클러스터에 접근하기

클러스터에 접근하기 (Accessing Clusters)

이 주제에서는 클러스터와 상호작용하는 여러 방법을 다뤄요.

출처: 문서

본문

kubectl로 처음 접근하기

쿠버네티스 API에 처음 접근할 때는 쿠버네티스 CLI인 kubectl을 사용하는 것을 권장해요.

클러스터에 접근하려면 클러스터의 위치를 알고 접근할 자격 증명(credentials)이 필요합니다. 보통 이는 시작하기 가이드를 진행할 때 자동으로 설정되거나, 다른 누군가가 클러스터를 설정하고 자격 증명과 위치를 제공했을 때 가능합니다.

다음 명령으로 kubectl이 알고 있는 위치와 자격 증명을 확인한다:

kubectl config view

많은 예시가 kubectl 사용법을 소개하며, 전체 문서는 kubectl 참조에 있습니다.

REST API에 직접 접근하기

Kubectl은 apiserver를 찾고 인증하는 것을 처리합니다. curl이나 wget 같은 http 클라이언트, 또는 브라우저로 REST API에 직접 접근하려면 몇 가지 방법으로 위치를 찾고 인증할 수 있어요:

• kubectl을 프록시 모드로 실행한다.
  • 권장 접근 방식.
  • 저장된 apiserver 위치를 사용한다.
  • 자체 서명 인증서로 apiserver의 신원을 검증한다. MITM이 불가능하다.
  • apiserver에 인증한다.
  • 향후에는 지능적인 클라이언트 측 로드 밸런싱과 장애 조치를 할 수도 있다.
• 위치와 자격 증명을 http 클라이언트에 직접 제공한다.
  • 대안 접근 방식.
  • 프록시 사용에 혼란을 겪는 일부 유형의 클라이언트 코드에서 동작한다.
  • MITM으로부터 보호하려면 브라우저에 루트 인증서를 가져와야 한다.

kubectl proxy 사용하기

다음 명령은 kubectl을 리버스 프록시 역할을 하는 모드로 실행합니다. apiserver를 찾고 인증하는 것을 처리합니다. 다음과 같이 실행하세요:

kubectl proxy --port=8080

자세한 내용은 kubectl proxy를 참조하세요.

그 다음 curl, wget 또는 브라우저로 API를 탐색할 수 있습니다. IPv6의 경우 localhost를 [::1]로 바꾸세요:

curl http://localhost:8080/api/

출력은 다음과 비슷합니다:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

kubectl proxy 없이

kubectl apply와 kubectl describe secret...을 grep/cut과 함께 사용해 기본 서비스 계정(default service account)의 토큰을 만든다:

먼저, 기본 ServiceAccount의 토큰을 요청하는 Secret을 만든다:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: default-token
  annotations:
    kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

다음으로, 토큰 컨트롤러가 Secret에 토큰을 채울 때까지 기다린다:

while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
  echo "waiting for token..." >&2
  sleep 1
done

생성된 토큰을 캡처해 사용한다:

APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

출력은 다음과 비슷합니다:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

jsonpath 사용:

APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

출력은 다음과 비슷합니다:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

위 예시들은 --insecure 플래그를 사용합니다. 이는 MITM 공격에 취약하게 만듭니다. kubectl이 클러스터에 접근할 때는 저장된 루트 인증서와 클라이언트 인증서를 사용해 서버에 접근합니다. (이것들은 ~/.kube 디렉터리에 설치됩니다). 클러스터 인증서는 보통 자체 서명이므로, http 클라이언트가 루트 인증서를 사용하게 하려면 특별한 구성이 필요할 수 있습니다.

일부 클러스터에서 apiserver는 인증을 요구하지 않습니다. localhost에서 제공되거나 방화벽으로 보호될 수 있습니다. 이에 대한 표준은 없습니다. API 접근 제어는 클러스터 관리자가 이를 구성하는 방법을 설명합니다.

API에 프로그래밍 방식으로 접근하기

쿠버네티스는 공식적으로 Go와 Python 클라이언트 라이브러리를 지원합니다.

Go 클라이언트

• 라이브러리를 얻으려면 go get k8s.io/client-go@kubernetes-<kubernetes-version-number> 명령을 실행하고, 자세한 설치 지침은 INSTALL.md를 참조하세요. 지원되는 버전은 https://github.com/kubernetes/client-go에서 확인할 수 있습니다.
• client-go 클라이언트 위에 애플리케이션을 작성합니다. client-go는 자체 API 객체를 정의하므로, 필요하다면 메인 저장소가 아닌 client-go에서 API 정의를 가져오세요. 예를 들어 import "k8s.io/client-go/kubernetes"가 올바릅니다.

Go 클라이언트는 kubectl CLI와 같은 kubeconfig 파일을 사용해 apiserver를 찾고 인증할 수 있어요. 이 예시를 참조하세요.

애플리케이션이 클러스터 안의 파드로 배포된다면 다음 섹션을 참조하세요.

Python 클라이언트

Python 클라이언트를 사용하려면 pip install kubernetes 명령을 실행하세요. 더 많은 설치 옵션은 Python Client Library 페이지를 참조하세요.

Python 클라이언트는 kubectl CLI와 같은 kubeconfig 파일을 사용해 apiserver를 찾고 인증할 수 있어요. 이 예시를 참조하세요.

다른 언어

다른 언어에서 API에 접근하는 클라이언트 라이브러리가 있습니다. 다른 라이브러리가 어떻게 인증하는지 각각의 문서를 참조하세요.

파드에서 API에 접근하기

파드에서 API에 접근할 때 apiserver를 찾고 인증하는 것은 다소 다릅니다.

자세한 내용은 파드 안에서 API에 접근하기를 확인하세요.

클러스터에서 실행 중인 서비스에 접근하기

이전 섹션은 쿠버네티스 API 서버에 연결하는 방법을 설명했어요. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법에 대한 정보는 클러스터 서비스 접근을 참조하세요.

리다이렉트 요청하기

리다이렉트 기능은 더 이상 사용되지 않고 제거되었습니다. 대신 프록시(아래 참조)를 사용하세요.

다양한 프록시들

쿠버네티스를 사용할 때 접할 수 있는 여러 가지 프록시가 있습니다:

1. kubectl proxy:

   • 사용자의 데스크톱이나 파드에서 실행된다
   • localhost 주소에서 쿠버네티스 apiserver로 프록시한다
   • 클라이언트→프록시는 HTTP를 사용한다
   • 프록시→apiserver는 HTTPS를 사용한다
   • apiserver를 찾는다
   • 인증 헤더를 추가한다

2. apiserver proxy:

   • apiserver에 내장된 배스천(bastion)이다
   • 클러스터 밖의 사용자를 그렇지 않으면 도달할 수 없을 수도 있는 클러스터 IP에 연결한다
   • apiserver 프로세스에서 실행된다
   • 클라이언트→프록시는 HTTPS를 사용한다(apiserver가 그렇게 구성된 경우 http)
   • 프록시→대상은 사용 가능한 정보를 바탕으로 프록시가 선택한 HTTP 또는 HTTPS를 사용할 수 있다
   • 노드, 파드, Service에 도달하는 데 사용할 수 있다
   • Service에 도달할 때 로드 밸런싱을 한다

3. kube proxy:

   • 각 노드에서 실행된다
   • UDP와 TCP를 프록시한다
   • HTTP를 이해하지 못한다
   • 로드 밸런싱을 제공한다
   • 서비스에 도달하는 데만 사용된다

4. apiserver 앞의 Proxy/Load-balancer:

   • 존재와 구현은 클러스터마다 다르다 (예: nginx)
   • 모든 클라이언트와 하나 이상의 apiserver 사이에 위치한다
   • apiserver가 여러 개면 로드 밸런서로 동작한다

5. 외부 서비스의 Cloud Load Balancer:

   • 일부 클라우드 제공자에 의해 제공된다 (예: AWS ELB, Google Cloud Load Balancer)
   • Kubernetes 서비스 type이 LoadBalancer일 때 자동으로 생성된다
   • UDP/TCP만 사용한다
   • 구현은 클라우드 제공자에 따라 다르다

쿠버네티스 사용자는 보통 처음 두 유형 외에는 걱정할 필요가 없습니다. 클러스터 관리자가 보통 나머지 유형이 올바르게 설정되도록 합니다.

더 알아보기 (Learn more)

• Service로 애플리케이션 연결하기
• 클러스터에서 실행 중인 애플리케이션 접근하기
• Service