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-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的安装及简单使用
前言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...
Pod/Node亲和性和反亲和性部署
参考:https://cloud.tencent.com/developer/article/1746649 Kubernetes K8S之Node节点亲和性与反亲和性以及Pod亲和性与反亲和性详解与示例...
k3s介绍
之所以叫做 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...
k3s在启动后修改配置参数
https://github.com/k3s-io/k3s/discussions/5434#discussioncomment-2568382 例如修改端口和单节点最大pod数量(apiserver参数配置在master)master vim /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' systemctl daemon-reload systemctl restart k3s node vim...
记录k3s的升级过程(v1.21.7+k3s1 -> v1.24.3+k3s1)
参考官网链接: https://docs.rancher.cn/docs/k3s/upgrades/_index/ 注:如果要对server/master节点升级,绝对不要在流量高峰场景下进行 如果不希望清理所有容器及网络组件,不要轻易使用k3s-killall.sh脚本 官方文档描述升级过程为高可用模式,但最好还是在流量低峰期进行升级 否则可能会导致部署单元多个pod都部署在同一节点, 然后进行了pod转移, 如下 k8s在1.22版本新增了安全sysctlc参数net.ipv4.ip_unprivileged_port_start, 且需要将内核版本升级至4.4以上: https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/#enabling-unsafe-sysctls 我的sysctl配置 1234567891011121314151617181920# 将桥接的IPV4流量传递到iptables的链, Disable the swap...cat >...