简述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领有以下显著劣势：

  • 1、为大型集群提供了更好的可扩展性和性能；
  • 2、反对比iptables更简单的复制平衡算法（最小负载、起码连贯、加权等）；
  • 3、反对服务器健康检查和连贯重试等性能；
  • 4、能够动静批改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波及多个组件之间联动，次要流程如下：

  • 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的状态将被批改。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节点进行扩容，从而将利用零碎进行程度扩大。次要过程如下：

  • 1、在该Node上装置Docker、kubelet和kube-proxy服务；
  • 2、而后配置kubelet和kubeproxy的启动参数，将Master URL指定为以后Kubernetes集群Master的地址，最初启动这些服务；
  • 3、通过kubelet默认的主动注册机制，新的Worker将会主动退出现有的Kubernetes集群中；
  • 4、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...