Merge pull request #33781 from jihoon-seo/220516_ko_Reorg_the_Debugging_section

[ko] Reorg pages in `dev-1.24-ko.1`

Author: k8s-ci-robot

content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md

@@ -7,7 +7,7 @@ evergreen: true
 ---
 
 **업데이트:** _쿠버네티스의 `dockershim`을 통한 도커 지원이 제거되었습니다.
-더 자세한 정보는 [제거와 관련된 자주 묻는 질문](/dockershim)을 참고하세요.
+더 자세한 정보는 [제거와 관련된 자주 묻는 질문](/dockershim/)을 참고하세요.
 또는 지원 중단에 대한 [GitHub 이슈](https://github.com/kubernetes/kubernetes/issues/106917)에서 논의를 할 수도 있습니다._
 
 ---

content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md

@@ -51,7 +51,7 @@ SIG Windows는 계속해서 성장하는 개발자 커뮤니티를 지원하기
 
 ### 기본(default) seccomp 프로파일
 
-알파 기능인 기본 seccomp 프로파일이 신규 커맨드라인 플래그 및 설정과 함께 kubelet에 추가되었습니다. 이 신규 기능을 사용하면, `Unconfined`대신 `RuntimeDefault` seccomp 프로파일을 기본으로 사용하는 seccomp이 클러스터 전반에서 기본이 됩니다. 이는 쿠버네티스 디플로이먼트(Deployment)의 기본 보안을 강화합니다. 워크로드에 대한 보안이 기본으로 더 강화되었으므로, 이제 보안 관리자도 조금 더 안심하고 쉴 수 있습니다. 이 기능에 대한 자세한 사항은 공식적인 [seccomp 튜토리얼](https://kubernetes.io/docs/tutorials/clusters/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads)을 참고하시기 바랍니다.
+알파 기능인 기본 seccomp 프로파일이 신규 커맨드라인 플래그 및 설정과 함께 kubelet에 추가되었습니다. 이 신규 기능을 사용하면, `Unconfined`대신 `RuntimeDefault` seccomp 프로파일을 기본으로 사용하는 seccomp이 클러스터 전반에서 기본이 됩니다. 이는 쿠버네티스 디플로이먼트(Deployment)의 기본 보안을 강화합니다. 워크로드에 대한 보안이 기본으로 더 강화되었으므로, 이제 보안 관리자도 조금 더 안심하고 쉴 수 있습니다. 이 기능에 대한 자세한 사항은 공식적인 [seccomp 튜토리얼](/docs/tutorials/security/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads)을 참고하시기 바랍니다.
 
 ### kubeadm을 통한 보안성이 더 높은 컨트롤 플레인
 

content/ko/docs/concepts/cluster-administration/_index.md

@@ -59,7 +59,7 @@ no_list: true
 
 * [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
 
-* [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
+* [감사(audit)](/docs/tasks/debug/debug-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
 
 ### kubelet 보안
   * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)

content/ko/docs/concepts/cluster-administration/manage-deployment.md

@@ -461,5 +461,5 @@ kubectl edit deployment/my-nginx
 ## {{% heading "whatsnext" %}}
 
 
-- [애플리케이션 검사 및 디버깅에 `kubectl` 을 사용하는 방법](/docs/tasks/debug-application-cluster/debug-application-introspection/)에 대해 알아본다.
+- [애플리케이션 검사 및 디버깅에 `kubectl` 을 사용하는 방법](/ko/docs/tasks/debug/debug-application/debug-running-pod/)에 대해 알아본다.
 - [구성 모범 사례 및 팁](/ko/docs/concepts/configuration/overview/)을 참고한다.

content/ko/docs/concepts/configuration/manage-resources-containers.md

@@ -229,7 +229,7 @@ kubelet은 파드의 리소스 사용량을 파드
 [`status`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)에 포함하여 보고한다.
 
 클러스터에서 선택적인 [모니터링 도구](/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)를
-사용할 수 있다면, [메트릭 API](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-api)에서
+사용할 수 있다면, [메트릭 API](/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api)에서
 직접 또는 모니터링 도구에서 파드 리소스
 사용량을 검색할 수 있다.
 

content/ko/docs/concepts/configuration/secret.md

@@ -1290,7 +1290,7 @@ kubelet은 시크릿에 있던 기밀 데이터의 로컬 복사본을 삭제한
   base64 인코딩은 암호화 수단이 _아니기 때문에_, 평문과 마찬가지로 기밀성을 제공하지 않는다.
 - 시크릿 API와 통신하는 애플리케이션을 배포할 때, 
   [RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 
-  [인증 정책](/docs/reference/access-authn-authz/authorization/)을 사용하여 
+  [인증 정책](/ko/docs/reference/access-authn-authz/authorization/)을 사용하여 
   접근을 제한해야 한다.
 - 쿠버네티스 API에서, 네임스페이스 내 시크릿에 대한 `watch` 와 `list` 요청은 매우 강력한 기능이다. 
   시크릿 목록 조회를 가능하게 하면 
@@ -1309,7 +1309,7 @@ kubelet은 시크릿에 있던 기밀 데이터의 로컬 복사본을 삭제한
   가장 특권이 있는 시스템 레벨의 컴포넌트에만 이 동작을 허용한다.
 - 시크릿 API와 통신하는 애플리케이션을 배포할 때, 
   [RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 
-  [인증 정책](/docs/reference/access-authn-authz/authorization/)을 사용하여 
+  [인증 정책](/ko/docs/reference/access-authn-authz/authorization/)을 사용하여 
   접근을 제한해야 한다.
 - API 서버에서, (시크릿을 포함한) 오브젝트는 
   {{< glossary_tooltip term_id="etcd" >}}에 저장된다. 그러므로

content/ko/docs/concepts/containers/runtime-class.md

@@ -97,7 +97,7 @@ spec:
 이것은 kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
 만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
 `Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다.
-에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
+에러 메시지에 상응하는 [이벤트](/ko/docs/tasks/debug/debug-application/debug-running-pod/)를
 확인한다.
 
 만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며,

content/ko/docs/concepts/extend-kubernetes/_index.md

@@ -46,7 +46,7 @@ no_list: true
 
 호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
 
-[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
+[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
 
 ## 익스텐션
 

content/ko/docs/concepts/overview/components.md

@@ -114,7 +114,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적
 
 ### 컨테이너 리소스 모니터링
 
-[컨테이너 리소스 모니터링](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은
+[컨테이너 리소스 모니터링](/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)은
 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
 
 ### 클러스터-레벨 로깅

content/ko/docs/concepts/policy/pod-security-policy.md renamed to content/ko/docs/concepts/security/pod-security-policy.md

@@ -652,13 +652,13 @@ spec:
 ### AppArmor
 
 파드시큐리티폴리시의 어노테이션을 통해 제어된다. [AppArmor
-문서](/ko/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다.
+문서](/ko/docs/tutorials/security/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다.
 
 ### Seccomp
 
 쿠버네티스 v1.19부터 파드나 컨테이너의 `securityContext` 에서
 `seccompProfile` 필드를 사용하여 [seccomp 프로파일 사용을
-제어](/docs/tutorials/clusters/seccomp)할 수 있다. 이전 버전에서는, 파드에
+제어](/docs/tutorials/security/seccomp/)할 수 있다. 이전 버전에서는, 파드에
 어노테이션을 추가하여 seccomp를 제어했다. 두 버전에서 동일한 파드시큐리티폴리시를 사용하여
 이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다.