基本使用指南 本文主要介绍如何使 Kruise Rollout 生效以及如何完成一个完整的发布，并回答一些关于用法的问题。 完整的发布流程 步骤 0：要求 安装 Kruise Rollouts。 假设您的 Kubernetes 集群中已经有一个部署（Deployment），如下所示： apiVersion: apps/v1 kind: Deployment metadata: name: workload-demo namespace: default spec: replicas: 10 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: - name: busybox image: busybox:latest command: ["/bin/sh", "-c", "sleep 100d"] env: - name: VERSION value: "version-1" 步骤 1：准备并应用 Rollout 配置 假设您想要使用多批次更新策略将部署从 “version-1” 升级到 “version-2”： 在第一批次：只升级 1 个 Pod； 在第二批次：升级 50% 的 Pods，即 5 个已更新的 Pod； 在第三批次：升级 100% 的 Pods，即 10 个已更新的 Pod。 $ kubectl apply -f - <<EOF apiVersion: rollouts....

Argo Rollouts Argo Rollouts 是一个 Kubernetes Operator 实现，它为 Kubernetes 提供更加高级的部署能力，如蓝绿、金丝雀、金丝雀分析、实验和渐进式交付功能，为云原生应用和服务实现自动化、基于 GitOps 的逐步交付。 支持如下特性： 蓝绿更新策略 金丝雀更新策略 更加细粒度、加权流量拆分 自动回滚 手动判断 可定制的指标查询和业务 KPI 分析 Ingress 控制器集成：NGINX，ALB 服务网格集成：Istio，Linkerd，SMI Metrics 指标集成：Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs、Datadog、New Relic 实现原理 与 Deployment 对象类似，Argo Rollouts 控制器将管理 ReplicaSets 的创建、缩放和删除，这些 ReplicaSet 由 Rollout 资源中的 spec.template 定义，使用与 Deployment 对象相同的 pod 模板。 当 spec.template 变更时，这会向 Argo Rollouts 控制器发出信号，表示将引入新的 ReplicaSet，控制器将使用 spec.strategy 字段内的策略来确定从旧 ReplicaSet 到新 ReplicaSet 的 rollout 将如何进行，一旦这个新的 ReplicaSet 被放大（可以选择通过一个 Analysis），控制器会将其标记为稳定。 如果在 spec.template 从稳定的 ReplicaSet 过渡到新的 ReplicaSet 的过程中发生了另一次变更（即在发布过程中更改了应用程序版本），那么之前的新 ReplicaSet 将缩小，并且控制器将尝试发布反映更新 spec....

记录一下 Linux Cgroup V2 版本基本使用操作，包括 cpu、memory 子系统演示。 1. 开启 Cgroup V2 版本检查 通过下面这条命令来查看当前系统使用的 Cgroups V1 还是 V2 stat -fc %T /sys/fs/cgroup/ 如果输出是cgroup2fs 那就是 V2，就像这样 root@tezn:~# stat -fc %T /sys/fs/cgroup/ cgroup2fs 如果输出是tmpfs 那就是 V1，就像这样 [root@docker cgroup]# stat -fc %T /sys/fs/cgroup/ tmpfs 启用 cgroup v2 如果当前系统未启用 Cgroup V2，也可以通过修改内核 cmdline 引导参数在你的 Linux 发行版上手动启用 cgroup v2。 如果你的发行版使用 GRUB，则应在 /etc/default/grub 下的 GRUB_CMDLINE_LINUX 中添加 systemd.unified_cgroup_hierarchy=1， 然后执行 sudo update-grub。 具体如下： 1）编辑 grub 配置 vi /etc/default/grub 内容大概是这样的： GRUB_DEFAULT=0 GRUB_TIMEOUT_STYLE=hidden GRUB_TIMEOUT=0 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX="" 对最后一行GRUB_CMDLINE_LINUX进行修改...

Argo CD Argo CD 是一个为 Kubernetes 而生的，遵循声明式 GitOps 理念的持续部署工具。Argo CD 可在 Git 存储库更改时自动同步和部署应用程序。 Argo CD 遵循 GitOps 模式，使用 Git 仓库作为定义所需应用程序状态的真实来源，Argo CD 支持多种 Kubernetes 清单： kustomize helm charts ksonnet applications jsonnet files Plain directory of YAML/json manifests Any custom config management tool configured as a config management plugin Argo CD 可在指定的目标环境中自动部署所需的应用程序状态，应用程序部署可以在 Git 提交时跟踪对分支、标签的更新，或固定到清单的指定版本。 架构 Argo CD 是通过一个 Kubernetes 控制器来实现的，它持续 watch 正在运行的应用程序并将当前的实时状态与所需的目标状态（ Git 存储库中指定的）进行比较。已经部署的应用程序的实际状态与目标状态有差异，则被认为是 OutOfSync 状态，Argo CD 会报告显示这些差异，同时提供工具来自动或手动将状态同步到期望的目标状态。在 Git 仓库中对期望目标状态所做的任何修改都可以自动应用反馈到指定的目标环境中去。 下面简单介绍下 Argo CD 中的几个主要组件：...

etcd 监控实操 etcd 通常由多个节点组成集群，节点之间使用 raft 协议保证一致性。ETCD 具有以下特点： 每个节点都有一个角色状态，Follower、Candidate、Leader 如果 Follower 找不到当前 Leader 节点的时候，就会变成 Candidate 选举系统会从 Candidate 中选出 Leader 所有的写操作都通过 Leader 进行 一旦 Leader 从大多数 Follower 拿到 ack，该写操作就被认为是“已提交”状态 只要大多数节点存活，整个 ETCD 就是存活的，个别节点挂掉不影响整个集群的可用性 ETCD 使用 restful 风格的 HTTP API 来操作，这使得 ETCD 的使用非常方便，这也是 ETCD 流行的一个关键因素 读取 /metrics 接口 ETCD 这么云原生的组件，显然是内置支持了 /metrics 接口的，不过 ETCD 很讲求安全性，默认的 2379 端口的访问是要用证书的，我来测试一下先： [root@dev01.nj ~]# curl -k https://localhost:2379/metrics curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate [root@dev01.nj ~]# ls /etc/kubernetes/pki/etcd ca.crt ca.key healthcheck-client....