스터디/[쿠버네티스 인 액션] (2024.8)

[쿠버네티스 인 액션] 8장. 애플리케이션 파드 메타데이터와 그 외의 리소스에 엑세스하기

ttoance 2024. 10. 9. 14:48

8.1 Downward(하강) API 로 메타데이터 전달 

- 7장 환경변수, 컨피그맵, 시크릿 볼륨은 이미 알고 있는 데이터에 적합하다

- but 파드의 IP, 호스트 노드 이름 또는 파드 자체의 이름과 같이 실행시점까지 알려지지 않은 데이터의 경우에 대해서 해결방법이 필요하다 >  Downward API  

 

 Downward API  

- 환경변수 또는 파일로 파드의 해당 환경의 메타 데이터를 전달할 수 있다. 

 

  • API 서버: 이 서버는 포드와 관련된 메타데이터와 상태 정보를 제공합니다. 그림에서 '포드 매니페스트'라는 문서에 메타데이터와 상태 정보를 포함하고 있습니다.
  • 포드 매니페스트: 포드와 관련된 구성 정보와 현재 상태를 정의합니다. 여기에는 포드의 이름, 네임스페이스 등 메타데이터와 상태 정보가 포함됩니다.
  • 컨테이너(main): 포드 안의 애플리케이션을 실행하는 컨테이너입니다. 이 컨테이너는 환경 변수로부터 정보를 받아 애플리케이션 프로세스에서 사용합니다.
  • downwardAPI 볼륨: 포드 내에서 메타데이터를 파일 형태로 컨테이너에 전달하는 방법을 나타냅니다. 애플리케이션은 이 정보를 읽어서 사용할 수 있습니다.

 

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

> 파드의 이름

> 파드의 IP 주소 

> 파드가 속한 네임스페이스 

> 파드가 실행 중인 노드의 이름

> 파드가 실행 중인 서비스 어카운트 이름

> 각 컨테이너의 CPU와 메모리 요청 

> 각 컨테이너의 CPU와 메모리 제한

> 파드의 레이블

> 파드의 어노테이션

 

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

https://github.com/luksa/kubernetes-in-action/blob/master/Chapter08/downward-api-env.yaml

 

kubernetes-in-action/Chapter08/downward-api-env.yaml at master · luksa/kubernetes-in-action

Code from the Kubernetes in Action book. Contribute to luksa/kubernetes-in-action development by creating an account on GitHub.

github.com

파드의 이름, IP와 네임스페이스는 환경변수로 노출한다.

 

컨테이너 내부에서 실행되는 모든 프로세스는 해당 변수를 읽을 수 있고, 필요한 대로 사용할 수 있ㄷ. 

 

- downwardAPI 볼륨에 파일로 메타데이터 전달 

https://github.com/luksa/kubernetes-in-action/blob/master/Chapter08/downward-api-volume.yaml

 

kubernetes-in-action/Chapter08/downward-api-volume.yaml at master · luksa/kubernetes-in-action

Code from the Kubernetes in Action book. Contribute to luksa/kubernetes-in-action development by creating an account on GitHub.

github.com

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

 

> 파드가 실행되는 동안 레이블과 어노테이션을 수정할 수 있다. 파일을 업데이트 해서 항상 최신 데이터 볼 수 있도록 설정한다. 

 

 

=> downward api를 사용하면 환경변수의 특정 데이터 활용하는 애플리케이션 짤때 유용하다 

but 사용 가능한 메타 데이터가 제한적이기 때문에 이 경우 쿠버네티스 API 서버를 통해 직접 가져오면 된다. 

 


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

 

로컬 서버에서 API 서버와 통신하는 방법

 kubectl proxy 

- 프록시 서버를 실행해 로컬 컴퓨터에서 HTTP 연결을 수신하고, 이 연결을 인증을 관리하면서 API 서버로 전달하기 때문에,

요청할 때마다 인증 토큰을 전달할 필요가 없다. 

- 또한 각 요청마다 서버의 인증서를 확인해 중간자가 아닌 실제 API 서버와 통신한다는 것을 담보한다. 

- 작동 흐름  

  1. 사용자가 kubectl proxy --port=8080 명령을 실행합니다.
  2. 로컬 컴퓨터에서 8080 포트를 통해 프록시 서버가 실행됩니다.
  3. 사용자가 http://localhost:8080/api/v1/namespaces로 HTTP 요청을 보냅니다.
  4. kubectl proxy는 이 요청을 받아서 Kubernetes API 서버로 전달합니다. 이때 인증은 사용자의 자격 증명을 기반으로 자동으로 수행됩니다.
  5. API 서버는 요청을 처리하고 응답을 프록시로 보냅니다.
  6. kubectl proxy는 API 서버의 응답을 다시 사용자에게 반환합니다.

 

kubectl proxy

 

# 클러스터에 있는 모든 잡 인스턴스 나열
/apis/batch/v1/jobs

# 이름별로 특정 잡 인스턴스 검색
/apis/batch/v1/namespaces/default/jobs/my-job

 

 

 

kubectl이 없는 파드 내에서 통신하는 방법 

- 파드 내부에서 통신하려면 다음 세 가지 처리해야 한다

> API 서버의 위치를 찾아야 한다. 

> API 서버와 통신하고 있는지 확인해야 한다. 

> API 서버로 인증해야 한다. 

 

1) API 서버와 통신을 시도하기 위한 파드 실행 

https://github.com/luksa/kubernetes-in-action/blob/master/Chapter08/curl.yaml

 

kubernetes-in-action/Chapter08/curl.yaml at master · luksa/kubernetes-in-action

Code from the Kubernetes in Action book. Contribute to luksa/kubernetes-in-action development by creating an account on GitHub.

github.com

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

- 컨터이너에서 curl 사용해야 하기 때문에 tutum/curl 이미지 사용 

- 계속 실행되도록 하기 위해 sleep 커멘드 실행 

 

2) API 서버 주소 찾기 

https://kubernetes 로 접근 

 

3) 서버의 아이덴티티 검증으로 token 설정 

- 인증 기관의 인증서는 ca.cart파일에 있다 

- token파일의 내용을 Authorization HTTP 헤더에 bearer 토큰으로 넣어 전송해서 인증해야 한다. 

반응형