[2] Kubernetes 리소스의 관리와 설정

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 ./으로 시크릿 생성