K8s的相关知识总结

1. kubernetes 简介

• 在Docker 作为高级容器引擎快速发展的同时，在Google内部，容器技术已经应用了很多年

• Borg系统运行管理着成千上万的容器应用。

• Kubernetes项目来源于Borg，可以说是集结了Borg设计思想的精华，并且吸收了Borg系统中的经验和教训。

• Kubernetes对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。

kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：

• 自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器

• 弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整

• 服务发现：服务可以通过自动发现的形式找到它所依赖的服务

• 负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡

• 版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本

• 存储编排：可以根据容器自身的需求自动创建存储卷

2. K8S的设计架构

2.1K8S各个组件用途

一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件

1 master：集群的控制平面，负责集群的决策

• ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制

• Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上

• ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等

• Etcd ：负责存储集群中各种资源对象的信息

2 node：集群的数据平面，负责为容器提供运行环境

• kubelet：负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理

• Container runtime：负责镜像管理以及Pod和容器的真正运行（CRI）

• kube-proxy：负责为Service提供cluster内部的服务发现和负载均衡

2.2 K8S 各组件之间的调用关系

当我们要运行一个web服务时

1. kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中

2. web服务的安装请求会首先被发送到master节点的apiServer组件

3. apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上

   在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer

4. apiServer调用controller-manager去调度Node节点安装web服务

5. kubelet接收到指令后，会通知docker，然后由docker来启动一个web服务的pod

6. 如果需要访问web服务，就需要通过kube-proxy来对pod产生访问的代理

2.3 K8S 的 常用名词感念

• Master：集群控制节点，每个集群需要至少一个master节点负责集群的管控

• Node：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的

• Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器

• Controller：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等

• Service：pod对外服务的统一入口，下面可以维护者同一类的多个pod

• Label：标签，用于对pod进行分类，同一类pod会拥有相同的标签

• NameSpace：命名空间，用来隔离pod的运行环境

2.4 k8S的分层架构

• 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

• 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）

• 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）

• 接口层：kubectl命令行工具、客户端SDK以及集群联邦

• 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴

• Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等

• Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

3. K8S集群环境搭建

3.1 k8s 环境部署说明

K8S中文官网：Kubernetes

主机名	ip	角色
harbor	192.168.232.140	harbor仓库
master	192.168.232.141	master，k8s集群控制节点
node3	192.168.232.142	worker，k8s集群工作节点
node4	192.168.232.143	worker，k8s集群工作节点

• 所有节点禁用selinux和防火墙

• 所有节点同步时间和解析

• 所有节点安装docker-ce

• 所有节点禁用swap，注意注释掉/etc/fstab文件中的定义

3.2 部署 harbor仓库

3.2.1 创建加密传输的认证key和证书

3.2.2 配置yml文件

完成后访问当前ip 输入账号密码就可以登录到harbor仓库

3.3 集群初始化

3.3.1禁用所有swap

3.3.2 添加本地解析

3.3.3 安装docker

3.3.4 将所有harbor的证书复制到每个节点的docker中

3.3.5 查看docker配置有无问题

docker info 查看docker的信息

3.3.6 安装k8s工具

3.3.7 在所有节点上安装cri-docker

3.3.8 集群初始化

3.3.9 安装网络插件

3.3.10 集群扩容

利用刚才初始化给的加入集群的指令在相对应的节点加入集群

查看集群情况

4.kubernetes 中的资源

4.1资源管理介绍

- 在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。
- kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务
- 所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。
- kubernetes的最小管理单元是pod而不是容器，只能将容器放在`Pod`中，
- kubernetes一般也不会直接管理Pod，而是通过`Pod控制器`来管理Pod的。
- Pod中服务的访问是由kubernetes提供的`Service`资源来实现。
- Pod中程序的数据需要持久化是由kubernetes提供的各种存储系统来实现

4.2 资源管理方式

• 命令式对象管理：直接使用命令去操作kubernetes资源

  kubectl run nginx-pod --image=nginx:latest --port=80

• 命令式对象配置：通过命令配置和配置文件去操作kubernetes资源

  kubectl create/patch -f nginx-pod.yaml

• 声明式对象配置：通过apply命令和配置文件去操作kubernetes资源

  kubectl apply -f nginx-pod.yaml

类型	适用环境	优点	缺点
命令式对象管理	测试	简单	只能操作活动对象，无法审计、跟踪
命令式对象配置	开发	可以审计、跟踪	项目大时，配置文件多，操作麻烦
声明式对象配置	开发	支持目录操作	意外情况下难以调试

4.3 实验前准备

可以将输出数据保存，编写相关的脚本文件。

4.3.1 编写生成的yaml文件

4.3.2 pod资源的更新

4.3.3 命名空间

4.4pod的生命周期

• Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
• Init 容器与普通的容器非常像，除了如下两点：
• 它们总是运行到完成
• init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。
• 如果Pod的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。但是，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

4.4.1 INIT容器的功能

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。

Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。

应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。

由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

4.4.2 探针

探针是由 kubelet 对容器执行的定期诊断:

ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。

HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

成功：容器通过了诊断。

失败：容器未通过诊断。

未知：诊断失败，因此不会采取任何行动。

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。

readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

ReadinessProbe 与 LivenessProbe 的区别

ReadinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。

LivenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施

StartupProbe 与 ReadinessProbe、LivenessProbe 的区别

如果三个探针同时存在，先执行 StartupProbe 探针，其他两个探针将会被暂时禁用，直到 pod 满足 StartupProbe 探针配置的条件，其他 2 个探针启动，如果不满足按照规则重启容器。

另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而 StartupProbe 探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。

5.控制器

5.1 什么是控制器

官方文档：

工作负载管理 | Kubernetes

控制器也是管理pod的一种手段

• 自主式pod：pod退出或意外关闭后不会被重新创建

• 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod

当建立控制器后，会把期望值写入etcd，k8s中的apiserver检索etcd中我们保存的期望状态，并对比pod的当前状态，如果出现差异代码自驱动立即恢复

5.2 控制器的常用类型

控制器名称	控制器用途
Replication Controller	比较原始的pod控制器，已经被废弃，由ReplicaSet替代
ReplicaSet	ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
Deployment	一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力
DaemonSet	DaemonSet 确保全指定节点上运行一个 Pod 的副本
StatefulSet	StatefulSet 是用来管理有状态应用的工作负载 API 对象。
Job	执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束
CronJob	Cron Job 创建基于时间调度的 Jobs。
HPA全称Horizontal Pod Autoscaler	根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放

5.3 replicaset控制器

5.3.1 replocaset功能

• ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet

• ReplicaSet和Replication Controller的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求

• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行

• 虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制

5.3.2 replocaset参数说明

参数名称	字段类型	参数说明
spec	Object	详细定义对象，固定值就写Spec
spec.replicas	integer	指定维护pod数量
spec.selector	Object	Selector是对pod的标签查询，与pod数量匹配
spec.selector.matchLabels	string	指定Selector查询标签的名称和值，以key：value方式指定
spec.template	Object	指定对pod的描述信息，比如lab标签，运行容器的信息等
spec.template.metadata	Object	指定pod属性
spec.template.metadata.labels	string	指定pod标签
spec.template.spec	Object	详细定义对象
spec.template.spec.containers	list	Spec对象的容器列表定义
spec.template.spec.containers.name	string	指定容器名称
spec.template.spec.containers.image	string	指定容器镜像

5.3.3 replicaset 示例

apply此yaml文件并查看pods情况

replicaset是根据标签匹配pod当修改对应的标签时，他会自动生成一个新的pod

当标签修改回去时自动删除多余的pod

replicaset的副本数量可以自愈

5.4 deployment 控制器

5.4.1 deployment控制器的功能

• 为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。

• Deployment控制器并不直接管理pod，而是通过管理ReplicaSet来间接管理Pod

• Deployment管理ReplicaSet，ReplicaSet管理Pod

• Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法

• 在Deployment中ReplicaSet相当于一个版本

典型的应用场景：

• 用来创建Pod和ReplicaSet

• 滚动更新和回滚

• 扩容和缩容

• 暂停与恢复

5.4.2 deployment控制器示例

5.4.3 版本迭代

运行相关的yml文件后

版本回滚就是将文件中的v2改成对应的版本

5.4.4 滚动更新策略

5.4.5 暂停及恢复

在实际生产环境中我们做的变更可能不止一处，当修改了一处后，如果执行变更就直接触发了

我们期望的触发时当我们把所有修改都搞定后一次触发

暂停，避免触发不必要的线上更新

暂停相关pods

修改yml文件

运用文件后，调整副本数不受影响；但是更新镜像和修改资源并没有触发更新

5.5 daemonset控制器

5.5.1 daemonset功能

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod ，当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod

DaemonSet 的典型用法：

• 在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。

• 在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。

• 在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等

• 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用

• 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求

5.5.2 示例

5.6 job控制器

5.6.1 功能

Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务

Job特点如下：

• 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量

• 当成功结束的pod达到指定的数量时，Job将完成执行

5.6.2 job控制器示例

关于重启策略设置的说明：

- ​    如果指定为OnFailure，则job会在pod出现故障时重启容器

​    而不是创建pod，failed次数不变

- ​    如果指定为Never，则job会在pod出现故障时创建新的pod

​    并且故障pod不会消失，也不会重启，failed次数加1

- ​    如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了

5.7 cronjob控制器

5.7.1 功能

- Cron Job 创建基于时间调度的 Jobs。
- CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，
- CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。
- CronJob可以在特定的时间点(反复的)去运行job任务。

5.7.2 示例

6.微服务

6.1 什么是微服务

用控制器来完成集群的工作负载，那么应用如何暴漏出去？需要通过微服务暴漏出去后才能被访问

• Service是一组提供相同服务的Pod对外开放的接口。

• 借助Service，应用可以实现服务发现和负载均衡。

• service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现

6.2 微服务的类型

微服务类型	作用描述
ClusterIP	默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问
NodePort	将Service通过指定的Node上的端口暴露给外部，访问任意一个NodeIP:nodePort都将路由到ClusterIP
LoadBalancer	在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器，并将请求转发到 NodeIP:NodePort，此模式只能在云服务器上使用

示例：

查看生成的微服务

6.3 ipvs模式

• Service 是由 kube-proxy 组件，加上 iptables 来共同实现的

• kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的 iptables 规则，如果宿主机有大量的Pod，不断刷新iptables规则，会消耗大量的CPU资源

• IPVS模式的service，可以使K8s集群支持更多量级的Pod

6.3.1 ipvs模式配置方式

在所有节点先安装ipvsadm工具

6.4 微服务类型详解

6.4.1 clusterip

特点：

clusterip模式只能在集群内访问，并对集群内的pod提供健康检测和自动发现功能

示例：

6.4.2 ClusterIP中的特殊模式headless

headless（无头服务）

对于无头 Services 并不会分配 Cluster IP，kube-proxy不会处理它们， 而且平台也不会为它们进行负载均衡和路由，集群访问通过dns解析直接指向到业务pod上的IP，所有的调度有dns单独完成

回收原来的yaml，运用新的yaml

6.4.3 nodeport

通过ipvs暴漏端口从而使外部主机通过master节点的对外ip:<port>来访问pod业务

其访问过程为：

        

6.5 ingress-nginx

6.5.1 ingress-nginx功能

• 一种全局的、为了代理不同后端 Service 而设置的负载均衡服务,支持7层

• Ingress由两部分组成：Ingress controller和Ingress服务

• Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。

• 业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维护了对应的 Ingress Controller。

5.6.2 部署ingress

5.6.2.1下载部署文件

5.6.2.2测试ingress