k8s

前言微服务架构场景中，应用系统复杂切分散。长期运行时，局部出现故障时不可避免的。如果发生故障时不能进行有效反应，系统的可用性将极大地降低。 什么是故障演练 故障演练是指模拟生产环境中可能出现的故障，测试系统或应用在面对故障时的反应和响应能力。 故障演练可以模拟各种故障情况（网络故障、数据库故障、服务过载，CPU或内存异常等）。 什么是混沌工程 混沌工程是稳定性方面的工程学科，英文叫作 Chaos Engineering，是由网飞公司最先提出的，因为最开始混沌工程被叫作 Chaos Monkey， 就像一只猴子在系统中捣乱一样，以至于到现在每次出现混沌工程都会提及一只捣乱的猴子的比喻。但是稳定性测试却不是网飞独创的，在混沌工程之前，就 已经有很多关于稳定性方面的研究了。随着测试系统的业务逻辑越来越复杂，交付团队不断地通过细化测试、增加发布环节以及各种流程管控，来保障的系统 的稳定性，但是的系统还是会出现各式各样的故障，混沌工程就是本着提早暴露系统脆弱环节的理念，以提高系统的稳定性为目的而出现的。 为什么需要故障演练故障演练是微服务架构下非常重要的实践，用以测试系统或应用在面对故...

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

转自: https://blog.51cto.com/u_15127588/3305078 JetBrains 系列 IDE 有一个非常好用的 Kubernetes 的官方插件：JetBrains Kubernetes Plugin 。该插件支持资源对象关键字的自动补全和语法检查，这对于编写或者修改 YAML 文件非常方便。但是此前版本不支持 自定义的 CRD 对象，这对于该插件的易用性来说，略有一些遗憾。 现在新版的 Kubernetes 插件已经支持通过文件导入或者 URL 导入 CRD 定义文件，从而支持任意 CRD 资源对象的关键字自动补全和语法检查。 12Custom resource definition (CRD) supportCustom resources can be validated by providing complementary OpenAPI 2.0 files with CRD schemas and/or CRD resource definitions (YAML) (limited support). 下面以服务网格 Istio ...

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-proxy也是我们常说的sidecar，istio默认使用envoy注入的，envoy的日志级别包括trace, debug, info, warning, error, critical, off Envoy 访问日志记录了通过 Envoy 进行请求 / 响应交互的相关记录，可以方便地了解具体通信过程和调试定位问题。 修改日志级别的几种方式全局配置istio配置都是在configmap中的，可以通过修改configmap来修改全局的proxy日志级别： 开启 Envoy 访问日志，执行以下命令修改 istio 配置1kubectl -n istio-system edit configmap istio 1234data: mesh: |- accessLogEncoding: JSON accessLogFile: /dev/stdout 其中，accessLogEncoding表示 accesslog 输出格式，Istio 预定义了 TEXT 和 JSON 两种日志输出格式。默认使用 TEXT，通常改成 JSON 以提升...

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

参考：https://cloud.tencent.com/developer/article/1746649 Kubernetes K8S之Node节点亲和性与反亲和性以及Pod亲和性与反亲和性详解与示例 主机配置规划 服务器名称(hostname) 系统版本 配置 内网IP 外网IP(模拟) k8s-master CentOS7.7 2C/4G/20G 172.16.1.110 10.0.0.110 k8s-node01 CentOS7.7 2C/4G/20G 172.16.1.111 10.0.0.111 k8s-node02 CentOS7.7 2C/4G/20G 172.16.1.112 10.0.0.112 亲和性和反亲和性nodeSelector提供了一种非常简单的方法，将pods约束到具有特定标签的节点。而亲和性/反亲和性极大地扩展了可表达的约束类型。关键的增强是： 1、亲和性/反亲和性语言更具表达性。除了使用逻辑AND操作创建的精确匹配之外，该语言还提供了...

之所以叫做 K3S 是因为希望安装的 K8S 在内存占用方面只是一半的大小，而一半大的东西就是一个 5 个字母的单词，简写为 K3S。 k3s 特点 k3s 是由 Rancher Lab 开源的轻量级 Kubernetes。k3d 完美继承了 k3s 的简单、快速和占用资源少的优势，镜像大小只有 100 多 M，启动速度快，支持多节点集群。虽然 k3s 对 Kubernetes 进行了轻量化的裁剪，但是提供了完整了功能，像 Istio 这样复杂的云原生应用都可以在 k3s 上顺利运行。 因为 k3s 本身应用场景主要在边缘侧，所以支持的设备和架构很多，如：ARM64 和 ARMv7 处理器。很多老旧 PC 和树莓派这样的设备都可以拿来做成 k3s 集群，为本地研发测试燃尽最后的生命。 k3s是打包为单个二进制文件 把 K8S 相关的组件，比如 kube-api/ kube-manager 都打包到同一个二进制文件里面，这样的话，只需要启动这个文件就可以快速的启动对应的组件。 使用基于 sqlite3 的默认存储机制 同时支持使用 etcd3、MySQL 和...