From 20b88e92c0d4f1e010aec481027a99fd0935b577 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Tue, 14 Mar 2023 10:29:45 +0900 Subject: [PATCH] [ko] Update outdated files in `dev-1.26-ko.1` (M8-M9,M127-M133) --- .../concepts/cluster-administration/addons.md | 1 + .../cluster-administration/logging.md | 248 ++++++++++++------ ...-dockershim-and-cri-compatible-runtimes.md | 1 + .../ko/docs/reference/scheduling/_index.md | 2 +- .../ko/docs/reference/scheduling/policies.md | 1 + .../ko/docs/reference/setup-tools/_index.md | 2 +- content/ko/docs/reference/tools/_index.md | 2 +- content/ko/docs/reference/using-api/_index.md | 25 +- .../reference/using-api/client-libraries.md | 3 +- 9 files changed, 184 insertions(+), 101 deletions(-) diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 3ba3e35c2a..971b78be79 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -1,6 +1,7 @@ --- title: 애드온 설치 content_type: concept +weight: 120 --- diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index a9ea47332c..93b93eb761 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -9,24 +9,35 @@ weight: 60 -애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. +애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. +로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. +대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. +마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. +컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다. -그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. +그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 +완전한 로깅 솔루션으로 충분하지 않다. -예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것이다. +예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에 +애플리케이션의 로그에 접근하고 싶을 것이다. -클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. +클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 +별도의 스토리지와 라이프사이클을 가져야 한다. +이 개념을 [클러스터-레벨 로깅](#cluster-level-logging-architectures)이라고 한다. + +클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다. +쿠버네티스가 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만, +쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다. +아래 내용은 로그를 어떻게 처리하고 관리하는지 설명한다. -클러스터-레벨 로깅은 로그를 저장, 분석, 쿼리하기 위해서는 별도의 백엔드가 필요하다. 쿠버네티스가 -로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지는 않지만, -쿠버네티스에 통합될 수 있는 기존의 로깅 솔루션이 많이 있다. +## 파드와 컨테이너 로그 {#basic-logging-in-kubernetes} -## 쿠버네티스의 기본 로깅 +쿠버네티스는 실행중인 파드의 컨테이너에서 출력하는 로그를 감시한다. -이 예시는 텍스트를 초당 한 번씩 표준 출력에 쓰는 -컨테이너에 대한 `Pod` 명세를 사용한다. +아래 예시는, 초당 한 번씩 표준 출력에 텍스트를 기록하는 +컨테이너를 포함하는 `파드` 매니페스트를 사용한다. {{< codenew file="debug/counter-pod.yaml" >}} @@ -51,10 +62,9 @@ kubectl logs counter 출력은 다음과 같다. ```console -0: Mon Jan 1 00:00:00 UTC 2001 -1: Mon Jan 1 00:00:01 UTC 2001 -2: Mon Jan 1 00:00:02 UTC 2001 -... +0: Fri Apr 1 11:42:23 UTC 2022 +1: Fri Apr 1 11:42:24 UTC 2022 +2: Fri Apr 1 11:42:25 UTC 2022 ``` `kubectl logs --previous` 를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다. @@ -67,72 +77,129 @@ kubectl logs counter -c count 자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다. -## 노드 레벨에서의 로깅 +### 노드가 컨테이너 로그를 처리하는 방법 ![노드 레벨 로깅](/images/docs/user-guide/logging/logging-node-level.png) -컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 엔진이 처리 및 리디렉션 한다. -예를 들어, 도커 컨테이너 엔진은 이 두 스트림을 [로깅 드라이버](https://docs.docker.com/engine/admin/logging/overview)로 리디렉션 한다. 이 드라이버는 쿠버네티스에서 JSON 형식의 파일에 작성하도록 구성된다. +컨테이너화된 애플리케이션의 `stdout(표준 출력)` 및 `stderr(표준 에러)` 스트림에 의해 생성된 모든 출력은 컨테이너 런타임이 처리하고 리디렉션 시킨다. +다양한 컨테이너 런타임들은 이를 각자 다른 방법으로 구현하였지만, +kubelet과의 호환성은 _CRI 로깅 포맷_ 으로 표준화되어 있다. -{{< note >}} -도커 JSON 로깅 드라이버는 각 라인을 별도의 메시지로 취급한다. 도커 로깅 드라이버를 사용하는 경우, 멀티-라인 메시지를 직접 지원하지 않는다. 로깅 에이전트 레벨 이상에서 멀티-라인 메시지를 처리해야 한다. -{{< /note >}} +기본적으로 컨테이너가 재시작하는 경우, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. +파드가 노드에서 축출되면, 해당하는 모든 컨테이너와 로그가 함께 축출된다. -기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다. +kubelet은 쿠버네티스의 특정 API를 통해 사용자들에게 로그를 공개하며, +일반적으로 `kubectl logs`를 통해 접근할 수 있다. -노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여, -로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는 -로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로 -이를 해결하기 위한 솔루션을 설정해야 한다. -예를 들어, `kube-up.sh` 스크립트에 의해 배포된 쿠버네티스 클러스터에는, -매시간 실행되도록 구성된 [`logrotate`](https://linux.die.net/man/8/logrotate) -도구가 있다. 애플리케이션의 로그를 자동으로 -로테이션하도록 컨테이너 런타임을 설정할 수도 있다. +### 로그 로테이션 -예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은 -[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해 -자세히 알 수 있다. +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다. -kubelet은 이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다. -[kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/)에 있는 -두 개의 kubelet 파라미터 [`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를 -사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다. +kubelet이 로그를 자동으로 로테이트하도록 설정할 수 있다. + +로테이션을 구성해놓으면, kubelet은 컨테이너 로그를 로테이트하고 로깅 경로 구조를 관리한다. +kubelet은 이 정보를 컨테이너 런타임에 전송하고(CRI를 사용), +런타임은 지정된 위치에 컨테이너 로그를 기록한다. + +[kubelet 설정 파일](/docs/tasks/administer-cluster/kubelet-config-file/)을 사용하여 +두 개의 kubelet 파라미터 +[`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를 설정 가능하다. +이러한 설정을 통해 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다. 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를 -실행하면, 노드의 kubelet이 요청을 처리하고 -로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다. +실행하면, 노드의 kubelet이 요청을 처리하고 로그 파일에서 직접 읽는다. +kubelet은 로그 파일의 내용을 반환한다. + {{< note >}} -만약, 일부 외부 시스템이 로테이션을 수행했거나 CRI 컨테이너 런타임이 사용된 경우, -`kubectl logs` 를 통해 최신 로그 파일의 내용만 -사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가 -로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일) -`kubectl logs` 는 이 예시에서는 빈 응답에 해당하는 최신 로그 파일을 반환한다. +`kubectl logs`를 통해서는 +최신 로그만 확인할 수 있다. + +예를 들어, 파드가 40MiB 크기의 로그를 기록했고 kubelet이 10MiB 마다 로그를 로테이트하는 경우 +`kubectl logs`는 최근의 10MiB 데이터만 반환한다. {{< /note >}} -### 시스템 컴포넌트 로그 +## 시스템 컴포넌트 로그 -시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. +시스템 컴포넌트에는 두 가지 유형이 있는데, 컨테이너에서 실행되는 것과 실행 중인 컨테이너와 관련된 것이다. 예를 들면 다음과 같다. -* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다. -* Kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다. +* kubelet과 컨테이너 런타임은 컨테이너에서 실행되지 않는다. + kubelet이 컨테이너({{< glossary_tooltip text="파드" term_id="pod" >}}와 그룹화된)를 실행시킨다. +* 쿠버네티스의 스케줄러, 컨트롤러 매니저, API 서버는 + 파드(일반적으로 {{< glossary_tooltip text="스태틱 파드" term_id="static-pod" >}})로 실행된다. + etcd는 컨트롤 플레인에서 실행되며, 대부분의 경우 역시 스태틱 파드로써 실행된다. + 클러스터가 kube-proxy를 사용하는 경우는 `데몬셋(DaemonSet)`으로써 실행된다. -systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 journald에 작성한다. -systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/log` 디렉터리의 -`.log` 파일에 작성한다. 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고, -항상 `/var/log` 디렉터리에 기록한다. -시스템 컴포넌트는 [klog](https://github.com/kubernetes/klog) -로깅 라이브러리를 사용한다. [로깅에 대한 개발 문서](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에서 -해당 컴포넌트의 로깅 심각도(severity)에 대한 규칙을 찾을 수 있다. +### 로그의 위치 {#log-location-node} -컨테이너 로그와 마찬가지로, `/var/log` 디렉터리의 시스템 컴포넌트 로그를 -로테이트해야 한다. `kube-up.sh` 스크립트로 구축한 쿠버네티스 클러스터에서 -로그는 매일 또는 크기가 100MB를 초과하면 -`logrotate` 도구에 의해 로테이트가 되도록 구성된다. +kubelet과 컨테이너 런타임이 로그를 기록하는 방법은, +노드의 운영체제에 따라 다르다. -## 클러스터 레벨 로깅 아키텍처 +{{< tabs name="log_location_node_tabs" >}} +{{% tab name="리눅스" %}} + +systemd를 사용하는 시스템에서는 kubelet과 컨테이너 런타임은 기본적으로 로그를 journald에 작성한다. +`journalctl`을 사용하여 이를 확인할 수 있다. +예를 들어 `journalctl -u kubelet`. + +systemd를 사용하지 않는 시스템에서, kubelet과 컨테이너 런타임은 로그를 `/var/log` 디렉터리의 `.log` 파일에 작성한다. +다른 경로에 로그를 기록하고 싶은 경우에는, `kube-log-runner`를 통해 +간접적으로 kubelet을 실행하여 +kubelet의 로그를 지정한 디렉토리로 리디렉션할 수 있다. + +kubelet을 실행할 때 `--log-dir` 인자를 통해 로그가 저장될 디렉토리를 지정할 수 있다. +그러나 해당 인자는 더 이상 지원되지 않으며(deprecated), kubelet은 항상 컨테이너 런타임으로 하여금 +`/var/log/pods` 아래에 로그를 기록하도록 지시한다. + +`kube-log-runner`에 대한 자세한 정보는 [시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/#klog)를 확인한다. + +{{% /tab %}} +{{% tab name="윈도우" %}} + +kubelet은 기본적으로 `C:\var\logs` 아래에 로그를 기록한다 +(`C:\var\log`가 아님에 주의한다). + +`C:\var\log` 경로가 쿠버네티스에 설정된 기본값이지만, +몇몇 클러스터 배포 도구들은 윈도우 노드의 로그 경로로 `C:\var\log\kubelet`를 사용하기도 한다. + +다른 경로에 로그를 기록하고 싶은 경우에는, `kube-log-runner`를 통해 +간접적으로 kubelet을 실행하여 +kubelet의 로그를 지정한 디렉토리로 리디렉션할 수 있다. + +그러나, kubelet은 항상 컨테이너 런타임으로 하여금 +`C:\var\log\pods` 아래에 로그를 기록하도록 지시한다. + +`kube-log-runner`에 대한 자세한 정보는 [시스템 로그](/ko/docs/concepts/cluster-administration/system-logs/#klog)를 확인한다. +{{% /tab %}} +{{< /tabs >}} + +
+ +파드로 실행되는 쿠버네티스 컴포넌트의 경우, +기본 로깅 메커니즘을 따르지 않고 `/var/log` 아래에 로그를 기록한다 +(즉, 해당 컴포넌트들은 systemd의 journal에 로그를 기록하지 않는다). +쿠버네티스의 저장 메커니즘을 사용하여, 컴포넌트를 실행하는 컨테이너에 영구적으로 사용 가능한 저장 공간을 연결할 수 있다. + +etcd와 etcd의 로그를 기록하는 방식에 대한 자세한 정보는 [etcd 공식 문서](https://etcd.io/docs/)를 확인한다. +다시 언급하자면, 쿠버네티스의 저장 메커니즘을 사용하여 +컴포넌트를 실행하는 컨테이너에 영구적으로 사용 가능한 저장 공간을 연결할 수 있다. + +{{< note >}} +스케줄러와 같은 쿠버네티스 클러스터의 컴포넌트를 배포하여 상위 노드에서 공유된 볼륨에 로그를 기록하는 경우, +해당 로그들이 로테이트되는지 확인하고 관리해야 한다. +**쿠버네티스는 로그 로테이션을 관리하지 않는다**. + +몇몇 로그 로테이션은 운영체제가 자동적으로 구현할 수도 있다. +예를 들어, 컴포넌트를 실행하는 스태틱 파드에 `/var/log` 디렉토리를 공유하여 로그를 기록하면, +노드-레벨 로그 로테이션은 해당 경로의 파일을 +쿠버네티스 외부의 다른 컴포넌트들이 기록한 파일과 동일하게 취급한다. + +몇몇 배포 도구들은 로그 로테이션을 자동화하지만, +나머지 도구들은 이를 사용자의 책임으로 둔다. +{{< /note >}} + +## 클러스터-레벨 로깅 아키텍처 {#cluster-level-logging-architectures} 쿠버네티스는 클러스터-레벨 로깅을 위한 네이티브 솔루션을 제공하지 않지만, 고려해야 할 몇 가지 일반적인 접근 방법을 고려할 수 있다. 여기 몇 가지 옵션이 있다. @@ -165,7 +232,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo ![스트리밍 컨테이너가 있는 사이드카 컨테이너](/images/docs/user-guide/logging/logging-with-streaming-sidecar.png) 사이드카 컨테이너가 자체 `stdout` 및 `stderr` 스트림으로 -쓰도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를 +기록하도록 하면, 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를 활용할 수 있다. 사이드카 컨테이너는 파일, 소켓 또는 journald에서 로그를 읽는다. 각 사이드카 컨테이너는 자체 `stdout` 또는 `stderr` 스트림에 로그를 출력한다. @@ -177,8 +244,8 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo 빌트인 도구를 사용할 수 있다. 예를 들어, 파드는 단일 컨테이너를 실행하고, 컨테이너는 -서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. 파드에 대한 -구성 파일은 다음과 같다. +서로 다른 두 가지 형식을 사용하여 서로 다른 두 개의 로그 파일에 기록한다. +다음은 파드에 대한 매니페스트이다. {{< codenew file="admin/logging/two-files-counter-pod.yaml" >}} @@ -188,7 +255,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo 컨테이너는 공유 볼륨에서 특정 로그 파일을 테일(tail)한 다음 로그를 자체 `stdout` 스트림으로 리디렉션할 수 있다. -다음은 사이드카 컨테이너가 두 개인 파드에 대한 구성 파일이다. +다음은 사이드카 컨테이너가 두 개인 파드에 대한 매니페스트이다. {{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}} @@ -202,9 +269,9 @@ kubectl logs counter count-log-1 출력은 다음과 같다. ```console -0: Mon Jan 1 00:00:00 UTC 2001 -1: Mon Jan 1 00:00:01 UTC 2001 -2: Mon Jan 1 00:00:02 UTC 2001 +0: Fri Apr 1 11:42:26 UTC 2022 +1: Fri Apr 1 11:42:27 UTC 2022 +2: Fri Apr 1 11:42:28 UTC 2022 ... ``` @@ -215,27 +282,28 @@ kubectl logs counter count-log-2 출력은 다음과 같다. ```console -Mon Jan 1 00:00:00 UTC 2001 INFO 0 -Mon Jan 1 00:00:01 UTC 2001 INFO 1 -Mon Jan 1 00:00:02 UTC 2001 INFO 2 +Fri Apr 1 11:42:29 UTC 2022 INFO 0 +Fri Apr 1 11:42:30 UTC 2022 INFO 0 +Fri Apr 1 11:42:31 UTC 2022 INFO 0 ... ``` -클러스터에 설치된 노드-레벨 에이전트는 추가 구성없이 +클러스터에 노드-레벨 에이전트를 설치했다면, 에이전트는 추가적인 설정 없이도 자동으로 해당 로그 스트림을 선택한다. 원한다면, 소스 컨테이너에 -따라 로그 라인을 파싱(parse)하도록 에이전트를 구성할 수 있다. +따라 로그 라인을 파싱(parse)하도록 에이전트를 구성할 수도 있다. -참고로, CPU 및 메모리 사용량이 낮음에도 불구하고(cpu에 대한 몇 밀리코어의 -요구와 메모리에 대한 몇 메가바이트의 요구), 로그를 파일에 기록한 다음 -`stdout` 으로 스트리밍하면 디스크 사용량은 두 배가 될 수 있다. 단일 파일에 -쓰는 애플리케이션이 있는 경우, 일반적으로 스트리밍 -사이드카 컨테이너 방식을 구현하는 대신 `/dev/stdout` 을 대상으로 -설정하는 것을 추천한다. +CPU 및 메모리 사용량이 낮은(몇 밀리코어 수준의 CPU와 몇 메가바이트 수준의 메모리 요청) 파드라고 할지라도, +로그를 파일에 기록한 다음 `stdout` 으로 스트리밍하는 것은 +노드가 필요로 하는 스토리지 양을 두 배로 늘릴 수 있다. +단일 파일에 로그를 기록하는 애플리케이션이 있는 경우, +일반적으로 스트리밍 사이드카 컨테이너 방식을 구현하는 대신 +`/dev/stdout` 을 대상으로 설정하는 것을 추천한다. -사이드카 컨테이너를 사용하여 애플리케이션 자체에서 로테이션할 수 없는 -로그 파일을 로테이션할 수도 있다. 이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다. +사이드카 컨테이너를 사용하여 +애플리케이션 자체에서 로테이션할 수 없는 로그 파일을 로테이션할 수도 있다. +이 방법의 예시는 정기적으로 `logrotate` 를 실행하는 작은 컨테이너를 두는 것이다. 그러나, `stdout` 및 `stderr` 을 직접 사용하고 로테이션과 -유지 정책을 kubelet에 두는 것이 권장된다. +유지 정책을 kubelet에 두는 것이 더욱 직관적이다. #### 로깅 에이전트가 있는 사이드카 컨테이너 @@ -252,24 +320,30 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2 접근할 수 없다. {{< /note >}} -여기에 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 구성 파일이 있다. 첫 번째 파일에는 -fluentd를 구성하기 위한 [`ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다. +아래는 로깅 에이전트가 포함된 사이드카 컨테이너를 구현하는 데 사용할 수 있는 두 가지 매니페스트이다. +첫 번째 매니페스트는 fluentd를 구성하는 +[`컨피그맵(ConfigMap)`](/docs/tasks/configure-pod-container/configure-pod-configmap/)이 포함되어 있다. {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} {{< note >}} -fluentd를 구성하는 것에 대한 자세한 내용은, [fluentd 문서](https://docs.fluentd.org/)를 참고한다. +예제 매니페스트에서, 꼭 fluentd가 아니더라도, +애플리케이션 컨테이너 내의 모든 소스에서 로그를 읽어올 수 있는 다른 로깅 에이전트를 사용할 수 있다. {{< /note >}} -두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다. +두 번째 매니페스트는 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다. 파드는 fluentd가 구성 데이터를 가져올 수 있는 볼륨을 마운트한다. {{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}} -이 예시 구성에서, 사용자는 애플리케이션 컨테이너 내의 모든 소스을 읽는 fluentd를 다른 로깅 에이전트로 대체할 수 있다. - ### 애플리케이션에서 직접 로그 노출 ![애플리케이션에서 직접 로그 노출](/images/docs/user-guide/logging/logging-from-application.png) 애플리케이션에서 직접 로그를 노출하거나 푸시하는 클러스터-로깅은 쿠버네티스의 범위를 벗어난다. + +## {{% heading "whatsnext" %}} + +* [쿠버네티스 시스템 로그](/docs/concepts/cluster-administration/system-logs/) 살펴보기. +* [쿠버네티스 시스템 컴포넌트에 대한 추적(trace)](/docs/concepts/cluster-administration/system-traces/) 살펴보기. +* 파드가 실패했을 때 쿠버네티스가 어떻게 로그를 남기는지에 대해, [종료 메시지를 사용자가 정의하는 방법](/docs/tasks/debug/debug-application/determine-reason-pod-failure/#종료-메시지-사용자-정의하기) 살펴보기. \ No newline at end of file diff --git a/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md b/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md index 3ed3b7cfce..7eef64d390 100644 --- a/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md +++ b/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md @@ -1,6 +1,7 @@ --- title: 도커심 제거 및 CRI 호환 런타임 사용에 대한 기사 content_type: reference +weight: 20 --- 이 문서는 쿠버네티스의 _도커심_ diff --git a/content/ko/docs/reference/scheduling/_index.md b/content/ko/docs/reference/scheduling/_index.md index 7a37a35981..5956f2ae87 100644 --- a/content/ko/docs/reference/scheduling/_index.md +++ b/content/ko/docs/reference/scheduling/_index.md @@ -1,5 +1,5 @@ --- title: 스케줄링 -weight: 70 +weight: 140 toc-hide: true --- diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md index 47518285ed..b740b9b3e8 100644 --- a/content/ko/docs/reference/scheduling/policies.md +++ b/content/ko/docs/reference/scheduling/policies.md @@ -3,6 +3,7 @@ title: 스케줄링 정책 content_type: concept sitemap: priority: 0.2 # Scheduling priorities are deprecated +weight: 30 --- diff --git a/content/ko/docs/reference/setup-tools/_index.md b/content/ko/docs/reference/setup-tools/_index.md index 717b9cb2ac..8cbd2a662f 100644 --- a/content/ko/docs/reference/setup-tools/_index.md +++ b/content/ko/docs/reference/setup-tools/_index.md @@ -1,4 +1,4 @@ --- title: 설치 도구 -weight: 50 +weight: 100 --- diff --git a/content/ko/docs/reference/tools/_index.md b/content/ko/docs/reference/tools/_index.md index d6188ed7d4..da1b9866f2 100644 --- a/content/ko/docs/reference/tools/_index.md +++ b/content/ko/docs/reference/tools/_index.md @@ -3,7 +3,7 @@ title: 도구 # reviewers: # - janetkuo content_type: concept -weight: 80 +weight: 150 no_list: true --- diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md index 4716e1081f..691cce639a 100644 --- a/content/ko/docs/reference/using-api/_index.md +++ b/content/ko/docs/reference/using-api/_index.md @@ -5,7 +5,7 @@ title: API 개요 # - lavalamp # - jbeda content_type: concept -weight: 10 +weight: 20 no_list: true card: name: 레퍼런스 @@ -50,27 +50,31 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. - 알파(Alpha): - 버전 이름에 `alpha`가 포함된다(예: `v1alpha1`). + - 빌트인 알파 API 버전은 기본적으로 활성화되지 않으며, 활성화하기 위해서는 `kube-apiserver` 설정에 반드시 명시해야 한다. - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다. - 기본적으로 비활성화되어 있다. - - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. + - 알파 API에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다. - 버그에 대한 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다. - 베타(Beta): - 버전 이름에 `beta`가 포함된다(예: `v2beta3`). + - 빌트인 베타 API 버전은 기본적으로 활성화되지 않으며, 활성화하기 위해서는 `kube-apiserver` 설정에 반드시 명시해야 한다. + (**예외사항** 쿠버네티스 1.22 버전 이전의 베타 API들은 기본적으로 활성화되어 있다.) + - 빌트인 베타 API 버전이 더 이상 지원되지 않기까지는 9달 또는 3번의 마이너 릴리스(둘 중 더 긴 것을 기준으로 함)가 걸린다. + 그리고 지원되지 않은 시점에서 제거되기까지는 다시 9달 또는 3번의 마이너 릴리스(둘 중 더 긴 것을 기준으로 함)가 걸린다. - 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다. - 기본적으로 활성화되어 있다. - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다. - - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 + - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 API 버전에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 - 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 - 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. + 이관할 수 있는 가이드가 제공된다. 다음 베타 또는 안정화 API 버전을 적용하는 것은 + API 오브젝트의 편집 또는 재생성이 필요할 수도 있으며, 그렇게 쉬운 일만은 아닐 것이다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다. - 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 - 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 - 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다. + 호환되지 않는 변경 사항이 적용될 수 있다. + 베타 API 버전이 더 이상 지원되지 않는 경우, 후속 베타 또는 안정화 API 버전으로 전환하기 위해서는 + 베타 API 버전을 사용해야 한다. {{< note >}} 베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는 @@ -79,7 +83,8 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. - 안정화(Stable): - 버전 이름이 `vX`이고 `X` 는 정수다. - - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다. + - 안정화된 API 버전은 이후의 모든 쿠버네티스 메이저 버전에서 사용 가능하며, + 현재로써 쿠버네티스 메이저 버전에서 안정화된 API를 제거하려는 계획은 없다. ## API 그룹 diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index f4abf70c60..204e8e1ef0 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -34,7 +34,7 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [둘러보기](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) | Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples) | Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [둘러보기](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) -| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation) +| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java/tree/master/examples) | JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) | Perl | [github.com/kubernetes-client/perl/](https://github.com/kubernetes-client/perl/) | [둘러보기](https://github.com/kubernetes-client/perl/tree/master/examples) | Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) @@ -80,5 +80,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | | Scala | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | +| Scala | [github.com/hnaderi/scala-k8s](https://github.com/hnaderi/scala-k8s) | | Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) |