k8s(三)走进k8s

k8s(三)走进k8s

普遍意义上实现了容器编排,解决了容器难使用的问题。

作者:lomtom

个人网站:lomtom.cn

个人公众号:博思奥园

你的支持就是我最大的动力。

k8s系列:

  1. k8s(一)走进docker
  2. k8s(二)Docker的HelloWorld
  3. k8s(三)走进k8s
  4. k8s(四)安装k8s集群
  5. k8s(五)k8s的HelloWorld
  6. k8s(六)走进Pod

本节主要是提及一些k8s的相关概念,当然也会涉及到k8s的一些相关命令,暂时无需自己去敲这些命令,安装k8s集群,会在下一节中讲解,那时候再去体验这些命令也不迟。

K8s诞生

如果想要将Docker应用于具体的业务实现,是存在困难的——编排、管理和调度等各个方面,都不容易。于是,人们迫切需要一套管理系统,对Docker及容器进行更高级更灵活的管理。

就在这个时候,K8S出现了。

K8S,就是基于容器的集群管理平台,它的全称,是kubernetes。

至于他为什么叫K8s,那是因为从k到s之间刚好有8个字母(就是这么随意)。

功能:为容器化的 应用提供了资源调度、部署运行、服务发现、扩容及缩容等一整套功能

K8s集群

对于应用系统的架构,一般可以分为:

  1. 有中心架构,通常为一个管理节点和多个工作节点(或者数据节点),例如HDFS。
  2. 无中心架构,所有的节点皆为同等的伙伴关系,例如Redis集群。

而一个K8S系统,通常称为一个K8S集群(Cluster),他是属于有中心架构模式。

  • 一个Master节点(主节点):Master节点主要还是负责管理和控制
  • 多个Node节点(工作节点):Node节点是工作负载节点,里面是具体的容器

使用kubectl get node 来查看节点情况。

1
2
3
4
5
[root@master-1 ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
master-1 Ready master 72d v1.17.11
slave-1 Ready <none> 72d v1.17.11
slave-2 Ready <none> 72d v1.17.11

Master

Kubernetes里的Master指的是集群控制节点,在每个Kubernetes集群 里都需要有一个Master来负责整个集群的管理和控制,基本上 Kubernetes的所有控制命令都发给它,它负责具体的执行过程,我们后 面执行的所有命令基本都是在Master上运行的。

Master通常会占据一个 独立的服务器(高可用部署建议用3台服务器),主要原因是它太重要 了,是整个集群的“首脑”,如果它宕机或者不可用,那么对集群内容器 应用的管理都将失效。

Master节点包括API Server、Scheduler、Controller manager、etcd。

  • API Server是整个系统的对外接口,供客户端和其它组件调用,相当于“营业厅”,即集群的入口及出口。
    • 包括认证、授权、准入等功能;
    • 还包括对etcl的数据缓存;
    • 建立其他模块与etcl的通信枢纽。
  • Scheduler负责对集群内部的资源进行调度,相当于“调度室”。调度过程:
    • Predict:过滤掉不符合业务需求的节点。
    • Priority:按照满足需求的情况下,选择最佳节点。
    • Bind:将工作节点与pod绑定,完成调度
  • Controller manager负责管理控制器,相当于“大总管”。
  • etcd:etcd的官方将它定位成一个可信赖的分布式键值(key,value)存储服务,它能够为整个分布式集群存储一些关键数据,协助分布式集群的正常运转
1
2
3
4
5
6
7
8
9
[root@master ~]# kubectl get pod -A -o wide |grep  master
kube-system coredns-6d8c4cb4d-2fbpp 1/1 Running 0 2d21h 10.244.0.3 master
kube-system coredns-6d8c4cb4d-g8jzg 1/1 Running 0 2d21h 10.244.0.2 master
kube-system etcd-master 1/1 Running 1 (2d21h ago) 2d21h 8.16.0.67 master
kube-system kube-apiserver-master 1/1 Running 1 (2d21h ago) 2d21h 8.16.0.67 master
kube-system kube-controller-manager-master 1/1 Running 2 (29h ago) 2d21h 8.16.0.67 master
kube-system kube-flannel-ds-7gm8n 1/1 Running 0 2d21h 8.16.0.67 master
kube-system kube-proxy-tdz44 1/1 Running 0 2d21h 8.16.0.67 master
kube-system kube-scheduler-master 1/1 Running 2 (29h ago) 2d21h 8.16.0.67 master

Node

Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns(可选),还有就是Pod

Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程,它内部封装了一个或多个紧密相关的容器。除了Pod之外,K8S还有一个Service的概念,一个Service可以看作一组提供相同服务的Pod的对外访问接口。

  • Docker,Docker引擎,负责本机的容器创建 和管理工作。
  • Kubelet,主要负责监视指派到它所在Node上的Pod,包括创建、修改、监控、删除等。
  • Kube-proxy,主要负责为Pod对象提供代理。
  • Fluentd,主要负责日志收集、存储与查询。

Namespace

Namespace(命名空间)是资源隔离的基本单位,K8s将集群内部的资源分配到不同的Namespace下。

Kubernetes集群在启动后会创建一个名为default的Namespace,通过 kubectl可以查看:kubectl get namespaces

1
2
3
4
5
6
[root@master ~]# kubectl get ns
NAME STATUS AGE
default Active 39d
kube-node-lease Active 39d
kube-public Active 39d
kube-system Active 39d

在使用kubectl命令查看k8s资源时都需要带上-n参数来指定命名空间,不指定时将是默认的命名空间。

Pod

Kubernetes 官网

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元

Pod 是一组(一个或多个) 容器; 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置(colocated)的并且一同调度,在共享的上下文中运行。 Pod 所建模的是特定于应用的“逻辑主机”,其中包含一个或多个应用容器, 这些容器是相对紧密的耦合在一起的。 在非云环境中,在相同的物理机或虚拟机上运行的应用类似于 在同一逻辑主机上运行的云应用。

Kubernetes为每个Pod都分配了唯一的IP地址,称之为Pod IP,一个 Pod里的多个容器共享Pod IP地址。

根据Pod在集群中的存储位置可以分为两种类型:

  1. 普通的Pod
  2. 静态Pod(Static Pod)。

后者比 较特殊,它并没被存放在Kubernetes的etcd存储里,而是被存放在某个 具体的Node上的一个具体文件中,并且只在此Node上启动、运行。

而 普通的Pod一旦被创建,就会被放入etcd中存储,随后会被Kubernetes Master调度到某个具体的Node上并进行绑定(Binding),随后该Pod被 对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。在 默认情况下,当Pod里的某个容器停止时,Kubernetes会自动检测到这个 问题并且重新启动这个Pod(重启Pod里的所有容器),如果Pod所在的 Node宕机,就会将这个Node上的所有Pod重新调度到其他节点上。

同样,根据pod的数据是否是持久化可以分为有状态的和无状态的。

  • 有状态:会持久化数据到永久存储中,可以存储在集群的存储中,也可以外挂硬盘来进行存储,例如Mysql服务器。

  • 无状态:无状态服务不会在本地存储持久化数据,比如web应用。

    1)deployment认为所有的pod都是一样的
    2)不用考虑顺序的要求
    3)不用考虑在哪个node节点上运行
    4)可以随意扩容和缩容

那么在k8s中怎么获取pod的信息呢?

使用kubectl get pod 即可获取pod的状态信息。

1
2
3
4
5
[root@master-1 ~]# kubectl get pod 
NAME READY STATUS RESTARTS AGE
pod1 0/1 Completed 0 3d
pod2 1/1 Running 0 2d
pod3 0/1 CrashLoopBackOff 5000 2d

工作负载

Kubernetes 官网

工作负载是在 Kubernetes 上运行的应用程序(相当于数据库、后端等所有组在一起能够提供完整功能的应用)。

无论你的负载是单一组件还是由多个一同工作的组件构成,在 Kubernetes 中你 可以在一组 Pods 中运行它。 在 Kubernetes 中,Pod 代表的是集群上处于运行状态的一组 容器

Kubernetes Pods 有确定的生命周期。 例如,当某 Pod 在你的集群中运行时,Pod 运行所在的 节点 出现致命错误时, 所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态: 即使该节点后来恢复正常运行,你也需要创建新的 Pod 来恢复应用。

不过,为了让用户的日子略微好过一些,你并不需要直接管理每个 Pod。 相反,你可以使用 负载资源 来替你管理一组 Pods。 这些资源配置 控制器 来确保合适类型的、处于运行状态的 Pod 个数是正确的,与你所指定的状态相一致。

容器、pods、工作负载关系

为什么Kubernetes会设计出一个全新的Pod的概念并且Pod有这样特 殊的组成结构?

  • 原因之一:在一组容器作为一个单元的情况下,我们难以简单地 对“整体”进行判断及有效地行动。比如,一个容器死亡了,此时算是整 体死亡么?是N/M的死亡率么?引入业务无关并且不易死亡的Pause容 器作为Pod的根容器,以它的状态代表整个容器组的状态,就简单、巧 妙地解决了这个难题。

  • 原因之二:Pod里的多个业务容器共享Pause容器的IP,共享Pause容 器挂接的Volume,这样既简化了密切关联的业务容器之间的通信问 题,也很好地解决了它们之间的文件共享问题。

Service

在Kubernetes中,Service是分布式集群架构的核心,一个Service对 象拥有如下关键特征。

◎ 拥有唯一指定的名称(比如mysql-server)。

◎ 拥有一个虚拟IP(Cluster IP、Service IP或VIP)和端口号。

◎ 能够提供某种远程服务能力。

◎ 被映射到提供这种服务能力的一组容器应用上。

我们运行的应用(Pod)通常通过Service来进行对外暴露的。

K8S 控制器

在K8s中,我们通常很少的去使用pod的定义文件去生成,而是使用更高级的控制器来管理这些pod。通常有以下控制器。

  1. Replication Controller

    • 机制

      定义了一个RC并将其提交到Kubernetes集群中后,Master上 的Controller Manager组件就得到通知,定期巡检系统中当前存活的目标 Pod,并确保目标Pod实例的数量刚好等于此RC的期望值,如果有过多 的Pod副本在运行,系统就会停掉一些Pod,否则系统会再自动创建一些 Pod。

    • 好处

      可以说,通过RC,Kubernetes实现了用户应用集群的高可用性, 并且大大减少了系统管理员在传统IT环境中需要完成的许多手工运维工 作(如主机监控脚本、应用监控脚本、故障恢复脚本等)。

  2. Replica Set

    在Kubernetes 1.2后引入,Replica Set与RC当前的唯一区别是,Replica Sets支持基于集合的Label selector(Set-based selector),而RC只支持基于等式的Label Selector(equality-based selector),这使得Replica Set的功能更强。

    当前很少单独使用Replica Set,它主要被Deployment这 个更高层的资源对象所使用,从而形成一整套Pod创建、删除、更新的 编排机制。

  3. Deployment

    在Kubernetes 1.2后引入,用于更好地解决Pod的编排问题

    Deployment相对于RC的一个最大升级是我们可以随时知道当前 Pod“部署”的进度。实际上由于一个Pod的创建、调度、绑定节点及在目 标Node上启动对应的容器这一完整过程需要一定的时间,所以我们期待 系统启动N个Pod副本的目标状态,实际上是一个连续变化的“部署过程”导致的最终状态。

    Deployment的典型使用场景有以下几个。

    ◎ 创建一个Deployment对象来生成对应的Replica Set并完成Pod副 本的创建。

    ◎ 检查Deployment的状态来看部署动作是否完成(Pod副本数量 是否达到预期的值)。

    ◎ 更新Deployment以创建新的Pod(比如镜像升级)。

    ◎ 如果当前Deployment不稳定,则回滚到一个早先的Deployment 版本。

    ◎ 暂停Deployment以便于一次性修改多个PodTemplateSpec的配 置项,之后再恢复Deployment,进行新的发布。

    ◎ 扩展Deployment以应对高负载。

    ◎ 查看Deployment的状态,以此作为发布是否成功的指标。

    ◎ 清理不再需要的旧版本ReplicaSets。

  4. StatefulSet

    为了解决:Pod的管理对象RC、Deployment、DaemonSet 和Job都面向无状态的服务,所以引入StatefulSet

    Kubernetes从1.4版本开始引入了PetSet这个新的资源对象,并且在 1.5版本时更名为StatefulSet,StatefulSet从本质上来说,可以看作 Deployment/RC的一个特殊变种。

    特性:

    ◎ StatefulSet里的每个Pod都有稳定、唯一的网络标识,可以用来发现集群内的其他成员。假设StatefulSet的名称为kafka,那么第1个Pod 叫kafka-0,第2个叫kafka-1,以此类推。

    ◎ StatefulSet控制的Pod副本的启停顺序是受控的,操作第n个Pod 时,前n-1个Pod已经是运行且准备好的状态。

    ◎ StatefulSet里的Pod采用稳定的持久化存储卷,通过PV或PVC来实现,删除Pod时默认不会删除与StatefulSet相关的存储卷(为了保证数 据的安全)。

  5. DaemonSet

    守护进程集

  6. Job

    批处理任务

  7. CronJob

k8s的强大之处远比我们想象的还要强大的多

k8s(三)走进k8s

https://lomtom.cn/2ef4a819.html

作者

lomtom

发布于

2022-05-30

更新于

2022-06-27

许可协议