Kubernetes 跨 Namespace 服务访问与 gRPC 负载均衡实践指南
在 Kubernetes 中,服务发现和负载均衡是微服务架构的核心能力。然而,当服务分布在不同的 Namespace 中,或者使用 gRPC 协议时,一些"默认"机制并不能完全满足需求。本文将首先介绍跨 Namespace 访问服务的标准方法,然后深入剖析 gRPC 在 Kubernetes 中遇到的负载不均衡问题,并给出多种解决方案,帮助你在生产环境中构建稳定、高效的服务通信。
在 Kubernetes 中,服务发现和负载均衡是微服务架构的核心能力。然而,当服务分布在不同的 Namespace 中,或者使用 gRPC 协议时,一些"默认"机制并不能完全满足需求。本文将首先介绍跨 Namespace 访问服务的标准方法,然后深入剖析 gRPC 在 Kubernetes 中遇到的负载不均衡问题,并给出多种解决方案,帮助你在生产环境中构建稳定、高效的服务通信。
在 Buildbarn + Kubernetes 的分布式编译场景中,识别弹性节点并据此调整 Worker 行为,是构建弹性编译集群的关键一环。以下结合 Buildbarn 架构,给出完整的技术方案。
Buildbarn 分布式编译集群通常包含以下核心组件:
把 Buildbarn 自身的负载指标,转化为 Kubernetes 的行动指令。
在 Kubernetes 上运行 Buildbarn 作为远端执行(Remote Execution)/ 远程缓存后端时,一个常见诉求是:根据 CI 编译任务的规模,动态调整 Worker 的数量,从而既扛得住编译高峰,又不在低谷期浪费资源。本文梳理了四种主流方案,并给出选型建议。
在开源代码托管平台的选择上,Gitea 凭借轻量、易部署的特性,一直是很多开发团队的首选。但近两年来,Forgejo 的出现和崛起,给这个领域带来了新的变量。
Gitea 和 Forgejo 到底是什么关系?它们的 CI/CD 能力有何差异?如何基于它们搭建现代化的 DevOps 流水线?又能否将 Kubernetes 作为 CI/CD 的执行环境?
这篇文章将基于我们团队的调研和实践,一次性讲清楚这些问题。
harbor的官方安装指南 介绍了harbor有三种安装方式,分别是在线安装、离线安装和OVA安装,本文主要采用离线安装的方式。
官方文档上面说明需要依赖Python 2.7或以上版本,Docker引擎1.10以上,还有Docker Compose 1.6.0或以上版本,openssl。
这个参考应用程序在服务器和客户端是跨平台的,这要归功于.NET Core服务能够在Linux或Windows容器上运行,具体取决于您的Docker主机,以及Xamarin用于在Android,iOS或Windows / UWP plus上运行的移动应用程序客户端Web应用程序的任何浏览器。该体系结构提出了一种面向微服务的体系结构实现,具有多个自治微服务(每个都拥有自己的数据库/ db),并在每个微服务中实现不同的方法(简单的CRUD与DDD / CQRS模式),使用Http作为客户端应用程序之间的通信协议。微服务和支持异步通信,用于基于集成事件和事件总线(轻量级消息代理,在RabbitMQ或Azure Service Bus之间进行选择,跨多个服务)进行数据更新传播。
apt install socat ebtables ethtool
主要软件有:
kubeadm_1.10.2-00_arm64 、kubectl_1.10.2-00_arm64 、kubelet_1.10.2-00_arm64 、kubernetes-cni_0.6.0-00_arm64