超详细！k8s 面试题总结

简述ETCD及其特色？

etcd 是 CoreOS 团队发起的开源项目，是一个管理配置信息和服务发现（service discovery）的项目，它的目标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现。

• 特色：
• 简单：支持 REST 风格的 HTTP+JSON API
• 安全：支持 HTTPS 方式的访问
• 快速：支持并发 1k/s 的写操做
• 可靠：支持分布式结构，基于 Raft 的一致性算法，Raft 是一套经过选举主节点来实现分布式系统一致性的算法。

简述ETCD适应的场景？

etcd基于其优秀的特色，可普遍的应用于如下场景：

服务发现(Service Discovery)：服务发现主要解决在同一个分布式集群中的进程或服务，要如何才能找到对方并创建链接。本质上来讲，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，而且经过名字就能够查找和链接。

消息发布与订阅：在分布式系统中，最适用的一种组件间通讯方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。经过这种方式能够作到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到etcd上进行集中管理。

负载均衡：在分布式系统中，为了保证服务的高可用以及数据的一致性，一般都会把数据和服务部署多份，以此达到对等服务，即便其中的某一个服务失效了，也不影响使用。etcd自己分布式架构存储的信息访问支持负载均衡。etcd集群化之后，每一个etcd的核心节点均可以处理用户的请求。因此，把数据量小可是访问频繁的消息数据直接存储到etcd中也能够实现负载均衡的效果。

分布式通知与协调：与消息发布和订阅相似，都用到了etcd中的Watcher机制，经过注册与异步通知机制，实现分布式环境下不一样系统之间的通知与协调，从而对数据变动作到实时处理。

分布式锁：由于etcd使用Raft算法保持了数据的强一致性，某次操做存储到集群中的值必然是全局一致的，因此很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。

集群监控与Leader竞选：经过etcd来进行监控实现起来很是简单而且实时性强。

简述什么是Kubernetes？

Kubernetes是一个全新的基于容器技术的分布式系统支撑平台。是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提升了大规模容器集群管理的便捷性。而且具备完备的集群管理能力，多层次的安全防御和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。

简述Kubernetes和Docker的关系？

Docker 提供容器的生命周期管理和，Docker 镜像构建运行时容器。它的主要优势是将将软件/应用程序运行所需的设置和依赖项打包到一个容器中，从而实现了可移植性等优势。

Kubernetes 用于关联和编排在多个主机上运行的容器。

简述Kubernetes中什么是Minikube、Kubectl、Kubelet？

Minikube 是一种能够在本地轻松运行一个单节点 Kubernetes 群集的工具。

Kubectl 是一个命令行工具，可使用该工具控制Kubernetes集群管理器，如检查群集资源，建立、删除和更新组件，查看应用程序。

Kubelet 是一个代理服务，它在每一个节点上运行，并使从服务器与主服务器通讯。

简述Kubernetes常见的部署方式？

常见的Kubernetes部署方式有：

• kubeadm：也是推荐的一种部署方式；
• 二进制：CentOS 搭建 K8S，一次性成功，收藏了！
• minikube：在本地轻松运行一个单节点 Kubernetes 群集的工具。
• 简单几步，无坑部署最小化 K8S 集群
• Kubernetes 部署如此简单，看彻底明白了

简述Kubernetes如何实现集群管理？

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

简述Kubernetes的优点、适应场景及其特色？

Kubernetes做为一个完备的分布式系统支撑平台，其主要优点：

• 容器编排
• 轻量级
• 开源
• 弹性伸缩
• 负载均衡

Kubernetes常见场景：

• 快速部署应用
• 快速扩展应用
• 无缝对接新的应用功能
• 节省资源，优化硬件资源的使用

Kubernetes相关特色：

• 可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）。
• 可扩展: 模块化,、插件化、可挂载、可组合。
• 自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展。

简述Kubernetes的缺点或当前的不足之处？

Kubernetes当前存在的缺点（不足）以下：

• 安装过程和配置相对困难复杂。
• 管理服务相对繁琐。
• 运行和编译须要不少时间。
• 它比其余替代品更昂贵。
• 对于简单的应用程序来讲，可能不须要涉及Kubernetes便可知足。

简述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在共享使用整个集群的资源的同时还能被分别管理。

简述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的伸缩动做。

简述Kubernetes RC的机制？

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

简述Kubernetes Replica Set 和 Replication Controller 之间有什么区别？Replica Set 和 Replication Controller 相似，都是确保在任何给定时间运行指定数量的 Pod 副本。不一样之处在于RS 使用基于集合的选择器，而 Replication Controller 使用基于权限的选择器。

简述kube-proxy做用？

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

简述kube-proxy iptables原理？

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

简述kube-proxy ipvs原理？

IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），容许几乎无限的规模扩张，所以被kube-proxy采纳为最新模式。

在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构，所以当规则不少时，也能够很高效地查找和匹配。

能够将ipset简单理解为一个IP（段）的集合，这个集合的内容能够是IP地址、IP网段、端口等，iptables能够直接添加规则对这个“可变的集合”进行操做，这样作的好处在于能够大大减小iptables规则的数量，从而减小性能损耗。

简述kube-proxy ipvs和iptables的异同？

iptables与IPVS都是基于Netfilter实现的，但由于定位不一样，两者有着本质的差异：iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），容许几乎无限的规模扩张。

与iptables相比，IPVS拥有如下明显优点：

• 一、为大型集群提供了更好的可扩展性和性能；
• 二、支持比iptables更复杂的复制均衡算法（最小负载、最少链接、加权等）；
• 三、支持服务器健康检查和链接重试等功能；
• 四、能够动态修改ipset的集合，即便iptables的规则正在使用这个集合。

简述Kubernetes中什么是静态Pod？

静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能经过API Server进行管理，没法与ReplicationController、Deployment或者DaemonSet进行关联，而且kubelet没法对他们进行健康检查。静态Pod老是由kubelet进行建立，而且老是在kubelet所在的Node上运行。

简述Kubernetes中Pod可能位于的状态？

Pending：API Server已经建立该Pod，且Pod内还有一个或多个容器的镜像没有建立，包括正在下载镜像的过程。

Running：Pod内全部容器均已建立，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。

Succeeded：Pod内全部容器均成功执行退出，且不会重启。

Failed：Pod内全部容器均已退出，但至少有一个容器退出为失败状态。

Unknown：因为某种缘由没法获取该Pod状态，可能因为网络通讯不顺畅致使。

简述Kubernetes建立一个Pod的主要流程？

Kubernetes中建立一个Pod涉及多个组件之间联动，主要流程以下：

• 一、客户端提交Pod的配置信息（能够是yaml文件定义的信息）到kube-apiserver。
• 二、Apiserver收到指令后，通知给controller-manager建立一个资源对象。
• 三、Controller-manager经过api-server将pod的配置信息存储到ETCD数据中心中。
• 四、Kube-scheduler检测到pod信息会开始调度预选，会先过滤掉不符合Pod资源配置要求的节点，而后开始调度调优，主要是挑选出更适合运行pod的节点，而后将pod的资源配置单发送到node节点上的kubelet组件上。
• 五、Kubelet根据scheduler发来的资源配置单运行pod，运行成功后，将pod的运行信息返回给scheduler，scheduler将返回的pod运行情况的信息存储到etcd数据中心。

简述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进行健康检查。

简述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掉。

简述Kubernetes Pod的LivenessProbe探针的常见方式？

kubelet按期执行LivenessProbe探针来诊断容器的健康状态，一般有如下三种方式：

ExecAction：在容器内执行一个命令，若返回码为0，则代表容器健康。

TCPSocketAction：经过容器的IP地址和端口号执行TCP检查，若能创建TCP链接，则代表容器健康。

HTTPGetAction：经过容器的IP地址、端口号及路径调用HTTP Get方法，若响应的状态码大于等于200且小于400，则代表容器健康。

简述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。

简述Kubernetes初始化容器（init container）？

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

简述Kubernetes deployment升级过程？

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

简述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）来控制滚动更新的过程。

简述Kubernetes DaemonSet类型的资源特性？

DaemonSet资源对象会在每一个Kubernetes集群中的节点上运行，而且每一个节点只能运行一个pod，这是它和deployment资源对象的最大也是惟一的区别。所以，在定义yaml文件中，不支持定义replicas。

它的通常使用场景以下：

• 在去作每一个节点的日志收集工做。
• 监控每一个节点的的运行状态。

简述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的副本数量，完成扩缩容操做。

简述Kubernetes Service类型？

经过建立Service，能够为一组具备相同功能的容器应用提供一个统一的入口地址，而且将请求负载分发到后端的各个容器应用上。其主要类型有：

• ClusterIP：虚拟的服务IP地址，该地址用于Kubernetes集群内部的Pod访问，在Node上kube-proxy经过设置的iptables规则进行转发；
• NodePort：使用宿主机的端口，使可以访问各Node的外部客户端经过Node的IP地址和端口号就能访问服务；
• LoadBalancer：使用外接负载均衡器完成到服务的负载分发，须要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址，一般用于公有云。

简述Kubernetes Service分发后端的策略？

Service负载分发的策略有：RoundRobin和SessionAffinity

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

简述Kubernetes Headless Service？

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

简述Kubernetes外部如何访问集群内的服务？

对于Kubernetes，集群外的客户端默认状况，没法经过Pod的IP地址或者Service的虚拟IP地址:虚拟端口号进行访问。一般能够经过如下方式进行访问Kubernetes集群内的服务：

映射Pod到物理机：将Pod端口号映射到宿主机，即在Pod中采用hostPort方式，以使客户端应用可以经过物理机访问容器应用。

映射Service到物理机：将Service端口号映射到宿主机，即在Service中采用nodePort方式，以使客户端应用可以经过物理机访问容器应用。

映射Sercie到LoadBalancer：经过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景。

简述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提供的是对外服务，则实际上实现的是边缘路由器的功能。

简述Kubernetes镜像的下载策略？

K8s的镜像下载策略有三种：Always、Never、IFNotPresent。

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

简述Kubernetes的负载均衡器？

负载均衡器是暴露服务的最多见和标准方式之一。

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

简述Kubernetes各模块如何与API Server通讯？

Kubernetes API Server做为集群的核心，负责集群各功能模块之间的通讯。集群内的各个功能模块经过API Server将信息存入etcd，当须要获取和操做这些数据时，则经过API Server提供的REST接口（用GET、LIST或WATCH方法）来实现，从而实现各模块之间的信息交互。

如kubelet进程与API Server的交互：每一个Node上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自身状态，API Server在接收到这些信息后，会将节点状态信息更新到etcd中。

如kube-controller-manager进程与API Server的交互：kube-controller-manager中的Node Controller模块经过API Server提供的Watch接口实时监控Node的信息，并作相应处理。

如kube-scheduler进程与API Server的交互：Scheduler经过API Server的Watch接口监听到新建Pod副本的信息后，会检索全部符合该Pod要求的Node列表，开始执行Pod调度逻辑，在调度成功后将Pod绑定到目标节点上。

简述Kubernetes Scheduler做用及实现原理？

Kubernetes Scheduler是负责Pod调度的重要功能模块，Kubernetes Scheduler在整个系统中承担了“承上启下”的重要功能，“承上”是指它负责接收Controller Manager建立的新Pod，为其调度至目标Node；“启下”是指调度完成后，目标Node上的kubelet服务进程接管后继工做，负责Pod接下来生命周期。

Kubernetes Scheduler的做用是将待调度的Pod（API新建立的Pod、Controller Manager为补足副本而建立的Pod等）按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的Node上，并将绑定信息写入etcd中。

在整个调度过程当中涉及三个对象，分别是待调度Pod列表、可用Node列表，以及调度算法和策略。

Kubernetes Scheduler经过调度算法调度为待调度Pod列表中的每一个Pod从Node列表中选择一个最适合的Node来实现Pod的调度。随后，目标节点上的kubelet经过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，而后获取对应的Pod清单，下载Image镜像并启动容器。

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

Kubernetes Scheduler根据以下两种调度算法将 Pod 绑定到最合适的工做节点：

预选（Predicates）：输入是全部节点，输出是知足预选条件的节点。kube-scheduler根据预选策略过滤掉不知足策略的Nodes。若是某节点的资源不足或者不知足预选策略的条件则没法经过预选。如“Node的label必须与Pod的Selector一致”。

优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为经过预选的Nodes进行打分排名，选择得分最高的Node。例如，资源越富裕、负载越小的Node可能具备越高的排名。

简述Kubernetes kubelet的做用？

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

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

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

简述Kubernetes如何保证集群的安全性？

Kubernetes经过一系列机制来实现集群的安全控制，主要有以下不一样的维度：

• 基础设施方面：保证容器与其所在宿主机的隔离；
• 权限方面：
• 最小权限原则：合理限制全部组件的权限，确保组件只执行它被受权的行为，经过限制单个组件的能力来限制它的权限范围。
• 用户权限：划分普通用户和管理员的角色。
• 集群方面：
• API Server的认证受权：Kubernetes集群中全部资源的访问和变动都是经过Kubernetes API Server来实现的，所以须要建议采用更安全的HTTPS或Token来识别和认证客户端身份（Authentication），以及随后访问权限的受权（Authorization）环节。
• API Server的受权管理：经过受权策略来决定一个API调用是否合法。对合法用户进行受权而且随后在用户访问时进行鉴权，建议采用更安全的RBAC方式来提高集群安全受权。
• 敏感数据引入Secret机制：对于集群敏感数据建议使用Secret方式进行保护。
• AdmissionControl（准入机制）：对kubernetes api的请求过程当中，顺序为：先通过认证 & 受权，而后执行准入操做，最后对目标对象进行操做。

简述Kubernetes准入机制？

在对集群进行请求时，每一个准入控制代码都按照必定顺序执行。若是有一个准入控制拒绝了这次请求，那么整个请求的结果将会当即返回，并提示用户相应的error信息。

准入控制（AdmissionControl）准入控制本质上为一段准入代码，在对kubernetes api的请求过程当中，顺序为：先通过认证 & 受权，而后执行准入操做，最后对目标对象进行操做。经常使用组件（控制代码）以下：

• AlwaysAdmit：容许全部请求
• AlwaysDeny：禁止全部请求，多用于测试环境。
• ServiceAccount：它将serviceAccounts实现了自动化，它会辅助serviceAccount作一些事情，好比若是pod没有serviceAccount属性，它会自动添加一个default，并确保pod的serviceAccount始终存在。
• LimitRanger：观察全部的请求，确保没有违反已经定义好的约束条件，这些条件定义在namespace中LimitRange对象中。
• NamespaceExists：观察全部的请求，若是请求尝试建立一个不存在的namespace，则这个请求被拒绝。

简述Kubernetes RBAC及其特色（优点）？

RBAC是基于角色的访问控制，是一种基于我的用户的角色来管理对计算机或网络资源的访问的方法。

相对于其余受权模式，RBAC具备以下优点：

• 对集群中的资源和非资源权限均有完整的覆盖。
• 整个RBAC彻底由几个API对象完成， 同其余API对象同样， 能够用kubectl或API进行操做。
• 能够在运行时进行调整，无须从新启动API Server。

简述Kubernetes Secret做用？

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

简述Kubernetes Secret有哪些使用方式？

建立完secret以后，可经过以下三种方式使用：

• 在建立Pod时，经过为Pod指定Service Account来自动使用该Secret。
• 经过挂载该Secret到Pod来使用它。
• 在Docker镜像下载时使用，经过指定Pod的spc.ImagePullSecrets来引用它。

简述Kubernetes PodSecurityPolicy机制？

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

简述Kubernetes PodSecurityPolicy机制能实现哪些安全策略？

在PodSecurityPolicy对象中能够设置不一样字段来控制Pod运行时的各类安全策略，常见的有：

• 特权模式：privileged是否容许Pod以特权模式运行。
• 宿主机资源：控制Pod对宿主机资源的控制，如hostPID：是否容许Pod共享宿主机的进程空间。
• 用户和组：设置运行容器的用户ID（范围）或组（范围）。
• 提高权限：AllowPrivilegeEscalation：设置容器内的子进程是否能够提高权限，一般在设置非root用户（MustRunAsNonRoot）时进行设置。
• SELinux：进行SELinux的相关配置。

简述Kubernetes网络模型？

Kubernetes网络模型中每一个Pod都拥有一个独立的IP地址，并假定全部Pod都在一个能够直接连通的、扁平的网络空间中。因此无论它们是否运行在同一个Node（宿主机）中，都要求它们能够直接经过对方的IP进行访问。设计这个原则的缘由是，用户不须要额外考虑如何创建Pod之间的链接，也不须要考虑如何将容器端口映射到主机端口等问题。

同时为每一个Pod都设置一个IP地址的模型使得同一个Pod内的不一样容器会共享同一个网络命名空间，也就是同一个Linux网络协议栈。这就意味着同一个Pod内的容器能够经过localhost来链接对方的端口。

在Kubernetes的集群里，IP是以Pod为单位进行分配的。一个Pod内部的全部容器共享一个网络堆栈（至关于一个网络命名空间，它们的IP地址、网络设备、配置等都是共享的）。

简述Kubernetes CNI模型？

CNI提供了一种应用容器的插件化网络解决方案，定义对容器网络进行操做和配置的规范，经过插件的形式对CNI接口进行实现。CNI仅关注在建立容器时分配网络资源，和在销毁容器时删除网络资源。在CNI模型中只涉及两个概念：容器和网络。

容器（Container）：是拥有独立Linux网络命名空间的环境，例如使用Docker或rkt建立的容器。容器须要拥有本身的Linux网络命名空间，这是加入网络的必要条件。

网络（Network）：表示能够互连的一组实体，这些实体拥有各自独立、惟一的IP地址，能够是容器、物理机或者其余网络设备（好比路由器）等。

对容器网络的设置和操做都经过插件（Plugin）进行具体实现，CNI插件包括两种类型：CNI Plugin和IPAM（IP Address  Management）Plugin。CNI Plugin负责为容器配置网络资源，IPAM Plugin负责对容器的IP地址进行分配和管理。IPAM Plugin做为CNI Plugin的一部分，与CNI Plugin协同工做。

简述Kubernetes网络策略？

为实现细粒度的容器间网络访问隔离策略，Kubernetes引入Network Policy。

Network Policy的主要功能是对Pod间的网络通讯进行限制和准入控制，设置容许访问或禁止访问的客户端Pod列表。Network Policy定义网络策略，配合策略控制器（Policy Controller）进行策略的实现。

简述Kubernetes网络策略原理？

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

简述Kubernetes中flannel的做用？

Flannel能够用于Kubernetes底层网络的实现，主要做用有：

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

简述Kubernetes Calico网络组件实现原理？

Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都可以良好地集成。

Calico在每一个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每一个vRouter都经过BGP协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其余节点的路由转发规则。

Calico保证全部容器之间的数据流量都是经过IP路由的方式完成互联互通的。Calico节点组网时能够直接利用数据中心的网络结构（L2或者L3），不须要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，可以节约CPU运算，提升网络效率。

简述Kubernetes共享存储的做用？

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

简述Kubernetes数据持久化的方式有哪些？

Kubernetes 经过数据持久化来持久化保存重要数据，常见的方式有：

EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由Pod内保部映射到宿主机上。相似于docker中的manager volume。

• 场景：
• 只须要临时将数据保存在磁盘上，好比在合并/排序算法中；
• 做为两个容器的共享存储。
• 特性：
• 同个pod里面的不一样容器，共享同一个持久化目录，当pod节点删除时，volume的数据也会被删除。
• emptyDir的数据持久化的生命周期和使用的pod一致，通常是做为临时存储使用。

Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。相似于docker中的bind mount挂载方式。

• 特性：增长了pod与节点之间的耦合。

PersistentVolume（简称PV）：如基于NFS服务的PV，也能够基于GFS的PV。它的做用是统一数据持久化目录，方便管理。

简述Kubernetes PV和PVC？

PV是对底层网络共享存储的抽象，将共享存储定义为一种“资源”。

PVC则是用户对存储资源的一个“申请”。

简述Kubernetes PV生命周期内的阶段？

某个PV在生命周期中可能处于如下4个阶段（Phaes）之一。

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

简述Kubernetes所支持的存储供应模式？

Kubernetes支持两种资源的存储供应模式：静态模式（Static）和动态模式（Dynamic）。

静态模式：集群管理员手工建立许多PV，在定义PV时须要将后端存储的特性进行设置。

动态模式：集群管理员无须手工建立PV，而是经过StorageClass的设置对后端存储进行描述，标记为某种类型。此时要求PVC对存储的类型进行声明，系统将自动完成PV的建立及与PVC的绑定。

简述Kubernetes CSI模型？

Kubernetes CSI是Kubernetes推出与容器对接的存储接口标准，存储提供方只须要基于标准接口进行存储插件的实现，就能使用Kubernetes的原生存储机制为容器提供存储服务。CSI使得存储提供方的代码能和Kubernetes代码完全解耦，部署也与Kubernetes核心组件分离，显然，存储插件的开发由提供方自行维护，就能为Kubernetes用户提供更多的存储功能，也更加安全可靠。

CSI包括CSI Controller和CSI Node：

• CSI Controller的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操做。
• CSI Node的主要功能是对主机（Node）上的Volume进行管理和操做。

简述Kubernetes Worker节点加入集群的过程？

一般须要对Worker节点进行扩容，从而将应用系统进行水平扩展。主要过程以下：

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

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

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

一般，一个程序所使用的CPU与Memory是一个动态的量，确切地说，是一个范围，跟它的负载密切相关：负载增长时，CPU和Memory的使用量也会增长。

简述Kubernetes Requests和Limits如何影响Pod的调度？

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

简述Kubernetes Metric Service？

在Kubernetes从1.10版本后采用Metrics Server做为默认的性能数据采集和监控，主要用于提供核心指标（Core Metrics），包括Node、Pod的CPU和内存使用指标。

对其余自定义指标（Custom Metrics）的监控则由Prometheus等组件来完成。

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

在Kubernetes集群环境中，一般一个完整的应用或服务涉及组件过多，建议对日志系统进行集中化管理，一般采用EFK实现。

EFK是 Elasticsearch、Fluentd 和 Kibana 的组合，其各组件功能以下：

• Elasticsearch：是一个搜索引擎，负责存储日志并提供查询接口；
• Fluentd：负责从 Kubernetes 搜集日志，每一个node节点上面的fluentd监控并收集该节点上面的系统日志，并将处理事后的日志信息发送给Elasticsearch；
• Kibana：提供了一个 Web GUI，用户能够浏览和搜索存储在 Elasticsearch 中的日志。

经过在每台node上部署一个以DaemonSet方式运行的fluentd来收集每台node上的日志。Fluentd将docker日志目录/var/lib/docker/containers和/var/log目录挂载到Pod中，而后Pod会在node节点的/var/log/pods目录中建立新的目录，能够区别不一样的容器日志输出，该目录下有一个日志文件连接到/var/lib/docker/contianers目录下的容器日志输出。

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

因为Kubernetes节点运行大量Pod，所以在进行关机维护以前，建议先使用kubectl drain将该节点的Pod进行驱逐，而后进行关机维护。

简述Kubernetes集群联邦？

Kubernetes集群联邦能够将多个Kubernetes集群做为一个集群进行管理。所以，能够在一个数据中心/云中建立多个Kubernetes集群，并使用集群联邦在一个地方控制/管理全部集群。

简述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 上查找、安装、升级、回滚、卸载应用程序。

来源： https://www.yuque.com/docs/sh...