简述Kubernetes和Docker的关系？

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

简述Kubernetes常见的部署方式？

• kubeadm：也是推荐的一种部署方式；
• 二进制；
• minikube：在本地轻松运行一个单节点 Kubernetes 群集的工具；

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

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

简述Kubernetes集群相关组件？

组件	功能
API Server	作为Kubernetes系统的入口，其封装了核心对象的增删改查操作，以RESTful API接口方式提供给外部客户和内部组件调用，集群内各个功能模块之间数据交互和通信的中心枢纽。
Scheduler	为新建立的Pod进行节点(node)选择(即分配机器)，负责集群的资源调度。
Controller	负责执行各种控制器，目前已经提供了很多控制器来保证Kubernetes的正常运行。
Replication Controller	管理维护Replication Controller，关联Replication Controller和Pod，保证Replication Controller定义的副本数量与实际运行Pod数量一致。
Node Controller	管理维护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实例上。

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