K8S核心组件

K8s 组件

  • K8s 是用来管理容器，但是不直接操作容器，最小操作单元是 Pod （间接管理容器）。
  • 一个 Master 有一群 Node 节点与之对应
  • Master 节点不存储容器，只负责调度、网管、控制器、资源对象存储
  • 容器的存储在 Node 节点，容器是存储在 Pod 内部的）
  • Pod 内部可以有一个容器，或者多个容器
  • Kubelet 负责本地 Pod 的维护
  • Kube-proxy 负责负载均衡，在多个 Pod 之间来做负载均衡

Pod 是什么？

  • Pod 也是一个容器，这个容器中装的是 Docker 创建的容器，Pod 用来封装容器的一个容器，Pod 是一个虚拟化分组；
  • Pod 相当于独立主机，可以封装一个或者多个容器。

Pod 有自己的 IP 地址、主机名，相当于一台独立沙箱环境。
Pod 到底用来干什么？
通常情况下，在服务部署时候，使用 Pod 来管理一组相关的服务。一个 Pod 中要么部署一个服务，要么部署一组有关系的服务。
一组相关的服务是指：在链式调用的调用连路上的服务。
Web 服务集群如何实现？
实现服务集群：只需要复制多方 Pod 的副本即可，这也是 K8s 管理的先进之处，K8s 如果继续扩容，只需要控制 Pod 的数量即可，缩容道理类似。
Pod 底层网络，数据存储是如何进行的？

  • Pod 内部容器创建之前，必须先创建 Pause 容器；
  • 服务容器之间访问 localhost ，相当于访问本地服务一样，性能非常高。

ReplicaSet 副本控制器
控制 Pod 副本「服务集群」的数量，永远与预期设定的数量保持一致即可。当有 Pod 服务宕机时候，副本控制器将会立马重新创建一个新的 Pod，永远保证副本为设置数量。
副本控制器：标签选择器-选择维护一组相关的服务（它自己的服务）。

  • 1 selector：
  • 2 app = web
  • 3 Release = stable
  • ReplicationController 副本控制器：单选
  • ReplicaSet 副本控制器：单选，复合选择

在新版的 K8s 中，建议使用 ReplicaSet 作为副本控制器，ReplicationController 不再使用了。
Deployment 部署对象

  • 服务部署结构模型
  • 滚动更新

ReplicaSet 副本控制器控制 Pod 副本的数量。但是，项目的需求在不断迭代、不断的更新，项目版本将会不停的的发版。版本的变化，如何做到服务更新？
部署模型：

  • ReplicaSet 不支持滚动更新，Deployment 对象支持滚动更新，通常和 ReplicaSet 一起使用；
  • Deployment 管理 ReplicaSet，RS 重新建立新的 RS，创建新的 Pod。

MySQL 使用容器化部署，存在什么样的问题？

  • 容器是生命周期的，一旦宕机，数据丢失
  • Pod 部署，Pod 有生命周期，数据丢失

对于 K8s 来说，不能使用 Deployment 部署有状态服务。
通常情况下，Deployment 被用来部署无状态服务，那么对于有状态服务的部署，使用 StatefulSet 进行有状态服务的部署。
什么是有状态服务？
有实时的数据需要存储
有状态服务集群中，把某一个服务抽离出去，一段时间后再加入机器网络，如果集群网络无法使用
什么是无状态服务？

  • 没有实时的数据需要存储
  • 无状态服务集群中，把某一个服务抽离出去，一段时间后再加入机器网络，对集群服务没有任何影响

StatefulSet

  • 为了解决有状态服务使用容器化部署的一个问题。
  • 部署模型
  • 有状态服务

StatefulSet 保证 Pod 重新建立后，Hostname 不会发生变化，Pod 就可以通过 Hostname 来关联数据。

K8s 的服务注册与发现

Pod 的结构是怎样的？

  • Pod 相当于一个容器，Pod 有独立 IP 地址，也有自己的 Hostname，利用 Namespace 进行资源隔离，独立沙箱环境。
  • Pod 内部封装的是容器，可以封装一个，或者多个容器（通常是一组相关的容器）

Pod 网络

  • Pod 有自己独立的 IP 地址
  • Pod 内部容器之间访问采用 Localhost 访问

Pod 内部容器访问是 Localhost，Pod 之间的通信属于远程访问。
Pod 是如何对外提供服务访问的？
Pod 是虚拟的资源对象（进程），没有对应实体（物理机，物理网卡）与之对应，无法直接对外提供服务访问。
那么该如何解决这个问题呢？
Pod 如果想要对外提供服务，必须绑定物理机端口。也就是说在物理机上开启端口，让这个端口和 Pod 的端口进行映射，这样就可以通过物理机进行数据包的转发。
概括来说：先通过物理机 IP + Port 进行访问，再进行数据包转发。
一组相关的 Pod 副本，如何实现访问负载均衡？
我们先明确一个概念，Pod 是一个进程，是有生命周期的。宕机、版本更新，都会创建新的 Pod。这时候 IP 地址会发生变化，Hostname 会发生变化，使用 Nginx 做负载均衡就不太合适了。
所以我们需要依赖 Service 的能力。
Service 如何实现负载均衡？
简单来说，Service 资源对象包括如下三部分：

  • Pod IP：Pod 的 IP 地址
  • Node IP：物理机 IP 地址
  • Cluster IP：虚拟 IP ，是由 K8s 抽象出的 Service 对象，这个 Service 对象就是一个 VIP 的资源对象

Service VIP 更深入原理探讨

  • Service 和 Pod 都是一个进程，Service 也不能对外网提供服务；
  • Service 和 Pod 之间可以直接进行通信，它们的通信属于局域网通信；
  • 把请求交给 Service 后，Service 使用 iptable，ipvs 做数据包的分发。

Service 对象是如何和 Pod 进行关联的？

  • 不同的业务有不同的 Service；
  • Service 和 Pod 通过标签选择器进行关联；
selector：
app=x 选择一组订单的服务 pod ，创建一个 service；
通过 endpoints 存放一组 pod ip；

Service 通过标签选择器选择一组相关的副本，然后创建一个 Service。
Pod 宕机、发布新的版本的时候，Service 如何发现 Pod 已经发生了变化？
每个 Pod 中都有 Kube-Proxy，监听所有 Pod。如果发现 Pod 有变化，就动态更新（etcd 中存储）对应的 IP 映射关系。

 

Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 Controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。换句话说，Pod 是脆弱的，但应用是健壮的。每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时，新 Pod 会分配到新的 IP 地址。
这样就产生了一个问题：如果一组 Pod 对外提供服务（比如 HTTP），它们的 IP 很有可能发生变化，那么客户端如何找到并访问这个服务呢？
K8s 给出的解决方案是 Service。 Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 Label 来挑选。
Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，K8s 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。

posted on 2020-08-07 14:20  小夏coding  阅读(340)  评论(0)  编辑  收藏  举报

导航