docker的工作原理是什么，讲一下
docker是一个Client-Server结构的系统，docker守护进程运行在宿主机上，守护进程从客户端接受命令并管理运行在主机上的容器，容器是一个运行时环境，这就是我们说的集装箱。

docker的组成包含哪几大部分
一个完整的docker有以下几个部分组成：
1、docker client，客户端，为用户提供一系列可执行命令，用户用这些命令实现跟 docker daemon 交互；
2、docker daemon，守护进程，一般在宿主主机后台运行，等待接收来自客户端的请求消息；
3、docker image，镜像，镜像run之后就生成为docker容器；
4、docker container，容器，一个系统级别的服务，拥有自己的ip和系统目录结构；运行容器前需要本地存在对应的镜像，如果本地不存在该镜像则就去镜像仓库下载。

docker 使用客户端-服务器 (C/S) 架构模式，使用远程api来管理和创建docker容器。docker 容器通过 docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。

docker与传统虚拟机的区别什么？
1、传统虚拟机是需要安装整个操作系统的，然后再在上面安装业务应用，启动应用，通常需要几分钟去启动应用，而docker是直接使用镜像来运行业务容器的，其容器启动属于秒级别；
2、Docker需要的资源更少，Docker在操作系统级别进行虚拟化，Docker容器和内核交互，几乎没有性能损耗，而虚拟机运行着整个操作系统，占用物理机的资源就比较多;
3、Docker更轻量，Docker的架构可以共用一个内核与共享应用程序库，所占内存极小;同样的硬件环境，Docker运行的镜像数远多于虚拟机数量，对系统的利用率非常高;
4、与虚拟机相比，Docker隔离性更弱，Docker属于进程之间的隔离，虚拟机可实现系统级别隔离;
5、Docker的安全性也更弱，Docker的租户root和宿主机root相同，一旦容器内的用户从普通用户权限提升为root权限，它就直接具备了宿主机的root权限，进而可进行无限制的操作。虚拟机租户root权限和宿主机的root虚拟机权限是分离的，并且虚拟机利用如Intel的VT-d和VT-x的ring-1硬件隔离技术，这种技术可以防止虚拟机突破和彼此交互，而容器至今还没有任何形式的硬件隔离;
6、Docker的集中化管理工具还不算成熟，各种虚拟化技术都有成熟的管理工具，比如：VMware vCenter提供完备的虚拟机管理能力;
7、Docker对业务的高可用支持是通过快速重新部署实现的，虚拟化具备负载均衡，高可用、容错、迁移和数据保护等经过生产实践检验的成熟保障机制，Vmware可承诺虚拟机99.999%高可用，保证业务连续性;
8、虚拟化创建是分钟级别的，Docker容器创建是秒级别的，Docker的快速迭代性，决定了无论是开发、测试、部署都可以节省大量时间;
9、虚拟机可以通过镜像实现环境交付的一致性，但镜像分发无法体系化，Docker在Dockerfile中记录了容器构建过程，可在集群中实现快速分发和快速部署。

docker技术的三大核心概念是什么？
镜像：镜像是一种轻量级、可执行的独立软件包，它包含运行某个软件所需的所有内容，我们把应用程序和配置依赖打包好形成一个可交付的运行环境(包括代码、运行时需要的库、环境变量和配置文件等)，这个打包好的运行环境就是image镜像文件。
容器：容器是基于镜像创建的，是镜像运行起来之后的一个实例，容器才是真正运行业务程序的地方。如果把镜像比作程序里面的类，那么容器就是对象。
镜像仓库：存放镜像的地方，研发工程师打包好镜像之后需要把镜像上传到镜像仓库中去，然后就可以运行有仓库权限的人拉取镜像来运行容器了。

centos镜像几个G，但是docker centos镜像才几百兆，这是为什么？
一个完整的Linux操作系统包含Linux内核和rootfs根文件系统，即我们熟悉的/dev、/proc/、/bin等目录。我们平时看到的centOS除了rootfs，还会选装很多软件，服务，图形桌面等，所以centOS镜像有好几个G也不足为奇。
而对于容器镜像而言，所有容器都是共享宿主机的Linux 内核的，而对于docker镜像而言，docker镜像只需要提供一个很小的rootfs即可，只需要包含最基本的命令，工具，程序库即可，所有docker镜像才会这么小。

讲一下镜像的分层结构以及为什么要使用镜像的分层结构？
一个新的镜像其实是从 base 镜像一层一层叠加生成的。每安装一个软件，dockerfile中使用RUM命令，就会在现有镜像的基础上增加一层，这样一层一层的叠加最后构成整个镜像。所以我们docker pull拉取一个镜像的时候会看到docker是一层层拉去的。

分层机构最大的一个好处就是 ： 共享资源。比如：有多个镜像都从相同的 base 镜像构建而来，那么 Docker Host 只需在磁盘上保存一份 base 镜像；同时内存中也只需加载一份 base 镜像，就可以为所有容器服务了。而且镜像的每一层都可以被共享。

讲一下容器的copy-on-write特性，修改容器里面的内容会修改镜像吗？
我们知道，镜像是分层的，镜像的每一层都可以被共享，同时，镜像是只读的。当一个容器启动时，一个新的可写层被加载到镜像的顶部，这一层通常被称作“容器层”，“容器层”之下的都叫“镜像层”。

所有对容器的改动 - 无论添加、删除、还是修改文件，都只会发生在容器层中，因为只有容器层是可写的，容器层下面的所有镜像层都是只读的。镜像层数量可能会很多，所有镜像层会联合在一起组成一个统一的文件系统。如果不同层中有一个相同路径的文件，比如 /a，上层的 /a 会覆盖下层的 /a，也就是说用户只能访问到上层中的文件 /a。在容器层中，用户看到的是一个叠加之后的文件系统。

添加文件时：在容器中创建文件时，新文件被添加到容器层中。
读取文件：在容器中读取某个文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后打开并读入内存。
修改文件：在容器中修改已存在的文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后修改之。
删除文件：在容器中删除文件时，Docker 也是从上往下依次在镜像层中查找此文件。找到后，会在容器层中记录下此删除操作。

只有当需要修改时才复制一份数据，这种特性被称作 Copy-on-Write。可见，容器层保存的是镜像变化的部分，不会对镜像本身进行任何修改。

简单描述一下Dockerfile的整个构建镜像过程
好的。
1、首先，创建一个目录用于存放应用程序以及构建过程中使用到的各个文件等；
2、然后，在这个目录下创建一个Dockerfile文件，一般建议Dockerfile的文件名就是Dockerfile；
3、编写Dockerfile文件，编写指令，如，使用FROM 指令指定基础镜像，COPY指令复制文件，RUN指令指定要运行的命令，ENV设置环境变量，EXPOSE指定容器要暴露的端口，WORKDIR设置当前工作目录，CMD容器启动时运行命令，等等指令构建镜像；
4、Dockerfile编写完成就可以构建镜像了，使用docker build -t 镜像名:tag . 命令来构建镜像，最后一个点是表示当前目录，docker会默认寻找当前目录下的Dockerfile文件来构建镜像，如果不使用默认，可以使用-f参数来指定dockerfile文件，如：docker build -t 镜像名:tag -f /xx/xxx/Dockerfile ；
5、使用docker build命令构建之后，docker就会将当前目录下所有的文件发送给docker daemon，顺序执行Dockerfile文件里的指令，在这过程中会生成临时容器，在临时容器里面安装RUN指定的命令，安装成功后，docker底层会使用类似于docker commit命令来将容器保存为镜像，然后删除临时容器，以此类推，一层层的构建镜像，运行临时容器安装软件，直到最后的镜像构建成功。

Dockerfile构建镜像出现异常，如何排查？
首先，Dockerfile是一层一层的构建镜像，期间会产生一个或多个临时容器，构建过程中其实就是在临时容器里面安装应用，如果因为临时容器安装应用出现异常导致镜像构建失败，这时容器虽然被清理掉了，但是期间构建的中间镜像还在，那么我们可以根据异常时上一层已经构建好的临时镜像，将临时镜像运行为容器，然后在容器里面运行安装命令来定位具体的异常。

Dockerfile的基本指令有哪些？
FROM 指定基础镜像（必须为第一个指令，因为需要指定使用哪个基础镜像来构建镜像）；
MAINTAINER 设置镜像作者相关信息，如作者名字，日期，邮件，联系方式等；
COPY 复制文件到镜像；
ADD 复制文件到镜像（ADD与COPY的区别在于，ADD会自动解压tar、zip、tgz、xz等归档文件，而COPY不会，同时ADD指令还可以接一个url下载文件地址，一般建议使用COPY复制文件即可，文件在宿主机上是什么样子复制到镜像里面就是什么样子这样比较好）；
ENV 设置环境变量；
EXPOSE 暴露容器进程的端口，仅仅是提示别人容器使用的哪个端口，没有过多作用；
VOLUME 数据卷持久化，挂载一个目录；
WORKDIR 设置工作目录，如果目录不在，则会自动创建目录；
RUN 在容器中运行命令，RUN指令会创建新的镜像层，RUN指令经常被用于安装软件包；
CMD 指定容器启动时默认运行哪些命令，如果有多个CMD，则只有最后一个生效，另外，CMD指令可以被docker run之后的参数替换；
ENTRYOINT 指定容器启动时运行哪些命令，如果有多个ENTRYOINT，则只有最后一个生效，另外，如果Dockerfile中同时存在CMD和ENTRYOINT，那么CMD或docker run之后的参数将被当做参数传递给ENTRYOINT；

如何进入容器？使用哪个命令
进入容器有两种方法：docker attach、docker exec；
docker attach命令是attach到容器启动命令的终端，docker exec 是另外在容器里面启动一个TTY终端。

docker run -d centos /bin/bash -c "while true;do sleep 2;echo I_am_a_container;done"
3274412d88ca4f1d1292f6d28d46f39c14c733da5a4085c11c6a854d30d1cde0
docker attach 3274412d88ca4f                        #attach进入容器
Ctrl + c  退出，Ctrl + c会直接关闭容器终端，这样容器没有进程一直在前台运行就会死掉了
Ctrl + pq 退出（不会关闭容器终端停止容器，仅退出）

docker exec -it 3274412d88ca /bin/bash                #exec进入容器    
[root@3274412d88ca /]# ps -ef                        #进入到容器了开启了一个bash进程
UID         PID   PPID  C STIME TTY          TIME CMD
root          1      0  0 05:31 ?        00:00:01 /bin/bash -c while true;do sleep 2;echo I_am_a_container;done
root        306      0  1 05:41 pts/0    00:00:00 /bin/bash
root        322      1  0 05:41 ?        00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 2
root        323    306  0 05:41 pts/0    00:00:00 ps -ef
[root@3274412d88ca /]#exit                            #退出容器，仅退出我们自己的bash窗口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
小结：attach是直接进入容器启动命令的终端，不会启动新的进程；exec则是在容器里面打开新的终端，会启动新的进程；一般建议已经exec进入容器。

什么是k8s？说出你的理解
K8s是kubernetes的简称，其本质是一个开源的容器编排系统，主要用于管理容器化的应用，其目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。
说简单点：k8s就是一个编排容器的系统，一个可以管理容器应用全生命周期的工具，从创建应用，应用的部署，应用提供服务，扩容缩容应用，应用更新，都非常的方便，而且还可以做到故障自愈，所以，k8s是一个非常强大的容器编排系统。

k8s的组件有哪些，作用分别是什么？
k8s主要由master节点和node节点构成。master节点负责管理集群，node节点是容器应用真正运行的地方。
master节点包含的组件有：kube-api-server、kube-controller-manager、kube-scheduler、etcd。
node节点包含的组件有：kubelet、kube-proxy、container-runtime。

kube-api-server：以下简称api-server，api-server是k8s最重要的核心组件之一，它是k8s集群管理的统一访问入口，提供了RESTful API接口, 实现了认证、授权和准入控制等安全功能；api-server还是其他组件之间的数据交互和通信的枢纽，其他组件彼此之间并不会直接通信，其他组件对资源对象的增、删、改、查和监听操作都是交由api-server处理后，api-server再提交给etcd数据库做持久化存储，只有api-server才能直接操作etcd数据库，其他组件都不能直接操作etcd数据库，其他组件都是通过api-server间接的读取，写入数据到etcd。

kube-controller-manager：以下简称controller-manager，controller-manager是k8s中各种控制器的的管理者，是k8s集群内部的管理控制中心，也是k8s自动化功能的核心；controller-manager内部包含replication controller、node controller、deployment controller、endpoint controller等各种资源对象的控制器，每种控制器都负责一种特定资源的控制流程，而controller-manager正是这些controller的核心管理者。

kube-scheduler：以下简称scheduler，scheduler负责集群资源调度，其作用是将待调度的pod通过一系列复杂的调度算法计算出最合适的node节点，然后将pod绑定到目标节点上。shceduler会根据pod的信息，全部节点信息列表，过滤掉不符合要求的节点，过滤出一批候选节点，然后给候选节点打分，选分最高的就是最佳节点，scheduler就会把目标pod安置到该节点。

Etcd：etcd是一个分布式的键值对存储数据库，主要是用于保存k8s集群状态数据，比如，pod，service等资源对象的信息；etcd可以是单个也可以有多个，多个就是etcd数据库集群，etcd通常部署奇数个实例，在大规模集群中，etcd有5个或7个节点就足够了；另外说明一点，etcd本质上可以不与master节点部署在一起，只要master节点能通过网络连接etcd数据库即可。

kubelet：每个node节点上都有一个kubelet服务进程，kubelet作为连接master和各node之间的桥梁，负责维护pod和容器的生命周期，当监听到master下发到本节点的任务时，比如创建、更新、终止pod等任务，kubelet 即通过控制docker来创建、更新、销毁容器；
每个kubelet进程都会在api-server上注册本节点自身的信息，用于定期向master汇报本节点资源的使用情况。

kube-proxy：kube-proxy运行在node节点上，在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作，kube-proxy会监听api-server中从而获取service和endpoint的变化情况，创建并维护路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。

container-runtime：容器运行时环境，即运行容器所需要的一系列程序，目前k8s支持的容器运行时有很多，如docker、rkt或其他，比较受欢迎的是docker，但是新版的k8s已经宣布弃用docker。

kubelet的功能、作用是什么？（重点，经常会问）
答：kubelet部署在每个node节点上的，它主要有2个功能：
1、节点管理。kubelet启动时会向api-server进行注册，然后会定时的向api-server汇报本节点信息状态，资源使用状态等，这样master就能够知道node节点的资源剩余，节点是否失联等等相关的信息了。master知道了整个集群所有节点的资源情况，这对于 pod 的调度和正常运行至关重要。
2、pod管理。kubelet负责维护node节点上pod的生命周期，当kubelet监听到master的下发到自己节点的任务时，比如要创建、更新、删除一个pod，kubelet 就会通过CRI（容器运行时接口）插件来调用不同的容器运行时来创建、更新、删除容器；常见的容器运行时有docker、containerd、rkt等等这些容器运行时，我们最熟悉的就是docker了，但在新版本的k8s已经弃用docker了，k8s1.24版本中已经使用containerd作为容器运行时了。
3、容器健康检查。pod中可以定义启动探针、存活探针、就绪探针等3种，我们最常用的就是存活探针、就绪探针，kubelet 会定期调用容器中的探针来检测容器是否存活，是否就绪，如果是存活探针，则会根据探测结果对检查失败的容器进行相应的重启策略；
4、Metrics Server资源监控。在node节点上部署Metrics Server用于监控node节点、pod的CPU、内存、文件系统、网络使用等资源使用情况，而kubelet则通过Metrics Server获取所在节点及容器的上的数据。

kube-api-server的端口是多少？各个pod是如何访问kube-api-server的？
kube-api-server的端口是8080和6443，前者是http的端口，后者是https的端口，以我本机使用kubeadm安装的k8s为例：
在命名空间的kube-system命名空间里，有一个名称为kube-api-master的pod，这个pod就是运行着kube-api-server进程，它绑定了master主机的ip地址和6443端口，但是在default命名空间下，存在一个叫kubernetes的服务，该服务对外暴露端口为443，目标端口6443，这个服务的ip地址是clusterip地址池里面的第一个地址，同时这个服务的yaml定义里面并没有指定标签选择器，也就是说这个kubernetes服务所对应的endpoint是手动创建的，该endpoint也是名称叫做kubernetes，该endpoint的yaml定义里面代理到master节点的6443端口，也就是kube-api-server的IP和端口。这样一来，其他pod访问kube-api-server的整个流程就是：pod创建后嵌入了环境变量，pod获取到了kubernetes这个服务的ip和443端口，请求到kubernetes这个服务其实就是转发到了master节点上的6443端口的kube-api-server这个pod里面。

k8s中命名空间的作用是什么？
amespace是kubernetes系统中的一种非常重要的资源，namespace的主要作用是用来实现多套环境的资源隔离，或者说是多租户的资源隔离。
k8s通过将集群内部的资源分配到不同的namespace中，可以形成逻辑上的隔离，以方便不同的资源进行隔离使用和管理。不同的命名空间可以存在同名的资源，命名空间为资源提供了一个作用域。
可以通过k8s的授权机制，将不同的namespace交给不同的租户进行管理，这样就实现了多租户的资源隔离，还可以结合k8s的资源配额机制，限定不同的租户能占用的资源，例如CPU使用量、内存使用量等等来实现租户可用资源的管理。

k8s提供了大量的REST接口，其中有一个是Kubernetes Proxy API接口，简述一下这个Proxy接口的作用，已经怎么使用。
好的。kubernetes proxy api接口，从名称中可以得知，proxy是代理的意思，其作用就是代理rest请求；Kubernets API server 将接收到的rest请求转发到某个node上的kubelet守护进程的rest接口，由该kubelet进程负责响应。我们可以使用这种Proxy接口来直接访问某个pod，这对于逐一排查pod异常问题很有帮助。
下面是一些简单的例子：

http://<kube-api-server>:<api-sever-port>/api/v1/nodes/node名称/proxy/pods      #查看指定node的所有pod信息
http://<kube-api-server>:<api-sever-port>/api/v1/nodes/node名称/proxy/stats      #查看指定node的物理资源统计信息
http://<kube-api-server>:<api-sever-port>/api/v1/nodes/node名称/proxy/spec      #查看指定node的概要信息

http://<kube-api-server>:<api-sever-port>/api/v1/namespace/命名名称/pods/pod名称/pod服务的url/      #访问指定pod的程序页面
http://<kube-api-server>:<api-sever-port>/api/v1/namespace/命名名称/servers/svc名称/url/      #访问指定server的url程序页面
1
2
3
4
5
6
pod是什么？
在kubernetes的世界中，k8s并不直接处理容器，而是使用多个容器共存的理念，这组容器就叫做pod。pod是k8s中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，其他的资源对象都是用来支撑pod对象功能的，比如，pod控制器就是用来管理pod对象的，service或者imgress资源对象是用来暴露pod引用对象的，persistentvolume资源是用来为pod提供存储等等，简而言之，k8s不会直接处理容器，而是pod，pod才是k8s中可以创建和管理的最小单元，也是基本单元。

pod的原理是什么？
在微服务的概念里，一般的，一个容器会被设计为运行一个进程，除非进程本身产生子进程，这样，由于不能将多个进程聚集在同一个单独的容器中，所以需要一种更高级的结构将容器绑定在一起，并将它们作为一个单元进行管理，这就是k8s中pod的背后原理。

pod有什么特点？
1、每个pod就像一个独立的逻辑机器，k8s会为每个pod分配一个集群内部唯一的IP地址，所以每个pod都拥有自己的IP地址、主机名、进程等；
2、一个pod可以包含1个或多个容器，1个容器一般被设计成只运行1个进程，1个pod只可能运行在单个节点上，即不可能1个pod跨节点运行，pod的生命周期是短暂，也就是说pod可能随时被消亡（如节点异常，pod异常等情况）；
2、每一个pod都有一个特殊的被称为"根容器"的pause容器，也称info容器，pause容器对应的镜像属于k8s平台的一部分，除了pause容器，每个pod还包含一个或多个跑业务相关组件的应用容器；
3、一个pod中的容器共享network命名空间；
4、一个pod里的多个容器共享pod IP，这就意味着1个pod里面的多个容器的进程所占用的端口不能相同，否则在这个pod里面就会产生端口冲突；既然每个pod都有自己的IP和端口空间，那么对不同的两个pod来说就不可能存在端口冲突；
5、应该将应用程序组织到多个pod中，而每个pod只包含紧密相关的组件或进程；
6、pod是k8s中扩容、缩容的基本单位，也就是说k8s中扩容缩容是针对pod而言而非容器。
1
2
3
4
5
6
7
pause容器作用是什么？
每个pod里运行着一个特殊的被称之为pause的容器，也称根容器，而其他容器则称为业务容器；创建pause容器主要是为了为业务容器提供 Linux命名空间，共享基础：包括 pid、icp、net 等，以及启动 init 进程，并收割僵尸进程；这些业务容器共享pause容器的网络命名空间和volume挂载卷，当pod被创建时，pod首先会创建pause容器，从而把其他业务容器加入pause容器，从而让所有业务容器都在同一个命名空间中，这样可以就可以实现网络共享。pod还可以共享存储，在pod级别引入数据卷volume，业务容器都可以挂载这个数据卷从而实现持久化存储。

pod的重启策略有哪些？
pod重启容器策略是指针对pod内所有容器的重启策略，不是重启pod，其可以通过restartPolicy字段配置pod重启容器的策略，如下：

Always: 当容器终止退出后，总是重启容器，默认策略就是Always。
OnFailure: 当容器异常退出，退出状态码非0时，才重启容器。
Never: 当容器终止退出，不管退出状态码是什么，从不重启容器。
1
2
3
pod的镜像拉取策略有哪几种？
pod镜像拉取策略可以通过imagePullPolicy字段配置镜像拉取策略，主要有3中镜像拉取策略，如下：

IfNotPresent: 默认值，镜像在node节点宿主机上不存在时才拉取。
Always: 总是重新拉取，即每次创建pod都会重新从镜像仓库拉取一次镜像。
Never: 永远不会主动拉取镜像，仅使用本地镜像，需要你手动拉取镜像到node节点，如果node节点不存在镜像则pod启动失败。
1
2
3
pod的存活探针有哪几种？（必须记住3重探测方式，重点，经常问）
kubernetes可以通过存活探针检查容器是否还在运行，可以为pod中的每个容器单独定义存活探针，kubernetes将定期执行探针，如果探测失败，将杀死容器，并根据restartPolicy策略来决定是否重启容器，kubernetes提供了3种探测容器的存活探针，如下：

httpGet：通过容器的IP、端口、路径发送http 请求，返回200-400范围内的状态码表示成功。
exec：在容器内执行shell命令，根据命令退出状态码是否为0进行判断，0表示健康，非0表示不健康。
TCPSocket：与容器的IP、端口建立TCP Socket链接，能建立则说明探测成功，不能建立则说明探测失败。
1
2
3
存活探针的属性参数有哪几个？
存活探针的附加属性参数有以下几个：

initialDelaySeconds：表示在容器启动后延时多久秒才开始探测；
periodSeconds：表示执行探测的频率，即间隔多少秒探测一次，默认间隔周期是10秒，最小1秒；
timeoutSeconds：表示探测超时时间，默认1秒，最小1秒，表示容器必须在超时时间范围内做出响应，否则视为本次探测失败；
successThreshold：表示最少连续探测成功多少次才被认定为成功，默认是1，对于liveness必须是1，最小值是1；
failureThreshold：表示连续探测失败多少次才被认定为失败，默认是3，连续3次失败，k8s 将根据pod重启策略对容器做出决定；

注意：定义存活探针时，一定要设置initialDelaySeconds属性，该属性为初始延时，如果不设置，默认容器启动时探针就开始探测了，这样可能会存在
应用程序还未启动就绪，就会导致探针检测失败，k8s就会根据pod重启策略杀掉容器然后再重新创建容器的莫名其妙的问题。
在生产环境中，一定要定义一个存活探针。
1
2
3
4
5
6
7
8
9
pod的就绪探针有哪几种？（必须记住3重探测方式，重点，经常问）
我们知道，当一个pod启动后，就会立即加入service的endpoint ip列表中，并开始接收到客户端的链接请求，假若此时pod中的容器的业务进程还没有初始化完毕，那么这些客户端链接请求就会失败，为了解决这个问题，kubernetes提供了就绪探针来解决这个问题的。
在pod中的容器定义一个就绪探针，就绪探针周期性检查容器，如果就绪探针检查失败了，说明该pod还未准备就绪，不能接受客户端链接，则该pod将从endpoint列表中移除，被剔除了service就不会把请求分发给该pod，然后就绪探针继续检查，如果随后容器就绪，则再重新把pod加回endpoint列表。k8s提供了3种就绪探针，如下：

httpGet：通过容器的IP、容器的端口以及路径来发送http get请求，返回200-400范围内的状态码表示请求成功。
exec：在容器内执行shell命令，它根据shell命令退出状态码是否为0进行判断，0表示健康，非0表示不健康。
TCPSocket：通过容器的IP、端口建立TCP Socket链接，能正常建立链接，则说明探针成功，不能正常建立链接，则探针失败。
1
2
3
就绪探针的属性参数有哪些
就绪探针的附加属性参数有以下几个：

initialDelaySeconds：延时秒数，即容器启动多少秒后才开始探测，不写默认容器启动就探测；
periodSeconds ：执行探测的频率（秒），默认为10秒，最低值为1；
timeoutSeconds ：超时时间，表示探测时在超时时间内必须得到响应，负责视为本次探测失败，默认为1秒，最小值为1；
failureThreshold ：连续探测失败的次数，视为本次探测失败，默认为3次，最小值为1次；
successThreshold ：连续探测成功的次数，视为本次探测成功，默认为1次，最小值为1次；
1
2
3
4
5
就绪探针与存活探针区别是什么？
两者作用不一样，存活探针是将检查失败的容器杀死，创建新的启动容器来保持pod正常工作；
就绪探针是，当就绪探针检查失败，并不重启容器，而是将pod移出endpoint，就绪探针确保了service中的pod都是可用的，确保客户端只与正常的pod交互并且客户端永远不会知道系统存在问题。

简单讲一下 pod创建过程
情况一、如果面试官问的是使用kubectl run命令创建的pod，可以这样说：
#注意：kubectl run 在旧版本中创建的是deployment，但在新的版本中创建的是pod则其创建过程不涉及deployment
如果是单独的创建一个pod，则其创建过程是这样的：
1、首先，用户通过kubectl或其他api客户端工具提交需要创建的pod信息给apiserver；
2、apiserver验证客户端的用户权限信息，验证通过开始处理创建请求生成pod对象信息，并将信息存入etcd，然后返回确认信息给客户端；
3、apiserver开始反馈etcd中pod对象的变化，其他组件使用watch机制跟踪apiserver上的变动；
4、scheduler发现有新的pod对象要创建，开始调用内部算法机制为pod分配最佳的主机，并将结果信息更新至apiserver；
5、node节点上的kubelet通过watch机制跟踪apiserver发现有pod调度到本节点，尝试调用docker启动容器，并将结果反馈apiserver；
6、apiserver将收到的pod状态信息存入etcd中。
至此，整个pod创建完毕。

情况二、如果面试官说的是使用deployment来创建pod，则可以这样回答：
1、首先，用户使用kubectl create命令或者kubectl apply命令提交了要创建一个deployment资源请求；
2、api-server收到创建资源的请求后，会对客户端操作进行身份认证，在客户端的~/.kube文件夹下，已经设置好了相关的用户认证信息，这样api-server会知道我是哪个用户，并对此用户进行鉴权，当api-server确定客户端的请求合法后，就会接受本次操作，并把相关的信息保存到etcd中，然后返回确认信息给客户端。
3、apiserver开始反馈etcd中过程创建的对象的变化，其他组件使用watch机制跟踪apiserver上的变动。
4、controller-manager组件会监听api-server的信息，controller-manager是有多个类型的，比如Deployment Controller, 它的作用就是负责监听Deployment，此时Deployment Controller发现有新的deployment要创建，那么它就会去创建一个ReplicaSet，一个ReplicaSet的产生，又被另一个叫做ReplicaSet Controller监听到了，紧接着它就会去分析ReplicaSet的语义，它了解到是要依照ReplicaSet的template去创建Pod, 它一看这个Pod并不存在，那么就新建此Pod，当Pod刚被创建时，它的nodeName属性值为空，代表着此Pod未被调度。
5、调度器Scheduler组件开始介入工作，Scheduler也是通过watch机制跟踪apiserver上的变动，发现有未调度的Pod，则根据内部算法、节点资源情况，pod定义的亲和性反亲和性等等，调度器会综合的选出一批候选节点，在候选节点中选择一个最优的节点，然后将pod绑定该该节点，将信息反馈给api-server。
6、kubelet组件布署于Node之上，它也是通过watch机制跟踪apiserver上的变动，监听到有一个Pod应该要被调度到自身所在Node上来，kubelet首先判断本地是否在此Pod，如果不存在，则会进入创建Pod流程，创建Pod有分为几种情况，第一种是容器不需要挂载外部存储，则相当于直接docker run把容器启动，但不会直接挂载docker网络，而是通过CNI调用网络插件配置容器网络，如果需要挂载外部存储，则还要调用CSI来挂载存储。kubelet创建完pod，将信息反馈给api-server，api-servier将pod信息写入etcd。
7、Pod建立成功后，ReplicaSet Controller会对其持续进行关注，如果Pod因意外或被我们手动退出，ReplicaSet Controller会知道，并创建新的Pod，以保持replicas数量期望值。

以上即使pod的调度过程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
简单描述一下pod的终止过程
1、用户向apiserver发送删除pod对象的命令；
2、apiserver中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead；
3、将pod标记为terminating状态；
4、kubectl在监控到pod对象为terminating状态了就会启动pod关闭过程；
5、endpoint控制器监控到pod对象的关闭行为时将其从所有匹配到此endpoint的server资源endpoint列表中删除；
6、如果当前pod对象定义了preStop钩子处理器，则在其被标记为terminating后会意同步的方式启动执行；
7、pod对象中的容器进程收到停止信息；
8、宽限期结束后，若pod中还存在运行的进程，那么pod对象会收到立即终止的信息；
9、kubelet请求apiserver将此pod资源的宽限期设置为0从而完成删除操作，此时pod对用户已不可见。
1
2
3
4
5
6
7
8
9
pod的生命周期有哪几种？
pod生命周期有的5种状态（也称5种相位），如下：

Pending（挂起）：API server已经创建pod，但是该pod还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程；
Running（运行中）：Pod内所有的容器已经创建，且至少有一个容器处于运行状态、正在启动括正在重启状态；
Succeed（成功）：Pod内所有容器均已退出，且不会再重启；
Failed（失败）：Pod内所有容器均已退出，且至少有一个容器为退出失败状态
Unknown（未知）：某于某种原因apiserver无法获取该pod的状态，可能由于网络通行问题导致；
1
2
3
4
5
pod一致处于pending状态一般有哪些情况，怎么排查？（重点，持续更新）
（这个问题被问到的概率非常大）
答：一个pod一开始创建的时候，它本身就是会处于pending状态，这时可能是正在拉取镜像，正在创建容器的过程。
如果等了一会发现pod一直处于pending状态，那么我们可以使用kubectl describe命令查看一下pod的Events详细信息。一般可能会有这么几种情况导致pod一直处于pending状态：
1、调度器调度失败。Scheduer调度器无法为pod分配一个合适的node节点。而这又会有很多种情况，比如，node节点处在cpu、内存压力，导致无节点可调度；pod定义了资源请求，没有node节点满足资源请求；node节点上有污点而pod没有定义容忍；pod中定义了亲和性或反亲和性而没有节点满足这些亲和性或反亲和性；以上是调度器调度失败的几种情况。
2、pvc、pv无法动态创建。如果因为pvc或pv无法动态创建，那么pod也会一直处于pending状态，比如要使用StatefulSet 创建redis集群，因为粗心大意，定义的storageClassName名称写错了，那么会造成无法创建pvc，这种情况pod也会一直处于pending状态，或者，即使pvc是正常创建了，但是由于某些异常原因导致动态供应存储无法正常创建pv，那么这种情况pod也会一直处于pending状态。

pod的钩子函数有哪几种，作用是什么？
pod的初始化容器是干什么的？
init container，初始化容器用于在启动应用容器之前完成应用容器所需要的前置条件，初始化容器本质上和应用容器是一样的，但是初始化容器是仅允许一次就结束的任务，初始化容器具有两大特征：

1、初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成；
2、初始化容器必须按照定义的顺序执行，当且仅当前一个初始化容器成功之后，后面的一个初始化容器才能运行；
1
2
pod的资源请求、限制如何定义？
pod的资源请求、资源限制可以直接在pod中定义，主要包括两块内容，limits，限制pod能使用的最大cpu和内存，requests，pod启动时申请的cpu和内存。

 resources:                    #资源配额
      limits:                    #限制最大资源，上限
        cpu: 2                    #CPU限制，单位是code数
        memory: 2G                #内存最大限制
      requests:                    #请求资源（最小，下限）
        cpu: 1                    #CPU请求，单位是code数
        memory: 500G            #内存最小请求
1
2
3
4
5
6
7
pod的定义中有个command和args参数，这两个参数不会和docker镜像的entrypointc冲突吗？
不会。
在pod中定义的command参数用于指定容器的启动命令列表，如果不指定，则默认使用Dockerfile打包时的启动命令，args参数用于容器的启动命令需要的参数列表；
特别说明：
kubernetes中的command、args其实是实现覆盖dockerfile中的ENTRYPOINT的功能的。当

1、如果command和args均没有写，那么使用Dockerfile的配置；
2、如果command写了但args没写，那么Dockerfile默认的配置会被忽略，执行指定的command；
3、如果command没写但args写了，那么Dockerfile中的ENTRYPOINT的会被执行，使用当前args的参数；
4、如果command和args都写了，那么Dockerfile会被忽略，执行输入的command和args。
1
2
3
4
标签及标签选择器是什么，如何使用？
标签是键值对类型，标签可以附加到任何资源对象上，主要用于管理对象，查询和筛选。标签常被用于标签选择器的匹配度检查，从而完成资源筛选；一个资源可以定义一个或多个标签在其上面。

标签选择器，标签要与标签选择器结合在一起，标签选择器允许我们选择标记有特定标签的资源对象子集，如pod，并对这些特定标签的pod进行查询，删除等操作。
标签和标签选择器最重要的使用之一在于，在deployment中，在pod模板中定义pod的标签，然后在deployment定义标签选择器，这样就通过标签选择器来选择哪些pod是受其控制的，service也是通过标签选择器来关联哪些pod最后其服务后端pod。

service是如何与pod关联的？
答案是通过标签选择器，每一个由deployment创建的pod都带有标签，这样，service就可以定义标签选择器来关联哪些pod是作为其后端了，就是这样，service就与pod管联在一起了。

service的域名解析格式、pod的域名解析格式
service的DNS域名表示格式为<servicename>.<namespace>.svc.<clusterdomain>，servicename是service的名称，namespace是service所处的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local

pod的DNS域名格式为：<pod-ip>.<namespace>.pod.<clusterdomain> ，其中，pod-ip需要使用-将ip直接的点替换掉，namespace为pod所在的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local ，演示如下：10-244-1-223.default.pod.cluster.local
对于deployment、daemonsets等创建的pod，还还可以通过<pod-ip>.<deployment-name>.<namespace>.svc.<clusterdomain> 这样的域名访问。

service的类型有哪几种
service的类型一般有4中，分别是：

ClusterIP：表示service仅供集群内部使用，默认值就是ClusterIP类型
NodePort：表示service可以对外访问应用，会在每个节点上暴露一个端口，这样外部浏览器访问地址为：任意节点的IP：NodePort就能连上service了
LoadBalancer：表示service对外访问应用，这种类型的service是公有云环境下的service，此模式需要外部云厂商的支持，需要有一个公网IP地址
ExternalName：这种类型的service会把集群外部的服务引入集群内部，这样集群内直接访问service就可以间接的使用集群外部服务了

一般情况下，service都是ClusterIP类型的，通过ingress接入的外部流量。
1
2
3
4
5
6
一个应用pod是如何发现service的，或者说，pod里面的容器用于是如何连接service的？
答：有两种方式，一种是通过环境变量，另一种是通过service的dns域名方式。
1、环境变量：当pod被创建之后，k8s系统会自动为容器注入集群内有效的service名称和端口号等信息为环境变量的形式，这样容器应用直接通过取环境变量值就能访问service了，如curl http://${WEBAPP_SERVICE_HOST}:{WEBAPP_SERVICE_PORT}
2、DNS方式：使用dns域名解析的前提是k8s集群内有DNS域名解析服务器，默认k8s中会有一个CoreDNS作为k8s集群的默认DNS服务器提供域名解析服务器；service的DNS域名表示格式为<servicename>.<namespace>.svc.<clusterdomain>，servicename是service的名称，namespace是service所处的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local ，这样容器应用直接通过service域名就能访问service了，如wget http://svc-deployment-nginx.default.svc.cluster.local:80，另外，service的port端口如果定义了名称，那么port也可以通过DNS进行解析，格式为：_<portname>._<protocol>.<servicename>.<namespace>.svc.<clusterdomain>

如何创建一个service代理外部的服务，或者换句话来说，在k8s集群内的应用如何访问外部的服务，如数据库服务，缓存服务等?
答：可以通过创建一个没有标签选择器的service来代理集群外部的服务。
1、创建service时不指定selector标签选择器，但需要指定service的port端口、端口的name、端口协议等，这样创建出来的service因为没有指定标签选择器就不会自动创建endpoint；
2、手动创建一个与service同名的endpoint，endpoint中定义外部服务的IP和端口，endpoint的名称一定要与service的名称一样，端口协议也要一样，端口的name也要与service的端口的name一样，不然endpoint不能与service进行关联。
完成以上两步，k8s会自动将service和同名的endpoint进行关联，这样，k8s集群内的应用服务直接访问这个service就可以相当于访问外部的服务了。

service、endpoint、kube-proxys三种的关系是什么？
service：在kubernetes中，service是一种为一组功能相同的pod提供单一不变的接入点的资源。当service被建立时，service的IP和端口不会改变，这样外部的客户端（也可以是集群内部的客户端）通过service的IP和端口来建立链接，这些链接会被路由到提供该服务的任意一个pod上。通过这样的方式，客户端不需要知道每个单独提供服务的pod地址，这样pod就可以在集群中随时被创建或销毁。
endpoint：service维护一个叫endpoint的资源列表，endpoint资源对象保存着service关联的pod的ip和端口。从表面上看，当pod消失，service会在endpoint列表中剔除pod，当有新的pod加入，service就会将pod ip加入endpoint列表；但是正在底层的逻辑是，endpoint的这种自动剔除、添加、更新pod的地址其实底层是由endpoint controller控制的，endpoint controller负责监听service和对应的pod副本的变化，如果监听到service被删除，则删除和该service同名的endpoint对象，如果监听到新的service被创建或者修改，则根据该service信息获取得相关pod列表，然后创建或更新service对应的endpoint对象，如果监听到pod事件，则更新它所对应的service的endpoint对象。
kube-proxy：kube-proxy运行在node节点上，在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作，kube-proxy会监听api-server中从而获取service和endpoint的变化情况，创建并维护路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。

无头service和普通的service有什么区别，无头service使用场景是什么？
答：无头service没有cluster ip，在定义service时将 service.spec.clusterIP：None，就表示创建的是无头service。
普通的service是用于为一组后端pod提供请求连接的负载均衡，让客户端能通过固定的service ip地址来访问pod，这类的pod是没有状态的，同时service还具有负载均衡和服务发现的功能。普通service跟我们平时使用的nginx反向代理很相识。
但是，试想这样一种情况，有6个redis pod ,它们相互之间要通信并要组成一个redis集群，不在需要所谓的service负载均衡，这时无头service就是派上用场了，无头service由于没有cluster ip，kube-proxy就不会处理它也就不会对它生成规则负载均衡，无头service直接绑定的是pod 的ip。无头service仍会有标签选择器，有标签选择器就会有endpoint资源。
使用场景：无头service一般用于有状态的应用场景，如Kaka集群、Redis集群等，这类pod之间需要相互通信相互组成集群，不在需要所谓的service负载均衡。

deployment怎么扩容或缩容？
答：直接修改pod副本数即可，可以通过下面的方式来修改pod副本数：
1、直接修改yaml文件的replicas字段数值，然后kubectl apply -f xxx.yaml来实现更新；
2、使用kubectl edit deployment xxx 修改replicas来实现在线更新；
3、使用kubectl scale --replicas=5 deployment/deployment-nginx命令来扩容缩容。

deployment的更新升级策略有哪些？
答：deployment的升级策略主要有两种。
1、Recreate 重建更新：这种更新策略会杀掉所有正在运行的pod，然后再重新创建的pod；
2、rollingUpdate 滚动更新：这种更新策略，deployment会以滚动更新的方式来逐个更新pod，同时通过设置滚动更新的两个参数maxUnavailable、maxSurge来控制更新的过程。

deployment的滚动更新策略有两个特别主要的参数，解释一下它们是什么意思？
答：deployment的滚动更新策略，rollingUpdate 策略，主要有两个参数，maxUnavailable、maxSurge。

maxUnavailable：最大不可用数，maxUnavailable用于指定deployment在更新的过程中不可用状态的pod的最大数量，maxUnavailable的值可以是一个整数值，也可以是pod期望副本的百分比，如25%，计算时向下取整。
maxSurge：最大激增数，maxSurge指定deployment在更新的过程中pod的总数量最大能超过pod副本数多少个，maxUnavailable的值可以是一个整数值，也可以是pod期望副本的百分比，如25%，计算时向上取整。
1
2
deployment更新的命令有哪些？
答：可以通过三种方式来实现更新deployment。
1、直接修改yaml文件的镜像版本，然后kubectl apply -f xxx.yaml来实现更新；
2、使用kubectl edit deployment xxx 实现在线更新；
3、使用kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1 命令来更新。

简述一下deployment的更新过程?
deployment是通过控制replicaset来实现，由replicaset真正创建pod副本，每更新一次deployment，都会创建新的replicaset，下面来举例deployment的更新过程：
假设要升级一个nginx-deployment的版本镜像为nginx:1.9，deployment的定义滚动更新参数如下：

replicas: 3
deployment.spec.strategy.type: RollingUpdate
maxUnavailable：25%
maxSurge：25%
1
2
3
4
通过计算我们得出，3*25%=0.75，maxUnavailable是向下取整，则maxUnavailable=0，maxSurge是向上取整，则maxSurge=1，所以我们得出在整个deployment升级镜像过程中，不管旧的pod和新的pod是如何创建消亡的，pod总数最大不能超过3+maxSurge=4个，最大pod不可用数3-maxUnavailable=3个。

现在具体讲一下deployment的更新升级过程：
使用kubectl set image deployment/nginx nginx=nginx:1.9 --record 命令来更新；
1、deployment创建一个新的replaceset，先新增1个新版本pod，此时pod总数为4个，不能再新增了，再新增就超过pod总数4个了；旧=3，新=1，总=4；
2、减少一个旧版本的pod，此时pod总数为3个，这时不能再减少了，再减少就不满足最大pod不可用数3个了；旧=2，新=1，总=3；
3、再新增一个新版本的pod，此时pod总数为4个，不能再新增了；旧=2，新=2，总=4；
4、减少一个旧版本的pod，此时pod总数为3个，这时不能再减少了；旧=1，新=2，总=3；
5、再新增一个新版本的pod，此时pod总数为4个，不能再新增了；旧=1，新=3，总=4；
6、减少一个旧版本的pod，此时pod总数为3个，更新完成，pod都是新版本了；旧=0，新=3，总=3；

deployment的回滚使用什么命令
在升级deployment时kubectl set image 命令加上 --record 参数可以记录具体的升级历史信息，使用kubectl rollout history deployment/deployment-nginx 命令来查看指定的deployment升级历史记录，如果需要回滚到某个指定的版本，可以使用kubectl rollout undo deployment/deployment-nginx --to-revision=2 命令来实现。

讲一下都有哪些存储卷，作用分别是什么?
卷    作用    常用场景
emptyDir    用于存储临时数据的简单空目录    一个pod中的多个容器需要共享彼此的数据 ，emptyDir的数据随着容器的消亡也会销毁
hostPath    用于将目录从工作节点的文件系统挂载到pod中    不常用，缺点是，pod的调度不是固定的，也就是当pod消失后deployment重新创建一个pod，而这pod如果不是被调度到之前pod的节点，那么该pod就不能访问之前的数据
configMap    用于将非敏感的数据保存到键值对中，使用时可以使用作为环境变量、命令行参数arg，存储卷被pods挂载使用    将应用程序的不敏感配置文件创建为configmap卷，在pod中挂载configmap卷，可是实现热更新
secret    主要用于存储和管理一些敏感数据，然后通过在 Pod 的容器里挂载 Volume 的方式或者环境变量的方式访问到这些 Secret 里保存的信息了，pod会自动解密Secret 的信息    将应用程序的账号密码等敏感信息通过secret卷的形式挂载到pod中使用
downwardApi    主要用于暴露pod元数据，如pod的名字    pod中的应用程序需要指定pod的name等元数据，就可以通过downwardApi 卷的形式挂载给pod使用
projected    这是一种特殊的卷，用于将上面这些卷一次性的挂载给pod使用    将上面这些卷一次性的挂载给pod使用
pvc    pvc是存储卷声明    通常会创建pvc表示对存储的申请，然后在pod中使用pvc
网络存储卷    pod挂载网络存储卷，这样就能将数据持久化到后端的存储里    常见的网络存储卷有nfs存储、glusterfs 卷、ceph rbd存储卷
pv的访问模式有哪几种
pv的访问模式有3种，如下：

ReadWriteOnce，简写：RWO    表示，只仅允许单个节点以读写方式挂载；
ReadOnlyMany，简写：ROX    表示，可以被许多节点以只读方式挂载；
ReadWriteMany，简写：RWX    表示，可以被多个节点以读写方式挂载；
1
2
3
pv的回收策略有哪几种
主要有2中回收策略：retain 保留、delete 删除。
Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍然存在，PV被视为已释放，管理员可以手动回收卷。
Delete：删除，如果Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包括AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等。
Recycle：回收，如果Volume插件支持，Recycle策略会对卷执行rm -rf清理该PV，并使其可用于下一个新的PVC，但是本策略将来会被弃用，目前只有NFS和HostPath支持该策略。（这种策略已经被废弃，不用记）

在pv的生命周期中，一般有几种状态
pv一共有4中状态，分别是：
创建pv后，pv的的状态有以下4种：Available（可用）、Bound（已绑定）、Released（已释放）、Failed（失败）

Available，表示pv已经创建正常，处于可用状态；
Bound，表示pv已经被某个pvc绑定，注意，一个pv一旦被某个pvc绑定，那么该pvc就独占该pv，其他pvc不能再与该pv绑定；
Released，表示pvc被删除了，pv状态就会变成已释放；
Failed，表示pv的自动回收失败；
1
2
3
4
存储类的资源回收策略:
主要有2中回收策略，delete 删除，默认就是delete策略、retain 保留。
Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍然存在，PV被视为已释放，管理员可以手动回收卷。
Delete：删除，如果Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包括AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等。

注意：使用存储类动态创建的pv默认继承存储类的回收策略，当然当pv创建后你也可以手动修改pv的回收策略。

怎么使一个node脱离集群调度，比如要停机维护单又不能影响业务应用
crodon背后的原理其实就是打污点
使用kubectl drain 命令

pv存储空间不足怎么扩容?
一般的，我们会使用动态分配存储资源，在创建storageclass时指定参数 allowVolumeExpansion：true，表示允许用户通过修改pvc申请的存储空间自动完成pv的扩容，当增大pvc的存储空间时，不会重新创建一个pv，而是扩容其绑定的后端pv。这样就能完成扩容了。但是allowVolumeExpansion这个特性只支持扩容空间不支持减少空间。

k8s生产中遇到什么特别影响深刻的问题吗，问题排查解决思路是怎么样的？（重点）
（此问题被问到的概率高达90%，所以可以自己准备几个自己在生产环境中遇到的问题进行讲解）

答：前端的lb负载均衡服务器上的keepalived出现过脑裂现象。
1、当时问题现象是这样的，vip同时出现在主服务器和备服务器上，但业务上又没受到影响；
2、这时首先去查看备服务器上的keepalived日志，发现有日志信息显示凌晨的时候备服务器出现了vrrp协议超时，所以才导致了备服务器接管了vip；查看主服务器上的keepalived日志，没有发现明显的报错信息，继续查看主服务器和备服务器上的keepalived进程状态，都是running状态的；查看主服务器上检测脚本所检测的进程，其进程也是正常的，也就是说主服务器根本没有成功执行检测脚本（成功执行检查脚本是会kill掉keepalived进程，脚本里面其实就是配置了检查nginx进程是否存活，如果检查到nginx不存活则kill掉keepalived，这样来实现备服务器接管vip）；
3、排查服务器上的防火墙、selinux，防火墙状态和selinux状态都是关闭着的；
4、使用tcpdump工具在备服务器上进行抓取数据包分析，分析发现，现在确实是备接管的vip，也确实是备服务器也在对外发送vrrp心跳包，所以现在外部流量应该都是流入备服务器上的vip；
5、怀疑：主服务器上设置的vrrp心跳包时间间隔太长，以及检测脚本设置的检测时间设置不合理导致该问题；
6、修改vrrp协议的心跳包时间间隔，由原来的2秒改成1秒就发送一次心跳包；检测脚本的检测时间也修改短一点，同时还修改检测脚本的检测失败的次数，比如连续检测2次失败才认定为检测失败；
7、重启主备上的keepalived，现在keepalived是正常的，主服务器上有vip，备服务器上没有vip；
8、持续观察：第二天又发现keepalived出现过脑裂现象，vip又同时出现在主服务器和备服务器上，又是凌晨的时候备服务器显示vrrp心跳包超时，所以才导致备服务器接管了vip；
9、同样的时间，都是凌晨，vrrp协议超时；很奇怪，很有理由怀疑是网络问题，询问第三方厂家上层路由器是否禁止了vrrp协议，第三方厂家回复，没有禁止vrrp协议；
10、百度、看官方文档求解；
11、百度、看官网文档得知，keepalived有2种传播模式，一种是组播模式，一种是单播模式，keepalived默认在组播模式下工作，主服务器会往主播地址224.0.0.18发送心跳包，当局域网内有多个keepalived实例的时候，如果都用主播模式，会存在冲突干扰的情况，所以官方建议使用单播模式通信，单播模式就是点对点通行，即主向备服务器一对一的发送心跳包；
12、将keepalived模式改为单播模式，继续观察，无再发生脑裂现象。问题得以解决。

答：测试环境二进制搭建etcd集群，etcd集群出现2个leader的现象。
1、问题现象就是：刚搭建的k8s集群，是测试环境的，搭建完成之后发现，使用kubectl get nodes 显示没有资源，kubectl get namespace 一会能正常显示全部的命名空间，一会又显示不了命名空间，这种奇怪情况。
2、当时经验不是很足，第一点想到的是不是因为网络插件calico没装导致的，但是想想，即使没有安装网络插件，最多是node节点状态是notready，也不可能是没有资源发现呀；
3、然后想到etcd数据库，k8s的资源都是存储在etcd数据库中的；
4、查看etcd进程服务的启动状态，发现etcd服务状态是处于running状态，但是日志有大量的报错信息，日志大概报错信息就是集群节点的id不匹配，存在冲突等等报错信息；
5、使用etcdctl命令查看etcd集群的健康状态，发现集群是health状态，但是居然显示有2个leader，这很奇怪（当初安装etcd的时候其实也只是简单看到了集群是健康状态，然后没注意到有2个leader，也没太关注etcd服务进程的日志报错信息，以为etcd集群状态是health状态就可以了）
6、现在etcd出现了2个leader，肯定是存在问题的；
7、全部检测一遍etcd的各个节点的配置文件，确认配置文件里面各个参数配置都没有问题，重启etcd集群，报错信息仍未解决，仍然存在2个leader；
8、尝试把其中一个leader节点踢出集群，然后再重新添加它进入集群，仍然是报错，仍然显示有2个leader；
9、尝试重新生成etcd的证书，重新颁发etcd的证书，问题仍然存在，仍然显示有2个leader；日志仍是报错集群节点的id不匹配，存在冲突；
10、计算etcd命令的MD5值，确保各个节点的etcd命令是相同的，确保在scp传输的时候没有损耗等等，问题仍未解决；
11、无解，请求同事，架构师介入帮忙排查问题，仍未解决；
12、删除全部etcd相关的文件，重新部署etcd集群，etcd集群正常了，现在只有一个leader，使用命令kubectl get nodes 查看节点，也能正常显示了；
13、最终问题的原因也没有定位出来，只能怀疑是环境问题了，由于是刚部署的k8s测试环境，etcd里面没有数据，所以可以删除重新创建etcd集群，如果是线上环境的etcd集群出现这种问题，就不能随便删除etcd集群了，必须要先进行数据备份才能进行其他方法的处理。

etcd集群节点可以设置为偶数个吗，为什么要设置为基数个呢？
不能，也不建议这么设置。
因为在软件的概念了，有个默认的规则，那就是集群的节点数量必须是基数个，因为这涉及到一个选举机制的问题。
（待补充）

etcd集群节点之间是怎么同步数据的？
（待补充）

pod的网络是怎么实现的，比如在node节点上ping一个pod的ip，这个网络流程是什么验证的？
这块涉及到k8s的网络，优点难（待补充）

一个用户请求流量是如何进入k8s集群内部的？
用户访问我们的k8s集群里面的应用网站，出现500报错，你是如何排查这种问题的？
k8s后端存储使用的是什么？
你们的服务发布怎么做的？

1、kubenetes针对pod资源对象的健康监测机制?

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

2、pod的重启策略是什么？

        答：pod的spec包含restartPolicy字段是查看pod的重启策略;Always：但凡pod对象终止就重启，此为默认策略;OnFailure：仅在pod对象出现错误时才重启;Never：不论容器运行状态如何，kubelet都不会重启该容器；

3、DaemonSet资源对象的特性？

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

4、删除一个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）;
5、请详述kube-proxy原理?      

        答：集群中每个Node上都会运行一个kube-proxy服务进程，他是Service的透明代理兼均衡负载器，其核心功能是将某个Service的访问转发到后端的多个Pod上。kube-proxy通过监听集群状态变更，并对本机iptables做修改，从而实现网络路由。 而其中的负载均衡，也是通过iptables的特性实现的。从V1.8版本开始，用IPVS（IP Virtual Server）模式，用于路由规则的配置，主要优势是：1）为大型集群提供了更好的扩展性和性能。采用哈希表的数据结构，更高效；2）支持更复杂的负载均衡算法；3）支持服务器健康检查和连接重试；4）可以动态修改ipset的集合；

6、flannel 和 ovs 网络的区别？

        答：1）配置是否自动化：OpenvSwitch（ovs）作为开源的交换机软件，相对比较成熟和稳定，支持各种网络隧道和协议，经历了大型项目 OpenStack 的考验，而 flannel 除了支持建立覆盖网络来实现 Pod 到 Pod 之间的无缝通信之外，还跟 docker、k8s 的架构体系紧密结合，flannel 能感知 k8s 中的 service 对象，然后动态维护自己的路由表，并通过 etcd 来协助 docker 对整个 k8s 集群的 docker0 网段进行规范，而 ovs ，这些操作则需要手动完成，假如集群中有 N 个节点，则需要建立 N(N-1)/2 个 Vxlan 或者 gre 连接，这取决于集群的规模，如果集群的规模很大，则必须通过自动化脚本来初始化，避免出错。2）是否支持隔离：flannel 虽然很方便实现 Pod 到 Pod 之间的通信，但不能实现多租户隔离，也不能很好地限制 Pod 的网络流量，而 ovs 网络有两种模式：单租户模式和多租户模式，单租户模式直接使用 openvswitch + vxlan 将 k8s 的 pod 网络组成一个大二层，所有的 pod 可以互相通信访问，多租户模式以 Namespace 为维度分配虚拟网络，从而形成一个网络独立用户，一个 Namespace 中的 pod 无法访问其他 Namespace 中的 pod 和 svc 对象；

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

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

8、K8S 资源限制 QoS？

        答：Quality of Service（Qos） 主要有三种类别：1）BestEffort：什么都不设置（CPU or Memory），佛系申请资源；2）Burstable：Pod 中的容器至少一个设置了CPU 或者 Memory 的请求；3）Guaranteed：Pod 中的所有容器必须设置 CPU 和 Memory，并且 request 和 limit 值相等；

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

        答：1)EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由Pod内保部映射到宿主机上。类似于docker中的manager volume；场景有：a.只需要临时将数据保存在磁盘上，比如在合并/排序算法中；b.作为两个容器的共享存储，使得第一个内容管理的容器可以将生成的数据存入其中，同时由同一个webserver容器对外提供这些页面;emptyDir的特性：同个pod里面的不同容器，共享同一个持久化目录，当pod节点删除时，volume的数据也会被删除。如果仅仅是容器被销毁，pod还在，则不会影响volume中的数据。总结来说：emptyDir的数据持久化的生命周期和使用的pod一致。一般是作为临时存储使用。2）Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式；3）PersistentVolume（简称PV）：基于NFS服务的PV，也可以基于GFS的PV。它的作用是统一数据持久化目录，方便管理，PVC是向PV申请应用所需的容量大小，K8s集群中可能会有多个PV，PVC和PV若要关联，其定义的访问模式必须一致。定义的storageClassName也必须一致，若群集中存在相同的（名字、访问模式都一致）两个PV，那么PVC会选择向它所需容量接近的PV去申请，或者随机申请；

10、K8S的基本组成部分？

        答：Master节点主要有五个组件，分别是kubectl、api-server、controller-manager、kube-scheduler 和 etcd；node节点主要有三个组件，分别是 kubelet、kube-proxy 和 容器运行时 docker 或者 rkt；

kubectl：客户端命令行工具，作为整个系统的操作入口。
apiserver：以REST API服务形式提供接口，作为整个系统的控制入口。
controller-manager：执行整个系统的后台任务，包括节点状态状况、Pod个数、Pods和Service的关联等。
kube-scheduler：负责节点资源管理，接收来自kube-apiserver创建Pods任务，并分配到某个节点。
etcd：负责节点间的服务发现和配置共享。
kube-proxy：运行在每个计算节点上，负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。
kubelet：运行在每个计算节点上，作为agent，接收分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver。
DNS：一个可选的DNS服务，用于为每个Service对象创建DNS记录，这样所有的Pod就可以通过DNS访问服务了。

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

        答：可通过命令“kubectl explain pod.spec.containers”来查看imagePullPolicy这行的解释，K8s的镜像下载策略有三种：Always：镜像标签为latest时，总是从指定的仓库中获取镜像；Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载；

12、标签与标签选择器的作用是什么？

        答：标签：是当相同类型的资源对象越来越多的时候，为了更好的管理，可以按照标签将其分为一个组，为的是提升资源对象的管理效率；标签选择器：就是标签的查询过滤条件。

13、K8s的负载均衡器？

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

14、kubelet 监控 Node 节点资源使用是通过什么组件来实现的？

        答：用Metrics Server提供核心指标，包括Node、Pod的CPU和内存的使用。而Metrics Server需要采集node上的cAdvisor提供的数据资源，当 kubelet 服务启动时，它会自动启动 cAdvisor 服务，然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。kubelet 的启动参数 --cadvisor-port 可自定义 cAdvisor 对外提供服务的端口号，默认是 4194；

15、Pod的状态？

        答：1）Pending：已经创建了Pod，但是其内部还有容器没有创建；2）Running：Pod内部的所有容器都已经创建，只有由一个容器还处于运行状态或者重启状态；3）Succeeed：Pod内所有容器均已经成功执行并且退出，不会再重启；4）Failed：Pod内所有容器都退出，但至少有一个为退出失败状态；5）Unknown：由于某种原因不能获取该Pod的状态，可能是网络问题；

16、deployment/rs的区别？

        答：deployment是rs的超集，提供更多的部署功能，如：回滚、暂停和重启、 版本记录、事件和状态查看、滚动升级和替换升级。如果能使用deployment，则不应再使用rc和rs；

17、rc/rs实现原理？

        答：Replication Controller 可以保证Pod始终处于规定的副本数，而当前推荐的做法是使用Deployment+ReplicaSet，ReplicaSet 号称下一代的 Replication Controller，当前唯一区别是RS支持set-based selector，RC是通过ReplicationManager监控RC和RC内Pod的状态，从而增删Pod，以实现维持特定副本数的功能，RS也是大致相同；

18、k8s 创建一个pod的详细流程，涉及的组件怎么通信的？

        答：1）客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML；2）api-server 处理用户请求，将 pod 信息存储至 etcd 中；3）kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出；4）选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中；5）随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器；

19、kubernetes服务发现？

        答：1）环境变量： 当你创建一个Pod的时候，kubelet会在该Pod中注入集群内所有Service的相关环境变量。需要注意: 要想一个Pod中注入某个Service的环境变量，则必须Service要先比该Pod创建；2）DNS：可以通过cluster add-on方式轻松的创建KubeDNS来对集群内的Service进行服务发现；

20、k8s发布(暴露)服务，servcie的类型有那些？

        答：kubernetes原生的，一个Service的ServiceType决定了其发布服务的方式。1） ClusterIP：这是k8s默认的ServiceType。通过集群内的ClusterIP在内部发布服务。2）NodePort：这种方式是常用的，用来对集群外暴露Service，你可以通过访问集群内的每个NodeIP:NodePort的方式，访问到对应Service后端的Endpoint。3）LoadBalancer: 这也是用来对集群外暴露服务的，不同的是这需要Cloud Provider的支持，比如AWS等。4）ExternalName：这个也是在集群内发布服务用的，需要借助KubeDNS(version >= 1.7)的支持，就是用KubeDNS将该service和ExternalName做一个Map，KubeDNS返回一个CNAME记录；

21、简述ETCD及其特点?

        答：etcd是一个分布式的、高可用的、一致的key-value存储数据库，基于Go语言实现，主要用于共享配置和服务发现。特点：1）完全复制：集群中的每个节点都可以使用完整的存档；2）高可用性：Etcd可用于避免硬件的单点故障或网络问题；3）一致性：每次读取都会返回跨多主机的最新写入；4）简单：包括一个定义良好、面向用户的API（gRPC）；5）安全：实现了带有可选的客户端证书身份验证的自动化TLS；6）快速：每秒10000次写入的基准速度；7）可靠：使用Raft算法实现了强一致、高可用的服务存储目录；

22、简述ETCD适应的场景?

        答：1）服务发现：服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以查找和连接。2）消息发布与订阅：构建一个配置共享中心，应用中用到的一些配置信息放到etcd上进行集中管理。3）负载均衡：分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，etcd本身分布式架构存储的信息访问支持负载均衡。4）分布式通知与协调：通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。5）分布式锁：因为etcd使用Raft算法保持了数据的强一致性，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。6）分布式队列：创建一个先进先出的队列，保证顺序。7）集群监控与Leader精选：通过etcd来进行监控实现起来非常简单并且实时性强；

23、简述Kubernetes和Docker的关系?

        答：Docker开源的容器引擎，一种更加轻量级的虚拟化技术；K8s，容器管理工具，用来管理容器pod的集合，它可以实现容器集群的自动化部署、自动扩缩容、维护等功能；

24、简述Kubernetes中什么是Minikube、Kubectl、Kubelet?

        答：Minikube 是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具；Kubectl 是一个命令行工具，可以使用该工具控制Kubernetes集群管理器，如检查群集资源，创建、删除和更新组件，查看应用程序；Kubelet 是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信；

25、简述Kubernetes如何实现集群管理?

        答：在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的；

26、简述Kubernetes的优势、适应场景及其特点?

        答：优势：容器编排、轻量级、开源、弹性伸缩、负载均衡；场景：快速部署应用、快速扩展应用、无缝对接新的应用功能、节省资源，优化硬件资源的使用；特点：可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）、可扩展: 模块化,、插件化、可挂载、可组合、自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展；

27、简述Kubernetes的缺点或当前的不足之处?

        答：安装过程和配置相对困难复杂、管理服务相对繁琐、运行和编译需要很多时间、它比其他替代品更昂贵、对于简单的应用程序来说，可能不需要涉及Kubernetes即可满足；

28、简述Kubernetes相关基础概念?       

        答：master：k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程；node（worker）：Node（worker）是Kubernetes集群架构中运行Pod的服务节点，是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy；pod：运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通信。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器；label：Kubernetes中的Label实质是一系列的Key/Value键值对，其中key与value可自定义。Label可以附加到各种资源对象上，如Node、Pod、Service、RC等。一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Kubernetes通过Label Selector（标签选择器）查询和筛选资源对象；Replication Controller：Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心；Deployment：Deployment在内部使用了RS来实现目的，Deployment相当于RC的一次升级，其最大的特色为可以随时获知当前Pod的部署进度；HPA（Horizontal Pod Autoscaler）：Pod的横向自动扩容，也是Kubernetes的一种资源，通过追踪分析RC控制的所有Pod目标的负载变化情况，来确定是否需要针对性的调整Pod副本数量；Service：Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行；Volume：Volume是Pod中能够被多个容器访问的共享目录，Kubernetes中的Volume是定义在Pod上，可以被一个或多个Pod中的容器挂载到某个目录下；Namespace：Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的不同项目、小组或用户组，便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理；

29、简述Kubernetes RC的机制?

        答：Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。当定义了RC并提交至Kubernetes集群中之后，Master节点上的Controller Manager组件获悉，并同时巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，若存在过多的Pod副本在运行，系统会停止一些Pod，反之则自动创建一些Pod；

30、简述kube-proxy作用?

        答：kube-proxy 运行在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上；

31、简述kube-proxy iptables原理?

        答：Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod；

32、简述kube-proxy ipvs原理?

        答：IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式；在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配；可以将ipset简单理解为一个IP（段）的集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少iptables规则的数量，从而减少性能损耗；

33、简述kube-proxy ipvs和iptables的异同?

        答：iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。与iptables相比，IPVS拥有以下明显优势：为大型集群提供了更好的可扩展性和性能；支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；支持服务器健康检查和连接重试等功能；可以动态修改ipset的集合，即使iptables的规则正在使用这个集合；

34、简述Kubernetes中什么是静态Pod?

        答：静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过API Server进行管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对他们进行健康检查。静态Pod总是由kubelet进行创建，并且总是在kubelet所在的Node上运行；

35、简述Kubernetes Pod的常见调度方式?

        答：1）Deployment或RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量；2）NodeSelector：定向调度，当需要手动指定将Pod调度到特定Node上，可以通过Node的标签（Label）和Pod的nodeSelector属性相匹配；3）NodeAffinity亲和性调度：亲和性调度机制极大的扩展了Pod的调度能力，目前有两种节点亲和力表达：硬规则，必须满足指定的规则，调度器才可以调度Pod至Node上（类似nodeSelector，语法不同）；软规则，优先调度至满足的Node的节点，但不强求，多个优先级规则还可以设置权重值；4）Taints和Tolerations（污点和容忍）：Taint：使Node拒绝特定Pod运行；Toleration：为Pod的属性，表示Pod能容忍（运行）标注了Taint的Node；

36、简述Kubernetes初始化容器（init container）?

        答：init container的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个init container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后，Kubernetes才会初始化Pod的各种信息，并开始创建和运行应用容器；

37、简述Kubernetes deployment升级过程?

        答：初始创建Deployment时，系统创建了一个ReplicaSet，并按用户的需求创建了对应数量的Pod副本；当更新Deployment时，系统创建了一个新的ReplicaSet，并将其副本数量扩展到1，然后将旧ReplicaSet缩减为2；之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整；最后，新的ReplicaSet运行了对应个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0；

38、简述Kubernetes deployment升级策略?

        答：在Deployment的定义中，可以通过spec.strategy指定Pod更新的策略，目前支持两种策略：Recreate（重建）和RollingUpdate（滚动更新），默认值为RollingUpdate；Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod；RollingUpdate：设置spec.strategy.type=RollingUpdate，表示Deployment会以滚动更新的方式来逐个更新Pod。同时，可以通过设置spec.strategy.rollingUpdate下的两个参数（maxUnavailable和maxSurge）来控制滚动更新的过程；

39、简述Kubernetes DaemonSet类型的资源特性?

        答：DaemonSet资源对象会在每个Kubernetes集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。因此，在定义yaml文件中，不支持定义replicas。它的一般使用场景如下：在去做每个节点的日志收集工作。监控每个节点的的运行状态。

40、简述Kubernetes自动扩容机制?

        答：Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器周期性地监测目标Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对比，在满足条件时对Pod副本数量进行调整；

41、简述Kubernetes Service分发后端的策略?

        答：1）RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个Pod上；2）SessionAffinity：基于客户端IP地址进行会话保持的模式，即第1次将某个客户端发起的请求转发到后端的某个Pod上，之后从相同的客户端发起的请求都将被转发到后端相同的Pod上；

42、简述Kubernetes Headless Service?

        答：在某些应用场景中，若需要人为指定负载均衡器，不使用Service提供的默认负载均衡的功能，或者应用程序希望知道属于同组服务的其他实例。Kubernetes提供了Headless Service来实现这种功能，即不为Service设置ClusterIP（入口IP地址），仅通过Label Selector将后端的Pod列表返回给调用的客户端；

43、简述Kubernetes外部如何访问集群内的服务?

        答：映射Pod到物理机：将Pod端口号映射到宿主机，即在Pod中采用hostPort方式，以使客户端应用能够通过物理机访问容器应用；映射Service到物理机：将Service端口号映射到宿主机，即在Service中采用nodePort方式，以使客户端应用能够通过物理机访问容器应用；映射Sercie到LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景；

44、简述Kubernetes ingress?

        答：K8s的Ingress资源对象，用于将不同URL的访问请求转发到后端不同的Service，以实现HTTP层的业务路由机制。K8s使用了Ingress策略和Ingress Controller，两者结合并实现了一个完整的Ingress负载均衡器。使用Ingress进行负载分发时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，从而跳过kube-proxy的转发功能，kube-proxy不再起作用，全过程为：ingress controller + ingress 规则 ----> services；

45、简述Kubernetes镜像的下载策略?

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

46、简述Kubernetes的负载均衡器?

        答：根据工作环境使用两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器，而外部负载均衡器将流量从外部负载引导至后端容器；

47、简述Kubernetes各模块如何与API Server通信?

        答：K8s API Server作为集群的核心，负责集群各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，则通过API Server提供的REST接口（用GET、LIST或WATCH方法）来实现，从而实现各模块之间的信息交互。1）kubelet进程与API Server的交互：每个Node上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自身状态，API Server在接收到这些信息后，会将节点状态信息更新到etcd中；2）kube-controller-manager进程与API Server的交互：kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口实时监控Node的信息，并做相应处理；3）kube-scheduler进程与API Server的交互：Scheduler通过API Server的Watch接口监听到新建Pod副本的信息后，会检索所有符合该Pod要求的Node列表，开始执行Pod调度逻辑，在调度成功后将Pod绑定到目标节点上；

48、简述Kubernetes Scheduler作用及实现原理?

        答：Scheduler是负责Pod调度的重要功能模块，负责接收Controller Manager创建的新Pod，为其调度至目标Node，调度完成后，目标Node上的kubelet服务进程接管后继工作，负责Pod接下来生命周期；Scheduler的作用是将待调度的Pod，按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的Node上，并将绑定信息写入etcd中；Scheduler通过调度算法调度为待调度Pod列表中的每个Pod从Node列表中选择一个最适合的Node来实现Pod的调度。随后，目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像并启动容器；

49、简述Kubernetes Scheduler使用哪两种算法将Pod绑定到worker节点?

        答：1）预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选；2）优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过预选的Nodes进行打分排名，选择得分最高的Node。例如，资源越富裕、负载越小的Node可能具有越高的排名；

50、简述Kubernetes kubelet的作用?

        答：在Kubernetes集群中，在每个Node（又称Worker）上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务，管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源；

51、简述Kubernetes kubelet监控Worker节点资源是使用什么组件来实现的?

        答:kubelet使用cAdvisor对worker节点资源进行监控。在 Kubernetes 系统中，cAdvisor 已被默认集成到 kubelet 组件内，当 kubelet 服务启动时，它会自动启动 cAdvisor 服务，然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标；

52、简述Kubernetes如何保证集群的安全性?

        答：1）基础设施方面：保证容器与其所在宿主机的隔离；2）用户权限：划分普通用户和管理员的角色；3）API Server的认证授权：Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server来实现的，因此需要建议采用更安全的HTTPS或Token来识别和认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）环节；4）API Server的授权管理：通过授权策略来决定一个API调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权，建议采用更安全的RBAC方式来提升集群安全授权；5）AdmissionControl（准入机制）：对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作；

53、简述Kubernetes准入机制?

        答：在对集群进行请求时，每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求，那么整个请求的结果将会立即返回，并提示用户相应的error信息，准入控制（AdmissionControl）准入控制本质上为一段准入代码，在对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。常用组件（控制代码）如下：AlwaysAdmit：允许所有请求；AlwaysDeny：禁止所有请求，多用于测试环境；ServiceAccount：它将serviceAccounts实现了自动化，它会辅助serviceAccount做一些事情，比如如果pod没有serviceAccount属性，它会自动添加一个default，并确保pod的serviceAccount始终存在；LimitRanger：观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在namespace中LimitRange对象中；NamespaceExists：观察所有的请求，如果请求尝试创建一个不存在的namespace，则这个请求被拒绝；

54、简述Kubernetes RBAC及其特点（优势）?

        答：RBAC是基于角色的访问控制，是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法，优势：1）对集群中的资源和非资源权限均有完整的覆盖；2）整个RBAC完全由几个API对象完成， 同其他API对象一样， 可以用kubectl或API进行操作；3）可以在运行时进行调整，无须重新启动API Server；

55、简述Kubernetes Secret作用?

        答：Secret对象，主要作用是保管私密数据，比如密码、OAuth Tokens、SSH Keys等信息。将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全，也更便于使用和分发；

56、简述Kubernetes Secret有哪些使用方式?

        答：1）在创建Pod时，通过为Pod指定Service Account来自动使用该Secret；2）通过挂载该Secret到Pod来使用它；3）在Docker镜像下载时使用，通过指定Pod的spc.ImagePullSecrets来引用它；

57、简述Kubernetes PodSecurityPolicy机制?

        答：Kubernetes PodSecurityPolicy是为了更精细地控制Pod对资源的使用方式以及提升安全策略。在开启PodSecurityPolicy准入控制器后，Kubernetes默认不允许创建任何Pod，需要创建PodSecurityPolicy策略和相应的RBAC授权策略（Authorizing Policies），Pod才能创建成功；

58、简述Kubernetes PodSecurityPolicy机制能实现哪些安全策略?

        答：1）特权模式：privileged是否允许Pod以特权模式运行；2）宿主机资源：控制Pod对宿主机资源的控制，如hostPID：是否允许Pod共享宿主机的进程空间；3）用户和组：设置运行容器的用户ID（范围）或组（范围）；4）提升权限：AllowPrivilegeEscalation：设置容器内的子进程是否可以提升权限，通常在设置非root用户（MustRunAsNonRoot）时进行设置；5）SELinux：进行SELinux的相关配置；

59、简述Kubernetes网络模型?

        答：Kubernetes网络模型中每个Pod都拥有一个独立的IP地址，不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问；同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间，也就是同一个Linux网络协议栈。这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口；在Kubernetes的集群里，IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈；

60、简述Kubernetes CNI模型?

        答：是对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。容器（Container）：是拥有独立Linux网络命名空间的环境，例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间，这是加入网络的必要条件；网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP地址，可以是容器、物理机或者其他网络设备（比如路由器）等；

61、简述Kubernetes网络策略?

        答：为实现细粒度的容器间网络访问隔离策略，K8s引入Network Policy主要功能是对Pod间的网络通信进行限制和准入控制，设置允许访问或禁止访问的客户端Pod列表。Network Policy定义网络策略，配合策略控制器（Policy Controller）进行策略的实现；

62、简述Kubernetes网络策略原理?

        答：Network Policy的工作原理主要为：policy controller需要实现一个API Listener，监听用户设置的Network Policy定义，并将网络访问规则通过各Node的Agent进行实际设置（Agent则需要通过CNI网络插件实现）；

63、简述Kubernetes中flannel的作用?

        答：1）它能协助Kubernetes，给每一个Node上的Docker容器都分配互相不冲突的IP地址；2）它能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内；

64、简述Kubernetes Calico网络组件实现原理?

        答：Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成，Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则；Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率；

65、简述Kubernetes共享存储的作用?

        答：Kubernetes对于有状态的容器应用或者对数据需要持久化的应用，因此需要更加可靠的存储来保存应用产生的重要数据，以便容器应用在重建之后仍然可以使用之前的数据。因此需要使用共享存储；

66、简述Kubernetes PV和PVC?

        答：PV是对底层网络共享存储的抽象，将共享存储定义为一种“资源”；PVC则是用户对存储资源的一个“申请”；

67、简述Kubernetes PV生命周期内的阶段?

        答：1）Available：可用状态，还未与某个PVC绑定；2）Bound：已与某个PVC绑定；3）Released：绑定的PVC已经删除，资源已释放，但没有被集群回收；4）Failed：自动资源回收失败；

68、简述Kubernetes CSI模型?

        答：CSI是Kubernetes推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用Kubernetes的原生存储机制为容器提供存储服务，CSI使得存储提供方的代码能和Kubernetes代码彻底解耦，部署也与Kubernetes核心组件分离；CSI包括CSI Controller：的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作；Node的主要功能是对主机（Node）上的Volume进行管理和操作；

69、简述Kubernetes Worker节点加入集群的过程?

        答：在该Node上安装Docker、kubelet和kube-proxy服务； 然后配置kubelet和kubeproxy的启动参数，将Master URL指定为当前Kubernetes集群Master的地址，最后启动这些服务； 通过kubelet默认的自动注册机制，新的Worker将会自动加入现有的Kubernetes集群中； Kubernetes Master在接受了新Worker的注册之后，会自动将其纳入当前集群的调度范围；

70、简述Kubernetes Pod如何实现对节点的资源控制?

        答：Kubernetes集群里的节点提供的资源主要是计算资源，计算资源是可计量的能被申请、分配和使用的基础资源。当前Kubernetes集群中的计算资源主要包括CPU、GPU及Memory。CPU与Memory是被Pod使用的，因此在配置Pod时可以通过参数CPU Request及Memory Request为其中的每个容器指定所需使用的CPU与Memory量，Kubernetes会根据Request的值去查找有足够资源的Node来调度此Pod；

71、简述Kubernetes Requests和Limits如何影响Pod的调度?

        答：当一个Pod创建成功时，Kubernetes调度器（Scheduler）会为该Pod选择一个节点来执行。对于每种计算资源（CPU和Memory）而言，每个节点都有一个能用于运行Pod的最大容量值。调度器在调度时，首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和，不超过该节点能提供给Pod使用的CPU和Memory的最大容量值；

72、简述Kubernetes Metric Service?

        答：在Kubernetes从1.10版本后采用Metrics Server作为默认的性能数据采集和监控，主要用于提供核心指标（Core Metrics），包括Node、Pod的CPU和内存使用指标。对其他自定义指标（Custom Metrics）的监控则由Prometheus等组件来完成；

73、简述Kubernetes中，如何使用EFK实现日志的统一管理？

        答：在Kubernetes集群环境中，通常一个完整的应用或服务涉及组件过多，建议对日志系统进行集中化管理，EFK是 Elasticsearch、Fluentd 和 Kibana 的组合，Elasticsearch：是一个搜索引擎，负责存储日志并提供查询接口；Fluentd：负责从 Kubernetes 搜集日志，每个node节点上面的fluentd监控并收集该节点上面的系统日志，并将处理过后的日志信息发送给Elasticsearch；Kibana：提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的日志；

74、简述Kubernetes如何进行优雅的节点关机维护?

        答：由于Kubernetes节点运行大量Pod，因此在进行关机维护之前，建议先使用kubectl drain将该节点的Pod进行驱逐，然后进行关机维护；

75、简述Kubernetes集群联邦?

        答：Kubernetes集群联邦可以将多个Kubernetes集群作为一个集群进行管理。因此，可以在一个数据中心/云中创建多个Kubernetes集群，并使用集群联邦在一个地方控制/管理所有集群；

76、简述Helm及其优势?

        答：Helm 是 Kubernetes 的软件包管理工具，Helm能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。 Helm中通常每个包称为一个Chart，一个Chart是一个目录，优势：1）统一管理、配置和更新这些分散的 k8s 的应用资源文件；2）分发和复用一套应用模板；3）将应用的一系列资源当做一个软件包管理；4）对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库；5）对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序；

77、标签与标签选择器的作用是什么?

        答：1）标签可以附加在kubernetes任何资源对象之上的键值型数据，常用于标签选择器的匹配度检查，从而完成资源筛选；2）标签选择器用于表达标签的查询条件或选择标准，Kubernetes API目前支持两个选择器：基于等值关系（equality-based）的标签选项器以及基于集合关系（set-based）的标签选择器；

78、什么是Google容器引擎?

        答：Google Container Engine（GKE）是Docker容器和集群的开源管理平台。这个基于 Kubernetes的引擎仅支持在Google的公共云服务中运行的群集；

79、pod的共享资源？

        答：1）PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID；2）网络命名空间：Pod 中的多个容器能够访问同一个IP和端口范围；3）IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信；4）UTS 命名空间：Pod 中的多个容器共享一个主机名；5）Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes；

80、Pod到Service的通信？

        答：1）k8s在创建服务时为服务分配一个虚拟IP，客户端通过该IP访问服务，服务则负责将请求转发到后端Pod上；2）Service是通过kube-proxy服务进程实现，该进程在每个Node上均运行可以看作一个透明代理兼负载均衡器；3）对每个TCP类型Service，kube-proxy都会在本地Node上建立一个SocketServer来负责接受请求，然后均匀发送到后端Pod默认采用Round Robin负载均衡算法；4）Service的Cluster IP与NodePort等概念是kube-proxy通过Iptables的NAT转换实现，kube-proxy进程动态创建与Service相关的Iptables规则；5）kube-proxy通过查询和监听API Server中Service与Endpoints的变化来实现其主要功能，包括为新创建的Service打开一个本地代理对象，接收请求针对针对发生变化的Service列表，kube-proxy会逐个处理；

81、image的状态有那些？

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

82、Service这种资源对象的作用是什么?

        答：service就是将多个POD划分到同一个逻辑组中，并统一向外提供服务，POD是通过Label  Selector加入到指定的service中。Service相当于是一个负载均衡器，用户请求会先到达service，再由service转发到它内部的某个POD上，通过 services.spec.type 字段来指定：1）ClusterIP：用于集群内部访问。该类型会为service分配一个IP，集群内部请求先到达service，再由service转发到其内部的某个POD上；2）NodePort：用于集群外部访问。该类型会将Service的Port映射到集群的每个Node节点上，然后在集群之外，就能通过Node节点上的映射端口访问到这个Service；3）LoadBalancer：用于集群外部访问。该类型是在所有Node节点前又挂了一个负载均衡器，作为集群外部访问的统一入口，外部流量会先到达LoadBalancer，再由它转发到集群的node节点上，通过nodePort再转发给对应的service，最后由service转发到后端Pod中；4）ExternalName：创建一个DNS别名（即CNAME）并指向到某个Service Name上，也就是为某个Service Name添加一条CNAME记录，当有请求访问这个CNAME时会自动解析到这个Service Name上；

83、常用的标签分类有哪些?

        答：release（版本）：stable（稳定版）、canary（金丝雀版本）、beta（测试版本）、environment（环境变量）：dev（开发）、qa（测试）、production（生产）、application（应用）：ui、as（application software应用软件）、pc、sc、tier（架构层级）：frontend（前端）、backend（后端）、cache（缓存）、partition（分区）：customerA（客户A）、customerB（客户B）、track（品控级别）：daily（每天）、weekly（每周）；

84、说说你对Job这种资源对象的了解?

        答：Job控制一组Pod容器，可以通过Job这种资源对象定义并启动一个批处理任务的Job，其中Job所控制的Pod副本是短暂运行的，可以将其视为一组Docker容器，每个Docker容器都仅仅运行一次，当Job控制的所有Pod的副本都运行结束时，对应的Job也就结来。Job生成的副本是不能自动重启的，对应的Pod副本的RestartPolicy都被设置为Never。Job所控制的Pod副本的工作模式能够多实例并行计算。

85、 k8s是怎么进行服务注册的?

        答：1）Service创建的时候会向 API Server 用 POST 方式提交一个新的 Service 定义，这个请求需要经过认证、鉴权以及其它的准入策略检查过程之后才会放行；2）CoreDns 会为Service创建一个dns记录，Service 得到一个 ClusterIP（虚拟 IP 地址），并保存到集群数据仓库；3）在集群范围内传播 Service 配置；

86、Kubernetes与Docker Swarm的区别如何?

        答：1）安装和部署：k8s安装很复杂;但是一旦安装完毕，集群就非常强大，Docker Swarm安装非常简单;但是集群不是很强大;2)图形用户界面：k8s有，Docker Swarm无；3）可伸缩性：k8s支持，Docker Swarm比k8s快5倍；4）自动伸缩：k8s有，Docker Swarm无；5）负载均衡：k8s在不同的Pods中的不同容器之间平衡负载流量，需要手动干预，Docker Swarm可以自动平衡集群中容器之间的流量；6）滚动更新回滚：k8s支持，Docker Swarm可以部署滚动更新，但不能自动回滚；7）数据量：k8s可以共享存储卷。只能与其他集装箱在同一Pod，Docker Swarm可以与任何其他容器共享存储卷；8）日志记录和监控：k8s内置的日志和监控工具，Docker Swarm要用第三方工具进行日志记录和监控；

87、什么是Container Orchestration?

        答：1）资源编排 - 负责资源的分配，如限制 namespace 的可用资源，scheduler 针对资源的不同调度策略；2）工作负载编排 - 负责在资源之间共享工作负载，如 Kubernetes 通过不同的 controller 将 Pod 调度到合适的 node 上，并且负责管理它们的生命周期；3）服务编排 - 负责服务发现和高可用等，如 Kubernetes 中可用通过 Service 来对内暴露服务，通过 Ingress 来对外暴露服务；容器编排常用的控制器有：Deployment 经常被作为无状态实例控制器使用; StatefulSet 是一个有状态实例控制器; DaemonSet 可以指定在选定的 Node 上跑，每个 Node 上会跑一个副本，它有一个特点是它的 Pod 的调度不经过调度器，在 Pod 创建的时候就直接绑定 NodeName；最后一个是定时任务，它是一个上级控制器，和 Deployment 有些类似，当一个定时任务触发的时候，它会去创建一个 Job ，具体的任务实际上是由 Job 来负责执行的；

88、什么是Heapster?

        答：Heapster 是 K8s 原生的集群监控方案。Heapster 以 Pod 的形式运行，它会自动发现集群节点、从节点上的 Kubelet 获取监控数据。Kubelet 则是从节点上的 cAdvisor 收集数据；

89、k8s Architecture的不同组件有哪些?

        答：主要有两个组件 – 主节点和工作节点。主节点具有kube-controller-manager，kube-apiserver，kube-scheduler等组件。而工作节点具有kubelet和kube-proxy等组件；

90、 能否介绍一下Kubernetes中主节点的工作情况?

        答：主节点是集群控制节点，负责集群管理和控制，包含：1）apiserver: rest接口，资源增删改查入口；2）controller-manager:所有资源对象的控制中心；3）scheduler:负责资源调度，例如pod调度；4）etcd: 保存资源对象数据；

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

        答：kube-apiserver: rest接口，增删改查接口，集群内模块通信；kube-scheduler: 将待调度的pod按照调度算法绑定到合适的pod，并将绑定信息写入etcd；

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

        答：是集群内部的控制中心，负责node,pod,namespace等管理，控制管理器负责管理各种控制器，每个控制器通过api server监控资源对象状态，将现有状态修正到期望状态；

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

        答：ClusterIP、NodePort、LoadBalancer、ExternalName；

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

        答：1）内部负载均衡器: 自动平衡负载并使用所需配置分配容器；2）外部负载均衡器: 将流量从外部负载引导至后端容器；

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

        答：1）确保容器本身安全；2）锁定容器的Linux内核；3）使用基于角色的访问控制（RBAC）；4）保守秘密的辛勤工作；5）保持网络安全；

1、 k8s是什么？请说出你的了解？
答：Kubernetes是一个针对容器应用，进行自动部署，弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。

K8S是Google公司推出的，它来源于由Google公司内部使用了15年的Borg系统，集结了Borg的精华。

2、 K8s架构的组成是什么？
答：和大多数分布式系统一样，K8S集群至少需要一个主节点（Master）和多个计算节点（Node）。

主节点主要用于暴露API，调度部署和节点的管理；

计算节点运行一个容器运行环境，一般是docker环境（类似docker环境的还有rkt），同时运行一个K8s的代理（kubelet）用于和master通信。计算节点也会运行一些额外的组件，像记录日志，节点监控，服务发现等等。计算节点是k8s集群中真正工作的节点。

K8S架构细分：

1、Master节点（默认不参加实际工作）：

Kubectl：客户端命令行工具，作为整个K8s集群的操作入口；

Api Server：在K8s架构中承担的是“桥梁”的角色，作为资源操作的唯一入口，它提供了认证、授权、访问控制、API注册和发现等机制。客户端与k8s群集及K8s内部组件的通信，都要通过Api Server这个组件；

Controller-manager：负责维护群集的状态，比如故障检测、自动扩展、滚动更新等；

Scheduler：负责资源的调度，按照预定的调度策略将pod调度到相应的node节点上；

Etcd：担任数据中心的角色，保存了整个群集的状态；

2、Node节点：

Kubelet：负责维护容器的生命周期，同时也负责Volume和网络的管理，一般运行在所有的节点，是Node节点的代理，当Scheduler确定某个node上运行pod之后，会将pod的具体信息（image，volume）等发送给该节点的kubelet，kubelet根据这些信息创建和运行容器，并向master返回运行状态。（自动修复功能：如果某个节点中的容器宕机，它会尝试重启该容器，若重启无效，则会将该pod杀死，然后重新创建一个容器）；

Kube-proxy：Service在逻辑上代表了后端的多个pod。负责为Service提供cluster内部的服务发现和负载均衡（外界通过Service访问pod提供的服务时，Service接收到的请求后就是通过kube-proxy来转发到pod上的）；

container-runtime：是负责管理运行容器的软件，比如docker

Pod：是k8s集群里面最小的单位。每个pod里边可以运行一个或多个container（容器），如果一个pod中有两个container，那么container的USR（用户）、MNT（挂载点）、PID（进程号）是相互隔离的，UTS（主机名和域名）、IPC（消息队列）、NET（网络栈）是相互共享的。我比较喜欢把pod来当做豌豆夹，而豌豆就是pod中的container；

3、 容器和主机部署应用的区别是什么？
答：容器的中心思想就是秒级启动；一次封装、到处运行；这是主机部署应用无法达到的效果，但同时也更应该注重容器的数据持久化问题。

另外，容器部署可以将各个服务进行隔离，互不影响，这也是容器的另一个核心概念。

4、请你说一下kubernetes针对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次。

上面两种探针都支持以下三种探测方法：

**1）Exec：**通过执行命令的方式来检查服务是否正常，比如使用cat命令查看pod中的某个重要配置文件是否存在，若存在，则表示pod健康。反之异常。

Exec探测方式的yaml文件语法如下：

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:         #选择livenessProbe的探测机制
      exec:                      #执行以下命令
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5          #在容器运行五秒后开始探测
      periodSeconds: 5               #每次探测的时间间隔为5秒
在上面的配置文件中，探测机制为在容器运行5秒后，每隔五秒探测一次，如果cat命令返回的值为“0”，则表示健康，如果为非0，则表示异常。

**2）Httpget：**通过发送http/htps请求检查服务是否正常，返回的状态码为200-399则表示容器健康（注http get类似于命令curl -I）。

Httpget探测方式的yaml文件语法如下：

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    livenessProbe:              #采用livenessProbe机制探测
      httpGet:                  #采用httpget的方式
    scheme:HTTP         #指定协议，也支持https
        path: /healthz          #检测是否可以访问到网页根目录下的healthz网页文件
        port: 8080              #监听端口是8080
      initialDelaySeconds: 3     #容器运行3秒后开始探测
      periodSeconds: 3                #探测频率为3秒
上述配置文件中，探测方式为项容器发送HTTP GET请求，请求的是8080端口下的healthz文件，返回任何大于或等于200且小于400的状态码表示成功。任何其他代码表示异常。

3）tcpSocket： 通过容器的IP和Port执行TCP检查，如果能够建立TCP连接，则表明容器健康，这种方式与HTTPget的探测机制有些类似，tcpsocket健康检查适用于TCP业务。

tcpSocket探测方式的yaml文件语法如下：

spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
- containerPort: 8080
#这里两种探测机制都用上了，都是为了和容器的8080端口建立TCP连接
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

在上述的yaml配置文件中，两类探针都使用了，在容器启动5秒后，kubelet将发送第一个readinessProbe探针，这将连接容器的8080端口，如果探测成功，则该pod为健康，十秒后，kubelet将进行第二次连接。

除了readinessProbe探针外，在容器启动15秒后，kubelet将发送第一个livenessProbe探针，仍然尝试连接容器的8080端口，如果连接失败，则重启容器。

探针探测的结果无外乎以下三者之一：

Success：Container通过了检查；

Failure：Container没有通过检查；

Unknown：没有执行检查，因此不采取任何措施（通常是我们没有定义探针检测，默认为成功）。

若觉得上面还不够透彻，可以移步其官网文档：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

5、 如何控制滚动更新过程？
答：可以通过下面的命令查看到更新时可以控制的参数：

[root@master yaml]# kubectl explain deploy.spec.strategy.rollingUpdate
maxSurge： 此参数控制滚动更新过程，副本总数超过预期pod数量的上限。可以是百分比，也可以是具体的值。默认为1。

（上述参数的作用就是在更新过程中，值若为3，那么不管三七二一，先运行三个pod，用于替换旧的pod，以此类推）

maxUnavailable： 此参数控制滚动更新过程中，不可用的Pod的数量。

（这个值和上面的值没有任何关系，举个例子：我有十个pod，但是在更新的过程中，我允许这十个pod中最多有三个不可用，那么就将这个参数的值设置为3，在更新的过程中，只要不可用的pod数量小于或等于3，那么更新过程就不会停止）。

6、K8s中镜像的下载策略是什么？
7、 image的状态有哪些？
8、 pod的重启策略是什么？
9、 Service这种资源对象的作用是什么？
10、版本回滚相关的命令？
11、 标签与标签选择器的作用是什么？
12、 常用的标签分类有哪些？
13、 有几种查看标签的方式？
14、 添加、修改、删除标签的命令？
15、 DaemonSet资源对象的特性？
16、 说说你对Job这种资源对象的了解？
17、描述一下pod的生命周期有哪些状态？
18、 创建一个pod的流程是什么？
19、 删除一个Pod会发生什么事情？
20、 K8s的Service是什么？
21、 k8s是怎么进行服务注册的？
22、 k8s集群外流量怎么访问Pod？
23、 k8s数据持久化的方式有哪些？

1、简述ETCD及其特点?
2、简述ETCD适应的场景?
3、简述什么是Kubernetes?
4、简述Kubernetes和Docker的关系?
5、简述Kubernetes中什么是Minikube、Kubectl、Kubele t?
6、简述Kubernetes常见的部署方式?
7、简述Kubernetes如何实现集群管理?8、简述Kubernetes的优势、适应场景及其特点?
9、简述Kubernetes的缺点或当前的不足之处?
10、简述Kubernetes相关基础概念?
11、简述Kubernetes集群相关组件?12、简述Kubernetes RC的机制?
13、简述kube-proxy作用?
14、简述kube-proxy iptables原理?15、简述kube-proxy ipvs原理?
16、简述kube-proxy ipvs和iptables的异同?17、简述Kubernetes中什么是静态Pod?18、简述Kubernetes中Pod可能位于的状态?19、简述Kubernetes创建一个Pod的主要流程?
20、简述Kubernetes中Pod的重启策略?21、简述Kubernetes中Pod的健康检查方式?
22、简述Kubernetes Pod的LivenessProbe探针的常见方式?
23、简述Kubernetes Pod的常见调度方式?
24、简述Kubernetes初始化容器（init container）?
25、简述Kubernetes deployment升级过程?
26、简述Kubernetes deployment升级策略?
27、简述Kubernetes DaemonSet类型的资源特性?
28、简述Kubernetes自动扩容机制?
29、简述Kubernetes Service类型?
30、简述Kubernetes Service分发后端的策略?
31、简述Kubernetes Headless Service?
32、简述Kubernetes外部如何访问集群内的服务?
33、简述Kubernetes ingress?
34、简述Kubernetes镜像的下载策略?35、简述Kubernetes的负载均衡器?
36、简述Kubernetes各模块如何与API Server通信?
37、简述Kubernetes Scheduler作用及实现原理?38、简述Kubernetes Scheduler使用哪两种算法将Pod绑定到worker节点?
39、简述Kubernetes kubelet的作用?
40、简述Kubernetes kubelet监控Worker节点资源是使用什么组件来实现的?
41、简述Kubernetes如何保证集群的安全性?
42、简述Kubernetes准入机制?
43、简述Kubernetes RBAC及其特点（优势）?44、简述Kubernetes Secret作用?
45、简述Kubernetes Secret有哪些使用方式?
46、简述Kubernetes PodSecurityPolicy机制?
47、简述Kubernetes PodSecurityPolicy机制能实现哪些安全策略?
48、简述Kubernetes网络模型?
49、简述Kubernetes CNI模型?
50、简述Kubernetes网络策略?
51、简述Kubernetes网络策略原理?52、简述Kubernetes中flannel的作用?53、简述Kubernetes Calico网络组件实现原理?54、简述Kubernetes共享存储的作用?
55、简述Kubernetes数据持久化的方式有哪些?56、简述Kubernetes PV和PVC?
57、简述Kubernetes PV生命周期内的阶段?58、简述Kubernetes所支持的存储供应模式?
59、简述Kubernetes CSI模型?
60、简述Kubernetes Worker节点加入集群的过程?
61、简述Kubernetes Pod如何实现对节点的资源控制?
62、简述Kubernetes Requests和Limits如何影响Pod的调度?
63、简述Kubernetes Metric Service?
64、简述Kubernetes中，如何使用EFK实现日志的统一管理n
65、简述Kubernetes如何进行优雅的节点关机维护?
66、简述Kubernetes集群联邦?
67、简述Helm及其优势?
68、k8s是什么?请说出你的了解?
69、K8s架构的组成是什么?
69、 容器和主机部署应用的区别是什么?
70、请你说一下kubenetes针对pod资源对象的健康监测机制?
71、如何控制滚动更新过程?
72、K8s中镜像的下载策略是什么?73、image的状态有哪些?
74、pod的重启策略是什么?
75、Service这种资源对象的作用是什么?
76、版本回滚相关的命令?
77、标签与标签选择器的作用是什么?
78、常用的标签分类有哪些?
79、有几种查看标签的方式?
80、添加、修改、删除标签的命令?
81、DaemonSet资源对象的特性?
82、说说你对Job这种资源对象的了解?
83、描述一下pod的生命周期有哪些状态?
84、创建一个pod的流程是什么?85、删除一个Pod会发生什么事情?
86、K8s的Service是什么?
87、k8s是怎么进行服务注册的?
88、k8s集群外流量怎么访问Pod?
89、k8s数据持久化的方式有哪些?
90、Kubernetes与Docker Swarm的区别如何?
91、什么是Kubernetes?
92、Kubernetes与Docker有什么关系?
93、在主机和容器上部署应用程序有什么区别?
94、什么是Container Orchestration?
95、Container Orchestration需要什么?
96、Kubernetes有什么特点?
97、Kubernetes如何简化容器化部署?
98、对Kubernetes的集群了解多少?
99、什么是Google容器引擎?
100、什么是Heapster?
101、什么是Minikube?
102、什么是Kubectl?
103、什么是Kubelet?
104、Kubernetes Architecture的不同组件有哪些?
105、你对Kube-proxy有什么了解?
106、能否介绍一下Kubernetes中主节点的工作情况?
107、kube-apiserver和kube-scheduler的作用是什么?
108、你能简要介绍一下Kubernetes控制管理器吗?
109、什么是ETCD?
110、Kubernetes有哪些不同类型的服务?
111、你对Kubernetes的负载均衡器有什么了解?
112、什么是Ingress网络，它是如何工作的?
113、您对云控制器管理器有何了解?114、什么是Container资源监控?
115、Replica Set和Replication Controller之间有什么区别?
116、什么是Headless Service?
117、使用Kubernetes时可以采取哪些最佳安全措施?118、什么是集群联邦?
119、您如何看待公司从单—服务转向微服务并部署其服务容器?
120、考虑一家拥有分布式系统的跨国公司，拥有大量数据中心，虚拟机和许多从事各种任务的员工。您认为这样公司如何以与Kubernetes一致的方式管理所有任务?
121、考虑一种情况，即公司希望通过维持最低成本来提高其效率和技术运营速度。您认为公司将如何实现这一目标?122、假设一家公司想要修改它的部署方法，并希望建立一个更具可扩展性和响应性的平台。您如何看待这家公司能够实现这一目标以满足客户需求?
123、考虑一家拥有非常分散的系统的跨国公司，期待解决整体代码库问题。您认为公司如何解决他们的问题?
124、我们所有人都知道，从单片到微服务的转变解决了开发方面的问题，但却增加了部署方面的问题。公司如何解决部署方面的问题?
125、公司如何有效地实现这种资源分配?
126、您认为公司如何处理服务器及其安装?
127、考虑一种情况，公司希望向具有各种环境的客户提供所有必需的分发。您认为他们如何以动态的方式实现这一关键目标?