[쿠버네티스] 2. 쿠버네티스 오브젝트 Pod, ReplicaSets, Deployments, Services, Namespaces

##deployment 생성
kubectl create -f deployment-definition.yaml

##deployment 목록 확인 
kubectl get deployments
##출력 예시
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deployment    3       3            3           1m

1. Pod 

1) 정의

- 쿠버네티스에서 배포 가능한 가장 작은 단위로, 어플리케이션의 단일 인스턴스를 나타냄. 

- Pod는 하나 이상의 컨테이너를 캡슐화하며, 네트워크와 스토리지 리소스를 공유 

2) Pod와 컨테이너

(1) Pod와 컨테이너의 관계

- 일반적으로 Pod는 하나의 컨테이너를 포함하지만, 필요에 따라 여러 컨테이너를 포함

- 여러 컨테이너를 포함한 경우, 이들은 같은 네트워크 네임스페이스와 스토리지를 공유

(2) 어플리케이션 확장

- 트래픽 증가 시, 기존 Pod에 컨테이너를 추가하지 않고 새로운 Pod를 생성하여 확장 

- 여러 노드로 구성된 클러스터에서는 새로운 Pod가 다른 노드에 배치 

(3) Multi- container Pod

- 드문 경우지만, 하나의 Pod에 여러 컨테이너를 배치할 수 있다.(주 어플리케이션 컨테이너와 이를 지원하는 헬퍼 컨테이너.)

- 같은 Pod내의 컨테이너들을 localhost로 서로 통신하며, 동일한 스토리지를 공유

(4) Pod의 라이프사이클 관리 

- Pod내 모든 컨테이너는 함께 생성되고 함께 삭제

- Kubernetes는 네트워킹, 스토리지 공유 및 의존성 관리를 자동으로 처리 

3) Pod 생성 및 확인

(1) 명령어를 사용한 Imperative 방식

- kubectl run 명령어를 사용하여 간단히 Pod를 생성 

kubectl run nginx --image=nginx

- 생성된 Pod 확인

kubectl get pods

(2) YAML 파일을 사용한 Declarative 방식

- YAML 파일을 작성하여 Pod를 정의하고 생성

## yaml 예제 pod-definition.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: frontend
spec:
  containers:
  - name: nginx-container
    image: nginx

 - yaml 파일을 사용하여 Pod 생성

kubectl create -f pod-definition.yaml

 

4) Pod 관리 명령어

(1) Pod 목록조회

kubectl get pods

(2) Pod 상세 정보 확인 

kubectl describe pod <pod-name>

(3) Pod 삭제

kubectl delete pod <pod-name>

5) Pod의 장점

- 어플리케이션 확장 및 관리가 용이

- 멀티컨테이너 설정으로 복잡한 어플리케이션 구조 지원

- 네트워킹과 스토리지 설정 자동화로 개발자 부담 감소

- 향후 어플리케이션 구조 변경에도 유연하게 대처 가능 

 

2. Replicasets

1) 정의

- 쿠버네티스에서 어플리케이션의 가용성을 보장하고 스케일링을 지원하는 컨트롤러.

- 지정된 수의 Pod가 항상 실행되도록 관리하며, Pod가 실패하거나 삭제될 경우 자동으로 새로운 Pod를 생성하여 원하는 상태를 유지 

(1) Pod 복제 및 관리

- Replicaset은 지정된 수의 Pod가 항상 실행되도록 보장

- Pod 중 하나가 실패하거나 삭제되면 자동으로 새로운 Pod를 생성 

(2) 스케일링 지원

- ReplicaSet은 어플리케이션의 트래픽 증가 시 Pod수를 늘려 부하를 분산하거나 필요하지 않을 경우, Pod수를 줄여 리소스를 절약

(3) Selector와 Label

- Selector를 사용하여 관리할 Pod를 식별

- Selector는 Pod의 Label과 매칭되며, 이를 통해 Pod만 관리

- 이미 존재하는 Pod도 Label이 일치하면 ReplicaSet에 의해 관리 

2) ReplicaSet Yaml 정의 예제

- 3개의 nginx pod를 생성하고 관리하는 ReplicaSet 정의 파일 예제

## replicaset-definition.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: frontend
spec:
  replicas: 3  # 원하는 Pod 개수
  selector:
    matchLabels:
      app: myapp  # 이 Label을 가진 Pod만 관리
  template:  # 새로 생성될 Pod의 템플릿
    metadata:
      labels:
        app: myapp
        type: frontend
    spec:
      containers:
      - name: nginx-container
        image: nginx

3) ReplicaSet 생성 및 관리 명령어

(1) ReplicaSet 생성 

kubectl create -f replicaset-definition.yaml

(2) ReplicaSet 목록 확인

kubectl get replicaset

##출력

NAME                 DESIRED   CURRENT   READY   AGE
myapp-replicaset     3         3         3       20s

(3) Pod 목록 확인

kubectl get pods

##출력 예시

NAME                          READY   STATUS    RESTARTS   AGE
myapp-replicaset-9ddl9        1/1     Running   0          20s
myapp-replicaset-9jtpx        1/1     Running   0          20s
myapp-replicaset-hq84m        1/1     Running   0          20s

 

(4) ReplicaSet 삭제

kubectl delete replicaset myapp-replicaset

- 해당 replicaset을 삭제하며 모든 Pod도 삭제

 

4) ReplicaSet 스케일링

(1) YAML 파일 수정 : replicas를 3개에서 6개로 증가

## replicaset-definition.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: frontend
spec:
  replicas: 6  # 원하는 Pod 개수를 6개로 증가 
  selector:
    matchLabels:
      app: myapp  # 이 Label을 가진 Pod만 관리
  template:  # 새로 생성될 Pod의 템플릿
    metadata:
      labels:
        app: myapp
        type: frontend
    spec:
      containers:
      - name: nginx-container
        image: nginx

 

(2) kubectl로 replicaset 업데이트

kubectl replace -f replicaset-definition.yaml

(3) YAML 없이 바로 업데이트

kubectl scale --replicas=6 replicaset myapp-replicaset

(4) Replicaset 상세 정보 확인 

kubectl describe replicaset myapp-replicaset

5) ReplicaSet 작동방식

(1) ReplicaSet은 지정된 Template에 따라 필요한 수의 Pod를 생성

(2) selector와 matchlabels를 통해 관리할 Pod를 식별하며, 이미 존재하는 Pod도 일치하는 Label을 가지면 관리 대상에 포함

(3) 만약 지정된 수보다 적은 Pod가 실행 중이라면 부족한 만큼 새로 생성하고, 초과하면 삭제하여 항상 원하는 상태를 유지 

 

3. Deployments 

1) 주요기능

- Pod와 ReplicaSets을 관리하며, 롤링 업데이트, 롤백, 스케일링 등 다양한 기능을 제공 

(1) 다중 인스턴스 관리

- 하나의 어플리케이션에 대해 여러 Pod를 실행하여 가용성과 부하분산을 보장 

(2) 롤링 업데이트 

- 애플리케이션의 새로운 버전을 배포할 때, 모든 인스턴스를 동시에 업데이트하지 않고 순차적으로 업데이트하여 서비스 중단을 최소화

(3) 롤백

- 문제가 발생했을 경우, 이전 버전으로 쉽게 롤백 

(4) 스케일링

- 필요에 따라 Pod 수를 늘러간 줄여 리소스를 효율적으로 활용 가능 

(5) Pause 및 Resume

- 여러 변경 사항을 적용하기 전에 배포를 일시 중지하고, 준비가 완료되면 재개하여 변경 사항을 한번에 적용 

2) Deployment 구성요소

## deployment-definition.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
    type: frontend
spec:
  replicas: 3  # 생성할 Pod 수
  selector:
    matchLabels:
      app: myapp  # 이 Label을 가진 Pod를 관리
  template:
    metadata:
      labels:
        app: myapp
        type: frontend
    spec:
      containers:
      - name: nginx-container
        image: nginx

(1) apiVersion: Deployment의 경우 apps/v1을 사용

(2) kind: 객체 유형인 Deployment 지정 

(3) metadata: Deployment 이름과 레이블을 정의

(4) spec: deployment의 사양을 정의하는 섹션으로, 

- replicas: 생성할 Pod의 수 

- selector: 관리할 Pod를 식별하기 위한 Label

- template: 생성될 Pod의 템플릿

3) Deployment 생성 및 확인 

 

## deployment 생성 
kubectl create -f deployment-definition.yaml

##deployment 조회 
kubectl get deployments

NAME                READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deployment    3       3            3           1m

 

4) Deployment 업데이트 

(1) yaml 파일 수정 후 적용

- replicas 증가 

## deployment 수정 
## deployment-definition.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
    type: frontend
spec:
  replicas: 4  # 생성할 Pod 수 수정 --> replicas 4개로 증가 
  selector:
    matchLabels:
      app: myapp  # 이 Label을 가진 Pod를 관리
  template:
    metadata:
      labels:
        app: myapp
        type: frontend
    spec:
      containers:
      - name: nginx-container
        image: nginx
        
## 적용
kubectl apply -f deployment-definition.yaml

(2) 명령어로 스케일링 가능

kubectl scale deployment myapp-deployment --replicas=4

 

5) Rollout 및 Rollback

(1) 롤아웃 상태 확인 

kubectl rollout status deployment/myapp-deployment

(2) 롤백

kubectl rollout undo deployment/myapp-deployment

 

6) Deployment 삭제

kubectl delete deployment myapp-deployment

 

7) Deployment 작동방식

- Deployment를 내부적으로 ReplicaSet을 생성하며, ReplicaSet은 Pod를 관리

- kubectl get all 명령어를 실행하면 Deployment, 관련 ReplicaSet 그리고 생성된 Pod를 모두 확인 

- 롤링 업데이드 시 기존 ReplicaSet은 점진적으로 새로운 ReplicaSet으로 교체 

 

4. Services

1) 개념

(1) 정의

-- 클러스터 내의 어플리케이션 구성요소 간 또는 외부 사용자와의 통신을 가능하게 하는 쿠버네티스의 핵심 개념 

-  동적으로 생성도고 삭제되는 Pod들의 네트워크 정체성을 안정적으로 유지하며, 어플리케이션간의 느슨한 결합을 지원 

(2) 기능

- 안정적인 네트워크 엔드포인트: Pod의 IP주소는 고정적이지 않지만, 서비스는 고정된 IP 주소 또는 DNS 이름을 제공 

- 로드 밸런싱: 여러 Pod에 걸쳐 트래픽을 분산 

- 어플리케이션 간 디커플링: 마이크로서비스 구조에서 각 구성요소가 독립적으로 작동할 수 있도록 도움. 

2) 유형

(1) ClusterIP(기본값)

- 클러스터 내부에서만 접근 가능한 가상 IP를 제공

- 백엔드 서비스와 같은 내부통신에서 사용

- 다른 Pod는 ClusterIP또는 DNS이름을 통해 통신가능

- 기본 설정이므로 별도로 지정하지 않아도 ClusterIP로 생성 

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

(2) NodePort
- 클러스터 외부에서 노드의 IP와 특정포트를 통해 접근 가능

- 개발 및 테스트 환경에서 어플리케이션 외부 노출

- 포트 범위는 기본적으로 30000-32767

- 노드의 IP와 NodePort를 통해 접근가능

apiVersion: v1
kind: Service
metadata:
  name: nodeport-service
spec:
  type: NodePort
  selector:
    app: web-app
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30008

- port: 서비스 객체가 클러스터 내부에서 트래픽을 수신하는 포트로 클러스터 내부에서 서비스가 노출되는 지점이다. 다른 Pod들이 포트를 통해 서비스에 접근 

- TargetPort: 서비스가 선택한 Pod로 트래픽을 전달할 때 사용하는 Pod 내부의 포트로 서비스로 들어온 요청이 실제로 Pod내에서 애플리케이션이 수신하는 포트로 전달 . Pod의 컨테이너에서 어플리케이션이 리스닝하고 있어야하는 포트

ex) 위에서 port 80번에서 서비스가 받은 요청을 Pod의 8080번으로 전달 

- NodePort: 클러스터 외부에서 노드의 IP주소와 함께 사용할 수 있는 포트로 외부 사용자가 쿠버네티스 클러스터에서 접근할 수 있도록 노드의 특정포트를 통해 서비스를 노출. 30000-32767 범위내에서 설정됨 

ex) 외부사용자가 NodeIP:30008로 접근하면, 요청이 서비스의 80번 포트를 거쳐 pod의 8080번 포트로 전달 

 

(3) LoadBalancer 

-  동일한 어플리케이션을 실행하는 여러 Pod에 트래픽을 균등하게 분산 

- 고가용성을 보장하고 특정 Pod에 과부하걸리는 것을 방지

- 단일 엔드포인트 제공하여 외부클라이언트가 클러스터 내부의 개별노드나 Pod의 IP 주소를 알 필요 없이, 단일 IP 또는 도메인으로 어플리케이션에 접근할 수 있도록 함 

- 새로운 Pod이 추가되거나 제거되더라도 LoadBalancer는 자동으로 업데이트되어 트래픽 라우팅을 조정 

- 네트워크 흐름: 외부클라이언트 -> LoadBalancer IP -> Kubernetes Node (NodePort) // ClusterIP -> Target Pod 

- 외부요청은 LB IP로 전달되고 이후 내부의 Nodeport와 Cluster IP를 통해 적절한 Pod로 라우팅

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - name: http
      protocol: TCP
      port: 80          # 서비스가 외부에 노출하는 포트
      targetPort: 8080  # Pod 내 애플리케이션이 리스닝하는 포트

- selector를 통해 해당 라벨을 가진 Pod를 선택하여 트래픽을 전달 

(4) ExternalName

- 클러스터 내부의 어플리케이션이 클러스터 외부에 있는 서비스에 쉽게 접근할 수 있도록 도와주는 서비스 유형 

- pod로 트래픽을 직접 프록시하지 않고, DNS이름(CNAME 레코드)을 통해 외부 서비스를 직접 참조 

- 외부 서비스의 도메인이름을 쿠버네티스 클러스터  내부에서 사용할 수 있는 이름으로 매핑

- 클러스터 내에서 해당 이름을 CNAME 레코드로 등록하여 외부 도메인으로 라우팅 

- 일반적인 서비스의 selector를 사용하지 않는다. 

- 외부 서비스의 IP주소나 도메인이 변경되더라도  External name정의만 업데이트 하면 된다. 

apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  type: ExternalName
  ## 연결하려는 외부서비스의 FQDN 
  externalName: external.example.com
  
## 생성
  kubectl apply -f externalname.yaml
  
## 서비스 확인
  kubectl get svc
  
  NAME               TYPE           CLUSTER-IP    EXTERNAL-IP        PORT(S)    AGE
external-service   ExternalName   <none>        external.example.com <none>    10s

##클러스터 내부에서 테스트
## 외부 external-service가 어떻게 resolve되는지 external name의 nslookup으로 확인 
kubectl run test-pod --image=busybox --rm -it -- /bin/sh
nslookup external-service.default.svc.cluster.local

Server:         10.96.0.10
Address:        10.96.0.10#53

Name:   external-service.default.svc.cluster.local
Address: external.example.com

 

5. Namespace

1) 정의

- 쿠버네티스 클러스터 내에서 리소스를 격리하고 조직화하는 논리적 파티션

- 리소스 격리: 네임스페이스 내의 리소스는 다른 네임스페이스와 분리되어 관리 ex) 개발환경, 운영환경을 따로 네임스페이스로 만들어 관리가능

- 정책 정의: 각 네임스페이스는 고유한 접근 제어 정책을 가질 수 있음

- 자원 관리: 네임스페이스별로 자원 활당량을 설정하여 자원 사용을 제한

- 접근제어: 각 팀은 자신만의 네임스페이스에 대한 접근 권한을 가질 수 있음 

2) 쿠버네티스의 기본 Namespace

-- 클러스터가 생성되면 기본적으로 다음 세가지 namespace가 자동으로 생성

(1) default: 사용자가 별도로 지정하지 않은 경우 리소스가 생성되는 기본 네임스페이스

(2) kube-system: kubernetes 시스템 구성요소(네트워킹,DNS 등)를 위한 네임스페이스. 사용자에 의해 수정되거나 삭제되지 않아야 함

(3) kube-public: 클러스터 내 모든 사용자에게 공개적으로 접근 가능한 리소스를 포함 

3) 네임스페이스 내 및 간 리소스 상호작용

- 같은 네임스페이스내에서는 리소스를 단순 이름으로 참조 가능

- 다른 네임스페이스의 리소스를 참조하려면 FQDN 형식을 사용해야함.

servicename.namespace.svc.cluster.local
db-service.dev.svc.cluster.local

4) 생성 및 조회

 

## YAML을 통한 생성(namespace-definiton.yaml)
apiVersion: v1
kind: Namespace
metadata:
  name: dev
  
kubectl create -f namespace-definition.yaml

## 명령어를 통한 직접 실행
kubectl create namespace dev

##조회
kubectl get pods --namespace=dev
kubectl get pods --all-namespaces

 

5)Namespace 전환

- 기본적으로 default 네임스페이스에서 작업하지만, 특정 네임스페이스로 영구 전환하려면 다음 명령어를 사용

kubectl config set-context $(kubectl config current-context) --namespace=dev

 

6) 자원할당량 설정

- 특정 네임스페이스 내에서 사용할 수 있는 자원의 총량을 제한

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: dev
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 5Gi
    limits.cpu: "10"
    limits.memory: 10Gi
    
    
kubectl create -f compute-quota.yaml