流水易寒の博客

OpenKruise 是一个基于 Kubernetes 的扩展套件，主要聚焦于云原生应用的自动化，比如部署、发布、运维以及可用性防护。OpenKruise 提供的绝大部分能力都是基于 CRD 扩展来定义的，它们不存在于任何外部依赖，可以运行在任意纯净的 Kubernetes 集群中。Kubernetes 自身提供的一些应用部署管理功能，对于大规模应用与集群的场景这些功能是远远不够的，OpenKruise 弥补了 Kubernetes 在应用部署、升级、防护、运维等领域的不足。 OpenKruise 提供了以下的一些核心能力： 增强版本的 Workloads：OpenKruise 包含了一系列增强版本的工作负载，比如 CloneSet、Advanced StatefulSet、Advanced DaemonSet、BroadcastJob 等。它们不仅支持类似于 Kubernetes 原生 Workloads 的基础功能，还提供了如原地升级、可配置的扩缩容/发布策略、并发操作等。其中，原地升级是一种升级应用容器镜像甚至环境变量的全新方式，它只会用新的镜像重建 Pod 中的特定 ...

Kruise Rollouts是OpenKruise提供的一个旁路组件，用于提供先进的渐进式交付功能。它支持金丝雀、多批次和 A/B 测试交付模式，可以帮助实现对应用程序变更的平稳和可控发布，同时它与 Gateway API 和各种 Ingress 实现的兼容性使其更容易与你现有基础架构集成。总的来说，Kruise Rollouts 对于希望优化其部署流程的 Kubernetes 用户来说是一个有价值的工具！ Kruise Rollouts Kruise Rollouts 具有以下几个主要特点： 更多的发布策略 Deployment、CloneSet、StatefulSet 和 Advanced StatefulSet 的多批次更新策略。 Deployment 的金丝雀更新策略。 更多流量路由管理策略 在更新工作负载时进行流量细粒度加权流量转移。 基于 HTTP 头和 Cookie 进行 A/B 测试，根据流量进行转移。 更多流量协议支持 Ingress 控制器集成：NGINX、ALB、Higress。 通过 Gateway API 与服务网格集成 ...

这篇文章旨在让您对 OpenTelemetry 有基本的了解。将涵盖的主题有： 分布式追踪 OpenTelemetry 是什么？ OpenTelemetry 检测（自动和手动） OpenTelemetry 协议（OTLP） OpenTelemetry Collectors OpenTelemetry Collectors 部署模式 OpenTelemetry 后端 OpenTelemetry on Kubernetes OpenTelemetry Operator OpenTelemetry 示例应用程序 在本文结束时，您将了解如何使用 OpenTelemetry Operator 在应用程序中实现跟踪，而无需更改任何代码。 分布式追踪让我们首先了解一下什么是分布式跟踪以及我们为什么需要它。 为什么我们需要追踪？我们需要为什么分布式追踪？为什么我们不能只使用指标和日志呢？假设你有一个如下所示的微服务架构。 现在想象一下来自客户端的请求。 从上面的架构图中我们可以看出，一个请求可能要经过几十个或几百个网络调用。这使得我们很难知道请求所经过的整个路径，如果只有日志和指标，那么故障排查 ...

微服务架构具有诸多优势，包括增强团队自主性、提高扩展与部署灵活性。但缺点是，系统中的服务越多（一个微服务应用可能包含几十个甚至几百个服务），清晰地了解系统总体运行情况的难度就越大。作为复杂软件系统的编写者和维护者，我们深知掌握系统运行情况的重要性。可观测性工具可帮助我们清晰地了解众多服务和支持基础设施。 在本教程中，我们将重点介绍微服务应用的一种非常重要的可观测性工具：链路追踪（tracing）。在步入正题之前，让我们先定义一下讨论可观测性时通常会用到的一些术语： 可观测性—仅基于对复杂系统（如微服务应用）的外部输出（如链路追踪、日志和指标）的了解就能获悉其内部状态或状况的能力。 监控—观测并检查对象在一段时间内的进度或状态的能力。例如，您可以监控在高峰时段传入应用的流量，并使用这些信息对应用进行相应的扩展。 遥测—收集指标、链路追踪和日志，并将它们从源点转移到另一个系统进行存储和分析的行为。有时，遥测还指数据本身。 链路追踪—记录请求或操作通过分布式系统所有节点的过程。 Span—一项操作链路追踪中的记录及其相关元数据。链路追踪由许多嵌套的 span 组成。 事件记录& ...

记录并分享最近部署的Kubernetes集群，踩坑记录全部给剔除，并说明不同CRI的方式：docker和containerd。下文不会介绍过多的细节和基础知识，都是生产环境很实用的基本情况，相关命令和解释不会说明。 所谓多节点集群，要求服务器应该有两台或者更多，这里我采用一台是 Master 节点，另两台是 Worker 节点，说明使用 kubeadm 部署 Kubernetes 集群的一些细节和注意点，同时说明生产环境如何添加多 Master 节点和多 Worker 节点。 前期准备（所有节点） HOST IP 系统 k8s-master01 172.17.40.174 Ubuntu 22.04.2 LTS k8s-work01 172.17.40.175 Ubuntu 22.04.2 LTS k8s-work02 172.17.40.176 Ubuntu 22.04.2 LTS 服务器基础配置123456789101112131415161718192021222324252627282930313233343536373839404142434445464 ...

Submariner 是一个完全开源的项目，可以帮助我们在不同的 Kubernetes 集群之间（无论是在本地还是云端）实现网络通信。Submariner 有以下功能： 跨集群的 L3 连接 跨集群的服务发现 Globalnet 支持 CIDR 重叠 提供命令行工具 subctl 简化部署和管理 兼容各种 CNI 1 Submariner 架构 Submariner 由几个主要部分组成： Broker: 本质上是两个用于交换集群信息的 CRD（Endpoint 和 Cluster），我们需要选择一个集群作为 Broker 集群，其他集群连接到 Broker 集群的 API Server 来交换集群信息： Endpoint：包含了 Gateway Engine 建立集群间连接需要的信息，例如 Private IP 和 Public IP，NAT 端口等等。 Cluster：包含原始集群的静态信息，例如其 Service 和 Pod CIDR。 Gateway Engine：管理连接到其他集群的隧道。 Route Agent：负责将跨集群的流量路由到 active Gatew ...

01Unnderlay 网络 的 IP 需求随着数据中心私有云的发展，应用希望能直接获取并使用宿主机网络中的 IP 地址，实现在 Underlay 网络下的东西向和南北向通信；同时基于对 IPAM（IP地址管理） 的特殊需求，迫切希望能解决如下的一些诉求： Pod 多网卡支持 为使 Pod 能通达不同的 Underlay 子网，需给应用的不同网卡分配不同子网下的 IP 地址，社区现有的方案配合 Multus 能分配多网卡 IP 地址，但是不能实现多网卡都固定 IP 地址。 社区现有的多网卡分配 IP 地址方案，还存在多网卡路由协调问题，例如：Pod 的默认路由在网卡 1 上，外部 Client 访问 Pod 网卡 2 的 IP 地址，当外部的源 IP 与 Pod 的网卡 2 不是同网段时，Pod 就会通过默认路由从而走到网卡 1 进行回包，请求向和回复向的转发路径不一致，因此外部的 Client 收不到回包，导致网络不可达。 有状态和无状态应用 IP 固定 Pod 的 IP 地址常常受防火墙策略管控，防火墙只会允许特定的 IP 或者 IP 范围内的目标访问，因此 P ...

  那么，部署在kubernetes集群中的Harbor服务，如何对Harbor的数据进行备份和恢复呢？   以下教程展示了如何使用 Velero 备份和恢复已使用 Harbor helm 图表部署在 Kubernetes 集群中的 Harbor 实例。 本教程仅备份 Harbor 资源和数据的一个子集，包括所有与 Harbor 相关的 Kubernetes 资源（部署、StatefulSets、Services、ConfigMap 等）以及 Harbor 内部数据库、注册表、chartmuseum、jobservice 和 Trivy 的 PersistentVolumes 中的数据。 Harbor 的 Redis 数据未备份，请参阅限制部分，了解有关对 Harbor 实例的潜在影响的更多详细信息。 本教程中执行的备份是崩溃一致的，而不是应用程序一致的。这意味着恢复后某些数据将丢失，有关详细信息，请参阅限制部分。 一、Velero简介项目地址：https://github.com/vmware-tanzu/velero Velero 是Heptio公司（已被VMware收购 ...

形式一1234567891011121314151617181920212223#!/bin/basherr=0for k in $(seq 1 3)do check_code=$(pgrep haproxy) if [[ $check_code == "" ]]; then err=$(expr $err + 1) sleep 1 continue else err=0 break fidoneif [[ $err != "0" ]]; then echo "systemctl stop keepalived" /usr/bin/systemctl stop keepalived exit 1else exit 0fi 形式二1234567891011121314#!/bin/sherrorExit() { echo "*** $*" 1>&2 exit 1
...

在 使用 Go 和 Linux Kernel 技术探究容器化原理 一文中，我们揭秘了容器的本质就是一个特殊的进程，特殊在为其创建了 NameSpace 隔离运行环境，并用 Cgroups 为其控制资源开销。 借助这两个底层技术，我们可以成功实现应用容器化，但如何让多个容器在网络环境不互相干扰的情况下还能互相通信，让容器可以访问外部网络，让外部网络可以访问特定容器等等的这些容器的网络问题还得再利用一些 Linux 网络虚拟化技术。 容器网络隔离：NameSpace让多个容器的网络环境不会互相干扰，可以延续之前 NameSpace 的知识点。 在前面介绍的 8 种 NameSpace 中，有一个 Network NameSpace ，我们可以借助这个来给容器配置独立的网络视图。 我们先看宿主机所处的 Default Network NameSpace ： 123[root@host ~]# readlink /proc/$$/ns/netnet:[4026531956][root@host ~]# 以 net:[4026531956] 为例，net 代表了 NameSpace 的类型，4 ...