Kubernetes Basic (MSA에서 Kubernetes)

Cloud Computing


as a Service

각종 `디지털 재화가 네트워크를 통해서 사용 가능한 형태로 제공되는 서비스`이다. XaaS는 클라우드를 통해서 구현된다. 엄밀히 말해 클라우드 자체가 ''대용량 스토리자와 연산능력 등이 갖춰진 서버를 기반으로 클라이언트(사용자)에게 가상의 네트워크 컴퓨팅 환경을 제공한다.'는 개념인 만큼, 클라우드는 태생부터 'as a Service' 구현을 위해 만들어 졌다고 봐도 과언이 아니다.

과거엔 모든 프로그램을 PC에 직접 설치하는 방식으로 사용했다. 그러나 클라우드가 등장하면서부터 직접 설치 방식의 프로그램은 슬슬 구시대의 유물이 되어 가는 중이다. 클라우드 서비스를 이용할 때 사용자에게 필요한 건 네트워크에 접속하고 입력할 수 있는 하드웨어뿐이다. 그 외 필요한 것은 대부분 클라우드 서버를 통해 제공되고, 명령의 실행과 제어 같은 연산 작업도 모두 서버단에서 처리되기 때문에 사용자는 최종 결과값만 수신하면 되는 구조다.

각 단계를.. Camping에 비유를 해보자면..

• On-Premises(비박 캠핑) / Colocation(캠핑장-장소만) / Hosting(캠핑장-화장실,수도제공) / IasS(캠핑장-조리시설까지) / PasS(글램핑/펜션) / SasS(호텔/리조트)

• IaaS (Infrastructure as a Service)

• PaaS (Platform as a Service)

• SaaS (Service as a Service)

Why MSA

Monolithic, Market 그리고 Container

• 모놀리식(Monolithic) 방식의 한계

  • 코드 / 프로젝트가 커질수록, 영향도 및 전체 시스템 구조 파악의 어려움

  • 사소한 수정이 부른 대규모 QA

  • 연계 시스템의 변경 또는 장애에 대한 높은 의존성

• 시장 및 환경은 빠르게 변한다.

  • 빠르게 반응하는 고객의 피드백

  • 애플리케이션 서버 환경의 변화

  • 개발 패러다임의 변화

• Container

  • S/W 실행에 필요한 것을 패키지로 구성하여 표준화된 하나의 독립 컨테이너에 저장

  • VM과 달리 컨테이너는 전체 OS가 아닌 S/W 필요로 하는 라이브러리와 설정만 포함.

Micro Service Concept

2017, 8년도에 Gartner에서 MSA에 대한 Service 구분 / Component / API Technology / Service Mesh / Monitoring에 관련 잘 정리된 Image가 있어서 몇가지 소개 하도록 하겠다.


위의 이미지는 각 서비스의 Component별 서비스 제공자 또는 Program들 이며, 아래의 이미지는 각 서비스 Component별 서비스 구조를 도식화 해놓은 이미지 이다.


각 단계별 조금 더 살펴 보자면,

`External Gateway`는 외부에 서비스를 제공하기 위한 API및 사용자 인증 및 정책 제공하여 서비스를 보호 하며 종종 외부 API 관리 제품을 통해서 구현 됩니다.

`Service Mesh`파트는 Micro화된 서비스간의 연견을 위해서 각 서비스에 대한 Configuration을 통합해 관리 하고 서비스를 찾아 갈수 있도록 Discovery 기능 및 서비스에 대한 분배 라우팅 역할을 해야 합니다. MSA에서 Service Mesh 구성은 서비스의 연속성 및 확장성을 위해서 중요한 포인트 중에 하나입니다.

`Runtime Platform`은 각 서비스를 유지 및 관리 확장 하기 위해서 중간에 실제 자원의 할당에 대한 가교역할을 하며 Service Mesh 부분과 API로 통신하며 각 서비스에 대한 자원 유지 관리 역할을 담당합니다.

`Backing Service`들은 MSA의 특성상 신규 생성, 재생성, 서비스 인스턴스 삭제 등의 작업이 빈번하게 이뤄여야 하기 때문에 Message Queue를 활용한 비동기 통신을 많이 사용하게 됩니다. 비동기 방식으로 처리 되는 특성으로 인해서 Backing Service의 구성도 중요 합니다.

`Telemetry`는 기본적으로 컨테이너 환경에서는 Container 내부에 로그를 남기지 않으며 대부분 수십대 많게는 수백대의 컨테이너를 관리 하기 때문에 이에 대한 가시성을 확보 및 로그를 관리 하는 역할을 담당합니다.

`CI/CD Automation` 모든 환경은 컨테이너 이미지를 사용해서 배포하고 많은 수의 컨테이너를 생성해야 하기 때문에 자동화가 필요하며 이미지 빌드 및 저장 및 배포를 자동으로 구현한 부분입니다.


복잡하게 얽혀 있는 MSA 구조에서는 각 서비스 또는 고객의 접점에 대한 중계 방식이 하나의 중요한 포인트중 하나입니다. 각 서비스와 외부 사용자 관리자간의 통신 Inner 서비스간의 통신 이러한 모든 통신은 API를 통해서 상호 연결이 됩니다. 위의 이미지는 고객 / Inner / 서비스간의 통신 방식에 대한 도식도 입니다.


각 서비스에 대한 모니터링에 관련한 도식도 이며, MSA 환경에서 여러개의 컨테이너를 관리하기 위해서 무엇보다도 가시성 확보를 통한 시스템 이상 유무 확인 및 중앙 집중형 로그 분석 시스템이 필요 합니다. 이를 통해서 서비스의 이상 유무 및 비지니스 처리가 원활하게 이루어 지는지를 모니터링 해야 합니다.

MSA 장점과 단점

장점

• 모놀리식 방식의 경우 개발자는 모두 하나의 언어로 개발해야하지만, MSA에서는 각 서비스는 독립적이고 새로운 프로젝트이며 요구 사항에 맞게 언어를 선택해서 개발이 가능함.

• 개발자는 특정 서비스만을 집중해 개발하기 때문에 코드에 대한 전문성이 높아짐.

• 비 동기식 처리방식으로 인한 중앙 집중된 데이터 베이스의 의존도가 줄어듬.

단점

• 메시지 큐를 이용한 비동기식으로 동작하기 때문에 장애 추적이 어려움.

• 하나의 단일 고객 서비스를 운영하는 경우에도 많은 개별 서비스가 존재하며 비동기식으로 동작하기 때문에 장애추적이 어려우며 이를 관리하고 모니터링에 대한 어려움도 존재.

• 따라서 좋은 모니터링 시스템이 필요하며 이는 추가 비용이 발생함.

• 서비스별 작은 단위로 팀이 나눠져야 하기 때문에 여러팀과 인력이 필요함.

Docker Container

Docker Mission



어디서나 빌드해서 배포하기 쉽게하고 Docker Engine이 돌아가는 어느곳에서나 운영할수 있게 하며, 다양한 앱을 쉽게 돌릴수 있게 한다.


Container 관리

• Container Orchestration 이 왜 필요 한가?

  • Container가 몇개일 경우 관리가 가능한데 이게 몇십개 및 몇백개 이상의 Container가 될경우 관리하기 힘들다. 이 때문에 운영환경에서의 Container를 운영하고 관리 하기 쉽게 도와 주는 Orchestration Tool들이 필요하다.

    • 관련 서비스들이 정상적으로 동작하는가? 서비스의 관련 로그 확인이 가능한가? 등등..의 숙제를 Orchestration Tool들을 이용하여 손쉽게 해결이 가능하다. (단, Orchestration Tool에 대한 Study는 쉽다고 말하기는 힘들것 같다...)


Kubernetes란?

Kuernetes란?

**쿠버네티스**(Kubernetes, 쿠베르네티스, "K8s")는 컨테이너화된 애플리케이션의 자동 디플로이, 스케일링 등을 제공하는 관리시스템으로, [오픈 소스](https://ko.wikipedia.org/wiki/오픈_소스) 기반이다.[[4\]](https://ko.wikipedia.org/wiki/쿠버네티스#cite_note-4) 원래 [구글](https://ko.wikipedia.org/wiki/구글)에 의해 설계되었고 현재 [리눅스 재단](https://ko.wikipedia.org/wiki/리눅스_재단)에 의해 관리되고 있다. 목적은 여러 클러스터의 호스트 간에 애플리케이션 컨테이너의 배치, 스케일링, 운영을 자동화하기 위한 플랫폼을 제공하기 위함이다.[[3\]](https://ko.wikipedia.org/wiki/쿠버네티스#cite_note-:2-3) [도커](https://ko.wikipedia.org/wiki/도커_(소프트웨어))를 포함하여 일련의 컨테이너 도구들과 함께 동작한다.

Kubernetes는 현재 [CNCF(Cloud Native Computing Foundation)](https://www.cncf.io/)에 의해서 관리 되고 있다. 최초 2014년 중순에 Google에 의해서 처음 발표 되었다. Google의 Borg 프로젝트로 시작되었으며 Google 안에서의 코드명은 프로젝트 세븐이었으며, 이는 Borg StarTrack 캐릭터를 참조한 것이다. - [on Wikipedia.org]([https://ko.wikipedia.org/wiki/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4#cite_note-6](https://ko.wikipedia.org/wiki/쿠버네티스#cite_note-6))

Kubernetes는 2015년 7월 21일 최초 v1.0이 출시되었다. 1.0 버전 출시와 함께 Google은 [리눅스 재단](https://www.linuxfoundation.org/)과 파트너십을 맺고 CNCF를 설립하였고 Kubernetes를 시드 테크놀로지(seed technology)로 제공하였다. 현재 CNCF는 Kubernetes를 시작으로 Cloud의 오픈 소스 표준을 만들어 가고 있으며, 많은 오픈 소스 프로젝트들이 인큐베이팅되어서 발전되고 있다.

Borg?

Borg는 아래와 같은 특성을 가지고 있다.

`개개인의 자유 의지 없이 하나로써 완전한 동화를 추구하는 기계 종족으로 다른 종족의 기술과 생명체들을 흡수하여 더 강대해지고 발전하는 것이 기본적이자 궁극적인 목표다. 이들의 함선을 분석해보면 함선 전체가 곧 지휘부이며 동력원이고 생활공간이며 무기고이고 엔진실이다. 또한 100% 완벽한 에너지 효율을 자랑한다. 하지만 집합체의 통일성을 파괴하거나 특출한 기술이나 생물적 특성이 없는 종족은 기계화시키지 않는다고 한다.`

캐릭터 이름과 Kubernetes의 특성을 살펴보면 정말 작명을 잘했다는 느낌이 든다. 캐릭터에 대한 특징이 Kuberetes에서도 잘 나타난다. 예를 들어 Kubernetes의 경우 모든 기능들이 Pod에 Application 형태로 올라가서 동작하며 이를 완벽하게 동화 해서 엄청난 효율성을 발휘하게 한다. 즉 여러 앱들을 흡수해서 더 강대해지고 발전해 가는 Borg의 캐릭터와 너무나 흡사하다. (어찌 보면 현재 CNCF의 행보도 비슷하다)

CNCF Graduated, Incubating, Sandbox Project

CNCF에서는 크게 성숙도(Maturity)를 3가지로 나누어 프로젝트를 관리 하고 있다.

[CNCF Project](https://www.cncf.io/projects/)

`SANDBOX, INCUBATING, GRADUATED`


이 단계를 기준으로 기업에서 프로젝트를 진행시 선택의 기준으로 삼을수 있을것으로 보인다.

Graduated Level은 sandbox or incubating 상태를 졸업했다는 의미로 최소 2개 이상의 Committers 조직이 존재 하며, Security Audit 및 품질 결과가 게시된내용을 토대로 제 3자의 보안 감사를 해결했다는 의미 이다. 다시 말해 관련 문서 및 기반이 충실하며 여러 Committers 를 통해서 검증되었다는 의미이다.

졸업 기준에 대한 자세한 내용은 [CNCF의 졸업기준](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc)에 자세히 나와 있다.

현재 Kubernetes와 연동되고 있는 많은 Open Source들이 Graduated Level에 존재 하며, 대표적으로 Prometheus(Monitoring), Fluent(Logging), Helm(Package Management) 등이 있다. 현재 기본적으로 Kube-System에서 동작하는 CoreDNS 및 Containerd 등도 포함된다.

Kubernetes Version (with EKS)

[Kubernetes Version History](https://en.wikipedia.org/wiki/Kubernetes#Release_Versions)

Kubernetes의 버전은 굉장히 빠르게 변화하고 버전업 되고 있다. 최초 테스트를 위해서 구성을할때 1.17이 최신 버전이였고 EKS를 사용하고자 하였을때 EKS의 지원 최신버전은 1.14 였다(2020년 3월 초 기준). 현재는 1.19버전이 최신 버전이며, EKS에서는 1.17버전을 지원하고 있다. 버전업이 너무나 빨라서 안정적이지 않다고 생각할수도 있으나 이미 대용량 대규모의 서비스들을 많은 유수의 기업들에서 Kubernetes를 통해서 운영하고 있으며, 다르게 말하면 기능에 대한 빠른 반영이 되고 있어 더 강력해 지고 있다.

Kubernetes 특징

• Automatic Binpacking

  • 가용성에 대한 희생 없이, 리소스 사용과 제약 사양을 기준으로 자동으로 컨테이너를 스케쥴

    • e.g. resources:limits:cpu, resource:requests:cpu

• Self-healing

  • 자동으로 문제가 발생한 노드의 컨터이너를 대체(룰/정책에 따른 헬스 체크)

    • e.g. healthe check, envicted

• Scaling

  • CPU와 메모리 같은 리소스 사용에 따라 자동으로 애플리케이션을 확장. 경우에 따라서, 사용자 정의 측정 값을 기준으로 동적인 확장 가능

    • e.g. Cluster Autoscaling, HPA(Horizontal Pod Autoscaler), VPA(Vertical Pod Autoscaler)

• Service discovery and Load balancing

  • Container에 고유한 IP를 부여. 여러개의 Container를 묶어 단일 Service로 부여하는 경우 단일 DNS Name으로 접근하도록 로드 밸런싱을 제공

  • i.e. Service Object를 통한 외부 접근이 가능하며(e.g. NodePort, Loadbalacing etc..), 각 Pod에 대한 서비스 디스커버리를 가능.

• Automatic Rollouts and rollbacks

  • 다운타임 없이 애플리케이션의 새로운 버전 및 설정에 대한 롤아웃 / 롤백 가능

    • e.g. rolling update, canary update etc..

• Secret and configuration management

  • 애플리케이션의 secret과 configuration 정보를 이미지와 독립적으로 구분하여 별도의 이미지 재생성 없이 관리

    • e.g. Seccrets, ConfigMap

    • i.e. Password 정보 및 인증정보등 민감한 정보를 별도로 관리가 가능하며, 이미지의 변경 없이 Configuration 설정을 변경 및 수정 가능

• Storage orchestration

  • 소프트웨어 정의 저장장치(Software Defined Storage)를 기반으로 로컬, 외부 및 저장소 솔루션 등을 동일한 방법으로 컨테이너에 마운트 할 수 있음.

    • e.g. emptyDir, hostPath, PV, PVC

• Batch execution

  • CI 워크로드와 같은 Batch성 작업 지원 / Crontab 형식으로 스케쥴링도 가능

    • e.g) Job, Cronjob

Kubernetes Architecture


Kubernetes Master

API Server(=Kube-apiserver)

`The API server is a component of the Kubernetes [control plane](https://kubernetes.io/docs/reference/glossary/?all=true#term-control-plane) that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane.`

• Kubernetes Cluster와 상호 작용은 모두 Kubernetes API 서버와 통신하게 됩니다. e.g. kubectl 명령어로 호출시 모두 API 서버와 통신하여 상호 작용하게 됩니다.

Kube-scheduler

`Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on.`

• Worker Node에 있는 Pod를 스케쥴하며 새로운 Pod를 할당되지 않은 노드에 할당 하거나 실행할 위치를 지정하는 역할을 합니다.

Kube-controller-manager

`Control Plane component that runs controller processes.`

• Deployment나 Replication Controller등 관리등에 사용되며 Node / Relication / Endpoints / Service Account and Token Controller가 존재 합니다.

Cloud-controller-manager

`A Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that just interact with your cluster.`

• Cloud 인프라를 제공자와 상호작용하는 Controller이며, Node / Route / Service / Volume 관련 Controller가 존재 합니다. i.e. Cloud Provider의 인프라 사용에 대한 관련된 API와 주로 통신합니다.

Etcd

`Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.`

• 고 가용성 Key / Value에 저장소이며, Kubernetes Object에 대한 값을 저장합니다. 즉, Cluster에 구성된 노드들에 대한 구성정보를 저장합니다. Kubernetes 의 DB와 같습니다.

Kubernetes Worker Node

Kublet

`An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod.`

• 각 노드별 실행되는 Agent입니다. Pod안에 Container들을 실행되는 것을 직접적으로 관리하는 역할을 합니다.

Kube-Proxy

`kube-proxy is a network proxy that runs on each [node](https://kubernetes.io/docs/concepts/architecture/nodes/) in your cluster, implementing part of the Kubernetes Service concept.`

• Kubernetes는 Cluster 내부에 별도의 가상 Network를 설정하고 관리합니다. Kube-Proxy는 이러한 가상의 네트워크를 동작할 수 있게 하는 실질적인 역할을 하는 Process입니다.

Container-Runtime

`The container runtime is the software that is responsible for running containers.`

• Container-Runtime은 Container를 실행시키는 역할을 합니다. OCI(Open Container Initiative, https://www.opencontainers.org/)의 Runtime 규격(runtime-spec)을 구현하고 있는 Container Runtime이면 Kubernetes에서 사용할 수 있습니다.

AWS Elastic Kubernetes ServiceAWS EKS Architecture


AWS RBAC Authentication


Object

Objects

• Basic Object

  • POD

  • Service

  • Volume

  • Namespace

• Higher-level abstractions Object

  • Deployment

  • ReplicaSet

  • StatefulSet

  • DeamonSet

  • Job / Cronjob

POD

`The smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster.`

• Pod는 Kubernetes에서 Application을 실행하는 가장 작은 단위이며 Pod는 1개의 Container 또는 2개 이상의 Container로 구성 가능하다.

• 각각의 Pod는 고유한 IP가 할당되며 하나의 Pod내에서는 PID namespace, network 와 hostname을 공유 한다.

Service

`An abstract way to expose an application running on a set of Pods as a network service.`

• Network와 관련된 Object이며 Pod를 외부에 하나의 endpoint로 노출되는 Pod의 집합이다.

  • ClusterIP, NodePort, LoadBalancer, ExternalName

Service NodePort


Servce Ingress


AWS ALB Ingress


Configmap

`An API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.`

• Pod에 저장된 Container에 사용되는 환경 설정 값

Secret

`Stores sensitive information, such as passwords, OAuth tokens, and ssh keys.`

• 컨테이너에서 사용되는 소량의 민간한 정보 특수한 colume이 자동으로 연결되어 container에서 사용가능

• Base64로 Encoding 될 뿐 암호화 되지는 않음

• Volume으로 연결된 File 형식 또는 환경 변수 형식으로 사용 가능

• EKS에서는 KMS를 통한 암복호화 가능

Volume

`A directory containing data, accessible to the containers in a Pod.`

• 저장소와 관련된 Object입니다. Host Directory를 그대로 사용할 수도 있고 EBS 같은 Storage를 동적으로 생성하여 사용할 수도 있습니다.

Namespace & Label

`Namespace : An abstraction used by Kubernetes to support multiple virtual clusters on the same physical cluster.`

`Label : Tags objects with identifying attributes that are meaningful and relevant to users.`

• 하나의 Cluster를 논리적으로 구분하여 사용할 수 있습니다. 또한 라벨 기능을 적극적으로 사용하면 유연하면서 확장성 있게 리소스를 관리 할수 있습니다.

Higher-level abstractions Object

Deployment

`An API object that manages a replicated application, typically by running Pods with no local state.`

• Deployment는 새로운 버전의 Application을 다양한 전략으로 무중단 배포할 수 있습니다.

ReplicaSet

`A ReplicaSet (aims to) maintain a set of replica Pods running at any given time.`

• Pod를 여러 개(한 개 이상) 복제하여 관리하는 Object입니다. Pod를 생성하고 개수를 유지하려면 반드시 ReplicaSet을 사용해야 합니다.

  • e.g. 비동기 처리식 단일 시스템

StatefulSet

`Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods.`

• 실행 순서를 보장하고 호스트 이름과 볼륨을 일정하게 사용할 수 있어 순서나 데이터가 중요한 경우에 사용할 수 있다.

  • i.e. 라이선스가 포함된 시스템, Cluster 단위로 운영되야 하는 시스템(e.g. ElasticSearch)

DaemonSet

`Ensures a copy of a Pod is running across a set of nodes in a cluster.`

• Log나 Monitoring 등 모든 Node에 설치가 필요한 경우에 DeamonSet을 사용할수 있다.

  • e.g. FluentD or Bit, Logstash or Filebit

Job

`Job : A finite or batch task that runs to completion.`

`Cronjob : Manages a Job that runs on a periodic schedule.`

• 배치성 작업이나 예약 작업이 필요할 경우 Job과 Cronjob을 사용할 수 있다.

Storage

Type of Volumes

• https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes

emptyDir

Pod와 수명 주기를 같이하는 Volume

hostPath

Pod와 생명 주기를 같이하는 볼륨이나 Pod내의 Container간 Data 공유가 가능.


Persistent Volume Claim / PersistentVolume / DynamicallyProvisioningPersistentVolume


• Kubernetes Cluster 관리자에 의해 생성된 저장소의 일부

• Volume과 유사하지만 Pod와 독립적인 Life-Cycle을 가짐

• 사용자가 용량, 모드 등 필요한 정보와 함께 PVC(PersistentVolumeClaim)를 생성하면, 이에 대응하는 PersistentVolume가 연결(Persistent Volume) 또는 생성(Dynamically Provisioning Persistent Volume)됨.

PV access mode

• ReadWriteOnce - Read-Write 기능을 가진 Disk Mount를 하나의 Node에서만 가능

• ReadOnlyMany - Read Only 기능을 가진 Disk Mount를 여러 Node에서 가능

• ReadWriteMany - Read-Write 기능을 가진 Disk Mount를 여러 Node에서 가능