whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Eleventh Korean l10n work for release 1.18

Browse Source 
- Update outdated files in the dev-1.18-ko.11 branch (#23643)
- Fix inconsistent translation in Ko (#23683)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: Daehyun Paik <paik@a30a.dev>
This commit is contained in:
Daehyun Paik
2020-09-04 14:16:02 +09:00
committed by Seokho Son
parent e79459a064
commit 2a94b058ce
64 changed files with 624 additions and 566 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/controller.md
+36 -37
View File
@@ -6,14 +6,14 @@ weight: 30
<!-- overview -->
로보틱스와 자동화에서 _컨트롤 루프_ 는
로보틱스와 자동화에서 _컨트롤 루프_ 는
시스템 상태를 조절하는 종료되지 않는 루프이다.
컨트롤 루프의 예시: 실내 온도 조절기
사용자는 온도를 설정해서, 사용자가 *의도한 상태* 를
온도 조절기에 알려준다.
*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서
*현재 상태* 이다. 온도 조절기는 장비를 켜거나 꺼서
현재 상태를 의도한 상태에 가깝게 만든다.
{{< glossary_definition term_id="controller" length="short">}}
@@ -28,64 +28,64 @@ weight: 30
컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다.
이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects)
는 의도한 상태를 표현하는 사양 필드를 가지고 있다.
해당 리소스의 컨트롤러(들)은 현재 상태를 의도한
해당 리소스의 컨트롤러(들)은 현재 상태를 의도한
상태에 가깝게 만드는 역할을 한다.
컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로,
쿠버네티스에서는 컨트롤러가
컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로,
쿠버네티스에서는 컨트롤러가
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} 로
유용한 부수적인 효과가 있는 메시지를 발송한다. 그 예시는 아래에서 볼 수 있다.
{{< comment >}}
네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는
오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는
네임스페이스 컨트롤러와 같은 일부 내장된 컨트롤러는 사양을 가지지 않는
오브젝트에 대해 작동한다. 내용의 간결함을 위해서, 이 페이지에서는
자세한 설명을 생략한다.
{{< /comment >}}
### API 서버를 통한 제어
{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스
내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와
{{< glossary_tooltip term_id="job" >}} 컨트롤러는 쿠버네티스
내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와
상호 작용하며 상태를 관리한다.
잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고,
작업을 수행한 다음 중지하는
잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고,
작업을 수행한 다음 중지하는
쿠버네티스 리소스 이다.
(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet
(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet
의 의도한 상태 중 일부가 된다.)
잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서
잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서
노드 집합의 kubelet이 작업을 수행하기에 적합한
수의 파드를 실행하게 한다.
잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다.
대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록
대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록
지시한다.
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의
{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의
다른 컴포넌트는 신규 정보
(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여,
(예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여,
결국 해당 작업을 완료시킨다.
새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다.
잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게
만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서
잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게
만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서
잡이 완료에 가까워 지도록 한다.
또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다.
예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는
잡 오브젝트가 `Finished` 로 표시되도록 업데이트한다.
(이것은 지금 방 온도가 설정한 온도인 것을 표시하기
(이것은 지금 방 온도가 설정한 온도인 것을 표시하기
위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다).
### 직접 제어
잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을
잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을
변경해야 할 필요가 있다.
예를 들어, 만약 컨트롤 루프를 사용해서
예를 들어, 만약 컨트롤 루프를 사용해서
클러스터에 충분한 {{< glossary_tooltip text="노드들" term_id="node" >}}이
있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록
있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록
현재 클러스터 외부의 무언가를 필요로 한다.
외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한
@@ -101,7 +101,7 @@ weight: 30
쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인
변화에 대응할 수 있다.
작업이 발생함에 따라 어떤 시점에서든 클러스터가
작업이 발생함에 따라 어떤 시점에서든 클러스터가
변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로,
클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다.
@@ -110,26 +110,26 @@ weight: 30
## 디자인
디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을
디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을
관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프
(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로
(컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로
만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는
잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를
잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를
확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면,
잡은 다른 컨트롤러가 생성한다.
컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다,
간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를
컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다,
간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를
허용하도록 디자인되었다.
{{< note >}}
동일한 종류의 오브젝트를 만들거나 업데이트하는 여러 컨트롤러가 있을 수 있다.
이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에
이면에, 쿠버네티스 컨트롤러는 컨트롤 하고 있는 리소스에
연결된 리소스에만 주의를 기울인다.
예를 들어, 디플로이먼트와 잡을 가지고 있다. 이 두 가지 모두 파드를 생성한다.
잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다.
이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는
잡 컨트롤러는 디플로이먼트가 생성한 파드를 삭제하지 않는다.
이는 컨트롤러가 해당 파드를 구별하기 위해 사용할 수 있는
정보({{< glossary_tooltip term_id="label" text="레이블" >}})가 있기 때문이다.
{{< /note >}}
@@ -139,14 +139,14 @@ weight: 30
내부에서 실행되는 내장된 컨트롤러 집합이 있다. 이
내장 컨트롤러는 중요한 핵심 동작을 제공한다.
디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의
디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의
자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다.
쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로,
쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로,
어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다.
컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다.
또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다.
소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나,
소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나,
또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에
따라 달라진다.
@@ -154,8 +154,7 @@ weight: 30
## {{% heading "whatsnext" %}}
* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)에 대해 읽기
* [쿠버네티스 오브젝트](/ko/docs/concepts/#쿠버네티스-오브젝트)의 몇 가지 기본 사항을 알아보자.
* [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)에 대해 읽기
* [쿠버네티스 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)의 몇 가지 기본 사항을 알아보자.
* [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자.
* 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다.
content/ko/docs/concepts/cluster-administration/addons.md
+1 -1
View File
@@ -29,7 +29,7 @@ content_type: concept
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
* [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
## 서비스 검색
content/ko/docs/concepts/cluster-administration/cloud-providers.md
+5 -76
View File
@@ -6,7 +6,7 @@ weight: 30
<!-- overview -->
이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에
대해 설명한다.
대해 설명한다. 다른 클라우드 제공자의 프로젝트가 많이 있지만, 여기의 목록은 쿠버네티스 자체에 의존하거나, 포함되어있는 프로젝트로 한정한다.
<!-- body -->
### kubeadm
@@ -116,15 +116,6 @@ AWS 어노테이션에 대한 정보 출처는 [aws.go](https://github.com/kuber
Azure 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름(hostname)을 사용한다.
참고로 쿠버네티스 노드 이름은 Azure VM 이름과 일치해야 한다.
## CloudStack
이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)이다.
### 노드 이름
CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
참고로 쿠버네티스 노드 이름은 CloudStack VM 이름과 일치해야 한다.
## GCE
이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)이다.
@@ -138,11 +129,6 @@ GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으
외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다.
### 노드 이름
HUAWEI CLOUD 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다.
노드에서 kubelet을 시작할 때 반드시 `--hostname-override=<node private IP>` 를 사용한다.
## OpenStack
이 섹션에서는 쿠버네티스와 함께 OpenStack을 사용할 때 사용할 수 있는
모든 구성에 대해 설명한다.
@@ -251,11 +237,9 @@ OpenStack 제공자에 대한 다음의 구성 옵션은 로드 밸런서와 관
값은 `v1` 또는 `v2` 이다. 값이 제공되지 않는 경우 자동 감지는
기본 OpenStack 클라우드에 의해 제공되는 가장 최신의 지원되는 버전을
선택한다.
* `use-octavia` (선택): Octavia LBaaS V2 서비스 카탈로그 엔드포인트를 찾고 사용할지의
여부를 결정하는 데 사용된다. 유효한 값은 `true` 또는 `false` 이다.
`true` 가 지정되고 Octaiva LBaaS V2 항목을 찾을 수 없는 경우,
제공자는 폴백(fall back)하고 대신 Neutron LBaaS V2 엔드포인트를 찾으려고
시도한다. 기본값은 `false` 이다.
* `use-octavia` (선택): Neutron-LBaaS를 사용하는 대신 LoadBalancer 유형의
서비스 구현에 Octavia를 사용할지 여부를 결정한다. 기본값: true
주의: Openstack CCM은 v1.17.0 이후로 기본 로드 밸런서 구현으로 Octavia를 사용한다.
* `subnet-id` (선택): 로드 밸런서를 생성하려는 서브넷의 id를
지정하는 데 사용된다. Network > Networks 에서 찾을 수 있다. 해당
네트워크를 클릭하여 서브넷을 가져온다.
@@ -362,19 +346,7 @@ OpenStack 제공자에 대한 다음의 구성 옵션은 [kubenet]
[kubenet](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)을
사용하는 데 필요하다.
## OVirt
### 노드 이름
OVirt 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
참고로 쿠버네티스 노드 이름은 VM FQDN(Ovirt의 `<vm><guest_info><fqdn>...</fqdn></guest_info></vm>` 아래에서 보고된)과 일치해야 한다.
## Photon
### 노드 이름
Photon 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
참고로 쿠버네티스 노드 이름은 Photon VM 이름(또는 `--cloud-config` 에서 `overrideIP` 가 true로 설정된 경우, 쿠버네티스 노드 이름은 Photon VM IP 주소와 일치해야 함)과 일치해야 한다.
[kubenet]: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet
## vSphere
@@ -388,46 +360,3 @@ vSphere 6.7U3 미만을 사용할 경우, 인-트리 vSphere 클라우드 제공
{{< /tabs >}}
vSphere 클라우드 제공자에 대한 자세한 문서를 보려면, [vSphere 클라우드 제공자 문서 사이트](https://cloud-provider-vsphere.sigs.k8s.io)를 방문한다.
## IBM 클라우드 쿠버네티스 서비스
### 컴퓨트 노드
IBM 클라우드 쿠버네티스 서비스 제공자를 사용하면, 단일 영역 또는 하나의 리전에서 여러 영역에 걸쳐 가상 노드와 물리(베어 메탈) 노드가 혼합된 클러스터를 생성할 수 있다. 자세한 정보는, [클러스터와 워커(worker) 노드 설정 계획](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)을 참고한다.
쿠버네티스 노드 오브젝트의 이름은 IBM 클라우드 쿠버네티스 서비스 워커 노드 인스턴스의 프라이빗 IP 주소이다.
### 네트워킹
IBM 클라우드 쿠버네티스 서비스 제공자는 노드의 네트워크 성능 품질과 네트워크 격리를 위한 VLAN을 제공한다. 사용자 정의 방화벽 및 Calico 네트워크 폴리시를 설정하여 클러스터에 추가적인 보안 계층을 추가하거나 VPN을 통해 온-프레미스 데이터센터에 클러스터를 연결할 수 있다. 자세한 내용은 [클러스터 네트워킹 구성](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)을 참고한다.
퍼블릭 또는 클러스터 내에서 앱을 노출하기 위해 노드포트(NodePort), 로드밸런서 또는 인그레스 서비스를 활용할 수 있다. 어노테이션을 사용하여 인그레스 애플리케이션 로드 밸런서를 커스터마이징 할 수도 있다. 자세한 내용은 [앱을 노출할 서비스 선택하기](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)을 참고한다.
### 스토리지
IBM 클라우드 쿠버네티스 서비스 제공자는 쿠버네티스-네이티브 퍼시스턴트 볼륨을 활용하여 사용자가 파일, 블록 및 클라우드 오브젝트 스토리지를 앱에 마운트할 수 있도록 한다. 데이터를 지속적으로 저장하기 위해 서비스로서의-데이터베이스(database-as-a-service)와 써드파티 애드온을 사용할 수도 있다. 자세한 정보는 [고가용성 퍼시스턴트 스토리지 계획](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)을 참고한다.
## Baidu 클라우드 컨테이너 엔진
### 노드 이름
Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 프라이빗 IP 주소를 사용한다.
참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다.
## Tencent 쿠버네티스 엔진
이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다.
### 노드 이름
Tencent 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
참고로 쿠버네티스 노드 이름은 Tencent VM 프라이빗 IP와 일치해야 한다.
## Alibaba 클라우드 쿠버네티스
이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)이다.
### 노드 이름
Alibaba 클라우드는 노드 이름의 형식을 요구하지는 않지만, kubelet은 `--provider-id=${REGION_ID}.${INSTANCE_ID}` 를 추가해야만 한다. 파라미터 `${REGION_ID}` 는 쿠버네티스의 지역 ID에 해당하고, `${INSTANCE_ID}` 는 Alibaba ECS (Elastic Compute Service) ID를 의미한다.
### 로드 밸런서
[어노테이션](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)을 구성해서 Alibaba 클라우드의 특정 기능을 사용하도록 외부 로드 밸런서를 설정할 수 있다.
content/ko/docs/concepts/configuration/manage-resources-containers.md
+2 -2
View File
@@ -112,7 +112,7 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다.
`memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다.
E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를
일반 정수 또는 고정 소수점 정수로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와
같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.
```shell
@@ -311,7 +311,7 @@ _임시-스토리지_ 를 사용하여 로컬 임시 저장소를 관리할 수
* `spec.containers[].resources.requests.ephemeral-storage`
`ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와
같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 정수로 표현할 수 있다.
같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다.
Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다.
예를 들어, 다음은 대략 동일한 값을 나타낸다.
content/ko/docs/concepts/configuration/resource-bin-packing.md
+1 -1
View File
@@ -168,7 +168,7 @@ Node Score:
intel.com/foo = resourceScoringFunction((2+2),8)
= (100 - ((8-4)*100/8)
= (100 - 25)
= (100 - 50)
= 50
= rawScoringFunction(50)
= 5
content/ko/docs/concepts/configuration/secret.md
+4
View File
@@ -350,6 +350,8 @@ NAME TYPE DATA
db-user-pass-96mffmfh4k Opaque 2 51s
```
시크릿에 대한 설명을 볼 수 있다.
```shell
kubectl describe secrets/db-user-pass-96mffmfh4k
```
@@ -1000,6 +1002,8 @@ kubectl create secret generic prod-db-secret --from-literal=username=produser --
secret "prod-db-secret" created
```
테스트 환경의 자격 증명에 대한 시크릿을 만들 수도 있다.
```shell
kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
```
content/ko/docs/concepts/containers/images.md
+2 -2
View File
@@ -94,7 +94,7 @@ weight: 10
이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다.
{{< note >}}
쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다.
기본 쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다.
도커 자격 증명 도우미(`credHelpers` 또는 `credsStore`)는 지원되지 않는다.
{{< /note >}}
@@ -262,7 +262,7 @@ EOF
이것은 프라이빗 레지스트리를 사용하는 각 파드에 대해서 수행될 필요가 있다.
그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-accounts/)) 리소스에
그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 리소스에
imagePullSecrets을 셋팅하여 자동화할 수 있다.
자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다.
content/ko/docs/concepts/extend-kubernetes/extend-cluster.md
+1 -1
View File
@@ -93,7 +93,7 @@ kubectl에서
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/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다.
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/#스토리지-플러그인)을 통해 지원될 수 있다.
content/ko/docs/concepts/extend-kubernetes/operator.md
+1 -4
View File
@@ -9,7 +9,7 @@ weight: 30
오퍼레이터(Operator)는
[사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를
사용하여 애플리케이션 및 해당 컴포넌트를 관리하는 쿠버네티스의 소프트웨어 익스텐션이다. 오퍼레이터는
쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)를 따른다.
쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/architecture/controller/)를 따른다.
<!-- body -->
@@ -126,6 +126,3 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
* 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기
* 오퍼레이터 패턴을 소개한 [CoreOS 원본 기사](https://coreos.com/blog/introducing-operators.html) 읽기
* 오퍼레이터 구축을 위한 모범 사례에 대한 구글 클라우드(Google Cloud)의 [기사](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) 읽기
content/ko/docs/concepts/storage/persistent-volumes.md
+10
View File
@@ -248,6 +248,16 @@ FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하
EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다.
{{< /note >}}
#### 볼륨 확장 시 오류 복구
기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다.
1. 퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 `Retain` 반환 정책으로 표시한다.
2. PVC를 삭제한다. PV에는 `Retain` 반환 정책이 있으므로 PVC를 재생성할 때 데이터가 손실되지 않는다.
3. 새 PVC를 바인딩할 수 있도록 PV 명세에서 `claimRef` 항목을 삭제한다. 그러면 PV가 `Available` 상태가 된다.
4. PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 `volumeName` 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다.
5. PV의 반환 정책을 복원하는 것을 잊지 않는다.
## 퍼시스턴트 볼륨의 유형
content/ko/docs/concepts/storage/volume-snapshots.md
+2 -2
View File
@@ -87,14 +87,14 @@ spec:
사전 프로비저닝된 스냅샷의 경우, 다음 예와 같이 `volumeSnapshotContentName`을 스냅샷 소스로 지정해야 한다. 사전 프로비저닝된 스냅샷에는 `volumeSnapshotContentName` 소스 필드가 필요하다.
```
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
name: test-snapshot
spec:
source:
volumeSnapshotContentName: test-content
volumeSnapshotContentName: test-content
```
## 볼륨 스냅샷 컨텐츠
content/ko/docs/concepts/workloads/controllers/daemonset.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: 데몬셋
content_type: concept
weight: 50
weight: 40
---
<!-- overview -->
content/ko/docs/concepts/workloads/controllers/deployment.md
+6 -6
View File
@@ -6,7 +6,7 @@ feature:
쿠버네티스는 애플리케이션 또는 애플리케이션의 설정 변경시 점진적으로 롤아웃하는 동시에 애플리케이션을 모니터링해서 모든 인스턴스가 동시에 종료되지 않도록 보장한다. 만약 어떤 문제가 발생하면 쿠버네티스는 변경 사항을 롤백한다. 성장하는 디플로이먼트 솔루션 생태계를 이용한다.
content_type: concept
weight: 30
weight: 10
---
<!-- overview -->
@@ -82,7 +82,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다.
```shell
```
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
@@ -98,21 +98,21 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
3. 디플로이먼트의 롤아웃 상태를 보려면, `kubectl rollout status deployment.v1.apps/nginx-deployment` 를 실행한다.
다음과 유사하게 출력된다.
```shell
```
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. 몇 초 후 `kubectl get deployments` 를 다시 실행한다.
다음과 유사하게 출력된다.
```shell
```
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
디플로이먼트에서 3개의 레플리카가 생성되었고, 모든 레플리카는 최신 상태(최신 파드 템플릿을 포함)이며 사용 가능한 것을 알 수 있다.
5. 디플로이먼트로 생성된 레플리카셋(`rs`)을 보려면, `kubectl get rs` 를 실행한다. 다음과 유사하게 출력된다.
```shell
```
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
@@ -129,7 +129,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
6. 각 파드에 자동으로 생성된 레이블을 보려면, `kubectl get pods --show-labels` 를 실행한다.
다음과 유사하게 출력된다.
```shell
```
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: 가비지(Garbage) 수집
content_type: concept
weight: 70
weight: 60
---
<!-- overview -->
content/ko/docs/concepts/workloads/controllers/job.md
+1 -1
View File
@@ -5,7 +5,7 @@ feature:
title: 배치 실행
description: >
쿠버네티스는 서비스 외에도 배치와 CI 워크로드를 관리할 수 있으며, 원하는 경우 실패한 컨테이너를 교체할 수 있다.
weight: 70
weight: 50
---
<!-- overview -->
content/ko/docs/concepts/workloads/controllers/replicaset.md
+4 -3
View File
@@ -1,7 +1,7 @@
---
title: 레플리카셋
content_type: concept
weight: 10
weight: 20
---
<!-- overview -->
@@ -241,9 +241,10 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
`.spec.selector` 필드는 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)이다.
[앞서](#레플리카-셋의-작동-방식) 논의한 것처럼 이 레이블은 소유될 가능성이 있는 파드를 식별하는데 사용된다.
우리 `frontend.yaml` 예제에서의 셀렉터는 다음과 같다.
```shell
```yaml
matchLabels:
tier: frontend
tier: frontend
```
레플리카셋에서 `.spec.template.metadata.labels`는 `spec.selector`과 일치해야 하며
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+2 -2
View File
@@ -7,7 +7,7 @@ feature:
오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다.
content_type: concept
weight: 20
weight: 90
---
<!-- overview -->
@@ -112,7 +112,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
레플리케이션 컨트롤러 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/).
컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다.
content/ko/docs/concepts/workloads/controllers/statefulset.md
+1 -1
View File
@@ -1,7 +1,7 @@
---
title: 스테이트풀셋
content_type: concept
weight: 40
weight: 30
---
<!-- overview -->
content/ko/docs/concepts/workloads/pods/_index.md
+1 -1
View File
@@ -255,7 +255,7 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
* [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
* [PodDisruptionBudget](https://kubernetes.io/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
* 파드는 쿠버네티스 REST API의 최상위 리소스이다.
[파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
오브젝트 정의는 오브젝트를 상세히 설명한다.