실습
- ArgoCD 설치 및 Kube Cluster, Git Repo 연동
- ArgoCD를 이용한 Deploy 및 Helm Application 배포
- GitOps 실습 : 명령어를 통한 Deploy 상태 수정 후 ArgoCD Sync 상태 확인
실습 내역을 교육 완료 후 테스트 클러스터 환경에서 직접 해 보시길 권고합니다. IT는 백문이 불여일타입니다.
Why Argo for GitOps
실 서비스 운영 환경에서 다양한 담당자가 여러가지 이유로 Kube 클러스터 설정을 변경합니다. 문제는 수정된 History가 제대로 관리가 안 된다는 것 입니다. 개발자도 다양하고 운영자도 다양합니다. 가장 심각한 건 저는 제가 어제 왜 수정했는지 도무지 기억이 안 납니다. 운영 환경을 섣불리 k edit 으로 수정하고 해당 내역을 Git Repo에 저장을 안하고는 합니다.
이러한 혼돈을 막기 위하여 Git Repo에 저장된 Source만 단일 소스로 실제 운영 환경에 반영하자는 것이 GitOps 입니다. Git Repo가 아닌 담당자 PC YAML 파일 혹은 명령어를 통한 수정이 발생하면 GitOps Tool에서 이를 감지하여 Alarm으로 알려 줍니다.
GitOps의 핵심은 Git 저장소에 저장된 쿠버네티스 매니페스트 같은 파일을 이용하여, 배포를 선언적으로 한다는 것입니다. 즉, Git에 저장된 매니페스트가 쿠버네티스 클러스터에도 똑같이 반영된다는 것입니다.
출처 : https://kangwoo.kr/tag/gitops/
GitOps Tool로 여러 Tool을 사용하실 수 있는데 저는 사용법이 간단하고 직관적인 UI를 제공하는 ArgoCD를 사용합니다.
Why Argo CD?
Application definitions, configurations, and environments should be declarative and version controlled. Application deployment and lifecycle management should be automated, auditable, and easy to understand.
출처: https://argoproj.github.io/argo-cd/
Argo 설치
설치는 공식 홈페이지 가이드를 따릅니다.
https://argo-cd.readthedocs.io/en/stable/getting_started/
[spkr@erdia22 polaris-4.0.2 (kspray:polaris)]$ kubectl create namespace argocd
rgocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yamlnamespace/argocd created
[spkr@erdia22 polaris-4.0.2 (kspray:polaris)]$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io created
serviceaccount/argocd-application-controller created
serviceaccount/argocd-dex-server created
serviceaccount/argocd-redis created
serviceaccount/argocd-server created
role.rbac.authorization.k8s.io/argocd-application-controller created
role.rbac.authorization.k8s.io/argocd-dex-server created
role.rbac.authorization.k8s.io/argocd-redis created
role.rbac.authorization.k8s.io/argocd-server created
clusterrole.rbac.authorization.k8s.io/argocd-application-controller created
clusterrole.rbac.authorization.k8s.io/argocd-server created
rolebinding.rbac.authorization.k8s.io/argocd-application-controller created
rolebinding.rbac.authorization.k8s.io/argocd-dex-server created
rolebinding.rbac.authorization.k8s.io/argocd-redis created
rolebinding.rbac.authorization.k8s.io/argocd-server created
clusterrolebinding.rbac.authorization.k8s.io/argocd-application-controller created
clusterrolebinding.rbac.authorization.k8s.io/argocd-server created
configmap/argocd-cm created
configmap/argocd-gpg-keys-cm created
configmap/argocd-rbac-cm created
configmap/argocd-ssh-known-hosts-cm created
configmap/argocd-tls-certs-cm created
secret/argocd-secret created
service/argocd-dex-server created
service/argocd-metrics created
service/argocd-redis created
service/argocd-repo-server created
service/argocd-server created
service/argocd-server-metrics created
deployment.apps/argocd-dex-server created
deployment.apps/argocd-redis created
deployment.apps/argocd-repo-server created
deployment.apps/argocd-server created
statefulset.apps/argocd-application-controller created
networkpolicy.networking.k8s.io/argocd-application-controller-network-policy created
networkpolicy.networking.k8s.io/argocd-dex-server-network-policy created
networkpolicy.networking.k8s.io/argocd-redis-network-policy created
networkpolicy.networking.k8s.io/argocd-repo-server-network-policy created
networkpolicy.networking.k8s.io/argocd-server-network-policy created
(이전 버전에는 없던 networkpolicy가 추가되었네요.)
아직도 Helm을 사용하지 않는 것은 참 의문입니다. ㅎㅎ
정상적으로 설치가 완료되면 POD 확인 가능합니다.
[spkr@erdia22 ~ (kspray:argocd)]$ kns argocd
Context "kspray" modified.
Active namespace is "argocd".
[spkr@erdia22 ~ (kspray:argocd)]$ kgp
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
argocd-application-controller-0 1/1 Running 0 104s 10.233.87.5 ksp3 <none> <none>
argocd-dex-server-56dc8fc7df-5r57q 1/1 Running 0 105s 10.233.79.4 ksp2 <none> <none>
argocd-redis-9567956cd-xsvps 1/1 Running 0 105s 10.233.87.4 ksp3 <none> <none>
argocd-repo-server-747c48457-7wkp2 1/1 Running 0 105s 10.233.79.5 ksp2 <none> <none>
argocd-server-595b6f797d-lkgd7 1/1 Running 0 105s 10.233.127.6 ksp1 <none> <none>
Admin Page 접속을 위하여 기존 argocd-server 서비스 타입을 ClusterIP에서 NodePort로 변경합니다.
[spkr@erdia22 46.ArgoCD (kspray:argocd)]$ k get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
argocd-dex-server ClusterIP 10.233.63.39 <none> 5556/TCP,5557/TCP,5558/TCP 4m16s
argocd-metrics ClusterIP 10.233.31.187 <none> 8082/TCP 4m16s
argocd-redis ClusterIP 10.233.14.46 <none> 6379/TCP 4m16s
argocd-repo-server ClusterIP 10.233.2.161 <none> 8081/TCP,8084/TCP 4m16s
argocd-server ClusterIP 10.233.38.211 <none> 80/TCP,443/TCP 4m16s
argocd-server-metrics ClusterIP 10.233.31.209 <none> 8083/TCP 4m16s
[spkr@erdia22 46.ArgoCD (kspray:argocd)]$ k get svc argocd-server -o yaml |k neat > argocd-server-svc.yml
argocd-server-svc.yml 파일을 아래와 같이 type: NodePort로 수정합니다.
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/component: server
app.kubernetes.io/name: argocd-server
app.kubernetes.io/part-of: argocd
name: argocd-server
namespace: argocd
spec:
# clusterIP: 10.233.38.211
# clusterIPs:
# - 10.233.38.211
# ipFamilies:
# - IPv4
# ipFamilyPolicy: SingleStack
type: NodePort
ports:
- name: http
port: 80
targetPort: 8080
- name: https
port: 443
targetPort: 8080
selector:
app.kubernetes.io/name: argocd-server
[spkr@erdia22 46.ArgoCD (kspray:argocd)]$ ka argocd-server-svc.yml
service/argocd-server configured
[spkr@erdia22 46.ArgoCD (kspray:argocd)]$ k get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
argocd-dex-server ClusterIP 10.233.63.39 <none> 5556/TCP,5557/TCP,5558/TCP 6m15s
argocd-metrics ClusterIP 10.233.31.187 <none> 8082/TCP 6m15s
argocd-redis ClusterIP 10.233.14.46 <none> 6379/TCP 6m15s
argocd-repo-server ClusterIP 10.233.2.161 <none> 8081/TCP,8084/TCP 6m15s
argocd-server NodePort 10.233.38.211 <none> 80:31525/TCP,443:30314/TCP 6m15s
argocd-server-metrics ClusterIP 10.233.31.209 <none> 8083/TCP 6m15s
이제 NodePort 30314 Port로 접속합니다.
- 이제 argo 문어(다리가 8개네요)를 확인 할 수 있습니다.
ID는 admin 이고 Password는 아래와 같이 argocd-initial-admin-secret 에서 참조합니다.
[spkr@erdia22 ~ (kspray:argocd)]$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
NsDJcdwGRhcCKDrJ
(secret 암호 정보를 평문으로 가져오는 방법입니다.)
ID, PWD 입력 후 무사히 비어있는(?) 페이지 확인 하실 수 있습니다.
Git Repositories 추가
이제 ArgoCD에 Git Source Repo를 추가 합니다. (물론 사전에 로컬 Git Repo가 있어야 합니다. 아니면 GitHub도 사용 가능합니다.)
참조: https://argoproj.github.io/argo-cd/user-guide/private-repositories/
화면 좌측 Configuration 톱니 바퀴를 선택하시고 Repositories 클릭합니다.
로컬 GitLab URL을 도메인이(gitlab.spkr.io 등 사설 도메인) 아닌 IP로 입력 가능합니다.
이 때 도메인이 아닌 IP를 입력하면 인증서 관련 에러가 발생하므로 ‘Skip server verification’ 체크 합니다.
이제 정상적으로 git 등록 되었습니다.
Application 배포
이제 git 소스 YAML 파일을 kube cluster로 배포 하겠습니다.
참조: https://argoproj.github.io/argo-cd/getting_started/
먼저, 배포할 deployment yaml 파일을 미리 git source에 push 합니다.
- 저는 아래 busybox, nginxhello YAML 파일을 미리 06.Deployment 디렉토리로 git push 하였습니다.
이제 해당 source 파일을 Argocd 통하여 배포합니다.
먼저, 화면 좌측 상단 Application - + NEW APP 클릭합니다.
임의로 Application Name 지정하고 Project는 default로 선택합니다.
이전에 등록한 Git Repository URL을 선택하고 deploy Path를 지정합니다. (디렉토리 단위도 가능합니다.)
DESTINATION 으로 Local Kube Cluster(argocd가 배포된 클러스터), namespace로 default를 선택합니다.
이제 CREATE 합니다.
생성 후 SYNC 버튼을 클릭 합니다.
조금 기다리면 배포 상태를 확인 가능합니다.
이제 Kube cluster에서 해당 busybox, nginx-hello Deployment를 확인 하실 수 있습니다. (k apply -f 안해도 자동으로 배포 되었습니다. ^^)
[spkr@erdia22 06.Deployment (kspray:default)]$ kgp
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
busybox-6d8496d56f-6v7c5 1/1 Running 0 2m1s 10.233.127.11 ksp1 <none> <none>
nginx-hello-6c74c6f84d-lrsnt 1/1 Running 0 2m1s 10.233.127.12 ksp1 <none> <none>
nginx-hello-6c74c6f84d-ncxvs 1/1 Running 0 2m1s 10.233.79.8 ksp2 <none> <none>
ArgoCD UI에서 좀 더 상세한 내역을 확인 가능합니다.
GitOps 실습
먼저, Git Repo의 Source 파일 수정 없이 임의로 현재 상태를 변경 하겠습니다. Replica 갯수를 2개에서 1개로 조정합니다.
[spkr@erdia22 06.Deployment (kspray:default)]$ k scale deployment nginx-hello --replicas=1
deployment.apps/nginx-hello scaled
nginx-hello POD 개수가 1개가 되었습니다.
[spkr@erdia22 06.Deployment (kspray:default)]$ kgp
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
busybox-6d8496d56f-6v7c5 1/1 Running 0 6m24s 10.233.127.11 ksp1 <none> <none>
nginx-hello-6c74c6f84d-ncxvs 1/1 Running 0 6m24s 10.233.79.8 ksp2 <none> <none>
이제 ArgoCD 에서 Sync 상태를 확인합니다. (여기서 Sync, 동기화란 Git Repo YAML 파일과 현재 실제 적용된 클러스터 적용 내역 간의 동기화 여부를 의미합니다.)
위와 같이 OutOfSync 상태로 변경되었습니다. 즉 Git Repo의 YAML File에서 replicas=2로 설정되었는데, 실제 클러스터 상태는 replicas=1이므로 2개의 상태가 서로 다르다는 것을 (똑똑한) ArgoCD가 보여주고 있습니다.
- nginx-hello 클릭하시면 좀 더 상세한 로그 확인이 가능합니다.
상세 내역을 DIFF로 확인하면 친절하게 replicas 이 서로 다르다는 것을 확인 하실 수 있습니다.
이제 동기화를 위하여 YAML 파일을 수정(replicas=1) 하고 git push 합니다.
[spkr@erdia22 06.Deployment (kspray:default)]$ git add . && git commit -m "modify replicas
2 to 1"
[master 674464e] modify replicas 2 to 1
1 file changed, 1 insertion(+), 1 deletion(-)
[spkr@erdia22 06.Deployment (kspray:default)]$ git push
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 333 bytes | 333.00 KiB/s, done.
Total 4 (delta 2), reused 0 (delta 0)
To https://gitlab.spk.io/jerry/spk.git
45d2d6d..674464e master -> master
다시 sync 상태를 확인하면 정상적으로 다시 ‘synced’ 상태가 되었습니다.
정리하면 ArgoCD의 App Sync 상태 화면으로 Git Repo의 YAML File 설정과 실제 Kube 클러스터의 현재 운영 중인 상태를 서로 비교 할 수 있습니다. 실제 운영 중인 Kube 클러스터와 Git Repo의 소스가 항상 일치하게 만드실 수 있습니다.
클러스터 및 Application 규모 및 담당자가 작은 곳에서는 비교적 필요를 덜 느끼실 수도 있지만 조금만 규모가 있다면 GitOps가 처음에는 불편하면서도 참으로 필요하다는 것을 자주 느낄 수 있습니다. 특히 테스트/Stg/운영 클러스터에 Migration 작업 혹은 신규 클러스터 구축 작업 시 이점이 많습니다. 적극적으로 검토해 보시는 것을 추천 드립니다.
(참고로 위 실습은 GUI 환경에서 진행 하였습니다. 일단 개념만 익히시고 실제 작업은 CLI 환경에서 하는 것을 추천 드립니다. 우리는 Admin이므로 시간을 절약하지 못하는 GUI는 잘 쓰지 않습니다.)
'쿠버네티스 교육' 카테고리의 다른 글
23. Kube 교육 - Polaris(보안 취약점 확인) (0) | 2021.06.04 |
---|---|
22. Kube 교육 - HA 및 부하 테스트 (0) | 2021.06.04 |
20. Kube 교육 - Local GitLab Repository (0) | 2021.06.04 |
19. Kube 교육 - Harbor (0) | 2021.06.04 |
18. Kube 교육 - Loki Logging System (0) | 2021.06.04 |