K8S入门-概念篇(上)

ronald8个月前职场1770


    认识到K8S的产生背景之后,我们开始进一步了解K8S,基于对K8S里面一些概念的了解之后,我们再去探讨K8S的一些原理:

一. node

    如前所述,K8S是一个容器编排平台,即容器的自动部署、扩展和管理;其最终的落点是把容器调度到一个运行他的节点上,在K8S中这个运行容器的节点就是node,但是需要注意的是,这个节点可以是实际的物理机,也可能是物理机上的虚拟机(实际上大部分云厂商就是这么干的),甚至可以是一个容器,只要运行了K8S集群的数据节点的kubelet和kube-proxy组件就可以,至于kubelet和kube-proxy我们会在后面K8S原理部分进行介绍。

二. pod

    运行容器的节点有了,那么被调度的对象是容器吗?并不是。

    在K8S中,实际调度的单位是Pod,所谓Pod是运行于一个node的若干容器的集合。那么会问了,为什么是Pod,而不是多个容器,或者一个容器运行多个进程?

    首先,实际现网运行过程中,有些进程是需要绑定在一台机器上运行的,比如一个业务进程搭配一个配置更新的进程,需要配置更新进程连接配置中心,以sidecar的形式拉到最新的配置之后,通知业务进程进行更新。

    但是我们又不希望这种绑定关系固化到容器内,以一个容器运行多个进程的形式提供,因为若是这样,容器成为最基本的调度单位,这种情况下当配置更新进程故障的时候,我们不容易对应进程的重启和更新,因为他和业务进程绑定,而容器又是最基本的调度单位,一旦重启会影响现网服务的提供。

    因此,K8S新增了POD概念来解耦这种多进程协同服务场景下,既需要绑定部署又希望单进程故障重启影响收敛的问题。

    那么Pod容器是如何实现网络空间共享的呢?

image-20210913112429997.png


    如图所示,Pod创建时,会首先创建一个infra容器(就是我们在终端看到的pause容器),Pod内其他容器都加入这个infra容器的network namespace,普通容器和infra容器共享IP、端口范围等实现网络共享;而这个infra容器的周期和Pod保持一致。因此,我们有时也可以理解为,所谓Pod就是管理一组容器共享网络、共享存储空间的容器。

三. label

    解决了运行实体和调度的单位的问题之后,k8s通过label机制解决了资源组织和资源之间的匹配问题。这里的资源匹配包括:

        1. node和pod的资源匹配

        2. service和pod的资源匹配

    所谓label机制主要包括三个部分:标签(键值对)、节点选择器和操作符。

    首先是node和pod的资源匹配,我们通过cuda-test选择指定版本显卡的node的实例来结合看一下:

        第一步:我们通过k8s的指令(后面会详细介绍),给名为k8s-node1-p100的节点打上标签accelerator = nvidia-tesla-p100,如下所示:

kubectl label nodes k8s-node1-p100  accelerator = nvidia-tesla-p100

        第二步:在Pod的描述文件中,通过nodeSelector进行指定,表示cuda-test这个pod需要被调度到nvidia-tesla-p100这样的节点上。

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "k8s.gcr.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

    除了通过nodeSelector进行节点选择,K8S还提供了更加强大和丰富的结点亲和性和反亲和性的特性,进行node和pod的匹配,这个在后面高级特性会进行介绍。

    其次是service和pod的资源匹配,所谓service和pod的资源匹配,是指K8S中管理的任意部署单位往往含有多个实例,通过一组相同功能的实例同时对外提供服务的方式来提升服务的承载能力和容灾能力;而通过label,可以帮助k8s实现对一组相同功能和属性的Pod进行组织和管理,集合实例来看:

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

    如上述一个nginx的配置所示,我们的以恶名为label-demo的pod拥有两个标签,即{environment: production}和{app: nginx},而我们在选择pod提供服务的时候可以有两种选择方式:

    一种是基于等式的匹配方式,如下所示:

selector:
  matchLabels:
    environment: production

    即service按照key为environment的标签进行匹配,选择值为production的Pod;

    一种是基于集合的匹配方式,如下所示:

selector:
  matchExpressions:
    - {key: environment, operator: In, values: [production]}

    即K8S按照key为environment的标签进行匹配,值在values集合里面的pod都可以被选中



三. service

    service用于在集群内向其他节点进行服务暴露;如前所述,K8S通过一组功能相同的Pod支持服务以提升服务的承载能力和容灾能力,但是对于客户端来说对任一服务管理一组IP成本更高,且Pod是非常驻实体,一旦被重新调度,Pod的IP就会改变;在系统设计中不应该让客户端去感知这种节点的变化,所以K8S结构中提供了service这种机制提供了服务的统一入口。

    那么service是如何获取后端指定服务的Pod IP列表并进行流量分发的呢?

    以iptables机制为例,在K8S集群中,所有工作节点都通过API-Server订阅集群的状态信息,当有新的Pod上线之后,会向集群执行注册;API-server会将上线信息发布到各个工作节点,工作节点本地kube-proxy收到这个信息之后会修改本节点iptables的转发规则;因此本质上service的ip并不事实存在于集群中,只是一个iptables的一个转发规则,并且这个ip是ping不通的。

image-20210914095721342.png


    但是由于iptables本质上是一个转发规则,在做负载均衡时灵活度一般,且随着集群规模的增大,效率上相对较低,后面版本的K8S service支持基于ipvs的流量转发。相比于iptables,ipvs提供了更丰富的后端路由选项,且底层数据结构是哈希表,意味着查找性能更高。

标签: K8S

相关文章

K8S入门-概念篇(下)

K8S入门-概念篇(下)

一. volume    volume解决的是pod上不同容器之间共享文件的问题和容器文件持久化的问题;K8S提供了以下几类volume:1. hostPath    hostPath是一种通过pod所在node上的文件系统指定的文件或者目录实现文件共享,如下所示,先在Pod内定义一个volume,类型定义为hostP...

K8S背景

    在深入了解K8S之前,我们先了解一下K8S产生的背景,看下是为了解决怎样的问题一步步衍生出K8S这样一套系统。一. 微服务化    随着需求的发展,单体应用的复杂度越来越高,大大增加了系统现网的运维成本,主要包括以下几个方面。    1. 模块耦合度提升,维护成本高&nb...

K8S入门-原理篇

K8S入门-原理篇

一. K8S总体架构及组件功能    K8S总体架构图如下所示:    在K8S中,整个集群划分为控制节点和工作节点,其中控制节点分为:    ·ETCD        一个分布式的数据库,用于存储集...

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。