Kubernetes架构理论理解
Kubernetes Cluster 由 Master 和 Node 组成，节点上运行着若干 Kubernetes 服务。
Master 节点中运行组件
如图所示，将使用上篇文档中的介绍的概念来理解k8s的框架，先看在master节点运行着k8s的哪些服务
Master 是 Kubernetes Cluster 的大脑，运行着如下 Daemon 服务：kube-apiserver、kube-scheduler、kube-controller-manager、etcd 和 Pod 网络（例如 flannel）。
在集群master使用命令kubectl get pod -o wide --all-namespaces，可以看到在集群各个节点运行的组件
API Server（kube-apiserver）
API Server 提供 HTTP/HTTPS 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组件运行端口
在安装文档中有提到关于kubernetes的有很多端口号，每部分端口号对应着某个节点所运行的组件，如在
| 端口范围 | 组件 |
|---|---|
| 64430-64439 | API Server |
| 2379-2380 | etcd、API Server |
| 10250 | Kubelet API |
| 10251 | kube-scheduler |
| 10252 | kube-controller-manager |
Node节点中运行组件
Node 是 Pod 运行的地方，Kubernetes 支持 Docker、rkt 等容器 Runtime。 Node上运行的 Kubernetes 组件有 kubelet、kube-proxy 和 Pod 网络（例如 flannel）。
如图所示
kubelet
kubelet 是 Node 的 agent，当Master节点的Scheduler组件确定在某个 Node 上运行 Pod 后，会将 Pod 的具体配置信息（image、volume 等）发送给该Node的 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 网络
细心一点的应该可以发现，在master节点也运行着kubelet和kube-proxy，因为master也是一个node，也会去运行Pod容器。
几乎所有的 Kubernetes 组件本身也运行在 Pod 里，执行如下命令：
kubectl get pod --all-namespaces -o wideKubernetes 的系统组件都被放到 kube-system namespace 中。这里还有一个 kube-dns 组件，它为 Cluster 提供 DNS 服务，后面会说到。kube-dns是在执行kubeadm init时，作为附加组件安装的。
Kubelet是唯一没有以容器形式运行的Kubernetes组件。
实例理解Kubernetes结构
通过使用Kubernetes部署一个应用来演示各个组件之间是如何协作的
[root@node1 ~]# kubectl run httpd-app --image=httpd --replicas=2
Flag --replicas has been deprecated, has no effect and will be removed in the future.
pod/httpd-app created在1.18版本的kubernetes中已经将--replicas选项弃用，据目前所知只能使用yml文件来启动多个容器了，所以最终只运行了一个容器
查看已经运行的pod
[root@node1 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
httpd-app 1/1 Running 0 41m查看运行的pod被调度运行到了哪台节点中
[root@node1 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
httpd-app 1/1 Running 0 3m 10.244.2.3 node3 <none> <none>访问仓库到的ip
[root@node1 ~]# curl 10.244.2.3
<html><body><h1>It works!</h1></body></html>删除pod
1.18版本之前kubectl run运行之后会生成一个Deployment，在Deployment中运行了Pod，这里没有生成是因为是新版本，我也是刚发现，在1.17版本中是可以的，删除的方法，没有随着版本的变化而变化
kubectl delete deployment httpd-app删除deployment就是删除它所创建的pod，在后面的文档中会有演示
管理者通过kubectl发送部署信息到Master中的API Server组件中
API Server通知Controller Manager创建一个deployment资源
Scheduler执行调度任务，将副本pod分发到node3中
node3的kubelet在自己节点上创建并运行pod
pod中服务的配置和当前状态的信息保存在etcd中，执行kubectl get pod时API Server会从etcd中读取这些数据。
flannel会为每个pod都分配ip，因为没有创建service，目前kube-proxy还没有参与进来
以上例子中的创建应用的方法在新版本1.18.1的kubernetes中已经被取消，所以接下来会使用初次之外的另一种方法来去创建应用
博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
