Kubernetes context의 역할 알아보기

쿠버네티스에서는 context라는 개념이 있는데,
어떤 역할을 하는지 알아보자

 

여러 개의 쿠버네티스 클러스터를 운영한다면 다른 클러스터로 이동하기 위해 kubectl config use-context <context name> 명령어를 사용한 경험이 있을건데요.  저 또한 꽤나 많이 사용하는 명령어입니다. 하지만 해당 명령어를 사용하면서도 다른 클러스터로 이동하는 건데 왜 cluster가 아닌 context라고 하는 거지? 라는 의문이 있었습니다. 이번 포스팅에서는 context가 무엇이고 어떤 역할을 하는지 이야기 해보려 합니다.

쿠버네티스에 접근하기 위한 kubeconfig

kubeconfig 파일은 쿠버네티스의 설정 파일로 kubectl로 쿠버네티스의 API 서버에 접근할 때 사용하는 인증 정보를 가지고 있습니다. 보통은 ~/.kube에 config라는 이름으로 위치해있습니다. 해당 파일이 제대로 구성되어 있지 않으면 kubectl 명령어를 사용할 때 api 서버에 접근하지 못한다는 에러를 만나게 됩니다.

 

이 config는 크게 3가지 부분으로 구성되어 있습니다.

 

- clusters: 쿠버네티스 API 서버 정보들

- users: 쿠버네티스 API에 접속하기 위한 사용자 목록

- contexts: user와 cluster 사이의 관계를 매핑

 

위의 정보는 여러 클러스터에 대해 설정할 수 있고 이를 통해 여러 클러스터 사이를 이동할 수 있게 됩니다.

클러스터와 유저를 묶는 context

위의 설명에서 보셨다시피 context는 클러스터와 접근할 유저를 매핑한 것을 말합니다. 따라서 context가 하는 역할은 어떤 클러스터에 어떤 유저가 접근하는지를 결정하는 요소라고 할 수 있겠죠. 따라서 한 클러스터에도 여러 context가 존재할 수 있고 이 context를 변경함에 따라 원하는 유저로 원하는 클러스터에 접근할 수 있게됩니다.

 

간단하게 config 파일을 통해 예시를 살펴보겠습니다.

 

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: test
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    password: some-password
    username: exp

 

굉장히 복잡해보이는 config 파일인데요. clusters, users, contexts 구성에만 신경쓰면 그리 어렵지 않습니다. 클러스터는 development, test 두 가지로 구성되어 있고, 유저도 developer, experimenter 두 명이 있네요. 클러스터, 유저 이 두가지 정보만 알면 어떤 유저가 어떤 클러스터에 접근하는 것인지 알 수 없는데, 컨텍스트를 통해 관계성을 파악할 수 있습니다. 

 

먼저 dev-frontend 컨텍스트는 developer 유저가 development 클러스터의 dev-frontend 네임스페이스에 접근할 수 있다고 말해주고 있네요. dev-storage 컨텍스트 또한 developer 유저가 development 클러스터에 접근할 수 있지만 dev-storage라는 다른 네임스페이스에 대한 권한만 있네요.

 

dev-frontend 컨텍스트로 정리해보면 "development 클러스터의 frontend 네임스페이스에 접근하는데 developer 사용자 자격증명을 사용하라고 알려준다."라고 할 수 있습니다.