Sixth Korean l10n work for release-1.19

- fix Korean translation of 'object' (#25370) - Update outdated files in the dev-1.19-ko.6 branch (2) (#25403) - Translate setup/release/version-skew-policy.md in Korean (#25345) - Translate tutorials/configuration/configure-java-microservice/configure-java-microservice/ into Korean (#24981) - Translate health-checks.md into Korean (#25342) - Translate reference/glossary/api-group.md in Korean (#25321) - Translate reference/glossary/object.md in Korean (#25318) - Translate tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive/ into Korean (#24984) - switch New York Times case study to use youtube shortcode (ko) (#25287) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: PyungHo Yoon <learder@gmail.com> Co-authored-by: mylovepooh <jun8414@gmail.com> Co-authored-by: jmkim <jm1223.kim@samsung.com> Co-authored-by: santachopa <santachopa@naver.com> Co-authored-by: Arhell <arhell333@gmail.com>
2020-11-28 02:58:25 +02:00
parent c4c17a9b8a
commit dd950df8bd
55 changed files with 760 additions and 545 deletions
@@ -128,7 +128,7 @@ API 서버 인가를 외부 서비스에 노출시킨다.
 * `LocalSubjectAccessReview` - `SubjectAccessReview`와 비슷하지만 특정 네임스페이스로 제한된다.
 * `SelfSubjectRulesReview` - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.

-이러한 API는 반환된 객체의 응답 "status" 필드가 쿼리의 결과인
+이러한 API는 반환된 오브젝트의 응답 "status" 필드가 쿼리의 결과인
 일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.

 ```bash
@@ -18,95 +18,105 @@ weight: 50
 쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
 구분한다.

-  - 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
-    위한 것이다.
-  - 사용자 어카운트는 전역을 대상으로 고려된다.
-    클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 하며, 향후 사용자 리소스는 네임스페이스에 할당되지 않는다.
-    서비스 어카운트는 네임스페이스에 할당된다.
-  - 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
-    여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
-    서비스 어카운트 생성은
-    클러스터 사용자가 특정 작업(즉, 최소 권한 원칙)을 위한 서비스 어카운트를 만들 수 있도록
-    보다 가볍게 만들어졌다.
-  - 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
-  - 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
-    서비스 어카운트는 임시(ad-hoc)로 만들 수도 있고 네임스페이스에 할당된 이름을 가질 수도 있기 때문에
-    이러한 설정은 이식성이 좋다.
+- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
+  위한 것이다.
+- 사용자 어카운트는 전역을 대상으로 고려된다.
+  클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다.
+- 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
+  여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
+  서비스 어카운트 생성은
+  클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록
+  보다 가볍게 만들어졌다.
+- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
+- 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
+  서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에
+  이러한 설정은 이식성이 좋다.

 ## 서비스 어카운트 자동화

 서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.

-  - 서비스 어카운트 어드미션 컨트롤러
-  - 토큰 컨트롤러
-  - 서비스 어카운트 컨트롤러
+- `ServiceAccount` 어드미션 컨트롤러
+- 토큰 컨트롤러
+- `ServiceAccount` 컨트롤러

-### 서비스 어카운트 어드미션 컨트롤러
+### 서비스어카운트(ServiceAccount) 어드미션 컨트롤러

-파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
-라는 플러그인을 통해 구현된다. 이것은 apiserver의 일부이다.
+파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는
+플러그인을 통해 구현된다.
+이것은 API 서버의 일부이다.
 파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.

-  1. 파드에 `ServiceAccount`가 없다면 `ServiceAccount`를 `default`로 설정한다.
-  1. 파드에 참조되는 `ServiceAccount`가 있도록 하고, 그렇지 않으면 이를 거부한다.
-  1. 파드에 `ImagePullSecrets`이 없는 경우 `ServiceAccount`의 `ImagePullSecrets`이 파드에 추가된다.
-  1. 파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
-  1. `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 파드의 각 컨테이너에 `volumeSource`를 추가한다.
+1. 파드에 `serviceAccountName`가 없다면, `serviceAccountName`를
+   `default`로 설정한다.
+1. 파드에 참조되는 `serviceAccountName`가 있도록 하고, 그렇지 않으면
+   이를 거부한다.
+1. 파드에 `imagePullSecrets`이 없는 경우, 서비스어카운트의
+   `imagePullSecrets`이 파드에 추가된다.
+1. 서비스어카운트 `automountServiceAccountToken` 또는 파드의
+   `automountServiceAccountToken` 이 `false` 로 설정되지 않은 경우
+   파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
+1. 이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우,
+   `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된
+   파드의 각 컨테이너에 `volumeSource`를 추가한다.

-v1.13부터 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
+`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
 서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
-[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참조한다.
+[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한
+자세한 내용을 참조한다.

 ### 토큰 컨트롤러

-토큰컨트롤러는 컨트롤러 매니저의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
+토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,

- 서비스 어카운트 생성을 지켜보고 API에 접근할 수 있는 시크릿을 생성한다.
- 서비스 어카운트 삭제를 지켜보고 해당하는 모든 서비스 어카운트 토큰 시크릿을 삭제한다.
- 시크릿 추가를 지켜보고 참조된 서비스 어카운트가 존재하는지 확인하고 필요한 경우 시크릿에 토큰을 추가한다.
- 시크릿 삭제를 지켜보고 필요한 경우 해당 서비스 어카운트에서 참조를 제거한다.
+- 서비스어카운트 생성을 감시하고 API에 접근할 수 있는 해당
+  서비스어카운트 토큰 시크릿을 생성한다.
+- 서비스어카운트 삭제를 감시하고 해당하는 모든 서비스어카운트
+  토큰 시크릿을 삭제한다.
+- 서비스어카운트 토큰 시크릿 추가를 감시하고, 참조된 서비스어카운트가
+  존재하는지 확인하고, 필요한 경우 시크릿에 토큰을 추가한다.
+- 시크릿 삭제를 감시하고 필요한 경우 해당 서비스어카운트에서
+  참조를 제거한다.

-서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 옵션을 사용하여 컨트롤러 매니저의 토큰 컨트롤러에 전달해야 한다.
-개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
-마찬가지로 `--service-account-key-file` 옵션을 사용하여 해당 공개키를 쿠버네티스 API 서버에 전달해야 한다.
-공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다.
+서비스 어카운트 개인키 파일은 `--service-account-private-key-file`
+플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야
+한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
+마찬가지로 `--service-account-key-file` 플래그를 사용하여 해당 공개키를
+`kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을
+검증하는 데 사용될 것이다.

 #### 추가적인 API 토큰 생성

-컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스 어카운트에 존재하도록 보장한다.
-서비스 어카운트에 대한 추가적인 API 토큰을 생성하기 위해
-서비스 어카운트를 참조하는 어노테이션과 함께 `ServiceAccountToken` 유형의 시크릿을 생성하면
+컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다.
+서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해
+서비스어카운트를 참조하는 어노테이션과 함께 `kubernetes.io/service-account-token` 유형의 시크릿을 생성하면
 컨트롤러가 새로 생성된 토큰으로 갱신한다.

-secret.json:
+다음은 시크릿에 대한 샘플 구성이다.

-```json
-{
-    "kind": "Secret",
-    "apiVersion": "v1",
-    "metadata": {
-        "name": "mysecretname",
-        "annotations": {
-            "kubernetes.io/service-account.name": "myserviceaccount"
-        }
-    },
-    "type": "kubernetes.io/service-account-token"
-}
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecretname
+  annotations:
+    kubernetes.io/service-account.name: myserviceaccount
+type: kubernetes.io/service-account-token
 ```

 ```shell
-kubectl create -f ./secret.json
+kubectl create -f ./secret.yaml
 kubectl describe secret mysecretname
 ```

-#### 서비스 어카운트 토큰 삭제/무효화
+#### 서비스 어카운트 토큰 시크릿 삭제/무효화

 ```shell
 kubectl delete secret mysecretname
 ```

-### 서비스 어카운트 컨트롤러
+### 서비스어카운트 컨트롤러

-서비스 어카운트 컨트롤러는 네임스페이스에 있는 서비스 어카운트를 관리하고
-"default"라는 이름의 서비스 어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
+서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고
+"default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
@@ -83,8 +83,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | |
 | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | |
 | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
-| `CustomResourceDefaulting` | `false` | 알파| 1.15 | 1.15 |
-| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | |
 | `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | |
 | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
 | `DevicePlugins` | `true` | 베타 | 1.10 | |
@@ -137,12 +135,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `RuntimeClass` | `true` | 베타 | 1.14 | |
 | `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
 | `SCTPSupport` | `true` | 베타 | 1.19 | |
-| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
-| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
 | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
 | `ServerSideApply` | `true` | 베타 | 1.16 | |
 | `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
-| `ServiceAppProtocol` | `false` | 알파 | 1.18 | |
+| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
+| `ServiceAppProtocol` | `true` | 베타 | 1.19 | |
 | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
 | `ServiceNodeExclusion` | `true` | 베타 | 1.19 | |
 | `ServiceTopology` | `false` | 알파 | 1.17 | |
@@ -209,6 +206,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 |
 | `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 |
 | `CustomPodDNS` | `true` | GA | 1.14 | - |
+| `CustomResourceDefaulting` | `false` | 알파 | 1.15 | 1.15 |
+| `CustomResourceDefaulting` | `true` | 베타 | 1.16 | 1.16 |
+| `CustomResourceDefaulting` | `true` | GA | 1.17 | - |
 | `CustomResourcePublishOpenAPI` | `false` | 알파| 1.14 | 1.14 |
 | `CustomResourcePublishOpenAPI` | `true` | 베타| 1.15 | 1.15 |
 | `CustomResourcePublishOpenAPI` | `true` | GA | 1.16 | - |
@@ -0,0 +1,19 @@
+---
+title: API 그룹(API Group)
+id: api-group
+date: 2019-09-02
+full_link: /ko/docs/concepts/overview/kubernetes-api/#api-groups
+short_description: >
+  쿠버네티스 API의 연관된 경로들의 집합.
+
+aka:
+tags:
+- fundamental
+- architecture
+---
+쿠버네티스 API의 연관된 경로들의 집합. 
+
+<!--more-->
+API 서버의 구성을 변경하여 각 API 그룹을 활성화하거나 비활성화할 수 있다. 특정 리소스에 대한 경로를 비활성화하거나 활성화할 수도 있다. API 그룹을 사용하면 쿠버네티스 API를 더 쉽게 확장할 수 있다. API 그룹은 REST 경로 및 직렬화된 오브젝트의 `apiVersion` 필드에 지정된다.
+
+* 자세한 내용은 [API 그룹(/ko/docs/concepts/overview/kubernetes-api/#api-groups)을 참조한다.
@@ -3,18 +3,18 @@ title: 미러 파드(Mirror Pod)
 id: mirror-pod
 date: 2019-08-06
 short_description: >
-  Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 객체.
+  Kubelet의 스태틱 파드(Static Pod)를 추적하는 API 서버 내부의 오브젝트.

 aka:
 tags:
 - fundamental
 ---
  Kubelet이 {{< glossary_tooltip text="스태틱 파드" term_id="static-pod" >}}를
-  표현하는 {{< glossary_tooltip text="파드" term_id="pod" >}} 객체
+  표현하는 {{< glossary_tooltip text="파드" term_id="pod" >}} 오브젝트

 <!--more-->
 Kubelet이 설정에서 스태틱 파드를 찾으면, 자동으로 쿠버네티스
-API 서버에 파드 객체 생성을 시도한다. 이렇게 생성된 파드를
+API 서버에 파드 오브젝트 생성을 시도한다. 이렇게 생성된 파드를
 API 서버에서 확인할 수는 있지만, API 서버를 통해 제어할 수는 없다.

 (예를 들어, 미러 파드를 제거하더라도 kubelet 데몬이 해당 파드를 멈추지 않는다.)
@@ -0,0 +1,19 @@
+---
+title: 오브젝트(Object)
+id: object
+date: 2020-12-1
+full_link: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects
+short_description: >
+   클러스터 상태의 일부를 나타내는 쿠버네티스 시스템의 엔티티이다.
+aka:
+tags:
+- fundamental
+---
+쿠버네티스 시스템의 엔티티이다. 쿠버네티스 API가 클러스터의 상태를 나타내기 위해
+사용하는 엔티티이다.
+<!--more-->
+쿠버네티스 오브젝트는 일반적으로 "의도를 담은 레코드"이다. 당신이 오브젝트를 생성하게 되면, 쿠버네티스
+{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 그 아이템이 실제 존재함을 보장하기 위해
+지속적으로 작동한다.
+객체를 생성함으로써 당신의 클러스터의 워크로드 해당 부분이 어떻게 보이길 원하는지 쿠버네티스 시스템에 효과적으로 알리는 것이다.
+이것은 당신의 클러스터의 의도한 상태이다.
@@ -14,5 +14,5 @@ tags:

 <!--more--> 

-쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록 상 유사한 개체의 출현을 서로 구분하기 위함이다.
+쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록상 유사한 오브젝트의 출현을 서로 구분하기 위함이다.

@@ -86,6 +86,13 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml      # 여러 파일로 부터 생성
 kubectl apply -f ./dir                         # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
 kubectl apply -f https://git.io/vPieo          # url로부터 리소스(들) 생성
 kubectl create deployment nginx --image=nginx  # nginx 단일 인스턴스를 시작
+
+# "Hello World"를 출력하는 잡(Job) 생성
+kubectl create job hello --image=busybox -- echo "Hello World"
+
+# 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성
+kubectl create cronjob hello --image=busybox   --schedule="*/1 * * * *" -- echo "Hello World"    
+
 kubectl explain pods                           # 파드 매니페스트 문서를 조회

 # stdin으로 다수의 YAML 오브젝트 생성
@@ -59,7 +59,7 @@ kubectl [command] [TYPE] [NAME] [flags]
   * 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>`

      * YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).<br/>
-     예: `kubectl get pod -f ./pod.yaml`
+     예: `kubectl get -f ./pod.yaml`

 * `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.<br/>

@@ -0,0 +1,101 @@
+---
+title: 쿠버네티스 API 헬스(health) 엔드포인트
+content_type: concept
+weight: 50
+---
+
+<!-- overview -->
+쿠버네티스 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}는 현재 상태를 나타내는 API 엔드포인트를 제공한다.
+이 페이지에서는 API 엔드포인트들에 대해 설명하고 이를 사용하는 방법을 다룬다.
+
+<!-- body -->
+
+## 헬스를 위한 API 엔드포인트
+
+쿠버네티스 API 서버는 현재 상태를 나타내는 세 가지 API 엔드포인트(`healthz`, `livez` 와 `readyz`)를 제공한다.
+`healthz` 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스  v1.16 버전 이후), 대신 보다 구체적인 `livez` 와 `readyz` 엔드포인트를 사용해야 한다.
+`livez` 엔드포인트는 `--livez-grace-period` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 시작 대기 시간을 지정할 수 있다.
+`/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다.
+API 서버의 `health`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다.
+상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다.
+아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다.
+
+다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.
+
+모든 엔드포인트는 `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다.
+이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.
+
+```shell
+curl -k https://localhost:6443/livez?verbose
+```
+
+인증을 사용하는 원격 호스트에서 사용할 경우에는 다음과 같이 수행한다.
+
+```shell
+kubectl get --raw='/readyz?verbose'
+```
+
+출력은 다음과 같다.
+
+    [+]ping ok
+    [+]log ok
+    [+]etcd ok
+    [+]poststarthook/start-kube-apiserver-admission-initializer ok
+    [+]poststarthook/generic-apiserver-start-informers ok
+    [+]poststarthook/start-apiextensions-informers ok
+    [+]poststarthook/start-apiextensions-controllers ok
+    [+]poststarthook/crd-informer-synced ok
+    [+]poststarthook/bootstrap-controller ok
+    [+]poststarthook/rbac/bootstrap-roles ok
+    [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+    [+]poststarthook/start-cluster-authentication-info-controller ok
+    [+]poststarthook/start-kube-aggregator-informers ok
+    [+]poststarthook/apiservice-registration-controller ok
+    [+]poststarthook/apiservice-status-available-controller ok
+    [+]poststarthook/kube-apiserver-autoregistration ok
+    [+]autoregister-completion ok
+    [+]poststarthook/apiservice-openapi-controller ok
+    healthz check passed
+
+또한 쿠버네티스 API 서버는 특정 체크를 제외할 수 있다.
+쿼리 파라미터는 다음 예와 같이 조합될 수 있다.
+
+```shell
+curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
+```
+
+출력에서 etcd 체크가 제외된 것을 보여준다.
+
+    [+]ping ok
+    [+]log ok
+    [+]etcd excluded: ok
+    [+]poststarthook/start-kube-apiserver-admission-initializer ok
+    [+]poststarthook/generic-apiserver-start-informers ok
+    [+]poststarthook/start-apiextensions-informers ok
+    [+]poststarthook/start-apiextensions-controllers ok
+    [+]poststarthook/crd-informer-synced ok
+    [+]poststarthook/bootstrap-controller ok
+    [+]poststarthook/rbac/bootstrap-roles ok
+    [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
+    [+]poststarthook/start-cluster-authentication-info-controller ok
+    [+]poststarthook/start-kube-aggregator-informers ok
+    [+]poststarthook/apiservice-registration-controller ok
+    [+]poststarthook/apiservice-status-available-controller ok
+    [+]poststarthook/kube-apiserver-autoregistration ok
+    [+]autoregister-completion ok
+    [+]poststarthook/apiservice-openapi-controller ok
+    [+]shutdown ok
+    healthz check passed
+
+## 개별 헬스 체크
+
+{{< feature-state state="alpha" >}}
+
+각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
+개별 체크를 위한 스키마는 `/livez/<healthcheck-name>` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
+`<healthcheck-name>` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
+이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.
+
+```shell
+curl -k https://localhost:6443/livez/etcd
+```