一、Kubernetes 架构：
Kubernetes Cluster 由 Master 和 Node 组成，节点上运行着若干 Kubernetes 服务。
Master 节点
Master 是 Kubernetes Cluster 的大脑，运行着如下 Daemon 服务：kube-apiserver、kube-scheduler、kube-controller-manager、etcd 和 Pod 网络（例如 flannel）。
API Server（kube-apiserver）
API Server 提供 HTTP/HTTPS RESTful API，即 Kubernetes API。API Server 是 Kubernetes Cluster 的前端接口，各种客户端工具（CLI 或 UI）以及 Kubernetes 其他组件可以通过它管理 Cluster 的各种资源。
Scheduler（kube-scheduler）
Scheduler 负责决定将 Pod 放在哪个 Node 上运行。Scheduler 在调度时会充分考虑 Cluster 的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。
Controller Manager（kube-controller-manager）
Controller Manager 负责管理 Cluster 各种资源，保证资源处于预期的状态。Controller Manager 由多种 controller 组成，包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。
不同的 controller 管理不同的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 资源。
etcd
etcd 负责保存 Kubernetes Cluster 的配置信息和各种资源的状态信息。当数据发生变化时，etcd 会快速地通知 Kubernetes 相关组件。
Pod 网络
Pod 要能够相互通信，Kubernetes Cluster 必须部署 Pod 网络，flannel 是其中一个可选方案。
以上是 Master 上运行的组件，下一节我们讨论 Node。
node节点
Node 是 Pod 运行的地方，Kubernetes 支持 Docker、rkt 等容器 Runtime。 Node上运行的 Kubernetes 组件有 kubelet、kube-proxy 和 Pod 网络（例如 flannel）。
kubelet
kubelet 是 Node 的 agent，当 Scheduler 确定在某个 Node 上运行 Pod 后，会将 Pod 的具体配置信息（image、volume 等）发送给该节点的 kubelet，kubelet 根据这些信息创建和运行容器，并向 Master 报告运行状态。
kube-proxy
service 在逻辑上代表了后端的多个 Pod，外界通过 service 访问 Pod。service 接收到的请求是如何转发到 Pod 的呢？这就是 kube-proxy 要完成的工作。
每个 Node 都会运行 kube-proxy 服务，它负责将访问 service 的 TCP/UPD 数据流转发到后端的容器。如果有多个副本，kube-proxy 会实现负载均衡。
Pod 网络
Pod 要能够相互通信，Kubernetes Cluster 必须部署 Pod 网络，flannel 是其中一个可选方案。
完整的架构图
结合实验环境，我们得到了如下的架构图：
你可能会问：为什么 k8s-master 上也有 kubelet 和 kube-proxy 呢？
这是因为 Master 上也可以运行应用，即 Master 同时也是一个 Node。
几乎所有的 Kubernetes 组件本身也运行在 Pod 里，执行如下命令：
kubectl get pod --all-namespaces -o wide
Kubernetes 的系统组件都被放到 kube-system namespace 中。这里有一个 kube-dns 组件，它为 Cluster 提供 DNS 服务，我们后面会讨论。kube-dns是在执行 kubeadm init 时（第 ⑤ 步）作为附加组件安装的。
二、Kubernetes 实践：
通过例子理解 k8s 架构
执行如下命令：
kubectl run httpd-app --image=reg.yunwei.edu/learn/httpd:latest --replicas=2
kubectl get deployment
kubectl get pod -n default -o wide
Kubernetes 部署了 deployment httpd-app，有两个副本 Pod，分别运行在k8s-node2 和 k8s-node3上。
详细讨论整个部署过程。
① kubectl 发送部署请求到 API Server。
② API Server 通知 Controller Manager 创建一个 deployment 资源。
③ Scheduler 执行调度任务，将两个副本 Pod 分发到 k8s-node1 和 k8s-node2。
④ k8s-node1 和 k8s-node2 上的 kubectl 在各自的节点上创建并运行 Pod。
补充两点：
-
应用的配置和当前状态信息保存在 etcd 中，执行 kubectl get pod 时 API Server 会从 etcd 中读取这些数据。
-
flannel 会为每个 Pod 都分配 IP。因为没有创建 service，目前 kube-proxy 还没参与进来。
Kubernetes 架构就讨论到这里。从下节开始，我们将通过实践深入学习 Kubernetes 的各种特性。作为容器编排引擎，最重要也是最基本的功能当然是运行容器化应用。
用 Deployment 运行应用
Deployment
前面我们已经了解到，Kubernetes 通过各种 Controller 来管理 Pod 的生命周期。为了满足不同业务场景，Kubernetes 开发了 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等多种 Controller。我们首先学习最常用的 Deployment。
（1）上面我们运行了一个http-app，下面详细分析 Kubernetes 都做了些什么工作。
kubectl get deployment -n default -o wide
接下来我们用 kubectl describe deployment httpd-app了解更详细的信息。
大部分内容都是自解释的，我们重点看最下面部分。这里告诉我们创建了一个 ReplicaSet httpd-app-cfb6dc947，Events 是 Deployment 的日志，记录了 ReplicaSet 的启动过程。
（2）通过上面的分析，也验证了 Deployment 通过 ReplicaSet 来管理 Pod 的事实。接着我们将注意力切换到 httpd-app-cfb6dc947，执行 kubectl describe replicaset：
两个副本已经就绪，用 kubectl describe replicaset 查看详细信息：
Controlled By 指明此 ReplicaSet 是由 Deployment/httpd-app 创建。Events 记录了两个副本 Pod 的创建。
（3）接着我们来看 Pod，执行 kubectl get pod -n default
两个副本 Pod 都处于 Running 状态，用 kubectl describe pod -n default 查看更详细的信息：
Controlled By 指明此 Pod 是由 ReplicaSet/httpd-app-cfb6dc947 创建。Events 记录了 Pod 的启动过程（httpd-app-cfb6dc947-mrtlz 和 httpd-app-cfb6dc947-rhgbs）。如果操作失败（比如 image 不存在），也能在这里查看到原因。
总结一下这个过程：
-
用户通过 kubectl 创建 Deployment。
-
Deployment 创建 ReplicaSet。
-
ReplicaSet 创建 Pod。
从上图也可以看出，对象的命名方式是：子对象的名字 = 父对象名字 + 随机字符串或数字。
