(책)쿠버네티스(Kubernetes)

leesj·2021년 9월 24일

Virtualization container orchestration docker kubernetes

kubernetes

목록 보기

4/8

도서 시작하세요!도커/쿠버네티스의 2부 쿠버네티스 요약

기타 쿠버네티스를 위해 필요하다고 생각되는 내용은 중간중간 추가 정리

쿠버네티스(Kubernetes)

현재 사실상 표준(de facto standar)으로 사용되고 있는 컨테이너 오케스트레이션 도구
구글에서 2014년에 오픈소스로 공개
도커 스웜 모드처럼 여러 대의 도커 호스트를 하나의 클러스터로 만들어 준다는 점이 같지만 세부적인 기능을 더욱 폭넓게 제공하기 때문에 운영 단계에서 쿠버네티스가 더욱 많이 쓰이고 있음

쿠버네티스 장점

1)서버 자원 클러스터링, 마이크로서비스 구조의 컨테이너 배포, 서비스 장애 복구 기능 지원
2)구글, 레드햇을 비롯한 많은 오픈소스 진영에서 쿠버네티스의 소스코드에 기여하고 있어 성능과 안정성 면에서 신뢰받고 있음
3)Persistent Volume, 스케줄링, 장애 복구, 오토 스케일링, 서비스 디스커버리 및 인그레스 등 컨테이너 기반의 클라우드 운영시 필요한 대부분의 기능과 컴포넌트를 사용자가 직접 커스터마이징
4)CNCF(Cloud Native Computing Foundation)및 다른 클라우드 운영 도구들과 쉽게 연동되어 높은 확장성

쿠버네티스 단점

1)다른 오케스트레이션 툴보다 훨씬 다양한 지식을 필요로 하며, 쿠버네티스 자체의 관리가 더욱 어려울 수도 있다.
2)도커 스웜보다 구조가 훨씬 더 복잡하고 사용 방법이 다양하기 때문에 쿠버네티스를 배우는 학습 비용 고려 필요
3)소규모 조직에서는 쿠버네티스의 기능을 배우고 관리하는것 자체가 오버 엔지니어링이 될 수도 있다.

쿠버네티스 배포판

(추후정리)

쿠버네티스 설치

5.1 쿠버네티스 설치 환경의 종류

개발 용도 쿠버네티스 설치: Minikube, Docker Desktop for Mac/Windows 에 내장된 쿠버네티스
서비스 테스트 또는 운영 용도 쿠버네티스 설치: kops, kubespray, kubeadm, EKS, GKE 등의 매니지도 서비스

쿠버네티스 사용 환경에 따른 3가지 유형 **

1) 자체 서버 환경(On-premise)에 쿠버네티스 설치
쿠버네티스를 포함한 모든 인프라를 직접 관리해야 함.
쿠버네티스 및 서버 인프라를 세밀한 뿐까지 설정해 원하는 대로 구성할 수 있다는 것이 장점. 모든 관리를 직접 도맡아 해야 하므로 운영 및 유지보수가 복잡해질 수 있는것이 단점.
자체 서버 환경에서는 kubespray, kubeadm 등의 도구를 이용해 쿠버네티스 설치 가능
2) 클라우드 플랫폼에서 쿠버네티스 설치
클라우드 플랫폼의 서버 인스턴스만을 사용해 쿠버네티스를 설치하는 경우를 의미ㅏㅎ며 서버, 네트워크 등 인프라에 대한 관리는 AWS, GCP 와 같은 클라우드 제공자에게 맡기되, 쿠버네티스의 설치 및 관리는 직접 수행.
kubesparay, kubeadm, kops 등의 설치 도구를 이용 가능.
3) 쿠버네티스 자체를 클라우드 서비스로서 사용
AWS 의 EKS, GKE 등의 매니지드 서비스를 이용해 쿠버네티스를 사용. 쿠버네티스의 설치 및 관리까지 클라우드 제공자가 담당하므로 쿠버네티스 관리 및 유지보수의 비용이 줄어줄게 됨.
EKS, GKE 와 같은 매니지도 서비스를 사용하면 별도로 쿠버네티스를 설치할 필요 없이 실제 서비스 환경을 구성할 수 있다는 장점이 있음. (클라우드 플랫폼 Lock in side effect 를 고려해야 함)

5.2 쿠버네티스 버전 선택

쿠버네티스의 기능이 매우 빠르게 업데잍 되기 때문에 사소한 버전 차이로 인해 쿠버네티스의 사용 방법이나 기능이 달라질 수 있음.
너무 최신 버전이거나 너무 예전 버전을 사용하지 않는 것이 좋음.

5.3 개발 용도의 쿠버네티스 설치

5.3.1 Docker desktop for Mac / Windows 에서 쿠버네티스 사용

Docker Desktop for Mac 을 이용해 도커 트레이 아이콘에서 Preferences > Kubernetes > Enable kubernetes 체크 박스 체크를 통해 간단힌 설치 가능

5.3.2 Minikube 로 쿠버네티스 설치

Minikube 는 로컬에서 가상 머신이나 도커 엔진을 통해 쿠버네티스를 사용할 수 있는 환경을 제공함.
실제 운영 환경에서는 Minikube 를 적용하기 힘들뿐더러 쿠버네티스의 몇몇 기능을 사용할 수 없어 설치 과정은 별도 정리하지 않음

5.4 여러 서버로 구성된 쿠버네티스 클러스터 설치

5.4.1 kubeadm 으로 쿠버네티스 설치

https://velog.io/@leesjpr/Kubernetes-InstallOn-premise

5.4.2 kops 로 AWS에서 쿠버네티스 설치

kops 는 클라우드 플랫폼(AWS, GCP)에서 설치를 지원
책은 AWS 에서 kops 를 사용하는 방법을 설명하기 때문에 별도 정리하지 않음

5.4.3 구글 클라우드 플랫폼의 GKE로 쿠버네티스 사용하기

별도 블로그 글로 정리

6.1 쿠버네티스를 시작하기 전에

쿠버네티스의 특징
1) 모든 리소스는 오브젝트 형태로 관리된다.
ex) 컨테이너의 집합(pods), 컨테이너의 집합을 관리하는 컨트롤러(Replica Set), 사용자(Service Account), 노드(Node) 까지 하나의 오브젝트로 사용할 수 있다.

// 오브젝트 리스트 보기
$ kubectl api-resources
// 특정 오브젝트의 설명
$ kubectl explain pod

2) 쿠버네티스는 명령어로도 사용할 수 있지만, YAML 파일을 더 많이 사용한다.
3) 쿠버네티스는 여러 개의 컴포넌틀 구성돼 있다.

쿠버네티스는 크게 마스터와 워커로 나뉘어 있다.
마스터 노드는 쿠버네티스가 제대로 동작할 수 있게 클러스터를 관리하는 역할을 담당
워커 노드에는 애플리케이션 컨테이너가 생성된다.
클러스터 구성을 위해 kubelet 이라는 에이전트가 모든 노드에서 실행된다.
kubelet 은 컨테이너의 생성, 삭제뿐만 아니라 마스터와 워커 노드 간의 통신 역할을 함께 담당하는 에이전트

6.2 포드(Pod): 컨테이너를 다루는 기본 단위

6.2.1 포드 사용하기

쿠버네티스에서 컨테이너 애플리케이션의 기본 단위이며 1개 이상의 컨테이너로 구성된 컨테이너의 집합
예를 들어 Nginx 웹 서비스를 쿠버네티스에서 생성하려면 가장 간단하게는 포드 1개에 Nnginx 컨테이너 1개만을 포함해서 생성한다.
포드를 생성하기 위해 사용되는 yaml 파일의 네가지 구성요소
1) apiVersion: YAML 파일에서 정의한 오브젝트의 API 버전
2) kind: 기술한 리소스의 종류(pod 인 경우 "Pod")
3) metadata: 라벨, 이름 등과 같은 리소스의 부가 정보 입력
4) spec: 리소스를 생성하기 위한 자세한 정보, containers, image, port 등을 입력
작성된 yml 파일의 적용

$ kubectl apply -f [YAML_FILE_NAME]

object 목록 확인

$ kubectl get [OBJ_NAME]
$ kubectl get pods

리소스에 대한 자세한 정보 확인

$ kubectl describe pods [POD_NAME]

쿠버네티스의 pod 컨테이너 내부 접근

$ kubectl exec -it [POD_NAME] bash
// -c 옵션을 통해 특정 컨테이너 지정 가능
$ kubectl exec -it [POD_NAME] -c [CONTAINER_NAME] bash

pod 로그 확인

$ kubectl logs [POD_NAME]

object 삭제

$ kubectl delete -f [YAML_FILE_NAME]
or
$ kubectl delete pod [POD_NAME]

6.2.2 포드 vs. 도커 컨테이너

쿠버네티스가 포드를 사용하는 이유 중 하나는 여러 리눅스 네임스페이스를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위해서이다.

일례로 특정 포드 내의 사이드카 컨테이너에서 localhost 로 다른 컨테이너에 접근 가능하다. 이는 포드 내의 컨테이너들이 네트워크 네임스페이스 등과 같은 리눅스 네임스페이스를 공유해 사용하기 때문이다.

네임스페이스는 컨테이너의 고유한 네트워크 환경을 제공해주는 역할을 담당한다.
쿠버네티스의 포드는 도커에서 컨테이너 네트워크 타입을 통해 네트워크 네임스페이스를 컨테이너 간에 공유해 사용할 수 있도록 설정하여 여러 개의 컨테이너가 동일한 네트워크 환경을 갖는 네임스페이스 공유 개념을 사용한다.

6.2.3 완전한 애플리케이션으로서의 포드

하나의 포드는 하나의 완전 애플리케이션이다.
사이드카(sidecar) 컨테이너: 포드에 정의된 부가적인 컨테이너
포드에 포함된 컨테이너들은 모두 같은 워커 노드에서 함께 실행됨

6.3 레플리카셋(Replica Set): 일정 개수의 포드를 유지하는 컨트롤러

6.3.1 레플리카셋을 사용하는 이유

마이크로 서비스에서는 여러 개의 동일한 컨테이너를 생성한 뒤 외부 요청이 각 컨테이너에 분배 될 수 있어야 한다.
쿠버네티에서는 기본 단위가 포드이기 때문에 여러개의 포드를 생성해 외부 요청을 각 포드에 분배 하는 방식을 사용해야 한다.
그러나 만약 YAML 파일에 정의해 여러개의 포들르 생성한다면 다수의 포드중 특정 포드가 포함된 노드가 비정상 종료 될 경우 포드가 다른 노드에서 다시 생성되지 않으며 종료된 채로 남아 있는다
이러한 한계점을 극복하기 위해 레플리카셋이라는 오브젝트를 사용한다.
1) 레플리카셋은 정해진 수의 동일한 포드가 항상 실행되도록 관리한다.
2) 노드 장애 등의 이유로 폳르르 사용할 수 없다면 다른 노드에서 포드를 다시 생성한다.

레플리카셋은 사용자 대신 포들르 관리해준다...

6.3.2 레플리카셋 사용하기

레플리카셋을 정의한 YAML 파일 에시

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: [REPLICASET_NAME]
spec:
  replicas: 3
  selector:
    matchLabels:
      app: [app_NAME]
  template:
  .
  .
  .

replicas: 생성할 포드의 갯수
template: 포드를 생성할 때 사용할 템플릿 정의
레플리카셋 생성

$ kubectl apply -f [YAML_FILE_NAME]

최초 설정된 포드의 갯수를 늘리는 등의 작업을 진행 한 후 기존에 생성된 리플리카셋을 삭제하거나 할 필요 없이 kubectl apply -f 명령어로 yaml 파일을 쿠버네티스에 적용한다.
레플리카셋 삭제

$ kubectl delete rs replicaset-nginx

6.3.3 레플리카셋의 동작 원리

레플리카셋은 포드와 느슨한 연결을 유지하고 있으며 이러한 연결은 레플리카셋 정의 중 label selector 를 이용해 이뤄진다.

레플리카셋은 라벨 셀렉터의 라벨을 가지는 포드를 replicas 개수만큼 생성한다.

즉 spec.selector.matchLabels.app 항목의 라벨과 일치하는 template.labels.app 이 spec.replicas 의 갯수만큼 작성되어야 한다.
만약 숫자만큼 작성되지 않으면 포드를 정의하는 포드 템플릿 항목의 내용으로 포드를 생성한다.

레플리카셋은 포드를 생성하는 것이 아닌 일정 개수의 포드를 유지하는 것이다.
포드가 설정된 갯수보다 적은면 더 생성, 설정도니 갯수보다 많으면 포들르 삭제한다.

레플리케이션 컨트롤러

레플리케이션 컨트롤러는 이전 버전의 쿠버네티스에서 사용됨. (deprecated)

6.4. 디플로이먼트(Deployment): 레플리카셋, 포드의 배포 관리

6.4.1 디플로이먼트 사용하기

실제 쿠버네티스 운영 환경에서 레플리카셋을 YAML 파일에서 사용하는 경우는 거의 없다. 대부분 레플리카셋과 포드의 정보를 정의하는 Deployment 라는 이름의 오브젝트를 YAML 파일에 정의하여 사용한다.

Deployment 는 레플리카셋의 상위 오브젝트
Deployment 를 생성하면 해당 디플로이먼트에 대응하는 레플리카셋도 함께 생성된다.
Deployment 를 삭제하면 레플리카셋과 포드 또한 삭제된다.

Deployment 목록 출력

$ kubectl get deployment

6.4.2 Deployment 를 사용하는 이유

애플리케이션의 업데이트와 배포를 더욱 편하게 만들기 위함.
리비전을 남겨 롤백을 가능하게 해주고, 무중단 서비스를 위해 포드의 롤링 업데이트 전략을 지정

컨테이너 애플리케이션의 버전 업데이트로 인한 포드의 이미지 변경시

$ kubectl set image
$ kubeclt set image deployment [DEPLOYMENT_NAME] [CONTAINER_NAME]=[CONTAINER_VERSION] --record

위와 같이 진행 하거나 kubectl edit 명령어를 사용
혹은 YAML 파일을 직접 수정해 image 항목을 [CONTAINER_NAME]:[CONTAINER_VERSION] 으로 변경한 다음 kubectl apply -f 명령어로 적용

위와 같은 작업 진행시 레플리카셋의 목록을 출력해보면 2개의 레플리카셋이 있으며, DESIRED, CURRENT 등의 항목이 3으로 표시된 레플리카셋이 신규로 생성된 레플리카셋을 의미함
디플로이먼트는 포드의 정보 변경으로 업데이트 발생 시 이전의 정보를 리비전으로 보존하며 이러한 리비전 정보는 아래와 같이 자세히 볼 수 있음

$ kubectl rollout history deployment my-nginx-deployment

이전 레플리카셋으로 되돌리는 롤백

$ kubectl rollout undo deployment my-nginx-deployment --to-revision=1

리소스 정리

$ kubectl delete deployment,pod,rs --all

6.5 서비스 포드를 연결하고 외부에 노출

여러 개의 디플로이먼트를 하나의 완벽한 애플리케이션으로 연동하기 위해 포드 IP 가 아닌, 서로를 발견 할 수 있는 방법이 필요함.
서비스라고 부르는 별도의 쿠버네티스 오브젝트 생성을 통해 진행

서비스: 포드에 접근하기 위한 규칙을 정의
서비스의 핵심 기능
1) 여러 개의 포드에 쉽게 접근할 수 있도록 고유한 도메인 이름을 부여.
2) 여러 개의 포드에 접근할 때, 요청을 분산하는 로드 밸런서 기능 수행.
3) 클라우드 플랫폼의 로드 밸런서, 클러스터 노드의 포트 등을 통해 포드를 외부로 노출.

6.5.1 Service 의 종류

포드의 IP 확인

$ kubectl get pods -o wide

쿠버네티스의 서비스는 포드에 어떻게 접근할 것이냐에 따라 종류가 여러개로 세분화 돼 있기 때문에 목적에 맞는 적절한 서비스의 종류를 선택해야 한다.

주요 서비스 타입
1) ClusterIP: 쿠버네티스 내부에서만 포드들에 접근할 때 사용. 외부로 포드를 노출하지 않음
2) NodePort: 포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 동일하게 개방. ClusterIP 의 기능을 포함하고 있기 때문에 내부 IP와 DNS 이름을 사용해 접근할 수 있다. 실제 운영 환경에서 NodePort 로 서비스를 외부에 제공하는 경우는 많지 않음.
3) LoadBalancer: 클라우드 플랫폼에서 제공하는 로드 밸런서를 동적으로 프로비저닝해 포드에 연결. NodePort 타입과 마찬가지고 외부에서 포드에 접근할 수 있는 서비스 타입
(일반적으로 AWS, GCP 등과 같은 클라우드 플랫폼 환경에서만 사용 가능)

7 쿠버네티스 리소스의 관리와 설정

효율적으로 애플리케이션을 관리하기 위해 자주 Namespace, configMap, Secret 이 주로 사용된다.

7.1 네임스페이스(Namespace)

리소스를 논리적으로 구분하는 장벽
쿠버네티스는 리소스를 논리적으로 구분하기 위해 네임스페이스라는 오브젝트를 제공.
네임스페이스는 포드, 레플리카셋, 디플로이먼트, 서비스 등과 같은 쿠버네티스 리소스들이 묶여 있는 하나의 가상 공간 또는 그룹(조직별 역할별로 네임스페이스 설정해 사용가능)
네임스페이스 확인

$ kubectl get namespaces(ns)
// 모든 네임스페이스의 리소스를 확인
# kubectl get --all-namespaces

네임스페이스 생성

$ kubectl create namespace [NAMESPACE_NAME]

특정 네임스페이스를 대상으로 포드를 확인하려면 다음과 같이 옵션을 주어 실행

$ kubectl get pods --namespace default

네임스페이스 삭제

# kubectl delete namespace production

별도로 네임스페이스를 생성하지 않았더라도 기본적으로 3개의 네임스페이스가 존재한다.
default, kube-public, kube-system
default 는 쿠버테니스를 설치하면 자도응로 설정되는 네임스페이스로, kubectl 명령어로 쿠버네티스 리소스를 사용할 때는 기본적으로 default 네임스페이스를 사용하게 된다.
네임스페이스 활용
1) 클러스터를 여러명이 동시에 사용해야 하는 경우 사용자마다 네임스페이스를 별도로 생성
2) 용도에 따라 네임스페이스를 여러 개 만들어 특정 목적의 디플로이먼트, 서비스를 운영

모니터링, 로드 밸런싱 인그레스 등의 특정 목적을 위한 용도로 별도 네임스페이스를 생성하여 사용 경우가 많음.

네임스페이스에 종속되지 않는 오브젝트
포드, 서비스, 레플리카셋, 디플로이먼트와 같이 네임스페이스 단위로 구분할 수 있는 오브젝는 '오브젝트가 네임스페이스 속한다(namespaced) 라고 표현한다.

// 네임 스페이스에 속하는 오브젝트 종류 확인
$ kubectl api-resources --namespaced=true
// 네임 스페이스에 혹하지 않는 오브젝트 종류 확인
# kubectl api-resources --namespaced=false

nodes 는 쿠버네티스의 오브젝트 중 하나이지만, 네임스페이스에 속하지 않는 대표적인 오브젝이다. 쿠버네티스 클러스터에서 사용되는 저수준의 오브젝트이며, 네임스페이스에 의해 구분되지 않는다.

7.2.1 컨피그맵(Configmap)

7.2.2 시크릿(Secret)

시크릿 사용법 익히기

시크릿은 SSH 키, 비밀번호 등과 같이 민감한 정보를 저장하기 위한 용도로 사용되며, 네임스페이스에 종속되는 쿠버네티스 오브젝트이다.

my-password 라는 이름의 시크릿을 생성하여, password=1q2w3e4r이라는 키-값 쌍을 저장

$ kubectl create secret generic my-password --from-literal password=1q2w3e4r

시크릿 확인

$ kubectl get secrets

시크릿의 내용 확인

$ kubectl describe secret my-password
$ kubectl get secret my-password -o yaml

쿠버네티스의 오브젝트 중 하나인 ServiceAccount 에 의해 네임스페이스별로 default-token-xxx 시크릿이 자동으로 생성되어 있다.

시크릿에 저장할 때, 쿠버네티스가 기본적으로 base64로 값을 인코딩 한다.

이미지 레지스트리 접근을 위한 docker-registry 타입의 시크리 사용하기

시크릿은 사용 용도에 따라 여러 종류를 설정 할 수 있으며, 비공개 레지스트리에 접근할 때 사용하는 인증 설정 시크릿을 예로 설명한다.

쿠버네티스에서는 docker login 명령어 대신 레지스트리의 인증 정보를 저장하는 별도의 시크릿을 생성해 사용한다.

레지스트리 인증을 위해 시크릿을 생성하는 2가지 방법
1) docker login 명령어로 로그인에 성공했을 때 도커 엔진이 자동으로 생성하는 ~/.docekr/config.json 파일을 사용(인증정보가 포함되어있음)

config.json 파일의 인증정보 그대로 가져오기

$ kubectl create secret generic [REGISTRY_NAME] \
--from-file=.dockerconfigjson=/root/.docker/config.json \
--type=kubernetees.io/dockerconfigjson

2) 시크릿을 생성하는 명령어에서 직접 로그인 인증 정보를 명시

필수옵션: --docker-username, --docker-password
사설 레지스트리 옵션: --docker-server

$ kubectl create secret docker-registry [REGISTRY-NAME] \
--docker-username=[USER_NAME] \
--docker-password=[PASSWORD] \
--docker-server=[DOCKERSERVER_DOMAIN] <-- 사설 레지스트리 설정 옵션

TLS 키를 저장할 수 있는 tls 타입의 시크릿 사용하기

TLS 연결에 사용되는 공개키, 비밀키 등을 쿠버네티스에 자체적으로 저장할 수 있도록 tls 타입을 지원

좀 더 쉽게 컨피그맵과 시크릿 리소스 배포하기

컨피그맵이나 시크릿을 업데이트해 애플리케이션의 설정값 변경하기

8 Ingress

인그레스트래픽은 외부에서 서버로 유입되는 트래픽을 의미하며, 인그레스 네트워크는 인그레스 트래픽을 처리하기 위한 네트워크를 의미 한다.

인그레스 오브젝트의 기본적인 기능
1) 외부 요청의 라우팅: 특정 경로로 들어온 요청을 어떠한 서비스로 전달할지 정의하는 라우팅 규칙 설정
2) 가상 호스트 기반의 요청 처리: 같은 IP에 대해 다른 도메인 이름으로 요청이 도착했을 때, 어떻게 처리할 것인지 정의 가능
3) SSL/TLS 보안 연결 처리: 여러 개의 서비스로 요청을 라우팅할 때, 보안 연결을 위한 인증서를 쉽게 적용 가능

인그레스의 기능은 위 기능으로 제한되는것이 아닌 인그레스의 요청을 처리할 서버로 무엇을 선택하느냐에 따라 기능은 조금씩 달라진다.

8.1 Ingress 사용 이유

인그레스는 라우팅 정의나 보안 연결 등과 같은 세부 설정은 서비스와 디플로이먼특 아닌 인그레스에 의해 수행되며 각 디플로이먼트에 대해 일일이 설정을 적용할 필요 없이 하나의 설정 지점에서 처리 규칙을 정의하기만 하면 된다.

즉 외부 요청에 대한 처리 규칙을 쿠버네티스 자체의 기능으로 편리하게 관리할 수 있는 것이 인그레이스의 핵심이다.
LB 의단점?
로드 밸런서는 서비스당 하나의 IP 주소만 처리할 수 있습니다.
클러스터에서 여러 서비스를 실행하는 경우 각 서비스에 대한 로드 밸런서가 있어야 합니다.
모든 서비스에 대해 로드 밸런서를 보유하는 것은 비용이 많이 들 수 있습니다.

Ingress 오브젝트의 기본적인 기능
1) 외부 요청의 라우팅
2) 가상 호스트 기반의 요청 처리
3) SSl/TLS 보안 처리

위 기능 외에도 인그레스를 어덯게 사용하느냐에 따라 다양한 기능을 사용할 수 있다.
외부 요청에 대한 처리 규칙을 쿠버네티스 자체의 기능으로 편리하게 관리할 수 있다는 것이 인그레스의 핵심이다.

8.2 Ingress 구조

인그레스의 는 단지 요청을 처리하는 규칙을 정의하는 선언적인 오브젝트일 뿐, 외부 요청을 받아들일 수 있는 실제 서버가 아니기 때문에 인그레스 컨트롤러 라고 하는 특수한 서버에 적용해야 규칙을 사용 가능하다.
실제 외부 요청을 받아들이는 것 또한 인그레스 컨트롤러 서버이며, 이 서버가 인그레스 규칙을 로드해 사용한다.

ingress 확인

$ kubectl get ingress
or
$ kubectl get ing

ingress 컨트롤러를 쿠버네티스 상에서 설치

$ kubectl apply -f \ https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.35.0/deploy/static/provider/aws/deploy.yaml

설치 후 확인

$ kubectl get pods,deployment -n ingress-nginx
$ kubectl get svc -n ingress-nginx

인그레스 컨트롤러를 설치하면 자동으로 생성되는 서비스는 LoadBalancer 타입이다.
인그레스 컨트롤러는 다양한 종류가 있으며 Nginx-ingress 컨트롤러가 가장 많이 사용되는 듯하다.
Nginx 인그레스 컨트롤러는 쿠버네티스에서 공식적으로 개발되고 있다.
온프레미스에서 운영 단계를 계획한다면 MetalLB 나 오픈스택의 로드 밸런서를 사용 할 수 있다.

인그레스 컨트롤러의 동작 이해

인그레스 사용 방법/절차
1) 공식 깃허브에서 제공되는 YAML 파일로 Nginx 인그레스 컨트롤러를 생성한다.
2) Nginx 인그레스 컨트롤러를 외부로 노출하기 위한 서비스를 생성한다.
3) 요청 처리 규칙을 정의하는 인그레스 오브젝트를 생성한다.
4) Nginx 인그레스 컨트롤러로 들어온 요청은 인그레스 규칙에 따라 적절한 서비스로 전달된다.

쿠버네티스의 API 에는 특정 오브젝트의 상태가 변화하는 것을 확인할 수 있는 Watch API 가 있으며 인그레스 컨트롤러 또한 인그레스 리소스에 대해 Watch API 를 사용한다. 리소슷에서 생성, 삭제, 수정 등의 이벤트가 발생했을 때 이를 알려주는 기능으로 kubectl get 명령어에서도 -w 옵션을 붙여 사용 가능하다.
# 포드에 변화가 생기면 콘솔에 표시
$ kubectl get pods -w 

8.3 인그레스의 세부 기능: annotation을 이용한 설정

8.4 Nignx 인그레스 컨트롤러에 SSL/TLS 보안 연결 적용

인그레스는 일종의 GW 역할을 수행하는데 인그레스 컨트롤러 지점에서 인증서를 적용해 두면 요청이 전달되는 애플리케이션에 대해 모두 인증서 처리를 할 수 있다.

직접 서명한 루트 인증서를 통해 Nginx 인그레스 컨트롤러에 적용 가능하다.
(인증서를 통한 보안 연결 기능을 제공)

연결에 사용할 인증서와 비밀키 생성

$ openssl req -x509 -nodes -days 365 -newekey rsa:2048 \
-keyout tls.key -out tls.crt -subj "/CN=[PUBLIC_DOAMIN]/0=[KEY?]
$ ls
tls.crt tls.key
$ kubectl create secret tls tls-secret --key tls.key --cert tls.crt

yaml 생성 시에 아래와 같이 내용 추가

spec:
  tls:
  - hosts:
    - alicek106.example.com
    secretName: tls-secret
  rules:
  -hosts: alicek106.example.com

요청 test

// -k 옵션은 신뢰할 수 없는 인증서로 보안 연결을 하기 위함
$ curl https://alicek106.example.com/echo-hostname -k

8.5 여러 개의 인그레스 컨트롤러 사용하기

하나의 쿠버네티스에서 여러개의 인그레스 컨트롤러를 사용하는것이 가능
Nginx 인그레스 컨트롤러는 기본적으로 nginx 라는 이름의 클래스를 가지고 있으며,
이 설정을 변경하여 여러 개의 Nginx 인그레스 컨트롤러를 사용 하거나 인그레스 규칙을 선택적으로 적용할 수도 있다.

10 보안을 위한 인증과 인가: ServiceAccount 와 RBAC

10.1 쿠버네티스의 권한 인증과정

서비스 어카운트와 롤(Role), 클러스터 롤(Cluster Role)

여러 개의 클러스터 롤을 조합해서 사용하기

10.3 쿠버네티스 API 서버에 접근

10.4 서비스 어카운트에 이미지 레지스트리 접근을 위한 시크릿 설정

10.5 kubeconfig 파일에 서비스 어카운트 인증 정보 설정

10.6 유저(User)와 그룹(Group)의 개념

10.7 x509 인증서를 이용한 사용자 인증

참고자료
용찬호, 『시작하세요!도커/쿠버네티스: 친절한 설명으로 쉽게 이해하는 컨테이너 관리』, 위키북스(2020)

leesj

이전 포스트

Rancher 를 통한 Kubernetes 클러스터 Deployments 생성

다음 포스트