运维老生常谈

要构建 Docker 镜像，需要使用，其中包含指令。这些指令分别是和，用于定义 Docker 镜像的多个方面。由于工作原因，开发人员常常会对它们感到困惑。本博客将列出并解释RUN、CMD和ENTRYPOINT命令之间的多种差异。用于执行命令指令并创建新的镜像层。用于设置在容器启动后默认执行的命令及其参数。配置容器启动时要执行的命令，从功能的角度来看，类似于 CMD。让我们通过下面提供的指令来检查 RUN、CMD 和 ENTRYPOINT 的工作原理。首先，创建一个，并将以下代码粘贴到其中，该代码包含。

Docker是一个开源应用程序，提供用户应用程序及其宿主机器和容器化应用程序之间的隔离。它有助于在操作系统上创建、部署和管理应用程序容器。容器是Docker镜像的运行实例，用户可以挂载、存储库和文件。本篇文章将提供关于Docker中不同类型挂载的详细信息。让我们逐一查看上述列出的类型吧！卷是保留由Docker容器生成的数据的首选机制，并且它也被Docker使用。此外，卷比将数据保存在容器的可写层内更好。卷不会通过利用它来最大化Docker容器的大小。绑定挂载依赖于主机的目录结构和操作系统。

bridge-nf-call-iptables 这个内核参数 (置为 1)，表示 bridge 设备在二层转发时也去调用 iptables 配置的三层规则 (包含 conntrack)，所以开启这个参数就能够解决上述 Service 同节点通信问题，这也是为什么在 Kubernetes 环境中，大多都要求开启 bridge-nf-call-iptables 的原因。，当 coredns 所在节点上的 pod 解析 dns 时，dns 请求落到当前节点的 coredns pod 上时，就可能发生这个问题。

用户通过kubectl或者其他方式（如 CI/CD 系统）向 Kubernetes API Server 提交 Pod 定义（YAML 或 JSON 格式）。这个定义文件描述了 Pod 的配置，包括容器镜像、资源需求、环境变量、卷挂载等。通过上述组件的协同工作，Kubernetes 确保了 Pod 的生命周期管理，从创建到调度再到运行，均实现了自动化和高可用。每个组件都扮演着关键角色，共同保证了集群内工作负载的可靠性和可扩展性。

这些exporter工具使 Prometheus 能够从各种不同的系统和服务中收集和监控指标数据，涵盖了从主机系统到应用程序、数据库、网络服务等多种场景。选择合适的exporter可以帮助你全面了解系统的性能状况，并根据需要进行监控和告警配置。

在 Kubernetes 中，探针（Probe）是一种用于检查容器状态的机制。探针可以检测容器是否处于健康状态，以及是否准备好处理请求。探针的配置在容器级别进行，Kubernetes 可以基于探针的结果对容器执行特定的操作，比如重启容器或者将其从服务的后端列表中移除。Kubernetes 中的三种探针类型Liveness Probe（存活探针）用途: 检查容器是否还在运行。如果 Liveness Probe 失败，Kubernetes 会将容器视为不可用并尝试重启它。

任何关于证书报错的信息和日志仔细看，证书过期、 certSAN 不匹配和不是一套 ca 导致校验不通过等是不一样的事情，不要无脑找到啥证书文章博客就跟着瞎操作，证书操作前要备份已有证书，产生 kubeconfig 文件的时候，要使用 kubectl 指定新路径生成，不要动老的。k8s 采用的是基于 X.509 V3 标准的双向 SSL，客户端和服务端通信，都会验证双方证书，根据双方是否是一样的 CA 签署的证书，而 CA 私钥是自己生成的，你可以看到 k8s 组件的 cmdline 都有指定参数。

在大规模环境下，优化 Prometheus 的性能非常重要，以确保监控系统能够可靠、高效地处理大量数据。以下是一些关键的优化策略：1.分区和分片使用多个 Prometheus 实例：通过将监控负载分散到多个 Prometheus 实例来减少单个实例的压力。可以根据服务、地理位置或环境（如生产与开发）来划分实例。

实现告警的自动化响应可以显著提高系统的可靠性和运维效率，减少人为干预的需要。以下是实现告警自动化响应的几个关键步骤和最佳实践：1.定义自动化响应的策略分类告警：根据告警的严重性和类型，将告警分类为可自动处理的告警和需要人工干预的告警。自动化响应应优先用于那些可以通过脚本或自动化工具解决的常见问题。预定义操作：为每种类型的告警定义相应的自动化响应操作，例如重启服务、清理缓存、扩展资源等。失败策略：考虑自动化响应失败的情况，并定义失败时的回退策略，例如在自动化操作失败后升级为人工处理。

删除一个 Kubernetes Namespace 是一个多步骤的过程，这个过程涉及多个内部操作，以确保 Namespace 中的所有资源被正确地清理并从集群中移除。以下是 Namespace 删除的详细流程：1.用户发起删除请求用户通过命令或其他 API 客户端发起删除 Namespace 的请求。Kubernetes API Server 接收到该请求后，标记该 Namespace 资源的字段，表示该 Namespace 已经进入删除过程。2.

在构建 Docker 镜像时，减小镜像体积有助于提高传输速度、减少存储成本，并提升启动性能。以下是一些减小 Dockerfile 生成镜像体积的最佳实践：1.使用轻量级基础镜像选择更小的基础镜像，如alpine，代替常见的较大镜像（如ubuntu或debianAlpine 是一个轻量级的 Linux 发行版，体积通常不到 10MB，而 Ubuntu 通常在 100MB 以上。2.多阶段构建（Multi-stage Builds）

CAT 发生红盘， 排查问题 查看容器速查大盘，发现某个 Pod 发生丢包。

通过这些措施，可以大大提高 Prometheus 的高可用性，确保在任何情况下都能及时发现并解决问题，从而保障整个监控系统的稳定运行。

在 Kubernetes 中，当节点的状态变为NotReady时，节点上的 Pod 是否会被重新调度取决于 Pod 的类型和 Kubernetes 的配置。下面是相关的详细说明：1.节点状态变为NotReady的原因节点变为NotReady通常表示节点无法正常与 Kubernetes 控制平面（API Server）通信，可能由于以下原因：节点宕机或网络故障。节点上的kubelet服务停止工作。节点资源耗尽（如 CPU、内存过载）。

在使用容器化技术时，容器时区与主机或其他容器不一致可能导致日志时间错误或应用程序时间不同步。以下是解决该问题的常见方法： 挂载主机时区文件：通过挂载主机的/etc/localtime和/etc/timezone文件，使容器与主机时区一致。 设置环境变量：通过TZ环境变量（如TZ=Asia/Shanghai）配置时区，适用于支持该变量的镜像。 手动修改容器时区：在已运行的容器中，通过命令手动更新时区配置。 确保时区数据安装：在轻量级镜像中安装tzdata包以支持时区设置。 Kubernetes中的解决方案：通

在容器技术中，CRIcontainerd和runc是 Kubernetes 和 Docker 等容器平台中关键的组件，它们在容器生命周期管理中扮演着重要角色。理解它们之间的关系有助于理解容器运行的整个过程。下面将详细描述它们的关系及执行命令时底层的工作流程。1.CRI、containerd、runc 之间的关系CRI是 Kubernetes 定义的一套标准接口，用于与容器运行时交互。Kubernetes 通过 CRI 与底层容器运行时进行通信。常见的 CRI 实现有。

在 Prometheus 和 Thanos 环境中，为了实现告警架构的高可用性，需要在多个层面进行设计和配置。以下是实现告警高可用性的几个关键步骤：1.Prometheus 实例的高可用多 Prometheus 实例：部署多个 Prometheus 实例来监控相同的服务和指标。这些实例可以彼此独立运行，保证即使其中一个实例发生故障，其他实例仍然可以继续收集数据和评估告警规则。

僵尸进程（Zombie Process）是指在 Unix/Linux 系统中，一个子进程已经终止，但其父进程尚未对它进行善后处理（即没有读取其退出状态），导致子进程的进程表项仍然保留在系统中。由于这个进程已经结束，但进程表中的记录尚未被释放，所以称为“僵尸进程”。僵尸进程的产生过程一个父进程创建了一个子进程。子进程完成任务后，调用exit()退出，进入终止状态（Terminated）。退出的子进程会向父进程发送一个 SIGCHLD 信号，告知父进程它已经结束。父进程应调用wait()

在Kubernetes（K8s）集群规模达到上千个节点时，需要注意的问题相对较为复杂和全面。以下是一些关键的考虑因素和最佳实践：1.资源管理资源配额：设置适当的资源配额（Resource Quotas）和限制（LimitRanges）以防止某个命名空间耗尽集群资源。自动扩展：使用Horizontal Pod Autoscaler（HPA）和Cluster Autoscaler根据负载动态扩展Pods和节点。2.网络管理网络插件。

删除一个 Kubernetes Pod 的过程涉及多个步骤和组件之间的协作，以确保 Pod 被安全地终止并从集群中移除。以下是删除 Pod 的简要流程：1.用户或控制器发起删除请求用户通过命令，或者控制器（如Deployment）通过更新其管理的副本数量来触发 Pod 的删除。Kubernetes API Server 接收到删除请求后，会将 Pod 的字段设置为当前时间，标志着该 Pod 进入删除流程。2.更新 Pod 状态为 Terminating一旦。

Traefik和NGINX Ingress都是流行的Kubernetes Ingress控制器，各有其优点。以下是Traefik相对于NGINX Ingress的一些主要优点：1.易于配置和使用动态配置：Traefik支持自动发现服务，可以根据Kubernetes的状态动态更新路由规则，而NGINX通常需要手动刷新配置。简化配置：Traefik的配置文件格式更为简单和友好，特别适合快速部署和测试。2.原生支持微服务架构服务发现。

Prometheus的规则评估功能适合单实例的监控环境，专注于在本地存储和评估数据，适合较简单或中小规模的监控部署。组件扩展了规则评估功能，适用于分布式、高可用的监控场景，能够处理跨多个 Prometheus 实例的数据，提供更强大的规则评估和告警能力，特别适合大规模企业级监控系统。如果你已经在使用 Prometheus 并希望扩展到更大的规模或跨区域监控，使用 Thanos 的rule组件将是一个自然的进阶选择。

Thanos Sidecar 和 Thanos Receive 是 Thanos 生态系统中两个关键组件，但它们在架构中的作用和功能上有明显的区别。以下是它们的主要区别：1.功能：与 Prometheus 集成：Sidecar 是一个部署在每个 Prometheus 实例旁边的组件。它的主要作用是与 Prometheus 紧密集成，以扩展 Prometheus 的功能。

Thanos 是一个用于扩展 Prometheus 的高可用性和长期存储的解决方案。它通过整合多个 Prometheus 实例，提供了全局查询、长期存储、以及高可用性的能力。Thanos 的架构主要由以下几个核心组件组成：1.Sidecar功能：Sidecar 是与每个 Prometheus 实例一起部署的组件。它的主要功能是将 Prometheus 的时间序列数据上传到远程对象存储（如 S3、GCS 等），并在需要时从这些存储中检索数据。

当你在使用 Prometheus 监控时，发现某个目标（Target）显示为DOWN，意味着 Prometheus 无法成功抓取该目标的指标数据。要解决这个问题，你可以按照以下步骤进行故障排除：1.检查 Prometheus 的 Target 页面访问 Prometheus 的 Web 界面，点击 “Targets” 页面，查看该目标的状态。通过页面查看：状态：目标是否显示为DOWN。：最后一次抓取的时间和状态。Error。

在Kubernetes中，Service和Endpoints是两个密切关联的对象，它们共同实现了服务发现和负载均衡的功能。以下是它们之间的关联和工作原理：1.Service 的定义Service是一种抽象，定义了一组逻辑上相关的 Pod，以及用于访问这些 Pod 的策略。它为 Pod 提供了一个稳定的网络标识，可以通过 ClusterIP、NodePort 或 LoadBalancer 等方式暴露服务。Service 定义了如何选择和访问这些 Pod。2.Endpoints 的定义。

Kubernetes Scheduler 负责将 Pods 调度到适当的节点上，以确保应用程序的高效运行。其调度流程主要包括以下几个步骤：1.对接收的 Pod 进行筛选监听事件：Scheduler 监听 Kubernetes API Server 中 Pod 的事件，通常是有新的 Pod 被创建（例如，用户创建了一个 Deployment）。待调度 Pods 列表：Pod 处于 Pending 状态，标识为待调度的 Pod 将被调度器处理。2.过滤步骤（Filtering）节点选择。

Prometheus 支持多种服务发现 (Service Discovery) 机制，用于自动发现需要监控的目标。这些服务发现机制主要分为以下几类：1.静态配置 (Static Configuration)手动定义静态目标列表。适用于小规模的、固定的目标环境，通过在配置文件中直接指定目标的地址和端口。2.基于 DNS 的服务发现 (DNS Service Discovery)通过 DNS SRV 记录自动发现目标。这种方式适用于使用 DNS 进行服务注册和发现的环境。

Prometheus 通过块存储格式和多种压缩算法（如 delta 编码和变长编码）来优化数据存储，减少存储需求。数据被分割成多个时间块，块内使用压缩技术，索引文件也被压缩以提高性能。持久化机制通过设置数据保留时间和自动清理策略来管理数据的长期存储，确保数据的可靠性和有效性。

Prometheus 的告警从触发到收到通知的过程中，延迟可能会出现在多个环节。以下是告警延迟可能发生的几个主要步骤和原因：1.数据采集延迟 (Scraping Delay)描述：Prometheus 定期从被监控的目标中拉取 (scrape) 数据，默认间隔通常是 15 秒。这个间隔时间决定了 Prometheus 更新监控数据的频率。可能的延迟：如果目标在 Prometheus 上次拉取数据后才发生状态变化，则在下一次拉取前，这些变化不会被发现，因此可能会有一个间隔时间的延迟。2.

在Kubernetes中，ReplicaSet和Deployment是用于管理 Pod 副本的关键对象。它们各自的功能和实现机制如下：1.ReplicaSet功能管理 Pod 副本：确保指定数量的 Pod 副本一直在运行。如果有 Pod 副本崩溃或被删除，ReplicaSet 会创建新的 Pod 以维持期望的副本数。维护 Pod 的状态：ReplicaSet 会监控其管理的 Pods 并确保它们处于健康状态。实现机制选择器。

Prometheus 是一个开源的监控和告警系统，专为监控分布式系统而设计。它的工作流程主要包括以下几个关键步骤：1.数据采集 (Scraping)目标发现 (Service Discovery)：Prometheus 自动或手动配置监控目标，通过 DNS、Kubernetes、Consul 等机制发现需要监控的服务或节点。数据拉取 (Scraping)：Prometheus 定期（默认每 15 秒）从被监控目标的/metrics端点拉取监控数据。

Prometheus 和 Zabbix 是两种流行的监控系统，但它们在数据收集方式上有显著的不同：Prometheus 使用拉取模式(pull model)，而 Zabbix 通常使用推送模式以下是两者的区别以及各自的优缺点：Prometheus 的拉取模式 (Pull Model)工作原理拉取数据：Prometheus 定期从配置的目标（如服务、应用、导出器）中主动拉取数据。这些目标必须暴露一个/metrics。

upupup[5m]upavg(up)up这些查询结果类型用于不同的查询场景和计算需求，帮助用户灵活地分析和监控其系统的状态和性能。

在 Kubernetes 或其他基于 Linux 的容器化环境中，WSS和RSS是用于衡量内存使用情况的两个重要指标。它们的区别在于它们所反映的内存使用的不同方面。

pause 容器作为同一个 Pod 中所有其他容器的基础容器，它为 Pod 中的每个业务容器提供了大量的 Pod 级别资源，这些资源都是 Linux 命名空间（包括网络命名空间，IPC 命名空间和 PID 命名空间）。pause 容器提供了一种方法来管理所有这些命名空间并允许业务容器共享它们，在同一个网络命名空间中的好处是：同一个 Pod 中的容器可以使用 localhost 来相互通信。

添加 Targets：通过或PodMonitor资源定义服务或 Pod 的监控配置。添加告警规则：通过资源定义告警规则并应用到 Kubernetes 集群中。使用 Prometheus Operator 管理 Prometheus 可以简化这些配置和维护任务，确保监控系统的高效和稳定。

Pod 的健康检查失败可能由多种原因引起，通常与应用程序的配置、网络、资源、或 Kubernetes 配置有关。以下是常见的原因及排查思路：1.应用程序本身的问题1.1. 应用程序未启动或启动缓慢原因: 应用程序可能需要较长时间启动，超出了探针的超时时间。排查查看应用程序的日志：。如果应用启动缓慢，可以增加探针的或考虑使用。1.2. 应用程序崩溃或陷入死循环原因: 应用程序可能在启动时崩溃或陷入死循环，导致探针无法成功。排查查看应用程序的日志：。

在 Kubernetes 集群中，如果发现 Pod 之间无法通信，可能是由多种原因引起的。排查 Pod 之间网络访问不通的问题，通常可以按照以下步骤进行：1.检查 Pod 的基本状态状态: 确保 Pod 状态为Running，而非Pending等异常状态。节点分布: 查看 Pod 所在节点，确认它们是否分布在不同节点上，这可能影响网络排查的思路。2.检查 Pod 的网络配置通过检查 Pod 的详细信息，特别是网络相关的配置。Pod IP。

在 Kubernetes 中，Pod 是最小的可部署单元，Pod 的状态反映了其当前的运行状况。以下是几种常见的 Pod 状态：1.Pending描述: Pod 已被 Kubernetes API Server 接收并创建，但还没有开始运行在任何节点上。原因Pod 资源不足，无法调度到任何节点上。等待某些条件满足，如 PersistentVolume 的绑定。还没有被调度到任何节点。2.Running描述: Pod 已经成功调度到节点，并且至少有一个容器在运行或者正处于启动过程中。