深入浅出 Kubernetes 项目网关与应用路由
KubeSphere 项目网关与应用路由提供了一种聚合服务的方式，将集群的内部服务通过一个外部可访问的 IP 地址以 HTTP 或 HTTPs 暴露给集群外部。应用路由定义了这些服务的访问规则，用户可以定义基于 host 主机名称和 URL 匹配的规则。同时还可以配置 HTTPs offloading 等选项。项目网关则是应用路由的具体实现，它承载了流量的入口并根据应用路由规则将匹配到的请求转发至集群内的服务。
Helm Tips
Helm 是最常用的 Kubernetes 包管理器之一。但实际应使用时却会面对各种复杂的问题，以下内容是对常见应用场景的简要总结： 将 kubectl 部署的资源转为 Helm 资源 如果您的项目最初不是使用 Helm 进行资源管理且已经部署在线上运行，那么你可能需要将已有资源转换 Helm 资源。 否则直接运行 helm install 这时你将看见如下错误信息： Error: rendered manifests contain a resource that already exists. Unable to continue with install: 解决这个问题的方法很简单，只需要将对应的资源打上 Helm 的 Label 和 Annotation 即可: KIND=deployment NAME=my-app-staging RELEASE=staging NAMESPACE=default kubectl annotate $KIND $NAME meta.helm.sh/release-name=$RELEASE kubectl annotate $KIND $NAME meta.
Kubernetes CNI 插件性能测试
网络性能是影响 Kubernetes 集群与应用性能的重要指标之一。同时网络架构也是 Kubernetes 中较为复杂模块之一，Kubernetes 通过开放 CNI 接口，实现了网络插件即插即用功能，CNI 插件的实现方式是影响网络性能的最主要因素。目前主流的 CNI 插件包括：Flannel、Calico、Weave、Canal 和 Cilium 等。除 CNI 插件外，Kube-proxy 运行模式也是影响网络性能的重要因素之一。 Kubernetes 通过 Kube-proxy 提供了集群内负载均衡的能力，其内置方式有 Iptables 和 IPVS 等两种。在不同的场景下，CNI 和 Kube-proxy 都会对网络性能产生显著的影响。本文着重对 Kubernetes 网络性能测试的方法以及影响因素进行讲解和分析，不包含具体插件的性能比较。 Kubernetes 网络通讯模式 在 Kubernetes 网络中，主要有以下几种通讯场景： 容器与容器之间的直接通信，通过本地回环实现，不通过网络插件协议栈，因此测试可以忽略。 Pod与Pod之间的通信，这是测试中的重点，同等条件(物理网卡带宽、CPU等)下性能主要受 CNI 插件影响。 Pod到Service之间的通信，会受到 CNI 与 Kube-proxy 的共同影响，因此也是测试的重点之一。 集群外部与内部组件之间的通信。集群外部访问的模式较多，链路较长，本文不做重点介绍。 除以上场景外，还需要考虑 POD 之间通讯是在同 NODE 与不同 NODE 等两种情况。如果再加上网络协议类型，那么我们需要考虑：通讯场景、协议、跨主机等三个维度的组合。以最常见的模式，我们可以得到以下8种组合：
Kubernetes 源码调试
前言 本文提供了一种基于 vscode 和 minikube 的快速搭建 Kubernetes 开发调试环境的方法。通过 devle 对 Kubernetes 各个组件进行远程调试。调试代码可以帮助你更深入地理解 Kubernetes 逻辑，更清晰的分析代码执行流程。 准备阶段 Clone kubernetes 源代码 参考官方文档，将 Kubernetes clone 到默认 $GOPATH (Ubuntu 默认路径: ~/go)下 mkdir -p $GOPATH/src/k8s.io cd $GOPATH/src/k8s.io git clone https://github.com/kubernetes/kubernetes cd kubernetes # 以 1.19.x 分支为例我们签出源代码 git checkout release-1.19 # 或签出指定 tag 版本 git checkout v1.19.3 Kubernetes 各个版本的编译对 golang 版本有依赖，例如编译 Kubernetes 1.
Kiosk 多租户扩展-基本概念
Kubernetes 多租户扩展 使用 Accounts 与 Account User 在共享的 Kubernetes 集群中区分租户 租户自助 Namespace 空间配置 Account Limits 账户配额保障服务质量与公平性 Namespace Templates 命名空间模板保证租户隔离与自助初始化 Namespace。 *多集群租户管理以共享集群池 Why kiosk Kubernetes 被设计为一个单租户平台，因此在单集群上实现多租户功能变得十分困难。然而，共享一个集群有很多优势，例如，资源利用率高，管理配置成本低，也可使租户更容易共享集群内部资源。 当然，创建多租户 Kubernetes 集群的方法有很多，许多 Kubernetes 发行版也提出了他们自己的租户逻辑，然而却没有一个种轻量级的，可热拔插，并可定制化的解决方案。使管理员可以在任何标准的 Kubernetes 集群之上增加多租户能力。 kiosk 愿景 100% 开源：使用 CNCF 兼容的 Apache 2.0 license 即插即用：可轻而易举地在任何已有集群中安装，适用于多种不同的场景 快速：着重于租户的自动化与自助服务 安全：为不同级别的租户隔离提供默认配置 可扩展：providing building blocks for higher-level Kubernetes platforms 架构 kiosk 的核心理念是使用 Kubernetes Namespace 作为隔离的工作空间，租户的应用可以运行在彼此隔离的空间中。为了降低管理成本，集群管理员应该配置 kiosk，然后它将成为一个租户可以在 Kubernetes 中自助配置 Namespace 的系统。