Michael Blog

ImageStream是OpenShift中的一个特有的资源。在DeploymentConfig/BuildConfig中使用ImageStream和ImageStreamTag时经常会有这样的疑惑：究竟它指向的镜像有没有pull到OpenShift内部的镜像仓库呢？我们使用DeploymentConfig发布应用时，集群会从内部镜像仓库中pull镜像，还是从指向的外部镜像仓库中拉取？大家来看一下下面这个例子： 1$ oc import-image openshift/jenkins:v3.10 --from=docker.io/openshift/jenkins-2-centos7:v3.10 --confirm 猜一猜，以上这条命令是否会将镜像拉取到内部镜像仓库？答案是否定的，内部镜像仓库并不会拉取镜像本身，只是获取镜像的元数据，将创建的ImageStreamTag openshift/jenkins:v3.10指向镜像docker.io/openshift/jenkins-2-centos7:v3.10。这里的关键就是ImageStream[Tag]的一个配置项：re ...

1. 测试环境物理机设备：集群（3 master 2 infra 3 node） 管理（1manager 部署LB+外部镜像仓库+DNS）物理机配置：40c 378GOpenshift：v3.11.0+1a90c5c-83Kubernetes：v1.11.0+d4cacc0Kafka Operator：amq-streams-1.1.0Kafka：2.1.1 2. 测试要求和内容根据测试要求，本次具体测试的功能点如下： 序号 测试项目 测试项 优先级 1 Kafka Operator部署 Kafka Operator部署 高 Kafka集群创建 高 Kafka监控部署 高 2 Kafka功能测试 Kafka创建Topic 高 Openshift集群内部Kafka producer与consumer测试 高 Openshift集群外部Kafka producer与consumer测试（NodePort方案） 高 Openshift集群外部Kafka producer与consumer测试（Router方案） 高 3 Kafka ...

###1. readiness健康检查一直失败，Pod会不会重启？ 不会，一直处于Running状态，但Not Ready。 2. Pod重启时，Pod的容器是重启，还是重新创建？ POD容器不动，应用容器是重新创建。POD IP保持不变，但应用容器中的临时文件会丢失。 ###3. 如果更改Deployment的配置后，马上将配置恢复回去，应用Pod是否会触发重新部署？不会，恢复回去后不会创建新的RS。 4. master_cluster_hostname与master_cluster_public_hostname的区别master_cluster_hostname是集群内部组件使用的域名master_cluster_public_hostname是集群外部使用的域名###5. 对于高可用集群中，3个master节点是完全相同的吗？openshift 不是，虽然它们的运行态是完全一致的，但是在OpenShift的运维脚本中是有区分的，如集群扩容时。有一台是主master（inventory中的第一台），它会单独保存集群的证书及一些配置。 ###6. 对于statefulset类型 ...

calico 是容器网络的一种解决方案，也是当前最流行的方案之一。它完全利用路由规则实现动态组网，通过BGP协议通告路由。Calico BGP没有像ovs那样需要封包解包，所以它的网络性能更好。管理calico网络免不了使用calicoctl工具，本篇介绍如何在OpenShift/Kubernetes环境下，配置calicoctl来管理集群网络。 calico元数据支持两种存储类：etcd与kubernetes 安装calicoctl12$ curl -O -L https://github.com/projectcalico/calicoctl/releases/download/v3.10.0/calicoctl$ chmod a+x calicoctl 确认Calico部署时使用的元数据存储类型，查看calico-config1$ oc describe cm calico-config -n kube-system | grep datastore_type 可以为kubernetes、etcdv3。默认为etcdv3。设置为kubernetes时表示直接使用k8 ...

小强维护着一套生成的OpenShift集群，突然有一天集群的master1节点出现异常，自动关机了。他尝试了多次，都无法开机，怎么办？他需要赶快恢复master1节点，来满足集群的高可用性。 原来的masters在ansible/hosts中的顺序如下 1234567891011121314[masters]master1 ## 重要主节点，安装完后单独保存/etc/etcd/ca中的证书master2master3[etcd]master1master2master3[nodes]master1master2master3 恢复过程如下： 新建一台 master1节点，hostname 与 IP 都和原 master1 节点一致 在master2上恢复master主节点的证书、ca.serial.txt及openshift软件。 通过新增 master 的方式将这个节点重新加回集群 通过新增 etcd 的方法，恢复了这台 master 节点 etcd 的状况 以下是恢复的具体步骤。 一、初始化Master节点 与部署机互信 开启selinux 关闭firewall ...

背景大家知道OpenShfit官方通过Prometheus Operator可以快速构建高可用的监控告警平台，它不仅能够收集集群本身的监控指标，还可以通过ServiceMonitor扩展以监控应用自身的指标，实现单集群内部的统一监控。但是生产实践中，我们并不会只采用一个OpenShift部署应用，还会部署非容器应用，在非容器环境下也可能会部署Prometheus来监控相关服务（特别是现在Prometheus已经成为了监控的一个标配），甚至有可能会在不同的网络区部署多个集群，由于不同网络的隔离特性显然一组Prometheus是无法满足所有平台及应用的监控的。这就使得生产中会有很多套Prometheus集群需要管理与维护，查看监控指标也很分散，也就让我们想到必须采用一种办法能够将各处的指标统一收集，实现多集群多Prometheus服务的统一监控。目前实现这种要求的方法主要有两个，一个是通过Prometheus联邦 Federate，另一个是通过Thanos。今天主要介绍集群外部如何使用Prometheus联邦机制收集OpenShift内部Prometheus服务的监控指标。 操作实现其实 ...

prometheus.yml配置中绑定alertmanager服务 1234567......alerting: alertmanagers: - scheme: http static_configs: - targets: - "localhost:9093" prometheus.rules设置prometheus告警规则 12345678910...rules:- alert: TooManyPods expr: kuberlet_running_pod_count > 10 for: 2m labels: team: node annotations: summary: "{{$labels.instance}}: has {{$value}} pods" description: "{{$labels.instance}} be cateful ...

在企业实践中，通常会部署多个OpenShift集群：开发测试、生产等。每个集群都是独立的，通过物理资源进行隔离。这种方式管理简单，易于理解，但是消耗的资源更多，每个集群都需要额外的控制节点及运维节点。有没有办法，使不同环境运行在同一个集群上，并且它们之间实现隔离呢？答案是可以的。对于不同的环境，做好资源隔离，我们需要对计算资源——宿主机做好规划，同时还需要对网络做好规划。宿主机的隔离，可以通过给主机添加label的方法，规划pod的调度。本篇中，我们只针对网络Route部分做好开发测试环境与生产环境的隔离。 OpenShift集群Route分片机制大家都知道OpenShift管理南北流量是通过Route来实现的，所谓的Route本质就是一个Haproxy/Nginx服务，与K8S中的Ingress类似。默认情况下，OpenShift集群的Router是全局共用的，也就是说，在创建新的Route资源、Pod更新或者证书更新时，所有的OpenShift Router Pod都会更新Haproxy/Nginx的配置，并重新加载。所有的Route后台应用可以通过任一Rout ...

OpenShift的Router是几乎所有南北流量的入口，对它的运行机制的了解非常重要，尤其是Router的配置更新加载机制。在服务请求出现异常情况下，我们能够快速分析出问题的原因，及时修复，保证应用的连续性。本章主要介绍OpenShift Router的配置加载机制。 OpenShift路由默认是基于Haproxy实现的。当Pod有更新或者证书更新等情况时会重新加载Haproxy的配置，来保证集群的路由信息是最新的。重载配置是否会对当前在线业务产生影响，这是系统管理员担心的问题。 一、 Haproxy配置重载的过程Haproxy在重新加载配置过程分两步。 生成最新的配置 重启Haproxy进程 Haproxy生成最新的配置OpenShift上以下三种资源的改变会触发Haproxy配置的更新 Routes改变 Pod IP/Endpoint 改变 证书改变 OpenShift Route有一个配置模板文件，最终的配置会根据这个模板文件来创建。该模板文件，默认路径为/var/lib/haproxy/conf/haproxy-config.template，也可以通过环 ...

Route会话保持OpenShift Router是基于Haproxy反向代理实现的，客户端请求与后端应用POD通过cookie来实现会话保持。 默认是开启会话保持的，基于cookie的会话保持。 如果设置haproxy.router.openshift.io/disable_cookies为True，将会禁用基于cookie的会话保持，而使用balance的负载策略。 此过程分为两个阶段：第一次请求阶段、再次发起请求阶段 第一次请求阶段客户端发起第一次请求时，Router会给返回的数据中添加一条指定的cookie。 客户端请求到达Router节点。 Router节点通过默认的负载均衡策略选择后端应用POD。 后端应用POD返回数据到Router节点。 Router根据后端应用POD,给返回的数据包set-cookie: cookiename[HASH值]=cookievalue(HASH值），有效期为SESSION(浏览器客户端关闭前有效)。 再次发起请求阶段客户端再次发起请求时，会带上第一次Router设置的cookie,Router根据该cookie值选择对应的 ...