CloudFoundry & Kubernetes

본 문서는 클라우드 파운드리, 쿠버네티스에 대한 간단한 소개를 위한 자료이다. 하지만 Cloud Foundry와 Kubernetes 소개를 위해서 추가적으로 이해가 필요한 내용이 있으므로 최소한의 내용으로 기술 하였다. 본 자료에 사용한 이미지는 출처를 명시했고, 참고한 문서들에서 짧게 기술된 일부 개념은 예시 코드/이미지 등을 통하여 이해를 돕도록 작성 되었다.

CloudFoundry & Kubernetes

MSA

MSA(microservice architecture)는 애플리케이션을 느슨히 결합된 서비스들로 구조화 하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발방법론이다. MSA를 통해서 애플리케이션을 더 작은 단위의 서비스로 분해 할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게하며 장애에 더 탄력적으로 대응 할 수 있으며, 이런한 장점들로 인해 지속적인 통합(CI: Continuous Integration), 지속적인 배포(전달)(CD: Continuous Deployment or Delivery)를 달성 할 수 있다. Netflix, Amazon, eBay 등의 회사들이 자사의 monolithic 구조의 아키텍처를 microservice 구조의 아키텍처로 전환한 사례가 유명하다.

출처 https://ko.wikipedia.org/wiki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

BACK TO TOC

12-Factor

소프트웨어를 서비스 형태로 제공하는게 일반화 되면서, 웹앱 혹은 SaaS(Software As A Service)라고 부르게 되었다. 12-Factor 애플리케이션은 다음의 특징을 가지는 SaaS 애플리케이션을 만들기 위한 방법론이다

설정 자동화를 위한 절차를 체계화, 새로운 개발자가 프로젝트 참여하여 적응하는 비용(시간)을 최소화 한다.
OS에 따라 달라지는 부분을 명확히하고, 실행 환경 사이의 이식성을 극대화 할 수 있다.
여러 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요없게 된다.
개발과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하다.
툴, 아키텍처, 개발 방식을 크게 변경하지 않고 확장 할 수 있다.

출처 https://12factor.net/ko/

12-Factor Detail
- 코드베이스: 버전 관리되는 하나의 코드베이스와 다양한 배포
- 종속성: 명시적으로 선언되고 분리된 종속성 (예: 애플리케이션에 시스템의 도구가 필요한 경우가 있다면 시스템 도구를 애플리케이션 기준으로 통합)
- 설정: 환경(environment)에 저장된 설정
- 백엔드 서비스: 백엔드 서비스를 연결된 리소스로 취급
- 빌드, 릴리즈, 실행: 철저하게 분리된 빌드와 실행 단계
- 프로세스: 애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행
- 포트 바인딩: 포트 바인딩을 사용해서 서비스를 공개함(포트가 바인딩된 서비스는 다른 애플리케이션의 기준에서 백엔드 서비스가 된다는 의미, 위에 언급된 백엔드 서비스와 유사)
- 동시성(Concurrency): 프로세스 모델을 사용한 확장(scaling)
- 폐기 가능(Disposability): 빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화
- 개발 / 운영 환경의 일치: 개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지
- 로그: 로그를 이벤트 스트림으로 취급
- Admin 프로세스: admin / maintenance 작업을 일회성 프로세스로 실행

BACK TO TOC

Cloud Foundry

What is the Cloud Foundry

클라우드 파운드리(이하 CF)는 업계 표준의 오픈소스 플랫폼으로서 BOSH와 함께 자체 컴퓨팅 시스템, IaaS(AWS, vSphere, OpenStack 등) 기반 위에서 애플리케이션 소스만으로 배포가 가능하다. CF는 Pivotal사의 다른 오픈소스 도구인 BOSH와 상호작용 하므로 CF + BOSH 거의 1개의 플랫폼으로 봐도 무방하며, 전통적인(개발 및 운영에 필요한 대부분의 컴포넌트를 지원하는 형태) PaaS 플랫폼 이다.

전통적 방식, IaaS 기반, Cloud Foundry 기반의 시스템 컴포넌트 구성도 이미지

출처 https://docs.cloudfoundry.org/concepts/overview.html#industry-standard

Cloud Foundry Components

Cloud Foundry 컴포넌트 구성도 이미지

출처 https://docs.cloudfoundry.org/concepts/images/cf_architecture_block.png

Routing 외부에서 유입되는 요청을 CF 내부에 애플리케이션으로 전달하는 역할을 하는 컴포넌트로 GoRouter와 TCPRouter가 내부에 존재하여 요청의 프로토콜에 맞게 적절히 라우팅 한다.

최근 Cloud Native Seoul 2019 pivotal 발표자에 따르면 Istio & Envoy proxy를 적용하여 Service Mesh Architector 지원 할 수 있도록 릴리즈

Authentication Spring security로 구현된 OAuth2 & 로그인 서버로 클라우드 파운드리 내에서 식별 관리를 제공한다.
App Lifecycle
- Cloud Controller & Diego Brain Cloud Controller는 애플리케이션 배포를 지시하며 애플리케이션이 push 커맨드를 통해 요청되면 Cloud Controller는 Diego Brain을 CC-Bridge 요소를 통해서 지시하여 개별 Diego Cell을 조정하고 애플리케이션을 실행한다.
- nsync, BBS, and Cell Reps >출처 https://docs.cloudfoundry.org/concepts/architecture/#nsync-bbs nsync, BBS 및 Cell Rep은 체인을 따라 함께 작동하여 애플리케이션의 가동을 유지하는 역할을 한다.
- nsync : nsync는 사용자에 의해서 애플리케이션을 스케일시 Cloud Controller로부터 메시지를 받고 Diego BBS 데이터베이스 안에 DesiredLRP 구조에 인스턴스 갯수를 작성한다.
- BBS : BBS는 DesiredLRP과 ActualLRP 값을 모니터링 하기 위해 convergence 프로세스를 사용하고, ActualLRP와 DesiredLRP 갯수가 맞는지 검증하기 위해 애플리케이션 인스턴스들을 시작 혹은 종료 처리한다.
- Cell Rep : 컨테이너들을 모니터링하고 ActualLRP 값을 제공한다.
App Storage and Execution
- Blobstore
Blobstore는 대형 바이너리 파일로 구성된 repository 역할을 하며 애플리케이션 코드 패키지, Buildpacks, Droplets 포함한다. 또한 Blobstore를 내부에 다른 서버로 설정하거나 외부 S3 Endpoint로 설정이 가능하다.
- Diego Cell
애플리케이션 인스턴스, 애플리케이션 작업 그리고 배치중인 작업들은 모두 Garden 컨테이너로 실행된다. Diego cell rep 컴포넌트는 컨테이너 라이프 사이클, 컨테이너 내부에서 실행되는 프로세스들을 관리하며, 그 상태들을 Diego BBS에 레포팅하고 Loggregator에 로그 및 메트릭 정보 보낸다.
Services (Service Brokers)

애플리케이션은 일반적으로 DB 또는 타사 SaaS 공급자 같은 서비스들에 의존한다. 개발자가 서비스를 제공하고 애플리케이션에 바인딩 하면 서비스 브로커가 서비스 인스턴스를 제공하는 책임이 있다.

Messaging
- Internal HTTPS and BBS
Cloud Foundry 구성 요소 VM은 HTTP 및 HTTPS 프로토콜을 통해 내부적으로 서로 통신하여 Diego BBS에 저장된 임시 메시지와 데이터를 공유한다.

BOSH Director는 배포된 모든 VM에 BOSH DNS 서버를 배치합니다. 모든 VM은 동일한 토대에 있는 다른 모든 VM에 대한 최신 DNS 레코드를 유지하므로 VM 간의 서비스 검색이 가능합니다. 또한 BOSH DNS는 여러 VM을 사용할 수 있을때 무작위로 정상적인 VM을 선택하여 클라이언트 측 부하분산을 제공한다.

Diego의 BBS는 오래토록 처리되는 긴 분산 잠금 뿐만 아니라 cell 및 애플리케이션 상태, 할당되지 않은 작업, 생존신호 메시지 같은 데이터의 갱신 및 삭제 정보를 아주 빈번하게 저장한다. BBS는 Go MySQL Driver를 사용하여 MySQL에 데이터를 저장한다.

route-emitter는 NATS 프로토콜을 사용하여 최신 라우팅 테이블을 라우터에 브로드 캐스트 처리한다.
Metrics and Logging
- Loggregator: 애플리케이션 로그를 개발자에게 스트리밍 한다.
- Metrics Collector: 구성 요소에서 메트릭 및 통계 정보를 수집하고 운영자는 이 정보를 사용하여 Cloud Foundry 배포를 모니터링 한다.

Build pack

Buildpacks은 애플리케이션에 프레임워크 및 런타임을 지원하는 오픈소스이다. Buildpacks은 애플리케이션을 검사해서 다운로드 할 종속성과 기타 다른 서비스와 통신하도록 애플리케이션을 구성하는 방법을 결정하게 된다.

Cloud Foundry 컴포넌트 구성도 이미지

출처 Cloud Native Day 2019 SEOUL

애플리케이션을 CloudFoundry에 push 하면 Buildpacks은 다음과 같은 처리를 진행한다.
1. 애플리케이션에 Buildpacks을 적용할지 여부를 결정
2. 애플리케이션에 의존성 제공(Runnable OS image, JDK 등), 컴파일 처리
3. 애플리케이션을 Cloud Foundry 내부에서 실행 할 수 있는 Droplet으로 생성
4. Droplet을 Blobstore 저장후 Diego Cell이 Droplet을 내려받고 애플리케이션을 실행
Buildpack 사용시 이점
- 애플리케이션만 배포하면 애플리케이션이 구동하기 위한 나머지 의존성은 Buildpack이 처리 (Only $ cf push)
- 애플리케이션을 제외한 의존성 레이어의 간편한 교체
출처 https://buildpacks.io/docs/using-pack/update-app-rebase/

Deployed Apps in Cloud Foundry

클라우드 파운드리 환경에서 적용된 애플리케이션들은 다음과 같은 논리적 구성도 이미지와 같이 배치가 되고 동작한다.

Cloud Foundry 내부에 배포된 애플리케이션 이미지

출처 https://docs.cloudfoundry.org/concepts/security.html

BACK TO TOC

Kubernetes

What is the Kubernetes

쿠버네티스는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 플랫폼이다. 쿠버네티스는 컨테이너 중심의 관리 환경을 제공하는 플랫폼이며 다음과 같은 특징이 있다.

Service discovery and load balancing

Kubernetes는 DNS 이름 또는 자체 IP를 사용하여 컨테이너를 노출 할 수 있다. 컨테이너에 대한 트래픽이 많으면 Kubernetes는 네트워크 트래픽을 로드밸런싱 하며, 그래서 배포가 안정적으로 이루어지게 한다.

Storage orchestration

Kubernetes를 사용하면 로컬 스토리지, 공용 클라우드 공급자 등과 같이 원하는 스토리지를 자동 마운트 가능하다 (PersistentVolume, PersistentVolumeClaim, StorageClass, StatefulSet)

Automated rollouts and rollbacks

Kubernetes를 사용하여 배포된 컨테이너의 원하는(Desired) 상태를 기술 할 수 있으며 제어된 비율로 실제 상태를 원하는(Desired) 상태로 변경할 수 있습니다. 예를 들어 Kubernetes를 자동화하여 배포용 새 컨테이너를 만들고 기존 컨테이너를 제거하고 모든 리소스를 새 컨테이너에 적용 할 수 있다.

Automatic bin packing

Kubernetes는 각 컨테이너에 필요한 CPU, 메모리의 양을 지정 할 수 있고 컨테이너에 자원 요청이 지정되면 Kubernetes는 컨테이너에 대한 자원을 관리하기 위해 더 나은 결정을 내릴 수 있습니다.

Self-healing

Kubernetes는 실패한 컨테이너를 재시작하고 사용자-정의 상태 검사에 응답하지 않는 컨테이너를 제거하며 컨테이너가 서비스 제공을 위한 준비가 될 때까지 클라이언트에 통지하지 않는다.

Secret and configuration management

Kubernetes를 사용하면 암호, OAuth 토큰 및 ssh 키와 같은 중요한 보안 및 인증 정보를 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 보안 및 인증 정보를 노출하지 않고도 애플리케이션을 배포 및 업데이트 할 수 있다.

Kubernetes is not the traditional PaaS.

전통적 방식, 가상화 방식, 컨테이너 방식의 시스템 컴포넌트 구성도 이미지

출처 https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/#going-back-in-time

전통적인 방식(PaaS 관리하기 위한 각종 컴포넌트를 지원하는 형태)의 PaaS인 Cloud Foundry와는 다르게 Kubernetes는 전통적인 PaaS는 아니다. 쿠버네티스는 컨테이너 중심의 관리환경만을 제공한다는 의미이며 이로 인하여 Container PaaS 나 CaaS로 불리기도 한다.

쿠버네티스는 지원하는 애플리케이션의 유형을 제한하지 않는다.
쿠버네티스는 애플리케이션의 소스 코드에 관련한 빌드나 배포를 처리하지 않는다.
애플리케이션 레벨의 서비스(미들웨어, 데이터베이스, 캐시)를 제공하지 않는다.
관리자 편의를 위한 로깅, 모니터링, 알림 솔루션을 제공하지 않는다.
머신(Node) 레벨의 설정, 유지, 관리 등을 제공하지 않는다.

출처 https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/#what-kubernetes-is-not

Kubernetes components

마스터 컴포넌트

클러스터 관리를 위한 전반적인 결정을 하는 컴포넌트

kube-apiserver

쿠버네티스 API를 노출하는 프론트엔드이며 수평적 스케일 처리를 위해 설계되었다. 아래는 쿠버네티스 API 접근할 수 있는 kubectl CLI를 통해서 Pod 리소스를 조회하는 예시이다.
```
$ kubectl get pods/metrics-server-84bb785897-frst4 -n kube-system
NAME                              READY   STATUS    RESTARTS   AGE
metrics-server-84bb785897-frst4   1/1     Running   0          103s
```
etcd

모든 클러스터 데이터를 저장하는 저장소 역할을 한다.
kube-scheduler

새로 생성된 Pod 감지하고 Pod 구동되는 노드를 선택한다. 구동되는 노드를 지정 할 때 각종 조건을 판단하는 역할도 포함한다.
kube-controller-manager

Apiserver를 구동하며 노드 컨트롤러, 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 서비스 어카운트 & 토큰 컨트롤러들을 포함한다.
Cloud-Controller-Manager

클라우드 환경 (IaaS)을 제공하는 프로바이더와 상호 작용을 하는 컨트롤러이다.
노드 컴포넌트

노드에서 실행하는 Pod들을 유지하고, 쿠버네티스 런타임 환경을 제공한다. 노드 컴포넌트는 모든 노드에서 동작한다.

kubelet

클러스터 내에서 각 노드에서 실행되는 에이전트이고 Pod 안에서의 생성된 컨테이너 동작을 관리(컨테이너의 health check 위주의 처리)
kube-proxy

kube-proxy는 호스트에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로 쿠버네티스 서비스의 추상화가 가능토록 하는 역할을 한다. 아래는 동일한 쿠버네티스 네임스페이스 리소스 범위내에서 서비스를 하고 있는 elasticsearch-client 서비스에 9200 포트로 연결하는 설정의 일부분이다.
```
# ... 중략 ...
data:
  kibana.yml: |
    elasticsearch.hosts: http://elasticsearch-client:9200
# ... 중략 ...
```
Container Runtime

Container Runtime은 컨테이너의 동작을 관리하며(새로운 컨테이너의 기동 위주의 처리), 여기서 Runtime은 Docker, containerd, cri-o, rktlet, Kubernetes CRI를 구현한 런타임을 의미한다.
애드온

애드온은 클러스터 기능을 이행하는 Pod과 서비스다. Pod는 Deployment, Replication Controller 등에 의해서 관리된다. 애드온들은 kube-system 이름의 namespace를 가진 쿠버네티스 리소스이다.

DNS

모든 쿠버네티스 클러스터는 클러스터 DNS 환경을 가져야 하기 때문에 DNS 애드온은 기본 설치로 봐도 된다. 주로 CNCF 졸업 프로젝트인 CoreDNS가 설치된다.
Web UI(Dashboard)

쿠버네티스에서 제공하는 쿠버네티스 대시보드를 의미하며 사용자로 하여금 클러스터 및 애플리케이션들의 범용적 관리 기능을 제공하는 애플리케이션이다.

출처 https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/

컨테이너 리소스 모니터링(metrics server, cAdvisor)

컨테이너 리소스 모니터링은 중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.

metrics-server 애드온이 설치되면 다음과 같이 노드 혹은 Pod의 시계열 메트릭스 정보를 볼 수 있다.

$ kubectl top node
NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
minikube   135m         6%     721Mi           9%

$ kubectl top pod -n kube-system
NAME                               CPU(cores)   MEMORY(bytes)
coredns-5c98db65d4-8gk56           2m           7Mi
coredns-5c98db65d4-pcdhg           2m           7Mi
etcd-minikube                      17m          25Mi
kube-addon-manager-minikube        12m          2Mi
kube-apiserver-minikube            28m          198Mi
kube-controller-manager-minikube   11m          38Mi
kube-proxy-lns6s                   1m           9Mi
kube-scheduler-minikube            1m           10Mi
metrics-server-84bb785897-frst4    0m           9Mi
storage-provisioner                0m           17Mi

클러스터 레벨 로깅

클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다. 아래는 사이드카 패턴을 사용하여 컨테이너 로그가 스트리밍 되는 구조를 설명한 이미지이다.

출처 https://kubernetes.io/docs/concepts/cluster-administration/logging/#streaming-sidecar-container

Kubernetes Master nodes & Worker nodes 구성

Cloud Controller Manager 구성도 이미지

출처 https://kubernetes.io/docs/concepts/architecture/cloud-controller/

Deployment

Deployment는 Pod들과 ReplicaSet들 위한 선언적 업데이트를 제공하는 쿠버네티스 리소스이다. Deployment를 통해서 원하는 상태를 지정하고 쿠버네티스에 적용하면 Deployment 컨트롤러는 현재 상태를 원하는 상태로 변경하게 된다.

정의된 Deployment에 의해서 쿠버네티스 마스터가 Worker 노드에 스케줄한다.
Deployment 컨트롤러에 의해서 애플리케이션 인스턴스의 상태를 모니터링 한다.
애플리케이션이 배치된 노드에 문제가 발생하면 Deployment 컨트롤러가 해당 인스턴스를 다른 노드로 교체한다.(self-healing)
Deployment로 정의하는 Pod의 애플리케이션은 상태를 관리하지 않아야 한다.(Stateless)

StatefulSet

StatefulSet은 정의해 놓은(원하는) 상태를 관리하고 Pod들의 스케일링을 처리할 수 있으며, 관리하는 Pod들의 식별 및 순서 등을 보증하는 쿠버네티스 리소스이다.

안정적이고 고유한 네트워크 식별자, 스토리지를 관리 할 수 있다.
순서를 보장하는 Graceful 배포 및 확장과 롤링 업데이트를 할 수 있다.
StatefulSet을 통해서 배포되는 Pod들은 동일한 Spec으로 생성 되지만 각각의 Pod은 영구 식별자를 가지며 스케쥴이 다시 처리가 되어도 유지 관리가 된다.
Pod들이 교체되는 scaling 명령이 발생하면 Pod들은 영구적 스토리지, 네트워크 식별을 유지하고 순서데로 scaling 처리를 진행하게 된다.
Pod들은 StorageClass를 통해서 동적으로 PersistentVolume이 할당할 수 있다.
StatefulSet을 삭제 하거나, 확장(scaling) 하여도 이미 할당된 볼륨은 삭제가 되지 않는다.
StatefulSet을 삭제시 Pod의 삭제를 보장하지 않기 때문에 StatefulSet과 해당하는 Pod들을 Graceful 종료 및 삭제하기 위해서는 replicaset 갯수를 0으로 조정하고 이후에 StatefulSet을 삭제 한다.

DaemonSet

DaemonSet은 일부 혹은 모든 노드에서 Pod들이 실행하도록 보장하는 쿠버네티스 리소스이다. A-DaemonSet이 적용된 상태에서 쿠버네티스 클러스터에 워커 노드가 추가 혹은 삭제 된다면 DaemonSet 명세를 통해서 적용된 해당 노드의 Pod은 배치되거나 삭제가 된다. DaemonSet을 삭제하면 노드 각각에 배치된 Pod들은 삭제된다. DaemonSet은 일반적으로 다음의 목적과 특징이 있다.

DaemonSet은 스토리지 데몬(glusterd, ceph 등)처럼 사용할 목적
fluentd, logstash와 같은 모든 노드에서 로그를 수집할때 형태의 목적
모든 노드에 설치되어 노드를 모니터링 하기 위해서 메트릭 정보를 수집하는 형태의 목적
사이드카 패턴을 노드마다 적용하여 서비스를 제공하는 애플리케이션을 적용할 목적
노드별로 Pod이 만들어지는 유형의 리소스이기 때문에 api 명세에 replicas 속성이 없다.

Service

하나의 논리적인 Pod 세트와 그 Pod들을 접근 할 수 있는 정책을 정의하는 쿠버네티스 리소스이다. 서비스가 외부에서 유입되는 요청을 Pod들에게 전달시 일반적으로 LabelSelector를 통해 결정이 된다. 외부로 서비스를 하고자 하는 모든 Pod들은 쿠버네티스 서비스가 반드시 필요하다. 서비스는 다음의 4가지 유형으로 정의가 가능하다.

ClusterIP

클러스터 안에서 다른 애플리케이션들에게 서비스 하고자 할때 이용하는 방식이다. 이 방식은 오직 클러스터 내에서만 서비스가 접근된다.

NodePort

NAT가 이용되는 클러스터 내에서 해당 노드에 포트를 통해서 서비스가 노출이 된다. 노드IP:노드PORT 통해서 클래스터 외부에서 서비스를 접근할 수 있다.

LoadBalancer

클라우드 프로바이더(AWS, GCP, AZURE 등)에서 제공하는 로드밸런서를 이용해서 외부로 서비스 노출한다. 외부의 로드밸런서가 라우팅하는 NodePort 그리고 ClusterIP 서비스들이 자동으로 만들어진다.

ExternalName

이름으로 CNAME 레코드(service.bankwareglobal.io, oauth2.bankwareglobal.io 형태)를 반환함으로써 임의의 이름을 이용하여 서비스를 노출시켜준다.

Ingress

  internet
     |
[ Ingress ]
--|-----|--
[ Services ]

Ingress는 외부에서 쿠버네티스 클러스터 환경으로 HTTP(S) 요청시 진입점이 되는 쿠버네티스 리소스이다. Ingress는 요청을 받으면 쿠버네티스의 서비스로 받은 요청을 전달하게 된다. 쿠버네티스의 서비스 리소스와 비슷한 역할을 하지만 Ingress는 반드시 Ingress Controller가 필요하고 Ingress는 Kubernetes v1.1 부터 beta 상태의 리소스이다. 다음은 Ingress 설정 방식에 따른 유형이다.

Single Service

foo.bar.com -> 178.91.123.132 ->          service1:4200

URL Path

foo.bar.com -> 178.91.123.132 -> / foo    service1:4200
                                / bar    service2:8080

Virtual Host( HTTP Request Host Header )

foo.bar.com --|                 |-> foo.bar.com s1:80
            | 178.91.123.132  |
bar.foo.com --|                 |-> bar.foo.com s2:80

Ingress 리소스에 쿠버네티스 시크릿을 통해서 TLS 설정을 할 수 있다.

Ingress Controller List
- Ambassador API Gateway( BXM 클라우드 Easy Set-Up을 통해 설치 )
- AppsCode
- Contour
- Citrix
- F5
- Gloo
- HAProxy
- Istio
- Kong
- GLBC (Kubernetes support & maintain)
- NGINX (Kubernetes support & maintain)
- Traefik

ConfigMap

ConfigMap 리소스는 구성 파일, 명령줄 인수, 환경 변수, 포트 번호, 기타 구성 아티팩트를 런타임에 Pod의 컨테이너와 시스템 구성요소에 결합합니다. ConfigMap을 사용하면 Pod과 구성요소에서 구성을 분리할 수 있어 작업 부하를 이식 가능하게 유지하는 데 도움이 되고, 구성을 쉽게 변경하고 관리할 수 있으며, 구성 데이터를 Pod 사양에 하드코딩 방지합니다.

ConfigMap은 민감하지 않은 암호화되지 않은 구성 정보를 저장하고 공유하는 데 유용합니다. 클러스터에서 민감한 정보를 사용하려면 보안 비밀을 사용해야 합니다.

문자(Literal)

$ kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

파일

$ kubectl create configmap special-config --from-file special-config.txt

Pod with ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: special-config
namespace: default
resourceVersion: "651"
selfLink: /api/v1/namespaces/default/configmaps/special-config
uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
special.how: very
special.type: charm

Secret

쿠버네티스의 Secret 리소스는 클러스터 내부에 비밀번호, OAuth 토큰, SSH 키, 서버 인증서와 같은 민감한 데이터를 저장하기 위한 리소스이다. Secret을 사용하게 되면 승인되지 않은 사용자에게 민감한 정보가 노출될 위험을 줄일 수 있다.

yaml 사용해서 다음과 같이 Secret의 spec을 정의할 수 있다.

---
apiVersion: v1
kind: Secret
metadata:
  labels:
    app.kubernetes.io/name: order-secret
  name: order-secret
type: Opaque
data:
  # echo -n 'order' | base64
  username: b3JkZXI=
  # echo -n 'redro' | base64
  password: cmVkcm8=

위에서 정의한 Secret 리소스를 Deployment 리소스 spec에 적용한 예시이다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: order-service
  name: order-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: order-service
  template:
    metadata:
      labels:
        app.kubernetes.io/name: order-service
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: saga-pattern-order-service
          image: docker.io/smartkuk/order-service:latest
          args:
            - "--spring.profiles.active=postgresql"
          ports:
            - name: http
              containerPort: 8080
          env:
            # ... 중략 ...
            - name: "DB_USERNAME"
              valueFrom:
                secretKeyRef:
                  name: order-secret
                  key: username
            - name: "DB_PASSWORD"
              valueFrom:
                secretKeyRef:
                  name: order-secret
                  key: password

PersistentVolume

PersistentVolume은 쿠버네티스 클러스터 환경에서 영구적인 저장소를 이용하려고 할때 사용하는 쿠버네티스의 리소스이다. 이 PersistentVolume은 Pod과 함께 동작하는 리소스이지만 Pod이 삭제 처리가 되어도 PersistentVolume이 같이 삭제가 되지 않는다.

Reclaim policy

PersistentVolume을 생성시 다음과 같은 재요청에 대한 정책들을 정의할 수 있다.

Retain: 할당된 볼륨을 재요청시에도 삭제하지 않는 정책
Recycle: rm -rf /thevolume 명령과 같이 삭제하고 재활용 하는 정책
Delete: 재요청시 클라우드 프로바이더에서 제공하는 스토리지 제품에 대해서 삭제하는 정책

PersistentVolumeClaim

PersistentVolumeClaim은 PersistentVolume 리소스를 요청하기 위한 리소스이다. 즉 PersistentVolume의 크기, 액세스 유형, StorageClass 등을 요청할 수 있다. 쿠버네티스에서는 PersistentVolumeClaim 요청에 부합하는 PersistentVolume이 존재하거나, PersistentVolume을 프로비저닝 할 수 있다고 판단되면 PersistentVolumeClaim과 결합된다. 아래는 간단한 PersistentVolumeClaim 예시이다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: helloweb-disk
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi

StorageClass

다양한 클라우드 프로바이더(AWS, GCP, AZURE 등)에서는 쿠버네티스 볼륨을 동적으로 프로비저닝 하기위해 StorageClass를 구현하여 제공하고 있다. 이 StorageClass는 PersistentVolumeClaim spec에 추가시켜서 사용한다.

Volume Plugin	Internal Provisioner	Config Example
`AWS`ElasticBlockStore	✓	AWS EBS
`Azure`File	✓	Azure File
AzureDisk	✓	Azure Disk
CephFS	-	-
Cinder	✓	OpenStack Cinder
FC	-	-
Flexvolume	-	-
Flocker	✓	-
`GCE`PersistentDisk	✓	GCE PD
Glusterfs	✓	Glusterfs
iSCSI	-	-
Quobyte	✓	Quobyte
NFS	-	-
RBD	✓	Ceph RBD
VsphereVolume	✓	vSphere
PortworxVolume	✓	Portworx Volume
ScaleIO	✓	ScaleIO
StorageOS	✓	StorageOS
Local	-	Local

출처 https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner

Pods

Pod은 쿠버네티스에서 가장 많이 사용하게 되는 쿠버네티스 리소스이다. 아래에 Pod의 논리적 구성 이미지를 보면 Pod 내부에 1개의 IP, 복수의 볼륨, 복수의 컨테이너화 처리된 애플리케이션을 볼 수 있다.

쿠버네티스 Pod 구성 이미지

출처 https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/#pods-overview

Pod 리소스 특징
- Pod은 Self-healing 할 수 없다.(Deployment / StatefulSet / DaemonSet 컨트롤러 리소스를 통한 Pod 배포시 컨트롤러가 self-healing 처리를 관할)
- 각각의 Pod은 IP 주소가 할당된다.
- Pod 안에 컨테이너들은 네트워크를 공유한다.
- Pod은 공유 스토리지 볼륨을 지정할 수 있고, Pod 안에 모든 컨테이너는 공유 스토리지 볼륨에 접근할 수 있다.
- Pod은 서로 다른 목적의 컨테이너들을 정의하여 적용 할 수 있다.
- Cloud Foundry와는 다르게 애플리케이션을 Pod으로 적용하려면 애플리케이션을 Docker 이미지로 만들어 제공해야 한다.

Pods with Service

Pod을 외부에 노출하여 서비스 하기 위해서는 쿠버네티스의 서비스 리소스를 적용해야 한다. 쿠버네티스의 서비스는 위에서 언급한데로 ClusterIP, NodePort, LoadBalancer, ExternalName 4종류가 있다.

아래에 Node(육각형), Service(민트색 점선), Pod, Label들을 표현한 이미지를 보면 노드가 다른 분리된 영역에 배치된 Pod들을 서비스로 묶어서 표현이 되었는데, 즉 Pod들은 Node 상관없이 배치가 가능한 것을 알 수 있다.

그리고 Node에 상관없이 배치된 Pod들은 Service와 맵핑된다. 또한 서비스가 맵핑한 Pod들을 찾을때 레이블(Label) 정보를 이용한다.

쿠버네티스 Pod & Service 구성 이미지

출처 https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/#services-and-labels

Pods in Node

Worker node에 배치되는 Pod들은 필요하다면 다음과 같이 node 안에 있는 볼륨을 사용할 수 있게 설정도 가능하다.(예: Fluentd)

쿠버네티스 Node 내부의 Pod 구성 이미지

출처 https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/#node-overview

BACK TO TOC