Rala
repo

매니징 쿠버네티스

Github logo Edit on GitHub

매니징 쿠버네티스를 공부하며 작성한 노트 필기

Chapter 1. 쿠버네티스란?

Kubernetes : 컨테이너화된 애플리케이션을 배포하기 위한 오픈 소스 오케스트레이터(orchestrator). 구현은 오케스트레이션을 위한 API이다. Kubernetes Cluster : 컨테이너 오케스트레이션을 위한 시스템셋. 쿠버네티스 API로 동작한다. 운영 주제 :

  • 클러스터 작동 방식
  • 클러스터 조정, 보안, 적용 방법
  • 클러스터를 이해하고 문제에 대응하는 방법
  • 새로운 기능과 사용자 정의 기능으로 클러스터를 확장하는 방법

Chapter 2. 쿠버네티스 살펴보기

2.1. 컨테이너

컨테이너의 두 구성

  • 컨테이너 이미지
  • 프로세스(컨테이너 이미지 러닝용) 격리를 위한 운영체제의 지원

컨테이너 이미지

애플리케이션의 구성

  • 애플리케이션 바이너리
  • 라이브러리
  • 기타 데이터 => 자기 컴퓨터에서 싸도 남의 컴퓨터에서 돌꺼라는, 이식성을 갖춘 컨테이너 이미지 획득
컨테이너 이미지 실행환경

운영체제의 네임스페이스

네임스페이스의 구성
  • OS내의 다른 프로세스 등으로부터 격리
  • chroot : 분리된 고유한 파일 시스템?
  • 고유한 네트워크 및 프로세스 식별자(PID)
  • 개별 SELinux를 실행 중인 컨테이너와 함께 사용 가능
컨테이너 이미지 관련 도구
  • 이미지 빌더 : ex. 도커
  • 이미지 생성 절차 : ex. dockerfile
  • 이미지 레지스트리 : ex. registry

2.2. 컨테이너 오케이스트레이션

이미지 레지스트리에서 애플리케이션을 운영하기 위한 환경 및 API 이미지를 돌리기 위한 사양을 설정->현재 확인하여 스케줄링->설정된 스케줄에 따라 이미지가 러닝

2.3. 쿠버네티스 API

클러스터를 운영하기 위한 API로 RESTful API. API 서버 제공. 하위 호환성이 개쩐다.

2.3.1. 기본 오브젝트

파드

쿠버네티스 클러스터 구성 최소 단위(atomic). 실행 중인 컨테이너로 구성. 하나의 파드에서 수행된다는 것은 동일한 시스템을 차지하도록 보장. 하나의 파드에서 수행되는 컨테이너는 네임스페이스를 공유 -> 네트워크 공유, IPC를 통한 통신 가능 -> 파드는 논리적으로 그루핑된 복제 단위

레플리카셋

복제본. 스케일아웃하여 하나가 자빠져도 다른 친구가 일해라. ReplicaSet 사용. RelicatoinController는 안녕.

서비스

서비스는 로드밸런서. TCP/UDP를 밸런싱 하며 아래와 같이 구성된다.

  • 자체 IP 주소(->서비스의 DNS 바인딩)
  • 클러스터 DNS 항목
  • 로드 밸런싱 규칙(Service->파드)
스토리지: 퍼시스턴트 볼륨, 컨피그맵, 시크릿

볼륨 :

  • 파드내에서 볼륨 집합 정의 가능.
  • NFS, iSCSI, gitRepo, 클라우드 스토리지 등 10가지. -> 다양한 종류의 스토리지를 연결하기 위한 CSI(Container Storage Interface) 제공
  • Mount : 컨테이너-볼륨 연결

컨피그맵(Configmap)

  • ConfigMap 기반의 볼륨. Configmap으로 정의된 볼륨을 컨테이너에서 볼 수 있음

시크릿

  • 디비암호, 인증서와 같은 보안 데이터. Configmap과 동일하게 동작.

2.3.2. 클러스터 구성 오브젝트: 네임스페이스, 레이블, 어노테이션

네임스페이스

쿠버네티스 클러스터의 자원 폴더. 폴더가 삭제되면 내부 자원도 모두 삭제 네임스페이스별 RBAC을 지원.

기본 생성되는 네임스페이스

  • default : 기본 네임스페이스
  • kube-system : 클러스터 운영 컨테이너
  • kube-public : 전체 클러스터에서 읽을 필요가 있는 자원을 위한 네임스페이스. 모든 사용자(인증되지 않은 사용자 포함) 접근 가능
  • kube-node-lease : 스케일링을 위한 리스 노드?용 네임스페이스

FQDN에 네임스페이스를 포함하여 네임스페이스 별로 동일한 자원명 설정이 가능. 예를 들어 my-service라는 서비스를 만들면, FQDN에 네임스페이스를 포함. 예를 들어 my-service.svc.my-namespace.cluster.internal.

레이블과 레이블 쿼리

레이블 : 자원 식별하는데 도움이 되는 키밸류 데이터. 전통적인 의미로 태그에 가까운듯? 예를 들어 "role" : "frontend"

레이블쿼리 : 레이블 셀렉터. 복수의 자원을 레이블로 검색해서 땡김

어노테이션

우리가 아는 그 어노테이션. 단순 주석일수 있지만 주석형 지시자로 어노테이션을 확장하여 신규 기능 개발 가능. 레이블은 쿼리가 가능하지만 어노테이션은 쿼리가 불가능.

2.3.3. 고급 오브젝트 : 디플로이먼트, 인그레스, 스테이트풀셋

디플로이먼트

롤아웃 업데이트를 위한 API. 3개의 리플리카셋이 있다면 v1 하나생성->정상동작확인->기존레플리카수 하나 줄이기를 3회 반복하여 롤아웃 업데이트. 디플로이먼트의 기능이 많으므로 굳이 레플리카셋을 직접 다루지않고 디플로이먼트를 사용

HTTP 로드밸런싱과 인그레스

인그레스 : HTTP 로드 밸런서(L7) foo.company.com, bar.company.com이 있을 때, DNS->인그레스(IP)연결하고, 인그레스에서 매핑 정보를 통해 각 서비스로 라우팅.

스테이트풀셋

레플리카셋의 보완책. 상태 기반 레플리카셋.

배치 워크로드 : 잡과 크론잡

잡 : 일회성 업무 크론잡 : 잡을 스케줄링함. 크론탭의 그 크론

2.3.5. 클러스터 에이전트와 유틸리티 : 데몬셋

에이전트

2.4. 마치며

잘 이해하자.

Chapter 3. 아키텍처

3.1. 개념

3.1.1. 선언적 구성(Declarative Configuration)

어떤 자원을 얼마나 사용할지에 대한 상태를 미리 선언(yaml or json) <-> 명령어 구성(imperative configuration)과 반대. 자가 복구가 가능해짐.

3.1.2. 조정 또는 컨트롤러

쿠버네티스 클러스터에서 구동되는 자원에 대해 사용자가 원하는 상태를 선언하고, 컨트롤러가 현재 상태를 관찰하여 해당 상태를 유지 모니터링을 위하여 자원의 라벨과 라벨쿼리를 이용

3.1.3. 암시적 또는 동적 그룹화

명시적/정적 그룹화 <-> 암시적/동적 그룹화

3.2. 구조

설계 원칙

3.2.1. 유닉스 철학

각자 일을 잘 수행하는 작은 조각, 모듈화를 기반으로 함. 단일 바이너리가 아니라 각자의 역할을 잘 수행하는 조각의 모음.

3.2.2. API 기반 상호작용

3.3. 구성 요소

워커 노드와 헤드 노드로 분류

  • 헤드 노드/제어/플랜 노드에서 쿠버네티스 인프라를 구성하는 대부분의 구성 요소가 수행
  • 워커 노드에서 실제 워크로드가 수행
3.3.1. 헤드노드의 구성요소
etcd

쿠버네티스 클러스터의 모든 오브젝트에 대한 키밸류 저장소. 이를 이용하여 비교 후 교환(CAS, Compare and Swap) 구현 가능? watch 프로토콜을 구현? 감시용 프로토콜?

API 서버

그야말로 인터페이스. 클라이언트는 API를 통해서 etcd를 조작한다. 이것이 쿠버네티스 클러스터의 기본 흐름(클라이언트 -> API 서버 -> etcd)

스케줄러

실제 워크로드 수행 스케줄을 짬. OS의 태스크스케줄러 역할. 스케줄러->API 서버->파드에서 워크로드 돌림 여기까지 구축하면 기본적으로 컨테이너 이미지를 돌릴 수 있는 환경이 구축된다.

컨트로러 관리자

etc, API 서버, 스케줄러만으로는 제어 루프 수행 불가 => replicasets, service, deployment 동작 불가

3.3.2. 모든 노드의 구성 요소

모든 노드에서 공통 요소. 필수 기능이 구현됨.

쿠블렛(kubelet)

현재 노드의 API 서버 사이의 연결자. 예를 들어 컨트롤 루프가 컨테이너 상태를 볼때 API 서버에 요청을 하면 API 서버가 각 노드의 쿠블렛과 통신하여 CPU, 메모리 등의 정보를 던짐. 하드웨어 자원뿐 아니라 노드 위에 수행 컨테이너 정보를 포함. 모니터링 뿐만 아니라 컨테이너 스케줄링 및 제어도 담당.

kube-proxy

Service의 로드밸런서 네트워킹 구현. pod->pod 트래픽 라우팅.

3.3.3. 스케줄된 구성 요소

쿠버 DNS

쿠버 DNS 서버. Service에 대한 가상 IP와 도메인 정보를 담음. 쿠버 DNS 서비스에는 정적 가상 IP주소가 부여되므로, 컨테이너에서 해당 DNS로 DNS 쿼리를 날려 개발 가능함.

힙스터

바이너리 파일. 모든 컨테이너의 CPU, 메모리 등 메트릭 수집. 인플럭스 DB(influxDB) ? kubelet과 다른가? 자동 스케일링을 구현하는데 메트릭을 사용. => 요즘은 metrics-server를 통해 클러스터 전체 리소스 사용량 데이터를 집계. 힙스터 안씀

추가 기능

대시보드 Faas, 자동 인증 에이전트 등.

3.4. 마치며

Chapter 4 쿠버네티스 API 서버

4.1. 관리 효율을 위한 기본 특성

API 서버 - persistence DB 구조이므로 API 서버는 스테이트리스하다. 다만, 로그가 잔뜩 쌓이는데, 로그 로테이트로 돌리거나 집계 서비스로 뽑아서 관리하자

###4.2. API 서버의 구성

4.2.1. API 관리

4.2.2. 요청 처리

요청 경로는 /api or /apis로 시작한다. 예를 들어 /apis/batch/v1과 같은 요청 경로를 가진다.

경로 구성 방식 - namespace가 있는 경우

  • /api/v1/namespaces/<namespace-name>/<resource-type-name>/<resource-name>
  • espace(/apis/<api-group>/<api-version>/namespace/<namespace-name>/<resource-type-name>/<resource-name>)

경로 구성 방식 - namespace가 없는 경우

  • "/api/v1/<resource-type-name>/<resource-name>"
  • "/apis/<api-group>/<api-version>/<resource-type-name>/<resource-name>"

4.2.3. API 검색

; 로컬 클라이언트에서 API Server로 향하는 프록시 서버 생성(localhost:8001)
; curl로 API 명령 가능
kubectl proxy

4.3. 요청관리

4.3.1. 요청의 유형

GET

특정 리소스와 연관된 데이터를 검색. 예를 들어 /api/v1/namespaces/dafault/pods/foo라는 요청을 날리면 default네임스페이스의 foo 파드 데이터 검색함.

LIST

LIST = Collection Get. /api/v1/namespace/default/pods를 때리면 default 네임스페이스에 있는 전체 pods를 땡김.

POST

리소스 생성. 경로에 리소스 유형을 넣으므로 pod을 추가하려면 경로를 /api/v1/namespace/pods로 요청하고 생성할 pod의 내용을 본문에 넣음

DELETE

리소스 삭제. /api/v1/namespace/default/pods/foo와 같이 삭제할 리소스 경로 전송. 진짜 지워진다. 조심허자.

4.3.2. 요청의 수명

요청->인증

인증

요청의 첫 단계.

RBAC/인가

인증 후 인가(authentication 후 authorization)를 수행하며 RBAC 모델을 따른다.

요청자는 인가된 사용자가 아니면 403 응답을 받음.

승인 제어

Admission Controller에서 구현. 요청이 올바른지 판단하고 오류가 있을 경우 유청을 거부함. 플러그인 가능한 인터페이스.

유효성 검사

단일 오브젝트 요청에 대한 유효성 검사. 더 많은 정보를 필요로 할 경우 어드미션 컨트롤러로 구현 필요.

전문화된 요청

/proxy, /exec, /attach, /logs

단일 요청에 대한 응답 구조가 아니라 지속적으로 오픈 후 데이터 스트리밍과 같은 전문화된 요청이 가능

/logs

/logs 땡길 경우,client->apiserver-> kubelet->컨테이너 매트릭을 땡겨감.

데이터를 스트리밍 하므로 웹 소켓(3개 : std in, std out, std err)을 이용.

  • 프레임 구조 : "streamtype(0, 1, 2)" "byte1" "byte2"...

웹 소켓 하나당 256개의 스트림 다중화 가능.

/proxy

  • 프레임 구조 : "스트림 번호(고유 아이디(0~255))" "port(upper byte)" "port(lowertype)" "byte1" "byte2" ...
워치 동작

모든 변경 사항을 보고 관찰하기 위해 매번 연결하지 않고 서버-클라이언트간 지속 연결을 오픈함.

?watch=true 옵션으로 활성화.

낙관적 동시 업데이트

동시성 제어. 동일 자원 수정시 뒤쪽에 들어온 수정 요청에 실패(409, 충돌)을 날림

대체 인코딩

JSON타입 뿐 아니라 다른 두가지 형식 인코딩 지원. Content-type으로 지정(Application/json)함.

  • JSON - application/json
  • YAML - application/yaml
  • 프로토콜 버퍼 - application/vnd.kubernetes.protobuf. 와이어 포멧으로 키밸류로 표현됨. 시각화가 어렵다. 일부 클라이언트 라이브러리는 프로토콜 버퍼 요청 또는 응답 지원 불가.
공통 응답 코드
  • 202 - 비동기 요청에 대한 수락. 완료시점에서 실제 오브젝트가 반환
  • 400 - 잘못된 요청
  • 401 - 권한 없음(authenticatio)
  • 403 - 금지(authorization)
  • 409 - 충돌
  • 422 - 구문 분석 실패

4.4. API 서버 내부

4.4.1. CRD 제어 루프

CRD(Custom Resource Definition)은 동적 API 오브젝트. 생성한 자원에 대한 패스를 관리한다.

생성은 간단하지만 삭제하면 복구 불가. 주의.

4.5. API 서버 디버깅

API 서버가 기록하는 로그를 활용.

로그스트림 타입 : 표준(기본), 감사

4.5.1. 기본 로그

API 서버는 전송되는 모든 요청으 기록함.

4.5.2. 감사 로그

audit log. 파일에 기록될 수 있으나 웹훅에 기록될 수 있음.

audit.k8s.io API 그룹 event 타입의 구조화된 JSON 오브젝트

4.5.3. 추가 로그 활성화

애플리케이션 수준의 로그 활성화 가능(https://github.com/golang/glog)

--v로 verbosity레벨 조정하여 상세한 로깅 가능

4.5.4. kubectl 요청 디버깅

github.com/golang/glog로 동일하게 활성화 가능. kubectl의 요청을 기록하고 요청을 복사할 수 있음.

4.6. 마치며

기본적인 API 지식 획득 완료!

Chapter 5 스케줄러

스케줄러는 쿠버네티스 클러스터의 스케줄링을 수행하는 바이너리.

5.1. 스케줄링이란

파드를 실행할 노드를 찾고 파드가 돌아가도록 할당함.

파드 최초 생성시 nodeName이 비어있다.

  • 흐름 : 스케줄러-watch->kubelet => 노드 상태 확인 후 nodename 기입. 실행.

5.2. 스케줄링 프로세스

5.2.1. 사전 조건

사전 조건(predicate condition) : constraint. 예를 들어 메모리 요구량을 만족(true)/불만족(false)

5.2.2. 우선 순위

우선순위 / 우선순위 기능 : 가능/불가능 영역이 아닌 우선 순위. 예를 들어 시작 지연시간 관점에서 노드에서 파드가 이미 수행되고 있으면 이미지 복사 시간이 줄어 지연시간이 짧으므로 우선 순위가 높음. 역으로 spreading의 경우 파드가 돌고 있는 한 노드가 무너져도 다른 노드에서 파드가 돌고 있으면 서비스 수행이 가능하므로 파드가 없는 노드의 우선 순위가 높음.

5.2.3. 상위레벨 알고리즘

1) 파드가 실행가능 노드를 쫙 땡겨서 2) 우선 순위가 높은 노드로 정렬하고 3) 우선 순위가 제일 높은 노드에 배치. 동일하면 RR이나 랜덤으로 뿌림

5.2.4. 충돌

예를 들어, 코어 두 개 짜리 파드를 코어 두 개만 남은 노드에서 실행하고자 스케줄링했는데, 코어 하나짜리 파드가 해당 노드에서 우선 수행 되었다. 이 경우 파드 실행이 실패하게 된다.

이를 대비하기 위하여 단일 파드의 경우에도 replicaset(or deployment)으로 실행해야 한다. replicaset의 경우 실행에 실패하면 재시도를 하므로 파드가 실행됨

5.3. 스케줄링 제어하기

기본 스케줄링 말고, 사용자 정의 스케줄링 가능한 툴 제공.

5.3.1. 노드 셀렉터

특정 노드에서 파드가 수행되게 하기 위한 방법. 레이블을 이용. 선호도보다는 요구사항적 느낌.

예를 들어 ssd가 필요한 경우 ssd:true라는 레이블을 추가하여 해당 노드를 레이블 셀럭터로 땡겨와 그 노드에서 수행

5.3.2. 노드 어피니티

노드를 선택하기 위한 조건식. 요구사항(필수-requiredDuringSchedulingIgnoreDuringExecution)과 우선순위(preferredDuringSchedulingIgnoredDuringExecution)으로 나뉨 . weight값으로 선호도 작성.

5.3.3. 테인트와 톨러레이션

  • 노드 테인트 : 노드의 오염을 표현. 이를테면 신규 프로세서/구형 프로세서가 있는 경우 구형 프로세스를 오염 처리.

  • 노드 톨러레이션 : 용인/관용. 구형 프로세스의 수요가 줄므로 굳이 돌릴 필요는 없지만 돌아도 상관없는, don't care함을 표현.

5.4. 마치며

스케줄링 끝.

Chapter 6. 쿠버네티스 설치

고생 많으십니다.

6.1. 쿠베어드민(kubeadm)

쿠버네티스 설치 솔루션 중 하나. 메인 릴리즈에 포함된다. 일단 익혀두면 개이득인 부분.

6.1.1. 요구사항

  • 환경 : 다양한 환경(x86, arm, powerpc...) 지원.

  • 필수 바이너리 : 컨테이너 런타임과 쿠버네티스 쿠블렛, 리눅스 표준 유틸리티

  • 컨테이너 런타임 제약 : CRI(Container Runtime Interface) 준수 확인.

    • 호환 런타임 : 도커, rkt, CRI-O

6.1.2. 쿠블렛

컨테이너 런타임과의 인터페이스를 담당. API 서버는 이를 통하여 파드 전체 생명 주기를 관리. 쿠블렛은 systemd로 관리되며 유닛 파일은 대체로 커뮤니티에서 제공되는 모범 사례를 확인.

6.2. 컨트롤 플레인(마스터노드) 설치

  • 컨트롤 플레인(Control Plane) : 워커 노드에 실제로 작업을 지시하는 구성 요소
  • 구성요소 : API 서버, 컨트롤러 관리자, 스케줄러
  • 저장소 : etcd
노드에 컨트롤 플레인 설치
$ kubeadm init

init에서 수행하는 작업은 다음과 같다.

6.2.1. 쿠베어드민 설정

Kubeadm init을 수행하면 컨트롤 플레인을 설치하고, 기본 설정한 설정을 클러스터의 configmap으로 저장.

  • configmap : 컨테이너의 환경 설정 분리. 예를 들어 IP, API Key 등. 고전적인 명칭으로는 서버 설정

6.2.2. 비행 전 사전 점검

설치 전 사전 점검을 수행(Preflight-check)한다. 설치전 시스템이 설치에 적합한지 체크한다. 체크를 스킵할 수 있지만 안 하는 것이 좋음.

6.2.3. 인증서

자체 CA와 키 생성. 생성된 CA를 이용하여 다양한 인증서 생성하여 사용

  • API 서버 : 인바운드 요청 보호, 상요자 인증, 아웃바운드 요청 생성, 쿠블렛간의 TLS 등
  • PKI 위치 : /etc/kubernetes/pki

자체 생성 말고 준비된 키 파일 사용 가능(인증 기관에서 발급한).

6.2.4. etcd

kubeadm init시, 로컬 etc 서버 인스턴스를 설치. 로컬 호스트 볼륨을 연결하여 컨트롤 플레인 노드의 파일 시스템에 데이터를 유지. 이 경우 TLS 보호가 되지 않으므로 상용 환경에서는 TLS 보안이 적용된 etcd 엔드포인트를 사용. etcd는 다른 구성요소와 다르게 교체가 어려우므로 etcd 클러스터를 별도로 분리하자.

비밀데이터

etcd의 모든 데이터는 암호화하지 않는 것이 디폴트. 비밀 데이터를 위한 방안 제공.

Kube-apiserver에 --experimental-encryption-provider-config 파라미터 사용(대칭키).

encryption.conf에 암호화 설정을 추가

$ cat encryption.conf
kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
    - secrets
    providers:
      - identity: {}
      - aescbc:
        keys:
        - name: encryptionkey
          secret: asdfasdffwefwer23=(32bytes key)

--experimental-encription-provider-config=/path/to/encription.conf를 cube-apiserver에 추가하면 모든 비밀이 암호화되어 etcd에 기록. 위 예제에서는 secrets만 암호화하였지만, 실제로를 다양한 리소스 암호화 가능

6.2.5 쿠베컨피그

쿠베컨피그 파일들은 인증 수단에 사용. 예를 들어 kubeadm init시 쿠베어드민 기본 관리자 컨피그파일은 /etc/kubernetes/admin.conf에 생성됨. 여러용도로 쓰지 말고 부트스크랩용으로만 쓰자

6.2.6. 테인트

테인트란 key, value, effect로 구성되는 쿠버네티스 오브젝트.

프로덕트에서는 사용자 워크로드와 컨트롤 플레인 구성 요소를 분리하는 것이 좋음.

=> 쿠베어드민은 모든 컨트롤 플레인 노드를 node-role.kubernetes.io/master 테인트로 제어. 오염요소(톨러레이션)이 있는 노드들은 무시하도록 스케줄러에 지시

잘 모르겠다...

6.3. 워커 노드 설치

Chapter 7. 인증과 사용자 관리

  • API 요청 절차

API요청 -> [인증->접근제어->승인제어->요청승인]

​ -> 반려

Chapter 7.1. 사용자

사용자 : 일반적으로 외부 사용자 ID 관리 시스템(like AD)로 정의됨

Chapter 7.2. 인증

인증 방법

  • 기본 인증
  • X.509 클라언트 인증서
  • 베어러 토큰

Chapter 7.2.1. 기본 인증

기본 인증 : 사용자 정보를 내부파일로 관리. HTTP 인증 헤더에 아이디/비밀번호 등을 엮어서 Base64로 엮어서 해시로 결합

password, username, uid, "group1, group2, group3"
password, username, uid, "group1, group2, group3"
...

API 서버 인증 파일 넘기기 : --basic-auth-file옵션 사용

테스트 정도로 쓰기는 적당할 것 같다.

Chapter 7.2.2. X.509 클라이언트 인증서

가장 일반적인 형태. CA 서명에 대한 접근 권한이 있으면 사용자 생성 가능. => 인증서를 통한 유저 생성

클라이언트 인증서를 생성하려면?
  1. 생성할 유저 정보(이름-CN 등)를 담은 CSR생성
  2. cfssl을 이용하여 읹으서 생성
cfssl gencert \ 
 -ca=ca.pem \       ; ca서명
 -ca-key=ca-key.pem \ ;ca-key
 -config=ca-config.json \
 -profile=kubernetes \
 csr.json | cfssljson -bare admin

Chapter 7.2.3 OIDC

OAuth 2.0 기반 인증. JWT토큰 이용.

여기서부터 7장은 러프하게 훓고 필요할 때 다시.

기본 인증 흐름
  1. 사용자가 쿠버네티스 API 서버 애플리케이션에 인증요청
  2. 인증프론트가 수신한 자격 증명을 ID 제공자에게 던짐
  3. ID제공자가 인증 결과(접근 코드)를 프론트로 반환. 프론트가 클라이언트 자격 증명을 포함하여 ID제공자에게 반환. ID제공자가 토큰을 만들어 프론트로 던짐. 프론트가 사용자에게 토큰 반환
  4. 사용자는 쿠베컨피그 설정에 토큰 추가
  5. 쿠베컨피그에 토큰이 있으므로, kubectl이 api요청을 할 때 해당 토큰을 삽입. 만료되면 kubectl이 갱신 시도
  6. 쿠버네티스API는 kubectl이 날린 자격증명(토큰)을 ID제공자에게 던져 정상 토큰인지 확인
  7. 정상 토큰이면 ID 공급자는 사용자 정보를 쿠버네티스 API 서버로 반환하여 요청받은 기능을 수행

Chapter 7.2.4. 웹훅

Chapter 7.2.5. 덱스

공식적으로 디렉터리 서비스가 아직은 제공되지 않는다(책 기준). 이를 위하여 OIDC 브로커로 사용될 수 있는 덱스 프로젝트가 진행 중. AD, LDAP, SAML 다 지원.

Chapter 7.3. 쿠베컨피그 파일

인증 메커니즘이 포함된 쿠베컨피그 생성.

쿠베컨피그 파일 최상위 구조
- users : 사용자 이름, 인증 메커니즘
- clusters : 클러스터 연결 정보
- Context : 사용자와 클러스터를 연결
; 클러스터 전환
$ kubectl config use-context cluster2-regular

Chapter 7.4 서비스 계정

모든 파드에 있는 관리용 계정

Chapter 7.5 마치며

Chapter 8. 인가(Authorization)

사용자별 권한 부여

8.1. REST

쿠버네티스 API는 기본적으로 CRUD(post get put delete)베이스로 움직임.

API 종류

get update delet patch list watch proxy redirect deletecollection

8.2. 인가

유저별 권한 부여

8.3. RBAC

쿠버네티스 알백은 심플하다. 유저정보에 접근해야 하는 자원과 동사를 매핑함

8.3.1. 롤과 클러스터 롤

롤 예제 : 사용자가 deployments에 대한 읽기/쓰기 접근 권한을 갖지만 파드에 대해서는 읽기 접근 권한만 갖는
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: web-rw-deployment
  namespace: some-web-app-ns
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

롤과 클러스터롤은 범위만 다르다. 위 롤의 경우 some-web-app-ns 네임스페이스 리소스만 조작 가능 하다.

클러스터롤

클러스터의 일부 기능만을 사용해야할 경우.

service/ingress 리소스에 사용자 정의 어노테이션을 기반으로 DNS레코드를 만드는 경우 등

8.3.2. 롤 바인딩과 클러스터 롤 바인딩

롤 바인딩 : 사용자와 롤을 연결하는 것.

8.3.3. 테스트 권한 인가

kubectl context로 전환하여 사용자에게 롤(권한)이 잘 먹혔는지 간단하게 확인 가능함

8.4. 마치며

Reference

  1. systemd : https://lunatine.net/2014/10/21/about-systemd/
  2. 테인트와 톨러레이션 : https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/
Previous
Kubenetes with VMware(On-Premise)
Next
tcpdump 로그 읽기