220605 Today I Learned

일지

특이 사항 없음

오늘의 할일

• 220605 TIL 작성
• Kubernetes udemy 강좌 수강
• ArgoCD 찍먹

주요 키워드

GitOps
ArgoCD

공부 정리

What is GitOps, How GitOps works and Why it’s so useful

Intro
Infrastructure as Code - X as Code
Using IaC the wrong way
What is GitOps?
How GitOps works?
CD Pipeline: Push vs Pull Model
Easy Rollback
Git - Single Source of Truth

• Increasing Security
• Wrap Up

Intro

Git OPS > IaC w/ done right

무슨의미인지 모르겠다

Infrastructure as Code - X as Code

• IaC: 인프라 생성을 코드로 관리함으로써 간단히 재생산 가능하고 복제되는 인프라 관리를 가능케함
• XaC?
  • 인프라뿐만아니라, N/W, Policy, Conf, Sec, 또한 코드로 관리 가능
• 수동으로 서버와, 네트워크와, 정책을 수립하는것과 달리
• AWS에서 k8s 클러스터를 생성하고 권한 관리하는 일을
  • TRF/ASB YAML로 인프라를 생성 및 구성하고
  • k8s manifest 파일로 오브젝트를 구성
  • 기타 다른 def.파일들로 플랫폼 생성과 구성 관리

Using IaC the wrong way

• 로컬 환경에서 YAML 파일을 생성

• 로컬 환경에서 실행

• Git Repo에 파일 저장 (긍정)
  • IaC 파일에 대한 버전 관리
  • 중앙에 저장되어 모든 팀원이 접근 가능
• 리뷰/승인 절차 부재 (부정)
  • Pull Requests (Merge Requests) 하지 않음
  • 코드 리뷰 없이 Main 브랜치로 바로 커밋
  • 자동화된 테스트 없음 (yaml형식 오류, 오타, 속성이름오류, 환경 장애)
• 자동화 되지 않은 인프라 업데이트(부정)
  • 모든 사람들이 인프라에 접근 가능한 상황
  • 누가 무엇을 변경했는지 추적하기 어려움
  • 오류가 실행되고 나서야 발견됨 (사전 감지 불가)
• IaC로 인프라 구성을 정의하는 것을 매우 좋음
• 수동 및 비효율적인 절차를 개선하여야 함

What is GitOps?

• IaC를 Application Code와 같은 방식으로 간주

How GitOps works?

• IaC가 Git 저장소에 호스팅
  • 버전 관리
  • 팀간 협업

1. Pull/Merge Request 생성
   • 메인 브랜치와 별도로 변경사항 수정
   • 팀원과의 협력
2. CI 파이프라인 가동
   • 구성 파일 유효성 검증
   • 자동화된 테스트 수행
3. 변경 사항 승인
   • 테스트 종료 후 다른 팀 멤버가 최종 변경 승인
   • 테스트 되고, 검토된 변경사항만 메인에 합병
4. CD 파이프라인 가동
   • 환경에 배포

최종적으로, 자동화 프로세스, 투명성, IaC 품질보증, 팀 협업 가능

CD Pipeline: Push vs Pull Model

1. Push Deployment
   • 기존에 젠킨스와 깃랩 등에서 자주 사용되던 방식
   • CI/CD서버에 업로드되면, 배포 환경으로 Push
2. Pull Deployment
   • k8s 클러스터와 같이 환경에 에이전트 설치되어있음
   • 에이전트가 Git 저장소에서 Pull
   • Desired == Actual state 모니터링 및 비교
   • 필요한 변경사항 수행
   • flux, argoCD

Easy Rollback

Git을 통해 버전관리가 되고, 변경점이 동기화 되기 떄문에

• 이전 상태로 복구하기 용이
• 실수로 인프라 환경이 복구되어도, git revert …

Git - Single Source of Truth

• 단일 신뢰 지점
  • 작업자 개개인에게 / Win,Mac등 다양한 작업 공간 대신
  • Git 저장소에 보관하고, 배포 환경은 이와 동기화

Increasing Security

• CD 서버만 접근 허용 가능
  • 개별 작업자의 배포 환경으로의 개별 접근 차단
  • 작업자는 CI/CD 과정을 통해서 관리
• Less Permissions to Manage
• More Secure Environment

Wrap Up

ArgoCD Tutorial for Beginners

▬▬▬▬▬▬ T I M E S T A M P S ⏰ ▬▬▬▬▬▬ 0:00 - Intro and Overview
0:45 - What is ArgoCD
1:29 - CD workflow without ArgoCD
4:48 - CD workflow with ArgoCD
9:34 - Benefits of using GitOps with ArgoCD
9:41 - Git as Single Source of Truth
13:20 - Easy Rollback
14:08 - Cluster Disaster Recovery
15:10 - K8s Access Control with Git & ArgoCD
16:52 - ArgoCD as Kubernetes Extension
18:49 - How to configure ArgoCD?
20:08 - Multiple Clusters with ArgoCD
23:24 - Replacement for other CI/CD tools?
24:45 - Demo Setup & Overview
27:42 - Beginning of Hands-On Demo

Intro and Overview

• What? > ArgoCD Def.
• Why? > ArgoCD Use case
• How? > Works & benefits
• Hands-on Demo

What is ArgoCD

• CD Tools
• 대부분 프로젝트에서, CD가 어떻게 수행되는가?
  • 일반 용례는 젠킨스와 깃랩
• 아르고는 저거보다 뭐가 다름?
  • 단순 CD 도구?
  • 다른 일반적인 CI/CD 도구 대체가능?

CD workflow without ArgoCD

1. k8s 클러스터에 가동중인 MSA 어플리케이션 가정
2. App 코드를 변경하여 Git Repo 커밋 (새로운 기능 추가or버그 수정)
3. 젠킨스등이 테스트, Docker이미지 생성
4. k8s Deployment의 image tag 변경 image: myapp:2.0
5. k apply …

• 장애사항?불편사항?
  • k8s 클러스터 접근 및 변경 수행을 위해 별도 도구 설치 필요
  • k8s 에 대한 접근 권한 설정 필요
  • 클라우드 플랫폼(eks)에 대한 접근 권한 설정 필요
  • 보안 결함; 클러스터에 대한 보안 자격증명을 외부서비스에 제공
  • 배포 상태에 대한 가시성 없음

CD workflow with ArgoCD

• ArgoCD가 나은 대안임
  • 흐름 전환
    • 아르고는 k8s 클러스터의 일부
    • k8s manifest를 외부에서 pull, 적용

1. k8s 클러스터에 아르고 설치
2. 아르고 설정 > Git 저장소 추적
3. 변경사항 모니터링 및 적용 자동화

깃 저장소 모범사례

• app 소스코드와 app구성(k8s manifest)에 대해 별도의 깃 저장소 개설
• 시스템 구성에 대한 깃 저장소도 분리
• 이유?
  • Deployment.yaml 뿐만 아니라, ConfigMap, Secret, …
  • 소스코드와 별개로 인프라만 수정한 경우, CI과정 생략가능

분리되었지만, 자동화되어 작동하는 별개의 CI/CD 파이프라인 구성가능

Benefits of using GitOps with ArgoCD

1. 코드로 정의된 모든 k8s 구성파일을 깃 저장소에 저장
2. 개인이 로컬환경에서 수동으로 변경 불가
3. 업데이트를 위한 동일한 환경 (무조건 깃 커밋)

Git as Single Source of Truth

• 만약, 직접적으로 클러스터에 접근해 빠르게 무언가를 업데이트했다면?
  • Desired(Git) != Actual(k8s)
  • 수동 업데이트 사항 제거
• 깃 저장소 안의 k8s manifest가 단일 신뢰지점임을 보증함

• 원한다면 override 하지않게 설정도 가능함

• k apply … > 추적불가
• git commit … > Single interface, 변경 버전관리

Easy Rollback

깃 옵스랑 동일
장애 발생시 되돌리기 가능

앗 아니당
선언형이 아닌 명령형이기 때문에, Desired 상태 선언만 하면 나머지는 자동

Cluster Disaster Recovery

클라우드 환경에서, region 또는 AZ에 장애가 발생하더라도
새로운 클러스터를 생성해서 깃 저장소에 따른 환경 재구성 가능

이러한 기능들은 사실상 GitOps의 이점과 비슷함
아르고는 깃옵스에 기반했고, 깃옵스 원칙들을 도입하는데 유용함

K8s Access Control with Git & ArgoCD

• 모든 팀 구성원이 k8s 클러스터에 접근권한을 가지면 안됨
• 깃 저장소를 통한 접근권한 구성가능
• 깃을 통한 비직접적(indirect) 접근권한 관리

• k8s 클러스터 롤/유저 리소스 같은거 안해도댐

• 깃 저장소 뿐만 아니라, 배포 클러스터에 있어서도 접근권한 통제
• 아르고가 클러스터내부에 존재
  • CI(젠킨스)등의 접근을 위한 클러스터 외부 접근권한 설정등을 하지 않아도 됨
  • 외부에 대한 k8s 보안 자격증명 관리 안해도됨

ArgoCD as Kubernetes Extension

• k8s 부가기능으로써의 이점
  • 기존의 k8s 기능들을 활용 가능
    • 데이터 저장을 위한 etcd 사용
    • Actual/Desire 상태 비교를 위한 k8s 컨트롤러 사용
  • 클러스터 내부의 가시성
    • 현재 클러스터 상황에 대한 모니터링 가능
      • 팟 생성, 헬스체크, 가동 실패, 복구 필요, etc…

Git repo	Argo CD	k8s
Desired TARGET state	IN SYNC	Actual LIVE state

How to configure ArgoCD?

1. k8s 클러스터에 아르고 배포
   • CRD(Custom Resource Definion)로써 k8s API와 통신
2. k8s YAML 파일을 통해 아르고 설정
   • 주 리소스는 “ Application” application.yaml
   • src: 어떤 깃 저장소?
   • dst: 어떤 k8s 클러스터?

Multiple Clusters with ArgoCD

• 같은 기능을 하는 클러스터들이 다른 region에 배포되어있다면?
  • 1개의 아르고만 구성하고 관리
  • 1개의 아르고가 k8s 클러스터 전체를 동기화 가능
• dev/stage/prod 클러스터, 레플리카숫자등 각자다른환경이라면?
  • 각 클러스터에 아르고 배치
  • 1개의 깃 저장소
    • 동시에 배포하고싶진않음
      • dev 먼저 배포, stage 배포, prd 배포 등 순차적 배포가능
    • \1. 각 환경별 branch 생성을 통해서 설정
    • \2. Using overlays w/kustomize (권장)
      • CI for DEV: ../devlopment/kustomization.yaml
      • CI for PRD: ../production/kustomization.yaml

Replacement for other CI/CD tools?

• CI 파이프라인 필요
  • 젠킨스, 깃랩, Azure Pipelines, Bamboo, Bitbucket, Teamcity, circleci, …
• 아르고는 CD 영역 담당
  • k8s에 특화
  • flux, 젠킨스x 등 k8s용 깃옵스 도구도 존재

Demo Setup & Overview

Beginning of Hands-On Demo