Primes's Infra Tech

노드가 다운되면, 노드 내 파드에도 접근이 불가능해진다. 따라서 실 서비스에도 영향을 미치게된다. 그렇다면 관리자는 파드를 어떻게 배치하느냐에 따라 서비스가 끊김없이 제공될 수 있을지 고민해야 한다. 노드 하나가 다운되어 파란/초록 파드가 접근할 수 없더라도, 3번째 노드에 복제본이 있기 때문에 해당 어플리케이션으로의 접근은 문제가 없다. 하지만 초록 파드는 복제본이 없으므로 서비스에 접근할 수 없게된다. 5분(기본값, 지정가능) 이상 노드의 다운이 지속되면, 쿠버네티스는 노드와 노드 내 파드가 죽은 것으로 판단하고 ReplicaSet을 통해 다른 노드에 파드를 재생성한다. 만일, ReplicaSet에 죽은 파드가 포함되어 있지 않다면 복구가 되지 않을 것이니 유의하자. 만일, 5분이 지난 후에 노드가 ..

Multi Container Pods 서비스의 규모가 클 때, 모놀리식 아키텍쳐보다는 마이크로 아키텍쳐가 서비스 운영에 적합하다. 마이크로 아키텍처는 스케일 업 다운에 유용하며, 서비스를 파트별로 나누어 관리하여 유지보수 및 업데이트에도 용이하다. 일반적으로 쿠버네티스에서 구축하는 서비스들이 이 마이크로 아키텍쳐의 구성을 위해 쿠버네티스를 사용하게 된다. 컨테이너별로 서비스를 분리하기 쉽기 때문이다. 하지만 때때로 웹 서버와 로깅 서비스들을 같이 운영해야 하는 케이스가 생긴다. 각각 다른 기능이지만, 함께 연동되어 작동해야 하는 서비스들의 경우가 그렇다. 이렇게 두 가지 서비스를 한 아키텍처에서 운영해야 할 때, 멀티 컨테이너 파드를 사용할 수 있다. 위와같이 두 서비스(주황, 남색)는 같은 네트워크 공..

ConfigMap 을 통해 키와 값을 쌍으로 이루어 데이터를 저장하고, 여러 파드에 한번에 적용할 수 있다는 이점이 있음을 알았다. 하지만 암호화가 필요한 비밀번호와 같은 민감한 데이터에 대해서 ConfigMap을 활용한다면 보안적으로 매우 취약해진다. 이러할 경우 사용하는 기능이 Secret 이다. Secret은 암호화가 진행된다는 점 외엔 ConfigMap과 대체로 유사하다. ConfigMap과 동일한 방식으로, Secret 리소스를 생성하고 데이터를 담아, 파드가 데이터를 참조할 수 있게끔 하는 방식으로 동작한다. ConfigMap과 마찬가지로 명령 및 정의 파일을 통해 생성할 수 있다. 명령어의 경우에도 secret 명령어 외에 차이점이 없음을 알 수 있다. Secret 역시도 파일을 통해 다수의..

Configmap은 쿠버네티스에서 환경변수를 설정할 때 사용한다. 간단히 말하면 "환경변수 저장고" 라고 볼 수 있다. 파드에 환경변수를 설정할 때, 정의 파일 내 필드를 설정하여 환경변수를 추가할 수 있다. 하지만, 쿠버네티스에서 파드를 정의하는 파일의 수는 점점 늘어나고 그럴수록 환경변수 관리는 어려워진다. 이 때 사용하는 기능이 바로 Configmap 이다. Configmap은 환경변수 파일을 묶어 Key:Value 배열의 형태로 환경변수를 관리한다. 먼저 ConfigMap을 구성해두고, 파드를 생성할 때 파드 정의파일에서 ConfigMap을 불러와 적용하는 필드를 추가한다. 이러한 구성을 통해 파드에 일일히 환경변수를 추가하지 않고 Configmap 내의 환경변수를 참조하는 것으로 구성할 수 있다..

쿠버네티스에 대해 알아보기 전, Docker로 맛보기를 하고 들어간다. docker run ubuntu 명령어를 실행하여도 실행중인 컨테이너 목록에는 보이지 않는다. 이는 즉시 종료되었기 때문이다. => VM과 달리, 컨테이너는 운영체제를 직접 호스팅하지 않는다. 특정 작업 및 프로세스를 실행하기 위한 공간이기 때문이다. 컨테이너 내에서 실행되는 프로세스는 프로그램을 정의하는 명령어가 실행한다. 위의 명령어들은 컨테이너 내에서 실행될 명령어이다. nginx는 cmd nginx, mysql은 cmd mysqld 가 프로세스를 시작하는 명령어이다. 하지만 ubuntu OS 이미지의 경우, 위와같은 프로세스를 "실행" 하는 명령어가 없다. bash 는 default command로, 무언가 프로세스를 실행하는..

Revision 1 : 처음 배포를 진행하면 Rollout(업데이트) 를 진행하고 버전 1(Revision 1)을 생성한다. Revision 2 : App이 업그레이드되면 컨테이너에 Rollout을 진행하고 버전 2 (Revision 2)를 생성한다. 위와같은 방식으로 버전을 관리함으로써 배포로 인한 변화를 추적하고, 필요하다면 Rollback을 할 수 있도록 한다. Rollout 커맨드는 아래와 같다. kubectl rollout status deployment/myapp-deployment kubectl rollout history deployment/myapp-deployment 위 명령어를 통해 status 및 history 확인이 가능하다. 배포 방법 수립 Recreate 방법 : 기존 배포되어..

쿠버네티스의 Monitoring 쿠버네티스에서는 자체적인 모니터링 솔루션이 없다. 따라서 별도의 오픈소스 모니터링 툴을 이용해야 한다. 주로 사용되는 것은 Prometheus, Elastic Stack 등이 있겠다. 과거에는 Heapster 라는 모니터링 프로젝트를 사용했으나, 현재는 사용하지 않고 Metric Server 라는 간소화된 방식을 사용한다. Metric Server 동작 방식은 아래와 같다. - 클러스터당 메트릭 서버를 1개 생성한다. 해당 서버는 각 쿠버네티스의 노드 및 파드에서 메트릭을 가져와 메모리에 저장한다. - Metric Server는 In-Memory 방식으로 동작한다. 따라서 메트릭을 디스크에 저장하지 않아 오랜 기간 동안의 누적 지표와 같은 데이터는 확인할 수 없다. => ..

처음은 정렬 단계이다. 파드들은 스케줄링 될 때, 노드에 스케줄 되는 것을 기다린다. 파드는 생성될 때, 우선순위가 정해져 있다. 이는 파드 정의 파일에서 필드로 정의할 수 있다. 우선순위 클래스를 생성하고, 우선순위 값을 설정해야 한다. 파드의 우선순위 필드에서는 해당 클래스를 불러와 우선순위를 적용한다. 이렇게 우선순위를 적용하면, value가 높은 파드부터 스케줄링이 우선으로 노드에 배정된다. 다음은 필터링 단계이다. 파드를 실행할 수 없는 노드는 이 단계에서 배제된다. 리소스 부족, 적합하지 않은 조건 등에 따라 파드에 맞는 노드를 "필터링" 하는 단계이다. 다음은 스코어링을 진행한다. 선별된 노드들에 점수를 매겨 가장 적합한 노드를 최종 결정한다. 마지막 바인딩 단계에서 최종 결정된 노드에 파드..

스케줄러는 각 노드에 알맞는 조건, 리소스에 맞추어 파드를 배포하는 기본적인 알고리즘을 따른다. 이 때, 관리자 입장에서는 기본 스케줄러의 설정을 따르는 것이 아닌 몇몇 특정 프로그램들은 특별한 스케줄링 알고리즘을 가진 스케줄러를 사용을 원하는 상황이 발생할 수 있다. 이러할 경우 사용자 지정 스케줄러를 생성하여 배포를 진행할 수 있다. 쿠버네티스에서 파드를 배포할 때, 어떠한 스케줄러를 따를지 결정할 수 있다. 사용자 지정 스케줄러는 위와같이 정의할 수 있다. --kubeconfig 파일의 경로에 있는 scheduler.conf 파일은 kube-api server에 연결하기 위한 인증 정보가 담긴 파일이다. leaderElection 필드도 주목해야할 필요가 있다. 해당 옵션은 스케줄러 복사본을 여러 ..

DaemonSets DaemonSets는 각 노드가 생성될 때 같이 생성되는 기본 파드라고 이해할 수 있다. 노드가 생성되면 같이 생성되며, 삭제될 때 같이 삭제된다. DaemonSets은 파드의 복제본을 노드에 항상 존재하도록 하는 리소스라고 볼 수 있다. Monitoring 에이전트나, kube-proxy와 같이 모든 노드에 필수적으로 설치 및 설정되어야 할 요소들을 Daemonsets을 활용하면 간단하게 Scale-out/in 시 파드에 바로 적용할 수 있다. 데몬셋의 yaml 파일 정의 요소는 replicaset과 거의 동일하다. 이는 수행하는 역할이 비슷하기 때문인 것으로 보인다. Static Pods Static Pods는 kube-apiserver 에 의존하지 않고 pod-definition..