diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md
index 84c85306f1..6625fe615a 100644
--- a/content/ko/docs/concepts/configuration/secret.md
+++ b/content/ko/docs/concepts/configuration/secret.md
@@ -566,7 +566,7 @@ metadata:
 spec:
   containers:
     - name: test-container
-      image: k8s.gcr.io/busybox
+      image: registry.k8s.io/busybox
       command: [ "/bin/sh", "-c", "env" ]
       envFrom:
       - secretRef:
@@ -794,7 +794,7 @@ spec:
       secretName: dotfile-secret
   containers:
   - name: dotfile-test-container
-    image: k8s.gcr.io/busybox
+    image: registry.k8s.io/busybox
     command:
     - ls
     - "-l"
diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
index ee3f0a4af3..21d5b3327f 100644
--- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
@@ -103,9 +103,9 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
 
 훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
 만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
-`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며,
-`PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다.
-실패한 `FailedPreStopHook` 이벤트를 직접 생성하려면, [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) 파일을 수정하여 postStart 명령을 "badcommand"로 변경하고 이를 적용한다.
+`PostStart`의 경우 `FailedPostStartHook` 이벤트이며,
+`PreStop`의 경우 `FailedPreStopHook` 이벤트이다.
+실패한 `FailedPostStartHook` 이벤트를 직접 생성하려면, [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) 파일을 수정하여 postStart 명령을 "badcommand"로 변경하고 이를 적용한다.
 다음은 `kubectl describe pod lifecycle-demo` 를 실행하여 볼 수 있는 이벤트 출력 예시이다.
 
 ```
diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md
index d725169975..5ad0fa4ec6 100644
--- a/content/ko/docs/concepts/containers/images.md
+++ b/content/ko/docs/concepts/containers/images.md
@@ -24,8 +24,8 @@ weight: 10
 ## 이미지 이름
 
 컨테이너 이미지는 일반적으로 `pause`, `example/mycontainer` 또는 `kube-apiserver` 와 같은 이름을 부여한다.
-이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들면, `fictional.registry.example/imagename`
-과 같다. 그리고 포트 번호도 포함할 수 있다. 예를 들면, `fictional.registry.example:10443/imagename` 과 같다.
+이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들어 `fictional.registry.example/imagename`
+와 같다. 그리고 `fictional.registry.example:10443/imagename` 와 같이 포트 번호도 포함할 수 있다.
 
 레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다.
 
@@ -275,6 +275,8 @@ kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
 {{< /note >}}
 
 쿠버네티스는 파드에 컨테이너 이미지 레지스트리 키를 명시하는 것을 지원한다.
+`imagePullSecrets`은 모두 파드와 동일한 네임스페이스에 있어야 한다.
+참조되는 시크릿의 타입은 `kubernetes.io/dockercfg` 이거나 `kubernetes.io/dockerconfigjson` 이어야 한다.
 
 #### 도커 구성으로 시크릿 생성
 
diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index 34ec15dfae..5f7d9a072a 100644
--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -26,7 +26,7 @@ weight: 10
 동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며
 클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다.
 커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로
-[kubectl](/ko/docs/reference/kubectl/)을 사용하여 해당 오브젝트를 생성하고
+{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}을 사용하여 해당 오브젝트를 생성하고
 접근할 수 있다.
 
 ## 커스텀 컨트롤러
@@ -99,7 +99,7 @@ _선언적(declarative) API_ 를 제공하게 된다.
 * 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다.
 
 {{< note >}}
-민감한 데이터에는 [시크릿](/ko/docs/concepts/configuration/secret/)을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전한다.
+민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전하다.
 {{< /note >}}
 
 다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자.
diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 81e753b00a..bd48985467 100644
--- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -68,7 +68,7 @@ metadata:
 spec:
   containers:
     - name: demo-container-1
-      image: k8s.gcr.io/pause:2.0
+      image: registry.k8s.io/pause:2.0
       resources:
         limits:
           hardware-vendor.example/foo: 2
diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md
index 67bde697ba..f59f470f3f 100644
--- a/content/ko/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ko/docs/concepts/extend-kubernetes/operator.md
@@ -15,7 +15,7 @@ weight: 30
 
 ## 동기 부여
 
-오퍼레이터 패턴은 서비스 또는 서비스 셋을 관리하는 운영자의
+_오퍼레이터 패턴_은 서비스 또는 서비스 셋을 관리하는 운영자의
 주요 목표를 포착하는 것을 목표로 한다. 특정 애플리케이션 및
 서비스를 돌보는 운영자는 시스템의 작동 방식, 배포 방법 및 문제가 있는 경우
 대처 방법에 대해 깊이 알고 있다.