Kubernetes

Secret ConfigMap 처럼 키 - 값 형태로 저장하는 저장소이다. 그렇지만 ConfigMap과는 사용하는 목적이 다른데, Secret은 소량의 민감한 데이터를 안전하게 저장하기 위한 목적으로 사용한다. 따라서 패스워드, 인증서, 키, 토큰과 같은 정보를 담는데 적합하며, 1MiB 까지 저장할 수 있다. Secret 은 ConfigMap와 동일하게 특수한 볼륨의 한 형태라고 이해할 수 있으며, Pod에 볼륨으로 연결하여 사용할 수 있다. 또한 configMap은 Plain text로 저장되는 반면 secret은 base64 방식으로 인코딩되어 저장된다. Base 64 방식 인코딩과 디코딩을 하는 명령어는 다음과 같다. $ echo "minjee" | base64 bWluamVlCg== $ echo..

ConfigMap은 변수, 설정 파일 등의 내용을 key:value 형태로 저장한다. ConfigMap은 특수한 볼륨의 한 종류에 해당하며, 실제로 Pod를 생성할 때 ConfigMap 볼륨에 연결할 수 있다. Secret 오브젝트와 비교했을 때는 비교적 민감하지 않은 정보들이 저장된다. 1. 명령어로 ConfigMap 생성하기 $ kubectl create configmap CONFIGMAP_NAME --from-file=FILE_NAME $ kubectl create configmap CONFIGMAP_NAME--from-literal=KEY_NAME=VALUE # key 를 새로 지정하고 value를 파일에 있는 값으로 넣어주기 $ kubectl create configmap my-config3 -..

Ingress 컨트롤러 Ingress 컨트롤러는 NodePort, LoadBalancer 서비스 타입처럼 서비스를 외부에 노출시키는 방법 중 하나이다. NodePort, LoadBalancer와 다른점은, NodePort, LoadBalancer는 Layer 4 (UPT/TCP) 에서 작동하는 반면, Ingress 는 Layer 7 (HTTP/HTTPS) 에서 로드밸런싱을 제공한다는 점이다. Ingress 컨트롤러는 요청이 왔을 때, 어플리케이션이 사용하는 프로토콜(HTTP/HTTPS) , 서버 주소, 어플리케이션이 구체적으로 접근하고자 하는 리소스의 경로를 보고 특정한 어플리케이션에 요청을 전달해주게 된다. Layer 4 이하의 헤더의 정보들만으로는 이러한 트래픽 요청 사항을 처리할 수 없어서 Laye..

1. 쿠버네티스 네트워크 아키텍처 보통 쿠버네티스 아키텍처에서는 노드가 여러개인 구조를 가진다. 쿠버네티스 클러스터 환경에서 같은 대역의 네트워크 (192.168.56.0/24) 로 묶여져 있을 것이며, 노드들마다 IP가 할당된다. 그런데 이는 노드에 부여한 IP이지, Pod에 바로 접근할 수는 없다. 각각의 Pod들이 서로 통신을 할 수 있도록 하는 것이 CNI (Container Network Interface)의 역할이다. Pod와 호스트의 인터페이스를 연결해준다. CNI를 통해서 Pod에 할당되는 IP주소로 통신할 수 있게 한다. 그런데 이 Pod라는 것은 일회성으로 사용되는 목적으로 운영된다. 따라서 Pod에 문제가 생기거나 삭제되어버리면 IP가 변동되어 클라이언트 측에서는 Pod의 IP를 예측..

데몬셋 (Daemon Set) 데몬셋은 레플리카셋이나 레플리케이션 컨트롤러처럼 object controller의 한 종류로 pod들을 관리하는 컨트롤러이다. 데몬셋은 Node Label 이 일치하는 노드들 에 pod 복제본이 각 1개씩 실행되도록 관리한다. 만약 Node Label에 대해서 따로 설정을 해주지 않는다면 기본적으로 control plane을 제외한 워커로드에서 pod가 1개씩 실행되도록 관리하는 컨트롤러이다. 레플리카셋 또는 레플리케이션 컨트롤러와 차이점은 별도로 pod 복제본 수를 제어하지 않는다는 점이다. 즉, 처음에 생성한 pod에 문제가 생겨서 삭제가 되면 레플리카셋이나 레플리케이션 컨트롤러는 복제본 pod을 스스로 생성해 준다. 그렇지만 데몬셋은 pod이 삭제가 되더어도 다시 po..

Replication Controller 쿠버네티스의 컨트롤러는 파드 복제본 (replicas)들의 숫자를 보장해주는 역할을 한다. 레플레케이션 컨트롤러는 이용가능한 상태의 pod을 원하는 수 만큼으로 관리해 주는데, pod가 원하는 수 보다 많은 경우 줄여주고, 원하는 수 보다 적은 경우 자동으로 늘려준다. 레플리케이션 컨트롤러를 구성하는데 필요한 요소는 레이블 셀렉터, 파드 템플릿, 복제본의 수가 있다. 레이블 셀렉터는 key :value 형식으로 설정되며, 생성 및 관리를 할 파드에 대해 지정하는 것이다. 파드 템플릿은 파드를 어떤식으로 구성할 것인지 설정 내용에 대한 것이다. 이 파드 템플릿과 동일하게 복제본들이 만들어 진다. 복제본의 수는 지정해 주지 않으면 디폴트 값이 1 이며, 지정해 주면 ..

Pod의 생명주기 Pod는 kubelet에 의해 생성되며, 영구적인 엔티티가 아니라 일시적인 엔티티이다. Pod이 생성되면 UID를 할당받고, node에 스케줄링 되어서 할당된 node 내에서 종료될때까지 남아있는다. Pod은 한번 스케줄링 되어 node에 할당되면 그걸로 끝이라서 일시적이라고 할 수 있는 것이다. 즉, 같은 Pod이 rescheduling 되는 일은 없다. 또한 Pod은 생성되어서 종료될때까지 생명주기를 가진다 Pending Pod이 kube scheduler에 의해서 스케줄링 되기 이전 상태이다. Registry 에서 Image를 pull해오면서 준비하는 상태. 즉, Pod이 만들어지는 단계이다. Running Pod이 만들어져서 Node에 할당이 된 상태이다. Pod 내부서는 하나 ..

Pod 쿠버네티스의 워크로드 리소스 중에서 가장 작은 기본 구성 단위이다. 쿠버네티스에서는 컨테이너 단위로 다루는 도커와 달리 개별 pod 단위로 다룬다. 하나이상의 컨테이너를 포함하는 쿠버네티스의 기본 실행 단위이다. pod가 포함하는 컨테이너는 1개일 수도, 여러개일 수도 있다. pod가 실행하는 컨테이너가 1개이면 pod와 컨테이너를 비슷하게 생각할 수 있다. 그러나 컨테이너가 여러개 실행될 수도 있으므로 구분해야 한다. 네트워크나 Storage에 연결할 때 컨테이너가 아니라, pod 단위와 연결한다. 즉, pod와 연결된 volume storage가 있는 경우 pod 내부의 컨테이너들은 이 공간을 공유해서 사용한다. 네트워크도 동일하게 공유해서 사용한다. pod라는 단위는 하나의 노드에서 실행된다..