[ko] Update outdated files in dev-1.21-ko.2 (p1)
Jihoon Seo
parent
c47bc83e41
commit
f4981f1ad6
|
|
@ -1 +1 @@
|
||||||
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:#f9f9f9;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>
|
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:transparent;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>
|
||||||
|
Before Width: | Height: | Size: 4.3 KiB After Width: | Height: | Size: 4.3 KiB |
|
|
@ -304,13 +304,6 @@ ConditionFalse 다.).
|
||||||
{{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다.
|
{{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다.
|
||||||
이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
|
이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
|
||||||
|
|
||||||
|
|
||||||
{{< caution >}}
|
|
||||||
`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는
|
|
||||||
서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에
|
|
||||||
사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다.
|
|
||||||
{{< /caution >}}
|
|
||||||
|
|
||||||
### 노드 용량
|
### 노드 용량
|
||||||
|
|
||||||
노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의
|
노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의
|
||||||
|
|
|
||||||
|
|
@ -170,4 +170,5 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
|
||||||
## {{% heading "whatsnext" %}}
|
## {{% heading "whatsnext" %}}
|
||||||
|
|
||||||
* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다
|
* 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다
|
||||||
|
* [안정 버전의 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 살펴본다
|
||||||
* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다
|
* [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다
|
||||||
|
|
|
||||||
|
|
@ -50,11 +50,10 @@ terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실
|
||||||
### 훅 핸들러 구현
|
### 훅 핸들러 구현
|
||||||
|
|
||||||
컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
|
컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
|
||||||
구현될 수 있는 컨테이너의 훅 핸들러에는 세 가지 유형이 있다.
|
구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.
|
||||||
|
|
||||||
* Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
|
* Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
|
||||||
커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
|
커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
|
||||||
* TCP - 컨테이너의 특정 포트에 대한 TCP 연결을 연다.
|
|
||||||
* HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.
|
* HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.
|
||||||
|
|
||||||
### 훅 핸들러 실행
|
### 훅 핸들러 실행
|
||||||
|
|
|
||||||
|
|
@ -11,7 +11,7 @@ weight: 20
|
||||||
이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
|
이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
|
||||||
|
|
||||||
런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
|
런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
|
||||||
구성은 파드의 컨테이너를 실행하는데 사용된다.
|
구성은 파드의 컨테이너를 실행하는 데 사용된다.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -21,7 +21,7 @@ weight: 20
|
||||||
## 동기
|
## 동기
|
||||||
|
|
||||||
서로 다른 파드간에 런타임클래스를 설정하여
|
서로 다른 파드간에 런타임클래스를 설정하여
|
||||||
성능대 보안의 균형을 유지할 수 있다.
|
성능과 보안의 균형을 유지할 수 있다.
|
||||||
예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
|
예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
|
||||||
하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
|
하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
|
||||||
그러면 몇가지 추가적인 오버헤드는 있지만
|
그러면 몇가지 추가적인 오버헤드는 있지만
|
||||||
|
|
@ -106,7 +106,8 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
|
||||||
|
|
||||||
#### dockershim
|
#### dockershim
|
||||||
|
|
||||||
쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다.
|
dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다.
|
||||||
|
dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
|
||||||
|
|
||||||
#### {{< glossary_tooltip term_id="containerd" >}}
|
#### {{< glossary_tooltip term_id="containerd" >}}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -2,6 +2,10 @@
|
||||||
title: 쿠버네티스 확장
|
title: 쿠버네티스 확장
|
||||||
weight: 110
|
weight: 110
|
||||||
description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
|
description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
|
||||||
|
feature:
|
||||||
|
title: 확장성을 고려하여 설계됨
|
||||||
|
description: >
|
||||||
|
쿠버네티스 업스트림 소스 코드 수정 없이 쿠버네티스 클러스터에 기능을 추가할 수 있다.
|
||||||
content_type: concept
|
content_type: concept
|
||||||
no_list: true
|
no_list: true
|
||||||
---
|
---
|
||||||
|
|
@ -76,19 +80,18 @@ kubectl에서
|
||||||
아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
|
아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
|
||||||
보여주는 다이어그램이다.
|
보여주는 다이어그램이다.
|
||||||
|
|
||||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
|
|
||||||
|
|
||||||
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
|
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## 익스텐션 포인트
|
## 익스텐션 포인트
|
||||||
|
|
||||||
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
|
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
|
||||||
|
|
||||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
|
|
||||||
|
|
||||||
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
|
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
|
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
|
||||||
2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
|
2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
|
||||||
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
||||||
|
|
@ -99,11 +102,10 @@ kubectl에서
|
||||||
|
|
||||||
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
|
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
|
||||||
|
|
||||||
|
|
||||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
|
|
||||||
|
|
||||||
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
|
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## API 익스텐션
|
## API 익스텐션
|
||||||
### 사용자 정의 유형
|
### 사용자 정의 유형
|
||||||
|
|
||||||
|
|
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
|
|
@ -1,201 +0,0 @@
|
||||||
---
|
|
||||||
title: 쿠버네티스 클러스터 확장
|
|
||||||
content_type: concept
|
|
||||||
weight: 10
|
|
||||||
---
|
|
||||||
|
|
||||||
<!-- overview -->
|
|
||||||
|
|
||||||
쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로
|
|
||||||
쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가
|
|
||||||
거의 없다.
|
|
||||||
|
|
||||||
이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
|
|
||||||
쿠버네티스 클러스터를 업무 환경의 요구에 맞게
|
|
||||||
조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를
|
|
||||||
대상으로 한다.
|
|
||||||
잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는
|
|
||||||
쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
|
|
||||||
어떤 익스텐션 포인트와 패턴이 있는지,
|
|
||||||
그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다.
|
|
||||||
|
|
||||||
|
|
||||||
<!-- body -->
|
|
||||||
|
|
||||||
## 개요
|
|
||||||
|
|
||||||
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
|
|
||||||
|
|
||||||
## 구성
|
|
||||||
|
|
||||||
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
|
|
||||||
|
|
||||||
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
|
|
||||||
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
|
|
||||||
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
|
|
||||||
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
|
|
||||||
|
|
||||||
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
|
|
||||||
|
|
||||||
[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다.
|
|
||||||
|
|
||||||
## 익스텐션(Extension) {#익스텐션}
|
|
||||||
|
|
||||||
익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다.
|
|
||||||
이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다.
|
|
||||||
|
|
||||||
대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다.
|
|
||||||
결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고
|
|
||||||
새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다.
|
|
||||||
|
|
||||||
## 익스텐션 패턴
|
|
||||||
|
|
||||||
쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다.
|
|
||||||
쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다.
|
|
||||||
*자동화* 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라
|
|
||||||
고가용성과 강력한 자동화를 작성할 수 있다.
|
|
||||||
자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든
|
|
||||||
쿠버네티스 클러스터에서 작동한다.
|
|
||||||
|
|
||||||
쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다.
|
|
||||||
컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음
|
|
||||||
오브젝트의 `.status`를 업데이트 한다.
|
|
||||||
|
|
||||||
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고
|
|
||||||
원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를
|
|
||||||
*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을
|
|
||||||
추가한다.
|
|
||||||
|
|
||||||
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
|
|
||||||
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
|
|
||||||
바이너리 플러그인은 kubelet(예:
|
|
||||||
[Flex 볼륨 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
|
|
||||||
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
|
|
||||||
kubectl에서
|
|
||||||
사용한다.
|
|
||||||
|
|
||||||
아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
|
|
||||||
보여주는 다이어그램이다.
|
|
||||||
|
|
||||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
|
|
||||||
|
|
||||||
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
|
|
||||||
|
|
||||||
|
|
||||||
## 익스텐션 포인트
|
|
||||||
|
|
||||||
이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
|
|
||||||
|
|
||||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
|
|
||||||
|
|
||||||
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
|
|
||||||
|
|
||||||
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
|
|
||||||
2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다.
|
|
||||||
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
|
|
||||||
4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/#스케줄러-익스텐션) 섹션에 설명되어 있다.
|
|
||||||
5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
|
|
||||||
6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
|
|
||||||
7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다.
|
|
||||||
|
|
||||||
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
|
|
||||||
|
|
||||||
|
|
||||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
|
|
||||||
|
|
||||||
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
|
|
||||||
|
|
||||||
## API 익스텐션
|
|
||||||
### 사용자 정의 유형
|
|
||||||
|
|
||||||
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl`과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
|
|
||||||
|
|
||||||
애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
|
|
||||||
|
|
||||||
커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
|
|
||||||
|
|
||||||
|
|
||||||
### 새로운 API와 자동화의 결합
|
|
||||||
|
|
||||||
사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
|
|
||||||
|
|
||||||
### 빌트인 리소스 변경
|
|
||||||
|
|
||||||
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
|
|
||||||
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다.
|
|
||||||
|
|
||||||
|
|
||||||
### API 접근 익스텐션
|
|
||||||
|
|
||||||
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다.
|
|
||||||
|
|
||||||
이러한 각 단계는 익스텐션 포인트를 제공한다.
|
|
||||||
|
|
||||||
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
|
|
||||||
|
|
||||||
### 인증
|
|
||||||
|
|
||||||
[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다.
|
|
||||||
|
|
||||||
쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
|
|
||||||
|
|
||||||
|
|
||||||
### 승인
|
|
||||||
|
|
||||||
[승인](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인증 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
|
|
||||||
|
|
||||||
|
|
||||||
### 동적 어드미션 컨트롤
|
|
||||||
|
|
||||||
요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다.
|
|
||||||
|
|
||||||
* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다.
|
|
||||||
* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
|
|
||||||
|
|
||||||
## 인프라스트럭처 익스텐션
|
|
||||||
|
|
||||||
|
|
||||||
### 스토리지 플러그인
|
|
||||||
|
|
||||||
[Flex 볼륨](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면
|
|
||||||
Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
|
|
||||||
빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
|
|
||||||
|
|
||||||
|
|
||||||
### 장치 플러그인
|
|
||||||
|
|
||||||
장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
|
|
||||||
통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를
|
|
||||||
발견할 수 있게 해준다.
|
|
||||||
|
|
||||||
### 네트워크 플러그인
|
|
||||||
|
|
||||||
노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해
|
|
||||||
다양한 네트워킹 패브릭을 지원할 수 있다.
|
|
||||||
|
|
||||||
### 스케줄러 익스텐션
|
|
||||||
|
|
||||||
스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
|
|
||||||
컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서
|
|
||||||
기본 스케줄러를 완전히 교체하거나,
|
|
||||||
[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를
|
|
||||||
동시에 실행할 수 있다.
|
|
||||||
|
|
||||||
이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할
|
|
||||||
필요가 없다는 것을 알게 된다.
|
|
||||||
|
|
||||||
스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가
|
|
||||||
파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는
|
|
||||||
[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을
|
|
||||||
지원한다.
|
|
||||||
|
|
||||||
|
|
||||||
## {{% heading "whatsnext" %}}
|
|
||||||
|
|
||||||
* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
|
|
||||||
* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기
|
|
||||||
* 인프라스트럭처 익스텐션에 대해 더 알아보기
|
|
||||||
* [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
|
||||||
* [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
|
|
||||||
* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기
|
|
||||||
* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기
|
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
|
|
@ -53,9 +53,9 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
|
||||||
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
|
`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
|
||||||
|
|
||||||
유효한 레이블 값은 다음과 같다.
|
유효한 레이블 값은 다음과 같다.
|
||||||
* 63 자 이하 여야 하고(공백이면 안 됨),
|
* 63 자 이하여야 하고 (공백일 수도 있음),
|
||||||
* 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
|
* (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
|
||||||
* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)를 중간에 포함할 수 있다.
|
* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다.
|
||||||
|
|
||||||
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
|
유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -72,7 +72,7 @@ spec:
|
||||||
## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels}
|
## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels}
|
||||||
|
|
||||||
[붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는
|
[붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는
|
||||||
표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)를 참고한다.
|
표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/labels-annotations-taints/)를 참고한다.
|
||||||
|
|
||||||
{{< note >}}
|
{{< note >}}
|
||||||
이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.
|
이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.
|
||||||
|
|
|
||||||
|
|
@ -206,9 +206,9 @@ tolerations:
|
||||||
`Ready` 가 "`False`"로 됨에 해당한다.
|
`Ready` 가 "`False`"로 됨에 해당한다.
|
||||||
* `node.kubernetes.io/unreachable`: 노드가 노드 컨트롤러에서 도달할 수 없다. 이는
|
* `node.kubernetes.io/unreachable`: 노드가 노드 컨트롤러에서 도달할 수 없다. 이는
|
||||||
NodeCondition `Ready` 가 "`Unknown`"로 됨에 해당한다.
|
NodeCondition `Ready` 가 "`Unknown`"로 됨에 해당한다.
|
||||||
* `node.kubernetes.io/out-of-disk`: 노드에 디스크가 부족하다.
|
|
||||||
* `node.kubernetes.io/memory-pressure`: 노드에 메모리 할당 압박이 있다.
|
* `node.kubernetes.io/memory-pressure`: 노드에 메모리 할당 압박이 있다.
|
||||||
* `node.kubernetes.io/disk-pressure`: 노드에 디스크 할당 압박이 있다.
|
* `node.kubernetes.io/disk-pressure`: 노드에 디스크 할당 압박이 있다.
|
||||||
|
* `node.kubernetes.io/pid-pressure`: 노드에 PID 할당 압박이 있다.
|
||||||
* `node.kubernetes.io/network-unavailable`: 노드의 네트워크를 사용할 수 없다.
|
* `node.kubernetes.io/network-unavailable`: 노드의 네트워크를 사용할 수 없다.
|
||||||
* `node.kubernetes.io/unschedulable`: 노드를 스케줄할 수 없다.
|
* `node.kubernetes.io/unschedulable`: 노드를 스케줄할 수 없다.
|
||||||
* `node.cloudprovider.kubernetes.io/uninitialized`: "외부" 클라우드 공급자로
|
* `node.cloudprovider.kubernetes.io/uninitialized`: "외부" 클라우드 공급자로
|
||||||
|
|
@ -271,7 +271,7 @@ tolerations:
|
||||||
|
|
||||||
* `node.kubernetes.io/memory-pressure`
|
* `node.kubernetes.io/memory-pressure`
|
||||||
* `node.kubernetes.io/disk-pressure`
|
* `node.kubernetes.io/disk-pressure`
|
||||||
* `node.kubernetes.io/out-of-disk` (*중요한 파드에만 해당*)
|
* `node.kubernetes.io/pid-pressure` (1.14 이상)
|
||||||
* `node.kubernetes.io/unschedulable` (1.10 이상)
|
* `node.kubernetes.io/unschedulable` (1.10 이상)
|
||||||
* `node.kubernetes.io/network-unavailable` (*호스트 네트워크만 해당*)
|
* `node.kubernetes.io/network-unavailable` (*호스트 네트워크만 해당*)
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -935,11 +935,18 @@ Classic ELB의 연결 드레이닝은
|
||||||
# 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.
|
# 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다.
|
||||||
|
|
||||||
service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
|
service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f"
|
||||||
# 생성된 ELB에 추가할 기존 보안 그룹 목록.
|
# 생성된 ELB에 설정할 기존 보안 그룹(security group) 목록.
|
||||||
# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다.
|
# service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체하며,
|
||||||
|
# '해당 ELB를 위한 고유 보안 그룹 생성'을 오버라이드한다.
|
||||||
|
# 목록의 첫 번째 보안 그룹 ID는 인바운드 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향하도록 하는 규칙으로 사용된다.
|
||||||
|
# 여러 ELB가 하나의 보안 그룹 ID와 연결되면, 1줄의 허가 규칙만이 워커 노드 보안 그룹에 추가된다.
|
||||||
|
# 즉, 만약 여러 ELB 중 하나를 지우면, 1줄의 허가 규칙이 삭제되어, 같은 보안 그룹 ID와 연결된 모든 ELB에 대한 접속이 막힌다.
|
||||||
|
# 적절하게 사용되지 않으면 이는 다수의 서비스가 중단되는 상황을 유발할 수 있다.
|
||||||
|
|
||||||
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
|
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e"
|
||||||
# ELB에 추가될 추가 보안 그룹(security group) 목록
|
# 생성된 ELB에 추가할 추가 보안 그룹 목록
|
||||||
|
# 이 방법을 사용하면 이전에 생성된 고유 보안 그룹이 그대로 유지되므로, 각 ELB가 고유 보안 그룹 ID와 그에 매칭되는 허가 규칙 라인을 소유하여
|
||||||
|
# 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향할 수 있도록 한다. 여기에 기재되는 보안 그룹은 여러 서비스 간 공유될 수 있다.
|
||||||
|
|
||||||
service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
|
service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api"
|
||||||
# 로드 밸런서의 대상 노드를 선택하는 데
|
# 로드 밸런서의 대상 노드를 선택하는 데
|
||||||
|
|
@ -988,7 +995,6 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스
|
||||||
| 규칙 | 프로토콜 | 포트 | IP 범위 | IP 범위 설명 |
|
| 규칙 | 프로토콜 | 포트 | IP 범위 | IP 범위 설명 |
|
||||||
|------|----------|---------|------------|---------------------|
|
|------|----------|---------|------------|---------------------|
|
||||||
| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
|
| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
|
||||||
|
|
||||||
| 클라이언트 트래픽 | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
|
| 클라이언트 트래픽 | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
|
||||||
| MTU 탐색 | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
|
| MTU 탐색 | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -29,10 +29,9 @@ weight: 10
|
||||||
쿠버네티스는 다양한 유형의 볼륨을 지원한다. {{< glossary_tooltip term_id="pod" text="파드" >}}는
|
쿠버네티스는 다양한 유형의 볼륨을 지원한다. {{< glossary_tooltip term_id="pod" text="파드" >}}는
|
||||||
여러 볼륨 유형을 동시에 사용할 수 있다.
|
여러 볼륨 유형을 동시에 사용할 수 있다.
|
||||||
임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은
|
임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은
|
||||||
파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서
|
파드의 수명을 넘어 존재한다. 파드가 더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
|
||||||
실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가
|
|
||||||
더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만,
|
|
||||||
퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.
|
퍼시스턴트(persistent) 볼륨은 삭제하지 않는다.
|
||||||
|
볼륨의 종류와 상관없이, 파드 내의 컨테이너가 재시작되어도 데이터는 보존된다.
|
||||||
|
|
||||||
기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드
|
기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드
|
||||||
내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는
|
내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는
|
||||||
|
|
|
||||||
|
|
@ -135,7 +135,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생
|
||||||
|
|
||||||
Eviction API를 사용하여 파드를 축출하면,
|
Eviction API를 사용하여 파드를 축출하면,
|
||||||
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의
|
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의
|
||||||
`terminationGracePeriodSeconds` 설정을 준수하여 정상적으로 [종료됨](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료) 상태가 된다.)
|
`terminationGracePeriodSeconds` 설정을 준수하여 정상적으로 [종료됨](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료) 상태가 된다.
|
||||||
|
|
||||||
## PodDisruptionBudget 예시 {#pdb-example}
|
## PodDisruptionBudget 예시 {#pdb-example}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -58,7 +58,7 @@ graph TB
|
||||||
class zoneA,zoneB cluster;
|
class zoneA,zoneB cluster;
|
||||||
{{< /mermaid >}}
|
{{< /mermaid >}}
|
||||||
|
|
||||||
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/kubernetes-api/labels-annotations-taints/)을 재사용할 수 있다.
|
레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/labels-annotations-taints/)을 재사용할 수 있다.
|
||||||
|
|
||||||
## 파드의 분배 제약 조건
|
## 파드의 분배 제약 조건
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -123,8 +123,8 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
|
||||||
```bash
|
```bash
|
||||||
origin git@github.com:<github_username>/website.git (fetch)
|
origin git@github.com:<github_username>/website.git (fetch)
|
||||||
origin git@github.com:<github_username>/website.git (push)
|
origin git@github.com:<github_username>/website.git (push)
|
||||||
upstream https://github.com/kubernetes/website (fetch)
|
upstream https://github.com/kubernetes/website.git (fetch)
|
||||||
upstream https://github.com/kubernetes/website (push)
|
upstream https://github.com/kubernetes/website.git (push)
|
||||||
```
|
```
|
||||||
|
|
||||||
6. 포크의 `origin/master` 와 `kubernetes/website` 의 `upstream/master` 에서 커밋을 가져온다.
|
6. 포크의 `origin/master` 와 `kubernetes/website` 의 `upstream/master` 에서 커밋을 가져온다.
|
||||||
|
|
|
||||||
|
|
@ -25,7 +25,7 @@ no_list: true
|
||||||
* [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
* [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||||
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
|
* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
|
||||||
* [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항
|
* [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항
|
||||||
* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)
|
* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/labels-annotations-taints/)
|
||||||
|
|
||||||
## 공식적으로 지원되는 클라이언트 라이브러리
|
## 공식적으로 지원되는 클라이언트 라이브러리
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -5,14 +5,15 @@ weight: 50
|
||||||
---
|
---
|
||||||
|
|
||||||
<!-- overview -->
|
<!-- overview -->
|
||||||
|
|
||||||
이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다.
|
이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다.
|
||||||
독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다.
|
독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다.
|
||||||
|
|
||||||
인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다.
|
인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다.
|
||||||
가끔은 서비스 어카운트를 더 잘 설명하기 위해 준비 중인 기능을 참조한다.
|
서비스 어카운트를 더 잘 설명하기 위해, 때때로 미완성 기능이 언급될 수 있다.
|
||||||
|
|
||||||
|
|
||||||
<!-- body -->
|
<!-- body -->
|
||||||
|
|
||||||
## 사용자 어카운트와 서비스 어카운트 비교
|
## 사용자 어카운트와 서비스 어카운트 비교
|
||||||
|
|
||||||
쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
|
쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
|
||||||
|
|
@ -48,37 +49,51 @@ weight: 50
|
||||||
파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
|
파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
|
||||||
이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
|
이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
|
||||||
|
|
||||||
1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다.
|
1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다.
|
||||||
1. 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다.
|
1. 이전 단계는 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다.
|
||||||
1. 파드에 `ImagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `ImagePullSecrets` 이 파드에 추가된다.
|
1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 어느 것도 `false` 로 설정되어 있지 않다면, API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다.
|
||||||
1. 파드에 API 접근을 위한 토큰이 포함된 `volume` 을 추가한다.
|
1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
|
||||||
1. `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
|
1. 파드에 `ImagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `ImagePullSecrets` 이 파드에 추가된다.
|
||||||
|
|
||||||
#### 바인딩된 서비스 어카운트 토큰 볼륨
|
#### 바인딩된 서비스 어카운트 토큰 볼륨
|
||||||
|
|
||||||
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
|
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
|
||||||
|
|
||||||
`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가
|
`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면,
|
||||||
시크릿 볼륨 대신 프로젝티드 서비스 어카운트 토큰 볼륨을 추가한다. 서비스 어카운트 토큰은 기본적으로 1시간 후에 만료되거나 파드가 삭제된다. [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참고한다.
|
토큰 컨트롤러에 의해 생성된 무기한 서비스 어카운트 토큰을 위해, 서비스 어카운트 어드미션 컨트롤러가 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다.
|
||||||
|
|
||||||
이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 활성화된 `RootCAConfigMap` 기능 게이트에 따라 다르다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.
|
```yaml
|
||||||
|
- name: kube-api-access-<random-suffix>
|
||||||
|
projected:
|
||||||
|
defaultMode: 420 # 0644
|
||||||
|
sources:
|
||||||
|
- serviceAccountToken:
|
||||||
|
expirationSeconds: 3600
|
||||||
|
path: token
|
||||||
|
- configMap:
|
||||||
|
items:
|
||||||
|
- key: ca.crt
|
||||||
|
path: ca.crt
|
||||||
|
name: kube-root-ca.crt
|
||||||
|
- downwardAPI:
|
||||||
|
items:
|
||||||
|
- fieldRef:
|
||||||
|
apiVersion: v1
|
||||||
|
fieldPath: metadata.namespace
|
||||||
|
path: namespace
|
||||||
|
```
|
||||||
|
|
||||||
1. 파드에 `serviceAccountName`가 없다면, `serviceAccountName`를
|
프로젝티드 볼륨은 세 가지로 구성된다.
|
||||||
`default`로 설정한다.
|
|
||||||
1. 파드에 참조되는 `serviceAccountName`가 있도록 하고, 그렇지 않으면
|
|
||||||
이를 거부한다.
|
|
||||||
1. 파드에 `imagePullSecrets`이 없는 경우, 서비스어카운트의
|
|
||||||
`imagePullSecrets`이 파드에 추가된다.
|
|
||||||
1. 서비스어카운트 `automountServiceAccountToken` 또는 파드의
|
|
||||||
`automountServiceAccountToken` 이 `false` 로 설정되지 않은 경우
|
|
||||||
파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
|
|
||||||
1. 이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우,
|
|
||||||
`/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된
|
|
||||||
파드의 각 컨테이너에 `volumeSource`를 추가한다.
|
|
||||||
|
|
||||||
`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
|
1. kube-apiserver로부터 TokenRequest API를 통해 얻은 서비스어카운트토큰(ServiceAccountToken). 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다.
|
||||||
서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
|
1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 컨피그맵(ConfigMap). 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 기능 게이트인 `RootCAConfigMap`이 활성화되어 있어야 동작한다. `RootCAConfigMap`은 1.20에서 기본적으로 활성화되어 있으며, 1.21 이상에서는 항상 활성화된 상태이다.
|
||||||
[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한
|
1. 파드의 네임스페이스를 참조하는 DownwardAPI.
|
||||||
자세한 내용을 참조한다.
|
|
||||||
|
상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다.
|
||||||
|
|
||||||
|
`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우,
|
||||||
|
위의 프로젝티드 볼륨을 파드 스펙에 추가하여 시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다.
|
||||||
|
그러나, `RootCAConfigMap`은 활성화되어 있어야 한다.
|
||||||
|
|
||||||
### 토큰 컨트롤러
|
### 토큰 컨트롤러
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue