1.在离线混部-Koordinator Cpu Burst 特性 源码调研
2.在家庭私有云上实现 K8S 部署 kong 网关和 konga 管理后台
3.Kubernetes OOM 和 CPU Throttling 问题
4.开源免费的源码服务网格 Service Mesh
5.k8s-服务网格实战-入门Istio
6.kubernetes网络和CNI简介

在离线混部-Koordinator Cpu Burst 特性 源码调研

       在离线混部场景下，Koordinator引入了Cpu Burst特性来优化CPU资源管理。限流这个特性源自Linux内核的源码CPU Burst技术，旨在处理突发的限流CPU使用需求，减少CPU限流带来的源码影响。cgroups的限流好哥俩源码参数如cpu.share、cpu.cfs_quota_us和cpu.cfs_burst，源码分别控制了CPU使用率、限流配额和突发缓冲效果。源码在Kubernetes中，限流资源请求（requests.cpu）和限制（limits.cpu）通过这些参数来实现动态调整，源码以保证容器间公平的限流CPU分配。

       对于资源调度，源码Kubernetes的限流Bandwidth Controller通过时间片限制进程的CPU消耗，针对延迟敏感业务，源码如抖音视频服务，通过设置合理的CPU limits避免服务质量下降，同时也考虑资源的高效利用。然而，常规的限流策略可能导致容器部署密度降低，因为时间片间隔可能不足以应对突发的CPU需求。CPU Burst技术正是为了解决这个问题，通过收集未使用的CPU资源，允许在突发时使用，从而提高CPU利用率并减少throttled_time。

       在Koordinator的配置中，通过configMap可以调整CPU Burst的百分比，以及在负载过高时的调整策略。例如，当CPU利用率低于阈值时，允许动态扩展cfs_quota，以应对突发的CPU使用。源码中，会根据节点负载状态和Pod的QoS策略来调整每个容器的CPU Burst和cfs_quota。

       总的来说，Cpu Burst特性适用于资源利用率不高且短作业较多的场景，能有效提升核心业务的CPU资源使用效率，同时对相邻容器的影响较小。在某些情况下，结合cpuset的核绑定和NUMA感知调度可以进一步减少CPU竞争。理解并灵活运用这些技术，有助于优化云计算环境中的资源分配和性能管理。

在家庭私有云上实现 K8S 部署 kong 网关和 konga 管理后台

       Kong是一个开源的API网关框架，它具备众多高级功能，包括流量控制、API安全、服务发现、熔断、查看按钮源码限流等，旨在帮助开发者构建可扩展、可靠和安全的微服务应用程序。

       以下是Kong的一些主要特点：

       简单易用：Kong提供了一个简单的命令行接口和易于使用的配置文件系统，使得部署和管理API网关变得非常简单。

       多协议支持：Kong支持多种常见的HTTP/HTTPS协议，如HTTP、HTTPS、WebSocket等。

       灵活的配置：Kong允许用户根据需要自定义各种参数，例如限流、熔断、日志记录等。

       高度可扩展：Kong可以轻松地集成其他流行的服务发现、负载均衡和监控工具，例如Consul、Eureka和Prometheus等。

       社区支持：Kong是由一个活跃的开源社区开发的，这意味着用户可以获得很好的技术支持和文档资源。

       在K8S中部署Kong的步骤如下：

       1、如果还没有命名空间，先创建。

       2、在k8s的master节点进入任意目录新建kong-migrations.yaml、kong.yaml、konga.yaml三个文件，把如下信息粘贴进去：

       注意：kong-migrations.yaml这个POD是专门用来初始化数据库的，执行一次之后就可以删除了。

       注意：kong.yaml这里需要注意一下，我是把kong的端口映射到宿主机的和，确保你宿主机这两个常用端口没有被占用，还有个问题是k8s的nodePort端口范围为：-，配置文件直接写和，会报错，需要改下配置。

       找到kube-apiserver.yaml文件的绝对路径，其路径为"/etc/kubernetes/manifests/kube-apiserver.yaml"，并添加参数"- --service-node-port-range=1-"，如下所示：

       不需要重启，过一会自动就生效了。

       注意：konga.yaml这里我使用了NFS把konga的文件映射出来，这样当Pod被销毁或者被调度到其他节点之后数据都不会丢失，你如果还没有安装NFS服务器可以参考我之前写的“在家庭私有云上实现 Docker 部署 NFS 网络文件系统”这篇文章。

       执行kubeclt命令。

       我们打开k8s-dashboard管理后台瞄一眼：

       然后在浏览器输入master节点的ip+端口：打开konga管理后台，输入如下信息，让konga管理kong的源码搜索指标路由配置：

       连接成功：

       在konga管理后台验证成功后，如何验证kong网关是否能够正常提供服务呢？首先拿出我的域名，这个域名没有备案，但是我把它解析到k8s的master节点的内网ip，仅仅做内网使用是没问题的。

       在konga管理后台点开服务管理，新建服务，填入如下信息：

       接着点开Routes选项卡，配置通过 konga.azyu.cc访问：

       点击保存，之前我们是通过IP加端口的方式访问konga管理后台，现在可以通过域名，在浏览器输入 konga.azyu.cc，大功告成！

Kubernetes OOM 和 CPU Throttling 问题

       使用 Kubernetes 时，内存不足（OOM）错误和 CPU 限制（Throttling）是云应用程序中资源处理的主要难题。为什么会出现这种情况呢？

       云应用程序中的 CPU 和内存要求变得越来越重要，因为它们与您的云成本直接相关。

       通过配置 limits 和 requests，您可以确定 pod 如何分配内存和 CPU 资源，从而避免资源短缺并调整云成本。

       那么，如何监控 Pod 是否快要发生 OOM 或 CPU 被限制了呢？

       Pod 中的每个容器都需要内存才能运行。

       Kubernetes limits 是在 Pod 定义或 Deployment 定义中为每个容器设置的。

       所有现代 Unix 系统都有一种方法可以杀死进程，以此回收内存（当没有空闲内存时，只能杀进程了）。这个错误将被标记为 错误码或 OOMKilled。

       退出代码 表示该进程使用的内存超过允许的数量，必须被 OS 终止。

       这是 Linux 中的一项功能，内核为系统中运行的进程设置 oom_score 值。此外，它还允许设置一个名为 oom_score_adj 的值，Kubernetes 使用该值来实现服务质量。它还具有 OOM Killer，它将检查进程并终止那些使用过多内存（比如申请了超过 limits 限制的数量的内存）的进程。

       请注意，在 Kubernetes 中，进程可能会达到以下任何限制：内存过量分配。

       限制（limits）可以高于请求（requests），因此所有限制的总和可以高于节点容量。这称为过量分配，并且很常见。实际上，如果所有容器使用的内存多于 request 的内存，则可能会耗尽节点中的内存。这通常会导致一些 pod 死亡，以释放一些内存。博客产品源码

       在 Prometheus 生态中，使用 node-exporter 时，有一个名为 node_vmstat_oom_kill 的指标。跟踪 OOM 终止何时发生非常重要，但您可能希望在此类事件发生之前抢占先机并了解其情况。

       我们更希望的是，检查进程与 Kubernetes limits 的接近程度：

       CPU 限制（throttling）是一种当进程即将达到某些资源限制时减慢速度的行为。与内存情况类似，这些限制可能是：

       想想下面的类比。我们有一条高速公路，交通流量如下：

       这里的 throttling 被表示为交通拥堵：最终，所有进程都会运行，但一切都会变慢。

       CPU 在 Kubernetes 中通过shares 进行处理。每个 CPU 核心被分为 个 shares，然后使用 Linux 内核的 cgroups（control groups）功能在运行的所有进程之间进行划分。

       如果 CPU 可以处理当前所有进程，则无需执行任何操作。如果进程使用超过 % 的 CPU，shares 机制就要起作用了。与任何 Linux 内核一样，Kubernetes 使用 CFS（Completely Fair Scheduler）机制，因此拥有更多份额的进程将获得更多的 CPU 时间。

       与内存不同，Kubernetes 不会因为限流而杀死 Pod。

       You can check CPU stats in /sys/fs/cgroup/cpu/cpu.stat

       正如我们在 limits 和 requests 文章中看到的，当我们想要限制进程的资源消耗时，设置 limits 或 requests 非常重要。尽管如此，请注意不要将总 requests 设置为大于实际 CPU 大小，每个容器都应该有保证的 CPU。

       您可以检查进程与 Kubernetes limits 的接近程度：

       如果我们想要跟踪集群中发生的限制量，cadvisor 提供了 container_cpu_cfs_throttled_periods_total 和 container_cpu_cfs_periods_total 两个指标。通过这两个指标，您可以轻松计算所有 CPU 周期内的限制百分比。

       Limits 是在节点中设置资源最大上限的一种方法，但需要谨慎对待，因为您可能最终会受到限制或终止进程。

       准备好应对驱逐

       通过设置非常低的请求，您可能认为这将为您的进程授予最少的 CPU 或内存。但 kubelet 会首先驱逐那些使用率高于请求的 Pod，因此就相当于您将这些进程标记为最先被杀死的！

       如果您需要保护特定 Pod 免遭抢占（当 kube-scheduler 需要分配新 Pod 时），请为最重要的进程分配 Priority Classes。

       Throttling 是一个无声的敌人

       设置不切实际的 limits 或过度使用，您可能没有意识到您的进程正在受到限制并且性能受到影响。主动监控 CPU 用量，多多提源码了解确切的容器和命名空间层面的限制，及时发现问题非常重要。

       下面这张图，比较好的解释了 Kubernetes 中 CPU 和内存的限制问题。供参考：

       本文翻译自： sysdig.com/blog/trouble...

开源免费的服务网格 Service Mesh

       服务网格是一种微服务管理的软件基础设施，旨在简化和提升服务间通信的可靠性和可扩展性。其核心在于Sidecar模式，分离服务的通信功能与应用业务，Sidecar代理负责服务间的通信，业务代码仅与其他进程的代理通信。

       Conduit是轻量级、高性能且易于理解和使用的ServiceMesh框架，与Kubernetes集成，提供服务发现、负载均衡、熔断和限流功能。它使用Rust语言开发数据平面，Go语言开发控制平面，内存占用极小。

       Consul Connect是基于Consul的服务网格，支持服务注册、发现、负载均衡、路由、熔断等功能，提供应用间双向TLS连接，侧重应用安全。

       Envoy是Lyft开发的高性能服务网格框架，适用于大规模应用，作为数据层代理，负责服务网格中应用间流量管理。

       Istio是一个强大的开源服务网格，提供统一的路径保护、连接和监控服务，无需修改服务代码即可实现负载平衡、服务间身份验证和监控。

       Kuma是Kong开发的开源服务网格框架，提供跨集群全局控制平面、多环境服务网格、安全性和策略等功能，支持Kubernetes和虚拟机。

       Linkerd是Kubernetes服务网格的开源解决方案，提供服务间通信、故障处理、负载平衡和安全性功能，以轻量级、安全优先为特点。

       Maesh是Containous开发的开源服务网格框架，基于Traefik的反向代理和负载均衡器，提供简单且易于使用的服务网格，增强服务间连通性。

       Open Service Mesh由Microsoft开发的开源框架，支持最新服务网格标准SMI，提供简单易用的服务网格功能。

k8s-服务网格实战-入门Istio

       进入服务网格系列，前面已讲解基本知识，但企业中存在复杂应用调用关系，需要管理限流、降级、trace、监控、负载均衡等功能。

       在kubernetes出现之前，这些问题通常由微服务框架解决，如Dubbo、SpringCloud等。但kubernetes出现后，这些功能应交给专门的云原生组件，即本篇将讲解的Istio，它是目前最广泛使用的服务网格解决方案。

       官方对Istio的解释简洁，具体功能包括限流、降级、trace、监控、负载均衡等。Istio分为控制面control plane和数据面data plane，控制面负责Istio自身管理功能，数据面由Envoy代理业务应用，实现流量管理。

       首先安装Istio命令行工具，确保有kubernetes运行环境，Linux使用特定命令，Mac使用brew，其他环境下载Istio配置环境变量。

       使用install命令安装控制面，默认使用kubectl配置的kubernetes集群，使用demo profile。

       为namespace添加label，使得Istio控制面知道哪个namespace下的Pod自动注入sidecar，为default命名空间开启自动注入，部署deployment-istio.yaml。

       每个Pod有两个container，其中一个istio-proxy sidecar，进行负载均衡测试，效果相同，说明Istio生效。

       观察sidecar日志，看到所发出和接收到的流量。

       本期内容简单，主要涉及安装配置，下期将更新内部服务调用的超时、限流等功能配置。

       大部分操作偏运维，后续功能配置只需编写yaml资源。

       生产使用时，提供管理台可视化页面，方便开发者灵活配置功能。

       各大云平台厂商提供类似能力，如阿里云的EDAS等。

       本文源码可访问github.com/crossoverJie...

kubernetes网络和CNI简介

        对于任何kubernetes网络方案，都需要满足以下需求：

        容器通过使用linux内核提供的Cgroups和Namespaces技术实现了相互之间的网络、存储等资源的隔离与限制。对于网络，kubernetes项目中的Pod则通过让一组用户容器和pause容器/infra容器共享一个network namespace的方式，使一个Pod内的容器都使用了一个网络栈。而一个 Network Namespace 的网络栈包括：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和 iptables 规则。所以，不难想象，Pod的网络和一台虚拟机的网络栈配置起来实际上是类似的，比如同样需要虚拟网卡，IP、MAC地址等，并且每个Pod都有自己唯一的网络栈。当所有的Pod都有了自己的网络栈后，如果想要连接两个Pod进行通信，则类似于其他任何网络架构，需要配置交换机、路由器等，并为其规划IP，路由等信息。如果是对于物理机，我们可以使用网线、交换机、路由器这些设备进行连接，但在Pod中显然需要其他方式。

        kubernetes Pod的网络方案有很多，最典型的就是Flannel的三种后端实现方式了（UDP、VxLan、host-gw），讨论这些则主要是在关注容器跨主机通信的问题。而这里主要讨论的则是Pod的内部的网卡如何创建，又如何将网络数据包在宿主机和容器之间传递。

        图片来自 这里

        CNI是Container Network Interface的缩写，它是一个通用的容器网络插件的k8s网络接口，开源社区里已经有了很多实现容器网络的方案，不同的网络实现方案在k8s内都是以插件调用的形式工作，所以这里需要一个统一的标准接口。如果将k8s的Pod视为一台“虚拟机”，那么网络插件的工作就是管理这台虚拟机的网络栈，包括给这台虚拟机插入网卡、配置路由、IP等；而CNI的工作则是对接网络插件和kubelet容器运行时管理工具（对于docker容器运行时来说实际上是dockershim），主要体现在Pod的创建和删除过程：

        CNI 配置文件，给CRI使用的，比如dockershim

        CNI官方维护的插件包括以下几个，对于已经搭建好的k8s，cni插件可以在 /opt/cni/bin/ 文件夹下查看：

        CNI的基础可执行文件按照功能可以划分为三类：

Main插件：创建具体网络设备

        bridge ：网桥设备，连接container和host

        ipvlan ：为容器增加ipvlan网卡

        loopback ：lo设备

        macvlan ：为容器创建一个MAC地址

        ptp ：创建一对Veth Pair

        vlan ：分配一个vlan设备

        host-device ：将已存在的设备移入容器内

        IPAM插件：负责分配IP地址

        dhcp ：容器向DHCP服务器发起请求，给Pod发放或回收IP地址

        host-local ：使用预先配置的IP地址段来进行分配

        static ：为容器分配一个静态IPv4/IPv6地址，主要用于debug

        meta插件：并非单独使用

        bandwidth ：使用Token Bucket Filter（TBF）来限流的插件

        flannel ：flannel网络方案的CNI插件，对应于flannel配置文件

        portmap ：通过iptables配置端口映射

        sbr ：为网卡设置source based routing

        tuning ：通过sysctl调整网络设备参数

        firewall ：通过iptables给容器网络的进出流量进行一系列限制

        实验内容：go安装社区维护的CNI相关插件，在linux主机上创建一个network namespace，再利用安装的网络插件给这个linux network namespace配置好网络。实验方法教程参考的是 这里

        安装cni插件：

        linux上创建一个network namespace：

        设置网络参数：

        vi /etc/cni/net.d/-myptp.conf

        模拟给容器配置网络：

        返回值

        测试网络是否可用：

        进入namespace，ping一下百度的DNS

        清除：

        最后多说一句，所谓的云服务其实就是基于网络的服务，好好规划网络可以充分利用数据中心的资源，只有充分利用数据中心的资源，才能称之为云计算。

在 EKS 集群中使用 Traefik 管理4/7层流量

       王跃祖和张杰合作的文章指出，在国内知名人工智能企业的业务容器化部署中，亚马逊云科技 Amazon Elastic Kubernetes Service (EKS) 采用了AWS Load Balancer Controller来管理4/7层服务流量。然而，考虑到客户业务的复杂性和对认证系统的需求，他们发现Traefik是一个更合适的选择。

       Traefik作为一款开源的负载均衡和反向代理工具，具有高效资源管理、动态配置、丰富中间件支持以及自动发现容器变化等特点。它能够简化配置，自动调整路由规则，支持多种负载均衡算法，并且能通过中间件实现认证、限流等功能。在EKS环境中，通过Helm部署Traefik 2.7.0版本，配合EKS v1..9-eks，可以有效替代原有的ALB和NLB，节省资源并提高管理效率。

       具体应用上，Traefik可以创建nginx应用和IngressRoute资源，提供HTTPS支持，实现路径重写、流量复制和身份验证。例如，通过HTTP跳转至HTTPS中间件，确保访问安全；使用IPWhiteList中间件，实现访问控制。Traefik的流量镜像功能，如将%流量镜像到测试版本，有助于业务测试和故障排查。

       最终，通过将+个负载均衡器简化为Traefik服务，不仅降低了成本，还增强了系统的安全性和灵活性。可视化的Traefik Dashboard提供了更好的监控和管理体验。综上，Traefik的引入带来了显著的收益和提升。

KubeVela 1.7 版本解读：接管你的已有工作负载

       接管工作负载

       KubeVela 1.7 版本发布，引入了工作负载接管功能，让已有工作负载能自然迁移到标准化体系中，被统一管理。接管提供两种模式：“只读”与“接管”。前者适用于内部已有平台，能以只读方式统一观测应用。后者适用于直接迁移场景，自动接管工作负载，实现统一管理。

       使用策略（policy）体系定义接管规则，选择器区分资源类型，确保应用创建时可纳入管理，复用配置。在“只读”策略中，资源如“Deployment”是只读的，运维特征创建和修改“Ingress”、“Service”不受影响。在“接管”策略中，资源可控，应用创建时能将已有资源纳入管理，仅将对“scaler”运维特征的实例数修改作为配置。

       通过命令行一键接管工作负载，方便快捷。使用`vela adopt`命令，指定资源类型、命名空间与名称，自动生成接管的`Application`对象。命令默认使用“只读”模式，支持原生资源、Helm应用及批量接管命名空间下全部工作负载。

       接管规则灵活定义，基于可扩展设计原则，使用CUE定义配置转换规则。命令行一键接管是规则的一种特例，适用于高阶用户，更多细节可参考官方文档。

       大幅性能优化

       性能优化是1.7版本亮点之一，整体性能、单应用容量、应用处理吞吐量提升5到倍，涉及资源配额调整、压缩功能、应用与组件版本记录上限降低、参数调整等。

       通过ztsd压缩功能，默认开启，资源大小压缩近倍，单个KubeVela Application资源容量扩大倍。应用版本记录上限从个减少到2个，组件版本默认关闭，控制器内存消耗缩小1/3。定义历史版本记录从个减少到2个，Kubernetes API交互限流QPS从提升到。

       易用性提升

       客户端支持多环境资源渲染，实现策略(policy)和工作流(workflow)根据不同环境自定义生成不同实际资源。应用删除功能增强，交互式删除资源，保留下层资源或保留应用元数据。插件安装后自定义输出，允许制作者动态输出安装提示。工作流能力增强，支持更多细粒度操作，包括在工作流中构建镜像并推送到镜像仓库。

       VelaUX控制台增强功能，包括用户界面和操作优化。KubeVela 1.8版本预计在3月底发布，规划包括进一步增强功能。社区欢迎参与讨论，成为贡献者或合作伙伴，详情可访问GitHub社区页面。

kube-apiserver限流机制原理

       本文分享自华为云社区《kube-apiserver限流机制原理》，作者：可以交个朋友。

       背景：apiserver在Kubernetes中扮演核心角色，一旦遭遇恶意刷接口或请求量超负荷，apiserver服务可能崩溃，影响整个Kubernetes集群的可用性。因此，实现apiserver限流是提升Kubernetes健壮性的关键。

       k8s-apiserver限流能力演进：限流能力经历了两个阶段。在kubernetes 1.版本之前，限流主要分为变更和非变更请求类型，并通过配置参数设定最大并发数，但这限制了处理能力。随后，引入了APF（APIPriorityAndFairness）作为默认限流方式，以更细粒度分类和隔离请求，结合优先级和公平性策略处理。

       两个阶段对比显示了APF在分类颗粒度和隔离性方面的显著提升。老版本限流方法在处理大规模请求时，易导致性能瓶颈，影响其他客户端请求。而APF通过更精细的资源管理和策略配置，实现更高效、灵活的限流控制。

       APF关键资源介绍：APF包含FlowSchema和PriorityLevelConfiguration两个核心资源。FlowSchema解决分类颗粒度粗的问题，通过规则匹配请求，覆盖资源类型、操作类型、请求者身份和命名空间等维度。PriorityLevelConfiguration则解决隔离性差和优先级问题，定义限流细节，如队列数量、队列长度和是否可排队。关联规则匹配的请求，实现精细化管理。

       处理过程：请求与集群中的FlowSchema列表匹配，优先级较低的规则先进行匹配。匹配规则后，请求关联到指定的PriorityLevelConfiguration资源。资源中包含多个队列，根据请求分组分配队列数量，实现请求隔离。每个PriorityLevelConfiguration资源具备独立并发上限，确保公平性处理请求，避免恶意用户影响系统整体性能。

       实战示例：通过查看Kubernetes原生规则，创建自定义规则以限流特定资源。通过在不同命名空间中创建测试实例，模拟请求，分析apiserver日志信息，验证限流效果。实现对特定请求的限制，确保系统稳定运行。

       总结：通过深入了解kube-apiserver限流机制原理，掌握APF的分类、优先级管理和队列分配策略，可以有效提升Kubernetes集群的稳定性，防范大规模请求带来的风险，确保服务持续可用。