GeorgeGuo

选择有时候比奋斗更重要

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文件的格式:① 冒号之后必须要有空格;② 缩进是两个空格;③ - 代表列表或者数组;

服务 Services

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,
            }
        ]
    }
}

复制控制器 (Replication Controller,RC)

复制控制器类似一个监控进程,负责在Pod出现故障时,重新生成一个Pod。

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

从上述分析可知,Pod具有临时性,随时都可能出现故障,因此通过Pod自身的地址访问应用是不可靠的,而需要通过服务访问;

Service、Pod、RC和Namespace之间的关系如下图所示:
image.png

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。

【持续改进和更新中】

参考

阅读更多
个人分类: Docker kubernetes
想对作者说点什么? 我来说一句

Kubernetes 核心概念

2016年08月21日 761KB 下载

没有更多推荐了,返回首页

不良信息举报

Kubernetes之核心概念(二)

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭