PKOS2) Kubernetes GitOps 앱 배포 인프라 구축

CloudNet@팀에서 진행하는 쿠버네티스 실무 실습 스터디 참가글입니다.

24단계 실습으로 정복하는 쿠버네티스 도서 내용을 기반으로 진행됩니다.

1. 쿠버네티스 애플리케이션 배포 인프라 구축

이번 챕터에서는 k8s 환경에서 앱 배포에 필요한 인프라 구성요소를 살펴본 뒤, 실제로 구축할 것이다.

  1. Harbor > 로컬 PC에서 작업한 컨테이너 이미지를 저장하는 Container image repository
  2. GitLab > 소스코드의 일원화된 관리를 위한 Git repository
  3. ArgoCD > k8s manifest를 배포하고 관리하는 CD(Continuous Delivery) 담당

배포 파이프라인>

  • 컨테이너 이미지화되어 특정 앱을 구성 하는 일련의 소스코드가 k8s 클러스터로 배포되는 일련의 과정을 자동화한 것.
쿠버네티스 환경의 애플리케이션 배포를 위해 필요한 기반 인프라

실습 환경 배포

# YAML 파일 다운로드
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/kops-oneclick-f1.yaml

# CloudFormation 스택 배포
aws cloudformation deploy –template-file kops-oneclick-f1.yaml –stack-name mykops –parameter-overrides KeyName=nasirk17 SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32  MyIamUserAccessKeyID=$AWS_ACCESS_KEY_ID MyIamUserSecretAccessKey=$AWS_SECRET_ACCESS_KEY ClusterBaseName=$KOPS_CLUSTER_NAME S3StateStore=$KOPS_STATE_STORE MasterNodeInstanceType=t3.medium WorkerNodeInstanceType=c5d.large –region ap-northeast-2

# CloudFormation 스택 배포 완료 후 kOps EC2 IP 출력
aws cloudformation describe-stacks –stack-name mykops –query ‘Stacks[*].Outputs[0].OutputValue’ –output text

# 13분 후 작업 SSH 접속
ssh -i ~/.ssh/nasirk17.pem ec2-user@$(aws cloudformation describe-stacks –stack-name mykops –query ‘Stacks[*].Outputs[0].OutputValue’ –output text)

# EC2 instance profiles 에 IAM Policy 추가(attach) : 처음 입력 시 적용이 잘 안될 경우 다시 한번 더 입력 하자! – IAM Role에서 새로고침 먼저 확인!
aws iam attach-role-policy –policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy –role-name masters.$KOPS_CLUSTER_NAME
aws iam attach-role-policy –policy-arn arn:aws:iam::$ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy –role-name nodes.$KOPS_CLUSTER_NAME

# 메트릭 서버 확인 : 메트릭은 15초 간격으로 cAdvisor를 통하여 가져옴
kubectl top node

1.1. 로컬 컨테이너 이미지 레지스트리 구축 (Harbor)

컨테이너 이미지를 저장하기 위해서는 Docker Hub나, AWS의 ECR(Elastic Container Registry), Azure의 ACR(Azure Container Registry), GCP의 Container Registry, ncloud의 Container Registry등의 퍼블릭 클라우드의 서비스를 활용 할 수 있다.

그러나 외부 솔루션을 사용하면, 아래 2가지 단점이 존재한다.

  1. 추가 스토리지, 네트워크 비용
  2. 보안 관리 (운영 이미지를 회사 외부에 저장?)

따라서 사내망에 자체적으로 컨테이너 이미지 저장소를 구축할 필요성이 생기고, 그에 대한 권장되는 도구가 하버(Harbor)이다.

하버는 23년3월26일 기준 CNCF를 졸업한 20개의 프로젝트 중 하나이다.

시장에서 가장 많은 점유율을 가지고 있는 컨테이너 레지스트리이며, Private Docker Registry나 Cloud Provider Registry로 부터 손쉽게 동기화할 수 있습니다. 또한 하버(Harbor) 자체를 관리할 수 있는 API를 통해서 자동화도 쉽게 구성이 가능한 장점이 있습니다. 추가 번들(플러그인)로 컨테이너 이미지의 취약점을 찾는 스캐너인 트리비(Trivy), 컨테이너 이미지 무결성을 보증하기 위한 서명을 위한 도구인 노터리(Notary)를 적용할 수 있습니다. 또한 차트 저장소인 차트뮤지엄(Chartmuseum)도 같이 구성하여 컨테이너 인프라에서 요구하는 것에 대한 모든 저장소를 통합할 수 있습니다.

2023년 쿠버네티스 표준 아키텍처
  • registry : 컨테이너 이미지를 저장
  • chartmuseum : 하버를 컨테이너 이미지뿐 아니라, 헬름 차트 리포지토리로도 사용
  • notary : 서명이 완료된 컨테이너 이미지만 운영 환경에 사용하도록 설정. 서명이 완료된 이미지는 별도로 구분
  • trivy : 컨테이너 이미지의 보안 취약점을 스캔, 스캔 기능은 별도 솔루션에서 제공하여 관리자는 보안 스캔용 도구를 선택 가능
Harbor architecture

1.1.1. Helm chart를 이용한 Harbor 설치

헬름차트에서 제공되는 harbor template에, 필요한 value값만 수정하여 설치할 것이다.

Helm chart를 이용한 Harbor 설치

# 하버 설치

helm repo add harbor https://helm.goharbor.io
helm fetch harbor/harbor –untar –version 1.11.0
vim ~/harbor/values.yaml

———————-

expose.tls.certSource=none # 19줄
expose.ingress.hosts.core=harbor.devxmonitor.click # 36줄 expose.ingress.hosts.notary=notary.devxmonitor.click # 37줄
expose.ingress.controller=alb # 44줄
expose.ingress.className=alb # 47줄 및 이하 추가expose.ingress.annotations=alb.ingress.kubernetes.io/scheme: internet-facing
expose.ingress.annotations=alb.ingress.kubernetes.io/target-type: ip expose.ingress.annotations=alb.ingress.kubernetes.io/listen-ports: ‘[{“HTTPS”:443}, {“HTTP”:80}]’ expose.ingress.annotations=alb.ingress.kubernetes.io/certificate-arn: ${CERT_ARN}
externalURL=https://harbor.devxmonitor.click # 131줄

———————-

# 모니터링

kubectl create ns harbor
watch kubectl get pod,pvc,ingress -n harbor

# 설치

helm install harbor harbor/harbor -f ~/harbor/values.yaml –namespace harbor –version 1.11.0

# 확인

helm list -n harbor
kubectl get-all -n harbor
kubectl get pod,pvc,ingress,deploy,sts -n harbor
kubectl get ingress -n harbor harbor-ingress -o json | jq
kubectl krew install df-pv && kubectl df-pv

# 웹 접속 주소 확인 및 접속

echo -e “harbor URL = https://harbor.$KOPS_CLUSTER_NAME”

1.1.2. 로컬 컨테이너 이미지 원격 하버 레지스트리 업로드

  • 로그인 : admin/Harbor12345
  • NEW PROJECT → Name(pkos), Access Level(Public Check) ⇒ OK 클릭
    • 신규 프로젝트 생성 : 프로젝트 단위로 컨테이너 이미지 저장소를 관리, 프로젝트 별로 사용자 권한(RBAC) 보안 설정이 가능
Harbor 접속 후 신규 프로젝트 생성

kops-ec2 에서 로컬 이미지를 원격 하버 이미지 저장소로 업로드

# 컨테이너 이미지 가져오기

docker pull nginx && docker pull busybox && docker images

# 태그 설정

docker tag busybox harbor.$KOPS_CLUSTER_NAME/pkos/busybox:0.1 docker image ls

# 로그인 – 방안2

echo ‘Harbor12345’ > harborpw.txt
cat harborpw.txt | docker login harbor.$KOPS_CLUSTER_NAME -u admin –password-stdin
cat /root/.docker/config.json | jq

# 이미지 업로드

docker push harbor.$KOPS_CLUSTER_NAME/pkos/busybox:0.1

1.1.3. 하버 이미지 저장소 경로를 사용하는 k8s manifest 생성

manifest에서, 이미지에 별다른 주소를 지정하지 않으면 docker hub에서 해당 이미지를 받아온다. 하지만 생성한 하버 레지스트리의 경로와 이미지를 입력하면 해당 이미지를 사용할 수 있다.

manifest 생성

# 파드 배포

curl -s -O https://raw.githubusercontent.com/junghoon2/kube-books/main/ch13/busybox-deploy.yml
sed -i “s|harbor.myweb.io/erp|harbor.$KOPS_CLUSTER_NAME/pkos|g” busybox-deploy.yml
kubectl apply -f busybox-deploy.yml

# 확인 : 정상적으로 harbor 에서 이미지 다운로드되어 파드가 동작!

kubectl get pod

# NAME READY STATUS RESTARTS AGE
# busybox-7d7884f746-7pw7f 1/1 Running 0 4s

kubectl describe pod | grep Events: -A7

# Events:
#   Type    Reason     Age   From               Message
#   —-    ——     —-  —-               ——-
#   Normal  Scheduled  36s   default-scheduler  Successfully assigned default/busybox-7d7884f746-7pw7f to i-0f1d4aee031357726
#   Normal  Pulling    36s   kubelet            Pulling image “harbor.devxmonitor.click/pkos/busybox:0.1”
#   Normal  Pulled     35s   kubelet            Successfully pulled image “harbor.devxmonitor.click/pkos/busybox:0.1” in 1.000516816s
#   Normal  Created    35s   kubelet            Created container busybox
#   Normal  Started    35s   kubelet            Started container busybox

1.1.4. 업로드된 이미지에 대한 자동 보안 스캔

컨테이너 이미지 스캔이 왜 필요한가?

Harbor에서는 Trivy 라는 컨테이너 이미지 스캐닝 도구를 사용해 보안 취약점을 파악한다.

트리비(Trivy) : 컨테이너 이미지 취약점 검증
대표적인 컨테이너 이미지 취약점 검증 도구이며 취약점 검증 이외에 도커(Docker), 테라폼(Terraform)등에 대한 파일 검증도 수행이 가능합니다. NSA(National Security Agency)와 FIPS(Federal Information Processing Standards)등의 기준에 맞게 보안 검증을 진행합니다. 특히 사용법이 쉽고 간단하여 가장 널리 사용되는 취약점 검증 도구입니다.

2023년 쿠버네티스 표준 아키텍처

자동 보안 스캔 설정

  • Project name > Configuration > Vulnerability scanning 체크 활성화
자동 보안 스캔 설정

실습!

# 태그 설정

docker tag nginx harbor.$KOPS_CLUSTER_NAME/pkos/nginx:0.1
docker image ls

# 이미지 업로드

docker push harbor.$KOPS_CLUSTER_NAME/pkos/nginx:0.1

# harbor 웹 확인

보안 스캔 결과

1.2. 로컬 Git 소스 레포지토리 구축 (Gitlab)

기존의 베어메탈, 또는 가상 머신 환경에서 시스템 운영 작업은 순차적으로 실행하는 명령어의 집합으로 이루어져있었다.

쿠버네티스 환경에서는, 최종 상태를 선언하고 이를 YAML 소스 코드로 구현하여 적용한다.

따라서 현재 클러스터에 배포된 형상이 무엇인지, 누가 작업한 구성파일인지 이력관리 및 조회하는것이 필수적이다. 운영/개발/보안팀 등 사내의 여러팀 간 구성파일이 통합되지 않으면 클러스터 안정성에 큰 문제가 생길것이다.

그림 14.1 쿠버네티스 YAML 파일 관리 방법 비교

코드 통합관리에 도움을 주는 VC로는 GitHub, Bitbucket 등 여러 솔루션이 있다. 그 중 자체 설치형 git repo 서비스는 GitLab이 많이 사용된다. 그래서 이번 실습에서는 설치형 gitlab 레포지토리를 구축하고, 그곳의 YAML manifest가 어떻게 실행될 수 있을지 살펴 볼 것이다.

1.2.1. Helm chart를 이용한 Gitlab 설치

1.1.1.과 유사하게, 헬름차트에서 제공되는 harbor template에, 필요한 value값만 수정하여 설치할 것이다.

# 설치

echo $CERT_ARN
helm repo add gitlab https://charts.gitlab.io/
helm repo update
helm fetch gitlab/gitlab –untar –version 6.8.1
vim ~/gitlab/values.yaml

————————-

global:
hosts:
domain: devxmonitor.click # 52줄
https: true
ingress: # 66줄~
configureCertmanager: false
provider: aws
class: alb
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: ‘[{“HTTPS”:443}, {“HTTP”:80}]’
alb.ingress.kubernetes.io/certificate-arn: ${CERT_ARN} # 각자 자신의 값으로 수정입력
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/group.name: “gitlab”
tls: # 79줄
enabled: false

————————-

helm install gitlab gitlab/gitlab -f ~/gitlab/values.yaml –set certmanager.install=false –set nginx-ingress.enabled=false –set prometheus.install=false –set gitlab-runner.install=false –namespace gitlab –version 6.8.4

# 웹 root 계정 암호 확인

kubectl get secrets -n gitlab gitlab-gitlab-initial-root-password –template={{.data.password}} | base64 -d ;echo

# 웹 접속 주소 확인 및 접속 (root / 웹 root 계정 암호)

echo -e “gitlab URL = https://gitlab.$KOPS_CLUSTER_NAME”

1.2.2. k8s YAML 소스코드를 원격 Git 레포 동기화

  • 접속 후 별도의 사용자 생성 : Admins → Users : 각자 자신만의 편한 계정 (gasida , gasida@cloudneta.net, Administrator 권한 부여) ⇒ 해당 계정으로 git 명령어 실행
    • Impersonation Tokens : Name(test), Scopes(모두 Check) → Create impersonation token 클릭 ⇒ 토큰 값 확인 glpat-yHopz2nW-wXm61udrvzP
  • Users : 유저 선택 후 암호 입력(Test1234), admin 권한 체크 ⇒ root 계정 로그아웃 ⇒ gasida 계정 로그인 ⇒ 암호 변경(P@ssw0rd)
  • 깃랩 신규 프로젝트 작성 : Project name (test-stg) , Project URL(<각자계정>, /test-stg) , Visibility Level (Intenal) , Initialize repository with a README (체크)
신규 계정 생성 후, 프로젝트 작성

프로젝트에 k8s YAML 소스코드 업로드

# 작업 디렉토리 생성 및 이동
mkdir ~/gitlab-test && cd ~/gitlab-test

# git 계정 설정 초기화 > 토큰 및 로그인 실패 시 매번 실행

git config –system –unset credential.helper
git config –global –unset credential.helper

# git 계정 정보 확인 및 global 계정 정보 입력

git config –list
git config –global user.name “nasir”
git config –global user.email “nasir17.dev@gmail.com”
git config –list

# git clone

git clone https://gitlab.$KOPS_CLUSTER_NAME/nasir/test-stg.git
Username for ‘https://gitlab.devxmonitor.click’: nasir
Password for ‘https://nasir@gitlab.devxmonitor.click’: glpat-yHopz2nW-wXm61udrvzP

# 이동

ls -al test-stg && cd test-stg && pwd

# 파일 생성 및 깃 업로드(push) : 웹에서 확인

echo “gitlab test memo” >> test.txt
git add . && git commit -m “initial commit – add test.txt”
git push

커밋 결과

1.3. GitOps 배포 시스템 구축 (ArgoCD)

  • 지속적인 배포란(Continuous Delivery, CD) 개발자가 소스코드를 변경해서 깃 저장소에 푸시하면 해당 변경 사항이 고객이 사용하는 실제 운영환경의 시스템까지 자동으로 반영함
    • 개발자의 코드가 원격 저장소에 업로드됐을 때 아르고시디가 자동으로 해당 코드를 클러스터 운영환경에 배포합니다.
    • ArgoCD로 배포한 헬름 애플리케이션의 리소스 목록, 각 리소스 간 관계 및 에러 유무를 UI로 보여줍니다.
  • 단일 진실 원천(SSOT, Single Source Of Truth)이란 어떠한 진실(결과)의 원인이 하나의 이유(원천)에서 비롯되는 것을 의미합니다.
    • 쿠버네티스 환경에서 깃옵스의 의미는 실제 운영 중인 클러스터의 상태를 개발자의 로컬 PC혹은 아무런 기록을 남기지 않고 클러스터에서 임의로 수정하게 하지 않고 공용으로 관리하는 깃 저장소에서만 유일하게 변경을 허용함으로써 단일 진실 원천(SSOT)를 구현합니다.
    • ArgoCD를 사용하면 쿠버네티스 매니페스트 소스 파일을 여러 개발자의 개인 PC에 보관하지 않고 중앙의 통합된 깃 저장소에 반드시 업로드하고 동기화하도록 정책 관리 가능함

1.3.1. Helm chart를 이용한 ArgoCD 설치

1.1.1.과 1.2.1과 유사하게, 헬름차트에서 제공되는 harbor template에, 필요한 value값만 수정하여 설치할 것이다.

Helm chart를 이용한 ArgoCD 설치

# 설치

cd
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm install argocd argo/argo-cd –set server.service.type=LoadBalancer –namespace argocd –version 5.19.14

# 확인

helm list -n argocd
kubectl get pod,pvc,svc,deploy,sts -n argocd
kubectl get-all -n argocd

kubectl get crd | grep argoproj

# applications.argoproj.io 2023-03-25T17:42:04Z
# applicationsets.argoproj.io 2023-03-25T17:42:04Z
# appprojects.argoproj.io 2023-03-25T17:42:03Z

# CLB에 ExternalDNS 로 도메인 연결

kubectl annotate service -n argocd argocd-server “external-dns.alpha.kubernetes.io/hostname=argocd.$KOPS_CLUSTER_NAME”
# service/argocd-server annotated

# admin 계정의 암호 확인

ARGOPW=$(kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath=”{.data.password}” | base64 -d)
echo $ARGOPW
qXI2qkwFuvaXs0Yn

# 웹 접속 로그인 (admin) CLB의 DNS 주소로 접속

echo -e “Argocd Web URL = https://argocd.$KOPS_CLUSTER_NAME”

1.3.2. Argocd CLI 설치

ArgoCD로 애플리케이션 배포에 사용할 깃 저장소와 쿠버네티스 클러스터 정보를 등록을 위해 cli 도구 또한 사용할 것이다.

ArgoCD도 grafana와 같이 WebUI기반으로만 작동하는줄 알았는데 CLI가 있었다니.. /놀랍다

주요 명령어

  • argocd app : 쿠버네티스 애플리케이션 동기화 상태 확인
  • argocd context : 복수의 쿠버네티스 클러스터 등록 및 선택
  • argocd login : 아르고시디 서버에 로그인
  • argocd repo : 원격 깃 저장소를 등록하고 현황 파악

Argocd CLI


# 최신버전 설치

curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

# 버전 확인

argocd version –short

# argocd 서버 로그인

argocd login argocd.$KOPS_CLUSTER_NAME –username admin –password $ARGOPW

# 기 설치한 깃랩의 프로젝트 URL 을 argocd 깃 리포지토리(argocd repo)로 등록. 깃랩은 프로젝트 단위로 소스 코드를 보관.

argocd repo add https://gitlab.$KOPS_CLUSTER_NAME/nasir/test-stg.git –username nasir –password P@ssw0rd

# 등록 확인

argocd repo list

# TYPE NAME REPO INSECURE OCI LFS CREDS STATUS MESSAGE PROJECT
# git https://gitlab.devxmonitor.click/nasir/test-stg.git false false false true Successful

# 기본적으로 아르고시디가 설치된 쿠버네티스 클러스터는 타깃 클러스터로 등록됨

argocd cluster list

# SERVER NAME VERSION STATUS MESSAGE PROJECT
# https://kubernetes.default.svc in-cluster Unknown Cluster has no applications and is not being monitored.

1.3.2. RabbitMQ HELM App 배포

ArgoCD를 활용해 배포하고, 상태 체크를 할 앱으로 RabbitMQ를 배포할 것이다.

RabbitMQ HELM App 배포

# test-stg 깃 디렉터리에서 아래 실행

cd ~/gitlab-test/test-stg

# 깃 원격 오리진 주소 확인

git config -l | grep remote.origin.url
# remote.origin.url=https://gitlab.devxmonitor.click/nasir/test-stg.git

# RabbitMQ 헬름 차트 설치

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm fetch bitnami/rabbitmq –untar –version 11.10.3
cd rabbitmq/
cp values.yaml my-values.yaml

# 헬름 차트를 깃랩 저장소에 업로드

git add . && git commit -m “add rabbitmq helm”
git push

# argocd CRD 확인

kubectl get crd | grep argo


# applications.argoproj.io 2022-01-25T15:46:16Z > 배포 앱 현재 실행 상태와 깃 저장소의 의도한 상태를 계속 비교
# appprojects.argoproj.io 2022-01-25T15:46:16Z > 프로젝트 단위 구분
# argocdextensions.argoproj.io 2022-01-25T15:46:16Z

# 수정

cd ~/
curl -s -O https://raw.githubusercontent.com/wikibook/kubepractice/main/ch15/rabbitmq-helm-argo-application.yml
vim rabbitmq-helm-argo-application.yml

——————————–

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: rabbitmq-helm
namespace: argocd
finalizers:
– resources-finalizer.argocd.argoproj.io

spec:
destination:
namespace: rabbitmq
server: https://kubernetes.default.svc
project: default
source: repoURL: https://gitlab.devxmonitor.click/nasir/test-stg.git
path: rabbitmq
targetRevision: HEAD
helm:
valueFiles:
– my-values.yaml
syncPolicy:
syncOptions:
– CreateNamespace=true

——————————–

# 모니터링 : argocd 웹 화면 보고 있기!

echo -e “Argocd Web URL = https://argocd.$KOPS_CLUSTER_NAME”

# 배포

kubectl apply -f rabbitmq-helm-argo-application.yml

# YAML 파일을 적용(apply)하여 아르고시디 ‘Application’ CRD를 생성

kubectl get applications.argoproj.io -n argocd
# NAME SYNC STATUS HEALTH STATUS
# rabbitmq-helm OutOfSync Missing

argocd 웹 화면 rabbitmq 클릭 → 헬름 차트 상세 내역 확인 ⇒ 화면 상단 SYNC 클릭해 동기화 실행 : helm install 을 실행하지 않아도 됨!

Sync 이전
Sync 이후

2. 실습

GitOps> “누가 인프라의 현황을 묻거든 고개를 들어 Git을 보게하라”

GitOps에 관해서는 Terraform Cloud 관련글을 적으면서 끄적였던바가 있으니 그쪽을 참고할 것.

이번 실습 영역에서는, git repo의 상태가 실 k8s cluster와 동일한지 검증 하는 ArgoCD의 작동을 확인 해볼 것이다.

ArgoCD 자동 동기화

2.1. 클러스터 설정 내용 변경 및 아르고 동기화

클러스터 설정 변경을 검증하기 위해, 아파치 웹서버와 서비스를 ArgoCD를 이용해 배포할 것이다.

아파치 manifest 파일 생성

# 깃랩 디렉토리에 아파치 manifest용 디렉토리 생성 후 이동

mkdir -p ~/gitlab-test/test-stg/httpd && cd ~/gitlab-test/test-stg/httpd

# 아래의 deployment, service yaml 생성

vi httpd-deploy.yaml
vi httpd-service.yaml

# 깃랩 저장소에 생성된 파일 업로드

git add . && git commit -m “add httpd manifest”
git push

Deployment YAML (httpd-deploy.yml)

apiVersion: apps/v1
kind: Deployment
metadata:
name: httpd
namespace: httpd
labels:
app: httpd #service가 바라보는 label이 아님. 주의.
spec:
replicas: 3
selector:
matchLabels:
app: httpd
template:
metadata:
labels:
app: httpd # Service가 바라보는 label 지정
spec:
containers:
– name: httpd
image: httpd

Service YAML (httpd-service.yml)

apiVersion: v1
kind: Service
metadata:
name: httpd-svc
namespace: httpd
spec:
ports:
– name: http
port: 80
protocol: TCP
targetPort: 80
nodePort: 30180
selector:
app: httpd
type: NodePort

ArgoCD Application CRD 적용

# 홈 디렉토리에 ArgoCD App CRD 생성

cd
vi httpd-directory-argo-application.yml

# 적용

kubectl apply -f httpd-directory-argo-application.yml

# 확인

kubectl get applications -n argocd

# NAME SYNC STATUS HEALTH STATUS
# httpd Synced Healthy
# rabbitmq-helm Synced Healthy

ArgoCD CRD YAML (httpd-directory-argo-application.yml)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: httpd
namespace: argocd
finalizers:
– resources-finalizer.argocd.argoproj.io
spec:
destination:
namespace: httpd
server: https://kubernetes.default.svc
project: default
source:
repoURL: https://gitlab.devxmonitor.click/nasir/test-stg.git
path: httpd
targetRevision: HEAD
directory:
recurse: true
syncPolicy:
syncOptions:
– CreateNamespace=true
automated:
prune: true

httpd 배포

ArgoCD의 상태체크 및 동기화를 위해, 배포된 리소스의 일부를 변경 및 삭제해볼 것이다.

deploy 리소스 변경

# deployment 리소스 수정

kubectl edit deployment httpd -n httpd
# L40) image: httpd > image: httpd:alpine 으로 변경

# 확인 > SYNC STATUS가 OutOfSync로 바뀜
k get applications -n argocd
# NAME SYNC STATUS HEALTH STATUS
# httpd OutOfSync Healthy
# rabbitmq-helm Synced Healthy

# WEB UI에서, App diff를 클릭하면 변경사항 확인 가능

App DIFF 변경사항 비교

service 리소스 삭제

# service 리소스 삭제

k delete svc httpd-svc -n httpd
# service “httpd-svc” deleted

# 확인 > HEALTH STATUS가 Missing으로 바뀜

k get applications -n argocd
# NAME SYNC STATUS HEALTH STATUS
# httpd OutOfSync Missing
# rabbitmq-helm Synced Healthy

# WEB UI에서, APP HEALTH가 Missing으로 변경됨

APP HEALTH

이렇게 상태가 어긋난 애플리케이션의 동기화가 필요한 경우, WEB UI의 SYNC를 누름으로써 간단히 깃 레포와 같은 상태로 복구할 수 있다.

2.2. 소스코드의 변경 감지 및 아르고 동기화

이번에는 깃 저장소의 소스코드를 변경하여, 수정 내역을 클러스터의 상태에 반영해볼 것이다.

기존에 업로드 되어있는 RabbitMQ의 헬름파일에서, 서비스 타입을 ClusterIP에서 LoadBalancer로 변경하고, 이를 Argo에서 어떻게 처리하는지를 확인해볼것이다.

소스코드의 변경 감지 및 아르고 동기화

# 현재 서비스 타입 확인 > ClusterIP

kubectl get svc -n rabbitmq
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
# rabbitmq-helm ClusterIP 100.65.170.103 5672/TCP,4369/TCP,25672/TCP,15672/TCP 111m
# rabbitmq-helm-headless ClusterIP None 4369/TCP,5672/TCP,25672/TCP,15672/TCP 111m

# RabbitMQ 헬름 차트 템플릿 변수파일(my-values.yaml) 수정

cd ~/gitlab-test/test-stg/rabbitmq
vi my-values.yaml
# L951) service.type: ClusterIP > LoadBalancer

# 변경사항을 깃 레포에 커밋

git add . && git commit -m “modify rabbit-mq” && git push

# WEB UI에서 REFRESH 후, APP DIFF 확인

APP DIFF 화면

# SYNC 한 뒤, 서비스 변경 확인

kubectl get svc -n rabbitmq

# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

# rabbitmq-helm LoadBalancer 100.65.170.103 afd62c496d3004224aae263ccad2b07b-1092979891.ap-northeast-2.elb.amazonaws.com 5672:31346/TCP,4369:31787/TCP,25672:31612/TCP,15672:32618/TCP 3h15m

# rabbitmq-helm-headless ClusterIP None 4369/TCP,5672/TCP,25672/TCP,15672/TCP 3h15m


3. 마무리

  • 열심히 해야 남는게 있다

책을 보는 것은 저자의 지식을 보는것이고, 강의를 듣는 것은 강사의 지식을 듣는 것이다.

내가 직접 써보고, 말해보아야 나의 지식이 된다.

스터디 교재를 출퇴근길에 눈으로 스키밍만 했었는데, 지난주 ‘교재 안보시는 분들이 많은것 같다’는 말에 내심 찔렸다.
저번 테라폼 스터디에서는 과제만 제출했었는데, 확실히 끝나고나서 남는게 많이 없는 기분이였었다. 그래서 이번 스터디에서는 매주 스터디 내용 정리하고 있는데,(많은 고인물(?)분들께 많은 자극받고 있기도 하고) 교재도 참고해서 좀더 확실히 정리해야 도움되고 남는게 있을 듯 하다.

  • 2023년 쿠버네티스 표준 아키텍처

쿠버네티스를 공부할때, 쿠버네티스 아키텍쳐와 내부 컴포넌트 공부도 재밌었지만 그 외에도, CNCF Landscape를 봤을 때 전율이 일었었다. k8s 생태계 제대로 파면 진짜 재밌겠다..!

2022년 11월 기준 CNCF Landscape

하지만 동시에 너무 광활한 만큼, 어디에서부터 공부를 시작해야하나하고 막연하기도 했었다. 200여개가 넘는 서비스를 갖고있는 AWS를 공부한다고 했을때 어디부터 삽질을 시작해야하나 고민했던 그 느낌?

AWS 공부에서는 Solutions Architect Associate 자격증 공부가 어느 정도 기준을 잡아주었다면, k8s Ecosystem에서는 아래와 같은 표준 구성에서 그 기준을 찾아낼 수 있을것 같다는 생각을 했다.

2023년 쿠버네티스 표준 구성

그리고 지금와서 다시 교재와 스터디구성을 보면, 각 영역별 / 매 주차별 이 표준 구성을 다 다루고 있어서 또 만족중!

Tags: , , ,

Leave a Reply