k8s主要概念大梳理!

 小姐姐养的狗02号   2021-06-03 17:37   685 人阅读  0 条评论

image.png


k8s已经成为了绝对热门的技术,一个上点规模的公司,如果不搞k8s,都不好意思出去见人。安装k8s要突破种种网络阻碍,但更大的阻碍还在后面...

我发现,很多k8s的文章,根本不说人话,包括那要命的官网。

要弄明白k8s的细节,需要知道k8s是个什么东西。它的主要功能,就是容器的调度--也就是把部署实例,根据整体资源的使用状况,部署到任何地方。先不要扯别的,那会扰乱视线,增加复杂性。

注意任何这两个字,预示着你并不能够通过常规的IP、端口方式访问部署的实例。复杂性由此而生。

我们学k8s,就要看它要调度哪些资源。以传统的感觉来看,无非就是cpu内存网络io等。在了解怎么对这些资源调度之前,先要搞懂什么叫Pod,这可是k8s的核心概念之一。

搞不懂Pod,就没法玩k8s。

本文的脑图,可以在这里在线查看:http://mind.xjjdog.cn/mind/cloud-k8s

1. Pod

pod是k8s调度的最小单元,包含一个或者多个容器(这里的容器你可以暂时认为是docker)。

Pod拥有一个唯一的IP地址,在包含多个容器的时候,依然是拥有一个IP地址,它是怎么办到的呢?

xjjdog之前写过两篇Docker原理的文章,指出其中两个使用到的底层技术,就是namespacecgroup,k8s在使用多个容器的时候,用到的就是共享namespace,这样Pod里的容器就可以通过localhost通信了,就像两个进程一样。同理的,Pod 可以挂载多个共享的存储卷(Volume),这时内部的各个容器就可以访问共享的 Volume 进行数据的读写。

image.png


一些边车(Sidecar),以及存活探针等,也是以容器的形式,存在于Pod中的。所以Pod是一个大杂烩,它取代了docker容器的一部分工作(这既是Pause容器的职责),比如创建一些共享的net namespace等。

那如何表示、声明一个Pod呢?又如何指定这些容器与Pod的关系呢?k8s选用了yaml这种配置方式,初衷是避免过度的API设计。

很好,这又引入了另外一个问题,那就是yml文件的膨胀。所有的k8s运维,都有过被yml文件给支配的恐惧。

没有银弹,只不过把问题转移到另外一个场景罢了。

声明一个Pod,就是写yml文件。一个Pod的yml样例,可能长得像下面这样。

apiVersion: v1           #本版号
kind: Service            #创建的资源类型
metadata:                #元数据必选
  namespace: bcmall      #绑定命名空间
  name: bcmall-srv       #Service资源名称
spec:                    #定义详细信息
  type: NodePort         #类型
  selector:              #标签选择器
    app: container-bcmall-pod 
  ports:                 #定义端口
    - port: 8080         #port 指定server端口,此端口用于集群内部访问
      targetPort: 80     #绑定pod端口
      nodePort: 14000    #将server 端口映射到Node节点的端口,用于外网访问
      protocol: TCP      #端口协议

注意kind这个选项,这将是k8s概念膨胀的噩梦!k8s的各种配置,基本上都是围着这里转。哦对了,要让这些yml文件生效,你需要用到kubectl 命令,就像这样。

kubectl create -f ./bcmall.yaml

访问一个Pod,可以通过它的IP,也可以通过内部的域名(这时候就需要CoreDNS)。当这么用的时候,其实Pod的表现,就相当于一台普通的机器,里面的容器就是一堆进程而已。

2. 探针和钩子

一个Pod被调度之后,就要进行初始化。初始化肯定是得有一个反馈的,否则都不知道最终有没有启动成功。这些健康检查的功能,叫做探针(Probe),一个比较怪异的英文名词。

常见的有livenessProbe、readinessProbe、startupProbe等三种探针。

livenessProbe有点像心跳,如果判定不在线了,就会把它干掉;readinessProbe一般表示就绪状态,也比较像心跳,证明你的服务在正常跑着;startupProbe用于判断容器是否已经启动好,避免一些超时等,比如你的JVM启动完毕了,才能对外提供服务。

image.png


一般,花费120s startupProbe的启动实践,每隔5s检测一下livenessProbe,每隔10s检测一下readinessProbe,是常用的操作。

这些信息,也是在yml中配置的,具体的配置层次如何,这里不罗嗦,您就查文档去吧。

再说一下钩子(Hook)。主要有PostStartPreStop两种。PostStart 可以在容器启动之后就执行,PreStop 则在容器被终止之前被执行。这没什么神奇的,就是执行一些shell脚本而已,只不过比较常用,就提升到了关键字的级别。


我们来看看它长什么样子。由于这些配置文件大同小异,后面就不再贴这样的代码了。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5


3. 高可用引起的名词爆炸

上面说到,yaml的复杂性,是由于kind的种类多所引起的。首先我们要接触的,就是ReplicaSet

我们需要多个副本,才能做高可用。

原因很简单,一个Pod就相当于一台机器,当掉之后,就无法提供服务了,这是哪门子的高可用?所以对等的Pod,要有多份才行。

ReplicaSet简称RS,可以让你的Pod数量一直保持在某个水平。但它在操作起来还是有点麻烦了,所以一般使用更加高级的Deployment。Deployment可以实现一些滚动升级的需求,但前提是你需要在spec.template.metadata.labels中设置了相应的键值对。

k8s的一些过滤工作,都是通过labels来实现的。这其实是一种非常折衷的做法,因为它本身并没有做一些类似于sql查询之类的工作,就只能在这一堆map的键值对上做文章。比如这样:

kubectl get pod -n demo -l app=nginx,version=v1

是不是很魔幻的写法?不要紧,习惯了就好了。

这些yml配置,通常都是一环套一环的,还会有交叉引用,所以也会有优先级。高阶的kind会直接顺带把低阶的kind一起创建了,属于一个级联关系。

一切不过是yml文件包了一层而已。

好了,我们要接触下一个kind:service了。

为什么需要Service?因为我们上面创建的Pod,哪怕是Deployment创建的Pod,你访问它都要费些功夫。虽然Pod有IP,但如果它重启了,或者销毁了,IP就会动态变化。因为Pod是被调度的,它并不知道自己会被调度到哪一台机器。

Service这个东西,就是要提供一种非IP的访问途径,使得不论Pod在哪里,我们都能访问的到它。

如图所示,通过Labels的过滤,可以把多个Pod归结为一类,然后以某种类型对外暴露服务。Service说白了也是一个组合后的东西。

image.png


对外访问的类型,这里要着重说明一下,因为它重要,所以要敲黑板。主要有4种:

  • ClusterIP 创建一个虚拟的IP,唯一且不可修改。所有访问该IP的请求,都将被iptables转发到后端。这是默认的行为,就是一个coredns的插件
  • NodePort 提供一个静态端口(NodePort)来暴露服务,主要使用的技术是NAT
  • LoadBalancer  LoadBalancer主要用于做外部的服务发现,即暴露给集群外部的访问
  • ExternalName 使用较少,感兴趣的可以自行了解

但是等等。k8s是如何实现跨主机的Pod相互访问的呢?

在单个Node上的Pod相互访问可以理解,直接通过docker0网桥分配的IP,就可相互访问。

那k8s的底层网络是真么设置的呢?答案可能令人沮丧。k8s本身并不负责网络管理,也不为容器提供具体的网络设置,它是通过CNI(容器网络接口)来实现的。在不同的Node之上,不同的Pod访问就费了点劲,这正是CNI的工作。常用的CNI插件有:Flannel、Calico、Canal、Weave。

没错,又是一堆名词,而且各个都很难搞。

网络方面是k8s最复杂的知识点,框架也奇多,后面的文章会专门进行介绍。

4. 内部组件

在开启更多的Kind之前,我们来看一下k8s的内部组件。

下面这张图,就是官网的一张图片,说明了k8s的一系列必要的组件。其中,etcd根本就不是这个体系里的,但k8s的一些持久化状态,需要有个地方存,就引入了这么一个组件,用来存储配置信息。

image.png

其中左半部分,是k8s自身的组件;右半部分,就在每个Node(也就是物理机)上的守护进程。它们的作用如下:

  • kube-apiserver 提供Rest接口,属于k8s的灵魂,所有的认证、授权、访问控制、服务发现等功能,都通过它来暴露
  • kube-scheduler 一看就是个调度组件,实际上它的作用也是这样。它会监听未调度的 Pod,实现你指定的目标
  • kube-controller-manager 负责维护整个k8s集群的状态。注意是k8s集群的状态,它不管Pod
  • kubelet  这是个守护进程,用来和apiserver通信,汇报自己Node的状态;一些调度命令,也是通过kubelet来接收执行任务
  • kube-proxy kube-proxy其实就是管理service的访问入口,包括集群内Pod到Service的访问和集群外访问service。我们上面提到的四种模式,就是通过proxy进行转发的

这些组件的职责,已经是非常非常清楚了。难点还是在多种Kind概念上。

5. 更多概念

image.png


图中的这些概念,本质上都是在Pod之上,又包了一层。层次越高,功能越抽象,依赖的配置也越多。下面将挑主要的进行介绍。

  • StatefulSet Deployment部署后的实例,它的id都是随机的,比如bcmall-deployment-5d45f98bd9,它是无状态的。与此对用的是StatefulSet,生成的实例名称是类似bcmall-deployment-1这样的。它具备固定的网络标记,比如主机名,域名等,可以按照顺序来部署和扩展,非常适合类似MySQL这样的实例部署
  • DaemonSet 用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统级后台任务
  • configMap和Secret 顾名思义,就是做配置用的,因为容器或多或少会需要外部传入一些环境变量。可以用来实现业务配置的统一管理, 允许将配置文件与镜像文件分离,以使容器化的应用程序具有可移植性
  • PV和PVC  业务运行就需要存储,可以通过PV进行定义。PV的生命周期独立于Pod的生命周期,就是一段网络存储;PVC是用户对于存储的需求:Pod消耗节点资源,PVC消耗PV资源,PVC和PV是一一对应的。没错,它们都是通过yml文件声明的
  • **StorageClass ** 可以实现动态PV,是更进一步的封装
  • Job 只要完成就立即退出,不需要重启或重建
  • Cronjob 周期性任务控制,不需要持续后台运行
  • CRD


6. 资源限制

很好,我们终于要聊一点资源限制方面的内容了。k8s的资源限制,仍然是通过cgroup来实现的。

k8s提供了requestslimits 两种类型参数对资源进行预分配和使用限制。

不要被这两个词给迷惑了。requests就相当于JVM参数中的-Xms,limits就相当于-Xmx。所以,如果你类比着把这两个值设置成一样的,是一种最佳的实践方式。

只是它的设置有点怪异:

requests:
 memory: "64Mi"
 cpu: "250m"
limits:
 memory: "128Mi"
 cpu: "500m"

内存的单位是Mi,而cpu的单位是m,要多别扭有多别扭,但它是有原因的。

m毫核的意思。比如,我们的操作系统有4核,把它乘以1000,那就是总CPU资源是4000毫核。如果你想要你的应用最多占用1/4核,那就设置成250m

再来看内存,Mi是MiB的意思,我也搞不懂为啥不用MB,而使用Mi,可能是想让你印象深刻吧(MB和MiB还真不一样)。

若内存使用超出限制,会引发系统的OOM机制,但CPU不会,顶多会影响系统运行罢了。

k8s还提供了叫做LimitRangeResourceQuota的Kind,用来限定CPU和Memory的申请范围,功能更加高级。

7. 集群搭建工具

image.png


k8s的集群搭建,常见的有kind,minikube,kubeadm,rancher2等。其中rancher2可以说是相对来说比较容易的方式。它考虑了一些网络不通的因素,有一些推荐的代理选项,对于新手来说,拿来尝尝鲜还是很好用的。

但在正常的使用中,还是推荐你使用kubeadm这个工具,这是官方维护和推荐的搭建工具,并做到了向下兼容,按照官方的指引,只需要kubeadm init就能搭建完毕。至于什么监控、日志等,反倒是好处理的了。

k8s最麻烦的有三点:

  • yml文件概念爆炸
  • 网络方案多样、复杂
  • 权限、证书配置繁琐

搞懂了这三个方面,可以说玩转k8s就没问题了。

image.png



本文地址:https://dockerchina.cn/?id=137
温馨提示:文章内容系作者个人观点,不代表Docker中文社区对观点赞同或支持。
版权声明:本文为转载文章,来源于 小姐姐养的狗02号 ,版权归原作者所有,欢迎分享本文,转载请保留出处!

 发表评论


表情

还没有留言,还不快点抢沙发?