분류 전체보기

Stateless Application VS Stateful Application Stateless Application Stateful Application 역할 단순 복제 각자 역할을 가짐 재생성 같은 서비스의 역할을 하는 앱을 생성 앱 이름 달라도 상관 없음 Down된 앱과 같은 앱을 생성 앱 이름 같아야 함 Volume 하나의 Volume을 공유하여 사용 가능 앱 각자의 Volume을 사용해야 함 네트워크 앱들이 트래픽을 균등하게 나누어 가짐 각 앱의 특징에 맞게 트래픽을 가짐 예시 Apache, Nginx MariaDB, Redis, MongoDB Controller ReplicaSet StatefulSet Service Service Headless Service StatefulSet Cont..

DaemonSet ReplicaSet은 node의 자원 상황에 따라 scheduler가 판단하여 Pod을 배치함 selector 과 template 을 지정해 template으로 각 node에 Pod을 생성하고 selector로 Pod의 label과 연결 특정한 Node에만 배포하고 싶을 때 nodeSelector 로 배포할 node의 라벨을 지정해 선택 배포 가능 hostPort 로 포트를 지정하여 각 Node의 포트가 배포된 Pod과 직접 연결되어 Service의 NodePort와 같이 사용할 수 있음 template 업데이트가 가능하며, 기본 업데이트 방식으로 RollingUpdate를 사용 DaemonSet은 node의 자원 상황에 관계없이 모든 Node에 Pod을 배포해야할 때 사용 사용 예시 ..

Update 방식 Recreate 기존 Pod들을 전체 삭제하고 새로운 Pod들을 만든 후 트래픽을 연결하는 방식 특징 삭제 후 새로운 버전의 Pod생성까지 시간만큼 Down Time 발생하는 단점 방법 기존 버전의 Pod를 삭제하고 새로운 버전의 Pod를 생성 Rolling Update 새로운 Pod을 한번에 설정한 갯수만큼 만들어 연결한 후 기존 Pod을 삭제하는 방식 특징 업데이트 중에 기존 Pod, 새로운 Pod 모두에 트래픽이 요청되기 때문에 구버전과 새버전이 공존하는 시간이 발생하는 단점 한번에 업데이트할 Pod의 갯수만큼 업데이트 하는 순간 자원을 추가 사용 Down Time 없음 방법 먼저 새로운 Pod를 생성한 후 트래픽을 연결 연결 후 기존 Pod을 삭제 기존 Pod 갯수만큼 위 방식 ..

Template Pod를 재생성할 때, 어떤 Pod를 재생성할 지에 대한 template Template을 update한 후 pod를 재생성하면 업데이트 된 버전으로 재생성함 기존에 연결된 Pod들은 자동으로 변경되지 않음 Template에 Pod의 이름을 명시해도 replicas가 2 이상이면 ReplicaSet이름-랜덤값 의 이름으로 Pod가 생성됨 apiVersion: v1 kind: ReplicationController metadata: name: replication-1 spec: replicas: 1 selector: type: web **template:** metadata: name: pod-1 labels: type: web spec: containers: - name: containe..

요약 하나의 Cluster 내 pod들을 Namespace로 묶어서 관리 특정 Namespace의 자원 독점 방지를 위해 Resource Quota를 두어 총 사용 가능한 자원을 제한 Limit Range를 두어 Namespace에 들어올 pod의 크기를 제한 Namespace 뿐 아니라 Cluster 단위에도 Limit Range 및 Resource Quota 설정 가능 Namespace 하나의 Namespace에서 같은 종류의 Object일 때 동일한 pod 이름 사용 불가 타 Namespace와 분리되어 관리됨 → 대부분의 자원들은 자신의 Namespace 내에서만 사용 가능 ex) 서로 다른 Namespace에 있는 pod와 service 사이에는 서로 연결 불가 PV, Node와 같이 모든 Na..

환경(dev, pord)에 따라 변하는 설정과 관련된 값들을 관리하는 Object 서비스 내에서 환경과 관련된 값들을 관리했을 때 단점 환경에 대한 값들이 서비스 내부에서 관리되면 바뀔때마다 이미지 전체를 관리해줘야 함 환경 값에 따라 다른 이미지가 만들어지기 때문에 많은 이미지를 저장, 관리해야 함 클러스터 내 다른 서비스에서 해당 값들에 대한 접근 불가 파일 저장 및 주입 방법 1. Env (Literal) 상수로 값을 저장 secret의 값은 Base64 인코딩하여 저장 → pod에 주입 될 때 자동 디코딩 secret이 메모리에 저장됨 1Mbyte까지 가능 → 너무 많이 생성하면 자원에 문제 일으킴 File 방식보다 보안성 좋음 apiVersion: v1 kind: ConfigMap metadat..

emptyDir pod내의 container끼리 데이터를 공유하기 위한 volume pod내에 생성되기 때문에 pod 삭제시 함께 삭제됨 → 일시적으로 사용하는 데이터만 저장 apiVersion: v1 kind: Pod metadata: name: pod-volume-1 spec: containers: - name: con-1 image: something volumeMounts: - name: empty-dir # empty-dir로 mount mountPath: /mount1 - name: con-2 image: something volumeMounts: - name: empty-dir # empty-dir로 mount mountPath: /mount2 volumes: - name: empty-dir..

Service 특징 Service는 default로 해당 클러스터의 ip를 가짐 pod를 Service에 연결하면 클러스터 ip로도 연결된 pod의 포트로 접근할 수 있음 pod는 재생성되면 ip가 변경되므로 service를 연결하여 service의 ip로 접근 ClusterIP ⊂ NodePort ⊂ Load Balancer ClusterIP 클러스터 내부에서만 접근이 가능 동일한 port의 여러 pod를 연결 가능 → Service가 트래픽을 분산 처리 인가된(클러스터 접근 가능한) 사용자만 접근 가능 내부 dashboard 관리나 pod의 서비스 상태 디버깅하는 용도로 사용 apiVersion: v1 kind: Service metadata: name: svc-1 spec: selector: app..

Pod 특징 하나의 Pod 내에는 여러 컨테이너를 가질 수 있다. 컨테이너들끼리는 같은 host를 공유 localhost를 이용해 상호 접근 가능 같은 포트가 여러 컨테이너에 할당되지 못함 Pod가 생성되면 IP가 자동 할당 클러스터 내에서만 해당 IP로 접근 가능 pod 재생성 시 IP 변경 Label 모든 오브젝트에 할당 가능 오브젝트들을 분류하기 위한 목적 Key : Value 형식으로 구성 하나의 오브젝트에 다수의 Label 할당 가능 사용 목적에 따라 적절한 Label을 등록하여 Service에 연결하면 원하는 오브젝트들에 대해 접근 가능 Node Schedule Node Schedule Life Cycle Pod Life Cycle QoS classes (Quality of Service) Q..

class의 우선 순위에 따라 down 되지 않도록 더 낮은 Pod를 down 시킨 후 자원을 분배 QoS Classes Guaranteed 모든 Container에 request와 limit가 설정되어 있어야 request, limit에는 memory와 cpu가 모두 설정되어 있어야 각 Container 내에 memory와 cpu의 request, limit의 값이 같아야 Burstable Container에 request와 limit 값이 다르거나 request, limit 중 하나가 없거나 이외에 Container 중 하나라도 Guaranteed 조건을 만족하지 않는 경우 BestEffort 어떤 Container 내에도 request와 limit 미설정 같은 우선 순위일 경우에 OOM score가..