Kubernetes之核心概念（二）

Kubernetes核心概念

要深入的理解Kubernetes的特性和工作机制，首先要掌握Kubernetes模型中的核心概念。从集群组件的角度来看，Kubernetes主要是主节点中的组件，如kube-apiserver、kube-scheduler等，工作节点中的组件，如kubelete、kube-proxy、Docker等；从资源抽象的角度来看，主要就是几个抽象的概念，如容器组(Pod)、复制控制器(Replication Controller，RC)、部署(Deployment)和服务(Service)等。

Kubernetes 核心概念.png

Kubernetes 集群组件

Master组件

kube-apiserver：集群核心，API接口、集群各个组件通信的中枢；集群安全控制；
kube-scheduler：集群Pod的调度中心；
kube-controller-manager：集群状态管理器，当集群状态与期望不同时，KCM会努力让集群恢复期望状态，例如：当一个Pod死掉，KCM会努力新建一个Pod来恢复对应replicas set期望的状态；
etcd：集群的数据中心；

Node组件

kubelet：负责与节点上的Docker守护进程通信；
kube-proxy: 实现了Service的代理以及软件模式的负载均衡，主要是为节点间的通信进行服务；每个节点上都运行一个kube-proxy进程，kube-proxy负责将到某个service的请求转发到具体的Pod上。
Docker：运行Docker容器；

Kubernetes 资源抽象

Kubernetes对集群中的资源进行了不同级别的抽象，如容器组(Pod)、复制控制器(Replication Controller，RC)、部署(Deployment)和服务(Service)等。每个资源都是一个REST对象，通过API进行操作，通过JSON或者YAML格式的模板文件进行定义。

容器组 Pod

Kubernetes并不直接操作容器，它的最小管理单位是容器组（Pod）。Pod由一个或者多个容器组成，Kubernetes围绕Pod进行创建、调度、停止等生命周期管理。

同一个Pod中的容器之间共享命名空间、CGROUPS限制和存储卷。这就意味着同一个Pod中的容器之间可以方便的通信。可以将Pod想象成一个“虚拟机”，而Pod中的容器就是虚拟机中运行的进程。

通常位于同一个Pod中的容器之间有比较紧密的关系，如：一个Pod中部署web应用、日期采集应用、状态监控应用。

一个Pod中部署多个应用

Kubernetes中每个资源都是一个REST对象，用户可以通过YAML或者JSON模板来定义一个Pod资源，例如：

apiVersion: v1
kind: pod
metadata:
  name: nginx-text
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

YMAL文件的格式：① 冒号之后必须要有空格；② 缩进是两个空格；③ - 代表列表或者数组；

复制控制器 (Replication Controller，RC）

复制控制器类似一个监控进程，负责在Pod出现故障时，重新生成一个Pod。RC就是为了Pod的高可用而设计的。

用户申请Pod之后，复制控制器RC负责将Pod调度到某个节点上，并保证它的给定份数(replica)正常运行。当实际运行的Pod份数超过数目，则终止一些Pod；当不足，则创建新的Pod。一般建议即使Pod的份数为1，也要是用复制控制器RC来创建，而不是直接创建Pod。

ReplicaSet是新一代的RC，ReplicaSet和RC的唯一区别就是二者对选择器的支持不同，RC仅仅支持 equality-based selector而ReplicaSet支持set-based selector。

部署 Deployment

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。

你只需要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment，也可以创建一个新的替换旧的Deployment。

一个典型的用例如下：

使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。
然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
扩容Deployment以满足更高的负载。
暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。
根据Deployment 的状态判断上线是否hang住了。
清除旧的不必要的ReplicaSet。

服务 Services

RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。

Kubernetes中服务的提出主要是解决Pod地址可变的问题。由于Pod随时可能出现故障，并可能在其他节点上被重启，Pod地址是不能保持固定的。因此，用一个服务来代表提供某一类功能的一些Pod，并分配不随Pod位置变化而改变的虚拟访问地址(Cluster IP)。
如下图service中包含两个Pod，一个Pod位于一台主机上，每个Pod中上运行一个MySQL服务的容器，用户是直接通过service的cluster ip来使用MySQL服务。

通过Cluster IP访问服务

同其他资源类似，服务资源的JSON格式定义如下：

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "web-service",
    },
    "spec": {
        "selector": {
            "app": "webApp"
        },
        "ports": [
            {
                "protocol": "TCP",
                "port":  80,
                "targetPort":  80,
            }
        ]
    }
}

从上述分析可知，Pod具有临时性，随时都可能出现故障，因此通过Pod自身的地址访问应用是不可靠的，而需要通过服务访问，Service、Pod、RC和Namespace之间的关系如下图所示：

image.png

【持续改进和更新中】