diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md
index 52b6060afe9d6..7bc45f7f303fa 100644
--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@@ -2,12 +2,12 @@
 # reviewers:
 # - erictune
 title: 파드
+api_metadata:
+- apiVersion: "v1"
+  kind: "Pod"
 content_type: concept
 weight: 10
 no_list: true
-card:
-  name: concepts
-  weight: 60
 ---
 
 <!-- overview -->
@@ -15,16 +15,16 @@ card:
 _파드(Pod)_ 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
 
 _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의
-[컨테이너](/ko/docs/concepts/containers/)의 그룹이다. 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
-함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는
+{{< glossary_tooltip text="컨테이너" term_id="container" >}}의 그룹이다. 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
+함께 스케줄되며, 공유 컨텍스트에서 실행된다. 파드는
 애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의
 애플리케이션 컨테이너가 포함된다.
-클라우드가 아닌 콘텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다.
+클라우드가 아닌 컨텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다.
 
 애플리케이션 컨테이너와 마찬가지로, 파드에는
-파드 시작 중에 실행되는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가
-포함될 수 있다. 클러스터가 제공하는 경우, 디버깅을 위해
-[임시 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)를
+파드 시작 중에 실행되는 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}가
+포함될 수 있다. 디버깅을 위해 실행중인 파드에
+{{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}를
 삽입할 수도 있다.
 
 <!-- body -->
@@ -32,23 +32,41 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)
 ## 파드란 무엇인가?
 
 {{< note >}}
-[도커](https://www.docker.com/)가 가장 일반적으로 잘 알려진 
-{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이지만, 
-쿠버네티스는 도커 외에도 다양한 컨테이너 런타임을 지원하며, 
-파드를 설명할 때 도커 관련 용어를 사용하면 더 쉽게 설명할 수 있다.
+클러스터의 각 노드에 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 
+설치해야 노드에서 파드가 실행될 수 있다.
 {{< /note >}}
 
-파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및
+파드의 공유 컨텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및
 {{< glossary_tooltip text="컨테이너" term_id="container" >}}를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다.
-파드의 콘텍스트 내에서 개별 애플리케이션은 추가적으로 하위 격리가 적용된다.
+파드의 컨텍스트 내에서 개별 애플리케이션은 추가적으로 하위 격리가 적용된다.
 
 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 있는 컨테이너들의 집합과 비슷하다.
 
+쿠버네티스 클러스터의 파드는 크게 두 가지 방식으로 사용된다.
+
+* **단일 컨테이너에서 실행되는 파드**: "파드 하나에 컨테이너 하나” 모델은 
+  쿠버네티스에서 가장 흔한 사용 사례이다. 이 경우 파드는 단일 컨테이너를 감싸는 
+  래퍼(wrapper)처럼 볼 수 있으며, 쿠버네티스는 컨테이너 자체가 아니라 
+  파드를 관리한다.
+* **함께 동작해야 하는 여러 컨테이너를 실행하는 파드**: 파드는 서로 긴밀하게 
+  결합되어 자원을 공유해야 하는 [여러 개의 컨테이너](#how-pods-manage-multiple-containers)로 
+  구성된 애플리케이션을 
+  캡슐화할 수 있다. 이렇게 함께 배치되고 공동 관리되는 
+  컨테이너들은 하나의 응집력 있는 단위를 이룬다.
+
+  여러 개의 컨테이너를 하나의 파드 안에 두고 관리하여 그룹화하는 것은 상대적으로 
+  고급 사용 사례이다. 컨테이너들이 긴밀히 결합되어 있는 특정한 상황에서만 이 
+  패턴을 사용하는 것이 권장된다.
+
+  복제(내결함성이나 용량 확보)를 위해 여러 컨테이너를 실행할 필요는 없다. 
+  여러 복제가 필요하다면, 
+  [워크로드 관리](/ko/docs/concepts/workloads/controllers/)를 참고한다.
+  
 ## 파드의 사용
 
 다음은 `nginx:1.14.2` 이미지를 실행하는 컨테이너로 구성되는 파드의 예시이다.
 
-{{< codenew file="pods/simple-pod.yaml" >}}
+{{% code_sample file="pods/simple-pod.yaml" %}}
 
 위에서 설명한 파드를 생성하려면, 다음 명령을 실행한다.
 ```shell
@@ -59,33 +77,13 @@ kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
 [파드 작업](#파드-작업) 섹션에서 파드와 워크로드 리소스의 관계에 대한 
 더 많은 정보를 확인한다.
 
-### Workload resources for managing pods
+### 파드를 관리하기 위한 워크로드 리소스
 
 일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, {{< glossary_tooltip text="디플로이먼트(Deployment)"
 term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}과 같은 워크로드 리소스를 사용하여 생성한다.
 파드가 상태를 추적해야 한다면,
-{{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 리소스를 고려한다.
-
-쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용된다.
+{{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 리소스를 고려하자.
 
-* **단일 컨테이너를 실행하는 파드**. "파드 당 하나의 컨테이너" 모델은
-  가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼
-  래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신
-  파드를 관리한다.
-* **함께 작동해야 하는 여러 컨테이너를 실행하는 파드**. 파드는
-  밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로
-  구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는
-  하나의 결합된 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너는 공유 볼륨에
-  저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 _사이드카_ 컨테이너는
-  해당 파일을 새로 고치거나 업데이트한다.
-  파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를
-  단일 단위로 함께 래핑한다.
-
-  {{< note >}}
-  단일 파드에서 함께 배치된 또는 함께 관리되는 여러 컨테이너를 그룹화하는 것은
-  비교적 고급 유스케이스이다. 이 패턴은 컨테이너가 밀접하게 결합된
-  특정 인스턴스에서만 사용해야 한다.
-  {{< /note >}}
 
 각 파드는 특정 애플리케이션의 단일 인스턴스를 실행하기 위한 것이다. 더 많은
 인스턴스를 실행하여 더 많은 전체 리소스를 제공하기 위해 애플리케이션을
@@ -98,25 +96,10 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
 자동 복구를 구현하는 방법에 대한 자세한 내용은
 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다.
 
-### 파드가 여러 컨테이너를 관리하는 방법
-
-파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를
-지원하도록 설계되었다. 파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서
-자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는
-리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을
-조정할 수 있다.
-
-예를 들어, 다음 다이어그램에서와 같이
-공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는
-별도의 "사이드카" 컨테이너가 있을 수 있다.
-
-{{< figure src="/images/docs/pod.svg" alt="파드 생성 다이어그램" class="diagram-medium" >}}
-
-일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.
-
 파드는 기본적으로 파드에 속한 컨테이너에 [네트워킹](#파드-네트워킹)과 [스토리지](#pod-storage)라는
 두 가지 종류의 공유 리소스를 제공한다.
 
+
 ## 파드 작업
 
 사용자가 쿠버네티스에서 직접 개별 파드를 만드는 경우는 거의 없다. 싱글톤 파드도 마찬가지이다. 이는
@@ -129,29 +112,34 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
 
 {{< note >}}
 파드에서 컨테이너를 다시 시작하는 것과 파드를 다시 시작하는 것을 혼동해서는 안된다. 파드는
-프로세스가 아니라 컨테이너를 실행하기 위한 환경이다. 파드는
+프로세스가 아니라 컨테이너(들)를 실행하기 위한 환경이다. 파드는
 삭제될 때까지 유지된다.
 {{< /note >}}
 
-파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다.
+파드의 이름은 반드시 유효한 
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)을 가져야한다. 
+그렇지 않으면, 파드 호스트네임에 예상지 못한 결과가 생길 수도 있다. 최고의 호환성을 위해,
+이름은 [DNS 라벨](/docs/concepts/overview/working-with-objects/names#dns-label-names)의 
+더욱 제한적인 조건을 따라야한다.
 
 ### 파드 OS
 
 {{< feature-state state="stable" for_k8s_version="v1.25" >}}
 
-파드를 실행할 때 OS를 표시하려면 `.spec.os.name` 필드를 `windows` 또는 
-`linux`로 설정해야 한다. 이 두 가지 운영체제는 현재 쿠버네티스에서 지원되는 
-유일한 운영체제이다. 앞으로 이 목록이 확장될 수 있다.
-
-쿠버네티스 v{{< skew currentVersion >}}에서, 이 필드에 대해 설정한 값은
-파드의 {{< glossary_tooltip text="스케줄링" term_id="kube-scheduler" >}}에 영향을 미치지 않는다.
-`.spec.os.name`을 설정하면 파드 검증 시 
-OS를 식별하는 데 도움이 된다. 
-kubelet은 
-자신이 실행되고 있는 노드의 운영체제와 
-동일하지 않은 파드 OS가 명시된 파드의 실행을 거부한다.
-[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)도 이 필드를 사용하여 해당 운영체제와 관련이 없는 정책을 시행하지 않도록 한다.
+`.spec.os.name` 필드는 파드를 실행하고자 하는 운영체제를 나타내기 위해 `windows` 또는 
+`linux`로 설정해야 한다. 현재 쿠버네티스에서 지원되는 운영체제는 
+이 두가지이다. 향후 이 목록이 확장될 수 있다.
+
+쿠버네티스 v{{< skew currentVersion >}}에서, `.spec.os.name` 값은
+{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 파드를 
+어떤 노드에 스케줄링하는지에 결정하는 것에 영향을 주지 않는다. 
+서로 다른 운영체제를 실행하는 노드가 있는 클러스터라면, 
+[kubernetes.io/os](/docs/reference/labels-annotations-taints/#kubernetes-io-os)레이블 
+각 노드에 올바르게 지정해야 하고, 운영체제 레이블을 기반으로 파드의 `nodeSelector`를 
+정의해야 한다. kube-scheduler는 다른 기준을 바탕으로 파드를 노드에 할당하는데, 
+파드 내의 컨테이너에 맞는 OS를 갖는 적절한 노드를 선택하는 데 성공할 수도 있고 실패할 수도 있다.
+[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/) 또한 이 
+필드를 사용하여 해당 운영체제와 관련이 없는 정책을 적용되지 않도록 한다.
 
 ### 파드와 컨트롤러
 
@@ -181,6 +169,10 @@ _파드 템플릿_ 에서 파드를 생성하고 사용자 대신 해당 파드
 사용하여 실제 파드를 생성한다. `PodTemplate` 은 앱을 실행하는 데 사용되는 워크로드 리소스가
 무엇이든지 원하는 상태의 일부이다.
 
+파드를 생성할 때, 파드 내에서 실행되는 컨테이너를 위해 파드 템플릿에서
+[환경 변수](/docs/tasks/inject-data-application/define-environment-variable-container/)를 
+선택할 수 있다.
+
 아래 샘플은 하나의 컨테이너를 시작하는 `template` 이 있는 간단한 잡의
 매니페스트이다. 해당 파드의 컨테이너는 메시지를 출력한 다음 일시 중지한다.
 
@@ -235,13 +227,12 @@ spec:
 
 - 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는
   `namespace`, `name`, `uid`, 또는 `creationTimestamp` 필드를 변경할 수 없다.
-  그리고 `generation` 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는
-  갱신만 허용한다.
+
 - `metadata.deletionTimestamp` 가 설정된 경우,
   `metadata.finalizers` 리스트에 새로운 항목이 추가될 수 없다.
-- 파드 갱신은 `spec.containers[*].image`, `spec.initContainers[*].image`,
-  `spec.activeDeadlineSeconds`, 또는 `spec.tolerations` 이외의 필드는
-  변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다.
+- 파드 갱신은 `spec.containers[*].image`, 
+  `spec.initContainers[*].image`, `spec.activeDeadlineSeconds`, `spec.terminationGracePeriodSeconds`,
+  `spec.tolerations`, 또는 `spec.schedulingGates` 이외의 필드는 변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다.
 - `spec.activeDeadlineSeconds` 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만
   허용한다.
 
@@ -249,6 +240,69 @@ spec:
   1. 필드의 양수를 음수가 아닌 더 작은 숫자로
      갱신.
 
+### 파드 서브리소스(Pod subresources)
+
+앞서 설명한 업데이트 규칙은 일반적인 파드 업데이트에 적용되지만, _서브리소스_를 통해 업데이트할 수 있는 다른 파드 필드도 있다.
+
+- **리사이즈(Resize):** `resize` 서브리소스를 사용하면 컨테이너 리소스(`spec.containers[*].resources`)를 업데이트할 수 있다.
+  자세한 내용은 [컨테이너 리소스 리사이즈](#resize-container-resources)를 참고한다.
+- **임시 컨테이너(Ephemeral Containers):** `ephemeralContainers` 서브리소스를 사용하면
+  {{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}를 
+  파드에 추가할 수 있다.
+  자세한 내용은 [임시 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)를 참고한다.
+- **상태(Status):** `status` 서브리소스를 사용하면 파드 상태를 업데이트할 수 있다.
+  이 서브리소스는 일반적으로 Kubelet과 다른 시스템 컨트롤러에서만 사용한다.
+- **바인딩(Binding):** `binding` 서브리소스를 사용하면 `Binding` 요청을 통해 파드의 `spec.nodeName`을 설정할 수 있다.
+  이 서브리소스는 일반적으로 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에서만 사용한다.
+
+### 파드 세대(Pod generation)
+
+- `metadata.generation` 필드는 고유하다. 시스템에서 자동으로 설정되며, 
+  새 파드는 `metadata.generation` 값을 1로 가지고 시작한다. 파드 스펙의 변경 가능한 필드가 
+  업데이트될 때마다 `metadata.generation` 값이 1씩 증가한다.
+
+{{< feature-state feature_gate_name="PodObservedGenerationTracking" >}}
+
+- `observedGeneration`은 파드 객체의 `status` 섹션에 기록되는 필드이다.
+  `PodObservedGenerationTracking` 기능 게이트가 설정되어 있으면, 
+  Kubelet이 파드 상태를 현재 파드 상태와 동기화하기 위해 `status.observedGeneration`을 설정한다. 파드의 `status.observedGeneration`은 
+  상태가 보고되는 시점의 `metadata.generation`을 반영한다.
+
+{{< note >}}
+`status.observedGeneration` 필드는 kubelet에서 관리한다. 외부 컨트롤러는 이 필드를 수정하지 **않아야** 한다.
+{{< /note >}}
+
+상태 필드는 현재 동기 루프(sync loop)의 `metadata.generation`과 연결될 수도 
+있고, 이전 동기 루프의 `metadata.generation`과 연결될 수도 있다. 핵심 차이는 
+`spec`의 변경이 `status`에 직접 반영되는지, 아니면 실행 중인 프로세스의 간접적인 결과인지에 있다.
+
+#### 직접적인 상태 업데이트(Direct Status Updates)
+
+할당된 spec이 직접적으로 status에 반영되는 상태 필드의 경우,  
+`observedGeneration`은 현재 `metadata.generation`(Generation N)과 연결된다.
+
+이 동작은 다음과 같은 경우에 적용한다.
+
+- **리사이즈 상태(Resize Status)**: 리소스 리사이즈 작업의 상태이다.
+- **할당된 리소스(Allocated Resources)**: 리사이즈 이후 파드에 할당된 리소스이다.
+- **임시 컨테이너(Ephemeral Containers)**: 새 임시 컨테이너가 추가되어 `Waiting` 상태일 때이다.
+
+#### 간접적인 상태 업데이트(Indirect Status Updates)
+
+실행 중인 spec의 결과로 간접적으로 반영되는 상태 필드의 경우,  
+`observedGeneration`은 이전 동기 루프의 `metadata.generation`(Generation N-1)과 연결된다.
+
+이 동작은 다음과 같은 경우에 적용한다.
+
+- **컨테이너 이미지**: `ContainerStatus.ImageID`는 새 이미지가 풀(pull)
+  되고 컨테이너가 업데이트되기 전까지 이전 세대의 이미지를 반영한다.
+- **실제 리소스**: 리사이즈가 진행 중일 때, 실제 사용 중인 리소스는 이전 세대의 
+  요청에 해당한다.
+- **컨테이너 상태**: 리사이즈가 진행 중이고 재시작 정책이 필요한 경우, 이전 세대의  
+  요청을 반영한다.
+- **activeDeadlineSeconds** & **terminationGracePeriodSeconds** &**deletionTimestamp**: 이 필드들이 파드 상태에 미치는 효과는 
+  이전에 관찰된 스펙의 결과이다.
+
 ## 리소스 공유와 통신
 
 파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을
@@ -284,15 +338,34 @@ spec:
 `name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한
 자세한 내용이 있다.
 
-## 컨테이너에 대한 특권 모드
-
-리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
-
-클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다. 파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다. HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
-
-{{< note >}}
-이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
-{{< /note >}}
+## 파드 보안 설정 {#pod-security}
+
+파드와 컨테이너에 보안 제약을 설정하려면 파드 명세의 
+`securityContext` 필드를 사용한다. 이 필드를 사용하면 
+파드나 개별 컨테이너가 할 수 있는 작업을 세밀하게 제어할 수 있다. 예를 들어,
+
+* 특정 리눅스 capabilities를 제거하여 CVE의 영향을 피한다.  
+* 파드의 모든 프로세스를 루트가 아닌 사용자 또는 특정 사용자나 그룹 ID로 
+  실행하도록 강제한다.  
+* 특정 seccomp 프로파일을 설정한다.  
+* Windows 보안 옵션을 설정한다. 예를 들어, 컨테이너를 HostProcess로 실행할지 여부를 지정한다.  
+
+{{< caution >}}
+파드의 securityContext를 사용해 리눅스 컨테이너에서  
+[_특권(privileged) 모드_](/ko/docs/concepts/security/linux-kernel-security-constraints/#privileged-containers)를 
+활성화할 수도 있다. 특권 모드는 securityContext의 다른 많은 보안 설정을 
+무시한다. 이 설정은 securityContext의 다른 필드로 동등한 권한을 부여할 
+수 없을 때를 제외하고는 사용하지 않는 것이 좋다.  
+쿠버네티스 1.26 이상에서는 파드 명세의 securityContext에서 
+`windowsOptions.hostProcess` 플래그를 설정하여  
+Windows 컨테이너를 유사한 특권 모드로 실행할 수 있다. 자세한 내용과 사용 방법은 
+[Windows HostProcess 파드 생성](/ko/docs/tasks/configure-pod-container/create-hostprocess-pod/)을 참고한다.
+{{< /caution >}}
+
+* 사용 가능한 커널 수준 보안 제약에 대해 알아보려면,  
+  [파드와 컨테이너를 위한 리눅스 커널 보안 제약](/ko/docs/concepts/security/linux-kernel-security-constraints)을 참고한다.
+* 파드 보안 컨텍스트에 대해 더 알아보려면,  
+  [파드 또는 컨테이너 보안 컨텍스트 구성하기](/ko/docs/tasks/configure-pod-container/security-context/)를 참고한다.
 
 ## 정적 파드
 
@@ -305,12 +378,13 @@ _정적 파드_ 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserv
 
 정적 파드는 항상 특정 노드의 {{< glossary_tooltip term_id="kubelet" >}} 하나에 바인딩된다.
 정적 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것이다. 즉,
-kubelet을 사용하여 개별 [컨트롤 플레인 컴포넌트](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)를 감독한다.
+kubelet을 사용하여 개별 [컨트롤 플레인 컴포넌트](/ko/docs/concepts/architecture/#control-plane-components)를 감독한다.
 
 kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드" term_id="mirror-pod" >}}를
 생성하려고 한다.
 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
-여기에서 제어할 수는 없다는 의미이다.
+여기에서 제어할 수는 없다는 의미이다. 자세한 내용은 [Create static Pods](/ko/docs/tasks/configure-pod-container/static-pod)을 
+참고한다.
 
 {{< note >}}
 스태틱 파드의 `스펙(spec)`은 다른 API 오브젝트
@@ -319,9 +393,61 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
 {{< glossary_tooltip text="시크릿" term_id="secret" >}}, 등)가 참조할 수 없다.
 {{< /note >}}
 
+## 여러 컨테이너를 가진 파드 {#how-pods-manage-multiple-containers}
+
+파드는 여러 협력 프로세스(컨테이너 형태)를 지원하도록 설계되어 있으며, 
+하나의 응집력 있는 서비스 단위를 형성한다. 파드의 컨테이너는 클러스터 
+내 동일한 물리적 또는 가상 머신에 자동으로 함께 배치되고, 함께 스케줄링된다. 
+컨테이너는 리소스와 종속성을 공유할 수 있고, 서로 통신할 수 있으며, 
+종료 시점과 방식을 조율할 수 있다.
+
+<!-- 본문 앞부분의 텍스트를 의도적으로 반복하되, 더 자세히 설명한다 -->
+쿠버네티스 클러스터에서 파드는 다음 두 가지 주요 방식으로 사용한다.
+
+* **단일 컨테이너를 실행하는 파드**: "파드당 하나의 컨테이너(one-container-per-Pod)" 모델은 
+  가장 일반적인 쿠버네티스 사용 사례이다. 이 경우 파드는 단일 컨테이너를 감싸는 
+  래퍼(wrapper)로 볼 수 있으며, 쿠버네티스는 컨테이너 자체가 아니라 
+  파드를 관리한다.
+* **여러 컨테이너가 함께 동작해야 하는 파드**: 파드는 
+  밀접하게 연결되고 리소스를 공유해야 하는 여러 개의 
+  컨테이너로 구성된 애플리케이션을 
+  캡슐화할 수 있다. 이러한 컨테이너들은 하나의 응집력 
+  있는 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너가 
+  공유 볼륨에 저장된 데이터를 외부로 제공하고, 다른 
+  {{< glossary_tooltip text="사이드카 컨테이너" term_id="sidecar-container" >}}가 
+  해당 파일을 갱신하거나 업데이트하는 방식이다. 
+  파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 
+  식별자를 하나의 단위로 묶는다.
+
+예를 들어, 웹 서버 역할의 한 컨테이너가 
+공유 볼륨에 있는 파일을 제공하고, 별도의 
+[사이드카 컨테이너](/ko/docs/concepts/workloads/pods/sidecar-containers/)가 
+원격 소스에서 해당 파일을 업데이트하는 경우가 있다. 이는 다음 다이어그램과 같다.
+
+{{< figure src="/images/docs/pod.svg" alt="Pod creation diagram" class="diagram-medium" >}}
+
+일부 파드에는 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}
+뿐 아니라 {{< glossary_tooltip text="애플리케이션 컨테이너" term_id="app-container" >}}도 있다.  
+기본적으로 초기화 컨테이너는 애플리케이션 컨테이너가 시작되기 전에 실행되고 완료된다.
+
+또한 [사이드카 컨테이너](/ko/docs/concepts/workloads/pods/sidecar-containers/)를 
+두어, 메인 애플리케이션 파드에 보조 서비스를 제공할 수도 있다(예: 서비스 메시).
+
+{{< feature-state feature_gate_name="SidecarContainers" >}}
+
+`SidecarContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 기본적으로 활성화되어 있다.  
+이 기능을 사용하면 초기화 컨테이너에 `restartPolicy: Always`를 지정할 수 있다.  
+`Always` 재시작 정책을 설정하면 쿠버네티스가 해당 초기화 컨테이너를 
+_사이드카_로 취급하여 파드 전체 수명 동안 계속 실행되도록 한다.
+명시적으로 사이드카 컨테이너로 정의된 컨테이너는 
+메인 애플리케이션 파드보다 먼저 시작되고, 파드가 종료될 때까지 
+실행된다.
+
+
 ## 컨테이너 프로브
 
-_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
+_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 
+진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
 
 - `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
 - `TCPSocketAction` (kubelet에 의해 직접 검사)
@@ -335,17 +461,21 @@ _프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 
 * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
 * [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
   다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
-* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
+* [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/)과 이를 
+  사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
 * 파드는 쿠버네티스 REST API의 최상위 리소스이다.
   {{< api-reference page="workload-resources/pod-v1" >}}
   오브젝트 정의는 오브젝트를 상세히 설명한다.
 * [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](/blog/2015/06/the-distributed-system-toolkit-patterns/)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)에 대해 읽어본다.
 
-쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.
+쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 
+{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 
+공통 파드 API를 래핑하는 이유에 대한 컨텍스트를 이해하기 위해서, 
+다음과 같은 선행 기술에 대해 읽어보자.
 
 * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
 * [Borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/)
 * [Marathon](https://github.com/d2iq-archive/marathon)
 * [Omega](https://research.google/pubs/pub41684/)
-* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
+* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/)