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
【持续改进和更新中】
