[CKA] cka 자격증 도전기

인프라 엔지니어로서 쿠버네티스에 대한 이해와 운영 경험이 중요하다고 생각했고, CKA 자격증을 취득하고자, 유데미 강의를 수강중이다.

해당 강의는 실습 환경을 무료로 제공하고, mock-exam과 lighting-lab을 제공하기에 좋았다!

 

해당 섹션별로,  틀렸던 문제나 헷갈리는 개념들을 정리하여 포스팅하려고 한다.

 

쿠버네티스의 목적은 애플리케이션을 컨테이너 형태로 자동화된 방식으로 호스팅하여 필요한만큼 애플리케이션의 인스턴스를 쉽게 배포하고 애플리케이션 내의 여러 서비스간에 쉽게 통신할 수 있도록 하는 것이다

 

마스터 노드는 컨테이너가 어디로 이동할지 계획하고, 노드와 컨테이너를 모니터링 하는 작업을 담당한다.

마스터 노드는 컨트롤 플레인 컴포넌트를 이용해서 모든 작업을 수행한다.

control plane에는 키 값 형태로 데이터를 저장하는 etcd 라는 데이터베이스가 존재한다

kube-scheduler는 컨테이너 리소스 요구 사항, 워커 노드 용량 또는 taint 및 tolerations 또는 node affinity와 규칙 같은 기타 정책이나 제약 조건에 따라 컨테이너를 배치할 올바른 노드를 식별한다

 

kube-controller-manager안에 있는 node controller는 노드를 관리한다. 클러스터에 새 노드를 온보딩하고, 노드를 사용할 수 없게 되거나 파괴되는 상황을 처리하며, 복제 컨트롤러는 복제 그룹에서 원하는 수의 컨테이너가 항상 실행되도록 보장한다

 

kube-apiserver는 클러스터내의 모든 작업을 오케스트레이션 하는 역할을 한다

 

kubelet은 각 노드에서 실행되는 에이전트이고, kube api 서버의 지시를 수신하고 필요에 따라 노드에 컨테이너를 배포하거나, 삭제한다.

kube apiserver는 주기적으로 Kubelet에서 상태 보고서를 가져와 노드와 그 노드위에 있는 컨테이너의 상태를 모니터링함

 

워커 노드끼리 통신은 워커 노드에서 실행되는 kube-proxy에 의해 활성화된다

kube-proxy 서비스는 워커 노드에서 실행중인 컨테이너가 서로 연결될 수 있도록 필요한 규칙이 워커 노드에 적용된다

 

파드가 노드에서 실행될 수 있도록 클러스터의 각 노드에 컨테이너 런타임을 설치해야 한다. 쿠버네티스 1.35에서는 컨테이너 런타임 인터페이스(CRI) 요구사항을 만족하는 런타임을 사용해야한다.

 

쿠버네티스는 컨테이너 런타임 인터페이스 외부에서 도커를 계속 지원하기 위한 임시적인 방법인 도커 심을 도입했고, 대부분의 다른 컨테이너 런타임은 CRI를 통해 작동하지만, 도커는 CRI가 없어도 계속 동작한다

Runcie를 컨테이너 런타임과 Runcie를 관리하는 데몬도 있다. 이를 컨테이너 라고 한다.

containerd는 CRI와 호환되며 다른 모든 런타임과 마찬가지로 쿠버네티스에서 직접 작동할 수 있다

 

kubectl get pods 했을때 ready 컬럼의 의미는 파드 안에 있는 running 컨테이너의 수/파드 안에 있는 전체 컨테이너의 수를 의미함

 

replicaset은 selector로 파드를 찾아서 관리한다

selector:
  matchLabels:
    tier: nginx
template:
  metadata:
    labels:
      tier: nginx

selector.matchLabels는 내가 관리할 파드를 고르는 조건이고, template.metadata.labels는 새로 만들 파드에 붙이는 라벨이다

따라서, 두개의 값이 같아야 한다.

 

1개의 deployment는 1개의 replicaset만 생성하고 유지한다.

 

blue 애플리케이션이 marketing 네임스페이스 내의 데이터베이스인 db-service에 접속하려고 한다. 접속에 사용할 DNS 이름은?

blue 애플리케이션과 db-service가 같은 네임스페이스에 있기 때문에 서비스 이름만 사용하면 된다.

 

이미 실행중인 redis파드를 클러스터 내부에서 6379포트로 노츨하는 서비스를 imperative commands로 만들기

kubectl expose pod [파드이름] --name=[서비스이름] --port=[포트 번호] --target-port=[포트번호] --type=[type]

port는 서비스가 외부에 노출하는 포트이고, targetPort는 서비스가 컨테이너로 실제로 전달하는 포트이다

따라서, 클라이이언트가 접속하면 Service(port) -> Pod(targetPort) -> 컨테이너(containerPort)로 타고 들어간다

서비스는 pod ip와 targetport로 트래픽을 전달한다. containerport를 직접 참조하지 않는다

하지만 보통 targetPort와 containerPort로 맞추는게 일반적이다

 

쿠버네티스 클러스터에서 사용 가능한 모든 API 리소스 확인 명령어: kubectl api-resources

 

yaml 파일의 spec: 아래를 보고 싶을때 (kubectl explain pod.spec, kubectl explain deployment.spec 하면 됨)

--recursive 플래그는 특정 필드 아래에 포함된 모든 하위 필드들을 한 번에 재귀적으로 보여주는 옵션이다