GitOps 实操手册 7: 实现 ArgoCD 高级管理特性

ArgoCD本地安装 参考官方文档:https://argo-cd.readthedocs.io/en/stable/getting_started/ 0. 前提要求 已经安装了kubectl命令行工具 存在kubeconfig文件(默认位置是 ~/.kube/config) 1. 安装 kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/ 阅读详情

内容简介

本实验手册系列包含七个主题,涵盖了从应用容器化到 GitOps 工作流的实现与高级特性。通过这些实验手册,您将学习到如何构建、部署和管理应用,以及如何在 Kubernetes 集群上实现高效的持续交付流程。

以下是实验手册的七个章节:

  1. 应用程序容器化实验手册:学习如何将应用程序容器化,并为主流编程语言构建镜像。同时,了解如何缩减镜像体积和使用 GitHub Actions 自动构建镜像。
  2. 单节点 Kubernetes 集群部署实验手册:使用 kind 在本地部署单节点 Kubernetes 集群,安装基础服务,并熟悉 Kubernetes 的基本功能,如运行 Pod、调度工作负载、服务发布和自动扩缩容。
  3. 示例应用的部署和解析实验手册:深入了解示例应用的各个组件,学习如何在 Kubernetes 集群上部署、运行和管理这些组件,实现服务调用、应用配置和扩缩容等功能。
  4. 使用 Helm 定义应用实验手册:通过 Helm 对示例应用进行定义,以满足 GitOps 部署的需求。了解 Helm Chart 的创建和使用,以及预发布和生产环境的部署。
  5. 构建 GitOps 工作流实验手册:在 Kubernetes 集群上安装 ArgoCD,并使用 ArgoCD 定义示例应用进行部署,实现基于镜像版本变化触发的 GitOps 工作流。
  6. 实现 GitOps 高级发布策略实验手册:结合 ArgoCD 的高级特性,如 Argo Rollout、AnalysisTemplate 和 Argo Rollout Dashboard,实现蓝绿发布、金丝雀发布和自动渐进交付。
  7. ArgoCD 高级管理特性实验手册:探讨 ArgoCD 在 GitOps 场景中的高级特性,包括使用 ApplicationSet 实现多环境部署和使用 SealedSecret 保护密钥。

通过这七个实验手册,您将全面掌握应用容器化、Kubernetes 和 GitOps 的相关知识,为应用的持续交付提供可靠和高效的解决方案。

在本系列实验手册的最后一章中,我们将深入探讨 ArgoCD 在 GitOps 场景中的两个高级特性:使用 ApplicationSet 实现多环境部署和使用 SealedSecret 保护密钥。这些高级特性将进一步提高 ArgoCD 在实际生产环境中的可用性和安全性。

本实验手册的主要实验环节包括:

  1. ApplicationSet 简介:了解 ApplicationSet 的概念以及如何使用它实现多环境部署。
  2. 实现多环境部署:通过 ApplicationSet 在不同的 Kubernetes 集群或命名空间中自动创建和管理多个 ArgoCD Application,满足多环境部署的需求。
  3. SealedSecret 简介:探讨 SealedSecret 的概念以及如何使用它保护 Kubernetes Secret。
  4. 保护密钥:使用 SealedSecret 对 Kubernetes Secret 进行加密,确保敏感信息在 Git 仓库中的安全存储,同时实现 GitOps 工作流中的密钥管理。

通过本实验手册,您将掌握 ArgoCD 的高级管理特性,并了解如何在 GitOps 工作流中实现多环境部署和密钥保护,为应用的持续交付提供更加安全和灵活的解决方案。

多环境部署

示例应用简介

该项目的目录结构包括 Chart.yamlapplicationset.yamlenv 目录和 templates 目录。熟悉 Helm 的用户很容易就能看出,实际上它是一个 Helm Chart。不同之处在于,Helm 的配置文件 values.yaml 并未放置在 Chart 的根目录,而是存放在 env 目录下。

templates 目录存储了示例应用程序的 Kubernetes 对象。为了简化演示过程,只部署前端相关的对象,即 frontend.yaml

├── Chart.yaml
├── applicationset.yaml
├── env
│   ├── dev
│   │   └── values.yaml
│   ├── prod
│   │   └── values.yaml
│   └── test
│       └── values.yaml
└── templates
    ├── frontend.yaml
    └── ingress.yaml

查看 ingress 配置

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: frontend
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: {{ .Release.Namespace }}.env.my
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 3000
  1. apiVersionkind:定义了这是一个 Kubernetes Ingress 资源对象。
  2. metadata:设置 Ingress 的名称和相关注解。
    • name:Ingress 资源的名称。
    • annotations:Ingress 资源的注解,这里设置了 Nginx Ingress 控制器作为处理此 Ingress 的控制器。
  3. spec:定义 Ingress 的配置。
    • rules:定义 Ingress 的路由规则。
      • host:定义请求的主机名,这里使用 {{ .Release.Namespace }}.env.my,其中 {{ .Release.Namespace }} 是一个 Helm 模板变量,表示当前资源所属的命名空间。请注意,这里需要将双大括号({{}})包裹在引号中,以便正确解析。
      • http:定义 HTTP 规则。
        • paths:定义基于路径的路由规则。
          • path:定义请求路径,这里是根路径 /
          • pathType:定义路径类型,这里是 Prefix,表示匹配以 / 开头的所有路径。
          • backend:定义后端服务。
            • service:指定后端服务的名称和端口。
              • name:后端服务的名称,这里是 frontend-service
              • port:后端服务的端口,这里是 3000

这个 Ingress 配置文件定义了一个 HTTP 路由规则,将所有以 / 开头的请求路由到名为 frontend-service 的后端服务的 3000 端口。主机名根据当前资源所属的命名空间动态设置。

需要注意的是,在 Ingress 对象中使用了 Helm 的内置变量 Release.Namespace,它实际上指的是 Helm Chart 部署的命名空间。在示例中,将 Release.Namespace 与域名拼接以生成访问地址。不同环境将被部署到独立的命名空间下,从而具有独立的访问域名。

创建 ApplicationSet

ApplicationSet 是本节课的重点,可以自动生成多个 Application 对象,每个对象对应着不同的环境。

示例应用目录中有一个名为 applicationset.yaml 的文件,其中定义了 ApplicationSet 的内容。

nano applicationset.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: frontend
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: "https://github.com/cloudzun/kubernetes-example.git"
      revision: HEAD
      files:
      - path: "helm-env/env/*/values.yaml"
  template:
    metadata:
      name: "{{path.basename}}"
    spec:
      project: default
      source:
        repoURL: "https://github.com/cloudzun/kubernetes-example.git"
        targetRevision: HEAD
        path: "helm-env"
        helm:
          valueFiles:
          - "env/{{path.basename}}/values.yaml"
      destination:
        server: 'https://kubernetes.default.svc'
        namespace: '{{path.basename}}'
      syncPolicy:
        automated: {}
        syncOptions:
          - CreateNamespace=true

这是一个 ArgoCD ApplicationSet 的配置文件,用于在 ArgoCD 中创建多个应用(Application)实例,这些实例基于相同的源代码仓库和模板配置,但具有不同的参数和目标集群/命名空间。

  1. apiVersionkind:定义了这是一个 ArgoCD 的 ApplicationSet 资源对象。
  2. metadata:设置 ApplicationSet 的名称和命名空间。
  3. spec:定义 ApplicationSet 的配置:
    • generators:生成器用于为 ApplicationSet 创建应用实例。在这里,使用 Git 生成器从 Git 仓库中获取配置文件。
      • repoURL:源代码仓库的地址。
      • revision:要使用的 Git 仓库的分支或标签。
      • files:一个文件列表,用于查找 Helm values 文件,这里会匹配 helm-env/env/*/values.yaml 路径下的所有 values 文件。
    • template:定义应用实例的基本模板。
      • metadata:设置应用实例的名称,这里使用 {{path.basename}} 模板变量从 values 文件路径中提取名称。
      • spec:定义应用实例的配置。
        • project:设置 ArgoCD 项目。
        • source:指定源代码仓库、路径和参数。
          • repoURL:源代码仓库的地址。
          • targetRevision:要使用的 Git 仓库的分支或标签。
          • path:仓库中 Helm chart 的路径。
          • helm:指定 Helm 相关配置。
            • valueFiles:指定 Helm values 文件的路径,使用 {{path.basename}} 模板变量匹配生成器中的 values 文件。
        • destination:设置目标集群和命名空间,这里使用 {{path.basename}} 从 values 文件路径中提取命名空间名称。
        • syncPolicy:设置同步策略。
          • automated:启用自动同步。
          • syncOptions:设置同步选项,这里将在同步时自动创建目标命名空间。

这个配置文件的目的是根据 Git 仓库中的 Helm values 文件创建多个 ArgoCD 应用实例,每个实例使用相同的源代码仓库和 Helm chart,但具有不同的参数和目标集群/命名空间。

kubectl apply -f applicationset.yaml

验证多环境部署

从ArgoCD 界面中进行查看

在这里插入图片描述

在hosts文件中增加以下条目

192.168.1.231 dev.env.my
192.168.1.231 test.env.my
192.168.1.231 prod.env.my
192.168.1.231 staging.env.my

分别查看各个环境的页面,以dev为例

在这里插入图片描述

密钥管理

安装 sealed-secrets

安装CLI

wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.20.2/kubeseal-0.20.2-linux-amd64.tar.gz
tar -xvzf kubeseal-0.20.2-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

安装 Controller 控制器

helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets -n kube-system --set-string fullnameOverride=sealed-secrets-controller sealed-secrets/sealed-secrets
kubectl wait deployment -n kube-system sealed-secrets-controller --for condition=Available=True --timeout=300s

查看secret对象

在本地使用 kubeseal 加密 Secret 对象时,kubeseal 会从集群内下载 RSA 公钥并使用它对 Secret 对象进行加密。接着,生成加密后的 SealedSecret CRD 资源,即 SealedSecret 对象。当集群内控制器检测到新的 SealedSecret 对象被部署时,控制器将使用集群内的 RSA 私钥解密信息,并在集群内重新生成 Secret 对象,以供工作负载使用。

kubectl get secret -n kube-system
root@node1:~# kubectl get secret -n kube-system
NAME                                   TYPE                 DATA   AGE
sealed-secrets-keywgh7h                kubernetes.io/tls    2      28h
sh.helm.release.v1.sealed-secrets.v1   helm.sh/release.v1   1      28h
kubectl get secret sealed-secrets-keywgh7h -n kube-system -o yaml
root@node1:~# kubectl get secret sealed-secrets-keywgh7h -n kube-system -o yaml
apiVersion: v1
data:
  tls.crt: LS0tLS...tLS0tLQo=
  tls.key: LS0tLS...tLS0K
kind: Secret
metadata:
  creationTimestamp: "2023-03-21T02:40:04Z"
  generateName: sealed-secrets-key
  labels:
    sealedsecrets.bitnami.com/sealed-secrets-key: active
  name: sealed-secrets-keywgh7h
  namespace: kube-system
  resourceVersion: "102417"
  uid: b5566b9f-ad31-4e1e-b44f-14d9e23839ae
type: kubernetes.io/tls

分析示例应用

https://github.com/cloudzun/kubernetes-example/blob/main/sealed-secret/manifest/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-spring
spec:
    ......
    spec:
      imagePullSecrets:
      - name: github-regcred
      containers:
      - name: sample-spring
        image: ghcr.io/cloudzun/sample-kotlin-spring:latest
        ports:
        - containerPort: 8080
          name: http
        env:
          - name: PASSWORD
            valueFrom:
              secretKeyRef:
                key: password
                name: sample-secret

这是一个Kubernetes的部署(Deployment)配置文件,用于部署一个名为sample-spring的应用。以下是对这个配置文件各部分的解释:

  1. apiVersion: apps/v1:指定Kubernetes API版本,这里是apps/v1,用于部署资源。
  2. kind: Deployment:指定资源类型为Deployment,用于管理应用的生命周期,例如滚动更新、回滚等。
  3. metadata:资源元数据。
    • name: sample-spring:指定部署的名称为sample-spring
  4. spec:部署的规格,描述了部署的属性。
    • ...:省略了其他部署配置,例如副本数(replicas)、更新策略(updateStrategy)等。
  5. spec:容器规格,描述了Pod中的容器属性。
    • imagePullSecrets:用于从私有仓库拉取镜像的凭据。
      • name: github-regcred:使用名为github-regcred的Secret作为镜像拉取凭据。
    • containers:定义容器列表。
      • name: sample-spring:指定容器名称为sample-spring
      • image: ghcr.io/cloudzun/sample-kotlin-spring:latest:指定容器使用的镜像为ghcr.io/cloudzun/sample-kotlin-spring的latest标签。
      • ports:容器的端口配置。
        • containerPort: 8080:指定容器监听的端口为8080。
        • name: http:给这个端口命名为http
      • env:容器的环境变量配置。
        • name: PASSWORD:设置环境变量名为PASSWORD
        • valueFrom:从其他资源中获取环境变量的值。
          • secretKeyRef:从Secret资源中获取环境变量的值。
            • key: password:指定从Secret中获取名为password的键值。
            • name: sample-secret:指定Secret资源的名称为sample-secret

这个配置文件定义了一个名为sample-spring的部署,使用ghcr.io/cloudzun/sample-kotlin-spring:latest镜像。容器监听8080端口,并从名为sample-secret的Secret中获取名为PASSWORD的环境变量。同时,它还使用名为github-regcred的Secret来从私有仓库拉取镜像。

在本示例中,应用镜像被存储在GitHub Package仓库中,即域名为ghcr.io的镜像仓库,并设置为私有仓库类型。如果没有向Kubernetes集群提供拉取凭据,将无法拉取镜像。这意味着直接将此工作负载部署到集群会导致ImagePullBackOff事件。imagePullSecret用于提供镜像拉取凭据,稍后将通过kubeseal创建此凭据。另外,还为工作负载配置了Env环境变量,其值来自名为sample-secret的Secret对象。稍后也将通过kubeseal创建这个Secret对象。

创建 ArgoCD 应用

https://github.com/cloudzun/kubernetes-example/blob/main/sealed-secret/application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: spring-demo
  namespace: argocd
spec:
   project: default
   source:
     repoURL: https://github.com/cloudzun/kubernetes-example.git
     targetRevision: HEAD
     path: sealed-secret/manifest
   destination:
     server: https://kubernetes.default.svc
     namespace: secret-demo
   syncPolicy:
     automated:
       prune: false
       selfHeal: false
     syncOptions:
      - CreateNamespace=true

这是一个用于 Argo CD 的 Kubernetes Application 自定义资源(CR)配置文件。Argo CD 是一个持续部署(Continuous Deployment,CD)工具,用于管理 Kubernetes 应用程序。它可以自动将 Git 仓库中的配置文件同步到 Kubernetes 集群中。这个配置文件定义了一个名为 “spring-demo” 的 Argo CD 应用,并说明了如何将 Git 仓库中的 Kubernetes 配置部署到目标集群。

让详细解释一下各个部分:

  1. apiVersion 和 kind:这两个字段用于定义这是一个 Argo CD Application 资源,使用 “argoproj.io/v1alpha1” 版本。
  2. metadata:该部分包含关于 Application 的元数据,如名称(name)和命名空间(namespace)。在这个例子中,名为 “spring-demo” 的应用将在 “argocd” 命名空间中创建。
  3. spec:这是 Application 的配置规范,其中包含以下字段:
    • project:指定应用所属的 Argo CD 项目。在这里,应用属于默认(default)项目。
    • source:定义了 Git 仓库的相关信息和要同步的文件路径。其中包括:
      • repoURL:Git 仓库的 URL,本例中是 “https://github.com/cloudzun/kubernetes-example.git”。
      • targetRevision:要检出的 Git 仓库分支或提交。这里使用 HEAD,表示最新的提交。
      • path:在 Git 仓库中要部署的 Kubernetes 配置文件所在的目录。本例中,位于 “sealed-secret/manifest” 目录。
    • destination:描述了应用的目标集群和命名空间。其中:
    • syncPolicy:定义了同步策略,包括以下设置:
      • automated:此字段启用自动同步。在本例中,prune 和 selfHeal 都设置为 false,表示 Argo CD 不会自动删除多余的资源,也不会自动修复资源。
      • syncOptions:同步选项。本例中,仅包含一个选项 “CreateNamespace=true”,表示在同步时创建目标命名空间(如果不存在)。

这个配置文件的目的是在 “secret-demo” 命名空间中部署位于 “sealed-secret/manifest” 目录的 Kubernetes 配置,同时启用自动同步。

安装应用

kubectl apply -f application.yaml
root@node1:~/kubernetes-example/sealed-secret# kubectl apply -f application.yaml

从Argo CD界面上观察有一颗破碎的红心

在这里插入图片描述

到终端查看线索

root@node1:~/kubernetes-example/sealed-secret# kubectl get pod -n secret-demo
NAME                            READY   STATUS             RESTARTS   AGE
sample-spring-b55d8b446-jldpd   0/1     ImagePullBackOff   0          96s
root@node1:~/kubernetes-example/sealed-secret# kubectl logs sample-spring-b55d8b446-jldpd -n secret-demo
Error from server (BadRequest): container "sample-spring" in pod "sample-spring-b55d8b446-jldpd" is waiting to start: trying and failing to pull image

详细解析这个错误:

  1. Error from server (BadRequest):这表示 API 服务器返回了一个错误,类型为 BadRequest。
  2. container “sample-spring” in pod “sample-spring-b55d8b446-jldpd”:指出问题发生在名为 “sample-spring” 的容器中,它属于名为 “sample-spring-b55d8b446-jldpd” 的 Pod。
  3. is waiting to start:表示此容器尚未启动,正在等待启动。
  4. trying and failing to pull image:表明在尝试从镜像仓库拉取镜像时失败了。这可能是由于多种原因导致的,例如错误的镜像名称、错误的镜像版本、镜像仓库无法访问、网络问题、认证问题等。

要解决这个问题,首先需要检查容器配置中的镜像名称和版本是否正确。然后,确保的集群可以访问镜像仓库。如果镜像仓库需要认证,请确保提供了正确的凭据。最后,检查集群的网络连接,确保节点可以正常访问外部资源。根据具体的错误原因,可能需要调整配置或解决基础设施问题。

创建加密后的对象

尝试使用 Github PAT 登陆

export PAT="Your PAT"
echo $PAT | docker login ghcr.io --username cloudzun --password-stdin

查看.dockerconfigjson

nano /root/.docker/config.json
{
        "auths": {
                "ghcr.io": {
                        "auth": "Y2xvdWR6dW46Z2hwX3JEdGJtcHFmTlhvMTRheW1QbHg3cTRlanZlVWw0ZDJjSk5SSg=="
                },
                "https://index.docker.io/v1/": {
                        "auth": "Y2hlbmd6aDoyd3N4I0VEQyRSRlY="
                }
        }
}

对整个文件进行base64编码,https://base64.us/

ewogICAgICAgICJhdXRocyI6IHsKICAgICAgICAgICAgICAgICJnaGNyLmlvIjogewogICAgICAgICAgICAgICAgICAgICAgICAiYXV0aCI6ICJZMnh2ZFdSNmRXNDZaMmh3WDNKRWRHSnRjSEZtVGxodk1UUmhlVzFRYkhnM2NUUmxhblpsVld3MFpESmpTazVTU2c9PSIKICAgICAgICAgICAgICAgIH0sCiAgICAgICAgICAgICAgICAiaHR0cHM6Ly9pbmRleC5kb2NrZXIuaW8vdjEvIjogewogICAgICAgICAgICAgICAgICAgICAgICAiYXV0aCI6ICJZMmhsYm1kNmFEb3lkM040STBWRVF5UlNSbFk9IgogICAgICAgICAgICAgICAgfQogICAgICAgIH0KfQo=

将上述数值替换到sealed-secret/image-pull-secret.yaml 文件中

kind: Secret
type: kubernetes.io/dockerconfigjson
apiVersion: v1
metadata:
  name: github-regcred
data:      .dockerconfigjson:ewogICAgICAgICJhdXRocyI6IHsKICAgICAgICAgICAgICAgICJnaGNyLmlvIjogewogICAgICAgICAgICAgICAgICAgICAgICAiYXV0aCI6ICJZMnh2ZFdSNmRXNDZaMmh3WDNKRWRHSnRjSEZtVGxodk1UUmhlVzFRYkhnM2NUUmxhblpsVld3MFpESmpTazVTU2c9PSIKICAgICAgICAgICAgICAgIH0sCiAgICAgICAgICAgICAgICAiaHR0cHM6Ly9pbmRleC5kb2NrZXIuaW8vdjEvIjogewogICAgICAgICAgICAgICAgICAgICAgICAiYXV0aCI6ICJZMmhsYm1kNmFEb3lkM040STBWRVF5UlNSbFk9IgogICAgICAgICAgICAgICAgfQogICAgICAgIH0KfQo=
  

创建 Image Pull Secret 对象

kubeseal -f image-pull-secret.yaml -w manifest/image-pull-sealed-secret.yaml --scope cluster-wide

简单解释一下这个命令。首先,-f 参数指定了原始 Sceret 对象文件,也就是 image-pull-secret.yaml。-w 参数表示将加密后的 Secret 对象写入 manifest 目录的 image-pull-sealed-secret.yaml 文件内,这样 ArgoCD 就可以将它一并部署到集群内。–scope 参数表示加密后的 Secret 对象可以在集群的任何命名空间下使用。然后,可以查看 manifest/image-pull-sealed-secret.yaml 文件,加密后的 Secret 对象如下。

root@node1:~/kubernetes-example/sealed-secret/manifest# nano image-pull-sealed-secret.yaml
piVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  annotations:
    sealedsecrets.bitnami.com/cluster-wide: "true"
  creationTimestamp: null
  name: github-regcred
spec:
  encryptedData:
    .dockerconfigjson: AgC0eBsAZrQAbVzVj2NiBlaYhIxlDMWoTsJId+Wsi50nWwS+B6FHnhsWpimgCpNv0KsavFkF6vAuWiClBGsb>
  template:
    metadata:
      annotations:
        sealedsecrets.bitnami.com/cluster-wide: "true"
      creationTimestamp: null
      name: github-regcred
    type: kubernetes.io/dockerconfigjson

创建 Secret 对象

kubeseal -f sample-secret.yaml -w manifest/sample-sealed-secret.yaml --scope cluster-wide

运行命令后,在 manifest 目录下生成 sample-sealed-secret.yaml 文件,它包含加密后的 Secret 内容。

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  annotations:
    sealedsecrets.bitnami.com/cluster-wide: "true"
  creationTimestamp: null
  name: sample-secret
spec:
  encryptedData:
    password: AgBc+wWk84ddVXhwZKo9KbLHnPIlXZqWXsvIOQDrFmRA5rNzmb1+Q3Pk0yXJZ94KLr/DQjsgxJqrciYK9NTRGFYEHoDS9>
  template:
    metadata:
      annotations:
        sealedsecrets.bitnami.com/cluster-wide: "true"
      creationTimestamp: null
      name: sample-secret

上述两个文件更新到github,建议采用git push,如果手动复制,则需要使用cat显示文本全文

git add .
git commit -a -m 'add secret'
git push origin main

验证 image pull secret

进入 ArgoCD 控制台的应用详情,手动点击“SYCN”按钮同步新增的 Secret 对象。此时,应用状态应变为 Healthy 健康状态。同时,Sealed-Secret 控制器会对刚才创建的 SealedSecret 对象进行解密,并重新创建原始的 Kubernetes Secret 对象以供 Deployment 工作负载使用。

在这里插入图片描述

验证Secret

除了镜像凭据,此前还创建了一个提供工作负载密码的 Secret 对象。该密码通过环境变量注入到 Pod 中。接下来,将验证应用是否能够获取来自 Secret 对象提供的密码

kubectl port-forward svc/sample-spring 8081:8080 -n secret-demo
curl http://localhost:8081/actuator/env/PASSWORD
root@node1:~/kubernetes-example/sealed-secret/manifest# curl http://localhost:8081/actuator/env/PASSWORD
{"property":{"source":"systemEnvironment","value":"******"},"activeProfiles":[],"propertySources":[{"name":"server.ports"},{"name":"servletConfigInitParams"},{"name":"servletContextInitParams"},{"name":"systemProperties"},{"name":"systemEnvironment","property":{"value":"******","origin":"System Environment Property \"PASSWORD\""}},{"name":"random"},{"name":"Config resource 'class path resource [application.yml]' via location 'optional:classpath:/'"},{"name":"Management Server"}]}

从返回结果可以发现,应用已经成功获取到了 PASSWORD 环境变量,这说明 Sealed-Secret 控制器也已经生成了原始的 Secret 对象。

后记

本课程体系旨在为学员提供一套全面的云原生技术学习路径,包括容器技术、Kubernetes 部署和管理、Ingress 管理、持久化存储、应用部署、可观测性、服务网格、DevOps 工具链和流水线以及 GitOps 等方面的内容。通过学习这套课程体系,学员将掌握云原生技术的关键概念、原理和实践方法,从而提升云原生应用的部署、管理和协作效率。

  1. Docker 技术实战:学习容器技术的基础知识,包括 Docker 的运作原理、核心组件以及应用部署和监控管理。
  2. Kubernetes 部署和管理实战:深入了解 Kubernetes 的核心概念和基础组件,掌握 Kubernetes 集群的部署、管理和监控技能。
  3. Kubernetes Ingress 管理与运维:学习 Kubernetes Ingress 的概念、工作机制和运维管理方法,提升 Ingress 的部署和管理能力。
  4. Kubernetes 持久化存储实践:探讨 Kubernetes 持久化存储的原理、实现方式和实际应用,提高在 Kubernetes 上实现持久化存储的能力。
  5. Kubernetes 应用部署和管理:学习 Kubernetes 应用部署和管理的基本概念、原理和实现方法,掌握在 Kubernetes 上部署和管理应用的技巧。
  6. Kubernetes 可观测性实践:研究 Kubernetes 可观测性实践的概念、原理和实现方法,涉及监控、日志记录和分析等方面。
  7. 基于 Istio 的服务网格实战:深入了解基于 Istio 的服务网格概念、原理和实现方法,包括服务路由、流量管理、弹性能力和微服务可观测性等。
  8. DevOps 工具链与流水线实践:探讨 DevOps 工具链与流水线的概念、原理和实现方法,涵盖自动化构建、测试、部署和监控等环节。
  9. GitOps 云原生应用的高效部署与管理:全面掌握 GitOps 原理、技术和工具,提高云原生应用部署、管理和协作效率。

通过对这九门课程的学习,学员可以:

  1. 熟练运用 Docker 和 Kubernetes 进行容器化应用的部署和管理。
  2. 掌握 Ingress 和持久化存储在 Kubernetes 集群中的配置和管理方法。
  3. 了解 Kubernetes 可观测性实践,提高应用监控、日志和分析的能力。
  4. 探究 Istio 服务网格的原理和实现,实现微服务的高可用、弹性和安全。
  5. 运用 DevOps 工具链和流水线实现自动化构建、测试、部署和监控。
  6. 掌握 GitOps 的原理和技术,提升云原生应用的部署、管理和协作效率。

本课程体系适合对云原生技术感兴趣的开发者、运维工程师、架构师等专业人士。课程内容丰富、实践性强,旨在帮助学员在实际工作中更好地应用云原生技术,为企业的数字化转型做出贡献。

如果希望获得更详细的课程介绍,请联系: info@cloudzun.com

云原生CI/CD】GitOpsArgoCD 云原生CI/CD正在经历从"自动化"到"智能化"的范式转移。ArgoCD作为GitOps的标杆工具,不仅解决了多环境交付难题,更通过声明式管理重塑了软件交付的生命周期。随着《国家"十四五"数字经济发展规划》对云原生技术的政策支持,掌握GitOps将成为架构师的核心竞争力。建议从业者从际业务痛点出发,结合本文案例逐步构建企业级持续交付体系。 阅读详情

相关推荐

ArgoCD战指南:GitOps驱动下的Kubernetes自动化部署与Helm/Kustomize集成

ArgoCD 是一种 GitOps 持续交付工具,专为 Kubernetes 设计。它能够自动同步 Git 仓库中的声明性配置,并将其应用到 Kubernetes 集群中。本文将介绍ArgoCD 的架构、安装步骤,以及如何结合Helm 和 Kustomize进行 Kubernetes 自动化部署。ArgoCD 是强大的 GitOps 解决方案,可提高 Kubernetes 资源管理效率。结合 Helm 和 Kustomize,可以实现更灵活的自动化部署。需要正确配置权限管理,确保安全性。未来展望✅。

记录从移动端、鸿蒙到物联网与AI的完整实战与思考。专注于分享可复用的工程方案与产品思维,尤其深入鸿蒙生态与全栈开发。以十年工程与管理沉淀,为你提供清晰的技术纵深路径。坚信技术的价值在于“贯通”与“落地”。 1472

把大表拆成更好用的“小仓库”:SAP HANA 表分区设计、分区裁剪与内存代价全解析

摘要:本文深入解析SAP HANA分区技术的核心价值与实现策略。作为内存数据库的"手术刀",分区通过将逻辑表横向切分为独立物理容器,显著提升并行计算能力与查询效率。重点探讨了三种分区类型(Range、Hash、Round-robin)的适用场景,以及分区裁剪的优化原理与前提条件。特别指出分区设计需要平衡查询模式与数据分布,并揭示了分区对内存占用的双向影响机制:既可能因字典复制增加消耗,也可能因数据纯度提升压缩率。通过电商订单表等际案例,展示了合理分区如何将分钟级报表优化至秒级响应。文章

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 1622

ArgoCD战指南:基于GitOpsKubernetes持续交付与多集群管理

云原生微服务架构中,持续交付与配置管理是核心挑战。GitOps作为一种新兴的运维范式,将Git仓库作为基础设施和应用的唯一事来源,通过声明式配置实现版本控制、审计追踪和自动化部署。其核心原理是通过自动化工具持续比对Git中声明的期望状态与际环境状态,并自动同步差异。这一模式在Kubernetes生态中尤为重要,它能有效管理复杂的YAML清单、Helm Chart和多环境配置,解决配置漂移和部署一致性问题。ArgoCD正是这一理念的杰出践,作为专为Kubernetes设计的声明式持续交付工具,它通过

412

Argo CD 安装和多集群管理(二)

本篇目录链接Argo CD 服务端安装Argo的访问方式-LoadBalancerArgo的访问方式-基于ingress部署Argo CD 客户端安装linux命令行MAC版helm部署argocd多集群管理获取到目标集群的config配置信息根据config配置信息,获取到目标集群的上下文信息客户端添加集群界面查看 Argo CD 服务端安装 安装参考:https://argoproj.github.io/argo-cd/getting_started 官方demo:https://cd.apps.arg

最美dee时光的博客 5459

基于Jenkins + Argo 实现多集群的持续交付

前面我们已经掌握了如何通过 Jenkins + Argo CD 的方式实现单集群的持续交付,明白了整个 CI/CD 过程中不同工具在流水线中的关系。所以接下来我们将更深入的了解 Argo CD 的特性。KubeSphere DevOps 基于 Jenkins + Argo 实现单集群的持续交付践。通过上述 List generator 的定义参数,对应好模版,这种类型都属于 Key/Values 类型。source:最后运行流水行以后,等待流水线执行完毕。

KubeSphere 2165

Kubernetes+Gitlab+Jenkins+ArgoCD多集群部署

在企业级环境中,由于业务的需要会有许多Kubernetes集群需要管理,比如Dev环境,UAT环境,Pro环境等. 每次发布和上线都需要分别登录不同集群进行部署项目.如果我们使用了ArgoCD,它可以支持多集群部署,大大提高了效率和准确性. ArgoCD允许同时向多个集群部署应用,还可以轻松地管理不同环境的配置,轻松部署应用程序,提高生产效率.

HYXRX的博客 2307

Gitops 手册 5:使用 ArgoCD 构建 GitOps 工作流

手册将引导您在 Kubernetes 集群上安装 ArgoCD,并在 ArgoCD 上定义并部署示例应用,实现镜像版本变化触发的 GitOps 工作流。

weixin_57766513的博客 661

Nacos - 与 ArgoCD 集成:实现 GitOps 驱动的配置管理

本文探讨如何将Nacos配置中心与ArgoCD集成,实现基于GitOps的配置管理方案。文章首先介绍GitOps的核心概念和工作流程,分析ArgoCD的工作原理及其在Kubernetes环境中的应用。随后详细讲解Nacos的服务发现与配置管理功能,并针对两者集成的技术挑战提出解决方案。重点推荐采用自定义控制器配合CRD的方式,通过定义NacosConfig资源并部署监听控制器,实现Git仓库与Nacos配置的自动化同步。最后提供环境准备指南,为构建完整的GitOps驱动配置管理系统奠定基础。

千淘万漉虽辛苦,吹尽狂沙始到金 2万+

GitOps 手册 6: 实现 ArgoCD 高级发布策略

手册将探讨如何利用 ArgoCD高级特性,如 Argo Rollout、AnalysisTemplate 以及 Argo Rollout Dashboard,实现高级的发布策略,包括蓝绿发布、金丝雀发布和自动渐进交付

weixin_57766513的博客 1155

GitOps 手册 2 :安装 Kubernetes 应用平台

本文旨在指导您使用Kind部署一个单节点的Kubernetes集群,并Kubernetes的基本功能。Kind是一个用于运行本地Kubernetes集群的工具,它非常适合测试和学习目的。在本手册中,您将学习到如何部署Kubernetes集群、安装基础集群服务,以及践核心功能,如运行Pods,使用Deployments调度工作负载,发布服务,以及自动扩缩容。

weixin_57766513的博客 280

k9s ArgoCD集成:GitOps工作流的终端管理界面

在现代云原生环境中,GitOps已成为部署和管理Kubernetes应用的标准践。ArgoCD作为GitOps工具链的核心组件,提供了声明式的应用部署能力。然而,在日常运维中,开发者和运维人员经常需要在终端环境中快速查看、管理和调试ArgoCD应用。k9s作为功能强大的Kubernetes终端管理工具,通过原生插件系统提供了与ArgoCD的无缝集成,让您能够在终端界面中高效管理GitOps工作流...

gitblog_00529的博客 1105

GitOpsKubernetes密钥管理:Sealed-Secrets与ArgoCD集成

云原生应用部署中,敏感信息管理是安全架构的核心环节。Kubernetes Secret作为存储密码、令牌和密钥等敏感数据的标准资源,其安全存储与分发直接影响系统安全性。传统方式将Secret排除在版本控制之外,违背了GitOps的声明式与可追溯原则。Sealed-Secrets通过非对称加密技术,将Secret加密为可在Git中安全存储的SealedSecret自定义资源,实现“加密存、集群解”的安全模型。结合ArgoCD的声明式同步能力,这套方案为持续交付管道提供了既符合GitOps工作流又保障敏感数据

weixin_34060299的博客 379

推荐:ArgoCD Lovely Plugin——优化GitOps之旅

推荐:ArgoCD Lovely Plugin——优化GitOps之旅 在寻求更高效GitOps践的道路上,我们经常会遇到这样一个挑战:如何将复杂的应用配置管理得既高效又灵活?答案就是ArgoCD Lovely Plugin。这一创新插件旨在弥补Argo CD原生功能的不足,带来一系列强大特性,让您的DevOps流程更加顺畅。 项目简介 ArgoCD Lovely Plugin,正如其名,是为那...

gitblog_00833的博客 571

Swag与ArgoCD集成:GitOps流程中的文档部署

你是否还在手动更新API文档?团队是否经常抱怨文档与代码不同步?在DevOps日益普及的今天,API文档的管理却常常成为被遗忘的角落。本文将展示如何通过Swag自动生成Swagger文档,并利用ArgoCD实现文档的GitOps式部署,彻底解决文档滞后问题。 读完本文你将获得: - Swag文档自动化生成的完整流程 - 基于Docker的文档容器化方案 - ArgoCD配置实现文档自动部署 - ...

gitblog_00170的博客 711

告别"配置漂移":Helm+ArgoCD打造GitOps应用交付流水线

你是否还在为Kubernetes集群中的"配置漂移"问题头疼?部署时的配置与际运行状态不一致、手动修改导致的版本混乱、多环境同步困难——这些问题正在消耗团队大量精力。本文将带你用Helm与ArgoCD构建完整的GitOps工作流,实现"一次配置,处处一致"的应用交付新范式。读完本文,你将掌握: - Helm Chart封装应用配置的最佳践 - ArgoCD自动同步机制的工作原理 - 多环境部...

gitblog_00938的博客 1196

第83章:ArgoCDGitOps工作流

声明式配置系统的期望状态通过声明式配置定义配置描述"应该是什么"而非"如何做"使用YAML、JSON等格式描述资源以Git为单一事来源所有配置存储在Git仓库中完整的变更历史和审计跟踪版本控制和回滚能力协作和审查流程自动化协调系统持续监控际状态与期望状态的差异自动应用必要的变更以达到期望状态偏差检测和自愈能力拉取模型(Pull Model)作者(Operator)从Git拉取配置避免直接访问集群的需要提高安全性和可审计性开发者工作流开发者提交代码到应用仓库。

上海交通大学电院毕业,现互联网大厂开发工程师 120

sealed-secrets与ArgoCD集成:GitOps环境中的密钥管理最佳

GitOps践中,将配置文件存储在Git仓库中实现基础设施即代码(IaC)已成为标准流程。然而,**密钥和敏感信息的管理**始终是一个棘手问题:直接存储明文密钥存在严重安全风险,而传统加密方案又往往破坏了GitOps的自动化流程。根据CNCF 2024年调查,**73%的企业**在GitOps施中因密钥管理不当导致过安全事件或部署中断。 Sealed Secrets通过**非对称加密**技...

gitblog_00973的博客 685

云原生时代的“魔法工匠”:ArgoCD 深度揭秘

ArgoCD 作为云原生应用部署和管理领域的佼佼者,凭借其对 GitOps 理念的深度践行,为我们带来了前所未有的便利和效率。通过将 Git 仓库作为应用部署的 “单一事来源”,ArgoCD 实现了应用的声明式部署和自动化生命周期管理,大大减少了人为错误,提高了应用交付的准确性和一致性。在际应用中,ArgoCD 的优势得到了充分体现。无论是企业级应用的大规模部署,还是微服务架构下复杂应用的管理ArgoCD 都能够应对自如。

大雨淅淅的博客 2471
上一篇: GitOps 实操手册 6: 实现 ArgoCD 高级发布策略
下一篇: 跟着查老四学Python Day 0:列目录,立Flag
cloudzun
博客等级 码龄5年 8粉丝 · 14原创
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值