summer_fish的专栏

IP 类型来源用途管理方核心规划点核心规划点主机网络主机网络基础设施/云与 Pod/Service CIDR 可路由Pod IPPod CIDRPod 间通信CNI 插件根据节点/Pod 规模计算，避免冲突Cluster IP服务发现与负载均衡与 Pod CIDR 不重叠，中等大小云或手动外部访问服务云控制器管理器通常自动管理。

CrashLoopBackOff 只是症状，根因往往隐藏在更深层。层级典型问题排查关键点镜像层命令错误 / 构建问题本地验证镜像启动命令运行时层资源不足 / 存储失败查看 Events 与应用层异常或依赖未就绪日志分析 + 网络连通性验证探针层误判 / 配置不当调整 startupProbe / livenessProbe现象 → 日志 → 层级 → 根因 → 优化。

基于上述生成的 Job 资源对象 YAML 文件，经过适当调整后得到以下配置。Job 资源对象本质上是对 Pod 资源对象的封装实现。如下定义的 Job 任务将通过echo命令输出两个参数。apiVersion: batch/v1 # 注意 Job 资源与其他 API 资源的版本差异kind: Jobmetadata:name: test-job # 可自定义标签的 Job 名称spec:activeDeadlineSeconds: 20 # 任务执行超时时长。

在Kubernetes（k8s）中，startupProbe、和。

原文：翻译：

The traffic and CPU performance of each pod are the same.But the memory usage in one pod is higher than others.Exception performanceNormal performancePath: /etc/nginx/nginx.confPodNginx.conf IsLeaderingress-nginx-controller-67d8c7cf46-qk8qr worker_pr

不要仅仅因为别人这么做就选择 Kubernetes。如果你的团队其实不需要它的复杂功能，那么你和我们一样发现了这个简单的事实：仅仅是三个更小巧、更简单的工具就可以做好这些工作。

退出，这反而不正常！这说明你的应用程序可能在启动后错误地执行完了某个逻辑就退出了，比如一个 Web 服务器启动脚本在启动完守护进程后自己就退了。操作系统和 Shell 只需要检查这个最高位，就能瞬间判断出进程是“寿终正寝”还是“意外身亡”，这是一种非常高效的约定！如果 退出码 & 128 的结果是 1 (或者说非0) -> 说明进程是被信号杀死的。: 这是最常见的错误码，通常意味着程序捕获到了一个异常但并未处理（或处理后决定退出）。这是一个“优雅退出”的终止信号，它告诉程序“请你准备一下，然后正常退出”。

验证通过后，API Server 将 Pod 的定义数据存储到其后端存储 etcd 中，至此，Pod 对象在集群中被“创建”了，但它实际上还没有被调度到任何节点上运行起来。的确，Pod启动涉及了Kubernetes各组件的协作，之后我把这个问题记录在了我自己的《面试问题集》里，当有机会面试别人，开头考察基础的时候，我也喜欢问这个问题。当它发现一个新的 Pod 对象（或者由它管理的 Deployment 下的 Pod 对象）被创建，且尚未分配到任何节点时，它会触发下一步的资源创建。

在 Kubernetes 中，`ipFamilyPolicy`是与网络相关的配置选项，用于控制 Pod 或服务的 IP 地址族（IPv4 或 IPv6）的使用策略。它主要应用于支持双栈网络（即同时支持 IPv4 和 IPv6）的场景中。`ipFamilyPolicy`有以下几种类型，每种类型的作用如下：• 作用：仅使用单一的 IP 地址族（IPv4 或 IPv6），具体使用哪一个取决于集群的配置。• 场景：适用于集群中仅支持 IPv4 或 IPv6 的环境。• 特点：• 如果集群配置为 IPv4，则仅使用

本文探讨Kubernetes节点维护中的两个关键操作：kubectl drain和systemctl stop containerd对DaemonSet Pods的不同影响。kubectl drain会忽略DaemonSet Pods的驱逐请求，以保持其每个节点运行的特性；而systemctl stop containerd会终止所有容器进程，但DaemonSet控制器和etcd会保留Pod元数据，在节点恢复后自动重建Pods。文章详细分析了这两种操作背后的Kubernetes设计哲学和恢复机制，强调了理解

Kubernetes中的readinessProbe和livenessProbe是两种重要的容器健康检查机制。readinessProbe用于判断容器是否准备好接收流量，成功则加入负载均衡，失败则移除；适合处理应用初始化场景。livenessProbe检测容器是否存活，失败会触发重启，适用于处理死锁等故障。启动时会先执行startupProbe（如有），之后二者按配置时间间隔运行。它们都支持exec、httpGet和tcpSocket三种检测方式，且可以同时使用，确保服务可靠性和自动恢复能力。

NoScheduleDaemonSet 的设计目标是确保。然而，如果节点被设置了污点（如假设某个节点被标记为要让 DaemonSet 的 Pod 能够在带有污点的节点上运行，需要在。

Kube-VIP 是一个轻量级、功能强大的 Kubernetes 虚拟 IP 管理工具，通过管理虚拟 IP 地址，提供了高可用性和负载均衡功能。它支持多种部署方式和网络协议，适用于多种场景，能够显著提高 Kubernetes 集群的可靠性和稳定性。

inotifykubelet使用inotify来监控 Pod 和容器的文件系统事件，确保及时响应配置文件和日志文件的变化。虽然inotify是一种高效的监控机制，但在使用时需要注意其限制，并根据需要调整内核参数。

参数的调整都是为了优化 Kubernetes 集群的性能和稳定性。通过增加系统资源限制和优化网络参数，可以确保 Kubernetes 集群在高负载情况下也能正常运行。在 Kubernetes (K8s) 安装过程中，对主机系统参数进行调整的界面。这些参数都是 Linux 内核的。参数，用于优化 Kubernetes 集群的性能和稳定性。

在请求流转中，代理容器通过 localhost 通信，并利用 Kubernetes 的iptables 规则实现流量劫持与转发，完成复杂功能如负载均衡等。为应对复杂需求，Istio支持通过 EnvoyFilter（Lua 脚本）和插件机制（WebAssembly） 扩展功能，且扩展无需重启容器，开发者可以选择多种语言开发插件，提升扩展性和灵活性。Istio通过在Kubernetes环境中引入代理容器，使业务进程和代理进程独立运行。Istio 的数据平面由承载流量的代理容器组成，处理请求流量。

在 Kubernetes 集群中，kube-proxy和CNI插件通过配置 Linux 内核的网络组件（如NetfilterVXLAN等），协同工作以确保 Pod 和 Service 之间的通信。随着eBPF等技术的发展，某些 CNI 插件能够实现无代理的服务转发，进一步优化了网络性能。

在云计算和微服务的浪潮中，容器技术以其轻量级、高效和可移植性的特点，迅速成为软件开发和部署的新宠。其中，单进程模型作为容器技术的核心概念，对于理解容器的工作原理和优势至关重要。本文将深入探讨单进程模型在容器中的应用，并结合实际案例，分析其在现代软件架构中的重要地位和未来发展趋势。此外，随着容器技术的普及，如何确保容器的安全性和合规性也成为了一个重要的考虑因素。：通过Cgroups等技术，容器可以对资源进行精细化的调度和管理，确保应用程序能够获得所需的资源，同时避免资源的过度消耗。

我们先看看通过内核的哪些参数能够提高Ingress的性能。保证在高并发环境下，发挥Ingress的最大性能。。在高并发环境下，如果队列过小，可能导致队列溢出，使得连接部分连接无法建立。要调大 Nginx Ingress 的连接队列，只需要调整 somaxconn 内核参数的值即可，但我想跟你分享下这背后的相关原理。Nginx 监听 socket 时没有读取 somaxconn，而是有自己单独的参数配置。

Istio 是一个开源的服务网格平台，用于连接、管理和保护微服务架构。Istio 提供了一组功能，例如流量管理、安全性、监控和可观察性，帮助开发人员更轻松地部署、维护和监控复杂的微服务应用程序。在 Istio 中，虚拟服务、目标规则和网关是关键概念，它们有助于定义服务之间的通信、流量控制和安全策略。

ThreadStats：线程统计信息。

在 Kubernetes 中，调度是指将 Pod 放置到合适的 Node 节点上，然后对应 Node 上的 Kubelet 才能够运行这些 pod。调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。调度器会依据下文的调度原则来做出调度选择。

我们都知道 Kubernetes 中最小的原子调度单位是Pod，那么就意味着资源管理和资源调度相关的属性都应该Pod对象的字段，其中我们最常见的就是 Pod 的 CPU 和内存配置，而为了实现 Kubernetes 集群中资源的有效调度和充分利用，Kubernetes采用 requests 和 limits 两种限制类型来对CPU和内存资源进行容器粒度的分配。其次，是Burstable级别的Pod，这个级别的Pod至少设置了1个CPU或者内存的requests，但又不满足最高级别的Qos条件。

Knative 专注于解决容器为核心的 Serverless 应用的构建、部署和运行的问题，它构建在 Kubernetes 和 Istio 平台之上，整合了 Kubernetes 提供的 deployment、replicaset 和 pods 等容器管理能力，与 Istio 提供的 ingress、LB、dynamic route 等网络管理功能。Knative 的开发人员可以使用熟悉的语言、框架和方式来部署任何工作负载，包括函数、应用与容器。- 源到容器的构建编排。

节点内存压力问题的出现，从之前的排查来看可能跟低版本的DCE有关，也有可能是节点产生了较多的cache占用了较多的内存，我们的建议是重启节点（之前同样问题的节点重启后暂时没出现过），如果不能重启节点，我们的建议是对节点进行扩容，通过k8s原理来看，在节点出现资源紧张的情况下，会对该节点的pod做驱逐排名，而resources设置了1:1相比于设置了1:n的，排名会更后，所以就出现了calico-node等pod被优先驱逐的情况。Pod的优先级是由用户设置的，并且可以通过权重来区分不同的优先级。

通俗来讲，可观测性被定义为根据系统产生的输出数据，如日志，指标和链路追踪来衡量当前系统运行状态的能力。可观测性目前被广泛的用于提升分布式 IT 系统的稳定性（系统复杂度成倍提升，在故障或者异常时很难快速定位和解决），它利用指标、日志和链路追踪三种类型数据，为分布式系统内部运行状态提供了深度透视能力，协助 DevOps 工程师解决各种问题并提升系统性能。

net.ipv4.ip_forward 是 Linux 内核中的一个参数，用于控制 IP 转发功能。IP 转发是指在一个路由器或者网络设备上接收到一个 IP 数据包后，根据目标 IP 地址的路由信息将数据包发送到合适的接口，使其能够到达目标主机。启用 IP 转发功能后，Linux 系统将能够实现路由转发功能，将数据包从一个网络接口转发到另一个网络接口。在 Linux 中，net.ipv4.ip_forward 的默认值通常是 0，表示禁止 IP 转发。

存储类（StorageClass）定义了持久卷声明（PersistentVolumeClaim）所需的属性和行为，而持久卷（PersistentVolume）是实际的存储资源，持久卷声明（PersistentVolumeClaim）是 Pod 对持久卷的请求。

它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插人这个“代理”的网格中，从而使网络抽象化。服务不直接通过网络调用服务，而是调用它们本地的 Sidecar代理，而 Sidecar代理又代表了服务管理请求，从而封装了服务间通信的复杂性。相互连接的Sidecar代理实现了所谓的数据平面，这与用于配置代理和收集指标的服务网格组件（控制平面）形成对比。在服务网格中，代理被称为数据层或数据平面（Data Plane），管理流程被称为控制层或控制平面（Control Plane）。

【代码】Flink访问K8S中namespace。

模式时，确保 Kubernetes 集群正常运行，Calico 与 Kubernetes API 服务器正常通信，并且 Pod 的 IP 地址能够被正确分配和获取。这样，Calico 将能够有效地管理和路由容器的流量。是一种特殊的模式，用于在 Kubernetes 环境中检测容器的 IP 地址。的配置项用于指定 Calico 如何检测容器的 IP 地址。在 Calico 中，

当流量到达时，物理网络设备将流量路由到MetalLB的VIP，然后MetalLB将其转发到实际运行服务的Pod。它使用集群中的物理节点作为虚拟IP（VIP）的代理，节点将收到的请求转发给实际运行服务的Pod。它的主要目标是为裸金属（Bare Metal）环境中的Kubernetes集群提供负载均衡服务，而无需依赖云服务提供商的负载均衡解决方案。在BGP 模式下，MetalLB使用 BGP 协议来通知集群中的路由器，告诉它们应该将流量路由到MetalLB的VIP。

Linux namespaces 是对全局系统资源的一种封装隔离，使得处于不同 namespace 的进程拥有独立的全局系统资源改变一个 namespace 中的系统资源只会影响当前 namespace 里的进程，对其他 namespace 中的进程没有影响。Linux 内核出现 namespace 的一个主要目的就是实现轻量级虚拟化（容器）服务。在同一个 namespace 下的进程可以感知彼此的变化，而对外界的进程一无所知，从而达到隔离的目的。

在 Linux 操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。。所以宿主机操作系统的内核，它对于该机器上的所有容器来说是一个全局变量，牵一发而动全身。由于 rootfs 的存在，容器才有了一个被反复宣传至今的重要特性：一致性。由于 rootfs 里打包的不只是应用，而是整个操作系统的文件和目录，也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起。有了容器镜像“打包操作系统”的能力，这个最基础的依赖环境也终于变成了应用沙盒的一部分。

docker支持多种graphDriver，包括vfs、devicemapper、overlay、overlay2、aufs等等，其中最常用的就是aufs了，但随着linux内核3.18把overlay纳入其中，overlay的地位变得更重，最近也在自己的虚拟机上用overlay2作为docker存储驱动实验了一番，下面来做一个简单的笔记和总结。因为在docker中，image是由多个layer组合而成的，换句话就是layer是一个共享的层，可能有多个image会指向某个layer。

随着云原生技术的发展，其应用场景不断扩大。越来越多的企业开始将应用程序部署在 Kubernetes 集群中，随着 Kubernetes 集群规模的不断扩大，也带来了许多管理挑战，例如多集群间负载均衡、资源调度、故障转移等问题。在多云多集群场景中，为了提高业务的高可用性，工作负载可能会被部署在多个不同的集群。在 Karmada 中，当集群发生故障，或是用户不希望在某个集群上继续运行工作负载时，集群状态将被标记为不可用，并被添加上一些污点。

调度器就像一个发动机，如果没有了发动机输入动力，是无法正常运行的。就像 Kubernetes 的调度器，它会负责根据节点的资源状态、Pod 的运行状态，判断 Pod 是调度到怎样的集群节点上去。对于 Karmada 这样的多云能力的调度器来说，调度能力也是大家非常关注的一个能力。主要体现在，能不能通过调度的能力，将多集群的资源负载，控制在相对均衡的水位线，以及需要被调度的资源对象，以怎样的方式被调度到不同的集群上。

1、hostNetwork的作用将 Kubernetes（k8s）中的Pod的hostNetwork: true属性设置为true时，该Pod将与其所在节点共享网络命名空间。这意味着Pod将使用主机的网络栈和IP地址，而不是由Kubernetes创建并管理的专用网络栈。设置hostNetwork: true后，Pod将使用宿主机的网络配置，包括主机上的网络接口、IP地址、路由表等。这使得Pod能够直接访问主机上的网络资源，例如监听主机端口或通过主机上的网络设备进行通信。

定义CRD的规范，包括资源名称、API版本、字段等。使用kubectl或其他Kubernetes API工具创建自定义资源。metadata:spec:names:- mycrd在这个规范中，我们定义了一个名为“my-crds”的自定义资源，其API版本为“v1alpha1”，并且定义了该资源的字段和属性。