Kubernetes on Cloud Private

 

 

  • Cloud private 이란?

쿠버네티스(컨테이너 오케스트레이션 도구) 기반의 IaaS와 PaaS가 통합된 Private Cloud 플랫폼으로써 퍼블릭 클라우드 상에서 운영하기 어려운 클라우드 어플리케이션을 고객의 데이터센터에 설치해 생성, 운영 및 관리할 수 있도록 만들어진 플랫폼(새로운 버전의 Bluemix Local)입니다.

 

 
그림1. Cloud private 적용 대상 클라우드 모델

 

  • Cloud private 사용이 고려되는 환경
  • 컴플라이언스나 규제가 엄격하여 Public Cloud 환경에서 운영할 수 없는 워크로드
  • 마이크로 서비스 형태의 서비스 운영 고려 및 Bluemix PaaS 오퍼링과 연계한 서비스 고려시
  • 새로이 어플리케이션을 개발하기 위한 개발 환경이 필요할 시

 

  • Cloud private 차별점
  • 컨테이너화한 어플리케이션 및 데이터 서비스
  • 선택 옵션 제공: IaaS(Openstack, VMware) 및 CaaS(Docker, rkt, LXC/LXD)
  • 기존 툴들과 연계하기 위한 API 제공 및 오픈 스탠다드 지향
  • 하이브리드 클라우드 관리와 기 구성된 자동화 기능 제공
  • 엔터프라이즈 레벨의 통합된 클라우드 플랫폼, 미들웨어, 데이터 서비스 제공

 


그림2.IBM Cloud private Dashboard

 


그림 3. IBM Cloud private App Center


그림 4. Node Memory 사용량 및 Node 현황

 

  • Cloud private 활용 가능 분야

컨테이너 기반의 하이브리드 클라우드 구성, DevOps, 코그니티브 솔루션 활용

 

  • Cloud Private 설치시 포함 항목
  • Kubernetes 클러스터
  • 관리 콘솔
  • 인증 관리
  • LDAP 통합
  • 프라이빗 도커 이미지 저장소

 

  • Cloud Private 구성 스펙
    • Hardware
      • 싱글 노드 구성(최소): 2Core / 4GB RAM / 40GB Disk
      • 멀티 노드 구성(최소)
        • Boot node: 1Core / 4GB RAM / 40GB Disk
        • Master node: 2Core / 8GB RAM / 40GB Disk
        • Proxy node: 1Core / 4GB RAM / 40GB Disk
        • Worker node: 1Core / 4GB RAM / 40GB Disk
      • Network
        • Calico
          : OSI 7계층 중 3계층에 속하는 네트워크 솔루션으로 라우터, 스위치, IP를 포함함
          : 스케일 확장을 위한 BGP 프로토콜(border gateway protocol) 사용

: 리눅스 커널의 효율적인 IP 포워딩 엔진 사용
: 각 Tenant들을 격리함
: 방화벽 정책이 있을시 각 호스트에 해당 정책 적용

  • Logging & Monitoring
    • ElasticSearch: 공유, 복제, 탐색 가능한 json 문서 저장소
    • Logstash: 로그 기록 수신, 정제 및 전달하는 도구. Elasticsearch 내부에서 로그 인덱싱
    • Filebeat: 시스템 및 어플리케이션 로그기록 수집
    • Heapster: 컨테이너 클러스터 모니터링 및 퍼포먼스 분석. 컴퓨트 리소스, 수명 주기 이벤트 등 다양한 신호를 해석하고 이 클러스터 매트릭스를 REST 방식으로 송신.
      (Elasticsearch, InfuxDB, Kafka, Google Cloud Logging 등 지원)
  • Authentication
    • 오픈아이디(OpenID) Connect: OAuth 2.0 프로토콜 기반
    • LDAP과 연동하여 사용자 및 테넌트를 관리

 

  • Cloud Private 컴포넌트 특징 구성요소
    • Docker
      : Docker 엔진을 기반으로 컨테이너를 관리하는 소프트웨어
      : 하드웨어 인프라 자원을 가상화 하지 않고 프로세스 격리를 통한 자원 활용으로 가상화 구성 대비 높은 퍼포먼스가 가능
      : 계층화된 이미지 구성을 통해 변경사항에 대한 내용만 업데이트 하므로 불필요한 데이터 중복 제거 및 빠른 이미지 생성 가능

 

  • Kubernetes
    : 구글에 의해 만들어지고 현재 오픈소스로 공개된 프로젝트
    : 컨테이너를 관리하기 위한 클러스터를 관리하는 오케스트레이션 도구
    : 클러스터만 관리하기 때문에 어플리케이션을 배포하거나 소스코드를 가져오는 등의 과정은 고객이 직접 구성하거나 PaaS형태의 서비스를 이용해야 함

[구성 요소]

  • Pod: 하나 혹은 그 이상의 컨테이너들로 이루어진 그룹으로 Pod 단위로 함께 배포, 생성, 정지 및 복제됨. Pod 내 컨테이너들끼리는 네트워크 인터페이스를 공유함
  • Service(=Proxy): 여러 Pod을 대표하는 하나의 고정 IP를 가지며 라벨링 되어 있는 Pod를 참조 가능. 부하 분산 역할을 수행함
  • Volume: 컨테이너가 지속적인 저장소가 필요할 경우 볼륨을 할당해 사용하며 컨테이너가 살아 있는 동안에만 지속됨. Configmaps, Secrets, HostPath, ServiceAccount 등의 다양한 데이터가 볼륨으로써 마운트 될 수 있음
  • Deployment: 요구 되는 복제 수에 따라 배포 목적을 정의하고 이에 따라 Pod 생성 및 삭제를 수행함. 운영 중인 Pod들을 롤아웃 업데이트시 주의해야 함
  • StatefulSet: Pod가 순차적으로 생성 되었는지 혹은 안정적인 네트워크 신원을 가지고 있는지 등을 관리
  • DaemonSet: 하나의 pod에 클러스터 저장소 데몬, 로그 수집 데몬, 모니터링 데몬 등 필요한 데몬들이 잘 구성되어 있는지 관리
  • Job: 하나 혹은 그 이상의 기준에 명시된 수만큼의 pod을 생성 및 삭제하는 역할
  • Cron Job: 특정 시간 혹은 반복적으로 가동되도록 job들을 관리

 

IBM Cloud private architecture

그림5. IBM Cloud private Architecture

 

  • Cloud Private 구성 노드
    • Boot Node
      : 설치, 구성, 노드 확장 및 클러스터 롤링 업데이트에 필요한 노드.
      : Boot 노드 하나로 모든 클러스터 제어 가능하며 마스터 노드와 같이 사용할 수 있음[구성 요소] – Ansible 기반의 인스톨러 및 운영 매니저
      – Calico: Kubernetes 네트워크 및 정책 설정
      – Filebeat: 각 노드에서 동작하고 있는 시스템 요소 및 사용자의 컨테이너 어플리케이션 로그 기록을 수집

 

  • Master Node
    : 클러스터 내의 API 서버를 중심으로 Worker 노드 내 Pods, Service 관리 및 Replication control등의 역할 수행
    : 리소스 할당, 노드 상태 이상 여부 확인 및 모니터링 수행
    : 단일 장애점을 보완하기 위해 HA(High Availability) 구성이 필요함[구성 요소] – Authorized Manager: 사용자 관리를 위한 HTTP API를 제공. Keystone이 권한 관리에 사용됨
    – Keystone: 사용자 데이터베이스를 관리하는 신원 조회 서비스로 기존에 LDAP을 사용하고 있다면 연동 가능
    – Calico: Kubernetes 네트워크 및 정책 설정
    – Docker 레지스트리: Private Docker image 보관
    – Default backend: 인바운드로 들어오는 네트워크의 분산을 보조하는 역할
    – etcd: 서비스에 설정한 구성 정보를 저장하는 분산형 키-값 저장소
    – Filebeat: 각 노드에서 동작하고 있는 시스템 구성요소 및 사용자 컨테이너 어플리케이션의 로그 기록을 수집
    – Elasticsearch: 시스템과 어플리케이션 로그기록 및 매트릭스를 저장. 로그 기록을 전송하기 위한 API 제공
    – Heapster: 각 Worker 노드안에서 동작하고 있는 kubelet에 연결하여 노드와 컨테이너 매트릭스를 수집(매트릭스: CPU, memory, 네트워크 사용량)
    – Helm(Tiller): Kubernetes 패키지 관리
    – IBM Cloud private management console: Master 노드 ip를 통한 콘솔 UI 제공
    – Image manager: Docker 레지스트리에 푸시, 풀 및 제거와 이미지 라이브러리에 대한 권한 등의 기능을 관리
    – Kubelet: 클러스터 구성 요소들에 대한 총괄 관리
    – Kube-dns: Kubernetes: 어플리케이션의 서비스 디스커버리 역할(탐지)
    – Kubernetes apiserver: pods, services 및 replication controller관리를 위한 REST API 제공
    – Kubernetes control manager(=replication controller): Kubernetes 클러스터의 공유 상태를 모니터링해 상태를 관리하고 요구되는 서비스 기준에 맞게 현 상태를 유지하는 역할(Km api서버를 통해 관리)
    – Kubernetes proxy: Kubernetes 서비스로 향하는 트래픽이 적합한 pod에 향할 수 있도록(Round Robin) 역할 수행
    – Kubernetes scheduler: 스케쥴 정책에 따라 worker 노드에 pods 을 할당 수 있도록 kubectl 명령을 API 서버에 전송
    – Logstash: Filebeat가 수집한 로그 기록을 변형해 Elasticsearch에 전달
    – Maria DB: Keystone이 사용하는 DB
    – Rescheduler: 클러스터 내 pod 관리에 사용하며 운영중인 pod 위치를 재조정하거나 구성을 최적화 하는 역할을 수행
    – Router: 모든 시스템 요소 API를 위한 리버시 프록시 역할 수행 및 관리 콘솔 호스팅
    (리버스 프록시 예: 클라이언트가 com로 요청시 프록시가 zxc.com에서 데이터를 가져와 응답하는 즉 프록시가 중간에서 서버로부터 데이터를 가져와 클라이언트 요청에 응답하는 형태)
    – Ucarp: Master 노드의 VIP를 관리
    – Unified router: IBM Cloud private 관리 콘솔의 백엔드 기능 지원
  • Proxy Node
    : 외부 요청을 클러스터 내부의 서비스에 전달하는 역할을 수행
    : 부하분산(L4)이 필요할 경우 적어도 1개 이상의 Proxy 노드가 필요함
    : Master 노드와 같이 구성할 수 있지만 부하 분산을 위해 따로 구성하는 것이 권고 됨
    : 단일 장애점을 보완하기 위해 HA(High Availability) 구성이 필요함[구성 요소] – Calico: Kubernetes 네트워크 및 정책 설정
    – Filebeat: 각 노드에서 동작하고 있는 시스템 구성요소 및 사용자 컨테이너 어플리케이션의 로그 기록을 수집
    – kubelet: 클러스터 구성 요소들에 대한 총괄 관리
    – Kubernetes proxy: Kubernetes 서비스로 향하는 트래픽이 적합한 pod에 향할 수 있도록 역할 수행
    – Ucarp: Master 노드의 VIP를 관리
    – Ingress controller: Kubernetes의 Nodeport에 대한 부하분산 수행
  • Worker Node
    : 어플리케이션 혹은 프로세스에 격리된(컨테이너화 된) 환경을 제공하는 노드
    : 추가하는 노드 개수에는 제한이 없으나, 어플리케이션을 운영하기 위해 최소한 1개 이상의 노드 구성이 요구됨[구성 요소] – Calico: Kubernetes 네트워크 및 정책 설정
    – Filebeat: 각 노드에서 동작하고 있는 시스템 구성요소 및 사용자 컨테이너 어플리케이션의 로그 기록을 수집
    – kubelet: 클러스터 구성 요소들에 대한 총괄 관리
    – Kubernetes proxy: Kubernetes 서비스로 향하는 트래픽이 적합한 pod에 향할 수 있도록 역할 수행
    – cAdvisor: 컨테이너 자원을 모니터링하는 것으로 kubectl 명령에 따라 수집한 매트릭스를 Elasticsearch에 전달
    – Label: 환경(Production, Dev, Staging) 혹은 역할(Frontend, Backend, Worker)등 Pod에 대해 라벨링(이름)하는 것으로 복수 라벨링 가능

자주 묻는 질문

Q1.  IBM Cloud private 설치는 누가 담당하나요?
A: 고객이 설치, 구성, 관리 및 업데이트를 직접 진행해야 합니다. 하지만 Managed Service를 통해 지원을 받을 수 있습니다.

Q2.  UI는 기존의 Spectrum Conductor for Containers의 UI를 기반으로 하나요?
A: 현재는 CFC(Conductor for Containers)를 기반으로 UI를 구성하지만 점차 IBM Cloud 퍼블릭 UI와 비슷하게 구성할 예정입니다.

Q3. Syndicated 형식(로컬과 퍼블릭 서비스를 연결해 필요시마다 퍼블릭 서비스 이용)을 지원하나요?
A: 당장은 지원하지 않지만 기술적으로 가능합니다. IBM Bluemix Dedicated 서비스는 VPN으로 연결해 사용하실 수 있습니다.

Q4. Cloud-native 어플리케이션과 VM 기반의 기존 서비스와의 연결에는 문제가 없나요?
A: 마이크로서비스 어플리케이션에 기존 VM 위에서 운영중인 Oracle DB를 연결해 잘 운영한 사례가 있습니다.

Q5.  기존에 Bluemix Local의 Cloud Foundry와는 어떤 관계인가요?
A: 2017년 말에 Cloud Foundry를 추가 업데이트할 계획에 있습니다.

Q6. 기존 On-prem에 설치해 사용하던 UCD(Urban Code Deploy)와는 어떤 관계인가요?
A: IBM Cloud private는 자바 개발자를 대상으로 퍼블릭과 프라이빗 환경을 모두 지원합니다. 현재는 IBM Cloud private의 App Center에서 설치할 수 있는 Micro-services Builder를 Jenkins와 연결해 사용 가능하며 이전에 UCD를 이미 사용하고 계실 경우 연동해서 사용하실 수 있습니다.

Q7. Serverless 컴퓨팅인 OpenWhisk의 포지션은 어떻게 되나요?
A: 추가가 예정되어 있습니다.

Q8. 이미 가지고 있는 서비스를 추가해 IBM Cloud private 상에서 관리할 수 있나요?
A: 네. 서비스를 배포하기 위해 Helm 차트를 통해서 관리하시기를 추천드립니다.

Q9. IBM Container Services(Public)과 IBM Cloud private과 통신할 수 있나요?
A: 네. Public IP통신, VPN 통신, Direct 연결로 통신이 가능합니다.

Q10. 기존에 Bluemix Local을 사용중이라면 어떻게 마이그레이션 할 수 있나요?
A: Bluemix Local은 필요하다면 계속해서 지원할 예정입니다. 고객이 직접 마이그레이션 하거나 GTS와 같은 서포트 조직의 도움을 받을 수도 있습니다.

Q11. Bluemix Private Cloud(Blue Box)와 같은 건가요?
A: 아닙니다. Bluemix Private Cloud는 OpenStack 위에서 IaaS 기반(IBM Cloud 센터에서 운영)으로 운영됩니다. IBM Cloud private은 쿠버네티스 기반으로 고객의 인프라 위에서 운영됩니다.

 

  • 참고 URL
  1. IBM Cloud private documentation: https://www.ibm.com/support/knowledgecenter/SSBS6K_1.2.0
  2. Calico 구성하기: https://www.projectcalico.org/calico-networking-for-kubernetes/

 

토론 참가

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다