Kubernetes

• Kubernetes主要由以下几个核心组件组成：

  • etcd：保存了整个集群的状态；
  • apiserver：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
  • controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
  • scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
  • kubelet：负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
  • Container runtime：负责镜像管理以及Pod和容器的真正运行（CRI）；
  • kube-proxy：负责为Service提供cluster内部的服务发现和负载均衡；

• 除了核心组件，还有一些推荐的Add-ons：

  • kube-dns负责为整个集群提供DNS服务
  • Ingress Controller为服务提供外网入口
  • Heapster提供资源监控
  • Dashboard提供GUI
  • Federation提供跨可用区的集群
  • Fluentd-elasticsearch提供集群日志采集、存储与查询

Pod

Pod 概述

• Pod 是 k8s 系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在 k8s 上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展 Pod 对象功能的，比如控制器对象是用来管控 Pod 对象的，Service 或者Ingress 资源对象是用来暴露 Pod 引用对象的，PersistentVolume 资源对象是用来为Pod提供存储等等，k8s 不会直接处理容器，而是 Pod，Pod 是由一个或多个container 组成。
• Pod 是 Kubernetes 的最重要概念，每一个 Pod 都有一个特殊的被称为”根容器“的Pause容器。Pause 容器对应的镜像属于 Kubernetes 平台的一部分，除了Pause 容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

Pod 的分类

普通 Pod

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

静态 Pod

• 静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod,它们不能通过API Server进行管理，无法与 ReplicationController、Deployment 或 DaemonSet 进行关联，并且kubelet 也无法对它们进行健康检查。

Pod 生命周期和重启策略

Pod 的状态

2515f0ff002849098babb4e5f417fd19.png

Pod 重启策略

2.png

常见状态转换

3.png

Label

Label 概述

• Label 是 Kubernetes 系统中另一个核心概念。一个 Label 是一个 key=value 的键值对，其中 key 与 value 由用户自己指 定。Label 可以附加到各种资源对象上，如Node、Pod、Service、RC，一个资源对象可以定义任意数量的 Label， 同一个 Label 也可以被添加到任意数量的资源对象上，Label 通常在资源对象定义时确定，也可以在对象创建后动态添加或删除。
• Label 的最常见的用法是使用 metadata.labels 字段，来为对象添加Label，通过spec.selector 来引用对象
• Label 附加到 Kubernetes 集群中各种资源对象上，目的就是对这些资源对象进行分组管理，而分组管理的核心就 是 Label Selector。Label 与 Label Selector 都是不能单独定义，必须附加在一些资源对象的定义文件上，一般附加 在 RC 和 Service 的资源定义文件中。

Controller 控制器

• Replication Controller(RC)是 Kubernetes 系统中核心概念之一，当我们定义了一个RC并提交到 Kubernetes 集群中以后，Master 节点上的 Controller Manager 组件就得到通知，定期检查系统中存活的 Pod,并确保目标 Pod 实例的数量刚好等于 RC 的预期值，如果有过多或过少的 Pod 运行，系统就会停掉或创建一些 Pod。此外我们也可以通过修改RC 的副本数量，来实现 Pod 的动态缩放功能。

• Replication Controller 与 Kubernetes 代码中的模块 Replication Controller 同名，所以在 Kubernetes v1.2 时， 它就升级成了另外一个新的概念 Replica Sets,官方解释为下一代的 RC，它与 RC 区别是:Replica Sets 支援基于集合的 Label selector,而RC 只支持基于等式的 Label Selector。我们很少单独使用 Replica Set,它主要被Deployment 这个更高层面的资源对象所使用，从而形成一整套 Pod 创建、删除、更新的编排机制。最好不要越过 RC 直接创建 Pod， 因为 Replication Controller 会通过RC 管理Pod 副本，实现自动创建、补足、替换、删除 Pod 副本，这样就能提高应用的容灾能力，减少由于节点崩溃等意外状况造成的损失。即使应用程序只有一个 Pod 副本，也强烈建议使用RC 来定义 Pod。

• Replica Sets 支援基于集合的 Label selector,而RC 只支持基于等式的 Label Selector。我们很少单独使用 Replica Set,它主要被Deployment 这个更高层面的资源对象所使用，从而形成一整套 Pod 创建、删除、更新的编排机制。最好不要越过 RC 直接创建 Pod， 因为 Replication Controller 会通过RC 管理Pod 副本，实现自动创建、补足、替换、删除 Pod 副本，这样就能提高应用的容灾能力，减少由于节点崩溃等意外状况造成的损失。即使应用程序只有一个 Pod 副本，也强烈建议使用RC 来定义 Pod。

• Kubernetes 对 Pod 扩容与缩容提供了手动和自动两种模式，手动模式通过kubectl scale命令对一个 Deployment/RC 进行 Pod 副本数量的设置。自动模式则需要用户根据某个性能指标或者自定义业务指标，并指定 Pod 副本数量的范围，系统将自动在这个范围内根据性能指标的变化进行调整。

Volume

Volume 概述

• Volume 是 Pod 中能够被多个容器访问的共享目录。Kubernetes 的 Volume 定义在Pod 上，它被一个 Pod 中的多个容器挂载到具体的文件目录下。Volume 与 Pod 的生命周期相同，但与容器的生命周期不相关，当容器终止或重启时，Volume 中的数据也不会丢失。要使用volume，pod 需要指定 volume 的类型和内容（ 字段），和映射到容器的位置（字段）。
• Kubernetes 支持多种类型的 Volume,包括：emptyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、nfs、iscsi、flocker、glusterfs、rbd、cephfs、gitRepo、secret、persistentVolumeClaim、downwardAPI、azureFileVolume、azureDisk、vsphereVolume、Quobyte、PortworxVolume、ScaleIO。
  • emptyDirEmptyDir 类型的volume创建于 pod 被调度到某个宿主机上的时候，而同一个 pod 内的容器都能读写EmptyDir 中的同一个文件。一旦这个 pod 离开了这个宿主机，EmptyDir 中的数据就会被永久删除。所以目前 EmptyDir 类型的 volume 主要用作临时空间，比如 Web 服务器写日志或者tmp 文件需要的临时目录。
  • HostPath 属性的 volume 使得对应的容器能够访问当前宿主机上的指定目录。例如，需要运行一个访问 Docker 系统目录的容器，那么就使用/var/lib/docker 目录作为一个HostDir 类型的 volume；或者要在一个容器内部运行 CAdvisor，那么就使用/dev/cgroups目录作为一个 HostDir 类型的 volume。一旦这个 pod 离开了这个宿主机，HostDir 中的数据虽然不会被永久删除，但数据也不会随 pod 迁移到其他宿主机上。因此，需要注意的是，由于各个宿主机上的文件系统结构和内容并不一定完全相同，所以相同pod 的HostDir 可能会在不 同的宿主机上表现出不同的行为。
  • NFS 类型 volume,允许一块现有的网络硬盘在同一个 pod 内的容器间共享。

PVC 和 PV

基本概述

管理存储是管理计算的一个明显问题。PersistentVolume 子系统为用户和管理员提供了一个 API，用于抽象如何根据消费方式提供存储的详细信息。两个新的API 资源：PersistentVolume 和 PersistentVolumeClaim。

• PersistentVolume（PV）是集群中由管理员配置的一段网络存储。 它是集群中的资源，就像节点是集群资源一样。 PV 是容量插件，如 Volumes，但其生命周期独立于使用PV 的任何单个 pod。 此 API 对象捕获存储实现的详细信息，包括 NFS，iSCSI 或特定于云提供程序的存储系统。
• PersistentVolumeClaim（PVC）是由用户进行存储的请求。 它类似于pod。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以一次读/写或多次只读）。
• 虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但是 PersistentVolumes 对于不同的问题，用户通常需要具有不同属性（例如性能）。群集管理员需要能够提供各种PersistentVolumes 不同的方式，而不仅仅是大小和访问模式，而不会让用户了解这些卷的实现方式。对于这些需求，有 StorageClass 资源。
• StorageClass 为管理员提供了一种描述他们提供的存储的“类”的方法。不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。Kubernetes 本身对于什么类别代表是不言而喻的。 这个概念有时在其他存储系统中称为“配置文件”。PVC 和 PV 是一一对应的。

Secret

Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。

Secret 有三种类型

• Service Account :用来访问 Kubernetes API,由 Kubernetes 自动创建，并且会自动挂载到 Pod 的/run/secrets/kubernetes.io/serviceaccount 目录中。
• Opaque : base64 编码格式的 Secret,用来存储密码、密钥等。
• kubernetes.io/dockerconfigjson ：用来存储私有 docker registry 的认证信息。

configMap

ConfigMap 概述

• ConfigMap 功能在 Kubernetes1.2 版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配 置信息。ConfigMap AP 丨给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也 可以用来保存整个配置文件或者JSON 二进制大对象

Namespace

Namespace 概述

• Namespace 在很多情况下用于实现多用户的资源隔离，通过将集群内部的资源对象分配到不同的 Namespace 中， 形成逻辑上的分组，便于不同的分组在共享使用整个集群的资源同时还能被分别管理。Kubernetes 集群在启动后，会创建一个名为"default"的Namespace，如果不特别指明 Namespace,则用户创建的 Pod，RC，Service 都将 被系统创建到这个默认的名为 default 的 Namespace 中。

Namespace 查看

kubectl get pods --namespace=development

Service

Service 概述

• Service 是 Kubernetes 最核心概念，通过创建 Service,可以为一组具有相同功能的容器应用提供一个统一的入口地 址，并且将请求负载分发到后端的各个容器应用上。

探针

探针类型

• K8s 中存在两种类型的探针：liveness probe 和 readiness probe。

liveness probe（存活探针）

• 用于判断容器是否存活，即 Pod 是否为 running 状态，如果 LivenessProbe 探针探测到容器不健康，则 kubelet 将 kill 掉容器，并根据容器的重启策略是否重启。如果一个容器不包含 LivenessProbe 探针，则 Kubelet 认为容器的 LivenessProbe 探针的返回值永远成功。有时应用程序可能因为某些原因（后端服务故障等）导致暂时无法对外提供服务，但应用软件没有终止，导致 K8S 无法隔离有故障的 pod，调用者可能会访问到有故障的pod，导致业务不稳定。K8S 提供 livenessProbe 来检测应用程序是否正常运行，并且对相应状况进行相应的补救措施。

readiness probe（就绪探针）

• 用于判断容器是否启动完成，即容器的 Ready 是否为 True，可以接收请求，如果ReadinessProbe 探测失败，则容器的 Ready 将为 False，控制器将此Pod 的Endpoint 从对应的 service 的 Endpoint 列表中移除，从此不再将任何请求调度此Pod 上，直到下次探测成功。通过使用 Readiness 探针，Kubernetes 能够等待应用程序完全启动，然后才允许服务将流量发送到新副本。
• 比如使用 tomcat 的应用程序来说，并不是简单地说 tomcat 启动成功就可以对外提供服务的，还需要等待 spring 容器初始化，数据库连接没连上等等。对于spring boot 应用，默认的 actuator 带有/health 接口，可以用来进行启动成功的判断。

每类探针都支持三种探测方法：

• （1）exec：通过执行命令来检查服务是否正常，针对复杂检测或无HTTP 接口的服务，命令返回值为 0 则表示容器健康。
• （2）httpGet：通过发送 http 请求检查服务是否正常，返回 200-399 状态码则表明容器健康。
• （3）tcpSocket：通过容器的 IP 和 Port 执行 TCP 检查，如果能够建立TCP 连接，则表明容器健康。

探针探测的结果

• （1）Success：Container 通过了检查。
• （2）Failure：Container 未通过检查。
• （3）Unknown：未能执行检查，因此不采取任何措施。

Pod 重启策略：

• （1）Always: 总是重启
• （2）OnFailure: 如果失败就重启
• （3）Never: 永远不重启

调度器

概述

• 一个容器平台的主要功能就是为容器分配运行时所需要的计算，存储和网络资源。容器调度系统负责选择在最合适的主机上启动容器，并且将它们关联起来。它必须能够自动的处理容器故障并且能够在更多的主机上自动启动更多的容器来应对更多的应用访问。目前三大主流的容器平台 Swarm, Mesos 和 Kubernetes 具有不同的容器调度系统。
  1. Swarm 的特点是直接调度 Docker 容器，并且提供和标准 Docker API 一致的API。
  2. Mesos 针对不同的运行框架采用相对独立的调度系统，其中 Marathon 框架提供了Docker容器的原生支持。
  3. Kubernetes 则采用了 Pod 和 Label 这样的概念把容器组合成一个个的互相存在依赖关系的逻辑单元。相关容器被组合成 Pod 后被共同部署和调度，形成服务（Service）。这个是 Kubernetes 和 Swarm，Mesos 的主要区别。
• 相对来说，Kubernetes 采用这样的方式简化了集群范围内相关容器被共同调度管理的复杂性。换一种角度来看，Kubernetes 采用这种方式能够相对容易的支持更强大，更复杂的容器调度算法。

k8s 调度工作方式

• Kubernetes 调度器作为集群的大脑，在如何提高集群的资源利用率、保证集群中服务的稳定运行中也会变得越来越重要

Kubernetes 的资源分为两种属性

1. 可压缩资源（例如 CPU 循环，Disk I/O 带宽）都是可以被限制和被回收的，对于一个Pod 来说可以降低这些资源的使用量而不去杀掉 Pod。
2. 不可压缩资源（例如内存、硬盘空间）一般来说不杀掉 Pod 就没法回收。未来Kubernetes 会加入更多资源，如网络带宽，存储 IOPS 的支持。
3. k8s 调度器
   • （1）kube-scheduler 是 kubernetes 系统的核心组件之一，主要负责整个集群资源的调度功能，根据特定的调度算法和策略，将 Pod 调度到最优的工作节点上面去，从而更加合理、更加充分的利用集群的资源，这也是选择使用 kubernetes 一个非常重要的理由。如果一门新的技术不能帮助企业节约成本、提供效率，我相信是很难推进的。
   • （2）调度流程：默认情况下，kube-scheduler 提供的默认调度器能够满足我们绝大多数的要求，之前接触的示例也基本上用的默认的策略，都可以保证我们的 Pod 可以被分配到资源充足的节点上运行。但是在实际的线上项目中，可能我们自己会比 kubernetes 更加了解我们自己的应用，比如我们希望一个 Pod 只能运行在特定的几个节点上，或者这几个节点只能用来运行特定类型的应用，这就需要我们的调度器能够可控。
   • kube-scheduler 是 kubernetes 的调度器，它的主要作用就是根据特定的调度算法和调度策略将 Pod 调度到合适的 Node 节点上去，是一个独立的二进制程序，启动之后会一直监听 API Server，获取到 PodSpec.NodeName 为空的 Pod，对每个 Pod 都会创建一个binding。

调度主要分为以下几个部分：

• 首先是预选过程，过滤掉不满足条件的节点，这个过程称为 Predicates
• 然后是优选过程，对通过的节点按照优先级排序，称之为 Priorities
• 最后从中选择优先级最高的节点，如果中间任何一步骤有错误，就直接返回错误Predicates 阶段首先遍历全部节点，过滤掉不满足条件的节点，属于强制性规则，这一阶段输出的所有满足要求的 Node 将被记录并作为第二阶段的输入，如果所有的节点都不满足条件，那么 Pod 将会一直处于 Pending 状态，直到有节点满足条件，在这期间调度器会不断的重试。
• 所以我们在部署应用的时候，如果发现有 Pod 一直处于 Pending 状态，那么就是没有满足调度条件的节点，这个时候可以去检查下节点资源是否可用。
• Priorities 阶段即再次对节点进行筛选，如果有多个节点都满足条件的话，那么系统会按照节点的优先级(priorites)大小对节点进行排序，最后选择优先级最高的节点来部署Pod应用。

集群安全机制 RBAC

基本概念

• RBAC(Role-Based Access Control，基于角色的访问控制)在 k8s v1.5 中引入，在v1.6 版本时升级为 Beta 版本，并成为 kubeadm 安装方式下的默认选项，相对于其他访问控制方式，新的 RBAC 具有如下优势：
  • （1）对集群中的资源和非资源权限均有完整的覆盖
  • （2）整个 RBAC 完全由几个 API 对象完成，同其他 API 对象一样，可以用kubectl 或API进行操作
  • （3）可以在运行时进行调整，无需重启 API Server
• 要使用 RBAC 授权模式，需要在 API Server 的启动参数中加上--authorization-mode=RBAC

k8s kubectl

kubectl 是 Kubernetes 集群的命令行工具，通过 kubectl 能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。

查看各个组件的简写

kubectl api-resources

查看所有node

kubectl get nodes

查看所有pod

kubectl get pods

kubectl create 生成yaml

kubectl create deployment web --image=nginx -o yaml --dry-run > nginx.yaml

kubectl get 导出yaml

kubectl get deploy nginx -o=yaml --export > nginx.yaml

创建新的deployment

kubectl create -f nginx.yaml

创建一个service

kubectl create service nodeport nginx --tcp 80:80

另一种方式创建service

kubectl expose deployment nginx --type=NodePort

查看某一个service的详情

kubectl describe services/nginx

查看所有service

kubectl get svc

删除pod和svc

kubectl delete deployments/nginx services/nginx

在master节点上查看slave node的ip

kubectl get nodes -o wide

在master节点上,查看所有pods

kubectl get pods -o wide

实现 Pod 的动态缩放功能

kubectl scale rc nginx --replicas=5

containerd

查看版本

ctr -v

查看已经存在的images

crictl images list

重启containerd服务

systemctl restart containerd

crictl 去 pull 镜像

crictl pull harbor.kingsd.top/ksd/ubuntu:16.04

kubernetes 部署项目

发布 Java 项目

4.png

你知道的越多，你不知道的越多。