Kubenetes/Kubernetes Pods (8) 썸네일형 리스트형 Pod의 Lifecycle Pod는 단일 애플리케이션만 실행하는 VM과 비교할 수 있다. Pod 내부에서 실행되는 애플리케이션은 VM에서 실행중인 애플리케이션과 다르지 않지만 중요한 차이가 있다. 한 가지 예는 쿠버네티스가 어떤 이유로 Pod를 다른 Node로 재배치해야 할 필요가 있거나 Node의 ScaleDown 요청 등이 있을 때 실행 중인 애플리케이션을 언제든지 종료할 수 있다는 것이다. 1. Application 종료/재배치 쿠버네티스 밖에서는 VM에서 실행되는 애플리케이션이 한 컴퓨터에서 다른 컴퓨터로 거의 이동하지 않는다. 운영자가 애플리케이션을 이동한다면 애플리케이션을 다시 구성하고 새 위치에서 애플리케이션이 정상적으로 작동하는지 수동으로 확인해야 한다. 쿠버네티스를 사용하면 애플리케이션을 훨씬 자주 그리고 자동으로.. Readiness Probe - Pod가 연결을 수락할 준비가 됐을 때 신호 보내기 레디네스 프로브는 주기적으로 호출되고 특정 포드가 클라이언트 요청의 수락 여부를 결정한다. 컨테이너의 레디네스 프로브가 성공을 반환한다면 컨테이너가 요청을 받아드릴 준비가 되었다는 신호다. 준비가 됐다는 표시는 분명히 각 컨테이너에 국한된 것이다. 쿠버네티스는 단지 컨테이너에서 실행 중인 애플리케이션이 간단한 GET/ 요청에 응답하는지 또는 특정 URL 경로에 도달할 수 있는지 확인하거나 필요에 따라서 애플리케이션이 준비됐는지 확인하기 위해 전체 체크리스트를 수행하기도 한다. ㅁ 레디네스 프로브(Readiness Probe)의 타입 ㅇ 프로세스를 실행시키는 Exec 프로브, 컨테이너의 상태는 프로세스의 종료 상태 코드에 의해 결정 ㅇ HTTP GET 요청을 컨테이너에게 보내고 응답의 HTTP 상태 코드를.. 데몬셋 (Daemon Set) 레플리케이션컨트롤러와 레플리카셋은 모두 쿠버네티스의 특정위치에 배포된 특정 개수의 포드를 실행하는데 사용 클러스터의 각 노드에서 포드를 실행해야 하는 경우 데몬셋을 사용 [데몬셋을 사용해 모든 노드에서 포드 실행] - 모든 클러스터 노드에서 포드를 실행하려면 데몬셋 객체를 만든다. - 이 객체는 레플리케이션컨트롤러 또는 레플리카셋과 비슷 - 단, 데몬셋에 의해 만들어진 포드는 이미 대상 노드가 지정돼 있고 쿠버네티스 스케줄러는 건너뛴다. - 노드가 다운되도 데몬셋은 어느곳에서도 포드를 생성하지 않는다. 그러나 새 노드가 클러스터에 추가되면 데몬셋은 즉시 새 포드 인스턴스를 배포한다. [데몬셋을 사용해 특정 노드에서 포드를 실행] - 포드가 모든 노드의 일부에만 실행하도록 지정하지 않는 한, 데몬셋은 클러.. 라이브니스 프로브 (Liveness Probe) 쿠버네티스는 라이브니스 프로브 (Liveness probe)를 통해 컨테이너가 아직 살아 있는지 확인 할 수 있다. 포드의 사양에서 각 컨테이너에 라이브니스 프로브를 지정할 수 있다. 쿠버네티스는 세 가지 메커니즘 중 하나를 사용해 컨테이너를 검색한다. - [HTTP GET 프로브]는 지정한 IP 주소, 포트, 경로에 HTTP GET 요청을 수행한다. ㅁ 프로브가 응답을 수신하고 응답코드가 오류를 나타내지 않으면(즉, HTTP 응답코드가 2xx 또는 3xx 인 경우) 프로브는 성공한 것으로 간주 ㅁ 서버가 오류 응답 코드를 리턴하거나 응답하지 않으면 프로브는 실패로 간주하고 결과적으로 컨테이너를 다시 시작 - [TCP 소켓 프로브]가 컨테이너의 지정된 포트에 TCP 연결을 열려고 시도. 성공적으로 연결되.. Pod 4 - (Namespace) - 객체를 서로 겹치지 않는 별개의 그룹으로 분리하려는 경우 쿠버네티스는 객체를 네임스페이스로 그룹화 함. - 이 네임스페이스는 리눅스 네임스페이스와는 다름 - 동일한 리소스 이름을 여러 네임스페이스에서 여러 번 사용할 수 있다. [네임스페이스의 필요성] - 여러 네임스페이스를 사용하면 많은 구성 요소를 포함하는 복잡한 시스템을 더 작은 그룹으로 분할 가능 - 멀티 테넌트(multi-tenant) 환경에서 리소스를 분리하고 리소스를 생산, 개발 및 QA 환경으로 또는 기타 필요한 방식으로 분할 하는데 사용 가능 - 리소스 이름은 네임스페이스 내에서만 고유하면 됨, 두 개의 네임스페이스는 동일한 이름의 리소스 포함 가능 [다른 네임스페이스와 네임스페이스의 포드] 클러스터에 있는 모든 네임스페이스 나열 $ .. Pod 3 - (Label을 이용한 Pod 구성) [라벨 소개] - 라벨은 포드 뿐만 아니라 쿠버네티스의 모든 리소스를 구성하는 간단하면서도 강력한 쿠버네티스 기능 - 라벨은 리소스에 첨부하는 임의의 키/값 쌍이다. - 라벨 셀렉터를 사용해 리소스를 선택할 때 활용 - 리소스는 해당 라벨의 키가 해당 자원 내에서 고유한 경우 하나 이상의 라벨을 가질 수 있다. - 각각의 포드는 두개의 라벨이 있다. ㅁ app은 포드가 속한 애플리케이션이며, 구성 요소 또는 마이크로서비스를 지정한다. ㅁ rel은 포드에서 실행 중인 애플리케이션이 안정적 버전, 베타 혹은 카나리 버전인지 여부를 표시 정의: 카나리 버전은 안정적인 버전 이외의 새로운 버전의 애플리케이션을 배포할 때 사용. 모든 사용자에게 배포하기 전에 일부 사용자가 새로운 버전을 사용해 동작 방법을 살펴 .. Pod 2 - (YAML이나 JSON 파일 디스크립터에서 Pod 만들기) Pod와 그 밖의 쿠버네티스 리소느는 일반적으로 JSON 또는 YAML 매티페스트를 쿠버네티스R EST API 앤드포인트에 게시해 생성 각 리소스 유형의 모든 속성을 구성하려면 쿠버네티스 API 객체의 정의를 알아야 함. 1. Pod의 YAML 디스크립터 검사 [배포된 Pod의 전체 YAML] $ kubectl get po kubia-zxzij -o yaml apiVersion: v1 kind: Pod metadata: annotations: kubernetes.io/created-by: ... creationTimestamp: 2016-03-18T12:37:50Z generateName: kubia- labels: run: kubia name: kubia-zxzij namespace: default r.. Pod 1 - (Pod 개요) 1. Pod의 필요성 - 여러 프로세스를 실행할 때 한개의 컨테이너보다 다수의 컨테이너가 더 적합 ㅁ 컨테이너는 프로세스 자체가 하위 프로세스를 생성하지 않는 한 컨테이너당 하나의 프로세스만 실행하도록 설계 ㅁ 다양한 프로세스들이 상호 관리를 통해 지원하는 환경을 구성할 경우(Web Process, Log 저장용 프로세스, Scheduling 프로세스 등) 하나의 컨테이너에서 수행이 어려울 수 있다. 2. Pod - 여러 개의 프로세스를 하나의 컨테이너로 묶으면 안 되기 때문에 컨테이너를 단일 단위로 관리할 수 있는 상위 레벨 구조가 필요 [동일한 포드의 컨테이너 사이의 부분 격리] - 쿠버네티스는 도커를 구성하여 각 컨테이너가 자체 세트를 가지고 있는 대신 모든 Pod Container가 동일한 Lin.. 이전 1 다음
