上一节我们讨论了 Kubernetes 架构 Master 上运行的服务,本节讨论 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
时(第 ⑤ 步)作为附加组件安装的。
kubelet 是唯一没有以容器形式运行的 Kubernetes 组件,它在 Ubuntu 中通过 Systemd 运行。
为了帮助大家更好地理解 Kubernetes 架构,下节我们将部署一个应用来展示各个组件是如何协作的。
昨天在群里看他们讨论,说1.9又改了好多功能,变化起来跟上两年的openstack一样,今天合适的思路到明天就废了。
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
思路不会变。变的是一些细节
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit