k8s基础概念

Kubernetes 是什么

Kubernetes 是一个基于容器技术的完备的分布式系统支撑平台。其具有完备的集群管理能力，包括：

• 服务发现和负载均衡
  Kubernetes 可以使用 DNS 名称或者自己的 IP 地址公开容器，如果进入容器的流量很大，Kubernetes 能够负载均衡并分配网络流量，从而使部署稳定。
• 存储编排
  Kubernetes 允许自动挂载选择的存储系统，例如本地存储、公共云提供商等。
• 自动部署和回滚
  可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为期望状态。例如，可以自动化 Kubernetes 来为部署创建新的容器，删除现有的容器并将它们的所有资源用于新容器。
• 自动完成装箱计算
  Kubernetes 允许指定每个容器所需的 CPU 和 内存。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
• 自我修复
  Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的、运行状况异常的容器，并且在准备好服务之前不将其通告给客户端。
• 秘钥和配置管理
  Kubernetes 允许存储和管理敏感信息，例如密码、Oauth 令牌和 ssh 秘钥。可以在不重建容器镜像的情况下部署和更新秘钥与应用程序配置，也无需在堆栈配置中暴露秘钥。

Kubernetes 架构

控制平面组件（Control Plane Components）

控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）。

控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。

kube-apiserver

API 服务器是 Kubernetes 控制面的组件， 该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端。
Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平伸缩，也就是说，它可通过部署多个实例进行伸缩。

etcd

etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。

kube-scheduler

控制平面组件，负责监视新创建的、未指定运行节点（node）的 Pods，选择节点让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

kube-controller-manager

在主节点上运行 控制器 的组件。
从逻辑上讲，每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
这些控制器包括:

• 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
• 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
• 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

cloud-controller-manager

云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接集群到云提供商的应用编程接口中， 并把和该云平台交互的组件与只和您的集群交互的组件分离开。

cloud-controller-manager 仅运行特定于云平台的控制回路。 如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的环境中不需要云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
• 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
• 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器

Node 组件

节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。

kubelet

一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

kube-proxy

kube-proxy 是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。
kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了数据包过滤层并可用的话，kube-proxy 会通过它来实现网络规则。否则， kube-proxy 仅转发流量本身。

Kubernetes 基本术语

Kubernetes 中的大部分概念如 Node、Pod、Replication Controller、Service 等都可以被看作一种资源对象，几乎所有资源对象都可以通过 Kubernetes 提供的 kubectl 工具（或者 API 编程调用）执行增、删、改、查等操作并将其保存在 etcd 中持久化存储。

Master

Kubernetes 里的 Master 指的是集群控制节点，在每个 Kubernetes 集群里都需要有一个 Master 来负责整个集群的管理和控制，基本上 Kubernetes 的所有控制命令都发给它，它负责具体的执行过程，几乎所有的执行命令都是在 Master 上运行的。Master 通常会占据一个独立的服务器（高可用部署建议至少3台）。

Master 上运行以下关键进程：

• Kubernetes API Server（kube-apiserver）：提供了 HTTP request 接口的关键服务进程，是 Kubernetes 里所有的资源的增删改查等操作的唯一入口，也是集群控制的入口进程；
• Kubernetes Controller Manager（kube-controller-manager）：Kubernetes 里所有资源对象的自动化中心，可以将其理解为资源对象的「大总管」；
• Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod 调度）的进程

另外，在 Master 机器上通常还需要部署 etcd 服务，因为 Kubernetes 里的所有资源对象的数据都是在保存 etcd 中。

Node

除了 Master 之外，Kubernetes 集群中的其他机器称之为 Node。和 Master 一样，Node 可以是物理机，也可以是一台虚拟机。Node 是 Kubernetes 集群中的工作负载节点，每个 Node 上都会被 Master 分配一些工作负载（Docker 容器），当某个 Node 宕机时，其上的工作负载会被 Master 自动转移到其他节点上。在每个 Node 节点上运行如下进程：

• kubelet：负责 Pod 对应的容器的创建、启停等任务，同时和 Master 密切协作，实现集群管理的基本功能；
• kube-proxy：实现 Kubernetes Service 的通信和负载均衡机制的重要组件；
• Docker Engine：负责本机的容器创建和管理工作。

Node 可以在运行期间动态增加到 Kubernetes 集群中，前提是在这个节点上已经正确安装、配置和启动了上述关键进程，在默认情况下 kubelet 会向 Master 注册自己，这也是 Kubernetes 推荐的 Node 管理方式。一旦 Node 被纳入集群管理范围，kubelet 进程就会定时向 Master 汇报自身的情报，例如操作系统、Docker 版本、机器的 CPU 和内存情况，以及当前有哪些 Pod 在运行等，这样 Master 就可以获知每个 Node 的资源使用情况，并实现高效均衡的资源调度策略。而某个 Node 在超过指定时间不上报信息时，会被Master 判定为“失联”，Node 的状态被标记为不可用（Not Ready），随后 Master 会触发“工作负载大转移”的自动流程。

Pod

Pod 是 Kubernetes 最重要的基本概念。每个 Pod 都有一个被称为“根容器”的 Pause 容器。Pause 容器对应的镜像属于 Kubernetes 平台的一部分。除了 Pause 容器，每个 Pod 还包含一至多个紧密相关的用户业务容器。

之所以要增加 Pause 容器，是因为：

• 在一组容器作为一个单元的情况下，我们难以简单的对“整体”进行判断及相应行动。例如，一个容器死亡了，怎么判断该 pod 的状态。引入业务无关的 Pause 容器作为 Pod 的根容器，以它的状态来表示 Pod 的状态，巧妙地解决了这个问题；
• Pod 里多个业务容器共享 Pause 容器的IP，共享 Pause 容器挂载的 Volume，这样既简化了业务容器之间的通信问题，也很好解决了他们之间的文件共享问题。

创建一个容器：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mynginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mynginx
  template:
    metadata:
      labels:
        app: mynginx
    spec:
      containers:
      - name: mynginx
        image: nginx
        imagePullPolicy: Always
        ports:
        - containerPort: 80

Kind 为 Pod 表明这是一个 Pod 定义。

每个 Pod 都可以对其能使用的服务器上的计算资源设置限额，当前可以设置的限额的计算资源有 CPU 和 Memory 两种，其中 CPU 的资源单位和为 CPU（core）的数量，是有个绝对值而非相对值。

对于绝大数容器来首，一个 CPU 的资源配额相当大，所以在 Kubernetes 里通常以千分之一的 CPU 配额为最小单位，用 m 来表示。通常一个容器的 CPU 配额被定义为 100~300m，即占用 0.1~0.3 个CPU。由于CPU配额是一个绝对值，所以无论在拥有一个 Core 的机器上，还是在拥有48个 Core 的机器上，100m 这个配额所代表的 CPU 的使用量都是一样的。与 CPU 配额类似，Memory 配额也是一个绝对值，它的单位是内存字节数。

在 Kubernetes 里，一个计算资源进行配额限定时设定如下两个参数：

• Requests：该资源的最小申请量，系统必须满足该要求；
• Limits：该资源最大允许使用的量，不能超过该数值。当容器试图使用超过该设定的资源时，可能会被 Kubernetes 杀掉并重启。