k8s

故障场景描述在 K3s 集群经历长时间运行（如 2 年以上）或底层容器运行时（Containerd）崩溃重启后，Rancher 界面显示集群状态为 Unavailable，错误提示通常为 "Cluster agent is not connected"。 故障诊断流程第一阶段：排查 K3s 节点健康度在手动处理 Rancher 连接前，必须确保 K3s 核心服务已恢复。 检查容器运行时状态： 12# 如果报错 connection refused，说明 containerd 没起crictl ps 检查孤儿挂载点（Device busy）： Kubelet 频繁报错 device or resource busy 会导致 API Server 响应极慢，进而撑挂 Rancher 隧道。 12# 查找并懒卸载残留路径grep "kubelet/pods" /proc/mounts | awk '{print $2}' | xargs -I {} umount -l
...

当我们在 Kubernetes 上工作时，有时会遇到这样的场景：我们需要从本地访问一个位于集群内部的 Redis 服务器，但出于安全考虑，这个 Redis 服务并没有直接暴露给外部。不过，集群里有一个 Pod 已经具备了访问这个 Redis 服务器的能力。 利用这个 Pod 作为跳板，我们可以安全地从本地连接到目标 Redis 服务器。由于这个 Pod 本身并不是 Redis 服务，我们不能直接使用 kubectl port-forward。相反，我们需要在 Pod 内部运行一个临时的代理进程。 下面是实现这个目标的详细步骤，可以作为你的操作笔记或博客文章。 借道 Kubernetes Pod 访问内部 Redis 服务器步骤零：先安装必要工具1apt install -y socat net-tools 步骤一：找到你的“跳板” Pod首先，你需要确定那个能够连接到 Redis 服务器的 Pod 的名称。你可以使用 kubectl 命令列出集群中的所有 Pod： 1kubectl get pods 从列表中找到你需要的 Pod，例如它的名字是 my-redis-client...

简介在没有Web版的Dashboard的情况下，您可以使用命令行命令来管理您的Kubernetes集群。这使得您可以轻松地执行各种操作，例如查看资源、编辑资源、删除资源等。 资源监视：使用K9s，您可以轻松地监视和管理Kubernetes集群中的各种资源，例如Pod、Deployment、Service和ConfigMap等。资源修改：您可以使用K9s的资源编辑功能来修改这些资源，例如更新Pod的副本数量或更改Service的类型。K9s还提供了强大的资源搜索功能，使您可以快速查找特定的资源。 安装 K9s 可用于 Linux、macOS 以及 Windows 平台 地址：https://github.com/derailed/k9s Linux12[root@localhost ~]# wget https://github.com/derailed/k9s/releases/download/v0.21.7/k9s_Linux_x86_64.tar.gz[root@localhost ~]# tar -zxf k9s_Linux_x86_64.tar.gz -C /usr/...

kubectl port-forward 是 Kubernetes 提供的一个命令行工具，它允许你从本地机器转发一个或多个端口到 Kubernetes 集群中的 Pod。这个功能在开发和调试应用程序时非常有用，因为它可以让你直接访问集群中的服务，而不需要通过 Kubernetes 的服务发现和负载均衡机制。 使用 kubectl port-forward 的一些常见场景包括： 快速访问服务：当开发者需要迅速检查集群内部署的服务是否正常运行时，他们可以直接将该服务的端口转发到本地机器来访问。 调试应用：如果开发者需要调试集群内部的应用程序，在该应用程序没有暴露为服务或者没有外部IP时，port-forward 可以提供一个快速的解决方案。 数据库调试：对于涉及数据库的服务，port-forward 允许开发者使用本地数据库客户端工具连接到集群中的数据库 Pod，进行调试和查询操作。 基本语法为： 1kubectl port-forward TYPE/NAME [options] LOCAL_PORT:REMOTE_PORT TYPE/NAME 是指定的资源类型和名称，例如 ...

VPAKubernetes VPA（Vertical Pod Autoscaler）可以理解为对单个服务资源进行扩容，如CPU、内存之类。它一般应用于一些中心化的单体应用，且无法对其进行部 署多份副本的场景，如 Prometheus 或 Jenkins 这类垂直 Pod 应用自动扩缩容。 VPA 会基于 Pod 的 资源使用情况自动为集群设置资源占用的限制，从而让集群将 Pod 调度到有足够资源的最佳节点上。VPA 也会保持最初容器定义中资源 request 和 limit 的占比。 当控制器检测到一个Pod负载过高时，这时会对当前Pod进行终止，接着对Pod的CPU或内存进行扩容，最后重建Pod，此时Pod可能在任何一个节点进行重建。 它与HPA的扩容机制是完全不一样的，VPA扩容过程中将无法正常提供服务，也因此它使用的场景相比HPA来说，要少的多。 安装vpa1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859...

安装 Sidecar注入为了充分利用 Istio 的所有特性，网格中的 Pod 必须运行一个 Istio Sidecar 代理。 下面的章节描述了向 Pod 中注入 Istio Sidecar 的两种方法：使用 istioctl 手动注入或启用 Pod 所属命名空间的 Istio Sidecar 注入器自动注入。 当 Pod 所属命名空间启用自动注入后，自动注入器会使用准入控制器在创建 Pod 时自动注入代理配置。 手动注入直接修改配置，如 Deployment，并将代理配置注入其中。 如果您不确定使用哪一种方法，建议使用自动注入。 自动注入 Sidecar使用 Istio 提供的准入控制器变更 Webhook， 可以将 Sidecar 自动添加到可用的 Kubernetes Pod 中。 虽然准入控制器默认情况下是启用的，但一些 Kubernetes 发行版会禁用这些控制器。 如果出现这种情况，根据指示说明来启用准入控制器。 当您在一个命名空间中设置了 istio-injection=enabled 标签，且 Injection Webhook 被启用后，任何新的 Pod 都有...

参考： 参数配置 service_config 重试

gRPC协议在K8S环境下的负载问题参考： https://www.lixueduan.com/posts/grpc/13-loadbalance-on-k8s/ https://www.cyub.vip/2021/11/09/k8s%E7%8E%AF%E5%A2%83%E4%B8%8B%E9%83%A8%E7%BD%B2grpc%E7%9A%84%E5%87%A0%E7%A7%8D%E6%96%B9%E6%A1%88/ 概述系统中多个服务间的调用用的是 gRPC 进行通信，最初没考虑到负载均衡的问题，因为用的是 Kubernetes，想的是直接用 K8s 的 Service 不就可以实现负载均衡吗。 但是真正测试的时候才发现，所有流量都进入到了某一个 Pod，这时才意识到负载均衡可能出现了问题。 因为 gRPC 是基于 HTTP/2 之上的，而 HTTP/2 被设计为一个长期存在的 TCP 连接，所有请求都通过该连接进行多路复用。 这样虽然减少了管理连接的开销，但是在负载均衡上又引出了新的问题。 由于我们无法在连接层面进行均衡，为了做 gRPC 负载...

污点与容忍 亲和性/反亲和性无论是硬策略还是软策略方式，都是调度 pod 到预期节点上，而Taints恰好与之相反，如果一个节点标记为 Taints ，除非 pod 也被标识为可以容忍污点节点，否则该 Taints 节点不会被调度 pod。 ​ 污点：taints ​ 容忍：tolerations 污点策略污点策略有以下选项： NoSchedule：表示 pod 不会被调度到标记为 taints 的节点 PreferNoSchedule：NoSchedule 的软策略版本，表示尽量不调度到污点节点上去 NoExecute：该选项意味着一旦 Taint 生效，如该节点内正在运行的 pod 没有对应 Tolerate 设置，会直接被逐出 污点 taint 标记节点的命令如下： 12$ kubectl taint nodes node02 test=node02:NoSchedulenode "node02" tainted 容忍上面的命名将 node02 节点标记为了污点，影响策略是 NoSchedule，只会影响新的 pod 调度，如果仍然希望...

Kubernetes 节点将conntrack_max值与节点上的 RAM 大小成比例地设置。高负载应用（尤其是在小型节点上）很容易超过conntrack_max，并导致连接复位和超时。 理论conntrack 是建立在 Netlifier 框架之上的功能。它对于高性能的 Kubernetes 复杂网络至关重要，其中节点需要跟踪数千个 Pod 和服务之间的连接信息。 在 Kubernetes 中, 默认值可以在 prometheus 指标中找到node_nf_conntrack_entries_limit（需要node_exporter） linux系统中可以通过以下指令查看【当然如果未配置过的话，默认值会以该公式「CONNTRACK_MAX = 内存 (bytes) / 16384 / (多少位 / 32)」计算出默认值】：sysctl net.netfilter.nf_conntrack_max conntrack_max值与节点的内存成正比，通常聚合代理类服务会需要持续跟踪大量连接【消耗大量的conntrack entries...