[13th][Day27] cluster

在丛集管理方面，kubernetes 将 cluster 中的机器划分为一个 master 节点以及一群工作节点(node)。
master 节点上运作的丛集管理相关的一套代理：
kube-apiserver
kube-controller-manager
kube-scheduler

这一套管理系统实现了整个 cluster 的自动化的资源管理、pod 调度、弹性缩放、安全管控、系统监控、容错 ... etc

node 作为丛集管理中的工作节点，执行真正的 application，在 node 中，k8s 管理的最小值行单位为 pod。
node 上运作的 k8s 的 kubelete、kube-proxy 相关服务，而他们负责着 pod 的建立、启动、监控、重启、删除、load balance .... etc

最後，在来看看传统 IT 系统中服务扩展 & 服务升级这两大难题，以及 k8s 所提供的全新思维。服务的扩展涉及资源配置(比方说 ... 选择哪个 node 扩充)、虚拟机器的部属 & 启动，在一个复杂的核心业务系统中，扩展 & 升级 这两大难题基本上由人工一步一步操作才能达到，不仅费时费力，而 ... 只要有人力的介入 ... 就增加了容易发生「意外」的可能性。

在 kubernetes cluster中，只需为扩展的 service 对应的 pod 建立一个 Replication Controller (RC)，接下来关於该 service 升级、扩展 ... 阿哩阿杂的麻烦问题看起来就不是那麽令人头痛了。

Replication Controller 的设定档必须包含几个资讯：

1. 目标 pod 的定义
2. 目标 pod 需要执行的 replicas (抄本数量)
3. 需监控的 目标 pod 上的 label(标签)

再建立好 RC 後， k8s 就会自动建置好 pod (如果 ... RC 有「正常」跑起来的话...)，k8s 会透过 RC 中定义的 label 筛选出对应的 pod 去监控其数量 & 状态，若是 pod 数量少於定义的 replicas ，则会依局 RC 中定义的 pod 范本来多新增 pod ，将此 pod 调度到合适的 node 上启动运作，直到满足 replicas 。

上面提到自动新增 pod 的部分完全是自动化的。无须人工干预，是不是棒透了呢 \0.0/
有了 RC ，服务扩展变成了一个单纯简单的数字游戏，只要修改 replicas 即可达成，要一个 pod 、两个 pod 还是 N 个 pod ，只需要调整一个数字就可以完成，後须 service 升级的部分也将透过修改 RC 来完成。