@@ -159,7 +159,7 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한
159159* ` PodScheduled ` : 파드가 노드에 스케줄되었다.
160160* ` ContainersReady ` : 파드의 모든 컨테이너가 준비되었다.
161161* ` Initialized ` : 모든 [ 초기화 컨테이너] ( /ko/docs/concepts/workloads/pods/init-containers/ ) 가
162- 성공적으로 시작되었다 .
162+ 성공적으로 완료(completed)되었다 .
163163* ` Ready ` : 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드
164164 밸런싱 풀에 추가되어야 한다.
165165
@@ -233,57 +233,87 @@ kubelet은 파드의 [컨디션](#파드의-컨디션)을 `ContainerReady` 로
233233
234234## 컨테이너 프로브(probe)
235235
236- [ 프로브 ] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) 는
236+ _ 프로브 _ 는
237237컨테이너에서 [ kubelet] ( /docs/reference/command-line-tools-reference/kubelet/ ) 에 의해
238238주기적으로 수행되는 진단(diagnostic)이다.
239239진단을 수행하기 위해서,
240- kubelet은 컨테이너에 의해서 구현된
241- [ 핸들러] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다.
242- 핸들러에는 다음과 같이 세 가지 타입이 있다.
240+ kubelet은 컨테이너 안에서 코드를 실행하거나,
241+ 또는 네트워크 요청을 전송한다.
243242
244- * [ ExecAction] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)은
245- 컨테이너 내에서 지정된 명령어를 실행한다.
246- 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
243+ ### 체크 메커니즘 {#probe-check-methods}
244+
245+ 프로브를 사용하여 컨테이너를 체크하는 방법에는 4가지가 있다.
246+ 각 프로브는 다음의 4가지 메커니즘 중 단 하나만을 정의해야 한다.
247247
248- * [ TCPSocketAction ] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core)은
249- 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다 .
250- 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다.
248+ ` exec `
249+ : 컨테이너 내에서 지정된 명령어를 실행한다 .
250+ 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
251251
252- * [ HTTPGetAction] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)은
253- 지정한 포트 및 경로에서 컨테이너의 IP주소에
254- 대한 HTTP ` GET ` 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면
252+ ` grpc `
253+ : [ gRPC] ( https://grpc.io/ ) 를 사용하여
254+ 원격 프로시저 호출을 수행한다.
255+ 체크 대상이 [ gRPC 헬스 체크] ( https://grpc.io/grpc/core/md_doc_health-checking.html ) 를 구현해야 한다.
256+ 응답의 ` status ` 가 ` SERVING ` 이면
257+ 진단이 성공했다고 간주한다.
258+ gRPC 프로브는 알파 기능이며
259+ ` GRPCContainerProbe ` [ 기능 게이트] ( /ko/docs/reference/command-line-tools-reference/feature-gates/ ) 를
260+ 활성화해야 사용할 수 있다.
261+
262+ ` httpGet `
263+ : 지정한 포트 및 경로에서 컨테이너의 IP주소에 대한
264+ HTTP ` GET ` 요청을 수행한다.
265+ 응답의 상태 코드가 200 이상 400 미만이면
255266 진단이 성공한 것으로 간주한다.
256267
268+ ` tcpSocket `
269+ : 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다.
270+ 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다.
271+ 원격 시스템(컨테이너)가 연결을 연 이후 즉시 닫는다면,
272+ 이 또한 진단이 성공한 것으로 간주한다.
273+
274+ ### 프로브 결과
275+
257276각 probe는 다음 세 가지 결과 중 하나를 가진다.
258277
259- * ` Success ` : 컨테이너가 진단을 통과함.
260- * ` Failure ` : 컨테이너가 진단에 실패함.
261- * ` Unknown ` : 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨.
278+ ` Success `
279+ : 컨테이너가 진단을 통과함.
262280
263- kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고
264- 그에 반응할 수 있다.
281+ ` Failure `
282+ : 컨테이너가 진단에 실패함.
283+
284+ ` Unknown `
285+ : 진단 자체가 실패함(아무런 조치를 수행해서는 안 되며, kubelet이
286+ 추가 체크를 수행할 것이다)
265287
266- * ` livenessProbe ` : 컨테이너가 동작 중인지 여부를 나타낸다. 만약
267- 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는
268- [ 재시작 정책] ( #restart-policy ) 의 대상이 된다. 만약 컨테이너가
269- 활성 프로브를 제공하지 않는 경우, 기본 상태는 ` Success ` 이다.
288+ ### 프로브 종류
270289
271- * ` readinessProbe ` : 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
272- 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는
273- 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의
274- 초기 지연 이전의 기본 상태는 ` Failure ` 이다. 만약 컨테이너가 준비성 프로브를
275- 지원하지 않는다면, 기본 상태는 ` Success ` 이다.
290+ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고
291+ 그에 반응할 수 있다.
276292
277- * ` startupProbe ` : 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
278- 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는
279- 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
280- 컨테이너는 [ 재시작 정책] ( #restart-policy ) 에 따라 처리된다. 컨테이너에 스타트업
281- 프로브가 없는 경우, 기본 상태는 ` Success ` 이다.
293+ ` livenessProbe `
294+ : 컨테이너가 동작 중인지 여부를 나타낸다. 만약
295+ 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는
296+ [ 재시작 정책] ( #restart-policy ) 의 대상이 된다. 만약 컨테이너가
297+ 활성 프로브를 제공하지 않는 경우, 기본 상태는 ` Success ` 이다.
298+
299+ ` readinessProbe `
300+ : 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
301+ 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는
302+ 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의
303+ 초기 지연 이전의 기본 상태는 ` Failure ` 이다. 만약 컨테이너가 준비성 프로브를
304+ 지원하지 않는다면, 기본 상태는 ` Success ` 이다.
305+
306+ ` startupProbe `
307+ : 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
308+ 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는
309+ 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
310+ 컨테이너는 [ 재시작 정책] ( #restart-policy ) 에 따라 처리된다. 컨테이너에 스타트업
311+ 프로브가 없는 경우, 기본 상태는 ` Success ` 이다.
282312
283313활성, 준비성 및 스타트업 프로브를 설정하는 방법에 대한 추가적인 정보는,
284314[ 활성, 준비성 및 스타트업 프로브 설정하기] ( /docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ ) 를 참조하면 된다.
285315
286- ### 언제 활성 프로브를 사용해야 하는가?
316+ #### 언제 활성 프로브를 사용해야 하는가?
287317
288318{{< feature-state for_k8s_version="v1.0" state="stable" >}}
289319
@@ -295,7 +325,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
295325프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를
296326지정하고, ` restartPolicy ` 를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
297327
298- ### 언제 준비성 프로브를 사용해야 하는가?
328+ #### 언제 준비성 프로브를 사용해야 하는가?
299329
300330{{< feature-state for_k8s_version="v1.0" state="stable" >}}
301331
@@ -329,7 +359,7 @@ failed 애플리케이션과 시동 중에 아직 데이터를 처리하고 있
329359남아 있다.
330360{{< /note >}}
331361
332- ### 언제 스타트업 프로브를 사용해야 하는가?
362+ #### 언제 스타트업 프로브를 사용해야 하는가?
333363
334364{{< feature-state for_k8s_version="v1.20" state="stable" >}}
335365
@@ -458,6 +488,6 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파
458488
459489* [ 컨테이너 라이프사이클 훅] ( /ko/docs/concepts/containers/container-lifecycle-hooks/ ) 에 대해 자세히 알아보자.
460490
461- * API의 파드 / 컨테이너 상태에 대한 자세한 내용은 [ PodStatus ] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
462- 그리고
463- [ ContainerStatus ] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참고한다.
491+ * API의 파드와 컨테이너 상태에 대한 자세한 내용은
492+ 파드의 [ ` .status ` ] ( /docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus ) 에 대해 다루는
493+ API 레퍼런스 문서를 참고한다.
0 commit comments