共计 1665 个字符，预计需要花费 5 分钟才能阅读完成。
接着上一篇持续部署利用到 K8S 中
之前简略部署的简略集群，三个工作节点是运行在 docker 和 kubelet 的，还有一个是管制节点
ReplicationController，pod 和 service 本次关系
之前有 提到 ReplicationController，pod 和 服务 是如何组合在一起的呢？
能够通过这张如图来解释一下
咱们之前创立 pod 的时候不是间接创立的，是通过 docker run 来创立的一个 replicationController，而后基于 rc 来创立的一个 pod 实例
为了让 pod 可能被内部拜访到，所以咱们须要让 K8S 将 replicationController 治理的所有 pod 由一个服务对外裸露，因而有了 kubia-http
- 服务是有对外裸露 IP 的，申请打到 service 上
- service 将申请转到 pod 下面的 9999 端口上，而后 pod 提供服务
ReplicationController 角色是啥样的
通过下面的案例，咱们应该晓得 ReplicationController 实际上是用于复制 pod 的，通过 ReplicationController 来创立多个 pod 正本
ReplicationController 始终确保存在一个运行中的 pod 实例
如果咱们下面创立的 pod 隐没了，那么 ReplicationController 将会创立一个新的 pod 来替换隐没的 pod
为什么须要 service
再来看看 service，也就是下面 kubia-http 服务
为什么须要服务，有了 pod，还拿 service 干啥？
通过下面的 ReplicationController 咱们晓得，pod 隐没之后，ReplicationController 会再创立一个新的将其替换
那么咱们也晓得，每一个 pod 都有本人的独立的主机名和 IP
pod 在环境中会因为任何起因间接挂掉和隐没，而后又被新的 pod 替换，这个时候 pod 的 IP 变动了，内部如何正确拜访到咱们的服务呢？
这个时候就须要 service 了
- service 能够解决一直变动的 pod IP 问题
- service 能够在一个固定 IP 和端口上对外裸露多个 pod
当一个 service 被创立的时候，会失去一个动态的 IP，在 service 整个生命周期中，它的 IP 是不会变的
客户端只须要通过这个固定 IP 连贯服务即可，服务会将申请转到 外部其中一个 pod，客户端不须要关怀 pod 在哪里，只须要关系 service 在哪里即可
减少正本数量
以后的零碎外面只有的一个正本，当初咱们能够减少到 3 个正本
咱们能够通过指令 kubectl get replicationcontrollers 来查看以后的正本数
能够通过 kubectl scale rc mykubia --replicas=3，来将正本数调整至 3 个
- 咱们执行下面这个指令，只是通知 K8S 零碎中冀望的正本数量，并没有通知 K8S 须要如何去操作，如何去实现
- K8S 本身会去查看以后的状态是否和冀望的状态统一，如果不统一就会进行调整，这个是 K8S 中根本的准则之一
咱们用到的指令中，好多都是 kubectl get xxx 的，就是获取对应的 pod，service，rc 等等信息的
其实咱们也能够间接执行 kubectl get，这样能够列出所有可能类型的对象，还可能显示缩写
最新的零碎状态
通过执行上述的指令，零碎中将 1 个正本，调整成了 3 个正本
这就是 K8S 能够轻易的做到程度伸缩，咱们要裁减正本的时候，再也不须要手动的去装置和运行其余正本了，只用执行指令，批改冀望数量即可
当然，咱们放进 pod 的服务，也须要做成无状态，可横向扩大的，这样能力更好的应用 K8S 的能力
这样子的话，最新的零碎应该是这个样子的
内部申请打到 service 下面，service 会将申请给到 任意一个 pod，对应的 pod 即提供服务即可
明天就到这里，学习所得，若有偏差，还请斧正
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是 阿兵云原生，欢送点赞关注珍藏，下次见~
