12. Accessing to Pod metadata from application

컨테이너에 정보 전달하기 위해 Downard API 사용 쿠버네티스 REST API 살펴보기 인증과 서버 검증을 kubectl proxy에 맡기기 컨테이너 내에서 API 서버에 접근하기 앰버서더 컨테이너 패턴의 이해 쿠버네티스 클라이언트 라이브러리 사용

애플리케이션이 쿠버네티스 API 서버와 통신해 리소스 정보를 가져오는 것과, 이러한 리소스를 관리하는 법에 대해 알아본다.

 

8.1 Downward API로 메타데이터 전달

파드의 IP, 호스트 이름, 파드 자체의 이름과 같이 실행 시점이 알려지지 않은 데이터는 ConfigMap 또는 Secret으로 전달하기에 적합하지 않다.

ConfigMap, Secret의 경우는 사용자가 데이터를 직접 설정하거나 파드가 노드에 스케줄링 되어 실행되기 이전에 알고 있어야 하기 때문이다.

이 경우 Downward API로 해결할 수 있다.

✅ Downward API - 환경변수 or downward API 볼륨 내의 파일로 파드와 해당 환경의 메타데이터를 컨테이너에 전달 할 수 있다. - Downward API는 REST API(애플리케이션이 호출해서 데이터 가져오는 api)와는 다르다.

 

8.1.1 사용 가능한 메타데이터 이해

Downward API를 사용해서 다음과 같은 pod 자체의 메타데이터를 컨테이너에 전달할 수 있다.

• 파드의 이름
• 파드 IP 주소
• 파드의 네임스페이스
• 파드가 실행 중인 노드 이름
• 파드가 실행 중인 서비스 계정 이름 (파드가 api 서버와 통신할 때 인증하는 계정)
• 각 컨테이너의 CPU와 메모리 요청 
• 각 컨테이너의 CPU와 메모리 제한 (컨테이너에 보장되는 CPU와 메모리의 양, 컨테이너가 얻을 수 있는 최대 양)
• 파드의 레이블
• 파드의 어노테이션

8.1.2 환경변수로 메타데이터 노출하기

아래 yaml 파일에 따르면 pod 이름, ip, 네임스페이스는 각각 POD_NAME, POD_IP, POD_NAMESPACE로 나타난다.

이때 divisor는 CPU나 메모리를 요청/제한할 때 사용하는 단위이다.

apiVersion: v1
kind: Pod
metadata:
  name: downward
spec:
  containers:
  - name: main
    image: busybox
    command: ["sleep", "9999999"]
    resources:
      requests:
        cpu: 15m
        memory: 100Ki
      limits:
        cpu: 100m
        memory: 20Mi
    env:
    # 특정 값을 설정하는 대신 파드 매니페스트의 metadata.name을 참조
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespac    
    - name: POD_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    - name: SERVICE_ACCOUNT
      valueFrom:
        fieldRef:
          fieldPath: spec.serviceAccountName
    - name: CONTAINER_CPU_REQUEST_MILLICORES
      valueFrom: 
        # 컨테이너의 CPU/메모리 요청과 제한은 fieldRef 대신 resourceFieldRef를 사용해 참조
        resourceFieldRef:
          resource: requests.cpu
          divisor: 1m      # 리소스 필드의 경우 필요한 단위의 값을 얻으려면 제수(divisor)을 정의
    - name: CONTAINER_MEMORY_LIMIT_KIBIBYTES
      valueFrom:
        resourceFieldRef:
          resource: limits.memory
          divisor: 1Ki

위 yaml 파일에서 cpu divisor는 1m으로, 1밀리코어를 의미한다.

memory divisor는 1ki(키비바이트)로 설정되었다.

다음과 같이 컨테이너에 적용된 모든 환경변수를 볼 수 있다.

컨테이너 내부의 모든 프로세스는 해당 변수를 읽고, 사용할 수 있게 된다.

root@master001:~/k8s_in_action/kubernetes-in-action/Chapter08# kubectl exec downward env
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=downward
POD_IP=172.30.254.34
NODE_NAME=worker002
SERVICE_ACCOUNT=default
CONTAINER_CPU_REQUEST_MILLICORES=15
CONTAINER_MEMORY_LIMIT_KIBIBYTES=20480
POD_NAME=downward
POD_NAMESPACE=default
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBIA_NODEPORT_SERVICE_HOST=10.99.129.201
KUBIA_NODEPORT_SERVICE_PORT=80
KUBIA_NODEPORT_PORT=tcp://10.99.129.201:80
KUBIA_NODEPORT_PORT_80_TCP=tcp://10.99.129.201:80
KUBIA_NODEPORT_PORT_80_TCP_PORT=80
KUBIA_NODEPORT_PORT_80_TCP_ADDR=10.99.129.201
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443
KUBIA_NODEPORT_PORT_80_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
HOME=/root

 

8.1.3 downward API 볼륨에 파일로 메타데이터 전달

downward API 볼륨을 이용해서 환경변수 대신 파일로 메타데이터를 노출할 수 있다.

파드의 라벨이나 어노테이션은 파일로만 전달 가능하다.

downward라는 볼륨을 정의하고 컨테이너의 /etc/downward 아래에 마운트한다.

apiVersion: v1
kind: Pod
metadata:
  name: downward
  labels:        # 레이블과 어노테이션은 downwardAPI 볼륨으로 노출
    foo: bar
  annotations:
    key1: value1
    key2: |
      multi
      line
      value
spec:
  containers:
  - name: main
    image: busybox
    command: ["sleep", "9999999"]
    resources:
      requests:
        cpu: 15m
        memory: 100Ki
      limits:
        cpu: 100m
        memory: 4Mi
    volumeMounts:
    - name: downward
      mountPath: /etc/downward  # downward 볼륨 /etc/downward에 마운트
  volumes:
  - name: downward              # downwardAPI 볼륨 정의
    downwardAPI:
      items:
      - path: "podName"         # metadata.name에 정의한 이름은 podName 파일에 기록됨
        fieldRef:
          fieldPath: metadata.name
      - path: "podNamespace"
        fieldRef:
          fieldPath: metadata.namespac
      - path: "labels"               # 파드의 레이블은 /etc/downward/labels 파일에 기록됨
        fieldRef:
          fieldPath: metadata.labels
      - path: "annotations"          # 파드의 어노테이션은 /etc/downward/annotations 파일에 기록됨
        fieldRef:
          fieldPath: metadata.annotations
      - path: "containerCpuRequestMilliCores"
        resourceFieldRef:
          containerName: main
          resource: requests.cpu
          divisor: 1m
      - path: "containerMemoryLimitBytes"
        resourceFieldRef:
          containerName: main
          resource: limits.memory
          divisor: 1

마운트된 정보는 다음과 같이 확인 가능하다.

root@master001:~/k8s_in_action/kubernetes-in-action/Chapter08# kubectl exec downward-volume -- ls -lL /etc/downward
total 24
-rw-r--r--    1 root     root           227 May  9 12:16 annotations
-rw-r--r--    1 root     root             2 May  9 12:16 containerCpuRequestMilliCores
-rw-r--r--    1 root     root             8 May  9 12:16 containerMemoryLimitBytes
-rw-r--r--    1 root     root             9 May  9 12:16 labels
-rw-r--r--    1 root     root            15 May  9 12:16 podName
-rw-r--r--    1 root     root             7 May  9 12:16 podNamespace

환경변수로는 전달할 수 없는 label과 annotaion도 전달된 걸 확인할 수 있다.

 

레이블과 어노테이션 업데이트

• downward API 볼륨을 사용하면 파드가 실행 중인 상태에서 레이블과 어노테이션 값이 업데이트 되면 파드가 최신 데이터를 확인하도록 한다.
• 환경변수 방법으로는 업데이트 불가능하다.

 

볼륨 스펙에서 컨테이너 수준의 메타데이터 참조

단 컨테이너의 수준의 메타데이터를 전달하는 경우는 해당 컨테이너의 이름을 지정해야 한다.

spec:
  volumes:
  - name: downward
    downwardAPI:
      items:
      - path: "containerCpuRequestMilliCores"
        resourceFieldRef:
          containerName: main   # 컨테이너 이름 지정
          resource: requests.cpu
          divisor: 1m

😮 DownwardAPI 를 통해 가져올 수 있는 메타데이터는 한정적이기 때문에 더 많은 정보를 위해서는 쿠버네티스 API를 통해 가져와야 한다.

 

8.2 쿠버네티스 API 서버와 통신하기

DownwardAPI는 파드 자체의 메타데이터와 일부 데이터만을 노출한다.

클러스터에 정의된 다른 파드나 리소스에 관한 정보를 애플리케이션에 제공해야 하는 경우 쿠버네티스API를 사용해야 한다.

 

8.2.1 쿠버네티스 REST API 살펴보기

로컬에서 서버의 REST 엔드포인트를 통해 API 서버와 통신하는 방법을 살펴본다.

root@master001:~/k8s_in_action/kubernetes-in-action/Chapter08# kubectl cluster-info
Kubernetes control plane is running at https://172.16.110.10:6443
KubeDNS is running at https://172.16.110.10:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

인증 처리 때문에 해당 url로 서버와 통신하는걸 확인할 수 없다.

그래서 proxy로 localhost에서 HTTP 연결을 수신하도록한다.

root@master001:~/k8s_in_action/kubernetes-in-action/Chapter08# kubectl proxy &
[1] 3103944
root@master001:~/k8s_in_action/kubernetes-in-action/Chapter08# Starting to serve on 127.0.0.1:8001

이제 curl로 로컬 포트 8001번으로 요청을 보낸다.

root@master001:~/k8s_in_action/kubernetes-in-action/Chapter08# curl localhost:8001
{
  "paths": [
    "/.well-known/openid-configuration",
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",
    "/apis/admissionregistration.k8s.io",
    "/apis/admissionregistration.k8s.io/v1",
    "/apis/admissionregistration.k8s.io/v1beta1",
    "/apis/apiextensions.k8s.io",
    "/apis/apiextensions.k8s.io/v1",
    "/apis/apiextensions.k8s.io/v1beta1",
    "/apis/apiregistration.k8s.io",
    "/apis/apiregistration.k8s.io/v1",
    "/apis/apiregistration.k8s.io/v1beta1",
    "/apis/apps",
    "/apis/apps/v1",

proxy로 요청을 보내고 -> proxy가 API 서버로 요청 -> proxy는 API 서버가 반환하는 것을 반환

위의 반환 결과에서 대부분의 리소스 타입을 확인 가능하다.

이러한 경로는 파드, 서비스 등과 같은 리소스를 생성할 때 리소스 정의에 지정한 API 그룹과 버전에 해당한다.

 

배치 API 그룹의 REST 엔드포인트 살펴보기

Job 리소스 API를 살펴보도록 한다.

/apis/batch 경로 뒤에는 다음과 같은 정보가 존재 한다.

root@master001:~/Chapter08# curl http://localhost:8001/apis/batch
{
  "kind": "APIGroup",
  "apiVersion": "v1",
  "name": "batch",
  "versions": [
    {
      "groupVersion": "batch/v1",
      "version": "v1"
    },
    {
      "groupVersion": "batch/v1beta1",
      "version": "v1beta1"
    }
  ],
  "preferredVersion": {
    "groupVersion": "batch/v1",
    "version": "v1"
  }

반환값을 보면 배치 API 그룹에는 v1과 v1beta1 버전이 존재한다. 

그리고 쿠버네티스에서 권장하는 버전은 v1임을 알 수 있다.

 

그러면 /apis/batch/v1 경로에 해당하는 데이터를 확인해 본다.

root@master001:~/Chapter08# curl http://localhost:8001/apis/batch/v1
{
  "kind": "APIResourceList",    # batch/v1 API 그룹 내의 API 리소스 목록
  "apiVersion": "v1",
  "groupVersion": "batch/v1",
  "resources": [                # 이 그룹의 모든 리소스 유형을 담는 배열
    {
      "name": "jobs",            
      "singularName": "",
      "namespaced": true,
      "kind": "Job",      # job 리소스
      "verbs": [          # job 리소스와 함께 사용할 수 있는 명령어(동사)
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],
      "categories": [
        "all"
      ],
      "storageVersionHash": "mudhfqk/qZY="
    },
    {
      "name": "jobs/status",    # 리소스의 상태를 수정하기 위한 별도의 REST 엔드포인트
      "singularName": "",
      "namespaced": true,
      "kind": "Job",
      "verbs": [                # 상태 정보를 검색, 패치, 업데이트 가능
        "get",
        "patch",
        "update"
      ]
    }
  ]

 

8.2.2 파드 내 API 서버와의 통신

이번에는 kubectl이 없는 파드와 쿠버네티스 API 서버가 통신하는 방법을 알아본다.

API 서버와 통신하기 위해서는 다음 세 가지가 수행되어야 한다.

1. API 서버의 위치를 찾는다.
2. 정확한 API 서버와 통신하고 있는지 확인
3. API 서버로 인증

API 서버와의 통신할 파드 실행

apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
  - name: main
    image: tutum/curl
    command: ["sleep", "9999999"]

그리고 해당 컨테이너의 bash 쉘로 접속한다.

root@master001:~/Chapter08# kubectl exec -it curl bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@curl:/# 

해당 pod에서 API 서버와 통신하는 것을 확인해 본다.

이를 위해서는 쿠버네티스 API 서버의 IP와 포트를 찾아야 한다.

root@curl:/# env | grep KUBERNETES_SERVICE
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT_HTTPS=443

위의 변수들은 kubernetes 라는 서비스에서 제공되는 것이다. 

따라서 컨테이너에서 kubernetes로 요청을 보낸다.

root@curl:/# curl https://kubernetes -k
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {

  },
  "code": 403

 

서버의 아이덴티티 검증

• Authorization HTTP 헤더 내부에 토큰을 전달하여 토큰을 인증된 것으로 인식하여 적절한 응답 받기 가능
• 이러한 방식으로 네임스페이스 내에 있는 모든 파드 조회 가능 (curl 파드가 어떤 네임스페이스에서 실행중인지 알아야 함)

# 서버의 인증서가 CA로 서명된 것인지 확인하기 위해 CA 인증서를 지정해서 API 서버에 접속한다.
root@curl:/# export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

root@curl:/# curl https://kubernetes
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {

  },
  "code": 403

 

API 서버로 인증

서버에서 인증을 통과해야 클러스터에 배포된 API 오브젝트를 read, update, delete를 할 수 있다.

이때 인증하기 위해서는 인증 토큰이 필요하다.

이 토근은 default-token 시크릿으로 제공된다. 해당 테이터를 TOKEN 환경변수에 로드해서 API 서버로 요청 보낼때 사용하도록 한다.

root@curl:/# TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

이제 해당 token을 사용해서 API 서버로부터 응답을 받는지 본다.

root@curl:/#  curl -H "Authorization: Bearer $TOKEN" https://kubernetes
{
  "paths": [
    "/.well-known/openid-configuration",
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",
    "/apis/admissionregistration.k8s.io",
    "/apis/admissionregistration.k8s.io/v1",
    "/apis/admissionregistration.k8s.io/v1beta1",
    "/apis/apiextensions.k8s.io",

 

 

 

파드가 쿠버네티스와 통신하는 방법 정리

Pod 내에서 실행 중인 애플리케이션이 쿠버네티스 API에 적절히 액세스 하는 방법을 정리한다.

1. ca.cert : 애플리케이션은 API 서버의 인증서가 인증 기관으로부터 서명된건지 검증해야 하는데, ca.crt 파일이 인증 기관의 인증서이다.
2. token : 애플리케이션은 token 파일의 내용을 Authorization HTTP 헤더에 Bearer 토큰으로 넣어 전송해서 자신을 인증한다.
3. namespace : 파드의 네임스페이스 안에 있는 API 오브젝트의 CRUD(create, read, update, delete) 작업을 수행할 때 네임스페이스를 API 서버로 전달하는데 사용

 

8.2.3 앰배서더 컨테이너를 이용한 API 서버 통신 간소화

지금까지 한 것처럼 HTTPS, 인증서, 인증 토큰을 하나하나 다루는건 까다롭다.

그래서 pod 내에서도 proxy를 사용해서 API로 직접 요청을 보내는 대신 프록시로 요청을 보내 인증, 암호화 등의 작업을 처리할 수 있다.

이를 앰배서더 패턴이라고 한다.

 

앰배서더 컨테이너 패턴

API와 직접 통신하는 대신 매인 컨테이너의 애플리케이션은 HTTP로 앰버서더에 연결하고, 앰버서더 프록시가 API 서버에 대한 https 연결을 처리한다.

 

앰버서더 컨테이너 사용한 curl 파드 실행

kubectl-proxy 이미지를 기반으로 동작하는 ambassador 컨테이너를 포함한 pod를 실행시킨다.

apiVersion: v1
kind: Pod
metadata:
  name: curl-with-ambassador
spec:
  containers:
  - name: main
    image: tutum/curl
    command: ["sleep", "9999999"]
  - name: ambassador
    image: luksa/kubectl-proxy:1.6.2

curl-with-ambassador pod를 생성한 후 main 파드에 들어가 API 서버에 접속한다.

이때 curl을 날리면 ambassador 컨테이너에서 proxy 되도록 한다.

kubectl proxy는 포트 8001에 바인딩 되어 있다.

root@curl-with-ambassador:/# curl localhost:8001
{
  "paths": [
    "/.well-known/openid-configuration",
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",​

 

(여기서 curl을 날리면 바로 위와 같은 api path가 나왔어야 했으나, serviceaccount가 생성되지 않아 403 forbidden이 발생하는 문제가 있었다)

Kubernetes log, User “system:serviceaccount:default:default” cannot get services in the namespace

위 문서에 따라 default ServiceAccount와 Cluster-admin이라는 role을 바인딩하고 해결했다.

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: fabric8-rbac
subjects:
  - kind: ServiceAccount
    # Reference to upper's `metadata.name`
    name: default
    # Reference to upper's `metadata.namespace`
    namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

 

결과적으로, curl로 출력된 결과는 앞서 테스트한 것과 같지만 이번에는 token 생성과 같은 인증 과정을 거칠 필요가 없었다.

• 과정
  • main 컨테이너에서 일반 HTTP 요청을 ambassador 컨테이너로 전달
  • ambassador의 proxy가 HTTPS 요청 + 인증 토큰 + 서버 인증서를 API 서버로 전달
  • 인증 이뤄진 후 main 컨테이너로 요청값 반환

이러한 ambassador container의 단점은 추가 프로세스가 동작하여 리소스가 소비된다는 것이다.

 

 

8.2.4 클라이언트 라이브러리 이용하여 API 서버와 통신

단순한 API 요청의 경우 kubectl-proxy ambassador를 사용하면 되지만, 좀 더 난이도 있는 요청을 처리하기 위해서는 쿠버네티스 API 클라이언트 라이브러리를 사용한다.

 

클라이언트 라이브러리 목록

-> kubernetes.io/ko/docs/reference/using-api/client-libraries/

 

 

Swagger와 OpenAPI를 사용해 자신의 라이브러리 구축

원하는 프로그래밍 언어에 대한 클라이언트가 없는 경우 스웨거 Swagger API 프레임워크로 라이브러리를 생성할 수 있다. Swagger API는 쿠버네티스 API 서버에 탑재되어 있지만 기본적으로는 비활성화 되어 있다.