k8，Kubernetes【1】

1. 简述ETCD及其特点?

etcd 是云原生架构中的基础组件，由 CNCF 孵化托管。etcd 在微服务和 kubernetes 集群中不仅可以作为服务注册中心用于服务发现，还可以作为 key-value 存储中间件etcd 是 CoreOS 团队与 2013 年 6 月发起的开源项目，它的目标是构建一个高可用的分布式键值（key-value）数据库。具有以下特点：
简单：安装配置简单，而且提供了 HTTP API 进行交互，使用也很简单
键值对存储：将数据存储在分层组织的目录中，如同 在标准文件系统中
检测变更：监测特定的键或目录以进行更改，并对值的更改做出反应
安全：支持 SSL 证书验证
快速：根据官方提供的 benchmark 数据，单实例支持每秒 2k+ 读操作
可靠：采用 raft 算法，实现分布式系统数据的可用性和一致性
etcd 采用 Go 语言编写，它具有出色的跨平台支持，很小的二进制文件和强大的社区。etcd 机器之间的通信通过 Raft 算法处理。
etcd 是一个高度一致的分布式键值存储，它提供了一种可靠的方式来存储需要分布式系统或机器集群访问的数据。它可以优雅处理网络分区期间的 leader 选举，以应对机器的故障，即使是在 leader 节点发生故障时。
从简单的 Web 应用程序到 kubernetes 集群，任何复杂的应用程序都可以从 etcd 中读取数据或将数据写入 etcd。etcd 于 2018 年 12 月正式加入云原生计算基金会 CNCF，并由 CNCF 支持

2. 简述ETCD适应的场景?

etcd比较多的应用场景是用于服务注册与发现，除此之外，也可以用于键值对存储，应用程序可以读取和写入etcd中的数据。一个简单的用例是将数据连接详细或功能标志存储在etcd中作为键值对。可以观察这些值，使我们的应用在更改时可以重新配置自己。高级用法是利用etcd的一致性保证来实施数据库leader选举或在一组follower之间执行分布式锁定。

3. 简述什么是键值对存储 ?

归根接底，etcd是一个键值存储的组件，其他的应用都是基于其键值存储的功能展开。etcd的存储有如下特点：
采用KV型数据存储，一般情况下比关系型数据库快
支持动态存储（内存）以及静态存储（磁盘）
分布式存储，可集成为多节点集群
存储方式，采用类似目录结构
只有叶子节点才能真正存储数据，相当于文件
叶子节点的父节点一定是目录，目录不能存储数据
etcd leader的延迟是要跟踪的最重要的指标，严重的延迟会在集群内造成不稳定，因为Raft的速度仅与大多数机器中最慢的一样快。

4. 简述什么是Kubernetes?

Kubernetes是一个全新的基于容器技术的分布式系统支撑平台。是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力，多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力

5. 简述Kubernetes和Docker的关系?

Docker提供容器的生命周期管理，Docker镜像构建运行时容器。但是，由于这些单独的容器必须通信，因此使用Kubernetes。因此，我们说Docker构建容器，这些容器通过 Kubernetes相互通信。因此，可以使用Kubernetes手动关联和编排在多个主机上运行的容器。
Docker是用于构建、分发和运行Docker容器的平台和工具；而Kubernetes不包含用于创建或管理容器镜像的功能，并且它本身并不运行容器。因此两者的主要区别在于Docker在单个节点上运行，而Kubernetes设计为在集群上运行。
Kubernetes和Docker另一个主要区别在于Docker可以在没有Kubernetes的情况下使用，而Kubernetes需要容器运行时才能进行编排。
Kubernetes 的早期版本仅适用于特定的容器运行时：Docker Engine。 后来，Kubernetes 增加了对使用其他容器运行时的支持。创建 CRI 标准是为了实现编排器（如 Kubernetes）和许多不同的容器运行时之间交互操作。 Docker Engine 没有实现（CRI）接口，因此 Kubernetes 项目创建了特殊代码来帮助过渡， 并使 dockershim 代码成为 Kubernetes 的一部分。
dockershim 代码一直是一个临时解决方案（因此得名：shim）。 你可以阅读 Kubernetes 移除 Dockershim 增强方案以了解相关的社区讨论和计划。 事实上，维护 dockershim 已经成为 Kubernetes 维护者的沉重负担。
在 1.20 版本- 1.23 版本，如果使用 Docker Engine， 在 kubelet 启动时会打印一个警告日志。 dockershim 将在 Kubernetes 1.24 版本中移除 。
Mirantis 和 Docker 已承诺 为 Docker Engine 维护一个替代适配器， 并在 dockershim 从 Kubernetes 移除后维护该适配器。 替代适配器名为 cri-dockerd。

6. 简介典型K8S Runtime架构 ？

目前，dockershim 将在 Kubernetes 1.24 版本中移除，但目前的最新版本是1.23，所以Kubernetes 的架构还是如此。
Kubelet 通过 CRI 接口（gRPC）调用 dockershim，请求创建一个容器。CRI 即容器运行时接口（Container Runtime Interface），这一步中，Kubelet 可以视作一个简单的 CRI Client，而 dockershim 就是接收请求的 Server。目前 dockershim 的代码其实是内嵌在 Kubelet 中的，所以接收调用的凑巧就是 Kubelet 进程；
dockershim 收到请求后，转化成 Docker Daemon 能听懂的请求，发到 Docker Daemon 上请求创建一个容器。
Docker Daemon 早在 1.12 版本中就已经将针对容器的操作移到另一个守护进程——containerd 中了，因此 Docker Daemon 仍然不能帮我们创建容器，而是要请求 containerd 创建一个容器；
containerd 收到请求后，并不会自己直接去操作容器，而是创建一个叫做 containerd-shim 的进程，让 containerd-shim 去操作容器。这是因为容器进程需要一个父进程来做诸如收集状态，维持 stdin 等 fd 打开等工作。而假如这个父进程就是 containerd，那每次 containerd 挂掉或升级，整个宿主机上所有的容器都得退出了。而引入了 containerd-shim 就规避了这个问题（containerd 和 shim 并不是父子进程关系）；
我们知道创建容器需要做一些设置 namespaces 和 cgroups，挂载 root filesystem 等等操作，而这些事该怎么做已经有了公开的规范了，那就是 OCI（Open Container Initiative，开放容器标准）。它的一个参考实现叫做 runC。于是，containerd-shim 在这一步需要调用 runC 这个命令行工具，来启动容器；
runC 启动完容器后本身会直接退出，containerd-shim 则会成为容器进程的父进程，负责收集容器进程的状态，上报给 containerd，并在容器中 pid 为 1 的进程退出后接管容器中的子进程进行清理，确保不会出现僵尸进程。

7. 在主机和容器上部署应用程序有什么区别？

主机部署时各应用共享操作系统以及各种库。应用之间不相互隔离。 容器部署时除了内核共享，容器内的应用各自隔离，各自有运行自己应用的不同的库。

8. 简述Kubernetes的常规组织架构 ？

kubectl：客户端命令行工具，作为整个系统的操作入口。
kube-apiserver：以 REST API 服务形式提供接口，作为整个系统的控制入口。
kube-controller-manager：执行整个系统的后台任务，包括节点状态状况、Pod 个数、Pods 和Service 的关联等。
kube-scheduler：负责节点资源管理，接收来自 kube-apiserver 创建 Pods 任务，并分配到某个节点。
etcd：负责节点间的服务发现和配置共享。
kube-proxy：运行在每个计算节点上，负责 Pod 网络代理。定时从 etcd 获取到 service 信息来做相应的策略。
kubelet：运行在每个计算节点上，作为 agent，接收分配该节点的 Pods 任务及管理容器，周期性获取容器状态，反馈给 kube-apiserver。
DNS：一个可选的 DNS 服务，用于为每个 Service 对象创建 DNS 记录，这样所有的 Pod 就可以通过 DNS 访问服务了。

9. 简述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节点上，若干相关容器的组合。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定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。
Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行；
Volume：
Volume是Pod中能够被多个容器访问的共享目录，Kubernetes中的Volume是定义在Pod上，可以被一个或多个Pod中的容器挂载到某个目录下；
Namespace：
Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的不同项目、小组或用户组，便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理；

10. 简述Kubernetes的优势、适应场景及其特点?

优势：容器编排、轻量级、开源、弹性伸缩、负载均衡；
场景：快速部署应用、快速扩展应用、无缝对接新的应用功能、节省资源，优化硬件资源的使用；
特点：
可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）、
可扩展: 模块化,、插件化、可挂载、可组合、
自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展；

11. 简述Kubernetes的缺点或当前的不足之处?

Kubernetes当前存在的缺点（不足）如下：
安装过程和配置相对困难复杂。
管理服务相对繁琐。
运行和编译需要很多时间。
它比其他替代品更昂贵。
对于简单的应用程序来说，可能不需要涉及Kubernetes即可满足复制、自动伸缩/扩展；

12. 简述什么是容器编排 ？

应用一般由单独容器化的组件（通常称为微服务）组成，且必须按顺序在网络级别进行组织，以使其能够按照计划运行。以这种方法对多个容器进行组织的流程即称为容器编排。

13. 简述容器编排的工作原理是什么？

使用容器编排工具（例如 Kubernetes）时，需要用到 YAML 或 JSON 文件来描述应用的配置。该配置文件会告诉配置管理工具到哪里查找容器镜像，如何建立网络，以及将日志存储在哪里。
部署新容器时，容器管理工具会考虑所有已定义的要求或限制，自动将部署调度到集群并查找适合的主机。之后，编排工具将根据 compose 文件中所确定的规范来管理容器的生命周期。
您可以使用 Kubernetes 模式来管理基于容器的应用和服务的配置、生命周期及规模。这些可重复的模式是 Kubernetes 开发人员构建完整系统所需的工具。
容器编排可以在运行容器的任何环境中使用，包括内部服务器和公共云或私有云环境。

14. 剖析kubeadm、Kubectl、Kubelet概念？

Minikube是一种可以在本地轻松运行一个单节点Kubernetes群集的工具。
Kubectl是一个命令行工具，可以使用该工具控制Kubernetes集群管理器，如检查群集资源，创建、删除和更新组件，查看应用程序。
Kubelet是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下

15. 简述Kubernetes常见的部署方式?

部署Kubernetes大致有以下三种形式：

1、Kubernetes-as-a-Service
这些解决方案能够在各种基础设施中部署kubernetes：比如公有云或者本地私有化。Kubernetes集群选择这种方法有以下几个优点：

1. 通过KaaS供应商升级，监控和支持
2. 混合云或多云环境下轻松扩充
3. 多个集群也能良好的展现
4. 高可用的多主机Kubernetes集群，能根据负载进行自动伸缩
5. 常见的企业集成，如SSO /隔离命名空间;
   以及拥有通过Helm chart部署应用程序的能力
6. 集群联合，在多个云或数据中心之间提供无缝的混合环境

2、托管基础设施
Google云平台和微软Azure分别通过GKE（Google
Container Engine）和ACS（Azure Container Service）提供Kubernetes 。在公有云中使用容器技术可以快速启动，但这样一来，数据将驻留在网络和防火墙之外。
Google的GKE领导着其他公有云供应商。谷歌一直在使用一个叫Borg的集群管理器来管理内部的容器项目，有超过十年的经验（来源：TheNextPlatform）。相比之下，微软的ACS则是一个相对年轻的产品，在今年2月份才推出对Kubernetes的支持。但是，ACS相当灵活：用户可自行选择容器编排平台（Kubernetes，Docker Swarm，DCOS），并且除了Linux之外，还可以在Windows上能部署容器化应用程序。如下图所示，GKE和ACS在公有云平台上， Kubernetes的服务和基础设施由托管提供商部署和管理。

3、本地部署
Minikube是本地部署Kubernetes最流行的方式。它支持各种虚拟机管理，包括VirtualBox，VMware Fusion，KVM和xhyve以及OS，包括OSX，Windows和Linux。
如上所示，用户使用Minikube CLI和Kubectl进行部署，这是Kubernetes的原生CLL。Minikube CLI可用于启动，停止，删除，获取状态，并在虚拟机上执行其他操作。一旦Minikube虚拟机启动，Kubectl CLI就会在Kubernetes集群上执行操作。以下命令启动现有的Minikube虚拟机并创建NGINX Kubernetes部署：
总结
综上，Kubernetes-as-a-service，Kubernetes托管基础设施，Minikube便是部署Kubernetes的三种方式。最后，如果你希望Kubernetes发挥最大的工作效能，还需要一款性能强劲，高效稳定的容器云平台，由Ghostcloud研发的EcOS平台便是一个很不错的选择，它可以让Kubernetes的优势展现得淋漓尽致。

16. 简述Kubernetes的优势、适应场景及其特点?

Kubernetes作为一个完备的分布式系统支撑平台，其主要优势：
容器编排
轻量级
开源
弹性伸缩
负载均衡
Kubernetes常见场景：
快速部署应用
快速扩展应用
无缝对接新的应用功能
节省资源，优化硬件资源的使用
Kubernetes相关特点：
可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）。
可扩展: 模块化,、插件化、可挂载、可组合。
自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展。

17. 简述Kubernetes组件的架构模型 ？

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；

18. 简述kubernetes的Master组件-kube-apiserver作用 ？

kube-apiserver
Kubernetes API，集群的统一入口，各组件协调者，以Restful API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储
用于暴露Kubernetes API，任何资源请求或调用操作都是通过kube-apiserver 提供的接口进行。以HTTP Restful API提供接口服务，所有对象资源的增删改查和监听操作都交给API Server 处理后再提交给Etcd 存储（相当于分布式数据库，以键值对方式存储）。
可以理解成API Server 是K8S的请求入口服务。API server 负责接收K8S所有请求(来自UI界面或者CLI 命令行工具)，然后根据用户的具体请求，去通知其他组件干活。可以说API server 是K8S集群架构的大脑。

19. 简述kubernetes的Master组件-kube-controller-manager作用 ？

kube-controller-manager (控制器管理中心-定义资源类型)

运行管理控制器，是k8s集群中处理常规任务的后台线程，是k8s集群里所有资源对象的自动化控制中心。
在k8s集群中，一个资源对应一个控制器，而Controller manager 就是负责管理这些控制器的。
由一系列控制器组成，通过API Server监控整个集群的状态，并确保集群处于预期的工作状态，比如当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态

控制器 功能
NodeContrpller(节点控制器)：负责在节点出现故障时发现和响应
Replication Controller ( 副本控制器)：负责保证集群中一个RC (资源对象ReplicationController) 所关联的Pod副本数始终保持预设值。可以理解成确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量
Endpoints Controller (端点控制器) ：
填充端点对象(即连接Services 和Pods) ，负责监听Service 和对应的Pod 副本的变化。可以理解端点是一个服务暴露出来的访问点，

如果需要访问一个服务，则必须知道它的 endpoint
Service Account & Token Controllers (服务帐户和令牌控制器)：为新的命名空间创建默认帐户和API访问令牌
ResourceQuotaController(资源配额控制器)：确保指定的资源对象在任何时候都不会超量占用系统物理资源
Namespace Controller (命名空间控制器)：管理namespace的生命周期
Service Controller (服务控制器)：属于K8S集群与外部的云平台之间的一个接口控制器

20. 简述kubernetes的Master组件-kube-scheduler作用 ？

kube-scheduler
可以理解成K8S所有Node 节点的调度器。当用户要部署服务时，scheduler 会根据调度算法选择最合适的Node 节点来部署Pod
API Server 接收到请求创建一批Pod，API Server 会让Controller-manager 按照所预设的模板去创建Pod，Controller-manager 会通过API Server去找Scheduler 为新创建的Pod选择最适合的Node 节点。比如运行这个Pod需要2C4G 的资源，Scheduler 会通过预算策略在所有Node节点中挑选最优的。Node 节点中还剩多少资源是通过汇报给API Server 存储在etcd 里，API Server 会调用一个方法找到etcd 里所有Node节点的剩余资源，再对比Pod 所需要的资源，在所有Node 节点中查找哪些Node节点符合要求。
如果都符合，预算策略就交给优选策略处理，优选策略再通过CPU的负载、内存的剩余量等因素选择最合适的Node 节点，并把Pod调度到这个Node节点上运行。
controller manager会通过API Server通知kubelet去创建pod，然后通过kube-proxy中的service对外提供服务接口。（node组件）

21. 简述kubernetes的Master组件-etcd（存储中心）作用 ？

分布式键值存储系统（特性:服务自动发现）。用于保存集群状态数据，比如Pod、Service等对象信息
k8s中仅API Server 才具备读写权限，其他组件必须通过API Server 的接口才能读写数据
PS:etcd V2版本:数据保存在内存中
v3版本:引入本地volume卷的持久化（可根据磁盘进行恢复),服务发现，分布式（方便扩容，缩容）
etcd是一种定时全量备份+持续增量备份的持久化方式，最后存储在磁盘中
但kubernetes 1.11版本前不支持v3,我用的事K8S 1.15
ETCD一般会做为3副本机制(奇数方式)，分布在三台master上(也有的公司单独用服务器部署ETCD )
master：奇数的方式部署（多节点的时候）

22. 简述kubernetes的Master组件-AUTH :认证模块作用 ？

K8S 内部支持使用RBAC认证的方式进行认证

23. 简述kubernetes的Master组件-cloud-controller-manager作用 ？

云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接集群到云提供商的应用编程接口中， 并把和该云平台交互的组件与只和您的集群交互的组件分离开。
cloud-controller-manager 仅运行特定于云平台的控制回路。 如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的环境中不需要云控制器管理器。
与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的 控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力

下面的控制器都包含对云平台驱动的依赖：
节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器

24. 简述kubernetes的Node组件-kubelet作用 ？

kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期,比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器
kubelet —》先和docker引擎进行交互—》docker容器(一组容器跑在Pod中)

25. 简述kubernetes的Node组件-kube-proxy（四层）作用 ？

在Node节点上实现Pod网络代理，维护网络规则、pod之间通信和四层负载均衡工作。默认会写入规则至iptables ，目前支持IPVS、同时还支持namespaces
对于七层的负载，k8s官方提供了一种解决方案；ingress-nginx

26. 简述kubernetes的Node组件-docker作用 ？

容器引擎，运行容器

27. 解释kube-api-server的端口是多少？各个pod是如何访问kube-api-server的？

kube-api-server的端口是8080和6443，前者是http的端口，后者是https的端口，以我本机使用kubeadm安装的k8s为例：
在命名空间的kube-system命名空间里，有一个名称为kube-api-master的pod，
这个pod就是运行着kube-api-server进程，它绑定了master主机的ip地址和6443端口，但是在default命名空间下，存在一个叫kubernetes的服务，该服务对外暴露端口为443，目标端口6443，
这个服务的ip地址是clusterip地址池里面的第一个地址，同时这个服务的yaml定义里面并没有指定标签选择器，
也就是说这个kubernetes服务所对应的endpoint是手动创建的，该endpoint也是名称叫做kubernetes，该endpoint的yaml定义里面代理到master节点的6443端口，也就是kube-api-server的IP和端口。
这样一来，其他pod访问kube-api-server的整个流程就是：pod创建后嵌入了环境变量，pod获取到了kubernetes这个服务的ip和443端口，请求到kubernetes这个服务其实就是转发到了master节点上的6443端口的kube-api-server这个pod里面

28. 简述k8s中命名空间的作用 ？

命名空间（namespace）是Kubernetes提供的组织机制，用于给集群中的任何对象组进行分类、筛选和管理。每一个添加到Kubernetes集群的工作负载必须放在一个命名空间中。

命名空间为集群中的对象名称赋予作用域。虽然在命名空间中名称必须是唯一的，但是相同的名称可以在不同的命名空间中使用。这对于某些场景来说可能帮助很大。例如，如果使用命名空间来划分应用程序生命周期环境（如开发、staging、生产），则可以在每个环境中维护利用同样的名称维护相同对象的副本。

命名空间还可以让用户轻松地将策略应用到集群的具体部分。你可以通过定义ResourceQuota对象来控制资源的使用，该对象在每个命名空间的基础上设置了使用资源的限制。类似地，当在集群上使用支持网络策略的CNI（容器网络接口）时，比如Calico或Canal（calico用于策略，flannel用于网络）。你可以将NetworkPolicy应用到命名空间，其中的规则定义了pod之间如何彼此通信。不同的命名空间可以有不同的策略。

理解预配置的Kubernetes命名空间
新的K8S集群默认会创建四个命名空间：

default：默认命名空间。资源未指定命名空间时，均创建在此命名空间下
kube-public：这个命名空间对所有用户可见（包括未授权用户），通常作为保留资源为集群所使用
kube-system：K8s 系统创建的对象在此命名空间下
kube-node-lease：此命名空间用于与各个节点相关的租期(Lease)对象；此对象的设计使得集群规模很大时节点心跳检测性能得到提升
注意：创建命名空间时，应避免使用 kube-作为前缀。

约束
在同一个命名空间中，资源名称须保持唯一。但在不同命名空间中，可以存在相同名称的资源。
每一个资源只能隶属于一个命名空间。
但命名空间本身不能属于另一个命名空间。

29. 简述Kubernetes核心概念 ？

Kubernetes包含多种类型的资源对象: Pod、 Label、 Service、 Replication Controller 等。
所有的资源对象都可以通过Kubernetes 提供的kubectl 工具进行增、删、改、查等操作，并将其保存在etcd 中持久化存储。
Kubernets其实是一个高度自动化的资源控制系统，通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异，来实现自动控制和自动纠错等高级功能

30. 解释什么是Pod ？

Pod是Kubernetes 创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。

可以把Pod理解成豌豆荚，而同一Pod内的每个容器是一颗颗豌豆。
一个Pod 由一个或多个容器组成，Pod 中容器共享网络、存储和计算资源，在同一台Docker 主机上运行。
一个Pod里可以运行多个容器，又叫边车模式(SideCara) 模式。而在生产环境中一 般都是单个容器或者具有强关联互补的多个容器组成一 个Pod。
同一个Pod 之间的容器可以通过localhost 互相访问，并且可以挂载Pod 内所有的数据卷;但是不同的Pod之间的容器不能用localhost访问，也不能挂载其他Pod的数据卷

31. 解释什么是Pod控制器 ？

Pod控制器是Pod启动的一种模版，用来保证在K8S里启动的Pod应始终按照用户的预期运行(副本数、生命周期、健康状态检查等)

K8s内提供了众多的Pod控制器，常用的有以下几种:
Deployment：无状态应用部署。Deployment 的作用是管理和控制Pod和ReplicaSet， 管控它们运行在用户期望的状态中。
Replicaset：确保预期的Pod 副本数量。Replicaset 的作用就是管理和控制Pod， 管控他们好好干活。但是，ReplicaSet 受控于Deployment。
可以理解成Deployment 就是总包工头，主要负责监督底下的工人Pod 干活，
确保每时每刻有用户要求数量的Pod在工作。如果一旦发现某个工人Pod 不行了，
就赶紧新拉一个Pod 过来替换它。而ReplicaSet 就是总包工头手下的小包工头。

从K8S使用者角度来看，用户会直接操作Deployment 部署服务，
而当Deployment 被部署的时候，K8S 会自动生成要求的ReplicaSet和Pod。
用户只需要关心Deployment 而不操心ReplicaSet。
资源对象Replication Controller 是ReplicaSet 的前身，
官方推荐用Deployment 取代Replication Controller 来部署服务。
Daemonset：确保所有节点运行同一类Pod，保证每 个节点上都有一个此类Pod运行，通常用于实现系统级后台任务。
Statefulset：有状态应用部署
Job：一次性任务。 根据用户的设置，Job管理的Pod把任务成功完成就自动退出了。
Cronjob：周期性计划性任务

32. 简述什么是Label ？

标签，是K8S特色的管理方式，便于分类管理资源对象。
Label可以附加到各种资源对象.上，例如Node、Pod、Service、 RC等，用于关联对象、查询和筛选。
一个Label 是一个key-value 的键值对，其中key 与value 由用户自己指定。
一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象中，也可以在对象创建后动态添加或者删除。
可以通过给指定的资源对象捆绑一个或多个不同的Label，来实现多维度的资源分组管理功能。
与Label 类似的，还有Annotation (注释)
区别在于有效的标签值必须为63个字符或更少，并且必须为空或以字母数字字符( [a-z0-9A-Z])开头和结尾，中间可以包含横杠(-)、下划线(_)、点(.)和字母或数字。注释值则没有字符长度限制。

33. 简述什么是Label选择器(Label selector )？

当我们给一组对象，比如有10个pod，打上了不同的标签之后，当我们要选择其中的部分，或者全部作为使用目标的时候，就可以使用label selector来实现这个操作，标签选择器中指定具体的过滤的条件，然后，就能在10个pod中过滤出满足我们要求的这些pod
给某个资源对象定义一个Label，就相当于给它打了一个标签;随后可以通过标签选择器( Label selector) 查询和筛选拥有某些Label的资源对象。
标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在)。

34. 简述什么是Service ？

在K8s的集群里，虽然每个Pod会被分配一个单独的IP地址，但由于Pod是有生命周期的(它们可以被创建，而且销毁之后不会再启动)，随时可能会因为业务的变更，导致这个IP地址也会随着Pod 的销毁而消失。
Service就是用来解决这个问题的核心概念。

K8S中的Service并不是我们常说的“服务"的含义，而更像是网关层，可以看作一组提供相同服务的Pod的对外访问接口、流量均衡器

35. 阐述Service作用于哪些Pod是通过标签选择器来定义的 ？

在K8S集群中，service 可以看作一组提供相同服务的Pod的对外访问接口。客户端需要访问的服务就是service对象。每个service都有一个固定的虛拟ip (这个ip也被称为Cluster IP) ，自动并且动态地绑定后端的Pod， 所有的网络请求直接访问Service 的虚拟ip,service会自动向后端做转发。
Service除了提供稳定的对外访问方式之外，还能起到负载均衡(Load Balance)的功能，自动把请求流量分布到后端所有的服务.上，Service可以做到对客户透明地进行水平扩展(scale)。
而实现service 这一功能的关键， 就是kube-proxy。 kube-proxy 运行在每个节点上，监听API Server 中服务对象的变化，可通过以下三种流量调度模式:
userspace (废弃)、iptables ( 濒临废弃)、ipvs (推荐，性能最好)来实现网络的转发。
Service 是K8S服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。比如我们的一个服务A，部署了3个副本，也就是3个Pod;
对于用户来说，只需要关注一个Service 的入口就可以，而不需要操心究竞应该请求哪一个Pod。
优势非常明显:一方面外部用户不需要感知因为Pod. 上服务的意外崩溃、K8S重新拉起Pod 而造成的IP变更，外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化

36. 简述什么是Ingress ？

Service主要负责K8S集群内部的网络拓扑，那么集群外部怎么访问集群内部呢?这个时候就需要Ingress 了。Ingress 是整个K8S集群的接入层，负责集群内外通讯。
Ingress是K8S 集群里工作在OSI网络参考模型下，第7层的应用，对外暴露的接口，典型的访问方式是http/https.
Service只能进行第四层的流量调度，表现形式是iptport。 Ingress 则可以调度不同业务域、不同URL访问路径的业务流量。
比如:客户端请求http://www. 123.com:port —> Ingress —> Service —> Pod

37. 简述什么是Name ？

由于K8S内部，使用“资源”来定义每一种逻辑概念(功能)，所以每种“资源”，都应该有自己的“名称”。
“资源”有api 版本(apiversion) 、类别(kind) 、元数据(metadata) 、定义清单(spec) 、状态(status) 等配置信息。
“名称”通常定义在“资源”的“元数据”信息里。在同一个namespace 空间中必须是唯一的

38. 解释kubernetes的核心作用整理总结 ？

kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：
自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器
弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整
服务发现：服务可以通过自动发现的形式找到它所依赖的服务
负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡
版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本
存储编排：可以根据容器自身的需求自动创建存储卷

39. 简述kubernetes重要特性 ？

1 服务发现和负载均衡
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
2 存储编排
Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。
3 自动部署和回滚
你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。
4 自动完成装箱计算
Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
5 自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
6 密钥与配置管理
Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

40. 详细阐述Pod有什么特点 ？

1、每个pod就像一个独立的逻辑机器，k8s会为每个pod分配一个集群内部唯一的IP地址，所以每个pod都拥有自己的IP地址、主机名、进程等；
2、一个pod可以包含1个或多个容器，1个容器一般被设计成只运行1个进程，1个pod只可能运行在单个节点上，即不可能1个pod跨节点运行，pod的生命周期是短暂，也就是说pod可能随时被消亡（如节点异常，pod异常等情况）；
2、每一个pod都有一个特殊的被称为"根容器"的pause容器，也称info容器，pause容器对应的镜像属于k8s平台的一部分，除了pause容器，每个pod还包含一个或多个跑业务相关组件的应用容器；
3、一个pod中的容器共享network命名空间；
4、一个pod里的多个容器共享pod IP，这就意味着1个pod里面的多个容器的进程所占用的端口不能相同，否则在这个pod里面就会产生端口冲突；既然每个pod都有自己的IP和端口空间，那么对不同的两个pod来说就不可能存在端口冲突；
5、应该将应用程序组织到多个pod中，而每个pod只包含紧密相关的组件或进程；
6、pod是k8s中扩容、缩容的基本单位，也就是说k8s中扩容缩容是针对pod而言而非容器

41. 简述Pod的重启策略有哪些？

pod重启容器策略是指针对pod内所有容器的重启策略，不是重启pod，其可以通过restartPolicy字段配置pod重启容器的策略，如下：
Always: 当容器终止退出后，总是重启容器，默认策略就是Always。
OnFailure: 当容器异常退出，退出状态码非0时，才重启容器。
Never: 当容器终止退出，不管退出状态码是什么，从不重启容器

42. Pod的镜像拉取策略有哪几种？

pod镜像拉取策略可以通过imagePullPolicy字段配置镜像拉取策略，

主要有3中镜像拉取策略，如下：
IfNotPresent: 默认值，镜像在node节点宿主机上不存在时才拉取。
Always: 总是重新拉取，即每次创建pod都会重新从镜像仓库拉取一次镜像。
Never: 永远不会主动拉取镜像，仅使用本地镜像，需要你手动拉取镜像到node节点，如果node节点不存在镜像则pod启动失败。

43. 解释kubenetes针对Pod资源对象的健康监测机制?

提供了三类probe（探针）来执行对pod的健康监测：
livenessProbe探针 （存活探针）:
可以根据用户自定义规则来判定pod是否健康，用于判断容器是否处于Running状态，
如果不是，kubelet就会杀掉该容器，并根据重启策略做相应的处理。如果容器不包含该探针，那么kubelet就会默认返回值都是success;
ReadinessProbe探针:
同样是可以根据用户自定义规则来判断pod是否健康，容器服务是否可用（Ready），如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功;
startupProbe探针:
启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，
这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可;
备注：每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：
initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败；
periodSeconds：检查间隔，多久执行probe检查，默认为10s；
timeoutSeconds：检查超时时长，探测应用timeout后为失败；
successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。

44. 简述Kubernetes Pod的常见调度方式?

1）Deployment或RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量；
2）NodeSelector：定向调度，当需要手动指定将Pod调度到特定Node上，可以通过Node的标签（Label）和Pod的nodeSelector属性相匹配；
3）NodeAffinity亲和性调度：亲和性调度机制极大的扩展了Pod的调度能力，目前有两种节点亲和力表达：硬规则，必须满足指定的规则，调度器才可以调度Pod至Node上（类似nodeSelector，语法不同）；软规则，优先调度至满足的Node的节点，但不强求，多个优先级规则还可以设置权重值；
4）Taints和Tolerations（污点和容忍）：Taint：使Node拒绝特定Pod运行；Toleration：为Pod的属性，表示Pod能容忍（运行）标注了Taint的Node；

45. 简述Kubernetes中什么是静态Pod?

静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过API Server进行管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对他们进行健康检查。
静态Pod总是由kubelet进行创建，并且总是在kubelet所在的Node上运行

46. 简述Pod的有哪些状态 ？

1）Pending：已经创建了Pod，但是其内部还有容器没有创建；
2）Running：Pod内部的所有容器都已经创建，只有由一个容器还处于运行状态或者重启状态；
3）Succeeed：Pod内所有容器均已经成功执行并且退出，不会再重启；
4）Failed：Pod内所有容器都退出，但至少有一个为退出失败状态；
5）Unknown：由于某种原因不能获取该Pod的状态，可能是网络问题；

47. 简述就绪探针（ReadinessProbe探针）与存活探针（livenessProbe探针）区别是什么？

两者作用不一样
存活探针是将检查失败的容器杀死，创建新的启动容器来保持pod正常工作；
就绪探针是，当就绪探针检查失败，并不重启容器，而是将pod移出endpoint，就绪探针确保了service中的pod都是可用的，确保客户端只与正常的pod交互并且客户端永远不会知道系统存在问题

48. 简述存活探针的属性参数有哪几个？

存活探针的附加属性参数有以下几个：
initialDelaySeconds：表示在容器启动后延时多久秒才开始探测；
periodSeconds：表示执行探测的频率，即间隔多少秒探测一次，默认间隔周期是10秒，最小1秒；
timeoutSeconds：表示探测超时时间，默认1秒，最小1秒，表示容器必须在超时时间范围内做出响应，否则视为本次探测失败；
successThreshold：表示最少连续探测成功多少次才被认定为成功，默认是1，对于liveness必须是1，最小值是1；
failureThreshold：表示连续探测失败多少次才被认定为失败，默认是3，连续3次失败，k8s 将根据pod重启策略对容器做出决定；
注意：定义存活探针时，一定要设置initialDelaySeconds属性，该属性为初始延时，如果不设置，默认容器启动时探针就开始探测了，这样可能会存在
应用程序还未启动就绪，就会导致探针检测失败，k8s就会根据pod重启策略杀掉容器然后再重新创建容器的莫名其妙的问题。
在生产环境中，一定要定义一个存活探针。

49. 简述K8S创建Pod过程 ？

情况一、使用kubectl run命令创建的pod：

注意：
kubectl run 在旧版本中创建的是deployment，
但在新的版本中创建的是pod则其创建过程不涉及deployment
如果是单独的创建一个pod，则其创建过程是这样的：
1、首先，用户通过kubectl或其他api客户端工具提交需要创建的pod信息给apiserver；
2、apiserver验证客户端的用户权限信息，验证通过开始处理创建请求生成pod对象信息，并将信息存入etcd，然后返回确认信息给客户端；
3、apiserver开始反馈etcd中pod对象的变化，其他组件使用watch机制跟踪apiserver上的变动；
4、scheduler发现有新的pod对象要创建，开始调用内部算法机制为pod分配最佳的主机，并将结果信息更新至apiserver；
5、node节点上的kubelet通过watch机制跟踪apiserver发现有pod调度到本节点，尝试调用docker启动容器，并将结果反馈apiserver；
6、apiserver将收到的pod状态信息存入etcd中。
至此，整个pod创建完毕。

情况二、使用deployment来创建pod：

1、首先，用户使用kubectl create命令或者kubectl apply命令提交了要创建一个deployment资源请求；
2、api-server收到创建资源的请求后，会对客户端操作进行身份认证，在客户端的~/.kube文件夹下，已经设置好了相关的用户认证信息，这样api-server会知道我是哪个用户，并对此用户进行鉴权，当api-server确定客户端的请求合法后，就会接受本次操作，并把相关的信息保存到etcd中，然后返回确认信息给客户端。
3、apiserver开始反馈etcd中过程创建的对象的变化，其他组件使用watch机制跟踪apiserver上的变动。
4、controller-manager组件会监听api-server的信息，controller-manager是有多个类型的，比如Deployment Controller, 它的作用就是负责监听Deployment，此时Deployment Controller发现有新的deployment要创建，那么它就会去创建一个ReplicaSet，一个ReplicaSet的产生，又被另一个叫做ReplicaSet Controller监听到了，紧接着它就会去分析ReplicaSet的语义，它了解到是要依照ReplicaSet的template去创建Pod, 它一看这个Pod并不存在，那么就新建此Pod，当Pod刚被创建时，它的nodeName属性值为空，代表着此Pod未被调度。
5、调度器Scheduler组件开始介入工作，Scheduler也是通过watch机制跟踪apiserver上的变动，发现有未调度的Pod，则根据内部算法、节点资源情况，pod定义的亲和性反亲和性等等，调度器会综合的选出一批候选节点，在候选节点中选择一个最优的节点，然后将pod绑定该该节点，将信息反馈给api-server。
6、kubelet组件布署于Node之上，它也是通过watch机制跟踪apiserver上的变动，监听到有一个Pod应该要被调度到自身所在Node上来，kubelet首先判断本地是否在此Pod，如果不存在，则会进入创建Pod流程，创建Pod有分为几种情况，第一种是容器不需要挂载外部存储，则相当于直接docker run把容器启动，但不会直接挂载docker网络，而是通过CNI调用网络插件配置容器网络，如果需要挂载外部存储，则还要调用CSI来挂载存储。kubelet创建完pod，将信息反馈给api-server，api-servier将pod信息写入etcd。
7、Pod建立成功后，ReplicaSet Controller会对其持续进行关注，如果Pod因意外或被我们手动退出，ReplicaSet Controller会知道，并创建新的Pod，以保持replicas数量期望值。

50. 简述 K8S 创建一个pod的详细流程，涉及的组件怎么通信的？

1）客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML；
2）api-server 处理用户请求，将 pod 信息存储至 etcd 中；
3）kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出；
4）选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中；
5）随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器；

51. 阐述Pod的终止过程 ？

1、用户向apiserver发送删除pod对象的命令；
2、apiserver中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead；
3、将pod标记为terminating状态；
4、kubectl在监控到pod对象为terminating状态了就会启动pod关闭过程；
5、endpoint控制器监控到pod对象的关闭行为时将其从所有匹配到此endpoint的server资源endpoint列表中删除；
6、如果当前pod对象定义了preStop钩子处理器，则在其被标记为terminating后会意同步的方式启动执行；
7、pod对象中的容器进程收到停止信息；
8、宽限期结束后，若pod中还存在运行的进程，那么pod对象会收到立即终止的信息；
9、kubelet请求apiserver将此pod资源的宽限期设置为0从而完成删除操作，此时pod对用户已不可见。

52. 如果Pod一致处于pending状态一般有哪些情况，怎么排查？

Pod一开始创建的时候，它本身就是会处于pending状态，这时可能是正在拉取镜像，正在创建容器的过程。
如果等了一会发现pod一直处于pending状态，
那么我们可以使用kubectl describe命令查看一下pod的Events详细信息。一般可能会有这么几种情况导致pod一直处于pending状态：
1、调度器调度失败。
Scheduer调度器无法为pod分配一个合适的node节点。
而这又会有很多种情况，比如，node节点处在cpu、内存压力，导致无节点可调度；pod定义了资源请求，没有node节点满足资源请求；node节点上有污点而pod没有定义容忍；pod中定义了亲和性或反亲和性而没有节点满足这些亲和性或反亲和性；以上是调度器调度失败的几种情况。
2、pvc、pv无法动态创建。
如果因为pvc或pv无法动态创建，那么pod也会一直处于pending状态，比如要使用StatefulSet 创建redis集群，因为粗心大意，定义的storageClassName名称写错了，那么会造成无法创建pvc，这种情况pod也会一直处于pending状态，或者，即使pvc是正常创建了，但是由于某些异常原因导致动态供应存储无法正常创建pv，那么这种情况pod也会一直处于pending状态。

53. 如果K8S删除一个Pod会发生什么事情？

Kube-apiserver会接受到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，
此时Pod的状态Terminating，kubelet看到pod标记为Terminating就开始了关闭Pod的工作;
关闭流程如下：
1）pod从service的endpoint列表中被移除；
2)如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；
3)进程被发送TERM信号（kill -14）;
4)当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）;

54. 简述K8S的Pod的共享哪些资源？

1）PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID；
2）网络命名空间：Pod 中的多个容器能够访问同一个IP和端口范围；
3）IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信；
4）UTS 命名空间：Pod 中的多个容器共享一个主机名；
5）Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes

55. 简述什么是Pod的初始化容器？

init container，初始化容器用于在启动应用容器之前完成应用容器所需要的前置条件
初始化容器本质上和应用容器是一样的，但是初始化容器是仅允许一次就结束的任务，初始化容器具有两大特征：
1、初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成；
2、初始化容器必须按照定义的顺序执行，当且仅当前一个初始化容器成功之后，后面的一个初始化容器才能运行；

56. 简述Pod的资源请求、限制如何定义？

pod的资源请求、资源限制可以直接在pod中定义
主要包括两块内容，
limits，限制pod能使用的最大cpu和内存，
requests，pod启动时申请的cpu和内存。
resources: #资源配额
limits: #限制最大资源，上限
cpu: 2 #CPU限制，单位是code数
memory: 2G #内存最大限制
requests: #请求资源（最小，下限）
cpu: 1 #CPU请求，单位是code数
memory: 500G #内存最小请求

57. 解释1个Node可以包含多少Pod ？

一个node有7个

58. Pod的定义中有个command和args参数，这两个参数不会和docker镜像的entrypointc冲突吗？

不会。
在pod中定义的command参数用于指定容器的启动命令列表，如果不指定，则默认使用Dockerfile打包时的启动命令，args参数用于容器的启动命令需要的参数列表；
特别说明：
kubernetes中的command、args其实是实现覆盖dockerfile中的ENTRYPOINT的功能的。
1、如果command和args均没有写，那么使用Dockerfile的配置；
2、如果command写了但args没写，那么Dockerfile默认的配置会被忽略，执行指定的command；
3、如果command没写但args写了，那么Dockerfile中的ENTRYPOINT的会被执行，使用当前args的参数；
4、如果command和args都写了，那么Dockerfile会被忽略，执行输入的command和args。

59. 简述Service是如何与Pod关联的？

通过标签选择器，每一个由deployment创建的pod都带有标签，这样，service就可以定义标签选择器来关联哪些pod是作为其后端了，就是这样，service就与pod管联在一起了

60. 简述什么是pause容器 ？

每个pod里运行着一个特殊的被称之为pause的容器，也称根容器，而其他容器则称为业务容器；
创建pause容器主要是为了为业务容器提供 Linux命名空间，共享基础：包括 pid、icp、net 等，以及启动 init 进程，并收割僵尸进程；
这些业务容器共享pause容器的网络命名空间和volume挂载卷，
当pod被创建时，pod首先会创建pause容器，从而把其他业务容器加入pause容器，从而让所有业务容器都在同一个命名空间中，这样可以就可以实现网络共享。
pod还可以共享存储，在pod级别引入数据卷volume，业务容器都可以挂载这个数据卷从而实现持久化存储

61. 简述Service的域名解析格式、Pod的域名解析格式 ？

service的DNS域名表示格式为…svc.，
servicename是service的名称，namespace是service所处的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local
pod的DNS域名格式为：…pod. ，
其中，pod-ip需要使用-将ip直接的点替换掉，namespace为pod所在的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local ，
演示如下：10-244-1-223.default.pod.cluster.local
对于deployment、daemonsets等创建的pod，还还可以通过…svc. 这样的域名访问。

62. 简述service的类型有哪几种 ？

service的类型一般有4中，分别是：
ClusterIP：表示service仅供集群内部使用，默认值就是ClusterIP类型
NodePort：表示service可以对外访问应用，会在每个节点上暴露一个端口，这样外部浏览器访问地址为：任意节点的IP：NodePort就能连上service了
LoadBalancer：表示service对外访问应用，这种类型的service是公有云环境下的service，此模式需要外部云厂商的支持，需要有一个公网IP地址
ExternalName：这种类型的service会把集群外部的服务引入集群内部，这样集群内直接访问service就可以间接的使用集群外部服务了
一般情况下，service都是ClusterIP类型的，通过ingress接入的外部流量。

63. 简述Pod与Service的通信方式 ？

1）k8s在创建服务时为服务分配一个虚拟IP，客户端通过该IP访问服务，服务则负责将请求转发到后端Pod上；
2）Service是通过kube-proxy服务进程实现，该进程在每个Node上均运行可以看作一个透明代理兼负载均衡器；
3）对每个TCP类型Service，kube-proxy都会在本地Node上建立一个SocketServer来负责接受请求，然后均匀发送到后端Pod默认采用Round Robin负载均衡算法；
4）Service的Cluster IP与NodePort等概念是kube-proxy通过Iptables的NAT转换实现，kube-proxy进程动态创建与Service相关的Iptables规则；
5）kube-proxy通过查询和监听API Server中Service与Endpoints的变化来实现其主要功能，包括为新创建的Service打开一个本地代理对象，接收请求针对针对发生变化的Service列表，kube-proxy会逐个处理；

64. 阐述应用Pod是如何发现Service或Pod里面的容器用于是如何连接Service的？

有两种方式，一种是通过环境变量，另一种是通过service的dns域名方式。
1、环境变量：
当pod被创建之后，k8s系统会自动为容器注入集群内有效的service名称和端口号等信息为环境变量的形式，
这样容器应用直接通过取环境变量值就能访问service了，
如curl http://${WEBAPP_SERVICE_HOST}:{WEBAPP_SERVICE_PORT}
2、DNS方式：
使用dns域名解析的前提是k8s集群内有DNS域名解析服务器，
默认k8s中会有一个CoreDNS作为k8s集群的默认DNS服务器提供域名解析服务器；
service的DNS域名表示格式为…svc.，
servicename是service的名称，namespace是service所处的命名空间，clusterdomain是k8s集群设置的域名后缀，一般默认为 cluster.local ，
这样容器应用直接通过service域名就能访问service了，
如wget http://svc-deployment-nginx.default.svc.cluster.local:80，
另外，service的port端口如果定义了名称，那么port也可以通过DNS进行解析，
格式为：.…svc.

65. 简述k8s集群内的应用如何访问外部的服务，如数据库服务，缓存服务等?

可以通过创建一个没有标签选择器的service来代理集群外部的服务。
1、创建service时不指定selector标签选择器，但需要指定service的port端口、端口的name、端口协议等，这样创建出来的service因为没有指定标签选择器就不会自动创建endpoint；
2、手动创建一个与service同名的endpoint，endpoint中定义外部服务的IP和端口，endpoint的名称一定要与service的名称一样，端口协议也要一样，端口的name也要与service的端口的name一样，不然endpoint不能与service进行关联。
完成以上两步，k8s会自动将service和同名的endpoint进行关联，
这样，k8s集群内的应用服务直接访问这个service就可以相当于访问外部的服务了

66. Pod的钩子函数有哪几种，作用是什么？

一、钩子函数简介
1.1 钩子函数简介
钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码
kubernetes在主容器的启动之后和停止之前提供了两个钩子函数
post start：容器创建之后执行，如果失败了会重启容器
pre stop：容器停止之前执行，执行完成之后容器将成功停止，再完成之前会阻塞删除容器的操作
1.2 钩子函数的方式
钩子处理器支持使用如下三种方式定义动作：
exec命令：在容器内执行一次命令
lifecycle:
postStart:
exec:
command:

• cat
• /var/lib/redis.conf
  tcpSocket: 在当前容器尝试访问指定的socket
  lifecycle:
  postStart:
  tcpSocket:
  port: 8000
  httpGet: 在当前容器中向某url发起http请求
  如下，为访问 http://192.168.2.150:80/users
  lifecycle:
  postStart:
  httpGet:
  path: /users
  port: 80
  host: 192.168.2.150
  scheme: HTTP #或者HTTPS
  以上三种方式第一种使用的比较多，其次是第三种，第二种使用的很少

二、钩子函数的使用
2.1 执行命令方式
编辑pod_hook_command.yaml文件，设置钩子函数，如下：

apiVersion: v1
kind: Namespace
metadata:
name: dev

---

apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: dev
labels:
user: redrose2100
spec:
containers:

• name: nginx
  image: nginx:1.17.1
  lifecycle:
  postStart:
  exec:
  command: [“/bin/sh”,“-c”,“echo ‘hello world…’ > /opt/demo.txt”]
  preStop:
  exec:
  command: [“/usr/sbin/nginx”,“-s”,“quit”]
  使用如下命令创建资源
  [root@master pod]#kubectl apply -f pod_hook_command.yaml
  namespace/dev created
  pod/nginx created
  [root@master pod]#
  这里可以登录容器中查看 /opt/demo.txt文件内容，如下表示已经成功写入

[root@master pod]#kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 26m
[root@master pod]#
[root@master pod]#
[root@master pod]#kubectl exec nginx -n dev -it -c nginx /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] – [COMMAND] instead.
#cat /opt/demo.txt
hello world…

使用如下命令删除资源
[root@master pod]#kubectl delete -f pod_hook_command.yaml
namespace “dev” deleted
pod “nginx” deleted
[root@master pod]#4
验证socket和http的方式与命令方式类似，使用最多的就是使用命令的方式，其次是http的方式，socket的方式使用的场景比较少

67. 简述网络各层负载均衡 ？

二层负载均衡：基于 MAC 地址的二层负载均衡。
三层负载均衡：基于 IP 地址的负载均衡。
四层负载均衡：基于 IP+端口 的负载均衡。
七层负载均衡：基于 URL 等应用层信息的负载均衡

68. Kubernetes中的负载均衡器有何理解?

负载平衡器是公开服务的最常见和标准的方法之一。根据工作环境有两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。
内部负载均衡器自动平衡负载并使用所需的配置分配pods，而外部负载均衡器将流量从外部负载定向到后端pods

69. 简述Kubernetes RC的机制?

Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。当定义了RC并提交至Kubernetes集群中之后，Master节点上的Controller Manager组件获悉，并同时巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，若存在过多的Pod副本在运行，系统会停止一些Pod，反之则自动创建一些Pod。我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等

70. 简述kube-proxy作用？

集群中每个Node上都会运行一个kube-proxy服务进程，他是Service的透明代理兼均衡负载器，其核心功能是将某个Service的访问转发到后端的多个Pod上。
kube-proxy通过监听集群状态变更，并对本机iptables做修改，从而实现网络路由。
而其中的负载均衡，也是通过iptables的特性实现的。
从V1.8版本开始，用IPVS（IP Virtual Server）模式，用于路由规则的配置，主要优势是：
1）为大型集群提供了更好的扩展性和性能。采用哈希表的数据结构，更高效；
2）支持更复杂的负载均衡算法；
3）支持服务器健康检查和连接重试；
4）可以动态修改ipset的集合；

71. 简述什么是无头service ？

无头service没有cluster ip，在定义service时将 service.spec.clusterIP：None，就表示创建的是无头service

72. 无头service和普通的service有什么区别 ？

无头service没有cluster ip，在定义service时将 service.spec.clusterIP：None，就表示创建的是无头service。
普通的service是用于为一组后端pod提供请求连接的负载均衡，让客户端能通过固定的service ip地址来访问pod，这类的pod是没有状态的，同时service还具有负载均衡和服务发现的功能。普通service跟我们平时使用的nginx反向代理很相识。
试想这样一种情况，有6个redis pod ,它们相互之间要通信并要组成一个redis集群，
不需要所谓的service负载均衡，这时无头service就是派上用场了，
无头service由于没有cluster ip，kube-proxy就不会处理它也就不会对它生成规则负载均衡，无头service直接绑定的是pod 的ip。无头service仍会有标签选择器，有标签选择器就会有endpoint资源。
无头service使用场景：
无头service一般用于有状态的应用场景，如Kaka集群、Redis集群等，这类pod之间需要相互通信相互组成集群，不在需要所谓的service负载均衡。

73. 简述kube-proxy iptables原理?

Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod；

74. 简述kube-proxy ipvs原理?

IPVS在Kubernetes1.11中升级为GA稳定版。
IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式；
在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。
iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配；
可以将ipset简单理解为一个IP（段）的集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少iptables规则的数量，从而减少性能损耗

75. 简述kube-proxy ipvs和iptables的异同?

iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：
iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。
与iptables相比，IPVS拥有以下明显优势：为大型集群提供了更好的可扩展性和性能；支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；支持服务器健康检查和连接重试等功能；可以动态修改ipset的集合，即使iptables的规则正在使用这个集合

76. 简述Kubernetes deployment升级过程?

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

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

78. 简述Kubernetes DaemonSet类型的资源特性?

DaemonSet资源对象会在每个Kubernetes集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。
因此，在定义yaml文件中，不支持定义replicas。
它的一般使用场景如下：在去做每个节点的日志收集工作。监控每个节点的的运行状态。

79. 简述Kubernetes自动扩容机制?

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

80. 简述Kubernetes Service分发后端的策略?

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