接着上一篇继续部署应用到 K8S中
之前简单部署的简单集群,三个工作节点是运行在 docker 和 kubelet 的,还有一个是控制节点
之前有提到 ReplicationController , pod 和 服务是如何组合在一起的呢?
可以通过这张如图来解释一下
我们之前创建 pod 的时候不是直接创建的,是通过 docker run 来创建的一个 replicationController ,然后基于 rc 来创建的一个 pod 实例
为了让 pod 能够被外部访问到,所以我们需要让 K8S 将 replicationController 管理的所有 pod 由一个服务对外暴露,因此有了 kubia-http
通过上面的案例,我们应该知道 ReplicationController实际上是用于复制 pod 的,通过 ReplicationController 来创建多个 pod 副本
ReplicationController 始终确保存在一个运行中的 pod 实例
如果我们上面创建的 pod 消失了,那么 ReplicationController 将会创建一个新的 pod 来替换消失的 pod
再来看看 service ,也就是上面 kubia-http 服务
为什么需要服务,有了 pod ,还拿 service 干啥?
通过上面的 ReplicationController 我们知道,pod 消失之后, ReplicationController 会再创建一个新的将其替换
那么我们也知道,每一个 pod 都有自己的独立的主机名和 IP
pod 在环境中会因为任何原因直接挂掉和消失,然后又被新的 pod 替换,这个时候 pod 的 IP 变化了,外部如何正确访问到我们的服务呢?
这个时候就需要 service 了
当一个 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 即提供服务即可
今天就到这里,学习所得,若有偏差,还请斧正
朋友们,你的支持和鼓励,是我坚持分享,提高质量的动力
好了,本次就到这里
技术是开放的,我们的心态,更应是开放的。拥抱变化,向阳而生,努力向前行。
我是阿兵云原生,欢迎点赞关注收藏,下次见~
更多的可以查看 零声每晚八点直播:https://ke.qq.com/course/417774