概念集合

1. Master

  • 集群控制节点

3 个核心进程：

  1. kube-apiserver：
    1. 提供了 HTTP Rest 接口的关键服务进程，是资源操作的唯一入口，
    2. 并提供认证、授权、访问控制、API 注册和发现等机制；
    3. 是集群的入口程序
  2. kube-controller manager：
    1. 所有资源对象的自动化控制：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
    2. 可以理解为资源对象的：“大总管”
  3. kube-scheduler：
    1. 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
    2. 理解为：调度室
  • 另外 etcd 必不可少：所有资源的数据都是保存在 etcd 中

2. Node

node

Node 是 Pod 真正运行的主机，可以物理机，也可以是虚拟机。

为了管理 Pod，每个 Node 节点上至少要运行

  1. container runtime——主要就是 docker
    1. 负责镜像管理以及 Pod 和容器的真正运行
  2. kubelet
    1. 负责维护容器的生命周期，
    2. 同时也负责 Volume（CVI）和网络（CNI）的管理；
  3. kube-proxy 服务
    1. 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

3. Pod

pod 文档

在 Kubernetes 中，最小的管理元素不是一个个独立的容器，而是 Pod,Pod 是最小的，管理，创建，计划的最小单元

包含：

  1. 根容器，Pause 容器：资源的共享及通信
  2. 业务容器（多个）: 具体业务

4. Lable

  • label 和 label selector 共同构成了 k8s 系统中 核心的应用模型，是的被管理对象能够精细的分组管理，实现整个集群的高可用性。
  1. 标签其实就一对 key/value ，被关联到对象上，比如 Pod, 标签的使用我们倾向于能够标示对象的特殊特点，并且对用户而言是有意义的（就是一眼就看出了这个 Pod 是尼玛数据库），但是标签对内核系统是没有直接意义的。
  2. 标签可以用来划分特定组的对象（比如，所有女的），
  3. 标签可以在创建一个对象的时候直接给与，也可以在后期随时修改，
  4. 每一个对象可以拥有多个标签，但是，key 值必须是唯一的

针对不同功能的常用标签

版本：“release” : “stable”, “release” : “canary”, …
环境：“environment” : “dev”, “environment” : “qa”, “environment” : “production”
架构：“tier” : “frontend”, “tier” : “backend”, “tier” : “middleware”
分区：“partition” : “customerA”, “partition” : “customerB”, …
质量管理：“track” : “daily”, “track” : “weekly”

具体使用

  1. 定义在 labels 字段
  2. 使用 selector 字段进行关联
    1. matchLabels
    2. matchExpressions

还有专门的查询语法

使用场景

  1. kube-controller 控制 rc 中 pod 数量
  2. kube-proxy 建立路由转发表
  3. node 定向调度 pod

5. Replication Controller

  • Replication Controller 保证了在所有时间内，都有特定数量的 Pod 副本正在运行，如果太多了，Replication Controller 就杀死几个，如果太少了，Replication Controller 会新建几个，
  • 和直接创建的 pod 不同的是，Replication Controller 会替换掉那些删除的或者被终止的 pod，不管删除的原因是什么（维护阿，更新啊，Replication Controller 都不关心）。基于这个理由，我们建议即使是只创建一个 pod，我们也要使用 Replication Controller。
  • Replication Controller 就像一个进程管理器，监管着不同 node 上的多个 pod, 而不是单单监控一个 node 上的 pod,Replication Controller 会委派本地容器来启动一些节点上服务（Kubelet ,Docker）。

核心就是管理 pod，包括：

  1. Pod 数量
  2. Pod 标签
  3. Pod 模板（标签也在模板中定义）
  • ReplicaSet 和 Replication Controller 之间的唯一区别是现在的选择器支持：
    • Replication Controller 只支持基于等式的 selector（env=dev 或 environment!=qa），
    • 但 ReplicaSet 还支持新的，基于集合的 selector（version in (v1.0, v2.0) 或 env notin (dev, qa)）

6. 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。

Service

  • Kubernetes Pod 是平凡的，它门会被创建，也会死掉（生老病死），并且他们是不可复活的。
  • ReplicationControllers 动态的创建和销毁 Pods（比如规模扩大或者缩小，或者执行动态更新）。每个 pod 都由自己的 ip，这些 IP 也随着时间的变化也不能持续依赖。这样就引发了一个问题：如果一些 Pods（让我们叫它作后台，后端）提供了一些功能供其它的 Pod 使用（让我们叫作前台），在 kubernete 集群中是如何实现让这些前台能够持续的追踪到这些后台的？

答案是：Service

service 和 rc 、pod 的关系：

参考

  1. 《kubernetes 权威指南》
  2. 中文文档