在openshift容器平台，k8 在container, hosts, deployment 机制， 运维和容器规模上管理容器化应用。这个container runtime打包， 启动和运行容器化应用。一个k8集群包含了1到多个masters和一组nodes.
你可以为你的master配置HA（high availability）去保证这个集群不会宕机
openshift 3.11基于K8 1.10和Docker 1.13
这里对该结构的一些核心观念进行讲解：
master: 指包含控制面板组件的host或者hosts, 包含API server, controller manager server和etcd。master管理在K8 cluster的nodes并且调度pods在哪些pod上运行。
让我们认识以下这些组件
API server（K8 API server）为pods, services和replication controller提供数据的认证和配置。
它也给nodes分配pods, 对pod 信息和service配置进行同步。
etcd 保存了master的状态，同时， 其他组件会关注etcd的变化，根据调整到etcd所预期的状态。etcd可以配置HA（high availability）, 通常部署为2n+1的结队服务。
Controller Manager Server 关注etcd变化去调整objects的replication controllers
HA proxy optional, 实时配置HA masters在API master中作负载均衡。在安装集群的过程中可用该方法动态的配置HA proxy. 相应的，你自然也可以预先配置你的load balancer
注意 etcd, API server, controller manager 组件都是静态的pods. kubelet操作这些pods.
openshift-sdn 和openvswitch作为一个DaemonSet运行而非一个systemd服务
尽管control plane components作为静态pods运行，master host依旧从/etc/origin/master/master-config.yaml文件中读取配置。
master nodes上的kubelet自动的为每个control plane static pods在API server上创建镜像pods，从而使得其在集群众他们可见。
static pods的清单默认被openshift-ansible installer安装在master host中的/etc/origin/node/pods目录。
在这些pod上有以下path voluemes defined:
/etc/origin/master 含有所有的证书，配置文件和admin.kuberconfig文件
/var/lib/origin包含volumes和potential core dumps of the binary
/etc/origin/cloudprovider包含云运行上提供的专门的配置（AWS，Azure, etc）
/usr/libexec/kubernetes/kubelet-plugins包含额外的第三方volume plug-ins
/etc/origin/kubelet-plugins包含用于system containers的额外的第三方voluem plug-ins
你可以在静态pods上作的操作是非常有限的。例如你可以登陆API server，查看这些pod。但是你却不能删掉他们。
且更改这些静态pod的配置，通常也是通过更改master的配置，并通过重启master级别的服务来实现的。例如以下操作:
master-restart API去重启master API
master-restart controllers去重启master controllers.
master-restart etcd去重启etcd
Viewing Master Service Logs
去查看这些静态pod日志，可以使用以下命令：
master-logs api/controllers/etcd
Nodes
Node为containers提供了实时运行的环境。在K8集群中每一个node都必须被master管理的一些服务。Node还必须有另外一些服务去运行pods, 包括container runtime, a kubelet和a service proxy. Openshift Container Platfrom从cloud provider, physical systems和vitual systems中船舰nodes. K8和node objects进行交互。Master用node objects中的信息基于health checks去验证nodes。不能通过health checks的node是被忽略的。master在确定node可用之前会一直检测nodes. 针对node的状态和管理，详情还可见Kubernetes documentation。
Adminstrators 可以在Openshift Container Platform instance中用CLI去管理nodes. 启动node servers定义配置和security options，可以用 dedicated node configuration files.
让我们来看一下node上的那几个服务：
每个node都有一个kubelet，用以更新和这个node绑定在一起的container manifest(用于描述一个pod的YAML文件）。Kubelet用了一些列的manifests去保证这些容器都是运行状态。而验证的方法和简单的Health check类型，周期性的探测文件或者请求来探测一个服务的状态。
每个node都会运行一个简单的network proxy，用以反射在这个node上的服务的API。这就允许node 可以穿过一些后端去传输简单的TCP和UDP的数据包。
The following is an example node object definition in Kubernetes:
apiVersion:v1
kind:Node
metadata:
creationTimestamp:null
labels:kubernetes.io/hostname:node1.example.com
name:node1.example.com
spec:
externalID:node1.example.com
status:nodeInfo:boot
ID:""
container
RuntimeVersion:""
kernelVersion:""
kubeProxyVersion:""
kubeletVersion:""
machineID:""
osImage:""
systemUUID:""
apiVersion定义了所用的API version。Kind:node定义其资源类型为node。
metadata.labels列出了给这个node贴的标签。
metadata.name是这个nodeobject的名字。当你运行‘oc get noes’时会看到这个名字
Spec.exterID定义node可以访问的domain name. 默认metadata.name设置为空。
Node Bootstrapping(Node 引导程序)
node的配置是被master引导的，也就是说 nodes 从master上pull 下来事先定义好的配置和证书。这样做的好处是：
1. 减少了nodes的不同
2. node启动很快
3. 配置集中有助于整个cluster都集中在预期的状态。
当node服务被启动后，在其加入cluster之前，node会确认/etc/origin/node/node.kubeconfig文件和其他node配置文件是否存在。如果他们不存在，则node会pull，然后加入cluster；有则直接加入。
ConfigMaps用于保存在集群中node的配置，其定义与/etc/origin/node/node-config.yaml。
更多关于ConfigMaps可参见Defining Node Groups and Host Mappings
网友评论