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 来查看节点情况。

[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）存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转
[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

[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的状态信息。

[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的强大之处远比我们想象的还要强大的多

lomtom

标题：k8s（三）走进k8s

作者：lomtom

链接：https://lomtom.cn/2ef4a819

K8s诞生
K8s集群
Master
Node
Namespace
Pod
工作负载
Service
K8S 控制器

Similar Posts

CKA（一）注意

CKA（一）注意

CKA（二）题库一

CKA（二）题库一