Kubernetes 是一个 可移植 、可扩展 的开源平台。使用 声明式的配置 依据配置信息自动化执行容器化应用程序的管理。
Traditonal Deployment（传统部署时代）：早期，企业直接将应用程序部署在物理机上，由于物理机不能为应用程序定义资源使用边界，很难合理地分配计算资源；
Virtualized Deployment（虚拟化部署时代）：用户可以在单台物理机的 CPU 上运行多个虚拟机；
- 虚拟化技术使得应用程序被虚拟机相互分隔开，限制了应用程序之间的非法访问，进而提供了一定程度的安全性；
- 虚拟化技术提高了物理机的资源利用率，可以更容易地安装或更新应用程序，降低了硬件成本，更好地规模化实施；
- 每一个虚拟机都可以被当作虚拟化的物理机上的一台完整机器，上面运行了一台机器的所有组件，包括虚拟机自身的操作系统。
Container Deployment（容器化部署时代）：容器与虚拟机类似，但降低了隔离层级，共享了操作系统。因此，容器可以被当作轻量级的
- 与虚拟机类似，每个容器都拥有自己的文件系统、CPU、内存、进程空间等；
- 运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦；
- 容器化应用程序可以跨云服务商、跨 Linux 操作系统发行版进行部署
容器化的优势：
Kubernetes不是一个传统意义的、保罗万象的 PaaS（Platform as a Service）系统。Kubernetes在容器层面工作，而不是硬件层面，它提供了与 PaaS 平台相似的通用特性，例如：部署、伸缩、负载均衡、日志、监控等。然而，Kubernetes并不是一个单一整体，这些特性都是可选、可插拔的。Kubernetes提供用于搭建开发平台的基础模块，同时为用户提供了不同模块的选择性和多样性。
可选的有 Jenkins / Gitlab Runner / docker registry / harbour 等
可选的有 ELK / Prometheus / Graphana / Pinpoint / Skywalking / Metrics Server 等
可选的有 helm/kustomize/kubectl/kubernetes dashboard/kuboard/octant/k9s 等
可选的组件有 puppet、ansible、open stack 等
Kubernetes不是一个纯粹意义上的容器编排系统。事实上，Kubernetes 消除了容器编排的需求。容器编排的技术定义是预定义流程的执行（先做A、再做B、然后做C）。与此相对应，Kubernetes构建了一系列相互独立、可预排的控制过程，以持续不断地将系统从当前状态调整到声明的目标状态
声明的方式是相对于非声明方式而言。
以滚动更新为例，假设当下有 3 个容器组，现在需要将它们的容器镜像更新为新的版本
- 非声明方式：
- 使用 kubectl 创建一个新版本镜像的容器组；
- 使用 kubectl 观察新建容器组的状态；
- 新建容器组的状态就绪之后，使用 kubectl 删除一个旧的容器组；
- 重复执行，直到所有容器组都已经替换为新版本镜像的容器组。
- 声明方式：
- 使用 kubectl 更新 Deployment 定义中 spec.template.spec.containers[].image 字段。
以 声明 的方式管理 Pod 和 ReplicaSet，其本质上是将一些特定场景的一系列运维步骤固化下来，以便快速无误的执行。
两种创建方式：
这里我们采用 kubectl 创建方式来完成~
（1）编辑 yaml 文件
## 该 yaml 文件定义了一个 Deployment，该 Deployment 将创建一个有 3 个 nginx Pod 副本的 ReplicaSet(副本集)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment # .metadata.name 字段指定了名称
labels:
app: nginx
spec:
replicas: 3
selector: # .spec.selector 字段指定了 Deployment 如何找到由他管理的 Pod
matchLabels:
app: nginx
template:
# 使用了 Pod template 定义的一个标签(app:nginx)，可根据需求添加更复杂的规则
metadata:
labels: # .template.metadata.labels 字段指定了 Pod 的标签
app: nginx
spec:
containers:
- name: nginx # .template.spec.containers[].name 字段表明容器名字为 nginx
image: nginx:1.7.9 # .template.spec.containers[].image 字段表明该 Pod 运行容器 nginx:1.7.9
ports:
- containerPort: 80
（2）执行命令来创建 Deployment
kubectl apply -f nginx-deployment.yaml
## 为该命令增加 --record 选项，kubectl 会将 kubectl apply -f nginx-deployment.yaml --record 写入 Deployment annotation(注解) kubernetes.io/change-cause 中，以便后期回顾某一个 Deployment 版本变化原因
（3）执行 kubectl get deployments 检查 deployment 创建情况，若还在创建过程中，则如下所示：
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
| 字段名称 | 说明 |
|---|---|
| NAME | Deployment name |
| DESIRED | Deployment 期望的 Pod 副本数，即 Deployment 中 .spec.replicas 字段指定的数值，为“期望”值 |
| CURRENT | 当前有多少个 Pod 副本数在运行 |
| UP-TO-DATE | Deployment 中，符合当前 Pod Template 定义的 Pod 数量 |
| AVAILABLE | 当前对用户可用的 Pod 副本数 |
| AGE | Deployment 部署以来到现在的时长 |
（4）查看 Deployment 的发布状态(rollout status)，执行命令 kubectl rollout status deployment.v1.apps/nginx-deployment
（5） 查看 Deployment 创建的 ReplicaSet（rs），执行命令 kubectl get rs
（6） 查看 Pod 的标签，执行命令 kubectl get pods --show-labels
警告：不要修改 Pod-template-hash 标签
当且仅当 Deployment 的 Pod template（.spec.template）字段中的内容发生变更时（例如标签、容器的镜像被改变），Deployment 的发布更新（rollout）将被触发。Deployment 中其他字段的变化（例如修改 .spec.replicas 字段）不会触发 Deployment 的发布更新（rollout）
两种途径对 Deployment 执行发布更新（rollout）：
这里我们采用 kubectl 更新方式来完成~
（1）将镜像从 nginx:1.7.9 更新到 nginx:1.9.1
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
（2）查看发布更新（rollout）的状态
kubectl rollout status deployment.v1.apps/nginx-deployment
查看 更新后 deployment 的情况
（1）更新（rollout）成功后，您可以执行命令 kubectl get deployments 以查看更新结果
（2）执行命令 kubectl get rs Deployment 的更新是通过创建一个新的 3 个副本数的 ReplicaSet 并同时将旧的 Replicaset 的副本数缩容到 0 个副本 来达成的
（3）执行命令 kubectl get pods，此时将只显示新的 Pod
.spec.replicas 的 75% 的 Pod 保持可用（25% max unavailable）.spec.replicas 的 25% 的 Pod 被创建（25% max surge）创建 Deployment 时，Deployment Controller 创建了一个 ReplicaSet，并直接将其 scale up 到 3 个副本。当更新 Deployment 时，Deployment Controller 先创建一个新的 ReplicaSet 并将其 scale up 到 1 个副本，然后 scale down 旧的 ReplicaSet 到 2。
Deployment Controller 继续 scale up 新的 ReplicaSet 并 scale down 旧的 ReplicaSet，直到最后，新旧两个 ReplicaSet，一个副本数为 3，另一个副本数为 0。
（1）检查 Deployment 更新历史
kubectl rollout history deployment.v1.apps/nginx-deployment
# 检查当前 Deployment 的历史版本
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
其中，CHANGE-CAUSE 是该 revision（版本）创建时从 Deployment 的 annotation kubernetes.io/change-cause 拷贝来
若需自定义，可通过如下操作完成：
kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1" 给 Deployment 添加注解--record 选项.metadata.annotation 信息（2）查看 revision（版本）详细信息
kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
（3）回滚前一个版本
kubectl rollout undo deployment.v1.apps/nginx-deployment
（4）回滚到前面某一个指定版本
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
## 通过 --to-revision=2 指定版本
（5）检查回滚是否成功
kubectl get deployment nginx-deployment
Master 组件是集群的控制平台
replicas 字段的规定时，启动一个新的 Pod）该组件提供 Kubernetes API。这是Kubernetes控制平台的前端（front-end），可以水平扩展（通过部署更多的实例以达到性能要求）。kubectl / kubernetes dashboard / kuboard 等Kubernetes管理工具就是通过 kubernetes API 实现对 Kubernetes 集群的管理。
支持一致性和高可用的名值对存储组件，Kubernetes集群的所有配置信息都存储在 etcd 中。
master 组件监控所有新创建尚未分配到节点的 Pod，并自动选择为 Pod 选择一个合适的节点去运行。
影响调度的因素有：
此 master 组件运行了所有的控制器
逻辑上说，每一个控制器是一个独立的进程，但为了降低复杂度，可以将这些控制器都合并在一个进程里。
其中包含的控制器有：
cloud-controller-manager 中运行了与具体云基础设施供应商互动的控制器。在 k8s 1.6 版本中引入的特性，它使得云供应商的代码和 Kubernetes 的代码可以各自独立的演化。在后续的版本中，特定于云供应商的代码将有云供应商自行维护，并在运行 kubernetes 时链接到
cloud-controller-manager。
下面这些控制器包含与云供应商相关的依赖：
Node 组件运行在每一个节点上（包括 master 节点和 worker 节点），负责维护运行中的 Pod 并提供 Kubernetes 运行时环境
运行在每一个集群节点上的代理程序。确保 Pod 中的容器处于运行状态，Kubelet 通过多种途径获得 PodSpec 定义，并确保 PodSpec 定义中所描述的容器处于运行和健康的状态。它只管理通过 Kubernetes 创建的容器。
kube-proxy 是一个网络代理程序，运行在集群中的每一个节点上，是实现 Kubernetes Service 的重要组成部分。
kube-proxy 在节点上维护网络规则。这些网络规则使得可以在集群内、外正确地与 Pod 进行网络通信。如果操作系统中存在
packet filtering layer，kube-proxy 将使用（iptables 代理模式）这一特性，否则的话，kube-proxy 将自行转发网络请求（User space 代理模式）