Git에 배포 파일을 올려두고도 계속 직접 반영하는 게 귀찮아짐.

처음에는 manifest를 직접 적용했음.

# Kubernetes manifest를 직접 적용한다.
kubectl apply -f k8s/

Helm으로 묶은 뒤에도 결국 배포 명령은 직접 실행해야 했음.

# Helm Chart를 직접 배포한다.
helm upgrade --install rhymix ./helm/rhymix \
  -n 3009-yeonghoon-kim \
  --set namespace.create=false

그래서 Git에 적힌 상태를 기준으로 Kubernetes 상태를 맞추는 구조를 잡기 시작함.

구축 매뉴얼 기준으로는 ArgoCD를 설치하고 GitOps 배포 구조의 입구를 준비하는 단계.

Git 저장소
= 원하는 상태

Kubernetes 클러스터
= 실제 상태

ArgoCD
= Git의 원하는 상태와 클러스터의 실제 상태를 비교하고 맞추는 도구

ArgoCD namespace 생성 및 설치.

ArgoCD install manifest는 CRD annotation 크기 문제로 일반 apply가 실패할 수 있어서 server-side apply 사용.

# ArgoCD namespace를 만들고 install manifest를 server-side apply 방식으로 설치한다.
set -e
kubectl create namespace argocd || true
kubectl apply --server-side --force-conflicts -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.4.3/manifests/install.yaml
kubectl -n argocd rollout status deployment/argocd-server --timeout=240s
kubectl -n argocd rollout status deployment/argocd-repo-server --timeout=240s
kubectl -n argocd rollout status deployment/argocd-applicationset-controller --timeout=240s
kubectl -n argocd rollout status statefulset/argocd-application-controller --timeout=240s

ArgoCD 설치 후에는 cluster-apps repo의 bootstrap manifest를 적용함.

# ArgoCD 설정, 알림 ConfigMap, Ingress를 적용한다.
set -e
cd /home/ioniere/gitlab-project-clones/ioniere/cluster-apps
kubectl -n argocd apply -f bootstrap/argocd-cmd-params-cm.yaml
kubectl -n argocd apply -f bootstrap/argocd-notifications-cm.yaml
kubectl -n argocd apply -f bootstrap/argocd-ingress.yaml
kubectl -n argocd rollout restart deployment/argocd-server
kubectl -n argocd rollout status deployment/argocd-server --timeout=180s

여기서 적용하는 파일은 Secret이 아니라 ConfigMap과 Ingress.

argocd-cmd-params-cm.yaml에서는 ArgoCD server를 insecure 모드로 둠.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  server.insecure: "true"

외부에 HTTP로 그대로 공개한다는 뜻은 아님.

앞단의 ingress-nginx가 HTTPS 입구 역할을 하고, ingress-nginx 뒤쪽에서 argocd-server로 넘길 때 HTTP를 사용하는 구조.

ArgoCD Ingress는 argo.yeonghoon.kim으로 들어온 요청을 argocd-server Service로 보냄.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server
  namespace: argocd
spec:
  ingressClassName: nginx
  rules:
    - host: argo.yeonghoon.kim
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port:
                  number: 80

접속 흐름.

https://argo.yeonghoon.kim/
-> Ingress VIP 192.168.200.49
-> ingress-nginx
-> argocd-server Service:80
-> argocd-server Pod

Ingress 확인.

# ArgoCD Ingress가 생성됐고 Ingress VIP에 붙었는지 확인한다.
kubectl -n argocd get ingress argocd-server -o wide

Ingress VIP 직접 응답 확인.

# Kubernetes Ingress VIP로 직접 ArgoCD UI HTTP 상태 코드를 확인한다.
curl -k -sS -o /dev/null -w "%{http_code}\n" \
  --max-time 10 \
  --resolve "argo.yeonghoon.kim:443:192.168.200.49" \
  https://argo.yeonghoon.kim/

정상 기준은 HTTP 200.

root Application 구조도 확인함.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cluster-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: ssh://[email protected]:2224/ioniere/cluster-apps.git
    targetRevision: main
    path: .
    directory:
      recurse: true
      include: '{projects/*.yaml,apps/*.yaml,storage/*.yaml,grafana/*.yaml,alerting/*.yaml,monitoring/*.yaml}'
  syncPolicy:
    automated: {}
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd

이 파일은 ArgoCD에게 cluster-apps 저장소를 읽고 그 안의 앱 정의들을 운영 대상으로 삼으라고 알려주는 입구.

다만 이 단계에서 root Application을 바로 적용하지는 않음.

private GitLab repo를 읽으려면 ArgoCD repo credential Secret이 필요하고, Pod 안에서 gitlab.yeonghoon.kim을 올바른 IP로 찾는 DNS/CoreDNS 경로도 필요함.

그래서 이 날은 ArgoCD 설치와 Ingress 확인, GitOps 구조 입구 준비까지로 정리.

Secret 복구와 GitLab 접근 경로를 준비한 뒤 root Application을 적용하는 순서로 잡음.