Primes's Infra Tech

쿼리를 통한 백업과 복원 이제까지 리소스를 생성할 때, 정의 파일을 생성하여 리소스를 정의하여 생성하는 방식을 주로 사용하였다. 일반적으로 명령어를 사용하여 생성하는 것보다는 정의 파일을 이용하여 리소스를 생성하는 것이 권장된다. 정의 파일은 백업도 가능하고, 타인과 공유도 가능하기 때문이다. 정의 파일은 git과 같은 코드 리포지토리를 통해 버전 관리를 하기에도 용이하다. 만일 정의 파일을 이용하지 않고 리소스를 생성하였는데 백업 및 복원이 필요할 경우에는 어떻게 해야 하는가? 이러한 경우에는 kube-apiserver를 쿼리하는 것이 가장 좋다. kubectl 을 활용하여 kube-apiserver에 접근하여 클러스터 내 리소스 구성 정보를 복제하여 저장할 수 있다. kubectl get all --..

쿠버네티스의 각 구성요소는 다른 버전으로 구성될 수 있으나 아래와 같은 조건이 존재한다. 1. 각 구성요소는 kube-apiserver보다 높은 버전을 사용해서는 안된다. 2. controller-manager, kube-scheduler는 kube-apiserver보다 한 버전 아래까지 사용 가능하다. 3. kubelet, kube-proxy 는 kube-apiserver보다 두 버전 아래까지 사용 가능하다. 4. kubectl은 kube-apiserver보다 +-1 버전을 사용할 수 있다. 쿠버네티스 버전 업그레이드를 꾸준히 진행해주어야 하는데, 이 때 주의할 점은 "버전을 단계적으로 업데이트" 해야 한다는 점이다. 한 번에 버전을 건너뛰고 업그레이드 하는 것은 권장되지 않는다. 만일, 쿠버네티스 환..

노드가 다운되면, 노드 내 파드에도 접근이 불가능해진다. 따라서 실 서비스에도 영향을 미치게된다. 그렇다면 관리자는 파드를 어떻게 배치하느냐에 따라 서비스가 끊김없이 제공될 수 있을지 고민해야 한다. 노드 하나가 다운되어 파란/초록 파드가 접근할 수 없더라도, 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가 높은 파드부터 스케줄링이 우선으로 노드에 배정된다. 다음은 필터링 단계이다. 파드를 실행할 수 없는 노드는 이 단계에서 배제된다. 리소스 부족, 적합하지 않은 조건 등에 따라 파드에 맞는 노드를 "필터링" 하는 단계이다. 다음은 스코어링을 진행한다. 선별된 노드들에 점수를 매겨 가장 적합한 노드를 최종 결정한다. 마지막 바인딩 단계에서 최종 결정된 노드에 파드..