Kubenetes (35) 썸네일형 리스트형 Kubernetes API 서버와 통신 Downward AI가 특정 포드 및 컨테이너 메타 데이터를 내부에서 실행되고 있는 프로세스로 간단하게 전달 가능 이는 포드 자체의 메타 데이터와 모든 포드 데이터의 하위 집합만 노출 가능 Downward API로는 애플리케이션이 다른 포드와 심지어는 클러스터에 정의된 다른 리소스에 대해서 더 많이 알아야 할 필요가 있을 경우 유용하지 않음 [쿠버네티스 REST API 탐색] kubectl cluster-info를 통해 쿠버네티스 API 서버 URL을 얻을 수 있다. $ kubectl cluster-inf kubernetes master is running at https://192.168.99.100:8443 서버는 HTTPS를 사용하고 인증이 필요하기 때문에 curl을 통한 통신이 되지 않는다. $ .. Downward API 포드가 시작된 후에 알수 있는 데이터, 즉 포드의 IP, 호스트 노드의 이름, 혹은 포드의 이름과 포드의 라벨과 주석과 같이 이미 다른 위치에 지정된 데이터 등을 Downward API를 통해 확인 할 수 있다. ㅁ Downward API를 사용하여 확인 가능한 메타 데이터 ㅇ 포드의 이름 ㅇ 포드의 IP 주소 ㅇ 포드가 속한 네임스페이스 ㅇ 포드가 실행되고 있는 노드의 이름 ㅇ 포드가 실행 중인 서비스 계정의 이름 ㅇ 각 컨테이너에 대한 CPU 및 메모리 요청 ㅇ 각 컨테이너의 CPU 및 메모리 한계 ㅇ 포드의 라벨 ㅇ 포드의 주석 ㅁ 환경 변수를 통한 메타 데이터 노출 환경 변수를 통해 포드와 컨테이너의 메타 데이터를 컨테이너에 전달하는 방법 [downward-api-env.yaml] apiVersi.. Secret (Secret 으로 컨테이너에 민감한 데이터 전달하기) 중요한 정보를 저장하고 분류하기 위해 쿠버네티스는 시크릿이라고 하는 별도의 객체를 제공 Secret은 ConfigMap과 매우 흡사하며 키/값 쌍으로 사용 가능 - 환경 변수로 Secret Entry를 컨테이너에 전달할 수 있음. - 볼륨의 파일로서 Secret Entry를 노출할 수 있음 쿠버네티스는 시크릿에 액세스해야 하는 Pod를 실행하는 Node에만 배포하도록 하여 안전하게 유지할 수 있다. 또한 Node 자체에서 Secret은 항상 메모리에 저장되고 실제 스토리지에는 기록되지 않으므로 디스크에서 Secret을 삭제한 후 디스크를 완전 삭제해야 한다. Secret과 ConfigMap 사이에서 선택은 - 민감하지 않은 일반 설정 데이터를 저장할 때 ConfigMap을 사용 - 본질적으로 민감한 데이.. 잡 리소스 및 스케줄링 작업을 완료한 후 종료되는 테스크만 실행하길 원하는 경우가 있다. 하지만 레플리케이션컨트롤러, 레플리카셋 및 데몬셋은 작업의 완료를 고려하지 않고 계속적으로 태스크를 실행한다. 따라서 쿠버네티스는 잡 리소스를 통해 내부에서 실행 중인 프로세스가 성공적으로 완료되면 컨테이너가 다시 시작되지 않도록 하는 포드를 실행할 수 있다. 일단 그렇게 되면 포드가 완료된 것으로 간주한다. [잡 리소스의 정의] export.yaml apiVersion: batch/v1 # 잡은 Batch API 그룹의 버전 v1에 있다. kind: Job metadata: name: batch-job spec: # 포드셀렉터를 지정하지 않았다. tmeplate: # 포드 템플릿의 라벨을 기반으로 만들어진다 metadata: labels.. 데몬셋 (Daemon Set) 레플리케이션컨트롤러와 레플리카셋은 모두 쿠버네티스의 특정위치에 배포된 특정 개수의 포드를 실행하는데 사용 클러스터의 각 노드에서 포드를 실행해야 하는 경우 데몬셋을 사용 [데몬셋을 사용해 모든 노드에서 포드 실행] - 모든 클러스터 노드에서 포드를 실행하려면 데몬셋 객체를 만든다. - 이 객체는 레플리케이션컨트롤러 또는 레플리카셋과 비슷 - 단, 데몬셋에 의해 만들어진 포드는 이미 대상 노드가 지정돼 있고 쿠버네티스 스케줄러는 건너뛴다. - 노드가 다운되도 데몬셋은 어느곳에서도 포드를 생성하지 않는다. 그러나 새 노드가 클러스터에 추가되면 데몬셋은 즉시 새 포드 인스턴스를 배포한다. [데몬셋을 사용해 특정 노드에서 포드를 실행] - 포드가 모든 노드의 일부에만 실행하도록 지정하지 않는 한, 데몬셋은 클러.. 레플리카셋(Replicaset) [레플리케이션컨트롤러 & 레플리카셋 차이] - 레플리카셋은 레플리케이션컨트롤러와 똑같이 동작하지만 더 풍부한 표현식 포드 셀렉터를 갖음 - 단일 레플리케이션컨트롤러는 ㅁ 레플리케이션컨트롤러의 라벨. 셀렉터는 특정 라벨을 포함하는 포드가 일치하는지만 본다 ㅁ 포드를 라벨 env=production 및 라벨 env=devel과 동시에 일치 불가 ㅁ 라벨키가 있는 경우에만 포드와 일치 - 레플리카셋 ㅁ 레플리카셋의 셀렉터는 특정 라벨이 없거나 해당 값과 관계없이 특정 라벨 키를 포함하는 포드를 매치하는지 본다. ㅁ 단일 레플리카셋은 두 포드의 세트와 일치 가능하며 단일 포드로 취급 가능 ㅁ 레플리카셋은 라벨키가 없어도 일치 가능 (라벨을 포함하는 모든 포드를 env=*로 생각할 수 있는) [레플리카셋 정의] .. 레플리케이션 컨트롤러 (Replication Controller) - 레플리케이션 컨트롤러는 포드가 항상 실행되도록 유지하는 쿠버네티스 리소스 - 노드가 클러스터에서 사라지는 경우 또는 노드에서 포드가 제거된 경우와 같이 어떤 이유로든 포드가 사라지면 레플리케이션컨트롤러는 누락된 포드를 감지하고 대체 포드를 만든다. [레플리케이션컨트롤러의 동작] 레플리케이션컨트롤러는 실행 중인 포드의 목록을 지속적으로 모니터링하고 '유형'의 실제 포드 수가 원하는 수와 항상 일치하는지 확인 [컨트롤러의 연결 고리] [레플리케이션켠트롤러의 세가지 요소] ㅁ 레플리케이션컨트롤러의 범위에 있는 포드를 결정하는 라벨 셀렉터 ㅁ 실행해야 하는 포드의 원하는 수를 지정하는 복제본 수 ㅁ 새로운 포드 복 제본을 만들 때 사용되는 포드 템플릿 [컨트롤러의 라벨 셀렉터 또는 포드 템플릿 변경에 따른 .. 라이브니스 프로브 (Liveness Probe) 쿠버네티스는 라이브니스 프로브 (Liveness probe)를 통해 컨테이너가 아직 살아 있는지 확인 할 수 있다. 포드의 사양에서 각 컨테이너에 라이브니스 프로브를 지정할 수 있다. 쿠버네티스는 세 가지 메커니즘 중 하나를 사용해 컨테이너를 검색한다. - [HTTP GET 프로브]는 지정한 IP 주소, 포트, 경로에 HTTP GET 요청을 수행한다. ㅁ 프로브가 응답을 수신하고 응답코드가 오류를 나타내지 않으면(즉, HTTP 응답코드가 2xx 또는 3xx 인 경우) 프로브는 성공한 것으로 간주 ㅁ 서버가 오류 응답 코드를 리턴하거나 응답하지 않으면 프로브는 실패로 간주하고 결과적으로 컨테이너를 다시 시작 - [TCP 소켓 프로브]가 컨테이너의 지정된 포트에 TCP 연결을 열려고 시도. 성공적으로 연결되.. 이전 1 2 3 4 5 다음