k8s

Kubernetes

컨테이너를 여러 서버에 설치해 주는 Scheduler

Networking Abstaction, Service Discovery

pod

• 프로세스라 이해하면 된다?
• 컨테이너는 스레드라 생각하면 편함
• 온디맨드로 얼마든지 복제

Container Orchestration

• 컨테이너화 된 애플리케이션에 대한 자동화된 설정, 관리 및 제어 체계
• 지원해야 하는 기능
  • 배포 관리
    • 어느 컨테이너를 어느 호스트에 배치하여 구동시킬 것인가
    • 최적의 스케줄링과 배포 상태를 유지 관리하는 방법
  • 제어 및 모니터링
    • 구동 중인 각 컨테이너들의 상태를 추적 관리
  • 스케일링
    • 운영 상황에 따른 사용량 규모에 대응할 방법
  • 네트워킹
    • 운영되는 인스턴스 및 컨테이너들을 어떻게 상호 연결할 것인가?
  • 프로비저닝 컨테이너
  • 애플리케이션 구성
  • 전개
  • 스케일링
  • 수명 주기 관리
  • 중복성 및 가용성 관리
  • 자원 할당
  • 부하 분산
  • 서비스 발견
  • 컨테이너의 상태 모니터링
• 온라인 인프라 환경에서 대규모의 컨테이너들이 안정적으로 운영될 수 있도록 관리의 복잡성을 줄여주고 이를 자동화하는 것이 컨테이너 오케스트레이션

쿠버네티스의 핵심 설계 사상 5가지

• 선언적 구성 기반의 배포 환경
  • 특정한 동작을 지시하는 것이 아닌
    • ex) 레플리카를 5개 만들어라
  • 원하는 상태를 선언하는 개념
    • ex) 내 호스트의 레플리카를 항상 5개로 유지하라
  • 쿠버네티스는 원하는 상태와 현재의 상태가 상호 일치하는지 지속적으로 체크하고 업데이트 한다
  • Watch loop 가 돌면서 수행
• 기능 단위의 분산
  • 각각의 기능들이 개별적인 요소로서 독립적으로 분산되어 있다
  • Node, ReplicaSet, Deployment, Namespace 등
  • 클러스터를 구성하는 주요 요소들이 모두 컨트롤러로서 구성되어 있으며,
  • 이들은 Kube Controller Manager 안에 패키징 되어 있다
• 클러스터 단위 중앙 제어
  • 쿠버네티스는 전체 물리 리소스를 클러스터 단위로 추상화하여 관리한다
  • 컨트롤 플레인 역할의 마스터 노드를 두게 되며, 관리자는 이 마스터 노드를 이용하여 클러스터 전체를 제어한다
• 동적 그룹화
  • 쿠버네티스는 구성 요소들에게 쿼리 가능한 레이블과 메타데이터용 어노테이션에 임의의 키-값 쌍을 삽입할 수 있다
  • 관리자는 selector를 이용해서 레이블 기준으로 구성 요소들을 유연하게 관리할 수 있고,
  • 어노테이션에 기재된 내용을 참고하여 해당 요소의 특징적인 내역을 추적할 수 있다
• API 기반 상호작용
  • 쿠버네티스의 구성 요소들은 오직 Kubernetes API server를 통해서만 상호 접근이 가능한 구조를 가진다
  • 마스터 노드에서 kubectl 을 거쳐 실행되는 모든 명령은 이 API 서버를 거쳐 수행되며,
  • 컨트롤 플레인에 포함된 클러스터 제어 요소나 워커 노드에 포함된 kubectl, 프록시 역시 API 서버를 항상 바라보게 되어 있다

Kubernetis Cluster

• 쿠버네티스는 컴퓨팅 자원을 클러스터 단위로 추상화하여 관리함
• 마스터 노드를 두고 관리자는 마스터 노드를 통해 클러스터 전체를 제어
• 클러스터는 용도에 따라 크게 워커 노드, 마스터 노드로 구분된다
  • 워커 노드
    • 각기 다른 컨테이너들이 선적된 컨테이너선
    • 각기 다른 목적과 기능으로 세분화된 컨테이너들이 실제 배치되는 노드
  • 마스터 노드
    • 통제함
    • 워커 노드들의 가용 리소스 현황을 고려하여,
    • 컨테이너 배치와 모니터링
    • 그리고 각 컨테이너에 대한 효율적인 추적 관리가 가능하다

컨트롤 플레인

• 클러스터를 제어하는 쿠버네티스 구성 요소와 클러스터의 상태 및 구성에 관한 데이터가 함께 있다
• 컨트롤러가 필요한 리소스를 갖고 충분한 횟수로 실행되도록 하는 역할

kube-apiserver

• 쿠버네티스 컨트롤 플레인의 프론트엔드, 내부 및 외부 요청을 처리
• API 서버는 요청이 유효한지 판별하고 유효한 요청을 처리한다
• REST 호출 또는 kubectl 커맨드라인 인터페이스 등 CLI를 통해 API에 액세스

kube-scheduler

• 클러스터가 양호한 상태인가? 새 컨테이너가 필요하다면 어디에 적합한가? 등등
• CPU 또는 메모리와 같은 포드의 리소스 요구 사항과 함께 클러스터의 상태를 고려합니다
• 그런 다음 포드를 적절한 컴퓨팅 노드에 예약

kube-controller-manager

• 컨트롤러는 실제로 클러스터를 실행하고
• controller-manager에 여러 컨트롤러 기능이 하나로 통합
• 하나의 컨트롤러는 스케줄러를 참고하여 정확한 수의 포드가 실행되게 합니다
• 컨트롤러는 서비스를 포드에 연결하므로 요청이 적절한 엔드포인트로 이동합니다. 또한 계정 및 API 액세스 토큰 생성을 위한 컨트롤러가 있습니다

etcd

• 설정 데이터와 클러스터의 상태에 관한 정보는 키-값 저장소 데이터베이스인 etcd에 상주하빈다
• 내결함성을 갖춤

쿠버네티스 노드 개념과 특징

노드

• 최소 1개 이상의 컴퓨팅 노드가 필요하지만 일반적으로 여러 개
• 포드는 노드에서 실행되도록 예약되고 오케스트레이션 된다
• 클러스터의 용량을 확장해야 한다면 노드를 더 추가

포드

• 쿠버네티스 오브젝트 모델에서 가장 작고 단순한 유닛
• 애플리케이션의 단일 인스턴스
• 각 포드는 컨테이너 실행 방식을 제어하는 옵션과 함께 컨테이너 하나 또는 긴밀히 결합된 일련의 컨테이너로 구성되어 있다
• 포드를 퍼시스턴트 스토리지에 연결하여 stateful 애플리케이션을 실행할 수 있다

컨테이너 런타임 엔진

• 컨테이너를 실행할 컨테이너 런다임 엔진

Kubelet

• 각 노드에서 실행되는 기본 Node Agent
• 컨트롤 플레인과 통신하여 컨테이너가 포드에서 실행되게 한다, 노드에 대한 역할을 수행
• 컨트롤 플레인에서 노드에 작업을 요청하는 경우 kubelet이 이 작업을 실행

kube-proxy

• 각 컴퓨팅 노드에는 쿠버네티스 네트워킹 서비스를 용이하게 하기 위한 네트워크 프록시인 kube-prox도 있다
• L4의 프록시
• 운영체제의 패킷 필터링 계층에 의존하거나 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신을 처리

Ingress

• 클러스터 외부에서 안에 있는 pod에 접근할 때 사용하는 방법
• 외부 요청을 어떻게 처리할 지 정의해둔 규칙에 모음
• 실제 동작은 인그레스 컨트롤러가 함으로 Ingress와 kubernetes Ingress Controller를 연동해야 한다
• 외부 요청을 받아 내부 서비스에 연결

Service

• 쿠버네티스 환경에서 파드들을 통해 실행되고 있는 애플리케이션을 네트워크에 노출(expose)시키는 가상의 컴포넌트
• L4
• 여러개로 복제된 한 종류의 POD를 로드밸런싱 한다
• 인그레스는 여러 서비스에 대하여 라우팅의 역할을 담당
• service는 label selector를 통해 어떤 Pod를 포함할지 정의가 가능하다
• Service.yaml에서 어떤 방식으로 외부에 노출시킬지에 대한 type에는 여러 종류가 있다
  • ClusterIP
    • 클러스터 내부에서만 접근 가능한 IP
  • NodePort
    • Node란 실제 virtual mechine이다
    • NodePort 옵션은 해당 노드들에 고정 포트를 부여하고 노드들의 IP에 서비스를 노출시킨다
    • 이는 서비스가 쿠버네티스 클러스터 외부에서 노드의 IP 주소와 포트로 접근할 수 있도록 한다
    • https://hyeo-noo.tistory.com/m/362
  • Load Balancer
    • Node port 방식을 사용한다면 외부에서 노드의 네트워크 엔드포인트를 관리해야 하는 문제가 생긴다
    • type을 load balancer로 한다면 해당 이미지의 pod들에 대한 엔드포인트를 하나로 묶어주고 로드밸런싱도 해준다
  • ExternalName
    • Kube-nds 컴포넌트로 DNS을 이용하는 방법

Deployment

• 파드와 레플리카셋에 대한 선언적 업데이트를 제공
• Pod와 ReplicaSet에 대한 선언적 업데이트를 제공한다
• Deployment가 ReplicaSet을 제어하고, 관리자는 ReplicaSet을 직접 제어하면 안된다
  • 참고로, ReplicaSet은 업데이트에 대한 기능을 제공하지 않는다
• Rolling Update, Recreate, Blue/Green, Canary 이렇게 4가지 업데이트 방법을 제공한다

namespace

• 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다
• 논리적인 분리, 이중화용으로 사용하면 안됨, 클러스터가 고장나면 다 고장난다
• namespace를 지우면 하위 pod도 다 지워짐