云原生

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

概述本文总结了京东在混沌工程领域的实践经验，介绍如何通过主动注入故障的方式提前发现系统隐患，以及如何在实际业务场景中进行混沌演练。 核心内容： 🎯 混沌工程的基本概念和价值 🔄 完整的混沌演练流程 📊 典型演练场景和监控指标 🔗 业务链路演练实践 文章来源： 京东云开发者社区 - 混沌工程基础 京东云开发者社区 - 链路演练实践 混沌工程基础什么是混沌工程混沌工程是通过主动制造故障场景并根据系统在各种压力下的行为表现确定优化策略的一种系统稳定性保障手段。 核心理念： 🔍 主动发现：在生产环境出问题之前主动找出隐患 🛡️ 提前加固：针对发现的脆弱点进行针对性加固 📈 持续改进：通过反复演练不断提升系统韧性 简单来说： 通过主动注入故障的方式，提前发现问题，然后解决问题规避风险。 为什么要进行混沌演练架构复杂度挑战： 随着互联网业务发展，微服务架构、分布式架构和虚拟化容器技术的广泛普及： 📐 软件架构的复杂度不断提升 🔗 服务之间的依赖呈指数级增长 🦋 任何一环的变化都可能产生蝴蝶效应 业务增长压力： 目前营销体系的挑战： 服务量级不断增加 整体...

在微服务架构场景中，应用系统复杂且分散，长期运行时局部故障不可避免。如果不能有效应对故障，系统的可用性将极大降低。本文介绍混沌工程和故障演练的概念、实践方法及工具平台。 核心概念什么是故障演练故障演练是指模拟生产环境中可能出现的故障，测试系统或应用在面对故障时的反应和响应能力。 故障演练可以模拟的场景包括： 网络故障（延迟、丢包、分区） 数据库故障（连接失败、查询超时） 服务过载（高并发、限流） 资源异常（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 编写效率

1. Service 端口命名约束Istio 支持多平台，不过 Istio 和 Kubernetes 的兼容性是最优的，不管是设计理念，核心团队还是社区，都有一脉相承的意思。但 Istio 和 Kubernetes 的适配并非完全没有冲突，一个典型问题就是 Istio 需要 Kubernetes service 按照协议进行端口命名（port naming）。 端口命名不满足约束而导致的流量异常，是使用 mesh 过程中最常见的问题，其现象是协议相关的流控规则不生效，这通常可以通过检查该 port LDS 中 filter 的类型来定位。 原因Kubernetes 的网络对应用层是无感知的，Kubernetes 的主要流量转发逻辑发生在 node 上，由 iptables/ipvs 来实现，这些规则并不关心应用层里是什么协议。 Istio 的核心能力是对 7 层流量进行管控，但前提条件是 Istio 必须知道每个受管控的服务是什么协议，istio 会根据端口协议的不同，下发不同的流控功能（envoy filter），而 Kubernetes 资源定义里并不包括七层协议信...

Kubernetes 中如何实现灰度发布当你Kubernetes 集群中部署业务时，可以利用 Kubernetes 原生提供的灰度发布的方式去上线业务。这种方式是通过在旧版本和新版本的服务之间，定义一个差异化的 Label，根据不同版本之间的公共 Label 负载流量到后端 Pod，最终实现根据 Pod 的副本数控制流量的百分比。 如下图所示：用户定义了两个 Deployment 对象，其中旧版本名为 frontend-stable，有3个副本。新版本为 frontend-canary，有1个副本。此时定义了一个 Service 对象，使用它们之间公共的 Label 进行选择。这就使得用户访问 frontend 这个 Service 时，能以 3:1 的比例同时访问到两个版本。并且还可以通过调整副本数持续控制流量比例，最终达到完整上线。 Kubernetes 默认的实现方式在简单的部署场景下很有效，但是在一些复杂场景中，仍然会有较大的局限，如： 业务配置自动伸缩后，会直接影响灰度发布的流量比例 低百分比的流量控制占用资源高，如 1 % 的流量到达新版本，则至少需要 100 ...

需求 同一套环境, 两个微服务serviceA和serviceB, 且分别有2个版本original, v1 调用链路: serviceA -> serviceB 具体分为以下几种情况 如果serviceA和serviceB都有v1版本 serviceA(v1) -> serviceB(v1) 如果serviceA有v1版本, serviceB没有 serviceA(v1) -> serviceB(original) 如果serviceA没有v1版本, 而serviceB有 serviceA(original) -> serviceB(v1) 技术方案流量染色 什么是流量染色 在元数据中心(这里可以代指我们的k8s集群)，维护每个环境对应的服务列表；在流量的入口处，对请求添加标识；在基础框架层，对流量标识进行解析、透传 和 服务路由。 实际操作一般是在我们的 HTTP 请求中，加入对应环境，用户等变量标识，使请求可以根据这些标识做分类，转发等操作 为什么需要流量染色 使不同的服务，共享环境 可以本地调试特定的服务，而不阻碍服务的正常运行 ...

Istio Envoy 访问日志的配置与查看方法，包括全局配置、动态调整和日志字段详解

前言Jaeger 是一个开源的端到端的分布式跟踪系统， 允许用户在复杂的分布式系统中监控和排查故障。 利用Rancher的安装方式安装cert-manager参考文档： jaeger requires：https://www.jaegertracing.io/docs/1.49/operator/#prerequisite cmctl（the tool which is to manage and verify cert-manager） install：https://cert-manager.io/v1.6-docs/usage/cmctl/#installation cert-manager verify：https://cert-manager.io/v1.6-docs/installation/verify/ 安装cert-manager：https://cert-manager.io/v1.6-docs/installation/kubectl/ 默认静态安装cert-manager：https://cert-manager.io/v1.6-docs/installa...