Service ? Worker Node위에 생성된 pod는 기본적으로는 외부에서 접근이 불가능하다. Service를 이용하여 외부 사용자의 pod 접근 및 pod pod 의 효율적인 내부접근을 구성할 수 있다. Service의 기능은 다음과 같다. Cloud platform의 로드밸런서 or 클러스터에 속한 worker node의 port를 통해 pod를 외부에 노출 여러 pod에 쉽게 접근할 수 있는 고유한 도메인 이름 부여 여러 pod에 접근할 때 요청을 분산하는 LB 기능 수행 Service에는 3가지 종류가 있다. NodePort / ClusterPort / LoadBalancer 타입이다. 하나씩 알아보도록 하자! NodePort Type Worker Node의 특정 port를 개방하여 외부에서..

컨테이너에 정보 전달하기 위해 Downard API 사용 쿠버네티스 REST API 살펴보기 인증과 서버 검증을 kubectl proxy에 맡기기 컨테이너 내에서 API 서버에 접근하기 앰버서더 컨테이너 패턴의 이해 쿠버네티스 클라이언트 라이브러리 사용 애플리케이션이 쿠버네티스 API 서버와 통신해 리소스 정보를 가져오는 것과, 이러한 리소스를 관리하는 법에 대해 알아본다. 8.1 Downward API로 메타데이터 전달 파드의 IP, 호스트 이름, 파드 자체의 이름과 같이 실행 시점이 알려지지 않은 데이터는 ConfigMap 또는 Secret으로 전달하기에 적합하지 않다. ConfigMap, Secret의 경우는 사용자가 데이터를 직접 설정하거나 파드가 노드에 스케줄링 되어 실행되기 이전에 알고 있어야..

7.5 시크릿으로 민감한 데이터 전달하기 보안이 유지되어야 하는 데이터(자격증명, 개인 암호화키 등)은 Secret이라는 오브젝트를 통해 관리한다. 7.5.1 Secret 소개 ConfigMap과 유사한 key-value 쌍으로 ConfigMap과 동일한 방식으로 사용 가능. 다음과 같은 상황에서 사용한다. 환경변수로 Secret 항목을 컨테이너에 전달 Secret 항목을 볼륨 파일로 노출 Secret을 사용해야 하는 파드가 있는 노드에만 개별적으로 시크릿을 배포할 수 있다. 노드 자체적으로 시크릿을 메모리에만 저장하고, 물리 저장소에는 저장하지 않는다. (wiping 방지) ConfigMap과 Secret을 적재적소에 사용하는 것이 필요하다. 민감하지 않은 일반 설정 데이터 : 컨피그맵 민감한 데이터 ..

컨테이너의 주 프로세스 변경 애플리케이션에 명령줄 옵션 전달 애플리케이션에 노출되는 환경변수 설정 컨피그맵으로 애플리케이션 설정 시크릿으로 민감한 정보 전달 7.1 컨테이너화된 애플리케이션 설정 컨테이너화된 애플리케이션의 설정값들은 다음과 같이 구성될 수 있다. 명령줄 인수로 설정값 지정 설정값을 파일에 저장하여 적용 단점) 해당 설정 파일을 컨테이너 이미지 안에 포함하거나, 파일이 포함된 볼륨을 mount하여 사용해야 해서 까다롭다. 환경 변수를 사용 (ex. MYSQL_ROOT_PASSWORD) Configmap 이란 설정 데이터를 저장하는 쿠버네티스 리소스를 의미한다. 컨피그맵을 사용해 다음 방법으로 애플리케이션을 구성할 수 있다. 컨테이너에 명령줄 인수 전달 각 컨테이너를 위한 사용자 정의 환경변..

Pod, ReplicaSet, DaemonSet 등으로 생성한 프로세스는 지속적으로 동작되며, 별도의 완료 시점이 없다. 반면 완료된 후 다시 시작되지 않는 프로세스를 Job 리소스로 구현할 수 있다. 4.5.1 Job 소개 Job은 작업이 제대로 완료되어야 하는 임시 작업에 유용하게 쓰인다. Job으로 관리하는 pod는 프로세스가 완료되기 전까지는 동작하도록 운영된다. 예를 들어 하나의 node에 장애가 생겼을때 그 위에서 동작하던 Job으로 생성한 pod는 다른 node에 자동 스케줄링 된다. 4.5.2 Job Resource Job 리소스를 생성한다. 아래 yaml 정의에서 사용한 image는 120초 동안 실행한 후 종료된다. apiVersion: batch/v1 kind: Job metadata..

DaemonSet을 사용하여 모든 클러스터 노드마다 pod를 하나씩 올릴 수 있다. 예를 들어 모든 node에서 동일하게 log 수집기를 구동 시켜야 하는 경우 DaemonSet을 이용하여 배포하게 된다. 4.4.1 DaemonSet으로 모든 node에 pod 실행하기 DaemonSet으로 생성되는 pod는 올라갈 노드가 이미 지정되어 있어 무작위로 배포되지 않는다. node자체가 다운될 경우 DaemonSet으 다른 node에 pod를 생성하지 않음 새로운 node가 클러스터에 추가될 경우 해당 노드에 새로운 pod생성함 4.4.2 DaemonSet 사용하여 특정 node에 pod실행하기 따로 설정하지 않으면 DaemonSet은 클러스터의 모든 node에 pod를 배포한다. 특정 노드를 지정하기 위해서..

Replication Controller와 ReplicaSet 모두 실행 중인 pod 목록을 지속적으로 모니터링하여 관리하는 pod 들의 실제 수가 의도하는 수와 동일하도록 보장하는 쿠버네티스의 리소스이다. 하지만 Replication Controller는 더 이상 사용되지 않는 추세이며, 유사한 기능을 제공하지만 좀더 나은 ReplicaSet을 거의 사용한다. 4.3.1 Replication Controller와 ReplicaSet 비교 두 리소스는 동일하게 도작하지만 ReplicaSet을 이요하면 좀 더 정교한 pod selector를 사용할 수 있다. Replication Controller : 특정 레이블이 있는 pod만 필터링 ReplicaSet : 특정 레이블이 없거나 레이블의 값과 상관없이 ..

※ 본 게시글은 도서 을 토대로 정리/학습한 내용입니다. 4장에서는 kubernetes가 container 들의 상태를 모니터링하여 원하는 상태를 유지시키도록 하는 방법을 알아본다. 4.1 Pod를 안정적으로 유지하기 쿠버네티스의 주요 장점은 사용자가 구동하고자 하는 container의 상태를 자체적으로 체크하여 원하는 상태를 유지하도록 관리한다는 것이다. container에 crash가 발생하여 정상 동작 하지 않으면 kubelet이 이를 감지하고 자동 재시작 시키는 것 등이다. 하지만 때로는 이러한 방식으로 모든 문제를 파악하기 어려울 때도 있다. 4.1.1 liveness probe liveness probe를 통해 컨테이너가 살아 있는지 확인하고, 실패할 경우 컨테이너를 재시작 한다. HEEP G..

pod는 다음과 같이 중지,제거 할 수 있다. 3.8.1 이름으로 삭제 pod를 삭제하면 pod 안의 모든 container 또한 종료된다. root@master001:~/k8s_in_action/03_pod# kubectl delete pod kubia-gpu pod "kubia-gpu" deleted 3.8.2 Label Selector를 이용한 pod 삭제 label을 지정하여 원하는 집합의 pod를 한번에 삭제할 수 있다. root@master001:~/k8s_in_action/03_pod# kubectl delete pod -l creation_method=manual pod "kubia" deleted pod "kubia-manual-v2" deleted 3.8.3 namespace 삭제로 인..