Passwd

Headless Service 일반적인 쿠버네티스 서비스와 유사하지만 IP를 할당받지 않는다. request를 로드밸런싱 하지 않으며, 포드 이름과 하위 도메인을 이용해 각 포드에 대한 DNS만 생성한다. DNS 형식 POD_NAME.SVC_NAME.CLUSTER_DOMAIN_NAMESPACE 예시 ) mysql-0.mysql-h.default.svc.cluster.local 생성 방법 yaml 형식의 정의 파일을 작성하여 create 명령으로 생성한다. apiVersion: v1 kind : Service metadata: name: mysql-h spec: ports: - port: 3306 selector: app: mysql clusterIP : None # 일반 서비스와 차별점 일반 서비스 생성..

Stateful Set 필요성 포드가 정해진 순서대로 생성되어야 하는 경우 포드에 고정적인 이름이나 주소가 필요한 경우 생성 방법 yaml 형식의 정의 파일을 작성한 뒤, create 명령으로 생성한다. Deployment와 비슷하게 작성한 후 kind 값만 StatefulSet으로 변경하면 된다. 서비스 이름을 지정해야 하며, Stateful Sets 생성 시 배포 순서대로 포드가 생성된다. apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql labels: app: mysql spec: templete: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql replica..

Stateful Sets deployment와 유사하게 포드를 관리하는 개체 템플릿 기반으로 포드 생성 scale up, scale down 가능 롤링 업데이트 & 롤백 수행 가능 모든 포드가 동시에 배포되어 포드의 순서를 보장하지 않는 deployment와 다르게, 포드의 순서를 보장한다. 포드 배포 순서 보장 -> 배포한 포드가 Running/Ready 상태로 진입해야 다음 포드를 배포한다. 각 포드에 고유한 인덱스(0부터 시작하여 1씩 증가)를 할당 -> Deployment의 경우, 배포 시 포드 이름을 임의(Random)로 설정한다. 포드 종료 후 재생성되더라도, 동일한 이름으로 생성 -> 포드의 고정 ID 유지 가능 참고 문서 https://livebook.manning.com/book/kube..

정적 프로비저닝 볼륨파일 등을 통해 특정 용량을 가진 PV를 미리 생성해 두고 요청이 있을 때 생성한 PV를 할당하여 사용하는 방식 동적 프로비저닝 볼륨사용자가 요청할 때 자동으로 PV를 생성하여 할당 스토리지 클래스PV를 동적으로 프로비저닝 할 때 사용하는 provisioner 정의스토리지 클래스를 생성하면 PV와 관련 스토리지가 자동으로 생성되기 때문에 yaml 형식의 PV 정의 파일이 필요하지 않다.PVC 정의 파일에 스토리지 클래스의 이름을 지정하여, 스토리지 클래스를 설정한다. 스토리지 클래스가 설정되면 provisioner를 사용하여 필요한 크기의 디스크를 프로비저닝 한 PV를 생성하여 PVC에 바인딩한다. 정의 파일 형식apiVersion: storage.k8s.io/v..

배경 2021.08.22 - Volumes 위의 글에서, 볼륨에 대한 스토리지 구성 정보가 yaml 형식의 포드 정의 파일 내에 포함되었다. 이런 구성 방법은 많은 Pod를 배포하는 대규모 환경에서 적절하지 않다. 이유 어떤 스토리지 솔루션을 사용하든 포드가 많아지는 경우, 각 포드에 대한 스토리지를 매번 구성해야 한다. 구성에 변경이 발생할 때마다, 모든 포드에서 변경을 해주어야 한다. => 스토리지의 중앙 관리 필요 Persistent Volumes 관리자가 구성한 클러스터 전체의 스토리지 볼륨 풀 클러스터에 애플리케이션을 배포하는 사용자가 사용하며, 사용자는 Persistent Volumes Claims를 사용하여 풀에서 스토리지를 선택한다. 생성 방법 yaml 형식의 정의 파일을 작성한 후 cre..

Persistent Volume Claims Persistent Volume과 마찬가지로 쿠버네티스 개별 개체 관리자가 Persistent Volume의 집합을 생성하면, 사용자는 스토리지를 사용하기 위해 Persistent Volume Claims 생성 Persistent Volume Claims 생성 시, 쿠버네티스는 Persistent Volume Claims 설정에 따라 Persistent Volume을 바인딩한다. 모든 Persistent Volume Claims은 Persistent Volume에 바인딩된다. 바인딩하는 과정에서 쿠버네티스는 Persistent Volume Claims이 요청한 용량, 접근 모드, 볼륨 모드, 스토리지 클래스 등의 속성에 따라 바인딩할 Persistent Vol..

도커 - 볼륨 도커 컨테이너는 본질적으로 일시적 데이터 처리가 필요할 때 요청하여, 처리를 완료한 뒤에는 삭제된다. 컨테이너 내의 데이터도 컨테이너와 함께 삭제되기 때문에, 데이터를 유지하기 위해서는 volume을 설정해주어야 한다. 볼륨을 설정하면 컨테이너에서 처리한 데이터가 볼륨에 저장 => 컨테이너 삭제 후에도 데이터 유지 가능 쿠버네티스 - 볼륨 쿠버네티스 포드도 도커 컨테이너와 마찬가지로 일시적이다. 포드가 생성되면 데이터를 처리한 뒤에 삭제되며, 이때 처리한 데이터도 함께 삭제된다. 포드에 볼륨을 설정하면 포드에서 생성한 데이터는 볼륨에 저장 => 포드가 삭제된 이후에도 데이터 유지 가능 구성 방법 볼륨 구성 방법 중 하나는 호스트의 디렉터리를 사용하도록 구성(hostPath)하는 것이다. 이..

들어오는 트래픽을 허용하면, 허용된 트래픽에 대한 응답을 자동으로 허용하기 때문에 요청이 발생하는 방향만 고려하면 된다. 또한 Network Policy는 ingress, egress 규칙을 모두 가질 수 있다. 여러 경우 클러스터 내에 label은 같지만 namespace가 다른 포드가 여러 개 있는 경우 -> 모든 namespace에서 label이 일치하는 모든 포드의 연결이 허용된다. 특정 namespace의 포드만 허용하고 싶은 경우 -> namespaceSelector를 사용한다. podSelector가 없는 대신 namespaceSelector만 있는 경우 -> 설정된 namespace 내의 모든 포드와의 연결을 허용하며, 그 외의 포드는 허용하지 않는다. 클러스터 외부에서 포드에 연결하고 싶..

Ingress 서버 입장에서, 들어오는 트래픽 Egress 서버 입장에서, 보내는 트래픽 트래픽이 발생한 방향을 따져서 ingress와 egress를 정의하며, ingress와 egress를 정의하기 위해서는 트래픽 규칙이 필요하다. All allow 모든 포드에서 다른 포르 또는 서비스로 트래픽을 허용하는 규칙 쿠버네티스가 기본적으로 구성하는 규칙으로, 쿠버네티스는 어떤 솔루션을 구현하든 추가 설정 없이 포드 간에 통신이 가능해야 함을 전제한다. Network Policy 쿠버네티스의 개체 중 하나로, 하나 이상의 포드에 연결하여 policy 내에 트래픽 규칙을 정의할 수 있다. Network Policy를 생성하여 포드에 적용하면, 적용된 포드에서는 규칙에 해당하는 트래픽만 혀용하고 다른 트래픽은 차..

쿠버네티스 서비스 세 가지 유형 중 로드밸런서 유형은 온프레미스에서의 NodePort 유형의 서비스의 역할을 클라우드 환경에서 대체한다. 다른 애플리케이션 두 개가 클러스터 리소스를 공유할 수 있도록 하기 위해서는 같은 클러스터 내에 별도 Deployment로 배포해야 하는데, 이때 로드밸런서 유형의 서비스는 로드밸런서를 프로비저닝 하기 때문에 클라우드 비용도 증가할 수 있다. 로드밸런서 간의 트래픽을 URL 기반으로 전달하기 위해서는, URL 기반 트래픽을 다른 서비스로 리다이렉션 할 수 있는 프록시 또는 로드밸런서가 필요하다. 새 쿠버네티스 서비스를 구성할 때마다 로드밸런서를 재구성해야 한다. 때문에 구성이 다양해진 상황에서는 애플리케이션 확장 시 관리가 어려울 수 있고, 각 서비스마다 새 클라우드 ..