[쿠버네티스] 클러스터 가상화 (네임스페이스 다루기)

* 실습에는 쿠버네티스 기능을 가상으로 테스트해볼 수 있는 환경인 katacoda(www.katacoda.com/courses/kubernetes/playground)를 이용하였음

* 실습 코드는 깃헙으로부터.

git clone https://github.com/Jpub/15_DandK
cd step15

---

클러스터 가상화

네임스페이스를 사용하여 k8s 클러스터를 논리적으로 분할하는 기능

---

오토스케일

수평 파드 오토스케일러 (Horizontal Pod Autoscaler, HPA)

• 파드 수를 부하에 맞게 자동으로 조절하는 기능
• CPU의 평균 사용률과 목표 사용률이 일치하도록 레플리카 수를 조절
• 스케일 업은 이전 동작에서 3분 뒤에 발동. 스케일 다운은 5분 뒤에 발동.

클러스터 오토스케일러 (Cluster Autoscaler, CA)

• 노드의 개수까지 조절
• 클라우드 API와 연동해야 함

---

네임스페이스

• 목적
  • 네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하기 위한 기능. 
  • kubectl이 적용되는 범위
  • 리소스 할당(CPU 시간과 메모리 용량), 접근 제어(파드 네트워크 통신)의 단위
• 종류
  • 초기 네임스페이스
    • default: 기본 네임스페이스. (지정하지 않으면 사용되는 네임스페이스)
    • kube-public: 모든 사용자가 읽을 수 있는 네임스페이스. 주로 전체 클러스 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 사용.
    • kube-system: 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
    • kube-node-lease: 클러스터가 스케일링될 때 노드 heartbeat의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스

초기 네임스페이스 목록

kube-system의 파드 목록

• 네임 스페이스 생성
  • 신규 생성
    • 네임스페이스를 만들면 서비스 어카운트와 그에 대응하는 시크릿(서비스 어카운트의 토큰(RBAC 기반의 접근제어에 사용됨), 클라이언드 인증서, 네임스페이스명이 담겨있음)이 생성됨

prod 네임스페이스 생성

서비스 어카운트인 default

secret

• 네임스페이스 prod에 파드가 기동되면, 서비스 어카운트의 시크릿이 자동으로 마운트되고 파드는 이 서비스 어카운트에 부여된 액세스 권한을 가짐
• 네임스페이스는 말 그대로 이름의 범위를 제공. 리소스의 이름은 네임스페이스 내에서 유일해야 함. 
  • 하나의 쿠버네티스 클러스터에 운영 환경과 테스트용 환경을 같이 돌리고 싶은 경우에 하나의 네임스페이스 안에서는 중복된 오브젝트의 이름이 허용되지 않기 때문에 매니페스트를 수정하여 오브젝트의 이름을 변경해야 함. 이럴 경우에는 각 환경별로 네임스페이스를 만들어 관리하면 편함. 네임스페이스가 다르면 같은 이름의 오브젝트를 만들수 있음.

 

시크릿과 컨피그맵

애플리케이션의 설정 정보나 패스워드와 같은 인증 정보는 컨테이너에 담지 말고 분리하여 네임스페이스에 저장하고 컨테이너가 읽도록 해야 함. 

• 컨피그맵: 네임스페이스에 저장한 설정 정보
• 시크릿: 인증 정보와 같이 보안이 필요한 정보를 네임스페이스에 저장한 것

컨테이너에서는 컨피그앱, 시크릿과 같은 오브젝트를 파일 시스템으로 마운트하여 파일로 읽거나 환경 변수로 참조할 수 있음

시크릿

• 사용자 ID와 비밀번호를 저장하는 매니페스트 (시크릿으로 등록)

db_credentials.yml 파일

secret으로 등록

컨피그맵

• 네임스페이스에 설정 정보를 저장하고 공유할 때 사용
• 시크릿과 다른 점? 
  • kubectl describe secret에서는 등록된 내용이 표시되지 않음
  • kubectl describe configmap 내용이 표시됨

---

메모리와 CPU 할당과 상한 지정

• 쿠버네티스는 CPU와 메모리 사용량을 지정할 수 있어 자원의 낭비 없이 높은 가동률로 클러스터를 운영할 수 있음
• 네임스페이스마다 CPU나 메모리의 최소 요구량과 최대 사용 제한을 설정 할 수 있음
• 네임스페이스에 리소스를 할당하는 방법
  • Resource Quota:
    • 여러 사용자나 팀이 정해진 수의 노드로 클러스터를 공유할 때 한 팀이 공정하게 분배된 리소스보다 많은 리소스를 사용하지 못하도록 제한.
    • 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와 해당 네임스페이스의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 제한할 수 있음
  • Limit Range:
    • 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점하는 것을 제한
    • CPU와 메모리 각각의 요구량과 최대량의 기본값을 설정. 파드의 CPU나 메모리의 요구량 및 최대 제한량의 기본값을 설정하여 메니페스트에 적지 않고도 네임스페이스에 설정된 디폴트값을 이용할 수 있도록 함. 
    • 네임스페이스별로 리소스 사용과 생성을 제한
    • CPU 상한 시간 (limit): 컨테이너가 실행할 수 있는 최대 CPU 시간. CPU에 작업이 없어 유휴 시간이 있어도 매초 중 400밀리초까지만 컨테이너에 CPU 시간을 할당. 
    • CPU 요구 시간: 컨테이너가 실행하기 전에 확보해야 하는 CPU 시간. 다른 컨테이너들과 함께 실행되어도 요구한 CPU 시간만큼은 보장(상한 값에 해당하는 부분은 컨테이너들끼리 경쟁). 컨테이너를 실행할 때 요구시간을 할당해줄 수 없을 경우 실행이 보류됨.

Reaource Quota: 컨테이너의 CPU 시간 할당 방식

네트워크의 접근 제어

• Firewall과 비슷한 기능
  • 예로 하나의 물리적 클러스터를 2개의 네임스페이스(prod, test)로 구분하여 사용하는 경우. 운영 환경에서 발생한 오류 원인을 분석하기 위해 테스트 환경에서 문제를 재현해 보고자 할때, 실수로 운영 환경을 잘못 건드릴 수가 있음..(위험함!) => 이럴 때 네트워크 정책을 이용해 사전에 방지
•  네트워크 정책은 네트워크 플러그인으로 구현
  • 네트워크 폴리시를 제공하는 제공자: 캘리코, 실리움, kube-router ...
• 파드는 기본적으로 모든 트랙픽을 받아들임
  • 파드는 파드를 선택한 네트워크 폴리시에 의해서 격리됨
  • 두 파드간 네트워크 흐름을 허용하기 위해서는 소스 파드의 이그레스(egress) 정책과 목적지 파드의 인그레스(ingress) 정책 모두가 해당 트래픽을 허용해야 함. 만약 소스의 이그레스 정책이나 목적지의 인그레스 정책 중 한쪽이라도 트래픽을 거절하면 해당 트래픽은 거절됨.
• network-policy.yml 예시
  
  • 네임스페이스 간 통신 금지
  • 라벨을 설정한 컨테이너만 외부로부터 액세스 허용

#
# 네트워크 폴리시 설정
#

##
# 동일한 네임스페이스 외에서의 엑세스 금지
#
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-from-other-namespaces
  namespace: prod
spec:
  podSelector:
    matchLabels:        #  ← 모든 파드가 대상
  ingress:
  - from:
    - podSelector: {}
---
## 
# app: expose 라벨이 붙은 컨테이너를 공개
#
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: expose-external
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: expose
  ingress:
  - from: []                 

---

역할에 따른 접근 범위 제한

• 모든 사람에게 슈퍼 유저 권한을 주지 않고, 역할에 맞는 권한을 부여

• 역할에 따른 접근 제어 (RBAC; Role Based Access Control): 사용자 ID가 아닌 역할에 권한을 부여하여 서비스 어카운트에 매핑한다.
• 예시
  1.  네임스페이스 작성: 운영용(prod), 테스트용(test)
  2. 각 네임스페이스에서 서비스 어카운트를 작성: 시스템 운영 담당(operator), 앱 개발 담당(developer)
  3. 클러스터 레벨의 역할(Role)을 작성해 서비스 어카운트와 매핑시킴 (RoleBinding)
     1. 기존에 있는 Role
        1. admin: 관리자 권한으로 생성, 편집, 삭제가 가능
        2. edit: 편집 가능 권한
        3. view: 참조만 가능한 권한
     2. 각 역할의 담당자에게 역할 별 토큰을 전달. 개발자는 전달받은 토큰과 인증서를 자신의 kubectl 설정에 추가.

 

---

참조

타카라 마호 저/이동규 역, <15단계로 배우는 도커와 쿠버네티스>, 제이펍, 2020.10.12.

kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/