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

쿠버네티스에서는 여러 단계에 걸친 작업을 관리해주는 워크플로우를 다양한 방법으로 수행할 수 있다. 그 근간이 되어주는 것이 쿠버네티스 기본 오브젝트인 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 에 내가 원하는 인프라/어플리케이션의 최종 상태가 선언적(declarative)으로 코드로 기술된다. 그러면 인간의 개입 없이 기계가 실제 배포 환경을 원하는 값으로 수정해준다. GitOps 가 지금으로서는 쿠버네티스 운영 관리를 위해 많이 논의되고는 있지만 본래 의미로는 쿠버네티스에 한정되지는 않는다. 핵심은 Git을 single source of truth로 둔다. Git을 딜리버리 파이프라인의 중앙에 두고, 개발자는 PR을 보내서 어플리케이션 배포와 k8s 운영 태스크들 처리하도록 한다. k8s와 다른 클라우드 네이티브 기술들의 운영 모델로, 컨테이너 클러스터와 어플리케이션들..

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..

어떤 도커 컨테이너 이미지가 실행될 때 반드시 실행되는 명령어를 ENTRYPOINT와 CMD를 통해 지정한다. 그 실행될 명령어가 ENTRYPOINT 라면 여기에 기본값을 넣어주는 것이 CMD이다. 그래서 실제로 실행될 때는 ENTRYPOINT + CMD가 붙은 것이 함께 돌아가게 된다. 예를 들어 ENTRYPOINT ['sleep'] CMD ["5"]라고 하면, sleep 5가 기본으로 실행되는 것이다. docker run .... 10이라고 컨테이너 실행시 어떤 인풋을 같이 넣어주게 되면 sleep 10이 실행되는 형태다. K8S에서도 이런 비슷한 역할을 해주는 것이 있는데, command가 ENTRYPOINT 역할이고, args가 CMD 역할이다. 만약 컨테이너 이미지에 ENTRYPO..

OPA? 모든 조직에는 '정책'이라는 것이 있습니다. 어떤 정책은 거버넌스, 법적 요구사항 때문에 반드시 지켜야 하는 것이라면, 어떤 정책은 아키텍처적인 베스트 프랙티스를 유지하고 조직의 운영 컨벤션(convention) 때문에 필요하기도 합니다. 이런 요건들을 수작업으로 관리하면 휴먼 에러도 발생할 수 있고 무엇보다도 굉장히 따분하고 짜증나는 일입니다. 때때로는 이런 정책을 지키는 것 때문에 어플리케이션 개발의 속도가 늦어진다든지 하는 일이 발생하기도 해서, 정책과 컴플라이언스를 유지하는 것이 소위 말하는 agility와 함께 가기 어려운 것으로 느껴졌습니다. OPA는 정책을 통합하여 적용/관리하도록 도와주는 오픈소스 프로젝트입니다. 컴플라이언스 정책을 선언적(declarative) 언어를 이용해 코드..

Pod 쿠버네티스에서는 컨테이너를 결국 배포해서 실행되게 하는 게 목적이지만, 컨테이너를 직접 노드에다가 실행하지 않는다. 대신 Pod라는 최소 단위로 encapsulate 해서 실행한다. 왜 이렇게 하냐고? 보통 하나의 Pod에 하나의 컨테이너가 들어가기는 하지만, 한 Pod에 여러 컨테이너가 들어갈 수도 있음. (예: logging 등을 전담하는 헬퍼 컨테이너) 하나의 파드에 여러 컨테이너가 들어가게 되면, 1) 네트워크 네임스페이스를 공유하기 때문에 localhost: 방식으로 컨테이너 간 통신이 가능함. 2) 스토리지 볼륨 공유 ReplicaSets Pod가 encapsulate 해주는 거는 좋은데, 결국 얘가 하나 죽으면 서비스가 불가한 상황이 된다. 그러니 여러 Pod를 유지하고 싶은데 죽을 ..

Cluster Architecture 쿠버네티스 클러스터는 컨트롤 플레인 컴포넌트와 '노드'라고 불리는 서버들의 집합이다. Master node: 전체 클러스터의 뇌 역할. 클러스터 내에서 발생하는 이벤트들을 감지하고 파드 스케줄링 등의 의사결정을 한다. Worker node: 컨테이너화 되어 있는 어플리케이션을 실행. Control Plane: Master Nodes kube-apiserver 쿠버네티스 컨트롤 플레인의 프론트엔드 역할. ETCD와 다이렉트로 통신하는 유일한 존재. 나머지 컴포넌트들은 apiserver를 경유하여 etcd와 상호작용. kubectl 명령어가 들어왔을 때? 사용자 인증 > 요청 검증 > 데이터 추출 > etcd 업데이트 > scheduler에 전달 > kub..