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 资源定义里并不包括七层协议信...
利用 Istio 实现灰度发布
Kubernetes 中如何实现灰度发布当你Kubernetes 集群中部署业务时，可以利用 Kubernetes 原生提供的灰度发布的方式去上线业务。这种方式是通过在旧版本和新版本的服务之间，定义一个差异化的 Label，根据不同版本之间的公共 Label 负载流量到后端 Pod，最终实现根据 Pod 的副本数控制流量的百分比。 如下图所示：用户定义了两个 Deployment 对象，其中旧版本名为 frontend-stable，有3个副本。新版本为 frontend-canary，有1个副本。此时定义了一个 Service 对象，使用它们之间公共的 Label 进行选择。这就使得用户访问 frontend 这个 Service 时，能以 3:1 的比例同时访问到两个版本。并且还可以通过调整副本数持续控制流量比例，最终达到完整上线。 Kubernetes 默认的实现方式在简单的部署场景下很有效，但是在一些复杂场景中，仍然会有较大的局限，如： 业务配置自动伸缩后，会直接影响灰度发布的流量比例 低百分比的流量控制占用资源高，如 1 % 的流量到达新版本，则至少需要 100 ...
单环境多分支并行开发方案（流量染色 / Istio）
需求 同一套环境, 两个微服务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 请求中，加入对应环境，用户等变量标识，使请求可以根据这些标识做分类，转发等操作 为什么需要流量染色 使不同的服务，共享环境 可以本地调试特定的服务，而不阻碍服务的正常运行 ...
查看 Envoy 访问日志
Istio Envoy 访问日志的配置与查看方法，包括全局配置、动态调整和日志字段详解
Jaeger 的安装及简单使用
前言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...
K8s 安装部署 MongoDB
MongoDB 高可用模式MongoDB 的部署方式有： Standalone 单节点部署此种部署方式是最简单易用并且常见的部署了，直接使用 mongod 启动一个进程。 Master-Slave 主从结构主从架构一般用于备份或者做读写分离。一般有一主一从和一主多从两种设计方式。 主（Master）：可读可写，当数据有修改的时候，会将 oplog 同步到所有连接的 slave 上。 从（Slave）：只读不可写，自动从 Master 同步数据。 对于 MongoDB 来说，并不推荐使用 Master-Slave 架构，因为 Master 宕机后不能自动恢复，推荐使用 Replica Set（除非 Replica 的节点数超过 50，才需要使用 Master-Slave 架构，正常情况下不可能用那么多节点）。 另外，Master-Slave 不支持链式结构，Slave 只能直接连接 Master。Redis 的 Master-Slave 支持链式结构，Slave 可以连接 Slave。 Replica Set 副本集MongoDB 的 Replica Set（副本集）主要有...
Pod/Node 亲和性和反亲和性部署
参考：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 介绍
之所以叫做 K3s 是因为希望安装的 Kubernetes 在内存占用方面只是一半的大小，而一半大的东西就是一个 5 个字母的单词，简写为 K3s。 K3s 特点 轻量级且完整：K3s 是由 Rancher Lab 开源的轻量级 Kubernetes。K3d 完美继承了 K3s 的简单、快速和占用资源少的优势，镜像大小只有 100 多 MB，启动速度快，支持多节点集群。虽然 K3s 对 Kubernetes 进行了轻量化的裁剪,但是提供了完整的功能，像 Istio 这样复杂的云原生应用都可以在 K3s 上顺利运行。 支持多架构：因为 K3s 本身应用场景主要在边缘侧，所以支持的设备和架构很多，如 ARM64 和 ARMv7 处理器。很多老旧 PC 和树莓派这样的设备都可以拿来做成 K3s 集群，为本地研发测试燃尽最后的生命。 单二进制文件打包：K3s 把 Kubernetes 相关的组件，比如 kube-apiserver、kube-controller-manager 都打包到同一个二进制文件里面，这样的话，只需要启动这个文件就可以快速启动对应的组件。 灵活的存储后端：使用...
K3s 在启动后修改配置参数
参考：https://github.com/k3s-io/k3s/discussions/5434#discussioncomment-2568382 例如修改端口和单节点最大 Pod 数量（apiserver 参数配置在 master）Master 节点编辑 /etc/systemd/system/k3s.service（如果是使用 etcd 作为存储，配置文件在 /etc/systemd/system/multi-user.target.wants/k3s.service） 1234ExecStart=/usr/local/bin/k3s \ server \ '--kubelet-arg=max-pods=300' \ '--kube-apiserver-arg=service-node-port-range=30000-40000' 重新加载并重启服务： 12systemctl daemon-reloadsystemctl restart k3s Node 节点编辑 /etc/systemd/system/k3...
记录 K3s 的升级过程（v1.21.7+k3s1 -> v1.24.3+k3s1）
参考官网链接：https://docs.rancher.cn/docs/k3s/upgrades/_index/ 注：如果要对 server/master 节点升级，绝对不要在流量高峰场景下进行 如果不希望清理所有容器及网络组件，不要轻易使用 k3s-killall.sh 脚本 官方文档描述升级过程为高可用模式，但最好还是在流量低峰期进行升级 否则可能会导致部署单元多个 Pod 都部署在同一节点，然后进行了 Pod 转移，如下 Kubernetes 在 1.22 版本新增了安全 sysctl 参数 net.ipv4.ip_unprivileged_port_start，且需要将内核版本升级至 4.4 以上：https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/#enabling-unsafe-sysctls 我的 sysctl 配置： 1234567891011121314151617181920# 将桥接的 IPv4 流量传递到 iptables 的链，禁用 swapcat >...
公告