Kubernetes

引言Helm 是 Kubernetes 的包管理器，它如同 Linux 系统中的 apt 或 yum，能够帮助开发者和运维人员轻松地查找、分享和使用为 Kubernetes 构建的软件。通过将一组相关的 Kubernetes 资源打包成一个称为 "Chart" 的单元，Helm 极大地简化了复杂应用的部署、升级和管理过程。 本指南将从 Helm 的安装开始，逐步深入到其核心概念和常用命令，为你提供一个全面而实用的 Helm 使用手册。 一、Helm 的安装在 Linux 系统上安装 Helm 非常直接。以下步骤以 Helm 3.8.0 为例： 1. 下载 Helm 二进制文件从 Helm 的官方发布页面或镜像站点下载适合你系统的二进制压缩包。 12# 从官方推荐的源下载wget https://get.helm.sh/helm-v3.8.0-linux-amd64.tar.gz 2. 解压文件将下载的压缩包解压。 1tar -zxvf helm-v3.8.0-linux-amd64.tar.gz 3. 移动到系统路径并授权将解压出的 helm 可执行文件移...

概述在 Kubernetes 环境中，经常需要从本地访问集群内部的服务（如 Redis、MySQL 等），但出于安全考虑，这些服务通常不对外暴露。本文介绍如何利用已有的 Pod 作为跳板，安全地从本地连接到内部服务。 核心方案： 🔐 Pod 作为代理跳板 🔄 socat 端口转发 🛡️ kubectl port-forward 隧道 🚀 无需暴露服务到公网 适用场景： 访问内部数据库（Redis、MySQL、MongoDB） 调试集群内部服务 开发环境数据查询 临时访问未暴露的服务 方案架构网络拓扑12345本地电脑 (127.0.0.1:6379) ↓ kubectl port-forwardPod (my-app:6379) ↓ socat 代理内部服务 (Redis:10.244.0.5:6379) 流量路径1234567本地 Redis 客户端 → localhost:6379 → kubectl port-forward 隧道 → Pod:6379 → socat 监听 → 转发到 10.244.0.5:637...

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

引言在 Kubernetes (K8s) 环境中，gRPC 作为一种高性能的 RPC 框架被广泛应用。然而，许多开发者在实践中发现，标准的 K8s Service 似乎无法对 gRPC 服务进行有效的负载均衡，导致所有请求都涌向了单个 Pod。本文将深入探讨这个问题的根源，并详细介绍四种主流的解决方案。 参考资料: gRPC Load Balancing on Kubernetes K8s环境下部署gRPC的几种方案 问题的根源：L4 vs L7 负载均衡传统的 K8s Service（如 ClusterIP）工作在 L4（传输层），它通过 kube-proxy 使用 IPtables 或 IPVS 来分发 TCP/UDP 流量。这种模式对于大多数基于 HTTP/1.1 的服务工作得很好，因为每个请求通常对应一个新的 TCP 连接。 然而，gRPC 构建于 HTTP/2 之上，其核心特性之一是多路复用（Multiplexing）。客户端与服务端之间会建立一个长期存在的 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 调度，如果仍然希望...

在微服务架构场景中，应用系统复杂且分散，长期运行时局部故障不可避免。如果不能有效应对故障，系统的可用性将极大降低。本文介绍混沌工程和故障演练的概念、实践方法及工具平台。 核心概念什么是故障演练故障演练是指模拟生产环境中可能出现的故障，测试系统或应用在面对故障时的反应和响应能力。 故障演练可以模拟的场景包括： 网络故障（延迟、丢包、分区） 数据库故障（连接失败、查询超时） 服务过载（高并发、限流） 资源异常（CPU、内存、磁盘异常） 什么是混沌工程混沌工程（Chaos Engineering）是稳定性方面的工程学科，最早由 Netflix 公司提出。最初被称为 Chaos Monkey，形象地比喻为一只在系统中"捣乱"的猴子。 混沌工程的核心理念： 主动暴露系统脆弱环节 提前发现潜在问题 提高系统稳定性和容错能力 虽然 Netflix 让混沌工程广为人知，但稳定性测试的研究由来已久。随着系统业务逻辑日益复杂，传统的测试手段已不足以保障系统稳定性，混沌工程应运而生。 为什么需要故障演练故障演练是微服务架构下的重要实践，至少可以在以下几个方面获得收益： 提前...

介绍 EnvoyFilter 提供了一种机制，可以自定义 Istio Pilot 生成的 Envoy 配置。使用 EnvoyFilter 修改某些字段的值、添加特定过滤器，甚至添加全新的监听器、集群等。这个功能必须小心使用，因为不正确的配置可能会破坏整个网格。与其他 Istio 网络对象不同，EnvoyFilters 是附加应用的。在特定命名空间中给定工作负载可以存在任意数量的 EnvoyFilters 。这些 EnvoyFilters 的应用顺序如下：所有位于配置根命名空间中的 EnvoyFilters ，然后是匹配工作负载命名空间中所有匹配到的 EnvoyFilters。 注意点注意1：此 API 的某些方面与 Istio 网络子系统以及Envoy XDS API 的内部实现密切相关。虽然EnvoyFilter API本身将保持向后兼容性，但通过此机制提供的任何 envoy 配置都应该在Istio代理版本升级时进行仔细监控，以确保已弃用字段被适当地删除和替换。 注意2：当多个Envoy Filters 绑定到给定名称空间中相同工作负载时，在创建时间顺序上按顺序处理所有补丁。...

为 JetBrains IDEA 配置 Istio CRD 智能提示，提升 YAML 编写效率