[1] 쿠버네티스 오브젝트

Kubernetes 시작하기

Kubernetes 고유 특징

1. 모든 리소스는 오브젝트 형태로 관리

   • 아래 요소들을 모두 오브젝트라고 간주함
     • 서비스 : 컨테이너의 묶음
     • 파드(Pods) : 컨테이너의 집합
     • 컨트롤러(Replica Set) : 컨테이너의 집합을 관리하는 컨트롤러
     • 사용자(Service Account)
     • 노드(Node)

2. 여러개의 컴포넌트로 구성

   • 쿠버네티스 노드
     • 마스터 : 클러스터를 관리
       • API-Server, 컨트롤러 매니저, 스케줄러, DNS Server, 프록시, 네트워크 플러그인
     • 워커 : 애플리케이션 컨테이너가 생성
   • kubelet : 클러스터 구성을 위한 에이전트

Pod : 컨테이너를 다루는 기본 단위

• 컨테이너 어플리케이션의 기본 단위
• 하나의 완전한 어플리케이션
• 1개 이상의 컨테이너로 구성된 컨테이너의 집합
• Docker -> 도커 컨테이너 / 스웜 모드 -> 서비스 / 쿠버네티스 -> 파드
• 1개의 포드에서는 1개의 컨테이너가 있을 수도 있고, 여러개의 컨테이너가 존재할 수도 있음

yaml 파일 구조

• apiVersion : 오브젝트의 API 버전을 나타냄
• kind : 리소스의 종류
  • 리소스 오브젝트인 pod나 pvc, pv등을 입력함
• metadata : 라벨, 주석, 이름 등과 같은 리소스 부가정보를 입력함
• spec : 리소스 생성을 위한 자세한 정보 입력
  • containers 하위에 name(컨테이너 이름), image(사용할 도커 이미지), ports(사용할 컨테이너 포트)를 입력할 수 있음

kubectl apply -f 명령어로 쿠버네티스에 생성할 수 있음

포드 v.s. 도커 컨테이너

• 포드 또한 ip주소를 가지고 있어 클러스터 내부에서 접근 가능
• kubectl exec 명령어로 포드 컨테이너 내부로 들어갈 수 있음
• kubectl logs 명령어로 포드의 로그 확인가능
• 도커 컨테이너 대신 포드라는 개념 사용 이유?
  • 여러 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위함
  • 특정 포드에 여러 컨테이너를 넣을 수 있긴 함(잘 안함)
    • 명령어를 시행할 때 -c라는 옵션으로 컨테이너를 지정할 수 있음
    • 각 내부 컨테이너가 같은 네트워크 네임스페이스를 공유하는 등 같은 리눅스 네임스페이스를 공유해 사용함
      • 네트워크 네임스페이스
      • 컨테이너의 공유한 네트워크 환경을 제공해주는 역할
  • yaml의 command, args
    • command : 도커 컨테이너의 Entrypoint(가장 먼저 실행되는 파일)
    • args : dockerfile의 Cmd와 동일
  • 특정 파드 내에 두개 이상의 컨테이너가 있을 때
    • nginx 컨테이너가 실행되기 위해, nginx 설정파일의 변경사항을 갱신해주는 설정 리로더 프로세스 또는 로그 수집해주는 프로세스는 nginx 컨테이너와 함께 실행되야 함
    • 주 컨테이너와 서브 컨테이너를 함께 포드에 포함시킬 수 있음
    • 부가적인 컨테이너 -> 사이드카 컨테이너
      • 동일한 네임스페이스들을 공유하여 사용할 수 있음

Replica Set : 일정 개수의 포드를 유지하는 컨트롤러

Replica Set 사용 이유

• 포드의 생애주기 관리
• 동일한 여러개의 포드를 생성한 뒤, 외부 요청이 각 컨테이너에 적절히 분배(로드 밸런서처럼)
  • 이름만 다른 동일 파드를 yaml에 ---로 구분하여 원하는 수만큼 띄워둠
    • 비효율적인 방법
    • 삭제되거나, 해당 노드에 장애가 발생하여 접근하지 못하게 됨 -> 직접 포드 삭제 후 재생성해야함

Replica Set 동작 원리

• 정해진 수의 동일한 포드가 항상 실행되도록 관리함
• 노드 장애 등의 이유로 포드를 사용할 수 없다면, 다른 노드에서 포드를 다시 생성함

  spec.replicas : 동일한 포드를 몇개 유지시킬지 설정
  spec.template : 포드 생성시 사용할 템플릿
  포드 사용내용을 동일하게 정의함으로 어던 포드를 어떻게 생성할지 명시

• 레플리카셋을 삭제하거나 수정 시 포드에 변경사항이 반영됨
  • yaml파일에 replicas를 3 -> 4로 해도 바로 변경사항이 반영됨
  • kubectl apply -f yaml 하면, Created가 아닌 configured가 출력되며, 기존 리소스가 수정됨
  • kubectl delete -f || rs yaml 하면, 해당 레플리카가 삭제됨
    • 레플리카셋에 의해 생성된 포드도 함께 삭제됨
      • 하지만 레플리카셋이 포드와 연결되어 있는 것은 아님
• 라벨 셀렉터에 의해 레플리카셋과 포드는 느슨한 연결 상태를 유지하고 있음
  • 쿠버네티스 리소스의 부가 정보 표현
  • 서로 다른 오브젝트가 서로를 찾아야 할때 사용
    • 생성해야 하는 포드를 찾음
  • 해당 라벨을 가지는 포드의 개수가 replicas의 수치와 일치하지 않으면 pod templete 항목으로 포드를 생성함
  • $ kubectl get pods --show-labels

Deployment: 레플리카셋, 포드의 배포를 관리

Deployment란?

• 레플리카셋의 상위 오브젝트
• 컨테이너 어플리케이션을 배포하고 관리하는 역할
• 포드와 레플리카셋을 직접 생성할 필요가 없음
  • 실행하면 레플리카셋과 레플리카 수에 따른 파드 n개가 생성됨
• $ kubectl apply -f <yaml파일>로 적용하고, $ kubectl get deploy || deployment로 배포할 수 있음
• 디플로이먼트 삭제 시, 이에 종속된 파드와 레플리카셋도 삭제됨

Deployment 사용 이유

• 어플리케이션의 업데이트와 배포를 더욱 편하게 만들기 위함
• 어플리케이션을 업데이트할 때, 레플리카셋의 변경 사항을 저장하는 리비전(revision)을 남겨 롤백을 가능하게 해줌
  • $ kubectl set image deployment <deployment_name> nginx=nginx:1.11 --record
  • 파드를 업데이트 시킬 때, 이미지를 업데이트 시키면 새롭게 생성된 파드들이 존재함
    • Pod도 이전 set이 존재하는 것 같지는 않음
  • 이전에 사용한 replica set을 삭제하지 않고 남겨둠 -> 리비전으로 보존함
    • $ kubectl rollout history deployment <deployment_name>
  • undo를 통해 롤백할 수도 있음
• 무중단 서비스를 위해 파드의 롤링업데이트의 전략을 지정할 수 있음

Service : 파드를 연결하고 외부에 노출

Service의 기능

• 포드에 접근하기 위한 규칙 정의
• 여러개의 포드에 쉽게 접근할 수 있도록 고유한 도메인 이름을 부여함
• 여러 개의 포드에 접근할 때, 요청을 분산하는 로드 밸런서 기능을 수행함
• 클라우드 플랫폼의 로드 밸런서, 클러스터 노드의 포트 등을 통해 포드를 외부로 노출함
• $ k get pods -o wide로 파드의 IP 확인가능함
• 파드에 어떻게 접근할 것인지에 따라 종류가 여러개
  • ClusterIP 타입
    • 쿠버네티스 내부에서만 포드에 접근할 때 사용
    • 외부로 파드를 노출하지 않음
  • NodePort 타입
    • 파드에 접근할 수 있는 포트를 클러스터의 모든 노드에 동일하게 개방
    • 외부에서 포드에 접근 가능
    • 접근할 수 있는 포트는 랜덤으로 정해지나, 특정 포트로 접근하도록 설정할 수도 있음
  • LoadBalancer 타입
    • 클라우드 플랫폼에서 제공하는 로드 밸런서를 동적으로 프로비저닝해 포드에 연결
    • 외부에서 포드에 접근 가능
    • AWS, GCP 와 같은 클라우드 플랫폼 환경에서만 사용가능
• 서비스를 생성할 때, 별도의 설정없이도 연결된 포드에 대해 로드 밸런싱을 수행함

1. ClusterIP web-port

• 쿠버네티스 내부에서만 포드에 접근할 수 있는 포트

  spec:
  
  ports:
  

  • name: web-port
    
    port: 8080
    
    targetPort: 80
    
    selector:
    
    app: webserver
    
    type: ClusterIP
    

• spec.selector : 어떤 라벨의 포드에 접근할 지 결정

• spec.ports.port : 서비스의 IP에 접근할 때 사용할 포트

• spec.ports.targetPort : containerPort 항목에서 사용할 포트를 동일하게 설정해야 함

• 포드가 서로 상호작용해야 할 때, 포드의 IP를 몰라도됨

  • 서비스 이름을 사용함으로 접근 가능

2. NodePort

• 모든 노드의 특정 포트를 개방해 서비스에 접근하는 방식
• $ kubectl get service를 통해 포트를 확인할 수 있음
• YAML 파일에 nodePort항목을 지정하여 포트를 선택할 수도 있음
  • 너무 낮은 포트의 경우, 시스템에 의해 예약된 포트로 사용불가능 할 수 있음
• 보통 실서비스에서는 노드포트로 서비스를 외부로 직접 제공하기 보다 Ingress라는 오브젝트로 간접 사용됨

3. LoadBalancer

• 동적으로 생성하는 기능을 제공하는 환경에서 사용할 수 있음 (GCP, AWS)
• $ kubectl get service를 하면 EXTERNAL-IP 항목을 볼 수 있음