摘要

本博文主要是k8s的面试相关问题与答案分享。

Kubernetes 中的资源对象 · Kubernetes Handbook - Kubernetes 中文指南/云原生应用架构实践手册 · Jimmy Song

一、简要说下Kubernetes有哪些核心组件以及这些组件负责什么工作？(8大组件)

etcd：提供数据库服务保存了整个集群的状态kube-apiserver：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制kube-controller-manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等cloud-controller-manager：是与底层云计算服务商交互的控制器kub-scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上kubelet：负责维护容器的生命周期，同时也负责Volume和网络的管理，运行在每个计算节点上，作为agent，接收分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver。kube-proxy：负责为Service提供内部的服务发现和负载均衡，并维护网络规则。运行在每个计算节点上，负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。container-runtime：是负责管理运行容器的软件，比如dockerkubectl:客户端命令行工具，作为整个系统的操作入口。kube-controller-manager:执行整个系统的后台任务，包括节点状态状况、Pod个数、Pods和Service的关联等。kube-scheduler:负责节点资源管理，接收来自kube-apiserver创建Pods任务，并分配到某个节点。kube-dns：一个可选的DNS服务，用于为每个Service对象创建DNS记录，这样所有的Pod就可以通过DNS访问服务了。Ingress Controller 为服务提供外网入口Heapster 提供资源监控Dashboard 提供 GUI

核心层：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS 解析等）
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）
接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
Kubernetes 外部：日志、监控、配置管理、CI、CD、Workflow等
Kubernetes 内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

二、你对 Kubernetes 的负载均衡器有什么了解？

负载均衡器是暴露服务的最常见和标准方式之一。根据工作环境使用两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器，而外部负载均衡器将流量从外部负载引导至后端容器。

三、经典pod的生命周期

Pod都处于以下几种状态之一，可通过查询Pod详情查看。Pending 部署Pod事务已被集群受理，但当前容器镜像还未下载完。Running 所有容器已被创建，并被部署到k8s节点。Successed Pod成功退出，并不会被重启。Failed Pod中有容器被终止。Unknown 未知原因，如kube-apiserver无法与Pod进行通讯。首先拖取Pod内容器的镜像，选择某个Node节点并启动Pod。 监控Pod状态，若Pod终止则根据策略决定是否重新调度。 Pod退出，并根据策略决定是否重启。

pod的重启策略是什么？

可以通过命令“kubectl explain pod.spec”查看pod的重启策略。（restartPolicy字段）Always：但凡pod对象终止就重启，此为默认策略。OnFailure：仅在pod对象出现错误时才重启

image的状态有哪些？

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

删除一个Pod会发生什么事情？

Kube-apiserver会接受到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，此时Pod的状态Terminating，kubelet看到pod标记为Terminating就开始了关闭Pod的工作；关闭流程如下：
1、 pod从service的endpoint列表中被移除；
2、 如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；
3、 进程被发送TERM信号（kill -14）
4、 当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）。

四、详述kube-proxy原理

问题：详述kube-proxy原理，一个请求是如何经过层层转发落到某个pod上的整个过程。请求可能来自pod也可能来自外部。kube-proxy部署在每个Node节点上，通过监听集群状态变更，并对本机iptables做修改，从而实现网络路由。 而其中的负载均衡，也是通过iptables的特性实现的。另外我们需要了解k8s中的网络配置类型，有如下几种：hostNetwork Pod使用宿主机上的网络，此时可能端口冲突。
hostPort 宿主机上的端口与Pod的目标端口映射。
NodePort 通过Service访问Pod，并给Service分配一个ClusterIP。

五、deployment/rs的区别

5.1 什么是ReplicaSet？

ReplicaSet是下一代复本控制器。ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持。Replication Controller只支持基于等式的selector（env=dev或environment!=qa），但ReplicaSet还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。在试用时官方推荐ReplicaSet。

大多数kubectl支持Replication Controller的命令也支持ReplicaSets。rolling-update命令有一个例外。如果您想要滚动更新功能，请考虑使用Deployments。此外， rolling-update命令是必须的，而Deployments是声明式的，因此我们建议通过rollout命令使用Deployments。

虽然ReplicaSets可以独立使用，但是今天它主要被 Deployments 作为协调pod创建，删除和更新的机制。当您使用Deployments时，您不必担心管理他们创建的ReplicaSets。Deployments拥有并管理其ReplicaSets。

ReplicaSet可确保指定数量的pod“replicas”在任何设定的时间运行。然而，Deployments是一个更高层次的概念，它管理ReplicaSets，并提供对pod的声明性更新以及许多其他的功能。因此，我们建议您使用Deployments而不是直接使用ReplicaSets，除非您需要自定义更新编排或根本不需要更新。

5.2 Deployment是什么？

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。

你只需要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment，也可以创建一个新的替换旧的Deployment。

一个典型的用例如下：

使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。
然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
扩容Deployment以满足更高的负载。
暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。
根据Deployment 的状态判断上线是否hang住了。
清除旧的不必要的ReplicaSet。

问题：deployment/rs有什么区别。其使用方式、使用条件和原理是什么。deployment是rs的超集，提供更多的部署功能，如：回滚、暂停和重启、 版本记录、事件和状态查看、滚动升级和替换升级。如果能使用deployment，则不应再使用rc和rs。

六、rc/rs实现原理

https://jimmysong.io/kubernetes-handbook/concepts/concepts.html

RC 是 Kubernetes 集群中最早的保证 Pod 高可用的 API 对象。通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本。指定的数目可以是多个也可以是 1 个；少于指定数目，RC 就会启动运行新的 Pod 副本；多于指定数目，RC 就会杀死多余的 Pod 副本。即使在指定数目为 1 的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有 1 个 Pod 在运行。RC 是 Kubernetes 较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的 Web 服务。

RS 是新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用

部署（Deployment）

部署表示用户对 Kubernetes 集群的一次更新操作。部署是一个比 RS 应用模式更广的 API 对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的 RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到 0 的复合操作；这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述。以 Kubernetes 的发展方向，未来对所有长期伺服型的的业务的管理，都会通过 Deployment 来管理。

服务（Service）

RC、RS 和 Deployment 只是保证了支撑服务的微服务 Pod 的数量，但是没有解决如何访问这些服务的问题。一个 Pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的 IP 启动一个新的 Pod，因此不能以确定的 IP 和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在 K8 集群中，客户端需要访问的服务就是 Service 对象。每个 Service 会对应一个集群内部有效的虚拟 IP，集群内部通过虚拟 IP 访问一个服务。在 Kubernetes 集群中微服务的负载均衡是由 Kube-proxy 实现的。Kube-proxy 是 Kubernetes 集群内部的负载均衡器。它是一个分布式代理服务器，在 Kubernetes 的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 Kube-proxy 就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。

任务（Job）

Job 是 Kubernetes 用来控制批处理型任务的 API 对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job 管理的 Pod 根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions 策略而不同：单 Pod 型任务有一个 Pod 成功就标志完成；定数成功型任务保证有 N 个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。

后台支撑服务集（DaemonSet）

长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的 Pod，有些节点上又没有这类 Pod 运行；而后台支撑型服务的核心关注点在 Kubernetes 集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类 Pod 运行。节点可能是所有集群节点也可能是通过 nodeSelector 选定的一些特定节点。典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持 Kubernetes 集群运行的服务。

有状态服务集（StatefulSet）

Kubernetes 在 1.3 版本里发布了 Alpha 版的 PetSet 功能，在 1.5 版本里将 PetSet 功能升级到了 Beta 版本，并重新命名为 StatefulSet，最终在 1.9 版本里成为正式 GA 版本。在云原生应用的体系里，有下面两组近义词；第一组是无状态（stateless）、牲畜（cattle）、无名（nameless）、可丢弃（disposable）；第二组是有状态（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）。RC 和 RS 主要是控制提供无状态服务的，其所控制的 Pod 的名字是随机设置的，一个 Pod 出故障了就被丢弃掉，在另一个地方重启一个新的 Pod，名字变了。名字和启动在哪儿都不重要，重要的只是 Pod 总数；而 StatefulSet 是用来控制有状态服务，StatefulSet 中的每个 Pod 的名字都是事先确定的，不能更改。StatefulSet 中 Pod 的名字的作用，并不是《千与千寻》的人性原因，而是关联与该 Pod 对应的状态。

对于 RC 和 RS 中的 Pod，一般不挂载存储或者挂载共享存储，保存的是所有 Pod 共享的状态，Pod 像牲畜一样没有分别（这似乎也确实意味着失去了人性特征）；对于 StatefulSet 中的 Pod，每个 Pod 挂载自己独立的存储，如果一个 Pod 出现故障，从其他节点启动一个同样名字的 Pod，要挂载上原来 Pod 的存储继续以它的状态提供服务。

适合于 StatefulSet 的业务包括数据库服务 MySQL 和 PostgreSQL，集群化管理服务 ZooKeeper、etcd 等有状态服务。StatefulSet 的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。传统的虚拟机正是一种有状态的宠物，运维人员需要不断地维护它，容器刚开始流行时，我们用容器来模拟虚拟机使用，所有状态都保存在容器里，而这已被证明是非常不安全、不可靠的。使用 StatefulSet，Pod 仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，StatefulSet 做的只是将确定的 Pod 与确定的存储关联起来保证状态的连续性。

集群联邦（Federation）

Kubernetes 在 1.3 版本里发布了 beta 版的 Federation 功能。在云计算环境中，服务的作用距离范围从近到远一般可以有：同主机（Host，Node）、跨主机同可用区（Available Zone）、跨可用区同地区（Region）、跨地区同服务商（Cloud Service Provider）、跨云平台。Kubernetes 的设计定位是单一集群在同一个地域内，因为同一个地区的网络性能才能满足 Kubernetes 的调度和计算存储连接要求。而联合集群服务就是为提供跨 Region 跨服务商 Kubernetes 集群服务而设计的。

每个 Kubernetes Federation 有自己的分布式存储、API Server 和 Controller Manager。用户可以通过 Federation 的 API Server 注册该 Federation 的成员 Kubernetes Cluster。当用户通过 Federation 的 API Server 创建、更改 API 对象时，Federation API Server 会在自己所有注册的子 Kubernetes Cluster 都创建一份对应的 API 对象。在提供业务请求服务时，Kubernetes Federation 会先在自己的各个子 Cluster 之间做负载均衡，而对于发送到某个具体 Kubernetes Cluster 的业务请求，会依照这个 Kubernetes Cluster 独立提供服务时一样的调度模式去做 Kubernetes Cluster 内部的负载均衡。而 Cluster 之间的负载均衡是通过域名服务的负载均衡来实现的。

Federation V1 的设计是尽量不影响 Kubernetes Cluster 现有的工作机制，这样对于每个子 Kubernetes 集群来说，并不需要更外层的有一个 Kubernetes Federation，也就是意味着所有现有的 Kubernetes 代码和机制不需要因为 Federation 功能有任何变化。

目前正在开发的 Federation V2，在保留现有 Kubernetes API 的同时，会开发新的 Federation 专用的 API 接口，详细内容可以在这里找到。

存储卷（Volume）

Kubernetes 集群中的存储卷跟 Docker 的存储卷有些类似，只不过 Docker 的存储卷作用范围为一个容器，而 Kubernetes 的存储卷的生命周期和作用范围是一个 Pod。每个 Pod 中声明的存储卷由 Pod 中的所有容器共享。Kubernetes 支持非常多的存储卷类型，特别的，支持多种公有云平台的存储，包括 AWS，Google 和 Azure 云；支持多种分布式存储包括 GlusterFS 和 Ceph；也支持较容易使用的主机本地目录 emptyDir, hostPath 和 NFS。Kubernetes 还支持使用 Persistent Volume Claim 即 PVC 这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术（例如 AWS，Google 或 GlusterFS 和 Ceph），而将有关存储实际技术的配置交给存储管理员通过 Persistent Volume 来配置。

持久存储卷（Persistent Volume，PV）和持久存储卷声明（Persistent Volume Claim，PVC）

PV 和 PVC 使得 Kubernetes 集群具备了存储的逻辑抽象能力，使得在配置 Pod 的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给 PV 的配置者，即集群的管理者。存储的 PV 和 PVC 的这种关系，跟计算的 Node 和 Pod 的关系是非常类似的；PV 和 Node 是资源的提供者，根据集群的基础设施变化而变化，由 Kubernetes 集群管理员配置；而 PVC 和 Pod 是资源的使用者，根据业务服务的需求变化而变化，有 Kubernetes 集群的使用者即服务的管理员来配置。

节点（Node）

Kubernetes 集群中的计算能力由 Node 提供，最初 Node 称为服务节点 Minion，后来改名为 Node。Kubernetes 集群中的 Node 也就等同于 Mesos 集群中的 Slave 节点，是所有 Pod 运行所在的工作主机，可以是物理机也可以是虚拟机。不论是物理机还是虚拟机，工作主机的统一特征是上面要运行 kubelet 管理节点上运行的容器。

密钥对象（Secret）

Secret 是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用 Secret 的好处是可以避免把敏感信息明文写在配置文件里。在 Kubernetes 集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能，例如访问 AWS 存储的用户名密码。为了避免将类似的敏感信息明文写在所有需要使用的配置文件中，可以将这些信息存入一个 Secret 对象，而在配置文件中通过 Secret 对象引用这些敏感信息。这种方式的好处包括：意图明确，避免重复，减少暴漏机会。

用户帐户（User Account）和服务帐户（Service Account）

顾名思义，用户帐户为人提供账户标识，而服务账户为计算机进程和 Kubernetes 集群中运行的 Pod 提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的 namespace 无关，所以用户账户是跨 namespace 的；而服务帐户对应的是一个运行中程序的身份，与特定 namespace 是相关的。

命名空间（Namespace）

命名空间为 Kubernetes 集群提供虚拟的隔离作用，Kubernetes 集群初始有两个命名空间，分别是默认命名空间 default 和系统命名空间 kube-system，除此以外，管理员可以可以创建新的命名空间满足需要。

RBAC 访问授权

Kubernetes 在 1.3 版本中发布了 alpha 版的基于角色的访问控制（Role-based Access Control，RBAC）的授权模式。相对于基于属性的访问控制（Attribute-based Access Control，ABAC），RBAC 主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。在 ABAC 中，Kubernetes 集群中的访问策略只能跟用户直接关联；而在 RBAC 中，访问策略可以跟某个角色关联，具体的用户在跟一个或多个角色相关联。显然，RBAC 像其他新功能一样，每次引入新功能，都会引入新的 API 对象，从而引入新的概念抽象，而这一新的概念抽象一定会使集群服务管理和使用更容易扩展和重用。

七、某个pod启动的时候需要用到pod的名称，请问怎么获取pod的名称，简要写出对应的yaml配置(考察是否对k8s的Downward API有所了解)

env:
- name: testvalueFrom:fieldRef:fieldPath: metadata.name

某个pod需要配置某个内网服务的hosts，比如数据库的host，刑如：192.168.4.124 db.test.com，请问有什么方法可以解决，简要写出对应的yaml配置或其他解决办法

解决办法：搭建内部的dns，在coredns配置中配置内网dns的IP要是内部没有dns的话，在yaml文件中配置hostAliases，刑如：hostAliases:
- ip: "192.168.4.124"hostnames:- "db.test.com"

请用系统镜像为centos:latest制作一个jdk版本为1.8.142的基础镜像，请写出dockerfile（考察dockerfile的编写能力）

FROM centos:latest
ARG JDK_HOME=/root/jdk1.8.0_142
WORKDIR /root
ADD jdk-8u142-linux-x64.tar.gz /root
ENV JAVA_HOME=/root/jdk1.8.0_142
ENV PATH=$PATH:$JAVA_HOME/bin
CMD ["bash"]

假如某个pod有多个副本，如何让两个pod分布在不同的node节点上，请简要写出对应的yaml文件（考察是否对pod的亲和性有所了解）

affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: "kubernetes.io/hostname"labelSelector:matchLabels:app: test

pod的日志如何收集，简要写出方案(考察是否真正有生产经验，日志收集是必须解决的一个难题)

每个公司的都不一样，下面三个链接可当做参考
https://jimmysong.io/kubernetes-handbook/practice/app-log-collection.html
https://www.jianshu.com/p/92a4c11e77ba
https://haojianxun.github.io/2018/12/21/kubernetes%E5%AE%B9%E5%99%A8%E6%97%A5%E5%BF%97%E6%94%B6%E9%9B%86%E6%96%B9%E6%A1%88/

谈下你对k8s集群监控的心得，口述

集群如何预防雪崩，简要写出必要的集群优化措施

1、为每个pod设置资源限制
2、设置Kubelet资源预留

集群怎么升级，证书过期怎么解决，简要说出做法

参考
https://googlebaba.io/post/2019/09/11-renew-ca-by-kubeadm/   #更新证书https://jicki.me/kubernetes/2019/05/09/kubeadm-1.14.1/       #集群升级

etcd如何备份，简要写出命令

参考：https://www.bladewan.com/2019/01/31/etcd_backup/
export ETCDCTL_API=3
etcdctl --cert=/etc/kubernetes/pki/etcd/server.crt \--key=/etc/kubernetes/pki/etcd/server.key \--cacert=/etc/kubernetes/pki/etcd/ca.crt \snapshot save /data/test-k8s-snapshot.db

在以往的k8s运维中遇到过哪些问题，怎么解决的？

您能否介绍一下Kubernetes中主节点的工作情况？

Kubernetes master控制容器存在的节点和节点内部。现在，这些单独的容器包含在容器内部和每个容器内部，您可以根据配置和要求拥有不同数量的容器。因此，如果必须部署pod，则可以使用用户界面或命令行界面部署它们。然后，在节点上调度这些pod，并根据资源需求，将pod分配给这些节点。kube-apiserver确保在Kubernetes节点和主组件之间建立通信。

kube-apiserver和kube-scheduler的作用是什么？

kube -apiserver遵循横向扩展架构，是主节点控制面板的前端。这将公开Kubernetes主节点组件的所有API，并负责在Kubernetes节点和Kubernetes主组件之间建立通信。kube-scheduler负责工作节点上工作负载的分配和管理。因此，它根据资源需求选择最合适的节点来运行未调度的pod，并跟踪资源利用率。它确保不在已满的节点上调度工作负载。

你能简要介绍一下Kubernetes控制管理器吗

多个控制器进程在主节点上运行，但是一起编译为单个进程运行，即Kubernetes控制器管理器。因此，Controller Manager是一个嵌入控制器并执行命名空间创建和垃圾收集的守护程序。它拥有责任并与API服务器通信以管理端点。因此，主节点上运行的不同类型的控制器管理器是：

什么是ETCD

Etcd是用Go编程语言编写的，是一个分布式键值存储，用于协调分布式工作。因此，Etcd存储Kubernetes集群的配置数据，表示在任何给定时间点的集群状态。

Kubernetes有哪些不同类型的服务？

什么是Ingress网络，它是如何工作的？

Ingress网络是一组规则，充当Kubernetes集群的入口点。这允许入站连接，可以将其配置为通过可访问的URL，负载平衡流量或通过提供基于名称的虚拟主机从外部提供服务。因此，Ingress是一个API对象，通常通过HTTP管理集群中服务的外部访问，是暴露服务的最有效方式。现在，让我以一个例子向您解释Ingress网络的工作。有2个节点具有带有Linux桥接器的pod和根网络命名空间。除此之外，还有一个名为flannel0（网络插件）的新虚拟以太网设备被添加到根网络中。现在，假设我们希望数据包从pod1流向pod 4.请参阅下图。因此，数据包将pod1的网络保留在eth0，并进入veth0的根网络。然后它被传递给cbr0，这使得ARP请求找到目的地，并且发现该节点上没有人具有目的地IP地址。因此，桥接器将数据包发送到flannel0，因为节点的路由表配置了flannel0。现在，flannel守护程序与Kubernetes的API服务器通信，以了解所有pod IP及其各自的节点，以创建pods IP到节点IP的映射。网络插件将此数据包封装在UDP数据包中，其中额外的标头将源和目标IP更改为各自的节点，并通过eth0发送此数据包。现在，由于路由表已经知道如何在节点之间路由流量，因此它将数据包发送到目标节点2。数据包到达node2的eth0并返回到flannel0以解封装并在根网络命名空间中将其发回。同样，数据包被转发到Linux网桥以发出ARP请求以找出属于veth1的IP。数据包最终穿过根网络并到达目标Pod4。

您对云控制器管理器有何了解？

Cloud Controller Manager负责持久存储，网络路由，从核心Kubernetes特定代码中抽象出特定于云的代码，以及管理与底层云服务的通信。它可能会分成几个不同的容器，具体取决于您运行的是哪个云平台，然后它可以使云供应商和Kubernetes代码在没有任何相互依赖的情况下开发。因此，云供应商开发他们的代码并在运行Kubernetes时与Kubernetes云控制器管理器连接。

什么是Container资源监控

对于用户而言，了解应用程序的性能和所有不同抽象层的资源利用率非常重要，Kubernetes通过在容器，pod，服务和整个集群等不同级别创建抽象来考虑集群的管理。现在，可以监视每个级别，这只是容器资源监视。

Replica Set 和 Replication Controller之间有什么区别？

Replica Set 和 Replication Controller几乎完全相同。它们都确保在任何给定时间运行指定数量的pod副本。不同之处在于复制pod使用的选择器。Replica Set使用基于集合的选择器，而Replication Controller使用基于权限的选择器。Equity-Based选择器：这种类型的选择器允许按标签键和值进行过滤。因此，在外行术语中，基于Equity的选择器将仅查找与标签具有完全相同短语的pod。 示例：假设您的标签键表示app = nginx，那么，使用此选择器，您只能查找标签应用程序等于nginx的那些pod。Selector-Based选择器：此类型的选择器允许根据一组值过滤键。因此，换句话说，基于Selector的选择器将查找已在集合中提及其标签的pod。 示例：假设您的标签键在（nginx，NPS，Apache）中显示应用程序。然后，使用此选择器，如果您的应用程序等于任何nginx，NPS或Apache，则选择器将其视为真实结果。

什么是Headless Service？

Headless Service类似于“普通”服务，但没有群集IP。此服务使您可以直接访问pod，而无需通过代理访问它。

使用Kubernetes时可以采取哪些最佳安全措施？

什么是集群联邦？

在联邦集群的帮助下，可以将多个Kubernetes集群作为单个集群进行管理。因此，您可以在数据中心/云中创建多个Kubernetes集群，并使用联邦来在一个位置控制/管理它们。联合集群可以通过执行以下两项操作来实现此目的。请参考下图。

场景1：假设一家基于单一架构的公司处理众多产品。现在，随着公司在当今的扩展行业的扩展，他们的单一架构开始引发问题。您如何看待公司从单一服务转向微服务并部署其服务容器？

由于公司的目标是从单一应用程序转向微服务，它们最终可以逐个构建，并行构建，只需在后台切换配置。然后他们可以将这些内置微服务放在Kubernetes平台上。因此，他们可以从一次或两次迁移服务开始，并监控它们以确保一切运行稳定。一旦他们觉得一切顺利，他们就可以将其余的应用程序迁移到他们的Kubernetes集群中。

考虑一家拥有分布式系统的跨国公司，拥有大量数据中心，虚拟机和许多从事各种任务的员工。您认为这样的公司如何以与Kubernetes一致的方式管理所有任务？

正如我们所有人都知道IT部门推出了数千个容器，其任务在分布式系统中遍布全球众多节点。在这种情况下，公司可以使用能够为基于云的应用程序提供敏捷性，横向扩展功能和DevOps实践的东西。因此，该公司可以使用Kubernetes来定制他们的调度架构并支持多种容器格式。这使得容器任务之间的亲和性成为可能，从而提供更高的效率，并为各种容器网络解决方案和容器存储提供广泛支持。

考虑一种情况，即公司希望通过维持最低成本来提高其效率和技术运营速度。您认为公司将如何实现这一目标？

公司可以通过构建CI/CD管道来实现DevOps方法，但是这里可能出现的一个问题是配置可能需要一段时间才能启动并运行。因此，在实施CI/CD管道之后，公司的下一步应该是在云环境中工作。一旦他们开始处理云环境，他们就可以在集群上安排容器，并可以在Kubernetes的帮助下进行协调。这种方法将有助于公司缩短部署时间，并在各种环境中加快速度。

假设一家公司想要修改它的部署方法，并希望建立一个更具可扩展性和响应性的平台。您如何看待这家公司能够实现这一目标以满足客户需求？

为了给数百万客户提供他们期望的数字体验，公司需要一个可扩展且响应迅速的平台，以便他们能够快速地将数据发送到客户网站。现在，要做到这一点，公司应该从他们的私有数据中心（如果他们使用任何）转移到任何云环境，如AWS。不仅如此，他们还应该实现微服务架构，以便他们可以开始使用Docker容器。一旦他们准备好基础框架，他们就可以开始使用最好的编排平台，即Kubernetes。这将使团队能够自主地构建应用程序并快速交付它们。

考虑一家拥有非常分散的系统的跨国公司，期待解决整体代码库问题。您认为公司如何解决他们的问题？

那么，为了解决这个问题，我们可以将他们的单片代码库转移到微服务设计，然后每个微服务都可以被视为一个容器。因此，所有这些容器都可以在Kubernetes的帮助下进行部署和协调。

我们所有人都知道，从单片到微服务的转变解决了开发方面的问题，但却增加了部署方面的问题。公司如何解决部署方面的问题？

团队可以试验容器编排平台，例如Kubernetes，并在数据中心运行。因此，通过这种方式，公司可以生成模板化应用程序，在五分钟内部署它，并在此时将实际实例集中在暂存环境中。这种Kubernetes项目将有数十个并行运行的微服务，以提高生产率，即使节点出现故障，也可以立即重新安排，而不会影响性能。

假设一家公司希望通过采用新技术来优化其工作负载的分配。公司如何有效地实现这种资源分配？

这个问题的解决方案就是Kubernetes。Kubernetes确保资源得到有效优化，并且只使用特定应用程序所需的那些资源。因此，通过使用最佳容器编排工具，公司可以有效地实现资源分配。

考虑一家拼车公司希望通过同时扩展其平台来增加服务器数量。您认为公司如何处理服务器及其安装？

公司可以采用集装箱化的概念。一旦他们将所有应用程序部署到容器中，他们就可以使用Kubernetes进行编排，并使用像Prometheus这样的容器监视工具来监视容器中的操作。因此，利用容器的这种使用，在数据中心中为它们提供更好的容量规划，因为它们现在将受到更少的限制，因为服务和它们运行的硬件之间存在抽象。

考虑一种情况，公司希望向具有各种环境的客户提供所有必需的分发。您认为他们如何以动态的方式实现这一关键目标？

该公司可以使用Docker环境，组建一个横截面团队，使用Kubernetes构建Web应用程序。这种框架将帮助公司实现在最短的时间内将所需产品投入生产的目标。因此，在这样的机器运行的情况下，公司可以向所有具有各种环境的客户发放电子邮件。

假设公司希望在不同的云基础架构上运行各种工作负载，从裸机到公共云。公司将如何在不同界面的存在下实现这一目标？

该公司可以将其基础设施分解为微服务，然后采用Kubernetes。这将使公司在不同的云基础架构上运行各种工作负载。

什么是Kubernetes集群中的minions？们是集群的工作节点。[答案]

Kubernetes集群数据存储在以下哪个位置？ETCD [答案]

哪个是Kubernetes控制器？ReplicaSet和Deployment [答案]

哪个是核心Kubernetes对象？Pods、Services、 Volumes

Kubernetes Network代理在哪个节点上运行？所有节点[答案]

节点控制器的职责是什么？将CIDR块分配给节点、维护节点列表、监视节点的运行状况

Replication Controller的职责是什么？使用单个命令更新或删除多个pod、有助于达到理想状态、如果现有Pod崩溃，则创建新Pod

如何在没有选择器的情况下定义服务？指定外部名称[答案]

1.8版本的Kubernetes引入了什么？Taints and Tolerations [答案]

Kubelet 调用的处理检查容器的IP地址是否打开的程序是？TCPSocketAction [答案]

Master选择

1-5个节点   4核8G(不建议2核4G)6-20个节点    4核16G21-100个节点  8核32G100-200个节点 16核64G

Service 有四种类型

ClusterIPNodePortLoadBalancer公网IP

POD健康检查

容器存活检查容器就绪检查#方式TCP 端口探测HTTP 请求探测执行命令检查

镜像拉取策略

支持三种 ImagePullPolicyAlways：不管镜像是否存在都会进行一次拉取
Never：不管镜像是否存在都不会进行拉取
IfNotPresent：只有镜像不存在时，才会进行镜像拉取

节点维护

1.封锁节点
封锁（cordon）节点后，将不接受新的 Pod 调度到该节点，您需要手动取消封锁的节点。封锁节点有以下两种方法：2.取消封锁节点
取消封锁（uncordon）节点后，将允许新的 Pod 调度到该节点。3.驱逐节点
在节点上执行维护之前，您可以通过驱逐（drain）节点安全地从节点中逐出 Pod。节点驱逐后，自动将节点内的所有 Pod（不包含 DaemonSet 管理的 Pod）驱逐到集群内其他节点上，并将驱逐的节点设置为封锁状态4.禁止pod调度到该节点上
kubectl cordon <node>5.驱逐该节点上的所有pod
kubectl drain <node>

PV和PVC

PV和PVC
PersistentVolume（PV）：集群内的存储资源，例如节点是集群的资源。PV 独立于 Pod 的生命周期，根据不同的 StorageClass 类型创建不同类型的 PV。
PersistentVolumeClaim（PVC）：集群内的存储请求。例如，PV 是 Pod 使用节点资源，PVC 则声明使用 PV 资源。当 PV 资源不足时，PVC 也可以动态创建 PV

QoS（服务质量等级）

Guaranteed：Pod 里的每个容器都必须有内存/CPU 限制和请求，而且值必须相等。
Burstable：Pod 里至少有一个容器有内存或者 CPU 请求且不满足 Guarantee 等级的要求，即内存/CPU 的值设置的不同。
BestEffort：容器必须没有任何内存或者 CPU 的限制或请求。

1. Kubernetes 常见面试题汇总

简述 Kubernetes 和 Docker 的关系
简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet
简述 Kubernetes 如何实现集群管理
简述 Kubernetes 集群相关组件
简述 Kubernetes Replica Set 和 Replication Controller 之间有什么区别
简述 Kubernetes Pod 的 LivenessProbe 探针的常见方式

2. DevOps & CI/CD 常见面试题汇总

DevOps 术语和定义
实施 DevOps 的原因
如何有效实施 DevOps
如何有效实施 CI/CD
每种术语之间的差异

3. Docker 常见面试题汇总

如何退出一个镜像的 bash，而不终止它
如何查看镜像支持的环境变量
如何控制容器占用系统资源（CPU，内存）的份额
Docker 与 LXC（Linux Container）有何不同
Docker 容器创建后，删除了 /var/run/netns 目录下的网络名字空间文件，可以手动恢复它

k8s的常用的命令的考察

2.1 查看ops这个命名空间下的全部pod，并显示pod的IP地址后端kubectl get pods -n ops -o wide2.2 查看tech命名空间下的pod名称为tech-12ddde-fdfde的日志，并显示最后30行kubectl logs tech-12ddde-fdfde -n tech|tail -n 302.3 怎么查看test的命名空间下pod名称为test-5f7f56bfb7-dw9pw的状态kubectl describe pods test-5f7f56bfb7-dw9pw -n test2.4 如何查看test命名空间下的全部endpointskubectl get ep -n test2.5 如何列出全部 namespace 中的全部 podkubectl get pods --all-namespaces2.六、如何查看test命名空间下的全部ingresskubectl get ingress -n test2.七、如何删除test命名空间下某个deploymemt，名称为gitlabkubectl delete deploy gitlab -n test2.8 如何缩减test命名空间下deployment名称为gitlab的副本数为1kubectl scale deployment gitlab -n test --replicas=12.9 如何在不进入pod内查看命名空间为test,pod名称为test-5f7f56bfb7-dw9pw的hostskubectl exec -it test-5f7f56bfb7-dw9pw -n test -- cat /etc/hosts2.10 如何设置节点test-node-10为不可调度以及如何取消不可调度kubectl cordon test-node-10     #设置test-node-10为不可调度
kubectl uncordon test-node-10   #取消

创建一个pod过程

用户通过 REST API 创建一个 Pod
apiserver 将其写入 etcd
scheduluer 检测到未绑定 Node 的 Pod，开始调度并更新 Pod 的 Node 绑定
kubelet 检测到有新的 Pod 调度过来，通过 container runtime 运行该 Pod
kubelet 通过 container runtime 取到 Pod 状态，并更新到 apiserver 中

什么是Ingress网络，它是如何工作的

Ingress 是允许访问到集群内 Service 的规则的集合，您可以通过配置转发规则，实现不同 URL 可以访问到集群内不同的 Service
A.Ingress controller 有很多，比如 traefik、nginx-controller
B.ingress 对象

排错汇总

a.kubectl：用于查看 Kubernetes 集群以及容器的状态，如 kubectl describe pod b.journalctl：用于查看 Kubernetes 组件日志，如 journalctl -u kubelet -lc.tcpdump：用于排查容器网络问题，如 tcpdump -nn host 10.240.0.8e.Weave Scope 是另外一款可视化容器监控和排错工具Probe 负责收集容器和宿主的信息，并发送给 AppApp 负责处理这些信息，并生成相应的报告，并以交互界面的形式展示参考：https://www.jianshu.com/p/a43f63af3df5kubectl apply -f "https://cloud.weave.works/k8s/scope.yaml?k8s-version=$(kubectl version | base64 | tr -d '\n')&k8s-service-type=NodePort"kubectl get pod -n weavekubectl get svc -n weavekubectl get deploy -n weavef.Kubernetes诊断信息工具参考：https://help.aliyun.com/document_detail/86761.html在 master/worker节点下载诊断脚本，并增加运行权限。curl -o /usr/local/bin/diagnose_k8s.sh http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/diagnose/diagnose_k8s.shchmod u+x /usr/local/bin/diagnose_k8s.shdiagnose_k8s.sh

当Kubernetes集群异常时，只需要在Master节点上收集Kubernetes集群的诊断信息。若Worker节点异常时，则需要分别在Master节点和异常的Worker节点上收集Kubernetes集群的诊断信息。请根据现场实际情况，选择下列对应的步骤：

指定node的节点的调度

指定 Node 节点调度有三种方式指定 Pod 只运行在指定的 Node 节点上nodeSelector：只调度到匹配指定 label 的 Node 上nodeAffinity：功能更丰富的 Node 选择器，比如支持集合操作podAffinity：调度到满足条件的 Pod 所在的 Node 上

常见端口

管理好以下端口。端口   进程  描述4149/TCP  kubelet 用于查询容器监控指标的cAdvisor端口10250/TCP  kubelet 访问节点的API端口10255/TCP kubelet 未认证的只读端口，允许访问节点状态10256/TCP   kube-proxy  kube-proxy的健康检查服务端口9099/TCP calico-felix    calico的健康检查服务端口（如果使用calico/canal）6443/TCP kube-apiserver  Kubernetes API端口

k8s的网络插件与方案

flannel
calico
contiv
weave net
kube-router
cilium
canal

授权管理

 RAM  IAM  CAM  /RBAC角色权限  管理员/运维/开发/受限用户

K8S的对象管理

对象分类
Kubernetes 常用对象主要分为以下类型：工作负载
Deployment：用于管理指定调度规则的 Pod。StatefulSet：管理应用程序的工作负载 API 对象，且该应用程序为有状态的应用程序。DaemonSet：确保所有或部分节点上运行 Pod，例如日志采集程序。Job：一个 Job 创建一个或多个 Pod，直至运行结束。CronJob：定时运行的 Job 任务。服务
Service：提供 Pod 访问的 Kubernetes 对象，可以根据业务需求定义不同类型。Ingress：管理集群中 Services 的外部访问的 Kubernetes 对象。配置ConfigMap：用于保存配置信息。Secret：用于保存敏感信息，例如密码、令牌等。存储Volume：可以存储容器访问相关的数据。Persistent Volumes（PV）：Kubernetes 集群中配置的一块存储。Persistent Volumes Claim（PVC）：请求存储的声明。如果把 PV 比作 Pod，那么 PVC 相当于工作负载。StorageClass：用于描述存储的类型。 创建 PVC 时，通过 StorageClass 创建指定类型的存储，即存储的模板。Kubernetes 对象还包括 Namespaces、HPA、Resource Quotas等数十种，您可以根据业务需要使用不同的
Kubernetes 对象

kubenetes针对pod资源对象的健康监测机制？

K8s中对于pod资源对象的健康状态检测，提供了三类probe（探针）来执行对pod的健康监测：

1） livenessProbe探针
可以根据用户自定义规则来判定pod是否健康，如果livenessProbe探针探测到容器不健康，则kubelet会根据其重启策略来决定是否重启，如果一个容器不包含livenessProbe探针，则kubelet会认为容器的livenessProbe探针的返回值永远成功。2） ReadinessProbe探针
同样是可以根据用户自定义规则来判断pod是否健康，如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功。3） startupProbe探针
启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可。每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败periodSeconds：检查间隔，多久执行probe检查，默认为10s；timeoutSeconds：检查超时时长，探测应用timeout后为失败；successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。

如何控制滚动更新过程？

可以通过下面的命令查看到更新时可以控制的参数：kubectl explain deploy.spec.strategy.rollingUpdate

K8s中镜像的下载策略是什么？

K8s的镜像下载策略有三种：Always、Never、IFNotPresent；Always：镜像标签为latest时，总是从指定的仓库中获取镜像；Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。默认的镜像下载策略是：当镜像标签是latest时，默认策略是Always；当镜像标签是自定义时（也就是标签不是latest），那么默认策略是IfNotPresent。

Service这种资源对象的作用是什么？

用来给相同的多个pod对象提供一个固定的统一访问接口，常用于服务发现和服务访问。Pod每次重启或者重新部署，其IP地址都会产生变化，这使得pod间通信和pod与外部通信变得困难，这时候，就需要Service为pod提供一个固定的入口。Service的Endpoint列表通常绑定了一组相同配置的pod，通过负载均衡的方式把外界请求分配到多个pod上

版本回滚相关的命令？

[root@master httpd-web]# kubectl apply -f httpd2-deploy1.yaml  --record#运行yaml文件，并记录版本信息；
[root@master httpd-web]# kubectl rollout history deployment httpd-devploy1 #查看该deployment的历史版本
[root@master httpd-web]# kubectl rollout undo deployment httpd-devploy1 --to-revision=1    #执行回滚操作，指定回滚到版本1#在yaml文件的spec字段中，可以写以下选项（用于限制最多记录多少个历史版本）：
spec:revisionHistoryLimit: 5
#这个字段通过 kubectl explain deploy.spec  命令找到revisionHistoryLimit   <integer>行获得

常用的标签分类有哪些？

标签分类是可以自定义的，但是为了能使他人可以达到一目了然的效果，一般会使用以下一些分类：版本类标签（release）：stable（稳定版）、canary（金丝雀版本，可以将其称之为测试版中的测试版）、beta（测试版）；环境类标签（environment）：dev（开发）、qa（测试）、production（生产）、op（运维）；应用类（app）：ui、as、pc、sc；架构类（tier）：frontend（前端）、backend（后端）、cache（缓存）；分区标签（partition）：customerA（客户A）、customerB（客户B）；品控级别（Track）：daily（每天）、weekly（每周）。

有几种查看标签的方式？

[root@master ~]# kubectl get pod --show-labels    #查看pod，并且显示标签内容[root@master ~]# kubectl get pod -L env,tier      #显示资源对象标签的值[root@master ~]# kubectl get pod -l env,tier      #只显示符合键值资源对象的pod，而“-L”是显示所有的pod

添加、修改、删除标签的命令？

#对pod标签的操作
[root@master ~]# kubectl label pod label-pod abc=123     #给名为label-pod的pod添加标签[root@master ~]# kubectl label pod label-pod abc=456 --overwrite       #修改名为label-pod的标签[root@master ~]# kubectl label pod label-pod abc-             #删除名为label-pod的标签[root@master ~]# kubectl get pod --show-labels#对node节点的标签操作   [root@master ~]# kubectl label nodes node01 disk=ssd      #给节点node01添加disk标签[root@master ~]# kubectl label nodes node01 disk=sss –overwrite    #修改节点node01的标签[root@master ~]# kubectl label nodes node01 disk-         #删除节点node01的disk标签

DaemonSet资源对象的特性？

DaemonSet这种资源对象会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。所以，在其yaml文件中，不支持定义replicas，除此之外，与Deployment、RS等资源对象的写法相同。它的一般使用场景如下：在去做每个节点的日志收集工作；监控每个节点的的运行状态；

说说你对Job这种资源对象的了解？

Job与其他服务类容器不同，Job是一种工作类容器（一般用于做一次性任务）。使用常见不多，可以忽略这个问题。#提高Job执行效率的方法：
spec:parallelism: 2           #一次运行2个completions: 8           #最多运行8个template:
metadata:

k8s是怎么进行服务注册的？

答：Pod启动后会加载当前环境所有Service信息，以便不同Pod根据Service名进行通信。

k8s集群外流量怎么访问Pod？

答：可以通过Service的NodePort方式访问，会在所有节点监听同一个端口，比如：30000，访问节点的流量会被重定向到对应的Service上面。

k8s数据持久化的方式有哪些？

1）EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由Pod内保部映射到宿主机上。类似于docker中的manager volume。主要使用场景：
1） 只需要临时将数据保存在磁盘上，比如在合并/排序算法中；
2） 作为两个容器的共享存储，使得第一个内容管理的容器可以将生成的数据存入其中，同时由同一个webserver容器对外提供这些页面。
emptyDir的特性：
同个pod里面的不同容器，共享同一个持久化目录，当pod节点删除时，volume的数据也会被删除。如果仅仅是容器被销毁，pod还在，则不会影响volume中的数据。
总结来说：emptyDir的数据持久化的生命周期和使用的pod一致。一般是作为临时存储使用。Hostpath：**将宿主机上已存在的目录或文件挂载到容器内部。类似于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的回收策略：recycle：清除PV的数据，然后自动回收；Retain：需要手动回收；delete：删除云存储资源，云存储专用；#PS：这里的回收策略指的是在PV被删除后，在这个PV下所存储的源文件是否删除）。若需使用PV，那么还有一个重要的概念：PVC，PVC是向PV申请应用所需的容量大小，K8s集群中可能会有多个PV，PVC和PV若要关联，其定义的访问模式必须一致。定义的storageClassName也必须一致，若群集中存在相同的（名字、访问模式都一致）两个PV，那么PVC会选择向它所需容量接近的PV去申请，或者随机申请。

节点生命周期状态说明

状态	说明
健康	节点正常运行，并连接上集群。
异常	节点运行异常，未连接上集群。
已封锁	节点已被封锁，不允许新的 Pod 调度到该节点。
驱逐中	节点正在驱逐 Pod 到其他节点。
其他状态	参考云服务器生命周期。

1.静态pod跟动态pod
2.Svc的node port target port port 关系
3.Hpa的监控指标分母是resource 分子是监控指标
4.Docker build 的时候通过dockerfile 是form容器并且run起来然后增加可写层
5.K8s的svc的nodeport可以设置跳过snat 拿到源ip 这样的话缺点是只有通过pod所在的node 的nodeport可以访问不在的node无法进行访问

6.loadbalance可以对接云api
7.Helm2 3的区别
8.Etcd 2 3 的区别
9.Etc目录权限修改的后果
10.Sudo权限修改错误然后且换普通用户如何修改
11.Istio link 的安全
12.代码仓库
13.镜像仓库
14.K8s迁移
15.Helm目录结构
16.Ci/cd的流程
17.Pod的生命周期
18.Shell python 如何区别私有ip公网ip
19.Awk 筛选第几行第几列如何筛选 NR
20.如果发现系统卡顿如何排查以及命令是如何
21.如何查看nfs 以及其他的挂载情况
df mount
22.docker compose 写容器启动顺序

k8s的controller如何进行leader选举，k8s如何保证主从模式的controller不成为集群性能瓶颈
leader选举机制。

controller选举 一般默认锁类型是endpoint资源，这个endpoint的annotations会有锁租约，谁占有这个锁，最后更新时间等信息，如果集群中的某一个节点想要成为leader，就需要先get这个endpoint，查看annotations中的信息，看leader是否过期，如果没有国企，申请leader失败，update之所以可能失败，是因为乐观锁保证本节点的get和update操作之间没有别的节点做update操作目前官方的说法一个k8s 最大支持5000节点，瓶颈不在于controller，etcd，调度器，apiserver会更容易成为瓶颈，默认的调度器不支持多pod同时调度，而且client-go做了大量的优化，包括cache，shardinformer

1.如何在 Kubernetes 中实现负载均衡？
Service会自带负载均衡的endpoint，ipvs或者iptables，ipvs的话性能好一点，iptables是概率的方式，不是很好用，
2.在生产中，你如何实现 Kubernetes 自动化？
使用jenkins开发流水线或者使用shell脚本
3.你如何扩展 Kubernetes 集群？
看安装方式如果是adm直接生成token以及就可以让node加入集群中，master的话需要把配置全部scp至新的node节点然后起来kubelet和proxy以及网络插件以后master授权
4.你能解释 Deployment、ReplicaSets、StatefulSets、Pod、CronJob 的不同用途吗？
Cronjob跟linux的crtab是类似的可以做批处理
Deployment具有上线部署、副本设定、滚动升级、回滚等功能

Rs的话他的功能被deployment包含了创建deployment控制器的时候他默认会自动来一个rs
Statefulset有状态的控制器一般是做有状态的应用部署比如redis以及mysql或者zk这种的
Pod是集群的最小单元，
5.Kubernetes 如何处理持久性？
可以使用pvc以及pv做持久化数据，可以自动也可以手动
6.服务和 ingress 的作用是什么？
Ingress可以作为一个7层调度器，可以保存ssl证书，这样的话从外部到ingress这一段用https通信，对pod使用http通信，就不用让pod做ssl会话了，service的Nodeport是不具备这个功能的，而且ingress可以加一些比如nginx他自身的参数，我们也知道nginx还是很强大的
7.你何时会使用像 ConfigMap 或 secret 这样的东西？
Configmap的话需要做配置统一的话会考虑用这个，通过修改configmap来做热加载或者重启pod让他生效，比如部署Prometheus的时候就用的configmap，Prometheus的自动发现功能还是很好用的
Secret的话一般是存储ssl证书的配置或者是存docker的镜像仓库凭证
8.Pod 亲和性作用是什么？
可以根据pod亲和来让pod指定运行在那个node节点上比如pod和pod亲和比如pod和node亲和
9.你能举例说明何时使用 Init Container 么？
Init是初始化容器，为这个初始化一个环境，没有很用过这个，
10.什么是 sidecar 容器？你能给出一个用例，说明你为什么要使用它么？
ServiceMesaher
11.在构建和管理生产集群时遇到的主要问题是什么？
容器雪崩（最后又介绍）
12.什么是 Istio 和 Linkerd？
istio在我的istio专栏有介绍
13.什么是 Kubernetes Operator？
是前辈们写好的程序，类似于一个自动部署集群的方式吧，
14.kubernetes包含几个组件。各个组件的功能是什么。组件之间是如何交互的。
kube-apiserver Kubernetes API，集群的统一入口，各组件协调者，以RESTful API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给 Etcd存储。 
kube-controller-manager 处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager 就是负责管理这些控制器的。 
kube-scheduler 根据调度算法为新创建的Pod选择一个Node节点，可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上。 
etcd 分布式键值存储系统。用于保存集群状态数据，比如Pod、Service等对象信息。
kubelet kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。
kube-proxy 在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。  docker或rocket 容器引擎，运行容器。

15.k8s的pause容器有什么用。是否可以去掉。
不可以生成每个pod的同时会生成pause，是一个pod的网络总入口
16.k8s中的pod内几个容器之间的关系是什么。
共享网络命名空间
17.一个经典pod的完整生命周期。
Init初始化容器初始化环境，然后启动pod，在启动的时候会有启动钩子做启动后的操作，然后经过健康监测以及资源限制，在关闭的时候会有关闭钩子。表示关闭前做一些操作，比如睡几秒在关，为什么睡几秒后面又介绍
18.k8s的service和ep是如何关联和相互影响的。
Service和ep通过svc的名字关联，svc和pod通过标签选择器
19.详述kube-proxy原理, -个请求是如何经过层层转发落到某个pod.上的整个过程。请求可能来自pod也可能来自外部。
Proxy是管理整个节点的网络状态，请求交给第一层的4层负载，4层负载转发至ingress或者service的nodeport也就是node的外放端口，然后交给pod
20.rc/rs功能是怎么实现的。详述从API接收到-一个创建rc/rs的请求,到最终在节点上创建pod的全过程,尽可能详细。另外,当-个pod失效时，kubernetes是如何发现并重启另一个pod的?
用户创建的请求跟api交互在认证授权通过之后，api会把数据写入etcd并联系scheduler，给他根据调度算法，查看每个节点状态确定往哪一个节点调度，然后api与该节点的kubelet交互并把相关的数据写入etcd，kubelet调用底层的docker来根据配置清单创建容器
21.cgroup中的cpu有哪几种限制方式。 k8s是如何使用实现request和limit的。
软硬也就是request和limit，预配值以及最大限制，实现的话还是转化为底层的docker，使用docker的限制方式实现的。

以下列举的内容都是 Kubernetes 中的对象（Object），这些对象都可以在 YAML 文件中作为一种 API 类型来配置。

Pod
Node
Namespace
Service
Volume
PersistentVolume
Deployment
Secret
StatefulSet
DaemonSet
ServiceAccount
ReplicationController
ReplicaSet
Job
CronJob
SecurityContext
ResourceQuota
LimitRange
HorizontalPodAutoscaling
Ingress
ConfigMap
Label
CustomResourceDefinition
Role
ClusterRole

类别	名称
资源对象	Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、CustomResourceDefinition
存储对象	Volume、PersistentVolume、Secret、ConfigMap
策略对象	SecurityContext、ResourceQuota、LimitRange
身份对象	ServiceAccount、Role、ClusterRole

参考博文

面试题—Kubernetes(二)_屈帅波的技术博客-CSDN博客

k8s面试题 - caibutou - 博客园

k8s 超详细总结，面试必问_huakai_sun的博客-CSDN博客_kubernetes面试

Kubernetes——面试问题全集相关推荐

java面试题目全集------转载
以前的收藏,估计很少有这么全的面试题集了 ^_^ 基础知识: 1.C++或Java中的异常处理机制的简单原理和应用. 当JAVA程序违反了JAVA的语义规则时,JAVA虚拟机就会将发生的错误表示为一个 ...
java与servlet JSP_java面试精品全集[jsp与servlet部分]
一.Jsp方面 1.forward 和redirect的区别答:forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器,浏览器根本 ...
java面试别人总结博客链接
一.java上中下面试提全集 Java面试题全集(上) Java面试题全集(中) Java面试题全集(下)
后端必备的200本书，一次性给你！
这段时间,我给大家整理一份后端必读书籍(电子版),一共200多本,大家一起来看下,文末有获取方式书籍分类面试手册 <JAVA面试题解惑系列> <程序员面试经典> <2 ...
8s pod 查看的yaml_Kubernetes入门到实战（五）深入浅出详解Pod
作者:Happy老师链接:https://blog.51cto.com/happylab/2500457 写在前面前面的系列文章已介绍kubernetes架构,安装,升级和快速入门,读者通过文章的 ...
linux unlink 与 rm区别_从 lsof 开始，深入理解 Linux 虚拟文件系统
背景有时会出现这样的情况,磁盘空间显示已经被占满,但是在查看磁盘的具体文件占用情况时,发现磁盘仍然有很大的空余空间.1.执行df命令查看磁盘使用情况,发现磁盘已经满了. -bash-4.2$ df ...
K8S 常见面试题总结
作者:fiisio 译文:https://zhuanlan.zhihu.com/p/74560934 Kubernetes一直是当今业界的流行语,也是最好的编排工具.它吸引了许多想要提升自己职业生涯的 ...
Redis 大数据量（百亿级）Key存储需求及解决方案
点击下方公众号「关注」和「星标」回复"1024"获取独家整理的学习资料! 最近我在思考实时数仓问题的时候,想到了巨量的redis的存储的问题,然后翻阅到这篇文章,与各位分享. 需 ...
太赞了！华为工程师总结的Linux+K8S笔记，提供下载
最近很多小伙伴找我要一些 Linux 和 K8S 基础资料,于是我翻箱倒柜,把这份华为大牛总结的 Linux 归纳笔记找出来,另外还有一份Kubernetes 学习资料免费共享给大家! 据说有小伙伴靠 ...

Kubernetes——面试问题全集

摘要