EKS 환경에서 kubeconfig 적용하기

개요

EKS의 사용률이 높아지면서 운영자의 입장에서는 그만큼 관리해야 할 클러스터가 많아질 것이다. EKS 기본 환경 Setting부터 여러 개의 클러스터 접근 방법에 대해 알아보려 한다.

쿠버네티스는 kubectl에 대한 인증정보를 kubeconfig라는 yaml파일에 저장한다. EKS 클러스터는 어떻게 접근을 하는지, 어떻게 인증을 받아오는지 알아보자.

Kubeconfig

EKS 클러스터에 접근 가능한 kubeconfig파일을 생성하는 것은 간단하다. aws command 한 줄이면 인증 정보를 kubeconfig 파일에 저장할 수 있다.

aws eks --region <region-code> update-kubeconfig --name <cluster_name>

EKS에 인증을 받아오는 구조는 어떤 방식일까? EKS 클러스터의 세부 정보 탭에 API 서버 엔드포인트와 인증 기관 (CA)를 확인할 수 있다.

apiVersion: v1
clusters:
- cluster:
    server: <endpoint-url>
    certificate-authority-data: <base64-encoded-ca-cert>
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  # namesapce: "<namespace>"
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws
      args:
        - "eks"
        - "get-token"
        - "--cluster-name"
        - "<cluster-name>"
        # - "--role-arn"
        # - "<role-arn>"
      # env:
        # - name: AWS_PROFILE
        #   value: "<aws-profile>"

kubeconfig 파일은 크게 clusters / contexts / users로 구분할 수 있다. clusters는 클러스터의 인증 정보, users는 사용자 eks로는 IAM에 대한 인증 정보를 토큰 값으로 저장하는 방식이다. 그리고 context는 clusters와 users의 조합하는 구간으로 namespace 또한 지정이 가능하다.

다중 클러스터 제어

aws command는 role이나 accesskey를 통해 사용이 가능하다. 여러 개의 클러스터를 운영하다 보면 다른 계정에 있는 클러스터에 접근해야 하는 일이 생긴다. accesskey를 사용할 경우에는 아래와 같이 profile을 나누어 key를 등록하면 된다.

** .aws 디렉터리는 각 user 별로 생성이 되기 때문에 configure를 설정한 홈 디렉터리를 잘 확인하자.

#.aws/credentials

**[default]**
aws_access_key_id = <acccess key>
aws_secret_access_key = <secret key>

**[sre-prd]**
aws_access_key_id = <acccess key>
aws_secret_access_key = <secret key>

**[sre-stg]**
aws_access_key_id = <acccess key>
aws_secret_access_key = <secret key>

kubeconfig 자동 생성

aws eks --region <region-code> update-kubeconfig --name <cluster_name> --profile <profile>

위와 동일하게 aws eks 명령어로 간단하게 생성 가능하다. —profile 옵션을 주면 해당 (ex sre-stg) profile로 등록된 aws access key를 참조하여 사용한다.

.kube/config 파일이 자동으로 생성되며, 다른 profile을 이용해 중복해서 사용될 경우 config 파일이 초기화되지 않고 add 된다.

kubeconfig 수동 생성

aws eks 명령어를 이용하면 편하지만, 해당 명령어에 대한 권한이 없거나 사용할 수 없는 경우 아래와 같이 수동으로 .kube/config 파일을 생성하면 된다.

복잡해 보이지만 생각보다 간단한 구조이다. aws eks 명령어를 —profile의 옵션을 주고 생성하면 아래와 동일하게 생성이 된다.

apiVersion: v1
clusters:
- cluster:
    server: <endpoint-url>
    certificate-authority-data: <base64-encoded-ca-cert>
  name: [sre-prd-cluster]
- cluster:
    server: <endpoint-url>
    certificate-authority-data: <base64-encoded-ca-cert>
  name: [sre-stg-cluster]
contexts:
- context:
    cluster: [sre-prd-cluster]
    user: [sre-prd]
  # namesapce: "<namespace>"
  name: [sre-prd-context]
- context:
    cluster: [sre-stg-cluster]
    user: [sre-stg]
  # namesapce: "<namespace>"
  name: [sre-stg-context]
current-context: [sre-prd-context]
kind: Config
preferences: {}
users:
- name: [sre-prd]
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws
      args:
        - "eks"
        - "get-token"
        - "--cluster-name"
        - "<cluster-name>"
      env:
        - name: AWS_PROFILE
          value: [sre-prd]
- name: [sre-stg]
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws
      args:
        - "eks"
        - "get-token"
        - "--cluster-name"
        - "<cluster-name>"
      env:
        - name: AWS_PROFILE
          value: [sre-stg]

sre-prd와 sre-stg라는 profile을 기준으로 user을 나눠 토큰 값을 부여받는 형식이며, context에 sre-prd-cluster ↔ sre-prd / sre-stg-cluster ↔ sre-stg을 연결하여 context만 변경하여 각기 다른 클러스터에 접근이 가능하다. (namespace를 지정하여 연결 가능)

context 변경

현재 사용되는 conext는 아래의 명령어로 확인 가능하다.

kubectl config current-context

default context 변경은 아래의 명령어로 설정 변경이 가능하다.

kubectl config use-context [context-name]

자세한 내용은 아래의 문서를 참고하면 좋을 것이다.

Amazon EKS용 kubeconfig 생성 - Amazon EKS