答：Kubenetes 是一个用于容器应用程序自动部署、弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。
K8S由Google推出。它源自Google内部使用了15年的Borg系统，融合了Borg的精华。
答：和大多数分布式系统一样，一个K8S集群至少需要一个主节点（Master）和多个计算节点（Node）。
答：容器的中心思想是秒级启动；一次打包，到处运行；这是主机部署应用无法达到的效果，但同时更要关注容器的数据持久化。
此外，容器部署可以隔离各种服务，互不影响。这是容器的另一个核心概念。
答：对于Pod资源对象的健康状态检测，K8s提供了三种类型的探针来对Pod进行健康监控：
您可以根据用户定义的规则判断Pod是否健康。如果 livenessProbe 探针检测到容器不健康，kubelet 将根据其重启策略决定是否重启。如果一个容器不包含 livenessProbe 探针，kubelet 会认为该容器的 livenessProbe 探针的返回值始终是成功的。
还可以根据用户定义的规则判断Pod是否健康。如果检测失败，控制器会将 pod 从相应服务的端点列表中删除，并且不再调度任何请求到该 pod，直到下一次检测成功。
启动检查机制，应用一些启动缓慢的服务，避免业务启动时间较长，被上述两类探针杀死。这个问题还可以通过另一种方式来解决，即在定义上述两类探测机制时， 初始化时间可以定义得长一些。
每种检测方式均可支持以下相同的检测参数，用于设置和控制检测时间：
以上两种探头均支持以下三种检测方式：
1）Exec：通过执行命令检查服务是否正常。例如，使用cat命令检查pod中是否存在重要配置文件。如果存在，则表示 pod 是健康的。否则不正常。
Exec检测模式的yaml文件语法如下：
规格:
容器:
-名称:活跃度
图像: k8s.gcr.io/busybox
args:
- /bin /sh
- -c -触摸/tmp/健康；睡眠30；rm-rf /tmp/健康; sleep 600
livenessProbe: #选择livenessProbe的探测机制
exec:30 #执行以下命令
命令:
-猫
-/tmp /健康
初始延迟秒：5#在容器运行五秒后开始探测
periodSeconds: 5 #每次探测的间隔为5秒
在上面的配置文件中，探测机制为在容器运行时间5秒后，每五秒探测一次，如果cat命令返回的值为“0”，则表示健康，如果为非0，则表示异常。
2）Httpget：通过发送http/https请求检查服务是否正常。返回的状态码是200-399，这意味着容器是健康的（注意http get类似于命令curl -I）。
Httpget检测方法的yaml文件语法如下：
规格：
容器：
-名称:活跃度
图像: k8s.gcr.io/活性
活性探针: #使用livenessProbe机制检测
httpGet: #采用httpget方法
方案:HTTP #指定协议，也支持https
路径:/healthz #检查根目录是否可以访问
port: 8080 #监听端口为 8080
initialDelaySeconds : 3 #开始检测运行容器 3 秒后
periodSeconds ？状态码小于400表示成功。任何其他代码都表示异常。3）tcpSocket：通过容器的IP和Port进行TCP检查。如果能够建立TCP连接，则说明容器是健康的。这种方法有点类似于HTTPget的检测机制。 tcpsocket健康检查适用于TCP服务。
tcpSocket检测方法的yaml文件语法如下：
规格:
容器:
- 名称: goproxy
图片: k8s.gcr.io/goproxy:0.1
端口:
- containerPort: 8080
#这里使用了两种检测机制，都是与容器的8080端口建立TCP连接
readinessProbe ：
tcpSocket:
端口: 8080
initialDelaySeconds : 5
周期秒: 10
livenessProbe：
tcpSocket：
端口： 8080
初始延迟秒： 15
周期秒: 20在上面的yaml配置文件中，使用了两种类型的探针。容器启动后5秒，kubelet会发送第一个readinessProbe探测，该探测会连接容器端口的8080。如果检测成功，则 Pod 是健康的。十秒后，kubelet 将进行第二次连接。
除了 readinessProbe 探针外，kubelet 还会在容器启动后 15 秒发送第一个 livenessProbe 探针，仍然尝试连接容器的 8080 端口，如果连接失败则重新启动容器。
探头检测的结果无非是以下三种之一：
- 成功：集装箱检验合格；
- 不合格：集装箱检验不合格；
- 未知：不进行检查，因此不采取任何操作（通常我们不定义探针检测，默认成功）。
如果你觉得上面还不够彻底，可以移步到它的官网文档：
5。如何控制滚动更新过程？
解答：可以通过以下命令查看更新过程中可以控制的参数：
[root@master yaml]# kubectl 解释部署.spec.strategy.rollingUpdatemaxSurge： 此参数控制滚动更新过程中，副本总数超过预期 Pod 数量上限。它可以是百分比或特定值。默认值为 1。
（以上参数的作用是，在更新过程中，如果值为3，那么无论怎样，都会先运行3个pod来替换旧的pod，以此类推）
maxUnavailable：该参数控制滚动更新过程中不可用的Pod数量。
（这个值和上面的值没有关系，比如：我有十个pod，但是在更新过程中，我允许这十个pod中最多三个不可用，那么把这个参数的值改成设置为3。更新过程中，只要不可用的Pod数量小于或等于3，更新过程就不会停止）。
6。 K8s中图片的下载策略是怎样的？
解答：可以通过命令“kubectl treat pod.spec.containers”查看imagePullPolicy这一行的解释。
K8s 有三种图片下载策略：Always、Never、IFNotPresent；
- Always：当镜像标签最新时，始终从指定仓库获取镜像；
- Never：禁止从仓库下载镜像，即只能使用本地镜像；
- IfNotPresent：如果本地没有对应的镜像，则只从目标仓库下载。
- 默认图片下载策略为：当图片标签为最新时，默认策略为始终；当图片标签是自定义的（即标签不是最新的）时，则默认策略为IfNotPresent。
7。图像的状态是什么？
- Running：Pod所需的容器已成功调度到节点并已成功运行。
- Pending：APIserver 已创建 pod 资源对象并已存储到 etcd 中，但尚未调度或仍在从仓库下载镜像的过程中。
- Unknown：API Server 无法正常获取 pod 对象的状态，通常是因为无法与工作节点的 kubelet 通信。
8。 Pod 的重启策略是什么？
答：可以通过命令 kubectlexplain pod.spec 来查看 pod 的重启策略。 （重启策略字段）
- 始终：只要 pod 对象终止，就重新启动它。这是默认策略。
- OnFailure：仅当 pod 对象发生错误时才重新启动
9。 Service这样的资源对象的作用是什么？
答：用于为同一个多个Pod对象提供固定的统一访问接口。它常用于服务发现和服务访问。
10。版本回滚相关的命令有哪些？
[root@master httpd-web]# kubectl apply -f httpd2-部署1。 yaml --记录
#运行yaml文件，记录版本信息；
[root@master httpd-web]# kubectl 部署历史部署 httpd -devploy1
#查看本条历史版本部署
[root@master httpd -web]# kubectl rollout 撤消部署 httpd -devploy1 --修订= 1
#执行回滚操作，指定回滚到版本1
#在yaml文件的spec字段中，可以写入以下选项（用于限制最多记录多少个历史版本）：
规格:
修订历史限制:5 #该字段由kubectl解释解释deploy.spec命令查找revisionHistoryLimit <整数>行获取11. 标签和标签 选择器有什么作用？
标签：当同一类型的资源对象越来越多时，为了更好的管理，可以根据标签进行分组，提高资源对象的管理效率。
标签选择器：标签的查询和过滤条件。目前该 API 支持两种标签选择器：
- 基于等价关系，如：“=”、“”“==”、“!=”（注：“==”也表示相等，yaml文件中的matchLabels字段）；
- 基于集合，如：in、notin、exists（yaml 文件中的 matchExpressions 字段）；
注：in：本集中； notin：不在此集合中；存在：该集合中全部（存在），或无（不存在）；
使用标签选择器的操作逻辑：
- 当使用基于集合的标签选择器，将多个选择器之间的逻辑关系指定为“与”运算时（例如： - {key: name,operator: In,values: [zhangsan,lisi]}，则 As只要资源具有这两个值，就会被选择）；
- 使用空值的标签选择器意味着每个资源对象都被选中（例如：标签选择器的键为“A”，两个资源对象同时拥有键A，但值不同。这种情况下，如果使用空值的标签选择器，两个资源对象都会同时被选中）
- 一个空的标签选择器（注意不是上面说的空值，而是空的，并且没有定义键名）将无法选择任何资源；
在基于集合的选择器中，当使用“In”或“Notin”操作时，其值可以为空，但如果为空，这个标签选择器将没有任何意义。
两种标签选择器类型（基于等价、基于集合的写法）：
选择器:
matchLabels: #基于等效值
应用程序: nginx
匹配表达式: # 根据套装
- {key: 姓名,操作者:在,值:[zhangsan] ,lisi]} #三个字段键、运算符和值是固定的
- {key:年龄,操作员: Exists,values:} #如果指定为exists，则values的值必须为空12.常用的标签类别有哪些？
标签类别可以自定义，但是为了让别人能够达到一目了然的效果，一般采用以下类别：
- 版本标签（release）：stable（稳定版本）、canary（金丝雀版本，在测试版本中可以称为测试版本）、beta（测试版本）；
- 环境标签（环境）：dev（开发）、qa（测试）、product（生产）、op（运维）；
- 应用类别（app）：ui、as、pc、sc；
- 架构类（tier）：frontend（前端）、backend（后端）、cache（缓存）；
- 分区标签（分区）：customerA（客户A）、customerB（客户B）；
- 质量控制级别（Track）：每日（daily）、每周（weekly）。
13。查看标签有几种方式？
答：常用的查看方式有以下三种：
[root@master ~]# kubectl get pod --show-labels #查看pod并显示标签内容
[root@master ~]# kubectl 获取 pod -L env,tier #显示资源对象标签的值
[root@ master ~]# kubectl 获取 pod -l env, tier #只显示与键值资源对象匹配的pod，并且“-L”是显示所有Pod14.添加、修改、删除标签的命令是什么？
#对Pod标签的操作
[root@master ~]# kubectl label pod label-pod abc=123 #为 pod 添加一个标签，名为 label-豆荚
[root@master ~] # kubectl label pod label-pod abc =456 --overwrite #修改标签命名 label-pod
[root@master ~ ]# kubectl label pod label-pod abc- #删除名为 label-pod
[ root@master ~] # k ubectl get pod --show-labels
#标签操作在节点节点
[root@master ~ ]# kubectl 标签节点 node01 disk=ssd #给节点node01添加磁盘标签
[root@master ~]# kubectl标签节点node01磁盘=sss –overwrite #修改节点node01 的标签
[root@master ~]# kubectl 标签节点 node01 磁盘- #删除节点node01的磁盘标签15 。 DaemonSet资源对象有哪些特点？
资源对象DaemonSet会运行在k8s集群的每个节点上，每个节点只能运行一个pod。这是它与部署资源对象最大也是唯一的区别。因此，在它的yaml文件中，不支持副本的定义。另外，它的编写方式与Deployment、RS等资源对象相同。
其一般使用场景如下：
- 正在做各个节点的日志收集工作；
- 监控各节点运行状态；
16。说说你对Job这样的资源对象的理解？
答：Job 与其他服务容器不同。 Job 是一个工作容器（通常用于一次性任务）。不常用，所以可以忽略这个问题。
#提高作业执行效率的方法：
spec:
并行度: 2 #一次运行 2 个
完成： 8 #运行最多 8 个
模板:
元数据:17. 描述一下Pod生命周期的状态？
- Pending：表示该pod已经同意创建，正在等待kube-scheduler选择合适的节点来创建，通常是准备镜像；
- Running：表示pod内所有容器均已创建，并且至少有一个容器正在运行或正在启动或正在重启；
- 成功：表示所有容器已成功终止，不会再次启动；
- Failed：表示pod内所有容器以非0（异常）状态退出；
- Unknown：表示无法读取 Pod 状态，通常 kube-controller-manager 无法与 Pod 通信。
18。创建 pod 的过程是怎样的？
- 客户端向kube-apiserver提交Pod配置信息（可以是yaml文件中定义的信息）；
- Apiserver收到指令后通知controller-manager创建资源对象；
- Controller-manager通过api-server将pod配置信息存储在ETCD数据中心；
- 当 Kube-scheduler 检测到 pod 信息时，就会开始调度预选。它会首先过滤掉不符合Pod资源配置要求的节点，然后开始调度优化。它主要是选择更适合运行Pod的节点，然后将Pod资源分配给该节点上的kubelet组件。
- Kubelet 根据调度器发送的资源配置表运行 pod。操作成功后，pod的运行信息返回给调度器，调度器将返回的pod运行状态信息存储在etcd数据中心。
19。如果删除 Pod 会发生什么？
答：Kube-apiserver会收到用户的删除指令。默认情况下，有 30 秒等待优雅退出。如果超过30秒，就会被标记为死亡。此时Pod的状态为Terminate。 Kubelet 将看到该 pod 被标记为“正在终止”。开始关闭 Pod；
关闭流程如下：
- pod 已从服务的端点列表中删除；
- 如果 pod 定义了预停止钩子，它将在 pod 内部调用。 stop hook 一般定义了如何优雅地结束进程；
- 向进程发送 TERM 信号 (kill -14)
- 当超过优雅退出时间时，Pod 中的所有进程都会收到 SIGKILL 信号（kill -9）。
20。 K8s的服务是什么？
答：每次 Pod 重启或重新部署时，其 IP 地址都会发生变化，这会导致 Pod 之间以及 Pod 与外界的通信变得困难。这时候Service就需要为Pod提供一个固定的入口。
Service 的 Endpoint 列表通常绑定到一组配置相同的 pod，外部请求通过负载均衡分发到多个 pod。
21。 k8s如何注册服务？
答：Pod启动后，会加载当前环境中的所有Service信息，以便不同的Pod可以根据Service名称进行通信。
22。 k8s集群外部的流量如何访问Pod？
答：可以通过Service的NodePort方法访问。所有节点都会监听同一个端口，比如30000，访问该节点的流量会被重定向到对应的Service。
23。 k8s数据持久化有哪些方法？
答案：
1）EmptyDir（空目录）
没有指定要挂载的主机上的目录，直接从 Pod 内部映射到主机。类似于docker中的管理卷。
主要使用场景：
- 仅临时将数据保存在磁盘上，例如在合并/排序算法中；
- 作为两个容器之间的共享存储，第一个内容管理容器可以将生成的数据存储在其中，同时同一个Webserver容器将这些页面提供给外界。
emptyDir的特点：
同一个pod中的不同容器共享相同的持久化目录。当Pod节点被删除时，卷数据也会被删除。如果只是容器被销毁，pod还在的话，卷中的数据不会受到影响。
总结一下：emptyDir的数据持久化生命周期和使用的pod是一致的。一般用作临时存储。
2) 主机路径
将主机上已存在的目录或文件挂载到容器中。类似于docker中的bind mount挂载方法。
这种数据持久化方式由于增加了pod和节点之间的耦合性，应用场景较少。
一般用于k8s集群本身的数据持久化和docker本身的数据持久化。可以参考apiService的yaml文件，位于/etc/kubernetes/main...目录下。
3）PersistentVolume（简称PV）
基于NFS服务的PV，或者基于GFS的PV。其作用是统一数据持久化目录，方便管理。
在PV的yaml文件中，可以配置PV的大小，并指定PV的访问模式：
- ReadWriteOnce：只能以读写方式挂载到单个节点；
- ReadOnlyMany：可以以只读方式挂载到多个节点；
- ReadWriteMany：可以以读写方式挂载到多个节点。并指定pv的回收策略：
- 回收：清除PV数据，然后自动回收；
- 保留：需要人工回收；
- 删除：删除云存储资源，云存储专用；
PS：这里的回收策略是指删除PV后是否删除该PV下存储的源文件）。
如果需要使用PV，还有一个重要的概念：PVC。 PVC是申请PV所需的容量。 K8s集群中可能存在多个PV。为了关联 PVC 和 PV，它们的定义访问模式必须一致。定义的storageClassName也必须一致。如果集群中存在两个同名（名称和访问模式相同）的PV，那么PVC会选择申请与自己需要的容量相近的PV，或者随机申请。
