1、简述ETCD及其特点？
etcd 是 CoreOS 团队发起的开源项目，是一个管理配置信息和服务发现（service discovery）的项目，它的目标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现。
特点：
简单：支持 REST 风格的 HTTP+JSON API
安全：支持 HTTPS 方式的访问
快速：支持并发 1k/s 的写操作
可靠：支持分布式结构，基于 Raft 的一致性算法，Raft 是一套通过选举主节点来实现分布式
系统一致性的算法。
2、简述ETCD适应的场景？
etcd基于其优秀的特点，可广泛的应用于以下场景：
**服务发现(Service Discovery)**：服务发现主要解决在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且
通过名字就可以查找和连接。
消息发布与订阅：在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到etcd上进行集中管理。
负载均衡：在分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。etcd本身分布式架构存储的信息访问支持负载均衡。etcd集群化以后，每个etcd的核心节点都可以处理用户的请求。所以，把数据量小但是访问频繁的消息数据直接存储到etcd中也可以实现负载均衡的效果。
分布式通知与协调：与消息发布和订阅类似，都用到了etcd中的Watcher机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。
分布式锁：因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。
集群监控与Leader竞选：通过etcd来进行监控实现起来非常简单并且实时性强。
3、简述什么是Kubernetes？
Kubernetes是一个全新的基于容器技术的分布式系统支撑平台。是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力，多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。
4、简述Kubernetes和Docker的关系？
Docker 提供容器的生命周期管理和，Docker 镜像构建运行时容器。它的主要优点是将将软件/应用程序运行所需的设置和依赖项打包到一个容器中，从而实现了可移植性等优点。
Kubernetes 用于关联和编排在多个主机上运行的容器。
5、简述Kubernetes中什么是Minikube、Kubectl、Kubelet？
Minikube 是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具。
Kubectl 是一个命令行工具，可以使用该工具控制Kubernetes集群管理器，如检查群集资源，创建、删除和更新组件，查看应用程序。
Kubelet 是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。
6、简述Kubernetes常见的部署方式？
常见的Kubernetes部署方式有：
kubeadm：也是推荐的一种部署方式；
二进制
minikube
7、简述Kubernetes如何实现集群管理？
在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kubescheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。
8、简述Kubernetes的优势、适应场景及其特点？
Kubernetes作为一个完备的分布式系统支撑平台，其主要优势：
容器编排
轻量级
开源
弹性伸缩
负载均衡
Kubernetes常见场景：
快速部署应用
快速扩展应用
无缝对接新的应用功能
节省资源，优化硬件资源的使用
Kubernetes相关特点：
可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）。
可扩展: 模块化,、插件化、可挂载、可组合。
自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展。
9、简述Kubernetes的缺点或当前的不足之处？
Kubernetes当前存在的缺点（不足）如下：
安装过程和配置相对困难复杂。
管理服务相对繁琐。
运行和编译需要很多时间。
它比其他替代品更昂贵。
对于简单的应用程序来说，可能不需要涉及Kubernetes即可满足。
10、简述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节点上，若干相关容器的组合(Kubernetes 之 Pod 实现原理)。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(Kubernetes 之服务发现)定义了Pod的逻辑集合和访问该集合的策略，是真实服务的
抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，
用户不需要了解后台Pod是如何运行。
Volume：Volume是Pod中能够被多个容器访问的共享目录，Kubernetes中的Volume是定义在Pod
上，可以被一个或多个Pod中的容器挂载到某个目录下。
Namespace：Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的
Namespace中，形成逻辑上的不同项目、小组或用户组，便于不同的Namespace在共享使用整个集群
的资源的同时还能被分别管理。
11、简述Kubernetes集群相关组件？
Kubernetes Master控制组件，调度管理整个系统（集群），包含如下组件:
Kubernetes API Server：作为Kubernetes系统的入口，其封装了核心对象的增删改查操作，以
RESTful API接口方式提供给外部客户和内部组件调用，集群内各个功能模块之间数据交互和通信的中心
枢纽。
Kubernetes Scheduler：为新建立的Pod进行节点(node)选择(即分配机器)，负责集群的资源调度。
Kubernetes Controller：负责执行各种控制器，目前已经提供了很多控制器来保证Kubernetes的正常
运行。
Replication Controller：管理维护Replication Controller，关联Replication Controller和Pod，保证
Replication Controller定义的副本数量与实际运行Pod数量一致。
Node Controller：管理维护Node，定期检查Node的健康状态，标识出(失效|未失效)的Node节点。
Namespace Controller：管理维护Namespace，定期清理无效的Namespace，包括Namesapce下
的API对象，比如Pod、Service等。
Service Controller：管理维护Service，提供负载以及服务代理。
EndPoints Controller：管理维护Endpoints，关联Service和Pod，创建Endpoints为Service的后端，
当Pod发生变化时，实时更新Endpoints。
Service Account Controller：管理维护Service Account，为每个Namespace创建默认的Service
Account，同时为Service Account创建Service Account Secret。
Persistent Volume Controller：管理维护Persistent Volume和Persistent Volume Claim，为新的
Persistent Volume Claim分配Persistent Volume进行绑定，为释放的Persistent Volume执行清理回
收。
Daemon Set Controller：管理维护Daemon Set，负责创建Daemon Pod，保证指定的Node上正常
的运行Daemon Pod。
Deployment Controller：管理维护Deployment，关联Deployment和Replication Controller，保证
运行指定数量的Pod。当Deployment更新时，控制实现Replication Controller和Pod的更新。
Job Controller：管理维护Job，为Jod创建一次性任务Pod，保证完成Job指定完成的任务数目
Pod Autoscaler Controller：实现Pod的自动伸缩，定时获取监控数据，进行策略匹配，当满足条件
时执行Pod的伸缩动作。
12、简述Kubernetes RC的机制？
Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。当定义了RC并提交至Kubernetes集群中之后，Master节点上的Controller Manager组件获悉，并同时巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，若存在过多的Pod副本在运行，系统会停止一些Pod，反之则自动创建一些Pod。
简述Kubernetes Replica Set 和 Replication Controller 之间有什么区别？Replica Set 和 ReplicationController 类似，都是确保在任何给定时间运行指定数量的 Pod 副本。不同之处在于RS 使用基于集合的选择器，而 Replication Controller 使用基于权限的选择器。
13、简述kube-proxy作用？
kube-proxy 运行在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
14、简述kube-proxy iptables原理？
Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。
15、简述kube-proxy ipvs原理？
IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡，并使用更高效的数据结
构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式。
在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。iptables规则链是一
个线性的数据结构，ipset则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配。
可以将ipset简单理解为一个IP（段）的集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables
可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少iptables规则的数量，
从而减少性能损耗。
16、简述kube-proxy ipvs和iptables的异同？
iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙
而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。
与iptables相比，IPVS拥有以下明显优势：
1、为大型集群提供了更好的可扩展性和性能；
2、支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；
3、支持服务器健康检查和连接重试等功能；
4、可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。
17、简述Kubernetes中什么是静态Pod？
静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过API Server进行管理，无法
与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对他们进行健康检
查。静态Pod总是由kubelet进行创建，并且总是在kubelet所在的Node上运行。
18、简述Kubernetes中Pod可能位于的状态？
Pending：API Server已经创建该Pod，且Pod内还有一个或多个容器的镜像没有创建，包括正在下载镜
像的过程。
Running：Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。
Succeeded：Pod内所有容器均成功执行退出，且不会重启。
Failed：Pod内所有容器均已退出，但至少有一个容器退出为失败状态。
Unknown：由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致。
19、简述Kubernetes创建一个Pod的主要流程？
Kubernetes中创建一个Pod涉及多个组件之间联动，主要流程如下：
1、客户端提交Pod的配置信息（可以是yaml文件定义的信息）到kube-apiserver。
2、Apiserver收到指令后，通知给controller-manager创建一个资源对象。
3、Controller-manager通过api-server将pod的配置信息存储到ETCD数据中心中。
4、Kube-scheduler检测到pod信息会开始调度预选，会先过滤掉不符合Pod资源配置要求的节
点，然后开始调度调优，主要是挑选出更适合运行pod的节点，然后将pod的资源配置单发送到
node节点上的kubelet组件上。
5、Kubelet根据scheduler发来的资源配置单运行pod，运行成功后，将pod的运行信息返回给
scheduler，scheduler将返回的pod运行状况的信息存储到etcd数据中心。
20、简述Kubernetes中Pod的重启策略？
Pod重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判
断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet将根据RestartPolicy的设置来进行相
应操作。
Pod的重启策略包括Always、OnFailure和Never，默认值为Always。
Always：当容器失效时，由kubelet自动重启该容器；
OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器；
Never：不论容器运行状态如何，kubelet都不会重启该容器。
同时Pod的重启策略与控制方式关联，当前可用于管理Pod的控制器包括ReplicationController、Job、
DaemonSet及直接管理kubelet管理（静态Pod）。
不同控制器的重启策略限制如下：
RC和DaemonSet：必须设置为Always，需要保证该容器持续运行；
Job：OnFailure或Never，确保容器执行完成后不再重启；
kubelet：在Pod失效时重启，不论将RestartPolicy设置为何值，也不会对Pod进行健康检查。
21、简述Kubernetes中Pod的健康检查方式？
对Pod的健康检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe。
LivenessProbe探针：用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不
健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含LivenessProbe
探针，kubelet认为该容器的LivenessProbe探针返回值用于是“Success”。
ReadineeProbe探针：用于判断容器是否启动完成（ready状态）。如果ReadinessProbe探针探测到
失败，则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod
的Eenpoint。
startupProbe探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探
针kill掉。
22、简述Kubernetes Pod的LivenessProbe探针的常见方式？
kubelet定期执行LivenessProbe探针来诊断容器的健康状态，通常有以下三种方式：
ExecAction：在容器内执行一个命令，若返回码为0，则表明容器健康。
TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，若能建立TCP连接，则表明容器健康。
HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，若响应的状态码大于等于200
且小于400，则表明容器健康。
23、简述Kubernetes Pod的常见调度方式？
Kubernetes中，Pod通常是容器的载体，主要有如下常见调度方式：
Deployment或RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副
本的数量，在集群内始终维持用户指定的副本数量。
NodeSelector：定向调度，当需要手动指定将Pod调度到特定Node上，可以通过Node的标签
（Label）和Pod的nodeSelector属性相匹配。
NodeAffinity亲和性调度：亲和性调度机制极大的扩展了Pod的调度能力，目前有两种节点亲和力
表达：
requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才
可以调度Pod至Node上（类似nodeSelector，语法不同）。
preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满足的Node的节
点，但不强求，多个优先级规则还可以设置权重值。
Taints和Tolerations（污点和容忍）：
Taint：使Node拒绝特定Pod运行；
Toleration：为Pod的属性，表示Pod能容忍（运行）标注了Taint的Node。
24、简述Kubernetes初始化容器（init container）？
init container的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个init
container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init
container。当所有init container都成功运行后，Kubernetes才会初始化Pod的各种信息，并开始创建
和运行应用容器。
25、简述Kubernetes deployment升级过程？
初始创建Deployment时，系统创建了一个ReplicaSet，并按用户的需求创建了对应数量的Pod副本。
当更新Deployment时，系统创建了一个新的ReplicaSet，并将其副本数量扩展到1，然后将旧
ReplicaSet缩减为2。
之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。
最后，新的ReplicaSet运行了对应个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0。
26、简述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）来控制滚动更新的过程。
27、简述Kubernetes DaemonSet类型的资源特性？
DaemonSet资源对象会在每个Kubernetes集群中的节点上运行，并且每个节点只能运行一个pod，这
是它和deployment资源对象的最大也是唯一的区别。因此，在定义yaml文件中，不支持定义replicas。
它的一般使用场景如下：
在去做每个节点的日志收集工作。
监控每个节点的的运行状态。
28、简述Kubernetes自动扩容机制？
Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器实现基于CPU使用率进行自动Pod扩缩容
的功能。HPA控制器周期性地监测目标Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对
比，在满足条件时对Pod副本数量进行调整。
HPA原理
Kubernetes中的某个Metrics Server（Heapster或自定义Metrics Server）持续采集所有Pod副本的指
标数据。HPA控制器通过Metrics Server的API（Heapster的API或聚合API）获取这些数据，基于用户定
义的扩缩容规则进行计算，得到目标Pod副本数量。
当目标Pod副本数量与当前副本数量不同时，HPA控制器就向Pod的副本控制器（Deployment、RC或
ReplicaSet）发起scale操作，调整Pod的副本数量，完成扩缩容操作。
29、简述Kubernetes Service类型？
通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发
到后端的各个容器应用上。其主要类型有：
ClusterIP：虚拟的服务IP地址，该地址用于Kubernetes集群内部的Pod访问，在Node上kubeproxy
通过设置的iptables规则进行转发；
NodePort：使用宿主机的端口，使能够访问各Node的外部客户端通过Node的IP地址和端口号就
能访问服务；
LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在spec.status.loadBalancer字
段指定外部负载均衡器的IP地址，通常用于公有云。
30、简述Kubernetes Service分发后端的策略？
Service负载分发的策略有：RoundRobin和SessionAffinity
RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个Pod上。
SessionAffinity：基于客户端IP地址进行会话保持的模式，即第1次将某个客户端发起的请求转发到
后端的某个Pod上，之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。
31、简述Kubernetes Headless Service？
在某些应用场景中，若需要人为指定负载均衡器，不使用Service提供的默认负载均衡的功能，或者应用
程序希望知道属于同组服务的其他实例。Kubernetes提供了Headless Service来实现这种功能，即不为
Service设置ClusterIP（入口IP地址），仅通过Label Selector将后端的Pod列表返回给调用的客户端。
32、简述Kubernetes外部如何访问集群内的服务？
对于Kubernetes，集群外的客户端默认情况，无法通过Pod的IP地址或者Service的虚拟IP地址:虚拟端口
号进行访问。通常可以通过以下方式进行访问Kubernetes集群内的服务：
映射Pod到物理机：将Pod端口号映射到宿主机，即在Pod中采用hostPort方式，以使客户端应用能够通
过物理机访问容器应用。
映射Service到物理机：将Service端口号映射到宿主机，即在Service中采用nodePort方式，以使客户端
应用能够通过物理机访问容器应用。
映射Sercie到LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种
用法仅用于在公有云服务提供商的云平台上设置Service的场景。
33、简述Kubernetes ingress？
Kubernetes的Ingress资源对象，用于将不同URL的访问请求转发到后端不同的Service，以实现HTTP层
的业务路由机制。
Kubernetes使用了Ingress策略和Ingress Controller，两者结合并实现了一个完整的Ingress负载均衡
器。使用Ingress进行负载分发时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service
对应的后端Endpoint（Pod）上，从而跳过kube-proxy的转发功能，kube-proxy不再起作用，全过程
为：ingress controller + ingress 规则 ----> services。
同时当Ingress Controller提供的是对外服务，则实际上实现的是边缘路由器的功能。
34、简述Kubernetes镜像的下载策略？
K8s的镜像下载策略有三种：Always、Never、IFNotPresent。
Always：镜像标签为latest时，总是从指定的仓库中获取镜像。
Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像。
IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。默认的镜像下载策略是：当镜像
标签是latest时，默认策略是Always；当镜像标签是自定义时（也就是标签不是latest），那么默认
策略是IfNotPresent。
35、简述Kubernetes的负载均衡器？
负载均衡器是暴露服务的最常见和标准方式之一。
根据工作环境使用两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。内部负载均衡器自动
平衡负载并使用所需配置分配容器，而外部负载均衡器将流量从外部负载引导至后端容器。