ABOUT ME

    -

    Today
    -
    Yesterday
    -
    Total
    -
    • 쿠버네티스... 너 누군데...? (K8s Architecture)
      카테고리 없음 2023. 8. 7. 15:50
      해당 글은 구글 클라우드 스킬 부스트의 "Architecting with Google Kubernetes Engine: Foundations" 내용을 참고함을 알림

       

      Keyword

      • Declarative Management
      • K8s Concept
      • K8s Component
      • 관리형 쿠버네티스 서비스

       

      Declarative Management

      Kubernetes는 선언적 관리(Declarative Management)의 원칙을 기반으로 설계된 컨테이너 오케스트레이션 시스템임. 선언적 관리는 원하는 상태를 선언하고, 해당 상태를 실제로 구현하도록 하는 방식을 의미합니다. 이는 핵심 기능 중 하나이며, 애플리케이션 배포, 확장, 업데이트, 롤백 등을 관리하는 데 매우 유용한 접근 방식이라고 함.

       

      선언적 관리의 원칙:

      1. 선언적 언어: Kubernetes에서는 YAML 또는 JSON과 같은 선언적 언어를 사용하여 애플리케이션 및 리소스의 상태를 정의.
        YAML 파일에 원하는 상태를 선언하면, Kubernetes 컨트롤 플레인이 이를 이해하고 필요한 리소스를 생성하거나 관리합니다.
      2. 상태 일치(Match Desired State): 선언적 관리의 핵심 개념은 현재 상태가 원하는 상태와 일치하도록 유지하는 것. K8s는 지속적으로 클러스터의 상태를 감시하고, 원하는 상태와의 차이를 감지함. 그리고 해당 차이를 해소하기 위해 적절한 액션을 실행.
      3. 자가치유(Self-healing): 애플리케이션의 무결성을 유지하려 함. K8s는 노드 장애, 컨테이너 장애 등과 같은 문제가 발생할 때, 지정된 원하는 상태로 자동으로 복구하는 기능을 가지고 있음. 즉, 컨테이너가 종료되면 자동으로 새로운 컨테이너를 생성하여 원하는 상태를 유지토록 함.
      4. 선언적 업데이트: 애플리케이션 배포 또는 업데이트를 수행할 때, 새로운 버전의 애플리케이션을 정의하는 새로운 YAML 파일을 제출하는 것만으로 업데이트를 수행할 수 있음. 이러한 변경사항을 감지하고, 새로운 상태를 현재 상태와 비교하여 필요한 변경사항을 적용.

      선언적 관리의 원칙은 Kubernetes의 핵심, 개발자와 운영자는 애플리케이션 배포와 관리를 간편하고 안정적으로 수행할 수 있도록 하고 클러스터의 확장성과 가용성을 높이는 데에도 큰 도움이 됨.

      요약: Control Plane은 클러스터의 상태를 지속적으로 모니터링하여 선언된 것과 실제 상태를 끊임없이 비교하고 필요에 따라 상태를 수정한다. 두둥 탁!

       

       

      Pod

      • 쿠버네티스 모듈의 기본 구성 요소로 배포 가능한 가장 작은 객체
      • 쿠버네티스 시스템에서 실행 중인 모든 컨테이너는 pod
      • Pod는 하나 이상의 컨테이너를 수용할 수 있는데 이 경우 컨테이너는 서로 긴밀하게 결합하여 네트워킹과 스토리지 등 리소스를 공유
      • K8s는 각 pod에 고유한 IP 주소를 할당
      • 하나의 pod 내의 모든 컨테이너는 IP주소 및 네트워크 포트를 포함하여 네트워크 네임스페이스를 공유
      • 같은 pod 내의 컨테이너는 localhost 127.0.0.1을 통해 통신 가능

       

      Kubernetes Cluster diagram

      Control Plane

      전체 클러스터를 관리하는 역할을 수행

      • kube-APIserver
        • 사용자와 직접 상호작용하는 서버
        • pod의 실행을 포함하여 클러스터의 상태를 보고 변경하는 명령어를 받는다
        • 사용자는 kubectl을 통하여 해당 APIserver와 통신을 수행
        • 또한 수신 요청은 인증하고 이가 유요한지 확인하여 허용 제어를 관리
      • etcd
        • 클러스터의 상태를 안정적으로 저장
        • 모든 클러스터 구성 데이터 저장
        • 어떤 노드가 클러스터의 일부인지, 어떤 pod가 실행되어야 하는지, 어디서 실행되어야 하는지와 같은 동적인 정보도 포함됨
        • etcd는 kubectl로 직접적으로 사용자에게 제어되지 않고 kube-APIserver를 통하여 상호작용
      • kube-schedular
        • 노드에 pod를 예약하는 역할
        • 각 pod의 요구사항을 평가하고 가장 적합한 노드를 선택한다.
        • 그러나 실제로 노드에서 pod를 실행하는 작업을 수행하지는 않는다.
        • 노드에 아직 할당되지 않은 pod 객체를 발견할 때마다 노드를 선택하고 해당 노드 이름을 pod 객체에 쓰는 작업을 수행
        • pod를 실행할 위치를 결정하는 방법
          • 모든 노드의 상태를 알고 인지하고 하드웨어, 소프트웨어, 정책을 바탕으로 사용자가 정의한 제약조건을 따름
      • kube-controller-manager
        • kube-APIserver를 통해 지속적으로 클러스터의 상태를 모니터링하고 클러스터의 현재 상태와 원하는 상태가 일치하지 않을 때마다 kube-controller-manager는 원하는 상태를 이루고자 변경을 시도
      • kube-cloud-manager
        • CSP와 상호작용하는 컨트롤러를 관리

      Node

      쿠버네티스의 워커, 클러스터에 따라 가상 혹은 물리 머신일 수 있다.

      • Kubelet
        • 각 노드에서 실행되는 에이전트
        • kube-APIserver가 노드에서 pod를 실행하려고 하면 해당 노드의 kubelet에 연결
        • Kubelet은 컨테이너 런타임을 사용하여 pod를 시작하고 준비 및 활성 프로브를 포함한 생명 주기를 모니터링하며 kube-APIServer에 다시 보고
      • Kube-proxy
        • 클러스터의 pod 간 네트워크 연결을 유지관리
        • K8s에서는 Linux 커널에 내장된 IP 테이블의 방화벽 기능을 사용하여 이를 수행

       

      관리형 Kubernetes 서비스

      쿠버네티스 클러스터를 일일이 설정하려면 많이 까다롭다. 다행히 클러스터의 초기 설정 대부분을 자동화할 수 있는 오픈소스인 kubeadm이라는 명령어가 존재함. 그러나 특정 노드에 문제가 생기거나 노드에 유지보수가 필요하면 관리자가 수동으로 대응을 해야 한다. 그렇기 때문에 관리형 Kubernetes 서비스들이 많이 선호된다.

      요금적인 측면에서 고민이 될 수 있으나 쿠버네티스의 Control Plane이 3대의 인스턴스로 구성되고 LoadBalancer와 유지보수까지 고민한다면 EKS와 GKE는 합리적인 선택이 될 수 있을 것이다.

      또한 Control Plane의 구성 요소 또한 관리형 Kubernetes 서비스에 의해 관리된다.

    Designed by Tistory.

    티스토리툴바