Skip to content

Latest commit

 

History

History
534 lines (528 loc) · 49.7 KB

쿠버네티스를 활용한 클라우드 네이티브 데브옵스.md

File metadata and controls

534 lines (528 loc) · 49.7 KB

쿠버네티스와 마이크로서비스

  • 데브옵스의 실현, 마이크로서비스
    • 데브옵스는 개발 조직과 운영 조직이 물리적으로 격리되지 않는 환경에서 개발, 테스트, 배포, 운영에 이르는 전체 생명주기를 서로 긴밀하게 통합하여 관리
    • 데브옵스를 실현하기 위한 수단으로 필연적으로 마이크로서비스가 등장
    • 마이크로서비스는 전통적인 거대한 덩치의 애플리케이션을 잘게 쪼개는 것, 서비스의 집합으로서의 애플리케이션
    • 데브옵스 워크플로우
      • 소프트웨어의 개발과 운영의 합성어로서 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화
  • 마이크로서비스 아키텍처에 대한 정의
    • 소프트웨어 애플리케이션을 독립적으로 배치 가능한 서비스 조합(suite)으로 설계하는 방식
    • 마이크로서비스 아키텍처는 아주 작은 단위로 동작하는 서비스가 구동되도록 시스템 및 소프트웨어의 구성과 구성요소 간의 관계를 정의한 아키텍처
    • 모든 요소를 하나의 애플리케이션에 구축하는 전통적인 모놀로식 접근 방식 대신 마이크로서비스에서는 모든 요소가 독립적이며 연동되어 동일한 태스크를 완수
    • 하나의 애플리케이션을 구성함에 있어 분할된 다수의 서버 또는 컨테이너를 통해 애플리케이션 기능뿐만 아니라 데이터까지 분리하여 격리된 독립된 환경으로 구성되는 점이 특징
  • 마이크로서비스 특징
    • 애플리케이션 로직을 각자 책임이 명확한 작은 컴포넌트들로 분해하고 이들을 조합해서 솔루션을 제공
    • 각 컴포넌트는 작은 책임 영역을 담당하고 완전히 상호 독립적으로 배포
    • 마이크로서비스는 몇가지 기본 원칙에 기반을 두며, 서비스 소비자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON같은 경량 통신 프로토콜을 사용
  • 가상화와 컨테이너
    • 전통적인 배포 : 물리서버 기반 애플리케이션 실행
    • 가상화된 배포 : 단일 물리 서버의 CPU에서 여러 가상 시스템(VM)실행
    • 컨테이너 개발 : VM과 유사, 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유
  • 컨테이너의 장점
    • 기민한 애플리케이션 생성과 배포 - VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임
    • 지속적인 개발, 통합 및 배포 - 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있음
    • 개발과 운영의 관심사 분리 - 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 디커플 됨
    • 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있음
    • 개발, 테스트 및 운영 환경에 걸친 일관성 - 랩탐에서도 클라우드에서와 동일하게 구동됨
    • 클라우드 및 OS 배포판 간 이식성
    • 애플리케이션 중심 관리 - 가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의 논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 수준이 높아짐
    • 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스 - 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있음
    • 자원 격리 - 애플리케이션 성능을 예측할 수 있음
    • 자원 사용량 - 고효율 고집적
  • 컨테이너 오케스트레이션
    • 컨테이너 배포 관리는 흔히 컨테이너 오케스트레이션(Container Orchestration)
    • 컨테이너 오케스트레이션의 목적은 여러 컨테이너의 배포 프로세스를 최적화
    • 애플리케이션은 더 이상 하나의 통일체가 아니라 특정 애플리케이션이 설계 의도대로 기능하도록 함께 작동해야 하는 수십 또는 수백 개의 느슨하게 결합되고 컨테이너화된 요소로 구성
    • Apache Mesos, Google Kubernetes, Docker Swarm 등의 플랫폼들은 각자 컨테이너 관리를 위한 자체적인 특별한 방식을 보유
  • 컨테이너 오케스트레이션 기능
    • 컨테이너형 애플리케이션의 배포
    • 컨테이너 그룹에 대한 로드밸런싱
    • 스케일링/오토스케일링
    • 컨테이너 장애 복구
    • 컨테이너 그룹간 격리/연결
    • 외부로 서비스 노출
    • 서비스 디스커버리
    • 로그 수집 집중화 / 자동화
    • 모니터링 집중화 / 자동화
  • Kubernetes
    • 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장 가능한 오픈소스 플랫폼
    • 디플로이(Deploy), 자동화, 스켈일링(Scaling), 컨테이너화된 애플리케이션의 관리를 위한 오픈소스 시스템
    • 여러 클러스터의 호스트간 애플리케이션 컨테이너의 배치, 스케일링, 운영을 자동화하기 위한 플랫폼을 제공
    • 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가짐
    • 쿠버네티스란 명칭은 키잡이(helmsman)이나 파일럿을 뜻하는 그리스어에서 유래
    • 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화 함
  • Docker Swarm
    • 여러 개의 Docker 호스트를 함께 클러스터링하여 단일 가상 Docker 호스트를 생성
    • 호스트 OS에 Agent만 설치하면 간단하게 작동하고 설정이 쉬움
    • Docker 명령어와 Compose를 그대로 사용가능
  • Apache Mesos
    • 수만 대의 물리적 시스템으로 확장 할 수 있도록 설계되어 있음
    • Hadoop, MPI, Hypertable, Spark같은 응용프로그램을 동적클러스터 환경에서 리소스 공유와 분리를 통해 자원 최적화가 가능
    • Docker 컨테이너를 적극적으로 지원함

쿠버네티스와 컨테이너

  • 도커 컨테이너
    • 도커는 BSD와 솔라리스(Solaris)와 같은 유닉스(Unix) 운영체제에서 수십년 간 사용되었던 개념이 현대적으로 재탄생된 최신 개념
    • 각 애플리케이션과 종속물이 운영체제 리소스의 분리된 세그먼트를 이용하는 방식
    • 컨테이너 런타임(container runtime)은 호스트 운영체제가 제공하는 저수준 컨테이너 서비스를 사용해 컨테이너를 셋업하거나 없앰
    • 분리와 조절 기능 제공
      • 도커 컨테이너는 앱을 서로 그리고 기반이 되는 시스템으로 부터 계속 분리
      • 동시에 더 쉽게 분리된 특정 애플레케이션의 CPU와 GPU, 메모리, I/O, 네트워킹 등 시스템 리소스 사용 방식을 규정
    • 이식성을 제공하는 도커 컨테이너
      • 컨테이너 런타임 환경을 지원하는 모든 장치에서 실행
    • 결합성(Composability)을 제공하는 도커 컨테이너
      • 대부분의 비즈니스 애플리케이션은 웹 서버, 데이터베이스, 인-메모리 캐시 등 하나의 스택으로 구성되는 여러 별개의 구성 요소로 구성, 이런 조각들을 쉽게 변경할 수 있는 부품으로 구성된 기능 유닛으로 결합
    • 오케스트레이션과 스케일링이 쉬운 도커 컨테이너
      • 여러 시스템에서의 애플리케이션 스케일링, 수요 증가와 리소스 보존을 위한 서비스 증가 및 다운에도 컨테이너를 사용
    • 가상 머신이 아닌 도커 컨테이너
      • 가상 머신은 운영체제에서 자신의 인스턴스에서 실행되기 때문에 고수준의 프로세스 분리 기능을 제공
    • 변경이 불가능하고, 비저장성이 특징인 도커 컨테이너
      • 내용을 설명하는 이미지로부터 부팅 및 실행됨, 이미지는 기본적으로 변경이 불가능함, 일단 생성되면 바뀌지 않음
    • 마이크로서비스가 아닌 도커 컨테이너
      • 컨테이너를 사용하면 더 쉽게 마이크로서비스 애플리케이션을 구현할 수 있음
  • 쿠버네티스와 데브옵스 운영
    • 컨테이너 기술은 민첩성을 확보하는 핵심 가상화 기술이며 컨테이너 기반의 가상화 환경을 운영 관리하는 핵심 기술이 바로 쿠버네티스(Kubernetes)
    • 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스, 쿠버네티스
    • 마이크로 서비스 아키텍처 발전
    • 데브옵스 모델의 성숙화
    • 개발 환경을 컨테이너 기반 가상화 환경으로 구현하고 CI(Continuous Integration)/CD(Continuous Development) 도구 및 개발 방법론을 결합함으로써 코딩, 빌드 및 테스트를 보다 쉽고 빠르게 수행하며 개발 환경 자동화와 손쉬운 운영 환경 배포의 기반을 마련
    • CI 기술은 개발 과정에서 빠른 소프트웨어 수정을 통해 품질 및 배포 속도를 향상시키며, CD기술은 소프트웨어 업데이트를 업무 애플리케이션에 적용해 변경 사항을 보다 효율적으로 배포하도록 지원
  • 마이크로 서비스 아키텍처
    • 관리 컨테이너
      • 개별 서비스 인스턴스에는 작동 할 컨테스트가 필요, 가상 컴퓨터 , Docker 컨테이너 또는 조정 된 프로세스로 구현 된 관리 컨테이너는 이러한 기능을 제공
    • 외부 게이트웨이
      • MSA 구현은 비즈니스 응용 프로그램 및 응용 프로그램에서 사용할 수 있는 API 형태로 기능을 노출 , 서비스 외부 게이트웨이는 이러한 서비스에 대한 액세스를 관리하고 트래픽 관리 및 보안 정책을 적용하여 마이크로 서비스 환경을 보호
    • 서비스 메쉬 기능
      • 서비스 메쉬는 서비스 간의 통신을 느슨하게 결합, 신뢰성 및 유연성을 유지하는 데 도움이되는 기능으로 구성되며 서비스 분리, 버전 관리 및 전략 지원 및 부하시 탄성 확장성 관리가 가능
    • 서비스 이미지 레지스트리 : 사용자 환경이 어딘가에는 빌드되고 테스트 된 서비스 불변 이미지를 저장하는 레지스트리로 저장소(동적으로 생성된 서비스의 경우), Docker 이미지 레지스트리, 이진 아티팩트 저장소 또는 VM 이미지 BLOB(Binary Large Object)기반 저장소 등
    • 메시지 지향 미들웨어 : 가장 간단한 MSA 구현은 HTTP와 같은 동기식 프로토콜 또는 gRPC 또는 Thrift와 같은 보다 효율적인 프로토콜을 사용하여 지속 가능하며 이벤트 및 메시지 중심 패턴을 지원하기 위해 비동기 메시징 채널이 필요
    • 빌드 및 테스트 자동화 : MSA의 개발 민첩성 이점은 개발 출력 품질을 극대화하고 전달을 간소화하기 위해 개발주기에서 높은 수준의 빌드 및 테스트 자동화가 필요
    • 배포 자동화 : 개발 민첩성 이점을 완전히 실현하려면 배포를 자동화

쿠버네티스와 오브젝트 모델

  • 쿠버네티스 생태계(CNCF : Cloud Native Interactive Landscape)
  • 쿠버네티스 개념
    • image
    • 클러스터 전체를 관리하는 컨트롤러로써 마스터
    • 컨테이너가 배포되는 머신(가상머신이나 물리적인 서버머신)인 노드
  • 쿠버네티스 오브젝트
    • 쿠버네티스는 상태를 관리하기 위한 대상을 오브젝트로 정의
    • 쿠버네티스 시스템에서 영속성을 가지는 개체
    • 클러스터 상태를 나타내기 위해 이 개체를 이용
    • 쿠버네티스 객체
      • 어떤 컨테이너화된 애플리케이션이 동작 중인지(그리고 어느 노드에서 동작 중인지)
      • 그 애플케이션이 이용할 수 있는 리소스
      • 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
    • 기본 오브젝트(Basic Object), 컨트롤러(Controller), 오브젝트 스펙 및 메타 정보로 구성
  • 쿠버네티스 기본 오브젝트
    • 컨테이너화되어 배포되는 애플리케이션의 워크로드를 기술하는 오브젝트
    • 오브젝트는 사용자가 쿠버네티스에 바라는 상태(desired state)를 의미하고 컨트롤러는 객체가 원래 설정된 상태를 잘 유지할수 있게 관리하는 역할
    • Pod : 컨테이너화된 애플리케이션
      • 하나의 컨테이너를 개별적으로 배포하는 것이 아닌 Pod 단위로 배포
      • 가장 기본적인 배포 단위로 하나 이상의 컨테이너를 포함하는 단위
      • 일반적으로 1 Pod 1 Container
      • Pod 내의 컨테이너들은 IP, Port를 공유
      • Pod가 재시작되면 IP가 변경되며 Pod내의 컨테이너들의 로컬디스크의 내용이 사라짐
      • Pod 내에 배포된 컨테이너간에는 디스크 볼륨을 공유 가능
    • Service : 로드밸런서
      • Label Selector로 Pod를 선택하여 하나의 Endpoint로 노출
      • 프리버전을 사용하게 되면 WorkerNode의 NodePort로 밖에 접근할 방법이 없음
      • 종류: ClusterIP, NodePort, LoadBalancer, ExternalName
      • Pod와 Volume을 이용하여 컨테이너들을 정의한 후에 Pod를 서비스로써 제공할 때 일반적으로 하나의 Pod로 서비스를 하는 경우는 드물고 여러개의 Pod를 서비스하며 이를 로드밸런서를 이용해 하나의 IP와 포트로 묶어서 서비스를 제공
      • Label Selector : 서비스를 정의할 때 어떤 Pod들을 Serviece로 묶을 것인지를 정의함
      • 각 Pod를 생성할 때 Object Spec의 metadata 부분에 Pod에서 사용할 라벨(Label)을 정의
    • Volume : 디스크
      • Pod가 기동될 때 디폴트로 컨테이너마다 로컬 디스크를 생성해서 기동되는데, 이 로컬 디스크의 경우에는 영구적이지 못함
      • 데이타 베이스와 같이 영구적으로 파일을 저장해야 하는 경우에는 컨테이너 재시작과 상관 없이 파일을 영속적으로 저장해야 하는데, 이러한 형태의 스토리지를 볼륨
      • Pod와 lifecycle이 같음
      • 컨테이너의 외장 디스크와 유사하며 Pod가 기동될때 컨테이너에 마운트하여 사용
      • iSCSI나 NFS와 같은 Onpremiss기반의 외장 스토리지 이외에 클라우드 외장 스토리지인 AWS EBS, Google PD 그리고 github, 등의 오픈소스 기반 외장스토리 서비스를 지원
    • Namespace : 패키지명
      • 한 쿠버네티스 클러스터내의 논리적인 분리단위
      • Pod,Service 등은 네임 스페이스 별로 생성이나 관리가 될 수 있고, 사용자의 권한 역시 이 네임 스페이스 별로 나눠서 부여 가능
      • 네임스페이스로 할 수 있는 거은 사용자별로 네임스페이스별 접근 권한을 다르게 운영 가능하고, 네임스페이스별로 리소스의 쿼타(할당량)을 지정 가능하고 네임 스페이스별로 리소스를 나눠서 관리 할 수 있음(Pod, Service 등)
      • 네임 스페이스는 논리적인 분리 단위이지 물리적이나 기타 장치를 통해서 환경을 분리(Isolation)한 것이 아니며 다른 네임 스페이스간의 Pod 라도 통신은 가능
  • 쿠버네티스 라벨
    • 쿠버네티스 리소스
      • 라벨은 쿠버네티스의 리소스를 선택하는데 사용
      • 각 리소스는 라벨을 가질 수 있고, 라벨 검색 조건에 따라서 특정 라벨을 가지고 있는 리소스만을 선택 가능
      • 특정 리소스만 배포하거나 업데이트할 수 있고 또는 라벨로 선택된 리소스만 Service에 연결하거나 특정 라벨로 선택된 리소스에만 네트워크 접근 권한을 부여하는 등의 행위 가능
  • 쿠버네티스 컨트롤러
    • image
    • 컨트롤러는 기본 오브젝트들을 생성하고 이를 관리하는 역할
    • 컨트롤러는 Replication Controller (aka RC), Replication Set, DaemonSet, Job, StatefulSet, Deployment 등 존재
    • Replication Controller
      • Replication Controller는 Pod를 관리해주는 역할을 하는데, 지정된 숫자로 Pod를 기동 시키고, 관리하는 역할
      • Replication Controller (이하 RC)는 크게 3가지 파트로 구성되는데, Replica의 수, Pod Selector, Pod Template 3가지로 구성
    • ReplicaSet
      • Replication Controller의 새버전
      • Replication Controller는 Equality 기반 Selector를 이용하는데 반해, Replica Set은 Set 기반의 Selector를 이용
    • Deployment
      • Deployment(이하 디플로이먼트) Replication controller와 Replica Set의 좀더 상위 추상화 개념
      • 실제 운영에서는 ReplicaSet이나 Replication Controller를 바로 사용하는 것보다, 좀 더 추상화된 Deployment를 사용
    • DaemonSet(DS)
      • Pod가 각각의 노드에서 하나씩만 돌게 하는 형태로 Pod를 관리하는 컨트롤러
      • DS에 의해 관리되는 Pod는 모든 노드에 균등하게 하나씩만 배포
      • 특정 노드에만 Pod를 배포할 수 있도록, Pod의 node selector를 이용해서 라벨을 이용하여 특정 노드만을 선택할 수 있게 지원
    • Job
      • 워크로드 모델중에서 배치나 한번 실행되고 끝나는 형태의 워크로드 모델을 지원하는 컨트롤러
      • Job에 의해서 관리되는 Pod는 Job이 종료되면, Pod를 같이 종료
      • Job을 정의할 때 컨테이너 스펙 부분에 image 뿐만 아니라, 컨테이너에서 Job을 수행하기 위한 커맨드(command)를 같이 입력
    • StatefulSet
      • 데이타 베이스 등과 같이 상태를 가지고 있는 Pod를 지원하기 위해서 StatefulSet 이라는 것이 새로 소개
      • 쿠버네티스의 디스크 볼륨에 대한 이해가 필요

쿠버네티스와 클러스터 아키텍쳐

  • 마스터와 노드
    • 쿠버네티스는 크게 마스터와 노드 두개의 컴포넌트로 분리
    • 쿠버네티스 마스터
      • 쿠버네티스의 설정 환경을 저장하고 전체 클러스터를 관리하는 역할
      • etcd,kube-apiserver, kube-scheduler, kube-controller-manager
    • 쿠베네티스 노드
      • 노드나 파드나 컨테이너처럼 쿠버네티스 위에서 동작하는 워크로드를 호스팅 하는 역할
      • 노드에서 kubelet, kube-proxy, docker등이 실행
      • 실제 사용자가 사용하는 컨테이너들은 대부분 노드에서 실행
  • 마스터 컴포넌트
    • 마스터 컴포넌트
      • 클러스터 전체를 관리하는 컨트롤러
      • 클러스터의 컨트롤 플레인을 제공
      • 클러스터에 관한 전반적인 결정(ex-스케줄링)을 수행하고 클러스터 이벤트(ex-디플로이먼트와 replicas 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응
      • 클러스터 내 어떠한 머신에서도 동작 가능
      • API Server, Controller Manager, Scheduler, etcd로 구성
      • 관리자는 Master API Server를 통해 K8s를 관리하며 모든 컴포넌트들을 API Server를 통해 서로 통신
    • kube-scheduler
      • 노드가 배정되지 않은 새로 생성된 파드를 감지하고 그것이 구동될 노드를 선택하는 마스터 상의 컴포넌트
      • 새로운 파드를 만들어질 때 현재 클러스터내에서 자원할당이 가능한 노드들 중에서 알맞은 노드를 선택해서 그곳에 포드를 띄우는역할
      • 파드는 처음 실행될 때 여러 가지 조건을 지정해서 실행하는데, kube-scheduler가 그 조건에 맞는 노드를 찾아주는 역할
      • 스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함
    • Kube-controler-manager
      • 컨트롤러를 구동하는 마스터 상의 컴포넌트
      • 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일 되고 단일 프로세스내에서 실행
    • cloud-controller-manager
      • 바탕을 이루는 클라우드 제공사업자와 상호작용하는 컨트롤러를 작동
      • 클라우드 밴더 코드와 쿠버네티스 코드가 서로 독립적으로 발전 나갈 수 있도록 해줌
    • kube-apiserver
      • 쿠버네티스는 MSA(마이크로서비스아키텍처) 구조
      • 여러 개의 분리된 프로세스로 구성
      • 쿠버네티스 API를 노출하는 마스터 상의 컴포넌트, 쿠버네티스 컨트롤 플레인에 대한 프론트엔드
      • 클러스터로 요청이 왔을때 그 요청이 유효한지 검증하는 역할
      • 쿠버네티스로의 모든 요청은 kube-apiserver를 통해서 다른 곳으로 전달
      • kube-apiserver는 수평적으로 확장이 가능하게 설계가 되어 있어서, 여러 대의 장비에 여러 개를 띄워놓고 사용
    • ETCD
      • 고가용성을 제공하는 분산 키-밸류(key value)스토어(저장소)
      • 쿠버네티스에서 필요한 모든 데이터를 저장하는 실질적인 데이터베이스
      • 프로세스 1개만 띄워서 사용할 수도 있지만 데이터의 안전성을 위해서는 여러 개의 장비에 분산해서 etcd 자체를 클러스터링을 구성해서 실행하는 게 일반적인 방법
      • etcd가 안정적이기는 하지만 보다 안정적으로 쿠버네티스를 운영하려면 주기적으로 etcd에 있는 데이터를 백업 필요
      • curl 등 HTTP 클라이언트/라이브러리로 작업 가능
  • 노드 컴포넌트
    • image
    • 동작중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작
    • 노드는 쿠버네티스에 있어서 워커 머신이며 클러스터에 따라 VM 또는 물리 머신이 될 수 있음, 여러 개의 파드는 하나의 노드 위에서 동작할 수 있음
    • kubelet
      • 클러스터내의 모든 모드에서 실행되는 에이전트
      • 쿠버네티스 마스터와 통신
      • Pod들과 Node의 상태를 클러스터에 보고
      • 파드내의 컨테이너들이 실행되는걸 직접적으로 관리하는 역할
      • 다양한 메커니즘으로 제공된 PodSpec 설정 집합을 가지며, PodSpec에 기술된 컨테이너들이 정상적으로 실행되고 있는지 상태 체크를 진행
      • 노드안에 있는 컨테이너라고 하더라도 쿠버네티스에 의해 생성되지 않은 컨테이너들은 관리하지 않음
    • kube-proxy
      • 클러스터 내 각 노드에서 실행되는 네트워크 프록시
      • 각 노드의 쿠버네티스 네트워킹 서비스를 반영하는 네트워크 프록시
      • 쿠버네티스는 클러스터 내부에 별도의 가상 네트워크를 설정하고 관리
      • 가상 네트워크가 동작할 수 있게 하는 실질적인 역할을 하는 프로세스
      • 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로써 쿠버네티스 서비스 추상화가 가능하도록 해줌
    • 컨테이너 런타임
      • 실제로 컨테이너를 실행시키는 역할
      • 가장 많이 알려진 런타임으로는 도커(Docker)가 있고, 그외 rkt, runc 같은 런타임도 지원
      • 컨테이너에 관한 표준을 제정하는 역할을 하는 OCI(Open Container Initiative)의 런타임 규격을 구현하고 있는 컨테이너 런타임이라면 쿠버네티스에서 사용 가능
  • 애드온
    • 쿠버네티스 리소스(데몬셋, 디플로이먼트 등)를 이용하여 클러스터 기능을 구현
    • 클러스터 단위의 기능을 제공하기 때문에 애드온에 대한 네임스페이스 리소스는 Kube-system 네임스페이스에 속함
    • DNS
      • 절대적으로 요구되지 않지만 필요로 하기 때문에 모든 쿠버네티스 클러스터는 cluster DNS를 갖추어야 함
      • 클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버
    • 웹 UI(대시보드)
      • 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI
      • 사용자로 하여금 클러스터 자체 뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리 및 장애 처리
    • 컨테이너 리소스 모니터링
      • 중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공
    • 클러스터-레벨 로깅
      • 검색 / 열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장

쿠버네티스 운영

  • 볼륨, 디스크 서비스
    • 쿠버네티스 볼륨
      • image
      • 데이터를 담는 디렉터리
      • Pod 내 컨테이너들이 접근가능함
      • Pod에 소속되는 동안 유지됨
      • Pod 내에서 구동되는 컨테이너들보다 오래 유지되며, 그 데이터는 컨테이너가 재시작되더라도 계속 보존됨
    • 쿠버네티스 볼륨 종류
      • 로컬디스크,configMap, secret, persistentVolumeClaim, emptyDir, hostPath
      • NFS,iSCSI, Fiber Channel과 같은 일반적인 외장 디스크 인터페이스
      • GlusterFS나 Ceph와 같은 오픈 소스 파일 시스템
      • AWS EBS, GCP Persistent 디스크와 같은 퍼블릭 클라우드에서 제공되는 디스크
      • VspherVolume과 같이 프라이비트 클라우드 솔루션에서 제공하는 디스크 볼륨
    • emptyDir
      • Pod가 생성될때 생성되고, Pod가 삭제 될때 같이 삭제되는 임시 볼륨으로 생성 당시에는 디스크에 아무 내용이 없기 때문에 emptyDir
      • 단 Pod 내의 컨테이너 크래쉬되어 삭제되거나 재시작 되더라도 emptyDir의 생명주기는 컨테이너 단위가 아니라 Pod 단위이기 때문에 emptyDir은 삭제되지 않고 계속해서 사용이 가능
    • hostPath
      • 노드의 로컬 디스크의 경로를 Pod에서 마운트해서 사용
      • 같은 hostPath에 있는 볼륨은 여러 Pod 사이에서 공유되어 사용
      • Pod가 삭제 되더라도 hostPath에 있는 파일들은 삭제되지 않고 다른 Pod가 같은 hostPath를 마운트하게 되면, 남아 있는 파일을 액세스 가능
      • 노드의 /tmp 디렉토리를 hostPath를 이용하여 /data/shared 디렉토리에 마운트
    • gitRepo
      • 생성시에 지정된 git 레파지토리의 특정 리비전의 내용을 clone을 이용해서 내려 받은후에 디스크 볼륨을 생성하는 방식
      • 물리적으로 emptyDir이 생성되고, git 레파지토리 내용을 clone으로 다운
    • PersistentVolume(PV) and PersistentVolumeClaim(PVC)
      • 클러스터 내 스토리지 일부 조각을 나타내는 API 객체
      • 개별 Pod의 수명주기를 넘어 보존되는 범용,플러그가능 자원으로서 가용함
      • 볼륨 자체를 의미하는 PV들은 스토리지를 사용하고자 할 때 그 제공방식의 세부사항들을 추상화하는 API를 제공함
      • 스토리지가 사전에 생성되는 시나리오(정적 프로비저닝)에서는 PV들이 직접 사용됨
      • 반면 온디멘트 스토리지를 필요로 하는 시나리오(동적 프로비저닝)에서는 PV 대신 PVC가 사용됨
      • PV는 파드하고는 별개로 관리되고 별도의 생명주기를 가지고 있으며, PVC는 사용자가 PV에 하는 요청
  • 쿠버네티스 서비스
    • Pod 집합과 같은 애플리케이션들에 접근하는 방법을 기술하는 API 객체
    • 포트,로드밸런서를 기술할 수 있음
    • Pod들을 서로 연결함
    • 설정을 분리(decouple)한다
    • Pod 접근 정책을 정의함
    • 마이크로서비스와 대응되는 개념
    • 액세스 포인트는 내부일수도 외부일 수도 있음
    • 서비스는 지정된 IP로 생성이 가능하고, 여러 Pod를 묶어서 로드 밸런싱이 가능하며, 고유한 DNS 이름을 가질 수 있음
    • 멀티 포트 지원, Pod 간에 랜덤으로 부하를 분산하는 로드 밸런싱 알고리즘 지원
  • Health Check
    • 쿠버네티스는 각 컨테이너의 상태를 주기적으로 체크해서, 문제가 있는 컨테이너를 자동으로 재시작하거나 도는 문제가 있는 컨테이너(Pod를) 서비스에서 제외 가능한 기능
    • Liveness probe : 컨테이너가 살아 있는지 아닌지를 체크하는 방법
    • Readiness probe : 컨테이너가 서비스가 가능한 상태인지를 체크하는 방법
    • Prob types
      • Liveness probe와 readiness porbe는 컨테이너가 정상인지 아닌지를 체크하는 3가지 방법
      • Command probe : 컨테이너의 상태 체크를 쉘 명령을 수행으로 체크
      • HTTP probe : HTTP GET을 이용하여, 컨테이너 상태를 체크
      • TCP probe : 지정된 포트에 TCP 연결을 시도하여 상태를 체크

쿠버네티스 배포

  • 롤링 업데이트
    • 일반적으로 애플리케이션을 배포하는 방법은 블루/그린, 카날리 배포, 롤링 업데이트 등이 존재
    • 가장 많이 사용되는 배포 방식 중의 하나
    • 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 하는 방법
    • 사용자들은 애플리케이션이 항상 가용한 상태일 것이라 여기고 개발자들은 하루에 여러번씩 새로운 버전을 배포하도록 요구됨 - 시스템을 무 장애로 업데이트할 수 있다는 장점
    • 방식
      • 여러 개의 인스턴스를 동작시키도록 애플리케이션을 스케일하는 것은 애플리케이션의 가용성에 영향을 미치지 않으면서 업데이트를 수행하는 것에 대한 요구
      • 기본적으로 업데이트가 이루어지는 동안 이용 불가한 파드의 최대 개수와 생성 가능한 새로운 파드의 최대 개수는 하나
      • 애플리케이션 스케일링과 유사하게 디플로이먼트가 외부로 노출되면, 서비스는 업데이트가 이루어지는 동안 오직 가용한 파드에게만 트래픽을 로드밸런스 할 것임, 가용한 파드란 애플리케이션의 사용자들에게 가용한 상태의 인스턴스를 의미
    • 동작
      • 하나의 환경에서 또 다른 환경으로의 애플리케이션 프로모션(컨테이너 이미지 업데이트를 통해)
      • 이전 버전으로의 롤백
      • 서비스 중단 없는 애플리케이션의 지속적인 통합과 지속적인 전달
      • 디플로이먼트가 외부로 노출되면, 서비스 업데이트가 이루어지는 동안 오직 가용한 파드에게만 트래픽을 로드밸런스 할 것임
  • 디플로이먼트
    • 쿠버네티스에서는 일반적으로 Replication Controller(RC)를 이용해서 배포하지 않고 Deployment라는 개념을 사용
    • 복제된(replicated) 애플리케이션을 관리하는 API 객체
    • 각 레플리카는 각각 하나의 Pod로 대표되며, 그러한 Pod들은 클러스터 내 노드들에 걸쳐 배포됨
    • ReplicatSet(+Pod)을 생성
    • 롤릴 업데이트 등을 할 때 RC를 두 개를 만들어야 하고 하나씩 Pod의 수를 수동으로 조정해야 하기 때문에 이를 자동화 해서 추상화한 개념이 Deployment
    • 기본적으로 Replication Controleer (RC)를 생성하고 이를 관리하는 역할
    • 특징
      • 쿠버네티스가 애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시
      • 디플로이먼트가 만들어지면, 쿠버네티스 마스터가 해당 애플리케이션 인스턴스를 클러스터의 개별 노드에 스케줄
      • 애플리케이션 인스턴스가 생성되면, 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를 모니터링
      • 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 메커니즘을 제공
      • 디플로이먼트는 애플리케이션 인스턴스를 생성하고 업데이트 하는 역할을 담당함
    • Kubectl이라는 쿠버네티스 CLI를 통해 디플로이먼트를 생성하고 관리
    • Kubectl은 클러스터와 상호 작용하기 위해 쿠버네티스 API를 사용
    • 디플로이먼트를 생성할 때, 애플리케이션에 대한 컨테이너 이미지와 구동시키고자 하는 복제 수를 지정
    • 애플리케이션이 쿠버네티스 상에 배포되려면 지원되는 컨테이너 형식 중 하나로 패키지 되어야함
  • ConfigMap
    • 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해 주기 위한 기능 : 클라우드 네이티브 아키텍처에서 컨테이너는 변하지 않는 자원
    • 비기밀 데이터를 키-값 쌍으로 저장하기 위해 사용하는 API 객체
    • 컨테이너 이미지에서 설정 데이터를 분리(decouple)시키기 위한 것
    • 컨테이너 이미지에서 사용하는 환경변수와 같은 세부 정보를 분리하고, 그 환경변수에 대한 값을 외부로 노출 시키지 않고 내부에 존재하는 스토리지에 저장해서 사용하는 방법
    • 환경변수, 커맨드라인 인자, 볼륨 내의 설정파일로 사용 가능
    • 컨피그맵을 사용하면 컨테이너 이미지에서 해당 환경에 국한된 설정을 분리 가능 : 애플리케이션을 어디로든 쉽게 이전 가능(portable)
    • ConfigMap을 변경하더라도 Running 상태의 Pod에 곧바로 적용되지 않으며 Pod을 재기동 해야 함
    • 사용방법
      • 파일 시스템(filesystem)
        • pod에 configmap을 마운트할 수 있음, 키 이름에 따라 각 항목의 파일이 생성됨, 해당 파일의 내용은 값으로 설정
      • 환경변수 (environment variable)
        • configmap 을 사용해 환경변수의 값을 동적으로 설정
      • 명령줄인수 (command-line arguemnt)
        • 쿠버네티스는 configmap 값을 기반으로 컨테이너에 대한 명령줄을 동적으로 생성하도록 지원

쿠버네티스 모니터링

  • 쿠버네티스 모니터링 시스템
    • 개념
      • 시스템을 운영하는데 있어서 운영 관점에 있어서 가장 중요한 기능중의 하나는 시스템에 대한 모니터링
      • 시스템 자원의 사용량이나 에러 등에 대한 모니터링을 통해서 시스템을 안정적으로 운영하고 문제 발생시 원인 파악과 대응 가능
      • 쿠버네티스 기반의 시스템 모니터링 대상
        • 리소스 : 리소스 모니터링은 클러스터와 애플리케이션 헬스를 이해하기 위해 필수적
        • 디스크 : 임계치는 클러스터 사이즈와 상관이 없기 때문에, 디스크 사용량을 모니터링 하는 것은 디스크 볼륨을 모니터링 하는 것 보다 더 효율적
        • CPU : CPU 모니터링은 Kube-state-metrics를 통해 가능하며 시스템, 사용자 사용량과 iowait 또한 모니터링 가능
        • 메모리 : 메모리 모니터링 또한 Kube-state-metrics에서 가능하며 메모리 사용량 확인 가능
        • Pod : Pod deployment의 헬스는 쿠버네티스가 제대로 작동하는지 확인
        • 네트워크 : 네트워크 대역폭
    • 쿠버네티스 시스템 모니터링 4가지 계층
      • image
      • 호스트(노드)
        • 쿠버네티스 컨테이너를 실행하는 하드웨어 호스트 , 즉 노드에 대한 지표 모니터링이 필요
        • 노드의 CPU, 메모리, 디스크, 네트워크 사용량과 노드 OS와 커널에 대한 모니터링
      • 컨테이너
        • 노드에서 기동되는 각각의 컨테이너에 대한 정보
        • 컨테이너 CPU, 메모리, 디스크, 네트워크 사용량등을 모니터링
      • 애플리케이션
        • 컨테이너 안에서 구동되는 개별 애플리케이션의 지표를 모니터링
        • 컨테이너에서 기동되는 애플리케이션의 응답시간, 에러 빈도 등을 모니터링
      • 쿠버네티스
        • 컨테이너를 컨트롤 하는 쿠버네티스 자체에 대한 모니터링
        • 쿠버네티스의 자원인 서비스나 POD, 계정 정보 등
  • 프로메테우스 기반 모니터링 아키텍처
    • SoundCloud에서 개발된 모니터링 툴
    • 시계열 데이터를 저장할 수 있는 다차원 데이터 모델과 이 데이터 모델을 효과적으로 활용할 수 있는 PromQL이라는 쿼리 언어
    • 수집대상을 정적으로 설정할 수도 있고 서비스 디스커버리(service discovery)를 통해서 동적으로 설정하는 것도 가능
    • 데이터 저장은 디스크에 저장하는 것도 가능하지만 외부 스토리지에 저장하는것 역시 가능
    • 프로메테우스 서버
      • 시계열 데이터를 수집해와서 저장하는 메인 컴포넌트
    • 클라이언트 라이브러리
      • 애플리케이션을 개발할 때 프로메테우스에서 데이터를 수집
    • pushgateway
      • 클라이언트에서 직접 프로메티우스로 데이터 전송시 송신
    • 익스포터(exporter)
      • 프로메테우스 클라이언트 라이브러리를 내장해서 만들어지지 않은 애플리케이션들에서 데이터를 수집
    • 알럿매니저(AlertManager)
      • 알람을 보낼 때 알람의 중복처리, 그룹핑 등과 알람
  • 모니터링 시스템 구축
    • 데이타 수집 부분
      • 기본적으로 프로메테우스는 데이터 수집을 PULLING 모델을 사용
      • 모니터링 대상이 되는 자원이 지표 정보를 프로메테우스로 보내는 것이 아니라 프로메테우스가 주기적으로 모니터링 대상에서 지표를 읽는 모델을 사용
      • 모니터링 대상이 프로메테우스의 데이터 포맷을 지원할 경우 바로 읽어올 수 있고 만약에 지원하지 않는다면 별도의 에이전트를 설치해서 지표를 읽어올 수 있는데 이를 exporter라고 함
      • mysql, nginx, redis와 같은 패키지는 미리 개발된 export가 있어서 다양한 서비스의 지표까지 쉽게 수집 가능
      • 프로메테우스 클라이언트 라이브러리를 사용하게 되면 바로 지표를 프로메테우스 서버로 전송 가능
      • Push gateway가 지표를 보관하고 있다가 프로메테우스 서버가 Pulling을 하면 저장된 지표 정보를 리턴
    • 서비스 디스커버리
      • 모니터링 대상 목록을 유지하고 있고 대상에 대한 IP나 기타 접속 정보를 설정 파일에 주면 그 정보를 기반으로 프로메테우스 서버가 모니터링 정보 수집
      • 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링 하는 형태
      • DNS나 Consul, etcd와 같은 다양한 서비스 디스커버리 서비스와 연동을 통해서 자동으로 모니터링 대상의 목록 수집 가능
    • 저장 및 시각화
      • 수집된 지표 정보들은 프로메테우스 내부의 시계열 데이터베이스에 저장
      • 프로메테우스 웹 콘솔을 이용하여 시각화 되거나 또는 API를 외부에 제공해서 Grafana와 같은 시각화 툴을 통해서 지표를 시각화
    • 알림 서비스
      • 부가 기능 중의 하나로 alerting 컴포넌트는 지표에 대한 규칙을 설정하고 규칙을 위반할 경우에는 알림을 보낼 수 있는 기능
      • 알림을 보내는 대상은 이메일이나 pagerduty와 같은 notification 서비스 등과 연동이 가능
    • 쿠버네티스 연동 아키텍처
      • 프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 서비스 디스커버리(Service discovery) 메카니즘이 필요
      • 쿠버네티스 API를 호출하고 자원들의 목록(Pod, Node, Service, Ingress, Endpoint 등)의 목록을 라벨 셀렉터(label selector)를 이용하여 수집
      • 수집된 모니터링 대상에 대해서 모니터링을 수행
      • 쿠버네티스는 apiServer에서 /metric이라는 URL을 통해서 기본적인 지표 정보를 리턴
      • 쿠버네티스 자원들에 대한 모니터링은 이 API를 통해서 수집

쿠버네티스 보안

  • 계정 인증
    • 인증(Authentication)
      • 쿠버네티스는 계정 체계를 관리함에 있어서 사람이 사용하는 사용자 어카운트와 시스템이 사용하는 서비스 어카운트 두 가지 개념을 제공
      • 일반적인 사용자
        • 일반적인 사용자는 우리가 일반적으로 생각하는 사용자 아이디의 개념
        • 쿠버네티스는 자체적으로 사용자 계정을 관리하고 이를 인증(Authenticate)하는 시스템이 없음
        • 반드시 별도의 외부 계정 시스템을 사용해야 하며 계정 시스템 연동을 위해서 OAuth나 구글 계정이나 오픈스택의 키스톤과 같은 계정 연동 방식을 지원
      • 서비스 어카운트
        • 쿠버네티스가 직접 관리하는 사용자 계정
        • 클라이언트가 쿠버네티스 API를 호출하거나 콘솔이나 기타 클라이언트가 쿠버네티스 API를 접근하고자 할 때 이는 실제 사용자가 아니라 시스템
      • 인증 방법
        • Basic HTTP Auth : HTTP 요청에 사용자 아이디와 비밀번호를 실어 보내서 인증하는 방식
        • Access token via HTTP Header : 일반적인 REST API 인증에 많이 사용되는 방식
        • Client cert : 클라이언트의 식별을 인증서을 이용해서 인증하는 방식
        • Custom made
    • 권한 관리 (Autorization)
      • 쿠버네티스의 권한 처리 체계는 기본적으로 역할기반의 권한 인가 체계
      • ABAC(Attribute-based access control)와 RBAC(Role-based access control) 2가지 방법 제공
      • ABAC
        • 단어의 의미 그대로 속성 기반의 권한 관리
        • 사용가능한 속성으로는 일반적으로 사용자, 그룹, 요청 경로, 요청 동사등 외에도 네임스페이스, 자원 등으로 설정
      • RBAC
        • 역할 기반권한 관리
        • 사용자와 역할을 별개로 선언한 다음에 그 2가지를 엮어서(binding)해서 사용자에게 권한을 부여
        • 서버에 접근할 필요없이 kubectl이나 api를 이용해서 관리하는 것이 가능
  • 네트워크 정책
    • Pod 그룹에 대해, 서로간 또는 외부 네트워크 엔드포인트와의 통신여부를 결정하는 정책
    • 네트워크 정책으로 Pod간 통신, 네임스페이스간 통신, 포트 번호 지정 등을 서술적으로 설정할 수 있음
    • NetworkPolicy 리소스들은 Pod들을 선택하고 선택된 Pod들에 허용되는 트래픽을 특정하는 규칙을 정의하기 위해 레이블을 사용함
    • 네트워크 정책들은 네트워크 프로바이더가 제공하는 네트워크 플러그인을 통해 실현됨
    • Ingress 트래픽 컨트롤 정의
      • ipBlock : CIDR IP 대역으로, 특정 IP 대역에서만 트래픽이 들어오도록 지정
      • podSelector : label을 이용하여, 특정 label을 가지고 있는 pod들에서 들어오는 트래픽만 수신 가능
      • namespaceSelector : 특정 namespace로 부터 들어오는 트래픽만 수신 가능
      • Protocol & Port : 받을 수 있는 프로토콜과 허용되는 포트를 정의
    • Engress 트래픽 컨트롤 정의
      • Engress 트래픽 컨트롤은 ipBlock과 Protocol & Port 두 가지만 지원
      • ipBlock : 트래픽이 나갈 수 있는 IP 대역을 정의
      • Protocol & port : 트래픽을 내보낼 수 있는 프로토콜과 포트를 정의
    • Using Cilium - Controlling Ingress/Engress from Namespaces
      • 네트워크 폴리시(NetworkPolicy)로 실리움(Cilium) 사용
      • image
    • 네트워킹 애드온
      • 쿠버네티스는 클러스터 내부에 가상네트워크를 구성해서 사용하는데, 이때 kube-proxy이외에 네트워킹 관련한 애드온을 사용
      • ACI, Calico, Canal, Cilium, CNI-Genie, Contiv, Flannel, Multus, NSX-T, Nuage, Romana, WeaveNet등이 있고, OCI의 CNI(Container Network, Interface)를 구현하고 있다면 다른 애드온들도 사용 가능
  • Security Context
    • 쿠버네티스의 Pod나 컨테이너에 대한 접근 제어 설정(Access COntrol Setting)이나 특수 권한(Privilege)를 설정하는 기능을 제공
    • Pod 또는 컨테이너의 권한부여, 환경설정 접근을 정의하는 securityContext 필드
    • Pod 또는 컨테이너 내의 securityContext 필드는 컨테이너 프로세스들이 사용하는 사용자(runAsUser)와 그룹(fsGroup), 가용량, 권한 설정, 보안 정책(SELinux/AppArmor/Seccomp)을 설정하기 위해 사용됨
    • 런타임 UID,GID를 포함함
  • Pod Security Policy
    • SecurityContext는 컨테이너나 Pod의 보안 기능을 정의
    • Pod Security Policy (이하 PSP)는 보안 기능에 대한 정책을 정의
    • Pod 생성,업데이트에 관한 세밀한 권한인증 제공
    • Pod 스펙에 대한 보안적 측면을 통제하는 클러스터-수준 리소스
    • PodSecurityPolicy 객체는, 관련 필드들에 대한 기본값들을 포함하여, Pod가 시스템 내로 받아들여지기 위해 구동될 때의 조건들 집합을 정의함
    • Pod 보안정책 통제는 선택적인 입장 승인 컨트롤러로서 구현됨

쿠버네티스 네트워킹

  • 쿠버네티스 클러스터 네트워크
    • 전체 클러스터를 위한 하나의 가상 네트워크
    • 각 파드에는 고유한 IP가 존재
    • 서비스는 파드와 다른 범위의 IP 대역을 가짐
    • 클러스터 CIDR : 클러스터 내 파드에 할당하는데 사용되는 IP 범위
    • 서비스 클러스터 IP 범위 : 서비스에 대한 IP 범위. 이것은 클러스터 CIDR와 중복 불가
    • 파드(Pod) CIDR : 특정 워커 노드 내 파드에 대한 IP 범위. 이 범위는 클러스터 CIDR 내에 있어야 하지만 다른 워커 노드의 파드 CIDR과 겹치면 안됨
  • 쿠버네티스 네트워킹
    • IP는 container가 아니라 pod에 할당됨
    • 컨테이너간 통신 : 커플드(Highly-coupled)된 컨테이너간 통신을 위해 pods와 로컬 호스트 통신으로 해결
    • Pod간 통신 : 클러스터 통신의 주 목적, k8s 네트워크 플러그인, service
    • Pod와 Service 통신 : 서비스에서 담당
    • 외부와 Service 통신 : 서비스에서 담당
    • Pod 내부의 container-to-container 통신 : 컨테이너 엔진(ex-docker)
    • 외부와 Pod의 통신 : service, ingress, egress
    • 클러스터 네트워킹 구성
      • 사용자의 Pod 접속 : 인터넷 사용자들의 클라이언트는 Pod에 직접 접속할 수 있고 Service를 설정해야 함
      • 서비스 정책 : Service는 kube-proxy에 의해 관리되고 여러 개의 iptables 규칙으로 설정
      • Service의 외부 연결 방법
        • NodePort
        • clusterIP
        • LoadBalancer
      • Kubernetes Worker Network
        • Kubernetes는 Pod 단위로 배포가 되며 하나의 Pod는 Overlay Network을 가짐
        • Pod는 하나 이상의 Container를 가지게 되지만 Pod에는 하나의 IP만 부여
      • Node간 Network Communication
        • 서로 다른 노드에 있는 Pod간 통신은 Proxy Container(Kube-proxy)를 통해서 구성
      • 외부와 Network Communication
        • 클라이언트가 외부에서 해당 서비스에 접근하기 위해서는 크게 NodePort와 LoadBalancer를 사용할 수 있음
        • NodePort는 해당 Worker 노드의 포트를 외부에 오픈해서 사용자가 직접 Worker 노드의 포트로 직접 접속하는 방식
        • LoadBalancer의 경우 서비스를 배포하고 나면 Extenal IP로 LoadBalancer로 셋팅
      • Ingress
        • 서비스와 pod는 클러스터 네트워크에 의해 라우팅이 가능한 IP들을 가짐
        • Ingress란 클러스터 서비스들에게 연결하기 위한 inbound connection을 허용하는 규칙들의 모음
        • 단순히 트래픽을 로드 밸런싱 해주는 것 이외에도 SSL< Virtual Host 등의 기능을 제공
        • ingress를 사용 시 NodePort로 서비스를 배포
      • overlay networ
        • 가상 네트워크 인터페이스와 bridge와 라우팅 rule의 조합을 overlay network
        • 쿠버네티스 네트워크에서는 overlay network를 이용하여 pod들이 서로 정보를 주고 받기 때문에 Pod 네트워크라고 함
  • CNI
    • 컨테이너 네트워크 인터페이스
      • CNCF 프로젝트 중 하나
      • 리눅스 컨테이너를 위한 네트워킹으로 런타임과 플러그인간의 상호 작용을 정의
      • 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준 API
    • Adopter(Plugins)
      • CoreOS Tecctonic - Enterprise Ready, Portable, Upstreram Kubernetes
      • rkt - container engine
      • Kurma - container runtime
      • Kubernetes - a system to simplify container operations
      • OpenShift - Red Hat's container platform
      • Cloud Foundry - a platform for cloud applicaitons
      • Apache Mesos - a distributed systems kernel
      • 3rd party plugins
        • Project Calico - a layer 3 virtual network
        • Weave - a multi-host Docker network
        • Cilium - BPF & XDP for containers
        • Romana - Layer 3 CNI plugin supporting network policy for Kubernetes
        • CNI Genie - generic CNI network plugin
        • flannel - a network fabric for containers, designed for Kubernetes