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

  07 Mar 2021

Kubernetes 리소스의 관리와 설정

Namespace : 리소스를 논리적으로 구분하는 장벽

Namespace란?

  • 도커나 스웜모드 사용 시, 컨테이너를 논리적으로 구분하는 방법이 없음
  • 포드, 레플리카셋, 디플로이먼트, 서비스 등의 쿠버네티스 리소스들이 묶여있는 하나의 가상공간 또는 그룹
  • 리소스들을 구분지어 관리할 수 있는 논리 그룹
  • 같은 네임스페이스 내의 서비스에 접근할때만 서비스명으로 접근 가능함
    • <서비스명>.<네임스페이스 이름="">.svc
  • 기본적으로 default, kube-system, kube-public 세 개의 namespace가 생성됨
    • 서비스, 레플리카셋과 같은 리소스들도 네임스페이스에 별도로 존재함
    • kube-dns(파드나 서비스등을 이름으로 찾을 수 있도록 하는 서비스)도 kube-system내에 존재

Namespace V.S. Label

  • 두 개념 다 리소스를 분류하고 구분하기 위한 방법
  • 네임스페이스는 라벨보다 더 넓은 용도
    • ResourceQuota 오브젝트 사용 시,
      • 포드의 자원 사용량 제한
      • 애드미션 컨트롤러라는 기능으로 특정 네임스페이스에 생성되는 포드에는 항상 사이드카 컨테이너를 붙임
  • 포드, 서비스 등의 리소스를 격리시킴

기본 설정

metadata:
name: 컨테이너의 이름
namespace : 네임스페이스명

  • $ kubectl get pods,services -n production
    • -n : namespace 옵션
  • $ kubectl get pods --all-namespaces
    • 모든 네임스페이스의 리소스 확인

Namespace 삭제

  • $ kubectl delete -f <YAML 파일명>
  • $ kubectl delete namespace <네임스페이스명>
  • 네임스페이스에 존재하는 모든 리소스가 삭제됨

Namespace의 서비스 접근

  • 쿠버네티스 클러스터 내부에서는 서비스 이름을 통해 파드에 접근 가능
  • 정확히 말하면, 같은 네임스페이스 내의 서비스에 접근할 때 서비스 이름으로만 접근 가능
  • 다른 네임스페이스에 있는 서비스의 경우, <서비스 이름="">.<네임스페이스 이름="">.svc 처럼 접속해야함

Namespace 종속성

  • 오브젝트가 네임스페이스에 속한다
    • A 네임스페이스에 파드 생성 시, A 네임스페이스에서만 보이고, 타 네임스페이스에서 보이지 않는 경우
  • 특정 네임스페이스에 속하지 않는 오브젝트
    • 저수준의 오브젝트
    • 클러스터 전반에 걸쳐 사용되는 경우
    • $ kubectl api-resources --namespaced=false
    • 노드 또는 네임스페이스와 같은 오브젝트

컨피그맵, 시크릿 : 설정값을 포드에 전달

배경 설명

도커

  • 도커 이미지 내부에 설정값 또는 설정파일을 정적으로 저장
  • But 도커 이미지는 한번 빌드 시 재빌드해야 하므로, 설정값을 유연하게 변경할 수 없다는 단점이 존재

쿠버네티스

  • YAML 파일에 환경 변수를 직접 적어놓는 하드 코딩 방식
  • 환경 변수만 다른, 동일한 여러 개의 YAML이 존재할 수 있음
    • 운영 환경과 개발 환경

컨피그맵

  • 네임스페이스에 속하기 때문에, 네임스페이스 별 컨피그맵이 존재
  • 컨피그맵 조회 시
    • $ kubectl get cm   $ kubectl get configmap
  • 컨피그맵 상세 조회 시
    • $ kubectl describe configmap {컨피그맵 명}
  • 설정 값 조회 방법
    • 컨피그맵의 값을 컨테이너의 환경 변수로 사용 valueForm
    • 컨피그맵의 데이터를 컨테이너의 환경변수로 가져오기 envForm 
      apiVersion: v1
kind: Pod
metadata:
  name: container-env-example
spec:
  containers:
    - name: my-container
      image: busybox
      args: ['tail', '-f', '/dev/null']
      envForm:
      - configMapRef:
          name: log-level-configmap
      - configMapRef:
          name: start-k8s
      • envForm 항목은 하나의 컨피그맵에 여러 개의 키-값 쌍이 존재하더라도 모두 환경 변수로 가져오도록 세팅 가능
      • valueForm 방식은 어떤 컨피그맵의 어떤 키를 사용할 지 설정 가능 
        env:
  valueForm:
    configMapRef:
      name: log-level-configmap
      key: LOG_LEVEL
    • 파드 내 환경변수 목록을 조회하고 싶을 때, $ kubectl exec {pod명} env
    • 컨피그맵의 값을 파드 내의 파일로 마운트해 사용
      • nginx.conf에서 특정 설정값을 읽어들인다면, 마운트 방식이 좋을 수 있음
      • 파드로 마운트된 설정 파일은 컨피그맵이나 시크릿을 변경하면 파일의 내용 또한 자동 갱신됨 ``` volumeMounts:
        • name: config-volume mountPath: /etc/config volumes:
        • name: configmap-volume configMap: name: start-k8s ```
      • YAML에서 사용할 볼륨의 목록을 정의
  • 서비스에 대한 접근 정보(PORT 정보들)은 자동으로 컨테이너의 환경변수로 설정함
    • KUBENETES_로 시작하는 값들
  • 컨피그맵 생성 시, --from-literal 옵션 대신 --from-file 옵션 사용 시, 여러 파일을 컨피그맵에 저장가능함

시크릿

  • SSH 키, 비밀번호 등과 같이 민감 정보 저장을 위한 용도로 사용
  • $ kubectl get secrets
    • default-token 이라는 시크릿은 쿠버네티스 오브젝트 중 ServiceAccount에 의해 네임스페이스별로 자동 생성된 시크릿
    • 시크릿값을 저장할 때, base64로 인코딩 된 문자열을 사용

시크릿 타입

  1. Opaque
    • 시크릿의 디폴트 타입
    • 옵션중에 generic이 Opaque 타입에 해당하는 종류임
  2. 인증 정보 저장용 시크릿
    • 비공개 레지스트리 접근 시 사용하는 인증 설정 시크릿
    • 쿠버에서는 파드 생성 시, 이미지가 로컬에 정의되지 않으면 자동으로 이미지를 받아옴
    • 도커 허브에 공개된 이미지들은 레지스트리 인증을 할 필요가 없으나, 사설 레지스트리 또는 도커 허브, GCR, ECR 등 클라우드 레지스트리 사용시 인증절차가 필요
      • ~/.docker/config.json 사용 
         kubectl create secret generic registry-auth \
 --from-file=.dockerconfigjson=/root/.docker/config.json \
 --type=kubenetes.io/dockerconfig.json
      • 시크릿 생성 명령어 중 로그인 인증 정보를 명시 
         kubectl  create secret docker-registry registry-auth-by-cmd \
 --docker-username={username} \
 --docker-password={비밀번호}
    • docker-server 옵션으로 레지스트리도 세팅할 수 있음 - imagePullSecrets으로 해당 인증정보 매핑
  3. TLS 키를 저장할 수 있는 tls 타입의 시크릿
    • 보안 연결을 위해 인증서나 비밀키 등을 가져와야 할때 시크릿의 값을 파드에 제공하는 방식으로 사용 가능
    • $ kubectl create secret tls로 생성가능
    • 각 데이터는 base64를 기반으로 인코딩됨

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

  • kubectl create secret 명령어를 사용해도 되지만, 바람직하지 않음
    • $ kubectl create secret tls my-tls-secret --cert cert.crt --key cert.key --dry-run -o yaml
    • tls.crt의 데이터가 매우 길어 가독성이 좋지 않음
    • YAML 파일과 데이터가 분리되지 않아 데이터를 관리하기에도 불편
  • kustomize 기능을 사용
    • 파일의 속성을 별도 정의하여 재사용
    • 여러 YAML 파일을 하나로 묶는 작업 ```

      kustomization.yaml # 시크릿을 생성하기 위한 지시문

      secretGenerator: # configMapGenerator로도 생성 가능

    • name: kustomize-secret
      type: kubernetes.io/tls # tls 타입의 시크릿을 생성 files:
    • tls.crt = cert.crt
    • tls.key = cert.key ```
  • 생성될 시크릿 정보를 미리 확인하려면 -> $ kubectl kustomize
    • --dry-run 옵션 사용과 비슷
  • $ kubectl apply -k ./으로 시크릿 생성
...