First Korean l10n work for release-1.19
- Translate tasks/job/parallel-processing-expansion.md into Korean (#23544) - Fix issue with ko/docs/concepts/workloads/controllers/job.md (#23720) - Translate reference/scheduling/policies.md in Korean (#23690) - Update outdated files in the dev-1.19-ko.1 branch (#23702) - Modify translation access by Korean glossary (#23627) Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: junghyeonsu <54893898+junghyeonsu@users.noreply.github.com> Co-authored-by: coolguyhong <podolsmith@naver.com>
This commit is contained in:
June Yi
@@ -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/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
|
||||
|
||||
## 서비스 검색
|
||||
|
||||
|
||||
@@ -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 클라우드의 특정 기능을 사용하도록 외부 로드 밸런서를 설정할 수 있다.
|
||||
|
||||
@@ -6,7 +6,7 @@ weight: 60
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
애플리케이션과 시스템 로그는 클러스터 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
|
||||
애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 따라서, 대부분의 컨테이너 엔진은 일종의 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
|
||||
|
||||
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다.
|
||||
|
||||
@@ -91,6 +91,7 @@ GCP의 COS 이미지 로깅을 설정하는 방법에 대한 자세한 정보를
|
||||
그 후 `kubectl logs` 는 빈 응답을 반환한다.
|
||||
{{< /note >}}
|
||||
|
||||
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
|
||||
### 시스템 컴포넌트 로그
|
||||
|
||||
시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다.
|
||||
@@ -257,5 +258,3 @@ fluentd를 구성하는 것에 대한 자세한 내용은,
|
||||
모든 애플리케이션에서 직접 로그를 노출하거나 푸시하여 클러스터-레벨 로깅을
|
||||
구현할 수 있다. 그러나, 이러한 로깅 메커니즘의 구현은
|
||||
쿠버네티스의 범위를 벗어난다.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user