خوشه bootstrap با fluxcd – جامعه dev

این تکرار بعدی مهاجرت “5 صبح باشگاه” است. همانطور که می توانید از سایر نوشته های منتشر شده در این سریال به یاد داشته باشید ، من روزانه با Kubernetes بازی کردم. نه به صورت روزانه ، بلکه به معنای واقعی کلمه هر روز. صادقانه بگویم ، من از نتایج بسیار خوشحالم. با این حال ، برنامه من یک چالش دارد ، که نیاز به حل آن دارد. زمان ساخت طولانی بود 15 دقیقه هر روز ، و گاهی اوقات اپراتور ESO در مورد استفاده از Kustomize برای استقرار مبتنی بر HELM با مشکل روبرو می شد. و فقط به دلیل محدودیت های تصادفی ، من می خواستم از یک ابزار برای بوت کردن یک خوشه استفاده کنم.

به همین دلیل است که من با طرح ارائه شده آخرین بار شروع کردم. بنابراین تقسیم منطقی در هر اپراتور با base/overlay زیر گروه

سپس من فکر کردم ، چرا فقط از برخی از راه حل های استاندارد برای آن استفاده نمی کنیم؟
ایده اول گسترش استفاده از آرگو برای زیرساخت های من بود. اما … نیاز به تنظیم ESO ، Doppler Secret و ArgoCD دارد. سپس می توانم برنامه ها را از سطح GIT تنظیم کنم.

این چالش ، آسانتر ، سریعتر و استاندارد تر از آن بود که در حال حاضر بود.

از ابتدا شروع می شود

چه شار است؟ و چه چیزی نیست؟

Flux ابزاری برای نگه داشتن Kubernetes است
خوشه های همگام با منابع پیکربندی (مانند مخازن GIT) ،
و در صورت وجود کد جدید برای استقرار ، به روزرسانی به روزرسانی ها.

ما می توانیم از Flux برای حفظ پیکربندی کل خوشه خود در Sync ، با مخزن GIT استفاده کنیم. نکته جالب این است که ما می توانیم برنامه ها و مادون قرمز را با استفاده از شار پیکربندی کنیم.

با این حال ، مدیریت برنامه ها با Flux به نظر من ساده ترین و راحت ترین راه حل نیست. به خصوص ، اگر ما اغلب نسخه ها را تغییر می دهیم و دوست داریم حداقل چند وابستگی بین برنامه ها و مادون قرمز داشته باشیم. به عنوان مثال ، نمونه ایمن من به آن نیاز دارد csi-driver-smb، که از طرف دیگر به آن نیاز دارد external-secret-operator وت external-secret-secret
(پیوند واقعی بین راز درون خوشه ای و ESO ClusterSecretStore). بنابراین ، هر Relese جدید ، باید ساخته شود و بررسی کند که تمام Kustomizations در محل وجود دارد.
سپس در واقع یک نسخه جدید را مستقر کنید. فرآیند بسیار طولانی ، همچنین ArgoCD UI فقط استفاده بهتر ، آسانتر و قطعاً کاربر پسند تر است – حداقل به نظر من.

ساخت مخزن

بنابراین پس از چند دور اولیه ، در حالت زیر به پایان رسید:

.
├── README.md
├── clusters
│   └── cluster0
│       └── flux-system
│           ├── gotk-components.yaml
│           ├── gotk-sync.yaml
│           ├── infrastructure.yaml
│           └── kustomization.yaml
└── infrastructure
    └── controllers
        ├── argocd-operator
        │   ├── configmap-patch.yaml
        │   ├── kustomization.yaml
        │   ├── namespace.yaml
        │   └── patch-argocd-server-annotations.yaml
        ├── argocd-operator-apps
        │   ├── applications.yaml
        │   ├── kustomization.yaml
        │   ├── projects.yaml
        │   └── repositories.yaml
        ├── csi-driver-smb
        │   ├── csi-driver-smb.yaml
        │   └── kustomization.yaml
        ├── external-secrets
        │   ├── external-secrets-operator.yaml
        │   └── kustomization.yaml
        ├── external-secrets-secret
        │   ├── cluster-secret-store.yaml
        │   └── kustomization.yaml
        ├── tailscale-operator
        │   ├── kustomization.yaml
        │   └── tailscale-operator.yaml
        ├── tailscale-operator-secrets
        │   ├── kustomization.yaml
        │   └── tailscale-operator-exteral-secret.yaml
        └── traefik
            ├── kustomization.yaml
            └── traefik-ext-conf.yaml

اکنون ما به توضیحاتی نیاز داریم ، درست است؟

پیکربندی شار

clusters
└── cluster0
    └── flux-system
        ├── gotk-components.yaml
        ├── gotk-sync.yaml
        ├── infrastructure.yaml
        └── kustomization.yaml

در اینجا ما پیکربندی خوشه خود را داریم که یک ایده عالی است. در یک مخزن می توانیم بر اساس ارائه دهنده ، محیط یا مکان ، تنظیماتی برای چندین خوشه داشته باشیم و آنها را به روشی بسیار ساده مدیریت کنیم. سپس ما پرونده های سیستم شارژ منظم داریم ، بنابراین flux-system/gotk-components.yaml وت flux-system/gotk-sync.yamlبشر بعد ، بیایید در مورد ساده من صحبت کنیم Kustomization پرونده

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - gotk-components.yaml
  - gotk-sync.yaml
  - infrastructure.yaml

این فقط به Flux می گوید ، که بعد از بوت کردن خود ، نصب کنید
تجلی بر اساس infrastructure.yaml پرونده بنابراین بیایید نگاهی به مهمترین قسمت پیکربندی بیندازیم.

---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: csi-driver-smb
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/controllers/csi-driver-smb
  prune: true
  wait: true
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: external-secrets
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/controllers/external-secrets
  prune: true
  wait: true
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: external-secrets-secret
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/controllers/external-secrets-secret
  dependsOn:
    - name: external-secrets
  prune: true
  wait: true
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: tailscale-operator
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/controllers/tailscale-operator
  dependsOn:
    - name: external-secrets-secret
  prune: true
  wait: true
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: tailscale-operator-secret
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/controllers/tailscale-operator-secrets
  dependsOn:
    - name: external-secrets
  prune: true
  wait: true
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: traefik
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/controllers/traefik
  prune: true
  wait: true
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: argocd-operator
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/controllers/argocd-operator
  dependsOn:
    - name: tailscale-operator
  prune: true
  wait: true
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: argocd-apps
  namespace: flux-system
spec:
  interval: 1h
  retryInterval: 1m
  timeout: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infrastructure/controllers/argocd-operator-apps
  dependsOn:
    - name: argocd-operator
  prune: true
  wait: true

همانطور که می بینید من به شدت به آن اعتماد می کنم dependsOn فرمان این به دلیل طراحی Archtecture Flux و Kubernetes است. هنگامی که ما در حال استفاده از kustomization هستیم ، ما ترتیب ایجاد منابع را کنترل نمی کنیم. البته ، اگر ما یک پرونده ، سرویس ، ورود و استقرار را در آن قرار دهیم ، Kubernetes می داند چگونه این کار را انجام دهد. مشکل این است که وقتی برنامه ای را که وابستگی به یکدیگر دارد ، مستقر می کنیم ، این چیزی نیست که Kubernetes می فهمد. بنابراین ما باید مستقیماً آن را مشخص کنیم. در مثال من csi-driver-smbبا external-secretsوت traefik می توان به صورت موازی نصب کرد ، اما پس از آن ما روابط داریم. در پایان ، ما در حال نصب Argo هستیم app-of-appsعلاوه بر این ، به طور کلی به تمام مؤلفه های قبلی نیاز دارد traefik – من ترافیک خود را از طریق صفحه مخفی در آنجا مسیریابی می کنم ، نه از طریق اینترنت.

اکنون می توانید فکر کنید:

برنامه برنامه؟ شما فقط مادون را گفتید!

این درست است ، منطق من کاملاً پیچیده بود ، صادقانه بگویم. به یاد می آورید ، وقتی من در مورد استفاده استفاده کردم؟ بوت کردن کل خوشه به گونه ای که بتوانم سریع با آن کار کنم. برنامه ها بخشی از خوشه کلی در پایان هستند. بنابراین تعریف برنامه برنامه من بسیار ساده بود:

infrastructure/controllers/argocd-operator-apps
├── applications.yaml
├── kustomization.yaml
├── projects.yaml
└── repositories.yaml

بیایید یک به یک به داخل آن شیرجه بزنیم.

1. برنامه ها. yaml

    ---
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: self-sync
      namespace: argocd
    spec:
      syncPolicy:
        automated:
          selfHeal: true
      project: non-core-namespaces
      source:
        repoURL: https://codeberg.org/3sky/argocd-for-home
        targetRevision: HEAD
        path: app-of-apps
      destination:
        server: https://kubernetes.default.svc
        namespace: argocd
   

   این یک تعریف بسیار ساده از اصلی من است Application این همه برنامه های اجرا شده روی خوشه من را کنترل می کند. در اینجا هیچ چیز خاصی نیست ، من در حال آزمایش بودم codeberg، اما بیایید بعداً در مورد آن صحبت کنیم.

2. kustomization.yaml

     ---
     apiVersion: kustomize.config.k8s.io/v1beta1
     kind: Kustomization
   
     namespace: argocd
     resources:
       - repositories.yaml
       - projects.yaml
       - applications.yaml
   

   Kustomization ساده است ، فقط در مسیر منطق سفارش داده شده است.

   مخزن -> پروژه -> کاربرد

3. پروژه ها

     ---
     apiVersion: argoproj.io/v1alpha1
     kind: AppProject
     metadata:
       name: non-core-namespaces
       namespace: argocd
     spec:
       description: Allow argo deploy everywhere
       sourceRepos:
         - 'https://codeberg.org/3sky/argocd-for-home'
       destinations:
         - namespace: '*'
           server: https://kubernetes.default.svc
       namespaceResourceWhitelist:
         - group: '*'
           kind: '*'
       clusterResourceWhitelist:
         - group: '*'
           kind: '*'
   

   همانطور که من ایجاد می کنم namespaces به عنوان بخشی از راه اندازی برنامه من ، مجوز اعطا شده به پروژه های آرگو بسیار گسترده است. در این حالت ، من فقط به روند GITOPS اعتماد دارم.

4. repositories.yaml

     apiVersion: external-secrets.io/v1beta1
     kind: ExternalSecret
     metadata:
       name: gitops-with-argo-secret
       namespace: argocd
     spec:
       refreshInterval: 6h
       secretStoreRef:
         name: doppler-auth-argocd
         kind: ClusterSecretStore
       target:
         name: gitops-with-argo
         creationPolicy: Owner
         template:
           type: Opaque
           metadata:
             labels:
               argocd.argoproj.io/secret-type: repository
           data:
             type: git
             url: https://codeberg.org/3sky/argocd-for-home
             username: 3sky
             password: "{{ .password }}"
       data:
         - secretKey: password
           remoteRef:
             key: CODEBERG_TOKEN
   

   این احتمالاً جالب ترین قسمت پیکربندی است. همانطور که ما قادر به تزریق رمز عبور خود به طور مستقیم نیستیم argocd.argoproj.io/secret-type: repository، که یک راز معمولی Kubernetes است. ما باید کل شی را تولید کنیم
   با ESO – جزئیات را می توان در اینجا یافت.

و همین است. حال بیایید در مورد روند واقعی Bootstrap صحبت کنیم.

محیط بوت استراپ

1. زیرساخت ها را با Terraform بچرخانید.

   terraform apply -var="local_ip=$(curl -s ifconfig.me)"
   

2. نصب K3s با چنگال محلی K3S قابل اتصال.

   ansible-playbook playbooks/site.yml -i inventory.yml
   

3. kubeconfig را بار کنید

   export KUBECONFIG=/home/kuba/.kube/config.hetzner-prod
   kubectl config use-context k3s-ansible
   

4. پیکربندی داپلر (ما در جایی به یک راز ابتکار نیاز داریم)

   kubectl create namespace external-secrets
   kubectl create secret generic \
     -n external-secrets doppler-token-argocd \
     --from-literal dopplerToken=""
   

5. بوت استرپ خوشه

   flux bootstrap github \
     --owner=3sky \
     --repository=flux-at-home \
     --branch=main \
     --path=./clusters/cluster0 \
     --personal
   

   جایی که GitHub به صورت بومی پشتیبانی می شود (از طریق برنامه های GitHub). راه حل هایی مانند CodeBerg به یک روش مستقیم تر نیاز دارند.

   flux bootstrap git \
     --url=ssh://git@codeberg.org/3sky/flux-at-home.git \
     --branch=main   \
     --path=./clusters/cluster0   \
     --private-key-file=/home/kuba/.ssh/id_ed25519_git
   

6. در صورت لزوم رمز عبور argocd را دریافت کنید

   kubectl --namespace argocd \
     get secret argocd-initial-admin-secret \
     -o json | jq -r '.data.password' | base64 -d
   

خلاصه

با این مجموعه دستورات ، من قادر به تنظیم خوشه های تازه ، با هتزنر یا هر چیز دیگری در 7 دقیقه است. شروع از نصب K3s گرفته تا برنامه های کاربردی از طریق تونل Cloudflare یا Tailscale Tailnet. صادقانه بگویم من واقعاً از نتیجه این تمرین راضی هستم. علاوه بر یک خوشه طولانی برای برنامه های خود میزبان من. من می توانم به راحتی ، سریع و با هزینه های کم نسخه های جدید ARGOCD را آزمایش کنم ، یا smb-driver اپراتور ، بدون اینکه به تنظیم فعلی من آسیب برساند! و این عالی است ، صادقانه بگویم. به خصوص برای خود میزبانی ، جایی که برنامه هایی که در آن کار می کنند خوب است production mode، حتی اگر فقط یک کاربر وجود داشته باشد.