k8s

当我们在 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，例如它的名字是...

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...

安装 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...

...

前言微服务架构场景中，应用系统复杂切分散。长期运行时，局部出现故障时不可避免的。如果发生故障时不能进行有效反应，系统的可用性将极大地降低。 什么是故障演练 故障演练是指模拟生产环境中可能出现的故障，测试系统或应用在面对故障时的反应和响应能力。 故障演练可以模拟各种故障情况（网络故障、数据库故障、服务过载，CPU或内存异常等）。 什么是混沌工程 混沌工程是稳定性方面的工程学科，英文叫作 Chaos Engineering，是由网飞公司最先提出的，因为最开始混沌工程被叫作 Chaos...