K8s 核心概念

Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部零容器化的应用简单并且高效 ( powerful ) , Kubernetes 提供了应用部香，规划，更新，维护的一种机制。

对应到 logo 中 , Docker 是一个鲸鱼运行了很多集装箱，而轮船 ( Kubernetes ) 来运集装箱 ( 管理 Docker )

1. Kubernetes 基本介绍

1.1 应用部署的演变

• 传统部署

优点: 简单，方便

缺点: 环境不隔离，两个程序之间可能会相互影响

• 虚拟化部署

优点: 解决了传统部署中的环境不隔离问题

缺点: 相比于传统部署结构更复杂了，浪费服务器资源 ( 因为有了多个虚拟机 )

• 容器化部署

优点：在同一个系统了，创建多个容器，每个容器拥有自己的文件系统（ 网络，进程..... ）

缺点：容器多了之后，容器管理不方便，以及容器数据持久化的问题

所以为了管理容器，就有了容器编排工具：

• Swarm：Docker 自己的容器编排工具

• Mesos：Apache 的一个资源统一管控的工具，需要和 Marathon 结合使用

• Kubernetes：Google 开源的的容器编排工具

1.2 k8s 特点

kubernetes 的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：

• 自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器

• 弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整

• 服务发现：服务可以通过自动发现的形式找到它所依赖的服务

• 负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡

• 版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本

• 存储编排：可以根据容器自身的需求自动创建存储卷

2. 集群架构和组件

2.1 k8s 架构

Master ( 主节点 ) : 集群的控制平面，负责集群的决策 ( 管理 )

• ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制

• Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上

• ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等

• Etcd ：负责存储集群中各种资源对象的信息

Node ( 从节点 ) ：集群的数据平面，负责为容器提供运行环境 ( 干活 )

• Kubelet : 负责维护容器的生命周期，即通过控制 docker，来创建、更新、销毁容器

• KubeProxy : 负责提供集群内部的服务发现和负载均衡

• Docker : 负责节点上容器的各种操作

2.2 控制面板（Master）组件

Api-Sever ( 入口 )：接口服务，基于 REST 风格开放 k8s 接口的服务，发起请求调用的就是 ApiServer

kube-controller-manager：控制器管理，管理各个类型的控制器，负责运行控制器进程

cloud-controller-manager：云控制器管理器，第三方平台同的控制器 API 对接管理功能

kube-scheduler：调度器，负责将 Pod 基于一定算法，将其调用到更合适的节点（服务器）上

etcd：键值类型存储的分布式数据库，提供了基于 Raft 算法实现自主的集群高可用

2.3 节点（Node）组件

kubelet：负责 Pod 的什么周期，存储，网格

kube-Proxy：网络dialing，负责 Service 的服务发现负责均衡（4 层负载）

container-runtime：容器运行时环境，docker，containerd，CRI-O

一台服务器有多个节点，一个节点下面有可以有多个 Pod，一个 Pod 下面有多个容器

所有节点之间依赖于 API-Server，通过控制器找到 api-server，最终进到节点里去，最终操作的就是 Pod

2.4 附加组件

kube-dns：kube-dns 负责为整个集群提供 DNS 服务

Ingress Controller：Ingress Controller 为服务提供外网入口

Prometheus：Prometheus 提供资源监控

Dashboard：Dashboard 提供 GUI

Federation：Federation 提供跨可用区的集群

Fluentd-elasticsearch：Fluentd-elasticsearch 提供集群日志采集、存储与查询

由上面这张图可以看出最顶层是 K8s 的生态系统（比如上面的附加组件），是基于看 K8s 创建出来的一系列应用

下一层是接口层所有的生态系统，应用，都需要调用 K8s 的接口

然后进入 K8s 的管理层，自动化管理应用

应用层则是部署应用 ( 无状态引用 , 有状态引用 , 批处理任务 , 集群应用等 ) 相关的一些东西

核心层 : Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境

3. 服务分类

3.1 无状态服务

无状态服务：不会对本地环境产生任何依赖，例如不会存储数据到本地磁盘

代表应用: Nginx，Apache

优点 : 对客户端透明 , 无依赖关系 , 可以高效的实现扩容 , 迁移

缺点 : 不能存储数据 , 需要额外的数据服务支撑

3.2 有状态服务

有状态服务：会对本地环境产生依赖，例如需要存储数据到本地磁盘

代表应用: Mysql , Redis

优点 : 可以独立存储数据 , 实现数据管理

缺点 : 集群环境下需要实现主从 , 数据同步 , 备份 , 水平扩容复杂

4. 资源和对象

首先在 k8s 中 , 所有内容被抽象为资源 ( 如 Pod , Service , Node )

资源通过配置文件的方式描述 ( JSON , YAML )

对象是基于资源创建出来的实例 , 是持久化的实体 , 比如某个具体的 Pod , Node ( 通过 Kubernetes API 就是 Api Server 提供的 Api 接口 )

4.1 对象规约 (spec) 和状态 (status)

• 对象规约 ( spec )

spec 描述了对象的期望状态（Desired State）—— 希望对象所具有的特征。当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）

• 对象状态

表示对象的实际状态，该属性由 k8s 自己维护，k8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态重合。

4.2 资源的分类

• 集群

集群级的资源 , 作用与集群之上 , 集群下所有资源都可以共享使用

• 元数据

对于资源的元数据描述 , 每个资源都可以使用元空间的数据

• 命名空间

对于 K8s 集群做了一个更加细致的划分，两个命名空间之间的资源可以隔离

加以区分是否了解这个资源是否可以跨集群使用 , 跨命名空间使用

4.3 元数据型

1. Horizontal Pod Autoscaler（HPA）：Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。（自动弹性伸缩）

2. PodTemplate：Pod Template 是关于 Pod 的定义，但是被包含在其他的 Kubernetes 对象中（例如 Deployment、StatefulSet、DaemonSet 等控制器）。控制器通过 Pod Template 信息来创建 Pod。（Pod 模版定义）

3. LimitRange：可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制，相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。（ 资源限制 ）

4.4 集群级

1. Namespace：Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群，这些虚拟集群被称为命名空间。（对 K8s 集群更细致的划分）

2. Node：相当于一台服务器，Node 本质上不是 Kubernetes 来创建的，Kubernetes 只是管理 Node 上的资源。(节点相同于一台服务器，有了节点才能作为 K8s 里面的一个节点)

3. ClusterRole：ClusterRole 是一组权限的集合，但与 Role 不同的是，ClusterRole 可以在包括所有 Namespace 和集群级别的资源或非资源类型进行鉴权。（对集群的权限管理，声明一个权限组）

4. ClusterRoleBinding：ClusterRoleBinding：将 Subject 绑定到 ClusterRole，ClusterRoleBinding 将使规则在所有命名空间中生效。（将角色和资源绑定）

5. Pod ( 重点 )

Pod（容器组）是 Kubernetes 中最小的可部署单元。一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。

pause 容器实现容器与容器之间的共享

一般情况下，一个 Pod 只运行一个容器，如果运行多个容器 （要求容器之间是需要协作运行的，否则两个容器不容器管理）

• 副本 ( replicas )

一个 Pod 可以被复制成多份，每一份可被称之为一个“副本”，这些“副本”除了一些描述性的信息（ Pod 的名字、uid 等）不一样以外，其它信息都是一样的，譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。

• 控制器 ( controller )

控制器可以创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。 例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。

Pod 的“控制器”通常包含一个名为 “replicas” 的属性。“replicas” 属性则指定了特定 Pod 的副本的数量，当当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s 会采取一些策略去使得当前状态满足配置的要求。

6. 控制器

Pod 的控制器：可以创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力

6.1 适用与无状态服务

ReplicationCotroller : 动态的更新 Pod 的副本数（根据 replicas）在 1.11 版本中被废弃

ReplicaSet : 动态的更新 Pod 的副本数，可以指定 selector 来选择对哪些 Pod 生效，实际工作也不会用，因为只有扩容缩容

Deployment : 针对 RS 更高层次的封装，提供了更丰富的部署相关功能

1. 创建 Replica Set / Pod

2. 滚动升级 / 回滚 （是自动的，自动检测容器的内容发送变化，就会做滚动升级）

3. 平滑扩容和缩容 （ 依赖 ReplicaSet 实现的 ）

4. 暂停与恢复 Deployment （ 如果觉得自动升级太频繁，可以先暂停 Deployment，等修改的内容多了之后再启动 ）

• 滚动升级 / 回滚

如果要对 RS1 进行滚动升级

过程如下 :

1. 首先针对 RS1 创建一个 新的 RS

2. 然后在 RS2 的 Pod1 中部署更新后的内容 , 然后停止 RS1 中的 Pod 1 ( 不是删除，是将服务变为不可用 )

3. 在 RS3 的 Pod2 中部署更新后的内容，停止 RS1 中的 Pod2

4. 这样 RS2 中的所有内容就为最新版

6.2 适用与有状态服务

组成 :

volumeClaimTemplate : 用于定义网络标志（DNS domain）

Headless Service) :

StatefulSet 中每个 Pod 的 DNS 格式为：

statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local

例如三个 redis pod :

redis-sts-0.redis-svc.sakura.svc.cluster.local

redis-sts-1.redis-svc.sakura.svc.cluster.local

redis-sts-2.redis-svc.sakura.svc.cluster.local

特点：

1. 稳定的持久化存储 （ 基于 volumeClaimTemplate）

2. 稳定的网络标志 ( 基于 Headless Service)

3. 有序部署，有序扩展

4. 有序收缩，有序删除

6.3 守护进程 daemonSet

DaemonSet 保证在每个 Node 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

基于一个选择器，将所有匹配到的 pod 都部署一个守护程序 ( 例如: 日志收集，系统监控，系统程序 )

• 日志收集，比如 fluentd，logstash 等

• 系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等

• 系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

6.4 任务 / 定时任务

• Job : 一次性任务，运行完成后Pod销毁，不再重新启动新容器

• CronJob : CronJob 是在 Job 基础上加上了定时功能

7. 服务发现

Ingress : 将 k8s 内部服务暴露给外网访问

Service : 实现 k8s 集群内部网络调用 , 负载均衡

8. 存储，配置，权限

8.1 存储

Volume : 数据卷 , 将 Pod 中的数据进行持久化

Container Storage Interface : 暴露容器内部存储的接口

8.2 配置

ConfigMap : 用来放配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放 ( 类似Etcd 和 golang 中的 viper )

Secret : 和 ConfigMap 一样，区别在于加密

DownwardAPI : 把 Pod 的信息共享到容器内部，使得容器可以直接读取到 Pod 信息，由两种方式

1. 环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部

2. volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去

8.3 权限

Role ：Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限，Role 用于给某个 Namespace 中的资源进行鉴权。( Role 定义命名空间级别的权限 )

RoleBinding : RoleBinding 是可以作用于 Role 和 ClusterRole，但是作用域是 NameSpace。