본문 바로가기

Kubenetes

(35)
컨테이너 기술 1. 컨테이너 격리를 가능하게 하는 매커니즘 컨테이너 격리를 가능하게 하는 두가지 메커니즘 ㅇ 첫번째 메커니즘은 각 프로세스가 파일, 프로세스, 네트워크 인터페이스, 호스트 이름 등 시스템에 독립 뷰를 제공하는 리눅스 네임스페이스(Linux Namespaces) ㅇ 두번째 메커니즘은 프로세스가 소비할 수 있는 리소스의 양(CPU, 메모리, 네트워크 대역폭 등)을 제한할 수 있는 리눅스 컨트롤 그룹(cgroup) 이다. ㅁ 리눅스 네임스페이스로 프로세스 격리 기본적으로 리눅스 시스템은 초기 구동 시에는 하나의 단일 네임스페이스를 갖는다. 파일 시스템, 프로세스 ID, 사용자 ID, 네트워크 인터페이스 등과 같은 모든 시스템 자원은 단일 네임스페이스에 속한다. 그러나 네임스페이스를 추가로 만들고 리소스를 구..
쿠버네티스 인터널 - 5 (고가용성 클러스터) 1. 앱의 가용성 높이기 쿠버네티스에서 앱을 실행할 때 노드가 실패할 경우에도 다양한 컨트롤러가 앱이 지정된 스케일에서 원할하게 실행되도록 한다. 애플리케이션의 가용성을 높이려면 배포 리소스를 통해 애플리케이션을 실행하고 적절한 수의 복제본을 구성하기만 하면 된다. ㅁ 가동 중단 시간을 줄일는 여러가지 실행 방법 다운타임을 회피하려면 활성 복제본과 함께 추가 비활성 복제본을 실행하고 빠른 실행 리스 또는 리더 선출 매커니즘을 사용해 하나만 활성 상태인지 확인해야 한다. 리더 선출 매커니즘이 익숙하지 않은 경우 분산 환경에서 실행되는 여러 애플리케이션 인스턴스가 리더가 되는 합의에 도달하는 방법이다. 리더는 유일하게 하나의 작업을 수행하는 반면 다른 모든 리더는 리더가 실패하고 리더가 되기를 기다리는 중이..
쿠버네티스 인터널 - 4 (Service 구현 방식) kube-proxy가 iptables를 사용하는 방식 API 서버에서 서비스를 만들면 가상 IP가 즉시 할당된다. 그 후에 API 서버는 워커 노드에서 실행중인 모든 kube-proxy 에이전트에 새로운 서비스가 생성됨을 알린다. 그런 다음 각 kube-proxy는 노드에서 실행 중인 해당 서비스에 주소를 지정할 수 있게 한다. 이 작업은 iptables 규칙을 몇 가지 설정해 서비스 IP/Port 쌍을 대상으로 하는 각 패킷을 가로채고 목적지 주소를 수정해 패킷을 서비스를 지원하는 포드 중 하나에 리다이렉션 하도록 한다. kube-proxy는 서비스 변경에 대한 API 서버를 보면서 앤드포인트 객체의 변경 사항을 감시한다. 앤드포인트 객체는 서비스를 백업하는 모든 포드의 IP/Port 쌍을 보유한다. ..
쿠버네티스 인터널 - 3 (실행중인 Pod의 이해 및 내부 네트워크) 3. 실행중인 포드의 이해 포드를 실행하고 있는 워커노드에 ssh로 접속할 수 있고, 도커 컨테이너에 실행중인 목록을 조사해 볼수 있다. 노드 내에 있다면 docker ps 명령을 사용해 실행 중인 모든 컨테이너를 나열 할 수 있다. 4. Inter-Pod Networking 4.1 네트워크는 어떤 모습이어야 하는가. 쿠버네티스는 특정 네트워크 기술을 사용하라고 요구하지 않지만 포드는 동일한 워커노드에 위치하는지 여부에 관계없이 다른 포드(컨테이너)들과 커뮤니케이션 할 수 있어야 한다. 포드가 통신하는데 사용하는 네트워크는 포드가 자신의 것으로 보는 IP 주소가 문제되는 포드의 IP 주소와 정확히 동일한 네트워크여야 한다. 이는 동일한 네트워크 스위치에 연결된 컴푸터에서 실행되는 것처럼 간단하고 정확하게..
쿠버네티스 인터널 - 2 (컨트롤러의 상호 협력 방식) 2. 컨트롤러의 상호 협력 방식 2. 1. 관련된 컴포넌트의 이해 컨트롤러, 스케줄러, Kubelet은 각 리소스 유형의 변경 사항을 API 서버에서 감시하고 있다. 아래 그림에서 보이는 것과 같이 표시된 컴포넌트는 트리거하려는 프로세스의 일부를 수행한다. 아래 그림에는 etcd를 포함하지는 않는다. 왜냐하면 API 서버 뒤에 숨겨져 있기 때문이다. 그래서 API 서버를 개체가 저장되는 것으로 생각할 수 있다. 2.2 이벤트 체인 Deployment 매니페스트가 포함하는 YAML 파일을 준비하고 이를 kubectl을 통해서 쿠버네티스에 제출한다고 고려할 때 kubectl은 쿠버네티스 API 서버로 HTTP POST 요청으로 매니페스트를 보낸다. API 서버는 Deployment 명세를 확인하고 etcd에..
쿠버네티스 인터널 - 1 (쿠버네티스 아키텍처) 1. 아키텍처 이해 쿠버네티스는 아래 두 부분으로 나뉘어져 있다 ㅇ 쿠버네티스 컨트롤 플레인 ㅇ 워커노드 각 부분은 다음으로 구성되어 있다. ㅁ 컨트롤 플레인 컴포넌트 컨트롤 플레인은 전체 클러스터 기능을 제어하고 만드는 역할을 한다. 컨트롤 플레인을 이루는 컴포넌트는 다음과 같다. ㅇ etcd 분산 스토리지 ㅇ API 서버 ㅇ 스케줄러 ㅇ 컨트롤 매니저 ㅁ 워커노드를 실행하는 컴포넌트 컨테이너를 실행하는 작업은 워커노드에서 실행 중인 컴포넌트에 달려 있다. ㅇ Kubelet ㅇ 쿠버네티스 서비스 프록시 (kube-proxy) ㅇ 컨테이너 런타임(도커, rkt, 그 밖의 것들) ㅁ 애드온 컴포넌트 컨트롤 플레인 컴포넌트와 워커노드에 실행 중인 컴포넌트뿐만 아니라 여러 기능에 필요한 클러스터용 애드온 컴포..
StatefulSet ㅁ 스테이트풀(Stateful) Pod 복제 - 레플리카셋은 단일 포드 템플리에서 여러 포드 복제본을 생성 - 복제본은 이름과 IP주소만 다르 뿐 나머지는 동일 - 포트 템플릿에 특정 PersistentVolumClaim을 참조하는 볼륨이 있으면 레플리카셋의 모든 복제본은 동일한 PersistentVolumeClaim사용하므로 Claim에 바인딩된 동일한 PersistentVolume을 사용함 여러 포드의 복제본을 찍어내는 데 사용하는 포드 템플릿에서 이 클레임(Persistent Volume Claim)을 참조하기 때문에 각 복제본이 고유한 PersistentVolumeClaim을 사용하도록 설정 할 수 없다. ㅁ 스테이트풀셋 이해 레플리카셋 또는 레플리케이션 컨트롤러로 관리하는 포드 복제본은 가축과 ..
Deployment - 애플리케이션 업데이트 다른 Pod나 외부 클라이언트에게 Service를 제공하는 Pod 인스턴스 세트가 있다고 가정하면 아래와 같은 구성으로 보여질 수 있다. 위의 Pod 내의 애플리케이션을 새로운 버전으로 업데이트 하기 위해서는 다음과 같은 방법이 필요 ㅇ 기존의 모든 Pod를 먼저 삭제한 다음 새로운 포드를 시작 ㅇ 새로운 것을 시작하고, 일단 끝나면 오래된 것을 지움. 모든 포드를 추가한 다음 한번에 모든 기존 포드를 삭제하거나 순차적으로 추가/제거 해야 함. 위의 작업들을 쿠버네티스가 자동으로 업데이트 하는 방법이 디플로이먼트임. [오래된 포드를 삭제하고 새로운 포드로 교체] 잠깐의 다운 타임을 허용할 수 있다면 포드의 세트를 업데이트하는 가장 간단한 방법 [한 번에 기존 버전에서 새로운 버전으로 전환] 포드는 대개 ..