Kubernetes 如何打赢容器之战？

当我们创建好 Deployment 的时候，Kubernetes 会自动创建 Pod 来承载应用实例。Pod 是一个抽象的概念，像一个“逻辑主机”，它代表一组应用容器的集合，这些应用容器共享资源，包括存储，网络和相同的内部集群 IP。

任何一个 Pod 都需要跑在一个 Node 节点上。Node 是一个“虚拟机器”，它可以是虚拟机也可以是物理机，一个 Node 可以有多个 Pods，Kubernetes 会自动调度 Pod 到合适的 Node 上。

Service 与 LabelSelector

Pods 终有一死，也就是说 Pods 也有自己的生命周期，当一个 Pod 挂了的时候，ReplicaSet 会创建新的，并且调度到合适的 Node 节点上。考虑下访问的问题，Pod 替换伴随着 IP 的变化，对于访问者来说，变化的 IP 是合理的;并且当有多个 Pod 节点时，如何 SLB 访问也是个问题，Service 就是为了解决这些问题的。

Service 是一个抽象的概念，它定义了一组逻辑 Pods，并且提供访问它们的策略。和其他对象一样，Service 也能通过 kubectl 或者 YAML 创建。Service 定义的 Pod 可以写在 LabelSelector 选项中(下文会介绍)，也存在不指定 Pods 的情况，这种比较复杂，感兴趣的读者可以自行查阅资料。

Service 有以下几种类型：

• ClusterIP(默认)：在集群中内部IP上暴露服务，此类型使Service只能从群集中访问;
• NodePort：通过每个 Node 上的 IP 和静态端口(NodePort)暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 :，可以从集群的外部访问一个 NodePort 服务;
• LoadBalancer：使用云提供商的负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务;
• ExternalName：通过返回 CNAME 和它的值，(适用于外部 DNS 的场景)

Labels 和 Selectors 能够让 Kubernetes 拥有逻辑运算的能力，有点像 SQL。举个例子：可以查找 app=hello_word 的所有对象，也可以查找 app in (a,b,c) abc的所有对象。

Labels是一个绑定在对象上的 K/V 结构，它可以在创建或者之后的时候的定义，在任何时候都可以改变。

扩容应用

前文提到我们可以使用 Deployment 增加实例个数，下图是原始的集群状态：

我们可以随意的更改 replicas (实例个数)来扩容，当我们更改了 Deployment 中的 replicas 值时，Kubernetes 会自动帮我们达到想要的目标实例个数，如下图

更新应用

更新应用和扩容类似，我们可以更改 Deployment 中的容器镜像，然后 Kubernetes 会帮住我们应用更新(蓝绿、金丝雀等方式)，通过此功能，我们还可以实现切换应用环境、回滚、不停机 CI/CD。下面是部署的过程，需要注意的是我们可以指定新创建的 Pod 最大个数和不可用 Pod 最大个数：

总结

到了最后，大家对 Kubernetes 有个大概的了解了，但 Kubernetes 远远不止本文所介绍的这些内容。在云原生概念逐渐清晰的今天，Kubernetes 作为 CNCF 中一个接地气的落地项目，其重要性不言而喻。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!