1、简述ETCD及其特点?

2、简述ETCD适应的场景?

7、简述Kubernetes如何实现集群管理?8、简述Kubernetes的优势、适应场景及其特点?

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

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

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

64、简述Kubernetes中，如何使用EFK实现日志的统一管理n

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

68、k8s是什么?请说出你的了解?

69、K8s架构的组成是什么?

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

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

71、如何控制滚动更新过程?

72、K8s中镜像的下载策略是什么?73、image的状态有哪些?

74、pod的重启策略是什么?

75、Service这种资源对象的作用是什么?

76、版本回滚相关的命令?

77、标签与标签选择器的作用是什么?

78、常用的标签分类有哪些?

79、有几种查看标签的方式?

80、添加、修改、删除标签的命令?

82、说说你对Job这种资源对象的了解?

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

84、创建一个pod的流程是什么?85、删除一个Pod会发生什么事情?

87、k8s是怎么进行服务注册的?

88、k8s集群外流量怎么访问Pod?

89、k8s数据持久化的方式有哪些?

93、在主机和容器上部署应用程序有什么区别?

106、能否介绍一下Kubernetes中主节点的工作情况?

108、你能简要介绍一下Kubernetes控制管理器吗?

112、什么是Ingress网络，它是如何工作的?

113、您对云控制器管理器有何了解?

117、使用Kubernetes时可以采取哪些最佳安全措施?

118、什么是集群联邦?

119、您如何看待公司从单—服务转向微服务并部署其服务容器?

120、考虑一家拥有分布式系统的跨国公司，拥有大量数据中心，虚拟机和许多从事各种任务的员工。您认为这样公司如何以与Kubernetes一致的方式管理所有任务?

121、考虑一种情况，即公司希望通过维持最低成本来提高其效率和技术运营速度。您认为公司将如何实现这一目标?

122、假设一家公司想要修改它的部署方法，并希望建立一个更具可扩展性和响应性的平台。您如何看待这家公司能够实现这一目标以满足客户需求?

123、考虑一家拥有非常分散的系统的跨国公司，期待解决整体代码库问题。您认为公司如何解决他们的问题?

124、我们所有人都知道，从单片到微服务的转变解决了开发方面的问题，但却增加了部署方面的问题。公司如何解决部署方面的问题?

125、公司如何有效地实现这种资源分配?

126、您认为公司如何处理服务器及其安装?

127、考虑一种情况，公司希望向具有各种环境的客户提供所有必需的分发。您认为他们如何以动态的方式实现这一关键目标?

128、假设公司希望在不同的云基础架构上运行各种工作负载，从裸机到公共云。公司将如何在不同界面的存在下实现这一目标?

Kubernes 是为运行分布式集群而建立的，分布式系统的本质使得网络成为 Kubernetes 的核心和必要组成部分，了解 Kubernetes 网络模型可以使你能够正确运行、和排查应用程序故障。

网络是非常复杂的，拥有许多概念，对于不熟悉这个领域的来说，这可能会有一定的难度，这里面有很多概念需要理解，并且还需要把这些概念整合起来形成一个连贯的整体，比如网络命名空间、虚拟、IP 转发、NAT 等概念。

Kubernetes 中对任何网络实现都规定了以下的一些要求：

• 所有 Pod 都可以在不使用 NAT 的情况下与所有其他 Pod 进行通信
• 所有节点都可以在没有 NAT 的情况下与所有 Pod 进行通信

鉴于这些限制，我们需要解决几个不同的网络问题：

接下来我们将来讨论这些问题及其解决方案。

通常情况下我们将虚拟机中的网络通信视为直接与设备进行交互，如图1所示。

在 EC2 中，每个实例都绑定到一个弹性网络接口 (ENI)，并且所有 ENI 都连接在一个 VPC 内 —— ENI 无需额外操作即可相互访问。默认情况下，每个 EC2 实例部署一个 ENI，但你可以创建多个 ENI 并将它们部署到 EC2 实例上。Kubernetes 的 AWS CNI 插件会为节点上的每个 Pod 创建一个新的 ENI，因为 VPC 中的 ENI 已经连接到了现有 AWS 基础设施中，这使得每个 Pod 的 IP 地址可以在 VPC 内自然寻址。当 CNI 插件被部署到集群时，每个节点（EC2 实例）都会创建多个弹性网络接口，并为这些实例分配 IP 地址，从而为每个节点形成了一个 CIDR 块。当部署 Pod 时，有一个小的二进制文件会作为 DaemonSet 部署到 Kubernetes 集群中，从节点本地的 kubelet 进程接收任何添加 Pod 到网络的请求，这个二进制文件会从节点的可用 ENI 池中挑选一个可用的 IP 地址，并通过在 Linux 内核中连接虚拟网络设备和网桥将其分配给 Pod，和在同一节点内容的 Pod 通信一样，有了这个，Pod 的流量就可以跨集群内的节点进行通信了。

上面我们已经介绍了如何在 Pod 和它们相关的 IP 地址之间的通信。但是 Pod 的 IP 地址并不是固定不变的，会随着应用的扩缩容、应用崩溃或节点重启而出现或消失，这些都可能导致 Pod IP 地址发生变化，Kubernetes 中可以通过 Service 对象来解决这个问题。

创建 Service 时候，会创建一个新的虚拟 IP（也称为 clusterIP），这集群中的任何地方，发往虚拟 IP 的流量都将负载均衡到与 Service 关联的一组 Pod。实际上，Kubernetes 会自动创建并维护一个分布式集群内的负载均衡器，将流量分配到 Service 相关联的健康 Pod 上。接下来让我们仔细看看它是如何工作的。

为了在集群中执行负载均衡，Kubernetes 会依赖于 Linux 内置的网络框架 - netfilter。Netfilter 是 Linux 提供的一个框架，它允许以自定义处理程序的形式实现各种与网络相关的操作，Netfilter 为数据包过滤、网络地址转换和端口转换提供了各种功能和操作，它们提供了引导数据包通过网络所需的功能，以及提供禁止数据包到达网络中敏感位置的能力。

VIP 更改为所选的 Pod IP。当 Pod 启动或关闭时，iptables 规则集也会更新以反映集群的变化状态。换句话说，iptables 已经在节点上做了负载均衡，以将指向 Service VIP 的流量路由到实际的 Pod 的 IP 上。

Kubernetes 新版本已经提供了另外一个用于集群负载均衡的选项：IPVS， IPVS 也是构建在 netfilter 之上的，并作为 Linux 内核的一部分实现了传输层的负载均衡。IPVS 被合并到了 LVS（Linux 虚拟服务器）中，它在主机上运行并充当真实服务器集群前面的负载均衡器，IPVS 可以将基于 TCP 和 UDP 的服务请求定向到真实服务器，并使真实服务器的服务作为虚拟服务出现在一个 IP 地址上。这使得 IPVS 非常适合 Kubernetes 服务。

这部署 kube-proxy 时，可以指定使用 iptables 或 IPVS 来实现集群内的负载均衡。IPVS 专为负载均衡而设计，并使用更高效的数据结构（哈希表），与 iptables 相比允许更大的规模。在使用 IPVS 模式的 Service 时，会发生三件事：在 Node 节点上创建一个虚拟 IPVS 接口，将 Service 的 VIP 地址绑定到虚拟

当这 Pod 和 Service 之间路由一个数据包时，流量和以前开始的方式一样，数据包首先通过连接到 Pod 的网络命名空间（1）的 eth0 离开 Pod，。然后它通过虚拟网络设备到达网桥（2）。网桥上运行的 ARP 是不知道 Service 地址的，所以它通过默认路由 eth0（3）将数据包传输出去。到这里会有一些不同的地方了，在 eth0 接收之前，该数据包会被 iptables 过滤，在收到数据包后，iptables 使用 kube-proxy 在节点上安装的规则来响应 Service 或 Pod 直接从节点上完成了集群内的负载均衡，然后流量流向 Pod，剩下的就和前面的 Pod 到 Pod 通信一样的了（5）。

相应的回包的时候，收到该数据包的 Pod 将响应，将源 IP 为自己的 IP，将目标 IP 标记为最初发送数据包的 Pod(1)。进入节点后，数据包流经 iptables，它使用 conntrack 记住它之前所做的选择，并将数据包的源重写为 Service 的 VIP 而不是现在 Pod 的 IP(2)。从这里开始，数据包通过网桥流向与 Pod 的命名空间配对的虚拟网络设备 (3)，然后流向我们之前看到的 Pod 的虚拟网络设备 (4)。

到这里我们已经了解了 Kubernetes 集群内的流量是如何路由的，但是更多的时候我们需要将服务暴露到外部去。这个时候会涉及到两个主要的问题：

• 将流量从 Kubernetes 服务路由到互联网上去
• 将流量从互联网传到你的 Kubernetes 服务

接下来我们就来讨论这些问题。

从节点到公共 Internet 的路由流量也是和特定的网络有关系的，这取决于你的网络如何配置来发布流量的。这里我们以 AWS VPC 为例来进行说明。

在 AWS 中，Kubernetes 集群在 VPC 中运行，每个节点都分配有一个私有 IP 地址，该地址可从 Kubernetes 集群内访问。要从集群外部访问服务，你可以在 VPC 上附加一个外网网关。外网网关有两个用途：在你的 VPC 路由表中为可路由到外网的流量提供目标，以及为已分配公共 IP 地址的实例执行网络地址转换 (NAT)。NAT 转换负责将集群节点的内部 IP 地址更改为公网中可用的外部 IP 地址。

有了外网网关，VM 就可以自由地将流量路由到外网。不过有一个小问题，Pod 有自己的 IP 地址，与运行 Pod 的节点 IP 地址不同，并且外网网关的 NAT 转换仅适用于 VM IP 地址，因为它不知道哪些 Pod 在哪些 VM 上运行 —— 网关不支持容器。让我们看看 Kubernetes 是如何使用 iptables 来解决这个问题的。

在下图中，数据包源自 Pod 的命名空间 (1)，并经过连接到根命名空间 (2) 的 veth 对。一旦进入根命名空间，数据包就会从网桥移动到默认设备，因为数据包上的 IP 与连接到网桥的任何网段都不匹配。在到达根命名空间的网络设备 (3) 之前，iptables 会破坏数据包 (3)。在这种情况下，数据包的源 IP 地址是 Pod，如果我们将源保留为 Pod，外网网关将拒绝它，因为网关 NAT 只了解连接到 VM 的 IP 地址。解决方案是让 iptables 执行源 NAT —— 更改数据包源，使数据包看起来来自 VM 而不是 Pod。有了正确的源 IP，数据包现在可以离开 VM (4) 并到达外网网关 (5) 了。外网网关将执行另一个 NAT，将源 IP 从 VM 内部 IP 重写为公网IP。最后，数据包将到达互联网上 (6)。在返回的路上，数据包遵循相同的路径，并且任何源 IP 的修改都会被取消，这样系统的每一层都会接收到它理解的 IP 地址：节点或 VM 级别的 VM 内部，以及 Pod 内的 Pod IP命名空间。

图10.从Pod到互联网通信

让流量进入你的集群是一个非常难以解决的问题。同样这也和特定的网络环境有关系，但是一般来说入流量可以分为两种解决方案：

当你创建一个 Kubernetes Service时，你可以选择指定一个 LoadBalancer 来使用它。LoadBalancer 有为你提供服务的云供应商负责创建负载均衡器，创建服务后，它将暴露负载均衡器的 IP 地址。终端用户可以直接通过该 IP 地址与你的服务进行通信。

在部署了 Service 后，你使用的云提供商将会为你创建一个新的 LoadBalancer（1）。因为 LoadBalancer 不支持容器，所以一旦流量到达 LoadBalancer，它就会分布在集群的各个节点上（2）。每个节点上的 iptables 规则会将来自 LoadBalancer 的传入流量路由到正确的 Pod 上（3）。从 Pod 到客户端的响应将返回

下图展示的就是托管 Pod 的三个节点前面的负载均衡器。传入流量（1）指向 Service 的 LoadBalancer，一旦 LoadBalancer 接收到数据包（2），它就会随机选择一个节点。我们这里的示例中，我们选择了没有运行 Pod 的节点 VM2（3）。在这里，运行在节点上的 iptables 规则将使用 kube-proxy 安装到集群中的内部负载均衡规则，将数据包转发到正确的 Pod。iptables 执行正确的 NAT 并将数据包转发到正确的 Pod（4）。

Service，也就是说，任何指向节点端口的流量都将使用 iptables 规则转发到 Service。

将节点的端口暴露在外网，可以使用一个 Ingress 对象，Ingress 是一个更高级别的 HTTP 负载均衡器，它将 HTTP 请求映射到 Kubernetes Service。根据控制器的实现方式，Ingress 的使用方式会有所不同。HTTP 负载均衡器，和四层网络负载均衡器一样，只了解节点 IP（而不是 Pod IP），因此流量路由同样利用由 kube-proxy 安装在每个节点上的 iptables 规则提供的内部负载均衡。

资源中指定的每个路径创建 TargetGroup 规则。这可以保证到特定路径的流量被路由到正确的 Kubernetes 服务上 (5)。

流经 Ingress 的数据包的生命周期与 LoadBalancer 的生命周期非常相似。主要区别在于 Ingress 知道 URL 的路径（可以根据路径将流量路由到 Service）Ingress 和节点之间的初始连接是通过节点上为每个服务暴露的端口。

部署 Service 后，你使用的云提供商将为你创建一个新的 Ingress 负载均衡器 (1)。因为负载均衡器不支持容器，一旦流量到达负载均衡器，它就会通过为你的服务端口分布在组成集群 (2) 的整个节点中。每个节点上的 iptables 规则会将来自负载均衡器的传入流量路由到正确的 Pod (3)。Pod 到客户端的响应将返回 Pod 的 IP，但客户端需要有负载均衡器的 IP 地址。正如我们之前看到的，iptables 和 conntrack 用于在返回路径上正确重写 IP。

本文介绍了 Kubernetes 网络模型以及如何实现常见网络任务。网络知识点既广泛又很深，所以我们这里不可能涵盖所有的内容，但是你可以以本文为起点，然后去深入了解你感兴趣的主题。