【从问题中去学习k8s】k8s中的常见面试题（夯实理论基础）（十四）

  本站以分享各种运维经验和运维所需要的技能为主

《python零基础入门》：python零基础入门学习

《python运维脚本》： python运维脚本实践

《shell》：shell学习

《terraform》持续更新中：terraform_Aws学习零基础入门到最佳实战

《k8》从问题中去学习k8s

《docker学习》暂未更新

《ceph学习》ceph日常问题解决分享

《日志收集》ELK+各种中间件

《运维日常》运维日常

《linux》运维面试100问

《DBA》db的介绍使用（mysql、redis、mongodb...）

思考一下问题：

66、简述Kubernetes集群联邦？

67、简述Helm及其优势？

68、 k8s是什么？请说出你的了解？以及K8s架构的组成是什么？

69、 容器和主机部署应用的区别是什么？

70、请你说一下kubenetes针对pod资源对象的健康监测机制？

参考答案：

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

67、简述Helm及其优势？
Helm 是 Kubernetes 的软件包管理工具。类似 Ubuntu 中使用的apt、Centos中使用的yum 或者
Python中的 pip 一样。
Helm能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。
Helm中通常每个包称为一个Chart，一个Chart是一个目录（一般情况下会将目录进行打包压缩，形成
name-version.tgz格式的单一文件，方便传输和存储）。
Helm优势
在 Kubernetes中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。使用
helm则具有如下优势：
统一管理、配置和更新这些分散的 k8s 的应用资源文件；
分发和复用一套应用模板；
将应用的一系列资源当做一个软件包管理。
对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到
软件仓库。
对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在
Kubernetes 上查找、安装、升级、回滚、卸载应用程序。

68、 k8s是什么？请说出你的了解？以及K8s架构的组成是什么？
答：Kubenetes是一个针对容器应用，进行自动部署，弹性伸缩和管理的开源系统。主要功能是生产环
境中的容器编排。
K8S是Google公司推出的，它来源于由Google公司内部使用了15年的Borg系统，集结了Borg的精华。

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；

69、 容器和主机部署应用的区别是什么？
答：容器的中心思想就是秒级启动；一次封装、到处运行；这是主机部署应用无法达到的效果，但同时
也更应该注重容器的数据持久化问题。
另外，容器部署可以将各个服务进行隔离，互不影响，这也是容器的另一个核心概念。

70、请你说一下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次。

上面两种探针都支持以下三种探测方法：
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-start
up-probes/