《Kubernetes应用部署模型解析》由会员分享，可在线阅读，更多相关《Kubernetes应用部署模型解析（8页珍藏版）》请在金锄头文库上搜索。
1、KubernetesKubernetes 应用部署模型原理解析应用部署模型原理解析Kubernetes 可用来管理 Linux 容器集群，加速开发和简化运维(即 DevOps)。但 目前网络上关于 Kubernetes 的文章介绍性远 多于实 际使用。本系列文章着眼 于实际部署，带您快速掌握 Kubernetes。本文为上篇，主要介绍部署之前需要 了解的原理和概念，包括 Kubernetes 的 组件结构，以及各个组件角色的功能。十多年来 Google 一直在生产环境中使用容器运行业务，负责管理其容器集群的 系统就是 Kubernetes 的前身 Borg。其实现在很多工作在 Kubernet
2、es 项目上 的 Google 开发者先前就在 Borg 这个项目上工作。多数 Kubernetes 的应用部署 模型的思想都起源于 Borg,了解 这些模型是掌握 Kubernetes 的关键。 Kubernetes 的 API 版本目前是 v1，本文以代码 0.18.2 版为基础来介绍它的应 用部署模型，最后我们用一个简单的用例来说明部署过程。 在部署结束后，阐 述了它是如何用 Iptables 规则来实现各种类型 Service 的。KubernetesKubernetes 架构架构Kubernetes 集群包括 Kubernetes 代理 (agents ) 和 Kubernetes
3、服务 (master node) 两种角色，代理角色的组件包括 Kube-proxy 和 Kubelet ，它 们同时部署在一个节点上，这个节点也就是代理节点。服务角色的组件包括 kube-apiserver ， kube-scheduler ， kube-controller-manager ，它们 可 以任意布属，它们可以部署在同一个节点上，也可以部署在不同的节点上(目前 版本好像不行)。 Kubernetes 集群依赖的第三方组件目前有 etcd 和 docker 两个。前者提供状态存储，二者用来管理容器。集群还可以使用分布式存储给 容器提供存储空间。下图显示了目前系统的组成部分：Kub
4、ernetesKubernetes 代理节点代理节点Kubelet 和 Kube-proxy 运行在代理节点上。他们监听服务节点的信息来启动容 器和实现 Kubernetes 网络和其它业务模型，比如 Service、Pod 等。当然每个 代理节点都运行 Docker。Docker 负责下载容器镜像和运行容器。KubeletKubeletKubelet 组件管理 Pods 和它们的容器，镜像和卷等信息。Kube-ProxyKube-ProxyKube-proxy 是一个简单的网络代理和负载均衡器。它具体实现 Service 模型， 每个 Service 都会在所有的 Kube-proxy 节点
5、上体现。根据 Service 的 selector 所覆盖的 Pods, Kube-proxy 会对这些 Pods 做负载均衡来服务于 Service的访问者。KubernetesKubernetes 服务节点服务节点Kubernetes 服务组件形成了 Kubernetes 的控制平面，目前他们运行在单一节 点上，但是将来会分开来部署，以支持高可用性。etcdetcd所有的持久性状态都保存在 etcd 中。Etcd 同时支持 watch，这样组件很容易得 到系统状态的变化，从而快速响应和协调工作。KubernetesKubernetes APIAPI ServerServer这个组件提供对
6、API 的支持，响应 REST 操作，验证 API 模型和更新 etcd 中的 相应对象。SchedulerScheduler通过访问 Kubernetes 中/binding API, Scheduler 负责 Pods 在各个节点上的 分配。Scheduler 是插件式的，Kubernetes 将来可以支持用户自定义的 scheduler。KubernetesKubernetes ControllerController ManagerManager ServerServerController Manager Server 负责所有其它的功能，比如 endpoints 控制器负 责 En
7、dpoints 对象的创建，更新。node 控制器负责节点的发现，管理和监控。 将来可能会把这些控制器拆分并且提供插件式的实现。KubernetesKubernetes 模型模型Kubernetes 的伟大之处就在于它的应用部署模型，主要包括 Pod、Replication controller、Label 和 Service。PodPodKubernetes 的最小部署单元是 Pod 而不是容器。作为 First class API 公民， Pods 能被创建，调度和管理。简单地来说，像一个豌豆荚中的豌豆一样，一个 Pod 中的应用容器同享同一个上下文：1. PID 名字空间。但是在 doc
8、ker 中不支持 2. 网络名字空间，在同一 Pod 中的多个容器访问同一个 IP 和端口空间。 3. IPC 名字空间，同一个 Pod 中的应用能够使用 SystemV IPC 和 POSIX 消 息队列进行通信。 4. UTS 名字空间，同一个 Pod 中的应用共享一个主机名。 5. Pod 中的各个容器应用还可以访问 Pod 级别定义的共享卷。 从 生命周期来说，Pod 应该是短暂的而不是长久的应用。 Pods 被调度到节点， 保持在这个节点上直到被销毁。当节点死亡时，分配到这个节点的 Pods 将会被 删掉。将来可能会实现 Pod 的迁移特性。在实际使用 时，我们一般不直接创建 Pod
9、s, 我们通过 replication controller 来负责 Pods 的创建，复制，监控和 销毁。一个 Pod 可以包括多个容器，他们直接往往相互协作完成一个应用功能。ReplicationReplication controllercontroller复制控制器确保 Pod 的一定数量的份数(replica)在运行。如果超过这个数量， 控制器会杀死一些，如果少了，控制器会启动一些。控制器也会在节点失效、 维护的时候来保证这个数量。所以强烈建议即使我们的份数是 1，也要使用复 制控制器，而不是直接创建 Pod。在生命周期上讲，复制控制器自己不会终止，但是跨度不会比 Service 强
10、。 Service 能够横跨多个复制控制器管理的 Pods。而且在一个 Service 的生命周 期内，复制控制器能被删除和创建。Service 和客户端程序是不知道复制控制 器的存在的。复制控制器创建的 Pods 应该是可以互相替换的和语义上相同的，这个对无状态 服务特别合适。Pod 是临时性的对象，被创建和销毁，而且不会恢复。复制器动态地创建和销 毁 Pod。虽然 Pod 会分配到 IP 地址，但是这个 IP 地址都不是持久的。这样就 产生了一个疑问：外部如何消费 Pod 提供的服务呢?ServiceServiceService 定义了一个 Pod 的逻辑集合和访问这个集合的策略。集合是通
11、过定义 Service 时提供的 Label 选择器完成的。举个例子，我们 假定有 3 个 Pod 的备 份来完成一个图像处理的后端。这些后端备份逻辑上是相同的，前端不关心哪 个后端在给它提供服务。虽然组成这个后端的实际 Pod 可能变 化，前端客户端 不会意识到这个变化，也不会跟踪后端。Service 就是用来实现这种分离的抽 象。对于 Service，我们还可以定义 Endpoint，Endpoint 把 Service 和 Pod 动态地 连接起来。ServiceService ClusterCluster IPIP 和和 kuberkuber proxyproxy每 个代理节点都运行了
12、一个 kube-proxy 进程。这个进程从服务进程那边拿到 Service 和 Endpoint 对象的变化。 对每一个 Service, 它在本地打开一个端口。到这个端口的任意连接都会代理到后端 Pod 集合中的一个 Pod IP 和端口。在 创建了服务后，服务 Endpoint 模型会体现后端 Pod 的 IP 和端口列表，kube- proxy 就是从这个 endpoint 维护的列表中选择服务后端的。另外 Service 对象 的 sessionAffinity 属性也会帮助 kube-proxy 来选择哪个具体的后端。缺省 情况下，后端 Pod 的选择是随机的。可以设置 servi
13、ce.spec.sessionAffinity 成 “ClientIP“ 来指定同一个 ClientIP 的流量代理到同一个后端。在实现上，kube-proxy 会用 IPtables 规则把访问 Service 的 Cluster IP 和端 口的流量重定向到这个本地端口。下面的部分会讲什么是 service 的 Cluster IP。注意：在 0.18 以前的版本中 Cluster IP 叫 PortalNet IP。内部使用者的服务发现内部使用者的服务发现KubernetesKubernetes在一个集群内创建的对象或者在代理集群节点上发出访问的客户端我们称之为 内部使用者。要把服务暴露
14、给内部使用者，Kubernetes 支持两种方式：环境变量和 DNS。环境变量环境变量当 kubelet 在某个节点上启动一个 Pod 时，它会给这个 Pod 的容器为当前运行 的 Service 设置一系列环境变量，这样 Pod 就可以访问这些 Service 了。一般 地情况是 SVCNAME_SERVICE_HOST h 和 SVCNAME_SERVICE_PORT 变量 , 其 中 SVCNAME 是 Service 名字变成大写，中划线变成下划线。比如Service “redis-master“，它的端口是 TCP 6379，分配到的 Cluster IP 地址 是 10.0.0.1
15、1，kubelet 可能会产生下面的变量给新创建的 Pod 容器：1. REDIS_MASTER_SERVICE_HOST= 10.0.0.11 2. 3. REDIS_MASTER_SERVICE_PORT=6379 4. 5. REDIS_MASTER_PORT=tcp:/10.0.0.11:6379 6. 7. REDIS_MASTER_PORT_6379_TCP=tcp:/ 10.0.0.11 :6379 8. 9. REDIS_MASTER_PORT_6379_TCP_PROTO=tcp 10. 11. REDIS_MASTER_PORT_6379_TCP_PORT=6379 12.
16、 13. REDIS_MASTER_PORT_6379_TCP_ADDR= 14. 15. 10.0.0.11 注意，只有在某个 Service 后创建的 Pod 才会有这个 Service 的环境变量。DNSDNS一个可选的 Kubernetes 附件(强烈建议用户使用)是 DNS 服务。它跟踪集群中 Service 对象，为每个 Service 对象创建 DNS 记录。这样所有的 Pod 就可以通 过 DNS 访问服务了。比 如说我们在 Kubernetes 名字空间“my-ns“中有个叫 my-service 的服务， DNS 服务会创建一条“my-service.my-ns“的 DNS 记录。同在这个命名空间 的 Pod 就可以通过“my-service“来得到这个 Service 分配到的 Cluster IP，在其 它命名空间的 Pod 则可以用全限定名“my-service.my-ns“来获得这个 Service 的地址。PodPod IPIP andand Ser
