kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #34817 from jihoon-seo/220705_Merge_dev-1.24-ko.1_into_main 

[ko] 1st Korean localization work for v1.24
This commit is contained in:
Kubernetes Prow Robot 2022-07-07 18:29:46 -07:00 committed by GitHub
parent 68ab7c8aeb 5a13863d99
commit e2f48d746f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
186 changed files with 5817 additions and 4043 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
README-ko.md
View File

@ -4,6 +4,9 @@
이 저장소에는 [쿠버네티스 웹사이트 및 문서](https://kubernetes.io/)를 빌드하는 데 필요한 자산이 포함되어 있습니다. 기여해주셔서 감사합니다!
- [문서에 기여하기](#contributing-to-the-docs)
- [`README.md`에 대한 쿠버네티스 문서 현지화](#localization-readmemds)
# 저장소 사용하기
Hugo(확장 버전)를 사용하여 웹사이트를 로컬에서 실행하거나, 컨테이너 런타임에서 실행할 수 있습니다. 라이브 웹사이트와의 배포 일관성을 제공하므로, 컨테이너 런타임을 사용하는 것을 적극 권장합니다.
@ -40,6 +43,8 @@ make container-image
make container-serve
```
에러가 발생한다면, Hugo 컨테이너를 위한 컴퓨팅 리소스가 충분하지 않기 때문일 수 있습니다. 이를 해결하려면, 머신에서 도커에 허용할 CPU 및 메모리 사용량을 늘립니다([MacOSX](https://docs.docker.com/docker-for-mac/#resources) / [Windows](https://docs.docker.com/docker-for-windows/#resources)).
웹사이트를 보려면 브라우저를 http://localhost:1313 으로 엽니다. 소스 파일을 변경하면 Hugo가 웹사이트를 업데이트하고 브라우저를 강제로 새로 고칩니다.
## Hugo를 사용하여 로컬에서 웹사이트 실행하기
@ -56,7 +61,45 @@ make serve
그러면 포트 1313에서 로컬 Hugo 서버가 시작됩니다. 웹사이트를 보려면 http://localhost:1313 으로 브라우저를 엽니다. 소스 파일을 변경하면, Hugo가 웹사이트를 업데이트하고 브라우저를 강제로 새로 고칩니다.
## API 레퍼런스 페이지 빌드하기
`content/en/docs/reference/kubernetes-api`에 있는 API 레퍼런스 페이지는 <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>를 사용하여 Swagger 명세로부터 빌드되었습니다.
새로운 쿠버네티스 릴리스를 위해 레퍼런스 페이지를 업데이트하려면 다음 단계를 수행합니다.
1. `api-ref-generator` 서브모듈을 받아옵니다.
```bash
git submodule update --init --recursive --depth 1
```
2. Swagger 명세를 업데이트합니다.
```bash
curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json
```
3. `api-ref-assets/config/`에서, 새 릴리스의 변경 사항이 반영되도록 `toc.yaml` 및 `fields.yaml` 파일을 업데이트합니다.
4. 다음으로, 페이지를 빌드합니다.
```bash
make api-reference
```
로컬에서 결과를 테스트하기 위해 컨테이너 이미지를 이용하여 사이트를 빌드 및 실행합니다.
```bash
make container-image
make container-serve
```
웹 브라우저에서, <http://localhost:1313/docs/reference/kubernetes-api/>로 이동하여 API 레퍼런스를 확인합니다.
5. 모든 API 변경사항이 `toc.yaml` 및 `fields.yaml` 구성 파일에 반영되었다면, 새로 생성된 API 레퍼런스 페이지에 대한 PR을 엽니다.
## 문제 해결
### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
Hugo는 기술적인 이유로 2개의 바이너리 세트로 제공됩니다. 현재 웹사이트는 **Hugo 확장** 버전 기반에서만 실행됩니다. [릴리스 페이지](https://github.com/gohugoio/hugo/releases)에서 이름에 `extended` 가 포함된 아카이브를 찾습니다. 확인하려면, `hugo version` 을 실행하고 `extended` 라는 단어를 찾습니다.
@ -97,17 +140,17 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
이 내용은 Catalina와 Mojave macOS에서 작동합니다.
# SIG Docs에 참여하기
[커뮤니티 페이지](https://github.com/kubernetes/community/tree/master/sig-docs#meetings)에서 SIG Docs 쿠버네티스 커뮤니티 및 회의에 대한 자세한 내용을 확인합니다.
이 프로젝트의 메인테이너에게 연락을 할 수도 있습니다.
- [슬랙](https://kubernetes.slack.com/messages/sig-docs) [슬랙에 초대 받기](https://slack.k8s.io/)
- [슬랙](https://kubernetes.slack.com/messages/sig-docs)
- [슬랙에 초대 받기](https://slack.k8s.io/)
- [메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
# 문서에 기여하기
# 문서에 기여하기 {#contributing-to-the-docs}
이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭하면 됩니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
@ -124,7 +167,15 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
* [문서화 스타일 가이드](http://kubernetes.io/docs/contribute/style/style-guide/)
* [쿠버네티스 문서 현지화](https://kubernetes.io/docs/contribute/localization/)
# `README.md`에 대한 쿠버네티스 문서 현지화(localization)
### 신규 기여자 대사(ambassadors)
기여 과정에서 도움이 필요하다면, [신규 기여자 대사](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador)에게 연락하는 것이 좋습니다. 이들은 신규 기여자를 멘토링하고 첫 PR 과정에서 도움을 주는 역할도 담당하는 SIG Docs 승인자입니다. 신규 기여자 대사에게 문의할 가장 좋은 곳은 [쿠버네티스 슬랙](https://slack.k8s.io/)입니다. 현재 SIG Docs 신규 기여자 대사는 다음과 같습니다.
| Name | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
# `README.md`에 대한 쿠버네티스 문서 현지화(localization) {#localization-readmemds}
## 한국어
@ -135,6 +186,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
* 손석호 ([GitHub - @seokho-son](https://github.com/seokho-son))
* [슬랙 채널](https://kubernetes.slack.com/messages/kubernetes-docs-ko)
# 행동 강령
쿠버네티스 커뮤니티 참여는 [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 따릅니다.

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

@ -3,6 +3,13 @@ layout: blog
title: "당황하지 마세요. 쿠버네티스와 도커"
date: 2020-12-02
slug: dont-panic-kubernetes-and-docker
evergreen: true
---
**업데이트:** _쿠버네티스의 `dockershim`을 통한 도커 지원이 제거되었습니다.
더 자세한 정보는 [제거와 관련된 자주 묻는 질문](/dockershim/)을 참고하세요.
또는 지원 중단에 대한 [GitHub 이슈](https://github.com/kubernetes/kubernetes/issues/106917)에서 논의를 할 수도 있습니다._
---
**저자:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
@ -10,8 +17,7 @@ slug: dont-panic-kubernetes-and-docker
**번역:** 박재화(삼성SDS), 손석호(한국전자통신연구원)
쿠버네티스는 v1.20 이후 컨테이너 런타임으로서
[도커를
사용 중단(deprecating)](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)합니다.
[도커를 사용 중단(deprecating)](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)합니다.
**당황할 필요는 없습니다. 말처럼 극적이진 않습니다.**
@ -26,7 +32,7 @@ slug: dont-panic-kubernetes-and-docker
빌드하는 데 유용한 도구이며, `docker
build` 실행 결과로 만들어진 이미지도 여전히 쿠버네티스 클러스터에서 동작합니다.
GKE, EKS 또는 AKS([containerd가 기본](https://github.com/Azure/AKS/releases/tag/2020-11-16)인)와 같은 관리형 쿠버네티스 서비스를
AKS, EKS 또는 GKE와 같은 관리형 쿠버네티스 서비스를
사용하는 경우 쿠버네티스의 향후 버전에서 도커에 대한 지원이
없어지기 전에, 워커 노드가 지원되는 컨테이너 런타임을 사용하고 있는지 확인해야 합니다. 노드에
사용자 정의가 적용된 경우 사용자 환경 및 런타임 요구 사항에 따라 업데이트가 필요할 수도
@ -35,8 +41,8 @@ GKE, EKS 또는 AKS([containerd가 기본](https://github.com/Azure/AKS/releases
자체 클러스터를 운영하는 경우에도, 클러스터의 고장을 피하기 위해서
변경을 수행해야 합니다. v1.20에서는 도커에 대한 지원 중단 경고(deprecation warning)가 표시됩니다.
도커 런타임 지원이 쿠버네티스의 향후 릴리스(현재는 2021년 하반기의
1.22 릴리스로 계획됨)에서 제거되면 더 이상 지원되지
도커 런타임 지원이 쿠버네티스의 향후 릴리스(<del>현재는 2021년 하반기의
1.22 릴리스로 계획됨</del>)에서 제거되면 더 이상 지원되지
않으며, containerd 또는 CRI-O와 같은 다른 호환 컨테이너 런타임 중
하나로 전환해야 합니다. 선택한 런타임이 현재 사용 중인
도커 데몬 구성(예: 로깅)을 지원하는지 확인하세요.
@ -103,4 +109,4 @@ containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심
모든 사람이 다가오는 변경 사항에 대해 최대한 많은 교육을 받을 수 있도록 하는 것입니다. 이 글이
여러분이 가지는 대부분의 질문에 대한 답이 되었고, 불안을 약간은 진정시켰기를 바랍니다! ❤️
더 많은 답변을 찾고 계신가요? 함께 제공되는 [도커심 사용 중단 FAQ](/blog/2020/12/02/dockershim-faq/)를 확인하세요.
더 많은 답변을 찾고 계신가요? 함께 제공되는 [도커심 제거 FAQ](/blog/2022/02/17/dockershim-faq/)(2022년 2월에 갱신됨)를 확인하세요.

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

@ -3,6 +3,7 @@ layout: blog
title: '쿠버네티스 1.22: 새로운 정점에 도달(Reaching New Peaks)'
date: 2021-08-04
slug: kubernetes-1-22-release-announcement
evergreen: true
---
**저자:** [쿠버네티스 1.22 릴리스 팀](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.22/release-team.md)
@ -50,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을 통한 보안성이 더 높은 컨트롤 플레인

396
content/ko/community/_index.html
View File

@ -1,257 +1,183 @@
---
title: 커뮤니티
title: Community
layout: basic
cid: community
community_styles_migrated: true
---
<img
id="banner"
srcset="/images/community/kubernetes-community-final-02.jpg 1500w, /images/community/kubernetes-community-02-mobile.jpg 900w"
sizes="(max-width: 900px) 900px, (max-width: 1920px) 1500px"
src="/images/community/kubernetes-community-final-02.jpg"
alt="Kubernetes conference photo">
<div class="newcommunitywrapper">
<div class="banner1">
<img src="/images/community/kubernetes-community-final-02.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;padding-left:0px" class="desktop">
<img src="/images/community/kubernetes-community-02-mobile.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;padding-left:0px" class="mobile">
<div class="community-section" id="introduction">
<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화를 통해 구성된 쿠버네티스 커뮤니티는
본 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다.
프로젝트 자체가 성장하고 변화함에 따라
우리의 문화와 가치관 또한 지속적으로 성장하고 변화하고 있습니다.
우리 모두는 프로젝트와 작업 방식을 지속적으로 개선하기 위해 함께 노력합니다.</p>
<p>우리는 이슈(issue)와 풀 리퀘스트(pull request)를 제출하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고,
도입(adoption)과 혁신(innovation)을 지지하며,
<code>kubectl get pods</code> 를 실행하고,
다른 수천가지 중요한 방법으로 기여하는 사람들 입니다.
어떻게 하면 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
</div>
<div class="intro">
<br class="mobile">
<p>사용자, 기여자, 그리고 우리가 함께 구축한 문화를 통해 구성된 쿠버네티스 커뮤니티는 본 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장하고 변화함에 따라 우리의 문화와 가치관 또한 지속적으로 성장하고 변화하고 있습니다. 우리 모두는 프로젝트와 작업 방식을 지속적으로 개선하기 위해 함께 노력합니다.
<br><br>우리는 이슈(issue)와 풀 리퀘스트(pull request)를 제출하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고, 도입(adoption)과 혁신(innovation)을 지지하며, <code>kubectl get pods</code> 를 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 어떻게 하면 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.</p>
<br class="mobile">
</div>
<div class="community__navbar">
<a href="https://www.kubernetes.dev/">기여자 커뮤니티</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#values">커뮤니티 가치</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#conduct">행동 강령 </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#videos">비디오</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#discuss">토론</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#events">이벤트와 모임들</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#news">새소식</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="/releases">릴리즈</a>
</div>
<br class="mobile"><br class="mobile">
<div class="imagecols">
<br class="mobile">
<div class="imagecol">
<img src="/images/community/kubernetes-community-final-03.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%" class="desktop">
<div id="navigation-items">
<div class="community-nav-item external-link">
<a href="https://www.kubernetes.dev/">기여자 커뮤니티</a>
</div>
<div class="imagecol">
<img src="/images/community/kubernetes-community-final-04.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%" class="desktop">
<div class="community-nav-item">
<a href="#values">커뮤니티 가치</a>
</div>
<div class="imagecol" style="margin-right:0% important">
<img src="/images/community/kubernetes-community-final-05.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;margin-right:0% important" class="desktop">
<div class="community-nav-item">
<a href="#conduct">행동 강령</a>
</div>
<div class="community-nav-item">
<a href="#videos">비디오</a>
</div>
<div class="community-nav-item">
<a href="#discuss">토론</a>
</div>
<div class="community-nav-item">
<a href="#meetups">밋업</a>
</div>
<div class="community-nav-item">
<a href="#news">새소식</a>
</div>
<div class="community-nav-item">
<a href="/releases">릴리스</a>
</div>
<img src="/images/community/kubernetes-community-04-mobile.jpg" alt="쿠버네티스 컨퍼런스 갤러리" style="width:100%;margin-bottom:3%" class="mobile">
<a name="values"></a>
</div>
<div><a name="values"></a></div>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1>커뮤니티 가치</h1>
쿠버네티스 커뮤니티가 추구하는 가치는 프로젝트의 지속적인 성공의 핵심입니다.<br>
이러한 원칙은 쿠버네티스 프로젝트의 모든 측면을 이끌어 갑니다.
<br>
<a href="/community/values/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
더 읽어 보기
</span>
<div class="community-section" id="gallery">
<img src="/images/community/kubernetes-community-final-03.jpg" alt="쿠버네티스 컨퍼런스 갤러리 사진" class="community-gallery-desktop">
<img src="/images/community/kubernetes-community-final-04.jpg" alt="쿠버네티스 컨퍼런스 갤러리 사진" class="community-gallery-desktop">
<img src="/images/community/kubernetes-community-final-05.jpg" alt="쿠버네티스 컨퍼런스 갤러리 사진" class="community-gallery-desktop">
<img src="/images/community/kubernetes-community-04-mobile.jpg" alt="쿠버네티스 컨퍼런스 갤러리 사진" class="community-gallery-mobile">
</div>
<div class="community-section" id="values">
<h2>커뮤니티 가치</h2>
<p>쿠버네티스 커뮤니티가 추구하는 가치는 프로젝트의 지속적인 성공의 핵심입니다.<br class="optional"/>
이러한 원칙은 쿠버네티스 프로젝트의 모든 측면을 이끌어 갑니다.</p>
<a href="https://www.kubernetes.dev/community/values/" class="community-cta-button">
<span class="community-cta">더 읽어 보기</span>
</a>
</div><a name="conduct"></a>
</div>
<div class="community-section" id="conduct">
<h2>행동 강령</h2>
<p>쿠버네티스 커뮤니티는 존중과 포괄성을 중요시하며 모든 상호작용에 행동 강령을 시행합니다.</p>
<p>이벤트나 회의, <a href="#slack">슬랙</a> 또는 다른 커뮤니케이션 메커니즘에서 행동 강령의 위반이 발견되면, 쿠버네티스 행동 강령 위원회 <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>에 연락하세요. 모든 제보는 기밀로 유지됩니다. <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">여기</a>서 위원회에 대한 내용을 읽을 수 있습니다.</p>
<a href="/ko/community/code-of-conduct/" class="community-cta-button">
<span class="community-cta">더 읽어 보기</span>
</a>
</div>
<div id="videos" class="community-section">
<h2>비디오</h2>
<p class="community-simple">유튜브에 많이 올라와 있어요. 다양한 주제에 대해 구독하세요.</p>
<div class="container">
<div class="video youtube">
<iframe src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg" title="Monthly office hours" allow="camera 'none'; microphone 'none'; geolocation 'none'; fullscreen https://www.youtube.com/" ></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg">
<span class="videocta">월간 Office Hours 보기&nbsp;&#9654;</span>
</a>
</div>
<div class="video youtube">
<iframe src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" title="Weekly community meetings" allow="camera 'none'; microphone 'none'; geolocation 'none'; fullscreen https://www.youtube.com/"></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ">
<span class="videocta">주간 커뮤니티 미팅 보기&nbsp;&#9654;</span>
</a>
</div>
<div class="video youtube" id="discuss">
<iframe src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F" title="Talk from a community member" allow="camera 'none'; microphone 'none'; geolocation 'none'; fullscreen https://www.youtube.com/"></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F">
<span class="videocta">커뮤니티 멤버와의 대화 보기&nbsp;&#9654;</span>
</a>
</div>
</div>
</div>
<div id="resources" class="community-section">
<h2>토론</h2>
<p class="community-simple">우리는 대화를 많이 합니다. 아래의 플랫폼에서 우리를 찾아 대화에 참여하세요.</p>
<div class="container">
<div class="community-resource">
<a href="https://discuss.kubernetes.io/">
<img src="/images/community/discuss.png" alt="Forum">
</a>
<a href="https://discuss.kubernetes.io/">커뮤니티 포럼&nbsp;&#9654;</a>
<p>문서, 트러블슈팅 및 그 외 더 많은 것을 소개하는
주제 기반 기술 토론이 열리는 곳입니다.</p>
</div>
<div id="twitter" class="community-resource">
<a href="https://twitter.com/kubernetesio">
<img src="/images/community/twitter.png" alt="Twitter">
</a>
<a href="https://twitter.com/kubernetesio">트위터&nbsp;&#9654;</a>
<p><em>#kubernetesio</em></p>
<p>블로그 게시물, 이벤트, 뉴스, 아이디어에 대한 실시간 소식들입니다.</p>
</div>
<div id="github" class="community-resource">
<a href="https://github.com/kubernetes/kubernetes">
<img src="/images/community/github.png" alt="GitHub">
</a>
<a href="https://github.com/kubernetes/kubernetes">GitHub&nbsp;&#9654;</a>
<p>모든 프로젝트와 이슈 추적, 그리고 물론 코드도 있습니다.</p>
</div>
<div id="server-fault" class="community-resource">
<a href="https://serverfault.com/questions/tagged/kubernetes">
<img src="/images/community/serverfault.png" alt="Server Fault">
</a>
<a href="https://serverfault.com/questions/tagged/kubernetes">Server Fault&nbsp;&#9654;</a>
<p>Server Fault에 쿠버네티스 관련 토론들이 있습니다. 질문을 하거나, 질문에 답해 보세요.</p>
</div>
<div id="slack" class="community-resource">
<a href="https://kubernetes.slack.com/">
<img src="/images/community/slack.png" alt="Slack">
</a>
<a href="https://kubernetes.slack.com/">Slack&nbsp;&#9654;</a>
<p>170개 이상의 채널이 있으며, 필요에 맞는 채널을 찾을 수 있습니다.</p>
<details><summary><em>초대가 필요하신가요?</em></summary>
초대를 받으려면 <a href="https://slack.k8s.io/">https://slack.k8s.io/</a> 를
방문하세요.</details>
</div>
</div>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1>행동 강령</h1>
쿠버네티스 커뮤니티는 존중과 포괄성을 중요시하며 모든 상호작용에 행동 강령을 시행합니다. 이벤트나 회의, 슬랙 또는 다른 커뮤니케이션 메커니즘에서 행동 강령의 위반이 발견되면, 쿠버네티스 행동 강령 위원회 <a href="mailto:conduct@kubernetes.io" style="color:#0662EE;font-weight:300">conduct@kubernetes.io</a>에 연락하세요. 모든 보고서는 기밀로 유지됩니다. <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct" style="color:#0662EE;font-weight:300">여기</a>서 위원회에 대한 내용을 읽을 수 있습니다.
<br>
<a href="/ko/community/code-of-conduct/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
더 읽어 보기
</span>
</a>
</div><a name="videos"></a>
</div>
</div>
<div class="videos">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="margin-top:0px">비디오</h1>
<div style="margin-bottom:4%;font-weight:300;text-align:center;padding-left:10%;padding-right:10%">유튜브에 많이 올라와 있어요. 다양한 주제에 대해 구독하세요.</div>
<div class="videocontainer">
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg" title="월간 Office Hours" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg">
<div class="videocta">
월간 Office Hours 보기&nbsp;&#9654;</div>
</a>
<div class="community-section" id="events">
<div class="container">
<h2>다가오는 이벤트</h2>
{{< upcoming-events >}}
</div>
</div>
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" title="주간 커뮤니티 미팅" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ">
<div class="videocta">
주간 커뮤니티 미팅 보기&nbsp;&#9654;
</div>
</a>
</div>
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F" title="커뮤니티 멤버와의 대화" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F">
<div class="videocta">
커뮤니티 멤버와의 대화 보기&nbsp;&#9654;
</div>
</a>
<a name="discuss"></a>
</div>
</div>
</div>
<div class="resources">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="padding-top:1%">토론</h1>
<div style="font-weight:300;text-align:center">우리는 대화를 많이 합니다. 이 모든 플랫폼에서 우리를 찾아 대화에 참여하세요.</div>
<div class="resourcecontainer">
<div class="resourcebox">
<img src="/images/community/discuss.png" alt=Forum" style="width:80%;padding-bottom:2%">
<a href="https://discuss.kubernetes.io/" style="color:#0662EE;display:block;margin-top:1%">
포럼&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
문서, 스택오버플로우 등을 연결하는 주제 기반 기술 토론하는 곳입니다.
</div>
</div>
<div class="resourcebox">
<img src="/images/community/twitter.png" alt="Twitter" style="width:80%;padding-bottom:2%">
<a href="https://twitter.com/kubernetesio" style="color:#0662EE;display:block;margin-top:1%">
트위터&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">블로그 게시물, 이벤트, 뉴스, 아이디어의 실시간 소식들입니다.
</div>
</div>
<div class="resourcebox">
<img src="/images/community/github.png" alt="GitHub" style="width:80%;padding-bottom:2%">
<a href="https://github.com/kubernetes/kubernetes" style="color:#0662EE;display:block;margin-top:1%">
깃헙&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
모든 프로젝트와 이슈 추적, 더불어 코드도 물론이죠.
</div>
</div>
<div class="resourcebox">
<img src="/images/community/stack.png" alt="Stack Overflow" style="width:80%;padding-bottom:2%">
<a href="https://stackoverflow.com/search?q=kubernetes" style="color:#0662EE;display:block;margin-top:1%">
스택 오버플로우&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
모든 유스 케이스에 대한 기술적인 문제 해결입니다.
<a name="events"></a>
</div>
</div>
<!--
<div class="resourcebox">
<img src="/images/community/slack.png" style="width:80%">
slack&nbsp;&#9654;
<div class="resourceboxtext" style="font-size:11px;text-transform:none !important;font-weight:200;line-height:1.4em;color:#333333;margin-top:4%">
170개 이상의 채널이 있으며, 필요에 맞는 채널을 찾을 수 있습니다.
</div>
</div>-->
</div>
</div>
<div class="events">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="eventcontainer">
<h1 style="color:white !important">다가오는 이벤트</h1>
{{< upcoming-events >}}
</div>
</div>
<div class="meetups">
<div class="meetupcol">
<div class="meetuptext">
<h1 style="text-align:left">글로벌 커뮤니티</h1>
전 세계 150개가 넘는 모임이 있고 성장하고 있는 가운데, 현지 kube 사람들을 찾아보세요. 가까운 곳에 없다면, 책임감을 갖고 직접 만들어보세요.
</div>
<a href="https://www.meetup.com/topics/kubernetes/">
<div class="button">
모임 찾아보기
</div>
</a>
<a name="news"></a>
</div>
</div>
<!--
<div class="contributor">
<div class="contributortext">
<br>
<h1 style="text-align:left">
New Contributors Site
</h1>
Text about new contributors site.
<br><br>
<div class="button">
VISIT SITE
</div>
</div>
</div>
-->
<div class="news">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="margin-bottom:2%">최근 소식들</h1>
<br>
<div class="twittercol1">
<a class="twitter-timeline" data-tweet-limit="1" href="https://twitter.com/kubernetesio?ref_src=twsrc%5Etfw">Tweets by kubernetesio</a> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>
<br>
<br><br><br><br>
<div class="community-section" id="meetups">
<h2>글로벌 커뮤니티</h2>
<p>
전 세계 150개가 넘는 모임이 있고 성장하고 있는 가운데, 가까이에 있는 kube people을 찾아보세요. 가까운 곳에 없다면, 역할을 맡아 직접 만들어보세요.
</p>
<a href="https://www.meetup.com/topics/kubernetes/" class="community-cta-button">
<span class="community-cta">밋업 찾아보기</span>
</a>
</div>
<div class="community-section community-frame" id="news">
<h2>최근 소식</h2>
<div class="twittercol1">
<a class="twitter-timeline" data-tweet-limit="1" href="https://twitter.com/kubernetesio?ref_src=twsrc%5Etfw">kubernetesio의 트윗</a>
</div>
</div>

16
content/ko/community/code-of-conduct.md
View File

@ -1,27 +1,29 @@
---
title: 커뮤니티
title: 쿠버네티스 커뮤니티 행동 강령
layout: basic
cid: community
css: /css/community.css
community_styles_migrated: true
---
<div class="community_main">
<h1>쿠버네티스 커뮤니티 행동 강령</h1>
<div class="community-section" id="cncf-code-of-conduct-intro">
<p>
쿠버네티스는
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF의 행동 강령</a>을 따르고 있습니다.
<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct.md">커밋 214585e</a>
에 따라 CNCF 행동 강령의 내용이 아래에 복제됩니다.
만약 최신 버전이 아닌 경우에는
<a href="https://github.com/kubernetes/website/issues/new">이슈를 제기해 주세요</a>.
</p>
<p>
이벤트나 회의, 슬랙 또는 다른 커뮤니케이션
메커니즘에서 행동 강령을 위반한 경우
<a href="https://git.k8s.io/community/committee-code-of-conduct">쿠버네티스 행동 강령 위원회</a>에 연락하세요.
<a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>로 이메일을 보내 주세요.
당신의 익명성은 보호됩니다.
</p>
</div>
<div class="cncf_coc_container">
<div id="cncf-code-of-conduct">
{{< include "/static/cncf-code-of-conduct.md" >}}
</div>
</div>

5
content/ko/community/static/README.md
View File

@ -1,2 +1,5 @@
이 디렉터리의 파일은 다른 소스에서 가져왔습니다. 새 버전으로
교체하는 경우를 제외하고 직접 편집하지 마십시오.
교체하는 경우를 제외하고 직접 편집하지 마십시오.
현지화 관련 노트: 이 디렉토리의 어떤 파일도
번역할 필요는 없습니다.

2
content/ko/docs/concepts/architecture/garbage-collection.md
View File

@ -13,7 +13,7 @@ weight: 50
* [소유자 참조가 없는 오브젝트](#owners-dependents)
* [사용되지 않는 컨테이너와 컨테이너 이미지](#containers-images)
* [반환 정책이 삭제인 스토리지클래스에 의해 동적으로 생성된 퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/#delete)
* [Stale 또는 만료된 CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) <!-- en 글에서부터 링크가 깨져있어 /docs를 따로 추가-->
* [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/)를 사용하는 클라우드
* 클러스터가 클라우드 컨트롤러 매니저와 유사한 애드온을 사용하는 온프레미스

140
content/ko/docs/concepts/architecture/nodes.md
View File

@ -86,14 +86,18 @@ kubelet 플래그 `--register-node`가 참(기본값)일 경우, kubelet은 API
자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
- `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
- `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
- `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게
{{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
- `--register-node` - 자동으로 API 서버에 등록.
- `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록.
- `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}}
리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록.
`register-node`가 거짓이면 동작 안 함.
- `--node-ip` - 노드의 IP 주소.
- `--node-labels` - 클러스터에 노드를 등록할 때 추가 할 {{< glossary_tooltip text="레이블" term_id="label" >}}([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고).
- `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의.
- `--node-labels` - 클러스터에 노드를 등록할 때 추가 할
{{< glossary_tooltip text="레이블" term_id="label" >}}
([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고).
- `--node-status-update-frequency` - 얼마나 자주 kubelet이 API 서버에 해당 노드 상태를 게시할 지 정의.
[Node authorization mode](/docs/reference/access-authn-authz/node/)와
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면,
@ -168,8 +172,10 @@ kubectl describe node <insert-node-name-here>
이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다.
* HostName: 노드의 커널에 의해 알려진 호스트명이다. `--hostname-override` 파라미터를 통해 치환될 수 있다.
* ExternalIP: 일반적으로 노드의 IP 주소는 외부로 라우트 가능 (클러스터 외부에서 이용 가능) 하다 .
* HostName: 노드의 커널에 의해 알려진 호스트명이다.
`--hostname-override` 파라미터를 통해 치환될 수 있다.
* ExternalIP: 일반적으로 노드의 IP 주소는 외부로 라우트 가능
(클러스터 외부에서 이용 가능) 하다 .
* InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다.
@ -289,7 +295,6 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고
7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다.
### 노드 컨트롤러
노드 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
@ -306,18 +311,21 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
세 번째는 노드의 동작 상태를 모니터링하는 것이다. 노드 컨트롤러는
다음을 담당한다.
- 노드가 접근 불가능(unreachable) 상태가 되는 경우, 노드의 `.status`
내에 있는 NodeReady 컨디션을 업데이트한다.
이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다.
- 노드가 접근 불가능(unreachable) 상태가 되는 경우,
노드의 `.status` 필드의 `Ready` 컨디션을 업데이트한다.
이 경우에는 노드 컨트롤러가 `Ready` 컨디션을 `Unknown`으로 설정한다.
- 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서
[API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을
트리거한다. 기본적으로, 노드 컨트롤러는 노드를
`ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가
`Unknown`으로 마킹한 뒤 5분을 기다렸다가
최초의 축출 요청을 시작한다.
노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
기본적으로, 노드 컨트롤러는 5 초마다 각 노드의 상태를 체크한다.
체크 주기는 `kube-controller-manager` 구성 요소의
`--node-monitor-period` 플래그를 이용하여 설정할 수 있다.
#### 축출 빈도 한계
#### 축출 빈도 제한
대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로
축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여
@ -325,8 +333,9 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할
경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지
체크한다(NodeReady 컨디션은 `ConditionUnknown` 또는
`ConditionFalse` 다).
체크한다(`Ready` 컨디션은 `Unknown` 또는
`False` 값을 가진다).
- 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold`
(기본값 0.55)가 되면 축출 속도가 감소한다.
- 클러스터가 작으면 (즉 `--large-cluster-size-threshold`
@ -335,7 +344,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
`--secondary-node-eviction-rate`(기본값 0.01)로 감소된다.
이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안
하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다.
하나의 가용성 영역이 컨트롤 플레인으로부터 분할되어 질 수도 있기 때문이다.
만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않는 이상,
축출 매커니즘은 영역 별 가용성을 고려하지 않는다.
@ -377,7 +386,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
## 노드 토폴로지
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
{{< feature-state state="beta" for_k8s_version="v1.18" >}}
`TopologyManager`
[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
@ -391,7 +400,9 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
kubelet은 노드 시스템 셧다운을 감지하고 노드에서 실행 중인 파드를 종료하려고 시도한다.
Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다.
Kubelet은 노드가 종료되는 동안 파드가
일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를
따르도록 한다.
그레이스풀 노드 셧다운 기능은
[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를
@ -404,18 +415,26 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
기본적으로, 아래 설명된 두 구성 옵션,
`shutdownGracePeriod` 및 `shutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로,
그레이스풀 노드 셧다운 기능이 활성화되지 않는다.
기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다.
기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고
0이 아닌 값으로 설정해야 한다.
그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.
1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
2. 노드에서 실행 중인
[중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
그레이스풀 노드 셧다운 기능은
두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
* `shutdownGracePeriod`:
* 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다.
* 노드가 종료를 지연해야 하는 총 기간을 지정한다.
이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의
파드 종료에 필요한 총 유예 기간에 해당한다.
* `shutdownGracePeriodCriticalPods`:
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `shutdownGracePeriod` 보다 작아야 한다.
* 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를
종료하는 데 사용되는 기간을 지정한다.
이 값은 `shutdownGracePeriod` 보다 작아야 한다.
예를 들어, `shutdownGracePeriod=30s`,
`shutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지
@ -433,6 +452,56 @@ Reason: Terminated
Message: Pod was terminated in response to imminent node shutdown.
```
{{< /note >}}
## 논 그레이스풀 노드 셧다운 {#non-graceful-node-shutdown}
{{< feature-state state="alpha" for_k8s_version="v1.24" >}}
전달한 명령이 kubelet에서 사용하는 금지 잠금 메커니즘(inhibitor locks mechanism)을 트리거하지 않거나,
또는 사용자 오류(예: ShutdownGracePeriod 및 ShutdownGracePeriodCriticalPods가 제대로 설정되지 않음)로 인해
kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가
노드 셧다운 액션을 감지하지 못할 수 있다.
자세한 내용은 위의 [그레이스풀 노드 셧다운](#graceful-node-shutdown) 섹션을 참조한다.
노드가 셧다운되었지만 kubelet의 노드 셧다운 관리자가 이를 감지하지 못하면,
스테이트풀셋에 속한 파드는 셧다운된 노드에 '종료 중(terminating)' 상태로 고착되어
다른 동작 중인 노드로 이전될 수 없다.
이는 셧다운된 노드의 kubelet이 파드를 지울 수 없어서
결국 스테이트풀셋이 동일한 이름으로 새 파드를 만들 수 없기 때문이다.
만약 파드가 사용하던 볼륨이 있다면,
볼륨어태치먼트(VolumeAttachment)도 기존의 셧다운된 노드에서 삭제되지 않아
결국 파드가 사용하던 볼륨이 다른 동작 중인 노드에 연결(attach)될 수 없다.
결과적으로, 스테이트풀셋에서 실행되는 애플리케이션이 제대로 작동하지 않는다.
기존의 셧다운된 노드가 정상으로 돌아오지 못하면,
이러한 파드는 셧다운된 노드에 '종료 중(terminating)' 상태로 영원히 고착될 것이다.
위와 같은 상황을 완화하기 위해,
사용자가 `node.kubernetes.io/out-of-service` 테인트를
`NoExecute` 또는 `NoSchedule` 값으로 추가하여
노드를 서비스 불가(out-of-service) 상태로 표시할 수 있다.
`kube-controller-manager`에 `NodeOutOfServiceVolumeDetach`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고,
노드가 이 테인트에 의해 서비스 불가 상태로 표시되어 있는 경우,
노드에 매치되는 톨러레이션이 없다면 노드 상의 파드는 강제로 삭제될 것이고,
노드 상에서 종료되는 파드에 대한 볼륨 해제(detach) 작업은 즉시 수행될 것이다.
이를 통해 서비스 불가 상태 노드의 파드가 빠르게 다른 노드에서 복구될 수 있다.
논 그레이스풀 셧다운 과정 동안, 파드는 다음의 두 단계로 종료된다.
1. 매치되는 `out-of-service` 톨러레이션이 없는 파드를 강제로 삭제한다.
2. 이러한 파드에 대한 볼륨 해제 작업을 즉시 수행한다.
{{< note >}}
- `node.kubernetes.io/out-of-service` 테인트를 추가하기 전에,
노드가 완전한 셧다운 또는 전원 꺼짐 상태에 있는지
(재시작 중인 것은 아닌지) 확인한다.
- 사용자가 서비스 불가 상태 테인트를 직접 추가한 것이기 때문에,
파드가 다른 노드로 옮겨졌고 셧다운 상태였던 노드가 복구된 것을 확인했다면
사용자가 서비스 불가 상태 테인트를 수동으로 제거해야 한다.
{{< /note >}}
### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown}
@ -443,7 +512,7 @@ Message: Pod was terminated in response to imminent node shutdown.
클러스터에 프라이어리티클래스(PriorityClass) 기능이 활성화되어 있으면
그레이스풀 노드 셧다운 과정에서 파드의 프라이어리티클래스가 고려된다.
이 기능으로 그레이스풀 노드 셧다운 시 파드가 종료되는 순서를 클러스터 관리자가
[프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)
[프라이어리티 클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)
기반으로 명시적으로 정할 수 있다.
위에서 기술된 것처럼, [그레이스풀 노드 셧다운](#graceful-node-shutdown) 기능은 파드를
@ -492,7 +561,7 @@ shutdownGracePeriodByPodPriority:
shutdownGracePeriodSeconds: 60
```
위의 표에 의하면 우선순위 값이 100000 이상인 파드는 종료까지 10초만 주어지며,
위의 표에 의하면 `priority` 값이 100000 이상인 파드는 종료까지 10초만 주어지며,
10000 이상 ~ 100000 미만이면 180초,
1000 이상 ~ 10000 미만이면 120초가 주어진다.
마지막으로, 다른 모든 파드는 종료까지 60초가 주어질 것이다.
@ -507,7 +576,7 @@ shutdownGracePeriodByPodPriority:
| 0 |60 seconds |
위의 경우, custom-class-b에 속하는 파드와 custom-class-c에 속하는 파드는
위의 경우, `custom-class-b`에 속하는 파드와 `custom-class-c`에 속하는 파드는
동일한 종료 대기 시간을 갖게 될 것이다.
특정 범위에 해당되는 파드가 없으면,
@ -517,10 +586,21 @@ kubelet은 해당 범위에 해당되는 파드를 위해 기다려 주지 않
기능이 활성화되어 있지만 환경 설정이 되어 있지 않으면,
순서 지정 동작이 수행되지 않을 것이다.
이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority` 기능 게이트를 활성화해야 하고,
kubelet 환경 설정의 `ShutdownGracePeriodByPodPriority`를
파드 프라이어리티 클래스 값과
각 값에 대한 종료 대기 시간을 명시하여 지정해야 한다.
이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 하고,
[kubelet config](/docs/reference/config-api/kubelet-config.v1beta1/)의
`ShutdownGracePeriodByPodPriority`를
파드 프라이어리티 클래스 값과 각 값에 대한 종료 대기 시간을 명시하여
지정해야 한다.
{{< note >}}
그레이스풀 노드 셧다운 과정에서 파드 프라이어리티를 고려하는 기능은
쿠버네티스 v1.23에서 알파 기능으로 도입되었다.
쿠버네티스 {{< skew currentVersion >}}에서 이 기능은 베타 상태이며 기본적으로 활성화되어 있다.
{{< /note >}}
`graceful_shutdown_start_time_seconds` 및 `graceful_shutdown_end_time_seconds` 메트릭은
노드 셧다운을 모니터링하기 위해 kubelet 서브시스템에서 방출된다.
## 스왑(swap) 메모리 관리 {#swap-memory}

2
content/ko/docs/concepts/cluster-administration/_index.md
View File

@ -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/)

2
content/ko/docs/concepts/cluster-administration/addons.md
View File

@ -30,7 +30,7 @@ content_type: concept
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
* [Romana](https://github.com/romana/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
* **Romana**는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
## 서비스 검색

14
content/ko/docs/concepts/cluster-administration/logging.md
View File

@ -12,7 +12,9 @@ weight: 60
애플리케이션 로그는 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움이 된다. 로그는 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다. 대부분의 최신 애플리케이션에는 일종의 로깅 메커니즘이 있다. 마찬가지로, 컨테이너 엔진들도 로깅을 지원하도록 설계되었다. 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성하는 것이다.
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다.
예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것이다.
클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다.
<!-- body -->
@ -55,7 +57,15 @@ kubectl logs counter
...
```
`kubectl logs --previous` 를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다. 파드에 여러 컨테이너가 있는 경우, 명령에 컨테이너 이름을 추가하여 접근하려는 컨테이너 로그를 지정해야 한다. 자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다.
`kubectl logs --previous` 를 사용해서 컨테이너의 이전 인스턴스에 대한 로그를 검색할 수 있다.
파드에 여러 컨테이너가 있는 경우,
다음과 같이 명령에 `-c` 플래그와 컨테이너 이름을 추가하여 접근하려는 컨테이너 로그를 지정해야 한다.
```console
kubectl logs counter -c count
```
자세한 내용은 [`kubectl logs` 문서](/docs/reference/generated/kubectl/kubectl-commands#logs)를 참조한다.
## 노드 레벨에서의 로깅
@ -141,7 +151,7 @@ systemd를 사용하지 않으면, kubelet과 컨테이너 런타임은 `/var/lo
노드-레벨 로깅은 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션에 대한 변경은 필요로 하지 않는다.
컨테이너는 stdout과 stderr를 동의되지 않은 포맷으로 작성한다. 노드-레벨 에이전트는 이러한 로그를 수집하고 취합을 위해 전달한다.
컨테이너는 로그를 stdout과 stderr로 출력하며, 합의된 형식은 없다. 노드-레벨 에이전트는 이러한 로그를 수집하고 취합을 위해 전달한다.
### 로깅 에이전트와 함께 사이드카 컨테이너 사용 {#sidecar-container-with-logging-agent}

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

@ -154,7 +154,7 @@ deployment.apps/my-deployment created
persistentvolumeclaim/my-pvc created
```
`kubectl` 에 대해 더 자세히 알고 싶다면, [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 참조한다.
`kubectl` 에 대해 더 자세히 알고 싶다면, [명령줄 도구 (kubectl)](/ko/docs/reference/kubectl/)를 참조한다.
## 효과적인 레이블 사용
@ -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/)을 참고한다.

71
content/ko/docs/concepts/cluster-administration/system-logs.md
View File

@ -110,6 +110,55 @@ I1025 00:15:15.525108 1 example.go:116] "Example" data="This is text with
second line.}
```
### 컨텍스츄얼 로깅(Contextual Logging)
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
컨텍스츄얼 로깅은 구조화된 로깅을 기반으로 한다.
컨텍스츄얼 로깅은 주로 개발자가 로깅 호출을 사용하는 방법에 관한 것이다.
해당 개념을 기반으로 하는 코드는 좀 더 유연하며,
[컨텍스츄얼 로깅 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging)에 기술된 추가적인 사용 사례를 지원한다.
개발자가 자신의 구성 요소에서
`WithValues` 또는 `WithName`과 같은 추가 기능을 사용하는 경우,
로그 항목에는 호출자가 함수로 전달하는 추가 정보가 포함된다.
현재 이 기능은 `StructuredLogging` 기능 게이트 뒤에 있으며
기본적으로 비활성화되어 있다.
이 기능을 위한 인프라는 구성 요소를 수정하지 않고 1.24에 추가되었다.
[`component-base/logs/example`](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go)
명령은 새 로깅 호출을 사용하는 방법과
컨텍스츄얼 로깅을 지원하는 구성 요소가 어떻게 작동하는지 보여준다.
```console
$ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/
$ go run . --help
...
--feature-gates mapStringBool A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
ContextualLogging=true|false (ALPHA - default=false)
$ go run . --feature-gates ContextualLogging=true
...
I0404 18:00:02.916429 451895 logger.go:94] "example/myname: runtime" foo="bar" duration="1m0s"
I0404 18:00:02.916447 451895 logger.go:95] "example: another runtime" foo="bar" duration="1m0s"
```
`runtime` 메시지 및 `duration="1m0s"` 값을 로깅하는
기존 로깅 함수를 수정하지 않고도,
이 함수의 호출자에 의해 `example` 접두사 및 `foo="bar"` 문자열이 로그에 추가되었다.
컨텍스츄얼 로깅이 비활성화되어 있으면, `WithValues` 및 `WithName` 은 아무 효과가 없으며,
로그 호출은 전역 klog 로거를 통과한다.
따라서 이 추가 정보는 더 이상 로그 출력에 포함되지 않는다.
```console
$ go run . --feature-gates ContextualLogging=false
...
I0404 18:03:31.171945 452150 logger.go:94] "runtime" duration="1m0s"
I0404 18:03:31.171962 452150 logger.go:95] "another runtime" duration="1m0s"
```
### JSON 로그 형식
{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
@ -150,27 +199,6 @@ JSON 로그 형식 예시(보기좋게 출력된 형태)는 다음과 같다.
* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}
* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}
### 로그 정리(sanitization)
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{<warning >}}
로그 정리(sanitization)는 상당한 오버 헤드를 발생시킬 수 있으므로 프로덕션 환경에서는 사용하지 않아야한다.
{{< /warning >}}
`--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화한다.
활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고 이러한 필드의 로깅이 방지된다.
현재 로그 정리(sanitization)를 지원하는 컴포넌트 목록:
* kube-controller-manager
* kube-apiserver
* kube-scheduler
* kubelet
{{< note >}}
로그 정리(sanitization) 필터는 사용자 작업 로그로부터 민감한 데이터가 유출되는 것을 방지할 수 없다.
{{< /note >}}
### 로그 상세 레벨(verbosity)
`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 기록된 이벤트 수가 줄어든다.
@ -197,5 +225,6 @@ systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은
* [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기
* [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기
* [컨텍스츄얼 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging) 알아보기
* [klog 플래그 사용 중단](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) 알아보기
* [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기

89
content/ko/docs/concepts/cluster-administration/system-traces.md Normal file
View File

@ -0,0 +1,89 @@
---
title: 쿠버네티스 시스템 컴포넌트에 대한 추적(trace)
content_type: concept
weight: 60
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
시스템 컴포넌트 추적은 클러스터 내에서 수행된 동작들 간의 지연(latency)과 관계(relationship)를 기록한다.
쿠버네티스 컴포넌트들은 [OpenTelemetry 프로토콜](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification)과
gRPC exporter를 이용하여 추적을 생성하고
[OpenTelemetry 수집기](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector)를
통해 추적 백엔드(tracing backends)로 라우팅되거나 수집될 수 있다.
<!-- body -->
## 추적 수집
추적 수집 및 수집기에 대한 전반적인 가이드는
[OpenTelemetry 수집기 시작하기](https://opentelemetry.io/docs/collector/getting-started/)에서 제공한다.
그러나, 쿠버네티스 컴포넌트에 관련된 몇 가지 사항에 대해서는 특별히 살펴볼 필요가 있다.
기본적으로, 쿠버네티스 컴포넌트들은 [IANA OpenTelemetry 포트](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry)인
4317 포트로 OTLP에 대한 grpc exporter를 이용하여 추적를 내보낸다.
예를 들면, 수집기가 쿠버네티스 컴포넌트에 대해 사이드카(sidecar)로 동작한다면,
다음과 같은 리시버 설정을 통해 span을 수집하고 그 로그를 표준 출력(standard output)으로 내보낼 것이다.
```yaml
receivers:
otlp:
protocols:
grpc:
exporters:
# 이 exporter를 사용자의 백엔드를 위한 exporter로 변경
logging:
logLevel: debug
service:
pipelines:
traces:
receivers: [otlp]
exporters: [logging]
```
## 컴포넌트 추적
### kube-apiserver 추적
kube-apiserver는 들어오는 HTTP 요청들과
webhook, etcd 로 나가는 요청들, 그리고 재진입 요청들에 대해 span을 생성한다.
kube-apiserver는 자주 퍼블릭 엔드포인트로 이용되기 때문에,
들어오는 요청들에 첨부된 추적 컨택스트를 사용하지 않고,
나가는 요청들을 통해 [W3C Trace Context](https://www.w3.org/TR/trace-context/)를 전파한다.
#### kube-apiserver 에서의 추적 활성화
추적을 활성화하기 위해서는, kube-apiserve에서 `APIServerTracing`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다.
또한, kube-apiserver의 추적 설정 파일에
`--tracing-config-file=<path-to-config>`을 추가한다.
다음은 10000개 요청 당 1개에 대한 span을 기록하는 설정에 대한 예시이고, 이는 기본 OpenTelemetry 엔드포인트를 이용한다.
```yaml
apiVersion: apiserver.config.k8s.io/v1alpha1
kind: TracingConfiguration
# 기본값
#endpoint: localhost:4317
samplingRatePerMillion: 100
```
`TracingConfiguration` 구조체에 대해 더 많은 정보를 얻고 싶다면
[API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)를 참고한다.
## 안정성
추적의 계측화(tracing instrumentation)는 여전히 활발히 개발되는 중이어서 다양한 형태로 변경될 수 있다.
span의 이름, 첨부되는 속성, 계측될 엔드포인트(instrumented endpoints)들 등이 그렇다.
이 속성이 안정화(graduates to stable)되기 전까지는
이전 버전과의 호환성은 보장되지 않는다.
## {{% heading "whatsnext" %}}
* [OpenTelemetry 수집기 시작하기](https://opentelemetry.io/docs/collector/getting-started/)을 참고

4
content/ko/docs/concepts/configuration/configmap.md
View File

@ -15,7 +15,6 @@ weight: 20
사용하여 데이터를 비공개로 유지하자.
{{< /caution >}}
<!-- body -->
## 사용 동기
@ -42,7 +41,7 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob
`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 `data` 및 `binaryData`
필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. `data` 필드와
`binaryData` 는 모두 선택 사항이다. `data` 필드는
UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리
UTF-8 문자열을 포함하도록 설계되었으며 `binaryData` 필드는 바이너리
데이터를 base64로 인코딩된 문자열로 포함하도록 설계되었다.
컨피그맵의 이름은 유효한
@ -280,5 +279,6 @@ immutable: true
* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 읽어본다.
* [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다.
* [컨피그맵 (또는 어떠한 쿠버네티스 오브젝트) 변경하기](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)를 읽어본다.
* 코드를 구성에서 분리하려는 동기를 이해하려면
[Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다.

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

@ -47,10 +47,9 @@ feature:
다른 방식으로 동일한 제약을 구현할 수 있다.
{{< note >}}
컨테이너가 자체 메모리 제한을 지정하지만, 메모리 요청을 지정하지 않는 경우, 쿠버네티스는
제한과 일치하는 메모리 요청을 자동으로 할당한다. 마찬가지로, 컨테이너가 자체 CPU 제한을
지정하지만, CPU 요청을 지정하지 않는 경우, 쿠버네티스는 제한과 일치하는 CPU 요청을 자동으로
할당한다.
리소스에 대해 제한은 지정하지만 요청은 지정하지 않고,
해당 리소스에 대한 요청 기본값을 지정하는 승인-시점 메커니즘(admission-time mechanism)이 없는 경우,
쿠버네티스는 당신이 지정한 제한을 복사하여 해당 리소스의 요청 값으로 사용한다.
{{< /note >}}
## 리소스 타입
@ -229,8 +228,8 @@ kubelet은 해당 컨테이너의 메모리/CPU 요청 및 제한을 컨테이
kubelet은 파드의 리소스 사용량을 파드
[`status`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)에 포함하여 보고한다.
클러스터에서 선택적인 모니터링 도구를
사용할 수 있다면, [메트릭 API](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-api)에서
클러스터에서 선택적인 [모니터링 도구](/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)를
사용할 수 있다면, [메트릭 API](/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api)에서
직접 또는 모니터링 도구에서 파드 리소스
사용량을 검색할 수 있다.
@ -801,5 +800,5 @@ Events:
* [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자.
* API 레퍼런스에 [컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)와
[컨테이너 리소스 요구사항](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)이 어떻게 정의되어 있는지 확인한다.
* XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기
* XFS의 [프로젝트 쿼터](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F)에 대해 읽어보기
* [kube-scheduler 정책 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)에 대해 더 읽어보기

21
content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
View File

@ -148,7 +148,28 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치
`$HOME/.kube/config`에서 상대 경로는 상대적으로, 절대 경로는
절대적으로 저장한다.
## 프록시
다음과 같이 kubeconfig 파일에 `proxy-url`을 설정하여 `kubectl`이 프록시를 거치도록 설정할 수 있다.
```yaml
apiVersion: v1
kind: Config
proxy-url: https://proxy.host:3128
clusters:
- cluster:
name: development
users:
- name: developer
contexts:
- context:
name: development
```
## {{% heading "whatsnext" %}}

1817
content/ko/docs/concepts/configuration/secret.md
View File

File diff suppressed because it is too large Load Diff

28
content/ko/docs/concepts/containers/container-lifecycle-hooks.md
View File

@ -99,28 +99,28 @@ TERM 신호를 보내기 전에 실행을 완료해야 한다. 실행 중에 `Pr
예를 들어, 훅을 전송하는 도중에 kubelet이 재시작된다면,
Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
### 디버깅 훅 핸들러
### 훅 핸들러 디버깅
훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며,
`PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다.
이 이벤트는 `kubectl describe pod <파드_이름>`를 실행하면 볼 수 있다.
다음은 이 커맨드 실행을 통한 이벤트 출력의 몇 가지 예다.
실패한 `FailedPreStopHook` 이벤트를 직접 생성하려면, [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) 파일을 수정하여 postStart 명령을 "badcommand"로 변경하고 이를 적용한다.
다음은 `kubectl describe pod lifecycle-demo` 를 실행하여 볼 수 있는 이벤트 출력 예시이다.
```
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2...
Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms
Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx"
Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container
Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container
Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n"
Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook
Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms
Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container
```

111
content/ko/docs/concepts/containers/images.md
View File

@ -29,8 +29,7 @@ weight: 10
레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다.
이미지 이름 부분 다음에 _tag_ 를 추가할 수 있다(`docker` 와 `podman`
등의 명령과 함께 사용).
이미지 이름 부분 다음에 _tag_ 를 추가할 수 있다(`docker` 또는 `podman` 과 같은 명령을 사용할 때와 동일한 방식으로).
태그를 사용하면 동일한 시리즈 이미지의 다른 버전을 식별할 수 있다.
이미지 태그는 소문자와 대문자, 숫자, 밑줄(`_`),
@ -91,7 +90,7 @@ weight: 10
`<image-name>:<tag>`를 `<image-name>@<digest>`로 교체한다.
(예를 들어, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`).
이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다.
이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 다이제스트로 명시하면 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해 준다.
파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가
태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는
@ -175,95 +174,11 @@ kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성
### 프라이빗 레지스트리에 인증하도록 노드 구성
노드에서 도커를 실행하는 경우, 프라이빗 컨테이너 레지스트리를 인증하도록
도커 컨테이너 런타임을 구성할 수 있다.
크리덴셜 설정에 대한 상세 지침은 사용하는 컨테이너 런타임 및 레지스트리에 따라 다르다. 가장 정확한 정보는 솔루션 설명서를 참조해야 한다.
이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다.
{{< note >}}
기본 쿠버네티스는 도커 구성에서 `auths` 와 `HttpHeaders` 섹션만 지원한다.
도커 자격 증명 도우미(`credHelpers` 또는 `credsStore`)는 지원되지 않는다.
{{< /note >}}
도커는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을
아래의 검색 경로 리스트에 넣으면, kubelet은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다.
* `{--root-dir:-/var/lib/kubelet}/config.json`
* `{cwd of kubelet}/config.json`
* `${HOME}/.docker/config.json`
* `/.docker/config.json`
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
* `{cwd of kubelet}/.dockercfg`
* `${HOME}/.dockercfg`
* `/.dockercfg`
{{< note >}}
kubelet 프로세스의 환경 변수에서 `HOME=/root` 를 명시적으로 설정해야 할 수 있다.
{{< /note >}}
프라이빗 레지스트리를 사용도록 사용자의 노드를 구성하기 위해서 권장되는 단계는 다음과 같다. 이
예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다.
1. 사용하고 싶은 각 자격 증명 세트에 대해서 `docker login [서버]`를 실행한다. 이것은 여러분 PC의 `$HOME/.docker/config.json`를 업데이트한다.
1. 편집기에서 `$HOME/.docker/config.json`를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다.
1. 노드의 리스트를 구한다. 예를 들면 다음과 같다.
- 이름을 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
- IP를 원하는 경우: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
1. 로컬의 `.docker/config.json`를 위의 검색 경로 리스트 중 하나에 복사한다.
- 이를 테스트하기 위한 예: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
{{< note >}}
프로덕션 클러스터의 경우, 이 설정을 필요한 모든 노드에 적용할 수 있도록
구성 관리 도구를 사용한다.
{{< /note >}}
프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다.
```shell
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: private-image-test-1
spec:
containers:
- name: uses-private-image
image: $PRIVATE_IMAGE_NAME
imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
EOF
```
```
pod/private-image-test-1 created
```
만약 모든 것이 잘 작동한다면, 잠시 후에, 다음을 실행할 수 있다.
```shell
kubectl logs private-image-test-1
```
그리고 커맨드 출력을 본다.
```
SUCCESS
```
명령이 실패한 것으로 의심되는 경우 다음을 실행할 수 있다.
```shell
kubectl describe pods/private-image-test-1 | grep 'Failed'
```
실패하는 케이스에는 출력이 다음과 유사하다.
```
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
```
클러스터의 모든 노드가 반드시 동일한 `.docker/config.json`를 가져야 한다. 그렇지 않으면, 파드가
일부 노드에서만 실행되고 다른 노드에서는 실패할 것이다. 예를 들어, 노드 오토스케일링을 사용한다면, 각 인스턴스
템플릿은 `.docker/config.json`을 포함하거나 그것을 포함한 드라이브를 마운트해야 한다.
프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는
프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.
프라이빗 컨테이너 이미지 레지스트리 구성 예시를 보려면,
[프라이빗 레지스트리에서 이미지 가져오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry/)를 참조한다.
해당 예시는 도커 허브에서 제공하는 프라이빗 레지스트리를 사용한다.
### config.json 파일 해석 {#config-json}
@ -332,6 +247,7 @@ kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미
이미지를 풀 해야 한다고 명시하면,
kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
### 미리 내려받은 이미지 {#pre-pulled-images}
{{< note >}}
@ -362,6 +278,8 @@ kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다.
#### 도커 구성으로 시크릿 생성
레지스트리에 인증하기 위해서는, 레지스트리 호스트네임 뿐만 아니라,
사용자 이름, 비밀번호 및 클라이언트 이메일 주소를 알아야 한다.
대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.
```shell
@ -426,16 +344,15 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
일반적인 유스케이스와 제안된 솔루션이다.
1. 비소유 이미지(예를 들어, 오픈소스)만 실행하는 클러스터의 경우. 이미지를 숨길 필요가 없다.
- 도커 허브의 퍼블릭 이미지를 사용한다.
- 퍼블릭 레지스트리의 퍼블릭 이미지를 사용한다.
- 설정이 필요 없다.
- 일부 클라우드 제공자는 퍼블릭 이미지를 자동으로 캐시하거나 미러링하므로, 가용성이 향상되고 이미지를 가져오는 시간이 줄어든다.
1. 모든 클러스터 사용자에게는 보이지만, 회사 외부에는 숨겨야하는 일부 독점 이미지를
실행하는 클러스터의 경우.
- 호스트 된 프라이빗 [도커 레지스트리](https://docs.docker.com/registry/)를 사용한다.
- 그것은 [도커 허브](https://hub.docker.com/signup)에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다.
- 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다.
- 호스트된 프라이빗 레지스트리를 사용한다.
- 프라이빗 레지스트리에 접근해야 하는 노드에 수동 설정이 필요할 수 있다
- 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다.
- 쿠버네티스 구성은 필요 없다.
- 쿠버네티스 구성은 필요하지 않다.
- 이미지 접근을 제어하는 호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
- 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다.
- 또는, 노드의 구성 변경이 불편한 클러스터에서는, `imagePullSecrets`를 사용한다.
@ -450,8 +367,6 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다.
다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다.
Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.json` 파일로 병합한다.
## {{% heading "whatsnext" %}}

38
content/ko/docs/concepts/containers/runtime-class.md
View File

@ -16,9 +16,6 @@ weight: 20
런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
구성은 파드의 컨테이너를 실행하는 데 사용된다.
<!-- body -->
## 동기
@ -62,12 +59,15 @@ weight: 20
(`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
```yaml
apiVersion: node.k8s.io/v1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
# 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: myclass # 런타임클래스는 해당 이름을 통해서 참조됨
# 런타임클래스 참조에 사용될 이름
# 런타임클래스는 네임스페이스가 없는 리소스임
handler: myconfiguration # 상응하는 CRI 설정의 이름임
name: myclass
# 상응하는 CRI 설정의 이름
handler: myconfiguration
```
런타임클래스 오브젝트의 이름은 유효한
@ -81,8 +81,8 @@ handler: myconfiguration # 상응하는 CRI 설정의 이름임
## 사용
클러스터를 위해서 런타임클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
`runtimeClassName`를 명시한다. 예를 들면 다음과 같다.
클러스터에 런타임클래스를 설정하고 나면,
다음과 같이 파드 스펙에 `runtimeClassName`를 명시하여 해당 런타임클래스를 사용할 수 있다.
```yaml
apiVersion: v1
@ -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`가 없다면, 기본 런타임 핸들러가 사용되며,
@ -107,16 +107,6 @@ spec:
CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/production-environment/container-runtimes/)를 확인한다.
#### dockershim
{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
dockershim은 쿠버네티스 v1.20에서 사용 중단되었으며, v1.24에서 제거될 것이다. 상세 사항은
[dockershim 사용 중단](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)을 참고한다.
dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다.
dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
#### {{< glossary_tooltip term_id="containerd" >}}
런타임 핸들러는 containerd의 구성 파일인 `/etc/containerd/config.toml` 통해 설정한다.
@ -126,8 +116,8 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```
더 자세한 containerd의 구성 문서를 살펴본다.
https://github.com/containerd/cri/blob/master/docs/config.md
더 자세한 내용은 containerd의 [구성 문서](https://github.com/containerd/cri/blob/master/docs/config.md)를
살펴본다.
#### {{< glossary_tooltip term_id="cri-o" >}}
@ -166,21 +156,17 @@ RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행
### 파드 오버헤드
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
파드 실행과 연관되는 _오버헤드_ 리소스를 지정할 수 있다. 오버헤드를 선언하면
클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다.
PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.)
파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면,
해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가
쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.
## {{% heading "whatsnext" %}}
- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 개념에 대해 읽기

3
content/ko/docs/concepts/extend-kubernetes/_index.md
View File

@ -39,13 +39,14 @@ no_list: true
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
[리소스쿼터](/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/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
## 익스텐션

2
content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
View File

@ -26,7 +26,7 @@ weight: 10
동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며
클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다.
커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로
[kubectl](/ko/docs/reference/kubectl/overview/)을 사용하여 해당 오브젝트를 생성하고
[kubectl](/ko/docs/reference/kubectl/)을 사용하여 해당 오브젝트를 생성하고
접근할 수 있다.
## 커스텀 컨트롤러

5
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
View File

@ -344,12 +344,11 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
다음은 장치 플러그인 구현의 예이다.
* [AMD GPU 장치 플러그인](https://github.com/RadeonOpenCompute/k8s-device-plugin)
* 인텔 GPU, FPGA 및 QuickAssist 장치용 [인텔 장치 플러그인](https://github.com/intel/intel-device-plugins-for-kubernetes)
* 인텔 GPU, FPGA, QAT, VPU, SGX, DSA, DLB 및 IAA 장치용 [인텔 장치 플러그인](https://github.com/intel/intel-device-plugins-for-kubernetes)
* 하드웨어 지원 가상화를 위한 [KubeVirt 장치 플러그인](https://github.com/kubevirt/kubernetes-device-plugins)
* [NVIDIA GPU 장치 플러그인](https://github.com/NVIDIA/k8s-device-plugin)
* GPU를 지원하는 Docker 컨테이너를 실행할 수 있는 [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0이 필요하다.
* [컨테이너에 최적화된 OS를 위한 NVIDIA GPU 장치 플러그인](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
* [RDMA 장치 플러그인](https://github.com/hustcat/k8s-rdma-device-plugin)
* [SocketCAN 장치 플러그인](https://github.com/collabora/k8s-socketcan)
* [Solarflare 장치 플러그인](https://github.com/vikaschoudhary16/sfc-device-plugin)
* [SR-IOV 네트워크 장치 플러그인](https://github.com/intel/sriov-network-device-plugin)
* Xilinx FPGA 장치용 [Xilinx FPGA 장치 플러그인](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin)

44
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
View File

@ -11,17 +11,20 @@ weight: 10
<!-- overview -->
쿠버네티스의 네트워크 플러그인은 몇 가지 종류가 있다.
쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다.
클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스).
* CNI 플러그인: 상호 운용성을 위해 설계된 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 명세를 준수한다.
* 쿠버네티스는 CNI 명세의 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 릴리스를 따른다.
* Kubenet 플러그인: `bridge` 와 `host-local` CNI 플러그인을 사용하여 기본 `cbr0` 구현한다.
[v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 이상의
CNI 스펙과 호환되는 CNI 플러그인을 사용해야 한다.
쿠버네티스 플러그인은
CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/SPEC.md)과 호환되는
플러그인의 사용을 권장한다(플러그인은 여러 스펙 버전과 호환 가능).
<!-- body -->
## 설치
kubelet에는 단일 기본 네트워크 플러그인과 전체 클러스터에 공통된 기본 네트워크가 있다. 플러그인은 시작할 때 플러그인을 검색하고, 찾은 것을 기억하며, 파드 라이프사이클에서 적절한 시간에 선택한 플러그인을 실행한다(CRI는 자체 CNI 플러그인을 관리하므로 도커에만 해당됨). 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다. CRI는 자체 CNI 플러그인을 관리한다. 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다.
@ -129,35 +132,8 @@ metadata:
...
```
### kubenet
Kubenet은 리눅스에서만 사용할 수 있는 매우 기본적이고, 간단한 네트워크 플러그인이다. 그 자체로는, 크로스-노드 네트워킹 또는 네트워크 정책과 같은 고급 기능을 구현하지 않는다. 일반적으로 노드 간, 또는 단일 노드 환경에서 통신을 위한 라우팅 규칙을 설정하는 클라우드 제공자와 함께 사용된다.
Kubenet은 `cbr0` 라는 리눅스 브리지를 만들고 각 쌍의 호스트 끝이 `cbr0` 에 연결된 각 파드에 대한 veth 쌍을 만든다. 쌍의 파드 끝에는 구성 또는 컨트롤러 관리자를 통해 노드에 할당된 범위 내에서 할당된 IP 주소가 지정된다. `cbr0` 에는 호스트에서 활성화된 일반 인터페이스의 가장 작은 MTU와 일치하는 MTU가 지정된다.
플러그인에는 몇 가지 사항이 필요하다.
* 표준 CNI `bridge`, `lo` 및 `host-local` 플러그인은 최소 0.2.0 버전이 필요하다. Kubenet은 먼저 `/opt/cni/bin` 에서 검색한다. 추가 검색 경로를 제공하려면 `cni-bin-dir` 을 지정한다. 처음 검색된 디렉터리가 적용된다.
* 플러그인을 활성화하려면 Kubelet을 `--network-plugin=kubenet` 인수와 함께 실행해야 한다.
* Kubelet은 `--non-masquerade-cidr=<clusterCidr>` 인수와 함께 실행하여 이 범위 밖 IP로의 트래픽이 IP 마스커레이드(masquerade)를 사용하도록 해야 한다.
* `--pod-cidr` kubelet 커맨드라인 옵션 또는 `--allocate-node-cidrs=true --cluster-cidr=<cidr>` 컨트롤러 관리자 커맨드라인 옵션을 통해 노드에 IP 서브넷을 할당해야 한다.
### MTU 사용자 정의 (kubenet 사용)
최상의 네트워킹 성능을 얻으려면 MTU를 항상 올바르게 구성해야 한다. 네트워크 플러그인은 일반적으로 합리적인 MTU를
유추하려고 시도하지만, 때로는 로직에 따라 최적의 MTU가 지정되지 않는다. 예를 들어,
도커 브리지나 다른 인터페이스에 작은 MTU가 지정되어 있으면, kubenet은 현재 해당 MTU를 선택한다. 또는
IPSEC 캡슐화를 사용하는 경우, MTU를 줄여야 하며, 이 계산은 대부분의
네트워크 플러그인에서 범위를 벗어난다.
필요한 경우, `network-plugin-mtu` kubelet 옵션을 사용하여 MTU를 명시 적으로 지정할 수 있다. 예를 들어,
AWS에서 `eth0` MTU는 일반적으로 9001이므로, `--network-plugin-mtu=9001` 을 지정할 수 있다. IPSEC를 사용하는 경우
캡슐화 오버헤드를 허용하도록 `--network-plugin-mtu=8873` 과 같이 IPSEC을 줄일 수 있다.
이 옵션은 네트워크 플러그인에 제공된다. 현재 **kubenet만 `network-plugin-mtu` 를 지원한다**.
## 용법 요약
* `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다.
* `--network-plugin=kubenet` 은 `/opt/cni/bin` 또는 `cni-bin-dir` 에 있는 CNI `bridge`, `lo` 및 `host-local` 플러그인과 함께 `kubenet` 네트워크 플러그인을 사용하도록 지정한다.
* 현재 kubenet 네트워크 플러그인에서만 사용하는 `--network-plugin-mtu=9001` 은 사용할 MTU를 지정한다.
## {{% heading "whatsnext" %}}

1
content/ko/docs/concepts/extend-kubernetes/operator.md
View File

@ -111,6 +111,7 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
{{% thirdparty-content %}}
* [Charmed Operator Framework](https://juju.is/)
* [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK)
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)

1
content/ko/docs/concepts/extend-kubernetes/service-catalog.md
View File

@ -230,4 +230,3 @@ spec:
* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
* [svc-cat.io](https://svc-cat.io/docs/) 살펴보기

4
content/ko/docs/concepts/overview/components.md
View File

@ -28,7 +28,7 @@ card:
컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나
간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서
사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 머신에서
실행되는 컨트롤 플레인 설정의 예제를 보려면
[kubeadm을 사용하여 고가용성 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/high-availability/)를 확인해본다.
@ -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를 제공해 준다.
### 클러스터-레벨 로깅

47
content/ko/docs/concepts/overview/kubernetes-api.md
View File

@ -22,7 +22,7 @@ card:
쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예:
파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.
대부분의 작업은 [kubectl](/ko/docs/reference/kubectl/overview/)
대부분의 작업은 [kubectl](/ko/docs/reference/kubectl/)
커맨드 라인 인터페이스 또는 API를 사용하는
[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과
같은 다른 커맨드 라인 도구를 통해 수행할 수 있다.
@ -82,18 +82,42 @@ IDL(인터페이스 정의 언어) 파일을 참고한다.
### OpenAPI V3
{{< feature-state state="alpha" for_k8s_version="v1.23" >}}
{{< feature-state state="beta" for_k8s_version="v1.24" >}}
쿠버네티스 v1.23은 OpenAPI v3 API 발행(publishing)에 대한 초기 지원을 제공한다.
이는 알파 기능이며 기본적으로 비활성화되어 있다.
쿠버네티스 {{< param "version" >}} 버전은 OpenAPI v3 API 발행(publishing)에 대한 베타 지원을 제공한다.
이는 베타 기능이며 기본적으로 활성화되어 있다.
kube-apiserver 구성 요소에
`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여
이 알파 기능을 활성화할 수 있다.
`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화하여
이 베타 기능을 비활성화할 수 있다.
이 기능이 활성화되면, 쿠버네티스 API 서버는
통합된(aggregated) OpenAPI v3 스펙을 쿠버네티스 그룹 버전별로
`/openapi/v3/apis/<group>/<version>` 엔드포인트에 제공한다.
사용할 수 있는 요청 헤더는 아래의 표를 참고한다.
`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든
그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다.
이러한 그룹/버전은 다음과 같은 형식으로 제공된다.
```json
{
"paths": {
...
"api/v1": {
"serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF"
},
"apis/admissionregistration.k8s.io/v1": {
"serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597"
},
...
}
```
위의 상대 URL은 변경 불가능한(immutable) OpenAPI 상세를 가리키고 있으며,
이는 클라이언트에서의 캐싱을 향상시키기 위함이다.
같은 목적을 위해 API 서버는 적절한 HTTP 캐싱 헤더를
설정한다(`Expires`를 1년 뒤로, `Cache-Control`을 `immutable`).
사용 중단된 URL이 사용되면, API 서버는 최신 URL로의 리다이렉트를 반환한다.
쿠버네티스 API 서버는
쿠버네티스 그룹 버전에 따른 OpenAPI v3 스펙을
`/openapi/v3/apis/<group>/<version>?hash=<hash>` 엔드포인트에 게시한다.
사용 가능한 요청 헤더 목록은 아래의 표를 참고한다.
<table>
<caption style="display:none"> OpenAPI v3 질의에 사용할 수 있는 유효한 요청 헤더 값</caption>
@ -126,9 +150,6 @@ kube-apiserver 구성 요소에
</tbody>
</table>
`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든
그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다.
## 지속성
쿠버네티스는 오브젝트의 직렬화된 상태를

20
content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
View File

@ -63,7 +63,7 @@ spec과 status간의 차이에 대응한다.
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다.
```shell
kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
```
그 출력 내용은 다음과 유사하다.
@ -83,14 +83,22 @@ deployment.apps/nginx-deployment created
오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [쿠버네티스 API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.
예를 들어, API 내 파드에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)에 대한 레퍼런스에서,
디플로이먼트에 대한 상세 정보는 [`spec` 필드](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec)에 대한 레퍼런스에서 확인할 수 있다.
해당 API 레퍼런스 페이지에서 PodSpec과 DeploymentSpec에 대해 언급된 내용을 볼 수 있다. 이 이름들은 쿠버네티스가 API를 구현하는데 사용한 Go 언어 코드 구현의 세부 내용이다.
예를 들어, 파드 API 레퍼런스를 보려면
[`spec` 필드](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)를 참조한다.
각 파드에 대해, `.spec` 필드는 파드 및 파드의 원하는 상태(desired state)를
기술한다(예: 파드의 각 컨테이너에 대한 컨테이너 이미지).
오브젝트 상세에 대한 또 다른 예시는 스테이트풀셋 API의
[`spec` 필드](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)이다.
스테이트풀셋의 경우, `.spec` 필드는 스테이트풀셋 및 스테이트풀셋의 원하는 상태(desired state)를 기술한다.
스테이트풀셋의 `.spec`에는 파드 오브젝트에 대한
[템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이 존재한다.
이 템플릿은 스테이트풀셋 명세를 만족시키기 위해
스테이트풀셋 컨트롤러가 생성할 파드에 대한 상세 사항을 설명한다.
서로 다른 종류의 오브젝트는 서로 다른 `.status`를 가질 수 있다.
다시 한번 말하자면, 각 API 레퍼런스 페이지는 각 오브젝트 타입에 대해 해당 `.status` 필드의 구조와 내용에 대해 소개한다.
## {{% heading "whatsnext" %}}
* [파드](/ko/docs/concepts/workloads/pods/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
* API 개념의 더 많은 설명은 [쿠버네티스 API 사용](/ko/docs/reference/using-api/)을 본다.

6
content/ko/docs/concepts/policy/resource-quotas.md
View File

@ -442,7 +442,7 @@ pods 0 10
### 네임스페이스 간 파드 어피니티 쿼터
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
@ -493,10 +493,6 @@ plugins:
해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.
이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
## 요청과 제한의 비교 {#requests-vs-limits}
컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다.

118
content/ko/docs/concepts/scheduling-eviction/api-eviction.md
View File

@ -1,18 +1,122 @@
---
title: API를 이용한 축출(Eviction)
title: API를 이용한 축출(API-initiated Eviction)
content_type: concept
weight: 70
---
{{< glossary_definition term_id="api-eviction" length="short" >}} </br>
`kubectl drain` 명령과 같은 kube-apiserver의 클라이언트를 사용하여,
축출 API를 직접 호출해 축출 요청을 할 수 있다.
그러면 API 서버가 파드를 종료하는 `Eviction` 오브젝트가 생성된다.
축출 API를 직접 호출하거나, 또는 `kubectl drain` 명령과 같이
{{<glossary_tooltip term_id="kube-apiserver" text="API 서버">}}의 클라이언트를 사용하여 프로그램적인 방법으로 축출 요청을 할 수 있다.
이는 `Eviction` 오브젝트를 만들며, API 서버로 하여금 파드를 종료하도록 만든다.
API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 [`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 준수한다.
API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및
[`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 값을 준수한다.
API를 사용하여 `Eviction` 오브젝트를 만드는 것은
정책 기반의 파드 [`DELETE` 동작](/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod)을 수행하는 것과
비슷한 효과를 낸다.
## 축출 API 호출하기
[각 언어 별 쿠버네티스 클라이언트](/ko/docs/tasks/administer-cluster/access-cluster-api/#api에-프로그래밍-방식으로-접근)를 사용하여
쿠버네티스 API를 호출하고 `Eviction` 오브젝트를 생성할 수 있다.
이를 실행하려면, 아래의 예시를 참고하여 POST 호출을 수행한다.
{{< tabs name="Eviction_example" >}}
{{% tab name="policy/v1" %}}
{{< note >}}
`policy/v1` 축출은 v1.22 이상에서 사용 가능하다. 이전 버전에서는 `policy/v1beta1`를 사용한다.
{{< /note >}}
```json
{
"apiVersion": "policy/v1",
"kind": "Eviction",
"metadata": {
"name": "quux",
"namespace": "default"
}
}
```
{{% /tab %}}
{{% tab name="policy/v1beta1" %}}
{{< note >}}
v1.22에서 사용 중단 및 `policy/v1`으로 대체되었다.
{{< /note >}}
```json
{
"apiVersion": "policy/v1beta1",
"kind": "Eviction",
"metadata": {
"name": "quux",
"namespace": "default"
}
}
```
{{% /tab %}}
{{< /tabs >}}
또는 다음 예시와 같이 `curl` 또는 `wget`으로 API에 접근하여
축출 동작을 시도할 수도 있다.
```bash
curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
```
## API를 이용한 축출의 동작
API를 사용하여 축출을 요청하면,
API 서버는 인가 확인(admission checks)를 수행하고 다음 중 하나로 응답한다.
* `200 OK`: 축출 요청이 허용되었고, `Eviction` 서브리소스가 생성되었고,
(마치 파드 URL에 `DELETE` 요청을 보낸 것처럼) 파드가 삭제되었다.
* `429 Too Many Requests`: 현재 설정된
{{<glossary_tooltip term_id="pod-disruption-budget" text="PodDisruptionBudget">}} 때문에
축출이 현재 허용되지 않는다.
또는 API 요청 속도 제한(rate limiting) 때문에 이 응답을 받았을 수도 있다.
* `500 Internal Server Error`: 잘못된 환경 설정(예:
여러 PodDisruptionBudget이 하나의 동일한 파드를 참조함)으로 인해 축출이 허용되지 않는다.
축출하려는 파드가
PodDisruptionBudget이 설정된 워크로드에 속하지 않는다면,
API 서버는 항상 `200 OK`를 반환하고 축출을 허용한다.
API 서버가 축출을 허용하면, 파드는 다음과 같이 삭제된다.
1. API 서버 내 `Pod` 리소스의 삭제 타임스탬프(deletion timestamp)가 업데이트되며,
이 타임스탬프에 명시된 시각이 경과하면 API 서버는 해당 `Pod` 리소스를 종료 대상으로 간주한다.
또한 설정된 그레이스 시간(grace period)이 `Pod` 리소스에 기록된다.
1. 로컬 파드가 실행되고 있는 노드의 {{<glossary_tooltip term_id="kubelet" text="kubelet">}}이
`Pod`가 종료 대상으로 표시된 것을 감지하고
로컬 파드의 그레이스풀 셧다운을 시작한다.
1. kubelet이 파드를 종료하는 와중에, 컨트롤 플레인은
{{<glossary_tooltip term_id="endpoint" text="엔드포인트">}} 및
{{<glossary_tooltip term_id="endpoint-slice" text="엔드포인트슬라이스">}} 오브젝트에서 파드를 삭제한다.
이 결과, 컨트롤러는 파드를 더 이상 유효한 오브젝트로 간주하지 않는다.
1. 파드의 그레이스 시간이 만료되면,
kubelet이 로컬 파드를 강제로 종료한다.
1. kubelet이 API 서버에 `Pod` 리소스를 삭제하도록 지시한다.
1. API 서버가 `Pod` 리소스를 삭제한다.
## 문제가 있어 중단된 축출 트러블슈팅하기
일부 경우에, 애플리케이션이 잘못된 상태로 돌입하여,
직접 개입하기 전에는 축출 API가 `429` 또는 `500` 응답만 반환할 수 있다.
이러한 현상은, 예를 들면 레플리카셋이 애플리케이션을 서비스할 파드를 생성했지만
새 파드가 `Ready`로 바뀌지 못하는 경우에 발생할 수 있다.
또는 마지막으로 축출된 파드가 긴 종료 그레이스 시간을 가진 경우에 이러한 현상을 목격할 수도 있다.
문제가 있어 중단된 축출을 발견했다면, 다음 해결책 중 하나를 시도해 본다.
* 이 문제를 발생시키는 자동 동작(automated operation)을 중단하거나 일시 중지한다.
해당 동작을 재시작하기 전에, 문제가 있어 중단된 애플리케이션을 조사한다.
* 잠시 기다린 뒤, 축출 API를 사용하는 것 대신
클러스터 컨트롤 플레인에서 파드를 직접 삭제한다.
## {{% heading "whatsnext" %}}
- [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기
- [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기
* [Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/)을 사용하여 애플리케이션을 보호하는 방법에 대해 알아본다.
* [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 알아본다.
* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아본다.

107
content/ko/docs/concepts/scheduling-eviction/pod-overhead.md
View File

@ -1,4 +1,8 @@
---
title: 파드 오버헤드
content_type: concept
weight: 30
@ -6,17 +10,12 @@ weight: 30
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
노드 상에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다.
이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다.
_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해
소비되는 리소스를 계산하는 기능이다.
쿠버네티스에서, _파드 오버헤드_ 는 리소스 요청 및 상한 외에도
파드의 인프라에 의해 소비되는 리소스를 계산하는 방법 중 하나이다.
<!-- body -->
@ -25,33 +24,30 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파
[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
이 수행될 때 지정된다.
파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에
파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나
파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다.
파드를 노드에 스케줄링할 때, 컨테이너 리소스 요청의 합 뿐만 아니라 파드의 오버헤드도 함께 고려된다.
마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나 파드의 축출 등급을 부여할 때에도
파드의 오버헤드를 포함하여 고려한다.
## 파드 오버헤드 활성화하기 {#set-up}
## 파드 오버헤드 환경 설정하기 {#set-up}
기능 활성화를 위해 클러스터에서
`PodOverhead` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화),
`overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다.
## 사용 예제
파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다.
파드 오버헤드를 활용하려면, `overhead` 필드를 정의하는 런타임클래스가 필요하다.
예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는
가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다.
```yaml
---
kind: RuntimeClass
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: kata-fc
name: kata-fc
handler: kata-fc
overhead:
podFixed:
memory: "120Mi"
cpu: "250m"
podFixed:
memory: "120Mi"
cpu: "250m"
```
`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산,
@ -68,7 +64,7 @@ spec:
runtimeClassName: kata-fc
containers:
- name: busybox-ctr
image: busybox
image: busybox:1.28
stdin: true
tty: true
resources:
@ -88,13 +84,15 @@ spec:
파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가
`overhead` 를 포함하도록 변경한다.
런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다.
런타임클래스 어드미션 컨트롤러가 변경을 완료하면,
다음의 명령어로 업데이트된 파드 오버헤드 값을 확인할 수 있다.
```bash
kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
```
명령 실행 결과는 다음과 같다.
```
map[cpu:250m memory:120Mi]
```
@ -106,23 +104,26 @@ kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할
해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는
리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다.
일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다.
일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은
파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다.
기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다.
만약 각 컨테이너에 대하여 QoS가 보장되었거나 향상이 가능하도록 QoS 의 리소스 상한 제한이 걸려있으면,
kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의
cgroup 의 상한선을 설정한다. 이 상한선은 컨테이너 리소스 상한과 PodSpec에
정의된 `overhead` 의 합에 기반한다.
만약 각 컨테이너에 대하여 리소스 상한 제한이 걸려있으면
(제한이 걸려있는 보장된(Guaranteed) Qos 또는 향상 가능한(Burstable) QoS),
kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 cgroup 의 상한선을 설정한다.
이 상한선은 컨테이너 리소스 상한과 PodSpec에 정의된 `overhead` 의 합에 기반한다.
CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의
리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다.
CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면,
kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다.
다음의 예제를 참고하여, 워크로드에 대하여 컨테이너의 리소스 요청을 확인하자.
```bash
kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
```
컨테이너 리소스 요청의 합은 각각 CPU 2000m 와 메모리 200MiB 이다.
```
map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
```
@ -133,19 +134,21 @@ map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
kubectl describe node | grep test-pod -B2
```
CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 파드의 오버헤드를 포함한다.
결과를 보면 2250 m의 CPU와 320 MiB의 메모리가 리소스로 요청되었다. 여기에는 파드 오버헤드가 포함되어 있다.
```
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m
```
## 파드 cgroup 상한 확인하기
워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며,
CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다.
파드의 오버헤드 동작을 보여주는 좋은 예이며,
사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다.
워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인해 보자.
다음의 예제에서,
[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며,
CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다.
파드 오버헤드 동작을 보여주는 좋은 예이며, 사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다.
먼저 특정 노드에서 파드의 식별자를 확인해 보자.
@ -155,39 +158,41 @@ POD_ID="$(sudo crictl pods --name test-pod -q)"
```
여기에서, 파드의 cgroup 경로를 확인할 수 있다.
```bash
# 파드가 스케줄 된 노드에서 이것을 실행
sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
```
명령의 결과로 나온 cgroup 경로는 파드의 `pause` 컨테이너를 포함한다. 파드 레벨의 cgroup은 하나의 디렉터리이다.
```
"cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
"cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
```
아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 메모리의 파드 레벨 cgroup 설정을 확인하자.
아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다.
메모리의 파드 레벨 cgroup 설정을 확인하자.
```bash
# 파드가 스케줄 된 노드에서 이것을 실행.
# 또한 사용자의 파드에 할당된 cgroup 이름에 맞춰 해당 이름을 수정.
cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
```
예상대로 320 MiB 이다.
예상한 것과 같이 320 MiB 이다.
```
335544320
```
### 관찰성
`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고,
정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다.
이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다.
그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다.
몇몇 `kube_pod_overhead` 메트릭은
[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 에서 사용할 수 있어,
파드 오버헤드가 사용되는 시기를 식별하고, 정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다.
## {{% heading "whatsnext" %}}
* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)
* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)
* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)에 대해 알아본다.
* 더 자세한 문맥은
[파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) 향상 제안을 확인한다.

6
content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
View File

@ -104,7 +104,7 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사
## 비-선점 프라이어리티클래스 {#non-preempting-priority-class}
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
`preemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의
앞쪽에 배치되지만,
@ -203,9 +203,11 @@ spec:
정보를 제공한다.
파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다.
The scheduler always tries the "nominated Node" before iterating over any other nodes.
스케줄러는 다른 노드에 스케줄링을 시도하기 전에 항상 "지정된 노드"부터 시도한다.
피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다.
스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수
있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용한다. 그 결과,
있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용할 수 있다. 그 결과,
파드 스펙의 `nominatedNodeName` 과 `nodeName` 은 항상 동일하지 않다. 또한,
스케줄러가 노드 N에서 파드를 축출했지만, 파드 P보다 우선순위가 높은 파드가
도착하면, 스케줄러가 노드 N에 새로운 우선순위가 높은 파드를 제공할 수 있다. 이러한

25
content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
View File

@ -21,25 +21,24 @@ kube-scheduler를 미세 조정할 수 있다.
## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기
쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를
통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의
동작은 `RequestedToCapacityRatioArgs`라는
구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources`
두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과
`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을
조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할
리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로
구성된다.
쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여
용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다.
이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어
대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다.
`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은
`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다.
이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다.
`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로
최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다.
`resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과
각 리소스의 가중치를 지정하는 `weight` 로 구성된다.
다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한
`requestedToCapacityRatioArguments` 를 빈 패킹 동작으로
설정하는 구성의 예시이다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
# ...

17
content/ko/docs/concepts/security/controlling-access.md
View File

@ -1,7 +1,9 @@
---
title: 쿠버네티스 API 접근 제어하기
content_type: concept
weight: 5
---
<!-- overview -->
@ -29,13 +31,16 @@ API 서버의 인증서에 대한 루트 인증서를 포함하며,
이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
클라이언트는 이 단계에서 TLS 클라이언트 인증서를 제시할 수 있다.
## 인증
TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
이는 다이어그램에 **1**단계로 표시되어 있다.
클러스터 생성 스크립트 또는 클러스터 관리자는
API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
인증기에 대해서는
[인증](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다.
@ -46,8 +51,6 @@ JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
여러 개의 인증 모듈을 지정할 수 있으며,
이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
이 외에는 사용자가 특정 `username`으로 인증되며,
이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
@ -126,6 +129,12 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre
요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
오브젝트 저장소에 기록(**4**단계)된다.
## 감사(Auditing)
쿠버네티스 감사는 클러스터에서 발생하는 일들의 순서를 문서로 기록하여, 보안과 관련되어 있고 시간 순서로 정리된 기록을 제공한다.
클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션, 그리고 컨트롤 플레인 자신이 생성한 활동을 감사한다.
더 많은 정보는 [감사](/docs/tasks/debug/debug-cluster/audit/)를 참고한다.
## API 서버 포트와 IP

4
content/ko/docs/concepts/policy/pod-security-policy.md → content/ko/docs/concepts/security/pod-security-policy.md
View File

@ -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를 제어했다. 두 버전에서 동일한 파드시큐리티폴리시를 사용하여
이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다.

11
content/ko/docs/concepts/services-networking/dns-pod-service.md
View File

@ -323,17 +323,6 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
쿠버네티스는 최대 32개의 탐색 도메인과
최대 2048자의 탐색 도메인 목록을 허용한다.
### 기능 가용성
파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
| 쿠버네티스 버전 | 기능 지원 |
| :---------: |:-----------:|
| 1.14 | 안정 |
| 1.10 | 베타 (기본값으로 켜져 있음)|
| 1.9 | 알파 |
## {{% heading "whatsnext" %}}

2
content/ko/docs/concepts/services-networking/dual-stack.md
View File

@ -43,7 +43,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음
쿠버네티스 버전, 쿠버네티스 해당 버전에 대한
문서 참조
* 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.)
* 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인
* 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
## IPv4/IPv6 이중 스택 구성

14
content/ko/docs/concepts/services-networking/endpoint-slices.md
View File

@ -1,4 +1,6 @@
---
title: 엔드포인트슬라이스
content_type: concept
weight: 45
@ -144,12 +146,12 @@ endpoints:
v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별
`topology` 가 효과적으로 제거되었다.
`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를
설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신,
v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한
필드는 API 버전 간에 자동으로 번역된다. 예를 들어,
v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"`
키 값은 v1 API의 `zone` 필드로 접근할 수 있다.
`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 설정하는 것은
더 이상 사용되지 않으며 v1 API에서 지원되지 않는다.
대신, v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다.
이러한 필드는 API 버전 간에 자동으로 번역된다.
예를 들어, v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` 키 값은
v1 API의 `zone` 필드로 접근할 수 있다.
{{< /note >}}
### 관리

3
content/ko/docs/concepts/services-networking/ingress-controllers.md
View File

@ -23,7 +23,7 @@ weight: 40
{{% thirdparty-content %}}
* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com/azure/application-gateway/overview)를 구성하는 인그레스 컨트롤러다.
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
컨트롤러다.
* [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
@ -48,6 +48,7 @@ weight: 40
구동하는 인그레스 컨트롤러다.
* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/)
웹서버(프록시로 사용)와 함께 작동한다.
* [Pomerium 인그레스 컨트롤러](https://www.pomerium.com/docs/k8s/ingress.html)는 [Pomerium](https://pomerium.com/) 기반 인그레스 컨트롤러이며, 상황 인지 접근 정책을 제공한다.
* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
* [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는
[Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다.

14
content/ko/docs/concepts/services-networking/ingress.md
View File

@ -74,7 +74,7 @@ graph LR;
{{< codenew file="service/networking/minimal-ingress.yaml" >}}
다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
인그레스에는 `apiVersion`, `kind`, `metadata` 및 `spec` 필드가 명시되어야 한다.
인그레스 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
@ -118,8 +118,14 @@ graph LR;
### DefaultBackend {#default-backend}
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로
[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송하며,
`.spec.defaultBackend`는 이와 같은 경우에 요청을 처리할 백엔드를 지정한다.
`defaultBackend` 는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며,
인그레스 리소스에 지정되어 있지 않다.
`.spec.rules` 가 명시되어 있지 않으면,
`.spec.defaultBackend` 는 반드시 명시되어 있어야 한다.
`defaultBackend` 가 설정되어 있지 않으면, 어느 규칙에도 해당되지 않는 요청의 처리는 인그레스 컨트롤러의 구현을 따른다(이러한
경우를 어떻게 처리하는지 알아보려면 해당 인그레스 컨트롤러 문서를 참고한다).
만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
기본 백엔드로 라우팅 된다.
@ -309,7 +315,7 @@ spec:
controller: example.com/ingress-controller
parameters:
# 이 인그레스클래스에 대한 파라미터는
# "external-configuration" 환경 설정 네임스페이스에 있는
# "external-configuration" 네임스페이스에 있는
# "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다.
scope: Namespace
apiGroup: k8s.example.com

39
content/ko/docs/concepts/services-networking/network-policies.md
View File

@ -45,42 +45,7 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo
네트워크폴리시 의 예시는 다음과 같다.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
```
{{< codenew file="service/networking/networkpolicy.yaml" >}}
{{< note >}}
선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다.
@ -281,7 +246,7 @@ API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을
## 이름으로 네임스페이스 지정
{{< feature-state state="beta" for_k8s_version="1.21" >}}
{{< feature-state for_k8s_version="1.22" state="stable" >}}
쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우

2
content/ko/docs/concepts/services-networking/service-topology.md
View File

@ -16,7 +16,7 @@ weight: 10
이 기능, 특히 알파 `topologyKeys` API는 쿠버네티스 v1.21부터
더 이상 사용되지 않는다.
쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints/)는
쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)는
유사한 기능을 제공한다.
{{</ note >}}

2
content/ko/docs/concepts/services-networking/service-traffic-policy.md
View File

@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
## {{% heading "whatsnext" %}}
* [토폴로지 인식 힌트](/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기
* [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기
* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기

103
content/ko/docs/concepts/services-networking/service.md
View File

@ -24,7 +24,7 @@ weight: 10
## 동기
쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와
쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 목표 상태(desired state)와
일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다.
만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면,
동적으로 파드를 생성하고 제거할 수 있다.
@ -108,13 +108,46 @@ spec:
필드와 같은 값으로 설정된다.
{{< /note >}}
파드의 포트 정의에는 이름이 있고, 서비스의 `targetPort` 속성에서 이 이름을
참조할 수 있다. 이것은 다른 포트 번호를 통한 가용한 동일 네트워크 프로토콜이 있고,
단일 구성 이름을 사용하는 서비스 내에
혼합된 파드가 존재해도 가능하다.
이를 통해 서비스를 배포하고 진전시키는데 많은 유연성을 제공한다.
예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음
버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
파드의 포트 정의에 이름이 있으므로,
서비스의 `targetPort` 속성에서 이 이름을 참조할 수 있다.
예를 들어, 다음과 같은 방법으로 서비스의 `targetPort`를 파드 포트에 바인딩할 수 있다.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app.kubernetes.io/name: proxy
spec:
containers:
- name: nginx
image: nginx:11.14.2
ports:
- containerPort: 80
name: http-web-svc
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort: http-web-svc
```
이것은 서로 다른 포트 번호를 통해 가용한 동일 네트워크 프로토콜이 있고,
단일 구성 이름을 사용하는 서비스 내에 혼합된 파드가 존재해도 가능하다.
이를 통해 서비스를 배포하고 진전시키는 데 많은 유연성을 제공한다.
예를 들어, 클라이언트를 망가뜨리지 않고,
백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다.
서비스의 기본 프로토콜은 TCP이다. 다른
[지원되는 프로토콜](#protocol-support)을 사용할 수도 있다.
@ -125,9 +158,9 @@ spec:
### 셀렉터가 없는 서비스
서비스는 일반적으로 쿠버네티스 파드에 대한 접근을 추상화하지만,
다른 종류의 백엔드를 추상화할 수도 있다.
예를 들면
서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만,
셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며,
여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다.
* 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만,
테스트 환경에서는 자체 데이터베이스를 사용한다.
@ -668,44 +701,38 @@ status:
#### 프로토콜 유형이 혼합된 로드밸런서
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{< feature-state for_k8s_version="v1.24" state="beta" >}}
기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든
포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가
지원하는 프로토콜이어야 한다.
kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다.
`MixedProtocolLBService` 기능 게이트(v1.24에서 kube-apiserver에 대해 기본적으로 활성화되어 있음)는
둘 이상의 포트가 정의되어 있는 경우에 로드밸런서 타입의 서비스에 대해 서로 다른 프로토콜을 사용할 수 있도록 해 준다.
{{< note >}}
로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다.
클라우드 제공자가 혼합 프로토콜을 지원하지 않는다면 이는 단일 프로토콜만을 제공한다는 것을 의미한다.
{{< /note >}}
#### 로드밸런서 NodePort 할당 비활성화
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
`type=LoadBalancer` 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며,
이는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하면 된다.
노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다.
기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다.
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우
해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 **않는다**.
이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다.
이 필드를 사용하려면 클러스터에 `ServiceLBNodePortControl`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로,
`spec.allocateLoadBalancerNodePorts` 필드를 사용할 수 있다.
다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다.
이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다.
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
@ -1211,7 +1238,7 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일
충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는
많은 일이 있다.
### 충돌 방지
### 충돌 방지 {#avoiding-collisions}
쿠버네티스의 주요 철학 중 하나는 잘못한 것이
없는 경우 실패할 수 있는 상황에 노출되어서는
@ -1219,9 +1246,10 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일
충돌할 경우에 대비해 자신의 포트 번호를 선택하지
않아도 된다. 그것은 격리 실패이다.
서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의
서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를
할당하여 이를 수행한다.
서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해,
두 개의 서비스가 충돌하지 않도록 해야 한다.
쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서
각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다.
각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는
각 서비스를 만들기 전에 {{< glossary_tooltip term_id="etcd" >}}에서
@ -1235,6 +1263,25 @@ IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다.
할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된
IP 주소를 정리한다.
#### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range}
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데,
그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address).
이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면
충돌이 발생할 수 있다.
`ServiceIPStaticSubrange`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면,
할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진
`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며,
여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다.
동적 IP 할당은 상위 대역에서 우선적으로 선택하며,
이를 통해 하위 대역에서 할당된 IP와의 충돌 위험을 줄인다.
이렇게 함으로써 사용자가 서비스의 고정 IP를
`service-cluster-ip-range`의 하위 대역에서 할당하면서도
충돌 위험을 줄일 수 있다.
### 서비스 IP 주소 {#ips-and-vips}
실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리,

6
content/ko/docs/concepts/services-networking/topology-aware-hints.md
View File

@ -19,6 +19,12 @@ _토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드
예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해,
인접성을 고려하여 트래픽을 라우트할 수 있다.
{{< note >}}
"토폴로지 인지 힌트" 기능은 베타 단계이며 기본적으로 활성화되어 있지 **않다**.
이 기능을 사용해 보려면,
`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
{{< /note >}}
<!-- body -->
## 동기(motivation)

34
content/ko/docs/concepts/storage/ephemeral-volumes.md
View File

@ -107,7 +107,7 @@ metadata:
spec:
containers:
- name: my-frontend
image: busybox
image: busybox:1.28
volumeMounts:
- mountPath: "/data"
name: my-csi-inline-vol
@ -125,8 +125,19 @@ spec:
더 자세한 사항은 각 CSI 드라이버 문서를
참고한다.
클러스터 관리자는, [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)를 사용하여 파드 내에서 어떤 CSI 드라이버가 사용될 수 있는지를 제어할 수 있으며,
[`allowedCSIDrivers` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)에 기재하면 된다.
### CSI 드라이버 제한 사항
CSI 임시 볼륨은 사용자로 하여금 `volumeAttributes`를
파드 스펙의 일부로서 CSI 드라이버에 직접 제공할 수 있도록 한다.
보통은 관리자만 사용할 수 있는 `volumeAttributes`를 허용하는 CSI 드라이버는
내장(inline) 임시 볼륨 내에서 사용하는 것이 적합하지 않다.
예를 들어, 일반적으로 스토리지클래스 내에 정의되어 있는 파라미터들은
내장 임시 볼륨 사용을 통해 사용자에게 노출되어서는 안 된다.
클러스터 관리자가 이처럼 파드 스펙 내장 임시 볼륨 사용이 가능한 CSI 드라이버를 제한하려면
다음을 수행할 수 있다.
- CSIDriver 스펙의 `volumeLifecycleModes`에서 `Ephemeral`을 제거하여, 해당 드라이버가 내장 임시 볼륨으로 사용되는 것을 막는다.
- [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여 드라이버를 활용하는 방법을 제한한다.
### 일반 임시 볼륨 {#generic-ephemeral-volumes}
@ -158,7 +169,7 @@ metadata:
spec:
containers:
- name: my-frontend
image: busybox
image: busybox:1.28
volumeMounts:
- mountPath: "/scratch"
name: scratch-volume
@ -196,7 +207,7 @@ spec:
즉각적인 바인딩을 사용하는 경우,
스케줄러는 볼륨이 사용 가능해지는 즉시 해당 볼륨에 접근 가능한 노드를 선택하도록 강요받는다.
[리소스 소유권](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent) 관점에서,
[리소스 소유권](/ko/docs/concepts/architecture/garbage-collection/#owners-dependents) 관점에서,
일반 임시 스토리지를 갖는 파드는
해당 임시 스토리지를 제공하는 퍼시스턴트볼륨클레임의 소유자이다.
파드가 삭제되면, 쿠버네티스 가비지 콜렉터는 해당 PVC를 삭제하는데,
@ -239,16 +250,9 @@ PVC 이름 규칙에 따라 서로 다른 파드 간 이름 충돌이 발생할
GenericEphemeralVolume 기능을 활성화하면
사용자가 파드를 생성할 수 있는 경우 PVC를 간접적으로 생성할 수 있도록 허용하며,
심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다.
클러스터 관리자는 이를 명심해야 한다.
이것이 보안 모델에 부합하지 않는다면, 다음의 두 가지 선택지가 있다.
- `volumes`의 목록 중에 `ephemeral` 볼륨 타입이 없는 경우,
[파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/)를
사용한다(쿠버네티스
1.21에서 사용 중단됨).
- 일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부하는
[어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을
사용한다.
심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. 클러스터 관리자는 이를 명심해야 한다.
이것이 보안 모델에 부합하지 않는다면, [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여
일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부해야 한다.
일반적인 [PVC의 네임스페이스 쿼터](/ko/docs/concepts/policy/resource-quotas/#스토리지-리소스-쿼터)는 여전히 적용되므로,
사용자가 이 새로운 메카니즘을 사용할 수 있도록 허용되었어도,

91
content/ko/docs/concepts/storage/persistent-volumes.md
View File

@ -175,6 +175,74 @@ spec:
그러나 `volumes` 부분의 사용자 정의 재활용 파드 템플릿에 지정된 특정 경로는 재활용되는 볼륨의 특정 경로로 바뀐다.
### 퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer) {#persistentvolume-deletion-protection-finalizer}
{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
퍼시스턴트볼륨에 파이널라이저를 추가하여, `Delete` 반환 정책을 갖는 퍼시스턴트볼륨이
기반 스토리지(backing storage)가 삭제된 이후에만 삭제되도록 할 수 있다.
새롭게 도입된 `kubernetes.io/pv-controller` 및 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는
동적으로 프로비전된 볼륨에만 추가된다.
`kubernetes.io/pv-controller` 파이널라이저는 인-트리 플러그인 볼륨에 추가된다. 다음은 이에 대한 예시이다.
```shell
kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
Name: pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
Labels: <none>
Annotations: kubernetes.io/createdby: vsphere-volume-dynamic-provisioner
pv.kubernetes.io/bound-by-controller: yes
pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume
Finalizers: [kubernetes.io/pv-protection kubernetes.io/pv-controller]
StorageClass: vcp-sc
Status: Bound
Claim: default/vcp-pvc-1
Reclaim Policy: Delete
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 1Gi
Node Affinity: <none>
Message:
Source:
Type: vSphereVolume (a Persistent Disk resource in vSphere)
VolumePath: [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk
FSType: ext4
StoragePolicyName: vSAN Default Storage Policy
Events: <none>
```
`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 CSI 볼륨에 추가된다.
다음은 이에 대한 예시이다.
```shell
Name: pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d
Labels: <none>
Annotations: pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
Finalizers: [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer]
StorageClass: fast
Status: Bound
Claim: demo-app/nginx-logs
Reclaim Policy: Delete
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 200Mi
Node Affinity: <none>
Message:
Source:
Type: CSI (a Container Storage Interface (CSI) volume source)
Driver: csi.vsphere.vmware.com
FSType: ext4
VolumeHandle: 44830fa8-79b4-406b-8b58-621ba25353fd
ReadOnly: false
VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com
type=vSphere CNS Block Volume
Events: <none>
```
특정 인-트리 볼륨 플러그인에 대해 `CSIMigration` 기능을 활성화하면 `kubernetes.io/pv-controller` 파이널라이저는 제거되고,
`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저가 추가된다.
이와 비슷하게, `CSIMigration` 기능을 비활성화하면 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 제거되고,
`kubernetes.io/pv-controller` 파이널라이저가 추가된다.
### 퍼시스턴트볼륨 예약
컨트롤 플레인은 클러스터에서 [퍼시스턴트볼륨클레임을 일치하는 퍼시스턴트볼륨에 바인딩](#바인딩)할
@ -284,18 +352,13 @@ FlexVolume은 파드 재시작 시 크기를 조정할 수 있다.
#### 사용 중인 퍼시스턴트볼륨클레임 크기 조정
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
{{< note >}}
사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다.
{{< /note >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다.
파일시스템이 확장되자마자 사용 중인 PVC가 파드에서 자동으로 사용 가능하다.
이 기능은 파드나 디플로이먼트에서 사용하지 않는 PVC에는 영향을 미치지 않는다. 확장을 완료하기 전에
PVC를 사용하는 파드를 만들어야 한다.
다른 볼륨 유형과 비슷하게 FlexVolume 볼륨도 파드에서 사용 중인 경우 확장할 수 있다.
{{< note >}}
@ -329,7 +392,7 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다.
{{< /note >}}
클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure`
클러스터에 `RecoverVolumeExpansionFailure`
기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면
이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다.
더 작은 크기를 지정하여 확장 시도를 요청하려면,
@ -849,17 +912,12 @@ spec:
## 볼륨 파퓰레이터(Volume populator)와 데이터 소스
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
{{< feature-state for_k8s_version="v1.24" state="beta" >}}
{{< note >}}
쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다.
이 알파 기능은 쿠버네티스 1.18에서 도입되었으며
1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다.
현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번
확인한다. {{% version-check %}}
커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해
`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
{{< /note >}}
커스텀 볼륨 파퓰레이터를 사용하려면,
kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다.
다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는
@ -877,6 +935,7 @@ spec:
`dataSourceRef` 필드와 `dataSource` 필드 사이에는
사용자가 알고 있어야 할 두 가지 차이점이 있다.
* `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만,
`dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다.
유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다.

33
content/ko/docs/concepts/storage/storage-capacity.md
View File

@ -16,37 +16,41 @@ weight: 70
예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고
스케줄러가 남아 있는 볼륨을 제공하기 위해 스토리지 용량이 충분한 노드에
파드를 스케줄링하기 위해 이 정보를 어떻게 사용하는지 설명한다.
[파드를 스케줄링](/ko/docs/concepts/scheduling-eviction/)하기 위해 이 정보를 어떻게 사용하는지 설명한다.
스토리지 용량을 추적하지 않으면, 스케줄러는
볼륨을 제공할 충분한 용량이 없는 노드를 선정할 수 있으며,
스케줄링을 여러 번 다시 시도해야 한다.
스토리지 용량 추적은 {{< glossary_tooltip
text="컨테이너 스토리지 인터페이스(CSI)" term_id="csi" >}} 드라이버에서 지원하며,
CSI 드라이버를 설치할 때 [사용하도록 설정](#스토리지-용량-추적-활성화)해야 한다.
## {{% heading "prerequisites" %}}
쿠버네티스 v{{< skew currentVersion >}} 버전은 스토리지 용량 추적을 위한 클러스터-수준 API를 지원한다.
이를 사용하려면, 스토리지 용량 추적을 지원하는 CSI 드라이버를 사용하고 있어야 한다.
사용 중인 CSI 드라이버가 이를 지원하는지, 지원한다면 어떻게 사용하는지를 알아보려면
해당 CSI 드라이버의 문서를 참고한다.
쿠버네티스 v{{< skew currentVersion >}} 버전을 사용하고 있지 않다면,
해당 버전 쿠버네티스 문서를 참고한다.
<!-- body -->
## API
이 기능에는 다음 두 가지 API 확장이 있다.
- CSIStorageCapacity 오브젝트:
- [CSIStorageCapacity](/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) 오브젝트:
CSI 드라이버가 설치된 네임스페이스에
CSI 드라이버가 이 오브젝트를 생성한다. 각 오브젝트는
하나의 스토리지 클래스에 대한 용량 정보를 담고 있으며,
어떤 노드가 해당 스토리지에 접근할 수 있는지를 정의한다.
- [ `CSIDriverSpec.StorageCapacity` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io):
- [`CSIDriverSpec.StorageCapacity` 필드](/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/#CSIDriverSpec):
`true`로 설정하면, 쿠버네티스 스케줄러가
CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려하게 된다.
## 스케줄링
다음과 같은 경우 쿠버네티스 스케줄러에서 스토리지 용량 정보를 사용한다.
- `CSIStorageCapacity` 기능 게이트(feature gate)가 true이고,
- 파드가 아직 생성되지 않은 볼륨을 사용하고,
- 해당 볼륨은 CSI 드라이버를 참조하고
`WaitForFirstConsumer`
@ -97,20 +101,9 @@ CSI 스토리지 드라이버에 볼륨 생성을 요청한다
토폴로지 세그먼트에 하나의 볼륨이 이미 생성되어
다른 볼륨에 충분한 용량이 남아 있지 않을 수 있다.
이러한 상황을 복구하려면
용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하며,
자동으로 처리하려면
[추가 작업](https://github.com/kubernetes/enhancements/pull/1703)이 필요하다.
## 스토리지 용량 추적 활성화
스토리지 용량 추적은 베타 기능이며,
쿠버네티스 1.21 이후 버전부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있다.
클러스터에서 스토리지 용량 추적 기능을 활성화하는 것뿐만 아니라, CSI 드라이버에서도 이 기능을 지원해야 한다.
자세한 내용은 드라이버 문서를 참조한다.
용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하다.
## {{% heading "whatsnext" %}}
- 설계에 대한 자세한 내용은
[파드 스케줄링 스토리지 용량 제약 조건](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)을 참조한다.
- 이 기능의 추가 개발에 대한 자세한 내용은 [개선 추적 이슈 #1472](https://github.com/kubernetes/enhancements/issues/1472)를 참조한다.
- [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 살펴본다.

6
content/ko/docs/concepts/storage/storage-classes.md
View File

@ -87,7 +87,7 @@ volumeBindingMode: Immediate
여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이
이름은 "kubernetes.io" 가 접두사로 시작하고, 쿠버네티스와
함께 제공된다). 또한, 쿠버네티스에서 정의한
[사양](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)을
[사양](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)을
따르는 독립적인 프로그램인 외부 프로비저너를 실행하고 지정할 수 있다.
외부 프로비저너의 작성자는 코드의 수명, 프로비저너의
배송 방법, 실행 방법, (Flex를 포함한)볼륨 플러그인
@ -241,8 +241,8 @@ allowedTopologies:
- matchLabelExpressions:
- key: failure-domain.beta.kubernetes.io/zone
values:
- us-central1-a
- us-central1-b
- us-central-1a
- us-central-1b
```
## 파라미터

7
content/ko/docs/concepts/storage/volume-health-monitoring.md
View File

@ -1,4 +1,9 @@
---
title: 볼륨 헬스 모니터링
content_type: concept
---
@ -19,7 +24,7 @@ CSI 드라이버가 컨트롤러 측의 볼륨 헬스 모니터링 기능을 지
외부 헬스 모니터 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 노드 장애 이벤트도 감시한다. `enable-node-watcher` 플래그를 true로 설정하여 노드 장애 모니터링을 활성화할 수 있다. 외부 헬스 모니터가 노드 장애 이벤트를 감지하면, 컨트롤러는 이 PVC를 사용하는 파드가 장애 상태인 노드에 있음을 나타내는 이벤트가 PVC에 보고된다고 알린다.
CSI 드라이버가 노드 측에서 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지되면 PVC를 사용하는 모든 파드에서 이벤트가 보고된다.
CSI 드라이버가 노드 측에서 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지되면 PVC를 사용하는 모든 파드에서 이벤트가 보고된다. 그리고, 볼륨 헬스 정보는 kubelet VolumeStats 메트릭 형태로 노출된다. 새로운 kubelet_volume_stats_health_status_abnormal 메트릭이 추가되었다. 이 메트릭은 `namespace` 및 `persistentvolumeclaim` 2개의 레이블을 포함한다. 카운터는 1 또는 0이다. 카운터가 1이면 볼륨이 정상적이지 않음을, 0이면 정상적임을 의미한다. 더 많은 정보는 [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)를 참고한다.
{{< note >}}
노드 측에서 이 기능을 사용하려면 `CSIVolumeHealth` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.

47
content/ko/docs/concepts/storage/volume-snapshots.md
View File

@ -120,6 +120,7 @@ spec:
driver: hostpath.csi.k8s.io
source:
volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
sourceVolumeMode: Filesystem
volumeSnapshotClassName: csi-hostpath-snapclass
volumeSnapshotRef:
name: new-snapshot-test
@ -141,6 +142,7 @@ spec:
driver: hostpath.csi.k8s.io
source:
snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
sourceVolumeMode: Filesystem
volumeSnapshotRef:
name: new-snapshot-test
namespace: default
@ -148,6 +150,51 @@ spec:
`snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의 고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다. `VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를 지정한다.
`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다.
`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다.
소스 볼륨 모드가 명시되어 있지 않으면,
쿠버네티스는 해당 스냅샷의 소스 볼륨 모드를 알려지지 않은 상태(unknown)로 간주하여 스냅샷을 처리한다.
## 스냅샷의 볼륨 모드 변환하기 {#convert-volume-mode}
클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면,
인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이
API에 있는 것이다.
클러스터가 이 기능을 지원하는지 확인하려면, 다음 명령어를 실행한다.
```yaml
$ kubectl get crd volumesnapshotcontent -o yaml
```
사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때
기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면,
`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에
`snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"` 어노테이션을 추가해야 한다.
이전에 프로비전된 스냅샷의 경우에는,
클러스터 관리자가 `Spec.SourceVolumeMode`를 추가해야 한다.
이 기능이 활성화된 예시 `VolumeSnapshotContent` 리소스는 다음과 같을 것이다.
```yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
name: new-snapshot-content-test
annotations:
- snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"
spec:
deletionPolicy: Delete
driver: hostpath.csi.k8s.io
source:
snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
sourceVolumeMode: Filesystem
volumeSnapshotRef:
name: new-snapshot-test
namespace: default
```
## 스냅샷을 위한 프로비저닝 볼륨
`PersistentVolumeClaim` 오브젝트의 *dataSource* 필드를 사용하여

127
content/ko/docs/concepts/storage/volumes.md
View File

@ -143,14 +143,20 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
#### azureDisk CSI 마이그레이션
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서
`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI
드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver)
를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk`
기능을 활성화해야 한다.
`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우,
기존 인-트리 플러그인의 모든 플러그인 작업을
`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다.
이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) 를 설치하고
`CSIMigration` 기능을 활성화해야 한다.
#### azureDisk CSI 마이그레이션 완료
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
컨트롤러 매니저 및 kubelet이 `azureDisk` 스토리지 플러그인을 로드하지 않도록 하려면,
`InTreePluginAzureDiskUnregister` 플래그를 `true`로 설정한다.
### azureFile {#azurefile}
@ -170,7 +176,15 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "<partition n
를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다.
Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다.
Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다.
#### azureFile CSI 마이그레이션 완료
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
컨트롤러 매니저 및 kubelet이 `azureFile` 스토리지 플러그인을 로드하지 않도록 하려면,
`InTreePluginAzureFileUnregister` 플래그를 `true`로 설정한다.
### cephfs
@ -219,17 +233,17 @@ spec:
#### 오픈스택 CSI 마이그레이션
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
Cinder의`CSIMigration` 기능은 Kubernetes 1.21에서 기본적으로 활성화됩니다.
Cinder의`CSIMigration` 기능은 Kubernetes 1.21부터 기본적으로 활성화되어 있다.
기존 트리 내 플러그인에서 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI)
드라이버로 모든 플러그인 작업을 수행한다.
[오픈스택 Cinder CSI 드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)가
클러스터에 설치되어 있어야 한다.
`CSIMigrationOpenStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
`false` 로 설정하여 클러스터에 대한 Cinder CSI 마이그레이션을 비활성화할 수 있다.
`CSIMigrationOpenStack` 기능을 비활성화하면, 트리 내 Cinder 볼륨 플러그인이
Cinder 볼륨 스토리지 관리의 모든 측면을 담당한다.
컨트롤러 매니저 및 kubelet이 인-트리 Cinder 플러그인을 로드하지 않도록 하려면,
`InTreePluginOpenStackUnregister`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다.
### 컨피그맵(configMap) {#configmap}
@ -251,7 +265,7 @@ metadata:
spec:
containers:
- name: test
image: busybox
image: busybox:1.28
volumeMounts:
- name: config-vol
mountPath: /etc/config
@ -879,7 +893,7 @@ RBD CSI 드라이버로의 마이그레이션을 시도하기 전에
* 또한, 트리 내(in-tree) 스토리지클래스의
`adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의
`adminSecretName` 값이 `adminId` 파라미터 값의
base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다.
base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. {{< /note >}}
### secret
@ -955,66 +969,15 @@ spec:
StorageOS, 동적 프로비저닝과 퍼시스턴트 볼륨 클래임에 대한 더 자세한 정보는
[StorageOS 예제](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 참고한다.
### vsphereVolume {#vspherevolume}
### vsphereVolume (사용 중단됨) {#vspherevolume}
{{< note >}}
쿠버네티스 vSphere 클라우드 공급자를 구성해야 한다. 클라우드공급자
구성에 대해선 [vSphere 시작 가이드](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)를 참조한다.
이 드라이버 대신 외부(out-of-tree) vSphere CSI 드라이버를 사용하는 것을 권장한다.
{{< /note >}}
`vsphereVolume` 은 vSphere VMDK 볼륨을 파드에 마운트하는데 사용된다. 볼륨을
마운트 해제해도 볼륨의 내용이 유지된다. VMFS와 VSAM 데이터스토어를 모두 지원한다.
{{< note >}}
파드와 함께 사용하기 위해선 먼저 다음 방법 중 하나를 사용하여 vSphere VMDK 볼륨을 생성해야 한다.
{{< /note >}}
#### VMDK 볼륨 생성하기 {#creating-vmdk-volume}
다음 중 하나를 선택해서 VMDK를 생성한다.
{{< tabs name="tabs_volumes" >}}
{{% tab name="vmkfstools를 사용해서 생성" %}}
먼저 ESX에 ssh로 들어간 다음, 다음 명령을 사용해서 VMDK를 생성한다.
```shell
vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk
```
{{% /tab %}}
{{% tab name="vmware-vdiskmanager를 사용해서 생성" %}}
다음 명령을 사용해서 VMDK를 생성한다.
```shell
vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk
```
{{% /tab %}}
{{< /tabs >}}
#### vSphere VMDK 구성 예시 {#vsphere-vmdk-configuration}
```yaml
apiVersion: v1
kind: Pod
metadata:
name: test-vmdk
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /test-vmdk
name: test-volume
volumes:
- name: test-volume
# 이 VMDK 볼륨은 이미 있어야 한다.
vsphereVolume:
volumePath: "[DatastoreName] volumes/myDisk"
fsType: ext4
```
더 자세한 내용은 [vSphere 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) 예제를 참고한다.
#### vSphere CSI 마이그레이션 {#vsphere-csi-migration}
@ -1026,8 +989,15 @@ spec:
[vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가
클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다.
마이그레이션에 대한 추가 조언은 VMware의 문서 페이지
[인-트리 vSphere 볼륨을 vSphere 컨테이너 스토리지 플러그인으로 마이그레이션하기](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html)를 참고한다.
또한 최소 vSphere vCenter/ESXi 버전은 7.0u1이고 최소 HW 버전은 VM 버전 15여야 한다.
쿠버네티스 v{{< skew currentVersion >}} 버전에서 외부(out-of-tree) CSI 드라이버로 마이그레이션하려면
vSphere 7.0u2 이상을 사용하고 있어야 한다.
v{{< skew currentVersion >}} 외의 쿠버네티스 버전을 사용 중인 경우,
해당 쿠버네티스 버전의 문서를 참고한다.
쿠버네티스 v{{< skew currentVersion >}} 버전과 vSphere 이전 버전을 사용 중이라면,
vSphere 버전을 7.0u2 이상으로 업그레이드하는 것을 추천한다.
{{< note >}}
빌트인 `vsphereVolume` 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다.
@ -1128,7 +1098,7 @@ spec:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
image: busybox
image: busybox:1.28
command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
volumeMounts:
- name: workdir1
@ -1196,10 +1166,9 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면
`csi` 볼륨은 세 가지 방법으로 파드에서 사용할 수 있다.
* [퍼시스턴트볼륨클레임](#persistentvolumeclaim)에 대한 참조를 통해서
* [일반 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)과 함께
(알파 기능)
* [일반 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)과 함께
* 드라이버가 지원하는 경우
[CSI 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)과 함께 (베타 기능)
[CSI 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)과 함께 (베타 기능)
스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을
구성할 수 있다.
@ -1262,11 +1231,11 @@ CSI 설정 변경 없이 평소와 같이
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
파드 명세 내에서 CSI 볼륨을 직접 구성할 수
있다. 이 방식으로 지정된 볼륨은 임시 볼륨이며
파드가 다시 시작할 때 지속되지 않는다. 자세한 내용은 [임시
볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)을
참고한다.
파드 명세 내에서 CSI 볼륨을 직접 구성할 수 있다.
이 방식으로 지정된 볼륨은 임시 볼륨이며
파드가 다시 시작할 때 지속되지 않는다.
자세한 내용은
[임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)을 참고한다.
CSI 드라이버의 개발 방법에 대한 더 자세한 정보는
[쿠버네티스-csi 문서](https://kubernetes-csi.github.io/docs/)를 참조한다.

17
content/ko/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -69,7 +69,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
# │ │ │ ┌───────────── 월 (1 - 12)
# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지;
# │ │ │ │ │ 특정 시스템에서는 7도 일요일)
# │ │ │ │ │
# │ │ │ │ │ 또는 sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
# * * * * *
```
@ -91,6 +91,21 @@ kube-controller-manager 컨테이너에 설정된 시간대는
크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다.
## 타임 존
크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다.
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
`CronJobTimeZone` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면,
크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나,
타임 존에 대한 실험적 지원을 제공하지 않는 쿠버네티스 버전을 사용 중인 경우,
클러스터의 모든 크론잡은 타임 존이 명시되지 않은 것으로 동작한다).
이 기능을 활성화하면, `spec.timeZone`을 유효한 [타임 존](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) 이름으로 지정할 수 있다.
예를 들어, `spec.timeZone: "Etc/UTC"`와 같이 설정하면 쿠버네티스는 협정 세계시를 기준으로 스케줄을 해석한다.
Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로 인클루드되며, 시스템에서 외부 데이터베이스를 사용할 수 없을 때 폴백(fallback)으로 사용된다.
## 크론잡의 한계 {#cron-job-limitations}
크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는

16
content/ko/docs/concepts/workloads/controllers/daemonset.md
View File

@ -76,11 +76,11 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
`.spec.selector` 필드는 파드 셀렉터이다. 이것은
[잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다.
쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
셀렉터의 기본 값은 `kubectl apply` 과 호환되지 않는다.
또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 의 변형은 가능하지 않다.
파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다.
`.spec.template`의 레이블과 매치되는
파드 셀렉터를 명시해야 한다.
또한, 한 번 데몬셋이 만들어지면
`.spec.selector` 는 바꿀 수 없다.
파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다.
`.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.
@ -91,8 +91,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.
만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다.
일치하지 않는 구성은 API에 의해 거부된다.
`.spec.selector` 는 `.spec.template.metadata.labels` 와 일치해야 한다.
이 둘이 서로 일치하지 않는 구성은 API에 의해 거부된다.
### 오직 일부 노드에서만 파드 실행
@ -107,7 +107,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
### 기본 스케줄러로 스케줄
{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
{{< feature-state for_k8s_version="1.17" state="stable" >}}
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나

26
content/ko/docs/concepts/workloads/controllers/deployment.md
View File

@ -255,10 +255,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다.
기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지).
예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음
이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며,
충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다.
이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다.
예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음,
이전 파드를 삭제하고, 또 다른 새로운 파드를 만든 것을 볼 수 있다.
충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다.
이것은 최소 3개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다.
디플로이먼트의 레플리카 크기가 4인 경우, 파드 숫자는 3개에서 5개 사이이다.
* 디플로이먼트의 세부 정보 가져오기
```shell
@ -303,13 +304,20 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
```
처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서
3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다.
디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음
이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다.
이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다.
처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성하고
3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다.
디플로이먼트를 업데이트하자, 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 모두 실행될 때까지 대기하였다.
그 뒤 이전 레플리카셋을 2개로 스케일 다운하고 새 레플리카셋을 2개로 스케일 업하여 모든 시점에 대해 최소 3개 / 최대 3개의 파드가 존재하도록 하였다.
이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다.
마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다.
{{< note >}}
쿠버네티스가 `availableReplicas` 수를 계산할 때 종료 중인(terminating) 파드는 포함하지 않으며,
이 수는 `replicas - maxUnavailable` 와 `replicas + maxSurge` 사이에 존재한다.
그 결과, 롤아웃 중에는 파드의 수가 예상보다 많을 수 있으며,
종료 중인 파드의 `terminationGracePeriodSeconds`가 만료될 때까지는 디플로이먼트가 소비하는 총 리소스가 `replicas + maxSurge` 이상일 수 있다.
{{< /note >}}
### 롤오버(일명 인-플라이트 다중 업데이트)
디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이

27
content/ko/docs/concepts/workloads/controllers/job.md
View File

@ -42,7 +42,9 @@ weight: 50
```shell
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
```
출력 결과는 다음과 같다.
```
job.batch/pi created
```
@ -52,7 +54,9 @@ job.batch/pi created
```shell
kubectl describe jobs/pi
```
출력 결과는 다음과 같다.
```
Name: pi
Namespace: default
@ -97,7 +101,9 @@ Events:
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
echo $pods
```
출력 결과는 다음과 같다.
```
pi-5rwd7
```
@ -110,7 +116,9 @@ pi-5rwd7
```shell
kubectl logs $pods
```
출력 결과는 다음과 같다.
```shell
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
```
@ -190,7 +198,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
### 완료 모드
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
`.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
@ -308,7 +316,7 @@ spec:
### 완료된 잡을 위한 TTL 메커니즘
{{< feature-state for_k8s_version="v1.21" state="beta" >}}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은
잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해
@ -425,13 +433,7 @@ spec:
### 잡 일시 중지
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< note >}}
이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며,
이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다.
[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다.
{{< /note >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
즉시 파드 생성을 시작하고 잡이 완료될 때까지
@ -482,7 +484,7 @@ spec:
kubectl get jobs/myjob -o yaml
```
```json
```yaml
apiVersion: batch/v1
kind: Job
# .metadata and .spec omitted
@ -581,7 +583,9 @@ Events:
```shell
kubectl get job old -o yaml
```
출력 결과는 다음과 같다.
```yaml
kind: Job
metadata:
@ -631,7 +635,8 @@ spec:
이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다.
사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
사용자가 느낄 수 있는 유일한 차이점은
컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
{{< /note >}}
이 기능이 활성화되지 않으면, 잡

2
content/ko/docs/concepts/workloads/controllers/replicaset.md
View File

@ -223,8 +223,6 @@ pod2 1/1 Running 0 36s
레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
레플리카셋 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.

6
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
View File

@ -185,8 +185,8 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용
Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를
삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다.
REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후,
레플리케이션 컨트롤러를 삭제).
REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우
명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, 레플리케이션 컨트롤러를 삭제).
### 레플리케이션 컨트롤러만 삭제
@ -194,7 +194,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적
kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=orphan`을 지정하라.
REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라.
원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면,
새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를

31
content/ko/docs/concepts/workloads/controllers/statefulset.md
View File

@ -115,7 +115,7 @@ spec:
### 파드 셀렉터
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다.
### 볼륨 클레임 템플릿
@ -226,8 +226,8 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
되기 전까지 종료되지 않는다.
### 파드 관리 정책
쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를
통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.
스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해
고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다.
#### OrderedReady 파드 관리
@ -266,7 +266,9 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
각 파드의 업데이트는 한 번에 하나씩 한다.
쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를
설정한 경우,
컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
### 파티션 롤링 업데이트 {#partitions}
@ -280,6 +282,27 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
### 최대 사용 불가능(unavailable) 파드 수
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
`.spec.updateStrategy.rollingUpdate.maxUnavailable` 필드를 명시하여,
업데이트 과정에서 사용 불가능(unavailable) 파드를 최대 몇 개까지 허용할 것인지를 조절할 수 있다.
값은 절대값(예: `5`) 또는 목표 파드 퍼센티지(예: `10%`)로 명시할 수 있다.
절대값은 퍼센티지 값으로 계산한 뒤 올림하여 얻는다.
이 필드는 0일 수 없다. 기본값은 1이다.
이 필드는 `0` 에서 `replicas - 1` 사이 범위에 있는 모든 파드에 적용된다.
이 범위 내에 사용 불가능한 파드가 있으면,
`maxUnavailable`로 집계된다.
{{< note >}}
`maxUnavailable` 필드는 현재 알파 단계이며
`MaxUnavailableStatefulSet`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 API 서버에서만
동작한다.
{{< /note >}}
### 강제 롤백
기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과

29
content/ko/docs/concepts/workloads/pods/_index.md
View File

@ -180,7 +180,7 @@ spec:
spec:
containers:
- name: hello
image: busybox
image: busybox:1.28
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
restartPolicy: OnFailure
# 여기까지 파드 템플릿이다
@ -251,20 +251,19 @@ spec:
### 파드 네트워킹
각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의
모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를
공유한다. 파드 내부(그때 **만** 해당)에서, 파드에 속한
컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가
*파드 외부의* 엔티티와 통신할 때,
공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다.
파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며,
`localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는
POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로
통신할 수도 있다. 다른 파드의 컨테이너는
고유한 IP 주소를 가지며
[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이 IPC로 통신할 수 없다.
다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을
사용하여 통신할 수 있다.
각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다.
파드의 모든 컨테이너는 네트워크 네임스페이스를 공유하며,
여기에는 IP 주소와 네트워크 포트가 포함된다.
파드 내부(이 경우에 **만** 해당)에서, 파드에 속한 컨테이너는
`localhost` 를 사용하여 서로 통신할 수 있다.
파드의 컨테이너가 *파드 외부의* 엔티티와 통신할 때,
공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다.
파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며,
`localhost` 를 통해 서로를 찾을 수 있다.
파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은
표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있다.
다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 OS 수준의 IPC로 통신할 수 없다.
다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다.
파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된
`name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한

2
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
View File

@ -70,4 +70,4 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
## {{% heading "whatsnext" %}}
* [임시 컨테이너 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
* [임시 컨테이너 디버깅하기](/ko/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)에 대해 알아보기.

2
content/ko/docs/concepts/workloads/pods/init-containers.md
View File

@ -332,4 +332,4 @@ Active deadline은 초기화 컨테이너를 포함한다.
## {{% heading "whatsnext" %}}
* [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성)
* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기
* [초기화 컨테이너 디버깅](/ko/docs/tasks/debug/debug-application/debug-init-containers/) 알아보기

4
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -136,8 +136,8 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과
종료 시간이 표시된다.
컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에
실행된다.
컨테이너에 구성된 `preStop` 훅이 있는 경우,
이 혹은 컨테이너가 `Terminated` 상태에 들어가기 전에 실행된다.
## 컨테이너 재시작 정책 {#restart-policy}

70
content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
View File

@ -4,21 +4,11 @@ content_type: concept
weight: 40
---
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
<!-- leave this shortcode in place until the note about EvenPodsSpread is
obsolete -->
<!-- overview -->
사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다.
{{< note >}}
v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서
`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
활성화해야 한다
{{< /note >}}
<!-- body -->
@ -83,16 +73,42 @@ spec:
- **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
이것은 0보다는 커야 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다.
- `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는
대상 토폴로지에서 일치하는 파드 수와 전역 최솟값
(토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. 예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, 전역 최솟값은 0)
(토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수.
예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면,
전역 최솟값은 0)
사이에 허용되는 최대 차이이다.
- `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는
왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
- **minDomains** 는 적합한(eligible) 도메인의 최소 수를 나타낸다.
도메인은 토폴로지의 특정 인스턴스 중 하나이다.
도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다.
- `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다.
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 적으면,
파드 토폴로지 스프레드는 "글로벌 미니멈"을 0으로 간주한 뒤, `skew` 계산이 수행된다.
"글로벌 미니멈"은 적합한 도메인 내에 매치되는 파드의 최소 수 이며,
적합한 도메인 수가 `minDomains`보다 적은 경우에는 0이다.
- 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 크거나 같으면,
이 값은 스케줄링에 영향을 미치지 않는다.
- `minDomains`가 nil이면, 이 제약은 `minDomains`가 1인 것처럼 동작한다.
- `minDomains`가 nil이 아니면, `whenUnsatisfiable`의 값은 "`DoNotSchedule`"이어야 한다.
{{< note >}}
`minDomains` 필드는 1.24에서 추가된 알파 필드이다.
이를 사용하려면 `MinDomainsInPodToplogySpread`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
{{< /note >}}
- **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
- **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다.
- `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
- `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다.
- **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.
파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 AND로 연결된다 - kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다.
@ -306,11 +322,12 @@ class zoneC cluster;
예시 구성은 다음과 같다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints:
@ -321,21 +338,17 @@ profiles:
```
{{< note >}}
기본 스케줄링 제약 조건에 의해 생성된 점수는
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에
의해 생성된 점수와 충돌 할 수 있다.
`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서
이 플러그인을 비활성화 하는 것을 권장한다.
[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)은
기본적으로 비활성화되어 있다.
비슷한 효과를 얻기 위해 `PodTopologySpread`를 사용하는 것을 추천한다.
{{< /note >}}
#### 내부 기본 제약
#### 내장 기본 제약 {#internal-default-constraints}
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
기본적으로 활성화된 `DefaultPodTopologySpread` 기능 게이트를 사용하면, 기존
`SelectorSpread` 플러그인이 비활성화된다.
kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은
기본 토폴로지 제약 조건을 사용한다.
파드 토폴로지 스프레딩에 대해 클러스터 수준의 기본 제약을 설정하지 않으면,
kube-scheduler는 다음과 같은 기본 토폴로지 제약을 설정한 것처럼 동작한다.
```yaml
defaultConstraints:
@ -347,8 +360,8 @@ defaultConstraints:
whenUnsatisfiable: ScheduleAnyway
```
또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인이
비활성화된다.
또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인은
기본적으로 비활성화되어 있다.
{{< note >}}
`PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가
@ -366,11 +379,12 @@ defaultConstraints:
`defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
apiVersion: kubescheduler.config.k8s.io/v1beta3
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- schedulerName: default-scheduler
pluginConfig:
- name: PodTopologySpread
args:
defaultConstraints: []

8
content/ko/docs/contribute/_index.md
View File

@ -95,9 +95,9 @@ class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
class S,T,U spacewhite
class first,second,third white
{{</ mermaid >}}
***그림 - 신규 기여자를 위한 시작 가이드***
그림 1. 신규 기여자를 위한 시작 가이드.
위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!
그림 1은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!
일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다.
역할과 권한에 대한 자세한 내용은
@ -105,7 +105,7 @@ class first,second,third white
## 첫 번째 기여
몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.
몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 그림 2는 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
@ -136,7 +136,7 @@ class A,B,D,E,F,G grey
class S,T spacewhite
class first,second white
{{</ mermaid >}}
***그림 - 첫 기여를 위한 준비***
그림 2. 첫 기여를 위한 준비.
- [기여 개요](/ko/docs/contribute/new-content/)를 읽고
기여할 수 있는 다양한 방법에 대해 알아봅니다.

1
content/ko/docs/contribute/advanced.md
View File

@ -86,6 +86,7 @@ SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/
- 문서 리포지터리에 대한 처음 몇 번의 PR을 통해 새로운 기여자를 멘토링한다.
- 새로운 기여자가 쿠버네티스 멤버가 되기 위해 필요한 보다 복잡한 PR을 작성하도록 지원한다.
- 쿠버네티스 멤버 가입을 위해 [기여자를 후원](/ko/docs/contribute/advanced/#새로운-기여자-후원)한다.
- 월간 미팅을 개최하여 새로운 기여자에게 도움을 주고 조언을 해 준다.
현재 새로운 기여자 홍보대사는 각 SIG-Docs 회의와 [쿠버네티스 #sig-docs 채널](https://kubernetes.slack.com)에서 발표된다.

17
content/ko/docs/contribute/participate/pr-wranglers.md
View File

@ -48,8 +48,7 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
CLA에 서명한 후 PR을 열 수 있음을 알린다.
**작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!**
- [LGTM 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을
지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다.
- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
@ -88,3 +87,17 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
[`k8s-triage-robot`](https://github.com/k8s-triage-robot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다.
{{< /note >}}
## PR 랭글러 섀도우 프로그램
2021년 말에, SIG Docs는 PR 랭글러 섀도우 프로그램을 도입했다. 이 프로그램은 새로운 기여자가 PR 랭글링 과정을 이해하는 데 도움을 주기 위해 도입되었다.
### 섀도우 되기
- PR 랭글러 섀도우 활동에 관심이 있다면, [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)에서 올해의 PR 랭글링 스케줄을 확인하고 지원한다.
- 쿠버네티스 org 멤버는 [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수정하여 기존 PR 랭글러를 1주일 간 섀도잉할 수 있다.
- 쿠버네티스 org 비 멤버는 [#sig-docs 슬랙 채널](https://kubernetes.slack.com/messages/sig-docs)에서 특정 주간에 대해 기존 PR 랭글러에 대한 섀도잉을 요청할 수 있다. Brad Topol (`@bradtopol`) 또는 [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) 중 한 명에게 연락하면 된다.
- PR 랭글러 섀도워로 지원했다면, [쿠버네티스 슬랙](https://slack.k8s.io)에서 PR 랭글러에게 자신을 소개한다.

4
content/ko/docs/contribute/review/reviewing-prs.md
View File

@ -36,7 +36,7 @@ weight: 10
## 리뷰 과정
일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 아래의 그림은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.
일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
@ -67,7 +67,7 @@ class S,T spacewhite
class third,fourth white
{{</ mermaid >}}
***그림 - 리뷰 과정 절차***
그림 1. 리뷰 과정 절차.
1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로
이동한다.

2
content/ko/docs/home/_index.md
View File

@ -60,7 +60,7 @@ cards:
title: K8s 릴리스 노트
description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다.
button: "쿠버네티스 다운로드"
button_path: "/docs/setup/release/notes"
button_path: "/releases/download"
- name: about
title: 문서에 대하여
description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다.

7
content/ko/docs/reference/_index.md
View File

@ -43,7 +43,7 @@ no_list: true
## CLI
* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
* [kubectl](/ko/docs/reference/kubectl/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
* [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드.
* [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.
@ -66,6 +66,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
* 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는
[포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트
## API 설정
이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
@ -73,10 +74,12 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
제공하지 않는다.
* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
* [kube-apiserver 환경설정 (v1)](/docs/reference/config-api/apiserver-config.v1/)
* [kube-apiserver 암호화 (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
* [kubelet 환경설정 (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) 및
[kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kubelet 크리덴셜 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/)
* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및
[kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)

2
content/ko/docs/reference/access-authn-authz/authorization.md
View File

@ -76,7 +76,7 @@ DELETE | delete(개별 리소스), deletecollection(리소스 모음)
쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,
* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)
* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/)
* `policy` API 그룹의 `podsecuritypolicies` 리소스에 대한 `use` 동사.
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
* `rbac.authorization.k8s.io` API 그룹의 `roles` 및 `clusterroles` 리소스에 대한 `bind` 동사.

481
content/ko/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -29,7 +29,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.
```shell
--feature-gates="...,GracefulNodeShutdown=true"
--feature-gates=...,GracefulNodeShutdown=true
```
다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를
@ -61,9 +61,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `APIServerIdentity` | `false` | 알파 | 1.20 | |
| `APIServerTracing` | `false` | 알파 | 1.22 | |
| `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | |
| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | 1.23 |
| `AnyVolumeDataSource` | `true` | 베타 | 1.24 | |
| `AppArmor` | `true` | 베타 | 1.4 | |
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | |
| `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
| `CPUManager` | `true` | 베타 | 1.10 | |
| `CPUManagerPolicyAlphaOptions` | `false` | 알파 | 1.23 | |
@ -74,34 +74,24 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `CSIInlineVolume` | `true` | 베타 | 1.16 | - |
| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigration` | `true` | 베타 | 1.17 | |
| `CSIMigrationAWS` | `false` | 알파 | 1.14 | |
| `CSIMigrationAWS` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigrationAWS` | `false` | 베타 | 1.17 | 1.22 |
| `CSIMigrationAWS` | `true` | 베타 | 1.23 | |
| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | 1.22 |
| `CSIMigrationAzureDisk` | `true` | 베타 | 1.23 | |
| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 |
| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | |
| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | 1.23 |
| `CSIMigrationAzureFile` | `true` | 베타 | 1.24 | |
| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigrationGCE` | `false` | 베타 | 1.17 | 1.22 |
| `CSIMigrationGCE` | `true` | 베타 | 1.23 | |
| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 |
| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | |
| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
| `CSIMigrationPortworx` | `false` | 알파 | 1.23 | |
| `csiMigrationRBD` | `false` | 알파 | 1.23 | |
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | 베타 | 1.21 | |
| `CSIVolumeHealth` | `false` | 알파 | 1.21 | |
| `CSRDuration` | `true` | 베타 | 1.22 | |
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 |
| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | |
| `ContextualLogging` | `false` | 알파 | 1.24 | |
| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
| `CustomResourceValidationExpressions` | `false` | 알파 | 1.23 | |
| `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 |
| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | |
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | |
| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | 1.22 |
| `DelegateFSGroupToCSIDriver` | `true` | 베타 | 1.23 | |
| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
@ -111,31 +101,25 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `DisableCloudProviders` | `false` | 알파 | 1.22 | |
| `DisableKubeletCloudCredentialProviders` | `false` | 알파 | 1.23 | |
| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 |
| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | |
| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 |
| `EfficientWatchResumption` | `true` | 베타 | 1.21 | |
| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | 1.21 |
| `DownwardAPIHugePages` | `true` | 베타 | 1.22 | |
| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | 1.21 |
| `EndpointSliceTerminatingCondition` | `true` | 베타 | 1.22 | |
| `EphemeralContainers` | `false` | 알파 | 1.16 | 1.22 |
| `EphemeralContainers` | `true` | 베타 | 1.23 | |
| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 |
| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | |
| `ExpandedDNSConfig` | `false` | 알파 | 1.22 | |
| `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 |
| `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | |
| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 |
| `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | |
| `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | |
| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 |
| `GracefulNodeShutdown` | `true` | 베타 | 1.21 | |
| `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | |
| `GRPCContainerProbe` | `false` | 알파 | 1.23 | |
| `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | |
| `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | 1.23 |
| `GracefulNodeShutdownBasedOnPodPriority` | `true` | 베타 | 1.24 | |
| `GRPCContainerProbe` | `false` | 알파 | 1.23 | 1.23 |
| `GRPCContainerProbe` | `true` | 베타 | 1.24 | |
| `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | |
| `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
| `HPAScaleToZero` | `false` | 알파 | 1.16 | |
| `IdentifyPodOS` | `false` | 알파 | 1.23 | |
| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 |
| `IndexedJob` | `true` | 베타 | 1.22 | |
| `IdentifyPodOS` | `false` | 알파 | 1.23 | 1.23 |
| `IdentifyPodOS` | `true` | 베타 | 1.24 | |
| `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginAzureDiskUnregister` | `false` | 알파 | 1.21 | |
| `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | |
@ -145,42 +129,44 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `InTreePluginRBDUnregister` | `false` | 알파 | 1.23 | |
| `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | |
| `JobMutableNodeSchedulingDirectives` | `true` | 베타 | 1.23 | |
| `JobReadyPods` | `false` | 알파 | 1.23 | |
| `JobReadyPods` | `false` | 알파 | 1.23 | 1.23 |
| `JobReadyPods` | `true` | 베타 | 1.24 | |
| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | 1.22 |
| `JobTrackingWithFinalizers` | `true` | 베타 | 1.23 | |
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
| `JobTrackingWithFinalizers` | `true` | 베타 | 1.23 | 1.23 |
| `JobTrackingWithFinalizers` | `false` | 베타 | 1.24 | |
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | 1.23 |
| `KubeletCredentialProviders` | `true` | 베타 | 1.24 | |
| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | 베타 | 1.15 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | 1.22 |
| `KubeletPodResourcesGetAllocatable` | `false` | 베타 | 1.23 | |
| `KubeletPodResourcesGetAllocatable` | `true` | 베타 | 1.23 | |
| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 |
| `LogarithmicScaleDown` | `true` | 베타 | 1.22 | |
| `MaxUnavailableStatefulSet` | `false` | 알파 | 1.24 | |
| `MemoryManager` | `false` | 알파 | 1.21 | 1.21 |
| `MemoryManager` | `true` | 베타 | 1.22 | |
| `MemoryQoS` | `false` | 알파 | 1.22 | |
| `MixedProtocolLBService` | `false` | 알파 | 1.20 | |
| `MinDomainsInPodTopologySpread` | `false` | 알파 | 1.24 | |
| `MixedProtocolLBService` | `false` | 알파 | 1.20 | 1.23 |
| `MixedProtocolLBService` | `true` | 베타 | 1.24 | |
| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | 1.21 |
| `NetworkPolicyEndPort` | `true` | 베타 | 1.22 | |
| `NetworkPolicyStatus` | `false` | 알파 | 1.24 | |
| `NodeSwap` | `false` | 알파 | 1.22 | |
| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
| `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
| `OpenAPIEnums` | `false` | 알파 | 1.23 | |
| `OpenAPIV3` | `false` | 알파 | 1.23 | |
| `NodeOutOfServiceVolumeDetach` | `false` | 알파 | 1.24 | |
| `OpenAPIEnums` | `false` | 알파 | 1.23 | 1.23 |
| `OpenAPIEnums` | `true` | 베타 | 1.24 | |
| `OpenAPIV3` | `false` | 알파 | 1.23 | 1.23 |
| `OpenAPIV3` | `true` | 베타 | 1.24 | |
| `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | |
| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 |
| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | |
| `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 |
| `PodDeletionCost` | `true` | 베타 | 1.22 | |
| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
| `PodOverhead` | `true` | 베타 | 1.18 | |
| `PodSecurity` | `false` | 알파 | 1.22 | 1.22 |
| `PodSecurity` | `true` | 베타 | 1.23 | |
| `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 |
| `PreferNominatedNode` | `true` | 베타 | 1.22 | |
| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 |
| `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | |
| `ProcMountType` | `false` | 알파 | 1.12 | |
@ -190,17 +176,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `RecoverVolumeExpansionFailure` | `false` | 알파 | 1.23 | |
| `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 |
| `RemainingItemCount` | `true` | 베타 | 1.16 | |
| `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 |
| `RemoveSelfLink` | `true` | 베타 | 1.20 | |
| `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
| `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
| `SeccompDefault` | `false` | 알파 | 1.22 | |
| `ServerSideFieldValidation` | `false` | 알파 | 1.23 | - |
| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | 1.21 |
| `ServiceInternalTrafficPolicy` | `true` | 베타 | 1.22 | |
| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.21 |
| `ServiceLBNodePortControl` | `true` | 베타 | 1.22 | |
| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | 1.21 |
| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | |
| `ServiceIPStaticSubrange` | `false` | 알파 | 1.24 | |
| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 |
| `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | |
| `StatefulSetAutoDeletePVC` | `false` | 알파 | 1.22 | |
@ -209,10 +191,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `StorageVersionAPI` | `false` | 알파 | 1.20 | |
| `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | 베타 | 1.15 | |
| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 |
| `SuspendJob` | `true` | 베타 | 1.22 | |
| `TopologyAwareHints` | `false` | 알파 | 1.21 | 1.22 |
| `TopologyAwareHints` | `false` | 베타 | 1.23 | |
| `TopologyAwareHints` | `false` | 베타 | 1.23 | 1.23 |
| `TopologyAwareHints` | `true` | 베타 | 1.24 | |
| `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
| `TopologyManager` | `true` | 베타 | 1.18 | |
| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
@ -220,7 +201,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
| `WinOverlay` | `true` | 베타 | 1.20 | |
| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | 1.22 |
| `WindowsHostProcessContainers` | `false` | 베타 | 1.23 | |
| `WindowsHostProcessContainers` | `true` | 베타 | 1.23 | |
{{< /table >}}
### GA 또는 사용 중단된 기능을 위한 기능 게이트
@ -230,19 +211,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| 기능 | 디폴트 | 단계 | 도입 | 종료 |
|---------|---------|-------|-------|-------|
| `Accelerators` | `false` | 알파 | 1.6 | 1.10 |
| `Accelerators` | - | 사용중단 | 1.11 | - |
| `Accelerators` | - | Deprecated | 1.11 | - |
| `AdvancedAuditing` | `false` | 알파 | 1.7 | 1.7 |
| `AdvancedAuditing` | `true` | 베타 | 1.8 | 1.11 |
| `AdvancedAuditing` | `true` | GA | 1.12 | - |
| `AffinityInAnnotations` | `false` | 알파 | 1.6 | 1.7 |
| `AffinityInAnnotations` | - | 사용중단 | 1.8 | - |
| `AffinityInAnnotations` | - | Deprecated | 1.8 | - |
| `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 |
| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 |
| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 |
| `AttachVolumeLimit` | `true` | GA | 1.17 | - |
| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | 1.21 |
| `BalanceAttachedNodeVolumes` | `false` | 사용중단 | 1.22 | |
| `BalanceAttachedNodeVolumes` | `false` | Deprecated | 1.22 | |
| `BlockVolume` | `false` | 알파 | 1.9 | 1.12 |
| `BlockVolume` | `true` | 베타 | 1.13 | 1.17 |
| `BlockVolume` | `true` | GA | 1.18 | - |
@ -251,7 +232,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - |
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 |
| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | |
| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | - |
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 |
| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | 1.23 |
| `ControllerManagerLeaderMigration` | `true` | GA | 1.24 | - |
| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 |
| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 |
| `CRIContainerLogRotation` | `true` | GA | 1.21 | - |
@ -260,34 +244,47 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `CSIBlockVolume` | `true` | GA | 1.18 | - |
| `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 |
| `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 |
| `CSIDriverRegistry` | `true` | GA | 1.18 | |
| `CSIDriverRegistry` | `true` | GA | 1.18 | - |
| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationAWSComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationAWSComplete` | - | Deprecated | 1.21 | - |
| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | 1.22 |
| `CSIMigrationAzureDisk` | `true` | 베타 | 1.23 | 1.23 |
| `CSIMigrationAzureDisk` | `true` | GA | 1.24 | |
| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationAzureDiskComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationAzureDiskComplete` | - | Deprecated | 1.21 | - |
| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationAzureFileComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationAzureFileComplete` | - | Deprecated | 1.21 | - |
| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationGCEComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationGCEComplete` | - | Deprecated | 1.21 | - |
| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 |
| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | 1.23 |
| `CSIMigrationOpenStack` | `true` | GA | 1.24 | |
| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | 1.20 |
| `CSIMigrationOpenStackComplete` | - | 사용중단 | 1.21 | - |
| `CSIMigrationOpenStackComplete` | - | Deprecated | 1.21 | - |
| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | 1.21 |
| `CSIMigrationvSphereComplete` | - | 사용중단 | 1.22 | - |
| `CSIMigrationvSphereComplete` | - | Deprecated | 1.22 | - |
| `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 |
| `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 |
| `CSINodeInfo` | `true` | GA | 1.17 | |
| `CSINodeInfo` | `true` | GA | 1.17 | - |
| `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 |
| `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 |
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 |
| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | 1.21 |
| `CSIServiceAccountToken` | `true` | GA | 1.22 | |
| `CSIServiceAccountToken` | `true` | GA | 1.22 | - |
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | 베타 | 1.21 | 1.23 |
| `CSIStorageCapacity` | `true` | GA | 1.24 | - |
| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 |
| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 |
| `CSIVolumeFSGroupPolicy` | `true` | GA | 1.23 | |
| `CSRDuration` | `true` | 베타 | 1.22 | 1.23 |
| `CSRDuration` | `true` | GA | 1.24 | - |
| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 |
| `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 |
| `CronJobControllerV2` | `true` | GA | 1.22 | - |
| `CronJobTimeZone` | `false` | 알파 | 1.24 | |
| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 |
| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 |
| `CustomPodDNS` | `true` | GA | 1.14 | - |
@ -306,25 +303,31 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 |
| `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 |
| `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - |
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | 1.23 |
| `DefaultPodTopologySpread` | `true` | GA | 1.24 | - |
| `DryRun` | `false` | 알파 | 1.12 | 1.12 |
| `DryRun` | `true` | 베타 | 1.13 | 1.18 |
| `DryRun` | `true` | GA | 1.19 | - |
| `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 |
| `DynamicAuditing` | - | 사용중단 | 1.19 | - |
| `DynamicAuditing` | - | Deprecated | 1.19 | - |
| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 |
| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - |
| `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
| `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - |
| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - |
| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 |
| `EfficientWatchResumption` | `true` | 베타 | 1.21 | 1.23 |
| `EfficientWatchResumption` | `true` | GA | 1.24 | - |
| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - |
| `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 |
| `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - |
| `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - |
| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 |
| `EndpointSlice` | `false` | 베타 | 1.17 | 1.17 |
| `EndpointSlice` | `true` | 베타 | 1.18 | 1.20 |
| `EndpointSlice` | `true` | GA | 1.21 | - |
| `EndpointSlice` | `true` | GA | 1.21 | - |
| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.20 |
| `EndpointSliceNodeName` | `true` | GA | 1.21 | - |
| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
@ -334,8 +337,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 |
| `EvenPodsSpread` | `true` | GA | 1.19 | - |
| `ExecProbeTimeout` | `true` | GA | 1.20 | - |
| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 |
| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | 1.23 |
| `ExpandCSIVolumes` | `true` | GA | 1.24 | - |
| `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 |
| `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | 1.23 |
| `ExpandInUsePersistentVolumes` | `true` | GA | 1.24 | - |
| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 |
| `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | 1.23 |
| `ExpandPersistentVolumes` | `true` | GA | 1.24 |- |
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
| `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - |
| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
@ -349,47 +361,60 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `HugePages` | `true` | 베타| 1.10 | 1.13 |
| `HugePages` | `true` | GA | 1.14 | - |
| `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 |
| `HyperVContainer` | `false` | 사용중단 | 1.20 | - |
| `HyperVContainer` | `false` | Deprecated | 1.20 | - |
| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 |
| `IPv6DualStack` | `true` | 베타 | 1.21 | 1.22 |
| `IPv6DualStack` | `true` | GA | 1.23 | - |
| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | 1.20 |
| `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | |
| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 |
| `IndexedJob` | `true` | 베타 | 1.22 | 1.23 |
| `IndexedJob` | `true` | GA | 1.24 | - |
| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 |
| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | 1.22 |
| `IngressClassNamespacedParams` | `true` | GA | 1.23 | - |
| `Initializers` | `false` | 알파 | 1.7 | 1.13 |
| `Initializers` | - | 사용중단 | 1.14 | - |
| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 |
| `IPv6DualStack` | `true` | 베타 | 1.21 | 1.22 |
| `IPv6DualStack` | `true` | GA | 1.23 | - |
| `Initializers` | - | Deprecated | 1.14 | - |
| `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 |
| `KubeletConfigFile` | - | 사용중단 | 1.10 | - |
| `KubeletConfigFile` | - | Deprecated | 1.10 | - |
| `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 |
| `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 |
| `KubeletPluginsWatcher` | `true` | GA | 1.13 | - |
| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 |
| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - |
| `LegacyServiceAccountTokenNoAutoGeneration` | `true` | 베타 | 1.24 | |
| `MountContainers` | `false` | 알파 | 1.9 | 1.16 |
| `MountContainers` | `false` | 사용중단 | 1.17 | - |
| `MountContainers` | `false` | Deprecated | 1.17 | - |
| `MountPropagation` | `false` | 알파 | 1.8 | 1.9 |
| `MountPropagation` | `true` | 베타 | 1.10 | 1.11 |
| `MountPropagation` | `true` | GA | 1.12 | - |
| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 |
| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - |
| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 |
| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - |
| `NodeLease` | `false` | 알파 | 1.12 | 1.13 |
| `NodeLease` | `true` | 베타 | 1.14 | 1.16 |
| `NodeLease` | `true` | GA | 1.17 | - |
| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 |
| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - |
| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
| `NonPreemptingPriority` | `true` | 베타 | 1.19 | 1.23 |
| `NonPreemptingPriority` | `true` | GA | 1.24 | - |
| `PVCProtection` | `false` | 알파 | 1.9 | 1.9 |
| `PVCProtection` | - | 사용중단 | 1.10 | - |
| `PVCProtection` | - | Deprecated | 1.10 | - |
| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 |
| `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 |
| `PersistentLocalVolumes` | `true` | GA | 1.14 | - |
| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 |
| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | 1.23 |
| `PodAffinityNamespaceSelector` | `true` | GA | 1.24 | - |
| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 |
| `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 |
| `PodDisruptionBudget` | `true` | GA | 1.21 | - |
| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
| `PodOverhead` | `true` | 베타 | 1.18 | 1.23 |
| `PodOverhead` | `true` | GA | 1.24 | - |
| `PodPriority` | `false` | 알파 | 1.8 | 1.10 |
| `PodPriority` | `true` | 베타 | 1.11 | 1.13 |
| `PodPriority` | `true` | GA | 1.14 | - |
@ -399,10 +424,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `PodShareProcessNamespace` | `false` | 알파 | 1.10 | 1.11 |
| `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 |
| `PodShareProcessNamespace` | `true` | GA | 1.17 | - |
| `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 |
| `PreferNominatedNode` | `true` | 베타 | 1.22 | 1.23 |
| `PreferNominatedNode` | `true` | GA | 1.24 | - |
| `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 |
| `RemoveSelfLink` | `true` | 베타 | 1.20 | 1.23 |
| `RemoveSelfLink` | `true` | GA | 1.24 | - |
| `RequestManagement` | `false` | 알파 | 1.15 | 1.16 |
| `RequestManagement` | - | 사용중단 | 1.17 | - |
| `RequestManagement` | - | Deprecated | 1.17 | - |
| `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 |
| `ResourceLimitsPriorityFunction` | - | 사용중단 | 1.19 | - |
| `ResourceLimitsPriorityFunction` | - | Deprecated | 1.19 | - |
| `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 |
| `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 |
| `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - |
@ -434,6 +465,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 |
| `ServiceAppProtocol` | `true` | 베타 | 1.19 | 1.19 |
| `ServiceAppProtocol` | `true` | GA | 1.20 | - |
| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.21 |
| `ServiceLBNodePortControl` | `true` | 베타 | 1.22 | 1.23 |
| `ServiceLBNodePortControl` | `true` | GA | 1.24 | - |
| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | 1.21 |
| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | 1.23 |
| `ServiceLoadBalancerClass` | `true` | GA | 1.24 | - |
| `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 |
| `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 |
| `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
@ -441,7 +478,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 |
| `ServiceNodeExclusion` | `true` | GA | 1.21 | - |
| `ServiceTopology` | `false` | 알파 | 1.17 | 1.19 |
| `ServiceTopology` | `false` | 사용중단 | 1.20 | - |
| `ServiceTopology` | `false` | Deprecated | 1.20 | - |
| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 |
| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | 1.21 |
| `SetHostnameAsFQDN` | `true` | GA | 1.22 | - |
@ -452,8 +489,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.17 |
| `StreamingProxyRedirects` | `true` | 사용중단 | 1.18 | 1.21 |
| `StreamingProxyRedirects` | `false` | 사용중단 | 1.22 | - |
| `StreamingProxyRedirects` | `true` | Deprecated | 1.18 | 1.21 |
| `StreamingProxyRedirects` | `false` | Deprecated | 1.22 | - |
| `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 |
| `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 |
| `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 |
@ -464,8 +501,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 |
| `SupportPodPidsLimit` | `true` | 베타 | 1.14 | 1.19 |
| `SupportPodPidsLimit` | `true` | GA | 1.20 | - |
| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 |
| `SuspendJob` | `true` | 베타 | 1.22 | 1.23 |
| `SuspendJob` | `true` | GA | 1.24 | - |
| `Sysctls` | `true` | 베타 | 1.11 | 1.20 |
| `Sysctls` | `true` | GA | 1.21 | |
| `Sysctls` | `true` | GA | 1.21 | - |
| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 |
| `TTLAfterFinished` | `true` | 베타 | 1.21 | 1.22 |
| `TTLAfterFinished` | `true` | GA | 1.23 | - |
@ -483,7 +523,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
| `TokenRequestProjection` | `true` | GA | 1.20 | - |
| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | 1.21 |
| `ValidateProxyRedirects` | `true` | 사용중단 | 1.22 | - |
| `ValidateProxyRedirects` | `true` | Deprecated | 1.22 | - |
| `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 |
| `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 |
| `VolumePVCDataSource` | `true` | GA | 1.18 | - |
@ -567,7 +607,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
플러그인의 초기 형태를 제공하였으며, 사용 중단되었다.
대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
확인한다.
- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다.
- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug/debug-cluster/audit/#advanced-audit) 기능을 활성화한다.
- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
설정을 활성화한다.
- `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다.
@ -579,48 +619,58 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다.
- `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
대한 제한을 보고하도록 한다.
자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다.
자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을
참고한다.
- `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를
포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가
더 가까운 노드가 선호된다.
- `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다.
자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
참고한다.
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을
마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
`kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
확인한다.
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록
서비스어카운트 볼륨을 마이그레이션한다.
클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다.
이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
`kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다.
- `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가
kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면,
cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록
[kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의
[kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와
[cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의
리더 마이그레이션(Leader Migration)을 활성화한다.
- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
[CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 미세 조정을 허용한다.
- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의
미세 조정을 허용한다.
이 기능 게이트는 품질 수준이 알파인 CPUManager 옵션의 *그룹*을 보호한다.
이 기능 게이트는 베타 또는 안정(stable) 상태로 변경되지 않을 것이다.
- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 미세 조정을 허용한다.
- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의
미세 조정을 허용한다.
이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다.
이 기능 게이트는 안정(stable) 상태로 변경되지 않을 것이다.
- `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다.
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다.
더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다.
로그 파일 사이즈 기본값은 10MB이며,
컨테이너 당 최대 로그 파일 수 기본값은 5이다.
이 값은 kubelet 환경설정으로 변경할 수 있다.
더 자세한 내용은
[노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다.
자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)
문서를 참고한다.
자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)을
참고한다.
- `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된
모든 로직을 활성화한다.
- `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다.
- `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서
사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다.
- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을
AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에
EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로
폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다.
- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을
AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
이 기능이 비활성화되어 있거나 EBS CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다.
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
- `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리
플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS
인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
@ -630,21 +680,26 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
더 이상 사용되지 않는다.
- `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리
AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가
필요하다.
- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리
플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로
라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능
플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어
있어야 한다. 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 `InTreePluginAzureDiskUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
인-트리 AzureDisk 플러그인으로의 폴백(falling back)을 지원한다.
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서
Azure-Disk 인-트리 플러그인 등록을 중지하고
shim 및 변환 로직을 사용하여
볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고
AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는
`InTreePluginAzureDiskUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다.
- `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을
Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다.
노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가
필요하다.
이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
인-트리 AzureFile 플러그인으로의 폴백(falling back)을 지원한다.
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
- `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리
플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을
Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로
@ -654,46 +709,57 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
`InTreePluginAzureFileUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
지원한다. CSIMigration 기능 플래그가 필요하다.
- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다.
이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는
`InTreePluginRBDUnregister` 기능 플래그에 의해
사용 중단되었다.
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
이 기능이 비활성화되어 있거나 PD CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
인-트리 GCE 플러그인으로의 폴백(falling back)을 지원한다.
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
- `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD
인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD
인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI
플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해
플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을
Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에
Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다.
이 기능이 비활성화되어 있거나 Cinder CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
인-트리 Cinder 플러그인으로의 폴백(falling back)을 지원한다.
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
- `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서
Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리
플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다.
클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고
Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해
Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다.
이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 `InTreePluginRBDUnregister` 기능 플래그에 의해
사용 중단되었다.
- `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을
라우팅하는 shim 및 변환 로직을 사용한다.
노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우
인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
이 기능이 비활성화되어 있거나 vSphere CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
인-트리 vSphere 플러그인으로의 폴백(falling back)을 지원한다.
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
- `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리
플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서
vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및
CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이
클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해
클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해
더 이상 사용되지 않는다.
- `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
Portworx CSI 드라이버가 설치 및 설정되어 있어야 하며, kube-controller-manager와 kubelet 환경 설정 내에 `CSIMigrationPortworx=true` 기능 게이트가 활성화되어 있어야 한다.
- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다.
- `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
마운트할 수 있다.
@ -714,14 +780,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은
[파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을
참고한다.
- `ContextualLogging`: 이 기능을 활성화하면,
컨텍스츄얼 로깅을 지원하는 쿠버네티스 구성 요소가 로그 출력에 추가 상세를 추가한다.
- `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에
대한 리더 마이그레이션을 지원한다.
- `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}}
컨트롤러의 대체 구현을 사용한다. 그렇지 않으면,
동일한 컨트롤러의 버전 1이 선택된다.
- `CronJobTimeZone`: [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)의 선택적 `timeZone` 필드 사용을 허용한다.
- `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서
`cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다.
- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 검증 규칙을 기반으로 커스텀 리소스를 검증하는 표현 언어 검증(expression language validation)을 CRD에 활성화한다.
- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된
검증 규칙을 기반으로 커스텀 리소스를 검증하는
표현 언어 검증(expression language validation)을 CRD에 활성화한다.
- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을
확인한다.
@ -755,8 +826,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
- `DynamicAuditing`: v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다.
[kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다.
- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다.
이 기능은 지원하는 버전 차이(supported skew policy) 바깥에서는 더 이상 지원되지 않는다.
이 기능 게이트는 1.24에 kubelet에서 제거되었다. [kubelet 재구성하기](/docs/tasks/administer-cluster/reconfigure-kubelet/)를 참고한다.
- `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록
기본 스케줄러를 확장한다.
이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다.
@ -804,12 +876,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을
사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
재 매핑이 활성화된 경우에만 활성화해야 한다.
- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다.
- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는
버그를 수정한다.
- `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인
볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원
등에서 제공할 수 있음).
[임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
[임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/)을 참고한다.
- `GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다.
시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행 중인
파드를 정상적으로 종료하려고 시도한다. 자세한 내용은
@ -817,8 +890,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
참조한다.
- `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때
kubelet이 파드 우선순위를 체크할 수 있도록 활성화한다.
- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다.
- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다.
[활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다.
- `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 PV-PVC 삭제 순서와 상관없이 정책을 준수한다.
더 자세한 정보는
[퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer)](/ko/docs/concepts/storage/persistent-volumes/#persistentvolume-deletion-protection-finalizer) 문서를
참고한다.
- `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의
개별 컨테이너 메트릭을 기반으로 확장한다.
- `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해
@ -830,10 +907,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
- `HyperVContainer`: 윈도우 컨테이너를 위한
[Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)
기능을 활성화한다.
- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다.
쿠버네티스 {{< skew currentVersion >}}에서, `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다.
- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다.
이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다.
쿠버네티스 {{< skew currentVersion >}}에서,
`pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다.
- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
변경할 수 없는(immutable) 것으로 표시할 수 있다.
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를
완료 인덱스에 따라 관리할 수 있도록 허용한다.
- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가
`IngressClass` 리소스를 참조할 수 있도록 허용한다.
이 기능은 `IngressClass.spec.parameters`에 `Scope` 및 `Namespace`의 2 필드를 추가한다.
- `Initializers`: Initializers 어드미션 플러그인을 사용하여,
오브젝트 생성 시 비동기 협조(asynchronous coordination)를 허용한다.
- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리
플러그인의 등록을 중지한다.
- `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리
@ -850,13 +936,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
플러그인의 등록을 중지한다.
- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리
플러그인의 등록을 중지한다.
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다.
- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로
한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에
`Scope` 와 `Namespace` 2개의 필드를 추가한다.
- `Initializers`: Initializers 어드미션 플러그인을 사용하여 오브젝트 생성의
비동기 조정을 허용한다.
- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
기능을 활성화한다.
- `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의
@ -874,20 +953,26 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
kubelet 구성을 로드할 수 있다.
자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
참고한다.
- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
- `KubeletInUserNamespace`: {{<glossary_tooltip text="user namespace" term_id="userns">}}에서 kubelet 실행을 활성화한다.
- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해
kubelet exec 자격 증명 공급자를 활성화한다.
- `KubeletInUserNamespace`: {{<glossary_tooltip text="user namespace" term_id="userns">}}에서
kubelet 실행을 활성화한다.
[루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다.
- `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은
플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
- `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은
[장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을
참고한다.
- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 `GetAllocatableResources` 기능을 활성화한다.
이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를
- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스
`GetAllocatableResources` 기능을 활성화한다.
이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록,
할당 가능 자원에 대한 정보를
[자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다.
- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은
`NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여
`node-role.kubernetes.io/master` 레이블을 무시한다.
- `LegacyServiceAccountTokenNoAutoGeneration`: 시크릿 기반
[서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)의 자동 생성을 중단한다.
- `LocalStorageCapacityIsolation`:
[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와
[emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의
@ -901,20 +986,34 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
향상시킨다.
- `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여
축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다.
- `MaxUnavailableStatefulSet`: 스테이트풀셋의
[롤링 업데이트 전략](/ko/docs/concepts/workloads/controllers/statefulset/#롤링-업데이트)에 대해
`maxUnavailable` 필드를 설정할 수 있도록 한다.
이 필드는 업데이트 동안 사용 불가능(unavailable) 상태의 파드를 몇 개까지 허용할지를 정한다.
- `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한
메모리 어피니티를 설정할 수 있다.
- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다.
- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여
파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다.
- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/) 내의
`minDomains` 사용을 활성화한다.
- `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
사용을 활성화한다.
- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
- `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
- `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable)
{{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. (네임스페이스의 이름도 변경 불가)
- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다.
{{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다.
(네임스페이스의 이름도 변경 불가)
- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에
포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다.
- `NetworkPolicyStatus`: 네트워크폴리시 오브젝트에 대해 `status` 서브리소스를 활성화한다.
- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption`
사용을 활성화한다.
- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
- `NodeOutOfServiceVolumeDetach`: 노드가 `node.kubernetes.io/out-of-service` 테인트를 사용하여 서비스 불가(out-of-service)로 표시되면,
노드에 있던 이 테인트를 허용하지 않는 파드는 강제로 삭제되며,
종료되는 파드에 대한 볼륨 해제(detach) 동작도 즉시 수행된다.
이로 인해 삭제된 파드가 다른 노드에서 빠르게 복구될 수 있다.
- `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다.
반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
@ -922,8 +1021,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
- `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의
"enum" 필드 채우기를 활성화한다.
- `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
삭제되지 않도록 한다.
- `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록,
[파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다.
- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다.
@ -931,8 +1028,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
- `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라
CRI 컨테이너 런타임으로부터 수집하도록 설정한다.
- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다.
- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과
[CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다.
- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터)
기능과
[CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터)
쿼터 범위 기능을 활성화한다.
- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
기능을 활성화한다.
- `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를
@ -948,12 +1047,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
지정된 노드를 먼저 검사할지 여부를
스케줄러에 알려준다.
- `ProbeTerminationGracePeriod`: 파드의 [프로브-수준
`terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다.
`terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds)
기능을 활성화한다.
더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다.
- `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여
컨테이너의 proc 타입의 마운트를 제어할 수 있다.
- `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록
kube-proxy를 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
삭제되지 않도록 한다.
- `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가
더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다
(현재 메모리만 해당).
@ -966,8 +1068,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
- `RemainingItemCount`: API 서버가
[청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한
응답에서 남은 항목 수를 표시하도록 허용한다.
- `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고
제거한다.
- `RemoveSelfLink`: 모든 오브젝트와 콜렉션에 대해 `.metadata.selfLink` 필드를 빈 칸(빈 문자열)으로 설정한다.
이 필드는 쿠버네티스 v1.16에서 사용 중단되었다.
이 기능을 활성화하면, `.metadata.selfLink` 필드는 쿠버네티스 API에 존재하지만,
항상 빈 칸으로 유지된다.
- `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을
관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다.
- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중
@ -982,7 +1086,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
[바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
참조한다.
- `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
자세한 내용은
[kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
- `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
자세한 사항은
[kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다.
@ -994,12 +1099,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
스케줄링할 수 있다.
- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서
_SCTP_ `protocol` 값을 활성화한다.
- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 `RuntimeDefault`을 사용한다.
- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로
`RuntimeDefault`을 사용한다.
seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다.
- `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여
목록 작업을 가속화할 수 있다.
- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/)
경로를 활성화한다.
- `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다.
이는 리소스 스키마의 검증이 클라이언트 사이드(예: `kubectl create` 또는 `kubectl apply` 명령줄)가 아니라
API 서버 사이드에서 수행됨을 의미한다.
- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및
JWKS URL)를 활성화한다. 자세한 내용은
[파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을
@ -1007,7 +1116,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다.
- `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다.
- `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다.
- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 자세한 내용은
- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다.
자세한 내용은
[로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다.
- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
- `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를
@ -1017,6 +1127,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
있도록 한다. 자세한 내용은
[서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를
참고한다.
- `ServiceIPStaticSubrange`: ClusterIP 범위를 분할하는
서비스 ClusterIP 할당 전략을 활성화한다.
ClusterIP 동적 할당을 주로 상위 범위에서 수행하여,
사용자가 고정 ClusterIP를 하위 범위에서 할당하는 상황에서도 충돌 확률을 낮출 수 있다.
더 자세한 사항은
[충돌 방지](/ko/docs/concepts/services-networking/service/#avoiding-collisions)를 참고한다.
- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로
설정하는 기능을 활성화한다.
[파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다.
@ -1064,7 +1180,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
서비스 어카운트 토큰을 파드에 주입할 수 있다.
- `TopologyAwareHints`: 엔드포인트슬라이스(EndpointSlices)에서 토폴로지 힌트 기반
토폴로지-어웨어 라우팅을 활성화한다. 자세한 내용은
[토폴로지 어웨어 힌트](/docs/concepts/services-networking/topology-aware-hints/)
[토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)
를 참고한다.
- `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스
할당을 조정하는 메커니즘을 활성화한다.
@ -1103,3 +1219,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
* [사용 중단 정책](/docs/reference/using-api/deprecation-policy/)은 쿠버네티스에 대한
기능과 컴포넌트를 제거하는 프로젝트의 접근 방법을 설명한다.
* 쿠버네티스 1.24부터, 새로운 베타 API는 기본적으로 활성화되어 있지 않다.
베타 기능을 활성화하려면, 연관된 API 리소스도 활성화해야 한다.
예를 들어, `storage.k8s.io/v1beta1/csistoragecapacities`와 같은 특정 리소스를 활성화하려면,
`--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`를 설정한다.
명령줄 플래그에 대한 상세 사항은 [API 버전 규칙](/ko/docs/reference/using-api/#api-버전-규칙)을 참고한다.

6
content/ko/docs/reference/glossary/api-eviction.md
View File

@ -10,7 +10,6 @@ aka:
tags:
- operation
---
API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)를 사용하여
생성된 `Eviction` 오브젝트로 파드를 정상 종료한다.
@ -20,4 +19,9 @@ API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api
축출 API를 직접 호출해 축출 요청을 할 수 있다.
`Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다.
API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및
[`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 값을 준수한다.
API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다.
* 더 많은 정보는 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을 참고한다.

2
content/ko/docs/reference/glossary/container-runtime-interface.md
View File

@ -18,5 +18,5 @@ Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜
쿠버네티스 컨테이너 런타임 인터페이스(CRI)는
[클러스터 컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}과
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} 사이의
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} 사이의
통신을 위한 주요 [gRPC](https://grpc.io) 프로토콜을 정의한다.

9
content/ko/docs/reference/glossary/kubectl.md
View File

@ -4,16 +4,19 @@ id: kubectl
date: 2018-04-12
full_link: /docs/user-guide/kubectl-overview/
short_description: >
쿠버네티스 API 서버와 통신하기 위한 커맨드라인 툴.
쿠버네티스 클러스터와 통신하기 위한 커맨드라인 툴.
aka:
- kubectl
tags:
- tool
- fundamental
---
{{< glossary_tooltip text="쿠버네티스 API" term_id="kubernetes-api" >}} 서버와 통신하기 위한 커맨드라인 툴.
쿠버네티스 API를 사용하여
쿠버네티스 클러스터의 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}과
통신하기 위한 커맨드라인 툴
<!--more-->
사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 kubectl를 사용할 수 있다.
사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 `kubectl`을 사용할 수 있다.

4
content/ko/docs/reference/glossary/namespace.md
View File

@ -2,9 +2,9 @@
title: 네임스페이스(Namespace)
id: namespace
date: 2018-04-12
full_link: /ko/docs/concepts/overview/working-with-objects/namespaces
full_link: /ko/docs/concepts/overview/working-with-objects/namespaces/
short_description: >
쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화.
쿠버네티스에서, 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상화.
aka:
tags:

3
content/ko/docs/reference/glossary/pod-security-policy.md
View File

@ -2,7 +2,7 @@
title: 파드 시큐리티 폴리시(Pod Security Policy)
id: pod-security-policy
date: 2018-04-12
full_link: /ko/docs/concepts/policy/pod-security-policy/
full_link: /ko/docs/concepts/security/pod-security-policy/
short_description: >
파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다.
@ -17,3 +17,4 @@ tags:
파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스. `PodSecurityPolicy` 오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다.
파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거될 예정이다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 또는 써드파티 어드미션 플러그인으로 이전(migrate)하는 것을 추천한다.

2
content/ko/docs/reference/issues-security/security.md
View File

@ -19,8 +19,6 @@ weight: 20
보안 및 주요 API 공지에 대한 이메일을 위해서는 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입한다.
[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드도 구독할 수 있다.
## 취약점 보고
우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다.

553
content/ko/docs/reference/kubectl/_index.md
View File

@ -1,5 +1,556 @@
---
title: "kubectl"
title: 명령줄 도구 (kubectl)
content_type: reference
weight: 60
no_list: true
card:
name: reference
weight: 20
---
<!-- overview -->
{{< glossary_definition prepend="쿠버네티스는 다음을 제공한다: " term_id="kubectl" length="short" >}}
이 툴의 이름은 `kubectl`이다.
구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다.
KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
파일을 지정할 수 있다.
이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다.
설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고하고,
빠른 가이드는 [치트 시트](/ko/docs/reference/kubectl/cheatsheet/)를 참고한다. `docker` 명령줄 도구에 익숙하다면,
[도커 사용자를 위한 `kubectl`](/ko/docs/reference/kubectl/docker-cli-to-kubectl/)에서 대응되는 쿠버네티스 명령어를 볼 수 있다.
<!-- body -->
## 구문
터미널 창에서 `kubectl` 명령을 실행하려면 다음의 구문을 사용한다.
```shell
kubectl [command] [TYPE] [NAME] [flags]
```
다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다.
* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다.
예: `create`, `get`, `describe`, `delete`
* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며
단수형, 복수형 또는 약어 형식을 지정할 수 있다.
예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
```shell
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
```
* `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods`
여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.
* 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다.
* 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. `TYPE1 name1 name2 name<#>`<br/>
예: `kubectl get pod example-pod1 example-pod2`
* 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`<br/>
예: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
* 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>`
* YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).<br/>
예: `kubectl get -f ./pod.yaml`
* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.<br/>
{{< caution >}}
커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다.
{{< /caution >}}
도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다.
## 클러스터 내 인증과 네임스페이스 오버라이드
기본적으로 `kubectl`은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 `KUBERNETES_SERVICE_HOST`와 `KUBERNETES_SERVICE_PORT` 환경 변수, 그리고 서비스 어카운트 토큰 파일이 `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다.
하위 호환성을 위해, 클러스터 내 인증 시에 `POD_NAMESPACE` 환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다.
**`POD_NAMESPACE` 환경 변수**
`POD_NAMESPACE` 환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 `seattle`로 설정되어 있으면, `kubectl get pods` 명령은 `seattle` 네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. `kubectl api-resources` 명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다.
명시적으로 `--namespace <value>` 인자를 사용하면 위와 같은 동작을 오버라이드한다.
**kubectl이 서비스어카운트 토큰을 관리하는 방법**
만약
* 쿠버네티스 서비스 어카운트 토큰 파일이
`/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 마운트되어 있고,
* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고,
* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고,
* kubectl 명령에 네임스페이스를 명시하지 않으면
kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다.
kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
이는 클러스터 외부에서 실행되었을 때와는 다른데,
kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우
kubectl은 `default` 네임스페이스에 대해 동작한다.
## 명령어
다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.
명령어 | 구문 | 설명
-------------------- | -------------------- | --------------------
`alpha` | `kubectl alpha SUBCOMMAND [flags]` | 쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다.
`annotate` | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다.
`api-resources` | `kubectl api-resources [flags]` | 사용 가능한 API 리소스를 나열한다.
`api-versions` | `kubectl api-versions [flags]` | 사용 가능한 API 버전을 나열한다.
`apply` | `kubectl apply -f FILENAME [flags]`| 파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다.
`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다.
`auth` | `kubectl auth [flags] [options]` | 승인을 검사한다.
`autoscale` | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | 레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다.
`certificate` | `kubectl certificate SUBCOMMAND [options]` | 인증서 리소스를 수정한다.
`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
`delete` | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | 파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다.
`describe` | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | 하나 이상의 리소스의 자세한 상태를 표시한다.
`diff` | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다.
`drain` | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다.
`edit` | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다.
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다.
`explain` | `kubectl explain [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다.
`expose` | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다.
`get` | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | 하나 이상의 리소스를 나열한다.
`kustomize` | `kubectl kustomize <dir> [flags] [options]` | kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다.
`label` | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 레이블을 추가하거나 업데이트한다.
`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 파드의 컨테이너에 대한 로그를 출력한다.
`options` | `kubectl options` | 모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다.
`patch` | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | 전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다.
`plugin` | `kubectl plugin [flags] [options]` | 플러그인과 상호 작용하기 위한 유틸리티를 제공한다.
`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 하나 이상의 로컬 포트를 파드로 전달한다.
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 쿠버네티스 API 서버에 프록시를 실행한다.
`replace` | `kubectl replace -f FILENAME` | 파일 또는 표준입력에서 리소스를 교체한다.
`rollout` | `kubectl rollout SUBCOMMAND [options]` | 리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다.
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 클러스터에서 지정된 이미지를 실행한다.
`scale` | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 지정된 레플리케이션 컨트롤러의 크기를 업데이트한다.
`set` | `kubectl set SUBCOMMAND [options]` | 애플리케이션 리소스를 구성한다.
`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 하나 이상의 노드에서 테인트(taint)를 업데이트한다.
`top` | `kubectl top [flags] [options]` | 리소스(CPU/메모리/스토리지) 사용량을 표시한다.
`uncordon` | `kubectl uncordon NODE [options]` | 노드를 스케줄 가능(schedulable)으로 표시한다.
`version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다.
`wait` | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다.
명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
## 리소스 타입
다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)
| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
|---|---|---|---|---|
| `bindings` | | | true | Binding |
| `componentstatuses` | `cs` | | false | ComponentStatus |
| `configmaps` | `cm` | | true | ConfigMap |
| `endpoints` | `ep` | | true | Endpoints |
| `events` | `ev` | | true | Event |
| `limitranges` | `limits` | | true | LimitRange |
| `namespaces` | `ns` | | false | Namespace |
| `nodes` | `no` | | false | Node |
| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
| `persistentvolumes` | `pv` | | false | PersistentVolume |
| `pods` | `po` | | true | Pod |
| `podtemplates` | | | true | PodTemplate |
| `replicationcontrollers` | `rc` | | true | ReplicationController |
| `resourcequotas` | `quota` | | true | ResourceQuota |
| `secrets` | | | true | Secret |
| `serviceaccounts` | `sa` | | true | ServiceAccount |
| `services` | `svc` | | true | Service |
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
| `apiservices` | | apiregistration.k8s.io | false | APIService |
| `controllerrevisions` | | apps | true | ControllerRevision |
| `daemonsets` | `ds` | apps | true | DaemonSet |
| `deployments` | `deploy` | apps | true | Deployment |
| `replicasets` | `rs` | apps | true | ReplicaSet |
| `statefulsets` | `sts` | apps | true | StatefulSet |
| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
| `cronjobs` | `cj` | batch | true | CronJob |
| `jobs` | | batch | true | Job |
| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
| `leases` | | coordination.k8s.io | true | Lease |
| `endpointslices` | | discovery.k8s.io | true | EndpointSlice |
| `events` | `ev` | events.k8s.io | true | Event |
| `ingresses` | `ing` | extensions | true | Ingress |
| `flowschemas` | | flowcontrol.apiserver.k8s.io | false | FlowSchema |
| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
| `ingressclasses` | | networking.k8s.io | false | IngressClass |
| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
| `runtimeclasses` | | node.k8s.io | false | RuntimeClass |
| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
| `roles` | | rbac.authorization.k8s.io | true | Role |
| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
| `csidrivers` | | storage.k8s.io | false | CSIDriver |
| `csinodes` | | storage.k8s.io | false | CSINode |
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
## 출력 옵션
특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
### 출력 서식화
모든 `kubectl` 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가할 수 있다.
#### 구문
```shell
kubectl [command] [TYPE] [NAME] -o <output_format>
```
`kubectl` 명령에 따라, 다음과 같은 출력 형식이 지원된다.
출력 형식 | 설명
--------------| -----------
`-o custom-columns=<spec>` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다.
`-o custom-columns-file=<filename>` | `<filename>` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다.
`-o json` | JSON 형식의 API 오브젝트를 출력한다.
`-o jsonpath=<template>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
`-o name` | 리소스 이름만 출력한다.
`-o wide` | 추가 정보가 포함된 일반 텍스트 형식으로 출력된다. 파드의 경우, 노드 이름이 포함된다.
`-o yaml` | YAML 형식의 API 오브젝트를 출력한다.
##### 예제
이 예제에서, 다음의 명령은 단일 파드에 대한 세부 정보를 YAML 형식의 오브젝트로 출력한다.
```shell
kubectl get pod web-pod-13je7 -o yaml
```
기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
[kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
#### 사용자 정의 열 {#custom-columns}
사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다.
사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
##### 예제
인라인:
```shell
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
```
템플릿 파일:
```shell
kubectl get pods <pod-name> -o custom-columns-file=template.txt
```
`template.txt` 파일에 포함된 내용은 다음과 같다.
```
NAME RSRC
metadata.name metadata.resourceVersion
```
두 명령 중 하나를 실행한 결과는 다음과 비슷하다.
```
NAME RSRC
submit-queue 610995
```
#### 서버측 열
`kubectl` 는 서버에서 오브젝트에 대한 특정 열 정보 수신을 지원한다.
이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다.
이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다.
이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면,
`kubectl get` 명령에 `--server-print=false` 플래그를 추가한다.
##### 예제
파드 상태에 대한 정보를 출력하려면, 다음과 같은 명령을 사용한다.
```shell
kubectl get pods <pod-name> --server-print=false
```
출력 결과는 다음과 비슷하다.
```
NAME AGE
pod-name 1m
```
### 오브젝트 목록 정렬
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
#### 구문
```shell
kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
```
##### 예제
이름별로 정렬된 파드 목록을 출력하려면, 다음을 실행한다.
```shell
kubectl get pods --sort-by=.metadata.name
```
## 예제: 일반적인 작업
다음 예제 세트를 사용하여 일반적으로 사용되는 `kubectl` 조작 실행에 익숙해진다.
`kubectl apply` - 파일 또는 표준입력에서 리소스를 적용하거나 업데이트한다.
```shell
# example-service.yaml의 정의를 사용하여 서비스를 생성한다.
kubectl apply -f example-service.yaml
# example-controller.yaml의 정의를 사용하여 레플리케이션 컨트롤러를 생성한다.
kubectl apply -f example-controller.yaml
# <directory> 디렉터리 내의 .yaml, .yml 또는 .json 파일에 정의된 오브젝트를 생성한다.
kubectl apply -f <directory>
```
`kubectl get` - 하나 이상의 리소스를 나열한다.
```shell
# 모든 파드를 일반 텍스트 출력 형식으로 나열한다.
kubectl get pods
# 모든 파드를 일반 텍스트 출력 형식으로 나열하고 추가 정보(예: 노드 이름)를 포함한다.
kubectl get pods -o wide
# 지정된 이름의 레플리케이션 컨트롤러를 일반 텍스트 출력 형식으로 나열한다. 팁: 'replicationcontroller' 리소스 타입을 'rc'로 짧게 바꿔쓸 수 있다.
kubectl get replicationcontroller <rc-name>
# 모든 레플리케이션 컨트롤러와 서비스를 일반 텍스트 출력 형식으로 함께 나열한다.
kubectl get rc,services
# 모든 데몬 셋을 일반 텍스트 출력 형식으로 나열한다.
kubectl get ds
# 노드 server01에서 실행 중인 모든 파드를 나열한다.
kubectl get pods --field-selector=spec.nodeName=server01
```
`kubectl describe` - 초기화되지 않은 리소스를 포함하여 하나 이상의 리소스의 기본 상태를 디폴트로 표시한다.
```shell
# 노드 이름이 <node-name>인 노드의 세부 사항을 표시한다.
kubectl describe nodes <node-name>
# 파드 이름이 <pod-name> 인 파드의 세부 정보를 표시한다.
kubectl describe pods/<pod-name>
# 이름이 <rc-name>인 레플리케이션 컨트롤러가 관리하는 모든 파드의 세부 정보를 표시한다.
# 기억하기: 레플리케이션 컨트롤러에서 생성된 모든 파드에는 레플리케이션 컨트롤러 이름이 접두사로 붙는다.
kubectl describe pods <rc-name>
# 모든 파드의 정보를 출력한다.
kubectl describe pods
```
{{< note >}}
`kubectl get` 명령은 일반적으로 동일한 리소스 타입의 하나 이상의
리소스를 검색하는 데 사용된다. 예를 들어, `-o` 또는 `--output` 플래그를
사용하여 출력 형식을 사용자 정의할 수 있는 풍부한 플래그 세트가 있다.
`-w` 또는 `--watch` 플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인할 수
있다. `kubectl describe` 명령은 지정된 리소스의 여러 관련 측면을
설명하는 데 더 중점을 둔다. API 서버에 대한 여러 API 호출을 호출하여
사용자에 대한 뷰(view)를 빌드할 수 있다. 예를 들어, `kubectl describe node`
명령은 노드에 대한 정보뿐만 아니라, 노드에서 실행 중인 파드의 요약 정보, 노드에 대해 생성된 이벤트 등의
정보도 검색한다.
{{< /note >}}
`kubectl delete` - 파일, 표준입력 또는 레이블 선택기, 이름, 리소스 선택기나 리소스를 지정하여 리소스를 삭제한다.
```shell
# pod.yaml 파일에 지정된 타입과 이름을 사용하여 파드를 삭제한다.
kubectl delete -f pod.yaml
# '<label-key>=<label-value>' 레이블이 있는 모든 파드와 서비스를 삭제한다.
kubectl delete pods,services -l <label-key>=<label-value>
# 초기화되지 않은 파드를 포함한 모든 파드를 삭제한다.
kubectl delete pods --all
```
`kubectl exec` - 파드의 컨테이너에 대해 명령을 실행한다.
```shell
# 파드 <pod-name>에서 'date'를 실행한 결과를 얻는다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec <pod-name> -- date
# 파드 <pod-name>의 <container-name> 컨테이너에서 'date'를 실행하여 출력 결과를 얻는다.
kubectl exec <pod-name> -c <container-name> -- date
# 파드 <pod-name>에서 대화식 TTY를 연결해 /bin/bash를 실행한다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec -ti <pod-name> -- /bin/bash
```
`kubectl logs` - 파드의 컨테이너에 대한 로그를 출력한다.
```shell
# 파드 <pod-name>에서 로그의 스냅샷을 반환한다.
kubectl logs <pod-name>
# 파드 <pod-name>에서 로그 스트리밍을 시작한다. 이것은 리눅스 명령 'tail -f'와 비슷하다.
kubectl logs -f <pod-name>
```
`kubectl diff` - 제안된 클러스터 업데이트의 차이점을 본다.
```shell
# "pod.json"에 포함된 리소스의 차이점을 출력한다.
kubectl diff -f pod.json
# 표준입력에서 파일을 읽어 차이점을 출력한다.
cat service.yaml | kubectl diff -f -
```
## 예제: 플러그인 작성 및 사용
`kubectl` 플러그인 작성과 사용에 익숙해지려면 다음의 예제 세트를 사용한다.
```shell
# 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로
# 시작하도록 실행 파일의 이름을 지정한다.
cat ./kubectl-hello
```
```shell
#!/bin/sh
# 이 플러그인은 "hello world"라는 단어를 출력한다
echo "hello world"
```
작성한 플러그인을 실행 가능하게 한다
```bash
chmod a+x ./kubectl-hello
# 그리고 PATH의 위치로 옮긴다
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# 이제 kubectl 플러그인을 만들고 "설치했다".
# kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다
kubectl hello
```
```
hello world
```
```shell
# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여,
# 플러그인을 "제거"할 수 있다
sudo rm /usr/local/bin/kubectl-hello
```
`kubectl` 에 사용할 수 있는 모든 플러그인을 보려면,
`kubectl plugin list` 하위 명령을 사용한다.
```shell
kubectl plugin list
```
출력 결과는 다음과 비슷하다.
```
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
```
`kubectl plugin list` 는 또한 실행 가능하지 않거나,
다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다.
```shell
sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거
kubectl plugin list
```
```
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
```
플러그인은 기존 kubectl 명령 위에 보다 복잡한 기능을
구축하는 수단으로 생각할 수 있다.
```shell
cat ./kubectl-whoami
```
다음 몇 가지 예는 이미 `kubectl-whoami` 에
다음 내용이 있다고 가정한다.
```shell
#!/bin/bash
# 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한
# 정보를 출력하기 위해 'kubectl config' 명령을 사용한다.
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
```
위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한
사용자가 포함된 출력이 제공된다.
```shell
# 파일을 실행 가능하게 한다
sudo chmod +x ./kubectl-whoami
# 그리고 PATH로 옮긴다
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
```
## {{% heading "whatsnext" %}}
* `kubectl` 레퍼런스 문서를 읽는다.
* kubectl [명령어 레퍼런스](/ko/docs/reference/kubectl/kubectl/)
* [명령줄 인자](/docs/reference/generated/kubectl/kubectl-commands/) 레퍼런스
* [`kubectl` 사용 규칙](/ko/docs/reference/kubectl/conventions/)에 대해 알아본다.
* kubectl의 [JSONPath 지원](/ko/docs/reference/kubectl/jsonpath/)에 대해 알아본다.
* [플러그인으로 kubectl 확장](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아본다.
* 플러그인에 대해 좀 더 알아보려면, [예시 CLI 플러그인](https://github.com/kubernetes/sample-cli-plugin)을 살펴본다.

54
content/ko/docs/reference/kubectl/cheatsheet.md
View File

@ -5,6 +5,7 @@ title: kubectl 치트 시트
content_type: concept
weight: 10 # highlight it
card:
name: reference
weight: 30
@ -38,6 +39,11 @@ complete -F __start_kubectl k
source <(kubectl completion zsh) # 현재 셸에 zsh의 자동 완성 설정
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.
```
### --all-namespaces 에 대한 노트
`--all-namespaces`를 붙여야 하는 상황이 자주 발생하므로, `--all-namespaces`의 축약형을 알아 두는 것이 좋다.
```kubectl -A```
## Kubectl 컨텍스트와 설정
@ -56,11 +62,11 @@ kubectl config view
# e2e 사용자의 암호를 확인한다
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
kubectl config view -o jsonpath='{.users[].name}' # 첫 번째 사용자 출력
kubectl config view -o jsonpath='{.users[].name}' # 첫 번째 사용자 출력
kubectl config view -o jsonpath='{.users[*].name}' # 사용자 리스트 조회
kubectl config get-contexts # 컨텍스트 리스트 출력
kubectl config current-context # 현재 컨텍스트 출력
kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정
kubectl config get-contexts # 컨텍스트 리스트 출력
kubectl config current-context # 현재 컨텍스트 출력
kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정
# 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
@ -73,6 +79,10 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce
kubectl config unset users.foo # foo 사용자 삭제
# 컨텍스트/네임스페이스를 설정/조회하는 단축 명령 (bash 및 bash 호환 셸에서만 동작함, 네임스페이스 설정을 위해 kn 을 사용하기 전에 현재 컨텍스트가 설정되어야 함)
alias kx='f() { [ "$1" ] && kubectl config use-context $1 || kubectl config current-context ; } ; f'
alias kn='f() { [ "$1" ] && kubectl config set-context --current --namespace $1 || kubectl config view --minify | grep namespace | cut -d" " -f6 ; } ; f'
```
## Kubectl apply
@ -92,10 +102,10 @@ kubectl apply -f https://git.io/vPieo # url로부터 리소스(들) 생
kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작
# "Hello World"를 출력하는 잡(Job) 생성
kubectl create job hello --image=busybox -- echo "Hello World"
kubectl create job hello --image=busybox:1.28 -- echo "Hello World"
# 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성
kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello World"
kubectl create cronjob hello --image=busybox:1.28 --schedule="*/1 * * * *" -- echo "Hello World"
kubectl explain pods # 파드 매니페스트 문서를 조회
@ -108,7 +118,7 @@ metadata:
spec:
containers:
- name: busybox
image: busybox
image: busybox:1.28
args:
- sleep
- "1000000"
@ -120,7 +130,7 @@ metadata:
spec:
containers:
- name: busybox
image: busybox
image: busybox:1.28
args:
- sleep
- "1000"
@ -172,9 +182,9 @@ kubectl get pods --selector=app=cassandra -o \
kubectl get configmap myconfig \
-o jsonpath='{.data.ca\.crt}'
# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/master'
# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/control-plane'
# 으로 명명된 라벨의 결과를 제외)
kubectl get node --selector='!node-role.kubernetes.io/master'
kubectl get node --selector='!node-role.kubernetes.io/control-plane'
# 네임스페이스의 모든 실행 중인 파드를 조회
kubectl get pods --field-selector=status.phase=Running
@ -212,19 +222,21 @@ kubectl diff -f ./my-manifest.yaml
# 노드에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
# 복잡한 중첩 JSON 구조 내에서 키를 찾을 때 유용하다.
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
kubectl get nodes -o json | jq -c 'paths|join(".")'
# 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
kubectl get pods -o json | jq -c 'paths|join(".")'
# 모든 파드에 대해 ENV를 생성한다(각 파드에 기본 컨테이너가 있고, 기본 네임스페이스가 있고, `env` 명령어가 동작한다고 가정).
# `env` 뿐만 아니라 다른 지원되는 명령어를 모든 파드에 실행할 때에도 참고할 수 있다.
for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod -- env; done
# 디플로이먼트의 status 서브리소스를 조회한다.
kubectl get deployment nginx-deployment --subresource=status
```
## 리소스 업데이트
```bash
kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
kubectl rollout history deployment/frontend # 현 리비전을 포함한 디플로이먼트의 이력을 체크
@ -234,7 +246,7 @@ kubectl rollout status -w deployment/frontend # 완료될 때
kubectl rollout restart deployment/frontend # "frontend" 디플로이먼트의 롤링 재시작
cat pod.json | kubectl replace -f - # std로 전달된 JSON을 기반으로 파드 교체
cat pod.json | kubectl replace -f - # stdin으로 전달된 JSON을 기반으로 파드 교체
# 리소스를 강제 교체, 삭제 후 재생성함. 이것은 서비스를 중단시킴.
kubectl replace --force -f ./pod.json
@ -266,11 +278,15 @@ kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "
# 위치 배열에 새 요소 추가
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
# Update a deployment's replicas count by patching it's scale subresource
# 디플로이먼트의 scale 서브리소스를 패치하여 레플리카 카운트를 업데이트.
kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'
```
## 리소스 편집
편집기로 모든 API 리소스를 편집.
선호하는 편집기로 모든 API 리소스를 편집할 수 있다.
```bash
kubectl edit svc/docker-registry # docker-registry라는 서비스 편집
@ -310,7 +326,7 @@ kubectl logs my-pod -c my-container --previous # 컨테이너의 이전 인
kubectl logs -f my-pod # 실시간 스트림 파드 로그(stdout)
kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행
kubectl run -i --tty busybox --image=busybox:1.28 -- sh # 대화형 셸로 파드를 실행
kubectl run nginx --image=nginx -n mynamespace # mynamespace 네임스페이스에서 nginx 파드 1개 실행
kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
--dry-run=client -o yaml > pod.yaml
@ -419,7 +435,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
```
더 많은 예제는 kubectl [참조 문서](/ko/docs/reference/kubectl/overview/#custom-columns)를 참고한다.
더 많은 예제는 kubectl [참조 문서](/ko/docs/reference/kubectl/#custom-columns)를 참고한다.
### Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅
@ -440,10 +456,10 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그
## {{% heading "whatsnext" %}}
* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자.
* [kubectl 개요](/ko/docs/reference/kubectl/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자.
* [kubectl](/ko/docs/reference/kubectl/kubectl/) 옵션을 참고한다.
* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/ko/docs/reference/kubectl/conventions/)을 참고한다.
* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용 규칙](/ko/docs/reference/kubectl/conventions/)을 참고한다.
* 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다.

10
content/ko/docs/reference/kubectl/conventions.md
View File

@ -19,6 +19,16 @@ content_type: concept
* 예를 들어 `jobs.v1.batch/myjob`과 같이 전체 버전을 사용한다. 이를 통해 `kubectl`이 시간이 지남에 따라 변경될 수 있는 기본 버전을 사용하지 않도록 한다.
* 문맥, 설정 또는 기타 암묵적 상태에 의존하지 않는다.
## 서브리소스 {#subresources}
* kubectl의 `get`, `patch`, `edit` 및 `replace`와 같은 명령어에서
서브리소스를 지원하는 모든 리소스에 대해 `--subresource` 알파 플래그를 사용하여
서브리소스를 조회하고 업데이트할 수 있다. 현재, `status`와 `scale` 서브리소스만 지원된다.
* 서브리소스에 대한 API 계약은 전체 리소스와 동일하다.
`status` 서브리소스를 새 값으로 업데이트해도,
컨트롤러에서 서브리소스를 잠재적으로 다른 값으로 조정할 수 있다는 점을 염두에 두어야 한다.
## 모범 사례
### `kubectl run`

2
content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md
View File

@ -187,7 +187,7 @@ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit
```
자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다.
자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/ko/docs/tasks/debug/debug-application/get-shell-running-container/)를 참고한다.
## docker logs

1
content/ko/docs/reference/kubectl/jsonpath.md
View File

@ -1,7 +1,6 @@
---
title: JSONPath 지원
content_type: concept
weight: 25
---
<!-- overview -->

2
content/ko/docs/reference/kubectl/kubectl.md
View File

@ -9,7 +9,7 @@ weight: 30
kubectl은 쿠버네티스 클러스터 관리자를 제어한다.
자세한 정보는 [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 확인한다.
자세한 정보는 [kubectl 개요](/ko/docs/reference/kubectl/)를 확인한다.
```
kubectl [flags]

547
content/ko/docs/reference/kubectl/overview.md
View File

@ -1,547 +0,0 @@
---
title: kubectl 개요
content_type: concept
weight: 20
card:
name: reference
weight: 20
---
<!-- overview -->
Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다.
구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다.
KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
파일을 지정할 수 있다.
이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다.
지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은
[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다.
설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고한다.
<!-- body -->
## 구문
터미널 창에서 `kubectl` 명령을 실행하려면 다음의 구문을 사용한다.
```shell
kubectl [command] [TYPE] [NAME] [flags]
```
다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다.
* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다.
예: `create`, `get`, `describe`, `delete`
* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며
단수형, 복수형 또는 약어 형식을 지정할 수 있다.
예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.
```shell
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
```
* `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods`
여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.
* 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다.
* 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. `TYPE1 name1 name2 name<#>`<br/>
예: `kubectl get pod example-pod1 example-pod2`
* 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`<br/>
예: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
* 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>`
* YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).<br/>
예: `kubectl get -f ./pod.yaml`
* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.<br/>
{{< caution >}}
커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다.
{{< /caution >}}
도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다.
## 클러스터 내 인증과 네임스페이스 오버라이드
기본적으로 `kubectl`은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 `KUBERNETES_SERVICE_HOST`와 `KUBERNETES_SERVICE_PORT` 환경 변수, 그리고 서비스 어카운트 토큰 파일이 `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다.
하위 호환성을 위해, 클러스터 내 인증 시에 `POD_NAMESPACE` 환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다.
**`POD_NAMESPACE` 환경 변수**
`POD_NAMESPACE` 환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 `seattle`로 설정되어 있으면, `kubectl get pods` 명령은 `seattle` 네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. `kubectl api-resources` 명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다.
명시적으로 `--namespace <value>` 인자를 사용하면 위와 같은 동작을 오버라이드한다.
**kubectl이 서비스어카운트 토큰을 관리하는 방법**
만약
* 쿠버네티스 서비스 어카운트 토큰 파일이
`/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 마운트되어 있고,
* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고,
* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고,
* kubectl 명령에 네임스페이스를 명시하지 않으면
kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다.
kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
이는 클러스터 외부에서 실행되었을 때와는 다른데,
kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우
kubectl은 `default` 네임스페이스에 대해 동작한다.
## 명령어
다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.
명령어 | 구문 | 설명
-------------------- | -------------------- | --------------------
`alpha` | `kubectl alpha SUBCOMMAND [flags]` | 쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다.
`annotate` | <code>kubectl annotate (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다.
`api-resources` | `kubectl api-resources [flags]` | 사용 가능한 API 리소스를 나열한다.
`api-versions` | `kubectl api-versions [flags]` | 사용 가능한 API 버전을 나열한다.
`apply` | `kubectl apply -f FILENAME [flags]`| 파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다.
`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다.
`auth` | `kubectl auth [flags] [options]` | 승인을 검사한다.
`autoscale` | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | 레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다.
`certificate` | `kubectl certificate SUBCOMMAND [options]` | 인증서 리소스를 수정한다.
`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
`delete` | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | 파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다.
`describe` | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | 하나 이상의 리소스의 자세한 상태를 표시한다.
`diff` | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다.
`drain` | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다.
`edit` | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다.
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다.
`explain` | `kubectl explain [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다.
`expose` | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다.
`get` | <code>kubectl get (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label]) [--watch] [--sort-by=FIELD] [[-o &#124; --output]=OUTPUT_FORMAT] [flags]</code> | 하나 이상의 리소스를 나열한다.
`kustomize` | `kubectl kustomize <dir> [flags] [options]` | kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다.
`label` | <code>kubectl label (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 하나 이상의 리소스 레이블을 추가하거나 업데이트한다.
`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 파드의 컨테이너에 대한 로그를 출력한다.
`options` | `kubectl options` | 모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다.
`patch` | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | 전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다.
`plugin` | `kubectl plugin [flags] [options]` | 플러그인과 상호 작용하기 위한 유틸리티를 제공한다.
`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 하나 이상의 로컬 포트를 파드로 전달한다.
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 쿠버네티스 API 서버에 프록시를 실행한다.
`replace` | `kubectl replace -f FILENAME` | 파일 또는 표준입력에서 리소스를 교체한다.
`rollout` | `kubectl rollout SUBCOMMAND [options]` | 리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다.
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | 클러스터에서 지정된 이미지를 실행한다.
`scale` | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 지정된 레플리케이션 컨트롤러의 크기를 업데이트한다.
`set` | `kubectl set SUBCOMMAND [options]` | 애플리케이션 리소스를 구성한다.
`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 하나 이상의 노드에서 테인트(taint)를 업데이트한다.
`top` | `kubectl top [flags] [options]` | 리소스(CPU/메모리/스토리지) 사용량을 표시한다.
`uncordon` | `kubectl uncordon NODE [options]` | 노드를 스케줄 가능(schedulable)으로 표시한다.
`version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다.
`wait` | <code>kubectl wait ([-f FILENAME] &#124; resource.group/resource.name &#124; resource.group [(-l label &#124; --all)]) [--for=delete&#124;--for condition=available] [options]</code> | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다.
명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
## 리소스 타입
다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.
(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)
| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND |
|---|---|---|---|---|
| `bindings` | | | true | Binding |
| `componentstatuses` | `cs` | | false | ComponentStatus |
| `configmaps` | `cm` | | true | ConfigMap |
| `endpoints` | `ep` | | true | Endpoints |
| `events` | `ev` | | true | Event |
| `limitranges` | `limits` | | true | LimitRange |
| `namespaces` | `ns` | | false | Namespace |
| `nodes` | `no` | | false | Node |
| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
| `persistentvolumes` | `pv` | | false | PersistentVolume |
| `pods` | `po` | | true | Pod |
| `podtemplates` | | | true | PodTemplate |
| `replicationcontrollers` | `rc` | | true | ReplicationController |
| `resourcequotas` | `quota` | | true | ResourceQuota |
| `secrets` | | | true | Secret |
| `serviceaccounts` | `sa` | | true | ServiceAccount |
| `services` | `svc` | | true | Service |
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
| `apiservices` | | apiregistration.k8s.io | false | APIService |
| `controllerrevisions` | | apps | true | ControllerRevision |
| `daemonsets` | `ds` | apps | true | DaemonSet |
| `deployments` | `deploy` | apps | true | Deployment |
| `replicasets` | `rs` | apps | true | ReplicaSet |
| `statefulsets` | `sts` | apps | true | StatefulSet |
| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
| `cronjobs` | `cj` | batch | true | CronJob |
| `jobs` | | batch | true | Job |
| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
| `leases` | | coordination.k8s.io | true | Lease |
| `endpointslices` | | discovery.k8s.io | true | EndpointSlice |
| `events` | `ev` | events.k8s.io | true | Event |
| `ingresses` | `ing` | extensions | true | Ingress |
| `flowschemas` | | flowcontrol.apiserver.k8s.io | false | FlowSchema |
| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration |
| `ingressclasses` | | networking.k8s.io | false | IngressClass |
| `ingresses` | `ing` | networking.k8s.io | true | Ingress |
| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
| `runtimeclasses` | | node.k8s.io | false | RuntimeClass |
| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
| `roles` | | rbac.authorization.k8s.io | true | Role |
| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
| `csidrivers` | | storage.k8s.io | false | CSIDriver |
| `csinodes` | | storage.k8s.io | false | CSINode |
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
## 출력 옵션
특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
### 출력 서식화
모든 `kubectl` 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가할 수 있다.
#### 구문
```shell
kubectl [command] [TYPE] [NAME] -o <output_format>
```
`kubectl` 명령에 따라, 다음과 같은 출력 형식이 지원된다.
출력 형식 | 설명
--------------| -----------
`-o custom-columns=<spec>` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다.
`-o custom-columns-file=<filename>` | `<filename>` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다.
`-o json` | JSON 형식의 API 오브젝트를 출력한다.
`-o jsonpath=<template>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식에 정의된 필드를 출력한다.
`-o jsonpath-file=<filename>` | `<filename>` 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식으로 정의된 필드를 출력한다.
`-o name` | 리소스 이름만 출력한다.
`-o wide` | 추가 정보가 포함된 일반 텍스트 형식으로 출력된다. 파드의 경우, 노드 이름이 포함된다.
`-o yaml` | YAML 형식의 API 오브젝트를 출력한다.
##### 예제
이 예제에서, 다음의 명령은 단일 파드에 대한 세부 정보를 YAML 형식의 오브젝트로 출력한다.
```shell
kubectl get pod web-pod-13je7 -o yaml
```
기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은
[kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다.
#### 사용자 정의 열 {#custom-columns}
사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, `custom-columns` 옵션을 사용할 수 있다.
사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. `-o custom-columns=<spec>` 또는 `-o custom-columns-file=<filename>`
##### 예제
인라인:
```shell
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
```
템플릿 파일:
```shell
kubectl get pods <pod-name> -o custom-columns-file=template.txt
```
`template.txt` 파일에 포함된 내용은 다음과 같다.
```
NAME RSRC
metadata.name metadata.resourceVersion
```
두 명령 중 하나를 실행한 결과는 다음과 비슷하다.
```
NAME RSRC
submit-queue 610995
```
#### 서버측 열
`kubectl` 는 서버에서 오브젝트에 대한 특정 열 정보 수신을 지원한다.
이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다.
이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다.
이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면,
`kubectl get` 명령에 `--server-print=false` 플래그를 추가한다.
##### 예제
파드 상태에 대한 정보를 출력하려면, 다음과 같은 명령을 사용한다.
```shell
kubectl get pods <pod-name> --server-print=false
```
출력 결과는 다음과 비슷하다.
```
NAME AGE
pod-name 1m
```
### 오브젝트 목록 정렬
터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 `kubectl` 명령에 `--sort-by` 플래그를 추가할 수 있다. `--sort-by` 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, [jsonpath](/ko/docs/reference/kubectl/jsonpath/) 표현식을 사용한다.
#### 구문
```shell
kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
```
##### 예제
이름별로 정렬된 파드 목록을 출력하려면, 다음을 실행한다.
```shell
kubectl get pods --sort-by=.metadata.name
```
## 예제: 일반적인 작업
다음 예제 세트를 사용하여 일반적으로 사용되는 `kubectl` 조작 실행에 익숙해진다.
`kubectl apply` - 파일 또는 표준입력에서 리소스를 적용하거나 업데이트한다.
```shell
# example-service.yaml의 정의를 사용하여 서비스를 생성한다.
kubectl apply -f example-service.yaml
# example-controller.yaml의 정의를 사용하여 레플리케이션 컨트롤러를 생성한다.
kubectl apply -f example-controller.yaml
# <directory> 디렉터리 내의 .yaml, .yml 또는 .json 파일에 정의된 오브젝트를 생성한다.
kubectl apply -f <directory>
```
`kubectl get` - 하나 이상의 리소스를 나열한다.
```shell
# 모든 파드를 일반 텍스트 출력 형식으로 나열한다.
kubectl get pods
# 모든 파드를 일반 텍스트 출력 형식으로 나열하고 추가 정보(예: 노드 이름)를 포함한다.
kubectl get pods -o wide
# 지정된 이름의 레플리케이션 컨트롤러를 일반 텍스트 출력 형식으로 나열한다. 팁: 'replicationcontroller' 리소스 타입을 'rc'로 짧게 바꿔쓸 수 있다.
kubectl get replicationcontroller <rc-name>
# 모든 레플리케이션 컨트롤러와 서비스를 일반 텍스트 출력 형식으로 함께 나열한다.
kubectl get rc,services
# 모든 데몬 셋을 일반 텍스트 출력 형식으로 나열한다.
kubectl get ds
# 노드 server01에서 실행 중인 모든 파드를 나열한다.
kubectl get pods --field-selector=spec.nodeName=server01
```
`kubectl describe` - 초기화되지 않은 리소스를 포함하여 하나 이상의 리소스의 기본 상태를 디폴트로 표시한다.
```shell
# 노드 이름이 <node-name>인 노드의 세부 사항을 표시한다.
kubectl describe nodes <node-name>
# 파드 이름이 <pod-name> 인 파드의 세부 정보를 표시한다.
kubectl describe pods/<pod-name>
# 이름이 <rc-name>인 레플리케이션 컨트롤러가 관리하는 모든 파드의 세부 정보를 표시한다.
# 기억하기: 레플리케이션 컨트롤러에서 생성된 모든 파드에는 레플리케이션 컨트롤러 이름이 접두사로 붙는다.
kubectl describe pods <rc-name>
# 모든 파드의 정보를 출력한다.
kubectl describe pods
```
{{< note >}}
`kubectl get` 명령은 일반적으로 동일한 리소스 타입의 하나 이상의
리소스를 검색하는 데 사용된다. 예를 들어, `-o` 또는 `--output` 플래그를
사용하여 출력 형식을 사용자 정의할 수 있는 풍부한 플래그 세트가 있다.
`-w` 또는 `--watch` 플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인할 수
있다. `kubectl describe` 명령은 지정된 리소스의 여러 관련 측면을
설명하는 데 더 중점을 둔다. API 서버에 대한 여러 API 호출을 호출하여
사용자에 대한 뷰(view)를 빌드할 수 있다. 예를 들어, `kubectl describe node`
명령은 노드에 대한 정보뿐만 아니라, 노드에서 실행 중인 파드의 요약 정보, 노드에 대해 생성된 이벤트 등의
정보도 검색한다.
{{< /note >}}
`kubectl delete` - 파일, 표준입력 또는 레이블 선택기, 이름, 리소스 선택기나 리소스를 지정하여 리소스를 삭제한다.
```shell
# pod.yaml 파일에 지정된 타입과 이름을 사용하여 파드를 삭제한다.
kubectl delete -f pod.yaml
# '<label-key>=<label-value>' 레이블이 있는 모든 파드와 서비스를 삭제한다.
kubectl delete pods,services -l <label-key>=<label-value>
# 초기화되지 않은 파드를 포함한 모든 파드를 삭제한다.
kubectl delete pods --all
```
`kubectl exec` - 파드의 컨테이너에 대해 명령을 실행한다.
```shell
# 파드 <pod-name>에서 'date'를 실행한 결과를 얻는다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec <pod-name> -- date
# 파드 <pod-name>의 <container-name> 컨테이너에서 'date'를 실행하여 출력 결과를 얻는다.
kubectl exec <pod-name> -c <container-name> -- date
# 파드 <pod-name>에서 대화식 TTY를 연결해 /bin/bash를 실행한다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec -ti <pod-name> -- /bin/bash
```
`kubectl logs` - 파드의 컨테이너에 대한 로그를 출력한다.
```shell
# 파드 <pod-name>에서 로그의 스냅샷을 반환한다.
kubectl logs <pod-name>
# 파드 <pod-name>에서 로그 스트리밍을 시작한다. 이것은 리눅스 명령 'tail -f'와 비슷하다.
kubectl logs -f <pod-name>
```
`kubectl diff` - 제안된 클러스터 업데이트의 차이점을 본다.
```shell
# "pod.json"에 포함된 리소스의 차이점을 출력한다.
kubectl diff -f pod.json
# 표준입력에서 파일을 읽어 차이점을 출력한다.
cat service.yaml | kubectl diff -f -
```
## 예제: 플러그인 작성 및 사용
`kubectl` 플러그인 작성과 사용에 익숙해지려면 다음의 예제 세트를 사용한다.
```shell
# 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로
# 시작하도록 실행 파일의 이름을 지정한다.
cat ./kubectl-hello
```
```shell
#!/bin/sh
# 이 플러그인은 "hello world"라는 단어를 출력한다
echo "hello world"
```
작성한 플러그인을 실행 가능하게 한다
```bash
chmod a+x ./kubectl-hello
# 그리고 PATH의 위치로 옮긴다
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# 이제 kubectl 플러그인을 만들고 "설치했다".
# kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다
kubectl hello
```
```
hello world
```
```shell
# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여,
# 플러그인을 "제거"할 수 있다
sudo rm /usr/local/bin/kubectl-hello
```
`kubectl` 에 사용할 수 있는 모든 플러그인을 보려면,
`kubectl plugin list` 하위 명령을 사용한다.
```shell
kubectl plugin list
```
출력 결과는 다음과 비슷하다.
```
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
```
`kubectl plugin list` 는 또한 실행 가능하지 않거나,
다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다.
```shell
sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거
kubectl plugin list
```
```
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
```
플러그인은 기존 kubectl 명령 위에 보다 복잡한 기능을
구축하는 수단으로 생각할 수 있다.
```shell
cat ./kubectl-whoami
```
다음 몇 가지 예는 이미 `kubectl-whoami` 에
다음 내용이 있다고 가정한다.
```shell
#!/bin/bash
# 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한
# 정보를 출력하기 위해 'kubectl config' 명령을 사용한다.
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
```
위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한
사용자가 포함된 출력이 제공된다.
```shell
# 파일을 실행 가능하게 한다
sudo chmod +x ./kubectl-whoami
# 그리고 PATH로 옮긴다
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
```
## {{% heading "whatsnext" %}}
* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다.
* 플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다.

2
content/ko/docs/reference/labels-annotations-taints.md → content/ko/docs/reference/labels-annotations-taints/_index.md
View File

@ -461,7 +461,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
## container.seccomp.security.alpha.kubernetes.io/[이름] {#container-seccomp-security-alpha-kubernetes-io}
이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다.
[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/clusters/seccomp/) 튜토리얼에서
[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/security/seccomp/) 튜토리얼에서
seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다.
튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며,
이는 파드의 `.spec` 내에 `securityContext` 를 설정함으로써 가능하다.

3
content/ko/docs/reference/tools/_index.md
View File

@ -30,9 +30,6 @@ no_list: true
[Helm](https://helm.sh/)은 사전 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 도구이다.
이 패키지는 _Helm charts_ 라고 알려져 있다.
Helm은 미리 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 제 3자가
관리하는 도구로, 쿠버네티스 차트(charts)라고도 알려져 있다.
Helm의 용도
* 쿠버네티스 차트로 배포된 인기있는 소프트웨어를 검색하고 사용

5
content/ko/docs/reference/using-api/_index.md
View File

@ -1,5 +1,9 @@
---
title: API 개요
content_type: concept
weight: 10
no_list: true
@ -104,6 +108,7 @@ API 그룹은 REST 경로와 직렬화된 오브젝트의 `apiVersion` 필드에
- `batch/v1` 을 비활성화하려면, `--runtime-config=batch/v1=false` 로 설정
- `batch/v2alpha1` 을 활성화하려면, `--runtime-config=batch/v2alpha1` 으로 설정
- 예를 들어 `storage.k8s.io/v1beta1/csistoragecapacities`와 같이 특정 버전의 API를 활성화하려면, `--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`와 같이 설정
{{< note >}}
그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여

4
content/ko/docs/setup/best-practices/certificates.md
View File

@ -22,6 +22,8 @@ weight: 40
쿠버네티스는 다음 작업에서 PKI를 필요로 한다.
* kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서
* API 서버가 kubelet과 통신하기 위한
kubelet [서버 인증서](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates)
* API 서버 엔드포인트를 위한 서버 인증서
* API 서버에 클러스터 관리자 인증을 위한 클라이언트 인증서
* API 서버에서 kubelet과 통신을 위한 클라이언트 인증서
@ -89,7 +91,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.
로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
`kind`는 하나 이상의 [x509 키 사용](https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다.
`kind`는 하나 이상의 [x509 키 사용](https://pkg.go.dev/k8s.io/api/certificates/v1beta1#KeyUsage) 종류를 가진다.
| 종류 | 키 사용 |
|--------|---------------------------------------------------------------------------------|

17
content/ko/docs/setup/best-practices/node-conformance.md
View File

@ -1,4 +1,6 @@
---
title: 노드 구성 검증하기
weight: 30
---
@ -6,13 +8,15 @@ weight: 30
## 노드 적합성 테스트
*노드 적합성 테스트* 는 노드의 시스템 검증과 기능 테스트를 제공하기 위해 컨테이너화된 테스트 프레임워크이다.
테스트는 노드가 쿠버네티스를 위한 최소 요구조건을 만족하는지를 검증한다. 그리고 테스트를 통과한 노드는 쿠버네티스 클러스터에 참
여할 자격이 주어진다.
*노드 적합성 테스트* 는 노드의 시스템 검증과 기능 테스트를 제공하기 위해 컨테이너화된
테스트 프레임워크이다.
테스트는 노드가 쿠버네티스를 위한 최소 요구조건을 만족하는지를 검증한다.
그리고 테스트를 통과한 노드는 쿠버네티스 클러스터에 참여할 자격이 주어진다.
## 노드 필수 구성 요소
노드 적합성 테스트를 실행하기 위해서는, 해당 노드는 표준 쿠버네티스 노드로서 동일한 전제조건을 만족해야 한다.
노드 적합성 테스트를 실행하기 위해서는,
해당 노드는 표준 쿠버네티스 노드로서 동일한 전제조건을 만족해야 한다.
노드는 최소한 아래 데몬들이 설치되어 있어야 한다.
* 컨테이너 런타임 (Docker)
@ -21,14 +25,13 @@ weight: 30
## 노드 적합성 테스트 실행
노드 적합성 테스트는 다음 순서로 진행된다.
1. kubelet에 대한 `--kubeconfig` 옵션의 값을 계산한다. 예를 들면, 다음과 같다.
`--kubeconfig = / var / lib / kubelet / config.yaml`.
테스트 프레임워크는 kubelet을 테스트하기 위해 로컬 컨트롤 플레인을 시작하기 때문에,
`http://localhost:8080` 을 API 서버의 URL로 사용한다.
사용할 수 있는 kubelet 커맨드 라인 파라미터가 몇 개 있다.
* `--pod-cidr`: `kubenet`을 사용 중이라면, 임의의 CIDR을 Kubelet에 지정해주어야 한다. 예) `--pod-cidr=10.180.0.0/24`.
* `--cloud-provider`: `--cloud-provider=gce`를 사용 중이라면, 테스트 실행 시에는 제거해야 한다.
* `--cloud-provider`: `--cloud-provider=gce`를 사용 중이라면,
테스트 실행 시에는 제거해야 한다.
2. 다음 커맨드로 노드 적합성 테스트를 실행한다.

2
content/ko/docs/setup/production-environment/_index.md
View File

@ -197,7 +197,7 @@ etcd 백업 계획을 세우려면
스크립트를 구성할 수 있는 가상화 플랫폼이 있다.
- *노드 헬스 체크 구성*: 중요한 워크로드의 경우,
해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다.
[Node Problem Detector](/docs/tasks/debug-application-cluster/monitor-node-health/)
[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/)
데몬을 사용하면 노드가 정상인지 확인할 수 있다.
## 프로덕션 사용자 관리

352
content/ko/docs/setup/production-environment/container-runtimes.md
View File

@ -8,21 +8,21 @@ weight: 20
---
<!-- overview -->
{{% dockershim-removal %}}
파드가 노드에서 실행될 수 있도록 클러스터의 각 노드에
{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을
설치해야 한다. 이 페이지에서는 관련된 항목을 설명하고
노드 설정 관련 작업을 설명한다.
<!-- body -->
쿠버네티스 {{< skew currentVersion >}}에서는
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는
런타임을 사용해야 한다.
더 자세한 정보는 [CRI 버전 지원](#cri-versions)을 참조한다.
이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한
세부 정보가 있다.
이 페이지는 쿠버네티스에서
여러 공통 컨테이너 런타임을 사용하는 방법에 대한 개요를 제공한다.
- [containerd](#containerd)
- [CRI-O](#cri-o)
@ -30,12 +30,27 @@ weight: 20
- [미란티스 컨테이너 런타임](#mcr)
{{< note >}}
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
쿠버네티스 v1.24 이전 릴리스는
_dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 통합을 지원했다.
이 특별한 직접 통합은
더 이상 쿠버네티스에 포함되지 않는다(이 제거는
v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다).
이 제거가 어떻게 영향을 미치는지 알아보려면
[Dockershim 사용 중단이 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다.
dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면,
[dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다.
v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 있다면,
해당 버전의 문서를 참고한다.
{{< /note >}}
<!-- body -->
## cgroup 드라이버
Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다.
리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은
프로세스에 할당된 리소스를 제한하는데 사용된다.
리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인
경우, init 프로세스는 root control group(`cgroup`)을
@ -64,7 +79,7 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
교체하거나, 자동화를 사용하여 다시 설치한다.
{{< /caution >}}
## cgroup v2
### Cgroup 버전 2 {#cgroup-v2}
cgroup v2는 cgroup Linux API의 다음 버전이다.
cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다.
@ -102,8 +117,8 @@ cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야
### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기
kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
[변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
기존에 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면,
[cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
## CRI 버전 지원 {#cri-versions}
@ -120,95 +135,47 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된
### containerd
이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.
이 섹션에는 containerd를 CRI 런타임으로 사용하는 데 필요한 단계를 간략하게 설명한다.
다음 명령을 사용하여 시스템에 containerd를 설치한다.
필수 구성 요소를 설치 및 구성한다.
1. 필수 구성 요소를 설치 및 구성한다.
```shell
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
# 재부팅하지 않고 sysctl 파라미터 적용
sudo sysctl --system
```
containerd를 설치한다.
{{< tabs name="tab-cri-containerd-installation" >}}
{{% tab name="Linux" %}}
1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다.
각 리눅스 배포판에 대한 도커 리포지터리를 설정하고
`containerd.io` 패키지를 설치하는 방법은
[도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다.
2. containerd 설정
(이 지침은 리눅스 노드에만 적용된다)
```shell
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
# 재부팅하지 않고 sysctl 파라미터 적용
sudo sysctl --system
```
3. containerd 재시작
1. containerd를 설치한다.
```shell
sudo systemctl restart containerd
```
[containerd 시작하기](https://github.com/containerd/containerd/blob/main/docs/getting-started.md)
문서를 확인하고,
유효한 환경 설정 파일(`config.toml`)을 작성하는 부분까지의
가이드를 따른다.
리눅스에서, 이 파일은 `/etc/containerd/config.toml`에 존재한다.
윈도우에서, 이 파일은 `C:\Program Files\containerd\config.toml`에 존재한다.
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
리눅스에서, containerd를 위한 기본 CRI 소켓은 `/run/containerd/containerd.sock`이다.
윈도우에서, 기본 CRI 엔드포인트는 `npipe://./pipe/containerd-containerd`이다.
PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
설정(예: `$Version:"1.4.3"`)한 후 다음 명령을 실행한다.
1. containerd 다운로드
```powershell
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
tar.exe xvf .\containerd-windows-amd64.tar.gz
```
2. 추출과 설정
```powershell
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii
# 설정을 검토한다. 설정에 따라 다음을 조정할 수 있다.
# - sandbox_image (쿠버네티스 일시중지 이미지)
# - cni bin 폴더와 conf 폴더 위치
Get-Content config.toml
# (선택사항 - 그러나 적극 권장함) Windows 디펜더 검사에서 containerd 제외
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
```
3. containerd 실행
```powershell
.\containerd.exe --register-service
Start-Service containerd
```
{{% /tab %}}
{{< /tabs >}}
#### `systemd` cgroup 드라이버의 사용 {#containerd-systemd}
#### `systemd` cgroup 드라이버 환경 설정하기 {#containerd-systemd}
`/etc/containerd/config.toml` 의 `systemd` cgroup 드라이버를 `runc` 에서 사용하려면, 다음과 같이 설정한다.
@ -219,7 +186,7 @@ PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로
SystemdCgroup = true
```
이 변경 사항을 적용하는 경우 containerd를 재시작한다.
이 변경 사항을 적용하려면, containerd를 재시작한다.
```shell
sudo systemctl restart containerd
@ -232,176 +199,14 @@ kubeadm을 사용하는 경우,
이 섹션은 CRI-O를 컨테이너 런타임으로 설치하는 필수적인 단계를 담고 있다.
시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다.
{{< note >}}
CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 버전이 일치해야 한다.
더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes)를 본다.
{{< /note >}}
필수 구성 요소를 설치하고 구성한다.
```shell
# .conf 파일을 만들어 부팅 시 모듈을 로드한다
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅 간에도 유지된다.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sudo sysctl --system
```
{{< tabs name="tab-cri-cri-o-installation" >}}
{{% tab name="Debian" %}}
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를
아래의 표에서 적절한 필드로 설정한다.
| 운영 체제 | `$OS` |
| ---------------- | ----------------- |
| Debian Unstable | `Debian_Unstable` |
| Debian Testing | `Debian_Testing` |
<br />
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
<br />
그런 다음, 아래를 실행한다.
```shell
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
EOF
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
EOF
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
sudo apt-get update
sudo apt-get install cri-o cri-o-runc
```
{{% /tab %}}
{{% tab name="Ubuntu" %}}
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를
아래의 표에서 적절한 필드로 설정한다.
| 운영 체제 | `$OS` |
| ---------------- | ----------------- |
| Ubuntu 20.04 | `xUbuntu_20.04` |
| Ubuntu 19.10 | `xUbuntu_19.10` |
| Ubuntu 19.04 | `xUbuntu_19.04` |
| Ubuntu 18.04 | `xUbuntu_18.04` |
<br />
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
<br />
그런 다음, 아래를 실행한다.
```shell
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
EOF
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
EOF
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -
apt-get update
apt-get install cri-o cri-o-runc
```
{{% /tab %}}
{{% tab name="CentOS" %}}
다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를
아래의 표에서 적절한 필드로 설정한다.
| 운영 체제 | `$OS` |
| ---------------- | ----------------- |
| Centos 8 | `CentOS_8` |
| Centos 8 Stream | `CentOS_8_Stream` |
| Centos 7 | `CentOS_7` |
<br />
그런 다음, `$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
사용자의 설치를 특정 릴리스에 고정할 수 있다.
버전 1.20.0을 설치하려면, `VERSION=1.20:1.20.0` 을 설정한다.
<br />
그런 다음, 아래를 실행한다.
```shell
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
sudo yum install cri-o
```
{{% /tab %}}
{{% tab name="openSUSE Tumbleweed" %}}
```shell
sudo zypper install cri-o
```
{{% /tab %}}
{{% tab name="Fedora" %}}
`$VERSION` 을 사용자의 쿠버네티스 버전과 일치하는 CRI-O 버전으로 설정한다.
예를 들어, CRI-O 1.20을 설치하려면, `VERSION=1.20` 로 설정한다.
사용할 수 있는 버전을 찾으려면 다음을 실행한다.
```shell
sudo dnf module list cri-o
```
CRI-O는 Fedora에서 특정 릴리스를 고정하여 설치하는 방법은 지원하지 않는다.
그런 다음, 아래를 실행한다.
```shell
sudo dnf module enable cri-o:$VERSION
sudo dnf install cri-o
```
{{% /tab %}}
{{< /tabs >}}
CRI-O를 시작한다.
```shell
sudo systemctl daemon-reload
sudo systemctl enable crio --now
```
자세한 사항은 [CRI-O 설치 가이드](https://github.com/cri-o/cri-o/blob/master/install.md)를
참고한다.
CRI-O를 설치하려면, [CRI-O 설치 방법](https://github.com/cri-o/cri-o/blob/main/install.md#readme)을 따른다.
#### cgroup 드라이버
CRI-O는 기본적으로 systemd cgroup 드라이버를 사용한다. `cgroupfs` cgroup 드라이버로
전환하려면, `/etc/crio/crio.conf` 를 수정하거나 `/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에
드롭-인(drop-in) 구성을 배치한다. 예를 들면, 다음과 같다.
CRI-O는 기본적으로 systemd cgroup 드라이버를 사용하며, 이는 대부분의 경우에 잘 동작할 것이다.
`cgroupfs` cgroup 드라이버로 전환하려면, `/etc/crio/crio.conf` 를 수정하거나
`/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에 드롭-인(drop-in) 구성을 배치한다.
예를 들면 다음과 같다.
```toml
[crio.runtime]
@ -410,27 +215,27 @@ cgroup_manager = "cgroupfs"
```
또한 `cgroupfs` 와 함께 CRI-O를 사용할 때 `pod` 값으로 설정해야 하는
변경된 `conmon_cgroup` 에 유의한다. 일반적으로 kubelet(일반적으로 kubeadm을 통해 수행됨)과
변경된 `conmon_cgroup` 에 유의해야 한다. 일반적으로 kubelet(일반적으로 kubeadm을 통해 수행됨)과
CRI-O의 cgroup 드라이버 구성을 동기화 상태로
유지해야 한다.
CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다.
### 도커 엔진 {#docker}
도커 엔진은 모든 것을 시작한 컨테이너 런타임이다.
이전에는 간단히 도커로 알려졌던 이 컨테이너 런타임은 다양한 형태로 사용할 수 있다.
[도커 엔진 설치하기](https://docs.docker.com/engine/install/)에서
이 런타임 설치의 옵션들을 확인할 수 있다.
{{< note >}}
아래의 지침은
당신이 도커 엔진과 쿠버네티스를 통합하는 데
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 어댑터를 사용하고 있다고 가정한다.
{{< /note >}}
도커 엔진은 쿠버네티스 {{< skew currentVersion >}}와 직접 호환되며, 이는 사용 중단된 `dockershim` 컴포넌트를 활용하기 때문에 가능하다.
더 많은 정보와 맥락을 보려면, [Dockershim 사용 중단 FAQ](/dockershim)를 참고한다.
1. 각 노드에서, [도커 엔진 설치하기](https://docs.docker.com/engine/install/#server)에 따라
리눅스 배포판에 맞게 도커를 설치한다.
지원되는 {{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를 통해
쿠버네티스에서 도커 엔진을 사용할 수 있게 해 주는
써드파티 어댑터를 찾아볼 수도 있다.
2. [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 소스 코드 저장소의 지침대로
`cri-dockerd`를 설치한다.
다음 CRI 어댑터는 도커 엔진과 함께 동작하도록 설계되었다.
- 미란티스의 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)
`cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다.
### 미란티스 컨테이너 런타임 {#mcr}
@ -439,3 +244,14 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로
오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며,
이 컴포넌트는 MCR에 포함되어 있다.
미란티스 컨테이너 런타임을 설치하는 방법에 대해 더 알아보려면,
[MCR 배포 가이드](https://docs.mirantis.com/mcr/20.10/install.html)를 참고한다.
CRI 소켓의 경로를 찾으려면
`cri-docker.socket`라는 이름의 systemd 유닛을 확인한다.
## {{% heading "whatsnext" %}}
컨테이너 런타임과 더불어, 클러스터에는
동작하는 [네트워크 플러그인](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)도 필요하다.

2
content/ko/docs/setup/production-environment/tools/kops.md
View File

@ -231,7 +231,7 @@ kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의
## {{% heading "whatsnext" %}}
* 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/overview/)에 대해 더 알아보기.
* 쿠버네티스 [개념](/ko/docs/concepts/) 과 [`kubectl`](/ko/docs/reference/kubectl/)에 대해 더 알아보기.
* 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 `kops` [고급 사용법](https://kops.sigs.k8s.io/)에 대해 더 자세히 알아본다.
* 슬랙(Slack)에서 `kops` 커뮤니티 토론을 할 수 있다: [커뮤니티 토론](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
* 문제를 해결하거나 이슈를 제기하여 `kops` 에 기여한다. [깃헙 이슈](https://github.com/kubernetes/kops/issues)

7
content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
View File

@ -24,9 +24,12 @@ kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지
더 자세한 사항은 [kubeadm에서 초기화 단계 사용하기](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)을 참고한다.
{{< /note >}}
<!-- body -->
{{< note >}}
이미 생성된 클러스터를 다시 구성하려면
[kubeadm 클러스터 다시 구성하기](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/)를 참고한다.
{{< /note >}}
{{< feature-state for_k8s_version="v1.12" state="stable" >}}
<!-- body -->
## `ClusterConfiguration`의 플래그로 컨트롤 플레인 사용자 정의하기

73
content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -15,7 +15,6 @@ card:
이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm을 사용하여 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다.
## {{% heading "prerequisites" %}}
@ -69,61 +68,69 @@ sudo sysctl --system
## 필수 포트 확인 {#check-required-ports}
[필수 포트들](/ko/docs/reference/ports-and-protocols/)은
쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다.
한다. 다음과 같이 netcat과 같은 도구를 이용하여 포트가 열려 있는지 확인해 볼 수 있다.
```shell
telnet 127.0.0.1 6443
nc 127.0.0.1 6443
```
사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도
있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한
플러그인 문서를 참고한다.
## 런타임 설치 {#installing-runtime}
## 컨테이너 런타임 설치 {#installing-runtime}
파드에서 컨테이너를 실행하기 위해, 쿠버네티스는
{{< glossary_tooltip term_id="container-runtime" text="컨테이너 런타임" >}}을 사용한다.
{{< tabs name="container_runtime" >}}
{{% tab name="리눅스 노드" %}}
기본적으로, 쿠버네티스는
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI)를
사용하여 사용자가 선택한 컨테이너 런타임과 인터페이스한다.
런타임을 지정하지 않으면, kubeadm은 잘 알려진 유닉스 도메인 소켓 목록을 검색하여
런타임을 지정하지 않으면, kubeadm은 잘 알려진 엔드포인트를 스캐닝하여
설치된 컨테이너 런타임을 자동으로 감지하려고 한다.
다음 표에는 컨테이너 런타임 및 관련 소켓 경로가 나열되어 있다.
{{< table caption = "컨테이너 런타임과 소켓 경로" >}}
| 런타임 | 유닉스 도메인 소켓 경로 |
|------------|-----------------------------------|
| 도커 | `/var/run/dockershim.sock` |
| containerd | `/run/containerd/containerd.sock` |
| CRI-O | `/var/run/crio/crio.sock` |
컨테이너 런타임이 여러 개 감지되거나 하나도 감지되지 않은 경우,
kubeadm은 에러를 반환하고 사용자가 어떤 것을 사용할지를 명시하도록 요청할 것이다.
더 많은 정보는
[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 참고한다.
{{< note >}}
도커 엔진은 컨테이너 런타임이 쿠버네티스와 호환되기 위한 요구 사항인
[CRI](/ko/docs/concepts/architecture/cri/)를 만족하지 않는다.
이러한 이유로, 추가 서비스인 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)가 설치되어야 한다.
cri-dockerd는 쿠버네티스 버전 1.24부터 kubelet에서 [제거](/dockershim/)된
기존 내장 도커 엔진 지원을 기반으로 한 프로젝트이다.
{{< /note >}}
아래 표는 지원 운영 체제에 대한 알려진 엔드포인트를 담고 있다.
{{< tabs name="container_runtime" >}}
{{% tab name="리눅스" %}}
{{< table >}}
| 런타임 | 유닉스 도메인 소켓 경로 |
|------------------------------------|----------------------------------------------|
| containerd | `unix:///var/run/containerd/containerd.sock` |
| CRI-O | `unix:///var/run/crio/crio.sock` |
| 도커 엔진 (cri-dockerd 사용) | `unix:///var/run/cri-dockerd.sock` |
{{< /table >}}
<br />
도커와 containerd가 모두 감지되면 도커가 우선시된다. 이것이 필요한 이유는 도커 18.09에서
도커만 설치한 경우에도 containerd와 함께 제공되므로 둘 다 감지될 수 있기
때문이다.
다른 두 개 이상의 런타임이 감지되면, kubeadm은 오류와 함께 종료된다.
kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다.
자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을
참고한다.
{{% /tab %}}
{{% tab name="다른 운영 체제" %}}
기본적으로, kubeadm은 컨테이너 런타임으로 {{< glossary_tooltip term_id="docker" >}}를 사용한다.
kubelet은 빌트인 `dockershim` CRI 구현을 통해 도커와 통합된다.
자세한 내용은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을
참고한다.
{{% tab name="윈도우" %}}
{{< table >}}
| 런타임 | 윈도우 네임드 파이프(named pipe) 경로 |
|------------------------------------|----------------------------------------------|
| containerd | `npipe:////./pipe/containerd-containerd` |
| 도커 엔진 (cri-dockerd 사용) | `npipe:////./pipe/cri-dockerd` |
{{< /table >}}
{{% /tab %}}
{{< /tabs >}}
## kubeadm, kubelet 및 kubectl 설치
모든 머신에 다음 패키지들을 설치한다.
@ -217,6 +224,10 @@ sudo systemctl enable --now kubelet
- 구성 방법을 알고 있는 경우 SELinux를 활성화된 상태로 둘 수 있지만 kubeadm에서 지원하지 않는 설정이 필요할 수 있다.
- 사용 중인 레드햇 배포판이 `basearch`를 해석하지 못하여 `baseurl`이 실패하면, `\$basearch`를 당신의 컴퓨터의 아키텍처로 치환한다.
`uname -m` 명령을 실행하여 해당 값을 확인한다.
예를 들어, `x86_64`에 대한 `baseurl` URL은 `https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64` 이다.
{{% /tab %}}
{{% tab name="패키지 매니저를 사용하지 않는 경우" %}}
CNI 플러그인 설치(대부분의 파드 네트워크에 필요)

6
content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -830,7 +830,7 @@ DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /
[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername/)은
컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는
컨테이너에 지정할 수 있다. 이것은
[RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)와 거의 동일하다.
[RunAsUser](/ko/docs/concepts/security/pod-security-policy/#사용자-및-그룹)와 거의 동일하다.
SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은
리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다.
@ -997,8 +997,8 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
## 도움 받기 및 트러블슈팅 {#troubleshooting}
쿠버네티스 클러스터 트러블슈팅을 위한 기본
도움말은 이
[섹션](/ko/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이
도움말은
[이 섹션](/ko/docs/tasks/debug/debug-cluster/)에서 먼저 찾아야 한다. 이
섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다.
로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른
기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야

15
content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
View File

@ -29,7 +29,7 @@ weight: 75
포함하는 쿠버네티스 클러스터를 생성한다.
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
모두 비슷한 방식이라는 것이 중요하다.
[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
[Kubectl 커맨드](/ko/docs/reference/kubectl/)로 클러스터에 접속하는 것은 동일하다.
아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다.
## 시작하기: 윈도우 컨테이너 배포하기
@ -160,21 +160,28 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
노드셀렉터(nodeSelector)의 조합을 이용해야 한다.
이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데,
이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
{{< note >}}
`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면,
파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다).
리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다.
윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을
`windows`로 설정한다.
스케줄러는 파드를 노드에 할당할 때 `.spec.os.name` 필드의 값을 사용하지 않는다.
{{< note >}}
1.24부터, `IdentifyPodOS` 기능은 베타 단계이며 기본적으로 활성화되어 있다.
{{< /note >}}
스케줄러는 파드를 노드에 할당할 때
`.spec.os.name` 필드의 값을 사용하지 않는다.
컨트롤 플레인이 파드를 적절한 운영 체제가 실행되고 있는 노드에 배치하도록 하려면,
[파드를 노드에 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)하는
일반적인 쿠버네티스 메카니즘을 사용해야 한다.
`.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에,
윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트,
톨러레이션 및 노드 셀렉터가 여전히 필요하다.
{{< /note >}}
### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다.

0
content/ko/docs/tasks/administer-cluster/access-cluster-services.md → content/ko/docs/tasks/access-application-cluster/access-cluster-services.md
View File

Some files were not shown because too many files have changed in this diff Show More