[持续更新] 容器的本质是进程，Kubernetes 就是操作系统！

kubeadm 为 Kubernetes 项目生成的证书文件都放在 Master 节点的 /etc/kubernetes/pki 目录下。在这个目录下，最主要的证书文件是 ca.crt 和对应的私钥 ca.key。

Docker

tty 就是 Linux 给用户提供的一个常驻小程序，用于接收用户的标准输入，返回操作系统的标准输出。当然，为了能够在 tty 中输入信息，你还需要同时开启 stdin（标准输入流）。

kubeadm init 流程

1. Preflight Checks

2. 生成 Kubernetes 对外提供服务所需的各种证书和对应的目录

/etc/kubernetes/pki 目录下。在这个目录下，最主要的证书文件是 ca.crt 和对应的私钥 ca.key。

3. 为其他组件生成访问 kube-apiserver 所需的配置文件

/etc/kubernetes/xxx.conf： /etc/kubernetes/admin.conf controller-manager.conf kubelet.conf scheduler.conf

4. kubeadm 会为 Master 组件生成 Pod 配置文件

Static Pod（/etc/kubernetes/manifests）当这 kubelet 启动时，会自动检查这个目录，加载所有的 Pod YAML 文件,然后启动

在 kubeadm 中，Master 组件的 YAML 文件会被生成在 /etc/kubernetes/manifests 路径下。

Master包括 组件 kube-apiserver、kube-controller-manager、kube-scheduler

5. 生成 bootstrap token

只要持有这个 token，任何一个安装了 kubelet 和 kubadm 的节点，都可以通过 kubeadm join 加入到这个集群

将 ca.crt 等 Master 节点的重要信息，通过 ConfigMap 的方式保存在 Etcd（cluster-info） 当中，供后续部署 Node 节点使用

6. 安装默认插件

kube-proxy 提供整个集群的服务发现，DNS 插件用来 提供DNS 功能。

7. kubeadm join 的工作流程

任何一台机器想要成为 Kubernetes 集群中的一个节点，就必须在集群的 kube-apiserver 上注册。可是，要想跟 apiserver 打交道，这台机器就必须要获取到相应的证书文件（CA 文件）。所以，kubeadm 至少需要发起一次“不安全模式”的访问到 kube-apiserver，从而拿到保存在 ConfigMap 中的 cluster-info（它保存了 APIServer 的授权信息）。而 bootstrap token，扮演的就是这个过程中的安全验证的角色。只要有了 cluster-info 里的 kube-apiserver 的地址、端口、证书，kubelet 就可以以“安全模式”连接到 apiserver 上，这样一个新的节点就部署完成了。

8. 配置 kubeadm 的部署参数

1
kubeadm init --config=kubeadm-config.yaml --upload-certs

Master可部署用户pod

1⃣️

1
2
kubectl describe node master
- Name: master Roles: master Taints: node-role.kubernetes.io/master:NoSchedule

2⃣️

1
2
kubectl taint nodes --all node-role.kubernetes.io/master-
// 在“node-role.kubernetes.io/master”这个键后面加上了一个短横线“-”，这个格式就意味着移除所有以“node-role.kubernetes.io/master”为键的 Taint。

Rook：存储插件

Rook 项目是一个基于 Ceph 的 Kubernetes 存储插件（它后期也在加入对更多存储实现的支持）。不过，不同于对 Ceph 的简单封装，Rook 在自己的实现中加入了水平扩展、迁移、灾难备份、监控等大量的企业级功能，使得这个项目变成了一个完整的、生产级别可用的容器存储插件。

Volume

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
spec: 
	selector: 
		matchLabels: 
			app: nginx 
	replicas: 2 
	template: 
		metadata: 
			labels: 
			app: nginx 
			spec: 
				containers: 
				- name: nginx 
					image: nginx:1.8 
					ports: 
					- containerPort: 80 
					volumeMounts: 
					- mountPath: "/usr/share/nginx/html" 
					name: nginx-vol
				volumes:
				- name: nginx-vol 
				emptyDir: {}
			/////			/////			/////
				volumes: 
				- name: nginx-vol 
					hostPath: 
						path: " /var/data"
						
$ kubectl exec -it nginx-deployment-5c678cfb6d-lg9lw -- /bin/bash
# ls /usr/share/nginx/html

隐式

emptyDir 类型:等同于 Docker 的隐式 Volume 参数，即：不显式声明宿主机目录的 Volume。所以，Kubernetes 也会在宿主机上创建一个临时目录，这个目录将来就会被绑定挂载到容器所声明的 Volume 目录上。备注：不难看到，Kubernetes 的 emptyDir 类型，只是把 Kubernetes 创建的临时目录作为 Volume 的宿主机目录，交给了 Docker。这么做的原因，是 Kubernetes 不想依赖 Docker 自己创建的那个 _data 目录。而 Pod 中的容器，使用的是 volumeMounts 字段来声明自己要挂载哪个 Volume，并通过 mountPath 字段来定义容器内的 Volume 目录，比如：/usr/share/nginx/html。

显式

hostPath : 见上图⬆️

POD

$GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/api/core/v1/types.go type Pod struct PodSpec

PodSpec

NodeSelector

是一个供用户将 Pod 与 Node 进行绑定的字段

意味着这个 Pod 永远只能运行在携带了“disktype: ssd”标签（Label）的节点上；否则，它将调度失败。

NodeName

一旦 Pod 的这个字段被赋值，Kubernetes 项目就会被认为这个 Pod 已经经过了调度，调度的结果就是赋值的节点名字。所以，这个字段一般由调度器负责设置，但用户也可以设置它来“骗过”调度器，当然这个做法一般是在测试或者调试的时候才会用到。

HostAliases

定义了 Pod 的 hosts 文件（比如 /etc/hosts）里的内容，

Kubernetes 项目中，如果要设置 hosts 文件里的内容，一定要通过这种方法。否则，如果直接修改了 hosts 文件的话，在 Pod 被删除重建之后，kubelet 会自动覆盖掉被修改的内容。

Container

  • ImagePullPolicy ：ImagePullPolicy 的值默认是 Always，即每次创建 Pod 都重新拉取一次镜像。另外，当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时，ImagePullPolicy 也会被认为 Always。而如果它的值被定义为 Never 或者 IfNotPresent，则意味着 Pod 永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。

  • Lifecycle：Container Lifecycle Hooks。顾名思义，Container Lifecycle Hooks 的作用，是在容器状态发生变化时触发一系列“钩子”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

postStart : 在容器启动后，立刻执行一个指定的操作。需要明确的是，postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。

preStop: 容器被杀死之前（比如，收到了 SIGKILL 信号）。而需要明确的是，preStop 操作的执行，是同步的。所以，它会阻塞当前的容器杀死流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死，这跟 postStart 不一样。

Projected Volume

它们存在的意义不是为了存放容器里的数据，也不是用来进行容器和宿主机之间的数据交换。这些特殊 Volume 的作用，是为容器提供预先定义好的数据

Secret

  • 把 Pod 想要访问的加密数据，存放到 Etcd 中,通过在 Pod 的容器里挂载 Volume 的方式，访问 Secret 里保存的信息。
1
2
3
4
5
6
7
8
9

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  user: YWRtaW4=
  pass: MWYyZDFlMmU2N2Rm

ConfigMap

  • 它与 Secret 的区别在于，ConfigMap 保存的是不需要加密的、应用所需的配置信息

Downward API

  • 让 Pod 里的容器能够直接获取到这个 Pod API 对象本身的信息（/etc/podinfo/labels）

  • Downward API 能够获取到的信息，一定是 Pod 里的容器进程启动之前就能够确定下来的信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

1. 使用fieldRef可以声明使用:
  spec.nodeName - 宿主机名字
  status.hostIP - 宿主机IP
  metadata.name - Pod的名字
  metadata.namespace - Pod的Namespace
  status.podIP - Pod的IP
  spec.serviceAccountName - Pod的Service Account的名字
  metadata.uid - Pod的UID
  metadata.labels['<KEY>'] - 指定<KEY>的Label值
  metadata.annotations['<KEY>'] - 指定<KEY>的Annotation值
  metadata.labels - Pod的所有Label
  metadata.annotations - Pod的所有Annotation

2. 使用resourceFieldRef可以声明使用:
  容器的CPU limit
  容器的CPU request
  容器的memory limit
  容器的memory request

ServiceAccountToken

  • 是一种特殊的**secret **
1
2
3
4

$ ls /var/run/secrets/kubernetes.io/serviceaccount 
ca.crt namespace  token

这种把 Kubernetes 客户端以容器的方式运行在集群里，然后使用 default Service Account 自动授权的方式，被称作“InClusterConfig”，也是我最推荐的进行 Kubernetes API 编程的授权方式。

RestartPolicy

pod.spec.restartPolicy

Pod 的恢复过程，永远都是发生在当前节点上，而不会跑到别的节点上去。事实上，一旦一个 Pod 与一个节点（Node）绑定，除非这个绑定发生了变化（pod.spec.node 字段被修改），否则它永远都不会离开这个节点。这也就意味着，如果这个宿主机宕机了，这个 Pod 也不会主动迁移到其他节点上去。

而如果你想让 Pod 出现在其他的可用节点上，就必须使用 Deployment 这样的“控制器”来管理 Pod，哪怕你只需要一个 Pod 副本。

即 一个单 Pod 的 Deployment 与一个 Pod 最主要的区别。

livenessProbe

你的 Pod 其实可以暴露一个健康检查 URL（比如 /healthz），或者直接让健康检查去检测应用的监听端口。这两种配置方法，在 Web 服务类的应用中非常常用。

readinessProbe

检查结果的成功与否，决定的这个 Pod 是不是能被通过 Service 的方式访问到，而并不影响 Pod 的生命周期

PodPreset

PodPreset 里定义的内容，只会在 Pod API 对象被创建之前追加在这个对象本身上，而不会影响任何 Pod 的控制器的定义。

比如，我们现在提交的是一个 nginx-deployment，那么这个 Deployment 对象本身是永远不会被 PodPreset 改变的，被修改的只是这个 Deployment 创建出来的所有 Pod。这一点请务必区分清楚。

控制器

kubernetes/pkg/controller/

控制器模式

control loop

e .p.

Deployment 控制器从 Etcd 中获取到所有携带了“app: nginx”标签的 Pod，然后统计它们的数量，这就是实际状态；

Deployment 对象的 Replicas 字段的值就是期望状态；

Deployment 控制器将两个状态做比较，然后根据比较结果，确定是创建 Pod，还是删除已有的 Pod

Replicaset

一个 ReplicaSet 对象，其实就是由副本数目的定义和一个 Pod 模板组成的.

Deployment 控制器实际操纵的，正是 ReplicaSet 对象，而不是 Pod 对象。

Deployment

使用一种 API 对象（Deployment）管理另一种 API 对象（Pod）的方法，在 Kubernetes 中，叫作“控制器”模式（controller pattern）。Deployment 扮演的正是 Pod 的控制器的角色。

Deployment 实际上是一个两层控制器。首先，它通过 ReplicaSet 的个数来描述应用的版本；然后，它再通过 ReplicaSet 的属性（比如 replicas 的值），来保证 Pod 的副本数量。

滚动更新

1
2
3
4
5
6
7
8

$ kubectl get deployments
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         0         0            0           1s

DESIRED：用户期望的 Pod 副本个数（spec.replicas 的值）；
CURRENT：当前处于 Running 状态的 Pod 的个数；
UP-TO-DATE：当前处于最新版本的 Pod 的个数，所谓最新版本指的是 Pod 的 Spec 部分与 Deployment 里 Pod 模板里定义的完全一致；AVAILABLE：当前已经可用的 Pod 的个数，即：既是 Running 状态，又是最新版本，并且已经处于 Ready（健康检查正确）状态的 Pod 的个数。

相比之下，Deployment 只是在 ReplicaSet 的基础上，添加了 UP-TO-DATE 这个跟版本有关的状态字段。

好处：升级刚开始的时候，集群里只有 1 个新版本的 Pod。如果这时，新版本 Pod 有问题启动不起来，那么“滚动更新”就会停止，从而允许开发和运维人员介入。而在这个过程中，由于应用本身还有两个旧版本的 Pod 在线，所以服务并不会受到太大的影响。

StatefulSet

拓扑状态

这种情况意味着，应用的多个实例之间不是完全对等的关系。这些应用实例，必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。而如果你把 A 和 B 两个 Pod 删除掉，它们再次被创建出来时也必须严格按照这个顺序才行。并且，新创建出来的 Pod，必须和原来 Pod 的网络标识一样，这样原先的访问者才能使用同样的方法，访问到这个新 Pod。

存储状态

这种情况意味着，应用的多个实例分别绑定了不同的存储数据。对于这些应用实例来说，Pod A 第一次读取到的数据，和隔了十分钟之后再次读取到的数据，应该是同一份，哪怕在此期间 Pod A 被重新创建过。这种情况最典型的例子，就是一个数据库应用的多个存储实例。所以，StatefulSet 的核心功能，就是通过某种方式记录这些状态，然后在 Pod 被重新创建时，能够为新 Pod 恢复这些状态。

Headless Service

其实仍是一个标准 Service 的 YAML 文件。只不过，它的 clusterIP 字段的值是：None，即：这个 Service，没有一个 VIP 作为“头”。这也就是 Headless 的含义

StatefulSet 这个控制器的主要作用之一，就是使用 Pod 模板创建 Pod 的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。而当 StatefulSet 的“控制循环”发现 Pod 的“实际状态”与“期望状态”不一致，需要新建或者删除 Pod 进行“调谐”的时候，它会严格按照这些 Pod 编号的顺序，逐一完成这些操作。

通过 Headless Service 的方式，StatefulSet 为每个 Pod 创建了一个固定并且稳定的 DNS 记录，来作为它的访问入口。

Service

访问service两种方式：

Virtual IP，即：虚拟 IP . Cluster IP

DNS

​ 这时候，只要我访问“my-svc.my-namespace.svc.cluster.local”这条 DNS 记录，就可以访问到名叫 my-svc 的 Service 所代理的某一个 Pod。具体还可以分为两种处理方法：

​ 第一种处理方法，是 Normal Service。这种情况下，你访问“my-svc.my-namespace.svc.cluster.local”解析到的，正是 my-svc 这个 Service 的 VIP，后面的流程就跟 VIP 方式一致了。

​ 而第二种处理方法，正是 Headless Service。这种情况下，你访问“my-svc.my-namespace.svc.cluster.local”解析到的，直接就是 my-svc 代理的某一个 Pod 的 IP 地址。可以看到，这里的区别在于，Headless Service 不需要分配一个 VIP，而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址。

PVC

Persistent Volume Claim

PV

Persistent Volume