[CKA] Core Concepts - 3

CKA (https://www.credly.com/org/the-linux-foundation/badge/cka-certified-kubernetes-administrator)

 

namespace

• 지금까지 클러스터에 Pod, Deployments, Service 와 같은 개체를 생성할 때 우리는 Default 네임스페이스에 배포해왔다.
• Default 네임스페이스는 이름에서 알겠지만 쿠버네티스가 자동으로 생성한느 네임스페이스다.
• 쿠버네티스는 내부 목적을 위해 네트워킹, DNS 서비스 등의 Pod와 Service의 세트를 생성한다.
• 사용자로부터 이것들을 분리하고 관리자가 실수로 이 서비스들을 삭제하거나 수정하는 것을 막기 위해서 kube-system이란 이름의 네임스페이스로 자원을 생성해왔다.
• kube-public이라는 네임스페이스도 있다.
  • kbue-public은 모든 사용자가 사용할 수 있어야하는 리소스가 생성되는 곳이다.
• 클러스터의 사이즈가 작은 경우 네임스페이스를 신경 쓸 필요 없이 Default 네임 스페이스를 사용하면 되지만 보통 기업에서는 네임스페이스를 나눈다. (예를 들어 Dev 와 Prod 환경을 나누는 경우)
• 이런 네임스페이스는 고유한 정책 모음을 가질 수 있다.
• 네임스페이스 별로 리소스 할당량을 할당할 수도 있다.
  • 이렇게 하면 일정량을 보장받고 허용된 한도 이상을 사용하지 않게 된다.
• A 네임스페이스에서 B 네임 스페이스의 서비스로 접근하기 위해서는 DNS 항목을 이용해서 접근하면 된다. appname.default-subdomain.default.svc.cluster.local
  • 역순으로 설명하자면 cluster.local 은 클러스터의 기본 도메인 이름
  • svc는 서비스를 위한 하위 도메인
  • default-subdomain은 네임스페이스
  • appname 은 실제 애플리케이션의 name
• kubectl get pod -n <또 다른 네임스페이스 이름> -n 옵션을 이용해 다른 네임스페이스에 있는 pod도 검색 가능하다.
• kubectl create -f example.yml --namespace=dev --namespace 옵션을 이용하게되면 create 시 namespace를 지정할 수 있다.

 

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: test
  labels:
    name: mypod
spec:
  containers:
  - name: mypod
    image: nginx

 

• 위와 같은 방법으로 리소스가 항상 같은 네임스페이스에 생성되도록 할 수 있다.

 

apiVersion: v1
kind: Namespace
metadata:
name: test

 

• 위와 같은 방법으로 namespace를 생성하거나
• kubectl create namespace test 명령어를 이용해서 namespace를 생성할 수 있다.
• 또한 네임스페이스 별로 리소스 할당량을 제한할 수도 있습니다.

 

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
  namespace: dev
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

 

imperative(명령형) vs declarative(선언형)

• 인프라를 코드로 관리하는 데에는 여러가지 접근법이 있다.
• 명령적 접근법과 선언적 접근법으로 나뉜다.
• 예를들어 B가에 있는 친구 집에 가고 싶다고 가정하면, 예전에는 택시를 빌려 목적지 까지의 경로를 기사에게 단계별로 지시했다. B 거리에서 우회전해서 C 거리에서 좌회전하고... 이런 방식은 뭘 할지, 어떻게 할지 명시하는 게 중요하다.
• 요즘에는 택시를 예약할 때 최종 목적지를 지정한다. 이건 명령적 접근이다. 단계 별로 지시하는 게 아니라 최종 목적지를 선언하면 시스템이 목적지로 가는 올바른 경로를 찾아준다. 어떻게가 아니라 무엇을 할지 명시하는 것

 

• IaC에서 인프라 프로비저닝의 필수 접근법의 예는 단계적으로 작성된 명령어들의 집합이다.
  1. 예를들어 Web-server라는 VM을 프로비저닝
  2. Nginx 소프트웨어 설치 및 8080 포트로 구성 파일 편집
  3. 등등...
• 위 과정을 거쳐서 Nginx 서버를 시작할 수 있다. 위 방법은 무엇이 요구되는지 어떻게 작업을 수행하는 지에 대해 나와 있다. 명령적인 것이다.
• 즉, 쿠버네티스에서 명령형은 run, create, expose, set 등등의 명령어를 관리자가 직접 실행해 설정을 적용하는 것

 

• 선언적으로 한다는 것은 아래와 같다.
  • web-server라는 이름의 VM이 필요하다
  • Nginx 소프트웨어가 탑재되어 있고
  • 8080 포트 설정과
  • 웹 파일의 경로가 정의
  • 등등...
• 즉, 쿠버네티스에서 선연형은 yaml 파일에 오브젝트 상태를 정의하고 apply를 통해 생성하는 방식
• apply 명령은 기존 구성을 보고 시스템에 어떤 변화가 필요한지 알아낸다.

 

 

• 이런 인프라를 갖추기 위해 필요한 모든 작업은 시스템이나 소프트웨어가 한다.
• 선언적인 것처럼 하나하나 차근차근 설명하지 않아도 된다.
• Ansible, puppet, chef, terraform 같은 오케스트레이션 도구는 이 범주에 속한다.
• 이미 존재하는지 확인하고 결과에 따라 조치하는 것은 어떻게 할까? 가장 이상적인 방법은 시스템이 똑똑해서 이미 진행된 사항을 파악하고 필요한 수정 사항만 적용하는 것이다.
• 명령형 접근은 수정을 신속히 돕고 yaml 파일을 다룰 필요가 없다는 장점이 있다. 하지만 기능에 한계가 있어서 고급 유스케이스를 위해 길고 복잡한 명령어를 만들어야한다.
• 그리고 명령형 접근은 한번 명령어를 실행해서 오브젝트를 만들고 나면 사용자의 세션 history 에서만 확인이 가능하기 때문에 오브젝트가 어떻게 만들어졌는지 파악하기 어렵다.
• 그래서 크고 복잡한 환경에서 이런 명령을 다루기가 어렵다.
• 이러한 단점으로 yaml과 같은 개체 구성 파일로 개체를 관리하는 게 도움이 된다.
• 개체 정의 파일 생성 또는 구성 파일 또는 매니페스트 파일이라고도 불리는 파일인 yaml은 개체가 정확히 어떻게 보여야 하는지를 적는데 도움을 준다.
• 보통 Git과 같은 Repo에 저장되기 때문에 항상 갖고 있을 수 있고 PR 이나 Approval과 같은 과정을 이용해 Prod에 적용되기 전에 검토할 수도 있다.

 

• 파드의 내용을 편집할 경우 kubectl edit 명령을 이용한다.
• edit 명령어로 확인 시 기존 yaml과 다른 필드를 찾을 수 있다.

 

 

• status 필드가 새로 생겼음을 알 수 있다.
• status 필드는 Pod의 상태를 저장하는 데 사용된다. status 필드를 수정하게 되면 live 개체에 바로 적용이 된다.
• 한가지 주의해야할 점은 kubectl edit 을 이용해 수정하게 되면 어디에도 기록되지 않는다.
• 변경 사항이 적용된 후 local 환경에만 definition file이 남게 되는데 kubectl edit 명령어로 수정한 내용이 있는 게 아니라 이전에 생성 시에 있던 내용이 있어 나중에 내가 보거나 동료들이 보기에 변경 사항을 추적하지 못할 수 있다.

 

 

• 대신에 yaml 파일을 새로 구성해서 kubectl replace -f nginx.yaml 로 업데이트하게 되면 file로서 변경 사항을 추적할 수 있는 더 좋은 접근법이 될 것이다.
• 때로는 개체를 완전히 삭제하고 재생성하고 싶을 수도 있다. kubectl replace --force --force 옵션을 이용하게되면 그렇게 할 수 있다.
• 명령적 접근으로 수정 및 삭제하기 위해서는 개체가 먼저 존재하는지 확인해야한다. 그렇기 때문에 관리자에게 매우 까다롭다. 항상 현재 환경 설정을 인지하고 변경하기 전에 확인해야하기 때문이다.
• 선언적 접근은 우리가 작업해온 동일한 개체 구성 파일을 사용하고, 명령을 생성하거나 대체하는 대신 개체를 관리하기 위해 kubectl apply 명령을 사용한다. apply 명령은 이미 존재하지 않는 개체를 만들만큼 영리하다.
• kubectl apply -f /path/to/conf 와 같이 단일 파일 대신 디렉터리를 경로로 설정해 여러 작업을 한 번에 할 수도 있다.

 

kubectl apply

• kubectl apply 명령의 원리에 관해 좀 더 자세히 알아보도록 하자.
• apply 명령 실행은 변경이 적용되기 전에 로컬 구성 파일과 쿠버네티스 live 개체 정의, 그리고 마지막으로 적용된 설정을 고려한다.
• 만약 apply 명령을 실행했을 시점에 구성되어 있는 개체가 없다면 개체가 생성된다.
• 개체를 생성하기 위해서 kubectl apply 하면 우리가 쓴 로컬 파일의 Yaml 버전은 json 형식으로 변환되고, applied configuration으로 저장된다.
• 오브젝트에 대한 업데이트는 three-way patch라고 하는 "Local file", "Last applied Configuration", "Kubernetes Live object configuration" 3가지를 모두 비교해 live 오브젝트에 어떤 변화가 있는지 확인한다.
• 예를 들어 Nginx 이미지가 1.18에서 1.19로 업데이트 될 때 Local file에 있는 1.19로 설정된 설정 파일로 kubectl apply 를 적용하면 live 구성 값과 비교되고 차이가 있다면 live 구성 값은 새 값으로 업데이트 된다.
• 어떤 변화가 있더라도 마지막으로 적용된 json 형식(Last applied Configuration)은 항상 최신으로 업데이트 된다.
• 그렇다면 Last applied Configuration 은 왜 필요한가?
• 특정 필드가 삭제되는 예를 들어 type 레이블이 삭제되고 kubectl apply를 실행하면 Last applied Configuration에 레이블이 있지만 로컬 구성에는 없는 것을 볼 수 있다.
• 이것은 해당 필드를 live 구성 값에서 제거해야 한다는 것을 의미한다.
• 필드가 live 구성에 존재하고 로컬이나 Last applied Configuration에 존재하지 않는다면 그대로 남게된다.
• 하지만 로컬 파일에서 필드가 누락돼 Last applied Configuration에 존재하는 경우 이전 단계 혹은 마지막으로 kubectl apply 명령을 실행했을 때 특정 필드가 있었고 지금은 제거되고 있다는 것을 의미한다.
• 결론적으로 Last applied Configuration는 로컬 파일에서 어떤 필드가 제거됐는지 알아내는 것을 돕는다.
• live 구성 값은 쿠버네티스 메모리에 있다.
• Last applied Configuration는 kubectl.kubernetes.io/last-applied-configuration 이라는 annotations에 live 구성 값에 저장되어 있다.
• 이는 kubectl apply 명령을 실행했을 시에만 되기 때문에 명령적 접근과 선언적 접근을 혼동하지 않을 필요가 있다.

 

참조 : 

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/