简述ETCD及其特点？
etcd是CoreOS团队发起的开源项目，是一个管理配置信息和服务发现（servicediscovery）的项目，它的目标是构建一个高可用的分布式键值（key-value）数据库，基于Go语言实现。
特点：
简单：支持REST风格的HTTP+JSONAPI安全：支持HTTPS方式的访问快速：支持并发1k/s的写操作可靠：支持分布式结构，基于Raft的一致性算法，Raft是一套通过选举主节点来实现分布式系统一致性的算法。
简述ETCD适应的场景？
etcd基于其优秀的特点，可广泛的应用于以下场景：
服务发现(ServiceDiscovery)：服务发现主要解决在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听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：也是推荐的一种部署方式；二进制：minikube：在本地轻松运行一个单节点Kubernetes群集的工具。
简述Kubernetes如何实现集群管理？
在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。
简述Kubernetes的优势、适应场景及其特点？
Kubernetes作为一个完备的分布式系统支撑平台，其主要优势：
容器编排轻量级开源弹性伸缩负载均衡
Kubernetes常见场景：
快速部署应用快速扩展应用无缝对接新的应用功能节省资源，优化硬件资源的使用
Kubernetes相关特点：
可移植:支持公有云、私有云、混合云、多重云（multi-cloud）。可扩展:模块化,、插件化、可挂载、可组合。自动化:自动部署、自动重启、自动复制、自动伸缩/扩展。
简述Kubernetes的缺点或当前的不足之处？
Kubernetes当前存在的缺点（不足）如下：
安装过程和配置相对困难复杂。管理服务相对繁琐。运行和编译需要很多时间。它比其他替代品更昂贵。对于简单的应用程序来说，可能不需要涉及Kubernetes即可满足。
简述Kubernetes相关基础概念？
master：k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行ApiServer进程，ControllerManager服务进程及Scheduler服务进程。node（worker）：Node（worker）是Kubernetes集群架构中运行Pod的服务节点，是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。运行dockereninge服务，守护进程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通过LabelSelector（标签选择器）查询和筛选资源对象。ReplicationController：ReplicationController用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量不变。ReplicationController是实现弹性伸缩、动态扩容和滚动升级的核心。Deployment：Deployment在内部使用了RS来实现目的，Deployment相当于RC的一次升级，其最大的特色为可以随时获知当前Pod的部署进度。HPA（HorizontalPodAutoscaler）：Pod的横向自动扩容，也是Kubernetes的一种资源，通过追踪分析RC控制的所有Pod目标的负载变化情况，来确定是否需要针对性的调整Pod副本数量。Service：Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行。Volume：Volume是Pod中能够被多个容器访问的共享目录，Kubernetes中的Volume是定义在Pod上，可以被一个或多个Pod中的容器挂载到某个目录下。Namespace：Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的不同项目、小组或用户组，便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理。
简述Kubernetes集群相关组件？
KubernetesMaster控制组件，调度管理整个系统（集群），包含如下组件:
KubernetesAPIServer：作为Kubernetes系统的入口，其封装了核心对象的增删改查操作，以RESTfulAPI接口方式提供给外部客户和内部组件调用，集群内各个功能模块之间数据交互和通信的中心枢纽。KubernetesScheduler：为新建立的Pod进行节点(node)选择(即分配机器)，负责集群的资源调度。KubernetesController：负责执行各种控制器，目前已经提供了很多控制器来保证Kubernetes的正常运行。ReplicationController：管理维护ReplicationController，关联ReplicationController和Pod，保证ReplicationController定义的副本数量与实际运行Pod数量一致。NodeController：管理维护Node，定期检查Node的健康状态，标识出(失效
未失效)的Node节点。NamespaceController：管理维护Namespace，定期清理无效的Namespace，包括Namesapce下的API对象，比如Pod、Service等。ServiceController：管理维护Service，提供负载以及服务代理。EndPointsController：管理维护Endpoints，关联Service和Pod，创建Endpoints为Service的后端，当Pod发生变化时，实时更新Endpoints。ServiceAccountController：管理维护ServiceAccount，为每个Namespace创建默认的ServiceAccount，同时为ServiceAccount创建ServiceAccountSecret。PersistentVolumeController：管理维护PersistentVolume和PersistentVolumeClaim，为新的PersistentVolumeClaim分配PersistentVolume进行绑定，为释放的PersistentVolume执行清理回收。DaemonSetController：管理维护DaemonSet，负责创建DaemonPod，保证指定的Node上正常的运行DaemonPod。DeploymentController：管理维护Deployment，关联Deployment和ReplicationController，保证运行指定数量的Pod。当Deployment更新时，控制实现ReplicationController和Pod的更新。JobController：管理维护Job，为Jod创建一次性任务Pod，保证完成Job指定完成的任务数目PodAutoscalerController：实现Pod的自动伸缩，定时获取监控数据，进行策略匹配，当满足条件时执行Pod的伸缩动作。
简述KubernetesRC的机制？
ReplicationController用来管理Pod的副本，保证集群中存在指定数量的Pod副本。当定义了RC并提交至Kubernetes集群中之后，Master节点上的ControllerManager组件获悉，并同时巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，若存在过多的Pod副本在运行，系统会停止一些Pod，反之则自动创建一些Pod。
简述KubernetesReplicaSet和ReplicationController之间有什么区别？
ReplicaSet和ReplicationController类似，都是确保在任何给定时间运行指定数量的Pod副本。不同之处在于RS使用基于集合的选择器，而ReplicationController使用基于权限的选择器。
简述kube-proxy作用？
kube-proxy运行在所有节点上，它监听apiserver中service和endpoint的变化情况，创建路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
简述kube-proxyiptables原理？
Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过APIServer的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。
简述kube-proxyipvs原理？
IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式。
在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配。
可以将ipset简单理解为一个IP（段）的集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少iptables规则的数量，从而减少性能损耗。
简述kube-proxyipvs和iptables的异同？
iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。
与iptables相比，IPVS拥有以下明显优势：
1、为大型集群提供了更好的可扩展性和性能；2、支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；3、支持服务器健康检查和连接重试等功能；4、可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。
简述Kubernetes中什么是静态Pod？
静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过APIServer进行管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对他们进行健康检查。静态Pod总是由kubelet进行创建，并且总是在kubelet所在的Node上运行。
简述Kubernetes中Pod可能位于的状态？
Pending：APIServer已经创建该Pod，且Pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程。Running：Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。Succeeded：Pod内所有容器均成功执行退出，且不会重启。Failed：Pod内所有容器均已退出，但至少有一个容器退出为失败状态。Unknown：由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致。
简述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数据中心。
简述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的状态将被修改。EndpointController将从Service的Endpoint中删除包含该容器所在Pod的Eenpoint。startupProbe探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉。
简述KubernetesPod的LivenessProbe探针的常见方式？
kubelet定期执行LivenessProbe探针来诊断容器的健康状态，通常有以下三种方式：
ExecAction：在容器内执行一个命令，若返回码为0，则表明容器健康。TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，若能建立TCP连接，则表明容器健康。HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTPGet方法，若响应的状态码大于等于且小于，则表明容器健康。
简述KubernetesPod的常见调度方式？
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初始化容器（initcontainer）？
initcontainer的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个initcontainer时，将按顺序逐个运行，并且只有前一个initcontainer运行成功后才能运行后一个initcontainer。当所有initcontainer都成功运行后，Kubernetes才会初始化Pod的各种信息，并开始创建和运行应用容器。
简述Kubernetesdeployment升级过程？
初始创建Deployment时，系统创建了一个ReplicaSet，并按用户的需求创建了对应数量的Pod副本。当更新Deployment时，系统创建了一个新的ReplicaSet，并将其副本数量扩展到1，然后将旧ReplicaSet缩减为2。之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。最后，新的ReplicaSet运行了对应个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0。
简述Kubernetesdeployment升级策略？
在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）来控制滚动更新的过程。
简述KubernetesDaemonSet类型的资源特性？
DaemonSet资源对象会在每个Kubernetes集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。因此，在定义yaml文件中，不支持定义replicas。
它的一般使用场景如下：
在去做每个节点的日志收集工作。监控每个节点的的运行状态。
简述Kubernetes自动扩容机制？
Kubernetes使用HorizontalPodAutoscaler（HPA）的控制器实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器周期性地监测目标Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对比，在满足条件时对Pod副本数量进行调整。
HPA原理
Kubernetes中的某个MetricsServer（Heapster或自定义MetricsServer）持续采集所有Pod副本的指标数据。HPA控制器通过MetricsServer的API（Heapster的API或聚合API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标Pod副本数量。
当目标Pod副本数量与当前副本数量不同时，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）发起scale操作，调整Pod的副本数量，完成扩缩容操作。
简述KubernetesService类型？
通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。其主要类型有：
ClusterIP：虚拟的服务IP地址，该地址用于Kubernetes集群内部的Pod访问，在Node上kube-proxy通过设置的iptables规则进行转发；NodePort：使用宿主机的端口，使能够访问各Node的外部客户端通过Node的IP地址和端口号就能访问服务；LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址，通常用于公有云。
简述KubernetesService分发后端的策略？
Service负载分发的策略有：RoundRobin和SessionAffinity
RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个Pod上。SessionAffinity：基于客户端IP地址进行会话保持的模式，即第1次将某个客户端发起的请求转发到后端的某个Pod上，之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。
简述KubernetesHeadlessService？
在某些应用场景中，若需要人为指定负载均衡器，不使用Service提供的默认负载均衡的功能，或者应用程序希望知道属于同组服务的其他实例。Kubernetes提供了HeadlessService来实现这种功能，即不为Service设置ClusterIP（入口IP地址），仅通过LabelSelector将后端的Pod列表返回给调用的客户端。
简述Kubernetes外部如何访问集群内的服务？
对于Kubernetes，集群外的客户端默认情况，无法通过Pod的IP地址或者Service的虚拟IP