사용자 정의 객체
CustomResourceDefinitions
사용자 정의 객체를 만들기 위한 정의
연결된 컨트롤러도 함께 배포해야한다
➕ 쿠버네티스 1.7 이전 버전에서는 ThirdPartyResource를 통해 정의한다
- website-crd.yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: websites.extensions.example.com # CRD 이름
spec:
scope: Namespaced
group: extensions.example.com # API group
version: v1 # version
names:
kind: Website
singular: website
plural: websites- website.yaml
apiVersion: extensions.example.com/v1
kind: Website
metadata:
name: kubia # 웹사이트 리소스 이름
spec:
gitRepo: https://github.com/luksa/kubia-website-example.git- 생성
# CRD 생성
$ kubectl create -f website-crd.yaml
# Website 리소스 생성
$ kubectl create -f website.yaml
# 리소스 조회
$ kubectl get websites
NAME KIND
kubia Website.v1.extensions.example.com
# kubia 조회
$ kubectl get website kubia -o yaml
# 인스턴스 삭제
$ kubectl delete website kubia사용자 정의 컨트롤러
사용자 정의 객체를 동작시키려면 사용자 정의 컨트롤러도 필요
-
Website 컨트롤러
-
Website 컨트롤러가 하는 일
- proxy에 URL을 요청하여 객체 감시
- API 서버는 website 객체에 대한 모든 이벤트를 전송
- ADDED 이벤트(객체 생성) 수신 시, API 서버에 매니페스트를 올려서 deployment와 service 객체 생성
- deployment : 두 개의 컨테이너가 있는 pod로 구성 (nginx 웹서버 컨테이너 + git-sync 프로세스 실행 컨테이너 + emptyDir 디렉토리)
- service : 각 노드의 임의 포트를 사용하는 NodePort 서비스
- DELETED 이벤트(객체 삭제) 수신 시, deployment와 service 삭제
- 모든 객체 조회
-
pod로 컨트롤러 실행(컨트롤러 배포)
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: website-controller
spec:
replicas: 1
template:
metadata:
name: website-controller
labels:
app: website-controller
spec:
serviceAccountName: website-controller # 특수 서비스 어카운트로 실행
containers:
- name: main # 메인 컨테이너
image: luksa/website-controller
- name: proxy # 사이드카 컨테이너
image: luksa/kubectl-proxy:1.6.2# 서비스 어카운트 생성
$ kubectl create serviceaccount website-controller
# 클러스터롤 바인딩(cluster-admin)
$ kubectl create clusterrolebinding website-controller --clusterrole=cluster-admin --serviceaccount=default:website-controller
# 클러스터가 실행 중인 상태에서 website 재생성
$ kubectl create -f website.yaml
# 컨트롤러 로그
$ kubectl logs website-controller-2429717411-q43zs -c main
2017/02/26 16:54:41 website-controller started.
2017/02/26 16:54:47 Received watch event: ADDED: kubia: https://github.c...
2017/02/26 16:54:47 Creating services with name kubia-website in namespa...
2017/02/26 16:54:47 Response status: 201 Created
2017/02/26 16:54:47 Creating deployments with name kubia-website in name...
2017/02/26 16:54:47 Response status: 201 Created유효성 검사
사용자 지정 객체 생성 시에 유효성 검사가 필요하다
👉 API 서버에서 유효하지 않은 객체를 거부하는 CustomResourceValidation 기능을 사용
사용자 정의 API 서버
-
API 서버 AGGREGATION
쿠버네티스 1.7에서는 API 서버 애그리게이션을 통해서 custom API 서버를 메인 API 서버와 통합할 수 있다.
-
APIService 배포
사용자 지정 API 서버를 등록하기 위한 리소스
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
name: v1alpha1.extensions.example.com
spec:
group: extensions.example.com # API 그룹
version: v1alpha1 # API 버전
priority: 150
service: # 노출될 서비스
name: website-api
namespace: default- 사용자 정의 CLI 툴
객체 전용 명령어(ex: kubectl) 사용 가능
Service Catalog
쿠버네티스는 사용하기 쉬운 셀프 서비스 시스템을 지향한다. 서비스 카탈로그는 쿠버네티스에게 사용자가 "PostgreSQL DB가 필요해, 프로비저닝하고 어떻게 연결할지 알려줘"라고 했을 때 쿠버네티스가 처리해주는 방법
서비스 카탈로그란?
서비스 실행에 필요한 pod, service 같은 리소스를 처리할 필요 없이 서비스 브로커를 통해 직접 카탈로그를 탐색하고 카탈로그에 나열된 서비스 인스턴스를 프로비저닝할 수 있다.
- API 리소스
- ClusterServiceBroker
서비스를 프로비저닝할 수 있는 외부 시스템을 설명 - ClusterServiceClass
프로비저닝할 수 있는 서비스 유형을 설명 - ServiceInstance
프로비저닝된 서비스 인스턴스 중 하나 - ServiceBinding
클라이언트 집합(Pod)과 ServiceInstance 간의 바인딩을 나타냄
- API 리소스들의 관계
클러스터에서 서비스를 제공할 ClusterServiceBroker 생성
-> 쿠버네티스가 브로커에게 제공할 수 있는 서비스 목록을 요청하면 각각에 대한 ClusterServiceClass 생성
-> ServiceInstance와 ServiceBinding을 생성하여 ServiceInstance를 pod에 바인딩해서 서비스를 프로비저닝
-> ServiceInstance에 연결하는데 필요한 모든 자격증명 등을 포함하는 secret을 pod에 주입
서비스 카탈로그 구성요소
- 서비스 카탈로그 API 서버
- etcd 스토리지
- 컨트롤러 매니저 (컨트롤러 실행, 서비스 카탈로그 API 서버와 통신)
API 서버에 API 리소스들 생성 -> etcd/API 서버의 CustomResourceDefinitions에 저장 -> 컨트롤러 매니저가 리소스를 사용하는 컨트롤러를 실행
Service Broker, OpenServiceBroker API
클러스터 관리자는 서비스 카탈로그에 하나 이상의 외부 ServiceBroker를 등록할 수 있다. 모든 브로커는 OpenServiceBroker API를 구현해야 한다.
-
- 서비스 목록 검색(GET /v2/catalog)
- 서비스 인스턴스 프로비저닝(PUT /v2/service_instances/:id)
- 서비스 인스턴스 업데이트(PATCH /v2/service_instances/:id)
- 서비스 인스턴스 바인딩(PUT /v2/service_instances/:id/service_bindings/:binding_id)
- 서비스 인스턴스 바인딩 해제(DELETE /v2/service_instances/:id/service_bindings/:binding_id)
- 서비스 인스턴스 디프로비저닝(DELETE /v2/service_instances/:id)
-
서비스 카탈로그에 브로커 등록
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ClusterServiceBroker
metadata:
name: database-broker
spec:
url: http://database-osbapi.myorganization.org
# 서비스 카탈로그가 브로커에 연결할 수 있는 곳브로커가 프로비저닝할 수 있는 서비스 목록을 검색하고, 각 서비스에 대한 설명을 하는 ClusterServiceClass 생성
- 서비스 검색
# 클러스터에서 사용 가능한 서비스 검색
$ kubectl get clusterserviceclasses
NAME KIND
postgres-database ClusterServiceClass.v1alpha1.servicecatalog.k8s.io
mysql-database ServiceClass.v1alpha1.servicecatalog.k8s.io
mongodb-database ServiceClass.v1alpha1.servicecatalog.k8s.io
# 세부 정보
$ kubectl get serviceclass postgres-database -o yaml
apiVersion: servicecatalog.k8s.io/v1alpha1
bindable: true
brokerName: database-broker
description: A PostgreSQL database
kind: ClusterServiceClass
metadata:
name: postgres-database
...service 사용
- ServiceInstance 프로비저닝
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
metadata:
name: my-postgres-db
spec:
clusterServiceClassName: postgres-database # ServiceClass
clusterServicePlanName: free # free plan
parameters:
init-db-args: --data-checksums # 브로커에 전달될 추가 파라미터- postgreSQL database 인스턴스 동작 확인
$ kubectl get instance my-postgres-db -o yaml
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceInstance
...
status:
asyncOpInProgress: false
conditions:
- lastTransitionTime: 2017-05-17T13:57:22Z
message: The instance was provisioned successfully
reason: ProvisionedSuccessfully
status: "True"
type: Ready # 사용될 수 있음인스턴스는 어딘가에서 동작되고 있음
- ServiceInstance 바인딩
pod에서 사용하기 위해 바인딩을 해줘야 한다.
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: ServiceBinding
metadata:
name: my-postgres-db-binding
spec:
instanceRef:
name: my-postgres-db # 인스턴스 참조
secretName: postgres-secret # 시크릿의 자격증명 사용현재는 ServiceInstance의 자격증명을 pod에 넣어줄 수 없다. PodPreset이 사용가능할 때 가능할 것
-
pod에서 서비스 카탈로그가 생성한 secret 사용
프로비저닝된 서비스 인스턴스(postgreSQL database)에 연결할 수 있게 된다. -
바인딩 해제
# ServiceBinding 삭제
$ kubectl delete servicebinding my-postgres-db-binding- 디프로비저닝
# ServiceInstance 삭제
$ kubectl delete serviceinstance my-postgres-dbKubernetes 기반 플랫폼
쿠버네티스를 기반으로 구축한 PaaS 시스템
Red Hat OpenShift
쿠버네티스가 애플리케이션 스케일링을 자동화한다면, openShift는 클러스터에 지속적 통합 솔루션을 통합할 필요 없이 애플리케이션 이미지 빌드와 배포를 자동화한다.
-
OpenShift에서 사용가능한 추가 리소스
- Users & Groups
- Projects
- Templates
- BuildConfigs
- DeploymentConfigs
- ImageStreeams
- Routes
-
USERS, GROUPS, AND PROJECTS
OpenShift는 사용자에게 multi-tenant 환경, 강력한 유저 관리 기능을 제공 (RBAC 이전 버전)
각 사용자는 특정한 프로젝트에 액세스할 수 있고, 해당 프로젝트에 있는 리소스에 대해서만 작업 수행 가능 -
APPLICATION TEMPLATES
OpenShift는 매니페스트를 매개변수화할 수 있다. 그 목록을 템플릿이라고 함. 미리 제작된 템플릿을 제공
-
BUILDCONFIGS를 사용한 이미지 빌드
애플리케이션의 소스코드가 있는 Git 저장소를 가리켜서 변경 사항이 발생할 때마다 컨테이너 이미지 빌드를 트리거하도록 구성된 BuildConfig라는 리소스를 생성
새 커밋이 발생하면 Git 저장소에서 변경 사항을 가져와 빌드 프로세스를 시작한다.
컨테이너 이미지 빌드를 OpenShift가 알아서 -
DEPLOYMENTCONFIGS 이미지 자동 배포
이미지가 작성되면 imageStream에 추가됨. DeploymentConfig가 새로 빌드된 이미지를 확인해서 작업 수행
쿠버네티스의 디플로이먼트와 비슷하지만 사전에 배포되고 몇가지 추가 기능이 있다는 차이가 있다. -
ROUTES 외부로 서비스 노출
ingress와 유사 + TLS termination과 트래픽 분할 관련의 추가 구성 제공 -
OPENSHIFT 사용
minikube -> minishift
https://manage.openshift.com
Deis Workflow
Workflow를 실행하면 서비스와 레플리케이션컨트롤러가 생성되어 개발자에게 간단하고 친숙한 환경을 제공한다.
git push deis master로 변경 사항을 push하면 Workflow가 애플리케이션 배포 이외의 나머지 작업을 수행
source to image 매커니즘, 애플리케이션 롤아웃 롤백, 에지 라우팅, 로그 집계, 메트릭 및 알람을 제공
Helm
쿠버네티스의 패키지 관리자
-
구성요소
클러스터에서 애플리케이션 패키지를 배포하고 관리할 때 사용- helm CLI tool
서버 구성요소 Tiller : 차트에 정의된 쿠버네티스 리소스 생성❕deprecated
-
Chart
Helm 애플리케이션 패키지
직접 작성할 수도 있고 이미 존재하는 차트를 사용할 수도 있다. -
Helm 구조
