Merge pull request #36772 from jihoon-seo/220913_ko_Update_links
[ko] Update links in `dev-1.24-ko.3`pull/36802/head
Kubernetes Prow Robot
GitHub
commit
fc9cd8d1d8
|
|
@ -21,7 +21,7 @@ evergreen: true
|
|||
|
||||
**당황할 필요는 없습니다. 말처럼 극적이진 않습니다.**
|
||||
|
||||
요약하자면, 기본(underlying) 런타임 중 하나인 도커는 쿠버네티스의 [컨테이너 런타임 인터페이스(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)를
|
||||
요약하자면, 기본(underlying) 런타임 중 하나인 도커는 쿠버네티스의 [컨테이너 런타임 인터페이스(CRI)](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)를
|
||||
사용하는 런타임으로써는 더 이상 사용되지 않습니다(deprecated).
|
||||
도커가 생성한 이미지는 늘 그래왔듯이 모든 런타임을 통해 클러스터에서
|
||||
계속 작동될 것입니다.
|
||||
|
|
@ -72,7 +72,7 @@ containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심
|
|||
스스로도 생각할 수 있을 것입니다. containerd가 도커 스택에 포함되어 있는 것이라면, 도커심이
|
||||
쿠버네티스에 왜 필요할까요?
|
||||
|
||||
도커는 [컨테이너 런타임 인터페이스](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)인 CRI를 준수하지 않습니다.
|
||||
도커는 [컨테이너 런타임 인터페이스](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)인 CRI를 준수하지 않습니다.
|
||||
만약 이를 준수했다면, 심(shim)이 필요하지 않았을 것입니다. 그러나
|
||||
이건 세상의 종말이 아니며, 당황할 필요도 없습니다. 여러분은 단지
|
||||
컨테이너 런타임을 도커에서 지원되는 다른 컨테이너 런타임으로 변경하기만 하면 됩니다.
|
||||
|
|
|
|||
|
|
@ -18,18 +18,18 @@ evergreen: true
|
|||
|
||||
연간 4회에서 3회로의 릴리스 케이던스 변경을 통해 프로젝트의 다양한 측면(기여와 릴리스가 관리되는 방법, 업그레이드 및 최신 릴리스 유지에 대한 커뮤니티의 역량 등)에 대한 균형을 이루고자 하였습니다.
|
||||
|
||||
더 자세한 사항은 공식 블로그 포스트 [쿠버네티스 릴리스 케이던스 변경: 알아두어야 할 사항](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/)에서 확인할 수 있습니다.
|
||||
더 자세한 사항은 공식 블로그 포스트 [쿠버네티스 릴리스 케이던스 변경: 알아두어야 할 사항](/blog/2021/07/20/new-kubernetes-release-cadence/)에서 확인할 수 있습니다.
|
||||
|
||||
|
||||
## 주요 주제
|
||||
|
||||
### 서버-사이드 어플라이(Server-side Apply)가 GA로 졸업
|
||||
|
||||
[서버-사이드 어플라이](https://kubernetes.io/docs/reference/using-api/server-side-apply/)는 쿠버네티스 API 서버에서 동작하는 신규 필드 오너십이며 오브젝트 병합 알고리즘입니다. 서버-사이드 어플라이는 사용자와 컨트롤러가 선언적인 구성을 통해서 자신의 리소스를 관리할 수 있도록 돕습니다. 이 기능은 단순히 fully specified intent를 전송하는 것만으로 자신의 오브젝트를 선언적으로 생성 또는 수정할 수 있도록 허용합니다. 몇 릴리스에 걸친 베타 과정 이후, 서버-사이드 어플라이는 이제 GA(generally available)가 되었습니다.
|
||||
[서버-사이드 어플라이](/docs/reference/using-api/server-side-apply/)는 쿠버네티스 API 서버에서 동작하는 신규 필드 오너십이며 오브젝트 병합 알고리즘입니다. 서버-사이드 어플라이는 사용자와 컨트롤러가 선언적인 구성을 통해서 자신의 리소스를 관리할 수 있도록 돕습니다. 이 기능은 단순히 fully specified intent를 전송하는 것만으로 자신의 오브젝트를 선언적으로 생성 또는 수정할 수 있도록 허용합니다. 몇 릴리스에 걸친 베타 과정 이후, 서버-사이드 어플라이는 이제 GA(generally available)가 되었습니다.
|
||||
|
||||
### 외부 크리덴셜 제공자가 이제 스테이블이 됨
|
||||
|
||||
쿠버네티스 클라이언트 [크리덴셜 플러그인](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)에 대한 지원은 1.11부터 베타였으나, 쿠버네티스 1.22 릴리스에서 스테이블로 졸업하였습니다. 해당 GA 기능 집합은 인터랙티브 로그인 플로우(interactive login flow)를 제공하는 플러그인에 대한 향상된 지원을 포함합니다. 또한, 많은 버그가 수정되었습니다. 플러그인 개발은 [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin)을 통해 시작할 수 있습니다.
|
||||
쿠버네티스 클라이언트 [크리덴셜 플러그인](/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)에 대한 지원은 1.11부터 베타였으나, 쿠버네티스 1.22 릴리스에서 스테이블로 졸업하였습니다. 해당 GA 기능 집합은 인터랙티브 로그인 플로우(interactive login flow)를 제공하는 플러그인에 대한 향상된 지원을 포함합니다. 또한, 많은 버그가 수정되었습니다. 플러그인 개발은 [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin)을 통해 시작할 수 있습니다.
|
||||
|
||||
### etcd 3.5.0으로 변경
|
||||
|
||||
|
|
@ -65,13 +65,13 @@ SIG Windows는 계속해서 성장하는 개발자 커뮤니티를 지원하기
|
|||
|
||||
GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에서 제거되었습니다. 기존의 모든 오브젝트는 스테이블 APIs를 통해 상호 작용할 수 있습니다. 이 제거에는 `Ingress`, `IngressClass`, `Lease`, `APIService`, `ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `TokenReview`, `SubjectAccessReview`, `CertificateSigningRequest` API의 베타 버전이 포함되었습니다.
|
||||
|
||||
전체 항목은 [사용 중단된 API에 대한 마이그레이션 지침](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22)과 블로그 포스트 [1.22에서 쿠버네티스 API와 제거된 기능: 알아두어야 할 사항](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/)에서 확인 가능합니다.
|
||||
전체 항목은 [사용 중단된 API에 대한 마이그레이션 지침](/docs/reference/using-api/deprecation-guide/#v1-22)과 블로그 포스트 [1.22에서 쿠버네티스 API와 제거된 기능: 알아두어야 할 사항](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/)에서 확인 가능합니다.
|
||||
|
||||
### 임시(ephemeral) 컨테이너에 대한 API 변경 및 개선
|
||||
|
||||
1.22에서 [임시 컨테이너](https://kubernetes.io/ko/docs/concepts/workloads/pods/ephemeral-containers/)를 생성하기 위한 API가 변경되었습니다. 임시 컨테이너 기능은 알파이며 기본적으로 비활성화되었습니다. 신규 API는 예전 API를 사용하려는 클라이언트에 대해 동작하지 않습니다.
|
||||
1.22에서 [임시 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)를 생성하기 위한 API가 변경되었습니다. 임시 컨테이너 기능은 알파이며 기본적으로 비활성화되었습니다. 신규 API는 예전 API를 사용하려는 클라이언트에 대해 동작하지 않습니다.
|
||||
|
||||
스테이블 기능에 대해서, kubectl 도구는 쿠버네티스의 [버전 차이(skew) 정책](https://kubernetes.io/ko/releases/version-skew-policy/)을 따릅니다. 그러나, kubectl v1.21 이하의 버전은 임시 컨테이너에 대한 신규 API를 지원하지 않습니다. 만약 `kubectl debug`를 사용하여 임시 컨테이너를 생성할 계획이 있고 클러스터에서 쿠버네티스 v1.22로 구동하고 있는 경우, kubectl v1.21 이하의 버전에서는 그렇게 할 수 없다는 것을 알아두어야 합니다. 따라서 만약 클러스터 버전을 혼합하여 `kubectl debug`를 사용하려면 kubectl를 1.22로 업데이트하길 바랍니다.
|
||||
스테이블 기능에 대해서, kubectl 도구는 쿠버네티스의 [버전 차이(skew) 정책](/ko/releases/version-skew-policy/)을 따릅니다. 그러나, kubectl v1.21 이하의 버전은 임시 컨테이너에 대한 신규 API를 지원하지 않습니다. 만약 `kubectl debug`를 사용하여 임시 컨테이너를 생성할 계획이 있고 클러스터에서 쿠버네티스 v1.22로 구동하고 있는 경우, kubectl v1.21 이하의 버전에서는 그렇게 할 수 없다는 것을 알아두어야 합니다. 따라서 만약 클러스터 버전을 혼합하여 `kubectl debug`를 사용하려면 kubectl를 1.22로 업데이트하길 바랍니다.
|
||||
|
||||
## 기타 업데이트
|
||||
|
||||
|
|
@ -99,9 +99,9 @@ GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에
|
|||
|
||||
# 릴리스 위치
|
||||
|
||||
쿠버네티스 1.22는 [여기](https://kubernetes.io/releases/download/)에서 다운로드할 수 있고, [GitHub 프로젝트](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0)에서도 찾을 수 있습니다.
|
||||
쿠버네티스 1.22는 [여기](/releases/download/)에서 다운로드할 수 있고, [GitHub 프로젝트](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0)에서도 찾을 수 있습니다.
|
||||
|
||||
쿠버네티스를 시작하는 데 도움이 되는 좋은 자료가 많이 있습니다. 쿠버네티스 사이트에서 [상호 작용형 튜토리얼](https://kubernetes.io/ko/docs/tutorials/)을 수행할 수도 있고, [kind](https://kind.sigs.k8s.io)와 도커 컨테이너를 사용하여 로컬 클러스터를 사용자의 머신에서 구동해볼 수도 있습니다. 클러스터를 스크래치(scratch)부터 구축해보고 싶다면, Kelsey Hightower의 [쿠버네티스 어렵게 익히기(the Hard Way)](https://github.com/kelseyhightower/kubernetes-the-hard-way) 튜토리얼을 확인해보시기 바랍니다.
|
||||
쿠버네티스를 시작하는 데 도움이 되는 좋은 자료가 많이 있습니다. 쿠버네티스 사이트에서 [상호 작용형 튜토리얼](/ko/docs/tutorials/)을 수행할 수도 있고, [kind](https://kind.sigs.k8s.io)와 도커 컨테이너를 사용하여 로컬 클러스터를 사용자의 머신에서 구동해볼 수도 있습니다. 클러스터를 스크래치(scratch)부터 구축해보고 싶다면, Kelsey Hightower의 [쿠버네티스 어렵게 익히기(the Hard Way)](https://github.com/kelseyhightower/kubernetes-the-hard-way) 튜토리얼을 확인해보시기 바랍니다.
|
||||
|
||||
# 릴리스 팀
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에
|
|||
* [쿠버네티스 기여자](https://www.kubernetes.dev/) 웹사이트에서 기여에 대한 더 자세한 사항을 확인
|
||||
* 최신 정보 업데이트를 위해 [@Kubernetesio](https://twitter.com/kubernetesio) 트위터 팔로우
|
||||
* [논의(discuss)](https://discuss.kubernetes.io/)에서 커뮤니티 논의에 참여
|
||||
* [슬랙](http://slack.k8s.io/)에서 커뮤니티에 참여
|
||||
* [슬랙](https://slack.k8s.io/)에서 커뮤니티에 참여
|
||||
* 쿠버네티스 [사용기](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) 공유
|
||||
* 쿠버네티스에서 일어나는 일에 대한 자세한 사항을 [블로그](https://kubernetes.io/blog/)를 통해 읽기
|
||||
* 쿠버네티스에서 일어나는 일에 대한 자세한 사항을 [블로그](/blog/)를 통해 읽기
|
||||
* [쿠버네티스 릴리스 팀](https://github.com/kubernetes/sig-release/tree/master/release-team)에 대해 더 알아보기
|
||||
|
|
|
|||
|
|
@ -16,7 +16,8 @@ weight: 50
|
|||
* [Stale 또는 만료된 CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
|
||||
* {{<glossary_tooltip text="노드" term_id="node">}} 는 다음과 같은 상황에서 삭제된다:
|
||||
* 클러스터가 [클라우드 컨트롤러 매니저](/ko/docs/concepts/architecture/cloud-controller/)를 사용하는 클라우드
|
||||
* 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스
|
||||
* 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는
|
||||
온프레미스
|
||||
* [노드 리스(Lease) 오브젝트](/ko/docs/concepts/architecture/nodes/#heartbeats)
|
||||
|
||||
## 소유자(Owners)와 종속(dependents) {#owners-dependents}
|
||||
|
|
@ -65,7 +66,8 @@ v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `
|
|||
* 포그라운드 캐스케이딩 삭제(Foreground cascading deletion)
|
||||
* 백그라운드 캐스케이딩 삭제(Background cascading deletion)
|
||||
|
||||
또한 쿠버네티스의 {{<glossary_tooltip text="finalizers" term_id="finalizer">}}를 사용하여 가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다.
|
||||
또한 쿠버네티스의 {{<glossary_tooltip text="finalizers" term_id="finalizer">}}를 사용하여
|
||||
가비지 수집이 소유자 참조가 있는 자원을 언제 어떻게 삭제할 것인지 제어할 수 있다.
|
||||
|
||||
### 포그라운드 캐스케이딩 삭제 {#foreground-deletion}
|
||||
|
||||
|
|
@ -77,90 +79,99 @@ v1.20 이상에서, 가비지 수집기가 잘못된 교차 네임스페이스 `
|
|||
오브젝트가 삭제 표시된 시간으로 설정한다.
|
||||
* 쿠버네티스 API 서버가 `metadata.finalizers` 필드를 `foregroundDeletion`로
|
||||
설정한다.
|
||||
* 오브젝트는 삭제 과정이 완료되기 전까지 쿠버네티스 API를 통해 조회할 수 있다.
|
||||
* 오브젝트는 삭제 과정이 완료되기 전까지
|
||||
쿠버네티스 API를 통해 조회할 수 있다.
|
||||
|
||||
소유자 오브젝트가 삭제 중 상태가 된 이후, 컨트롤러는 종속 오브젝트들을 삭제한다.
|
||||
모든 종속 오브젝트들이 삭제되고나면, 컨트롤러가 소유자 오브젝트를 삭제한다.
|
||||
이 시점에서 오브젝트는 더 이상 쿠버네티스 API를 통해 조회할 수 없다.
|
||||
이 시점에서 오브젝트는 더 이상
|
||||
쿠버네티스 API를 통해 조회할 수 없다.
|
||||
|
||||
포그라운드 캐스케이딩 삭제 중에 소유자 오브젝트의 삭제를 막는
|
||||
종속 오브젝트는`ownerReference.blockOwnerDeletion=true`필드를 가진 오브젝트다.
|
||||
더 자세한 내용은 [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)를
|
||||
더 자세한 내용은 [Use foreground cascading deletion](/ko/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)를
|
||||
참고한다.
|
||||
|
||||
### 백그라운드 캐스케이딩 삭제 {#background-deletion}
|
||||
|
||||
백그라운드 캐스케이딩 삭제에서는 쿠버네티스 API 서버가 소유자 오브젝트를 즉시 삭제하고
|
||||
백그라운드에서 컨트롤러가 종속 오브젝트들을 삭제한다.
|
||||
쿠버네티스는 수동으로 포그라운드 삭제를 사용하거나 종속 오브젝트를 분리하지 않는다면, 기본적으로 백그라운드 캐스케이딩 삭제를 사용한다.
|
||||
쿠버네티스는 수동으로 포그라운드 삭제를 사용하거나 종속 오브젝트를 분리하지 않는다면,
|
||||
기본적으로 백그라운드 캐스케이딩 삭제를 사용한다.
|
||||
|
||||
더 자세한 내용은 [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)를
|
||||
더 자세한 내용은 [Use background cascading deletion](/ko/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)를
|
||||
참고한다.
|
||||
|
||||
### 분리된 종속 (Orphaned dependents)
|
||||
|
||||
쿠버네티스가 소유자 오브젝트를 삭제할 때, 남은 종속 오브젝트는 *분리된* 오브젝트라고 부른다.
|
||||
기본적으로 쿠버네티스는 종속 오브젝트를 삭제한다.
|
||||
이 행동을 오버라이드하는 방법을 보려면,
|
||||
다음 [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)를 참고한다.
|
||||
기본적으로 쿠버네티스는 종속 오브젝트를 삭제한다. 이 행동을 오버라이드하는 방법을 보려면,
|
||||
[Delete owner objects and orphan dependents](/ko/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy)를 참고한다.
|
||||
|
||||
## 사용되지 않는 컨테이너와 이미지 가비지 수집 {#containers-images}
|
||||
|
||||
{{<glossary_tooltip text="kubelet" term_id="kubelet">}}은
|
||||
사용되지 않는 이미지에 대한 가비지 수집을 5분마다, 컨테이너에 대한 가비지 수집을 1분마다
|
||||
수행한다. 외부 가비지 수집 도구는 Kubelet 의 행동을 중단시키고
|
||||
수행한다. 외부 가비지 수집 도구는 kubelet 의 행동을 중단시키고
|
||||
존재해야만 하는 컨테이너를 삭제할 수 있으므로 사용을 피해야 한다.
|
||||
|
||||
사용되지 않는 컨테이너와 이미지에 대한 가비지 수집 옵션을 구성하려면,
|
||||
[configuration file](/docs/tasks/administer-cluster/kubelet-config-file/) 사용하여 Kubelet 을 수정하거나
|
||||
[configuration file](/docs/tasks/administer-cluster/kubelet-config-file/) 사용하여
|
||||
kubelet 을 수정하거나
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 리소스 타입의
|
||||
가비지 수집과 관련된 파라미터를 수정한다.
|
||||
|
||||
### 컨테이너 이미지 라이프사이클
|
||||
|
||||
쿠버네티스는 Kubelet의 일부인 *이미지 관리자*가 {{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}와 협동하여
|
||||
쿠버네티스는 kubelet의 일부인 *이미지 관리자*가
|
||||
{{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}와 협동하여
|
||||
모든 이미지의 라이프사이클을 관리한다.
|
||||
Kubelet은 가비지 수집 결정을 내릴 때, 다음 디스크 사용량 제한을 고려한다.
|
||||
kubelet은 가비지 수집 결정을 내릴 때,
|
||||
다음 디스크 사용량 제한을 고려한다.
|
||||
|
||||
* `HighThresholdPercent`
|
||||
* `LowThresholdPercent`
|
||||
|
||||
`HighThresholdPercent` 값을 초과한 디스크 사용량은
|
||||
마지막으로 사용된 시간을 기준으로 오래된 이미지순서대로 이미지를 삭제하는
|
||||
가비지 수집을 트리거한다. Kubelet은 디스크 사용량이 `LowThresholdPercent` 값에 도달할 때까지
|
||||
가비지 수집을 트리거한다. kubelet은 디스크 사용량이 `LowThresholdPercent` 값에 도달할 때까지
|
||||
이미지를 삭제한다.
|
||||
|
||||
### 컨테이너 이미지 가비지 수집 {#container-image-garbage-collection}
|
||||
|
||||
Kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로 사용되지 않는 컨테이너들을 삭제한다:
|
||||
kubelet은 사용자가 정의할 수 있는 다음 변수들을 기반으로
|
||||
사용되지 않는 컨테이너들을 삭제한다:
|
||||
|
||||
* `MinAge`: Kubelet이 가비지 수집할 수 있는 최소 나이. `0`으로 세팅하여 비활성화할 수 있다.
|
||||
* `MinAge`: kubelet이 가비지 수집할 수 있는 최소 나이.
|
||||
`0`으로 세팅하여 비활성화할 수 있다.
|
||||
* `MaxPerPodContainer`: 각 파드 쌍이 가질 수 있는 죽은 컨테이너의 최대 개수.
|
||||
`0`으로 세팅하여 비활성화할 수 있다.
|
||||
* `MaxContainers`: 클러스터가 가질 수 있는 죽은 컨테이너의 최대 개수
|
||||
`0`으로 세팅하여 비활성화할 수 있다.
|
||||
|
||||
위 변수와 더불어, Kubelet은 식별할 수 없고 삭제된 컨테이너들을 오래된 순서대로 가비지 수집한다.
|
||||
위 변수와 더불어, kubelet은 식별할 수 없고 삭제된 컨테이너들을
|
||||
오래된 순서대로 가비지 수집한다.
|
||||
|
||||
`MaxPerPodContainer`와 `MaxContainer`는
|
||||
파드의 최대 컨테이너 개수(`MaxPerPodContainer`)를 유지하는 것이
|
||||
전체 죽은 컨테이너의 개수 제한(`MaxContainers`)을 초과하게 될 때,
|
||||
서로 충돌이 발생할 수 있다.
|
||||
이 상황에서 Kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다.
|
||||
이 상황에서 kubelet은 충돌을 해결하기 위해 `MaxPodPerContainer`를 조절한다.
|
||||
최악의 시나리오에서는 `MaxPerPodContainer`를 `1`로 다운그레이드하고
|
||||
가장 오래된 컨테이너들을 축출한다.
|
||||
또한, 삭제된 파드가 소유한 컨테이너들은 `MinAge`보다 오래되었을 때 삭제된다.
|
||||
|
||||
{{<note>}}
|
||||
Kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을 수행한다.
|
||||
kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을 수행한다.
|
||||
{{</note>}}
|
||||
|
||||
## 가비지 수집 구성하기 {#configuring-gc}
|
||||
|
||||
자원을 관리하는 컨트롤러의 옵션을 구성하여 가비지 컬렉션을 수정할 수 있다.
|
||||
다음 페이지에서 어떻게 가비지 수집을 구성할 수 있는지 확인할 수 있다:
|
||||
자원을 관리하는 컨트롤러의 옵션을 구성하여
|
||||
가비지 컬렉션을 수정할 수 있다.
|
||||
다음 페이지에서 어떻게 가비지 수집을 구성할 수 있는지 확인할 수 있다.
|
||||
|
||||
* [쿠버네티스 오브젝트의 캐스케이딩 삭제 구성하기](/docs/tasks/administer-cluster/use-cascading-deletion/)
|
||||
* [쿠버네티스 오브젝트의 캐스케이딩 삭제 구성하기](/ko/docs/tasks/administer-cluster/use-cascading-deletion/)
|
||||
* [완료된 잡 자동 정리하기](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
|
||||
<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
|
||||
|
|
@ -168,5 +179,5 @@ Kubelet은 자신이 관리하는 컨테이너에 대한 가비지 수집만을
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [쿠버네티스 오브젝트의 소유권](/docs/concepts/overview/working-with-objects/owners-dependents/)에 대해 알아보자.
|
||||
* 쿠버네티스 [finalizers](/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자.
|
||||
* 쿠버네티스 [finalizers](/ko/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자.
|
||||
* 완료된 잡을 정리하는 [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) 에 대해 알아보자.
|
||||
|
|
|
|||
|
|
@ -79,9 +79,9 @@ no_list: true
|
|||
|
||||
### kubelet 보안
|
||||
|
||||
* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
|
||||
* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet 인증/인가](/ko/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
|
||||
## 선택적 클러스터 서비스
|
||||
|
||||
|
|
|
|||
|
|
@ -643,7 +643,7 @@ spec:
|
|||
|
||||
프로세스 ID(PID) 제한은 kubelet의 구성에 대해
|
||||
주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다.
|
||||
자세한 내용은 [PID 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
|
||||
자세한 내용은 [PID 제한](/ko/docs/concepts/policy/pid-limiting/)을 참고한다.
|
||||
|
||||
## 문제 해결
|
||||
|
||||
|
|
|
|||
|
|
@ -244,7 +244,7 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
|
|||
스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
|
||||
컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서
|
||||
기본 스케줄러를 완전히 교체하거나,
|
||||
[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를
|
||||
[여러 스케줄러](/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를
|
||||
동시에 실행할 수 있다.
|
||||
|
||||
이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ weight: 30
|
|||
## 네임스페이스 다루기
|
||||
|
||||
네임스페이스의 생성과 삭제는
|
||||
[네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다.
|
||||
[네임스페이스 관리자 가이드 문서](/ko/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다.
|
||||
|
||||
{{< note >}}
|
||||
`kube-` 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템용으로 예약되어 있으므로, 사용자는 이러한 네임스페이스를 생성하지 않는다.
|
||||
|
|
@ -145,5 +145,5 @@ kubectl api-resources --namespaced=false
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
|
||||
* [네임스페이스 삭제](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)에 대해 더 배우기.
|
||||
* [신규 네임스페이스 생성](/ko/docs/tasks/administer-cluster/namespaces/#새-네임스페이스-생성하기)에 대해 더 배우기.
|
||||
* [네임스페이스 삭제](/ko/docs/tasks/administer-cluster/namespaces/#네임스페이스-삭제하기)에 대해 더 배우기.
|
||||
|
|
|
|||
|
|
@ -61,5 +61,5 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
|
|||
- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
|
||||
- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
|
||||
- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
|
||||
- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
|
||||
- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/ko/docs/tasks/administer-cluster/limit-storage-consumption/#스토리지-요청을-제한하기-위한-리밋레인지-limitrange).
|
||||
- [네임스페이스당 할당량을 설정하는 자세한 예시](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ no_list: true
|
|||
* [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
* [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)
|
||||
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
|
||||
* [파드 토폴로지 분배 제약 조건](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
|
||||
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)
|
||||
* [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)
|
||||
* [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)
|
||||
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
|
||||
|
|
|
|||
|
|
@ -481,7 +481,7 @@ spec:
|
|||
|
||||
_토폴로지 분배 제약 조건_을 사용하여 지역(regions), 영역(zones), 노드 또는 사용자가 정의한 다른 토폴로지 도메인과 같은 장애 도메인 사이에서 {{< glossary_tooltip text="파드" term_id="Pod" >}}가 클러스터 전체에 분산되는 방식을 제어할 수 있다. 성능, 예상 가용성 또는 전체 활용도를 개선하기 위해 이 작업을 수행할 수 있다.
|
||||
|
||||
[파드 토폴로지 분배 제약 조건](/docs/concepts/scheduling-eviction/topology-spread-constraints/)에서
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)에서
|
||||
작동 방식에 대해 더 자세히 알아볼 수 있다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
|
|
|||
|
|
@ -83,10 +83,10 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
|
||||
* [파드 토폴로지 분배 제약 조건](/docs/concepts/scheduling-eviction/topology-spread-constraints/)에 대해 읽기
|
||||
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)에 대해 읽기
|
||||
* kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
|
||||
* [kube-scheduler 구성(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽기
|
||||
* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
|
||||
* [멀티 스케줄러 구성하기](/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
|
||||
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
|
||||
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
|
||||
* 볼륨을 사용하는 파드의 스케줄링에 대해 배우기
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
|
|||
인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다.
|
||||
|
||||
- [인증하기](/docs/reference/access-authn-authz/authentication/)
|
||||
- [부트스트랩 토큰(bootstrap token)으로 인증하기](/docs/reference/access-authn-authz/bootstrap-tokens/)
|
||||
- [부트스트랩 토큰(bootstrap token)으로 인증하기](/ko/docs/reference/access-authn-authz/bootstrap-tokens/)
|
||||
- [어드미션 컨트롤러(admission controller)](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
- [동적 어드미션(admission) 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
- [인가](/ko/docs/reference/access-authn-authz/authorization/)
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리
|
|||
|
||||
쿠버네티스 보안 주제에 관련한 내용들을 배워보자.
|
||||
|
||||
* [파드 보안 표준](/docs/concepts/security/pod-security-standards/)
|
||||
* [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)
|
||||
* [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)
|
||||
* [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access)
|
||||
* [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되
|
|||
새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.
|
||||
|
||||
1. 파드시큐리티폴리시를
|
||||
[파드 보안 표준](/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.
|
||||
[파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.
|
||||
|
||||
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
|
||||
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
|
||||
|
|
@ -497,7 +497,7 @@ podsecuritypolicy "example" deleted
|
|||
{{< codenew file="policy/restricted-psp.yaml" >}}
|
||||
|
||||
더 많은 예제는
|
||||
[파드 보안 표준](/docs/concepts/security/pod-security-standards/#policy-instantiation)을 본다.
|
||||
[파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/#정책-초기화)을 본다.
|
||||
|
||||
## 정책 레퍼런스
|
||||
|
||||
|
|
@ -773,7 +773,7 @@ spec:
|
|||
미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)에서
|
||||
파드시큐리티폴리시의 미래에 대해 알아본다.
|
||||
|
||||
- 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.
|
||||
- 폴리시 권장 사항에 대해서는 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)을 참조한다.
|
||||
|
||||
- API 세부 정보는
|
||||
[파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ weight: 60
|
|||
|
||||
워크로드(파드 혹은 파드를 관리하는
|
||||
[워크로드 리소스](/ko/docs/concepts/workloads/controllers/))를 생성할 수 있는 사용자는
|
||||
[파드 시큐리티 스탠다드](/docs/concepts/security/pod-security-standards/)에
|
||||
[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)에
|
||||
기반한 제한 사항이 없을 시에는 해당 노드에 대한 접근 권한을 부여받을 수 있다.
|
||||
|
||||
특권 파드 실행 권한을 가지는 사용자는 해당 노드에 대한 권한을 부여받을 수 있으며,
|
||||
|
|
|
|||
|
|
@ -423,4 +423,4 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
|
|||
|
||||
* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
|
||||
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/ko/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
|
||||
* [외부 로드 밸런서를 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.
|
||||
* [외부 로드 밸런서를 생성하기](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.
|
||||
|
|
|
|||
|
|
@ -305,7 +305,7 @@ IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주
|
|||
{{< /note >}}
|
||||
|
||||
윈도우의 다른 네트워크 모델에 대한 내용은
|
||||
[윈도우에서의 네트워킹](/docs/concepts/services-networking/windows-networking#network-modes)을 살펴본다.
|
||||
[윈도우에서의 네트워킹](/ko/docs/concepts/services-networking/windows-networking/#네트워크-모드)을 살펴본다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -63,5 +63,5 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기
|
||||
* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
|
||||
* [서비스 외부 트래픽 정책](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
|
||||
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기
|
||||
|
|
|
|||
|
|
@ -204,8 +204,8 @@ subsets:
|
|||
엔드포인트 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
|
||||
서비스를 위한 객체인 [엔드포인트](/ko/docs/reference/kubernetes-api/service-resources/endpoints-v1/)
|
||||
를 만들 때, 새로운 객체의 이름을
|
||||
서비스를 위한 객체인 [엔드포인트](/docs/reference/kubernetes-api/service-resources/endpoints-v1/)를 만들 때,
|
||||
새로운 객체의 이름을
|
||||
그것의 서비스 이름과 같게 설정해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ weight: 21 # just after persistent volumes
|
|||
`path` 필드는 프로젝티드 볼륨의 마운트 지점에 대한 상대 경로를 지정한다.
|
||||
|
||||
{{< note >}}
|
||||
[`하위 경로`](/docs/concepts/storage/volumes/#using-subpath) 볼륨 마운트로 프로젝티드 볼륨 소스를 사용하는 컨테이너는
|
||||
[`하위 경로`](/ko/docs/concepts/storage/volumes/#using-subpath) 볼륨 마운트로 프로젝티드 볼륨 소스를 사용하는 컨테이너는
|
||||
해당 볼륨 소스에 대한 업데이트를 수신하지 않는다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -837,7 +837,7 @@ spec:
|
|||
### projected
|
||||
|
||||
`Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다.
|
||||
더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다.
|
||||
더 자세한 사항은 [projected volumes](/ko/docs/concepts/storage/projected-volumes/)를 참고한다.
|
||||
|
||||
### quobyte (사용 중단됨) {#quobyte}
|
||||
|
||||
|
|
|
|||
|
|
@ -268,7 +268,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
|
|||
|
||||
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
|
||||
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
|
||||
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
|
||||
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/ko/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
|
||||
참고로, 드물기는 하지만, 동일한 인덱스에 대해 둘 이상의 파드를 시작할 수
|
||||
있지만, 그 중 하나만 완료 횟수에 포함된다.
|
||||
|
||||
|
|
@ -486,7 +486,7 @@ spec:
|
|||
|
||||
[작업 항목 당 파드가 있는 큐]: /ko/docs/tasks/job/coarse-parallel-processing-work-queue/
|
||||
[가변 파드 수를 가진 큐]: /ko/docs/tasks/job/fine-parallel-processing-work-queue/
|
||||
[정적 작업 할당을 사용한 인덱싱된 잡]: /docs/tasks/job/indexed-parallel-processing-static/
|
||||
[정적 작업 할당을 사용한 인덱싱된 잡]: /ko/docs/tasks/job/indexed-parallel-processing-static/
|
||||
[잡 템플릿 확장]: /ko/docs/tasks/job/parallel-processing-expansion/
|
||||
|
||||
## 고급 사용법
|
||||
|
|
@ -773,7 +773,7 @@ API 서버에서 파드가 제거되면 이를 알아챈다.
|
|||
* 다른 방식으로 잡을 구동하는 방법에 대해서 읽는다.
|
||||
* [작업 대기열을 사용한 거친 병렬 처리](/ko/docs/tasks/job/coarse-parallel-processing-work-queue/)
|
||||
* [작업 대기열을 사용한 정밀 병렬 처리](/ko/docs/tasks/job/fine-parallel-processing-work-queue/)
|
||||
* [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/docs/tasks/job/indexed-parallel-processing-static/)(베타) 사용
|
||||
* [병렬 처리를 위한 정적 작업 할당으로 인덱스된 잡](/ko/docs/tasks/job/indexed-parallel-processing-static/)(베타) 사용
|
||||
* 템플릿 기반으로 복수의 잡 생성: [확장을 사용한 병렬 처리](/ko/docs/tasks/job/parallel-processing-expansion/)
|
||||
* [완료된 잡을 자동으로 정리](#clean-up-finished-jobs-automatically) 섹션 내 링크를 따라서
|
||||
클러스터가 완료되거나 실패된 태스크를 어떻게 정리하는지에 대해 더 배운다.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ no_list: true
|
|||
참조 문헌
|
||||
|
||||
- [인증](/docs/reference/access-authn-authz/authentication/)
|
||||
- [부트스트랩 토큰 인증](/docs/reference/access-authn-authz/bootstrap-tokens/)
|
||||
- [부트스트랩 토큰 인증](/ko/docs/reference/access-authn-authz/bootstrap-tokens/)
|
||||
- [승인 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
|
||||
- [동적 승인 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
- [인가](/ko/docs/reference/access-authn-authz/authorization/)
|
||||
|
|
@ -24,5 +24,5 @@ no_list: true
|
|||
- 서비스 어카운트
|
||||
- [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
- [관리](/ko/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
- [kubelet 인증과 인가](/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
- [kubelet 인증과 인가](/ko/docs/reference/access-authn-authz/kubelet-authn-authz/)
|
||||
- kubelet [TLS 부트스트래핑](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)을 포함함
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ weight: 20
|
|||
|
||||
부트스트랩 토큰은 새 클러스터를 만들거나 새 노드를 기존 클러스터에 결합할 때
|
||||
사용되는 간단한 전달자 토큰이다.
|
||||
[kubeadm](/docs/reference/setup-tools/kubeadm/)을 지원하도록 구축되었지만
|
||||
[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)을 지원하도록 구축되었지만
|
||||
`kubeadm` 없이 클러스터를 시작하려는 사용자를 위해 다른 컨텍스트에서 사용할 수 있다.
|
||||
또한 RBAC 정책을 통해 [Kubelet TLS 부트스트래핑](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
시스템과 함께 동작하도록 구축되었다.
|
||||
|
|
|
|||
|
|
@ -18,6 +18,6 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
CNCF는 [리눅스 재단]((https://www.linuxfoundation.org/))의 산하 기구이다.
|
||||
CNCF는 [리눅스 재단](https://www.linuxfoundation.org/)의 산하 기구이다.
|
||||
CNCF의 목표는 어디서나 클라우드 네이티브 컴퓨팅을 활용할 수 있도록 만드는 것이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,4 +15,4 @@ kubelet이 {{< glossary_tooltip text="도커 엔진" term_id="docker" >}}과 통
|
|||
|
||||
<!--more-->
|
||||
|
||||
1.24버전 부터 도커심(Dockershim)은 쿠버네티스에서 제거되었다. 자세한 사항은 [Dockershim FAQ](/dockershim)를 참고한다.
|
||||
1.24버전 부터 도커심(Dockershim)은 쿠버네티스에서 제거되었다. 자세한 사항은 [Dockershim FAQ](/dockershim/)를 참고한다.
|
||||
|
|
|
|||
|
|
@ -17,4 +17,4 @@ tags:
|
|||
문제가 있는 실행 중 파드를 조사하고 싶다면, 파드에 임시 컨테이너를 추가하고 진단을 수행할 수 있다. 임시 컨테이너는 리소스 및 스케줄링에 대한 보장이 제공되지 않으며, 워크로드 자체를 실행하기 위해 임시 컨테이너를 사용해서는 안 된다.
|
||||
|
||||
<!-- Even though the English doc doesn't mention this, the link below is to help Korean readers understand what 임시 컨테이너 equates to in the API. -->
|
||||
더 자세한 정보는 파드 API의 [EphemeralContainer](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#EphemeralContainer)를 참고한다.
|
||||
더 자세한 정보는 파드 API의 [EphemeralContainer](/docs/reference/kubernetes-api/workload-resources/pod-v1/#EphemeralContainer)를 참고한다.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 파이널라이저(Finalizer)
|
||||
id: finalizer
|
||||
date: 2021-07-07
|
||||
full_link: /docs/concepts/overview/working-with-objects/finalizers/
|
||||
full_link: /ko/docs/concepts/overview/working-with-objects/finalizers/
|
||||
short_description: >
|
||||
쿠버네티스가 오브젝트를 완전히 삭제하기 이전, 삭제 표시를 위해
|
||||
특정 조건이 충족될 때까지 대기하도록 알려주기 위한 네임스페이스에 속한 키(namespaced key)이다.
|
||||
|
|
|
|||
|
|
@ -540,7 +540,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
|
||||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
값은 **반드시** [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/) 레벨과 상응하는
|
||||
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
|
||||
특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는
|
||||
레이블 네임스페이스에 모든 파드의 생성을 금지한다.
|
||||
|
|
@ -555,7 +555,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)
|
||||
정책의 버전이 결정된다.
|
||||
|
||||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
|
|
@ -567,7 +567,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
|
||||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
값은 **반드시** [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/) 레벨과 상응하는
|
||||
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
|
||||
특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을
|
||||
방지하지 않지만, 해당 파드에 audit 어노테이션을 추가한다.
|
||||
|
|
@ -582,7 +582,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)
|
||||
정책의 버전이 결정된다.
|
||||
|
||||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
|
|
@ -594,7 +594,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
|
||||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
값은 **반드시** [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/) 레벨과 상응하는
|
||||
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
|
||||
특히 `warn` 레이블은 해당 레이블이 달린 네임스페이스에, 표시된 레벨에 명시된 요구 사항을 충족하지 않는 파드를 생성하는 것을
|
||||
방지하지는 않지만, 그러한 파드가 생성되면 사용자에게 경고를 반환한다.
|
||||
|
|
@ -611,7 +611,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)
|
||||
정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
|
||||
객체를 만들거나 업데이트할 때에도 경고가 표시된다.
|
||||
|
||||
|
|
@ -655,8 +655,8 @@ seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는
|
|||
볼륨스냅샷(VolumeSnapshot)으로부터 생성될 경우,
|
||||
사용자가 소스 볼륨의 모드를 수정할 수 있는지 여부를 결정한다.
|
||||
|
||||
자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/docs/concepts/storage/volume-snapshots/#convert-volume-mode)
|
||||
와 [쿠버네티스 CSI 개발자용 문서](https://kubernetes-csi.github.io/docs/)를 참조한다.
|
||||
자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/ko/docs/concepts/storage/volume-snapshots/#convert-volume-mode)와
|
||||
[쿠버네티스 CSI 개발자용 문서](https://kubernetes-csi.github.io/docs/)를 참조한다.
|
||||
|
||||
## Audit을 위한 어노테이션들
|
||||
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ profiles:
|
|||
[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를
|
||||
구현한다.
|
||||
익스텐션 포인트: `filter`, `score`.
|
||||
- `PodTopologySpread`: [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/pod-topology-spread-constraints/)을
|
||||
- `PodTopologySpread`: [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)을
|
||||
구현한다.
|
||||
익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`.
|
||||
- `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ content_type: concept
|
|||
[영역 정보](/ko/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
|
||||
|
||||
클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/pod-topology-spread-constraints/)과
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)과
|
||||
함께 노드 레이블을 사용하여
|
||||
파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에
|
||||
분산되는 방식을 제어할 수 있다.
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ no_list: true
|
|||
상세 사항을 확인한다.
|
||||
- *apiserver를 위한 로드밸런서 구성*: 여러 노드에서 실행되는 apiserver 서비스 인스턴스에
|
||||
외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다.
|
||||
[외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서
|
||||
[외부 로드밸런서 생성하기](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/)에서
|
||||
상세 사항을 확인한다.
|
||||
- *etcd 서비스 분리 및 백업*: etcd 서비스는
|
||||
다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나,
|
||||
|
|
@ -194,7 +194,7 @@ etcd 백업 계획을 세우려면
|
|||
스크립트를 구성할 수 있는 가상화 플랫폼이 있다.
|
||||
- *노드 헬스 체크 구성*: 중요한 워크로드의 경우,
|
||||
해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다.
|
||||
[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/)
|
||||
[Node Problem Detector](/ko/docs/tasks/debug/debug-cluster/monitor-node-health/)
|
||||
데몬을 사용하면 노드가 정상인지 확인할 수 있다.
|
||||
|
||||
## 프로덕션 사용자 관리
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ debian 컨테이너에서 안녕하세요
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여 더 공부한다.
|
||||
* [합성 컨테이너(composite container) 패턴](/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여 더 공부한다.
|
||||
|
||||
* [모듈 구조를 위한 합성 컨테이너 구조](https://www.slideshare.net/Docker/slideshare-burns)에 관하여 더 공부한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ weight: 70
|
|||
|
||||
이 작업은
|
||||
지원되는 환경이 필요한
|
||||
[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스 타입을
|
||||
[외부 로드밸런서가 있는 서비스](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스 타입을
|
||||
대신 사용할 수 있다.
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ kubectl expose deployment example --port=8765 --target-port=9376 \
|
|||
{{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}} ).
|
||||
|
||||
명령줄 옵션 플래그를 포함한, 더 자세한 내용은
|
||||
[`kubectl expose` 레퍼런스](/ko/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다.
|
||||
[`kubectl expose` 레퍼런스](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다.
|
||||
|
||||
## IP 주소 찾기
|
||||
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
|
|||
초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다.
|
||||
이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다.
|
||||
게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system`
|
||||
[네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
|
||||
[네임스페이스](/ko/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
|
||||
|
||||
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
|
|||
[레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은
|
||||
배포할 모든 디플로이먼트와 서비스에 추가되어야 한다.
|
||||
|
||||
애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다.
|
||||
애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/ko/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다.
|
||||
소문자로 시작해야 하며, 소문자 또는 숫자로 끝나고,
|
||||
소문자, 숫자 및 대쉬(-)만을 포함해야 한다. 24 문자만을 제한한다.
|
||||
처음과 끝의 스페이스는 무시된다.
|
||||
|
|
@ -146,7 +146,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
|
|||
```
|
||||
|
||||
- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다.
|
||||
이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다.
|
||||
이러한 가상 클러스터들을 [네임스페이스](/ko/docs/tasks/administer-cluster/namespaces/)라고 부른다.
|
||||
논리적으로 명명된 그룹으로 리소스들을 분할할 수 있다.
|
||||
|
||||
대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 40
|
|||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) 윈도우 노드를 업그레이드하는 방법을 설명한다.
|
||||
이 페이지는 [kubeadm으로 생성된](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 윈도우 노드를 업그레이드하는 방법을 설명한다.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ content_type: task
|
|||
|
||||
예제에서는 다음과 같은 리소스가 사용된다. [리소스쿼터(ResourceQuota)](/ko/docs/concepts/policy/resource-quotas/),
|
||||
[리밋레인지(LimitRange)](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/),
|
||||
그리고 [퍼시스턴트볼륨클레임(PersistentVolumeClaim)](ko/docs/concepts/storage/persistent-volumes/).
|
||||
그리고 [퍼시스턴트볼륨클레임(PersistentVolumeClaim)](/ko/docs/concepts/storage/persistent-volumes/).
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ Resource Limits
|
|||
```
|
||||
|
||||
네임스페이스의 이름은
|
||||
유효한 [DNS 레이블](/docs/concepts/overview/working-with-objects/names#dns-label-names)이어야 한다.
|
||||
유효한 [DNS 레이블](/ko/docs/concepts/overview/working-with-objects/names/#dns-label-names)이어야 한다.
|
||||
|
||||
옵션 필드인 `finalizer`는 네임스페이스가 삭제 될 때 관찰자가 리소스를 제거할 수 있도록 한다. 존재하지 않는 파이널라이저(finalizer)를 명시한 경우 네임스페이스는 생성되지만 사용자가 삭제하려 하면 `Terminating` 상태가 된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ content_type: task
|
|||
<!--overview-->
|
||||
|
||||
이 페이지에서는 {{<glossary_tooltip text="가비지 수집" term_id="garbage-collection">}} 중
|
||||
클러스터에서 사용할 [캐스케이딩 삭제](ko/docs/concepts/architecture/garbage-collection/#cascading-deletion)
|
||||
클러스터에서 사용할 [캐스케이딩 삭제](/ko/docs/concepts/architecture/garbage-collection/#cascading-deletion)
|
||||
타입을 지정하는 방법을 보여준다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
@ -14,7 +14,7 @@ content_type: task
|
|||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
또한 다양한 타입들의 캐스케이딩 삭제를 실험하려면
|
||||
[샘플 디플로이먼트를 생성](ko/docs/tasks/run-application/run-stateless-application-deployment/#nginx-디플로이먼트-생성하고-탐색하기)할 필요가 있다. 각 타입에 대해 디플로이먼트를
|
||||
[샘플 디플로이먼트를 생성](/ko/docs/tasks/run-application/run-stateless-application-deployment/#nginx-디플로이먼트-생성하고-탐색하기)할 필요가 있다. 각 타입에 대해 디플로이먼트를
|
||||
다시 생성해야 할 수도 있다.
|
||||
|
||||
## 파드에서 소유자 참조 확인
|
||||
|
|
@ -101,7 +101,7 @@ kubectl delete deployment nginx-deployment --cascade=foreground
|
|||
쿠버네티스 API를 사용해
|
||||
포그라운드 캐스케이딩 삭제로 오브젝트들을 삭제할 수 있다.
|
||||
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
|
||||
1. 로컬 프록시 세션을 시작한다.
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ kubectl delete deployment nginx-deployment --cascade=background
|
|||
또는 `propagationPolicy: Background` 인수 없이
|
||||
다음 명령을 실행해도 같은 작업을 수행한다.
|
||||
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
|
||||
**kubectl 사용**
|
||||
|
||||
|
|
@ -296,7 +296,7 @@ kubectl delete deployment nginx-deployment --cascade=orphan
|
|||
{{% /tab %}}
|
||||
{{% tab name="쿠버네티스 1.20.x 전 버전" %}}
|
||||
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
상세한 내용은 [쿠버네티스 버전에 따른 문서](/ko/docs/home/supported-doc-versions/)를 참고한다.
|
||||
|
||||
**kubectl 사용**
|
||||
|
||||
|
|
@ -349,5 +349,5 @@ kubectl get pods -l app=nginx
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* 쿠버네티스의 [소유자와 종속 오브젝트](/docs/concepts/overview/working-with-objects/owners-dependents/)에 대해 알아보자.
|
||||
* 쿠버네티스 [파이널라이저(finalizers)](/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자.
|
||||
* 쿠버네티스 [파이널라이저(finalizers)](/ko/docs/concepts/overview/working-with-objects/finalizers/)에 대해 알아보자.
|
||||
* [가비지(garbage) 수집](/ko/docs/concepts/architecture/garbage-collection/)에 대해 알아보자.
|
||||
|
|
|
|||
|
|
@ -310,7 +310,7 @@ status:
|
|||
|
||||
* [리소스 메트릭 파이프라인](/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/)에서 사용할 수 있는 메트릭에 대해 알아 본다.
|
||||
* [리소스 사용량 모니터링](/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)을 위한 추가 도구에 대해 알아 본다.
|
||||
* Node Problem Detector를 사용하여 [노드 헬스(health)를 모니터링](/docs/tasks/debug/debug-cluster/monitor-node-health/)한다.
|
||||
* Node Problem Detector를 사용하여 [노드 헬스(health)를 모니터링](/ko/docs/tasks/debug/debug-cluster/monitor-node-health/)한다.
|
||||
* `crictl`을 사용하여 [쿠버네티스 노드를 디버깅](/docs/tasks/debug/debug-cluster/crictl/)한다.
|
||||
* [쿠버네티스 감사(auditing)](/docs/tasks/debug/debug-cluster/audit/)에 대한 더 자세한 정보를 본다.
|
||||
* `telepresence`를 사용하여 [서비스를 로컬에서 개발 및 디버깅](/docs/tasks/debug/debug-cluster/local-debugging/)한다.
|
||||
* `telepresence`를 사용하여 [서비스를 로컬에서 개발 및 디버깅](/ko/docs/tasks/debug/debug-cluster/local-debugging/)한다.
|
||||
|
|
|
|||
|
|
@ -201,7 +201,7 @@ cat /etc/podinfo/cpu_limit
|
|||
|
||||
* [`spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)을 읽어보자.
|
||||
파드에 대한 API 정의다. 여기에는 컨테이너 (파드의 일부)의 정의가 포함되어 있다.
|
||||
* downward API를 사용하여 노출할 수 있는 [이용 가능한 필드](/docs/concepts/workloads/pods/downward-api/#available-fields) 목록을 읽어보자.
|
||||
* downward API를 사용하여 노출할 수 있는 [이용 가능한 필드](/ko/docs/concepts/workloads/pods/downward-api/#사용-가능한-필드) 목록을 읽어보자.
|
||||
|
||||
레거시 API 레퍼런스에서 볼륨에 대해 읽어본다.
|
||||
* 컨테이너가 접근할 파드 내의 일반 볼륨을 정의하는
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ kubectl logs dapi-envars-resourcefieldref
|
|||
* [컨테이너를 위한 환경 변수 정의하기](/ko/docs/tasks/inject-data-application/define-environment-variable-container/)를 읽어보자.
|
||||
* [`spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)을 읽어보자.
|
||||
파드에 대한 API 정의다. 여기에는 컨테이너 (파드의 일부)의 정의가 포함되어 있다.
|
||||
* downward API를 사용하여 노출할 수 있는 [이용 가능한 필드](/docs/concepts/workloads/pods/downward-api/#available-fields) 목록을 읽어보자.
|
||||
* downward API를 사용하여 노출할 수 있는 [이용 가능한 필드](/ko/docs/concepts/workloads/pods/downward-api/#사용-가능한-필드) 목록을 읽어보자.
|
||||
|
||||
레거시 API 레퍼런스에서 파드, 컨테이너 및 환경 변수에 대해 읽어본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ weight: 10
|
|||
파드 시큐리티 어드미션(PSA, Pod Security Admission)은
|
||||
[베타로 변경](/blog/2021/12/09/pod-security-admission-beta/)되어 v1.23 이상에서 기본적으로 활성화되어 있다.
|
||||
파드 시큐리티 어드미션은 파드가 생성될 때
|
||||
[파드 시큐리티 스탠다드(Pod Security Standards)](/docs/concepts/security/pod-security-standards/)를
|
||||
[파드 시큐리티 스탠다드(Pod Security Standards)](/ko/docs/concepts/security/pod-security-standards/)를
|
||||
적용하는 어드미션 컨트롤러이다.
|
||||
이 튜토리얼은
|
||||
`baseline` 파드 시큐리티 스탠다드를 클러스터 수준(level)에 적용하여
|
||||
|
|
@ -34,7 +34,7 @@ weight: 10
|
|||
|
||||
[파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)을 이용하여
|
||||
`enforce`, `audit`, 또는 `warn` 모드 중 하나로
|
||||
내장 [파드 시큐리티 스탠다드](/docs/concepts/security/pod-security-standards/)를 적용할 수 있다.
|
||||
내장 [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)를 적용할 수 있다.
|
||||
|
||||
현재 구성에 가장 적합한 파드 시큐리티 스탠다드를 고르는 데
|
||||
도움이 되는 정보를 수집하려면, 다음을 수행한다.
|
||||
|
|
@ -324,5 +324,5 @@ weight: 10
|
|||
5. 최소한의 파드 구성을 위한 yaml 파일을 생성
|
||||
6. 해당 파일을 적용하여 새 클러스터에 파드를 생성
|
||||
- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
|
||||
- [파드 시큐리티 스탠다드](/docs/concepts/security/pod-security-standards/)
|
||||
- [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)
|
||||
- [파드 시큐리티 스탠다드를 네임스페이스 수준에 적용하기](/ko/docs/tutorials/security/ns-level-pss/)
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ weight: 10
|
|||
파드 시큐리티 어드미션(PSA, Pod Security Admission)은
|
||||
[베타로 변경](/blog/2021/12/09/pod-security-admission-beta/)되어 v1.23 이상에서 기본적으로 활성화되어 있다.
|
||||
파드 시큐리티 어드미션은 파드가 생성될 때
|
||||
[파드 시큐리티 스탠다드(Pod Security Standards)](/docs/concepts/security/pod-security-standards/)를 적용하는 어드미션 컨트롤러이다.
|
||||
[파드 시큐리티 스탠다드(Pod Security Standards)](/ko/docs/concepts/security/pod-security-standards/)를 적용하는 어드미션 컨트롤러이다.
|
||||
이 튜토리얼에서는,
|
||||
각 네임스페이스별로 `baseline` 파드 시큐리티 스탠다드를 강제(enforce)할 것이다.
|
||||
|
||||
|
|
@ -170,5 +170,5 @@ namespace/example created
|
|||
4. 해당 파드 시큐리티 스탠다드가 적용된 상태에서 새로운 파드를 생성
|
||||
|
||||
- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
|
||||
- [파드 시큐리티 스탠다드](/docs/concepts/security/pod-security-standards/)
|
||||
- [파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)
|
||||
- [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ client_address=10.240.0.3
|
|||
{{< figure src="/docs/images/tutor-service-nodePort-fig01.svg" alt="source IP nodeport figure 01" class="diagram-large" caption="그림. Source IP Type=NodePort using SNAT" link="https://mermaid.live/edit#pako:eNqNkV9rwyAUxb-K3LysYEqS_WFYKAzat9GHdW9zDxKvi9RoMIZtlH732ZjSbE970cu5v3s86hFqJxEYfHjRNeT5ZcUtIbXRaMNN2hZ5vrYRqt52cSXV-4iMSuwkZiYtyX739EqWaahMQ-V1qPxDVLNOvkYrO6fj2dupWMR2iiT6foOKdEZoS5Q2hmVSStoH7w7IMqXUVOefWoaG3XVftHbGeZYVRbH6ZXJ47CeL2-qhxvt_ucTe1SUlpuMN6CX12XeGpLdJiaMMFFr0rdAyvvfxjHEIDbbIgcVSohKDCRy4PUV06KQIuJU6OA9MCdMjBTEEt_-2NbDgB7xAGy3i97VJPP0ABRmcqg" >}}
|
||||
|
||||
이를 피하기 위해 쿠버네티스는
|
||||
[클라이언트 소스 IP 주소를 보존](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)하는 기능이 있다.
|
||||
[클라이언트 소스 IP 주소를 보존](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)하는 기능이 있다.
|
||||
`service.spec.externalTrafficPolicy` 의 값을 `Local` 로 하면
|
||||
오직 로컬 엔드포인트로만 프록시 요청하고
|
||||
다른 노드로 트래픽 전달하지 않는다. 이 방법은 원본
|
||||
|
|
@ -416,4 +416,4 @@ kubectl delete deployment source-ip-app
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 더 자세히 본다.
|
||||
* [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/) 방법을 본다.
|
||||
* [외부 로드밸런서 생성](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/) 방법을 본다.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ weight: 10
|
|||
* [kubectl](/ko/docs/tasks/tools/)을 설치한다.
|
||||
* Google Kubernetes Engine 또는 Amazon Web Services와 같은 클라우드 공급자를 사용하여
|
||||
쿠버네티스 클러스터를 생성한다. 이 튜토리얼은
|
||||
[외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데,
|
||||
[외부 로드 밸런서](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/)를 생성하는데,
|
||||
클라우드 공급자가 필요하다.
|
||||
* `kubectl`이 쿠버네티스 API 서버와 통신하도록 설정한다.
|
||||
자세한 내용은 클라우드 공급자의 설명을 참고한다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue