Kubernetes API 클라이언트 사용

최근 많은 팀원들이 서비스, 파이프라인 내에서 k8s 클러스터에서 정보를 얻어와야 하는 경우, 이미지 내에 kubectl을 설치하고 코드에서 kubectl 커맨드를 string으로 저장해 사용하거나(?) 심지어 token값을 string으로 박아 넣으려는(!) 시도를 하고 있음을 깨달았다. 

이 부분을 바로 잡으며, 사람들에게 어떤 문의를 많이 받았는지를 바탕으로 정리해보고자 한다. 

 

kubectl을 이미지 내 설치한다(?)

사실 불가능한 방법은 아니다.

1. 이미지 내 kubectl 바이너리를 설치해둔다.
2. 서비스가 사용할 적절한 권한의 계정을 추가하고, kubeconfig를 생성한다.
3. configmap으로 kubeconfig를 마운트한다.

이 경우, 코드 에서 시스템 커맨드를 실행하고 결과를 파싱해서 사용하게 되는데,
에러 처리, 디버깅도 전혀 고려하지 않은 방식일 뿐 아니라 이후에 이어질 로직을 구현하는 것도 엉성해지게 된다.

개인적인 생각이지만 권한 관리 측면에서도 서비스의 권한을 서비스 어카운트로 관리하지 않고, 따로 계정을 만드는 것이 깨끗하지 못한 관리 방법으로 생각된다. 

 

kubectl

사람들이 이미지 내 kubectl을 설치해 사용해왔던건, kubectl이 어떻게 동작하는 지도 특별히 관심을 갖지 않고 k8s를 통제하는 유일한 만능 도구인 것 처럼 생각해왔기 때문이다. 어플리케이션 개발자 관점에서 쿠버네티스 클러스터는 결국 쿠버네티스 API로 동작하는 녀석이고, kubectl 역시 cli에서 API를 커맨드로 쉽게 날릴 수 있도록 해주는 여러 client 중 하나이다.

https://veritis.com/services/kubernetes/

예를 들어 아래 간단한 kubectl 커맨드도, KUBECONFIG에 정의되어 있는 k8s API 서버 주소, 인증 정보, 계정 정보 등을 가지고 "GET /api/v1/namespaces/{namespace}/pods/{name}" 의 요청을 k8s master 노드의 API 서버에 보내는 것이다. 

kubectl get pods -n spark

Kubernetes API Reference Docs

 

파드 내에서 쿠버네티스 API 접근

다시 본론으로 돌아와, 그럼 파드 안에서 어떻게 요청을 보내는 것이 옳은 방법이란 말이냐.
공식문서에 아주 잘 설명이 되어 있다.

파드 내에서 쿠버네티스 API에 접근

API 서버를 인증하는 권장 방법은 서비스 어카운트 자격 증명을 사용하는 것이다. 기본적으로, 파드는 서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은 해당 파드에 있는 각 컨테이너의 파일시스템 트리의 /var/run/secrets/kubernetes.io/serviceaccount/token 에 있다.

요약하자면, 권한 제어, 인증 등은 서비스가 물고 있는 서비스 어카운트에 있고, 파드에 마운트되어 있으니, 가져와 적절한 API를 사용하면 된다.

파드 내에서 "커맨드"로 API을 날려보자면, 아래와 같은 요청이 된다.

APISERVER=https://kubernetes.default.svc
SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
TOKEN=$(cat ${SERVICEACCOUNT}/token)
CACERT=${SERVICEACCOUNT}/ca.crt
 
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/spark/pods

파드 내에서 "파이썬"으로 API를 날려보자면, 아래와 같은 요청이 된다. 

conf = client.Configuration()
conf.api_key['authorization'] = open('/var/run/secrets/kubernetes.io/serviceaccount/token').read()
conf.api_key_prefix['authorization'] = 'Bearer'
conf.host = 'https://kubernetes.default'
conf.ssl_ca_cert = '/var/run/secrets/kubernetes.io/serviceaccount/ca.crt'
conf.verify_ssl = True

v1 = client.CoreV1Api(client.ApiClient(conf))
pod_items: {} = v1.list_namespaced_pod("spark", watch=False).items

 

 

Service Account에 권한 부여

(설명을 위해 상황을 가정해보자) 모델학습 파이프라인 파이썬 코드에서, 새로 설치한 spark-operator의 커스텀 오브젝트인 sparkapplication을 생성하려고 한다.

커스텀 오브젝트는 CRD(Custom Resource Definement)를 통해 정의된다. CRD에는 리소스의 스펙과 해당 리소스에 대한 기능을 제공할 API 이름이 정의되어 있다. 실제 spark-operator의 crd는 다음과 같다. 

spark-operator/manifest/crds/sparkoperator.k8s.io_sparkapplications.yaml at master · kubeflow/spark-operator

 

어찌됐든 해당 API를 통해, 해당 리소스에 대한 기능을 요청할 수 있는 것이므로, 클라이언트를 작성한다. 파이썬 코드임을 가정했으니, python-kubernetes-client를 사용하기로 한다. 먼저 python-kubernetes-client의 공식 문서에서 어떤 형태로 커스텀 오브젝트에 대한 접근을 제공하는지 확인하고, 스펙에 맞게 구현한다.

python/kubernetes/docs/CustomObjectsApi.md at master · kubernetes-client/python

생성 기능만 찔끔 작성해보자.

import kubernetes.client
import logging


class KubernetesClient:
    def __init__(self):
        conf = kubernetes.client.Configuration()
        conf.api_key['authorization'] = open('/var/run/secrets/kubernetes.io/serviceaccount/token').read()
        conf.api_key_prefix['authorization'] = 'Bearer'
        conf.host = 'https://kubernetes.default'
        conf.ssl_ca_cert = '/var/run/secrets/kubernetes.io/serviceaccount/ca.crt'
        conf.verify_ssl = True
        self.api_client = kubernetes.client.ApiClient(conf)

    def create_crd(self, group: str, version: str, namespace: str, plural: str, body: object):
        logging.info(f"Kubernetes Client::Creating custom resource {plural}({group}/{version}).")
        api = kubernetes.client.CustomObjectsApi(self.api_client)
        return api.create_namespaced_custom_object(
            group=group,
            version=version,
            namespace=namespace,
            plural=plural,
            body=body
        )

코드를 실행하니 에러가 발생한다.

spark-operator를 새롭게 설치했고, 새로운 리소스와 API가 생겼는데, 현재 파이프라인이 가진 서비스 어카운트에는 해당 API에 대한 권한 정보가 없는 것이다. sparkapplication에 대한 생성, 조회, 삭제 등 필요한 권한을 골라 담아 Role을 만들고 파이프라인의 서비스 어카운트와 Role을 묶는 RoleBinding을 생성해준다. 필요한 경우 ClusterRole ClusterRoleBinding을 생성한다. 자세한 사항은 공식 문서를 참고한다. 

Using RBAC Authorization

 

요약

아래 정도는 기본이니 알고 사용하자. 

• kubectl을 이미지 내 설치해서 쓰는 것은, 이미지 크기를 키울 뿐 아니라 대부분의 경우 적절한 방법이 아니다. 
• 서비스가 클러스터와 정보를 주고 받아야 하는 경우 코드로 클라이언트를 통해 제어하자. 
• 서비스가 클러스터 내 권한이 필요한 경우 role, cluseterRole에 필요한 리소스 권한을 골라 담아 서비스 어카운트에 바인딩한다.