오브젝트 기술하기
쿠버네티스에서 오브젝트를 생성할 때, 기본적인 정보와 더불어 의도한 상태를 기술한 오브젝트 spec를 제시해줘야 한다.
많이 사용되는 것은 .yaml 파일로 kubectl에 정보를 제공해준다. kubectl은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜준다.
요청 필드와 오브젝트 spac를 보여주는 .yaml 파일 예시
# application/deployment.yaml
apiVersion: apps/v1 # apps/v1beta2를 사용하는 1.9.0보다 더 이전의 버전용
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # 템플릿에 매칭되는 파드 2개를 구동하는 디플로이먼트임
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
.yaml 파일을 이용한 반영 예시
.yaml 파일을 kubectl apply 명령어를 이용해서 반영 할 수 있다.
$ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
deployment.apps/nginx-deployment created
필드들 설명
생성하고자 하는 쿠버네티스 오브젝트에 대한 .yaml 파일 내, 다음 필드를 위한 값들을 설정해 줘야한다.
- apiVersion - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
- kind - 어떤 종류의 오브젝트를 생성하고자 하는지
- metadata - 이름 문자열, UID, 그리고 선택적인 네임스페이스 를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
- spec - 오브젝트에 대해 어떤 상태를 의도하는지
오브젝트 spec에 대한 정확한 포맷은 모든 코버네티스 오브젝트마다 다르고 그 오브젝트 특유의 중첩된 필드를 포함한다.
Kubernetes API Reference 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
용어 설명(1)
- 노드(Node)
- 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신.
- 클러스터(Cluster)
- 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다.
- 에지 라우터(Edge router)
- 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다.
용어 설명(2)
- 클러스터 네트워크(Cluster network)
- 쿠버네티스 네트워킹 모델에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합.
- 서비스(Service)
- 레이블 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 서비스(Service). 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다.
파드(Pod)에 대하여
파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 Cluster에서의 동작하는 프로세스를 나타낸다.
파다는 애플리케이션 컨테이너, 저장소 리소스, 특정 네트워크 IP 그리고 container가 동작하기 위해 만들어진 옵션들을 캡술화한다.파드는 배포의 단위를 말한다.
도커는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다.
파드는 두가지 방법으로 사용된다.
- 단일 컨테이너만 동작하는 파드
- 함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드
어떻게 파드가 다중 컨테너를 관리하는가?
파드는 init containers 뿐만 아니라 app containers도 가진다.
파드는 같은 파드 안에 속한 컨테이너에게 두가지 공유 리소스를 제공한다.
- 네트워킹
- 유일한 IP주소를 할당 받음
- 파드 안의 컨테이너끼리는
localhost를 통해 통신 할수 있음 - 파드 안의 컨테이너와 파드 밖의 요소와 통신을 위해 네트워크 리소스 공유(PORT 등)
- 저장소
- 공유 저장 집합인 volumes 명시
-
컨테이너가 재시작 해야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다.
파드와 컨트롤러
파드는 스스로를 치료 하지 않는다. 만약 스케줄링된 노드애 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제 된다. 그와 비슷하게 리소스나 노드의 유지 부족으로 인해 제거 되는 상황에서 살아남지 못한다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 컨트롤러 라고 하는 고수준의 추상적 개념을 사용한다.
컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다.
한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시.
파드 템플릿
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh', '-c', 'echo 안녕하세요 쿠버네티스! && sleep 3600']
서비스(Servic)
kubernetes에서 서비스는 논리적 포트 세트와 액세스 할 수 있는 정책을 정의하는 추상화를 제공합니다. 서비스가 대상으로 하는 파드의 세트는 설정으로 결정됩니다.
예를 들어 TCP 포트 9376을 사용하는 파드 셋의 레이블이 app=Myapp 일때, my-service를 다음과 같이 설정 할 수 있습니다.
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
서비스 external 설정
- ClusterIP (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.
- NodePort - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다.
: 를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. CluserIP의 상위 집합이다. - LoadBalancer - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.
- ExternalName - 이름으로 CNAME 레코드를 반환함으로써 임의의 이름(스펙에서 externalName으로 명시)을 이용하여 서비스를 노출시켜준다. 프록시는 사용되지 않는다. 이 방식은 kube-dns 버전 1.7 이상에서 지원 가능하다.
서비스와 레이블
서비스는 파드 셋에 걸쳐서 트래픽을 라우트한다
서비스는 쿠버네티스의 객체들에 대해 논리 연산을 허용해주는 기본 그룹핑 단위인, 레이블과 셀렉터를 이용하여 파드 셋과 매치시킨다.
인그레스(Ingress)
클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함.
인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있다.
인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
internet
|
[ Ingress ]
--|-----|--
[ Services ]
인그레스 리소스
최소한의 인그레스 리소스 예제
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: test-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /testpath
backend:
serviceName: test
servicePort: 80
인그레스 유형들
- 단일 서비스
NAME HOSTS ADDRESS PORTS AGE
test-ingress * 107.178.254.228 80 59s
- 간단한 팬아웃(fanout)
foo.bar.com -> 178.91.123.132 -> / foo service1:4200
/ bar service2:8080
- 이름 기반의 가상 호스팅
foo.bar.com --| |-> foo.bar.com service1:80
| 178.91.123.132 |
bar.foo.com --| |-> bar.foo.com service2:80
인그레스 컨트롤러
인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다.
kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
프로젝트로써 쿠버네티스는 현재 GCE 와 nginx 컨트롤러를 지원하고 유지한다.