多集群运维(一)：自动化交付，构建，部署，发布，监控

背景

在当今云计算和DevOps的时代，管理和维护多个集群环境已成为一项挑战。每个集群都有其独特的特性和需求，如开发、测试、生产等。有效管理这些集群需要精心规划和合适的工具。

目标

本文档的目标是展示如何有效地管理多个K8S集群，涵盖开发、测试、生产等不同环境。关键在于利用自动化工具和最佳实践来实现高效、可靠的运维流程。

目标的详细说明：

1. IaC 管理云资源： 使用基础设施即代码（IaC）的方法初始化 Cloud 资源。包括配置 VPC、防火墙规则、密钥对（keypairs）、虚拟主机（Vhosts）不同用途的实例（如 devops、monitor、sit、uat 和 prod）。
2. 使用GitHub Action Pipeline来自动化集群环境（devops、monitor、sit、uat和prod）的配置初始化。
3. 使用 GitOps/FluxCD 实现集群管理目标： 接入监控系统，管理告警规则，发布应用，配置变更

准备工作

Demo示例

配置仓库

1. IAC_code: https://github.com/svc-design/iac_modules.git
2. Playbook：https://github.com/svc-design/playbook.git
3. GitOps : https://github.com/svc-design/gitops.git
4. PipeLine : https://github.com/open-source-solution-design/Modern-Container-Application-Reference-Architecture.git

应用代码仓库

• C: https://github.com/scaffolding-design/c.git
• GO: https://github.com/scaffolding-design/go.git
• Python: https://github.com/scaffolding-design/python.git
• Rust: https://github.com/scaffolding-design/rust.git
• JS: https://github.com/scaffolding-design/javascript.git

部署上线

申请资源

首先是在配置仓库中声明资源配置清单，然后是使用GitHub CI流水线来自动化资源的申请过程。以下是这两个步骤的详细扩展：

创建和配置资源清单

在iac_modules仓库下的iac_modules/terraform/gcp/vhost/config.yaml文件中，定义了在GCP中需要的资源配置。这份YAML文件详细列出了针对各种用途（如devops、monitor、sit、uat和prod）定义了不同的实例，每个实例具有特定的规格，如CPU类型、内存大小、存储大小，所在区域等。

region: "asia-northeast1"
project_id: "cloudsvcsandbox"
bucket_name: "iac_gcp_terraform_state"
instances:
  - name: "devops"
    type: "e2-standard-4"
    zone: "asia-northeast1-a"
    image: "ubuntu-2004-lts"
    disk_size_gb: 100
    network: "custom"
    subnetwork: internet-subnet
  - name: "monitor"
    type: "e2-standard-4"
    zone: "asia-northeast1-a"
    image: "ubuntu-2004-lts"
    disk_size_gb: 100
    network: "custom"
    subnetwork: internet-subnet
  - name: "sit"
    image: "ubuntu-2004-lts"
    disk_size_gb: 100
    type: "e2-standard-2"
    zone: "asia-northeast1-a"
    network: "custom"
    subnetwork: internet-subnet
  - name: "uat"
    type: "e2-standard-4"
    zone: "asia-northeast1-a"
    image: "ubuntu-2004-lts"
    disk_size_gb: 100
    network: "custom"
    subnetwork: internet-subnet
  - name: "prod"
    type: "e2-standard-4"
    zone: "asia-northeast1-a"
    image: "ubuntu-2004-lts"
    disk_size_gb: 100
    network: "custom"
    subnetwork: internet-subnet

更多IAC配置详见https://github.com/svc-design/iac_modules.git仓库，其中关键元素包括如下：

• 区域和项目ID：定义了GCP中资源部署的地理位置和项目标识符。
• 存储桶：为Terraform状态管理指定了一个存储桶。
• 子网划分，路由，防火墙规则等

资源申请CI pipeline

1. 在.github/workflows/iac-pipeline-create.yml文件中，定义了一个GitHub CI流水线，用于自动化地申请在config.yaml中声明的资源。流水线利用GitHub Actions的能力，自动执行Terraform脚本，创建和配置在GCP中定义的资源

2.流水线运行成功后，可以从GCP控制台看到资源已经就绪，并且每个环境的基础配置已经完成

接入监控

1. 在GitOps配置仓库中，您创建了一个目录结构来组织监控相关的配置文件。例如，kube-prometheus-stack和observability-agent文件夹包含了相关的配置和Kustomize文件。

目录结构：

apps/
├── monitor
│   ├── kube-prometheus-stack
│   │   ├── kube-state-metrics-config.yaml
│   │   ├── kustomization.yaml
│   │   ├── kustomizeconfig.yaml
│   │   ├── release.yaml
│   │   └── repository.yaml
│   └── observability-agent
│       ├── kustomization.yaml
│       └── release.yaml

• apps/monitor/：包含监控相关的应用和配置
• kube-prometheus-stack/：包含了Prometheus堆栈的配置文件
• observability-agent/：包含监控代理的配置

使用GitOps分发监控配置

通过在GitOps仓库中定义kustomization.yaml文件，您可以指定哪些资源应该被应用到特定的Kubernetes集群。例如，在clusters/sit/kustomization.yaml文件中，您指定了要应用到SIT环境的资源和配置。

Kustomization文件内容：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - namespace.yaml
  - ../../apps/monitor/observability-agent/
  - ../../apps/monitor/kube-prometheus-stack/

在这个例子中，kustomization.yaml文件引用了namespace.yaml（定义了必要的Kubernetes命名空间），以及两个监控相关的目录，确保这些配置被应用到SIT环境的集群。在代码提交后，数分钟内，配置变更就可以完成，可以通过Grafana面板查看FluxCD的同步状态

配置告警

采用GitOps仓库来管理和变更配置，特别是在多集群环境中管理监控和告警系统，提供了显著的效率和便利性。这种方法允许团队使用熟悉的Git工作流程来管理复杂的配置，同时确保了环境间的一致性和可追溯性。

通过将监控配置文件添加到GitOps仓库，如下所示：

clusters/monitor/kustomization.yaml
clusters/monitor/recording-rules-patch.yaml
clusters/monitor/alert-rules-patch.yaml

采用GitOps方式能够实现几个关键的运维目标：

• 版本控制：所有的配置更改都通过版本控制，使得追踪更改、进行回滚和审计变得简单。
• 自动化部署：配置更改被推送到Git仓库后，GitOps工具（如ArgoCD或Flux）会自动检测这些更改并将其应用到相应的Kubernetes集群中。
• 集中管理：在Git仓库中集中管理多个集群的配置，提高了配置管理的效率和准确性。

一旦这些配置被应用到集群中，Grafana（作为监控可视化工具）将显示基于这些规则的实时数据和告警

发布应用

使用GitOps和Kustomize工具来管理和发布多个应用的过程。这种方法提供了一种高度自动化和声明性的方式来处理Kubernetes资源的部署和管理。

定义应用配置

在apps/目录下，每个子目录（如c-demo, go-demo, js-demo, python-demo, rust-demo）代表一个独立的应用。每个应用目录包含其自己的kustomization.yaml，namespace.yaml，以及release.yaml。

• kustomization.yaml：用于定义该应用所需的资源和配置。
• namespace.yaml：为每个应用创建一个独立的命名空间。
• release.yaml：特定于某些应用的部署或其他资源配置。

 apps/
├── c-demo
│   ├── kustomization.yaml
│   ├── namespace.yaml
│   └── release.yaml
├── go-demo
│   ├── kustomization.yaml
│   ├── namespace.yaml
│   └── release.yaml
├── js-demo
│   ├── kustomization.yaml
│   └── namespace.yaml
├── python-demo
│   ├── kustomization.yaml
│   ├── namespace.yaml
│   └── release.yaml
└── rust-demo
    ├── kustomization.yaml
    ├── namespace.yaml
    └── release.yaml

使用GitOps分发配置

在clusters/sit/kustomization.yaml文件中，以定义了要在SIT环境的集群中部署的资源为例：

clusters/sit/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - namespace.yaml
  - ../../apps/monitor/observability-agent/
  - ../../apps/monitor/kube-prometheus-stack/
  - ../../apps/c-demo/
  - ../../apps/js-demo/
  - ../../apps/python-demo/
  - ../../apps/go-demo/
  - ../../apps/rust-demo/

一旦这些配置被GitOps工具应用到Kubernetes集群中，Grafana（作为监控和可视化工具）将能够显示这些应用的发布状态和运行情况。

后续可以在Grafana中设置适当的Dashboard来监控以下更多应用状态信息：

• 应用性能指标：如CPU和内存使用情况、响应时间、流量等。
• 健康检查和可用性：通过liveness和readiness探针的数据来查看应用的健康状态。
• 告警和事件：如果设置了告警规则，Grafana还可以展示任何触发的告警。

总结

Pipeline：适合于环境初始化

Pipeline在自动化基础设施的初始化和设置方面表现出色。它的主要优势在于：

• 自动化设置：Pipeline可以自动化执行环境设置的各个步骤，如安装软件、配置网络和设置安全措施。
• 一次性任务：对于一些只需运行一次的任务，如创建数据库、配置集群等，Pipeline是一个理想的工具。
• 持续集成：Pipeline可以用于持续集成（CI）过程，自动化代码构建、测试和验证。
• 快速反馈：在代码提交到仓库后立即执行构建和测试，为开发者提供快速反馈。

GitOps：适合于应用和配置变更

• GitOps在应用部署和配置变更方面更加高效，特别是在持续部署（CD）和配置管理方面：
• 声明性配置：通过声明性配置管理，GitOps使得配置的变更、版本控制和审计变得简单透明。
• 配置版本控制：所有配置变更都通过Git进行版本控制，方便追踪历史和回滚错误。
• 自动化同步：GitOps工具如Argo CD或Flux会监控Git仓库的变化，并自动将配置变更同步到生产环境。
• 适应性强：非常适合于频繁的、小规模的更新和变更，如应用更新、配置调整等。

GitOps和基于Pipeline的DevOps在现代软件工程中的重要性和互补性。这两种实践结合起来，不仅提高了软件开发和运维的效率和质量，还为组织提供了适应快速变化的能力。此外，随着应用数量的增加，采用模板化和标准化策略确实有助于保持工作量的可控性，避免随着规模扩大而出现工作量的线性增长。以上运维实践参考为现代云原生应用的快速开发和运维提供了强大的支持。