씨솔트의 밑 빠진 독에 물 붓기 씨솔트의 밑 빠진 독에 물 붓기

이 글은 이 포스트를 보고 요약 정리한 것임을 밝힙니다. 기본적으로 API 게이트웨이는 외부에서 들어오는 트래픽에 대한 제어, 즉 North-South 트래픽 제어를 담당한다. 반면 서비스 메쉬는 서비스 간의 통신, East-West 트래픽을 위한 것이다. 하고자 하는 일이 다른데 왜 이런 혼선이 생기는걸까? 첫째로 프록시와 같은 기술을 기본적으로 공유하고 있다. 또 트래픽 제어, 라우팅, 메트릭 수집, 보안/정책 적용 등 기능이 중복된다. 서비스 메시가 자체로 Ingress Gateway 같은 것을 갖는 경우가 있어서 더 혼란스럽게 된다. 아래는 Istio (+Istio Gateway)와 다른 API 게이트웨이들이 공통적으로 제공하는 기능들이다. 분산추적 서비스 검색 부하분산 TLS terminatio..

쿠버네티스에서는 여러 단계에 걸친 작업을 관리해주는 워크플로우를 다양한 방법으로 수행할 수 있다. 그 근간이 되어주는 것이 쿠버네티스 기본 오브젝트인 Job 이다. Job 개념 쿠버네티스의 대부분의 컨트롤러는 모든 파드가 '언제나' 실행되도록 한다는 목표를 공유하고 있다. 그렇기 때문에 ReplicaSet, DaemonSet, StatefulSet, Deployment 모두가 본인들이 관리하는 파드 중 하나가 실패하면 재시작하고 재생성하고 하는 것이다. 그렇지만 내가 원하는 작업을 실행하고 파드가 그냥 죽기를 바란다면? 그때 사용하는 것이 Job이다. Job은 하나 이상의 파드가 할당 받은 명령을 모두 수행하고 작업이 잘 종료되어 정상 종료 코드(0)를 받도록 해주는 것이다. 다른 오브젝트..

Flux 는 쿠버네티스 클러스터가 설정 소스(git..)와 동기화된 상태를 유지하고 새 코드가 추가되면 자동으로 업데이트 해주는 도구이다. Flux v2는 쿠버네티스 API extension 과 프로메테우스 등 다른 쿠버네티스 생태계의 주요 컴포넌트들을 함께 활용하여 개발이 됐다. 설치부터 모니터링 등등 주요한 변화가 굉장히 많았고, backward compatibility 지원이 되지 않을 정도이다. Flux v2 시작하기 GitHub personal access token 을 설정한다. Repo 관련 모든 권한만 갖고 있으면 된다. 최초 설정, 트러블슈팅과 모니터링 등을 위해 flux cli 가 지원된다. 설치한다. brew install fluxcd/tap/flux Flux 가 동작하기 위해서는 k..

이전 포스트에서 살펴본 것처럼 GitOps는 Git을 Single Source of Truth 로 두고, 전체 인프라 및 워크로드를 선언적으로 코드로 정의하여 이를 기반으로 운영한다. 쿠버네티스에서는 kubectl create/apply나 helm install/upgrade가 아니라 git push로 운영을 한다는 의미이다. 실제로 GitOps 모델로 운영하기 위해서는 다음과 같은 것들이 필요하다. CI 시스템이 immutable한 이미지를 푸시하는 컨테이너 레지스트리 (latest 태그 X, 깃 커밋 번호 등을 태그로 이용) 워크로드를 YAML, Helm chart, Custom Resource 형식으로 정의하는 Git 레파지토리 컨피그 Git 레포를 모니터링하고 클러스터 상태를 원하는 상태로 변경해..

※ 아래 이미지의 출처는 이 페이지임을 밝힙니다. GitOps 는 원칙은 심플하고 구현은 복잡(?)하다. 기본적으로는 Git 에 내가 원하는 인프라/어플리케이션의 최종 상태가 선언적(declarative)으로 코드로 기술된다. 그러면 인간의 개입 없이 기계가 실제 배포 환경을 원하는 값으로 수정해준다. GitOps 가 지금으로서는 쿠버네티스 운영 관리를 위해 많이 논의되고는 있지만 본래 의미로는 쿠버네티스에 한정되지는 않는다. 핵심은 Git을 single source of truth로 둔다. Git을 딜리버리 파이프라인의 중앙에 두고, 개발자는 PR을 보내서 어플리케이션 배포와 k8s 운영 태스크들 처리하도록 한다. k8s와 다른 클라우드 네이티브 기술들의 운영 모델로, 컨테이너 클러스터와 어플리케이션들..

이 포스트는 Kubecon의 Applying Policy Throughout The Application Lifecycle with Open Policy Agent 세션을 듣고 작성하였음을 밝힙니다. 내 어플리케이션이 정책을 따라가게 하려면? 정책이란, 이 환경에서 할 수 있는 것과 해서는 안되는 것을 정의하는 일이다. 예를 들어 우리 환경에서는 Go를 1.13 버전 이상으로만 사용해야 한다 같은 것이 정책이다. 이 정책을 여러 클라우드 네이티브 솔루션들에 걸쳐, 하나의 통합된 방식으로 유연하게 정의하고 적용할 수 있게 해주는 것이 OPA 이다. 그렇다면 이 OPA 정책을 어디에서 적용할 것인가 이야기해보기 위해 어플리케이션의 라이프사이클을 세 단계로 나누고 시작하려고 한다. Local Developme..

앞선 포스팅에서 OPA 와 Gatekeeper 의 개념에 대해서 살펴보았다. 그럼 Gatekeeper 에서 사용하는 Constraint와 ContraintTemplate을 조금 더 자세히 알아보려고 한다. 개념 Constraint: 한 시스템이 만족시켜야 하는 요구사항 세트. Enforcement Point: Contraint 가 강제되는 곳. Git hooks 이나 Kubernetes admission controllers, audit systems 이 그 예시. contraint 기반의 정책이 여러 곳에 공통으로 적용되도록. ContraintTemplate: Contraint를 정의하도록 해줌. expected input parameter 와 Rego 정책을 담음. 다시 풀어서 말하면, OPA에서 사..

Volume and Mounts hostPath 컨테이너의 라이프사이클에 따라 생성/소멸되는 임시 볼륨 containers: - image ... volumeMounts: - mountPath: /opt name: data-volume volumes: - name: data-volume hostPath: # 여러 워커노드가 있으면 노드마다 이 폴더가 생김 path: /data # 워커노드의 실제 디렉토리 경로 type: Directoy other than hostPath aws 뿐만 아니라 azure, gcp 등등에서 타입 제공 containers: - image ... volumeMounts: - mountPath: /opt name: data-volume volumes: - name: data-vol..