简单说一下k8s集群内外网络如何互通的
要在 Kubernetes（k8s）集群内外建立网络互通，可以采取以下措施：
使用service： 使用Service类型为NodePort或LoadBalancer的Kubernetes服务。这可以使服务具有一个公共IP地址或端口，以便在集群内或外部访问该服务。
使用Ingress: 配置Kubernetes Ingress资源。Ingress是一种路由机制，它将外部流量路由到Kubernetes集群中的特定服务。可以使用Ingress控制器来实现负载均衡和SSL终止。
创建网络策略 : Kubernetes网络策略允许您定义哪些Pod可以与哪些其他Pod通信，以及在什么端口上进行通信。
使用DNS： 将集群内的服务和Pod绑定到一个公共IP地址或域名。可以使用DNS记录来实现这一点，例如在Kubernetes中使用外部DNS插件。
配置网络代理 : 网络代理是一种可选的解决方案，它可以帮助在Kubernetes集群内外之间建立网络互通。可以使用Ingress控制器或使用第三方代理解决方案，如NGINX或HAProxy。
描述下Pod的创建过程
描述一：
定义Pod：首先，需要定义一个Pod的配置文件，它描述了要创建的Pod的特征，例如Pod名称、容器映像、容器端口等。
描述二：
Pod 的创建流程 kubectl向API Server发送创建请求ReplicaSet，API Server请求存储在etcd Controller Manager接受到通知
Controller Manager通知到
Scheduler Scheduler通知Worker节点
API Server通知到Worker节点的kubelet
kubelet指示当前节点上的Container Runtime运行对应的容器
Container Runtime下载镜像并启动容器
k8s中Pod的终止过程
在 Kubernetes 中，一个 Pod 由一个或多个容器组成，因此 Pod 的终止过程实际上涉及到容器的终止以及 Pod 对应的资源的释放等多个方面。
当 Kubernetes 接收到一个 Pod 的终止请求时，它将执行以下步骤：
从 Service 中删除 Pod：如果 Pod 正在 Service 中被使用，Kubernetes 会将其从 Service 中删除，以确保不再将流量发送到该 Pod。
关闭容器：Kubernetes 向 Pod 中的每个容器发送一个终止请求，容器将开始执行关闭的预定义步骤。这些步骤包括停止正在运行的进程、关闭网络连接、清理文件系统等等。
发送 SIGTERM 信号：当 Kubernetes 接收到终止 Pod 的请求时，它将首先向容器发送 SIGTERM 信号，让容器开始优雅地终止。这个信号的作用是告诉容器它需要开始终止了，但是需要等待一定的时间来完成正在运行的任务和释放资源。
等待容器终止：Kubernetes 将等待容器在接收到 SIGTERM 信号后完成优雅终止。在这个等待期间，Kubernetes 将不再向 Pod 中发送新的请求，但它仍会监控 Pod 的状态。
发送 SIGKILL 信号：如果容器没有在一定的时间内完成优雅终止，Kubernetes 将发送 SIGKILL 信号给容器，强制终止容器并释放其资源。
清理资源：Kubernetes 将释放 Pod 使用的所有资源，包括节点上的网络、存储、内存等。同时，Kubernetes 还将更新其状态，以便管理员和其他应用程序可以获取到最新的 Pod 信息。
Kubernetes Pod 的终止过程包括了多个步骤，以确保容器能够安全、快速地释放资源，同时不会丢失任何数据或产生其他的副作用。
k8s中的自动伸缩有哪些方式
kubernetes中的自动伸缩主要有以下几种方式：
水平自动伸缩（Horizontal Pod Autoscaler，HPA）：根据 CPU 利用率、内存利用率等指标，动态地增加或减少 Pod 的数量，以满足应用的负载需求。HPA 是 Kubernetes 中最常用的自动伸缩方式之一。
垂直自动伸缩（Vertical Pod Autoscaler，VPA）：根据容器内部资源使用情况，动态地调整容器的 CPU 和内存资源请求量。VPA 可以优化容器的资源利用率，提高应用的性能和可靠性。
集群自动伸缩（Cluster Autoscaler）：根据集群节点的资源利用率，动态地增加或减少节点的数量，以适应不同的负载需求。集群自动伸缩可以自动扩容或缩容集群，确保应用的高可用性和可靠性。
自定义指标自动伸缩（Custom Metrics Autoscaler，CA）：根据自定义指标，动态地增加或减少 Pod 的数量。CA 可以根据应用的特殊需求，灵活地定制自动伸缩策略，提高应用的性能和可靠性。
总的来说，Kubernetes 提供了多种自动伸缩方式，可以根据应用的特点和需求选择合适的自动伸缩方式，以提高应用的性能、可靠性和可扩展性。
无论使用哪种自动伸缩方法，Kubernetes 都会根据应用程序的需求自动调整 Pod 的数量和资源限制，以确保应用程序始终具有足够的资源，并且可以根据需要扩展或缩减。
k8s中的故障检测有哪些方式
readiness（就绪状态）
liveness(存活性)
startup（启动时）
Kubernetes 中的故障检测方式包括以下几种：
Liveness Probe（存活探针）：用于检测容器是否处于正常运行状态。如果存活探针检测到容器内部的应用程序出现故障，Kubernetes 将会自动重启该容器。存活探针设置方式，可以使用 HTTP 请求、TCP 连接或命令执行来设置。
Readiness Probe（就绪探针）：用于检测容器是否准备好接收流量。如果就绪探针检测到容器没有准备好，Kubernetes 将不会将流量路由到该容器。可以使用 HTTP 请求、TCP 连接或命令执行来设置就绪探针。
Startup Probe（启动探针）：用于检测容器是否已经成功启动。如果启动探针检测到容器启动失败，Kubernetes 将会尝试重新启动该容器。与存活探针和就绪探针不同，启动探针只在容器启动时运行一次，然后就不再运行了。
Node Health Check（节点健康检查）：用于检测节点的状态。如果节点出现故障，Kubernetes 将会将该节点上的所有容器转移到其他节点上。可以使用 kubeadm 自带的 kubeadm node 命令或 kubelet 的 --healthz 选项来设置节点健康检查。
Cluster Health Check（集群健康检查）：用于检测整个集群的状态。可以使用 kubeadm 自带的 kubeadm check 命令或 kubelet 的 --healthz 选项来设置集群健康检查。此外，还可以使用 Kubernetes 官方提供的 kubeadm-diagnostics 工具来进行集群诊断。
k8s中的资源调度有哪些方式
Kubernetes 中的资源调度主要有以下几种方式：
基于 CPU 和内存资源的静态调度：在 Kubernetes 中，可以为每个 Pod 指定需要使用的 CPU 和内存资源。基于这些资源的需求，Kubernetes 会自动将 Pod 调度到具有足够资源的节点上。这种方式称为静态调度，因为资源需求是在 Pod 创建时指定的，而不会随着时间的推移而变化。
基于 CPU 和内存资源的动态调度：除了静态调度外，Kubernetes 还支持基于 CPU 和内存资源的动态调度。在这种方式下，Kubernetes 会根据当前节点的资源使用情况，将 Pod 动态地调度到具有可用资源的节点上，从而实现资源的最优分配。
基于节点标签的调度：Kubernetes 还支持基于节点标签的调度。通过为节点打上不同的标签，可以让 Kubernetes 将特定类型的 Pod 调度到具有相应标签的节点上。这种方式非常适合需要将不同类型的应用程序隔离开的场景。
基于节点亲和性和反亲和性的调度：在 Kubernetes 中，可以通过指定节点亲和性和反亲和性规则，来控制 Pod 被调度到哪些节点上。比如，可以指定一个 Pod 只能被调度到与指定节点具有相同标签的节点上，或者指定一个 Pod 不能被调度到与指定节点具有相同标签的节点上。
基于调度器插件的调度：Kubernetes 允许用户编写自己的调度器插件，并将其添加到 Kubernetes 集群中。通过使用这种方式，用户可以实现定制化的调度策略，以满足特定的需求。
k8s中的控制器(Controller)如何工作的
Kubernetes的控制器（Controller）是一种用于管理Kubernetes资源的控制器模式。
它确保系统处于期望的状态，通过周期性地监视系统状态，然后采取必要的操作使其达到期望状态。
控制器负责监控Kubernetes资源对象的状态，并确保资源对象的实际状态与期望状态匹配。
控制器的工作原理如下：
定义期望状态：控制器定义资源对象的期望状态，例如Pod应该运行在哪个节点上，有哪些容器以及运行的命令。
监控实际状态：控制器周期性地监视系统状态，通过 API Server 获取资源对象的实际状态，并与期望状态进行比较。
执行调谐操作：如果实际状态与期望状态不匹配，则控制器执行必要的操作来将系统状态调整为期望状态。例如，如果Pod未在期望节点上运行，则控制器会调度Pod到正确的节点上。
重复以上步骤：控制器持续监视系统状态，并根据需要执行调谐操作，直到实际状态与期望状态匹配为止。
Kubernetes提供了许多内置的控制器，如Deployment、ReplicaSet和StatefulSet，它们分别用于管理不同类型的应用程序和资源对象。
此外，用户还可以编写自定义控制器来管理自定义资源对象。
为什么docker系统镜像比传统系统镜像的小那么多？
层级存储：Docker 镜像是由多个层组成的，每一层只包含自上次提交或基础镜像以来的更改。这种设计减少了冗余数据，因为共享相同基础镜像的多个容器可以重用相同的层。
精简的操作系统：Docker 官方的 CentOS 镜像通常是精简版的，只包含运行容器所需的最基本的系统组件。这与完整的 CentOS 安装相比，后者可能包含许多不常用或不必要的软件包和库。
删除了不必要的软件和文档：为了减小镜像大小，Docker 镜像通常会移除一些不常用的软件包、文档和示例文件。
按需安装：在容器启动时，可以根据需要安装额外的软件包，而这些软件包不会增加镜像的初始大小。
使用更小的基础镜像：一些 CentOS 镜像可能是基于更小的基础镜像构建的，比如 Alpine Linux，其自身是一个非常小的 Linux 发行版。
讲一下镜像的分层结构以及为什么要使用镜像的分层结构？
镜像的分层结构：
Docker 镜像是分层的，这意味着它们可以由多个层组成。每个层都包含一个文件系统，该文件系统可以由其他层继承。例如，一个镜像可以包含一个基础操作系统层，一个应用程序层，以及一个配置层。
镜像的分层结构有几个优点：
镜像的分层结构优势：
描述一下Dockerfile的整个构建镜像过程
Dockerfile 的整个构建镜像过程如下：
从一个基础镜像开始，该镜像可以是官方镜像或自定义镜像。
使用 RUN 命令在镜像中安装软件包和运行命令。
使用 ADD 命令将文件和目录复制到镜像中。
使用 CMD 命令指定镜像的默认命令。
使用 EXPOSE 命令指定镜像的端口。
使用 LABEL 命令添加元数据到镜像。
使用 ENV 命令设置环境变量。
使用 USER 命令设置用户和组。
使用 VOLUME 命令创建卷。
使用 COPY 命令复制文件和目录到镜像中。
FROM ubuntu:latest RUN apt-get update && apt-get install -y nginx ADD nginx.conf /etc/nginx/nginx.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]
这个 Dockerfile 会从 Ubuntu 最新版本的镜像开始，然后安装 nginx 服务器。它还会将 nginx.conf 配置文件复制到镜像中，并将镜像的端口 80 暴露出来。最后，它会设置 nginx 服务器的默认命令。
当您使用 docker build 命令构建这个镜像时，Docker 会从基础镜像开始，并按照 Dockerfile 中的步骤进行操作。最终，它会创建一个新的镜像，该镜像包含 nginx 服务器和 nginx.conf 配置文件。
kubelet的功能、作用是什么？
kubelet 是 Kubernetes 集群中的一个关键组件，它负责管理 Pod 和容器。kubelet 在每个节点上运行，并与控制平面通信，以获取有关 Pod 和容器的最新信息。kubelet 负责启动、停止和重启 Pod 和容器，并确保它们在运行时保持健康。
kubelet 还负责将 Pod 和容器的状态报告给控制平面。这使得控制平面能够了解集群中正在运行的所有 Pod 和容器。
kubelet 是一个非常重要的组件，它是 Kubernetes 集群的核心。如果 kubelet 无法正常工作，则整个集群都可能无法正常工作。
k8s中为什么有了Metrics Server 还要额外部署Prometheus
Metrics Server 和 Prometheus 都是 Kubernetes 集群中用于监控和收集指标的工具，但它们有不同的用途和特点：
Metrics Server:
主要用于提供基本的资源使用数据，如 CPU 和内存使用情况。
它通过 Kubernetes API 聚合和提供这些指标，使得 Kubernetes 自身的自动扩展器（如 HPA）可以使用这些数据来自动调整 Pod 的数量。
Metrics Server 通常与 Kubernetes 集群紧密集成，是 Kubernetes 官方推荐用于资源监控的基础组件。
Prometheus:
是一个强大的开源监控和警报工具，用于记录实时的时间序列数据。
它支持自定义指标的收集，不仅限于 CPU 和内存，还可以收集网络、磁盘、I/O 等其他类型的指标。
Prometheus 提供了灵活的查询语言（PromQL）来查询和分析数据。
它可以与 Grafana 等可视化工具集成，提供丰富的图表和仪表板。
Prometheus 还支持长期存储和历史数据的查询，适合进行趋势分析和故障排除。
为什么同时使用 Metrics Server 和 Prometheus：
不同需求：Metrics Server 主要满足 Kubernetes 自动扩展和基本监控的需求，而 Prometheus 提供了更全面和深入的监控能力。
集成与灵活性：Metrics Server 与 Kubernetes 的集成更紧密，而 Prometheus 提供了更多的自定义选项和灵活性。
扩展性：Prometheus 可以轻松扩展以收集和监控更多的指标。
生态系统：Prometheus 拥有一个庞大的生态系统，包括各种 exporter、集成和可视化工具。
总的来说，Metrics Server 可以看作是 Kubernetes 集群监控的基础组件，而 Prometheus 是一个更为强大和灵活的监控解决方案，两者可以互补使用，以满足不同层次的监控需求。
k8s 提供了大量的REST接口，其中有一个是 Kubernetes Proxy API 接口，简述一下这个 Proxy接口 的作用，以及怎么使用？
Kubernetes Proxy API 接口是 Kubernetes 提供的一种代理机制，它允许用户通过代理服务器访问 Kubernetes 集群中的服务和资源。该接口的作用是简化对集群内部服务的访问，并提供了一种安全的方式来与集群进行通信。
使用 Kubernetes Proxy API 接口可以实现以下功能：
访问服务：通过代理接口，您可以直接访问 Kubernetes 集群中的服务，而无需暴露服务的端口到集群外部。这样可以提高集群的安全性，并且可以通过单个入口点访问多个服务。
访问资源：通过代理接口，您可以访问 Kubernetes 集群中的各种资源，如 Pod、Service、Deployment 等。这样可以方便地获取资源的状态、日志、指标等信息。
使用 Kubernetes Proxy API 接口的步骤如下：
启动代理服务器：在命令行中运行 kubectl proxy 命令，它会在本地启动一个代理服务器，默认监听在本地的 8001 端口。
访问服务或资源：通过发送 HTTP 请求到代理服务器，可以访问 Kubernetes 集群中的服务和资源。例如，要访问服务，可以使用 curl 命令发送请求，指定代理服务器的地址和服务的路径。
curl http://localhost:8001/api/v1/namespaces/default/services/my-service
pause容器的作用是什么？
Pause 容器是 Kubernetes 中的一个特殊容器，它的主要作用是作为一个占位符（placeholder），用来保证一个 Pod 在运行时至少有一个容器始终处于运行状态。
生命周期守护：Pause 容器保证即使 Pod 中的其他容器停止或重启，Pod 本身也不会因为所有容器都停止而被 Kubernetes 系统重启。
初始化容器支持：它为初始化容器提供了一个稳定的环境，确保在 Pod 的初始化阶段，即使初始化容器失败，也不会影响到 Pod 的整体状态。
网络和文件系统共享：它还帮助维持 Pod 的网络设置和文件系统状态，使得 Pod 中的其他容器可以共享这些资源。
pod的原理是什么？
资源共享与隔离：Pod中的容器共享网络命名空间，允许它们使用相同的网络接口和IP地址进行通信。同时，Pod支持容器间的资源共享和隔离，每个容器可以有独立的进程、文件系统等命名空间。
资源管理：Cgroups技术用于对Pod中每个容器的资源使用进行限制和管理，不仅包括CPU和内存，还可以限制磁盘I/O、网络带宽等资源。
初始化容器：Pod中的“pause”容器，作为初始化容器，其主要作用是同步Pod的生命周期与容器的生命周期，确保Pod的网络和文件系统命名空间的一致性。它不执行实际的应用程序，但对Pod的稳定性和一致性至关重要。
网络通信：Pod内的容器通过共享的网络命名空间，能够像在同一台主机上的进程一样，通过localhost进行高效通信。
pod的生命周期有哪几种？
Pending：Pod已经被Kubernetes系统接受，但是一个或多个容器尚未创建。这个阶段通常发生在系统正在为Pod分配所需资源，如下载容器镜像或调度到特定的节点上。
Running：Pod已经被调度到节点上，所有的容器都已被创建，并且至少有一个容器正在运行、正在启动或正在重启。
Succeeded：Pod中的所有容器都正常运行完毕并且已经退出，且不会再重启。
Failed：Pod中的所有容器都已终止。至少有一个容器是因为失败而终止的。即容器退出状态非零。
Unknown：因为某些原因，Pod的状态无法被Kubernetes系统确定，通常是因为与Pod所在节点的通信出现问题。
pod 一直处于pending状态一般有哪些情况，怎么排查
资源不足：当集群中没有足够的资源（如 CPU、内存）来调度 Pod 时，Pod 可能会一直处于 Pending 状态。您可以通过检查集群的资源使用情况，以及调整 Pod 的资源请求和限制来解决此问题。
调度约束：如果 Pod 的调度约束无法满足，例如节点上的标签不匹配或节点选择器不正确，Pod 也可能无法被调度并一直处于 Pending 状态。您可以检查 Pod 的调度约束是否正确，并确保节点上的标签和选择器匹配。
网络问题：如果 Pod 需要访问的镜像无法从容器仓库下载，或者 Pod 需要访问的服务无法连接，也可能导致 Pod 一直处于 Pending 状态。您可以检查网络连接是否正常，以及容器仓库是否可访问。
持久卷声明（Persistent Volume Claim）问题：如果 Pod 需要使用持久卷，并且没有可用的符合要求的持久卷，Pod 也会一直处于 Pending 状态。您可以检查持久卷声明的状态和可用性，以及持久卷的配额是否足够。
调度器问题：在某些情况下，调度器本身可能出现问题，导致 Pod 无法被正确调度。您可以检查调度器的日志和事件，以了解是否存在调度器问题。
排查 Pod Pending 状态的问题，可以执行以下操作：
使用 kubectl describe pod <pod-name> 命令查看 Pod 的详细信息，包括事件和调度器日志，以获取更多的上下文信息。
检查集群的资源使用情况，确保有足够的资源可供调度 Pod。
检查 Pod 的调度约束，包括标签和选择器的匹配情况。
检查网络连接是否正常，以及容器仓库是否可访问。
检查持久卷声明的状态和可用性，以及持久卷的配额是否足够。
检查调度器的日志和事件，了解是否存在调度器问题。
来源：
参考：
