对k8s的相关知识

东坡不稗

已于 2022-08-01 16:31:51 修改

阅读量1.2k

点赞数

分类专栏： k8s 文章标签： kubernetes docker java

于 2022-01-25 17:20:13 首次发布

本文链接：https://blog.csdn.net/qq_27759825/article/details/122689167

版权

k8s 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

对k8s的相关知识

1、k8s简介

Kubernetes简称k8s，是google公司用go语言开发的系统，是一个针对容器应用，进行自动部署，弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。

2、k8s架构的组成

在这里插入图片描述

大体架构

k8s集群至少需要一个主节点和多个计算节点

主节点用于暴露API，调度部署和节点管理
计算节点运行一个容器运行的环境，如docker，同时运行一个k8s代理（kubelet）用于和master通信，计算节点还运行一些额外的组件，像记录日志，节点监控，服务发现等等。是真正的工作节点

架构细分

master节点

kubectl：客户端命令行工具，作为整个k8s集群的操作入口
api server：作为资源的唯一入口，提供认证、授权、访问控制、API注册和发现等机制。客户端与k8s集群及k8s内部组件的通信，都要通过api server这个组件
controller-manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
scheduler：负责资源调度，按照预定的调度策略将pod调度到相应的node节点上
etcd：担任数据中心的角色，保存了整个集群的状态

node节点

kubelet：负责维护容器的生命周期、volume和网络管理，运行在node工作节点上。master的scheduler确定某个node要运行pod之后，将pod的具体信息（image，volume）等发送给该节点的kubelet，kubelet根据信息创建和运行容器，向master返回运行状态
kube-proxy：负责为service提供cluster内部的服务发现和负载均衡（service接收到请求后通过kube-proxy转发到pod）
container-runtime：是负责管理运行容器的软件，比如docker
pod：k8s里面最小的单位，每个pod能运行一个或多个container，多个container的资源，如USER（用户）、MNT（挂载点）、PID（进程号）相互隔离。如UTS（主机名、域名），IPC（消息队列）、NET（网格栈）相互共享

3、容器和主机部署应用的区别

容器的中心思想是秒级启动，一次封装、到处运行，主机部署无法达到这效果，但是容器部署要注意数据持久化问题。容器可以将各个服务进行隔离，互补影响。

4、k8s对pod资源对象的监控检测机制

k8s提供三类probe（探针）来执行对pod的健康检测

livenessProbe探针

可以根据用户自定义的规则来判定pod是否健康，如果为不健康，kubelet会根据重启策略来决定是否重启。如果容器不包含livenessProbe探针，则总是认为是健康的

readinessProbe探针

可以根据用户自定义的规则来判定pod是否健康，如果为不健康，控制器将pod从对应service的endpoint列表中移除，从此不再将任何请求调度到该pod，直到下次探测成功

startupProbe探针

启动检测机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉

5、控制滚动更新过程

通过以下命令查看更新时可以控制的参数：

kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge：控制滚动更新过程，副本总数超过预期pod数量的上限，可以是百分比也可以是具体的值，默认是1

maxUnavailable：次参数控制滚动更新过程中，不可用的pod数量

6、k8s中镜像的下载策略

可以通过命令查看

kubectl explain pod.spec.containers

imagePullPolicy有以下三种

Always：镜像标签为latest时，总是从指定仓库获取镜像
Never：禁止从仓库下载镜像，只能使用本地镜像
IfNotPresent：仅当本地没有相应镜像时，才从仓库下载

7、image的状态

Running：pod所需要的容器已经被成功调度到某个节点，且已经成功运行
Pending：api server创建了pod资源对象，并且已经存入etcd，但是它尚未被调度完成或仍然处于仓库的下载镜像过程中
Unknown：api server无法正常获取到pod对象的状态，通常是api server无法和所在工作节点的kubelet通信所致

8、pod的重启策略

可以通过命令查看

kubectl explain pod.spec

restartPolicy重启策略有以下2种

Always：pod对象终止就重启（默认）
OnFailure：pod出现错误时重启

9、service的作用

给相同的多个pod对象提供一个固定的统一访问接口，常用于服务发现和服务访问，

pod每次重启或者重新部署，ip都会发生变化，使得pod之间通信和pod与外部通信变得困难，service就能定义一个统一固定的访问入口

service的endpoint列表通常绑定一组相同配置的pod，通过负载均衡把外界的请求分配到多个pod

10、版本回滚相关命令

运行yaml文件，并记录版本信息；

kubectl apply -f httpd2-deploy1.yaml  --record

查看该deployment的历史版本

kubectl rollout history deployment httpd-devploy1

执行回滚操作，指定回滚到版本1

kubectl rollout undo deployment httpd-devploy1 --to-revision=1

在yaml文件的spec字段中，可以写以下选项（用于限制最多记录多少个历史版本）
```
spec:
  revisionHistoryLimit: 5
```

11、DaemonSet的特征

DaemonSet会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是和deploymentSet最大的也是唯一的区别，在yaml文件中不支持replicas属性，除此之外和DeploymentSet的写法相同

使用场景

每个节点上的日志收集
监控每个节点的运行状态

12、job资源

job和其他服务类容器不同，job是一种工作类容器，一般做一次性任务，使用不多

13、pod生命周期

pending：pod已经被同意创建，等待schedule选择合适的节点创建，一般在准备镜像
running：pod中所有容器都被创建、并且至少一个容器正在运行或者正在启动或者正在重启
succeeded：所有容器已经成功终止，并且不再启动
failed：pod中所有容器都是非0（不正常）状态退出
unknown：无法读取pod的状态，通常是controller-manager无法与pod通信

14、创建pod的流程

kubectl客户端提交pod的配置信息（可以是yaml文件）到api server
api server收到指令后，通知controller manager创建一个资源对象
controller manager通过api server将pod的配置信息存储到etcd数据中心
scheduler 检测到pod信息会开始调度预选，先过滤掉不符合pod资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行pod的节点，然后将pod的资源配置单发到node节点的kubelet组件上
kubelet收到pod配置信息，创建并运行pod，运行成功后，将pod的运行信息返回给scheduler，scheduler将返回的pod运行状况信息存储到etcd数据中心