"Kind 프라이빗 레지스트리"의 두 판 사이의 차이

 
(같은 사용자의 중간 판 8개는 보이지 않습니다)
3번째 줄: 3번째 줄:
;프라이빗 레지스트리
;프라이빗 레지스트리


This guide discusses how to use kind with image registries that require authentication.
이 가이드에서는 인증이 필요한 이미지 레지스트리를 kind에 사용하는 방법을 설명합니다.


There are multiple ways to do this, which we try to cover here.
여러 가지 방법이 있는데, 여기서 살펴보겠습니다.


__TOC__
__TOC__


==ImagePullSecrets 사용==
==ImagePullSecrets 사용==
Kubernetes supports configuring pods to use imagePullSecrets for pulling images. If possible, this is the preferable and most portable route.
Kubernetes는 이미지 pull에 <code>imagePullSecrets</code>를 사용하는 파드 설정을 지원합니다. 가능하다면, 이것이 가장 바람직하고 이식성이 뛰어난 루트입니다.


See the upstream kubernetes docs for this, kind does not require any special handling to use this.
[https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod 이에 대한 업스트림 kubernetes 문서]를 참조하세요. kind에서는 이를 사용하기 위해 특별한 처리가 필요하지 않습니다.


If you already have the config file locally but would still like to use secrets, read through kubernetes’ docs for creating a secret from a file.
로컬에 설정 파일이 이미 있지만 여전히 secret을 사용하고 싶다면, [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials 파일에서 secret을 생성하는 방법]에 대한 kubernetes 문서를 읽어보세요.


==호스트로 pull하고 사이드-로드==
==호스트로 pull하고 사이드-로드==
20번째 줄: 20번째 줄:


==노드에 인증서 추가==
==노드에 인증서 추가==
Generally the upstream docs for using a private registry apply, with kind there are two options for this.
일반적으로 [https://kubernetes.io/docs/concepts/containers/images/#using-a-private-registry 프라이빗 레지스트리 사용]에 대한 업스트림 문서가 적용되며, 이에 대한 두 가지 옵션이 있습니다.


===각 노드에 설정 파일 마운트===
===각 노드에 설정 파일 마운트===
If you pre-create a docker config.json containing credential(s) on the host you can mount it to each kind node.
호스트에 자격증명이 포함된 docker config.json을 미리 생성하는 경우 이를 각 kind 노드에 마운트할 수 있습니다.


Assuming your file is at /path/to/my/secret.json, the kind config would be:
파일이 <code>/path/to/my/secret.json</code>에 있다고 가정하면, kind 설정은 다음과 같습니다.


<syntaxhighlight lang='yaml'>
<syntaxhighlight lang='yaml'>
38번째 줄: 38번째 줄:


====액세스 토큰 사용====
====액세스 토큰 사용====
A credential can be programmatically added to the nodes at runtime.
A 자격증명은 런타임 시 프로그래밍 방식으로 노드에 추가될 수 있습니다.


If you do this then kubelet must be restarted on each node to pick up the new credentials.
이렇게 하면 새 자격증명을 가져오기 위해 각 노드에서 kubelet을 다시 시작해야 합니다.


An example shell snippet for generating a gcr.io cred file on your host machine using Access Tokens:
액세스 토큰을 사용하여 호스트 머신에서 gcr.io cred 파일을 생성하기 위한 예제 쉘 스니펫:


<syntaxhighlight lang='bash'>
<syntaxhighlight lang='bash'>
88번째 줄: 88번째 줄:


====서비스 어카운트 사용====
====서비스 어카운트 사용====
Access tokens are short lived, so you may prefer to use a Service Account and keyfile instead. First, either download the key from the console or generate one with gcloud:
액세스 토큰은 수명이 짧으므로, 대신 서비스 어카운트와 키 파일을 사용하는 것이 좋습니다. 먼저, 콘솔에서 키를 다운로드하거나 gcloud로 키를 생성합니다.


<syntaxhighlight lang='bash'>
<syntaxhighlight lang='bash'>
94번째 줄: 94번째 줄:
</syntaxhighlight>
</syntaxhighlight>


Then, replace the gcloud auth print-access-token | ... line from the access token snippet with:
Then, replace the line from the access token snippet with:
그런 다음, 액세스 토큰 스니핏의 <code>gcloud auth print-access-token | ...</code> 행을 다음으로  교체합니다.


<syntaxhighlight lang='bash'>
<syntaxhighlight lang='bash'>
100번째 줄: 101번째 줄:
</syntaxhighlight>
</syntaxhighlight>


See Google’s upstream docs on key file authentication for more details.
자세한 내용은 키 파일 인증에 대한 Google의 [https://cloud.google.com/container-registry/docs/advanced-authentication#json_key_file 업스트림 문서]를 참조하세요.


====인증서 사용====
====인증서 사용====
If you have a registry authenticated with certificates, and both certificates and keys reside on your host folder, it is possible to mount and use them into the containerd plugin patching the default configuration, like in the example:
인증서로 인증되는 레지스트리가 있고, 인증서와 키가 모두 호스트 폴더에 있는 경우, 다음 예제와 같이, 기본 설정을 패치하도록 <code>containerd</code> 플러그인에 마운트하여 사용할 수 있습니다.


<syntaxhighlight lang='yaml'>
<syntaxhighlight lang='yaml'>

2024년 5월 2일 (목) 19:15 기준 최신판

1 개요[ | ]

Private Registries
프라이빗 레지스트리

이 가이드에서는 인증이 필요한 이미지 레지스트리를 kind에 사용하는 방법을 설명합니다.

여러 가지 방법이 있는데, 여기서 살펴보겠습니다.

2 ImagePullSecrets 사용[ | ]

Kubernetes는 이미지 pull에 imagePullSecrets를 사용하는 파드 설정을 지원합니다. 가능하다면, 이것이 가장 바람직하고 이식성이 뛰어난 루트입니다.

이에 대한 업스트림 kubernetes 문서를 참조하세요. kind에서는 이를 사용하기 위해 특별한 처리가 필요하지 않습니다.

로컬에 설정 파일이 이미 있지만 여전히 secret을 사용하고 싶다면, 파일에서 secret을 생성하는 방법에 대한 kubernetes 문서를 읽어보세요.

3 호스트로 pull하고 사이드-로드[ | ]

kind can load an image from the host with the kind load ... commands. If you configure your host with credentials to pull the desired image(s) and then load them to the nodes you can avoid needing to authenticate on the nodes.

4 노드에 인증서 추가[ | ]

일반적으로 프라이빗 레지스트리 사용에 대한 업스트림 문서가 적용되며, 이에 대한 두 가지 옵션이 있습니다.

4.1 각 노드에 설정 파일 마운트[ | ]

호스트에 자격증명이 포함된 docker config.json을 미리 생성하는 경우 이를 각 kind 노드에 마운트할 수 있습니다.

파일이 /path/to/my/secret.json에 있다고 가정하면, kind 설정은 다음과 같습니다.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraMounts:
  - containerPath: /var/lib/kubelet/config.json
    hostPath: /path/to/my/secret.json

4.1.1 액세스 토큰 사용[ | ]

A 자격증명은 런타임 시 프로그래밍 방식으로 노드에 추가될 수 있습니다.

이렇게 하면 새 자격증명을 가져오기 위해 각 노드에서 kubelet을 다시 시작해야 합니다.

액세스 토큰을 사용하여 호스트 머신에서 gcr.io cred 파일을 생성하기 위한 예제 쉘 스니펫:

#!/bin/sh
set -o errexit

# desired cluster name; default is "kind"
KIND_CLUSTER_NAME="${KIND_CLUSTER_NAME:-kind}"

# create a temp file for the docker config
echo "Creating temporary docker client config directory ..."
DOCKER_CONFIG=$(mktemp -d)
export DOCKER_CONFIG
trap 'echo "Removing ${DOCKER_CONFIG}/*" && rm -rf ${DOCKER_CONFIG:?}' EXIT

echo "Creating a temporary config.json"
# This is to force the omission of credsStore, which is automatically
# created on supported system. With credsStore missing, "docker login"
# will store the password in the config.json file.
# https://docs.docker.com/engine/reference/commandline/login/#credentials-store
cat <<EOF >"${DOCKER_CONFIG}/config.json"
{
 "auths": { "gcr.io": {} }
}
EOF
# login to gcr in DOCKER_CONFIG using an access token
# https://cloud.google.com/container-registry/docs/advanced-authentication#access_token
echo "Logging in to GCR in temporary docker client config directory ..."
gcloud auth print-access-token | \
  docker login -u oauth2accesstoken --password-stdin https://gcr.io

# setup credentials on each node
echo "Moving credentials to kind cluster name='${KIND_CLUSTER_NAME}' nodes ..."
for node in $(kind get nodes --name "${KIND_CLUSTER_NAME}"); do
  # the -oname format is kind/name (so node/name) we just want name
  node_name=${node#node/}
  # copy the config to where kubelet will look
  docker cp "${DOCKER_CONFIG}/config.json" "${node_name}:/var/lib/kubelet/config.json"
  # restart kubelet to pick up the config
  docker exec "${node_name}" systemctl restart kubelet.service
done

echo "Done!"

4.1.2 서비스 어카운트 사용[ | ]

액세스 토큰은 수명이 짧으므로, 대신 서비스 어카운트와 키 파일을 사용하는 것이 좋습니다. 먼저, 콘솔에서 키를 다운로드하거나 gcloud로 키를 생성합니다.

gcloud iam service-accounts keys create <output.json> --iam-account <account email>

Then, replace the line from the access token snippet with: 그런 다음, 액세스 토큰 스니핏의 gcloud auth print-access-token | ... 행을 다음으로 교체합니다.

cat <output.json> | docker login -u _json_key --password-stdin https://gcr.io

자세한 내용은 키 파일 인증에 대한 Google의 업스트림 문서를 참조하세요.

4.1.3 인증서 사용[ | ]

인증서로 인증되는 레지스트리가 있고, 인증서와 키가 모두 호스트 폴더에 있는 경우, 다음 예제와 같이, 기본 설정을 패치하도록 containerd 플러그인에 마운트하여 사용할 수 있습니다.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    # This option mounts the host docker registry folder into
    # the control-plane node, allowing containerd to access them. 
    extraMounts:
      - containerPath: /etc/docker/certs.d/registry.dev.example.com
        hostPath: /etc/docker/certs.d/registry.dev.example.com
containerdConfigPatches:
  - |-
    [plugins."io.containerd.grpc.v1.cri".registry.configs."registry.dev.example.com".tls]
      cert_file = "/etc/docker/certs.d/registry.dev.example.com/ba_client.cert"
      key_file  = "/etc/docker/certs.d/registry.dev.example.com/ba_client.key"

5 참고[ | ]

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}