본문 바로가기
MLOps/Doker & Kubernetes

Udemy CKA 강의 정리 153: KubeConfig

by 공부하는 무니 2023. 1. 18.
반응형

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.


이번 강의에서는 쿠버네티스의 kubeconfigs에 대해 알아봅니다.

지금까지 사용자에 대한 인증서를 생성하는 방법을 살펴보았습니다. 클라이언트가 인증서 파일과 키, 그리고 curl을 사용하여 Kubernetes REST API에 파드 목록을 쿼리하는 방법을 살펴보았습니다.

이 경우 내 클러스터는 my-kube-playground라고 이름이 지정되어 있으므로 옵션으로 CA 인증서와 함께 베어러 파일을 전달하면서 kube-apiserver의 주소로 curl 요청을 보냅니다. 그런 다음 API 서버에서 유효성을 검사하여 사용자를 인증합니다.  kubectl 유틸리티를 통해서도 옵션 서버, 클라이언트 키, 클라이언트 인증서 및 인증 기관을 사용하여 동일한 정보를 지정할 수 있습니다.

분명히 매번 입력하는 것은 지루한 작업이므로 이 정보를 kubeconfig라는 config 파일로 옮기고 싶습니다. 아래 커맨드처럼 config 파일을 kubeconfig 옵션으로 지정하면 됩니다.

$ kubectl get pods --kubeconfig config

default로 kubectl tool은 .kube 디렉토리 아래에서 config라는 파일을 찾습니다. .kube는 사용자의 홈 디렉토리 아래에 있습니다. 따라서 거기에서 kubeconfig 파일을 지우면 kubectl 커맨드에서 파일 경로를 명시적으로 지정할 필요가 없습니다.(?) 이것이 지금까지 kubectl 커맨드에 대한 옵션을 지정하지 않은 이유입니다.

Kubeconfig File

kubeconfig 파일은 특정 형식을 가지고 있습니다. config 파일에는 세 섹션이 있습니다.

  • Clusters
  • Contexts
  • Users

클러스터는 액세스해야 하는 다양한 Kubernetes 클러스터입니다. 개발 환경, 테스트 환경, 제품 또는 다른 조직 또는 다른 클라우드 공급자 등에 대해 여러 클러스터가 있다고 가정합니다.

사용자는 이러한 클러스터에 액세스할 수 있는 사용자 계정입니다. 예를 들어 admin 사용자, dev 사용자, prod 사용자 등이 있습니다. 이러한 사용자는 다른 클러스터에서 다른 권한을 가질 수 있습니다.

마지막으로 컨텍스트는 이들을 결합합니다. 컨텍스트는 어떤 클러스터에 액세스하는 데 사용할 사용자 계정을 정의합니다. 예를 들어 admin 계정을 사용하여 프로덕션 클러스터에 액세스하는 프로덕션에서 admin이라는 컨텍스트를 만들 수 있습니다. 또는 내가 빌드한 애플리케이션의 배포를 테스트하기 위해 개발자 사용자의 자격 증명을 사용하여 Google에 설정한 클러스터에 액세스할 수 있습니다. 이 프로세스를 사용하여 클러스터에서 새 사용자를 생성하거나 어떤 종류의 사용자 액세스나 authorization도 구성하지 않는다는 점을 기억하세요.

기존 권한을 가진 기존 사용자를 사용하고, 어떤 클러스터에 액세스하는 데 사용할 사용자를 정의합니다. 이렇게 하면 실행하는 모든 kubectl 커맨드에서 사용자 인증서와 서버 주소를 지정할 필요가 없습니다. 

커맨드의 server specification은 클러스터 섹션으로 이동합니다. admin 사용자의 키와 인증서는 사용자 섹션으로 이동합니다. 그런 다음 MyKubeAdmin 사용자를 사용하여 MyKubePlayground 클러스터에 액세스하도록 지정하는 컨텍스트를 생성합니다.

이제 실제 kubeconfig 파일을 살펴보겠습니다. kubeconfig 파일은 YAML 형식입니다.

API 버전이 v1로 설정되어 있습니다. kind는 config입니다. 그리고 우리가 논의한 대로 세 개의 섹션이 있습니다. 하나는 클러스터용, 다른 하나는 컨텍스트용, 다른 하나는 사용자용입니다. 이들 각각은 배열 형식입니다. 이렇게 하면 동일한 파일 내에서 여러 클러스터, 사용자 또는 컨텍스트를 지정할 수 있습니다.

클러스터 아래에 kube playground 클러스터에 대한 새 항목을 추가합니다. my-kube-playground 라는 이름을 지정하고 서버 필드 아래에 서버 주소를 지정합니다. 또한 인증 기관의 인증서가 필요합니다.

그런 다음 user 섹션에 항목을 추가하여 my kube admin 사용자의 세부 정보를 지정할 수 있습니다. 클라이언트 인증서와 키 쌍의 위치를 제공하여 이제 클러스터와 클러스터에 액세스할 사용자를 정의했습니다.

다음으로 컨텍스트 섹션 아래에 항목을 만들어 둘을 함께 연결합니다. my kube playground에서 컨텍스트 이름을 my kube admin으로 지정합니다. 그런 다음 클러스터 및 사용자에 사용한 것과 동일한 이름을 지정합니다.

동일한 프로세스에 따라 매일 액세스하는 모든 클러스터, 액세스하는 데 사용하는 사용자 자격 증명 및 컨텍스트를 추가하세요. 파일이 준비되면, 일반적으로 다른 Kubernetes 오브젝트에 대해 하는 것처럼 오브젝트를 만들 필요가 없습니다. 파일은 그대로 두고 kubectl 커맨드로 읽고 필요한 값을 사용합니다. 

kubectl은 선택할 컨텍스트를 어떻게 알 수 있을까요? 여기서는 세 가지 컨텍스트를 정의했습니다. 어느 것으로 시작해야 할까요? kubeconfig 파일에 current-context 필드를 추가하여 사용할 default 컨텍스트를 지정할 수 있습니다. 이 경우 kubectl은 항상 dev-user@google 컨텍스트를 사용하여 Google 클러스터에 액세스합니다.

kubectl 내에서 kubeconfig 파일을 보고 수정할 수 있는 커맨드라인 옵션이 있습니다. 사용 중인 현재 파일을 보려면 kubectl config view 커맨드를 실행합니다.

$ kubectl config view

클러스터의 contexts 및 사용자뿐만 아니라 설정된 현재 컨텍스트를 보여줍니다. 앞에서 설명한 것처럼 사용할 kubeconfig 파일을 지정하지 않으면 .kube폴더에 있는 default 파일을 사용하게 됩니다. 또는, 이와 같이 커맨드라인에 kubeconfig 옵션을 전달하여 kubeconfig 파일을 지정할 수 있습니다.

$ kubectl config veiw --kubeconfig=my-custom-config

사용자 지정 config을 홈 디렉토리로 이동하면 default config 파일이 됩니다.

그렇다면 current context를 어떻게 업데이트할까요? my kube admin user를 사용하여 my kube playground에 액세스했습니다. prod user를 사용하여 프로덕션 클러스터에 액세스하도록 컨텍스트를 변경하고 싶습니다.

kubectl config use context 커맨드를 실행하여 현재 컨텍스트를 프로덕션 컨텍스트의 prod 사용자로 변경합니다. 이것은 파일의 current context 필드에서 볼 수 있습니다. kubectl config 커맨드으로 변경한 내용은 실제로 파일에 반영됩니다.

kubectl config 커맨드의 다른 변형을 사용하여 파일에서 다른 변경을 수행하거나 항목을 업데이트 또는 삭제할 수 있습니다. 시간이 있으시면 확인하세요.

What about namespaces?

네임스페이스는 어떨까요? 예를 들어 각 클러스터는 그 안에 여러 네임스페이스로 구성될 수 있습니다. 특정 네임스페이스로 전환하도록 컨텍스트를 구성할 수 있을까요? kubeconfig 파일의 context 섹션은 특정 네임스페이스를 지정할 수 있는 namespace라는 추가 필드를 사용할 수 있습니다. 이렇게 하면 해당 컨텍스트로 전환할 때 자동으로 특정 네임스페이스에 있게 됩니다.

Certificates in kubeconfig

마지막으로 인증서에 대해 말씀드리겠습니다. 아래와 같이 전체 경로를 사용하는 것이 좋습니다. 그러나 인증서 자격 증명을 지정하는 다른 방법도 있다는 점을 기억하세요.

예를 들어 CA에 대한 경로를 구성하는 첫 번째 항목을 살펴보겠습니다. 오른쪽에 ca.crt 파일이 있습니다. certificate authority 필드와 파일 경로를 사용하는 대신, 선택적으로 certificate authority data 필드를 사용하고 파일이 아닌 인증서 자체의 내용을 제공할 수 있습니다. 내용을 Base64 인코딩 형식으로 변환한 다음 전달합니다. 마찬가지로 인코딩된 형식의 인증서 데이터가 포함된 파일이 표시되면 Base64 디코딩 옵션을 사용하여 인증서를 디코딩합니다. 

반응형

댓글