k8s笔记 实例篇

01 金丝雀部署

金丝雀部署（Canary releases）是一种软件发布技术，可以通过将新版本的应用程序逐步部署到生产环境中的一小部分用户，来降低部署新软件版本的风险。如果新版本在初期测试中表现良好，它可以逐步推广到所有用户。
Istio控制流量的百分比

02 蓝绿部署

03 Ingress

04 istio

移除污点
kubectl taint nodes node-role.kubernetes.io/master-

001 istio中 addons是干嘛的？

在 Istio 中，“addons” 是指一组用于增强和扩展 Istio 功能的附加组件。这些附加组件提供了额外的功能和特性，可以帮助你更好地管理和监控你的服务网格。

Istio 的 “addons” 组件包括：

1. Grafana：一个流行的开源数据可视化工具，用于监控和展示 Istio 的度量指标。

2. Jaeger：一个分布式追踪系统，用于跟踪和调试请求在微服务架构中的流动情况。

3. Kiali：一个图形化的控制台工具，用于可视化和理解 Istio 网格的拓扑结构、流量状况、策略等。

4. Prometheus：一个用于监控和报警的开源系统，用于收集、存储和分析各种指标数据。

这些 “addons” 组件可以通过运行 kubectl apply -f samples/addons 命令来安装到 Istio 部署中。

通过添加这些附加组件，你可以更好地监控你的服务网格并获得更多的洞察力，同时也能够更好地管理和操作你的 Istio 部署。

002 istio功能

0001 请求路由

网页有三个版本，可以控制网页怎么刷新都只走v1版本，还有让jack用户登录后看到的是v2版本

0002 故障注入

05 service mesh

Problems

01 K8s Ingress 解决 “长连接” 负载不均衡的问题

在 Kubernetes (k8s) 环境中，长连接可能导致的负载不均衡问题是一个关键议题。长连接，即持久连接，是指客户端和服务器之间建立的TCP连接在传输完成后依然保持打开状态，以便后续的请求可以使用同一连接。这种机制对于减少建立连接的开销、提高性能很有帮助，但在负载均衡方面，可能会出现问题。

1. 问题描述：

   当使用基于连接的负载均衡（例如最简单的轮询机制）时，新的连接会被均匀分配到后端的各个服务器。但是，对于长连接的场景，一旦连接被建立并分配给了某个服务器，它会持续一段相对较长的时间。如果在这段时间内，有大量的请求沿着这些现存的连接发送，那么，即使某些服务器可能已经过载，新的请求还是会发送到这些服务器，因为连接已经建立。

   这种情况下，新启动的 pod 或者相对空闲的服务器可能接收不到足够的流量，因为它们没有与客户端建立足够的长连接。这就导致了不均衡的负载分配。

2. 举例说明：

   比如，一个在线游戏的后端运行在 Kubernetes 集群上，游戏客户端与服务器之间维持着长连接。在高峰期，成千上万的玩家同时在线。初始情况下，当玩家数量较少时，系统中的每个 pod 可能只处理少量的连接，但随着更多的玩家上线，新的连接会被创建，并可能会全部分配到某些 pod。

   假设此时扩展了集群，增加了更多的 pod。理想情况下，新的玩家应该连接到新的 pod 上，以实现负载均衡。但由于长连接的存在，现有的玩家仍连接在原有的 pod 上，继续给这些 pod 带来高负载，而新的 pod 可能却处于空闲状态，因为它们还没有收到新的连接。即使负载均衡器介入，但由于长连接已经建立，新的请求（游戏内的操作）仍然会沿着已有的连接发送，不会引导到新的 pod。

3. 解决方案：

   解决这种长连接导致的负载不均衡问题的一种方法是引入更智能的负载均衡机制，比如基于请求的负载均衡或者使用一些算法（如最少连接方法）动态地重新分配连接。

   另外，可以在应用层面上做一些优化，例如，通过在应用程序中实现断线重连逻辑，定期让客户端重新连接服务器，这样新的连接就有机会被重新均衡分配到不同的服务器上。

在使用 Kubernetes 和长连接时，理解这些挑战并采取适当的策略是非常重要的，以确保系统可以高效、公平地处理不同的负载。