k8s笔记

1 简述etcd及其特点

ETCD是高可用分布式的键值存储系统

特点

1）强一致性：即使部分节点故障，etcd仍能正常工作，并保持数据一致
（强一致性：分布式系统中，更新操作，所有节点读取的数据都是最新的，一致的）
2）高可用：etcd支持数据多副本复制，一个节点挂，其他节点接替工作
3）快速响应：它使用内存存储，可快速读写，支持异步复制数据到其他节点
4）简单易用：提供了http api,用http来更新和读取数据，还提供了客户端和命令行
5）功能丰富：除了基本的键值存储，etcd还提供了事务支持（在一个事务中要不全部成功执行，要不全部失败回滚）
和触发器机制（即满足一些条件，触发相应操作）

2 简述etcd适应的场景

1）多个节点的数据一致性
2）服务发现和负载均衡：服务注册到etcd, 通过查询etcd获取服务们的地址和状态。
3）分布式锁和并发控制（两者都是说的解决多个并发数据不一致的问题）
（原子操作：要么执行成功，要不失败，不存在部分执行）
（分布式锁：多个节点同时访问某个资源，只有一个节点可以获取到锁并执行操作，避免多节点同时修改资源）
4）etcd可以作为一个集中的配置存储，应用可以订阅它的信息，获取最新的配置信息，更新自身配置。
5）任务信息写入到etcd的有序集合中，消费者按顺序领取任务处理，实现分布式任务的调度和执行

3 简述什么是Kubernetes?

开源的容器编排工具，用于
1）自动化容器部署：比如要部署web应用到集群，可以通过定义一个deployment来描述部署规范，比如容器image,副本数量和资源限制，那么k8s会根据这个部署规范自动创建和管理一组pod。

2）扩展：就是deployment里修改了副本数量，k8s能自动增加副本数量和减少副本数量。
3）管理：容器管理是指k8s会自动重启异常退出的容器，还提供了日志收集和查看功能
4）回滚到以前的版本
5）在 Kubernetes 中，把 Pod 的副本设置为 2 可以起到以下效果：

1. 高可用性：如果一个 Pod 出现故障或停止运行，另一个 Pod 可以立即接管并继续提供服务，从而提高了应用程序的可用性和可靠性。
2. 可伸缩性：通过增加 Pod 的副本数量，可以根据需求增加应用程序的处理能力，从而提高了应用程序的可伸缩性。
3. 负载均衡：Kubernetes 会自动将流量分配到多个 Pod 副本上，从而实现负载均衡，提高了应用程序的性能和可靠性。
4. 容错性：如果一个 Pod 出现故障或停止运行，另一个 Pod 可以立即接管并继续提供服务，从而提高了应用程序的容错性。

需要注意的是，增加 Pod 的副本数量也会增加资源的使用，因此需要根据实际情况和需求来设置合适的副本数量，以平衡可用性、可伸缩性和资源使用之间的关系。

4 简述Kubernetes和Docker的关系?

docker提供了创建和运行容器的基本技术，可以通过docker compose对多个容器进行编排
k8s对这些容器进行编排、管理

5 简述Kubernetes中什么是Minikube、Kubectl、Kubelet?

1）minikube允许在本地运行的k8s,主要用于实验测试开发用
2）kubectl是一个命令行工具，用于和集群交互
3）kubeclet 是一个守护进程，运行在每个节点上，负责确保节点上容器健康运行

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

1）本地部署：minikube
2）手动部署：kubeadm 需要手动配置网络、存储等资源
3）kubesphere
4）Racher部署过k3s

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

实现集群管理涉及到多个组件
1）控制平面（Control Plane）
它是大脑，由多个组件组成，如API server、etcd、控制器管理器和调度器
2) API 服务器–kubectl 通过API服务器与集群交互
3）控制器管理器–如果一个节点失败，ReplicaSet控制器会在其他节点上创建新的pod，以确保实际pod数量和期望的一致
4）创建了一个新的pod，调度器决定将其放在哪个节点上运行
5）服务网络：Service是一个抽象，代表了一组提供相同功能的pod，可以为他们提供负载均衡和服务发现
6）通过pvc和pv提供持久化存储，这允许pod重启或者失败时得以保留
7）网络策略定义了如何控制pod之间以及pod与外界的网络访问
8） RBAC代表 Role-Based Access Control，即基于角色的访问控制，定义了谁可以对k8s API资源执行哪些操作。

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

1）其他优势上面已经囊括了
2）它支持应用的滚动更新，可以回滚到之前的版本。

适应场景

1）k8s 适合部署、管理和扩展微服务应用
2）k8s支持大数据如Spark、Flink
3）CI/CD: 与 Jenkins、GitLab 等 CI/CD 工具整合，实现自动化的代码部署和更新
4）支持在云端部署
5）在边缘设备部署

特点

1）自我修复
2）容器分组，pod为基本单位
3）丰富的生态系统：支持各种应用、数据卷、网络解决方案

9、简述Kubernetes的缺点或当前的不足之处?

1）k8s依赖于外部存储，如Ceph或ClusterFS，这增加了配置和维护的复杂性
2）运行大集群需要昂贵的硬件资源，以及相关的人员和培训成本
3）日志和监控如果要获得一个统一和全面的视图需要额外的努力

10、简述Kubernetes相关基础概念?

pod deployment service
Namespace:每个ns都有自己的pod、Service、Deployment等资源
Node Cluser:包括master 和 node

11、简述Kubernetes集群相关组件?

控制面组件

1）kube-apiserver
2) etcd
3) kube-scheduler: 控制pod调度到哪个节点
4) kube-controller-manager: 运行控制器进程（deployment, StatefulSet, DaemonSet…）
5）cloud-controller-manager是转为云服务提供商交互而设计的控制器。

节点组件

1）kubelet
2）kube-proxy 运行在每个节点上，将来自集群内部或外部的请求转发给相应的Pod 或 Service
3）Container runtime : 负责运行容器（容器运行时有：Docker、containerd、CRI-O）

容器运行时

主要职责：
1）pull image
2）解压镜像：将下载的容器镜像解压到文件系统中
3）运行容器：初始化并运行容器中的应用程序
4）隔离容器：确保容器在隔离的环境中运行，包括网络、文件系统和其他资源
5）监控容器
6）暂停、停止和删除容器
docker包含了容器的整个生命周期管理，后来为了模块化和标准化，Docker将核心容器运行时分离出来，创建了containerd,这意味着，当你使用Docker运行容器时，实际上是docker调用containerd来执行的。

12、简述Kubernetes RC的机制?

RC是 ReplicationController，用于确保指定数量的pod副本数在运行。已被ReplicaSet代替，RS支持滚动更新

13、简述kube-proxy作用?

假设有一个Kubernetes集群中部署了多个Pod，这些Pod提供了相同的服务，并且通过Service暴露给外部访问。kube-proxy就起到了负责将来自外部的请求流量转发到正确的Pod上的作用。

14、简述kube-proxy iptables原理?

1）当service创建时，kube-proxy会为其创建iptables规则以实现负载均衡
2）对于每一个service，kube-proxy都会在nat 表中创建规则来捕获 该 Service IP 的流量，并将其重定向到一个Pod.
3）使用 iptables 进行负载均衡的方式是选一个pod并修改目的 IP 地址，使其指向该 Pod 的 IP地址
iptable模式在处理大量服务和流量时会遇到性能瓶颈，因为每个新的网络连接都要遍历一个长规则链

当我们谈论iptables模式下处理大量服务和流量时遇到的性能瓶颈，提到的“长规则链”实际上是指iptables在处理网络流量时所依据的一系列规则。

要理解这个概念，我们可以将iptables想象成一个邮局，而网络流量（如数据包）就像是邮局收到的信件。每个信件（数据包）到达时，邮局（iptables）需要根据一本规则手册（规则链）来决定如何处理这些信件。这本手册包含了很多不同的规则，比如有的规则指定某些信件要送到特定地方，有的规则则决定哪些信件不应该被送出。

在iptables的情况下，这些规则是网络管理员设置的，用于控制和管理网络流量。例如，有些规则用来阻止不安全的流量，有些则用来确保只有特定类型的流量可以进入网络。

当网络流量量很大时，每个新的网络连接（就像一封新来的信件）都需要被检查并与这些规则进行对比，以确定它应该如何被处理。如果规则链很长，即有很多规则需要检查，那么这个过程就会变得缓慢，因为每个数据包都需要依次与这些规则进行比较。这就好比邮局工作人员必须每次都从头到尾翻阅整本厚厚的规则手册来处理每一封信件，效率自然会大大降低。

因此，在处理大量服务和流量时，iptables的这种方式可能会成为性能的瓶颈。这也是为什么在高流量的网络环境中，人们可能会寻找更高效的流量管理方案，比如使用更现代的系统如nftables或硬件级别的解决方案。

15、简述kube-proxy ipvs原理?

1）IPVS是一个基于内核的负载均衡器，用于将来自客户端的请求转发到多个后端服务器上。它通过操作内核网络协议栈中的连接追踪表和路由表来实现请求的转发。
2）ipvs提供了多种负载均衡的算法，如轮询、加权轮询（就是权重如果是3：2：1，那么轮询的时候比例也是3:2:1）等，它使用哈希表来存储规则，因此查询速度快，在大量服务和流量下也表现出色
3）当访问一个service的时候，去这个哈希表里找应该去哪个pod，其中有多种方式找pod，比如：哪家商店人最少（最少连接法）、根据你以前的喜好（会话亲和性）；如果有新的商店开业或者旧的关闭，都会更新哈希表
4）ipset就是将几个IP分成不同的集合，然后有集合名，这样查找IP的时候更快
IPSET是一个用户空间工具，用于创建和管理 IP 地址集合。它提供了一种高效的方法来组织和操作大量的 IP 地址，例如黑名单、白名单、IP 地址过滤等。IPSET可以与防火墙软件（如iptables）结合使用，实现对特定 IP 地址或地址范围的过滤和控制访问。
在IPVS中配置转发规则时，可以使用IPSET来定义需要过滤的源地址或目标地址范围。

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

iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，使用更高效的数据结构（hash表），几乎允许无限规模扩张
与 iptables 相比，IPVS可以为大型集群提供了更好的扩展性和性能；支持更复杂的负载均衡算法；可以动态修改ipset中的集合；支持服务器健康检查和连接重试等功能

在 IPVS 中，哈希表可能用于快速查找和管理大量的网络连接或规则，从而提高处理效率。
示例说明：
假设你有一个负载均衡器，需要决定将进入的网络请求分发给哪个服务器。使用哈希表，每个请求基于其属性（如 IP 地址或会话 ID）通过哈希函数生成一个哈希值。这个哈希值决定了请求应该分配给哪个服务器。由于哈希表的查找速度非常快，即使在处理成千上万个请求时，也能保持高效的性能。

17、简述Kubernetes中什么是静态Pod?

静态pod由 kubelet创建，并且总是在kubelet 所在的Node上运行，即使API服务器不可用，或者kubelet无法与其通信，静态pod 仍可以运行。与动态Pod相比，静态Pod不受调度器的控制，也没有与之关联的ReplicaSet、Deployment或其他高级控制器。

静态Pod通常用于一些特殊场景或需求，以下是一些使用静态Pod的情况：

1. 集群引导：在集群启动时，可以使用静态Pod来引导初始化一些基础服务或核心组件，例如kubelet、kube-proxy等。这样可以确保这些关键组件能够在集群启动时可靠地运行。

2. 节点特定的任务：某些任务可能需要运行在特定的节点上，例如节点监控代理、日志收集器等。使用静态Pod可以将这些任务分配到指定的节点上，并确保它们始终在该节点上运行。

3. 在故障转移和备份场景中：静态Pod可以用于在节点故障或主节点失效时，自动启动备份节点上的关键组件或服务。这样可以快速恢复关键功能，提高集群的可用性。

需要注意的是，由于静态Pod不受调度器的管理，因此它们需要手动创建并在对应节点上配置。这与动态Pod由控制器（如Deployment、StatefulSet等）自动管理的方式有所不同。静态Pod适用于一些特定的场景和需求，但在大多数情况下，使用动态Pod会更加灵活和可扩展。

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

1）Pending: 可能是没有合适的节点供调度
2）running
3）Succeeded: 一般是Job执行完成后的状态
4）Failed: Pod 中的所有容器都终止，但至少有一个是因为故障终止的。
5）Unknown： 无法确定Pod的状态，通常是因为与pod所在节点的通信有问题

19、简述Kubernetes创建一个Pod的主要流程?

1）kubectl create -f xxx.yml
2）API服务器接收到pod的定义，验证格式内容是否正确，然后pod定义存储在etcd
3）调度器决定将pod 调度到哪个节点
4）决定了，目标节点上的kubelet 就会被通知，kubelet就从镜像仓库 pull image
5）kubelet 使用容器运行时创建和启动 pod 中定义的每个容器
6）kubelet 开始执行pod 中定义的健康检查，如果某个容器不正常，kubelet 将会根据pod 的 restart policy重启它
7）为了使pod 能与其他pod 和外部通信，k8s 网络插件会配置网络，确保每个pod都有唯一的IP 地址，并且设置适当的路由规则。
8）kubelet 会定期上报给 API server pod的状态
9）如果pod 需要持久化存储，kubelet还会处理PV的挂载

20、简述Kubernetes中Pod的重启策略?

1）Always(总是重启)
2）OnFailure(失败时重启)：如果容器正常退出（状态码为0），k8s将不会自动重启它，适用于一次性任务
3）Never(从不重启)：如果选择了这个策略，需要手动干预来重新启动Pod中的容器。

21、简述Kubernetes中Pod的健康检查方式?

1）Liveness Probe(存活探针)：判断容器是否运行
2）Readiness Probe(就绪探针)：容器是否准备好接收流量，未就绪，将不会接收来自Service的流量
3）Startup Probe(启动探针)：容器是否启动

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

这三种检查方式适用于所有探针
1）HTTP探针：使用Http Get 来检查容器是否正常运行，状态码返回200，说明容器健康
2）TCP 探针：指定IP：Port，成功建立连接，说明容器健康
3）Exec 探针：通过容器内执行命令来检查容器健康与否，返回0，说明容器健康

23、简述Kubernetes Pod的常见调度方式?

1）均匀分布：k8s 默认调度策略时均匀地将Pod 分配到可用的节点上，负载在集群中均匀分布
2）节点亲和性：将pod 调度到指定节点上
3）资源限制：为 Pod 设置资源限制来控制pod 调度到哪个节点
4）pod间亲和性与反亲和性
5）节点选择器：将pod 调度到具体的节点上

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

1）是一种特殊的容器，在pod 常规容器之前运行，目的是为 pod 中的应用容器设置前置条件或配置工作
2）初始化容器会按顺序依次运行

25、简述Kubernetes deployment升级过程?

创建新的pod 版本，更新deployment 的配置，指定新的pod 版本，deployment的配置被更新，k8s会自动触发升级过程。新版 pod会逐步替换旧版本的pod。

26、简述Kubernetes deployment升级策略?

1）滚动更新 Rolling Update：这是默认策略。
该策略允许指定参数 maxUnavailable: 更新过程，允许最大不可用 Pod 数量或百分比
maxSurge: 在更新过程中，可以超出所需 Pod 数量的最大额外 Pod数量或百分比
2）Recreate 重新创建：删除旧的，启动新的

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

在每个节点只运行一个pod, 一般在每个节点做日志收集，监控每个节点的运行状态

28、简述Kubernetes自动扩容机制?

k8s 使用 HPA 控制器 基于CPU使用率 进行pod自动扩缩容功能 （Horizontal 水平的 Pod Autoscaler）
HPA 监测 pod 的资源使用情况，与 HPA中的条件比对， 在满足条件时调整 pod 的副本数

29、简述Kubernetes Service类型?

1）ClusterIP: 默认的service 类型。给service在集群内部创建了一个IP 地址，允许其他pod和 service 进行访问，外部无法访问
2）NodePort: 在每个节点上绑定一个端口，可以通过任何IP 和 NodePort 端口号来访问服务
3）LoadBalancer: 使用云服务商的负载均衡器来公开service
4）ExternalName: external-db.example.com是我们要访问的外部数据库 DNS 名称，这样在集群内部，pod或 service 可以使用 my-db-service 来访问外部数据库

apiVersion: v1
kind: Service
metadata:
  name: my-db-service
spec:
  type: ExternalName
  externalName: external-db.example.com

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

1）RoundRobin: 默认的轮询模式，即轮询发请求转到后端的各个pod上
2）SessionAffinity: 之前某个客户端发起的请求转发到后端的某个pod，以后还发给这个pod

31、简述Kubernetes Headless Service?

跳过 service的负载均衡，不通过Service 的 ClusterIP，直接通过 Pod 的 IP地址访问它们，这就是 headless service 的用武之地
clusterIP: None,这使得服务成为 headless。

当然，让我为您提供一些结合实际项目的例子来说明Headless Service在Kubernetes中的应用场景：

1. 分布式数据库部署

• 项目: 部署一个分布式数据库，如Cassandra或MongoDB。
• 使用Headless Service: 在这类数据库中，每个节点（Pod）需要与其他节点通信进行数据复制和同步。使用Headless Service，每个数据库Pod可以拥有一个稳定的网络标识，使得它们可以相互发现和通信，而不依赖于中央负载均衡器。

2. 微服务架构中的服务发现

• 项目: 一个基于微服务的应用，包含多个小服务，如订单处理、库存管理等。
• 使用Headless Service: 在这种架构中，每个服务可能需要直接与其他服务通信。使用Headless Service可以使得服务发现过程更加直接和高效，每个服务可以直接获取其他服务Pod的地址信息，而不是通过一个共用的入口。

3. 状态保持应用的稳定性

• 项目: 部署一个需要状态保持的应用，如Redis集群。
• 使用Headless Service: 对于Redis这样的内存数据存储，节点间的稳定通信非常重要。使用Headless Service可以确保每个Redis Pod都能被稳定地识别和访问，这对于数据的一致性和高可用性至关重要。

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

1）Pod采用 hostPort方式，将Pod端口号映射到宿主机
2）Service 采用 nodePort方式，将端口映射到宿主机
3）通过设置 LoadBalancer 映射到云服务商提供的 LoadBalancer 地址

33、简述Kubernetes ingress?

1）例子：当访问 example.com/service-a 时，请求会被路由到 service-a的后端服务，端口为80，
访问example.com/service-b 时，请求会被路由到 service-b的后端服务，端口为81，这就是Ingress的作用
2）为了使用 Ingress，需要配置 Ingress 控制器，比如 Nginx Ingress Controller, Traefik, Istio等
3）Ingress Controller 基于 Ingress 规则（就是那个yaml）将客户端请求直接转发到 Service 对应的后端 Endpoint(Pod)上，此时 kube-prox