Linux运维工程师笔试题第二十套

试题正文

1. 请解释Deployment、ReplicaSets、StatefulSets、Pod、Job、CronJob的不同用途
   Deployment的应用场景： 无状态的、轻量级应用
   StatefulSets的应用场景： 有状态的应用，每个节点有固定的的身份ID、Pod的启动有先后顺序、存储使用持久化存储卷（PV/PVC）；
   Deployment和Statefulset之间很显著的区别是deployment的pod名每次重启之后会变，而stateful不会变，另外statefuset的启动是有顺序的。
   Job的应用场景： 负责处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束；
   CronJob的应用场景: 在给定的时间点运行一个任务，也可以周期性地在给定时间点运行；

2. Kubernetes 如何处理持久性？
   根据独立的存储系统如NFS、iSCSI、cephfs、glusterfs等，创建动态/静态PV，然后对应绑定PVC，然后在POD里使用PVC即可。

3. 什么是sidecar容器？你能给出一个用例，说明你为什么要使用它么？
   将应用程序的功能划分为单独的进程可以被视为 Sidecar 容器。Sidecar的设计模式允许你为应用程序添加许多功能，而无需额外第三方组件的配置和代码。
   实际的应用场景是比如一些服务，还要搭配监控、日志、集中化配置和网络服务这样的附属服务的时候，就可以考虑用sidecar模式。

4. kubernetes包含几个组件。 各个组件的功能是什么。组件之间是如何交互的。
   k8s大致分为3个部分：Master节点、Node节点、应用。

Master节点提供集群的控制面板，其下组件有：

kube-apiserver 提供k8s的API调用服务。
etcd 数据中心，存储集群的所有数据。
kube-scheduler 调度器，负责给新创建的容器分配节点等。
kube-controller-manager 控制管理器，负责监控和维护集群状态。
cloud-controller-manager 是提供给第三方开发k8s特性的。

其中controller又包含：

Node Controller 报告节点健康状态。
Replication Controller 维护rc的pod个数，pod挂掉又控制重启。
Endpoints Controller 填充Endpoint对象，主要是给Service和Pod。
Service Account & Token Controllers 创建帐号和Token。

Node节点组件：

kubelet 管理Pod里面的容器。
kube-proxy 管理网络路由规则。
container runtime 容器运行环境，如Docker等。

应用都是部署在kube-system这个命名空间下的。如：

DNS dns服务。
Dashboard web管理界面。
Container Resource Monitoring 容器资源管理和监控，如cAdvisor、Prometheus。
Cluster-level Logging 日志收集分节点、集群、应用三种类型，可用elk或fluentd等。

5. k8s中的pod内几个容器之间的关系是什么。
   一个Pod是一组容器的集合，像豌豆荚于豌豆。提供容器间存储和网络的共享，和一系列运行规范。Pod里面的容器共享网络，因此可使用localhost通讯。由于也共享存储，所以可以使用IPC和共享内存进行通讯。

6. 如何在 Kubernetes 中实现负载均衡？
   通过创建service来实现负载均衡，Service Cluster IP 是一个虚拟 IP，它与pod IP的映射关系是通过iptables，而且用的是使用类似轮询的负载均衡策略（iptables规则里有–probability 0.33332999982这样的标记）。

7. Deployment、Rc、Rs有什么区别。 其使用方式使用条件和原理是什么。
   Replication Controller是最早的部署、升级Pod的管理工具，他能保证pod的健康个数。
   Replication Set包含RC的所有功能，它比RC强的地方就是RC只支持等式的seletor，而RS的用法更丰富。
   Deployment比RS还高级，而且支持历史回溯、回滚、查看事件状态、暂停启动升级等功能，而且它支持两种升级方案：Recreate（全毁重建）、RollingUpdate（默认，逐步替换）

8. Cgroup中的cpu有哪几种限制方式。
   Cgroup限制CPU的方式有三种：cpuset、cpuquota、cpushares，具体如下：

   cpuset隔离方式是以分配核心的方式进行资源隔离，可以提供的资源分配最小粒度是核心，不能提供更细粒度的资源隔离，但是隔离之后运算的相互影响最低。需要注意的是在服务器开启了超线程的情况下，要小心选择分配的核心，否则不同cgroup间的性能差距会比较大。
   cpuquota给我们提供了一种比cpuset可以更细粒度的分配资源的方式，并且保证了cgroup使用cpu比率的上限，相当于对cpu资源的硬限制。
   cpushares给我们提供了一种可以按权重比率弹性分配cpu时间资源的手段：当cpu空闲的时候，某一个要占用cpu的cgroup可以完全占用剩余cpu时间，充分利用资源。而当其他cgroup需要占用的时候，每个cgroup都能保证其最低占用时间比率，达到资源隔离的效果。

注意！Linux cgroup和Docker都将CPU核心数分成了1024个时间片（shares），而Kubernetes将它分成了1000个shares。所以有时候用docker inspect和kubectl查看有小小的误差。

9. k8s是如何使用实现request和limit的？
   CPU 资源限制和内存资源限制一样都是由cgroup控制

10. kubectl run这个命令敲下去会有什么过程？
    首先kubectl会先进行客户端验证的操作，kubectl run会自己判断创建的资源类型，比如当-–replicas=1的时候--restart=Never，那么生成的就是pod。如果有指定参数--generator，可以来部署其他多种资源类型。

然后通过apiVersion字段生成REST路径并且真正地发送HTTP请求。一旦请求发送到kube-apiserver之后获得成功的响应，kube-apiserver将对HTTP请求进行反序列化，然后利用得到的结果构建运行时对象的信息（有点像kubectl生成器的逆过程），并保存到etcd中。

此时Scheduler开始调度，第一轮算法是淘汰掉不满足pod需求的节点，第二轮算法是在符合要求的候选节点上进行优选，将结果打分。一旦找到了合适的节点，Scheduler就会创建一个Binding对象，该对象的Name和Uid与Pod相匹配，然后通过POST请求发送给apiserver。apiserver会把该资源与对应的node记录到etcd里。

Kubelet服务进程会根据度结果先创建pause容器，然后再进行业务Pod的创建。

参考资料

https://juejin.im/post/5d28508ff265da1b7638ceeb （kubectl 创建 Pod 背后到底发生了什么？）