K8S DOCKER面试 k8s和docker面试题

文章目录

• 
  

• 2、简述etcd适应的场景
• 3、简述什么是Kubernetes
• 4、简述Kubernetes和Docker的关系
• 5、简述Minikube、Kubectl、Kubelet分别是什么
• 6、简述Kubernetes常见的部署方式
• 7、简述Kubernetes如何实现集群管理
• 8、简述Kubernetes的优势、适应场景及其特点
• 10、简述Kubernetes相关基础概念
• 11、简述Kubernetes集群相关组件
• 12、简述Kubernetes RC的机制
• 13、简述Kubernetes Replica Set和Replication Controller之间有什么区别
• 14、简述kube-proxy的作用
• 15、简述kube-proxy iptables的原理
• 16、简述kube-proxy ipvs的原理
• 17、简述kube-proxy ipvs和iptables的异同
• 18、简述Kubernetes中什么是静态Pod
• 19、简述Kubernetes中Pod可能位于的状态
• 20、简述Kubernetes创建一个Pod的主要流程？
• 21、简述Kubernetes中Pod的重启策略
• 22、简述Kubernetes中Pod的健康检查方式
• 23、简述Kubernetes Pod的LivenessProbe探针的常见方式
• 24、简述Kubernetes Pod的常见调度方式
• 25、简述Kubernetes初始化容器（init container）
• 26、简述Kubernetes deployment升级过程
• 27、简述Kubernetes deployment升级策略
• 28、简述Kubernetes DaemonSet类型的资源特性
• 29、简述Kubernetes自动扩容机制
• 30、简述Kubernetes Service类型
• 31、简述Kubernetes Service分发后端的策略
• 32、简述Kubernetes Headless Service
• 33、简述Kubernetes外部如何访问集群内的服务
• 34、简述Kubernetes ingress
• 35、简述Kubernetes镜像的下载策略
• 36、简述Kubernetes的负载均衡器
• 37、简述Kubernetes各模块如何与API Server通信
• 38、简述Kubernetes Scheduler作用及实现原理
• 39、简述Kubernetes Scheduler使用哪两种算法将Pod绑定到worker节点
• 40、简述Kubernetes kubelet的作用
• 41、简述Kubernetes kubelet监控Worker节点资源是使用什么组件来实现的
• 42、简述Kubernetes如何保证集群的安全性
• 43、简述Kubernetes准入机制
• 44、简述Kubernetes RBAC及其特点（优势）
• 45、简述Kubernetes Secret作用
• 46、简述Kubernetes Secret有哪些使用方式
• 47、简述Kubernetes PodSecurityPolicy机制
• 48、简述Kubernetes PodSecurityPolicy机制能实现哪些安全策略
• 49、简述Kubernetes网络模型
• 50、简述Kubernetes CNI模型
• 51、简述Kubernetes网络策略
• 52、简述Kubernetes网络策略原理
• 53、简述Kubernetes中flannel的作用
• 54、简述Kubernetes Calico网络组件实现原理
• 55、简述Kubernetes共享存储的作用
• 56、简述Kubernetes数据持久化的方式有哪些
• 57、简述Kubernetes PV和PVC
• 58、简述Kubernetes PV生命周期内的阶段
• 59、简述Kubernetes所支持的存储供应模式
• 60、简述Kubernetes CSI模型
• 61、简述Kubernetes Worker节点加入集群的过程
• 62、简述Kubernetes Pod如何实现对节点的资源控制
• 63、简述Kubernetes Requests和Limits如何影响Pod的调度
• 64、简述Kubernetes Metric Service
• 65、简述Kubernetes中，如何使用EFK实现日志的统一管理
• 66、简述Kubernetes如何进行优雅的节点关机维护
• 67、简述Kubernetes集群联邦
• 68、简述Helm及其优势
• 69、k8s是什么？请说出你的了解？
• 70、K8s架构的组成是什么？

• K8S架构细分：

• 71、容器和主机部署应用的区别是什么？
• 72、请你说一下kubenetes针对pod资源对象的健康监测机制？
• 73、如何控制滚动更新过程？
• 74、K8s中镜像的下载策略是什么？
• 75、image的状态有哪些？
• 76、pod的重启策略是什么？
• 77、Service这种资源对象的作用是什么？
• 78、版本回滚相关的命令？
• 79、标签与标签选择器的作用是什么？
• 80、常用的标签分类有哪些？
• 81、有几种查看标签的方式？
• 82、添加、修改、删除标签的命令？
• 83、DaemonSet资源对象的特性？
• 84、说说你对Job这种资源对象的了解？
• 85、描述一下pod的生命周期有哪些状态？
• 86、创建一个pod的流程是什么？
• 87、删除一个Pod会发生什么事情？
• 88、K8s的Service是什么？
• 89、k8s是怎么进行服务注册的？
• 90、k8s集群外流量怎么访问Pod？
• 91、k8s数据持久化的方式有哪些？

• 1）EmptyDir（空目录）：
• 2）Hostpath：
• 3）PersistentVolume（简称PV）：

• StatefulSet
• Deployment

• 一、pandas是什么？
• 二、使用步骤

• 1.引入库
• 2.读入数据

• 总结

1、简述etcd及其特点

etcd是高可用的键值对数据库

具有高效，快速，安全的特点

2、简述etcd适应的场景

etcd服务发现，负载均衡，cun

3、简述什么是Kubernetes

kubernetes是谷歌的开源项目，是编排管理容器的系统。

4、简述Kubernetes和Docker的关系

docker负载容器的生命周期的管理，和运行镜像创建容器。k8s负载编排管理容器

5、简述Minikube、Kubectl、Kubelet分别是什么

minikube单机版按照方式

kubectl 命令行安装方式

kubelet 服务代理

6、简述Kubernetes常见的部署方式

二进制，kubeadm,minikube

7、简述Kubernetes如何实现集群管理

k8s分为一个主控节点，和几个工作节点,主控节点有apiserver,scheduler,controlermanager,apiserver就是集群的入口，scheduler负责调度，contrloller-manager负责管理控制资源，每个工作节点又有kubelet,kubelet负责管理控制pod,kube-proxy负责服务发现，负载均

8、简述Kubernetes的优势、适应场景及其特点

优势在于

便于容器的编排管理，服务发现

适应场景：集群应用，大规模服务

特点：便捷，高效

10、简述Kubernetes相关基础概念

11、简述Kubernetes集群相关组件

12、简述Kubernetes RC的机制

13、简述Kubernetes Replica Set和Replication Controller之间有什么区别

14、简述kube-proxy的作用

15、简述kube-proxy iptables的原理

16、简述kube-proxy ipvs的原理

17、简述kube-proxy ipvs和iptables的异同

18、简述Kubernetes中什么是静态Pod

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

20、简述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数据中心。

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

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

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

kubelet定期执行LivenessProbe探针来诊断容器的健康状态，通常有以下三种方式：

• ExecAction：在容器内执行一个命令，若返回码为0，则表明容器健康。
• TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，若能建立TCP连接，则表明容器健康。
• HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，若响应的状态码大于等于200且小于400，则表明容器健康。

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

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

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

26、简述Kubernetes deployment升级过程

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

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

28、简述Kubernetes DaemonSet类型的资源特性

DaemonSet资源对象会在每个Kubernetes集群中的节点上运行，并且每个节点只能运行一个Pod，这是它和Deployment资源对象的最大也是唯一的区别。因此，在定义yaml文件中，不支持定义replicas。

它的一般使用场景如下：

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

29、简述Kubernetes自动扩容机制

Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器周期性地监测目标Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对比，在满足条件时对Pod副本数量进行调整。

Kubernetes中的某个Metrics Server（Heapster或自定义Metrics Server）持续采集所有Pod副本的指标数据。HPA控制器通过Metrics Server的API（Heapster的API或聚合API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标Pod副本数量。

当目标Pod副本数量与当前副本数量不同时，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）发起scale操作，调整Pod的副本数量，完成扩缩容操作。

30、简述Kubernetes Service类型

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

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

31、简述Kubernetes Service分发后端的策略

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

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

32、简述Kubernetes Headless Service

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

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

对于Kubernetes，集群外的客户端默认情况，无法通过Pod的IP地址或者Service的虚拟IP地址：虚拟端口号进行访问。通常可以通过以下方式进行访问Kubernetes集群内的服务：

• 映射Pod到物理机：将Pod端口号映射到宿主机，即在Pod中采用hostPort方式，以使客户端应用能够通过物理机访问容器应用。
• 映射Service到物理机：将Service端口号映射到宿主机，即在Service中采用nodePort方式，以使客户端应用能够通过物理机访问容器应用。
• 映射Sercie到LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景。

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

35、简述Kubernetes镜像的下载策略

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

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

36、简述Kubernetes的负载均衡器

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

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

37、简述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绑定到目标节点上。

38、简述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镜像并启动容器。

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

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

• 预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node的label必须与Pod的Selector一致”。
• 优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过预选的Nodes进行打分排名，选择得分最高的Node。例如，资源越富裕、负载越小的Node可能具有越高的排名。

40、简述Kubernetes kubelet的作用

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

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

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

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

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

• 基础设施方面：保证容器与其所在宿主机的隔离；
• 权限方面：

• 最小权限原则：合理限制所有组件的权限，确保组件只执行它被授权的行为，通过限制单个组件的能力来限制它的权限范围。
• 用户权限：划分普通用户和管理员的角色。

• 集群方面：

• API Server的认证授权：Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server来实现的，因此需要建议采用更安全的HTTPS或Token来识别和认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）环节。
• API Server的授权管理：通过授权策略来决定一个API调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权，建议采用更安全的RBAC方式来提升集群安全授权。

• 敏感数据引入Secret机制：对于集群敏感数据建议使用Secret方式进行保护。
• AdmissionControl（准入机制）：对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。

43、简述Kubernetes准入机制

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

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

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

44、简述Kubernetes RBAC及其特点（优势）

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

相对于其他授权模式，RBAC具有如下优势：

• 对集群中的资源和非资源权限均有完整的覆盖。
• 整个RBAC完全由几个API对象完成， 同其他API对象一样， 可以用kubectl或API进行操作。
• 可以在运行时进行调整，无须重新启动API Server。

45、简述Kubernetes Secret作用

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

46、简述Kubernetes Secret有哪些使用方式

创建完secret之后，可通过如下三种方式使用：

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

47、简述Kubernetes PodSecurityPolicy机制

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

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

在PodSecurityPolicy对象中可以设置不同字段来控制Pod运行时的各种安全策略，常见的有：

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

49、简述Kubernetes网络模型

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

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

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

50、简述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协同工作。

51、简述Kubernetes网络策略

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

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

52、简述Kubernetes网络策略原理

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

53、简述Kubernetes中flannel的作用

Flannel可以用于Kubernetes底层网络的实现，主要作用有：

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

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

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

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

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

55、简述Kubernetes共享存储的作用

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

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

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

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

• 只需要临时将数据保存在磁盘上，比如在合并/排序算法中；
• 作为两个容器的共享存储。

• 特性：

• 同个pod里面的不同容器，共享同一个持久化目录，当pod节点删除时，volume的数据也会被删除。
• emptyDir的数据持久化的生命周期和使用的pod一致，一般是作为临时存储使用。

• Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式。
• 特性：增加了Pod与节点之间的耦合。

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

57、简述Kubernetes PV和PVC

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

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

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

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

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

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

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

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

60、简述Kubernetes CSI模型

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

CSI包括CSI Controller和CSI Node：

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

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

通常需要对Worker节点进行扩容，从而将应用系统进行水平扩展。主要过程如下：

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

62、简述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的使用量也会增加。

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

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

64、简述Kubernetes Metric Service

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

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

65、简述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目录下的容器日志输出。

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

由于Kubernetes节点运行大量Pod，因此在进行关机维护之前，建议先使用kubectl drain将该节点的Pod进行驱逐，然后进行关机维护。

67、简述Kubernetes集群联邦

Kubernetes集群联邦可以将多个Kubernetes集群作为一个集群进行管理。因此，可以在一个数据中心/云中创建多个Kubernetes集群，并使用集群联邦在一个地方控制/管理所有集群。

68、简述Helm及其优势

Helm是Kubernetes的软件包管理工具。类似Ubuntu中使用的APT、CentOS中使用的yum 或者Python中的 pip 一样。

Helm能够将一组Kubernetes资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。

Helm中通常每个包称为一个Chart，一个Chart是一个目录（一般情况下会将目录进行打包压缩，形成name-version.tgz格式的单一文件，方便传输和存储）。

在Kubernetes中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。使用Helm则具有如下优势：

• 统一管理、配置和更新这些分散的Kubernetes的应用资源文件；
• 分发和复用一套应用模板；
• 将应用的一系列资源当做一个软件包管理。
• 对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。

对于使用者而言，使用Helm后不用需要编写复杂的应用部署文件，可以以简单的方式在Kubernetes上查找、安装、升级、回滚、卸载应用程序。

69、k8s是什么？请说出你的了解？

答：Kubenetes是一个针对容器应用，进行自动部署，弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。

K8S是Google公司推出的，它来源于由Google公司内部使用了15年的Borg系统，集结了Borg的精华。

70、K8s架构的组成是什么？

答：和大多数分布式系统一样，K8S集群至少需要一个主节点（Master）和多个计算节点（Node）。

• 主节点主要用于暴露API，调度部署和节点的管理；
• 计算节点运行一个容器运行环境，一般是docker环境（类似docker环境的还有rkt），同时运行一个K8s的代理（kubelet）用于和master通信。计算节点也会运行一些额外的组件，像记录日志，节点监控，服务发现等等。计算节点是k8s集群中真正工作的节点。

K8S架构细分：

1、Master节点（默认不参加实际工作）：

• Kubectl：客户端命令行工具，作为整个K8s集群的操作入口；
• Api Server：在K8s架构中承担的是“桥梁”的角色，作为资源操作的唯一入口，它提供了认证、授权、访问控制、API注册和发现等机制。客户端与k8s群集及K8s内部组件的通信，都要通过Api Server这个组件；
• Controller-manager：负责维护群集的状态，比如故障检测、自动扩展、滚动更新等；
• Scheduler：负责资源的调度，按照预定的调度策略将pod调度到相应的node节点上；
• Etcd：担任数据中心的角色，保存了整个群集的状态；

2、Node节点：

• Kubelet：负责维护容器的生命周期，同时也负责Volume和网络的管理，一般运行在所有的节点，是Node节点的代理，当Scheduler确定某个node上运行pod之后，会将pod的具体信息（image，volume）等发送给该节点的kubelet，kubelet根据这些信息创建和运行容器，并向master返回运行状态。（自动修复功能：如果某个节点中的容器宕机，它会尝试重启该容器，若重启无效，则会将该pod杀死，然后重新创建一个容器）；
• Kube-proxy：Service在逻辑上代表了后端的多个pod。负责为Service提供cluster内部的服务发现和负载均衡（外界通过Service访问pod提供的服务时，Service接收到的请求后就是通过kube-proxy来转发到pod上的）；
• container-runtime：是负责管理运行容器的软件，比如docker
• Pod：是k8s集群里面最小的单位。每个pod里边可以运行一个或多个container（容器），如果一个pod中有两个container，那么container的USR（用户）、MNT（挂载点）、PID（进程号）是相互隔离的，UTS（主机名和域名）、IPC（消息队列）、NET（网络栈）是相互共享的。我比较喜欢把pod来当做豌豆夹，而豌豆就是pod中的container；

71、容器和主机部署应用的区别是什么？

答：容器的中心思想就是秒级启动；一次封装、到处运行；这是主机部署应用无法达到的效果，但同时也更应该注重容器的数据持久化问题。

另外，容器部署可以将各个服务进行隔离，互不影响，这也是容器的另一个核心概念。

72、请你说一下kubenetes针对pod资源对象的健康监测机制？

答：K8s中对于pod资源对象的健康状态检测，提供了三类probe（探针）来执行对pod的健康监测：

1） livenessProbe探针

可以根据用户自定义规则来判定pod是否健康，如果livenessProbe探针探测到容器不健康，则kubelet会根据其重启策略来决定是否重启，如果一个容器不包含livenessProbe探针，则kubelet会认为容器的livenessProbe探针的返回值永远成功。

2） ReadinessProbe探针

同样是可以根据用户自定义规则来判断pod是否健康，如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功。

3） startupProbe探针

启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可。

每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：

• initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败
• periodSeconds：检查间隔，多久执行probe检查，默认为10s；
• timeoutSeconds：检查超时时长，探测应用timeout后为失败；
• successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。

上面两种探针都支持以下三种探测方法：

1）Exec：通过执行命令的方式来检查服务是否正常，比如使用cat命令查看pod中的某个重要配置文件是否存在，若存在，则表示pod健康。反之异常。

Exec探测方式的yaml文件语法如下：

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:         #选择livenessProbe的探测机制
      exec:                      #执行以下命令
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5          #在容器运行五秒后开始探测
      periodSeconds: 5               #每次探测的时间间隔为5秒

在上面的配置文件中，探测机制为在容器运行5秒后，每隔五秒探测一次，如果cat命令返回的值为“0”，则表示健康，如果为非0，则表示异常。

2）Httpget：通过发送http/htps请求检查服务是否正常，返回的状态码为200-399则表示容器健康（注http get类似于命令curl -I）。

Httpget探测方式的yaml文件语法如下：

spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    livenessProbe:              #采用livenessProbe机制探测
      httpGet:                  #采用httpget的方式
    scheme:HTTP         #指定协议，也支持https
        path: /healthz          #检测是否可以访问到网页根目录下的healthz网页文件
        port: 8080              #监听端口是8080
      initialDelaySeconds: 3     #容器运行3秒后开始探测
      periodSeconds: 3                #探测频率为3秒

上述配置文件中，探测方式为项容器发送HTTP GET请求，请求的是8080端口下的healthz文件，返回任何大于或等于200且小于400的状态码表示成功。任何其他代码表示异常。

3）tcpSocket：通过容器的IP和Port执行TCP检查，如果能够建立TCP连接，则表明容器健康，这种方式与HTTPget的探测机制有些类似，tcpsocket健康检查适用于TCP业务。

tcpSocket探测方式的yaml文件语法如下：

spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
- containerPort: 8080
#这里两种探测机制都用上了，都是为了和容器的8080端口建立TCP连接
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

在上述的yaml配置文件中，两类探针都使用了，在容器启动5秒后，kubelet将发送第一个readinessProbe探针，这将连接容器的8080端口，如果探测成功，则该pod为健康，十秒后，kubelet将进行第二次连接。

除了readinessProbe探针外，在容器启动15秒后，kubelet将发送第一个livenessProbe探针，仍然尝试连接容器的8080端口，如果连接失败，则重启容器。

探针探测的结果无外乎以下三者之一：

• Success：Container通过了检查；
• Failure：Container没有通过检查；
• Unknown：没有执行检查，因此不采取任何措施（通常是我们没有定义探针检测，默认为成功）。

若觉得上面还不够透彻，可以移步其官网文档：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

73、如何控制滚动更新过程？

答：可以通过下面的命令查看到更新时可以控制的参数：

[root@master yaml]# kubectl explain deploy.spec.strategy.rollingUpdate

maxSurge： 此参数控制滚动更新过程，副本总数超过预期pod数量的上限。可以是百分比，也可以是具体的值。默认为1。

（上述参数的作用就是在更新过程中，值若为3，那么不管三七二一，先运行三个pod，用于替换旧的pod，以此类推）

maxUnavailable：此参数控制滚动更新过程中，不可用的Pod的数量。

（这个值和上面的值没有任何关系，举个例子：我有十个pod，但是在更新的过程中，我允许这十个pod中最多有三个不可用，那么就将这个参数的值设置为3，在更新的过程中，只要不可用的pod数量小于或等于3，那么更新过程就不会停止）。

74、K8s中镜像的下载策略是什么？

答：可通过命令“kubectl explain pod.spec.containers”来查看imagePullPolicy这行的解释。

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

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

75、image的状态有哪些？

• Running：Pod所需的容器已经被成功调度到某个节点，且已经成功运行，
• Pending：APIserver创建了pod资源对象，并且已经存入etcd中，但它尚未被调度完成或者仍然处于仓库中下载镜像的过程
• Unknown：APIserver无法正常获取到pod对象的状态，通常是其无法与所在工作节点的kubelet通信所致。

76、pod的重启策略是什么？

答：可以通过命令“kubectl explain pod.spec”查看pod的重启策略。（restartPolicy字段）

• Always：但凡pod对象终止就重启，此为默认策略。
• OnFailure：仅在pod对象出现错误时才重启

77、Service这种资源对象的作用是什么？

答：用来给相同的多个pod对象提供一个固定的统一访问接口，常用于服务发现和服务访问。

78、版本回滚相关的命令？

[root@master httpd-web]# kubectl apply -f httpd2-deploy1.yaml  --record  
#运行yaml文件，并记录版本信息；
[root@master httpd-web]# kubectl rollout history deployment httpd-devploy1  
#查看该deployment的历史版本
[root@master httpd-web]# kubectl rollout undo deployment httpd-devploy1 --to-revision=1    
#执行回滚操作，指定回滚到版本1
#在yaml文件的spec字段中，可以写以下选项（用于限制最多记录多少个历史版本）：
spec:
  revisionHistoryLimit: 5            
#这个字段通过 kubectl explain deploy.spec  命令找到revisionHistoryLimit   <integer>行获得

79、标签与标签选择器的作用是什么？

标签：是当相同类型的资源对象越来越多的时候，为了更好的管理，可以按照标签将其分为一个组，为的是提升资源对象的管理效率。

标签选择器：就是标签的查询过滤条件。目前API支持两种标签选择器：

• 基于等值关系的，如：“=”、“”“”、“！=”（注：“”也是等于的意思，yaml文件中的matchLabels字段）；
• 基于集合的，如：in、notin、exists（yaml文件中的matchExpressions字段）；

注：in:在这个集合中；notin：不在这个集合中；exists：要么全在（exists）这个集合中，要么都不在（notexists）；

使用标签选择器的操作逻辑：

• 在使用基于集合的标签选择器同时指定多个选择器之间的逻辑关系为“与”操作（比如：- {key: name,operator: In,values: [zhangsan,lisi]} ，那么只要拥有这两个值的资源，都会被选中）；
• 使用空值的标签选择器，意味着每个资源对象都被选中（如：标签选择器的键是“A”，两个资源对象同时拥有A这个键，但是值不一样，这种情况下，如果使用空值的标签选择器，那么将同时选中这两个资源对象）
• 空的标签选择器（注意不是上面说的空值，而是空的，都没有定义键的名称），将无法选择出任何资源；

在基于集合的选择器中，使用“In”或者“Notin”操作时，其values可以为空，但是如果为空，这个标签选择器，就没有任何意义了。

两种标签选择器类型（基于等值、基于集合的书写方法）：

selector:
  matchLabels:           #基于等值
    app: nginx
  matchExpressions:         #基于集合
    - {key: name,operator: In,values: [zhangsan,lisi]}     #key、operator、values这三个字段是固定的
    - {key: age,operator: Exists,values:}   #如果指定为exists，那么values的值一定要为空

80、常用的标签分类有哪些？

标签分类是可以自定义的，但是为了能使他人可以达到一目了然的效果，一般会使用以下一些分类：

• 版本类标签（release）：stable（稳定版）、canary（金丝雀版本，可以将其称之为测试版中的测试版）、beta（测试版）；
• 环境类标签（environment）：dev（开发）、qa（测试）、production（生产）、op（运维）；
• 应用类（app）：ui、as、pc、sc；
• 架构类（tier）：frontend（前端）、backend（后端）、cache（缓存）；
• 分区标签（partition）：customerA（客户A）、customerB（客户B）；
• 品控级别（Track）：daily（每天）、weekly（每周）。

81、有几种查看标签的方式？

答：常用的有以下三种查看方式：

[root@master ~]# kubectl get pod --show-labels    #查看pod，并且显示标签内容
[root@master ~]# kubectl get pod -L env,tier      #显示资源对象标签的值
[root@master ~]# kubectl get pod -l env,tier      #只显示符合键值资源对象的pod，而“-L”是显示所有的pod

82、添加、修改、删除标签的命令？

#对pod标签的操作
[root@master ~]# kubectl label pod label-pod abc=123     #给名为label-pod的pod添加标签
[root@master ~]# kubectl label pod label-pod abc=456 --overwrite       #修改名为label-pod的标签
[root@master ~]# kubectl label pod label-pod abc-             #删除名为label-pod的标签
[root@master ~]# kubectl get pod --show-labels
 
#对node节点的标签操作   
[root@master ~]# kubectl label nodes node01 disk=ssd      #给节点node01添加disk标签
[root@master ~]# kubectl label nodes node01 disk=sss –overwrite    #修改节点node01的标签
[root@master ~]# kubectl label nodes node01 disk-         #删除节点node01的disk标签

83、DaemonSet资源对象的特性？

DaemonSet这种资源对象会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。所以，在其yaml文件中，不支持定义replicas，除此之外，与Deployment、RS等资源对象的写法相同。

它的一般使用场景如下：

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

84、说说你对Job这种资源对象的了解？

答：Job与其他服务类容器不同，Job是一种工作类容器（一般用于做一次性任务）。使用常见不多，可以忽略这个问题。

#提高Job执行效率的方法：
spec:
  parallelism: 2           #一次运行2个
  completions: 8           #最多运行8个
  template:
metadata:

85、描述一下pod的生命周期有哪些状态？

• Pending：表示pod已经被同意创建，正在等待kube-scheduler选择合适的节点创建，一般是在准备镜像；
• Running：表示pod中所有的容器已经被创建，并且至少有一个容器正在运行或者是正在启动或者是正在重启；
• Succeeded：表示所有容器已经成功终止，并且不会再启动；
• Failed：表示pod中所有容器都是非0（不正常）状态退出；
• Unknown：表示无法读取Pod状态，通常是kube-controller-manager无法与Pod通信。

86、创建一个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数据中心。

87、删除一个Pod会发生什么事情？

答：Kube-apiserver会接受到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，此时Pod的状态Terminating，kubelet看到pod标记为Terminating就开始了关闭Pod的工作；

关闭流程如下：

• pod从service的endpoint列表中被移除；
• 如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；
• 进程被发送TERM信号（kill -14）
• 当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）。

88、K8s的Service是什么？

答：Pod每次重启或者重新部署，其IP地址都会产生变化，这使得pod间通信和pod与外部通信变得困难，这时候，就需要Service为pod提供一个固定的入口。

Service的Endpoint列表通常绑定了一组相同配置的pod，通过负载均衡的方式把外界请求分配到多个pod上

89、k8s是怎么进行服务注册的？

答：Pod启动后会加载当前环境所有Service信息，以便不同Pod根据Service名进行通信。

90、k8s集群外流量怎么访问Pod？

答：可以通过Service的NodePort方式访问，会在所有节点监听同一个端口，比如：30000，访问节点的流量会被重定向到对应的Service上面。

91、k8s数据持久化的方式有哪些？

答：

1）EmptyDir（空目录）：

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

主要使用场景：

• 只需要临时将数据保存在磁盘上，比如在合并/排序算法中；
• 作为两个容器的共享存储，使得第一个内容管理的容器可以将生成的数据存入其中，同时由同一个webserver容器对外提供这些页面。

emptyDir的特性：

同个pod里面的不同容器，共享同一个持久化目录，当pod节点删除时，volume的数据也会被删除。如果仅仅是容器被销毁，pod还在，则不会影响volume中的数据。

总结来说：emptyDir的数据持久化的生命周期和使用的pod一致。一般是作为临时存储使用。

2）Hostpath：

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

这种数据持久化方式，运用场景不多，因为它增加了pod与节点之间的耦合。

一般对于k8s集群本身的数据持久化和docker本身的数据持久化会使用这种方式，可以自行参考apiService的yaml文件，位于：/etc/kubernetes/main…目录下。

3）PersistentVolume（简称PV）：

基于NFS服务的PV，也可以基于GFS的PV。它的作用是统一数据持久化目录，方便管理。

在一个PV的yaml文件中，可以对其配置PV的大小，指定PV的访问模式：

• ReadWriteOnce：只能以读写的方式挂载到单个节点；
• ReadOnlyMany：能以只读的方式挂载到多个节点；
• ReadWriteMany：能以读写的方式挂载到多个节点。以及指定pv的回收策略：
• recycle：清除PV的数据，然后自动回收；
• Retain：需要手动回收；
• delete：删除云存储资源，云存储专用；

PS：这里的回收策略指的是在PV被删除后，在这个PV下所存储的源文件是否删除）。

若需使用PV，那么还有一个重要的概念：PVC，PVC是向PV申请应用所需的容量大小，K8s集群中可能会有多个PV，PVC和PV若要关联，其定义的访问模式必须一致。定义的storageClassName也必须一致，若群集中存在相同的（名字、访问模式都一致）两个PV，那么PVC会选择向它所需容量接近的PV去申请，或者随机申请。

1. Docker 是什么？
   Docker 是基于容器技术实现的，容器技术最开始是基于 Linux Container（简称 LXC）技术实现的，通过内核提供的 Namespace 和 Cgroup 机制，实现了对应用程序的隔离以及物理资源的分配。
   Docker 在容器基础上发展出了一个完善的生态系统，它将容器视为一种打包格式，将应用程序所需的一切，比如依赖库、运行时环境等都集合在了在一起，使得一次构建，到处运行。
   它将开发与运维很好的融合在一起。开发人员可以很轻松的构建、打包、推送和运行应用程序。而且还允许我们将容器视为部署单元，以模块化的方式发布，降低了系统的运维管理难度·
2. Docker 和虚拟机的区别？
   容器技术和虚拟机都提供了环境隔离的功能。不同的是。容器是运行在操作系统上的一个进程，它和其他应用程序是共享内核的，由操作系统提供虚拟化隔离功能；而虚拟机则是完完全全另起了个操作系统，将环境隔离的更加彻底。
3. k8s 是什么，特点？
   k8s 是一个容器管理平台，负责容器的编排、管理、调度， 支持故障转移/重启、自动扩缩容、服务发现/负载均衡、配置管理等功能，使得应用服务能从打包到部署再到监控能有一条完整的自动化流程。
4. k8s架构
   k8s 主要有 Master 节点和工作节点组成。主节点主要对集群做出全局决策(比如调度)，以及检测和响应集群事件(例如资源不足，自动扩缩容)；从节点负责维护运行的 Pod 并进行通信的网络代理。
   Mater 节点主要有以下组件：

• kube-apiserver：负责对外暴露 Kubernetes API。
• etcd：作为保存 Kubernetes 所有集群数据的后台数据库。
• kube-scheduler：在适当的时候进行调度决策，让 Pod 在合适的节点上创建运行。
• kube-controller-manager：负责监控调整调整集群的状态，比如故障检测、自动扩展、滚动更新等

Node 节点有以下组件：

• kubelet：主要负责执行、监控由调度器分配的 Pod，相当于是 Master 在每个 Node 节点上的代理。保证 Pod 的运行状态与目标状态一致。
• kube-proxy：k8s 在每个节点上的网络代理，负责为 Service 提供集群内部的服务发现和负载均衡。

1. k8s 的健康检查机制是什么？

• livenessProbe(存活探针)：用来确定什么时候要重启容器，例如通过一个 HTTP GET 请求来判断容器是否健康存活。
• readinessProbe(就绪探针)：有时候，应用程序会暂时性的不能提供通信服务。（例如启动加载大文件）。在这种情况下，既不想杀死应用程序，也不想给它发送请求。Kubernetes 提供了就绪探测器来发现并缓解这些情况，设置后，流量将不会打到 Service 上。

2. 镜像的下载策略有哪些？

• Always：总是从指定的仓库中获取镜像。
• Never：使用本地镜像，不从仓库中下载

• IfNotPresent：当本地镜像不存在时，才从仓库拉取。

当镜像标签是 latest 时，默认下载策略是 Always。当镜像标签是自定义时，使用 IfNotPresent。

7. Pod 的状态有哪些？

• Pending：pod 正在等待 kube-scheduler 选择合适的节点创建。
• Running：pod 已正常创建，并且至少有一个容器正在运行。

• Succeeded：所有容器已成功启动运行。

• Failed：pod 的容器非正常退出。

• Unknown：无法获取 pod 状态，可能节点间通信出现问题。

8. k8s 创建一个 pod 流程

1） 客户端提交 Pod 的配置信息（可以是 yaml 文件定义好的信息）到 kube-apiserver；
2） Apiserver 收到指令后，通知给 controller-manager 创建一个资源对象；
3） Controller-manager 通过 api-server 将 pod 的配置信息存储到 ETCD 数据中心中；
4） Kube-scheduler 检测到Kube-apiserver 会接受到用户的删除指令，默认有 30 秒时间等待优雅退出，超过 30 秒会被标记为死亡状态，此时 Pod 的状态 Terminating，kubelet 看到 pod 标记为 Terminating 就开始了关闭 Pod 的工作； pod 信息会开始调度预选，会先过滤掉不符合 Pod 资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行 pod 的节点，然后将 pod 的资源配置单发送到 node 节点上的 kubelet 组件上。
5） Kubelet 根据 scheduler 发来的资源配置单运行 pod，运行成功后，将 pod 的运行信息返回给 scheduler，scheduler 将返回的 pod 运行状况的信息存储到 etcd 数据中心。

9. docker的实现原理

通过Linux Cgroups来实现资源限制，限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等。

通过Linux NameSpace机制来实现资源隔离Namespace 技术实际上修改了应用进程看待整个计算机“视图”，即它的“视线”被操作系统做了限制，只能“看到”某些指定的内容。但对于宿主机来说，这些被“隔离”了的进程跟其他进程并没有太大区别.

通过rootfs机制来保证各个容器内看到的文件路径一致

10. 删除 pod 流程

Kube-apiserver 会接受到用户的删除指令，默认有 30 秒时间等待优雅退出，超过 30 秒会被标记为死亡状态，此时 Pod 的状态 Terminating，kubelet 看到 pod 标记为 Terminating 就开始了关闭 Pod 的工作；

11. docker网络模式

网络模式	配置	说明
bridge模式	–net=bridge	（默认为该模式）此模式会为每一个容器分配、设置IP等，并将容器连接到一个docker0虚拟网桥，通过docker0网桥以及Iptables nat表配置与宿主机通信。
host模式	–net=host	容器和宿主机共享Network namespace。
container模式	–net=container:NAME_or_ID	容器和另外一个容器共享Network namespace。 kubernetes中的pod就是多个容器共享一个Network namespace。
none模式	–net=none	该模式关闭了容器的网络功能。

12. service 是什么?

Pod 每次重启或者重新部署，其 IP 地址都会产生变化，这使得 pod 间通信和 pod 与外部通信变得困难，这时候，就需要 Service 为 pod 提供一个固定的入口。Service 的 Endpoint 列表通常绑定了一组相同配置的 pod，通过负载均衡的方式把外界请求分配到多个 pod 上

13. 同一个Pod中容器之间的通信

这种场景对于Kubernetes来说没有任何问题，根据Kubernetes的架构设计。Kubernetes创建Pod时，首先会创建一个pause容器，为Pod指派一个唯一的IP地址。然后，以pause的网络命名空间为基础，创建同一个Pod内的其它容器（–net=container:xxx）。因此，同一个Pod内的所有容器就会共享同一个网络命名空间，在同一个Pod之间的容器可以直接使用localhost进行通信。

14. flannel网络机制

flannel会在每一个宿主机上运行名为flanneld代理，其负责为宿主机预先分配一个子网，并为Pod分配IP地址。Flannel使用Kubernetes或etcd来存储网络配置、分配的子网和主机公共IP等信息。数据包则通过VXLAN、UDP或host-gw这些类型的后端机制进行转发。

15. docker是一个进程吗
16. Dockerfile COPY ADD 的区别

ADD指令的功能是将主机构建环境文件和目录拷贝到镜像中。

COPY是ADD的一种简化版本，目的在于满足大多数人“复制文件到容器”的需求。Add如果是压缩文件会自动解压

17. 容器实现原理

一个“容器”，实际上是一个由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境。

• Linux Namespace 和 Linux Cgroups，提供了运行时的隔离和资源的授予。
• rootfs，也就是镜像，提供了容器的运行内容。

1. iptables 的功能作用
   用来设置、维护和检查Linux内核的IP包过滤规则的。 可以定义不同的表，每个表都包含几个内部的链，也能包含用户定义的链。
2. replicaset、daemonset、statefulset的概念
   https://www.yj-example.cn/?p=925

StatefulSet

概念：StatefulSet主要用于管理有状态应用程序的工作负载API对象。

Deployment

概念：用于部署无状态的服务，这个最常用的控制器。一般用于管理维护企业内部无状态的微服务，比如configserver、zuul、springboot。他可以管理多个副本的Pod实现无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。

DaemonSet

DaemonSet（守护进程集）和守护进程类似，它在符合匹配条件的节点上均部署一个Pod。（所有节点）

1. 什么是有状态应用
   有状态服务 可以说是需要数据存储功能的服务、或者指多线程类型的服务，队列等。（mysql数据库、kafka、zookeeper等）
2. session会放在哪里
   服务器端的内存中。 不过session可以通过特殊的方式做持久化管理（memcache，redis)
3. k8s的pod之间是怎么互相访问的
   同一个pod： 直接localhost:+端口
   同一个节点，不同pod：给pod做service，通过服务发现的方式访问（service端口方式设为nodePort或者targetPort）。访问方式：nodePort:+端口
4. k8s的label与annotation
   **label:**Label 允许在 Kubernetes 资源上附加对于系统或者用户有意义的标示性属性，方便对 Kubernetes 资源进行分组管理。(用户在 pod 或者 node 上加一些 label，然后配置一些调度策Kubernetes 的 scheduler 会基于这些 label 信息进行调度)
   Annotations:Annotations 允许在 Kubernetes 资源上附加任意的非标识性元数据，用来记录资源的一些属性。
5. k8s的crd是什么
   而CRD则提供了一种方式，使用户可以自定义新的资源，以扩展k8s的功能。
6. 什么是操作系统？什么是文件系统？操作系统与文件系统的区别是什么？
   操作系统（英语：Operating System，简称OS）是管理和控制计算机 硬件与软件资源的 计算机程序，是直接 运行在“ 裸机”上的最基本的 系统软件，任何其他软件都必须在操作系统的支持下才能运行。 操作系统中负责管理和存储文件信息的软件机构称为 文件管理系统，简称文件系统。文件系统由三部分组成：文件系统的接口，对对象操纵和管理的软件集合，对象及属性
7. 1）EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由 Pod 内保部映射到宿主机上。类似于 docker 中的 manager volume。
   2）Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于 docker 中的 bind mount 挂载方式。
   3）PersistentVolume（简称 PV）： 基于 NFS 服务的 PV，也可以基于 GFS 的 PV。它的作用是统一数据持久化目录，方便管理。
8. 常用命令

• kubectl create：创建资源(kubectl create -f docker-registry.yaml)
• kubectl run：快速创建容器(kubectl run nginx --image=nginx)
• kubectl get：获取资源列表(kubectl get pods)
• kubectl describe：查看资源详细信息(kubectl describe pods/nginx)
• kubectl exec：在容器内执行命令(kubectl exec podName -c containerName -i -t – bash -il)
• kubectl logs：查看 pod 日志(kubectl logs nginx)
• kubectl delete：删除一个资源(kubectl delete pods --all)

9. 如何暴露pod访问
   1、hostNetwork：true 在pod中使用该配置，在这种Pod中运行的应用程序可以直接看到pod启动的主机的网络接口。注：每次pod的IP是会变化的
   2、hostPort：直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过主机的IP来访问Pod了
   3、NodePort：是K8s里一个广泛应用的服务暴露方式。K8s中的service默认情况都是使用Cluster IP这种类型，会产生一个只能在内部访问的Cluster IP，如果想能够直接访问service，需要将service type修改为nodePort。同时给改service指定一个nodeport值(30000-32767)，用 --service-node-port-range定义。
   4、LoadBalancer：只能在service上定义，是公有云提供的负载均衡器。
   5、Ingress：ingress controller是由K8s管理的负载均衡容器，它的镜像包含一个nginx或HAProxy负载均衡器和一个控制器守护进程。

提示：以下是本篇文章正文内容，下面案例可供参考

一、pandas是什么？

示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。

二、使用步骤

1.引入库

代码如下（示例）：

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
import warnings
warnings.filterwarnings('ignore')
import  ssl
ssl._create_default_https_context = ssl._create_unverified_context

2.读入数据

代码如下（示例）：

data = pd.read_csv(
    'https://labfile.oss.aliyuncs.com/courses/1283/adult.data.csv')
print(data.head())

该处使用的url网络请求的数据。

---

总结

提示：这里对文章进行总结：

例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。