diff --git a/README-ko.md b/README-ko.md index e23027c32a..c4038212c6 100644 --- a/README-ko.md +++ b/README-ko.md @@ -1,69 +1,144 @@ # 쿠버네티스 문서화 -[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website) -[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) +[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) -환영합니다! 이 저장소는 쿠버네티스 웹사이트 및 문서화를 만드는 데 필요로 하는 모든 asset에 대한 공간을 제공합니다. 여러분이 기여를 원한다는 사실에 매우 기쁩니다! +이 저장소에는 [쿠버네티스 웹사이트 및 문서](https://kubernetes.io/)를 빌드하는 데 필요한 자산이 포함되어 있습니다. 기여해주셔서 감사합니다! -## 문서에 기여하기 +# 저장소 사용하기 -이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭 가능합니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다. +Hugo(확장 버전)를 사용하여 웹사이트를 로컬에서 실행하거나, 컨테이너 런타임에서 실행할 수 있습니다. 라이브 웹사이트와의 배포 일관성을 제공하므로, 컨테이너 런타임을 사용하는 것을 적극 권장합니다. -여러분의 풀 리퀘스트가 생성된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다. 그뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다. +## 사전 준비 사항 -쿠버네티스 문서화에 기여하기와 관련된 보다 자세한 정보는, 다음을 살펴봅니다: +이 저장소를 사용하기 위해, 로컬에 다음의 소프트웨어들이 설치되어 있어야 합니다. -* [기여 시작하기](https://kubernetes.io/docs/contribute/start/) -* [문서화 변경 사항 스테이징하기](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [페이지 템플릿 사용하기](https://kubernetes.io/docs/contribute/style/page-content-types/) -* [문서화 스타일 가이드](http://kubernetes.io/docs/contribute/style/style-guide/) -* [쿠버네티스 문서화 로컬라이징](https://kubernetes.io/docs/contribute/localization/) +- [npm](https://www.npmjs.com/) +- [Go](https://golang.org/) +- [Hugo(확장 버전)](https://gohugo.io/) +- [도커](https://www.docker.com/)와 같은 컨테이너 런타임. -## `README.md`에 대한 쿠버네티스 문서화 번역 +시작하기 전에 의존성이 있는 소프트웨어를 설치합니다. 저장소를 복제(clone)하고 디렉터리로 이동합니다. -### 한국어 - -`README.md` 번역 및 한국어 기여자를 위한 보다 자세한 가이드를 [한국어 README](README-ko.md) 페이지 혹은 [쿠버네티스 문서 한글화 가이드](https://kubernetes.io/ko/docs/contribute/localization_ko/)에서 살펴봅니다. - -한국어 번역 메인테이너에게 다음을 통해 연락 가능합니다. - -* 이덕준 ([GitHub - @gochist](https://github.com/gochist)) -* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-ko) - -## 도커를 사용하여 사이트를 로컬에서 실행하기 - -쿠버네티스 웹사이트를 로컬에서 실행하기 위한 추천하는 방식은 [Hugo](https://gohugo.io) 정적 사이트 생성기를 포함하는 특별한 [도커](https://docker.com) 이미지를 실행하는 것입니다. - -> Windows에서 실행하는 경우, [Chocolatey](https://chocolatey.org)로 설치할 수 있는 명명 추가 도구를 필요로 할 것입니다. `choco install make` - -> 도커를 사용하지 않고 웹사이트를 로컬에서 실행하기를 선호하는 경우에는, 아래 [Hugo를 사용한 로컬 사이트 실행하기](#hugo를-사용한-로컬-사이트-실행하기)를 살펴봅니다. - -도커 [동작 및 실행](https://www.docker.com/get-started) 환경이 있는 경우, 로컬에서 `kubernetes-hugo` 도커 이미지를 빌드 합니다: - -```bash -make container-image +``` +git clone https://github.com/kubernetes/website.git +cd website ``` -해당 이미지가 빌드 된 이후, 사이트를 로컬에서 실행할 수 있습니다: +쿠버네티스 웹사이트는 [Docsy Hugo 테마](https://github.com/google/docsy#readme)를 사용합니다. 웹사이트를 컨테이너에서 실행하려는 경우에도, 다음을 실행하여 하위 모듈 및 기타 개발 종속성을 가져오는 것이 좋습니다. -```bash +``` +# Docsy 하위 모듈 가져오기 +git submodule update --init --recursive --depth 1 +``` + +## 컨테이너를 사용하여 웹사이트 실행하기 + +컨테이너에서 사이트를 빌드하려면, 다음을 실행하여 컨테이너 이미지를 빌드하고 실행합니다. + +``` +make container-image make container-serve ``` -브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다. +웹사이트를 보려면 브라우저를 http://localhost:1313 으로 엽니다. 소스 파일을 변경하면 Hugo가 웹사이트를 업데이트하고 브라우저를 강제로 새로 고칩니다. -## Hugo를 사용한 로컬 사이트 실행하기 +## Hugo를 사용하여 로컬에서 웹사이트 실행하기 -Hugo 설치 안내를 위해서는 [공식 Hugo 문서화](https://gohugo.io/getting-started/installing/)를 살펴봅니다. [`netlify.toml`](netlify.toml#L9) 파일에 있는 `HUGO_VERSION` 환경 변수에서 지정된 Hugo 버전이 설치되었는지를 확인합니다. +[`netlify.toml`](netlify.toml#L10) 파일의 `HUGO_VERSION` 환경 변수에 지정된 Hugo 확장 버전을 설치해야 합니다. -Hugo가 설치되었을 때 로컬에서 사이트를 실행하기 위해 (다음을 실행합니다): +사이트를 로컬에서 빌드하고 테스트하려면, 다음을 실행합니다. ```bash +# 의존성 있는 소프트웨어 설치 +npm ci make serve ``` -이를 통해 로컬 Hugo 서버를 1313번 포트에 시작합니다. 브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다. +그러면 포트 1313에서 로컬 Hugo 서버가 시작됩니다. 웹사이트를 보려면 http://localhost:1313 으로 브라우저를 엽니다. 소스 파일을 변경하면, Hugo가 웹사이트를 업데이트하고 브라우저를 강제로 새로 고칩니다. -## 감사합니다! +## 문제 해결 +### 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` 라는 단어를 찾습니다. + +### too many open files 이슈에 대한 macOS 문제 해결 + +macOS에서 `make serve` 를 실행하면 다음의 오류 메시지가 출력됩니다. + +``` +ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files +make: *** [serve] Error 1 +``` + +파일 오픈 개수에 대한 현재 제한값을 확인합니다. + +`launchctl limit maxfiles` + +그리고 다음의 명령을 실행합니다(https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c 를 참고하여 적용). + +``` +#!/bin/sh + +# 코멘트 처리한 것은 원래 gist 링크들이며, 그 아래는 수정된 tombigel의 gist 링크입니다. +# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist +# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist + +curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist +curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist + +sudo mv limit.maxfiles.plist /Library/LaunchDaemons +sudo mv limit.maxproc.plist /Library/LaunchDaemons + +sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist +sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist + +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://groups.google.com/forum/#!forum/kubernetes-sig-docs) + +# 문서에 기여하기 + +이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭하면 됩니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다. + +여러분의 풀 리퀘스트가 생성된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** + +또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황이거나, 또는 원래 여러분에게 피드백을 제공하기로 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황도 있습니다. + +그뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다. + +쿠버네티스 문서화에 기여하기와 관련된 보다 자세한 정보는, 다음을 참고합니다. + +* [쿠버네티스 문서에 기여하기](https://kubernetes.io/docs/contribute/) +* [페이지 콘텐트 타입](https://kubernetes.io/docs/contribute/style/page-content-types/) +* [문서화 스타일 가이드](http://kubernetes.io/docs/contribute/style/style-guide/) +* [쿠버네티스 문서 현지화](https://kubernetes.io/docs/contribute/localization/) + +# `README.md`에 대한 쿠버네티스 문서 현지화(localization) + +## 한국어 + +`README.md` 번역 및 한국어 기여자를 위한 보다 자세한 가이드는 [쿠버네티스 문서 한글화 가이드](https://kubernetes.io/ko/docs/contribute/localization_ko/)를 참고합니다. + +한국어 번역 메인테이너에게 다음을 통해 연락할 수 있습니다. + +* 손석호 ([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)을 따릅니다. + +# 감사합니다! + +쿠버네티스는 커뮤니티 참여를 통해 번창하며, 우리는 웹사이트 및 문서화에 대한 당신의 기여에 감사드립니다! diff --git a/README-pl.md b/README-pl.md index 166bc5ef4e..7d89d518cb 100644 --- a/README-pl.md +++ b/README-pl.md @@ -17,7 +17,7 @@ Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz * [Jak rozpocząć współpracę](https://kubernetes.io/docs/contribute/start/) * [Podgląd wprowadzanych zmian w dokumentacji](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Szablony stron](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Szablony stron](https://kubernetes.io/docs/contribute/style/page-content-types/) * [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/) * [Lokalizacja dokumentacji Kubernetes](https://kubernetes.io/docs/contribute/localization/) diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 3c598673ad..5eb26c2e54 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -71,6 +71,22 @@ body.td-404 main .error-details { max-width: 80%; border: 1px solid rgb(222, 226, 230); border-radius: 5px; + margin-bottom: 1rem; + padding-top: 1rem; + padding-bottom: 1rem; + + // mermaid diagram - sequence diagram + .actor { + fill: #326ce5 !important; + } + text.actor { + font-size: 18px !important; + stroke: white !important; + fill: white !important; + } + .activation0 { + fill: #c9e9ec !important; + } } /* HEADER */ diff --git a/content/de/docs/concepts/architecture/nodes.md b/content/de/docs/concepts/architecture/nodes.md index 8f3cd0f785..b790e68035 100644 --- a/content/de/docs/concepts/architecture/nodes.md +++ b/content/de/docs/concepts/architecture/nodes.md @@ -6,7 +6,7 @@ weight: 10 -Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes, früher als `minion` bekannt. Ein Node +Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes. Ein Node kann je nach Cluster eine VM oder eine physische Maschine sein. Jeder Node enthält die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste und wird von den Master-Komponenten verwaltet. diff --git a/content/en/blog/_posts/2020-12-02-dockershim-faq.md b/content/en/blog/_posts/2020-12-02-dockershim-faq.md new file mode 100644 index 0000000000..cbdd5cd680 --- /dev/null +++ b/content/en/blog/_posts/2020-12-02-dockershim-faq.md @@ -0,0 +1,180 @@ +--- +layout: blog +title: "Dockershim Deprecation FAQ" +date: 2020-12-02 +slug: dockershim-faq +aliases: [ '/dockershim' ] +--- + +This document goes over some frequently asked questions regarding the Dockershim +depreaction announced as a part of the Kubernetes v1.20 release. For more detail +on the deprecation of Docker as a container runtime for Kubernetes kubelets, and +what that means, check out the blog post +[Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/). + +### Why is dockershim being deprecated? + +Maintaining dockershim has become a heavy burden on the Kubernetes maintainers. +The CRI standard was created to reduce this burden and allow smooth interoperability +of different container runtimes. Docker itself doesn't currently implement CRI, +thus the problem. + +Dockershim was always intended to be a temporary solution (hence the name: shim). +You can read more about the community discussion and planning in the +[Dockershim Removal Kubernetes Enhancement Proposal][drkep]. + +Additionally, features that were largely incompatible with the dockershim, such +as cgroups v2 and user namespaces are being implemented in these newer CRI +runtimes. Removing support for the dockershim will allow further development in +those areas. + +[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim + +### Can I still use Docker in Kubernetes 1.20? + +Yes, the only thing changing in 1.20 is a single warning log printed at [kubelet] +startup if using Docker as the runtime. + +[kubelet]: /docs/reference/command-line-tools-reference/kubelet/ + + +### When will dockershim be removed? + +Given the impact of this change, we are using an extended deprecation timeline. +It will not be removed before Kubernetes 1.22, meaning the earliest release without +dockershim would be 1.23 in late 2021. We will be working closely with vendors +and other ecosystem groups to ensure a smooth transition and will evaluate things +as the situation evolves. + + +### Will my existing Docker images still work? + +Yes, the images produced from `docker build` will work with all CRI implementations. +All your existing images will still work exactly the same. + + +### What about private images? + +Also yes. All CRI runtimes support the same pull secrets configuration used in +Kubernetes, either via the PodSpec or ServiceAccount. + + +### Are Docker and containers the same thing? + +Docker popularized the Linux containers pattern and has been instrumental in +developing the underlying technology, however containers in Linux have existed +for a long time. The container ecosystem has grown to be much broader than just +Docker. Standards like OCI and CRI have helped many tools grow and thrive in our +ecosystem, some replacing aspects of Docker while others enhance existing +functionality. + + +### Are there examples of folks using other runtimes in production today? + +All Kubernetes project produced artifacts (Kubernetes binaries) are validated +with each release. + +Additionally, the [kind] project has been using containerd for some time and has +seen an improvement in stability for its use case. Kind and containerd are leveraged +multiple times every day to validate any changes to the Kubernetes codebase. Other +related projects follow a similar pattern as well, demonstrating the stability and +usability of other container runtimes. As an example, OpenShift 4.x has been +using the [CRI-O] runtime in production since June 2019. + +For other examples and references you can look at the adopters of containerd and +cri-o, two container runtimes under the Cloud Native Computing Foundation ([CNCF]). +- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md) +- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md) + +[CRI-O]: https://cri-o.io/ +[kind]: https://kind.sigs.k8s.io/ +[CNCF]: https://cncf.io + + +### People keep referencing OCI, what is that? + +OCI stands for the [Open Container Initiative], which standardized many of the +interfaces between container tools and technologies. They maintain a standard +specification for packaging container images (OCI image-spec) and running containers +(OCI runtime-spec). They also maintain an actual implementation of the runtime-spec +in the form of [runc], which is the underlying default runtime for both +[containerd] and [CRI-O]. The CRI builds on these low-level specifications to +provide an end-to-end standard for managing containers. + +[Open Container Initative]: https://opencontainers.org/about/overview/ +[runc]: https://github.com/opencontainers/runc +[containerd]: https://containerd.io/ + + +### Which CRI implementation should I use? + +That’s a complex question and it depends on a lot of factors. If Docker is +working for you, moving to containerd should be a relatively easy swap and +has have strictly better performance and less overhead. However we encourage you +to explore all the options from the [CNCF landscape] in case another would be an +even better fit for your environment. + +[CNCF landscape]: https://landscape.cncf.io/category=container-runtime&format=card-mode&grouping=category + + +### What should I look out for when changing CRI implementations? + +While the underlying containerization code is the same between Docker and most +CRIs (including containerd), there are a few differences around the edges. Some +common things to consider when migrating are: + +- Logging configuration +- Runtime resource limitations +- Node provisioning scripts that call docker or use docker via it's control socket +- Kubectl plugins that require docker CLI or the control socket +- Kubernetes tools that require direct access to Docker (e.g. kube-imagepuller) +- Configuration of functionality like `registry-mirrors` and insecure registries +- Other support scripts or daemons that expect docker to be available and are run + outside of Kubernetes (e.g. monitoring or security agents) +- GPUs or special hardware and how they integrate with your runtime and Kubernetes + +If you use Kubernetes resource requests/limits or file-based log collection +DaemonSets then they will continue to work the same, but if you’ve customized +your dockerd configuration, you’ll need to adapt that for your new container +runtime where possible. + +Another thing to look out for is anything expecting to run for system maintenance +or nested inside a container when building images will no longer work. For the +former, you can use the [`crictl`][cr] tool as a drop-in replacement and for the +latter you can use newer container build options like [img], [buildah], or +[kaniko] that don’t require Docker. + +[cr]: https://github.com/kubernetes-sigs/cri-tools +[img]: https://github.com/genuinetools/img +[buildah]: https://github.com/containers/buildah +[kaniko]: https://github.com/GoogleContainerTools/kaniko + +For containerd, you can start with their [documentation] to see what configuration +options are available as you migrate things over. + +[documentation]: https://github.com/containerd/cri/blob/master/docs/registry.md + +For instructions on how to use containerd and CRI-O with Kubernetes, see the +Kubernetes documentation on [Container Runtimes] + +[Container Runtimes]: /docs/setup/production-environment/container-runtimes + + +### What if I have more questions? + +If you use a vendor-supported Kubernetes distribution, you can ask them about +upgrade plans for their products. For end-user questions, please post them +to our end user community forum: https://discuss.kubernetes.io/. + +You can also check out the excellent blog post +[Wait, Docker is deprecated in Kubernetes now?][dep] a more in-depth technical +discussion of the changes. + +[dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m + + +### Can I have a hug? + +Always and whenever you want! 🤗🤗 + + diff --git a/content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md new file mode 100644 index 0000000000..e6df8971a6 --- /dev/null +++ b/content/en/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -0,0 +1,104 @@ +--- +layout: blog +title: "Don't Panic: Kubernetes and Docker" +date: 2020-12-02 +slug: dont-panic-kubernetes-and-docker +--- + +**Authors:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas + +Kubernetes is [deprecating +Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation) +as a container runtime after v1.20. + +**You do not need to panic. It’s not as dramatic as it sounds.** + +tl;dr Docker as an underlying runtime is being deprecated in favor of runtimes +that use the [Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) +created for Kubernetes. Docker-produced images will continue to work in your +cluster with all runtimes, as they always have. + +If you’re an end-user of Kubernetes, not a whole lot will be changing for you. +This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or +shouldn’t, use Docker as a development tool anymore. Docker is still a useful +tool for building containers, and the images that result from running `docker +build` can still run in your Kubernetes cluster. + +If you’re using a managed Kubernetes service like GKE, EKS, or AKS (which [defaults to containerd](https://github.com/Azure/AKS/releases/tag/2020-11-16)) you will need to +make sure your worker nodes are using a supported container runtime before +Docker support is removed in a future version of Kubernetes. If you have node +customizations you may need to update them based on your environment and runtime +requirements. Please work with your service provider to ensure proper upgrade +testing and planning. + +If you’re rolling your own clusters, you will also need to make changes to avoid +your clusters breaking. At v1.20, you will get a deprecation warning for Docker. +When Docker runtime support is removed in a future release (currently planned +for the 1.22 release in late 2021) of Kubernetes it will no longer be supported +and you will need to switch to one of the other compliant container runtimes, +like containerd or CRI-O. Just make sure that the runtime you choose supports +the docker daemon configurations you currently use (e.g. logging). + +## So why the confusion and what is everyone freaking out about? + +We’re talking about two different environments here, and that’s creating +confusion. Inside of your Kubernetes cluster, there’s a thing called a container +runtime that’s responsible for pulling and running your container images. Docker +is a popular choice for that runtime (other common options include containerd +and CRI-O), but Docker was not designed to be embedded inside Kubernetes, and +that causes a problem. + +You see, the thing we call “Docker” isn’t actually one thing -- it’s an entire +tech stack, and one part of it is a thing called “containerd,” which is a +high-level container runtime by itself. Docker is cool and useful because it has +a lot of UX enhancements that make it really easy for humans to interact with +while we’re doing development work, but those UX enhancements aren’t necessary +for Kubernetes, because it isn’t a human. + +As a result of this human-friendly abstraction layer, your Kubernetes cluster +has to use another tool called Dockershim to get at what it really needs, which +is containerd. That’s not great, because it gives us another thing that has to +be maintained and can possibly break. What’s actually happening here is that +Dockershim is being removed from Kubelet as early as v1.23 release, which +removes support for Docker as a container runtime as a result. You might be +thinking to yourself, but if containerd is included in the Docker stack, why +does Kubernetes need the Dockershim? + +Docker isn’t compliant with CRI, the [Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/). +If it were, we wouldn’t need the shim, and this wouldn’t be a thing. But it’s +not the end of the world, and you don’t need to panic -- you just need to change +your container runtime from Docker to another supported container runtime. + +One thing to note: If you are relying on the underlying docker socket +(/var/run/docker.sock) as part of a workflow within your cluster today, moving +to a different runtime will break your ability to use it. This pattern is often +called Docker in Docker. There are lots of options out there for this specific +use case including things like +[kaniko](https://github.com/GoogleContainerTools/kaniko), +[img](https://github.com/genuinetools/img), and +[buildah](https://github.com/containers/buildah). + +## What does this change mean for developers, though? Do we still write Dockerfiles? Do we still build things with Docker? + +This change addresses a different environment than most folks use to interact +with Docker. The Docker installation you’re using in development is unrelated to +the Docker runtime inside your Kubernetes cluster. It’s confusing, I know. As a +developer, Docker is still useful to you in all the ways it was before this +change was announced. The image that Docker produces isn’t really a +Docker-specific image -- it’s an OCI ([Open Container Initiative](https://opencontainers.org/)) image. +Any OCI-compliant image, regardless of the tool you use to build it, will look +the same to Kubernetes. Both [containerd](https://containerd.io/) and +[CRI-O](https://cri-o.io/) know how to pull those images and run them. This is +why we have a standard for what containers should look like. + +So, this change is coming. It’s going to cause issues for some, but it isn’t +catastrophic, and generally it’s a good thing. Depending on how you interact +with Kubernetes, this could mean nothing to you, or it could mean a bit of work. +In the long run, it’s going to make things easier. If this is still confusing +for you, that’s okay -- there’s a lot going on here, Kubernetes has a lot of +moving parts, and nobody is an expert in 100% of it. We encourage any and all +questions regardless of experience level or complexity! Our goal is to make sure +everyone is educated as much as possible on the upcoming changes. `<3` We hope +this has answered most of your questions and soothed some anxieties! + +Looking for more answers? Check out our accompanying [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/). diff --git a/content/en/case-studies/newyorktimes/index.html b/content/en/case-studies/newyorktimes/index.html index ae57a9ec7d..74bc5af627 100644 --- a/content/en/case-studies/newyorktimes/index.html +++ b/content/en/case-studies/newyorktimes/index.html @@ -26,10 +26,9 @@ case_study_details:

Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.

-{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times">}} - - -
+{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times" >}} +{{< youtube DqS_IPw-c6o youtube-quote-sm >}} +{{< youtube Tm4VfJtOHt8 youtube-quote-sm >}} "I think once you get over the initial hump, things get a lot easier and actually a lot faster." {{< /case-studies/quote >}} diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index a124d788fd..184b40c8dc 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -158,6 +158,11 @@ tables to provide per-instance subnets to each host (which is limited to 50-100 entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the network complexity required to deploy Kubernetes at scale within AWS. +### Coil + +[Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking. +Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks. + ### Contiv [Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced. @@ -311,4 +316,4 @@ to run, and in both cases, the network provides one IP address per pod - as is s The early design of the networking model and its rationale, and some future plans are described in more detail in the -[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). \ No newline at end of file +[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). diff --git a/content/en/docs/concepts/cluster-administration/system-metrics.md b/content/en/docs/concepts/cluster-administration/system-metrics.md index cd3f22e441..e2e037ff88 100644 --- a/content/en/docs/concepts/cluster-administration/system-metrics.md +++ b/content/en/docs/concepts/cluster-administration/system-metrics.md @@ -104,7 +104,7 @@ The kubelet collects accelerator metrics through cAdvisor. To collect these metr The responsibility for collecting accelerator metrics now belongs to the vendor rather than the kubelet. Vendors must provide a container that collects metrics and exposes them to the metrics service (for example, Prometheus). -The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features:~:text= DisableAcceleratorUsageMetrics,-false) disables metrics collected by the kubelet. +The [`DisableAcceleratorUsageMetrics` feature gate](/docs/reference/command-line-tools-reference/feature-gates/) disables metrics collected by the kubelet, with a [timeline for enabling this feature by default](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria). ## Component metrics diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index 572072dd3e..c28e3e1133 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -137,7 +137,7 @@ See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-a documentation for more information on how service accounts work. You can also check the `automountServiceAccountToken` field and the `serviceAccountName` field of the -[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) for information on referencing service account from Pods. ### Docker config Secrets @@ -154,7 +154,7 @@ When using this Secret type, you have to ensure the Secret `data` field contains a `.dockercfg` key whose value is content of a `~/.dockercfg` file encoded in the base64 format. -The `kubernetes/dockerconfigjson` type is designed for storing a serialized +The `kubernetes.io/dockerconfigjson` type is designed for storing a serialized JSON that follows the same format rules as the `~/.docker/config.json` file which is a new format for `~/.dockercfg`. When using this Secret type, the `data` field of the Secret object must @@ -248,7 +248,7 @@ configuration. The builtin type `kubernetes.io/ssh-auth` is provided for storing data used in SSH authentication. When using this Secret type, you will have to specify a -`ssh-privatekey` key-value pair in the `data` (or `stringData`) field. +`ssh-privatekey` key-value pair in the `data` (or `stringData`) field as the SSH credential to use. The following YAML is an example config for a SSH authentication Secret: @@ -349,22 +349,21 @@ data: usage-bootstrap-signing: dHJ1ZQ== ``` -A bootstrap type has the following keys specified under `data`: +A bootstrap type Secret has the following keys specified under `data`: - `token_id`: A random 6 character string as the token identifier. Required. - `token-secret`: A random 16 character string as the actual token secret. Required. -- `description1`: A human-readable string that describes what the token is +- `description`: A human-readable string that describes what the token is used for. Optional. - `expiration`: An absolute UTC time using RFC3339 specifying when the token should be expired. Optional. - `usage-bootstrap-`: A boolean flag indicating additional usage for the bootstrap token. - `auth-extra-groups`: A comma-separated list of group names that will be - authenticated as in addition to system:bootstrappers group. + authenticated as in addition to the `system:bootstrappers` group. The above YAML may look confusing because the values are all in base64 encoded -strings. In fact, you can create an identical Secret using the following YAML -which results in an identical Secret object: +strings. In fact, you can create an identical Secret using the following YAML: ```yaml apiVersion: v1 diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index be25fd4e14..99698668c4 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -84,7 +84,7 @@ Credentials can be provided in several ways: provider) can implement your mechanism for authenticating the node to the container registry. -These options are explaind in more detail below. +These options are explained in more detail below. ### Configuring nodes to authenticate to a private registry diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index ed89d1f5d1..506c76cde7 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/content/en/docs/concepts/overview/kubernetes-api.md @@ -77,19 +77,10 @@ about this format, see the [Kubernetes Protobuf serialization](https://github.co Interface Definition Language (IDL) files for each schema located in the Go packages that define the API objects. -## API changes +## Persistence -Any system that is successful needs to grow and change as new use cases emerge or existing ones change. -Therefore, Kubernetes has designed its features to allow the Kubernetes API to continuously change and grow. -The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that -compatibility for a length of time so that other projects have an opportunity to adapt. - -In general, new API resources and new resource fields can be added often and frequently. -Elimination of resources or fields requires following the -[API deprecation policy](/docs/reference/using-api/deprecation-policy/). - -What constitutes a compatible change, and how to change the API, are detailed in -[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). +Kubernetes stores the serialized state of objects by writing them into +{{< glossary_tooltip term_id="etcd" >}}. ## API groups and versioning @@ -107,17 +98,44 @@ To make it easier to evolve and to extend its API, Kubernetes implements [enabled or disabled](/docs/reference/using-api/#enabling-or-disabling). API resources are distinguished by their API group, resource type, namespace -(for namespaced resources), and name. The API server may serve the same -underlying data through multiple API version and handle the conversion between -API versions transparently. All these different versions are actually -representations of the same resource. For example, suppose there are two -versions `v1` and `v1beta1` for the same resource. An object created by the -`v1beta1` version can then be read, updated, and deleted by either the -`v1beta1` or the `v1` versions. +(for namespaced resources), and name. The API server handles the conversion between +API versions transparently: all the different versions are actually representations +of the same persisted data. The API server may serve the same underlying data +through multiple API versions. + +For example, suppose there are two API versions, `v1` and `v1beta1`, for the same +resource. If you originally created an object using the `v1beta1` version of its +API, you can later read, update, or delete that object +using either the `v1beta1` or the `v1` API version. + +### API changes + +Any system that is successful needs to grow and change as new use cases emerge or existing ones change. +Therefore, Kubernetes has designed the Kubernetes API to continuously change and grow. +The Kubernetes project aims to _not_ break compatibility with existing clients, and to maintain that +compatibility for a length of time so that other projects have an opportunity to adapt. + +In general, new API resources and new resource fields can be added often and frequently. +Elimination of resources or fields requires following the +[API deprecation policy](/docs/reference/using-api/deprecation-policy/). + +Kubernetes makes a strong commitment to maintain compatibility for official Kubernetes APIs +once they reach general availability (GA), typically at API version `v1`. Additionally, +Kubernetes keeps compatibility even for _beta_ API versions wherever feasible: +if you adopt a beta API you can continue to interact with your cluster using that API, +even after the feature goes stable. + +{{< note >}} +Although Kubernetes also aims to maintain compatibility for _alpha_ APIs versions, in some +circumstances this is not possible. If you use any alpha API versions, check the release notes +for Kubernetes when upgrading your cluster, in case the API did change. +{{< /note >}} Refer to [API versions reference](/docs/reference/using-api/#api-versioning) for more details on the API version level definitions. + + ## API Extension The Kubernetes API can be extended in one of two ways: @@ -135,3 +153,5 @@ The Kubernetes API can be extended in one of two ways: how the cluster manages authentication and authorization for API access. - Learn about API endpoints, resource types and samples by reading [API Reference](/docs/reference/kubernetes-api/). +- Learn about what constitutes a compatible change, and how to change the API, from + [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md index f8530ce546..560ab23dff 100644 --- a/content/en/docs/concepts/overview/working-with-objects/labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/labels.md @@ -140,10 +140,11 @@ partition !partition ``` -The first example selects all resources with key equal to `environment` and value equal to `production` or `qa`. -The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key. -The third example selects all resources including a label with key `partition`; no values are checked. -The fourth example selects all resources without a label with key `partition`; no values are checked. +* The first example selects all resources with key equal to `environment` and value equal to `production` or `qa`. +* The second example selects all resources with key equal to `tier` and values other than `frontend` and `backend`, and all resources with no labels with the `tier` key. +* The third example selects all resources including a label with key `partition`; no values are checked. +* The fourth example selects all resources without a label with key `partition`; no values are checked. + Similarly the comma separator acts as an _AND_ operator. So filtering resources with a `partition` key (no matter the value) and with `environment` different than  `qa` can be achieved using `partition,environment notin (qa)`. The _set-based_ label selector is a general form of equality since `environment=production` is equivalent to `environment in (production)`; similarly for `!=` and `notin`. diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md index 731d2bc263..079024c9d6 100644 --- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -32,15 +32,15 @@ You add a taint to a node using [kubectl taint](/docs/reference/generated/kubect For example, ```shell -kubectl taint nodes node1 key=value:NoSchedule +kubectl taint nodes node1 key1=value1:NoSchedule ``` -places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`. +places a taint on node `node1`. The taint has key `key1`, value `value1`, and taint effect `NoSchedule`. This means that no pod will be able to schedule onto `node1` unless it has a matching toleration. To remove the taint added by the command above, you can run: ```shell -kubectl taint nodes node1 key=value:NoSchedule- +kubectl taint nodes node1 key1=value1:NoSchedule- ``` You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the @@ -49,15 +49,15 @@ to schedule onto `node1`: ```yaml tolerations: -- key: "key" +- key: "key1" operator: "Equal" - value: "value" + value: "value1" effect: "NoSchedule" ``` ```yaml tolerations: -- key: "key" +- key: "key1" operator: "Exists" effect: "NoSchedule" ``` @@ -80,7 +80,7 @@ There are two special cases: An empty `key` with operator `Exists` matches all keys, values and effects which means this will tolerate everything. -An empty `effect` matches all effects with key `key`. +An empty `effect` matches all effects with key `key1`. {{< /note >}} diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md index 54f11beeff..df0e3ffd22 100644 --- a/content/en/docs/concepts/services-networking/ingress-controllers.md +++ b/content/en/docs/concepts/services-networking/ingress-controllers.md @@ -13,9 +13,8 @@ Unlike other types of controllers which run as part of the `kube-controller-mana are not started automatically with a cluster. Use this page to choose the ingress controller implementation that best fits your cluster. -Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and - [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers. - +Kubernetes as a project supports and maintains [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme), and + [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) ingress controllers. @@ -24,31 +23,31 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i {{% thirdparty-content %}} -* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). -* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress - controller with [community](https://www.getambassador.io/docs) or - [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/). -* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](https://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). -* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/). -* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller - provided and supported by VMware. -* Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments. -* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508) - for the [F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/). -* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io). -* [HAProxy Ingress](https://haproxy-ingress.github.io) is a highly customizable community-driven ingress controller for HAProxy. -* [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/). -* [Istio](https://istio.io/) based ingress controller - [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/). -* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or - [commercial](https://konghq.com/kong-enterprise/) support and maintenance for the - [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller). -* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the - [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller). -* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy -* [Traefik](https://github.com/traefik/traefik) is a fully featured ingress controller - ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial - support by [Traefik Labs](https://traefik.io). +* [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). +* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress + controller. +* The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with + Citrix Application Delivery Controller. +* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller. +* F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/) + lets you use an Ingress to configure F5 BIG-IP virtual servers. +* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io), + which offers API gateway functionality. +* [HAProxy Ingress](https://haproxy-ingress.github.io/) is an ingress controller for + [HAProxy](http://www.haproxy.org/#desc). +* The [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress#readme) + is also an ingress controller for [HAProxy](http://www.haproxy.org/#desc). +* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/) + is an [Istio](https://istio.io/) based ingress controller. +* The [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme) + is an ingress controller driving [Kong Gateway](https://konghq.com/kong/). +* The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) + works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy). +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy. +* The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an + ingress controller for the [Traefik](https://traefik.io/traefik/) proxy. +* [Voyager](https://appscode.com/products/voyager) is an ingress controller for + [HAProxy](http://www.haproxy.org/#desc). ## Using multiple Ingress controllers diff --git a/content/en/docs/concepts/storage/ephemeral-volumes.md b/content/en/docs/concepts/storage/ephemeral-volumes.md index 30029eae12..9b0b9464f5 100644 --- a/content/en/docs/concepts/storage/ephemeral-volumes.md +++ b/content/en/docs/concepts/storage/ephemeral-volumes.md @@ -46,7 +46,7 @@ different purposes: [downwardAPI](/docs/concepts/storage/volumes/#downwardapi), [secret](/docs/concepts/storage/volumes/#secret): inject different kinds of Kubernetes data into a Pod -- [CSI ephemeral volumes](#csi-ephemeral-volume): +- [CSI ephemeral volumes](#csi-ephemeral-volumes): similar to the previous volume kinds, but provided by special [CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md) which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md index 8ead92d2bd..5bd954dcef 100644 --- a/content/en/docs/concepts/workloads/pods/_index.md +++ b/content/en/docs/concepts/workloads/pods/_index.md @@ -172,14 +172,18 @@ spec: # The pod template ends here ``` -Modifying the pod template or switching to a new pod template has no effect on the -Pods that already exist. Pods do not receive template updates directly. Instead, -a new Pod is created to match the revised pod template. +Modifying the pod template or switching to a new pod template has no direct effect +on the Pods that already exist. If you change the pod template for a workload +resource, that resource needs to create replacement Pods that use the updated template. -For example, the deployment controller ensures that the running Pods match the current -pod template for each Deployment object. If the template is updated, the Deployment has -to remove the existing Pods and create new Pods based on the updated template. Each workload -resource implements its own rules for handling changes to the Pod template. +For example, the StatefulSet controller ensures that the running Pods match the current +pod template for each StatefulSet object. If you edit the StatefulSet to change its pod +template, the StatefulSet starts to create new Pods based on the updated template. +Eventually, all of the old Pods are replaced with new Pods, and the update is complete. + +Each workload resource implements its own rules for handling changes to the Pod template. +If you want to read more about StatefulSet specifically, read +[Update strategy](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) in the StatefulSet Basics tutorial. On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index c208c3f2dc..c385a15fda 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -282,7 +282,33 @@ from the OAuth2 [token response](https://openid.net/specs/openid-connect-core-1_ as a bearer token. See [above](#putting-a-bearer-token-in-a-request) for how the token is included in a request. -![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg) +{{< mermaid >}} +sequenceDiagram + participant user as User + participant idp as Identity Provider + participant kube as Kubectl + participant api as API Server + + user ->> idp: 1. Login to IdP + activate idp + idp -->> user: 2. Provide access_token,
id_token, and refresh_token + deactivate idp + activate user + user ->> kube: 3. Call Kubectl
with --token being the id_token
OR add tokens to .kube/config + deactivate user + activate kube + kube ->> api: 4. Authorization: Bearer... + deactivate kube + activate api + api ->> api: 5. Is JWT signature valid? + api ->> api: 6. Has the JWT expired? (iat+exp) + api ->> api: 7. User authorized? + api -->> kube: 8. Authorized: Perform
action and return result + deactivate api + activate kube + kube --x user: 9. Return result + deactivate kube +{{< /mermaid >}} 1. Login to your identity provider 2. Your identity provider will provide you with an `access_token`, `id_token` and a `refresh_token` @@ -328,7 +354,7 @@ tokens on behalf of another. Kubernetes does not provide an OpenID Connect Identity Provider. You can use an existing public OpenID Connect Identity Provider (such as Google, or [others](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)). -Or, you can run your own Identity Provider, such as CoreOS [dex](https://github.com/coreos/dex), +Or, you can run your own Identity Provider, such as [dex](https://dexidp.io/), [Keycloak](https://github.com/keycloak/keycloak), CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or Tremolo Security's [OpenUnison](https://github.com/tremolosecurity/openunison). @@ -339,7 +365,7 @@ For an identity provider to work with Kubernetes it must: 2. Run in TLS with non-obsolete ciphers 3. Have a CA signed certificate (even if the CA is not a commercial CA or is self signed) -A note about requirement #3 above, requiring a CA signed certificate. If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed. This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation. If you don't have a CA handy, you can use [this script](https://github.com/coreos/dex/blob/1ee5920c54f5926d6468d2607c728b71cfe98092/examples/k8s/gencert.sh) from the CoreOS team to create a simple CA and a signed certificate and key pair. +A note about requirement #3 above, requiring a CA signed certificate. If you deploy your own identity provider (as opposed to one of the cloud providers like Google or Microsoft) you MUST have your identity provider's web server certificate signed by a certificate with the `CA` flag set to `TRUE`, even if it is self signed. This is due to GoLang's TLS client implementation being very strict to the standards around certificate validation. If you don't have a CA handy, you can use [this script](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh) from the Dex team to create a simple CA and a signed certificate and key pair. Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh) that generates SHA256 certs with a longer life and larger key size. Setup instructions for specific systems: diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index e20826ca43..8ff32aa54e 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -90,6 +90,13 @@ kubectl apply -f ./my1.yaml -f ./my2.yaml # create from multiple files kubectl apply -f ./dir # create resource(s) in all manifest files in dir kubectl apply -f https://git.io/vPieo # create resource(s) from url kubectl create deployment nginx --image=nginx # start a single instance of nginx + +# create a Job which prints "Hello World" +kubectl create job hello --image=busybox -- echo "Hello World" + +# create a CronJob that prints "Hello World" every minute +kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello World" + kubectl explain pods # get the documentation for pod manifests # Create multiple YAML objects from stdin diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index 6abc42c131..6da8963f17 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -32,7 +32,7 @@ The cluster that `kubeadm init` and `kubeadm join` set up should be: - `kubeadm init` - `export KUBECONFIG=/etc/kubernetes/admin.conf` - `kubectl apply -f ` - - `kubeadm join --token :` + - `kubeadm join --token :` - **Extendable**: - It should _not_ favor any particular network provider. Configuring the cluster network is out-of-scope - It should provide the possibility to use a config file for customizing various parameters @@ -206,7 +206,7 @@ Please note that: 1. All images will be pulled from k8s.gcr.io by default. See [using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images) for customizing the image repository 2. In case of kubeadm is executed in the `--dry-run` mode, static Pods files are written in a temporary folder -3. Static Pod manifest generation for master components can be invoked individually with the [`kubeadm init phase control-plane all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) command +3. Static Pod manifest generation for control plane components can be invoked individually with the [`kubeadm init phase control-plane all`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-control-plane) command #### API server @@ -344,7 +344,7 @@ state and make new decisions based on that data. Please note that: 1. Before saving the ClusterConfiguration, sensitive information like the token is stripped from the configuration -2. Upload of master configuration can be invoked individually with the [`kubeadm init phase upload-config`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-upload-config) command +2. Upload of control plane node configuration can be invoked individually with the [`kubeadm init phase upload-config`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-upload-config) command ### Mark the node as control-plane @@ -355,7 +355,7 @@ As soon as the control plane is available, kubeadm executes following actions: Please note that: -1. Mark control-plane phase phase can be invoked individually with the [`kubeadm init phase mark-control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-master) command +1. Mark control-plane phase phase can be invoked individually with the [`kubeadm init phase mark-control-plane`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-mark-control-plane) command ### Configure TLS-Bootstrapping for node joining @@ -415,7 +415,7 @@ Additionally it creates a Role and a RoleBinding granting access to the ConfigMa Please note that: -1. The access to the `cluster-info` ConfigMap _is not_ rate-limited. This may or may not be a problem if you expose your master +1. The access to the `cluster-info` ConfigMap _is not_ rate-limited. This may or may not be a problem if you expose your cluster's API server to the internet; worst-case scenario here is a DoS attack where an attacker uses all the in-flight requests the kube-apiserver can handle to serving the `cluster-info` ConfigMap. @@ -430,8 +430,8 @@ Please note that: A ServiceAccount for `kube-proxy` is created in the `kube-system` namespace; then kube-proxy is deployed as a DaemonSet: -- The credentials (`ca.crt` and `token`) to the master come from the ServiceAccount -- The location of the master comes from a ConfigMap +- The credentials (`ca.crt` and `token`) to the control plane come from the ServiceAccount +- The location (URL) of the API server comes from a ConfigMap - The `kube-proxy` ServiceAccount is bound to the privileges in the `system:node-proxier` ClusterRole #### DNS diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md index 501e954642..fce6518eb2 100644 --- a/content/en/docs/setup/best-practices/multiple-zones.md +++ b/content/en/docs/setup/best-practices/multiple-zones.md @@ -33,7 +33,7 @@ support running as a pool of interchangable resources, replicated per component. When you deploy a cluster control plane, place replicas of -control plane components across multple failure zones. If availability is +control plane components across multiple failure zones. If availability is an important concern, select at least three failure zones and replicate each individual control plane component (API server, scheduler, etcd, cluster controller manager) across at least three failure zones. @@ -111,7 +111,7 @@ see [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topolog ## Networking By itself, Kubernetes does not include zone-aware networking. You can use a -[network plugin](docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +[network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) to configure cluster networking, and that network solution might have zone-specific elements. For example, if your cloud provider supports Services with `type=LoadBalancer`, the load balancer might only send traffic to Pods running in the @@ -126,7 +126,7 @@ of different failure zones, does vary depending on exactly how your cluster is s ## Fault recovery When you set up your cluster, you might also need to consider whether and how -your setup can restore service if all of the failure zones in a region go +your setup can restore service if all the failure zones in a region go off-line at the same time. For example, do you rely on there being at least one node able to run Pods in a zone? Make sure that any cluster-critical repair work does not rely diff --git a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md index 4ea12f5ca2..6c9c05cc90 100644 --- a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -68,7 +68,7 @@ spec: command: - powershell.exe - -command - - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " + - "<#code used from https://gist.github.com/19WAS85/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " nodeSelector: kubernetes.io/os: windows ``` diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 0384ff8dbb..5896ab8357 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -330,8 +330,8 @@ seconds. Minimum value is 1. * `timeoutSeconds`: Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. * `successThreshold`: Minimum consecutive successes for the probe to be -considered successful after having failed. Defaults to 1. Must be 1 for -liveness. Minimum value is 1. +considered successful after having failed. Defaults to 1. Must be 1 for liveness +and startup Probes. Minimum value is 1. * `failureThreshold`: When a probe fails, Kubernetes will try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1. diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md index a5346f0272..f1738ff53e 100644 --- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md @@ -15,8 +15,9 @@ weight: 30 This page shows how to run a replicated stateful application using a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) controller. -The example is a MySQL single-master topology with multiple slaves running -asynchronous replication. +This application is a replicated MySQL database. The example topology has a +single primary server and multiple replicas, using asynchronous row-based +replication. {{< note >}} **This is not a production configuration**. MySQL settings remain on insecure defaults to keep the focus @@ -69,9 +70,9 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml ``` This ConfigMap provides `my.cnf` overrides that let you independently control -configuration on the MySQL master and slaves. -In this case, you want the master to be able to serve replication logs to slaves -and you want slaves to reject any writes that don't come via replication. +configuration on the primary MySQL server and replicas. +In this case, you want the primary server to be able to serve replication logs to replicas +and you want replicas to reject any writes that don't come via replication. There's nothing special about the ConfigMap itself that causes different portions to apply to different Pods. @@ -96,12 +97,12 @@ cluster and namespace. The Client Service, called `mysql-read`, is a normal Service with its own cluster IP that distributes connections across all MySQL Pods that report -being Ready. The set of potential endpoints includes the MySQL master and all -slaves. +being Ready. The set of potential endpoints includes the primary MySQL server and all +replicas. Note that only read queries can use the load-balanced Client Service. -Because there is only one MySQL master, clients should connect directly to the -MySQL master Pod (through its DNS entry within the Headless Service) to execute +Because there is only one primary MySQL server, clients should connect directly to the +primary MySQL Pod (through its DNS entry within the Headless Service) to execute writes. ### StatefulSet @@ -167,33 +168,33 @@ This translates the unique, stable identity provided by the StatefulSet controller into the domain of MySQL server IDs, which require the same properties. -The script in the `init-mysql` container also applies either `master.cnf` or -`slave.cnf` from the ConfigMap by copying the contents into `conf.d`. -Because the example topology consists of a single MySQL master and any number of -slaves, the script simply assigns ordinal `0` to be the master, and everyone -else to be slaves. +The script in the `init-mysql` container also applies either `primary.cnf` or +`replica.cnf` from the ConfigMap by copying the contents into `conf.d`. +Because the example topology consists of a single primary MySQL server and any number of +replicas, the script simply assigns ordinal `0` to be the primary server, and everyone +else to be replicas. Combined with the StatefulSet controller's [deployment order guarantee](/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees/), -this ensures the MySQL master is Ready before creating slaves, so they can begin +this ensures the primary MySQL server is Ready before creating replicas, so they can begin replicating. ### Cloning existing data -In general, when a new Pod joins the set as a slave, it must assume the MySQL -master might already have data on it. It also must assume that the replication +In general, when a new Pod joins the set as a replica, it must assume the primary MySQL +server might already have data on it. It also must assume that the replication logs might not go all the way back to the beginning of time. These conservative assumptions are the key to allow a running StatefulSet to scale up and down over time, rather than being fixed at its initial size. The second Init Container, named `clone-mysql`, performs a clone operation on -a slave Pod the first time it starts up on an empty PersistentVolume. +a replica Pod the first time it starts up on an empty PersistentVolume. That means it copies all existing data from another running Pod, -so its local state is consistent enough to begin replicating from the master. +so its local state is consistent enough to begin replicating from the primary server. MySQL itself does not provide a mechanism to do this, so the example uses a popular open-source tool called Percona XtraBackup. During the clone, the source MySQL server might suffer reduced performance. -To minimize impact on the MySQL master, the script instructs each Pod to clone +To minimize impact on the primary MySQL server, the script instructs each Pod to clone from the Pod whose ordinal index is one lower. This works because the StatefulSet controller always ensures Pod `N` is Ready before starting Pod `N+1`. @@ -206,15 +207,15 @@ server, and an `xtrabackup` container that acts as a [sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). The `xtrabackup` sidecar looks at the cloned data files and determines if -it's necessary to initialize MySQL replication on the slave. +it's necessary to initialize MySQL replication on the replica. If so, it waits for `mysqld` to be ready and then executes the `CHANGE MASTER TO` and `START SLAVE` commands with replication parameters extracted from the XtraBackup clone files. -Once a slave begins replication, it remembers its MySQL master and +Once a replica begins replication, it remembers its primary MySQL server and reconnects automatically if the server restarts or the connection dies. -Also, because slaves look for the master at its stable DNS name -(`mysql-0.mysql`), they automatically find the master even if it gets a new +Also, because replicas look for the primary server at its stable DNS name +(`mysql-0.mysql`), they automatically find the primary server even if it gets a new Pod IP due to being rescheduled. Lastly, after starting replication, the `xtrabackup` container listens for @@ -224,7 +225,7 @@ case the next Pod loses its PersistentVolumeClaim and needs to redo the clone. ## Sending client traffic -You can send test queries to the MySQL master (hostname `mysql-0.mysql`) +You can send test queries to the primary MySQL server (hostname `mysql-0.mysql`) by running a temporary container with the `mysql:5.7` image and running the `mysql` client binary. @@ -291,7 +292,7 @@ it running in another window so you can see the effects of the following steps. ## Simulating Pod and Node downtime -To demonstrate the increased availability of reading from the pool of slaves +To demonstrate the increased availability of reading from the pool of replicas instead of a single server, keep the `SELECT @@server_id` loop from above running while you force a Pod out of the Ready state. @@ -409,9 +410,9 @@ Now uncordon the Node to return it to a normal state: kubectl uncordon ``` -## Scaling the number of slaves +## Scaling the number of replicas -With MySQL replication, you can scale your read query capacity by adding slaves. +With MySQL replication, you can scale your read query capacity by adding replicas. With StatefulSet, you can do this with a single command: ```shell diff --git a/content/en/examples/application/job/cronjob.yaml b/content/en/examples/application/job/cronjob.yaml index c9d3893027..3ca130289e 100644 --- a/content/en/examples/application/job/cronjob.yaml +++ b/content/en/examples/application/job/cronjob.yaml @@ -11,6 +11,7 @@ spec: containers: - name: hello image: busybox + imagePullPolicy: IfNotPresent args: - /bin/sh - -c diff --git a/content/en/examples/application/mysql/mysql-configmap.yaml b/content/en/examples/application/mysql/mysql-configmap.yaml index 46d34e422c..519334bc82 100644 --- a/content/en/examples/application/mysql/mysql-configmap.yaml +++ b/content/en/examples/application/mysql/mysql-configmap.yaml @@ -5,12 +5,12 @@ metadata: labels: app: mysql data: - master.cnf: | - # Apply this config only on the master. + primary.cnf: | + # Apply this config only on the primary. [mysqld] log-bin - slave.cnf: | - # Apply this config only on slaves. + replica.cnf: | + # Apply this config only on replicas. [mysqld] super-read-only diff --git a/content/en/examples/application/mysql/mysql-services.yaml b/content/en/examples/application/mysql/mysql-services.yaml index f538992566..0cd76d91c6 100644 --- a/content/en/examples/application/mysql/mysql-services.yaml +++ b/content/en/examples/application/mysql/mysql-services.yaml @@ -14,7 +14,7 @@ spec: app: mysql --- # Client service for connecting to any MySQL instance for reads. -# For writes, you must instead connect to the master: mysql-0.mysql. +# For writes, you must instead connect to the primary: mysql-0.mysql. apiVersion: v1 kind: Service metadata: diff --git a/content/en/examples/application/mysql/mysql-statefulset.yaml b/content/en/examples/application/mysql/mysql-statefulset.yaml index b69af02c59..bb61537fcf 100644 --- a/content/en/examples/application/mysql/mysql-statefulset.yaml +++ b/content/en/examples/application/mysql/mysql-statefulset.yaml @@ -29,9 +29,9 @@ spec: echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf # Copy appropriate conf.d files from config-map to emptyDir. if [[ $ordinal -eq 0 ]]; then - cp /mnt/config-map/master.cnf /mnt/conf.d/ + cp /mnt/config-map/primary.cnf /mnt/conf.d/ else - cp /mnt/config-map/slave.cnf /mnt/conf.d/ + cp /mnt/config-map/replica.cnf /mnt/conf.d/ fi volumeMounts: - name: conf @@ -47,7 +47,7 @@ spec: set -ex # Skip the clone if data already exists. [[ -d /var/lib/mysql/mysql ]] && exit 0 - # Skip the clone on master (ordinal index 0). + # Skip the clone on primary (ordinal index 0). [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} [[ $ordinal -eq 0 ]] && exit 0 @@ -108,12 +108,12 @@ spec: # Determine binlog position of cloned data, if any. if [[ -f xtrabackup_slave_info && "x$( change_master_to.sql.in # Ignore xtrabackup_binlog_info in this case (it's useless). rm -f xtrabackup_slave_info xtrabackup_binlog_info elif [[ -f xtrabackup_binlog_info ]]; then - # We're cloning directly from master. Parse binlog position. + # We're cloning directly from primary. Parse binlog position. [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1 rm -f xtrabackup_binlog_info xtrabackup_slave_info echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\ diff --git a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 1c45b2b071..4b8b736336 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -260,7 +260,7 @@ L'utilisation des deux peut garantir que le trafic n'atteigne pas un conteneur q * `periodSeconds`: La fréquence (en secondes) à laquelle la probe doit être effectuée. La valeur par défaut est de 10 secondes. La valeur minimale est de 1. * `timeoutSeconds`: Nombre de secondes après lequel la probe time out. Valeur par défaut à 1 seconde. La valeur minimale est de 1. * `successThreshold`: Le minimum de succès consécutifs pour que la probe soit considérée comme réussie après avoir échoué. La valeur par défaut est 1. Doit être 1 pour la liveness probe. La valeur minimale est de 1. -* `failureThreshold`: Quand un Pod démarre et que la probe échoue, Kubernetes va tenter pour un temps de `failureThreshold` avant d'abandonner. Abandonner en cas de liveness probe signifie le redémarrage du conteneur. En cas de readiness probe, le Pod sera marqué Unready. +* `failureThreshold`: Quand un Pod démarre et que la probe échoue, Kubernetes va tenter `failureThreshold` fois avant d'abandonner. Abandonner en cas de liveness probe signifie le redémarrage du conteneur. En cas de readiness probe, le Pod sera marqué Unready. La valeur par défaut est 3, la valeur minimum est 1. [HTTP probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) diff --git a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md index 78930a469a..714e48e943 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ja/docs/concepts/overview/working-with-objects/field-selectors.md @@ -46,7 +46,7 @@ kubectl get services --all-namespaces --field-selector metadata.namespace!=defa 下記の`kubectl`コマンドは、`status.phase`が`Runnning`でなく、かつ`spec.restartPolicy`フィールドが`Always`に等しいような全てのPodを選択します。 ```shell -kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default +kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always ``` ## 複数のリソースタイプ diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index e19c795d63..9e218fae53 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -65,7 +65,7 @@ spec: command: - powershell.exe - -command - - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count = $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " + - "<#code used from https://gist.github.com/19WAS85/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count = $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " nodeSelector: kubernetes.io/os: windows ``` diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 836b4a5b6b..b65cf13803 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -96,7 +96,17 @@ weight: 30 컨트롤러가 있다. [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 본다.) -## 원하는 상태와 현재 상태 {#desired-vs-current} +여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고, +현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다. +다른 컨트롤 루프는 보고된 데이터를 관찰하고 자체 조치를 할 수 있다. + +온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가 +서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는 +[쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해 +IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자 APIS 및 +기타 서비스 등과 간접적으로 연동하여 이를 구현한다. + +## 의도한 상태와 현재 상태 {#desired-vs-current} 쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인 변화에 대응할 수 있다. diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index daa1dfd702..ffeb3a58fb 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -47,7 +47,7 @@ no_list: true * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다. -* [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다. +* [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는 쿠버네티스가 자체 API에 대한 접근 제어를 구현하는 방법을 설명한다. * [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다. diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 4a0b700e02..48044b0460 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -22,7 +22,7 @@ weight: 60 이 섹션에서는, 쿠버네티스에서 표준 출력 스트림으로 데이터를 출력하는 기본 로깅의 예시를 볼 수 있다. 이 데모에서는 일부 텍스트를 초당 한 번씩 표준 출력에 쓰는 컨테이너와 함께 -[파드 명세](/examples/debug/counter-pod.yaml)를 사용한다. +파드 명세를 사용한다. {{< codenew file="debug/counter-pod.yaml" >}} diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index 63877bc535..9b378aed79 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -122,6 +122,10 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht 가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다. +### 캘리코 + +[캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다. + ### 실리움(Cilium) [실리움](https://github.com/cilium/cilium)은 애플리케이션 컨테이너 간에 @@ -289,14 +293,6 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에 특정 쿠버네티스 플러그인 및 문서가 있다. -### 프로젝트 캘리코 - -[프로젝트 캘리코](https://docs.projectcalico.org/)는 오픈소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다. - -캘리코는 리눅스(오픈소스)와 윈도우(독점 - [Tigera](https://www.tigera.io/essentials/)에서 사용 가능) 모두에서 인터넷과 동일한 IP 네트워킹 원칙을 기반으로 쿠버네티스 파드를 연결하기 위한 확장성이 뛰어난 네트워킹 및 네트워크 정책 솔루션을 제공한다. 캘리코는 캡슐화나 오버레이 없이 구축되어 고성능의 대규모 데이터센터 네트워킹을 제공할 수 있다. 또한 캘리코는 분산 방화벽을 통해 쿠버네티스 파드에 대해 세분화된 의도기반의 네트워크 보안 정책을 제공한다. - -캘리코는 플라넬, 일명 [canal](https://github.com/tigera/canal) 또는 네이티브 GCE, AWS나 Azure 네트워킹과 같은 다른 네트워킹 솔루션과 함께 정책 적용 모드로 실행될 수도 있다. - ### 로마나 [로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index 440da51dd8..e4dedb068a 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -97,6 +97,14 @@ some_counter 0 릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다. +## 액셀러레이터 메트릭 비활성화 + +kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVIDIA GPU와 같은 액셀러레이터의 경우, 이러한 메트릭을 수집하기 위해 kubelet은 드라이버에 열린 핸들을 가진다. 이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해 클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다. + +액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다. + +[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다. + ## 컴포넌트 메트릭 ### kube-controller-manager 메트릭 diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index a934d173d1..e75beb8666 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -12,51 +12,380 @@ weight: 30 쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은 민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이 -{{< glossary_tooltip term_id="pod" text="파드" >}} 정의나 -{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}} 내에 그대로 두는 것보다 안전하고 유연하다. 자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다. - +{{< glossary_tooltip term_id="pod" >}} 정의나 +{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}} +내에 그대로 두는 것보다 안전하고 유연하다. +자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다. +시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 +포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드 +명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도 +일부 시크릿을 만들 수 있다. ## 시크릿 개요 -시크릿은 비밀번호, 토큰 또는 키와 같은 소량의 -민감한 데이터를 포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 -파드 명세 또는 이미지에 포함될 수 있다. 사용자는 시크릿을 생성할 수 있으며 시스템도 -일부 시크릿을 생성한다. - 시크릿을 사용하려면, 파드가 시크릿을 참조해야 한다. 시크릿은 세 가지 방법으로 파드와 함께 사용할 수 있다. - 하나 이상의 컨테이너에 마운트된 -{{< glossary_tooltip text="볼륨" term_id="volume" >}} 내의 -[파일](#시크릿을-파드의-파일로-사용하기)로써 사용. + {{< glossary_tooltip text="볼륨" term_id="volume" >}} 내의 + [파일](#시크릿을-파드의-파일로-사용하기)로써 사용. - [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용. - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용. 시크릿 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다. +사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를 +명시할 수 있다. 해당 `data` 와 `stringData` 필드는 선택적으로 명시할 수 있다. +`data` 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다. +만약 사용자에게 base64로의 문자열 변환이 적합하지 않다면, +임의의 문자열을 값으로 받는 `stringData` 필드를 대신 사용할 수 있다. -`data` 와 `stringData` 의 키는 영숫자 및 `-`, `_` 또는 `.` 으로 -구성되어야 한다. +`data` 및 `stringData`의 키는 영숫자 문자, +`-`, `_`, 또는 `.` 으로 구성되어야 한다. `stringData` 필드의 모든 키-값 쌍은 의도적으로 +`data` 필드로 합쳐진다. 만약 키가 `data` 와 `stringData` 필드 모두에 정의되어 +있으면, `stringData` 필드에 지정된 값이 +우선적으로 사용된다. -### 빌트인 시크릿 +## 시크릿 타입 {#secret-types} -#### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함 +시크릿을 생성할 때, [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +리소스의 `type` 필드를 사용하거나, (활용 가능하다면) `kubectl` 의 +유사한 특정 커맨드라인 플래그를 사용하여 시크릿의 타입을 명시할 수 있다. +시크릿 타입은 시크릿 데이터의 프로그래믹 처리를 촉진시키기 위해 사용된다. -쿠버네티스는 API 접근을 위한 자격 증명이 포함된 -시크릿을 자동으로 생성하고 이러한 유형의 시크릿을 사용하도록 파드를 자동으로 -수정한다. +쿠버네티스는 일반적인 사용 시나리오를 위해 몇 가지 빌트인 타입을 제공한다. +이 타입은 쿠버네티스가 부과하여 수행되는 검증 및 제약에 +따라 달라진다. -원하는 경우 API 자격 증명의 자동 생성 및 사용을 비활성화하거나 -오버라이드할 수 있다. 그러나, API 서버에 안전하게 접근하기만 하면 되는 경우, -자동 생성 및 사용이 권장되는 워크플로이다. +| 빌트인 타입 | 사용처 | +|--------------|-------| +| `Opaque` | 임의의 사용자 정의 데이터 | +| `kubernetes.io/service-account-token` | 서비스 어카운트 토큰 | +| `kubernetes.io/dockercfg` | 직렬화 된(serialized) `~/.dockercfg` 파일 | +| `kubernetes.io/dockerconfigjson` | 직렬화 된 `~/.docker/config.json` 파일 | +| `kubernetes.io/basic-auth` | 기본 인증을 위한 자격 증명(credential) | +| `kubernetes.io/ssh-auth` | SSH를 위한 자격 증명 | +| `kubernetes.io/tls` | TLS 클라이언트나 서버를 위한 데이터 | +| `bootstrap.kubernetes.io/token` | 부트스트랩 토큰 데이터 | -서비스 어카운트 작동 방식에 대한 자세한 내용은 -[서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다. +사용자는 시크릿 오브젝트의 `type` 값에 비어 있지 않은 문자열을 할당하여 자신만의 시크릿 +타입을 정의하고 사용할 수 있다. 비어 있는 문자열은 `Opaque` 타입으로 인식된다. +쿠버네티스는 타입 명칭에 제약을 부과하지는 않는다. 그러나 만약 +빌트인 타입 중 하나를 사용한다면, 해당 타입에 정의된 모든 요구 사항을 +만족시켜야 한다. -### 시크릿 생성하기 +### 불투명(Opaque) 시크릿 + +`Opaque` 은 시크릿 구성 파일에서 누락된 경우의 기본 시크릿 타입이다. +`kubectl` 을 사용하여 시크릿을 생성할 때 `Opaque` 시크릿 타입을 나타내기 +위해서는 `generic` 하위 커맨드를 사용할 것이다. 예를 들어, 다음 커맨드는 +타입 `Opaque` 의 비어 있는 시크릿을 생성한다. + +```shell +kubectl create secret generic empty-secret +kubectl get secret empty-secret +``` + +출력은 다음과 같다. + +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s +``` + +해당 `DATA` 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다. +이 경우, `0` 은 비어 있는 시크릿을 방금 하나 생성하였다는 것을 의미한다. + +### 서비스 어카운트 토큰 시크릿 + +`kubernetes.io/service-account-token` 시크릿 타입은 서비스 어카운트를 확인하는 토큰을 저장하기 위해서 사용한다. 이 시크릿 타입을 사용할 때는, +`kubernetes.io/service-account.name` 어노테이션이 존재하는 서비스 +어카운트 이름으로 설정되도록 해야 한다. 쿠버네티스 컨트롤러는 +`kubernetes.io/service-account.uid` 및 실제 토큰 +콘텐츠로 설정된 `data` 필드의 `token` 키와 같은, +몇 가지 다른 필드들을 채운다. + +다음은 서비스 어카운트 토큰 시크릿의 구성 예시이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-sa-sample + annotations: + kubernetes.io/service-account.name: "sa-name" +type: kubernetes.io/service-account-token +data: + # 사용자는 불투명 시크릿을 사용하므로 추가적인 키 값 쌍을 포함할 수 있다. + extra: YmFyCg== +``` + +`Pod` 를 생성할 때, 쿠버네티스는 자동으로 서비스 어카운트 시크릿을 +생성하고 자동으로 파드가 해당 시크릿을 사용하도록 수정한다. 해당 서비스 +어카운트 토큰 시크릿은 API 접속을 위한 자격 증명을 포함한다. + +이러한 API 자격 증명의 자동 생성과 사용은 원하는 경우 해제하거나 +기각할 수 있다. 그러나 만약 사용자가 API 서버에 안전하게 접근하는 것만 +필요하다면, 이것이 권장되는 워크플로우이다. + +[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면 +서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다. +또한 파드에서 서비스 어카운트를 참조하는 방법을 +[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)의 +`automountServiceAccountToken` 필드와 `serviceAccountName` +필드를 통해 확인할 수 있다. + +### 도커 컨피그 시크릿 + +이미지에 대한 도커 레지스트리 접속 자격 증명을 저장하기 위한 +시크릿을 생성하기 위해서 다음의 `type` 값 중 하나를 사용할 수 있다. + +- `kubernetes.io/dockercfg` +- `kubernetes.io/dockerconfigjson` + +`kubernetes.io/dockercfg` 는 직렬화 된 도커 커맨드라인 구성을 +위한 기존(legacy) 포맷 `~/.dockercfg` 를 저장하기 위해 할당된 타입이다. +시크릿 타입을 사용할 때는, `data` 필드가 base64 포맷으로 +인코딩된 `~/.dockercfg` 파일의 콘텐츠를 값으로 가지는 `.dockercfg` 키를 포함하고 있는지 +확실히 확인해야 한다. + +`kubernetes/dockerconfigjson` 타입은 `~/.dockercfg` 의 +새로운 포맷인 `~/.docker/config.json` 파일과 동일한 포맷 법칙을 +따르는 직렬화 된 JSON의 저장을 위해 디자인되었다. +이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 `data` 필드가 `.dockerconfigjson` 키를 +꼭 포함해야 한다. `~/.docker/config.json` 파일을 위한 콘텐츠는 +base64로 인코딩된 문자열으로 제공되어야 한다. + +아래는 시크릿의 `kubernetes.io/dockercfg` 타입 예시이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-dockercfg +type: kubernetes.io/dockercfg +data: + .dockercfg: | + "" +``` + +{{< note >}} +만약 base64 인코딩 수행을 원하지 않는다면, 그 대신 `stringData` 필드의 +사용을 선택할 수 있다. +{{< /note >}} + +이러한 타입들을 매니페스트를 사용하여 생성하는 경우, API +서버는 해당 `data` 필드에 기대하는 키가 존재하는지 확인하고, +제공된 값이 유효한 JSON으로 파싱될 수 있는지 검증한다. API +서버가 해당 JSON이 실제 도커 컨피그 파일인지를 검증하지는 않는다. + +도커 컨피그 파일을 가지고 있지 않거나 도커 레지스트리 시크릿을 생성하기 +위해 `kubectl` 을 사용하고 싶은 경우, 다음과 같이 처리할 수 있다. + +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-username=tiger \ + --docker-password=pass113 \ + --docker-email=tiger@acme.com +``` + +이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다. +만약 `data` 필드로부터 `.dockerconfigjson` 콘텐츠를 복사(dump)해오면, +다음과 같이 유효한 도커 JSON 콘텐츠를 +즉석에서 얻게 될 것이다. + +```json +{ + "auths": { + "https://index.docker.io/v1/": { + "username": "tiger", + "password": "pass113", + "email": "tiger@acme.com", + "auth": "dGlnZXI6cGFzczExMw==" + } + } +} +``` + +### 기본 인증 시크릿 + +`kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기 +위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가 +다음의 두 키를 포함해야 한다. + +- `username`: 인증을 위한 사용자 이름 +- `password`: 인증을 위한 암호나 토큰 + +위의 두 키에 대한 두 값은 모두 base64로 인코딩된 문자열이다. 물론, +시크릿 생성 시 `stringData` 를 사용하여 평문 텍스트 콘텐츠(clear text content)를 제공할 +수도 있다. + +다음의 YAML은 기본 인증 시크릿을 위한 구성 예시이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-basic-auth +type: kubernetes.io/basic-auth +stringData: + username: admin + password: t0p-Secret +``` + +이 기본 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다. +사용자는 기본 인증에서 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다. +그러나, 빌트인 시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고, +API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 +검증도 한다. + +### SSH 인증 시크릿 + +이 빌트인 타입 `kubernetes.io/ssh-auth` 는 SSH 인증에 사용되는 데이터를 +저장하기 위해서 제공된다. 이 시크릿 타입을 사용할 때는 `ssh-privatekey` +키-값 쌍을 사용할 SSH 자격 증명으로 `data` (또는 `stringData`) +필드에 명시해야 할 것이다. + +다음 YAML은 SSH 인증 시크릿의 구성 예시이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-ssh-auth +type: kubernetes.io/ssh-auth +data: + # 본 예시를 위해 축약된 데이터임 + ssh-privatekey: | + MIIEpQIBAAKCAQEAulqb/Y ... +``` + +SSH 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다. +사용자는 SSH 인증에서 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다. +그러나, 빌트인 시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고, +API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 +검증도 한다. + +### TLS 시크릿 + +쿠버네티스는 보통 TLS를 위해 사용되는 인증서와 관련된 키를 저장하기 위해서 +빌트인 시크릿 타입 `kubernetes.io/tls` 를 제공한다. +이 데이터는 인그레스 리소스의 TLS 종료에 주로 사용되지만, 다른 +리소스나 워크로드에 의해 직접적으로 사용될 수도 있다. +이 타입의 시크릿을 사용할 때는 `tls.key` 와 `tls.crt` 키가 시크릿 구성의 +`data` (또는 `stringData`) 필드에서 제공되어야 한다. 그러나, API +서버가 각 키에 대한 값이 유효한지 실제로 검증하지는 않는다. + +다음 YAML은 TLS 시크릿을 위한 구성 예시를 포함한다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-tls +type: kubernetes.io/tls +data: + # 본 예시를 위해 축약된 데이터임 + tls.crt: | + MIIC2DCCAcCgAwIBAgIBATANBgkqh ... + tls.key: | + MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... +``` + +TLS 시크릿 타입은 사용자 편의만을 위해서 제공된다. 사용자는 TLS 서버 및/또는 +클라이언트를 위해 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다. 그러나, 빌트인 +시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고, +API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 검증도 한다. + +`kubectl` 를 사용하여 TLS 시크릿을 생성할 때, `tls` 하위 커맨드를 +다음 예시와 같이 사용할 수 있다. + +```shell +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file +``` + +공개/개인 키 쌍은 사전에 존재해야 한다. `--cert` 를 위한 공개 키 인증서는 +.PEM 으로 인코딩(Base64로 인코딩된 DER 포맷)되어야 하며, `--key` 를 위해 주어진 +개인 키에 맞아야 한다. +개인 키는 일반적으로 PEM 개인 키 포맷이라고 하는, +암호화되지 않은 형태(unencrypted)이어야 한다. 두 가지 방식 모두에 대해서, PEM의 +시작과 끝 라인(예를 들면, 인증서의 `--------BEGIN CERTIFICATE-----` 및 `-------END CERTIFICATE----`) +은 포함되면 *안* 된다. + +### 부트스트랩 토큰 시크릿 + +부트스트랩 토큰 시크릿은 시크릿 `type` 을 `bootstrap.kubernetes.io/token` 으로 +명확하게 지정하면 생성할 수 있다. 이 타입의 시크릿은 노드 부트스트랩 과정 중에 사용되는 +토큰을 위해 디자인되었다. 이것은 잘 알려진 컨피그맵에 서명하는 데 사용되는 +토큰을 저장한다. + +부트스트랩 토큰 시크릿은 보통 `kube-system` 네임스페이스에 생성되며 +`` 가 해당 토큰 ID의 6개 문자의 문자열으로 구성된 `bootstrap-token-` 형태로 +이름이 지정된다. + +쿠버네티스 매니페스트로서, 부트스트렙 토큰 시크릿은 다음과 유사할 +것이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: bootstrap-token-5emitj + namespace: kube-system +type: bootstrap.kubernetes.io/token +data: + auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4= + expiration: MjAyMC0wOS0xM1QwNDozOToxMFo= + token-id: NWVtaXRq + token-secret: a3E0Z2lodnN6emduMXAwcg== + usage-bootstrap-authentication: dHJ1ZQ== + usage-bootstrap-signing: dHJ1ZQ== +``` + +부트스트랩 타입은 `data` 아래 명시된 다음의 키들을 가진다. + +- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. +- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. +- `description1`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 + 문자열. 선택 사항. +- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를 + 사용하는 절대 UTC 시간. 선택 사항. +- `usage-bootstrap-`: 부트스트랩 토큰의 추가적인 사용처를 나타내는 + 불리언(boolean) 플래그. +- `auth-extra-groups`: system:bootstrappers 그룹에 추가로 인증될 + 쉼표로 구분된 그룹 이름 목록. + +위의 YAML은 모두 base64로 인코딩된 문자열 값이므로 혼란스러워 보일 +수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿 오브젝트 결과를 만드는 +동일한 시크릿을 생성할 수 있다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + # 시크릿 이름이 어떻게 지정되었는지 확인 + name: bootstrap-token-5emitj + # 부트스트랩 토큰 시크릿은 일반적으로 kube-system 네임스페이스에 포함 + namespace: kube-system +type: bootstrap.kubernetes.io/token +stringData: + auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token" + expiration: "2020-09-13T04:39:10Z" + # 이 토큰 ID는 이름에 사용됨 + token-id: "5emitj" + token-secret: "kq4gihvszzgn1p0r" + # 이 토큰은 인증을 위해서 사용될 수 있음 + usage-bootstrap-authentication: "true" + # 또한 서명(signing)에도 사용될 수 있음 + usage-bootstrap-signing: "true" +``` + +## 시크릿 생성하기 시크릿을 생성하기 위한 몇 가지 옵션이 있다. @@ -64,7 +393,7 @@ weight: 30 - [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/) - [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -### 시크릿 편집하기 +## 시크릿 편집하기 기존 시크릿은 다음 명령을 사용하여 편집할 수 있다. @@ -791,11 +1120,11 @@ spec: HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음, HMAC이 있는 일부 메시지에 서명해야 하는 프로그램을 고려한다. 애플리케이션 로직이 복잡하기 때문에, 서버에서 눈에 띄지 않는 원격 파일 읽기 공격이 -있을 수 있으며, 이로 인해 프라이빗 키가 공격자에게 노출될 수 있다. +있을 수 있으며, 이로 인해 개인 키가 공격자에게 노출될 수 있다. 이는 두 개의 컨테이너의 두 개 프로세스로 나눌 수 있다. 사용자 상호 작용과 -비즈니스 로직을 처리하지만, 프라이빗 키를 볼 수 없는 프론트엔드 컨테이너와 -프라이빗 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에 +비즈니스 로직을 처리하지만, 개인 키를 볼 수 없는 프론트엔드 컨테이너와 +개인 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에 응답하는 서명자 컨테이너로 나눌 수 있다. 이 분할된 접근 방식을 사용하면, 공격자는 이제 애플리케이션 서버를 속여서 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 497f4cbfda..2f1ae4a27c 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -61,9 +61,9 @@ weight: 10 `imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. -## 매니페스트가 있는 다중 아키텍처 이미지 +## 이미지 인덱스가 있는 다중 아키텍처 이미지 -바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 컨테이너 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 제공할 수도 있다. 매니페스트는 아키텍처별 버전의 컨테이너에 대한 이미지 매니페스트를 참조할 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. +바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. 쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index ec09e00446..81cc38337f 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -126,7 +126,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### API 접근 익스텐션 -요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다. +요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다. 이러한 각 단계는 익스텐션 포인트를 제공한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index f4301e2933..68e529549b 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -13,7 +13,7 @@ weight: 10 ## 커스텀 리소스 -*리소스* 는 [쿠버네티스 API](/ko/docs/reference/using-api/api-overview/)에서 특정 종류의 +*리소스* 는 [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에서 특정 종류의 [API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다. *커스텀 리소스* 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시 diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md index 3fe6451755..9775299a3c 100644 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -127,7 +127,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### API 접근 익스텐션 -요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다. +요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다. 이러한 각 단계는 익스텐션 포인트를 제공한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md index 6e27220d68..3ac6a2df7d 100644 --- a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md @@ -227,7 +227,7 @@ spec: * 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다. * [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 -* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 프로젝트 탐색 +* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 * [svc-cat.io](https://svc-cat.io/docs/) 살펴보기 diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 65662da9d0..89871bd83a 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -22,7 +22,7 @@ card: 대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/) 커맨드 라인 인터페이스 또는 API를 사용하는 -[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 +[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다. 그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다. @@ -101,8 +101,20 @@ API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를 제어할 수 있도록 한다. 보다 쉽게 발전하고 API를 확장하기 위해, 쿠버네티스는 -[활성화 또는 비활성화](/ko/docs/reference/using-api/api-overview/#api-그룹-활성화-또는-비활성화-하기)가 -가능한 [API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 구현한다. +[활성화 또는 비활성화](/ko/docs/reference/using-api/#api-그룹-활성화-또는-비활성화)가 +가능한 [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 구현한다. + +API 리소스는 API 그룹, 리소스 유형, 네임스페이스 +(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 +여러 API 버전을 통해 동일한 기본 데이터를 제공하고 API 버전 간의 +변환을 투명하게 처리할 수 있다. 이 모든 다른 버전은 실제로 +같은 리소스의 표현이다. 예를 들어 동일한 리소스에 대해 +두 가지 버전 `v1`과 `v1beta1`이 있다고 가정해 보자. +`v1beta1` 버전에서 생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서 +읽기, 업데이트 및 삭제할 수 있다. + +API 버전 수준 정의에 대한 자세한 내용은 +[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다. API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스 (네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한 @@ -129,7 +141,7 @@ API 버전 수준 정의에 대한 자세한 내용은 - 자체 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)을 추가하여 쿠버네티스 API를 확장하는 방법에 대해 배우기. -- [API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)는 +- [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)는 클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다. - [API 레퍼런스](/docs/reference/kubernetes-api/)를 읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기. diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 7d6c8c1f0e..449cae4393 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -35,7 +35,7 @@ sitemap: 각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다. -**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. +**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. 컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index c43acf468c..6bfdda943f 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -91,6 +91,7 @@ deployment.apps/nginx-deployment created ## {{% heading "whatsnext" %}} -* API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. + * [파드](/ko/docs/concepts/workloads/pods/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. +* API 개념의 더 많은 설명은 [쿠버네티스 API 사용](/ko/docs/reference/using-api/)을 본다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index a6f03a907f..631f0347d4 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -185,7 +185,7 @@ kubectl get pods -l 'environment,environment notin (frontend)' [`services`](/ko/docs/concepts/services-networking/service/) 와 [`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 -[파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다. +[파드](/ko/docs/concepts/workloads/pods/)와 같은 다른 리소스 집합을 선택한다. #### 서비스와 레플리케이션 컨트롤러 diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index c1e7bc56a9..93f2093952 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -138,12 +138,16 @@ RBAC 바인딩에 대한 자세한 예는, ### 문제 해결 - [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는 -[보안 API 포트](/ko/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며, -슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고, -모든 파드시큐리티폴리시 오브젝트가 허용되며 -사용자는 특권있는 컨테이너를 만들 수 있다. 컨트롤러 관리자 권한 구성에 대한 자세한 -내용은 [컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 -참고하길 바란다. +보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다. +API 서버 접근 제어에 대한 자세한 내용은 +[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다. +컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를 +통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고, +모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를 +만들 수 있는 권한을 부여할 수 있다. + +컨트롤러 관리자 권한 구성에 대한 자세한 내용은 +[컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고하기 바란다. ## 정책 순서 diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index 028209a07e..ffda9f5eda 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -15,7 +15,7 @@ weight: 10 `ResourceQuota` 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 제공한다. 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와 -해당 프로젝트의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 +해당 네임스페이스의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 제한할 수 있다. 리소스 쿼터는 다음과 같이 작동한다. @@ -23,10 +23,10 @@ weight: 10 - 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을 적용하기 위한 지원이 계획되어 있다. -- 관리자는 각 네임스페이스에 대해 하나의 `ResourceQuota`를 생성한다. +- 관리자는 각 네임스페이스에 대해 하나의 리소스쿼터를 생성한다. - 사용자는 네임스페이스에서 리소스(파드, 서비스 등)를 생성하고 쿼터 시스템은 - 사용량을 추적하여 `ResourceQuota`에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다. + 사용량을 추적하여 리소스쿼터에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다. - 리소스를 생성하거나 업데이트할 때 쿼터 제약 조건을 위반하면 위반된 제약 조건을 설명하는 메시지와 함께 HTTP 상태 코드 `403 FORBIDDEN`으로 요청이 실패한다. @@ -38,7 +38,7 @@ weight: 10 이 문제를 회피하는 방법에 대한 예제는 [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다. -`ResourceQuota` 오브젝트의 이름은 유효한 +리소스쿼터 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. 네임스페이스와 쿼터를 사용하여 만들 수 있는 정책의 예는 다음과 같다. @@ -59,7 +59,7 @@ weight: 10 API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 `ResourceQuota`가 있는 경우 활성화된다. -해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 +해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에 리소스 쿼터가 적용된다. ## 컴퓨트 리소스 쿼터 @@ -70,10 +70,14 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 | 리소스 이름 | 설명 | | --------------------- | ----------------------------------------------------------- | -| `limits.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 제한의 합은 이 값을 초과할 수 없음 | -| `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음 | -| `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음 | -| `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음 | +| `limits.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 제한의 합은 이 값을 초과할 수 없음. | +| `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음. | +| `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음. | +| `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음. | +| `hugepages-` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의 +휴즈 페이지 요청은 이 값을 초과하지 못함. | +| `cpu` | `requests.cpu` 와 같음. | +| `memory` | `requests.memory` 와 같음. | ### 확장된 리소스에 대한 리소스 쿼터 @@ -103,7 +107,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `requests.storage` | 모든 퍼시스턴트 볼륨 클레임에서 스토리지 요청의 합은 이 값을 초과할 수 없음 | | `persistentvolumeclaims` | 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | | `.storageclass.storage.k8s.io/requests.storage` | storage-class-name과 관련된 모든 퍼시스턴트 볼륨 클레임에서 스토리지 요청의 합은 이 값을 초과할 수 없음 | -| `.storageclass.storage.k8s.io/persistentvolumeclaims` | storage-class-name과 관련된 모든 퍼시스턴트 볼륨 클레임에서 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | `` 과 관련된 모든 퍼시스턴트 볼륨 클레임에서 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | 예를 들어, 운영자가 `bronze` 스토리지 클래스와 별도로 `gold` 스토리지 클래스를 사용하여 스토리지에 쿼터를 지정하려는 경우 운영자는 다음과 같이 쿼터를 정의할 수 있다. @@ -115,14 +119,17 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | 리소스 이름 | 설명 | | ------------------------------- |----------------------------------------------------------- | -| `requests.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 요청의 합은 이 값을 초과할 수 없음 | -| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음 | +| `requests.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 요청의 합은 이 값을 초과할 수 없음. | +| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음. | +| `ephemeral-storage` | `requests.ephemeral-storage` 와 같음. | ## 오브젝트 수 쿼터 -1.9 릴리스는 다음 구문을 사용하여 모든 표준 네임스페이스 리소스 유형에 쿼터를 지정하는 지원을 추가했다. +다음 구문을 사용하여 모든 표준 네임스페이스 처리된(namespaced) 리소스 유형에 대한 +특정 리소스 전체 수에 대하여 쿼터를 지정할 수 있다. -* `count/.` +* 코어 그룹이 아닌(non-core) 리소스를 위한 `count/.` +* 코어 그룹의 리소스를 위한 `count/` 다음은 사용자가 오브젝트 수 쿼터 아래에 배치하려는 리소스 셋의 예이다. @@ -136,32 +143,29 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. * `count/statefulsets.apps` * `count/jobs.batch` * `count/cronjobs.batch` -* `count/deployments.extensions` -1.15 릴리스는 동일한 구문을 사용하여 사용자 정의 리소스에 대한 지원을 추가했다. +사용자 정의 리소스를 위해 동일한 구문을 사용할 수 있다. 예를 들어 `example.com` API 그룹에서 `widgets` 사용자 정의 리소스에 대한 쿼터를 생성하려면 `count/widgets.example.com`을 사용한다. `count/*` 리소스 쿼터를 사용할 때 서버 스토리지 영역에 있다면 오브젝트는 쿼터에 대해 과금된다. 이러한 유형의 쿼터는 스토리지 리소스 고갈을 방지하는 데 유용하다. 예를 들어, 크기가 큰 서버에서 시크릿 수에 쿼터를 지정할 수 있다. 클러스터에 시크릿이 너무 많으면 실제로 서버와 -컨트롤러가 시작되지 않을 수 있다! 네임스페이스에 너무 많은 작업을 생성하는 -잘못 구성된 크론 잡으로 인해 서비스 거부를 유발하는 것으로부터 보호하기 위해 작업의 쿼터를 지정하도록 선택할 수 있다. - -1.9 릴리스 이전에는 제한된 리소스 셋에서 일반 오브젝트 수 쿼터를 적용할 수 있었다. -또한, 특정 리소스에 대한 쿼터를 유형별로 추가로 제한할 수 있다. +컨트롤러가 시작되지 않을 수 있다. 잘못 구성된 크론 잡으로부터의 보호를 위해 +잡의 쿼터를 설정할 수 있다. 네임스페이스 내에서 너무 많은 잡을 생성하는 크론 잡은 서비스 거부를 유발할 수 있다. +또한 제한된 리소스 셋에 대해서 일반 오브젝트 수(generic object count) 쿼터를 적용하는 것도 가능하다. 다음 유형이 지원된다. | 리소스 이름 | 설명 | | ------------------------------- | ------------------------------------------------- | -| `configmaps` | 네임스페이스에 존재할 수 있는 총 구성 맵 수 | +| `configmaps` | 네임스페이스에 존재할 수 있는 총 컨피그맵 수 | | `persistentvolumeclaims` | 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | | `pods` | 네임스페이스에 존재할 수 있는 터미널이 아닌 상태의 파드의 총 수. `.status.phase in (Failed, Succeeded)`가 true인 경우 파드는 터미널 상태임 | -| `replicationcontrollers` | 네임스페이스에 존재할 수 있는 총 레플리케이션 컨트롤러 수 | -| `resourcequotas` | 네임스페이스에 존재할 수 있는 총 [리소스 쿼터](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) 수 | +| `replicationcontrollers` | 네임스페이스에 존재할 수 있는 총 레플리케이션컨트롤러 수 | +| `resourcequotas` | 네임스페이스에 존재할 수 있는 총 리소스쿼터 수 | | `services` | 네임스페이스에 존재할 수 있는 총 서비스 수 | -| `services.loadbalancers` | 네임스페이스에 존재할 수 있는 로드 밸런서 유형의 총 서비스 수 | -| `services.nodeports` | 네임스페이스에 존재할 수 있는 노드 포트 유형의 총 서비스 수 | +| `services.loadbalancers` | 네임스페이스에 존재할 수 있는 `LoadBalancer` 유형의 총 서비스 수 | +| `services.nodeports` | 네임스페이스에 존재할 수 있는 `NodePort` 유형의 총 서비스 수 | | `secrets` | 네임스페이스에 존재할 수 있는 총 시크릿 수 | 예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 @@ -171,7 +175,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. ## 쿼터 범위 -각 쿼터에는 연결된 범위 셋이 있을 수 있다. 쿼터는 열거된 범위의 교차 부분과 일치하는 경우에만 +각 쿼터에는 연결된 `scopes` 셋이 있을 수 있다. 쿼터는 열거된 범위의 교차 부분과 일치하는 경우에만 리소스 사용량을 측정한다. 범위가 쿼터에 추가되면 해당 범위와 관련된 리소스를 지원하는 리소스 수가 제한된다. @@ -183,22 +187,60 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 | | `BestEffort` | 최상의 서비스 품질을 제공하는 파드 | | `NotBestEffort` | 서비스 품질이 나쁜 파드 | +| `PriorityClass` | 지정된 [프라이올리티 클래스](/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. | -`BestEffort` 범위는 다음의 리소스(파드)를 추적하도록 쿼터를 제한한다. +`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다. -`Terminating`, `NotTerminating` 및 `NotBestEffort` 범위는 쿼터를 제한하여 다음의 리소스를 추적한다. - -* `cpu` -* `limits.cpu` -* `limits.memory` -* `memory` * `pods` + +`Terminating`, `NotTerminating`, `NotBestEffort` 및 `PriorityClass` +범위는 쿼터를 제한하여 다음의 리소스를 추적한다. + +* `pods` +* `cpu` +* `memory` * `requests.cpu` * `requests.memory` +* `limits.cpu` +* `limits.memory` + +`Terminating` 과 `NotTerminating` 범위를 동일한 쿼터 내에 모두 +명시하지는 못하며, 마찬가지로 `BestEffort` 와 +`NotBestEffort` 범위도 동일한 쿼터 내에서 모두 명시하지는 못한다. + +`scopeSelector` 는 `operator` 필드에 다음의 값을 지원한다. + +* `In` +* `NotIn` +* `Exists` +* `DoesNotExist` + +`scopeSelector` 를 정의할 때, `scopeName` 으로 다음의 값 중 하나를 사용하는 +경우, `operator` 는 `Exists` 이어야 한다. + +* `Terminating` +* `NotTerminating` +* `BestEffort` +* `NotBestEffort` + +만약 `operator` 가 `In` 또는 `NotIn` 인 경우, `values` 필드는 적어도 하나의 값은 +가져야 한다. 예를 들면 다음과 같다. + +```yaml + scopeSelector: + matchExpressions: + - scopeName: PriorityClass + operator: In + values: + - middle +``` + +만약 `operator` 가 `Exists` 또는 `DoesNotExist` 이라면, `values` 필드는 명시되면 +*안된다*. ### PriorityClass별 리소스 쿼터 -{{< feature-state for_k8s_version="v1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="stable" >}} 특정 [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다. 쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 @@ -281,7 +323,7 @@ items: kubectl create -f ./quota.yml ``` -```shell +``` resourcequota/pods-high created resourcequota/pods-medium created resourcequota/pods-low created @@ -293,7 +335,7 @@ resourcequota/pods-low created kubectl describe quota ``` -```shell +``` Name: pods-high Namespace: default Resource Used Hard @@ -358,7 +400,7 @@ kubectl create -f ./high-priority-pod.yml kubectl describe quota ``` -```shell +``` Name: pods-high Namespace: default Resource Used Hard @@ -386,13 +428,6 @@ memory 0 20Gi pods 0 10 ``` -`scopeSelector`는 `operator` 필드에서 다음 값을 지원한다. - -* `In` -* `NotIn` -* `Exist` -* `DoesNotExist` - ## 요청과 제한의 비교 {#requests-vs-limits} 컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다. @@ -456,7 +491,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace kubectl get quota --namespace=myspace ``` -```shell +``` NAME AGE compute-resources 30s object-counts 32s @@ -466,7 +501,7 @@ object-counts 32s kubectl describe quota compute-resources --namespace=myspace ``` -```shell +``` Name: compute-resources Namespace: myspace Resource Used Hard @@ -482,7 +517,7 @@ requests.nvidia.com/gpu 0 4 kubectl describe quota object-counts --namespace=myspace ``` -```shell +``` Name: object-counts Namespace: myspace Resource Used Hard @@ -504,7 +539,7 @@ kubectl create namespace myspace ``` ```shell -kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace +kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace ``` ```shell @@ -515,29 +550,29 @@ kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2 kubectl describe quota --namespace=myspace ``` -```shell +``` Name: test Namespace: myspace Resource Used Hard -------- ---- ---- -count/deployments.extensions 1 2 +count/deployments.apps 1 2 count/pods 2 3 -count/replicasets.extensions 1 4 +count/replicasets.apps 1 4 count/secrets 1 4 ``` ## 쿼터 및 클러스터 용량 -`ResourceQuotas`는 클러스터 용량과 무관하다. 그것들은 절대 단위로 표현된다. +리소스쿼터는 클러스터 용량과 무관하다. 그것들은 절대 단위로 표현된다. 따라서 클러스터에 노드를 추가해도 각 네임스페이스에 더 많은 리소스를 사용할 수 있는 기능이 자동으로 부여되지는 *않는다*. 가끔 다음과 같은 보다 복잡한 정책이 필요할 수 있다. - - 여러 팀으로 전체 클러스터 리소스를 비례적으로 나눈다. - - 각 테넌트가 필요에 따라 리소스 사용량을 늘릴 수 있지만, 실수로 리소스가 고갈되는 것을 - 막기 위한 충분한 제한이 있다. - - 하나의 네임스페이스에서 요구를 감지하고 노드를 추가하며 쿼터를 늘린다. +- 여러 팀으로 전체 클러스터 리소스를 비례적으로 나눈다. +- 각 테넌트가 필요에 따라 리소스 사용량을 늘릴 수 있지만, 실수로 리소스가 고갈되는 것을 + 막기 위한 충분한 제한이 있다. +- 하나의 네임스페이스에서 요구를 감지하고 노드를 추가하며 쿼터를 늘린다. 이러한 정책은 쿼터 사용을 감시하고 다른 신호에 따라 각 네임스페이스의 쿼터 하드 제한을 조정하는 "컨트롤러"를 작성하여 `ResourceQuotas`를 구성 요소로 @@ -548,14 +583,16 @@ count/secrets 1 4 ## 기본적으로 우선 순위 클래스 소비 제한 -파드가 특정 우선 순위, 예를 들어 일치하는 쿼터 오브젝트가 존재하는 경우에만 "cluster-services"가 네임스페이스에 허용되어야 힌다. +파드가 특정 우선 순위, 예를 들어 일치하는 쿼터 오브젝트가 존재하는 +경우에만 "cluster-services"가 네임스페이스에 허용되어야 한다. -이 메커니즘을 통해 운영자는 특정 우선 순위가 높은 클래스의 사용을 제한된 수의 네임스페이스로 제한할 수 있으며 모든 네임스페이스가 기본적으로 이러한 우선 순위 클래스를 사용할 수 있는 것은 아니다. +이 메커니즘을 통해 운영자는 특정 우선 순위가 높은 클래스의 사용을 +제한된 수의 네임스페이스로 제한할 수 있으며 모든 네임스페이스가 +기본적으로 이러한 우선 순위 클래스를 사용할 수 있는 것은 아니다. -이를 적용하려면 kube-apiserver 플래그 `--admission-control-config-file`을 사용하여 다음 구성 파일의 경로를 전달해야 한다. +이를 적용하려면 kube-apiserver 플래그 `--admission-control-config-file` 을 +사용하여 다음 구성 파일의 경로를 전달해야 한다. -{{< tabs name="example1" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -571,30 +608,10 @@ plugins: operator: In values: ["cluster-services"] ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: "ResourceQuota" - configuration: - # Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1, ResourceQuotaConfiguration - apiVersion: resourcequota.admission.k8s.io/v1beta1 - kind: Configuration - limitedResources: - - resource: pods - matchScopes: - - scopeName: PriorityClass - operator: In - values: ["cluster-services"] -``` -{{% /tab %}} -{{< /tabs >}} 이제 "cluster-services" 파드는 `scopeSelector`와 일치하는 쿼터 오브젝트가 있는 네임스페이스에서만 허용된다. 예를 들면 다음과 같다. + ```yaml scopeSelector: matchExpressions: @@ -603,12 +620,9 @@ plugins: values: ["cluster-services"] ``` -자세한 내용은 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)와 [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 참고하길 바란다. - -## 예제 - -[리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고하길 바란다. - ## {{% heading "whatsnext" %}} -- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. +- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다. +- [리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고한다. +- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 읽는다. +- [제한된 자원](https://github.com/kubernetes/kubernetes/pull/36765)을 참고한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index a3bf6a5a25..6bbe7a6767 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -78,7 +78,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 방법이 있다. 1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다. -1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다. +1. [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다. ## {{% heading "whatsnext" %}} @@ -88,8 +88,8 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 -* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기 -* 볼륨을 사용하느 파드의 스케줄링에 대해 배우기 +* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 +* 볼륨을 사용하는 파드의 스케줄링에 대해 배우기 * [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드) * [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/) * [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/) diff --git a/content/ko/docs/reference/access-authn-authz/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md similarity index 100% rename from content/ko/docs/reference/access-authn-authz/controlling-access.md rename to content/ko/docs/concepts/security/controlling-access.md diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index af5c9ba574..86240a4116 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -102,7 +102,7 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋 워크로드 보안에서 고려할 영역 | 추천 | ------------------------------ | ------------ | RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ -인증 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ +인증 | https://kubernetes.io/ko/docs/concepts/security/controlling-access/ 애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ 파드 보안 정책 | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ 서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/ @@ -146,8 +146,8 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 * [파드 보안 표준](/docs/concepts/security/pod-security-standards/) * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) +* [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access) * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/) -* [API 접근 통제](/ko/docs/reference/access-authn-authz/controlling-access/) * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/) diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 844ff7bd2b..4206a2d9d4 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -94,7 +94,7 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급 ## 이그레스 트래픽 -근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent 를 사용할 수 있다. +근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent를 사용할 수 있다. ## 알려진 이슈들 diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index c4d18ada98..5b91356437 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -411,6 +411,13 @@ type: kubernetes.io/tls TLS 시크릿이 `https-example.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고 하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다. +{{< note >}} +가능한 모든 하위 도메인에 대해 인증서가 발급되어야 하기 때문에 +TLS는 기본 규칙에서 작동하지 않는다. 따라서 +`tls` 섹션의 `hosts`는 `rules`섹션의 `host`와 명시적으로 일치해야 +한다. +{{< /note >}} + {{< codenew file="service/networking/tls-example-ingress.yaml" >}} {{< note >}} diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 4cf129a3e6..a74dd45de6 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -177,27 +177,29 @@ spec: 퍼시스턴트볼륨이 존재하고 `claimRef` 필드를 통해 퍼시스턴트볼륨클레임을 예약하지 않은 경우, 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이 바인딩된다. 바인딩은 노드 선호도(affinity)를 포함하여 일부 볼륨 일치(matching) 기준과 관계없이 발생한다. -컨트롤 플레인은 여전히 [스토리지 클래스](https://kubernetes.io/ko/docs/concepts/storage/storage-classes/), 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다. +컨트롤 플레인은 여전히 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/), 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다. -``` +```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: foo-pvc namespace: foo spec: + storageClassName: "" # 빈 문자열은 명시적으로 설정해야 하며 그렇지 않으면 기본 스토리지클래스가 설정됨 volumeName: foo-pv ... ``` 이 메서드는 퍼시스턴트볼륨에 대한 바인딩 권한을 보장하지 않는다. 다른 퍼시스턴트볼륨클레임에서 지정한 PV를 사용할 수 있는 경우, 먼저 해당 스토리지 볼륨을 예약해야 한다. PV의 `claimRef` 필드에 관련 퍼시스턴트볼륨클레임을 지정하여 다른 PVC가 바인딩할 수 없도록 한다. -``` +```yaml apiVersion: v1 kind: PersistentVolume metadata: name: foo-pv spec: + storageClassName: "" claimRef: name: foo-pvc namespace: foo diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 38d59b6fb0..7526aff98d 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -89,7 +89,7 @@ volumeBindingMode: Immediate 등에 대한 완전한 재량권을 가진다. [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 리포지터리에는 대량의 사양을 구현하는 외부 프로비저너를 작성하기 위한 라이브러리가 있다. 일부 외부 프로비저너의 목록은 -[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage) 리포지터리에 있다. +[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns) 리포지터리에 있다. 예를 들어, NFS는 내부 프로비저너를 제공하지 않지만, 외부 프로비저너를 사용할 수 있다. 타사 스토리지 업체가 자체 외부 diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 5ad5a938eb..5903905d59 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -24,6 +24,8 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 `VolumeSnapshotClass` 을 사용하면 `VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 볼륨에서 가져온 스냅샷마다 다를 수 있으므로 `PersistentVolumeClaim` 의 `StorageClass` 를 사용하여 표현할 수는 없다. +볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 표준화된 방법을 제공한다. 예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다. + 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다. * API 객체인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 9077eec5d2..d89c0b7241 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -7,13 +7,14 @@ weight: 10 컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 -애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 첫째, 컨테이너가 충돌되면, -kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상태로 -시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때 -컨테이너 사이에 파일을 공유해야 하는 경우가 자주 발생한다. 쿠버네티스의 -`볼륨` 추상화는 이 두 가지 문제를 모두 해결한다. +애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 한 가지 문제는 +컨테이너가 크래시될 때 파일이 손실된다는 것이다. kubelet은 컨테이너를 다시 시작하지만 +초기화된 상태이다. 두 번째 문제는 `Pod`에서 같이 실행되는 컨테이너간에 +파일을 공유할 때 발생한다. +쿠버네티스 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 추상화는 +이러한 문제를 모두 해결한다. -[파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 익숙해지는 것을 추천한다. +[파드](/ko/docs/concepts/workloads/pods/)에 대해 익숙해지는 것을 추천한다. @@ -21,86 +22,47 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 도커는 다소 느슨하고, 덜 관리되지만 [볼륨](https://docs.docker.com/storage/)이라는 -개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 -다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 -로컬 디스크 백업 볼륨만 있었다. 도커는 이제 볼륨 드라이버를 -제공하지만, 현재 기능은 매우 제한되어 있다(예: 도커 1.7부터 -컨테이너 당 하나의 볼륨 드라이버만 허용되고 매개 변수를 볼륨에 -전달할 방법이 없다). +개념을 가지고 있다. 도커 볼륨은 디스크에 있는 디렉터리이거나 +다른 컨테이너에 있다. 도커는 볼륨 +드라이버를 제공하지만, 기능이 다소 제한된다. -반면에, 쿠버네티스 볼륨은 그것을 둘러싼 파드와 -동일한 명시적인 수명을 가진다. 그 결과로, 볼륨은 파드 내에서 실행되는 모든 컨테이너보다 -수명이 길고, 컨테이너를 다시 시작해도 데이터가 보존된다. 물론 파드가 -존재하지 않으면, 볼륨도 존재하지 않는다. 이보다 더 중요한 것은 -쿠버네티스가 많은 유형의 볼륨을 지원하고, 파드는 -여러 볼륨을 동시에 사용할 수 있다. +쿠버네티스는 다양한 유형의 볼륨을 지원한다. {{< glossary_tooltip term_id="pod" text="파드" >}}는 +여러 볼륨 유형을 동시에 사용할 수 있다. +임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은 +파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서 +실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가 +더 이상 존재하지 않으면, 볼륨은 삭제된다. 기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드 -내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는 +내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는 매체와 내용은 사용된 특정 볼륨의 유형에 따라 결정된다. -볼륨을 사용하기 위해 파드는 파드에 제공할 볼륨( -`.spec.volumes` -필드)과 컨테이너에 마운트 할 위치( -`.spec.containers[*].volumeMounts` -필드)를 지정한다. +볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고 +`.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다. -컨테이너 내 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 뷰를 -본다. [도커 -이미지](https://docs.docker.com/userguide/dockerimages/)는 파일 -시스템 계층의 루트에 있으며 모든 볼륨은 이미지 내에 지정된 경로에 -마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 -가질 수 없다. 파드 내 각각의 컨테이너는 각각의 볼륨을 마운트 할 위치를 독립적으로 +컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 +뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는 +파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에 +마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 +가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로 지정해야 한다. -## 볼륨 유형들 +## 볼륨 유형들 {#volume-types} 쿠버네티스는 여러 유형의 볼륨을 지원한다. - * [awsElasticBlockStore](#awselasticblockstore) - * [azureDisk](#azuredisk) - * [azureFile](#azurefile) - * [cephfs](#cephfs) - * [cinder](#cinder) - * [configMap](#configmap) - * [csi](#csi) - * [downwardAPI](#downwardapi) - * [emptyDir](#emptydir) - * [fc (파이버 채널)](#fc) - * [flexVolume](#flexVolume) - * [flocker](#flocker) - * [gcePersistentDisk](#gcepersistentdisk) - * [gitRepo (사용중단(deprecated))](#gitrepo) - * [glusterfs](#glusterfs) - * [hostPath](#hostpath) - * [iscsi](#iscsi) - * [local](#local) - * [nfs](#nfs) - * [persistentVolumeClaim](#persistentvolumeclaim) - * [projected](#projected) - * [portworxVolume](#portworxvolume) - * [quobyte](#quobyte) - * [rbd](#rbd) - * [scaleIO](#scaleio) - * [secret](#secret) - * [storageos](#storageos) - * [vsphereVolume](#vspherevolume) - -우리는 추가 기여를 환영한다. - ### awsElasticBlockStore {#awselasticblockstore} -`awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS) [EBS -볼륨](https://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 +`awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS) +[EBS 볼륨](https://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 EBS 볼륨의 -내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에 -데이터를 미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" -할 수 있다. +내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에 +데이터를 미리 채울 수 있으며, 파드 간에 데이터를 "전달(handed off)"할 수 있다. -{{< caution >}} +{{< note >}} 이를 사용하려면 먼저 `aws ec2 create-volume` 또는 AWS API를 사용해서 EBS 볼륨을 생성해야 한다. -{{< /caution >}} +{{< /note >}} `awsElasticBlockStore` 볼륨을 사용할 때 몇 가지 제한이 있다. @@ -108,7 +70,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 * 이러한 인스턴스는 EBS 볼륨과 동일한 지역과 가용성 영역에 있어야 함 * EBS는 볼륨을 마운트하는 단일 EC2 인스턴스만 지원함 -#### EBS 볼륨 생성하기 +#### AWS EBS 볼륨 생성하기 파드와 함께 EBS 볼륨을 사용하려면, 먼저 EBS 볼륨을 생성해야 한다. @@ -116,8 +78,8 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 ``` -클러스터를 띄운 영역과 생성하는 영역이 일치하는지 확인한다. (그리고 크기와 EBS 볼륨 유형이 -사용에 적합한지 확인한다!) +클러스터를 띄운 영역과 생성하는 영역이 일치하는지 확인한다. 크기와 EBS 볼륨 유형이 +사용에 적합한지 확인한다. #### AWS EBS 구성 예시 @@ -137,37 +99,38 @@ spec: - name: test-volume # 이 AWS EBS 볼륨은 이미 존재해야 한다. awsElasticBlockStore: - volumeID: + volumeID: "" fsType: ext4 ``` -#### CSI 마이그레이션 +#### AWS EBS CSI 마이그레이션 {{< feature-state for_k8s_version="v1.17" state="beta" >}} -awsElasticBlockStore 의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 -`ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) -드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [AWS EBS CSI -드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) -를 설치하고 `CSIMigration` 과 `CSIMigrationAWS` +`awsElasticBlockStore` 의 `CSIMigration` 기능이 활성화된 경우, 기존 인-트리 플러그인의 +모든 플러그인 작업을 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 리디렉션한다. 이 기능을 사용하려면, 클러스터에 [AWS EBS CSI +드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)를 +설치하고 `CSIMigration` 과 `CSIMigrationAWS` 베타 기능을 활성화해야 한다. -#### CSI 마이그레이션 완료 +#### AWS EBS CSI 마이그레이션 완료 {{< feature-state for_k8s_version="v1.17" state="alpha" >}} -컨트롤러 매니저와 kubelet에 의해 로드되지 않도록 awsElasticBlockStore 스토리지 플러그인을 끄려면, 이 기능의 플래그를 true로 설정해야 한다. 이는 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다. +컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지 +플러그인을 끄려면, `CSIMigrationAWSComplete` 플래그를 `true` 로 설정한다. 이 기능은 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다. ### azureDisk {#azuredisk} -`azureDisk` 는 Microsoft Azure [데이터 디스크](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/)를 파드에 마운트하는 데 사용한다. +`azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다. -더 자세한 내용은 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)에서 확인할 수 있다. +더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)을 참고한다. -#### CSI 마이그레이션 +#### azureDisk CSI 마이그레이션 {{< feature-state for_k8s_version="v1.19" state="beta" >}} -azureDisk의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) @@ -176,46 +139,46 @@ azureDisk의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 ### azureFile {#azurefile} -`azureFile` 은 Microsoft Azure 파일 볼륨 (SMB 2.1과 3.0)을 파드에 마운트하는데 -사용한다. +`azureFile` 볼륨 유형은 Microsoft Azure 파일 볼륨(SMB 2.1과 3.0)을 파드에 +마운트한다. -더 자세한 내용은 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)에서 확인할 수 있다. +더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)을 참고한다. -#### CSI 마이그레이션 +#### azureFile CSI 마이그레이션 {{< feature-state for_k8s_version="v1.15" state="alpha" >}} -azureFile의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI 드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile` 알파 기능을 활성화해야 한다. -### cephfs {#cephfs} +### cephfs `cephfs` 볼륨은 기존 CephFS 볼륨을 파드에 마운트 할 수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 cephfs 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 -해제만 된다. 이 의미는 `cephfs` 볼륨에 데이터를 미리 채울 수 있으며, -파드 간에 데이터를 "전달(handed off)" 할 수 있다. CephFS는 여러 작성자가 +해제만 된다. 이 의미는 `cephfs` 볼륨에 데이터를 미리 채울 수 있으며, +해당 데이터는 파드 간에 공유될 수 있다. `cephfs` 볼륨은 여러 작성자가 동시에 마운트할 수 있다. -{{< caution >}} +{{< note >}} CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다. -{{< /caution >}} +{{< /note >}} 더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다. -### cinder {#cinder} +### cinder {{< note >}} -전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스. +쿠버네티스는 오픈스택 클라우드 공급자로 구성되어야 한다. {{< /note >}} -`cinder` 는 오픈스택 Cinder 볼륨을 파드에 마운트하는 데 사용한다. +`cinder` 볼륨 유형은 오픈스택 Cinder 볼륨을 파드에 마운트하는데 사용된다. -#### Cinder 볼륨 예시 구성 +#### Cinder 볼륨 구성 예시 ```yaml apiVersion: v1 @@ -233,33 +196,32 @@ spec: - name: test-volume # 이 오픈스택 볼륨은 이미 존재해야 한다. cinder: - volumeID: + volumeID: "" fsType: ext4 ``` -#### CSI 마이그레이션 +#### 오픈스택 CSI 마이그레이션 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -Cinder의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI 드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) 를 설치하고 `CSIMigration` 과 `CSIMigrationOpenStack` 베타 기능을 활성화해야 한다. -### configMap {#configmap} +### 컨피그맵(configMap) {#configmap} -[`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) 리소스는 +[컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 구성 데이터를 파드에 주입하는 방법을 제공한다. -`ConfigMap` 오브젝트에 저장된 데이터는 `configMap` 유형의 볼륨에서 참조되고 +컨피그맵에 저장된 데이터는 `configMap` 유형의 볼륨에서 참조되고 그런 다음에 파드에서 실행되는 컨테이너화된 애플리케이션이 소비한다. -`configMap` 오브젝트를 참조할 때, 간단하게 참조하기 위한 볼륨의 이름을 -제공할 수 있다. ConfigMap의 특정 항목에 사용할 경로를 -사용자 정의할 수 있다. -예를 들어, `log-config` ConfigMap을 `configmap-pod` 라 부르는 파드에 마운트하려면 -아래 YAML을 사용할 수 있다. +컨피그맵을 참조할 때, 볼륨에 컨피그맵의 이름을 +제공한다. 컨피그맵의 특정 항목에 사용할 경로를 +사용자 정의할 수 있다. 다음 구성은 `log-config` 컨피그맵을 +`configmap-pod` 라 부르는 파드에 마운트하는 방법을 보여준다. ```yaml apiVersion: v1 @@ -282,48 +244,42 @@ spec: path: log_level ``` -`log-config` ConfigMap은 볼륨으로 마운트되며, `log_level` 항목에 -저장된 모든 컨텐츠는 파드의 "`/etc/config/log_level`" 경로에 마운트 된다. +`log-config` 컨피그맵은 볼륨으로 마운트되며, `log_level` 항목에 +저장된 모든 컨텐츠는 파드의 `/etc/config/log_level` 경로에 마운트된다. 이 경로는 볼륨의 `mountPath` 와 `log_level` 로 키가 지정된 `path` 에서 파생된다. -{{< caution >}} -ConfigMap 볼륨을 사용하려면 먼저 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 생성해야 한다. -{{< /caution >}} - {{< note >}} -ConfigMap을 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 ConfigMap +* 컨피그맵을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵 업데이트를 수신하지 않는다. -{{< /note >}} -{{< note >}} -텍스트 데이터는 UTF-8 문자 인코딩을 사용하는 파일로 노출된다. 다른 문자 인코딩을 사용하려면, binaryData를 사용한다. +* 텍스트 데이터는 UTF-8 문자 인코딩을 사용하는 파일로 노출된다. 다른 문자 인코딩의 경우, `binaryData` 를 사용한다. {{< /note >}} - ### downwardAPI {#downwardapi} -`downwardAPI` 볼륨은 애플리케이션에서 다운워드(downward) API 데이터를 사용할 수 있도록 하는데 사용된다. +`downwardAPI` 볼륨은 애플리케이션에서 다운워드(downward) API 데이터를 사용할 수 있도록 한다. 이것은 디렉터리를 마운트하고 요청된 데이터를 일반 텍스트 파일로 작성한다. {{< note >}} -Downward API를 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 Downward API +다운워드 API를 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다. {{< /note >}} -더 자세한 내용은 [`downwardAPI` 볼륨 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참조한다. +더 자세한 내용은 [다운워드 API 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다. ### emptyDir {#emptydir} -`emptyDir` 볼륨은 파드가 노드에 할당 될 때 처음 생성되며, -해당 노드에서 파드가 실행되는 동안에만 존재한다. 이름에서 알 수 있듯이 -`emptyDir` 볼륨은 처음에는 비어있다. 파드내 모든 컨테이너는 `emptyDir` 볼륨에서 동일한 -파일을 읽고 쓸수 있지만, 볼륨은 각각의 컨테이너에서 동일하거나 -다른 경로에 마운트 될 수 있다. 어떤 이유로든 노드에서 파드를 제거하면 +`emptyDir` 볼륨은 파드가 노드에 할당될 때 처음 생성되며, +해당 노드에서 파드가 실행되는 동안에만 존재한다. 이름에서 알 수 있듯이 +`emptyDir` 볼륨은 처음에는 비어있다. 파드 내 모든 컨테이너는 `emptyDir` 볼륨에서 동일한 +파일을 읽고 쓸 수 있지만, 해당 볼륨은 각각의 컨테이너에서 동일하거나 +다른 경로에 마운트될 수 있다. 어떤 이유로든 노드에서 파드가 제거되면 `emptyDir` 의 데이터가 영구적으로 삭제된다. {{< note >}} -컨테이너의 충돌은 노드에서 파드를 제거하지 *않기* 때문에, `emptyDir` 볼륨의 데이터는 컨테이너 충돌에서 안전하다. +컨테이너가 크래시되는 것은 노드에서 파드를 제거하지 *않는다*. `emptyDir` 볼륨의 데이터는 +컨테이너 크래시로부터 안전하다. {{< /note >}} `emptyDir` 의 일부 용도는 다음과 같다. @@ -333,15 +289,14 @@ Downward API를 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하 * 웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저 컨테이너가 가져오는 파일을 보관 -기본적으로, `emptyDir` 볼륨은 노드를 지원하는 모든 매체에 -저장된다(환경에 따라 디스크, SSD 또는 네트워크 스토리지일 -수 있다). 그러나 `emptyDir.medium` 필드를 `"Memory"` 로 설정해서 -쿠버네티스에 tmpfs(RAM 기반 파일 시스템)를 마운트하도록 할 수 있다. +환경에 따라, `emptyDir` 볼륨은 디스크, SSD 또는 네트워크 스토리지와 +같이 노드를 지원하는 모든 매체에 저장된다. 그러나, `emptyDir.medium` 필드를 +`"Memory"`로 설정하면, 쿠버네티스에 tmpfs(RAM 기반 파일시스템)를 마운트하도록 할 수 있다. tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs가 지워지고, 작성하는 모든 파일이 컨테이너 메모리 제한에 포함된다. -#### 파드 예시 +#### emptyDir 구성 예시 ```yaml apiVersion: v1 @@ -362,69 +317,72 @@ spec: ### fc (파이버 채널) {#fc} -`fc` 볼륨은 기존 파이버 채널 볼륨을 파드에 마운트할 수 있게 한다. -볼륨 구성에서 `targetWWNs` 파라미터를 사용하여 단일 또는 -다중 대상 월드 와이드 이름을 지정할 수 있다. 만약 여러 WWN이 지정된 경우, +`fc` 볼륨 유형은 기존 파이버 채널 블록 스토리지 볼륨을 +파드에 마운트할 수 있게 한다. 볼륨 구성에서 `targetWWNs` 파라미터를 사용하여 +단일 또는 다중 대상 월드 와이드 이름(WWN)을 지정할 수 있다. 만약 여러 WWN이 지정된 경우, targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다. -{{< caution >}} -이러한 LUN (볼륨)을 할당하고 대상 WWN에 마스킹하도록 FC SAN Zoning을 구성해야만 쿠버네티스 호스트가 해당 LUN에 접근할 수 있다. -{{< /caution >}} +{{< note >}} +이러한 LUN (볼륨)을 할당하고 대상 WWN에 마스킹하도록 FC SAN Zoning을 구성해야만 +쿠버네티스 호스트가 해당 LUN에 접근할 수 있다. +{{< /note >}} -더 자세한 내용은 [FC 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) 를 참조한다. +더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)를 참고한다. -### flocker {#flocker} +### flocker (사용 중단됨(deprecated)){#flocker} -[Flocker](https://github.com/ClusterHQ/flocker)는 오픈소스 클러스터 컨테이너 데이터 볼륨 매니저이다. 다양한 +[Flocker](https://github.com/ClusterHQ/flocker)는 오픈소스이고, 클러스터 +컨테이너 데이터 볼륨 매니저이다. Flocker는 다양한 스토리지 백엔드가 지원하는 데이터 볼륨 관리와 오케스트레이션을 제공한다. `flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약 Flocker내에 데이터셋이 없는 경우, 먼저 Flocker CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면 Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에 -따라 파드 간에 데이터를 "전달(handed off)" 할 수 있다는 의미이다. +따라 파드 간에 데이터를 공유할 수 있다는 의미이다. -{{< caution >}} +{{< note >}} `flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다. -{{< /caution >}} +{{< /note >}} 더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다. -### gcePersistentDisk {#gcepersistentdisk} +### gcePersistentDisk -`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진 (GCE) -[퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks)를 파드에 마운트 한다. 파드를 -제거할 때 지워지는 `emptyDir` 와는 다르게 PD의 내용은 유지되고, -볼륨은 마운트 해제만 된다. 이는 PD에 데이터를 -미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" 할 수 있다는 것을 의미한다. +`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진(GCE) +[영구 디스크](https://cloud.google.com/compute/docs/disks)(PD)를 파드에 마운트한다. +파드를 제거할 때 지워지는 `emptyDir` 와는 다르게, PD의 내용은 유지되고, +볼륨은 마운트 해제만 된다. 이는 PD에 데이터를 +미리 채울 수 있으며, 파드 간에 데이터를 공유할 수 있다는 것을 의미한다. -{{< caution >}} +{{< note >}} `gcePersistentDisk` 를 사용하려면 먼저 PD를 `gcloud`, GCE API 또는 UI를 사용해서 생성해야 한다. -{{< /caution >}} +{{< /note >}} -`gcePersistentDisk` 를 사용할 때 몇가지 제한이 있다. +`gcePersistentDisk` 를 사용할 때 몇 가지 제한이 있다. -* 파드가 실행중인 노드는 GCE VM이어야 함 -* 이러한 VM은 PD와 동일한 GCE 프로젝트와 영역에 있어야 함 +* 파드가 실행 중인 노드는 GCE VM이어야 함 +* 이러한 VM은 영구 디스크와 동일한 GCE 프로젝트와 영역에 있어야 함 -PD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 -있다는 것이다. 즉, 데이터셋으로 PD를 미리 채운 다음, 필요한 -만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, -PD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있으며 -동시 쓰기는 허용되지 않는다. +GCE 영구 디스크의 한 가지 기능은 영구 디스크에 대한 동시 읽기 전용 접근이다. +`gcePersistentDisk` 볼륨을 사용하면 여러 사용자가 영구 디스크를 읽기 전용으로 +동시에 마운트할 수 있다. 즉, PD를 데이터 세트로 미리 채운 다음 +필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행히도, +PD는 읽기-쓰기 모드에서 단일 사용자만 마운트할 수 있다. 동시 +쓰기는 허용되지 않는다. -ReplicationController가 제어하는 파드에서 PD를 사용하는 것은 -PD가 읽기 전용이거나 레플리카의 수가 0 또는 1이 아니라면 실패할 것이다. +PD가 읽기 전용이거나 레플리카의 수가 0 또는 1이 아니라면 레플리카셋(ReplicaSet)으로 제어되는 +파드가 있는 GCE 영구 디스크를 사용할 수 없다. -#### PD 생성하기 +#### GCE 영구 디스크 생성하기 {#gce-create-persistent-disk} -GCE PD를 파드와 함께 사용하려면 디스크를 먼저 생성해야 한다. +GCE 영구 디스크를 파드와 함께 사용하려면, 디스크를 먼저 생성해야 한다. ```shell gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk ``` -#### 예시 파드 +#### GCE 영구 디스크 구성 예시 ```yaml apiVersion: v1 @@ -446,18 +404,26 @@ spec: fsType: ext4 ``` -#### 지역(Regional) 퍼시스턴트 디스크 -[지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. +#### 리전 영구 디스크 + +[리전 영구 디스크](https://cloud.google.com/compute/docs/disks/#repds) +기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 영구 디스크를 +생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨(PersistentVolume)으로 +프로비저닝해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. + +#### 리전 PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 + +[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 +사용해서 동적 프로비저닝이 가능하다. +퍼시스턴트볼륨을 생성하기 전에 영구 디스크를 생성해야만 한다. -#### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 -[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 사용해서 동적 프로비저닝이 가능하다. -PersistentVolume을 생성하기 전에 PD를 생성해야만 한다. ```shell gcloud compute disks create --size=500GB my-data-disk - --region us-central1 - --replica-zones us-central1-a,us-central1-b + --region us-central1 + --replica-zones us-central1-a,us-central1-b ``` -PersistentVolume 사양 예시 + +#### 리전 영구 디스크 구성 예시 ```yaml apiVersion: v1 @@ -483,29 +449,28 @@ spec: - us-central1-b ``` -#### CSI 마이그레이션 +#### GCE CSI 마이그레이션 {{< feature-state for_k8s_version="v1.17" state="beta" >}} -GCE PD의 CSI 마이그레이션 기능이 활성화된 경우 기존 트리 내 플러그인에서 +GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러그인에서 `pd.csi.storage.gke.io` 컨테이너 스토리지 인터페이스(CSI) -드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI +드라이버로 모든 플러그인 작업을 리디렉션한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI 드라이버](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationGCE` 베타 기능을 활성화해야 한다. -### gitRepo (사용 중단(deprecated)) {#gitrepo} +### gitRepo (사용 중단됨) {#gitrepo} {{< warning >}} -gitRepo 볼륨 유형은 사용 중단(deprecated)되었다. git repo가 있는 컨테이너를 프로비전 하려면 초기화 컨테이너(InitContainer)에 [EmptyDir](#emptydir)을 마운트하고, 여기에 git을 사용해서 repo를 복제하고, [EmptyDir](#emptydir)을 파드 컨테이너에 마운트 한다. +`gitRepo` 볼륨 유형은 사용 중단되었다. git repo가 있는 컨테이너를 프로비전 하려면 초기화 컨테이너(InitContainer)에 [EmptyDir](#emptydir)을 마운트하고, 여기에 git을 사용해서 repo를 복제하고, [EmptyDir](#emptydir)을 파드 컨테이너에 마운트 한다. {{< /warning >}} -`gitRepo` 볼륨은 볼륨 플러그인으로 할 수 있는 예시이다. 빈 -디렉터리를 마운트하고 파드가 사용할 수 있도록 해당 디렉터리에 git 리포지트리를 -복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에 -이런 볼륨은 훨씬 더 분리된 모델로 이동될 수 있다. +`gitRepo` 볼륨은 볼륨 플러그인의 예시이다. 이 플러그인은 +빈 디렉터리를 마운트하고 파드가 사용할 수 있도록 이 디렉터리에 git 리포지터리를 +복제한다. -여기 gitRepo 볼륨의 예시가 있다. +여기 `gitRepo` 볼륨의 예시가 있다. ```yaml apiVersion: v1 @@ -526,19 +491,19 @@ spec: revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` -### glusterfs {#glusterfs} +### glusterfs `glusterfs` 볼륨을 사용하면 [Glusterfs](https://www.gluster.org) (오픈 -소스 네트워크 파일시스템) 볼륨을 파드에 마운트 할수 있다. 파드를 +소스 네트워크 파일시스템) 볼륨을 파드에 마운트할 수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs` 볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 -glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데이터를 -"전달(handed off)" 할 수 있다. GlusterFS는 여러 작성자가 동시에 +glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데이터를 +공유할 수 있다. GlusterFS는 여러 작성자가 동시에 마운트할 수 있다. -{{< caution >}} +{{< note >}} 사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다. -{{< /caution >}} +{{< /note >}} 더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다. @@ -576,14 +541,12 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데 * 동일한 구성(파드템플릿으로 생성한 것과 같은)을 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다. -* 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서 - 사용되는 리소스를 설명할 수 없다. * 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/tasks/configure-pod-container/security-context/)에서 루트로 실행하거나 `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다. -#### 파드 예시 +#### hostPath 구성 예시 ```yaml apiVersion: v1 @@ -607,10 +570,13 @@ spec: ``` {{< caution >}} -`FileOrCreate` 모드에서는 파일의 상위 디렉터리가 생성되지 않는다. 마운트된 파일의 상위 디렉터리가 없으면 파드가 시작되지 않는다. 이 모드가 작동하도록 하기 위해 다음과 같이 디렉터리와 파일을 별도로 마운트할 수 있다. +`FileOrCreate` 모드는 파일의 상위 디렉터리를 생성하지 않는다. 마운트된 파일의 상위 디렉터리가 +없으면 파드가 시작되지 않는다. 이 모드가 작동하는지 확인하려면, +[`FileOrCreate` 구성](#hostpath-fileorcreate-example)에 표시된대로 +디렉터리와 파일을 별도로 마운트할 수 있다. {{< /caution >}} -#### FileOrCreate 파드 예시 +#### hostPath FileOrCreate 구성 예시 {#hostpath-fileorcreate-example} ```yaml apiVersion: v1 @@ -638,49 +604,47 @@ spec: type: FileOrCreate ``` -### iscsi {#iscsi} +### iscsi `iscsi` 볼륨을 사용하면 기존 iSCSI (SCSI over IP) 볼륨을 파드에 마운트 -할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 +할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `iscsi` 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 해제만 된다. 이 의미는 iscsi 볼륨에 데이터를 미리 채울 수 있으며, -파드간에 데이터를 "전달(handed off)" 할 수 있다는 것이다. +파드간에 데이터를 공유할 수 있다는 것이다. -{{< caution >}} +{{< note >}} 사용하려면 먼저 iSCSI 서버를 실행하고 볼륨을 생성해야 한다. -{{< /caution >}} +{{< /note >}} iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수 -있다는 것이다. 즉, 데이터셋으로 사전에 볼륨을 채운다음, -필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행하게도, -iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있으며 +있다는 것이다. 즉, 데이터셋으로 사전에 볼륨을 채운다음, +필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행하게도, +iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있다. 동시 쓰기는 허용되지 않는다. 더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)를 본다. -### local {#local} - -{{< feature-state for_k8s_version="v1.14" state="stable" >}} +### local `local` 볼륨은 디스크, 파티션 또는 디렉터리 같은 마운트된 로컬 스토리지 장치를 나타낸다. -로컬 볼륨은 정적으로 생성된 퍼시스턴트볼륨(PersistentVolume)으로만 사용할 수 있다. 동적으로 -프로비저닝된 것은 아직 지원되지 않는다. +로컬 볼륨은 정적으로 생성된 퍼시스턴트볼륨으로만 사용할 수 있다. 동적으로 +프로비저닝된 것은 지원되지 않는다. -`hostPath` 볼륨에 비해 로컬 볼륨은 퍼시스턴트볼륨의 노드 어피니티를 살펴봄으로써 -볼륨의 노드 제약 조건을 인식하기 때문에 수동으로 파드를 노드에 예약하지 않고도 -내구성과 휴대성을 갖춘 방식으로 사용할 수 있다. +`hostPath` 볼륨에 비해 `local` 볼륨은 수동으로 파드를 노드에 예약하지 않고도 +내구성과 휴대성을 갖춘 방식으로 사용된다. 시스템은 +퍼시스턴트볼륨의 노드 어피니티를 확인하여 볼륨의 노드 제약 조건을 인식한다. -그러나 로컬 볼륨은 여전히 기본 노드의 가용성을 따르며 +그러나 `local` 볼륨은 여전히 기본 노드의 가용성을 따르며 모든 애플리케이션에 적합하지는 않는다. 만약 노드가 비정상 상태가 -되면 로컬 볼륨도 접근할 수 없게 되고, 파드를 실행할 수 -없게 된다. 로컬 볼륨을 사용하는 애플리케이션은 기본 디스크의 +되면 `local` 볼륨도 접근할 수 없게 되고, 파드를 실행할 수 +없게 된다. `local` 볼륨을 사용하는 애플리케이션은 기본 디스크의 내구 특성에 따라 이러한 감소되는 가용성과 데이터 손실 가능성도 허용할 수 있어야 한다. -다음은 `local` 볼륨과 `nodeAffinity` 를 사용하는 퍼시스턴트볼륨 -사양 예시이다. +다음의 예시는 `local` 볼륨과 `nodeAffinity` 를 사용하는 퍼시스턴트볼륨을 +보여준다. ```yaml apiVersion: v1 @@ -707,18 +671,18 @@ spec: - example-node ``` -로컬 볼륨을 사용할 때는 퍼시스턴트볼륨의 `nodeAffinity` 가 필요하다. 이를 통해 -쿠버네티스 스케줄러는 올바른 노드의 로컬 볼륨을 파드가 사용할 수 있도록 올바르게 -스케줄할 수 있다. +`local` 볼륨을 사용하는 경우 퍼시스턴트볼륨 `nodeAffinity` 를 설정해야 합니다. +쿠버네티스 스케줄러는 퍼시스턴트볼륨 `nodeAffinity` 를 사용하여 +파드를 올바른 노드로 스케줄한다. 퍼시스턴트볼륨의 `volumeMode` 을 "Block" (기본값인 "Filesystem"을 대신해서)으로 설정하면 로컬 볼륨을 원시 블록 장치로 노출할 수 있다. 로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된 -스토리지클래스(StorageClass)를 생성하는 것을 권장한다. -[예시](/ko/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 -퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터, -파드 어피니티 그리고 파드 안티 어피니티와 +스토리지클래스(StorageClass)를 생성하는 것을 권장한다. 자세한 내용은 +local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-classes/#local) 예제를 참고한다. +볼륨 바인딩을 지연시키는 것은 퍼시스턴트볼륨클래임 바인딩 결정도 +노드 리소스 요구사항, 노드 셀렉터, 파드 어피니티 그리고 파드 안티 어피니티와 같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다. 로컬 볼륨 라이프사이클의 향상된 관리를 위해 외부 정적 @@ -733,18 +697,18 @@ spec: 필요하다. {{< /note >}} -### nfs {#nfs} +### nfs `nfs` 볼륨을 사용하면 기존 NFS (네트워크 파일 시스템) 볼륨을 파드에 마운트 -할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 +할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `nfs` 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 해제만 된다. 이 의미는 NFS 볼륨에 데이터를 미리 채울 수 있으며, -파드간에 데이터를 "전달(handed off)" 할 수 있다는 뜻이다. NFS는 여러 작성자가 +파드 간에 데이터를 공유할 수 있다는 뜻이다. NFS는 여러 작성자가 동시에 마운트할 수 있다. -{{< caution >}} +{{< note >}} 사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다. -{{< /caution >}} +{{< /note >}} 더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다. @@ -758,27 +722,59 @@ iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다. 더 자세한 내용은 [퍼시스턴트볼륨 예시](/ko/docs/concepts/storage/persistent-volumes)를 본다. -### projected {#projected} +### portworxVolume {#portworxvolume} + +`portworxVolume` 은 쿠버네티스와 하이퍼컨버지드(hyperconverged)를 실행하는 탄력적인 블록 스토리지 +계층이다. [Portworx](https://portworx.com/use-case/kubernetes-storage/)는 서버의 +스토리지를 핑거프린팅하고(fingerprints), 기능에 기반하여 계층화하고, 그리고 여러 서버에 걸쳐 용량을 집계한다. +Portworx는 가상 머신 내 게스트 또는 베어 메탈 리눅스 노드 위에서 실행된다. + +`portworxVolume` 은 쿠버네티스를 통해 동적으로 생성되거나 +사전에 프로비전할 수 있으며 쿠버네티스 파드 내에서 참조할 수 있다. +다음은 사전에 프로비저닝된 Portworx 볼륨을 참조하는 파드의 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # 이 Portworx 볼륨은 이미 존재해야 한다. + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< note >}} +파드에서 사용하기 이전에 먼저 이름이 `pxvol` 인 PortworxVolume이 +있는지 확인한다. +{{< /note >}} + +자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) 예제를 참고한다. + +### projected `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. 현재, 다음 유형의 볼륨 소스를 프로젝티드한다. -- [`secret`](#secret) -- [`downwardAPI`](#downwardapi) -- [`configMap`](#configmap) -- `serviceAccountToken` +* [`secret`](#secret) +* [`downwardAPI`](#downwardapi) +* [`configMap`](#configmap) +* `serviceAccountToken` 모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은 [올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)를 본다. -서비스 어카운트 토큰의 프로젝션은 쿠버네티스 1.11에 기능이 -도입되었고 1.12에서 베타로 승격되었다. -1.11에서 이 기능을 활성화 하려면 `TokenRequestProjection` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -True로 명시적인 설정이 필요하다. - -#### 시크릿, downward API 그리고 configmap이 있는 파드 예시. +#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap} ```yaml apiVersion: v1 @@ -818,7 +814,7 @@ spec: path: my-group/my-config ``` -#### 기본값이 아닌 모드 설정과 여러 시크릿을 가진 파드 예시 +#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#example-configuration-secrets-nondefault-permission-mode} ```yaml apiVersion: v1 @@ -853,7 +849,7 @@ spec: 각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다. 파라미터는 두 가지 예외를 제외하고 거의 동일하다. -* 시크릿의 경우 `secretName` 필드는 ConfigMap 이름과 일치하도록 +* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록 `name` 으로 변경되었다. * `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만 지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode` @@ -861,7 +857,7 @@ spec: `TokenRequestProjection` 기능이 활성화 되면, 현재 [서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에 -대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 아래는 예시이다. +대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다. ```yaml apiVersion: v1 @@ -887,7 +883,7 @@ spec: ``` 예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이 -있다. 예를 들어 이 토큰은 파드 컨테이너에서 쿠버네티스 API 서버에 접근하는데 +있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데 사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을 포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며, 그렇지 않으면 토큰을 거부해야 한다. 이 필드는 @@ -900,95 +896,60 @@ API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정 상대 경로를 지정한다. {{< note >}} -projected 볼륨 소스를 [subPath](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다. +projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다. {{< /note >}} -### portworxVolume {#portworxvolume} - -`portworxVolume` 은 쿠버네티스와 하이퍼컨버지드(hyperconverged)를 실행하는 탄력적인 블록 스토리지 -계층이다. [Portworx](https://portworx.com/use-case/kubernetes-storage/)는 서버에 스토리지 지문을 남기고, 역량에 기반하여 계층화 하고, -그리고 여러 서버에 걸쳐 용량을 집계한다. Portworx는 가상 머신 내 게스트 또는 베어 메탈 리눅스 노드 위에서 실행된다. - -`portworxVolume` 은 쿠버네티스를 통해 동적으로 생성되거나 -사전 프로비전할 수 있으며 쿠버네티스 파드 내에서 참조할 수 있다. -여기에 사전에 프로비전 된 PortworxVolume을 참조하는 파드의 예시가 있다. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: test-portworx-volume-pod -spec: - containers: - - image: k8s.gcr.io/test-webserver - name: test-container - volumeMounts: - - mountPath: /mnt - name: pxvol - volumes: - - name: pxvol - # 이 Portworx 볼륨은 이미 존재해야 한다. - portworxVolume: - volumeID: "pxvol" - fsType: "" -``` - -{{< caution >}} -파드에서 사용하기 이전에 먼저 이름이 `pxvol` 인 PortworxVolume -이 있는지 확인한다. -{{< /caution >}} - -더 자세한 내용과 예시는 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md)에서 찾을 수 있다. - -### quobyte {#quobyte} +### quobyte `quobyte` 볼륨을 사용하면 기존 [Quobyte](http://www.quobyte.com) 볼륨을 파드에 마운트할 수 있다. -{{< caution >}} +{{< note >}} 사용하기 위해선 먼저 Quobyte를 설정하고 생성한 볼륨과 함께 실행해야 한다. -{{< /caution >}} +{{< /note >}} Quobyte는 {{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}를 지원한다. CSI 는 쿠버네티스 내에서 Quobyte 볼륨을 사용하기 위해 권장하는 플러그인이다. Quobyte의 깃헙 프로젝트에는 예시와 함께 CSI를 사용해서 Quobyte를 배포하기 위한 [사용 설명서](https://github.com/quobyte/quobyte-csi#quobyte-csi)가 있다. -### rbd {#rbd} +### rbd `rbd` 볼륨을 사용하면 -[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/)를 파드에 마운트할 수 -있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 -내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 +[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/)(RBD) 볼륨을 파드에 마운트할 수 +있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 +내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를 -"전달(handed off)" 할 수 있다는 것이다. +공유할 수 있다는 것이다. -{{< caution >}} +{{< note >}} RBD를 사용하기 위해선 먼저 Ceph를 설치하고 실행해야 한다. -{{< /caution >}} +{{< /note >}} RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 -있다는 것이다. 즉, 데이터셋으로 볼륨을 미리 채운 다음, 필요한 -만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, -RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있으며 +있다는 것이다. 즉, 데이터셋으로 볼륨을 미리 채운 다음, 필요한 +만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, +RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 동시 쓰기는 허용되지 않는다. -더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를 본다. +더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를 +참고한다. -### scaleIO {#scaleio} +### scaleIO (사용 중단됨) {#scaleio} ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를 -생성할 수 있는 소프트웨어 기반 스포티리 플랫폼이다. `scaleIO` 볼륨 +생성하는 소프트웨어 기반 스토리지 플랫폼이다. `scaleIO` 볼륨 플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수 -있다(또는 퍼시스턴트 볼륨 클래임을 위한 새 볼륨을 동적 프로비전할 수 있음, -[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 본다). +있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는 +방법에 대한 자세한 내용은 +[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 참고한다. -{{< caution >}} +{{< note >}} 사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고 생성한 볼륨과 함께 실행해야 한다. -{{< /caution >}} +{{< /note >}} -다음은 파드 구성을 ScaleIO와 함께 하는 예시이다. +다음의 예시는 ScaleIO를 사용하는 파드 구성이다. ```yaml apiVersion: v1 @@ -1015,26 +976,26 @@ spec: fsType: xfs ``` -자세한 내용은 [ScaleIO 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio)를 본다. +더 자세한 내용은 [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) 예제를 참고한다. -### secret {#secret} +### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 -사용된다. 쿠버네티스 API에 시크릿을 저장하고 쿠버네티스에 직접적으로 연결하지 않고도 -파드에서 사용할 수 있도록 파일로 마운트 할 수 있다. `secret` 볼륨은 +사용된다. 쿠버네티스 API에 시크릿을 저장하고 쿠버네티스에 직접적으로 연결하지 않고도 +파드에서 사용할 수 있도록 파일로 마운트 할 수 있다. `secret` 볼륨은 tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토리지에 절대 기록되지 않는다. -{{< caution >}} +{{< note >}} 사용하기 위해선 먼저 쿠버네티스 API에서 시크릿을 생성해야 한다. -{{< /caution >}} +{{< /note >}} {{< note >}} -시크릿을 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 시크릿 +시크릿을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 시크릿 업데이트를 수신하지 못한다. {{< /note >}} -시크릿에 대해서 [여기](/ko/docs/concepts/configuration/secret/)에 더 자세한 설명이 있다. +더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다. ### storageOS {#storageos} @@ -1058,6 +1019,8 @@ StorageOS 볼륨에 접근하거나 스토리지 용량을 [StorageOS 문서](https://docs.storageos.com)를 찾아본다. {{< /caution >}} +다음의 예시는 StorageOS를 사용한 파드 구성이다. + ```yaml apiVersion: v1 kind: Pod @@ -1086,24 +1049,24 @@ spec: fsType: ext4 ``` -동적 프로비저닝과 퍼시스턴트 볼륨 클래임을 포함한 더 많은 정보는 -[StorageOS 예시](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 본다. +StorageOS, 동적 프로비저닝과 퍼시스턴트 볼륨 클래임에 대한 더 자세한 정보는 +[StorageOS 예제](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 참고한다. ### vsphereVolume {#vspherevolume} {{< note >}} -전제조건: 쿠버네티스와 함께 vSphere Cloud Provider가 구성됨. 클라우드공급자 +쿠버네티스 vSphere 클라우드 공급자를 구성해야 한다. 클라우드공급자 구성에 대해선 [vSphere 시작 가이드](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)를 참조한다. {{< /note >}} `vsphereVolume` 은 vSphere VMDK 볼륨을 파드에 마운트하는데 사용된다. 볼륨을 마운트 해제해도 볼륨의 내용이 유지된다. VMFS와 VSAM 데이터스토어를 모두 지원한다. -{{< caution >}} -파드와 함께 사용하기 위해선 먼저 다음 방법중 하나를 사용해서 VMDK를 생성해야 한다. -{{< /caution >}} +{{< note >}} +파드와 함께 사용하기 위해선 먼저 다음 방법 중 하나를 사용하여 vSphere VMDK 볼륨을 생성해야 한다. +{{< /note >}} -#### VMDK 볼륨 생성하기 +#### VMDK 볼륨 생성하기 {#creating-vmdk-volume} 다음 중 하나를 선택해서 VMDK를 생성한다. @@ -1114,6 +1077,7 @@ spec: ```shell vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk ``` + {{% /tab %}} {{% tab name="vmware-vdiskmanager를 사용해서 생성" %}} 다음 명령을 사용해서 VMDK를 생성한다. @@ -1121,12 +1085,13 @@ vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk ```shell vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk ``` + {{% /tab %}} {{< /tabs >}} -#### vSphere VMDK 예시 구성 +#### vSphere VMDK 구성 예시 {#vsphere-vmdk-configuration} ```yaml apiVersion: v1 @@ -1148,23 +1113,23 @@ spec: fsType: ext4 ``` -더 많은 예시는 [여기](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)에서 확인할 수 있다. +더 자세한 내용은 [vSphere 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) 예제를 참고한다. -#### CSI 마이그레이션 +#### vSphere CSI 마이그레이션 {#vsphere-csi-migration} {{< feature-state for_k8s_version="v1.19" state="beta" >}} -vsphereVolume용 CSI 마이그레이션 기능이 활성화되면, 기존 인-트리 플러그인에서 -`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 shim한다. -이 기능을 사용하려면, [vSphere CSI -드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 +`vsphereVolume` 용 `CSIMigration` 기능이 활성화되면, 기존 인-트리 플러그인에서 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다. +이 기능을 사용하려면, +[vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. 또한 최소 vSphere vCenter/ESXi 버전은 7.0u1이고 최소 HW 버전은 VM 버전 15여야 한다. {{< note >}} -빌트인 vsphereVolume 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다. +빌트인 `vsphereVolume` 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다. * `diskformat` * `hostfailurestotolerate` @@ -1174,22 +1139,28 @@ vsphereVolume용 CSI 마이그레이션 기능이 활성화되면, 기존 인- * `objectspacereservation` * `iopslimit` -이러한 파라미터를 사용하여 생성된 기존 볼륨은 vSphere CSI 드라이버로 마이그레이션되지만, vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 따르지 않는다. +이러한 파라미터를 사용하여 생성된 기존 볼륨은 vSphere CSI 드라이버로 마이그레이션되지만, +vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 따르지 않는다. {{< /note >}} -#### CSI 마이그레이션 완료 +#### vSphere CSI 마이그레이션 완료 {#vsphere-csi-migration-complete} + {{< feature-state for_k8s_version="v1.19" state="beta" >}} -vsphereVolume 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 true로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치되어 있어야 한다. +`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치해야 한다. +## subPath 사용하기 {#using-subpath} -## subPath 사용하기 +때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. +`volumeMounts.subPath` 속성을 사용해서 root 대신 참조하는 볼륨 내의 하위 경로를 +지정할 수 있다. -때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. `volumeMounts.subPath` -속성을 사용해서 root 대신 참조하는 볼륨 내의 하위 경로를 지정할 수 있다. +다음의 예시는 단일 공유 볼륨을 사용하여 LAMP 스택(리눅스 Apache MySQL PHP)이 +있는 파드를 구성하는 방법을 보여준다. 이 샘플 `subPath` 구성은 프로덕션 용도로 +권장되지 않는다. -여기에 단일 공유 볼륨을 사용하는 LAMP 스택(리눅스 아파치 Mysql PHP)이 포함된 파드의 예시가 있다. -HTML 내용은 `html` 폴더에 매핑되고 데이터베이스는 `mysql` 폴더에 저장된다. +PHP 애플리케이션의 코드와 자산은 볼륨의 `html` 폴더에 매핑되고 +MySQL 데이터베이스는 볼륨의 `mysql` 폴더에 저장된다. 예를 들면 다음과 같다. ```yaml apiVersion: v1 @@ -1219,15 +1190,18 @@ spec: claimName: my-lamp-site-data ``` -### subPath를 확장된 환경 변수와 함께 사용하기 +### subPath를 확장된 환경 변수와 함께 사용하기 {#using-subpath-expanded-environment} {{< feature-state for_k8s_version="v1.17" state="stable" >}} - -`subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다. +`subPathExpr` 필드를 사용해서 다운워드 API 환경 변수로부터 +`subPath` 디렉터리 이름을 구성한다. `subPath` 와 `subPathExpr` 속성은 상호 배타적이다. -이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다. 호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다. +이 예제는 `Pod` 가 `subPathExpr` 을 사용해서 `hostPath` 볼륨 +`/var/log/pods` 내에 `pod1` 디렉터리를 만든다. +`hostPath` 볼륨은 `downwardAPI` 에서 `Pod` 이름을 사용한다. +호스트 디렉토리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트된다. ```yaml apiVersion: v1 @@ -1258,47 +1232,41 @@ spec: ## 리소스 -`emptyDir` 볼륨의 스토리지 매체(디스크, SSD, 등)는 kubelet root +`emptyDir` 볼륨의 스토리지 매체(디스크나 SSD와 같은)는 kubelet root 디렉터리(보통 `/var/lib/kubelet`)를 보유한 파일시스템의 -매체에 의해 결정 된다. `emptyDir` 또는 `hostPath` 볼륨이 -사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너간 또는 파드간 -격리는 없다. +매체에 의해 결정 된다. `emptyDir` 또는 `hostPath` 볼륨이 +사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너 간 또는 파드 간 격리는 +없다. -앞으로 `emptyDir` 과 `hostPath` 볼륨이 [리소스](/ko/docs/concepts/configuration/manage-resources-containers/) -사양을 사용해서 일정량의 공간을 요청하고, 여러 매체 유형이 -있는 클러스터에 사용할 매체 유형을 선택할 수 -있을 것으로 기대한다. +리소스 사양을 사용한 공간 요청에 대한 자세한 내용은 +[리소스 관리 방법](/ko/docs/concepts/configuration/manage-resources-containers/)을 참고한다. -## 아웃 오브 트리 볼륨 플러그인 +## 아웃-오브-트리(out-of-tree) 볼륨 플러그인 -아웃 오브 트리 볼륨 플러그인에는 컨테이너 스토리지 인터페이스 (CSI) 그리고 -FlexVolume이 포함된다. 스토리지 벤더들은 이 플러그인을 쿠버네티스 리포지터리에 +아웃-오브-트리 볼륨 플러그인에는 +{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 +FlexVolume이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. -CSI 와 FlexVolume을 도입하기 전에는 모든 볼륨 플러그인(위 -목록의 볼륨 유형과 같은)은 "인 트리(in-tree)" 로 쿠버네티스 핵심 -바이너리와 함께 빌드, 링크, 컴파일 그리고 전달되었고 쿠버네티스 -핵심 API를 확장했다. 이는 새로운 스토리지 시스템을 쿠버네티스( -볼륨 플러그인)에 추가하려면 쿠버네티스 핵심 코드 리포지토리의 코드 확인이 필요했음을 의미한다. +이전에는 모든 볼륨 플러그인이 "인-트리(in-tree)"에 있었다. "인-트리" 플러그인은 쿠버네티스 핵심 바이너리와 +함께 빌드, 링크, 컴파일 및 배포되었다. 즉, 쿠버네티스(볼륨 플러그인)에 +새로운 스토리지 시스템을 추가하려면 쿠버네티스 핵심 코드 리포지토리의 코드 확인이 필요했음을 의미한다. CSI와 FlexVolume을 통해 쿠버네티스 코드 베이스와는 독립적으로 볼륨 플러그인을 개발하고, 쿠버네티스 클러스터의 확장으로 배포(설치) 할 수 있다. 아웃 오브 트리(out-of-tree) 볼륨 플러그인을 생성하려는 스토리지 벤더는 -[이 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)를 참조한다. +[볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)를 참조한다. -### CSI +### csi -[컨테이너 스토리지 인터페이스](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) -는 컨테이너 오케스트레이션 시스템(쿠버네티스와 같은)을 위한 표준 인터페이스를 +[컨테이너 스토리지 인터페이스](https://github.com/container-storage-interface/spec/blob/master/spec.md)(CSI)는 +컨테이너 오케스트레이션 시스템(쿠버네티스와 같은)을 위한 표준 인터페이스를 정의하여 임의의 스토리지 시스템을 컨테이너 워크로드에 노출시킨다. 더 자세한 정보는 [CSI 디자인 제안](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)을 읽어본다. -CSI 지원은 쿠버네티스 v1.9에서 알파로 도입이 되었고, 쿠버네티스 v1.10에서 -베타로 이동되고 쿠버네티스 v1.13에서 정식(GA)이 되었다. - {{< note >}} CSI 규격 버전 0.2와 0.3에 대한 지원은 쿠버네티스 v1.13에서 사용중단(deprecated) 되었고, 향후 릴리스에서 제거될 예정이다. @@ -1311,57 +1279,59 @@ CSI 드라이버는 일부 쿠버네티스 릴리스에서 호환되지 않을 {{< /note >}} CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 -`csi` 볼륨 유형을 사용해서 CSI 드라이버에 의해 노출된 볼륨에 연결, 마운트, -등을 할 수 있다. +사용자는 `csi` 볼륨 유형을 사용해서 CSI 드라이버에 의해 노출된 볼륨에 연결하거나 +마운트할 수 있다. `csi` 볼륨은 세 가지 방법으로 파드에서 사용할 수 있다. -- [`persistentVolumeClaim`](#persistentvolumeclaim)에 대한 참조를 통해서 -- [일반 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)과 함께 (알파 기능) -- 드라이버가 지원하는 경우 - [CSI 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) (베타 기능) + +* [퍼시스턴트볼륨클레임](#persistentvolumeclaim)에 대한 참조를 통해서 +* [일반 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)과 함께 +(알파 기능) +* 드라이버가 지원하는 경우 +[CSI 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)과 함께 (베타 기능) 스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을 구성할 수 있다. -- `driver`: 사용할 볼륨 드라이버의 이름을 지정하는 문자열 값. +* `driver`: 사용할 볼륨 드라이버의 이름을 지정하는 문자열 값. 이 값은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)에 정의된 CSI 드라이버가 `GetPluginInfoResponse` 에 반환하는 값과 일치해야 한다. 쿠버네티스에서 호출할 CSI 드라이버를 식별하고, CSI 드라이버 컴포넌트에서 CSI 드라이버에 속하는 PV 오브젝트를 식별하는데 사용한다. -- `volumeHandle`: 볼륨을 식별하게 하는 고유한 문자열 값. +* `volumeHandle`: 볼륨을 식별하게 하는 고유한 문자열 값. 이 값은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)에 정의된 CSI 드라이버가 `CreateVolumeResponse` 의 `volume.id` 필드에 반환하는 값과 일치해야 한다. 이 값은 볼륨을 참조할 때 CSI 볼륨 드라이버에 대한 모든 호출에 `volume_id` 값을 전달한다. -- `readOnly`: 볼륨을 읽기 전용으로 "ControllerPublished" (연결)할지 +* `readOnly`: 볼륨을 읽기 전용으로 "ControllerPublished" (연결)할지 여부를 나타내는 선택적인 불리언(boolean) 값. 기본적으로 false 이다. 이 값은 `ControllerPublishVolumeRequest` 의 `readonly` 필드를 통해 CSI 드라이버로 전달된다. -- `fsType`: 만약 PV의 `VolumeMode` 가 `Filesystem` 인 경우에 이 필드는 +* `fsType`: 만약 PV의 `VolumeMode` 가 `Filesystem` 인 경우에 이 필드는 볼륨을 마운트하는 데 사용해야 하는 파일시스템을 지정하는 데 사용될 수 있다. 만약 볼륨이 포맷되지 않았고 포맷이 지원되는 경우, 이 값은 볼륨을 포맷하는데 사용된다. 이 값은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest` 그리고 `NodePublishVolumeRequest` 의 `VolumeCapability` 필드를 통해 CSI 드라이버로 전달된다. -- `volumeAttributes`: 볼륨의 정적 속성을 지정하는 문자열과 문자열을 +* `volumeAttributes`: 볼륨의 정적 속성을 지정하는 문자열과 문자열을 매핑한다. 이 매핑은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)에 정의된 대로 CSI 드라이버의 `CreateVolumeResponse` 와 `volume.attributes` 필드에서 반환되는 매핑과 일치해야 한다. 이 매핑은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, 그리고 `NodePublishVolumeRequest` 의 `volume_context` 필드를 통해 CSI 드라이버로 전달된다. -- `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume` +* `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume` 그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는 민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는 - 선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 + 선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에 둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다. -- `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해 +* `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해 CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 - 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 + 경우 비어있을 수 있다. 만약 시크릿에 둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다. -- `nodePublishSecretRef`: CSI의 `NodePublishVolume` 호출을 완료하기위해 +* `nodePublishSecretRef`: CSI의 `NodePublishVolume` 호출을 완료하기위해 CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 @@ -1375,7 +1345,7 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 지원을 구현할 수 있다. CSI 설정 변경 없이 평소와 같이 -[원시 블록 볼륨 지원으로 PV/PVC 설정](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 할 수 있다. +[원시 블록 볼륨 지원으로 퍼시스턴트볼륨/퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원) 설정을 할 수 있다. #### CSI 임시(ephemeral) 볼륨 @@ -1384,105 +1354,104 @@ CSI 설정 변경 없이 평소와 같이 파드 명세 내에서 CSI 볼륨을 직접 구성할 수 있다. 이 방식으로 지정된 볼륨은 임시 볼륨이며 파드가 다시 시작할 때 지속되지 않는다. 자세한 내용은 [임시 -볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)을 +볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)을 참고한다. -#### {{% heading "whatsnext" %}} +CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 +[쿠버네티스-csi 문서](https://kubernetes-csi.github.io/docs/)를 참조한다. -CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 [쿠버네티스-csi -문서](https://kubernetes-csi.github.io/docs/)를 참조한다. +#### 인-트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기 -#### 인 트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기 +{{< feature-state for_k8s_version="v1.17" state="beta" >}} -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} - -TCSI 마이그레이션 기능이 활성화 되면 기존의 인 트리 플러그인에 +`CSIMigration` 기능이 활성화 되면 기존의 인-트리 플러그인에 대한 작업을 해당 CSI 플러그인(설치와 구성이 될 것으로 예상한)으로 유도한다. -이 기능은 필요한 변환 논리와 심(shims)을 구현하여 작업을 완전한 -방식으로 재 라우팅 한다. 결과적으로 운영자는 인 트리 플러그인을 대체하는 -CSI 드라이버로 전환할 때 기존 스토리지 클래스, PV 또는 PVC(인 트리 -플러그인 참조)에 대한 구성을 변경할 필요가 없다. +결과적으로, 운영자는 인-트리 플러그인을 대체하는 +CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임(인-트리 플러그인 참조)에 +대한 구성 변경을 수행할 필요가 없다. -알파 상태에서 지원되는 작업과 기능에는 프로비저닝/삭제, +지원되는 작업 및 기능은 프로비저닝/삭제, 연결/분리, 마운트/마운트 해제 그리고 볼륨 크기 재조정이 포함된다. -CSI 마이그레이션을 지원하고 해당 CSI 드라이버가 구현된 인 트리 플러그인은 -위의 "볼륨 유형" 섹션에 나열되어 있다. +`CSIMigration` 을 지원하고 해당 CSI 드라이버가 구현된 인-트리 플러그인은 +[볼륨 유형들](#volume-types)에 나열되어 있다. -### FlexVolume {#flexVolume} +### flexVolume -FlexVolume은 버전 1.2 (CSI 이전) 이후 쿠버네티스에 존재하는 -아웃 오브 트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 -접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드(그리고 일부 경우에 마스터)에 +FlexVolume은 버전 1.2(CSI 이전) 이후 쿠버네티스에 존재하는 +아웃-오브-트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 +접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드와 일부 경우에 컨트롤 플레인 노드의 미리 정의된 볼륨 플러그인 경로에 설치해야 한다. -파드는 `flexvolume` 인 트리 플러그인을 통해 FlexVolume 드라이버와 상호 작용 한다. -더 자세한 내용은 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)에서 찾아볼 수 있다. +파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다. +더 자세한 내용은 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 예제를 참고한다. ## 마운트 전파(propagation) 마운트 전파를 통해 컨테이너가 마운트한 볼륨을 동일한 파드의 다른 컨테이너 또는 동일한 노드의 다른 파드로 공유할 수 있다. -볼륨 마운트 전파는 Container.volumeMounts의 `mountPropagation` 필드에 의해 제어된다. -그 값은 다음과 같다. +볼륨 마운트 전파는 `Container.volumeMounts` 의 `mountPropagation` 필드에 +의해 제어된다. 그 값은 다음과 같다. - * `None` - 이 볼륨 마운트는 호스트의 볼륨 또는 해당 서브디렉터리에 - 마운트된 것을 마운트 이후에 수신하지 않는다. - 비슷한 방식으로, 컨테이너가 생성 한 마운트는 호스트에서 볼 수 없다. - 이것이 기본 모드이다. +* `None` - 이 볼륨 마운트는 호스트의 볼륨 또는 해당 서브디렉터리에 + 마운트된 것을 마운트 이후에 수신하지 않는다. + 비슷한 방식으로, 컨테이너가 생성한 마운트는 호스트에서 볼 수 없다. + 이것이 기본 모드이다. - 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 - 설명된 `rshared` 마운트 전파와 같다. + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. - * `HostToContainer` - 이 볼륨 마운트는 볼륨 또는 해당 - 서브디렉터리를 마운트한 정보를 수신한다. +* `HostToContainer` - 이 볼륨 마운트는 볼륨 또는 해당 + 서브디렉터리를 마운트한 정보를 수신한다. - 다시 말하면, 만약 호스트가 볼륨 마운트 내부에 다른 것을 마운트 - 하더라도 컨테이너가 마운트 된 것을 볼 수 있다. + 다시 말하면, 만약 호스트가 볼륨 마운트 내부에 다른 것을 마운트 + 하더라도 컨테이너가 마운트된 것을 볼 수 있다. - 마찬가지로 `Bidirectional` 마운트 전파가 있는 파드가 동일한 마운트가 된 경우에 - 파드에 `HostToContainer` 마운트 전파가 있는 - 컨테이너가 이를 볼 수 있다. + 마찬가지로 `Bidirectional` 마운트 전파가 있는 파드가 동일한 마운트가 된 경우에 + 파드에 `HostToContainer` 마운트 전파가 있는 + 컨테이너가 이를 볼 수 있다. - 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 - 설명된 `rshared` 마운트 전파와 같다. + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. - * `Bidirectional` - 이 볼륨 마운트는 `HostToContainer` 마운트와 동일하게 작동한다. - 추가로 컨테이너에서 생성된 모든 볼륨 마운트는 동일한 볼륨을 - 사용하는 모든 파드의 모든 컨테이너와 호스트로 다시 전파된다. +* `Bidirectional` - 이 볼륨 마운트는 `HostToContainer` 마운트와 동일하게 작동한다. + 추가로 컨테이너에서 생성된 모든 볼륨 마운트는 동일한 볼륨을 + 사용하는 모든 파드의 모든 컨테이너와 호스트로 다시 전파된다. - 이 모드의 일반적인 유스 케이스로는 FlexVolume 또는 CSI 드라이버를 사용하는 파드 또는 - `hostPath` 볼륨을 사용하는 호스트에 무언가를 마운트해야 하는 파드이다. + 이 모드의 일반적인 유스 케이스로는 FlexVolume 또는 CSI 드라이버를 사용하는 파드 또는 + `hostPath` 볼륨을 사용하는 호스트에 무언가를 마운트해야 하는 파드이다. - 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 - 설명된 `rshared` 마운트 전파와 같다. + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. -{{< caution >}} +{{< warning >}} `Bidirectional` 마운트 전파는 위험할 수 있다. 이것은 -호스트 운영체제를 손상시킬수 있기에 권한이 있는 컨테이너에서만 +호스트 운영체제를 손상시킬 수 있기에 권한이 있는 컨테이너에서만 허용된다. 리눅스 커널 동작을 숙지하는 것을 권장한다. -또한 파드내 컨테이너에 의해 생성된 볼륨 마운트는 종료시 -컨테이너에의해 파괴(마운트 해제)되어야 한다. -{{< /caution >}} +또한 파드 내 컨테이너에 의해 생성된 볼륨 마운트는 종료 시 +컨테이너에 의해 파괴(마운트 해제)되어야 한다. +{{< /warning >}} ### 구성 + 일부 배포판(CoreOS, RedHat/Centos, Ubuntu)에서 마운트 전파가 제대로 작동하려면 아래와 같이 도커에서의 마운트 공유를 올바르게 구성해야 한다. -도커의 `systemd` 서비스 파일을 편집한다. `MountFlags` 를 다음과 같이 설정한다. +도커의 `systemd` 서비스 파일을 편집한다. `MountFlags` 를 다음과 같이 설정한다. + ```shell MountFlags=shared ``` + 또는 `MountFlags=slave` 가 있으면 제거한다. 이후 도커 데몬을 재시작 한다. + ```shell sudo systemctl daemon-reload sudo systemctl restart docker ``` - - ## {{% heading "whatsnext" %}} -* [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. +[퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md index a020124b6d..efd6fa1ff7 100644 --- a/content/ko/docs/concepts/workloads/_index.md +++ b/content/ko/docs/concepts/workloads/_index.md @@ -32,7 +32,7 @@ no_list: true 파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) * 완료될 때까지 실행되는 작업에 대한 [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및 - [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cronjob/) + [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/) 관련성을 찾을 수 있는 두 가지 지원 개념도 있다. * [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가 diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 5c0852dc12..c5a6832fd9 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -229,7 +229,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한 ### 파드 템플릿 -`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. +`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다. 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 00aed3c13d..e80c36aee4 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -77,13 +77,13 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되 `phase`에 가능한 값은 다음과 같다. -값 | 의미 -:-----|:----------- -`Pending` | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다. -`Running` | 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다. +값 | 의미 +:-----------|:----------- +`Pending` | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다. +`Running` | 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다. `Succeeded` | 파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않을 것이다. -`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. -`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다. +`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. +`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다. 노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는 손실된 노드의 모든 파드의 `phase` 를 Failed로 설정하는 정책을 적용한다. @@ -229,7 +229,8 @@ kubelet은 파드의 [조건](#파드의-조건)을 `ContainerReady` 로 설정 ## 컨테이너 프로브(probe) [프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는 -컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. +컨테이너에서 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해 +주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, kubelet은 컨테이너에 의해서 구현된 [핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index e45d00eef7..c8224ea76c 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -4,11 +4,21 @@ content_type: concept weight: 40 --- +{{< feature-state for_k8s_version="v1.19" state="stable" >}} + + 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. - +{{< note >}} +v1.19 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 +[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와 +[스케줄러](/docs/reference/generated/kube-scheduler/)에서 +`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화해야 한다 +{{< /note >}} diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md index a70374295f..30c0979969 100644 --- a/content/ko/docs/contribute/participate/pr-wranglers.md +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -6,7 +6,7 @@ weight: 20 -SIG Docs [승인자](/ko/docs/contribute/participating/roles-and-responsibilites/#승인자)는 리포지터리에 대해 일주일 동안 교대로 [풀 리퀘스트 관리](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수행한다. +SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 리포지터리에 대해 일주일 동안 교대로 [풀 리퀘스트 관리](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수행한다. 이 섹션은 PR 랭글러의 의무에 대해 다룬다. 좋은 리뷰 제공에 대한 자세한 내용은 [Reviewing changes](/ko/docs/contribute/review/)를 참고한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 86c67f4b06..8f2f5c48a6 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -16,8 +16,8 @@ content_type: concept ## API 레퍼런스 -* [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 -* [Kubernetes API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [쿠버네티스 API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요 ## API 클라이언트 라이브러리 @@ -34,7 +34,7 @@ content_type: concept * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. -* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. +* [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. ## 컴포넌트 레퍼런스 diff --git a/content/ko/docs/reference/access-authn-authz/_index.md b/content/ko/docs/reference/access-authn-authz/_index.md index c075922ad1..9e23c5d767 100644 --- a/content/ko/docs/reference/access-authn-authz/_index.md +++ b/content/ko/docs/reference/access-authn-authz/_index.md @@ -1,4 +1,26 @@ --- -title: API 접근하기 +title: API 접근 제어 weight: 20 ---- \ No newline at end of file +no_list: true +--- + +쿠버네티스가 API 접근을 구현 및 제어하는 방법에 대한 자세한 내용은 +[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고한다. + +참조 문헌 + +- [인증](/docs/reference/access-authn-authz/authentication/) + - [부트스트랩 토큰 인증](/docs/reference/access-authn-authz/bootstrap-tokens/) +- [승인 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/) + - [동적 승인 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [인가](/ko/docs/reference/access-authn-authz/authorization/) + - [역할 기반 접근 제어](/docs/reference/access-authn-authz/rbac/) + - [속성 기반 접근 제어](/docs/reference/access-authn-authz/abac/) + - [노드 인가](/docs/reference/access-authn-authz/node/) + - [웹훅 인가](/docs/reference/access-authn-authz/webhook/) +- [인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) + - [CSR 승인](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)과 + [인증서 서명](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)을 포함함 +- 서비스 어카운트 + - [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/) + - [관리](/ko/docs/reference/access-authn-authz/service-accounts-admin/) diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md index 3fe13d7ced..40d0a37c92 100644 --- a/content/ko/docs/reference/access-authn-authz/authorization.md +++ b/content/ko/docs/reference/access-authn-authz/authorization.md @@ -11,7 +11,7 @@ weight: 60 쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다. -인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)를 +인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)를 참고한다. 쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다. @@ -47,7 +47,7 @@ weight: 60 * **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다. * **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당). * **Namespace** - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당) - * **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 [핵심(core) API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 지정한다. + * **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 _핵심(core)_ [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 지정한다. ## 요청 동사 결정 @@ -197,5 +197,5 @@ status: ## {{% heading "whatsnext" %}} -* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다. +* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)에서 **인증** 을 참조한다. * 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)를 참조한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 11dc7f26b6..f5b7fa8dad 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -485,7 +485,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. -- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/configuration/pod-overhead/) 기능을 활성화한다. +- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다. - `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를 기반으로 파드의 스케줄링 취소와 선점을 활성화한다. - `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해 `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를 @@ -511,7 +511,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다. - `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다. - `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다. -- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다. +- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다. - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다. - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다. - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md new file mode 100644 index 0000000000..565c3b4faf --- /dev/null +++ b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md @@ -0,0 +1,343 @@ +--- +title: kube-proxy +content_type: tool-reference +weight: 30 +--- + +## {{% heading "synopsis" %}} + + +쿠버네티스 네트워크 프록시는 각 노드에서 실행된다. +이는 각 노드의 쿠버네티스 API에 정의된 서비스를 반영하며 단순한 +TCP, UDP 및 SCTP 스트림 포워딩 또는 라운드 로빈 TCP, UDP 및 SCTP 포워딩을 백엔드 셋에서 수행 할 수 있다. +서비스 클러스트 IP 및 포트는 현재 서비스 프록시에 의해 열린 포트를 지정하는 +Docker-links-compatible 환경 변수를 통해 찾을 수 있다. +이러한 클러스터 IP에 클러스터 DNS를 제공하는 선택적 애드온이 있다. 유저는 apiserver API로 +서비스를 생성하여 프록시를 구성해야 한다. + +``` +kube-proxy [flags] +``` + +## {{% heading "options" %}} + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--azure-container-registry-config string
Azure 컨테이너 레지스트리 구성 정보가 들어 있는 파일의 경로.
--bind-address ip     기본값: 0.0.0.0
프록시 서버가 서비스할 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0'으로 설정, 모든 IPv6 인터페이스의 경우 '::'로 설정)
--bind-address-hard-fail
true인 경우 kube-proxy는 포트 바인딩 실패를 치명적인 것으로 간주하고 종료한다.
--cleanup
true인 경우 iptables 및 ipvs 규칙을 제거하고 종료한다.
--cluster-cidr string
클러스터에 있는 파드의 CIDR 범위. 구성 후에는 이 범위 밖에서 서비스 클러스터 IP로 전송되는 트래픽은 마스커레이드되고 파드에서 외부 LoadBalancer IP로 전송된 트래픽은 대신 해당 클러스터 IP로 전송된다
--config string
설정 파일의 경로.
--config-sync-period duration     기본값: 15m0s
apiserver의 설정이 갱신되는 빈도. 0보다 커야 한다.
--conntrack-max-per-core int32     기본값: 32768
CPU 코어당 추적할 최대 NAT 연결 수(한도(limit)를 그대로 두고 contrack-min을 무시하려면 0으로 설정한다)(
--conntrack-min int32     기본값: 131072
conntrack-max-per-core와 관계없이 할당할 최소 conntrack 항목 수(한도를 그대로 두려면 conntrack-max-per-core값을 0으로 설정).
--conntrack-tcp-timeout-close-wait duration     기본값: 1h0m0s
CLOSE_WAIT 상태의 TCP 연결에 대한 NAT 시간 초과
--conntrack-tcp-timeout-established duration     기본값: 24h0m0s
설정된 TCP 연결에 대한 유휴시간 초과(값이 0이면 그대로 유지)
--detect-local-mode LocalMode
로컬 트래픽을 탐지하는 데 사용할 모드
--feature-gates mapStringBool
알파/실험 기능에 대한 기능 게이트를 설명하는 키=값 쌍 집합. 옵션은 다음과 같다.
APIListChunking=true|false (BETA - 기본값=true)
APIPriorityAndFairness=true|false (ALPHA - 기본값=false)
APIResponseCompression=true|false (BETA - 기본값=true)
AllAlpha=true|false (ALPHA - 기본값=false)
AllBeta=true|false (BETA - 기본값=false)
AllowInsecureBackendProxy=true|false (BETA - 기본값=true)
AnyVolumeDataSource=true|false (ALPHA - 기본값=false)
AppArmor=true|false (BETA - 기본값=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 기본값=false)
BoundServiceAccountTokenVolume=true|false (ALPHA - 기본값=false)
CPUManager=true|false (BETA - 기본값=true)
CRIContainerLogRotation=true|false (BETA - 기본값=true)
CSIInlineVolume=true|false (BETA - 기본값=true)
CSIMigration=true|false (BETA - 기본값=true)
CSIMigrationAWS=true|false (BETA - 기본값=false)
CSIMigrationAWSComplete=true|false (ALPHA - 기본값=false)
CSIMigrationAzureDisk=true|false (BETA - 기본값=false)
CSIMigrationAzureDiskComplete=true|false (ALPHA - 기본값=false)
CSIMigrationAzureFile=true|false (ALPHA - 기본값=false)
CSIMigrationAzureFileComplete=true|false (ALPHA - 기본값=false)
CSIMigrationGCE=true|false (BETA - 기본값=false)
CSIMigrationGCEComplete=true|false (ALPHA - 기본값=false)
CSIMigrationOpenStack=true|false (BETA - 기본값=false)
CSIMigrationOpenStackComplete=true|false (ALPHA - 기본값=false)
CSIMigrationvSphere=true|false (BETA - 기본값=false)
CSIMigrationvSphereComplete=true|false (BETA - 기본값=false)
CSIStorageCapacity=true|false (ALPHA - 기본값=false)
CSIVolumeFSGroupPolicy=true|false (ALPHA - 기본값=false)
ConfigurableFSGroupPolicy=true|false (ALPHA - 기본값=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 기본값=false)
DefaultPodTopologySpread=true|false (ALPHA - 기본값=false)
DevicePlugins=true|false (BETA - 기본값=true)
DisableAcceleratorUsageMetrics=true|false (ALPHA - 기본값=false)
DynamicKubeletConfig=true|false (BETA - 기본값=true)
EndpointSlice=true|false (BETA - 기본값=true)
EndpointSliceProxying=true|false (BETA - 기본값=true)
EphemeralContainers=true|false (ALPHA - 기본값=false)
ExpandCSIVolumes=true|false (BETA - 기본값=true)
ExpandInUsePersistentVolumes=true|false (BETA - 기본값=true)
ExpandPersistentVolumes=true|false (BETA - 기본값=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 기본값=false)
GenericEphemeralVolume=true|false (ALPHA - 기본값=false)
HPAScaleToZero=true|false (ALPHA - 기본값=false)
HugePageStorageMediumSize=true|false (BETA - 기본값=true)
HyperVContainer=true|false (ALPHA - 기본값=false)
IPv6DualStack=true|false (ALPHA - 기본값=false)
ImmutableEphemeralVolumes=true|false (BETA - 기본값=true)
KubeletPodResources=true|false (BETA - 기본값=true)
LegacyNodeRoleBehavior=true|false (BETA - 기본값=true)
LocalStorageCapacityIsolation=true|false (BETA - 기본값=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 기본값=false)
NodeDisruptionExclusion=true|false (BETA - 기본값=true)
NonPreemptingPriority=true|false (BETA - 기본값=true)
PodDisruptionBudget=true|false (BETA - 기본값=true)
PodOverhead=true|false (BETA - 기본값=true)
ProcMountType=true|false (ALPHA - 기본값=false)
QOSReserved=true|false (ALPHA - 기본값=false)
RemainingItemCount=true|false (BETA - 기본값=true)
RemoveSelfLink=true|false (ALPHA - 기본값=false)
RotateKubeletServerCertificate=true|false (BETA - 기본값=true)
RunAsGroup=true|false (BETA - 기본값=true)
RuntimeClass=true|false (BETA - 기본값=true)
SCTPSupport=true|false (BETA - 기본값=true)
SelectorIndex=true|false (BETA - 기본값=true)
ServerSideApply=true|false (BETA - 기본값=true)
ServiceAccountIssuerDiscovery=true|false (ALPHA - 기본값=false)
ServiceAppProtocol=true|false (BETA - 기본값=true)
ServiceNodeExclusion=true|false (BETA - 기본값=true)
ServiceTopology=true|false (ALPHA - 기본값=false)
SetHostnameAsFQDN=true|false (ALPHA - 기본값=false)
StartupProbe=true|false (BETA - 기본값=true)
StorageVersionHash=true|false (BETA - 기본값=true)
SupportNodePidsLimit=true|false (BETA - 기본값=true)
SupportPodPidsLimit=true|false (BETA - 기본값=true)
Sysctls=true|false (BETA - 기본값=true)
TTLAfterFinished=true|false (ALPHA - 기본값=false)
TokenRequest=true|false (BETA - 기본값=true)
TokenRequestProjection=true|false (BETA - 기본값=true)
TopologyManager=true|false (BETA - 기본값=true)
ValidateProxyRedirects=true|false (BETA - 기본값=true)
VolumeSnapshotDataSource=true|false (BETA - 기본값=true)
WarningHeaders=true|false (BETA - 기본값=true)
WinDSR=true|false (ALPHA - 기본값=false)
WinOverlay=true|false (ALPHA - 기본값=false)
WindowsEndpointSliceProxying=true|false (ALPHA - 기본값=false)
--healthz-bind-address ipport     기본값: 0.0.0.0:10256
헬스 체크 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4의 인터페이스의 경우 '0.0.0.0:10256', 모든 IPv6의 인터페이스인 경우 '[::]:10256'로 설정). 사용 안 할 경우 빈칸으로 둠.
-h, --help
kube-proxy에 대한 도움말.
--hostname-override string
문자열 값이 있으면, 이 값을 실제 호스트네임 대신에 ID로 사용한다.
--iptables-masquerade-bit int32     기본값: 14
순수 iptable 프록시를 사용하는 경우 SNAT가 필요한 패킷을 표시하는 fwmark 스페이스 비트. [0, 31] 범위 안에 있어야 한다.
--iptables-min-sync-period duration     기본값: 1s
엔드포인트 및 서비스가 변경될 때 iptable 규칙을 새로 고칠 수 있는 빈도의 최소 간격(예: '5s', '1m', '2h22m').
--iptables-sync-period duration     기본값: 30s
iptable 규칙을 새로 고치는 빈도의 최대 간격(예: '5s', '1m', '2h22m'). 0 보다 커야 한다.
--ipvs-exclude-cidrs stringSlice
IPVS 규칙을 정리할 때 ipvs 프록시가 건드리지 않아야 하는 쉼표로 구분된 CIDR 목록.
--ipvs-min-sync-period duration
엔드포인트 및 서비스가 변경될 때 ipvs 규칙을 새로 고칠 수 있는 빈도의 최소 간격(예: '5s', '1m', '2h22m').
--ipvs-scheduler string
프록시 모드가 ipvs인 경우 ipvs 스케줄러 유형.
--ipvs-strict-arp
arp_ignore를 1로 설정하고 arp_annotes를 2로 설정하여 엄격한 ARP를 사용.
--ipvs-sync-period duration     기본값: 30s
ipvs 규칙이 새로 갱신되는 빈도의 최대 간격(예: '5s', '1m', '2h22m'). 0 보다 커야 한다.
--ipvs-tcp-timeout duration
유휴 IPVS TCP 연결에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').
--ipvs-tcpfin-timeout duration
FIN 패킷을 수신한 후 IPVS TCP 연결에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').
--ipvs-udp-timeout duration
IPVS UDP 패킷에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').
--kube-api-burst int32     기본값: 10
쿠버네티스 api 서버와 통신하는 동안 사용할 burst.
--kube-api-content-type string     기본값: "application/vnd.kubernetes.protobuf"
api 서버에 보낸 요청의 내용 유형.
--kube-api-qps float32     기본값: 5
쿠버네티스 api 서버와 통신할 때 사용할 QPS.
--kubeconfig string
인증 정보가 있는 kubeconfig 파일의 경로(마스터 위치는 마스터 플래그로 설정됨).
--log-flush-frequency duration     기본값: 5s
로그 플러시 사이의 최대 시간
--masquerade-all
순수 iptables 프록시를 사용하는 경우 서비스 클러스터 IP를 통해 전송된 모든 트래픽을 SNAT함(일반적으로 필요하지 않음).
--master string
쿠버네티스 API 서버의 주소(kubeconfig의 모든 값 덮어쓰기).
--metrics-bind-address ipport     기본값: 127.0.0.1:10249
메트릭 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0:10249', 모든 IPv6 인터페이스의 경우 '[::]:10249'로 설정됨). 사용하지 않으려면 비워둘 것.
--nodeport-addresses stringSlice
NodePort에 사용할 주소를 지정하는 값의 문자열 조각. 값은 유효한 IP 블록(예: 1.2.3.0/24, 1.2.3.4/32). 기본값인 빈 문자열 조각값은([]) 모든 로컬 주소를 사용하는 것을 의미한다.
--oom-score-adj int32     기본값: -999
kube-proxy 프로세스에 대한 oom-score-adj 값. 값은 [-1000, 1000] 범위 내에 있어야 한다.
--profiling
값이 true이면 /debug/pprof 핸들러에서 웹 인터페이스를 통한 프로파일링을 활성화한다.
--proxy-mode ProxyMode
사용할 프록시 모드: 'userspace' (이전) or 'iptables' (빠름) or 'ipvs' or 'kernelspace' (윈도우). 공백인 경우 가장 잘 사용할 수 있는 프록시(현재는 iptables)를 사용한다. iptables 프록시를 선택했지만, 시스템의 커널 또는 iptables 버전이 맞지 않으면, 항상 userspace 프록시로 변경된다.
--proxy-port-range port-range
서비스 트래픽을 프록시하기 위해 사용할 수 있는 호스트 포트 범위(beginPort-endPort, single port 또는 beginPort+offset 포함). 만약 범위가 0, 0-0, 혹은 지정되지 않으면, 포트는 무작위로 선택된다.
--show-hidden-metrics-for-version string
숨겨진 메트릭을 표시할 이전 버전.
--udp-timeout duration     기본값: 250ms
유휴 UDP 연결이 열린 상태로 유지되는 시간(예: '250ms', '2s'). 값은 0보다 커야 한다. 프록시 모드 userspace에만 적용 가능함.
--version version[=true]
버전 정보를 인쇄하고 종료.
--write-config-to string
기본 구성 값을 이 파일에 옮겨쓰고 종료한다.
+ + + diff --git a/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md index 61f0b35d1f..6f9060dba4 100644 --- a/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md +++ b/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md @@ -5,7 +5,7 @@ title: Kubelet 인증/인가 ## 개요 -kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 노출시키며, +kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 제공하는 API를 노출하며, 노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다. 이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다. diff --git a/content/ko/docs/reference/glossary/container-lifecycle-hooks.md b/content/ko/docs/reference/glossary/container-lifecycle-hooks.md new file mode 100644 index 0000000000..7b1ebd27a4 --- /dev/null +++ b/content/ko/docs/reference/glossary/container-lifecycle-hooks.md @@ -0,0 +1,17 @@ +--- +title: 컨테이너 라이프사이클 훅(Container Lifecycle Hooks) +id: container-lifecycle-hooks +date: 2018-10-08 +full_link: /ko/docs/concepts/containers/container-lifecycle-hooks/ +short_description: > + 라이프사이클 훅은 컨테이너 관리 라이프사이클에 이벤트를 노출하고 이벤트가 발생할 때 사용자가 코드를 실행할 수 있도록 한다. + +aka: +tags: +- extension +--- + 라이프사이클 훅은 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 관리 라이프사이클에 이벤트를 노출하고 이벤트가 발생할 때 사용자가 코드를 실행할 수 있도록 한다. + + + +컨테이너에는 두 개의 훅(컨테이너가 생성된 직후에 실행되는 PostStart와 컨테이너가 종료되기 직전에 차단되고 호출되는 PreStop)이 노출된다. diff --git a/content/ko/docs/reference/glossary/container.md b/content/ko/docs/reference/glossary/container.md index 2420a42112..9d01041f9e 100755 --- a/content/ko/docs/reference/glossary/container.md +++ b/content/ko/docs/reference/glossary/container.md @@ -2,7 +2,7 @@ title: 컨테이너(Container) id: container date: 2018-04-12 -full_link: /ko/docs/concepts/overview/what-is-kubernetes/#왜-컨테이너인가 +full_link: /ko/docs/concepts/containers/ short_description: > 소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지. diff --git a/content/ko/docs/reference/kubectl/jsonpath.md b/content/ko/docs/reference/kubectl/jsonpath.md new file mode 100644 index 0000000000..4a910829f8 --- /dev/null +++ b/content/ko/docs/reference/kubectl/jsonpath.md @@ -0,0 +1,113 @@ +--- +title: JSONPath 지원 +content_type: concept +weight: 25 +--- + + +Kubectl은 JSONPath 템플릿을 지원한다. + + + + +JSONPath 템플릿은 중괄호 {}로 둘러싸인 JSONPath 표현식으로 구성된다. +Kubectl은 JSONPath 표현식을 사용하여 JSON 오브젝트의 특정 필드를 필터링하고 출력 형식을 지정한다. +원본 JSONPath 템플릿 구문 외에도 다음과 같은 기능과 구문이 유효하다. + +1. 큰따옴표를 사용하여 JSONPath 표현식 내부의 텍스트를 인용한다. +2. 목록을 반복하려면 `range`, `end` 오퍼레이터를 사용한다. +3. 목록에서 뒤로 이동하려면 negative slice 인덱스를 사용한다. negative 인덱스는 목록을 "순환(wrap around)" 하지 않으며, `-index + listLength >= 0` 인 한 유효하다. + +{{< note >}} + +- 표현식은 항상 루트 오브젝트에서 시작하므로 `$` 오퍼레이터는 선택 사항이다. + +- 결과 오브젝트는 String() 함수로 출력된다. + +{{< /note >}} + +JSON 입력 시 다음과 같다. + +```json +{ + "kind": "List", + "items":[ + { + "kind":"None", + "metadata":{"name":"127.0.0.1"}, + "status":{ + "capacity":{"cpu":"4"}, + "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}] + } + }, + { + "kind":"None", + "metadata":{"name":"127.0.0.2"}, + "status":{ + "capacity":{"cpu":"8"}, + "addresses":[ + {"type": "LegacyHostIP", "address":"127.0.0.2"}, + {"type": "another", "address":"127.0.0.3"} + ] + } + } + ], + "users":[ + { + "name": "myself", + "user": {} + }, + { + "name": "e2e", + "user": {"username": "admin", "password": "secret"} + } + ] +} +``` + +Function | Description | Example | Result +--------------------|---------------------------|-----------------------------------------------------------------|------------------ +`text` | 일반 텍스트 | `kind is {.kind}` | `kind is List` +`@` | 현재 오브젝트 | `{@}` | 입력과 동일 +`.` or `[]` | 자식 오퍼레이터 | `{.kind}`, `{['kind']}` or `{['name\.type']}` | `List` +`..` | 재귀 하향(recursive descent)| `{..name}` | `127.0.0.1 127.0.0.2 myself e2e` +`*` | 와일드 카드. 모든 오브젝트 가져오기 | `{.items[*].metadata.name}` | `[127.0.0.1 127.0.0.2]` +`[start:end:step]` | 아래 첨자 오퍼레이터 | `{.users[0].name}` | `myself` +`[,]` | 조합 오퍼레이터 | `{.items[*]['metadata.name', 'status.capacity']}` | `127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]` +`?()` | 필터 | `{.users[?(@.name=="e2e")].user.password}` | `secret` +`range`, `end` | 반복 목록 | `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}` | `[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]` +`''` | 해석된 문자열 인용 | `{range .items[*]}{.metadata.name}{'\t'}{end}` | `127.0.0.1 127.0.0.2` + +`kubectl` 및 JSONPath 표현식을 사용하는 예는 다음과 같다. + +```shell +kubectl get pods -o json +kubectl get pods -o=jsonpath='{@}' +kubectl get pods -o=jsonpath='{.items[0]}' +kubectl get pods -o=jsonpath='{.items[0].metadata.name}' +kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}" +kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}' +``` + +{{< note >}} +윈도우에서 공백이 포함된 JSONPath 템플릿을 큰따옴표(위의 bash에 표시된 작은따옴표가 아님)로 묶어야 한다. 즉, 템플릿의 모든 문자 주변에 작은따옴표 또는 이스케이프된 큰따옴표를 사용해야 한다. 예를 들면, 다음과 같다. + +```cmd +kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}" +kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}" +``` +{{< /note >}} + +{{< note >}} + +JSONPath 정규식은 지원되지 않는다. 정규 표현식을 이용해 매치하려면 `jq`와 같은 도구를 사용하면 된다. + +```shell +# kubectl은 JSONPath 출력에 대한 정규 표현식을 지원하지 않는다. +# 다음 커맨드는 작동하지 않는다. +kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}' + +# 다음 커맨드는 원하는 결과를 얻는다. +kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image' +``` +{{< /note >}} diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md new file mode 100644 index 0000000000..0f3f120d77 --- /dev/null +++ b/content/ko/docs/reference/scheduling/config.md @@ -0,0 +1,253 @@ +--- +title: 스케줄러 구성 +content_type: concept +weight: 20 +--- + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +구성 파일을 작성하고 해당 경로를 커맨드 라인 인수로 전달하여 +`kube-scheduler` 의 동작을 사용자 정의할 수 있다. + + + + + +스케줄링 프로파일(Profile)을 사용하면 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}에서 +여러 단계의 스케줄링을 구성할 수 있다. +각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 +익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. + +컴포넌트 구성 API([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration) +또는 [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration))를 +사용하고, `kube-scheduler --config `을 실행하여 +스케줄링 프로파일을 지정할 수 있다. +`v1alpha2` API를 사용하면 [여러 프로파일](#여러-프로파일)을 +실행하도록 kube-scheduler를 구성할 수 있다. + +최소 구성은 다음과 같다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +clientConnection: + kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig +``` + +## 프로파일 + +스케줄링 프로파일을 사용하면 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}에서 +여러 단계의 스케줄링을 구성할 수 있다. +각 단계는 [익스텐션 포인트](#익스텐션-포인트)에 노출된다. +[플러그인](#스케줄링-플러그인)은 이러한 익스텐션 포인트 중 +하나 이상을 구현하여 스케줄링 동작을 제공한다. + +`kube-scheduler` 의 단일 인스턴스를 구성하여 +[여러 프로파일](#여러-프로파일)을 실행할 수 있다. + +### 익스텐션 포인트 + +스케줄링은 다음 익스텐션 포인트를 통해 노출되는 일련의 단계에서 +발생한다. + +1. `QueueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를 + 정렬하는 데 사용되는 정렬 기능을 제공한다. 대기열 정렬 플러그인은 한 번에 단 하나만 활성화될 수 있다. + 사용할 수 있다. +1. `PreFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를 + 사전 처리하거나 확인하는 데 사용된다. 이 플러그인은 파드를 unschedulable로 + 표시할 수 있다. +1. `Filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며 + 파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 필터는 + 구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로 + 표시된다. +1. `PreScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는 + 정보성 익스텐션 포인트이다. +1. `Score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를 + 제공한다. 그런 다음 스케줄러는 가중치 합계가 가장 높은 + 노드를 선택한다. +1. `Reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에 + 알리는 정보성 익스텐션 포인트이다. 플러그인은 또한 + `Reserve` 도중 또는 이후에 실패한 경우 호출 되는 `Unreserve` 호출을 + 구현한다. +1. `Permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다. +1. `PreBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다. +1. `Bind`: 플러그인은 파드를 노드에 바인딩한다. Bind 플러그인은 순서대로 호출되며 + 일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. Bind + 플러그인은 적어도 하나 이상 필요하다. +1. `PostBind`: 파드가 바인드된 후 호출되는 + 정보성 익스텐션 포인트이다. + +각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나 +자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +profiles: + - plugins: + score: + disabled: + - name: NodeResourcesLeastAllocated + enabled: + - name: MyCustomPluginA + weight: 2 + - name: MyCustomPluginB + weight: 1 +``` + +비활성화된 배열의 이름으로 `*` 를 사용하여 해당 익스텐션 포인트에 대한 +모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데 +사용할 수도 있다. + +### 스케줄링 플러그인 + +1. `UnReserve`: 파드가 예약된 후 거부되고 `Permit` 플러그인에 의해 보류된 경우 + 호출되는 정보성 익스텐션 포인트이다. + +## 스케줄링 플러그인 + +기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중 +하나 이상을 구현한다. + +- `SelectorSpread`: {{< glossary_tooltip text="서비스" term_id="service" >}}, + {{< glossary_tooltip text="레플리카셋(ReplicaSets)" term_id="replica-set" >}} 및 + {{< glossary_tooltip text="스테이트풀셋(StatefulSets)" term_id="statefulset" >}}에 + 속하는 파드에 대해 노드 간 분산을 선호한다. + 익스텐션 포인트: `PreScore`, `Score`. +- `ImageLocality`: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를 + 선호한다. + 익스텐션 포인트: `Score`. +- `TaintToleration`: [테인트(taint)와 톨러레이션(toleration)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 + 구현한다. + 익스텐션 포인트 구현: `Filter`, `Prescore`, `Score`. +- `NodeName`: 파드 명세 노드 이름이 현재 노드와 일치하는지 확인한다. + 익스텐션 포인트: `Filter`. +- `NodePorts`: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다. + 익스텐션 포인트: `PreFilter`, `Filter`. +- `NodePreferAvoidPods`: 노드 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}} + `scheduler.alpha.kubernetes.io/preferAvoidPods` 에 따라 + 노드 점수를 매긴다. + 익스텐션 포인트: `Score`. +- `NodeAffinity`: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 + [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를 + 구현한다. + 익스텐션 포인트: `Filter`, `Score`. +- `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를 + 구현한다. + 익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`. +- `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를 + 필터링한다. + 익스텐션 포인트: `Filter`. +- `NodeResourcesFit`: 노드에 파드가 요청하는 모든 리소스가 있는지 + 확인한다. + 익스텐션 포인트: `PreFilter`, `Filter`. +- `NodeResourcesBalancedAllocation`: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을 + 얻을 수 있는 노드를 선호한다. + 익스텐션 포인트: `Score`. +- `NodeResourcesLeastAllocated`: 리소스 할당이 적은 노드를 + 선호한다. + 익스텐션 포인트: `Score`. +- `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지 + 또는 바인딩할 수 있는지 확인한다. + 익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`. +- `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한 + 제한 사항을 충족하는지 확인한다. + 익스텐션 포인트: `Filter`. +- `VolumeZone`: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지 + 확인한다. + 익스텐션 포인트: `Filter`. +- `NodeVolumeLimits`: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지 + 확인한다. + 익스텐션 포인트: `Filter`. +- `EBSLimits`: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인한다. + 익스텐션 포인트: `Filter`. +- `GCEPDLimits`: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인한다. + 익스텐션 포인트: `Filter`. +- `AzureDiskLimits`: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지 + 확인한다. + 익스텐션 포인트: `Filter`. +- `InterPodAffinity`: [파드 간 어피니티 및 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 + 구현한다. + 익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`. +- `PrioritySort`: 기본 우선 순위 기반 정렬을 제공한다. + 익스텐션 포인트: `QueueSort`. +- `DefaultBinder`: 기본 바인딩 메커니즘을 제공한다. + 익스텐션 포인트: `Bind`. +- `DefaultPreemption`: 기본 선점 메커니즘을 제공한다. + 익스텐션 포인트: `PostFilter`. + +기본으로 활성화되지 않는 다음의 플러그인을 +컴포넌트 구성 API를 통해 활성화할 수도 있다. + +- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를 + 선호한다. + 익스텐션 포인트: `Score`. +- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를 + 선호한다. + 익스텐션 포인트: `Score`. +- `NodeResourceLimits`: 파드 리소스 제한을 충족하는 노드를 선호한다. + 익스텐션 포인트: `PreScore`, `Score`. +- `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지 + 확인한다. + 익스텐션 포인트: `Filter`. +- `NodeLabel`: Filters and / or scores a node according to configured + {{< glossary_tooltip text="label(s)" term_id="label" >}}. + 익스텐션 포인트: `Filter`, `Score`. +- `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에 + 속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지 + 확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에 + 분산하는 것을 선호한다. + 익스텐션 포인트: `PreFilter`, `Filter`, `Score`. + +### 여러 프로파일 + +둘 이상의 프로파일을 실행하도록 `kube-scheduler` 를 구성할 수 있다. +각 프로파일에는 연관된 스케줄러 이름이 있으며 [익스텐션 포인트](#익스텐션-포인트)에 구성된 +다른 플러그인 세트를 가질 수 있다. + +다음의 샘플 구성을 사용하면, 스케줄러는 기본 플러그인이 있는 +프로파일과 모든 스코어링 플러그인이 비활성화된 프로파일의 두 가지 프로파일로 +실행된다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: default-scheduler + - schedulerName: no-scoring-scheduler + plugins: + preScore: + disabled: + - name: '*' + score: + disabled: + - name: '*' +``` + +특정 프로파일에 따라 스케줄하려는 파드는 +`.spec.schedulerName` 에 해당 스케줄러 이름을 포함할 수 있다. + +기본적으로, 스케줄러 이름 `default-scheduler` 를 가진 하나의 프로파일이 생성된다. +이 프로파일에는 위에서 설명한 기본 플러그인이 포함되어 있다. 둘 이상의 +프로파일을 선언할 때, 각각에 대한 고유한 스케줄러 이름이 필요하다. + +파드가 스케줄러 이름을 지정하지 않으면, kube-apiserver는 이를 `default-scheduler` 로 +설정한다. 따라서, 해당 파드를 스케줄하려면 이 스케줄러 이름을 가진 프로파일이 +있어야 한다. + +{{< note >}} +파드의 스케줄링 이벤트에는 ReportingController로 `.spec.schedulerName` 이 있다. +리더 선출을 위한 이벤트는 목록에서 첫 번째 프로파일의 스케줄러 이름을 +사용한다. +{{< /note >}} + +{{< note >}} +모든 프로파일은 QueueSort 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며 +동일한 구성 파라미터(해당하는 경우)를 가져야 한다. 그 이유는 스케줄러가 보류 중 상태인 파드 대기열을 +단 하나만 가질 수 있기 때문이다. +{{< /note >}} + +## {{% heading "whatsnext" %}} + +* [kube-scheduler 레퍼런스](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 +* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 diff --git a/content/ko/docs/reference/tools.md b/content/ko/docs/reference/tools.md index ceac0a5101..ac0a5fb6c5 100644 --- a/content/ko/docs/reference/tools.md +++ b/content/ko/docs/reference/tools.md @@ -20,7 +20,7 @@ content_type: concept ## Minikube -[`minikube`](/ko/docs/tasks/tools/install-minikube/)는 개발과 테스팅 목적으로 하는 +[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로 하는 단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서 쉽게 구동시키는 도구이다. @@ -44,7 +44,7 @@ Helm의 용도 ## Kompose -[`Kompose`](https://github.com/kubernetes-incubator/kompose)는 도커 컴포즈 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다. +[`Kompose`](https://github.com/kubernetes/kompose)는 도커 컴포즈 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다. Kompose의 용도 diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md index 7751aef2f4..427cebf529 100644 --- a/content/ko/docs/reference/using-api/_index.md +++ b/content/ko/docs/reference/using-api/_index.md @@ -1,4 +1,121 @@ --- -title: 쿠버네티스 API 사용하기 +title: 쿠버네티스 API 개요 +content_type: concept weight: 10 +card: + name: 레퍼런스 + weight: 50 + title: API 개요 --- + + + +이 섹션은 쿠버네티스 API에 대한 참조 정보를 제공한다. + +REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, +컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 +REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은 +API 오브젝트로 취급되고, +[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다. + +[쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)는 +쿠버네티스 버전 {{< param "version" >}}에 대한 API가 나열되어 있다. + +일반적인 배경 정보를 보려면, +[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 참고한다. +[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)는 +클라이언트가 쿠버네티스 API 서버에 인증하는 방법과 +요청이 승인되는 방법을 설명한다. + + +## API 버전 규칙 + +JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 +동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다. + +API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. +[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 +API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. + +API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. +[API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 +각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다. + +아래는 각 수준의 기준에 대한 요약이다. + +- 알파(Alpha): + - 버전 이름에 `alpha`가 포함된다(예: `v1alpha1`). + - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다. + 기본적으로 비활성화되어 있다. + - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. + - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다. + - 버그에 대한 위험이 높고 장기간 지원되지 않으므로 + 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다. + +- 베타(Beta): + - 버전 이름에 `beta`가 포함된다(예: `v2beta3`). + - 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다. + 기본적으로 활성화되어 있다. + - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다. + + - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 + 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 + 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 + 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. + 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다. + - 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 + 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 + 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다. + + {{< note >}} + 베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는 + 실질적으로 더 많은 변경이 어렵다. + {{< /note >}} + +- 안정화(Stable): + - 버전 이름이 `vX`이고 `X` 는 정수다. + - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다. + +## API 그룹 + +[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 +쿠버네티스 API를 더 쉽게 확장하게 해준다. +API 그룹은 REST 경로와 직렬화된 오브젝트의 `apiVersion` 필드에 +명시된다. + +쿠버네티스에는 다음과 같은 다양한 API 그룹이 있다. + +* *핵심* (또는 *레거시* 라고 불리는) 그룹은 REST 경로 `/api/v1`에 있다. + 핵심 그룹은 `apiVersion` 필드의 일부로 명시되지 않는다. 예를 + 들어, `apiVersion: v1` 과 같다. +* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 + `apiVersion: $GROUP_NAME/$VERSION`을 사용한다(예를 들어, `apiVersion: batch/v1`). + 지원되는 API 그룹 전체의 목록은 + [쿠버네티스 API 참조 문서](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#-strong-api-groups-strong-)에서 확인할 수 있다. + +## API 그룹 활성화 또는 비활성화 + +특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서 +`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다. +`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는 +쉼표로 구분된 `=` 쌍을 허용한다. 만약 `=` +부분을 생략하면, `=true` 가 명시된 것처럼 취급한다. 예를 들면, 다음과 같다. + + - `batch/v1` 을 비활성화하려면, `--runtime-config=batch/v1=false` 로 설정 + - `batch/v2alpha1` 을 활성화하려면, `--runtime-config=batch/v2alpha1` 으로 설정 + +{{< note >}} +그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여 +`--runtime-config` 변경을 반영해야 한다. +{{< /note >}} + +## 지속성 + +쿠버네티스는 {{< glossary_tooltip term_id="etcd" >}}에 기록하여 API 리소스 측면에서 +직렬화된 상태를 저장한다. + +## {{% heading "whatsnext" %}} + +- [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기 +- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에 + 대한 디자인 문서 읽기 diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md deleted file mode 100644 index 4bf982fc1b..0000000000 --- a/content/ko/docs/reference/using-api/api-overview.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: 쿠버네티스 API 개요 -content_type: concept -weight: 10 -card: - name: 레퍼런스 - weight: 50 - title: API 개요 ---- - - - -이 페이지는 쿠버네티스 API에 대한 개요를 제공한다. - - - - -REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, -컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 -REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은 -API 오브젝트로 취급되고, -[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다. - -## API 버전 규칙 - -JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 -동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다. - -API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. -[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 -API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. - -API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. -[API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 -각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다. - -아래는 각 수준의 기준에 대한 요약이다. - -- 알파(Alpha) 수준: - - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`) - - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. - 기본적으로 비활성화되어 있다. - - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. - - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다. - - 버그의 위험이 높고 장기간 지원되지 않으므로 - 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다. - -- 베타(Beta) 수준: - - 버전 이름에 `beta`가 포함된다. (예: `v2beta3`). - - 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. - 기본적으로 활성화되어 있다. - - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다. - - - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 - 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 - 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 - 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. - 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다. - - 이 소프트웨어는 프로덕션 용도로 권장되지 않는다. 이후 여러 버전에서 - 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 - 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다. - - {{< note >}} - 베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는 - 실질적으로 더 많은 변경이 어렵다. - {{< /note >}} - -- 안정화(stable) 수준: - - 버전 이름이 `vX`이고 `X` 는 정수다. - - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다. - -## API 그룹 - -[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 -쿠버네티스 API를 더 쉽게 확장하게 해준다. -API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 -명시된다. - -현재 다음과 같은 다양한 API 그룹이 사용되고 있다. - -* *핵심* (또는 *레거시* 라고 불리는) 그룹은 REST 경로 `/api/v1`에 있다. - 핵심 그룹은 `apiVersion` 필드의 일부로 명시되지 않는다. 예를 - 들어, `apiVersion: v1` 와 같다. -* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 - `apiVersion: $GROUP_NAME/$VERSION`을 사용한다(예를 들어, `apiVersion: batch/v1`). - 지원되는 API 그룹 전체의 목록은 - [쿠버네티스 API 참조 문서](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에서 확인할 수 있다. - -## API 그룹 활성화 또는 비활성화 {#enabling-or-disabling} - -특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서 -`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다. -`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는 -쉼표로 구분된 `=` 쌍을 허용한다. 예를 들면, 다음과 같다. - - - `batch/v1` 을 비활성화하려면, `--runtime-config=batch/v1=false` 로 설정 - - `batch/v2alpha1` 을 활성화하려면, `--runtime-config=batch/v2alpha1` 으로 설정 - -{{< note >}} -그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여 -`--runtime-config` 변경을 반영해야 한다. -{{< /note >}} - -## 지속성 - -쿠버네티스는 {{< glossary_tooltip term_id="etcd" >}}에 기록하여 API 리소스 측면에서 -직렬화된 상태를 저장한다. - -## {{% heading "whatsnext" %}} - -- [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기 -- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에 - 대한 디자인 문서 읽기 diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 9a6e07293f..9391072163 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -10,7 +10,7 @@ weight: 30 -[쿠버네티스 REST API](/ko/docs/reference/using-api/api-overview/)를 사용해 애플리케이션을 작성하기 위해 +[쿠버네티스 REST API](/ko/docs/reference/using-api/)를 사용해 애플리케이션을 작성하기 위해 API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. 사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다. diff --git a/content/ko/docs/setup/learning-environment/_index.md b/content/ko/docs/setup/learning-environment/_index.md index cd7005bf79..1c035d5bae 100644 --- a/content/ko/docs/setup/learning-environment/_index.md +++ b/content/ko/docs/setup/learning-environment/_index.md @@ -2,3 +2,32 @@ title: 학습 환경 weight: 20 --- + + + +## kind + +[`kind`](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서 +쿠버네티스를 사용할 수 있다. 이 툴을 사용하려면 +[도커](https://docs.docker.com/get-docker/)를 설치 및 구성해야 한다. + +kind [빠른 시작](https://kind.sigs.k8s.io/docs/user/quick-start/) 페이지에는 +kind를 시작하고 실행하기 위해 해야 할 일이 나와 있다. + +## minikube + +`kind`와 마찬가지로, [`minikube`](https://minikube.sigs.k8s.io/)는 로컬에서 쿠버네티스를 실행할 수 있는 툴이다. +`minikube`는 개인용 컴퓨터(윈도우, 맥OS, 리눅스 포함)에서 +단일 노드 쿠버네티스 클러스터를 실행하므로 +쿠버네티스를 시험해 보거나 일상적인 개발 작업에 사용할 수 있다. + +툴을 설치하고 싶으면 +[시작하기!](https://minikube.sigs.k8s.io/docs/start/) 공식 가이드를 +참조하기 바란다. diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md deleted file mode 100644 index 191da08404..0000000000 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ /dev/null @@ -1,512 +0,0 @@ ---- -title: Minikube로 쿠버네티스 설치 -weight: 30 -content_type: concept ---- - - - -Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 가상 머신(VM) 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다. - - - - - -## Minikube 특징 - -Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. - -* DNS -* 노드 포트 -* 컨피그 맵과 시크릿 -* 대시보드 -* 컨테이너 런타임: [Docker](https://www.docker.com/), [CRI-O](https://cri-o.io/) 와 [containerd](https://github.com/containerd/containerd) -* CNI(Container Network Interface) 사용 -* 인그레스 - -## 설치 - -[Minikube 설치](/ko/docs/tasks/tools/install-minikube/) 항목을 보자. - -## 빠른 시작 - -여기서 기술하는 간단한 데모는 어떻게 로컬에서 Minikube를 시작하고, 사용하고 삭제하는지를 안내한다. 다음의 주어진 단계를 따라서 Minikube를 시작하고 탐구한다. - -1. Minikube를 시작하고 클러스터를 생성 - - ```shell - minikube start - ``` - - 결과는 다음과 비슷하다. - - ``` - Starting local Kubernetes cluster... - Running pre-create checks... - Creating machine... - Starting local Kubernetes cluster... - ``` - - 특정 쿠버네티스 버전, VM, 컨테이너 런타임 상에서 클러스터를 시작하기 위한 보다 상세한 정보는 [클러스터 시작하기](#클러스터-시작하기)를 참조한다. - -2. 이제, kubectl을 통해서 클러스터와 상호작용할 수 있다. 보다 상세한 정보는 [클러스터와 상호 작용하기](#클러스터와-상호-작용하기)를 참조한다. - - 간단한 HTTP 서버인 `echoserver` 이미지를 사용해서 쿠버네티스 디플로이먼트를 만들고 `--port`를 이용해서 8080 포트로 노출해보자. - - ```shell - kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 - ``` - - 결과는 다음과 비슷하다. - - ``` - deployment.apps/hello-minikube created - ``` -3. `hello-minikube` 디플로이먼트에 액세스하기 위해, 서비스로 노출시킨다. - - ```shell - kubectl expose deployment hello-minikube --type=NodePort --port=8080 - ``` - - `--type=NodePort` 옵션은 서비스 타입을 지정한다. - - 결과는 다음과 비슷하다. - - ``` - service/hello-minikube exposed - ``` - -4. `hello-minikube` 파드가 이제 시작되었지만 노출된 서비스를 통해서 접근하기 전에 파드가 뜨기를 기다려야한다. - - 파드가 시작되고 실행 중인지 확인한다. - - ```shell - kubectl get pod - ``` - - 출력에서 `STATUS`가 `ContainerCreating`으로 나타나는 경우, 파드는 아직 생성 중이다. - - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s - ``` - - 출력에서 `STATUS`가 `Running`으로 나타나는 경우, 파드는 이제 시작돼서 실행 중이다. - - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 1/1 Running 0 13s - ``` - -5. 서비스 상세를 보기 위해서 노출된 서비스의 URL을 얻는다. - - ```shell - minikube service hello-minikube --url - ``` - -6. 로컬 클러스터의 상세를 보기위해서, 출력에서 얻은 URL을 브라우저에 복사해서 붙여넣는다. - - 출력은 다음과 비슷하다. - - ``` - Hostname: hello-minikube-7c77b68cff-8wdzq - - Pod Information: - -no pod information available- - - Server values: - server_version=nginx: 1.13.3 - lua: 10008 - - Request Information: - client_address=172.17.0.1 - method=GET - real path=/ - query= - request_version=1.1 - request_scheme=http - request_uri=http://192.168.99.100:8080/ - - Request Headers: - accept=*/* - host=192.168.99.100:30674 - user-agent=curl/7.47.0 - - Request Body: - -no body in request- - ``` - - 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. - -7. `hello-minikube` 서비스 삭제 - - ```shell - kubectl delete services hello-minikube - ``` - - The output is similar to this: - - ``` - service "hello-minikube" deleted - ``` - -8. `hello-minikube` 디플로이먼트 삭제 - - ```shell - kubectl delete deployment hello-minikube - ``` - - The output is similar to this: - - ``` - deployment.extensions "hello-minikube" deleted - ``` - -9. 로컬 Minikube 클러스터 중지 - - ```shell - minikube stop - ``` - - The output is similar to this: - - ``` - Stopping "minikube"... - "minikube" stopped. - ``` - - 보다 상세한 정보는 [클러스터 중지하기](#클러스터-중지하기)를 참조한다. - -10. 로컬 Minikube 클러스터 삭제 - - ```shell - minikube delete - ``` - 출력은 다음과 비슷하다. - ``` - Deleting "minikube" ... - The "minikube" cluster has been deleted. - ``` - 보다 상세한 정보는 [Deleting a cluster](#클러스터-삭제하기)를 참조한다. - -## 클러스터 관리하기 - -### 클러스터 시작하기 - -클러스터를 시작하기 위해서 `minikube start` 커멘드를 사용할 수 있다. -이 커멘드는 단일 노드 쿠버네티스 클러스터를 구동하는 가상 머신을 생성하고 구성한다. -이 커멘드는 또한 [kubectl](/ko/docs/reference/kubectl/overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. - -{{< note >}} -웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. - -```shell -https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 -``` -불행하게도, 환경 변수 설정만으로는 되지 않는다. - -Minikube는 또한 "minikube" 콘텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다. -이 콘텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`. -{{< /note >}} - -#### 쿠버네티스 버전 지정하기 - -`minikube start` 코멘드에 `--kubernetes-version` 문자열을 -추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. -예를 들어 버전 {{< param "fullversion" >}}를 구동하려면, 다음과 같이 실행한다. - -``` -minikube start --kubernetes-version {{< param "fullversion" >}} -``` -#### VM 드라이버 지정하기 -`minikube start` 코멘드에 `--driver=` 플래그를 추가해서 VM 드라이버를 변경할 수 있다. -코멘드를 예를 들면 다음과 같다. -```shell -minikube start --driver= -``` -Minikube는 다음의 드라이버를 지원한다. -{{< note >}} -지원되는 드라이버와 플러그인 설치 방법에 대한 보다 상세한 정보는 [드라이버](https://minikube.sigs.k8s.io/docs/reference/drivers/)를 참조한다. -{{< /note >}} - -* docker ([드라이버 설치](https://minikube.sigs.k8s.io/docs/drivers/docker/)) -* virtualbox ([드라이버 설치](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/)) -* podman ([드라이버 설치](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (EXPERIMENTAL) -* vmwarefusion -* kvm2 ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) -* hyperkit ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) -* hyperv ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) -다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다. -* vmware ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver) -* parallels ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) -* none (쿠버네티스 컴포넌트를 가상 머신이 아닌 호스트 상에서 구동한다. 리눅스를 실행중이어야 하고, {{< glossary_tooltip term_id="docker" >}}가 설치되어야 한다.) - -{{< caution >}} -`none` 드라이버를 사용한다면 일부 쿠버네티스 컴포넌트는 Minikube 환경 외부에 있는 부작용이 있는 권한을 가진 컨테이너로 실행된다. 이런 부작용은 개인용 워크스테이션에는 `none` 드라이버가 권장하지 않는 것을 의미 한다. -{{< /caution >}} - -#### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기 -Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다. -{{< tabs name="container_runtimes" >}} -{{% tab name="containerd" %}} -[containerd](https://github.com/containerd/containerd)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=containerd \ - --bootstrapper=kubeadm -``` - -혹은 확장 버전을 사용할 수 있다. - -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --extra-config=kubelet.container-runtime=remote \ - --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \ - --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ - --bootstrapper=kubeadm -``` -{{% /tab %}} -{{% tab name="CRI-O" %}} -[CRI-O](https://cri-o.io/)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=cri-o \ - --bootstrapper=kubeadm -``` -혹은 확장 버전을 사용할 수 있다. - -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --extra-config=kubelet.container-runtime=remote \ - --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \ - --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ - --bootstrapper=kubeadm -``` -{{% /tab %}} -{{< /tabs >}} - -#### Docker 데몬 재사용을 통한 로컬 이미지 사용하기 - -쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 도커 데몬을 재사용하기에 매우 간편하다. 이 경우는 호스트 장비에 도커 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. 또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 도커 데몬 안에서 이미지를 빌드하기 때문이다. - -{{< note >}} -Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. 혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, 만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다. -{{< /note >}} - -맥이나 리눅스 호스트에서 해당 Docker 데몬을 사용하려면 `minikube docker-env` 에서 마지막 줄을 실행한다. - -이제 개인의 맥/리눅스 머신 내 커멘드 라인에서 도커를 사용해서 Minikube VM 안의 도커 데몬과 통신할 수 있다. - -```shell -docker ps -``` - -{{< note >}} -Centos 7 에서 Docker는 아래와 같은 오류를 발생한다. - -``` -Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory -``` - -/etc/sysconfig/docker를 업데이트하고 Minikube의 환경에 변경이 반영되었는지 확인해서 고칠 수 있다. - -```shell -< DOCKER_CERT_PATH=/etc/docker ---- -> if [ -z "${DOCKER_CERT_PATH}" ]; then -> DOCKER_CERT_PATH=/etc/docker -> fi -``` -{{< /note >}} - -### 쿠버네티스 구성하기 - -Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설정할 수 있도록 하는 '설정기' 기능이 있다. -이 기능을 사용하려면, `--extra-config` 플래그를 `minikube start` 명령어에 추가하여야 한다. - -이 플래그는 여러번 쓸 수 있어 여러 옵션 설정을 전달 할 수 있다. - -이 플래그는 `component.key=value`형식의 문자열로, -앞에 `component`는 아래 목록에 하나의 문자열이며 `key`는 configuration struct의 값이고 `value`는 설정할 값이다(역주: key는 struct의 맴버명). - -올바른 키들은 각 컴포넌트의 쿠버네티스 `componentconfigs` 문서에서 찾아 볼 수 있다. -다음은 각각의 지원하는 설정에 대한 문서이다. - -* [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/kubeletconfig#KubeletConfiguration) -* [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions) -* [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration) -* [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration) -* [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig) -* [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration) - -#### 예제 - -쿠블렛에서 `MaxPods` 설정을 5로 바꾸려면 `--extra-config=kubelet.MaxPods=5` 플래그를 전달하자. - -이 기능은 또한 중첩 구조를 지원한다. 스케쥴러에서 `LeaderElection.LeaderElect` 설정을 `true`로 하려면, `--extra-config=scheduler.LeaderElection.LeaderElect=true` 플래그를 전달하자. - -`apiserver`에서 `AuthorizationMode`를 `RBAC`으로 바꾸려면, `--extra-config=apiserver.authorization-mode=RBAC`를 사용할 수 있다. - -### 클러스터 중지 -`minikube stop` 명령어는 클러스터를 중지하는데 사용할 수 있다. -이 명령어는 Minikube 가상 머신을 종료하지만, 모든 클러스터 상태와 데이터를 보존한다. -클러스터를 다시 시작하면 이전의 상태로 돌려준다. - -### 클러스터 삭제 -`minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다. -이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다. - -### Minikube 업그레이드 -macOS를 사용하고 있고 [Brew 패키지 관리자](https://brew.sh/)가 설치되어 있다면 다음과 같이 실행한다. - -```shell -brew update -brew upgrade minikube -``` - -## 클러스터와 상호 작용하기 - -### Kubectl - -`minikube start` 명령어는 Minikube로 부르는 [kubectl 콘텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다. -이 콘텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. - -Minikube는 이 콘텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 다음을 실행하자. - -`kubectl config use-context minikube` - -혹은 다음과 같이 커맨드를 실행할 때마다 매번 콘텍스트를 전달한다. - -`kubectl get pods --context=minikube` - -### 대시보드 - -[쿠버네티스 대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)를 이용하려면, Minikube를 실행한 후 쉘에서 아래 명령어를 실행하여 주소를 확인한다. - -```shell -minikube dashboard -``` - -### 서비스 - -노드 포트로 노출된 서비스를 접근하기 위해, Minikube를 시작한 이후 쉘에서 아래 명령어를 실행하여 주소를 확인하자. - -```shell -minikube service [-n NAMESPACE] [--url] NAME -``` - -## 네트워킹 - -Minikube VM은 host-only IP 주소를 통해 호스트 시스템에 노출되고, 이 IP 주소는 `minikube ip` 명령어로 확인할 수 있다. -`NodePort` 서비스 타입은 IP 주소에 해당 노드 포트로 접근할 수 있다. - -서비스의 NodePort를 확인하려면 `kubectl` 명령어로 아래와 같이 하면 된다. - -`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'` - -## 퍼시스턴트 볼륨 -Minikube는 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 `hostPath` 타입으로 지원한다. -이런 퍼시스턴트 볼륨은 Minikube VM 내에 디렉터리로 매핑됩니다. - -Minikube VM은 tmpfs에서 부트하는데, 매우 많은 디렉터리가 재부트(`minikube stop`)까지는 유지되지 않다. -그러나, Minikube는 다음의 호스트 디렉터리 아래 파일은 유지하도록 설정되어 있다. - -* `/data` -* `/var/lib/minikube` -* `/var/lib/docker` - -이것은 `/data` 디렉터리에 데이터를 보존하도록 한 퍼시스턴트 볼륨 환경설정의 예이다. - -```yaml -apiVersion: v1 -kind: PersistentVolume -metadata: - name: pv0001 -spec: - accessModes: - - ReadWriteOnce - capacity: - storage: 5Gi - hostPath: - path: /data/pv0001/ -``` - -## 호스트 폴더 마운트 -어떤 드라이버는 VM 안에 호스트 폴더를 마운트하여 VM과 호스트 사이에 쉽게 파일을 공유할 수 있게 한다. 이들은 지금 설정할 수 없고 사용하는 드라이버나 운영체제에 따라 다르다. - -{{< note >}} -호스트 폴더 공유는 KVM 드라이버에서 아직 구현되어 있지 않다. -{{< /note >}} - -| Driver | OS | HostFolder | VM | -| --- | --- | --- | --- | -| VirtualBox | 리눅스 | `/home` | `/hosthome` | -| VirtualBox | macOS | `/Users` | `/Users` | -| VirtualBox | 윈도우 | `C://Users` | `/c/Users` | -| VMware Fusion | macOS | `/Users` | `/mnt/hgfs/Users` | -| Xhyve | macOS | `/Users` | `/Users` | - -## 프라이빗 컨테이너 레지스트리 - -프라이빗 컨테이너 레지스트리를 이용하려면, [이 페이지](/ko/docs/concepts/containers/images/)의 단계를 따르자. - -`ImagePullSecrets`를 이용하기를 권하지만, Minikube VM 상에서 설정하려 한다면 `/home/docker` 디렉터리에 `.dockercfg`를 두거나 `/home/docker/.docker` 디렉터리에 `config.json`을 둘 수 있다. - -## 애드온 - -Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, -Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터리에 두자. -폴더 내부의 애드온은 Minikube VM으로 이동되어 -Minikube가 시작하거나 재시작될 때에 함께 실행된다. - -## HTTP 프록시 환경에서 Minikube 사용하기 - -Minikube는 쿠버네티스와 Docker 데몬을 포함한 가상 머신을 생성한다. -쿠버네티스가 Docker를 이용하여 컨테이너를 스케쥴링 시도할 때에, Docker 데몬은 컨테이너 이미지를 풀링하기 위해 외부 네트워크를 이용해야 한다. - -HTTP 프록시 내부라면, Docker에서 프록시 설정을 해야 한다. -이를 하기 위해서 요구되는 환경 변수를 `minikube start` 중에 플래그로 전달한다. - -예를 들어: - -```shell -minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ - --docker-env https_proxy=https://$YOURPROXY:PORT -``` - -만약 가상 머신 주소가 192.168.99.100 이라면 프록시 설정이 `kubectl`에 직접적으로 도달하지 못할 수도 있다. -이 IP 주소에 대해 프록시 설정을 지나치게 하려면 no_proxy 설정을 수정해야 한다. 다음과 같이 할 수 있다. - -```shell -export no_proxy=$no_proxy,$(minikube ip) -``` - -## 알려진 이슈 - -다중 노드가 필요한 기능은 Minukube에서 동작하지 않는다. - -## 설계 - -Minikube는 VM 프로비저닝을 위해서 [libmachine](https://github.com/docker/machine/tree/master/libmachine)를 사용하고, 쿠버네티스 클러스터를 프로비저닝하기 위해 [kubeadm](https://github.com/kubernetes/kubeadm)을 사용한다. - -Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md) 부분을 읽어보자. - -## 추가적인 링크: - -* **목표와 비목표**: Minikube 프로젝트의 목표와 비목표에 대해서는 [로드맵](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)을 살펴보자. -* **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [기여하기](https://minikube.sigs.k8s.io/docs/contrib/)를 살펴보자. -* **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://minikube.sigs.k8s.io/docs/contrib/building/)를 살펴보자. -* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/drivers/)를 보자. -* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. -* **MicroK8s**: 가상 머신을 사용하지 않으려는 리눅스 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. - -## 커뮤니티 - -컨트리뷰션, 질문과 의견은 모두 환영하며 격려한다! Minikube 개발자는 [슬랙](https://kubernetes.slack.com)에 `#minikube` 채널(초청받으려면 [여기](https://slack.kubernetes.io/))에 상주하고 있다. 또한 [kubernetes-dev 구글 그룹 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-dev)도 있다. 메일링 리스트에 포스팅한다면 제목에 "minikube: "라는 접두어를 사용하자. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 0bc616419b..5f6051d59c 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -4,126 +4,133 @@ content_type: concept weight: 10 --- -{{< feature-state for_k8s_version="v1.6" state="stable" >}} -파드에서 컨테이너를 실행하기 위해 쿠버네티스는 컨테이너 런타임을 사용한다. -이 페이지는 다양한 런타임들에 대한 설치 지침을 담고 있다. - +파드가 노드에서 실행될 수 있도록 클러스터의 각 노드에 +{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을 +설치해야 한다. 이 페이지에서는 관련된 항목을 설명하고 +노드 설정 관련 작업을 설명한다. +이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한 +세부 정보가 있다. -{{< caution >}} -컨테이너를 실행할 때 runc가 시스템 파일 디스크립터를 처리하는 방식에서 결함이 발견되었다. -악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며 -따라서 컨테이너 호스트 시스템에서 임의의 명령을 실행할 수 있다. - -문제에 대한 자세한 내용은 [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736) -를 참고한다. -{{< /caution >}} - -### 적용 가능성 +- [containerd](#containerd) +- [CRI-O](#cri-o) +- [도커](#도커) {{< note >}} -이 문서는 리눅스에 CRI를 설치하는 사용자를 위해 작성되었다. 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자. {{< /note >}} -### Cgroup 드라이버 - -리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는 -root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. -Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. -컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. -systemd와 함께`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다. +## Cgroup 드라이버 Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다. -단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고, -기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다. -관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는 -`cgroupfs`를 사용하고 나머지 프로세스는 -`systemd`를 사용하도록 노드가 설정된 경우, -리소스가 부족할 때 불안정해지는 사례를 본 적이 있다. + +리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인 +경우, init 프로세스는 root control group(`cgroup`)을 +생성 및 사용하는 cgroup 관리자로 작동한다. +Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. +컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. systemd와 함께 +`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다. + +단일 cgroup 관리자는 할당되는 리소스가 무엇인지를 단순화하고, +기본적으로 사용할 수 있는 리소스와 사용 중인 리소스를 일관성있게 볼 수 있다. +시스템에 두 개의 cgroup 관리자가 있으면, 이런 리소스도 두 개의 관점에서 보게 된다. +현장에서 사람들은 kubelet과 도커에 `cgroupfs`를 사용하고, +나머지 프로세스는 `systemd`를 사용하도록 노드가 설정된 경우, 리소스가 부족할 때 +불안정해지는 사례를 보고했다. 컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면 -시스템이 안정화된다. 아래의 도커 설정에서 `native.cgroupdriver=systemd` 옵션을 확인하라. +시스템이 안정화된다. 도커에 대해 구성하려면, `native.cgroupdriver=systemd`를 설정한다. {{< caution >}} -클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 권장하지 않는다. +클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 강력하게 권장하지 *않는다*. 하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면, -컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 PodSandBox를 재생성을 시도할 때, 에러가 발생할 수 있다. -kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. -추천하는 방법은 워크로드에서 노드를 제거하고, 클러스터에서 제거한 다음 다시 결합시키는 것이다. +컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 파드 샌드박스 재생성을 시도할 때, 에러가 발생할 수 있다. +kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. + +자동화가 가능하다면, 업데이트된 구성을 사용하여 노드를 다른 노드로 +교체하거나, 자동화를 사용하여 다시 설치한다. {{< /caution >}} -## 도커 +## 컨테이너 런타임 -각 머신들에 대해서, 도커를 설치한다. -버전 19.03.11이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. -쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 도커 버전의 지속적인 파악이 필요하다. +{{% thirdparty-content %}} -시스템에 도커를 설치하기 위해서 아래의 커맨드들을 사용한다. +### containerd -{{< tabs name="tab-cri-docker-installation" >}} -{{% tab name="Ubuntu 16.04+" %}} +이 섹션에는 `containerd` 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다. + +필수 구성 요소를 설치 및 구성한다. ```shell -# (도커 CE 설치) -## 리포지터리 설정 -### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치 -sudo apt-get update && sudo apt-get install -y \ - apt-transport-https ca-certificates curl software-properties-common gnupg2 -``` - -```shell -# 도커 공식 GPG 키 추가 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - -``` - -```shell -# 도커 apt 리포지터리 추가. -sudo add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" -``` - -```shell -# 도커 CE 설치. -sudo apt-get update && sudo apt-get install -y \ - containerd.io=1.2.13-2 \ - docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) -``` - -```shell -# 도커 데몬 설정 -cat <}} +{{% tab name="Ubuntu 16.04" %}} + +```shell +# 도커의 공식 GPG 키 추가 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - +# (containerd 설치) +## 리포지터리 설정 +### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치 +sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common ``` ```shell -sudo mkdir -p /etc/systemd/system/docker.service.d +## 도커의 공식 GPG 키 추가 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add - ``` ```shell -# 도커 재시작. -sudo systemctl daemon-reload -sudo systemctl restart docker +## 도커 apt 리포지터리 추가 +sudo add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" +``` + +```shell +## containerd 설치 +sudo apt-get update && sudo apt-get install -y containerd.io +``` + +```shell +# containerd 구성 +sudo mkdir -p /etc/containerd +sudo containerd config default > /etc/containerd/config.toml +``` + +```shell +# containerd 재시작 +sudo systemctl restart containerd ``` {{% /tab %}} {{% tab name="CentOS/RHEL 7.4+" %}} ```shell -# (도커 CE 설치) +# (containerd 설치) ## 리포지터리 설정 ### 필요한 패키지 설치 sudo yum install -y yum-utils device-mapper-persistent-data lvm2 @@ -131,64 +138,73 @@ sudo yum install -y yum-utils device-mapper-persistent-data lvm2 ```shell ## 도커 리포지터리 추가 -sudo yum-config-manager --add-repo \ - https://download.docker.com/linux/centos/docker-ce.repo +sudo yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo ``` ```shell -# 도커 CE 설치. -sudo yum update -y && sudo yum install -y \ - containerd.io-1.2.13 \ - docker-ce-19.03.11 \ - docker-ce-cli-19.03.11 +# containerd 설치 +sudo yum update -y && sudo yum install -y containerd.io ``` ```shell -## /etc/docker 생성. -sudo mkdir /etc/docker +## containerd 구성 +sudo mkdir -p /etc/containerd +sudo containerd config default > /etc/containerd/config.toml ``` ```shell -# 도커 데몬 설정. -cat <}} -부팅 시 도커 서비스를 시작하려면, 다음 명령을 실행한다. +#### systemd {#containerd-systemd} -```shell -sudo systemctl enable docker +`/etc/containerd/config.toml` 의 `systemd` cgroup 드라이버를 `runc` 에서 사용하려면, 다음과 같이 설정한다. + +``` +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] + ... + [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] + SystemdCgroup = true ``` -자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/) -를 참고한다. +kubeadm을 사용하는 경우, +[kubelet용 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 수동으로 구성한다. -## CRI-O +### CRI-O -이 섹션은 `CRI-O`를 CRI 런타임으로 설치하는 필수적인 단계를 담고 있다. +이 섹션은 CRI-O를 컨테이너 런타임으로 설치하는 필수적인 단계를 담고 있다. 시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다. @@ -197,7 +213,7 @@ CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o)를 본다. {{< /note >}} -### 선행 조건 +필수 구성 요소를 설치하고 구성한다. ```shell sudo modprobe overlay @@ -216,9 +232,10 @@ sudo sysctl --system {{< tabs name="tab-cri-cri-o-installation" >}} {{% tab name="Debian" %}} -다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다. +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 +아래의 표에서 적절한 필드로 설정한다. -| 운영 체제 | $OS | +| 운영 체제 | `$OS` | | ---------------- | ----------------- | | Debian Unstable | `Debian_Unstable` | | Debian Testing | `Debian_Testing` | @@ -233,14 +250,14 @@ sudo sysctl --system 그런 다음, 아래를 실행한다. ```shell cat < /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list +cat <}} -### CRI-O 시작 +CRI-O를 시작한다. ```shell sudo systemctl daemon-reload @@ -340,78 +361,75 @@ sudo systemctl start crio 자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)를 참고한다. -## Containerd +### 도커 -이 섹션은 `containerd`를 CRI 런타임으로써 사용하는데 필요한 단계를 담고 있다. +각 노드에 도커 CE를 설치한다. -Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사용한다. +쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는 도커 버전을 찾을 수 있다. -### 선행 조건 +사용자의 시스템에서 다음의 명령을 이용해 도커를 설치한다. + +{{< tabs name="tab-cri-docker-installation" >}} +{{% tab name="Ubuntu 16.04+" %}} ```shell -cat <}} -{{% tab name="Ubuntu 16.04" %}} - -```shell -# (containerd 설치) +# (도커 CE 설치) ## 리포지터리 설정 ### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치 -sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common +sudo apt-get update && sudo apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 ``` ```shell -## 도커 공식 GPG 키 추가 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - +# 도커 공식 GPG 키 추가: +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add - ``` ```shell -## 도커 apt 리포지터리 추가. +# 도커 apt 리포지터리 추가: sudo add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" + deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" ``` ```shell -## containerd 설치 -sudo apt-get update && sudo apt-get install -y containerd.io +# 도커 CE 설치 +sudo apt-get update && sudo apt-get install -y \ + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) ``` ```shell -# containerd 설정 -sudo mkdir -p /etc/containerd -sudo containerd config default > /etc/containerd/config.toml +# 도커 데몬 설정 +cat < /etc/containerd/config.toml +## /etc/docker 생성 +sudo mkdir /etc/docker ``` ```shell -# containerd 재시작 -sudo systemctl restart containerd -``` -{{% /tab %}} -{{% tab name="윈도우 (PowerShell)" %}} -```powershell -# (containerd 설치) -# containerd 다운로드 -cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.0-beta.2/containerd-1.4.0-beta.2-windows-amd64.tar.gz -cmd /c tar xvf .\containerd-1.4.0-beta.2-windows-amd64.tar.gz +# 도커 데몬 설정 +cat <}} -### systemd - -`systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`에 다음을 설정한다. +부팅 시 `docker` 서비스를 시작하려면, 다음 명령을 실행한다. +```shell +sudo systemctl enable docker ``` -[plugins.cri] -systemd_cgroup = true -``` -kubeadm을 사용하는 경우에도 마찬가지로, 수동으로 -[kubelet을 위한 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 설정한다. -## 다른 CRI 런타임: frakti - -자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다. +자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/)를 +참조한다. diff --git a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index b41120f7be..7eb0f8f706 100644 --- a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -600,7 +600,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 필요하다. - "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 참고한다. + "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다. ### 추가 조사 diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index f129386a62..bae83b73a9 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -65,7 +65,7 @@ spec: command: - powershell.exe - -command - - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " + - "<#code used from https://gist.github.com/19WAS85/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " nodeSelector: kubernetes.io/os: windows ``` diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 39226c89be..e78046f0ee 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -149,9 +149,8 @@ root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다. localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을 요구하지 않지만 이는 표준이 아니다. -[API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은 +[API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)은 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. -이 방식들은 미래의 고가용성 지원과 충돌될 수 있다. ## API에 프로그래밍 방식으로 접근 diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md index ba4a794d23..efb489b18d 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -148,8 +148,8 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 일부 클러스터에서, API 서버는 인증이 필요하지 않다. 로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은 -없다. [API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은 -클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 +없다. [쿠버네티스 API에 대한 접근 제어](/docs/concepts/security/controlling-access)은 +클러스터 관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 고 가용성 지원과 충돌할 수 있다. ### API에 프로그래밍 방식으로 접근 diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md index b57e07db65..0f241c87f4 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-management.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md @@ -69,7 +69,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레 다른 제공자들과 도구들은 업그레이드를 다른 방식으로 관리한다. 이들의 업그레이드를 위해서는 이들의 주요 문서를 참조하기를 권장한다. * [kops](https://github.com/kubernetes/kops) -* [kubespray](https://github.com/kubernetes-incubator/kubespray) +* [kubespray](https://github.com/kubernetes-sigs/kubespray) * [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html) * [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) * ... diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index ac3ac3f695..aea9411eda 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -8,7 +8,7 @@ weight: 10 {{< feature-state for_k8s_version="v1.15" state="stable" >}} -[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다. +[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다. ## {{% heading "prerequisites" %}} diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index 1b0873f74a..8623aadbc8 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -12,7 +12,7 @@ weight: 40 ## {{% heading "prerequisites" %}} -[kubeadm 시작하기](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)의 1, 2, 3 단계를 완료하자. +[kubeadm 시작하기](/ko/docs/reference/setup-tools/kubeadm/)의 1, 2, 3 단계를 완료하자. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index 736572c808..5b32655017 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -11,7 +11,7 @@ weight: 50 ## {{% heading "prerequisites" %}} 쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 -[kubeadm 시작하기 안내서](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)를 따른다. +[kubeadm 시작하기 안내서](/ko/docs/reference/setup-tools/kubeadm/)를 따른다. diff --git a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md index 980d71d9b5..a798018b91 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -21,8 +21,8 @@ weight: 10 클러스터의 각 노드에 최소 300 MiB 메모리가 있어야 한다. 이 페이지의 몇 가지 단계를 수행하기 위해서는 클러스터 내 -[metrics-server](https://github.com/kubernetes-incubator/metrics-server) -서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면 +[metrics-server](https://github.com/kubernetes-sigs/metrics-server) +서비스 실행이 필요하다. 이미 실행 중인 metrics-server가 있다면 다음 단계를 건너뛸 수 있다. Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 4c1679b8a3..dc4acf8411 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -31,7 +31,7 @@ weight: 60 아직 단일 노드 클러스터를 가지고 있지 않다면, [Minikube](/ko/docs/setup/learning-environment/minikube/)를 사용하여 클러스터 하나를 생성할 수 있다. -* [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)의 +* [퍼시스턴트 볼륨](https://minikube.sigs.k8s.io/docs/)의 관련 자료에 익숙해지도록 한다. diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index a9c9bf182d..e4bf6a1715 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -51,8 +51,8 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다. ## 메트릭 서버 -[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. -기본적으로, `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 메트릭 서버가 +[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. +`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 [디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다. diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index 87856b9cfe..21c5c3decf 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -28,7 +28,7 @@ title: 리소스 모니터링 도구 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인 -[metrics-server](https://github.com/kubernetes-incubator/metrics-server)에 +[metrics-server](https://github.com/kubernetes-sigs/metrics-server)에 의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의 diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md index 191e82021c..22372813e9 100644 --- a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -47,17 +47,10 @@ weight: 20 envar-demo 1/1 Running 0 9s ``` -1. 파드 안에 실행되고 있는 컨테이너의 셸에 접근한다. +1. 파드의 컨테이너 환경 변수를 나열한다. ```shell - kubectl exec -it envar-demo -- /bin/bash - ``` - -1. 셸 안에서, 환경 변수를 나열하기 위해 `printenv` 커맨드를 실행한다. - - ```shell - # 컨테이너 내 셸에서 다음을 실행한다. - printenv + kubectl exec envar-demo -- printenv ``` 출력은 아래와 비슷할 것이다. @@ -71,8 +64,6 @@ weight: 20 DEMO_FAREWELL=Such a sweet sorrow ``` -1. 셸에서 빠져나오기 위해, `exit`을 입력한다. - {{< note >}} `env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 안에서 명시된 모든 환경 변수들을 오버라이딩한다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index c9c694e237..b81329c24a 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -18,9 +18,9 @@ Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다. -[메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. +[메트릭-서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. -메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다. +메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다. Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, 버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 7a7d129525..5afca02371 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -264,12 +264,12 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. * 해당 API 등록: - * 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server)가 제공하는 `metrics.k8s.io` API이다. + * 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)가 제공하는 `metrics.k8s.io` API이다. 클러스터 애드온으로 시작할 수 있다. * 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다. 메트릭 파이프라인 또는 [알려진 솔루션 목록](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)으로 확인한다. - 직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-incubator/custom-metrics-apiserver)을 확인하라. + 직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다. * 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다. diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md index 9753772c5f..74abf8d981 100755 --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -17,11 +17,23 @@ no_list: true kubectl 설치 및 설정 가이드 보기 -[`kubectl` 레퍼런스 문서](/ko/docs/reference/kubectl/)를 읽어볼 수도 있다. +[`kubectl` 레퍼런스 문서](/ko/docs/reference/kubectl/)를 +읽어볼 수도 있다. + +## kind + +[kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서 +쿠버네티스를 실행할 수 있다. 이 도구를 사용하려면 +[도커](https://docs.docker.com/get-docker/)를 설치하고 구성해야 한다. + +kind [퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/) 페이지는 +kind를 시작하고 실행하기 위해 수행해야 하는 작업을 보여준다. + +kind 시작하기 가이드 보기 ## minikube -[`minikube`](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는 +`kind` 와 마찬가지로, [`minikube`](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는 도구이다. `minikube` 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서 단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을 수행할 수 있다. @@ -35,14 +47,12 @@ no_list: true `minikube` 가 작동하면, 이를 사용하여 [샘플 애플리케이션을 실행](/ko/docs/tutorials/hello-minikube/)해볼 수 있다. -## kind +## kubeadm -`minikube` 와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서 -쿠버네티스를 실행할 수 있다. `minikube` 와 달리, `kind` 는 단일 컨테이너 런타임에서만 작동한다. -`kind` 는 [도커](https://docs.docker.com/get-docker/)를 설치하고 -구성해야 한다. +{{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} 도구를 사용하여 쿠버네티스 클러스터를 만들고 관리할 수 있다. +사용자 친화적인 방식으로 최소한의 실행 가능하고 안전한 클러스터를 설정하고 실행하는 데 필요한 작업을 수행한다. -[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 `kind` 를 시작하고 실행하기 위해 -수행해야 하는 작업을 보여준다. +[kubeadm 설치](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 페이지는 kubeadm 설치하는 방법을 보여준다. +설치가 끝나면, [클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)이 가능하다. -kind 시작하기 가이드 보기 +kubeadm 설치 가이드 보기 diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md index 2f2e6c4fe0..04801d4ff8 100644 --- a/content/ko/docs/tasks/tools/install-kubectl.md +++ b/content/ko/docs/tasks/tools/install-kubectl.md @@ -521,7 +521,7 @@ compinit ## {{% heading "whatsnext" %}} -* [Minikube 설치](/ko/docs/tasks/tools/install-minikube/) +* [Minikube 설치](https://minikube.sigs.k8s.io/docs/start/) * 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다. * [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/) * 직접 생성하지 않은 클러스터에 접근해야하는 경우, diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 699902295e..8f3f515f31 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -15,25 +15,23 @@ card: -이 튜토리얼에서는 [Minikube](/ko/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 +이 튜토리얼에서는 Minikube와 Katacoda를 이용하여 쿠버네티스에서 샘플 애플리케이션을 어떻게 실행하는지 살펴본다. Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. {{< note >}} -[로컬에서 Minikube](/ko/docs/tasks/tools/install-minikube/)를 설치했다면 이 튜토리얼도 따라 할 수 있다. +로컬에서 Minikube를 설치했다면 이 튜토리얼도 따라 할 수 있다. +설치 안내는 [minikube 시작](https://minikube.sigs.k8s.io/docs/start/)을 참고한다. {{< /note >}} ## {{% heading "objectives" %}} - -* 샘플 애플리케이션을 Minikube에 배포한다. +* 샘플 애플리케이션을 minikube에 배포한다. * 배포한 애플리케이션을 실행한다. * 애플리케이션의 로그를 확인한다. - - ## {{% heading "prerequisites" %}} @@ -43,14 +41,14 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. -## Minikubue 클러스터 만들기 +## minikubue 클러스터 만들기 1. **Launch Terminal** 을 클릭 {{< kat-button >}} {{< note >}} - Minikube를 로컬에 설치했다면 `minikube start`를 실행한다. + minikube를 로컬에 설치했다면 `minikube start`를 실행한다. {{< /note >}} 2. 브라우저에서 쿠버네티스 대시보드를 열어보자. @@ -156,7 +154,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 로드 밸런서를 지원하는 클라우드 공급자의 경우에는 서비스에 접근할 수 있도록 외부 IP 주소가 프로비저닝 한다. - Minikube에서 `LoadBalancer`타입은 `minikube service` 명령어를 통해서 해당 서비스를 접근할 수 + minikube에서 `LoadBalancer`타입은 `minikube service` 명령어를 통해서 해당 서비스를 접근할 수 있게 한다. 3. 다음 명령어를 실행한다 @@ -173,7 +171,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ## 애드온 사용하기 -Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 {{< glossary_tooltip text="애드온" term_id="addons" >}} 셋이 있다. +minikube 툴은 활성화하거나 비활성화할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 {{< glossary_tooltip text="애드온" term_id="addons" >}} 셋이 포함되어 있다. 1. 현재 지원하는 애드온 목록을 확인한다. diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 33fdcb4dbe..8273f3bcd9 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -50,7 +50,7 @@ weight: 30 ### 추가적인 Minikube 설정 요령 {{< caution >}} -[Minikube](/docs/getting-started-guides/minikube/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. +[Minikube](https://minikube.sigs.k8s.io/docs/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. 이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가 발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md index cc02b6651d..faf5fd5303 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -17,8 +17,6 @@ card: * Metricbeat * Packetbeat - - ## {{% heading "objectives" %}} * Redis를 이용한 PHP 방명록 시작. @@ -27,7 +25,6 @@ card: * Beats 배포. * 로그와 메트릭의 대시보드 보기. - ## {{% heading "prerequisites" %}} @@ -38,16 +35,20 @@ card: * 실행 중인 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼의 배포본. -* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나, [파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) 워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다. +* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나, + [파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) + 워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다. ## Redis를 이용한 PHP 방명록 시작 + 이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자. ## 클러스터 롤 바인딩 추가 + [클러스터 단위 롤 바인딩](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다. ```shell @@ -58,31 +59,39 @@ kubectl create clusterrolebinding cluster-admin-binding \ ## kube-state-metrics 설치 [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다. + ```shell git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics kubectl apply -f kube-state-metrics/examples/standard ``` ### kube-state-metrics 실행 여부 확인 + ```shell kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics ``` + 출력 -```shell + +``` NAME READY STATUS RESTARTS AGE kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s ``` + ## Elastic의 예제를 GitHub 리포지터리에 클론한다. + ```shell git clone https://github.com/elastic/examples.git ``` 나머지 커맨드는 `examples/beats-k8s-send-anywhere` 디렉터리의 파일을 참조할 것이라서, 그쪽으로 현재 디렉터리를 변경한다. + ```shell cd examples/beats-k8s-send-anywhere ``` ## 쿠버네티스 시크릿 만들기 + 쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}은 암호나 토큰, 키 같이 소량의 민감한 데이터를 포함하는 오브젝트이다. 이러한 정보는 다른 방식으로도 파드 스펙이나 이미지에 넣을 수 있을 것이다. 시크릿 오브젝트에 넣으면 이것이 어떻게 사용되는지 다양하게 제어할 수 있고, 우발적인 노출 사고의 위험이 줄일 수 있다. {{< note >}} @@ -93,55 +102,68 @@ cd examples/beats-k8s-send-anywhere {{% tab name="자체 관리(Self Managed)" %}} ### 자체 관리 + Elastic Cloud의 Elasticsearch 서비스로 연결한다면 **관리 서비스** 탭으로 전환한다. ### 자격증명(credentials) 설정 + 자체 관리 Elasticsearch와 Kibana(자체 관리는 사실상 Elastic Cloud의 관리 서비스 Elasticsearch와 다르다) 서비스에 접속할 때에 4개 파일을 수정하여 쿠버네티스 시크릿을 생성한다. 파일은 다음과 같다. -1. ELASTICSEARCH_HOSTS -1. ELASTICSEARCH_PASSWORD -1. ELASTICSEARCH_USERNAME -1. KIBANA_HOST +1. `ELASTICSEARCH_HOSTS` +1. `ELASTICSEARCH_PASSWORD` +1. `ELASTICSEARCH_USERNAME` +1. `KIBANA_HOST` 이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시(또는 [*이 구성*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)을 본다)가 있다. #### `ELASTICSEARCH_HOSTS` + 1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup). - ```shell - ["http://elasticsearch-master.default.svc.cluster.local:9200"] - ``` + ``` + ["http://elasticsearch-master.default.svc.cluster.local:9200"] + ``` + 1. Mac을 위한 Docker에서 Beats를 운영 중인 Mac에서 운영하는 단일 Elasticsearch 노드. - ```shell - ["http://host.docker.internal:9200"] - ``` + ``` + ["http://host.docker.internal:9200"] + ``` + 1. VM이나 물리 장비에서 운영 중인 두 개의 ELASTICSEARCH 노드. - ```shell - ["http://host1.example.com:9200", "http://host2.example.com:9200"] - ``` -`ELASTICSEARCH_HOSTS` 수정한다. + ``` + ["http://host1.example.com:9200", "http://host2.example.com:9200"] + ``` + +`ELASTICSEARCH_HOSTS` 를 수정한다. + ```shell vi ELASTICSEARCH_HOSTS ``` #### `ELASTICSEARCH_PASSWORD` -화이트 스페이스나 인용 부호나 <> 도 없는 암호이다. +화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 암호이다. - <사용자의 시크릿 암호> +``` +<사용자시크릿암호> +``` + +`ELASTICSEARCH_PASSWORD` 를 수정한다. -`ELASTICSEARCH_PASSWORD` 수정한다. ```shell vi ELASTICSEARCH_PASSWORD ``` #### `ELASTICSEARCH_USERNAME` -화이트 스페이스나 인용 부호나 <> 도 없는 이름이다. +화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 이름이다. - +``` + +``` + +`ELASTICSEARCH_USERNAME` 을 수정한다. -`ELASTICSEARCH_USERNAME` 수정한다. ```shell vi ELASTICSEARCH_USERNAME ``` @@ -150,78 +172,97 @@ vi ELASTICSEARCH_USERNAME 1.Elastic의 Kibana Helm 차트의 인스턴스이다. 하위 도메인 `default`는 기본 네임스페이스를 참조한다. 다른 네임스페이스를 사용하여 Helm 차트를 배포한 경우 하위 도메인이 다릅니다. - ```shell - "kibana-kibana.default.svc.cluster.local:5601" - ``` + ``` + "kibana-kibana.default.svc.cluster.local:5601" + ``` + 1. Mac 용 Docker에서 실행하는 Beats가 있는 Mac에서 실행하는 Kibana 인스턴스 - ```shell - "host.docker.internal:5601" - ``` + ``` + "host.docker.internal:5601" + ``` 1. 가상머신이나 물리적 하드웨어에서 실행 중인 두 개의 Elasticsearch 노드 - ```shell - "host1.example.com:5601" - ``` -`KIBANA_HOST`를 편집한다. + ``` + "host1.example.com:5601" + ``` + +`KIBANA_HOST` 를 편집한다. + ```shell vi KIBANA_HOST ``` ### 쿠버네티스 시크릿 만들기 -이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(kube-system)에 시크릿을 만든다. - kubectl create secret generic dynamic-logging \ - --from-file=./ELASTICSEARCH_HOSTS \ - --from-file=./ELASTICSEARCH_PASSWORD \ - --from-file=./ELASTICSEARCH_USERNAME \ - --from-file=./KIBANA_HOST \ - --namespace=kube-system +이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 만든다. + +```shell +kubectl create secret generic dynamic-logging \ + --from-file=./ELASTICSEARCH_HOSTS \ + --from-file=./ELASTICSEARCH_PASSWORD \ + --from-file=./ELASTICSEARCH_USERNAME \ + --from-file=./KIBANA_HOST \ + --namespace=kube-system +``` {{% /tab %}} {{% tab name="관리 서비스(Managed service)" %}} ## 관리 서비스 + 이 탭은 Elastic Cloud에서 Elasticsearch 서비스 만에 대한 것으로, 이미 자체 관리 Elasticsearch와 Kibana 배포로 시크릿을 생성했다면, [Beats 배포](#deploy-the-beats)를 계속한다. + ### 자격증명(credentials) 설정 + Elastic Cloud에서 관리되는 Elastic 서비스에 연결할 때, 쿠버네티스 시크릿을 생성하기 위해 편집할 두 파일이 있다. 파일은 다음과 같다. -1. ELASTIC_CLOUD_AUTH -1. ELASTIC_CLOUD_ID +1. `ELASTIC_CLOUD_AUTH` +1. `ELASTIC_CLOUD_ID` 디플로이먼트를 생성할 때에 Elasticsearch 콘솔에서 제공한 정보로 이를 설정한다. 여기 예시들이 있다. -#### ELASTIC_CLOUD_ID -```shell +#### `ELASTIC_CLOUD_ID` + +``` devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ== ``` -#### ELASTIC_CLOUD_AUTH +#### `ELASTIC_CLOUD_AUTH` + 사용자 이름, 콜론(`:`) 및 비밀번호인데, 공백 또는 따옴표는 없다. -```shell + +``` elastic:VFxJJf9Tjwer90wnfTghsn8w ``` ### 필요 파일 편집하기 + ```shell vi ELASTIC_CLOUD_ID vi ELASTIC_CLOUD_AUTH ``` + ### 쿠버네티스 시크릿 생성하기 -이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(kube-system)에 시크릿을 생성한다. - kubectl create secret generic dynamic-logging \ - --from-file=./ELASTIC_CLOUD_ID \ - --from-file=./ELASTIC_CLOUD_AUTH \ - --namespace=kube-system +이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 생성한다. - {{% /tab %}} +```shell +kubectl create secret generic dynamic-logging \ + --from-file=./ELASTIC_CLOUD_ID \ + --from-file=./ELASTIC_CLOUD_AUTH \ + --namespace=kube-system +``` + +{{% /tab %}} {{< /tabs >}} ## Beats 배포하기 {#deploy-the-beats} + 각 Beat마다 메니페스트 파일을 제공한다. 이 메니페스트 파일은 앞서 생성한 시크릿을 사용하여, Elasticsearch 및 Kibana 서버에 연결하도록 Beats를 구성한다. ### Filebeat에 대해 + Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파드에서 실행되는 컨테이너의 로그를 수집한다. Filebeat는 {{< glossary_tooltip text="데몬 셋" term_id="daemonset" >}}으로 배포한다. Filebeat는 쿠버네티스 클러스터에서 실행 중인 애플리케이션을 자동 검색할 수 있다. 시작시에 Filebeat는 기존 컨테이너를 검색하고 이에 적절한 구성을 시작하고 새 시작/종료 이벤트를 감시한다. 아래 내용은 Filebeat가 방명록 애플리케이션과 함께 배포된 Redis 컨테이너에서 Redis 로그를 찾아 구문분석할 수 있게 하는 자동 검색 구성이다. 이 구성은 `filebeat-kubernetes.yaml`파일에 있다. @@ -240,20 +281,25 @@ Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파 enabled: true var.hosts: ["${data.host}:${data.port}"] ``` + 이것은 `redis` 컨테이너가 `app` 문자열을 포함하는 레이블로 감지될 때에 Filebeat 모듈 `redis`를 적용하도록 Filebeat를 구성한다. Redis 모듈은 Docker 입력 유형을 사용하여 컨테이너에서 `로그` 스트림을 수집할 수 있다(이 Redis 컨테이너의 STDOUT 스트림과 연관된 쿠버네티스 노드에서 파일 읽기). 또한 이 모듈은 컨테이너 메타 데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 Redis의 `slowlog` 항목을 수집할 수 있다. ### Filebeat 배포 + ```shell kubectl create -f filebeat-kubernetes.yaml ``` #### 확인 + ```shell kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic ``` ### Metricbeat에 대해 + Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음은 Redis 컨테이너에 대한 Metricbeat의 자동 검색 구성이다. 이 구성은 `metricbeat-kubernetes.yaml`에 있다. + ```yaml - condition.equals: kubernetes.labels.tier: backend @@ -265,18 +311,23 @@ Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음 # Redis hosts hosts: ["${data.host}:${data.port}"] ``` + 이것은 컨테이너가 `tier` 레이블이 `backend` 문자열과 같은 레이블로 감지될 때에 Metricbeat 모듈 `redis`를 적용하도록 Metricbeat를 구성한다. `redis` 모듈은 컨테이너 메타데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 컨테이너에서 `info` 및 `keyspace` 메트릭을 수집할 수 있다. ### Metricbeat 배포 + ```shell kubectl create -f metricbeat-kubernetes.yaml ``` + #### 확인 + ```shell kubectl get pods -n kube-system -l k8s-app=metricbeat ``` ### Packetbeat에 대해 + Packetbeat 구성은 Filebeat와 Metricbeat와는 다르다. 컨테이너 레이블과 일치시킬 패턴을 지정하지 않고, 구성은 관련 프로토콜 및 포트 번호를 기반으로 한다. 아래는 포트 번호의 하위 집합이다. {{< note >}} @@ -307,11 +358,13 @@ packetbeat.flows: ``` #### Packetbeat 배포하기 + ```shell kubectl create -f packetbeat-kubernetes.yaml ``` #### 확인하기 + ```shell kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic ``` @@ -328,13 +381,16 @@ Metricbeat에서 Apache 메트릭을 가져올 수 있게 하려면, mod-status ## 디플로이먼트를 확장하고 모니터링중인 새 파드를 확인하기 + 기존 디플로이먼트를 확인한다. + ```shell kubectl get deployments ``` 출력 -```shell + +``` NAME READY UP-TO-DATE AVAILABLE AGE frontend 3/3 3 3 3h27m redis-master 1/1 1 1 3h27m @@ -342,54 +398,56 @@ redis-slave 2/2 2 2 3h27m ``` front의 디플로이먼트를 두 개의 파드로 축소한다. + ```shell kubectl scale --replicas=2 deployment/frontend ``` + 출력 -```shell + +``` deployment.extensions/frontend scaled ``` + frontend의 파드를 최대 3개의 파드로 확장한다. + ```shell kubectl scale --replicas=3 deployment/frontend ``` ## Kibana에서 변화 확인하기 + 스크린 캡처를 확인하여, 표시된 필터를 추가하고 해당 열을 뷰에 추가한다. ScalingReplicaSet 항목이 표시되고, 여기에서 이벤트 목록의 맨 위에 풀링되는 이미지, 마운트된 볼륨, 파드 시작 등을 보여준다. ![Kibana 디스커버리](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png) - - ## {{% heading "cleanup" %}} 디플로이먼트와 서비스를 삭제하면 실행중인 파드도 삭제된다. 한 커맨드로 여러 개의 리소스를 삭제하기 위해 레이블을 이용한다. 1. 다음 커맨드를 실행하여 모든 파드, 디플로이먼트, 서비스를 삭제한다. - ```shell - kubectl delete deployment -l app=redis - kubectl delete service -l app=redis - kubectl delete deployment -l app=guestbook - kubectl delete service -l app=guestbook - kubectl delete -f filebeat-kubernetes.yaml - kubectl delete -f metricbeat-kubernetes.yaml - kubectl delete -f packetbeat-kubernetes.yaml - kubectl delete secret dynamic-logging -n kube-system - ``` + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment -l app=guestbook + kubectl delete service -l app=guestbook + kubectl delete -f filebeat-kubernetes.yaml + kubectl delete -f metricbeat-kubernetes.yaml + kubectl delete -f packetbeat-kubernetes.yaml + kubectl delete secret dynamic-logging -n kube-system + ``` 1. 실행 중인 파드가 없음을 확인하기 위해 파드 목록을 조회한다. - ```shell - kubectl get pods - ``` - - 커맨드의 출력은 다음과 같아야 한다. - - ``` - No resources found. - ``` + ```shell + kubectl get pods + ``` + 출력은 다음과 같아야 한다. + ``` + No resources found. + ``` ## {{% heading "whatsnext" %}} diff --git a/content/ko/includes/task-tutorial-prereqs.md b/content/ko/includes/task-tutorial-prereqs.md index b05dc3ac8c..90aa725d6c 100644 --- a/content/ko/includes/task-tutorial-prereqs.md +++ b/content/ko/includes/task-tutorial-prereqs.md @@ -1,7 +1,7 @@ 쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 만약, 아직 클러스터를 가지고 있지 않다면, -[Minikube](/ko/docs/setup/learning-environment/minikube/)를 사용해서 생성하거나, +[minikube](/ko/docs/tasks/tools/#minikube)를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다. * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) diff --git a/content/pl/_common-resources/images/kub_video_banner_homepage.jpg b/content/pl/_common-resources/images/kub_video_banner_homepage.jpg index 57582e4938..e40d92a503 100644 Binary files a/content/pl/_common-resources/images/kub_video_banner_homepage.jpg and b/content/pl/_common-resources/images/kub_video_banner_homepage.jpg differ diff --git a/content/pl/_index.html b/content/pl/_index.html index 1e759a89e7..1096114700 100644 --- a/content/pl/_index.html +++ b/content/pl/_index.html @@ -2,11 +2,14 @@ title: "Produkcyjny system zarządzania kontenerami" abstract: "Automatyzacja wdrażania, skalowania i zarządzania kontenerami" cid: home +sitemap: + priority: 1.0 + --- {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} -### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach. +[Kubernetes]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}), znany też jako K8s, to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach. Kubernetes grupuje kontenery, które są częścią jednej aplikacji, w logicznie grupy, ułatwiając ich odnajdywanie i zarządzanie nimi. Korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](http://queue.acm.org/detail.cfm?id=2898444) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność. {{% /blocks/feature %}} @@ -26,7 +29,7 @@ Niezależnie, czy prowadzisz tylko testy, czy globalny koncern, dzięki elastycz {{% /blocks/feature %}} {{% blocks/feature image="suitcase" %}} -#### Działa w każdym środowisku +#### K8s działa w każdym środowisku Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z prywatnego centrum danych, infrastruktury hybrydowej lub chmury publicznej. Bez wysiłku możesz przenieść swoje aplikacje tam, gdzie są najbardziej potrzebne. @@ -41,12 +44,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr

- Weź udział w wirtualnym KubeCon EU 17-20.08.2020 + Weź udział w wirtualnym KubeCon NA, 17-20.11.2020



- Weź udział w wirtualnym KubeCon NA w 17-20.11.2020 + Weź udział w wirtualnym KubeCon EU 4–7.05.2021

diff --git a/content/pl/docs/concepts/overview/_index.md b/content/pl/docs/concepts/overview/_index.md index 32ab47ea71..1c0ee2815d 100755 --- a/content/pl/docs/concepts/overview/_index.md +++ b/content/pl/docs/concepts/overview/_index.md @@ -2,4 +2,6 @@ title: "Przegląd" weight: 20 description: Ogólny zarys Kubernetesa i komponentów, z których jest zbudowany. +sitemap: + priority: 0.9 --- diff --git a/content/pl/docs/concepts/overview/components.md b/content/pl/docs/concepts/overview/components.md index ce4ea28ff2..dba2d1e782 100644 --- a/content/pl/docs/concepts/overview/components.md +++ b/content/pl/docs/concepts/overview/components.md @@ -11,7 +11,7 @@ card: --- -W wyniku instalacji Kubernetes otrzymujesz klaster. +W wyniku instalacji Kubernetesa otrzymujesz klaster. {{< glossary_definition term_id="cluster" length="all" prepend="Klaster Kubernetes to">}} @@ -19,7 +19,7 @@ W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, popr Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego różnymi częściami składowymi. -![Składniki Kubernetes](/images/docs/components-of-kubernetes.png) +![Składniki Kubernetes](/images/docs/components-of-kubernetes.svg) diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md index 5761b20c61..cd376dab1d 100644 --- a/content/pl/docs/concepts/overview/kubernetes-api.md +++ b/content/pl/docs/concepts/overview/kubernetes-api.md @@ -1,5 +1,5 @@ --- -title: API Kubernetes +title: API Kubernetesa content_type: concept weight: 30 description: > @@ -18,32 +18,25 @@ API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, _Namespaces_, _ConfigMaps_, _Events_). -Punkt dostępowe _(endpoints)_ API, typy zasobów i przykłady opisane są w [API Reference](/docs/reference/kubernetes-api/). +Większość operacji może zostać wykonana poprzez +interfejs linii komend (CLI) [kubectl](/docs/reference/kubectl/overview/) lub inne +programy, takie jak [kubeadm](/docs/reference/setup-tools/kubeadm/), które używają +API. Możesz też korzystać z API bezpośrednio przez wywołania typu REST. + +Jeśli piszesz aplikację używającą API Kubernetesa, +warto rozważyć użycie jednej z [bibliotek klienckich](/docs/reference/using-api/client-libraries/). -## Zmiany w API - -Jednym z wymagań, które odnoszą się do każdego systemu, który odniósł sukces, jest zdolność do rozwoju i ewolucji w miarę pojawiających się i zmieniających potrzeb. -Dlatego Kubernetes został zaprojektowany tak, aby umożliwić ciągły rozwój i zmiany w API. -Celem projektu Kubernetes jest _zachowanie_ zgodności z istniejącymi klientami i utrzymanie tej zgodności -przez odpowiednio długi czas, pozwalający innym projektom na stopniowe dostosowanie. - -W skrócie, nowe zasoby API i nowe pola dla konkretnych zasobów mogą być dodawane stosunkowo często. -Usunięcie zasobów lub pól wymaga stosowania -[API deprecation policy](/docs/reference/using-api/deprecation-policy/). - -Szczegółowe objaśnienia, jak wygląda zmiana, która zachowuje zgodność i jak zmieniać API, znajdują się w dokumencie -[API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). - ## Specyfikacja OpenAPI {#api-specification} Pełną specyfikację API udokumentowano za pomocą [OpenAPI](https://www.openapis.org/). Serwer API Kubernetes API udostępnia specyfikację OpenAPI poprzez ścieżkę `/openapi/v2`. -Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z: +Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z tabelą: + @@ -71,93 +64,63 @@ Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z: -
Dopuszczalne wartości nagłówka żądania dla zapytań OpenAPI v2
Nagłówekudostępnia application/json
Dozwolone nagłówki żądań dla zapytania OpenAPI v2
-W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API. +W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, +który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze +i opisany w [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md). +Pliki IDL dla każdego ze schematów można znaleźć w pakietach Go, które definiują obiekty API. -## Obsługa wersji API +## Zmiany API + +Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb. +Dlatego Kubernetes został tak zaprojektowany, aby API mogło się zmieniać i rozrastać. +Projekt Kubernetes dąży do tego, aby nie wprowadzać zmian niezgodnych z istniejącymi aplikacjami klienckimi +i utrzymywać zgodność przez wystarczająco długi czas, aby inne projekty zdążyły się dostosować do zmian. + +W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól +jest regulowane przez [API deprecation policy](/docs/reference/using-api/deprecation-policy/). +Definicja zmiany zgodnej (kompatybilnej) oraz metody wprowadzania zmian w API opisano w szczegółach +w [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md). + +## Grupy i wersje API Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub `/apis/rbac.authorization.k8s.io/v1alpha1`. -Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym, +Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach poszczególnych zasobów lub pól, aby być pewnym, że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej. -Schematy serializacji JSON i Protobuf stosują się do tych samych reguł wprowadzania zmian schematów — cały opis poniżej odnosi się do obydwu z nich. +Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy [*grupy API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md), +które mogą być [włączane i wyłączane](/docs/reference/using-api/#enabling-or-disabling). -Należy mieć na uwadze, że wersje API i wersje oprogramowania są powiązane ze sobą w sposób niebezpośredni. Proponowany -[Kubernetes Release Versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) opisuje związki pomiędzy zarządzaniem wersjami API i oprogramowania. +Zasoby API są rozróżniane poprzez przynależność do grupy API, typ zasobu, przestrzeń nazw (_namespace_, +o ile ma zastosowanie) oraz nazwę. Serwer API może obsługiwać +te same dane poprzez różne wersje API i przeprowadzać konwersję między +różnymi wersjami API w sposób niewidoczny dla użytkownika. Wszystkie te różne wersje +reprezentują w rzeczywistości ten sam zasób. Załóżmy przykładowo, że istnieją dwie +wersje `v1` i `v1beta1` tego samego zasobu. Obiekt utworzony przez +wersję `v1beta1` może być odczytany, zaktualizowany i skasowany zarówno przez wersję +`v1beta1`, jak i `v1`. -Różne wersje API oznaczają inną stabilność i poziom wsparcia. Kryteria dla każdego z tych poziomów opisano szczegółowo -w [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). -Podsumowanie zamieszczono poniżej: +Zajrzyj do [API versions reference](/docs/reference/using-api/#api-versioning) +po szczegółowe informacje, jak definiuje się poziomy wersji API. -- Poziom Alfa: - - Nazwa wersji zawiera słowo `alpha` (np. `v1alpha1`). - - Może zawierać błędy. Włączenie tej funkcjonalności może wyeksponować różne błędy. Domyślnie jest wyłączona. - - Wsparcie dla tej funkcjonalności może być zakończone w dowolnej chwili bez uprzedniego powiadomienia. - - W kolejnych wersjach API może zostać zmienione w sposób niezgodny z wersjami wcześniejszymi. - - Rekomendowana do użycia tylko na często przebudowywanych klastrach testowych ze względu na duże ryzyko wystąpienia błędów i brak gwarancji wsparcia w dalszym horyzoncie. -- Poziom Beta: - - Nazwa wersji zawiera słowo `beta` (np. `v2beta3`). - - Oprogramowanie jest dobrze przetestowane. Włączenie tej funkcjonalności uznaje się za bezpieczne. Funkcjonalność domyślnie włączona. - - Wsparcie dla funkcjonalności będzie utrzymywane, choć może zmieniać się w niektórych szczegółach. - - Schemat lub semantyka obiektu może się zmienić w sposób niezgodny z poprzednimi wersjami w następnych wydaniach beta lub stabilnych. Jeśli taka zmiana będzie miała miejsce, - dostarczymy instrukcję migracji do kolejnej wersji. Możemy wymagać skasowania, zmiany i odtworzenia obiektów API. - Proces zmiany może wymagać dodatkowych wstępnych analiz. W czasie wprowadzania zmian mogą wystąpić przerwy w dostępności aplikacji, które z tej funkcjonalności korzystają. - - Rekomendowane tylko dla zastosowań niekrytycznych dla biznesu ze względu na potencjalnie niezgodne zmiany w kolejnych wersjach oprogramowania. - Jeśli masz wiele klastrów, które mogą być aktualizowane niezależnie, można to ograniczenie pominąć. - - **Testuj nasze funkcjonalności w fazie beta i zgłaszaj swoje uwagi! Po wyjściu z fazy beta, możemy nie mieć już możliwości — ze względów praktycznych — wprowadzać w nich żadnych zmian.** -- Poziom Stabilny: - - Nazwa wersji jest w postaci `vX`, gdzie `X` jest liczbą naturalną. - - Stabilne funkcjonalności będą dostępne w wielu kolejnych wersjach oprogramowania. +## Rozbudowa API -## Grupy API +API Kubernetesa można rozbudowywać (rozszerzać) na dwa sposoby: -Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy [*grupy API*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md). -Grupa API jest określona przez ścieżkę API i pole `apiVersion` serializowanego obiektu. - -Obecne w użyciu jest kilka grup API: - -1. Grupa *podstawowa* (*core*), nazywana także *legacy group*, jest dostępna przez ścieżkę REST `/api/v1` i używa `apiVersion: v1`. - -1. Nazwane grupy udostępnione są przez ścieżkę REST `/apis/$GROUP_NAME/$VERSION` i używają `apiVersion: $GROUP_NAME/$VERSION` - (np. `apiVersion: batch/v1`). Pełna lista wpieranych grup API jest dostępna w [Kubernetes API reference](/pl/docs/reference/). - -API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/): - -1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) - jest przewidziana dla użytkowników z minimalnymi wymaganiami CRUD. -1. Użytkownicy, którzy potrzebują pełnej semantyki API Kubernetes, mogą zaimplementować własny apiserver - i użyć [agregatora](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), - aby zintegrować je w sposób niezauważalny dla klientów. - -## Włączanie i wyłączanie grup API - -Określone zasoby i grupy API są włączone domyślnie. Włączanie i wyłączanie odbywa się poprzez ustawienie `--runtime-config` -w kube-apiserver. - -`--runtime-config` przyjmuje wartości oddzielane przecinkami. Przykładowo, aby wyłączyć batch/v1, należy ustawić -`--runtime-config=batch/v1=false`, aby włączyć batch/v2alpha1, należy ustawić `--runtime-config=batch/v2alpha1`. -Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który opisuje konfigurację wykonawczą serwera API. - -{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu kube-apiserver i kube-controller-manager, -aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}} - -## Trwałość - -Kubernetes przechowuje swój stan w postaci serializowanej jako zasoby API zapisywane w -{{< glossary_tooltip term_id="etcd" >}}. +1. [Definicje zasobów własnych](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) + pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane zasoby API. +1. Można także rozszerzać API Kubernetesa implementując + [warstwę agregacji](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). ## {{% heading "whatsnext" %}} -[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje -sposoby, jakimi klaster zarządza dostępem do API. - -Ogólne wytyczne dotyczące API opisano w -[API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions). - -Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/). +- Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych + [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). +- [Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje + sposoby, jakimi klaster zarządza dostępem do API. +- Punkty dostępowe API _(endpoints)_, typy zasobów i przykłady zamieszczono w [API Reference](/docs/reference/kubernetes-api/). diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md index 75321bfbb5..db8ea18b70 100644 --- a/content/pl/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md @@ -7,6 +7,8 @@ weight: 10 card: name: concepts weight: 10 +sitemap: + priority: 0.9 --- @@ -35,7 +37,7 @@ Wirtualizacja pozwala lepiej wykorzystywać zasoby fizycznego serwera i lepiej s Każda maszyna wirtualna jest pełną maszyną zawierającą własny system operacyjny pracujący na zwirtualizowanej warstwie sprzętowej. **Era wdrożeń w kontenerach:** -Kontenery działają w sposób zbliżony do maszyn wirtualnych, ale mają mniejszy stopnień wzajemnej izolacji, współdzieląc ten sam system operacyjny. Kontenery określane są mianem "lekkich". Podobnie, jak maszyna wirtualna, kontener posiada własny system plików, procesor, pamięć, przestrzeń procesów itd. Ponieważ kontenery nie są związane z leżącymi poniżej warstwami infrastruktury, mogą być łatwiej przenoszone pomiędzy chmurami i różnymi dystrybucjami systemu operacyjnego. +Kontenery działają w sposób zbliżony do maszyn wirtualnych, ale mają mniejszy stopnień wzajemnej izolacji, współdzieląc ten sam system operacyjny. Kontenery określane są mianem "lekkich". Podobnie, jak maszyna wirtualna, kontener posiada własny system plików, udział w zasobach procesora, pamięć, przestrzeń procesów itd. Ponieważ kontenery nie są związane z leżącymi poniżej warstwami infrastruktury, mogą być łatwiej przenoszone pomiędzy chmurami i różnymi dystrybucjami systemu operacyjnego. Kontenery zyskały popularność ze względu na swoje zalety, takie jak: @@ -85,10 +87,7 @@ Kubernetes: * Nie zapewnia, ani nie wykorzystuje żadnego ogólnego systemu do zarządzania konfiguracją, utrzymaniem i samo-naprawianiem maszyn. * Co więcej, nie jest zwykłym systemem planowania *(orchestration)*. W rzeczywistości, eliminuje konieczność orkiestracji. Zgodnie z definicją techniczną, orkiestracja to wykonywanie określonego ciągu zadań: najpierw A, potem B i następnie C. Dla kontrastu, Kubernetes składa się z wielu niezależnych, możliwych do złożenia procesów sterujących, których zadaniem jest doprowadzenie stanu faktycznego do stanu oczekiwanego. Nie ma znaczenia, w jaki sposób przechodzi się od A do C. Nie ma konieczności scentralizowanego zarządzania. Dzięki temu otrzymujemy system, który jest potężniejszy, bardziej odporny i niezawodny i dający więcej możliwości rozbudowy. - - ## {{% heading "whatsnext" %}} -* Dowiedz się o [komponentach Kubernetesa](/pl/docs/concepts/overview/components/) -* Jesteś gotowy [zacząć pracę](/pl/docs/setup/)? - +* Dowiedz się o [komponentach Kubernetesa](/pl/docs/concepts/overview/components/) +* Jesteś gotowy [zacząć pracę](/pl/docs/setup/)? diff --git a/content/pl/docs/contribute/_index.md b/content/pl/docs/contribute/_index.md index a6f9356a58..c107ec357d 100644 --- a/content/pl/docs/contribute/_index.md +++ b/content/pl/docs/contribute/_index.md @@ -1,17 +1,24 @@ --- content_type: concept -title: Współtwórz dokumentację Kubernetesa +title: Współtwórz dokumentację K8s linktitle: Weź udział main_menu: true weight: 80 card: name: contribute weight: 10 - title: Weź udział + title: Współtwórz K8s --- +Kubernetes zaprasza do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych! + +{{< note >}} +Aby dowiedzieć się więcej ogólnych informacji o współpracy przy tworzeniu Kubernetesa, zajrzyj +do [contributor documentation](https://www.kubernetes.dev/docs/). +{{< /note >}} + Tym serwisem www opiekuje się [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs). Współtwórcy dokumentacji Kubernetesa: @@ -21,8 +28,6 @@ Współtwórcy dokumentacji Kubernetesa: - Tłumaczą dokumentację - Zarządzają i publikują dokumentację w ramach cyklu wydawniczego Kubernetesa -Zapraszamy do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczonych! - ## Jak zacząć? diff --git a/content/pl/docs/home/_index.md b/content/pl/docs/home/_index.md index 5c8facdbc5..1e2ecfe14b 100644 --- a/content/pl/docs/home/_index.md +++ b/content/pl/docs/home/_index.md @@ -30,7 +30,7 @@ cards: button: "Samouczki" button_path: "/docs/tutorials" - name: setup - title: "Uruchom klaster" + title: "Uruchom klaster K8s" description: "Uruchom klaster Kubernetes dopasowany do Twoich potrzeb i możliwości." button: "Uruchom Kubernetesa" button_path: "/docs/setup" @@ -55,7 +55,7 @@ cards: button: Weź udział button_path: /docs/contribute - name: release-notes - title: Informacje o wydaniu + title: Informacje o wydaniu K8s description: Jeśli instalujesz lub aktualizujesz Kubernetesa, zajrzyj do informacji o najnowszym wydaniu. - name: about title: O dokumentacji diff --git a/content/pl/docs/home/supported-doc-versions.md b/content/pl/docs/home/supported-doc-versions.md index 19e08be721..0ad302706a 100644 --- a/content/pl/docs/home/supported-doc-versions.md +++ b/content/pl/docs/home/supported-doc-versions.md @@ -1,25 +1,12 @@ --- -title: Wspierane wersje dokumentacji Kubernetesa -content_type: concept +title: Dostępne wersje dokumentacji +content_type: custom +layout: supported-versions card: name: about weight: 10 - title: Wspierane wersje dokumentacji + title: Dostępne wersje dokumentacji + --- - - Ten serwis zawiera dokumentację do bieżącej i czterech poprzednich wersji Kubernetesa. - - - - - -## Bieżąca wersja - -Bieżąca wersja to -[{{< param "version" >}}](/). - -## Poprzednie wersje - -{{< versions-other >}} diff --git a/content/pl/docs/search.md b/content/pl/docs/search.md deleted file mode 100644 index 9ae06bfa7d..0000000000 --- a/content/pl/docs/search.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -layout: search -title: Wyniki wyszukiwania ---- - diff --git a/content/pl/docs/tutorials/hello-minikube.md b/content/pl/docs/tutorials/hello-minikube.md index a56396843c..2c68bc3b5f 100644 --- a/content/pl/docs/tutorials/hello-minikube.md +++ b/content/pl/docs/tutorials/hello-minikube.md @@ -16,40 +16,35 @@ card: Ten samouczek pokaże, jak uruchomić przykładową aplikację -na Kubernetes przy użyciu [Minikube](/docs/setup/learning-environment/minikube) oraz Katacoda. +na Kubernetesie przy użyciu minikube oraz Katacoda. Katacoda to darmowe środowisko Kubernetes dostępne bezpośrednio z przeglądarki web. {{< note >}} -Możesz też skorzystać z tego samouczka, jeśli już zainstalowałeś [Minikube lokalnie](/docs/tasks/tools/install-minikube/). +Możesz też skorzystać z tego samouczka, jeśli już zainstalowałeś minikube. +Odwiedź stronę [minikube start](https://minikube.sigs.k8s.io/docs/start/), aby dowiedzieć się, jak go zainstalować. {{< /note >}} - - ## {{% heading "objectives" %}} - -* Skonfiguruj przykładową aplikację do uruchomienia w Minikube. +* Skonfiguruj przykładową aplikację do uruchomienia w minikube. * Uruchom aplikację. * Przejrzyj jej logi. - - ## {{% heading "prerequisites" %}} - W tym samouczku wykorzystamy obraz kontenera, który korzysta z NGINX, aby wyświetlić z powrotem wszystkie przychodzące zapytania. - - -## Stwórz klaster Minikube +## Stwórz klaster minikube 1. Kliknij w **Launch Terminal** {{< kat-button >}} - {{< note >}}Jeśli masz Minikube zainstalowane lokalnie, uruchom `minikube start`.{{< /note >}} + {{< note >}} + Jeśli masz minikube zainstalowane lokalnie, uruchom `minikube start`. + {{< /note >}} 2. Otwórz panel Kubernetes w przeglądarce: @@ -135,6 +130,9 @@ jako [*Serwis*](/docs/concepts/services-networking/service/) Kubernetes. Opcja `--type=LoadBalancer` wskazuje, że chcesz udostępnić swój Serwis na zewnątrz klastra. + Aplikacja, która jest umieszczona w obrazie kontenera `k8s.gcr.io/echoserver`, nasłuchuje jedynie na porcie TCP 8080. Jeśli użyłeś + `kubectl expose` do wystawienia innego portu, aplikacje klienckie mogą nie móc się podłączyć do tamtego innego portu. + 2. Sprawdź Serwis, który właśnie utworzyłeś: ``` @@ -151,7 +149,7 @@ jako [*Serwis*](/docs/concepts/services-networking/service/) Kubernetes. U dostawców usług chmurowych, którzy obsługują *load balancers*, zostanie przydzielony zewnętrzny adres IP na potrzeby serwisu. - W Minikube, typ `LoadBalancer` udostępnia serwis poprzez polecenie + W minikube, typ `LoadBalancer` udostępnia serwis poprzez polecenie `minikube service`. 3. Uruchom poniższe polecenie: @@ -168,7 +166,7 @@ jako [*Serwis*](/docs/concepts/services-networking/service/) Kubernetes. ## Włącz dodatki -Minikube ma zestaw wbudowanych {{< glossary_tooltip text="dodatków" term_id="addons" >}}, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes. +Narzędzie minikube dysponuje zestawem wbudowanych {{< glossary_tooltip text="dodatków" term_id="addons" >}}, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes. 1. Lista aktualnie obsługiwanych dodatków: @@ -272,13 +270,8 @@ minikube stop minikube delete ``` - - ## {{% heading "whatsnext" %}} - * Dowiedz się więcej o [obiektach typu Deployment](/docs/concepts/workloads/controllers/deployment/). * Dowiedz się więcej o [instalowaniu aplikacji](/docs/tasks/run-application/run-stateless-application-deployment/). * Dowiedz się więcej o [obiektach typu Serwis](/docs/concepts/services-networking/service/). - - diff --git a/content/ru/_index.html b/content/ru/_index.html index e86c2bf206..aaf9f136f5 100644 --- a/content/ru/_index.html +++ b/content/ru/_index.html @@ -42,6 +42,11 @@ Kubernetes — это проект с открытым исходным кодо

Посетите KubeCon NA онлайн, 17-20 ноября 2020 +
+
+
+
+ Посетите KubeCon EU онлайн, 4 – 7 мая 2021
diff --git a/content/zh/docs/concepts/cluster-administration/networking.md b/content/zh/docs/concepts/cluster-administration/networking.md index 06ff565cff..a51d74143b 100644 --- a/content/zh/docs/concepts/cluster-administration/networking.md +++ b/content/zh/docs/concepts/cluster-administration/networking.md @@ -350,6 +350,18 @@ network complexity required to deploy Kubernetes at scale within AWS. 复杂性（每个 VPC 限制为50-100个条目）。 简而言之，cni-ipvlan-vpc-k8s 大大降低了在 AWS 中大规模部署 Kubernetes 所需的网络复杂性。 + +### Coil + +[Coil](https://github.com/cybozu-go/coil) 是一个为易于集成、提供灵活的出站流量网络而设计的 CNI 插件。 +与裸机相比，Coil 的额外操作开销低，并允许针对外部网络的出站流量任意定义 NAT 网关。 + -Deployment 会创建一个 ReplicaSet 以确保所需数量的 Pod 始终可用，并指定替换 Pod 的策略 -（例如 [RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment))， -除了一些显式的[`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) -场景之外，几乎总是优先考虑直接创建 Pod。 -[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的。 + +Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用，也可以指定替换 Pod 的策略（例如 +[RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。 +除了一些显式的 [`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。 `Secret` 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 SSH 密钥。 将这些信息放在 `secret` 中比放在 {{< glossary_tooltip term_id="pod" >}} 的定义或者 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 中来说更加安全和灵活。 参阅 [Secret 设计文档](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) 获取更多详细信息。 + +Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 +这样的信息可能会被放在 Pod 规约中或者镜像中。 +用户可以创建 Secret，同时系统也创建了一些 Secret。 + -## Secret 概览 - -Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 -这样的信息可能会被放在 Pod 规约中或者镜像中。 -用户可以创建 Secret，同时系统也创建了一些 Secret。 - - +## Secret 概览 {#overview-of-secrets} + 要使用 Secret，Pod 需要引用 Secret。 Pod 可以用三种方式之一来使用 Secret： @@ -69,603 +70,624 @@ Pod 可以用三种方式之一来使用 Secret： - 由 [kubelet 在为 Pod 拉取镜像时使用](#using-imagepullsecrets) -### 内置 Secret - -#### 服务账号使用 API 凭证自动创建和附加 Secret - -Kubernetes 自动创建包含访问 API 凭据的 Secret，并自动修改你的 Pod 以使用此类型的 Secret。 - - -如果需要，可以禁用或覆盖自动创建和使用 API 凭据。 -但是，如果您需要的只是安全地访问 API 服务器，我们推荐这样的工作流程。 - -参阅[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) -文档了解关于服务账号如何工作的更多信息。 - - -### 创建您自己的 Secret - -#### 使用 `kubectl` 创建 Secret - -Secret 中可以包含 Pod 访问数据库时需要的用户凭证信息。 -例如，某个数据库连接字符串可能包含用户名和密码。 -你可以将用户名和密码保存在本地机器的 `./username.txt` 和 `./password.txt` 文件里。 - -```shell -# 创建本例中要使用的文件 -echo -n 'admin' > ./username.txt -echo -n '1f2d1e2e67df' > ./password.txt -``` - - - -`kubectl create secret` 命令将这些文件打包到一个 Secret 中并在 API server 中创建了一个对象。 Secret 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +在为创建 Secret 编写配置文件时，你可以设置 `data` 与/或 `stringData` 字段。 +`data` 和 `stringData` 字段都是可选的。`data` 字段中所有键值都必须是 base64 +编码的字符串。如果不希望执行这种 base64 字符串的转换操作，你可以选择设置 +`stringData` 字段，其中可以使用任何字符串作为其取值。 + + +## Secret 的类型 {#secret-types} + +在创建 Secret 对象时，你可以使用 +[`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +资源的 `type` 字段，或者与其等价的 `kubectl` 命令行参数（如果有的话）为其设置类型。 +Secret 的类型用来帮助编写程序处理 Secret 数据。 + +Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。 +针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。 + + +| 内置类型 | 用法 | +|--------------|-------| +| `Opaque` | 用户定义的任意数据 | +| `kubernetes.io/service-account-token` | 服务账号令牌 | +| `kubernetes.io/dockercfg` | `~/.dockercfg` 文件的序列化形式 | +| `kubernetes.io/dockerconfigjson` | `~/.docker/config.json` 文件的序列化形式 | +| `kubernetes.io/basic-auth` | 用于基本身份认证的凭据 | +| `kubernetes.io/ssh-auth` | 用于 SSH 身份认证的凭据 | +| `kubernetes.io/tls` | 用于 TLS 客户端或者服务器端的数据 | +| `bootstrap.kubernetes.io/token` | 启动引导令牌数据 | + + +通过为 Secret 对象的 `type` 字段设置一个非空的字符串值，你也可以定义并使用自己 +Secret 类型。如果 `type` 值为空字符串，则被视为 `Opaque` 类型。 +Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用内置类型之一， +则你必须满足为该类型所定义的所有要求。 + + +### Opaque Secret + +当 Secret 配置文件中未作显式设定时，默认的 Secret 类型是 `Opaque`。 +当你使用 `kubectl` 来创建一个 Secret 时，你会使用 `generic` 子命令来标明 +要创建的是一个 `Opaque` 类型 Secret。 +例如，下面的命令会创建一个空的 `Opaque` 类型 Secret 对象： ```shell -kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt -``` - -输出类似于： - -``` -secret "db-user-pass" created +kubectl create secret generic empty-secret +kubectl get secret empty-secret ``` -默认的键名是文件名。你也可以使用 `[--from-file=[key=]source]` 参数来设置键名。 +输出类似于 -```shell -kubectl create secret generic db-user-pass \ - --from-file=username=./username.txt \ - --from-file=password=./password.txt +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s ``` -{{< note >}} -特殊字符（例如 `$`、`\`、`*`、`=` 和 `!`）可能会被你的 -[Shell](https://en.wikipedia.org/wiki/Shell_(computing)) 解析，因此需要转义。 -在大多数 Shell 中，对密码进行转义的最简单方式是使用单引号（`'`）将其扩起来。 -例如，如果您的实际密码是 `S!B\*d$zDsb=` ，则应通过以下方式执行命令： - -``` -kubectl create secret generic dev-db-secret \ - --from-literal=username=devuser \ - --from-literal=password='S!B\*d$zDsb=' -``` - -您无需对文件中保存（`--from-file`）的密码中的特殊字符执行转义操作。 -{{< /note >}} - - -您可以这样检查刚创建的 Secret： - -```shell -kubectl get secrets -``` - -其输出类似于： - -``` -NAME TYPE DATA AGE -db-user-pass Opaque 2 51s -``` +`DATA` 列显示 Secret 中保存的数据条目个数。 +在这个例子种，`0` 意味着我们刚刚创建了一个空的 Secret。 -你可以查看 Secret 的描述： +### 服务账号令牌 Secret {#service-account-token-secrets} -```shell -kubectl describe secrets/db-user-pass -``` +类型为 `kubernetes.io/service-account-token` 的 Secret 用来存放标识某 +服务账号的令牌。使用这种 Secret 类型时，你需要确保对象的注解 +`kubernetes.io/service-account-name` 被设置为某个已有的服务账号名称。 +某个 Kubernetes 控制器会填写 Secret 的其它字段，例如 +`kubernetes.io/service-account.uid` 注解以及 `data` 字段中的 `token` +键值，使之包含实际的令牌内容。 -其输出类似于： - -``` -Name: db-user-pass -Namespace: default -Labels: -Annotations: - -Type: Opaque - -Data -==== -password.txt: 12 bytes -username.txt: 5 bytes -``` +下面的配置实例声明了一个服务账号令牌 Secret： -{{< note >}} -默认情况下，`kubectl get` 和 `kubectl describe` 避免显示密码的内容。 -这是为了防止机密被意外地暴露给旁观者或存储在终端日志中。 -{{< /note >}} - - -请参阅[解码 Secret](#decoding-secret) 了解如何查看 Secret 的内容。 - - -#### 手动创建 Secret - -您也可以先以 JSON 或 YAML 格式文件创建一个 Secret，然后创建该对象。 -Secret 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) -包含两个映射：`data` 和 `stringData`。 -`data` 字段用于存储使用 base64 编码的任意数据。 -提供 `stringData` 字段是为了方便，允许您用未编码的字符串提供机密数据。 - - -例如，要使用 `data` 字段将两个字符串存储在 Secret 中，请按如下所示将它们转换为 base64： - -```shell -echo -n 'admin' | base64 -``` - - -输出类似于： - -``` -YWRtaW4= -``` - -```shell -echo -n '1f2d1e2e67df' | base64 -``` - - -输出类似于： - -``` -MWYyZDFlMmU2N2Rm -``` - - - -现在可以像这样写一个 Secret 对象： - ```yaml apiVersion: v1 kind: Secret metadata: - name: mysecret -type: Opaque + name: secret-sa-sample + annotations: + kubernetes.io/service-account.name: "sa-name" +type: kubernetes.io/service-account-token data: - username: YWRtaW4= - password: MWYyZDFlMmU2N2Rm + # You can include additional key value pairs as you do with Opaque Secrets + extra: YmFyCg== ``` - - -使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 创建 Secret 对象： - -```shell -kubectl apply -f ./secret.yaml -``` - - -输出类似于： - -``` -secret "mysecret" created -``` - - -在某些情况下，你可能希望改用 stringData 字段。 -此字段允许您将非 base64 编码的字符串直接放入 Secret 中， -并且在创建或更新 Secret 时将为您编码该字符串。 - -下面的一个实践示例提供了一个参考。 -你正在部署使用 Secret 存储配置文件的应用程序，并希望在部署过程中填齐配置文件的部分内容。 - -如果您的应用程序使用以下配置文件： - ```yaml -apiUrl: "https://my.api.com/api/v1" -username: "user" -password: "password" +apiVersion: v1 +kind: Secret +metadata: + name: secret-sa-sample + annotations: + kubernetes.io/service-account.name: "sa-name" +type: kubernetes.io/service-account-token +data: + # 你可以像 Opaque Secret 一样在这里添加额外的键/值偶对 + extra: YmFyCg== ``` - + +Kubernetes 在创建 Pod 时会自动创建一个服务账号 Secret 并自动修改你的 Pod +以使用该 Secret。该服务账号令牌 Secret 中包含了访问 Kubernetes API +所需要的凭据。 + +如果需要，可以禁止或者重载这种自动创建并使用 API 凭据的操作。 +不过，如果你仅仅是希望能够安全地访问 API 服务器，这是建议的工作方式。 + + +参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) +文档了解服务账号的工作原理。你也可以查看 +[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档，了解 +从 Pod 中引用服务账号。 + + +### Docker 配置 Secret {#docker-config-secrets} + +你可以使用下面两种 `type` 值之一来创建 Secret，用以存放访问 Docker 仓库 +来下载镜像的凭据。 + +- `kubernetes.io/dockercfg` +- `kubernetes.io/dockerconfigjson` + + +`kubernetes.io/dockercfg` 是一种保留类型，用来存放 `~/.dockercfg` 文件的 +序列化形式。该文件是配置 Docker 命令行的一种老旧形式。 +使用此 Secret 类型时，你需要确保 Secret 的 `data` 字段中包含名为 +`.dockercfg` 的主键，其对应键值是用 base64 编码的某 `~/.dockercfg` +文件的内容。 + + +类型 `kubernetes.io/dockerconfigjson` 被设计用来保存 JSON 数据的序列化形式， +该 JSON 也遵从 `~/.docker/config.json` 文件的格式规则，而后者是 +`~/.dockercfg` 的新版本格式。 +使用此 Secret 类型时，Secret 对象的 `data` 字段必须包含 `.dockerconfigjson` +键，其键值为 base64 编码的字符串包含 `~/.docker/config.json` 文件的内容。 + +下面是一个 `kubernetes.io/dockercfg` 类型 Secret 的示例： ```yaml apiVersion: v1 kind: Secret metadata: - name: mysecret -type: Opaque + name: secret-dockercfg +type: kubernetes.io/dockercfg +data: + .dockercfg: | + "" +``` + +{{< note >}} + +如果你不希望执行 base64 编码转换，可以使用 `stringData` 字段代替。 +{{< /note >}} + + +当你使用清单文件来创建这两类 Secret 时，API 服务器会检查 `data` 字段中是否 +存在所期望的主键，并且验证其中所提供的键值是否是合法的 JSON 数据。 +不过，API 服务器不会检查 JSON 数据本身是否是一个合法的 Docker 配置文件内容。 + +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-username=tiger \ + --docker-password=pass113 \ + --docker-email=tiger@acme.com +``` + + +上面的命令创建一个类型为 `kubernetes.io/dockerconfigjson` 的 Secret。 +如果你对 `data` 字段中的 `.dockerconfigjson` 内容进行转储，你会得到下面的 +JSON 内容，而这一内容是一个合法的 Docker 配置文件。 + +```json +{ + "auths": { + "https://index.docker.io/v1/": { + "username": "tiger", + "password": "pass113", + "email": "tiger@acme.com", + "auth": "dGlnZXI6cGFzczExMw==" + } + } +} +``` + + +### 基本身份认证 Secret {#basic-authentication-secret} + +`kubernetes.io/basic-auth` 类型用来存放用于基本身份认证所需的凭据信息。 +使用这种 Secret 类型时，Secret 的 `data` 字段必须包含以下两个键： + +- `username`: 用于身份认证的用户名； +- `password`: 用于身份认证的密码或令牌。 + + +以上两个键的键值都是 base64 编码的字符串。 +当然你也可以在创建 Secret 时使用 `stringData` 字段来提供明文形式的内容。 +下面的 YAML 是基本身份认证 Secret 的一个示例清单： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-basic-auth +type: kubernetes.io/basic-auth stringData: - config.yaml: |- - apiUrl: "https://my.api.com/api/v1" - username: {{username}} - password: {{password}} + username: admin + password: t0p-Secret ``` +提供基本身份认证类型的 Secret 仅仅是出于用户方便性考虑。 +你也可以使用 `Opaque` 类型来保存用于基本身份认证的凭据。 +不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 +API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。 -然后，您的部署工具可以在执行 `kubectl apply` 之前替换模板的 `{{username}}` 和 `{{password}}` 变量。 -stringData 是只写的便利字段。检索 Secrets 时永远不会被输出。例如，如果您运行以下命令： + +### SSH 身份认证 Secret {#ssh-authentication-secrets} + +Kubernetes 所提供的内置类型 `kubernetes.io/ssh-auth` 用来存放 SSH 身份认证中 +所需要的凭据。使用这种 Secret 类型时，你就必须在其 `data` （或 `stringData`） +字段中提供一个 `ssh-privatekey` 键值对，作为要使用的 SSH 凭据。 + +下面的 YAML 是一个 SSH 身份认证 Secret 的配置示例： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-ssh-auth +type: kubernetes.io/ssh-auth +data: + # 此例中的实际数据被截断 + ssh-privatekey: | + MIIEpQIBAAKCAQEAulqb/Y ... +``` + + +提供 SSH 身份认证类型的 Secret 仅仅是出于用户方便性考虑。 +你也可以使用 `Opaque` 类型来保存用于 SSH 身份认证的凭据。 +不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 +API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。 + + +### TLS Secret + +Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型，用来存放证书 +及其相关密钥（通常用在 TLS 场合）。 +此类数据主要提供给 Ingress 资源，用以终结 TLS 链接，不过也可以用于其他 +资源或者负载。当使用此类型的 Secret 时，Secret 配置中的 `data` （或 +`stringData`）字段必须包含 `tls.key` 和 `tls.crt` 主键，尽管 API 服务器 +实际上并不会对每个键的取值作进一步的合法性检查。 + +下面的 YAML 包含一个 TLS Secret 的配置示例： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-tls +type: kubernetes.io/tls +data: + # 此例中的数据被截断 + tls.crt: | + MIIC2DCCAcCgAwIBAgIBATANBgkqh ... + tls.key: | + MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... +``` + + +提供 TLS 类型的 Secret 仅仅是出于用户方便性考虑。 +你也可以使用 `Opaque` 类型来保存用于 TLS 服务器与/或客户端的凭据。 +不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 +API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。 + +当使用 `kubectl` 来创建 TLS Secret 时，你可以像下面的例子一样使用 `tls` +子命令： ```shell -kubectl get secret mysecret -o yaml +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file ``` -输出类似于： +这里的公钥/私钥对都必须事先已存在。用于 `--cert` 的公钥证书必须是 .PEM 编码的 +（Base64 编码的 DER 格式），且与 `--key` 所给定的私钥匹配。 +私钥必须是通常所说的 PEM 私钥格式，且未加密。对这两个文件而言，PEM 格式数据 +的第一行和最后一行（例如，证书所对应的 `--------BEGIN CERTIFICATE-----` 和 +`-------END CERTIFICATE----`）都不会包含在其中。 + +### 启动引导令牌 Secret {#bootstrap-token-secrets} + +通过将 Secret 的 `type` 设置为 `bootstrap.kubernetes.io/token` 可以创建 +启动引导令牌类型的 Secret。这种类型的 Secret 被设计用来支持节点的启动引导过程。 +其中包含用来为周知的 ConfigMap 签名的令牌。 + + +启动引导令牌 Secret 通常创建于 `kube-system` 名字空间内，并以 +`bootstrap-token-<令牌 ID>` 的形式命名；其中 `<令牌 ID>` 是一个由 6 个字符组成 +的字符串，用作令牌的标识。 + +以 Kubernetes 清单文件的形式，某启动引导令牌 Secret 可能看起来像下面这样： ```yaml apiVersion: v1 kind: Secret metadata: - creationTimestamp: 2018-11-15T20:40:59Z - name: mysecret - namespace: default - resourceVersion: "7225" - uid: c280ad2e-e916-11e8-98f2-025000000001 -type: Opaque + name: bootstrap-token-5emitj + namespace: kube-system +type: bootstrap.kubernetes.io/token data: - config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 + auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4= + expiration: MjAyMC0wOS0xM1QwNDozOToxMFo= + token-id: NWVtaXRq + token-secret: a3E0Z2lodnN6emduMXAwcg== + usage-bootstrap-authentication: dHJ1ZQ== + usage-bootstrap-signing: dHJ1ZQ== ``` +A bootstrap type has the following keys specified under `data`: -如果在 data 和 stringData 中都指定了某一字段，则使用 stringData 中的值。 -例如，以下是 Secret 定义： +- `token_id`: A random 6 character string as the token identifier. Required. +- `token-secret`: A random 16 character string as the actual token secret. Required. +- `description1`: A human-readable string that describes what the token is + used for. Optional. +- `expiration`: An absolute UTC time using RFC3339 specifying when the token + should be expired. Optional. +- `usage-bootstrap-`: A boolean flag indicating additional usage for + the bootstrap token. +- `auth-extra-groups`: A comma-separated list of group names that will be + authenticated as in addition to the `system:bootstrappers` group. +--> +启动引导令牌类型的 Secret 会在 `data` 字段中包含如下主键： + +- `token_id`：由 6 个随机字符组成的字符串，作为令牌的标识符。必需。 +- `token-secret`：由 16 个随机字符组成的字符串，包含实际的令牌机密。必需。 +- `description`：供用户阅读的字符串，描述令牌的用途。可选。 +- `expiration`：一个使用 RFC3339 来编码的 UTC 绝对时间，给出令牌要过期的时间。可选。 +- `usage-bootstrap-`：布尔类型的标志，用来标明启动引导令牌的其他用途。 +- `auth-extra-groups`：用逗号分隔的组名列表，身份认证时除被认证为 + `system:bootstrappers` 组之外，还会被添加到所列的用户组中。 + + -secret 中的生成结果： +上面的 YAML 文件可能看起来令人费解，因为其中的数值均为 base64 编码的字符串。 +实际上，你完全可以使用下面的 YAML 来创建一个一模一样的 Secret： ```yaml apiVersion: v1 kind: Secret metadata: - creationTimestamp: 2018-11-15T20:46:46Z - name: mysecret - namespace: default - resourceVersion: "7579" - uid: 91460ecb-e917-11e8-98f2-025000000001 -type: Opaque -data: - username: YWRtaW5pc3RyYXRvcg== + # 注意 Secret 的命名方式 + name: bootstrap-token-5emitj + # 启动引导令牌 Secret 通常位于 kube-system 名字空间 + namespace: kube-system +type: bootstrap.kubernetes.io/token +stringData: + auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token" + expiration: "2020-09-13T04:39:10Z" + # 此令牌 ID 被用于生成 Secret 名称 + token-id: "5emitj" + token-secret: "kq4gihvszzgn1p0r" + # 此令牌还可用于 authentication （身份认证） + usage-bootstrap-authentication: "true" + # 且可用于 signing （证书签名） + usage-bootstrap-signing: "true" ``` -其中的 `YWRtaW5pc3RyYXRvcg==` 解码后即是 `administrator`。 +## 创建 Secret {#creating-a-secret} + +有几种不同的方式来创建 Secret： + +- [使用 `kubectl` 命令创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [使用配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [使用 kustomize 来创建 Secret](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -data 和 stringData 的键必须由字母数字字符 '-', '\_' 或者 '.' 组成。 +## 编辑 Secret {#editing-a-secret} -{{< note >}} -Secret 数据在序列化为 JSON 和 YAML 时，其值被编码为 base64 字符串。 -换行符在这些字符串中是非法的，因此必须省略。 -在 Darwin/macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。 -相反，Linux用户 *应该* 在 `base64` 命令中添加选项 `-w 0` ， -或者，如果 `-w` 选项不可用的情况下，执行 `base64 | tr -d '\n'`。 -{{< /note >}} - - -#### 从生成器创建 Secret - -Kubectl 从 1.14 版本开始支持[使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/)。 -Kustomize 提供资源生成器创建 Secret 和 ConfigMaps。 -Kustomize 生成器要在当前目录内的 `kustomization.yaml` 中指定。 -生成 Secret 之后，使用 `kubectl apply` 在 API 服务器上创建对象。 - - -#### 从文件生成 Secret {#generating-a-secret-from-files} - -你可以通过定义基于文件 `./username.txt` 和 `./password.txt` 的 -`secretGenerator` 来生成一个 Secret。 - -```shell -cat <./kustomization.yaml -secretGenerator: -- name: db-user-pass - files: - - username.txt - - password.txt -EOF -``` - - -应用包含 `kustomization.yaml` 目录以创建 Secret 对象。 - -```shell -kubectl apply -k . -``` - - -输出类似于： - -``` -secret/db-user-pass-96mffmfh4k created -``` - - -您可以检查 Secret 是否创建成功： - -```shell -kubectl get secrets -``` - - -输出类似于： - -``` -NAME TYPE DATA AGE -db-user-pass-96mffmfh4k Opaque 2 51s - -$ kubectl describe secrets/db-user-pass-96mffmfh4k -Name: db-user-pass -Namespace: default -Labels: -Annotations: - -Type: Opaque - -Data -==== -password.txt: 12 bytes -username.txt: 5 bytes -``` - - -#### 基于字符串值来创建 Secret {#generating-a-secret-from-string-literals} - -你可以通过定义使用字符串值 `username=admin` 和 `password=secret` -的 `secretGenerator` 来创建 Secret。 - -```shell -cat <./kustomization.yaml -secretGenerator: -- name: db-user-pass - literals: - - username=admin - - password=secret -EOF -``` - -应用包含 `kustomization.yaml` 目录以创建 Secret 对象。 - -```shell -kubectl apply -k . -``` - - -输出类似于： - -``` -secret/db-user-pass-dddghtt9b5 created -``` - - - -{{< note >}} -Secret 被创建时，Secret 的名称是通过为 Secret 数据计算哈希值得到一个字符串， -并将该字符串添加到名称之后得到的。这会确保数据被修改后，会有新的 Secret -对象被生成。 -{{< /note >}} - - - -#### 解码 Secret {#decoding-secret} - -可以使用 `kubectl get secret` 命令获取 Secret。例如，获取在上一节中创建的 secret： - -```shell -kubectl get secret mysecret -o yaml -``` - - -输出类似于： - -```yaml -apiVersion: v1 -kind: Secret -metadata: - creationTimestamp: 2016-01-22T18:41:56Z - name: mysecret - namespace: default - resourceVersion: "164619" - uid: cfee02d6-c137-11e5-8d73-42010af00002 -type: Opaque -data: - username: YWRtaW4= - password: MWYyZDFlMmU2N2Rm -``` - - - -解码 `password` 字段： - -```shell -echo 'MWYyZDFlMmU2N2Rm' | base64 --decode -``` - - -输出类似于： - -``` -1f2d1e2e67df -``` - - -#### 编辑 Secret - -可以通过下面的命令可以编辑一个已经存在的 secret 。 +你可以通过下面的命令编辑现有的 Secret： ```shell kubectl edit secrets mysecret ``` -这将打开默认配置的编辑器，并允许更新 `data` 字段中的 base64 编码的 Secret 值： +这一命令会打开默认的编辑器，允许你更新 `data` 字段中包含的 +base64 编码的 Secret 值： -``` +```yaml # Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. @@ -696,8 +718,7 @@ system, without being directly exposed to the pod. For example, they can hold credentials that other parts of the system should use to interact with external systems on your behalf. --> - -## 使用 Secret +## 使用 Secret {#using-secrets} Secret 可以作为数据卷被挂载，或作为{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}} 暴露出来以供 Pod 中的容器使用。它们也可以被系统的其他部分使用，而不直接暴露在 Pod 内。 @@ -1048,71 +1069,18 @@ Secret updates. 不会收到 Secret 更新。 {{< /note >}} -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} - - -Kubernetes 的 alpha 特性 _不可变的 Secret 和 ConfigMap_ 提供了一种可选配置， -可以设置各个 Secret 和 ConfigMap 为不可变的。 -对于大量使用 Secret 的集群（至少有成千上万各不相同的 Secret 供 Pod 挂载）， -禁止变更它们的数据有下列好处： - - -- 防止意外（或非预期的）更新导致应用程序中断 -- 通过将 Secret 标记为不可变来关闭 kube-apiserver 对其的监视，从而显著降低 - kube-apiserver 的负载，提升集群性能。 - - -使用这个特性需要启用 `ImmutableEmphemeralVolumes` -[特性开关](/zh/docs/reference/command-line-tools-reference/feature-gates/) -并将 Secret 或 ConfigMap 的 `immutable` 字段设置为 `true`. 例如： - -```yaml -apiVersion: v1 -kind: Secret -metadata: - ... -data: - ... -immutable: true -``` - - -{{< note >}} -一旦一个 Secret 或 ConfigMap 被标记为不可变，撤销此操作或者更改 `data` 字段的内容都是 _不_ 可能的。 -只能删除并重新创建这个 Secret。现有的 Pod 将维持对已删除 Secret 的挂载点 - 建议重新创建这些 Pod。 -{{< /note >}} - - #### 以环境变量的形式使用 Secrets {#using-secrets-as-environment-variables} 将 Secret 作为 Pod 中的{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}}使用： @@ -1149,10 +1117,10 @@ spec: ``` #### 使用来自环境变量的 Secret 值 {#consuming-secret-values-from-environment-variables} @@ -1164,7 +1132,9 @@ This is the result of commands executed inside the container from the example ab echo $SECRET_USERNAME ``` - + 输出类似于： ``` @@ -1175,13 +1145,74 @@ admin echo $SECRET_PASSWORD ``` - + 输出类似于： ``` 1f2d1e2e67df ``` + +## 不可更改的 Secret {#secret-immutable} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + + +Kubernetes 的 alpha 特性 _不可变的 Secret 和 ConfigMap_ 提供了一种可选配置， +可以设置各个 Secret 和 ConfigMap 为不可变的。 +对于大量使用 Secret 的集群（至少有成千上万各不相同的 Secret 供 Pod 挂载）， +禁止变更它们的数据有下列好处： + +- 防止意外（或非预期的）更新导致应用程序中断 +- 通过将 Secret 标记为不可变来关闭 kube-apiserver 对其的监视，从而显著降低 + kube-apiserver 的负载，提升集群性能。 + + +这个特性通过 `ImmutableEmphemeralVolumes` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +来控制，从 v1.19 开始默认启用。 +你可以通过将 Secret 的 `immutable` 字段设置为 `true` 创建不可更改的 Secret。 +例如： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} + +一旦一个 Secret 或 ConfigMap 被标记为不可更改，撤销此操作或者更改 `data` 字段的内容都是 _不_ 可能的。 +只能删除并重新创建这个 Secret。现有的 Pod 将维持对已删除 Secret 的挂载点 - 建议重新创建这些 Pod。 +{{< /note >}} + +- 学习如何[使用 `kubectl` 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- 学习如何[使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- 学习如何[使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md index 88f189287e..93f4a350ca 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/labels.md +++ b/content/zh/docs/concepts/overview/working-with-objects/labels.md @@ -221,17 +221,17 @@ partition ``` -第一个示例选择了所有键等于 `environment` 并且值等于 `production` 或者 `qa` 的资源。 -第二个示例选择了所有键等于 `tier` 并且值不等于 `frontend` 或者 `backend` 的资源，以及所有没有 `tier` 键标签的资源。 -第三个示例选择了所有包含了有 `partition` 标签的资源；没有校验它的值。 -第四个示例选择了所有没有 `partition` 标签的资源；没有校验它的值。 +* 第一个示例选择了所有键等于 `environment` 并且值等于 `production` 或者 `qa` 的资源。 +* 第二个示例选择了所有键等于 `tier` 并且值不等于 `frontend` 或者 `backend` 的资源，以及所有没有 `tier` 键标签的资源。 +* 第三个示例选择了所有包含了有 `partition` 标签的资源；没有校验它的值。 +* 第四个示例选择了所有没有 `partition` 标签的资源；没有校验它的值。 类似地，逗号分隔符充当 _与_ 运算符。因此，使用 `partition` 键（无论为何值）和 `environment` 不同于 `qa` 来过滤资源可以使用 `partition, environment notin（qa)` 来实现。 diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md index 9a50a835c8..2318f59e6f 100644 --- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -368,7 +368,7 @@ and an example `preferredDuringSchedulingIgnoredDuringExecution` anti-affinity w --> 与节点亲和一样，当前有两种类型的 pod 亲和与反亲和，即 `requiredDuringSchedulingIgnoredDuringExecution` 和 -`preferredDuringSchedulingIgnoredDuringExecution`，分表表示“硬性”与“软性”要求。请参阅前面节点亲和部分中的描述。`requiredDuringSchedulingIgnoredDuringExecution` 亲和的一个示例是“将服务 A 和服务 B 的 pod 放置在同一区域，因为它们之间进行大量交流”，而 `preferredDuringSchedulingIgnoredDuringExecution` 反亲和的示例将是“将此服务的 pod 跨区域分布”（硬性要求是说不通的，因为你可能拥有的 pod 数多于区域数）。 +`preferredDuringSchedulingIgnoredDuringExecution`，分别表示“硬性”与“软性”要求。请参阅前面节点亲和部分中的描述。`requiredDuringSchedulingIgnoredDuringExecution` 亲和的一个示例是“将服务 A 和服务 B 的 pod 放置在同一区域，因为它们之间进行大量交流”，而 `preferredDuringSchedulingIgnoredDuringExecution` 反亲和的示例将是“将此服务的 pod 跨区域分布”（硬性要求是说不通的，因为你可能拥有的 pod 数多于区域数）。 -给节点 `node1` 增加一个污点，它的键名是 `key`，键值是 `value`，效果是 `NoSchedule`。 +给节点 `node1` 增加一个污点，它的键名是 `key1`，键值是 `value1`，效果是 `NoSchedule`。 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 `node1` 这个节点。 若要移除上述命令所添加的污点，你可以执行： @@ -81,15 +81,15 @@ to schedule onto `node1`: ```yaml tolerations: -- key: "key" +- key: "key1" operator: "Equal" - value: "value" + value: "value1" effect: "NoSchedule" ``` ```yaml tolerations: -- key: "key" +- key: "key1" operator: "Exists" effect: "NoSchedule" ``` @@ -123,7 +123,7 @@ There are two special cases: An empty `key` with operator `Exists` matches all keys, values and effects which means this will tolerate everything. -An empty `effect` matches all effects with key `key`. +An empty `effect` matches all effects with key `key1`. --> {{< note >}} 存在两种特殊情况： diff --git a/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index 6db722eed5..4229689422 100644 --- a/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -2,52 +2,62 @@ title: 使用 HostAliases 向 Pod /etc/hosts 文件添加条目 content_type: concept weight: 60 +min-kubernetes-server-version: 1.7 --- -{{< toc >}} + +当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目， +可以在 Pod 级别覆盖对主机名的解析。你可以通过 PodSpec 的 HostAliases +字段来添加这些自定义条目。 -当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，可以在 Pod 级别覆盖对主机名的解析。在 1.7 版本，用户可以通过 PodSpec 的 HostAliases 字段来添加这些自定义的条目。 - -建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。 - +建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且 +可以在 Pod 创建/重启过程中被重写。 ## 默认 hosts 文件内容 -让我们从一个 Nginx Pod 开始，给该 Pod 分配一个 IP： +让我们从一个 Nginx Pod 开始，该 Pod 被分配一个 IP： ```shell kubectl run nginx --image nginx --generator=run-pod/v1 ``` -```shell +``` pod/nginx created ``` -检查Pod IP： +检查 Pod IP： ```shell kubectl get pods --output=wide ``` -```shell +``` NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 13s 10.200.0.4 worker0 ``` @@ -55,14 +65,13 @@ nginx 1/1 Running 0 13s 10.200.0.4 worker0 - 主机文件的内容如下所示： ```shell kubectl exec nginx -- cat /etc/hosts ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -77,63 +86,63 @@ fe00::2 ip6-allrouters By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like `localhost` and its own hostname. --> -默认，hosts 文件只包含 ipv4 和 ipv6 的样板内容，像 `localhost` 和主机名称。 +默认情况下，hosts 文件只包含 IPv4 和 IPv6 的样板内容，像 `localhost` 和主机名称。 +## 通过 HostAliases 增加额外条目 -## 通过 HostAliases 增加额外的条目 - -除了默认的样板内容，我们可以向 hosts 文件添加额外的条目，将 `foo.local`、 `bar.local` 解析为`127.0.0.1`， -将 `foo.remote`、 `bar.remote` 解析为 `10.1.2.3`，我们可以在 `.spec.hostAliases` 下为 Pod 添加 HostAliases。 +除了默认的样板内容，我们可以向 hosts 文件添加额外的条目。 +例如，要将 `foo.local`、`bar.local` 解析为 `127.0.0.1`， +将 `foo.remote`、 `bar.remote` 解析为 `10.1.2.3`，我们可以在 +`.spec.hostAliases` 下为 Pod 配置 HostAliases。 {{< codenew file="service/networking/hostaliases-pod.yaml" >}} - -可以使用以下命令启动此Pod： +你可以使用以下命令用此配置启动 Pod： ```shell kubectl apply -f hostaliases-pod.yaml ``` -```shell +``` pod/hostaliases-pod created ``` -检查Pod IP 和状态： +检查 Pod 详情，查看其 IPv4 地址和状态： ```shell kubectl get pod --output=wide ``` -```shell -NAME READY STATUS RESTARTS AGE IP NODE -hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0 +``` +NAME READY STATUS RESTARTS AGE IP NODE +hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0 ``` - hosts 文件的内容看起来类似如下这样： ```shell kubectl logs hostaliases-pod ``` -```none +``` # Kubernetes-managed hosts file. 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback @@ -151,30 +160,31 @@ fe00::2 ip6-allrouters - 在最下面额外添加了一些条目。 +## 为什么 kubelet 管理 hosts 文件？ -## 为什么 Kubelet 管理 hosts文件？ +kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) Pod +中每个容器的 hosts 文件，避免 Docker 在容器已经启动之后去 +[修改](https://github.com/moby/moby/issues/17190) 该文件。 -kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) Pod 中每个容器的 hosts 文件，避免 Docker 在容器已经启动之后去 [修改](https://github.com/moby/moby/issues/17190) 该文件。 - -因为该文件是托管性质的文件，无论容器重启或 Pod 重新调度，用户修改该 hosts 文件的任何内容，都会在 Kubelet 重新安装后被覆盖。因此，不建议修改该文件的内容。 +{{< caution >}} + +请避免手工更改容器内的 hosts 文件内容。 +如果你对 hosts 文件做了手工修改，这些修改都会在容器退出时丢失。 +{{< /caution >}} diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md index 25bebe4d01..06d1744eb2 100644 --- a/content/zh/docs/concepts/services-networking/connect-applications-service.md +++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md @@ -205,9 +205,8 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the -[CoreDNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). +[CoreDNS cluster addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). --> - ## 访问 Service Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者开箱即用，而后者则需要[CoreDNS集群插件] diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md index 48453424da..fc23f799ae 100644 --- a/content/zh/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md @@ -42,8 +42,7 @@ considered implementation details and are subject to change without warning. For more up-to-date specification, see [Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md). --> - -## 怎样获取 DNS 名字? +## 哪些对象会有 DNS 名字? {#what-things-get-dns-names} 在集群中定义的每个 Service（包括 DNS 服务器自身）都会被指派一个 DNS 名称。 默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的名字空间和集群默认域。 @@ -74,7 +73,6 @@ Services, this resolves to the set of IPs of the pods selected by the Service. Clients are expected to consume the set or else use standard round-robin selection from the set. --> - ### 服务 {#services} #### A/AAAA 记录 @@ -117,17 +115,35 @@ Kubernetes 会为命名端口创建 SRV 记录，这些端口是普通服务或 ### A/AAAA 记录 -经由 Deployment 或者 DaemonSet 所创建的所有 Pods 都会有如下 DNS -解析项与之对应： +一般而言，Pod 会对应如下 DNS 名字解析： -`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` +`pod-ip-address.my-namespace.pod.cluster-domain.example` + +例如，对于一个位于 `default` 名字空间，IP 地址为 172.17.0.3 的 Pod， +如果集群的域名为 `cluster.local`，则 Pod 会对应 DNS 名称： + +`172-17-0-3.default.pod.cluster.local`. + +Deployment 或通过 Service 暴露出来的 DaemonSet 所创建的 Pod 会有如下 DNS +解析名称可用： + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`. - ### Pod 的 hostname 和 subdomain 字段 当前，创建 Pod 时其主机名取自 Pod 的 `metadata.name` 值。 @@ -254,6 +269,51 @@ record unless `publishNotReadyAddresses=True` is set on the Service. 才会有与之对应的记录。 {{< /note >}} + +### Pod 的 setHostnameAsFQDN 字段 {#pod-sethostnameasfqdn-field} + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + + +**前置条件**：`SetHostnameAsFQDN` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +必须在 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} +上启用。 + +当你在 Pod 规约中设置了 `setHostnameAsFQDN: true` 时，kubelet 会将 Pod +的全限定域名（FQDN）作为该 Pod 的主机名记录到 Pod 所在名字空间。 +在这种情况下，`hostname` 和 `hostname --fqdn` 都会返回 Pod 的全限定域名。 + +{{< note >}} + +在 Linux 中，内核的主机名字段（`struct utsname` 的 `nodename` 字段）限定 +最多 64 个字符。 + +如果 Pod 启用这一特性，而其 FQDN 超出 64 字符，Pod 的启动会失败。 +Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerCreating`）， +并产生错误事件，例如 +"Failed to construct FQDN from pod hostname and cluster domain, FQDN +`long-FQDN` is too long (64 characters is the max, 70 characters requested)." +（无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64 +字符，请求字符数为 70）。 +对于这种场景而言，改善用户体验的一种方式是创建一个 +[准入 Webhook 控制器](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)， +在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。 +{{< /note >}} + +### Pod 的 DNS 策略 {#pod-s-dns-policy} -- "`Default`": Pod 从运行所在的节点继承名称解析配置。 - 参考[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 获取更多信息。 -- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 “www.kubernetes.io”） +DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 的 DNS 策略。 +这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置： + +- "`Default`": Pod 从运行所在的节点继承名称解析配置。参考 + [相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) + 获取更多信息。 +- "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"） 都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) 了解在这些场景中如何处理 DNS 查询的信息。 @@ -293,10 +358,10 @@ following pod-specific DNS policies. These policies are specified in the {{< note >}} -"`Default`" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "`ClusterFirst`"。 +"Default" 不是默认的 DNS 策略。如果未明确指定 `dnsPolicy`，则使用 "ClusterFirst"。 {{< /note >}} -公共路由和非公共路由的 IPv6 地址块的使用是可以的。提供底层 -{{< glossary_tooltip text="CNI" term_id="cni" >}} 的提供程序可以实现这种传输。 +可以使用可公共路由和非可公共路由的 IPv6 地址块，前提是下层的 +{{< glossary_tooltip text="CNI" term_id="cni" >}} 提供程序可以实现这种传输。 如果你拥有使用非公共路由 IPv6 地址的 Pod，并且希望该 Pod 到达集群外目的 （比如，公共网络），你必须为出口流量和任何响应消息设置 IP 伪装。 -[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 可以感知双栈， +[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 可以感知双栈， 所以你可以在双栈集群中使用 ip-masq-agent 来进行 IP 伪装。 - * Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (`--cluster-cidr`) +* Kubenet 强制 IPv4，IPv6 的 IPs 位置报告 (`--cluster-cidr`) ## {{% heading "whatsnext" %}} diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md index 4071ea6189..6b31e610d6 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md @@ -25,7 +25,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i 为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。 -基于此页面，您可选择最适合您的集群的 ingress 控制器实现。 +基于此页面，你可选择最适合你的集群的 ingress 控制器实现。 Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) 和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 @@ -42,7 +42,7 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress controller with [community](https://www.getambassador.io/docs) or [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/). -* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). +* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](https://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager). * [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) enables ingress using the [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/). * [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller provided and supported by VMware. @@ -95,7 +95,8 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i * [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller). * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy -* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller + +* [Traefik](https://github.com/traefik/traefik) is a fully featured ingress controller ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial support by [Containous](https://containo.us/services). --> @@ -107,9 +108,9 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i [用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) 提供支持和维护。 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。 -* [Traefik](https://github.com/containous/traefik) 是一个全功能的 ingress 控制器 +* [Traefik](https://github.com/traefik/traefik) 是一个全功能的 Ingress 控制器。 （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket）， - 并且它也有来自 [Containous](https://containo.us/services) 的商业支持。 + 并且它也有来自 [Traefik Labs](https://traefik.io) 的商业支持。 {{< note >}} -确保您查看了 ingress 控制器的文档，以了解选择它的注意事项。 +确保你查看了 ingress 控制器的文档，以了解选择它的注意事项。 {{< /note >}} ## {{% heading "whatsnext" %}} diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md index 6a5cb35739..e3dd00dede 100644 --- a/content/zh/docs/concepts/services-networking/ingress.md +++ b/content/zh/docs/concepts/services-networking/ingress.md @@ -708,6 +708,18 @@ Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `https-example 你需要确保创建的 TLS Secret 创建自包含 `sslexample.foo.com` 的公用名称（CN）的证书。 这里的公共名称也被称为全限定域名（FQDN）。 +{{< note >}} + +注意，默认规则上无法使用 TLS，因为需要为所有可能的子域名发放证书。 +因此，`tls` 节区的 `hosts` 的取值需要域 `rules` 节区的 `host` +完全匹配。 +{{< /note >}} + {{< codenew file="service/networking/tls-example-ingress.yaml" >}} -使用 Kubernetes，您无需修改应用程序即可使用不熟悉的服务发现机制。 +使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。 @@ -60,12 +60,12 @@ Enter _Services_. Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 是有生命周期的。 它们可以被创建，而且销毁之后不会再启动。 -如果您使用 {{< glossary_tooltip text="Deployment" term_id="deployment">}} -来运行您的应用程序，则它可以动态创建和销毁 Pod。 +如果你使用 {{< glossary_tooltip text="Deployment" term_id="deployment">}} +来运行你的应用程序，则它可以动态创建和销毁 Pod。 每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。 -这导致了一个问题： 如果一组 Pod（称为“后端”）为群集内的其他 Pod（称为“前端”）提供功能， +这导致了一个问题： 如果一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能， 那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用工作量的后端部分？ 进入 _Services_。 @@ -79,13 +79,13 @@ Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 是有生命周期 In Kubernetes, a Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). The set of Pods targeted by a Service is usually determined -by a {{< glossary_tooltip text="selector" term_id="selector" >}} -(see [below](#services-without-selectors) for why you might want a Service -_without_ a selector). +by a {{< glossary_tooltip text="selector" term_id="selector" >}}. +To learn about other ways to define Service endpoints, +see [Services _without_ selectors](#services-without-selectors). --> Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过 {{< glossary_tooltip text="选择算符" term_id="selector" >}} -（查看[下面](#services-without-selectors)了解，为什么你可能需要没有 selector 的 Service）实现的。 +要了解如何定义服务端点，请参阅[不带选择算符的服务](#services-without-selectors)。 ### 云原生服务发现 -如果您想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询 +如果你想要在应用程序中使用 Kubernetes API 进行服务发现，则可以查询 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} 的 Endpoints 资源，只要服务中的 Pod 集合发生更改，Endpoints 就会被更新。 @@ -126,6 +126,8 @@ balancer in between your application and the backend Pods. A Service in Kubernetes is a REST object, similar to a Pod. Like all of the REST objects, you can `POST` a Service definition to the API server to create a new instance. +The name of a Service object must be a valid +[DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names). For example, suppose you have a set of Pods that each listen on TCP port 9376 and carry a label `app=MyApp`: @@ -135,6 +137,8 @@ and carry a label `app=MyApp`: Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 像所有的 REST 对象一样，Service 定义可以基于 `POST` 方式，请求 API server 创建新的实例。 +Service 对象的名称必须是合法的 +[DNS 标签名称](/zh/docs/concepts/overview/working-with-objects/names#dns-label-names)。 例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 `app=MyApp` 标签。 @@ -200,9 +204,9 @@ Each port definition can have the same `protocol`, or a different one. Pod 中的端口定义是有名字的，你可以在服务的 `targetPort` 属性中引用这些名称。 即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。 这为部署和发展服务提供了很大的灵活性。 -例如，您可以更改Pods在新版本的后端软件中公开的端口号，而不会破坏客户端。 +例如，你可以更改 Pods 在新版本的后端软件中公开的端口号，而不会破坏客户端。 -服务的默认协议是TCP。 您还可以使用任何其他[受支持的协议](#protocol-support)。 +服务的默认协议是TCP。 你还可以使用任何其他[受支持的协议](#protocol-support)。 由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。 每个端口定义可以具有相同的 `protocol`，也可以具有不同的协议。 @@ -231,7 +235,7 @@ For example: * 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。 * 希望服务指向另一个 {{< glossary_tooltip term_id="namespace" >}} 中或其它集群中的服务。 - * 您正在将工作负载迁移到 Kubernetes。 在评估该方法时，您仅在 Kubernetes 中运行一部分后端。 + * 你正在将工作负载迁移到 Kubernetes。 在评估该方法时，你仅在 Kubernetes 中运行一部分后端。 在任何这些场景中，都能够定义没有选择算符的 Service。 实例: @@ -254,7 +258,7 @@ created automatically. You can manually map the Service to the network address a where it's running, by adding an Endpoint object manually: --> 由于此服务没有选择算符，因此 *不会* 自动创建相应的 Endpoint 对象。 -您可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口： +你可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口： ```yaml apiVersion: v1 @@ -267,6 +271,12 @@ subsets: ports: - port: 9376 ``` + +Endpoints 对象的名称必须是合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -### Endpoint 切片 +### EndpointSlice -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。 尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。 @@ -323,26 +333,21 @@ Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的 届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。 Endpoint 切片提供了附加的属性和功能，这些属性和功能在 -[Endpoint 切片](/zh/docs/concepts/services-networking/endpoint-slices/)中有详细描述。 +[EndpointSlices](/zh/docs/concepts/services-networking/endpoint-slices/) +中有详细描述。 -### 应用程序协议 +### 应用程序协议 {#application-protocol} -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -`appProtocol` 字段提供了一种为每个 Service 端口指定应用程序协议的方式。 - -作为一个 alpha 特性，该字段默认未启用。要使用该字段，请启用 `ServiceAppProtocol` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +`appProtocol` 字段提供了一种为每个 Service 端口指定应用协议的方式。 +此字段的取值会被映射到对应的 Endpoints 和 EndpointSlices 资源。 - -## VIP 和 Service 代理 {#virtual-ips-and-service-proxies} +## 虚拟 IP 和 Service 代理 {#virtual-ips-and-service-proxies} 在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。 `kube-proxy` 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 @@ -376,33 +380,17 @@ There are a few reasons for using proxying for Services: on the DNS records could impose a high load on DNS that then becomes difficult to manage. --> - ### 为什么不使用 DNS 轮询？ -时不时会有人问到，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？ -例如，是否可以配置具有多个A值（或IPv6为AAAA）的DNS记录，并依靠轮询名称解析？ +时不时会有人问到为什么 Kubernetes 依赖代理将入站流量转发到后端。那其他方法呢？ +例如，是否可以配置具有多个 A 值（或 IPv6 为 AAAA）的 DNS 记录，并依靠轮询名称解析？ 使用服务代理有以下几个原因： - * DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。 - * 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。 - * 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给 DNS 带来高负载，从而使管理变得困难。 - - - -### 版本兼容性 - -从 Kubernetes v1.0 开始，您已经可以使用 [用户空间代理模式](#proxy-mode-userspace)。 -Kubernetes v1.1 添加了 iptables 模式代理，在 Kubernetes v1.2 中，kube-proxy 的 iptables 模式成为默认设置。 -Kubernetes v1.8 添加了 ipvs 代理模式。 +* DNS 实现的历史由来已久，它不遵守记录 TTL，并且在名称查找结果到期后对其进行缓存。 +* 有些应用程序仅执行一次 DNS 查找，并无限期地缓存结果。 +* 即使应用和库进行了适当的重新解析，DNS 记录上的 TTL 值低或为零也可能会给 + DNS 带来高负载，从而使管理变得困难。 - 在 `ipvs` 模式下，kube-proxy监视Kubernetes服务和端点，调用 `netlink` 接口相应地创建 IPVS 规则， 并定期将 IPVS 规则与 Kubernetes 服务和端点同步。 该控制循环可确保IPVS 状态与所需状态匹配。访问服务时，IPVS 将流量定向到后端Pod之一。 @@ -572,7 +559,7 @@ You can also set the maximum session sticky time by setting 则可以通过将 `service.spec.sessionAffinity` 设置为 "ClientIP" （默认值是 "None"），来基于客户端的 IP 地址选择会话关联。 -您还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` +你还可以通过适当设置 `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` 来设置最大会话停留时间。 （默认值为 10800 秒，即 3 小时）。 @@ -585,10 +572,10 @@ When using multiple ports for a Service, you must give all of your ports names so that these are unambiguous. For example: --> -## 多端口 Service +## 多端口 Service {#multi-port-services} -对于某些服务，您需要公开多个端口。 -Kubernetes 允许您在 Service 对象上配置多个端口定义。 +对于某些服务，你需要公开多个端口。 +Kubernetes 允许你在 Service 对象上配置多个端口定义。 为服务使用多个端口时，必须提供所有端口名称，以使它们无歧义。 例如： @@ -639,7 +626,6 @@ The IP address that you choose must be a valid IPv4 or IPv6 address from within If you try to create a Service with an invalid clusterIP address value, the API server will return a 422 HTTP status code to indicate that there's a problem. --> - ## 选择自己的 IP 地址 在 `Service` 创建的请求中，可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。 @@ -673,7 +659,7 @@ For example, the Service `"redis-master"` which exposes TCP port 6379 and has be allocated cluster IP address 10.0.0.11, produces the following environment variables: --> -### 环境变量 +### 环境变量 {#environment-variables} 当 Pod 运行在 `Node` 上，kubelet 会为每个活跃的 Service 添加一组环境变量。 它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量 @@ -704,11 +690,11 @@ If you only use DNS to discover the cluster IP for a Service, you don't need to worry about this ordering issue. --> {{< note >}} -当您具有需要访问服务的Pod时，并且您正在使用环境变量方法将端口和群集 IP 发布到客户端 +当你具有需要访问服务的 Pod 时，并且你正在使用环境变量方法将端口和集群 IP 发布到客户端 Pod 时，必须在客户端 Pod 出现 *之前* 创建服务。 否则，这些客户端 Pod 将不会设定其环境变量。 -如果仅使用 DNS 查找服务的群集 IP，则无需担心此设定问题。 +如果仅使用 DNS 查找服务的集群 IP，则无需担心此设定问题。 {{< /note >}} ### DNS @@ -721,7 +707,14 @@ A cluster-aware DNS server, such as CoreDNS, watches the Kubernetes API for new Services and creates a set of DNS records for each one. If DNS has been enabled throughout your cluster then all Pods should automatically be able to resolve Services by their DNS name. +--> +你可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/) +为 Kubernetes 集群设置 DNS 服务。 +支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 +如果在整个集群中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。 + + +例如，如果你在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务， +则控制平面和 DNS 服务共同为 `"my-service.my-ns"` 创建 DNS 记录。 +`"my-ns"` 命名空间中的 Pod 应该能够通过简单地对 `my-service` 进行名称查找来找到它 +（`"my-service.my-ns"` 也可以工作）。 +其他命名空间中的 Pod 必须将名称限定为 `my-service.my-ns`。 +这些名称将解析为为服务分配的集群 IP。 + + -您可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/) -为 Kubernetes 集群设置 DNS 服务。 - -支持群集的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 -如果在整个群集中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。 - -例如，如果您在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务， -则控制平面和DNS服务共同为 `"my-service.my-ns"` 创建 DNS 记录。 -`"my-ns"` 命名空间中的 Pod 应该能够通过简单地对 `my-service` 进行名称查找来找到它 -（`"my-service.my-ns"` 也可以工作）。 - -其他命名空间中的Pod必须将名称限定为 `my-service.my-ns`。这些名称将解析为为服务分配的群集 IP。 - Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 如果 `"my-service.my-ns"` 服务具有名为 `"http"`　的端口，且协议设置为 TCP， 则可以对 `_http._tcp.my-service.my-ns` 执行 DNS SRV 查询查询以发现该端口号, @@ -762,9 +751,9 @@ Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 更多关于 `ExternalName` 信息可以查看 [DNS Pod 和 Service](/zh/docs/concepts/services-networking/dns-pod-service/)。 + +## 无头服务（Headless Services） {#headless-services} + 有时不需要或不想要负载均衡，以及单独的 Service IP。 遇到这种情况，可以通过指定 Cluster IP（`spec.clusterIP`）的值为 `"None"` 来创建 `Headless` Service。 -您可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。 +你可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes +的实现捆绑在一起。 对这无头 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们， 而且平台也不会为它们进行负载均衡和路由。 @@ -794,8 +786,7 @@ For headless Services that define selectors, the endpoints controller creates `Endpoints` records in the API, and modifies the DNS configuration to return records (addresses) that point directly to the `Pods` backing the Service. --> - -### 带选择算符的服务 +### 带选择算符的服务 {#with-selectors} 对定义了选择算符的无头服务，Endpoint 控制器在 API 中创建了 Endpoints 记录， 并且修改 DNS 配置返回 A 记录（地址），通过这个地址直接到达 Service 的后端 Pod 上。 @@ -807,18 +798,17 @@ For headless Services that do not define selectors, the endpoints controller doe not create `Endpoints` records. However, the DNS system looks for and configures either: - * CNAME records for [`ExternalName`](#externalname)-type Services. - * A records for any `Endpoints` that share a name with the Service, for all - other types. +* CNAME records for [`ExternalName`](#externalname)-type Services. +* A records for any `Endpoints` that share a name with the Service, for all + other types. --> - -### 无选择算符的服务 +### 无选择算符的服务 {#without-selectors} 对没有定义选择算符的无头服务，Endpoint 控制器不会创建 `Endpoints` 记录。 然而 DNS 系统会查找和配置，无论是： - * `ExternalName` 类型 Service 的 CNAME 记录 - * 记录：与 Service 共享一个名称的任何 `Endpoints`，以及所有其它类型 +* 对于 [`ExternalName`](#external-name) 类型的服务，查找其 CNAME 记录 +* 对所有其他类型的服务，查找与 Service 名称相同的任何 `Endpoints` 的记录 -## 发布服务 —— 服务类型 {#publishing-services-service-types} +## 发布服务（服务类型) {#publishing-services-service-types} -对一些应用（如前端）的某些部分，可能希望通过外部 Kubernetes 集群外部 IP 地址暴露 Service。 +对一些应用的某些部分（如前端），可能希望将其暴露给 Kubernetes 集群外部 +的 IP 地址。 -Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认是 `ClusterIP` 类型。 +Kubernetes `ServiceTypes` 允许指定你所需要的 Service 类型，默认是 `ClusterIP`。 `Type` 的取值以及行为如下： - * `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 `ServiceType`。 - * [`NodePort`](#nodeport)：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。 - `NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。 - 通过请求 `:`，可以从集群的外部访问一个 `NodePort` 服务。 - * [`LoadBalancer`](#loadbalancer)：使用云提供商的负载均衡器，可以向外部暴露服务。 - 外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。 - * [`ExternalName`](#externalname)：通过返回 `CNAME` 和它的值，可以将服务映射到 `externalName` - 字段的内容（例如， `foo.bar.example.com`）。 - 没有任何类型代理被创建。 + +* `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 + 这也是默认的 `ServiceType`。 +* [`NodePort`](#nodeport)：通过每个节点上的 IP 和静态端口（`NodePort`）暴露服务。 + `NodePort` 服务会路由到自动创建的 `ClusterIP` 服务。 + 通过请求 `<节点 IP>:<节点端口>`，你可以从集群的外部访问一个 `NodePort` 服务。 +* [`LoadBalancer`](#loadbalancer)：使用云提供商的负载均衡器向外部暴露服务。 + 外部负载均衡器可以将流量路由到自动创建的 `NodePort` 服务和 `ClusterIP` 服务上。 +* [`ExternalName`](#externalname)：通过返回 `CNAME` 和对应值，可以将服务映射到 + `externalName` 字段的内容（例如，`foo.bar.example.com`）。 + 无需创建任何类型代理。 - {{< note >}} - 您需要 CoreDNS 1.7 或更高版本才能使用 `ExternalName` 类型。 - {{< /note >}} + {{< note >}} + 你需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 `ExternalName` 类型。 + {{< /note >}} -您也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。 -Ingress 不是服务类型，但它充当集群的入口点。 + +你也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。 +Ingress 不是一种服务类型，但它充当集群的入口点。 它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。 ### NodePort 类型 {#nodeport} -如果将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在 `--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。 -每个节点将那个端口（每个节点上的相同端口号）代理到您的服务中。 -您的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。 +如果你将 `type` 字段设置为 `NodePort`，则 Kubernetes 控制平面将在 +`--service-node-port-range` 标志指定的范围内分配端口（默认值：30000-32767）。 +每个节点将那个端口（每个节点上的相同端口号）代理到你的服务中。 +你的服务在其 `.spec.ports[*].nodePort` 字段中要求分配的端口。 -如果您想指定特定的 IP 代理端口，则可以将 kube-proxy 中的 `--nodeport-addresses` +如果你想指定特定的 IP 代理端口，则可以将 kube-proxy 中的 `--nodeport-addresses` 标志设置为特定的 IP 块。从 Kubernetes v1.10 开始支持此功能。 该标志采用逗号分隔的 IP 块列表（例如，`10.0.0.0/8`、`192.0.2.0/25`）来指定 @@ -912,13 +905,16 @@ This means that you need to take care about possible port collisions yourself. You also have to use a valid port number, one that's inside the range configured for NodePort use. --> -例如，如果您使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy，则 kube-proxy 仅选择 NodePort Services 的环回接口。 +例如，如果你使用 `--nodeport-addresses=127.0.0.0/8` 标志启动 kube-proxy， +则 kube-proxy 仅选择 NodePort Services 的本地回路接口。 `--nodeport-addresses` 的默认值是一个空列表。 这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口。 （这也与早期的 Kubernetes 版本兼容）。 -如果需要特定的端口号，则可以在 `nodePort` 字段中指定一个值。控制平面将为您分配该端口或向API报告事务失败。 -这意味着您需要自己注意可能发生的端口冲突。您还必须使用有效的端口号，该端口号在配置用于NodePort的范围内。 +如果需要特定的端口号，你可以在 `nodePort` 字段中指定一个值。 +控制平面将为你分配该端口或报告 API 事务失败。 +这意味着你需要自己注意可能发生的端口冲突。 +你还必须使用有效的端口号，该端口号在配置用于 NodePort 的范围内。 -使用 NodePort 可以让您自由设置自己的负载平衡解决方案，配置 Kubernetes 不完全支持的环境， +使用 NodePort 可以让你自由设置自己的负载均衡解决方案，配置 Kubernetes 不完全支持的环境， 甚至直接暴露一个或多个节点的 IP。 -需要注意的是，Service 能够通过 `:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。 +需要注意的是，Service 能够通过 `:spec.ports[*].nodePort` 和 +`spec.clusterIp:spec.ports[*].port` 而对外可见。 例如： @@ -998,24 +995,34 @@ status: +来自外部负载均衡器的流量将直接重定向到后端 Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。 + +对于 LoadBalancer 类型的服务，当所定义的端口不止一个时，所有端口都必须 +使用相同的协议，并且其协议必须是 `TCP`、`UDP` 和 `SCTP` 之一。 + + -来自外部负载均衡器的流量将直接重定向到后端 Pod 上，不过实际它们是如何工作的，这要依赖于云提供商。 - +某些云提供商允许设置 `loadBalancerIP`。 在这些情况下，将根据用户设置的 `loadBalancerIP` 来创建负载均衡器。 -某些云提供商允许设置 `loadBalancerIP`。如果没有设置 `loadBalancerIP`，将会给负载均衡器指派一个临时 IP。 -如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的 `loadBalancerIP` 值将会被忽略掉。 +如果没有设置 `loadBalancerIP` 字段，将会给负载均衡器指派一个临时 IP。 +如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的 +`loadBalancerIP` 值将会被忽略掉。 {{< note >}} -如果您使用的是 SCTP，请参阅下面有关 `LoadBalancer` 服务类型的 +如果你使用的是 SCTP，请参阅下面有关 `LoadBalancer` 服务类型的 [注意事项](#caveat-sctp-loadbalancer-service-type)。 {{< /note >}} @@ -1028,13 +1035,16 @@ For example, `MC_myResourceGroup_myAKSCluster_eastus`. Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357). --> {{< note >}} -在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。 -此公共IP地址资源应与群集中其他自动创建的资源位于同一资源组中。 例如，`MC_myResourceGroup_myAKSCluster_eastus`。 +在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP`，则 +首先需要创建静态类型的公共 IP 地址资源。 +此公共 IP 地址资源应与集群中其他自动创建的资源位于同一资源组中。 +例如，`MC_myResourceGroup_myAKSCluster_eastus`。 -将分配的IP地址指定为 loadBalancerIP。 确保您已更新云提供程序配置文件中的 securityGroupName。 +将分配的 IP 地址设置为 loadBalancerIP。确保你已更新云提供程序配置文件中的 +securityGroupName。 有关对 `CreatingLoadBalancerFailed` 权限问题进行故障排除的信息， -请参阅 [与Azure Kubernetes服务（AKS）负载平衡器一起使用静态IP地址](https://docs.microsoft.com/en-us/azure/aks/static-ip) -或[通过高级网络在AKS群集上创建LoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。 +请参阅 [与 Azure Kubernetes服务（AKS）负载平衡器一起使用静态 IP 地址](https://docs.microsoft.com/en-us/azure/aks/static-ip) +或[在 AKS 集群上使用高级联网时出现 CreatingLoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。 {{< /note >}} -#### 内部负载均衡器 +#### 内部负载均衡器 {#internal-load-balancer} 在混合环境中，有时有必要在同一(虚拟)网络地址块内路由来自服务的流量。 -在水平分割 DNS 环境中，您需要两个服务才能将内部和外部流量都路由到您的端点（Endpoints）。 -您可以通过向服务添加以下注释之一来实现此目的。 -要添加的注释取决于您使用的云服务提供商。 +在水平分割 DNS 环境中，你需要两个服务才能将内部和外部流量都路由到你的端点（Endpoints）。 +你可以通过向服务添加以下注解之一来实现此目的。 +要添加的注解取决于你使用的云服务提供商。 {{< tabs name="service_tabs" >}} {{% tab name="Default" %}} @@ -1072,14 +1082,10 @@ metadata: cloud.google.com/load-balancer-type: "Internal" [...] ``` - -将 `cloud.google.com/load-balancer-type: "internal"` 节点用于版本1.7.0至1.7.3的主服务器。 -有关更多信息，请参见[文档](https://cloud.google.com/kubernetes-engine/docs/internal-load-balancing)。 + {{% /tab %}} {{% tab name="AWS" %}} + ```yaml [...] metadata: @@ -1088,8 +1094,10 @@ metadata: service.beta.kubernetes.io/aws-load-balancer-internal: "true" [...] ``` + {{% /tab %}} {{% tab name="Azure" %}} + ```yaml [...] metadata: @@ -1098,8 +1106,10 @@ metadata: service.beta.kubernetes.io/azure-load-balancer-internal: "true" [...] ``` + {{% /tab %}} {{% tab name="IBM Cloud" %}} + ```yaml [...] metadata: @@ -1108,8 +1118,10 @@ metadata: service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" [...] ``` + {{% /tab %}} {{% tab name="OpenStack" %}} + ```yaml [...] metadata: @@ -1118,8 +1130,10 @@ metadata: service.beta.kubernetes.io/openstack-internal-load-balancer: "true" [...] ``` + {{% /tab %}} {{% tab name="Baidu Cloud" %}} + ```yaml [...] metadata: @@ -1128,8 +1142,10 @@ metadata: service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true" [...] ``` + {{% /tab %}} {{% tab name="Tencent Cloud" %}} + ```yaml [...] metadata: @@ -1137,8 +1153,10 @@ metadata: service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx [...] ``` + {{% /tab %}} {{% tab name="Alibaba Cloud" %}} + ```yaml [...] metadata: @@ -1146,6 +1164,7 @@ metadata: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" [...] ``` + {{% /tab %}} {{< /tabs >}} @@ -1157,7 +1176,8 @@ annotations to a `LoadBalancer` service: --> ### AWS TLS 支持 {#ssl-support-on-aws} -为了对在AWS上运行的集群提供部分TLS / SSL支持，您可以向 `LoadBalancer` 服务添加三个注释： +为了对在 AWS 上运行的集群提供 TLS/SSL 部分支持，你可以向 `LoadBalancer` +服务添加三个注解： ```yaml metadata: @@ -1171,8 +1191,8 @@ The first specifies the ARN of the certificate to use. It can be either a certificate from a third party issuer that was uploaded to IAM or one created within AWS Certificate Manager. --> - -第一个指定要使用的证书的ARN。 它可以是已上载到 IAM 的第三方颁发者的证书，也可以是在 AWS Certificate Manager 中创建的证书。 +第一个指定要使用的证书的 ARN。 它可以是已上载到 IAM 的第三方颁发者的证书， +也可以是在 AWS Certificate Manager 中创建的证书。 ```yaml metadata: @@ -1197,14 +1217,15 @@ modifying the headers. In a mixed-use environment where some ports are secured and others are left unencrypted, you can use the following annotations: --> -第二个注释指定 Pod 使用哪种协议。 对于 HTTPS 和 SSL，ELB 希望 Pod 使用证书通过加密连接对自己进行身份验证。 +第二个注解指定 Pod 使用哪种协议。 对于 HTTPS 和 SSL，ELB 希望 Pod 使用证书 +通过加密连接对自己进行身份验证。 HTTP 和 HTTPS 选择第7层代理：ELB 终止与用户的连接，解析标头，并在转发请求时向 `X-Forwarded-For` 标头注入用户的 IP 地址（Pod 仅在连接的另一端看到 ELB 的 IP 地址）。 TCP 和 SSL 选择第4层代理：ELB 转发流量而不修改报头。 -在某些端口处于安全状态而其他端口未加密的混合使用环境中，可以使用以下注释： +在某些端口处于安全状态而其他端口未加密的混合使用环境中，可以使用以下注解： ```yaml metadata: @@ -1222,10 +1243,9 @@ be proxied HTTP. From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services. To see which policies are available for use, you can use the `aws` command line tool: --> - 从 Kubernetes v1.9 起可以使用 [预定义的 AWS SSL 策略](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) -为您的服务使用 HTTPS 或 SSL 侦听器。 +为你的服务使用 HTTPS 或 SSL 侦听器。 要查看可以使用哪些策略，可以使用 `aws` 命令行工具： ```bash @@ -1237,8 +1257,8 @@ You can then specify any one of those policies using the "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`" annotation; for example: --> -然后，您可以使用 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`" 注解; -例如： +然后，你可以使用 "`service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy`" +注解; 例如： ```yaml metadata: @@ -1256,8 +1276,9 @@ annotation: --> #### AWS 上的 PROXY 协议支持 -为了支持在 AWS 上运行的集群，启用 [PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。 -您可以使用以下服务注释： +为了支持在 AWS 上运行的集群，启用 +[PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。 +你可以使用以下服务注解： ```yaml metadata: @@ -1270,7 +1291,7 @@ annotation: Since version 1.3.0, the use of this annotation applies to all ports proxied by the ELB and cannot be configured otherwise. --> -从 1.3.0 版开始，此注释的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。 +从 1.3.0 版开始，此注解的使用适用于 ELB 代理的所有端口，并且不能进行其他配置。 #### AWS 上的 ELB 访问日志 -有几个注释可用于管理 AWS 上 ELB 服务的访问日志。 +有几个注解可用于管理 AWS 上 ELB 服务的访问日志。 -注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` 控制是否启用访问日志。 +注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` 控制是否启用访问日志。 注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval` -控制发布访问日志的时间间隔（以分钟为单位）。您可以指定 5 分钟或 60 分钟的间隔。 +控制发布访问日志的时间间隔（以分钟为单位）。你可以指定 5 分钟或 60 分钟的间隔。 -注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` +注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` 控制存储负载均衡器访问日志的 Amazon S3 存储桶的名称。 -注释 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` +注解 `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` 指定为 Amazon S3 存储桶创建的逻辑层次结构。 ```yaml @@ -1348,13 +1369,13 @@ specifies the logical hierarchy you created for your Amazon S3 bucket. name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "true" - # Specifies whether access logs are enabled for the load balancer + # 指定是否为负载均衡器启用访问日志 service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "60" - # The interval for publishing the access logs. You can specify an interval of either 5 or 60 (minutes). + # 发布访问日志的时间间隔。你可以将其设置为 5 分钟或 60 分钟。 service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name: "my-bucket" - # The name of the Amazon S3 bucket where the access logs are stored + # 用来存放访问日志的 Amazon S3 Bucket 名称 service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix: "my-bucket-prefix/prod" - # The logical hierarchy you created for your Amazon S3 bucket, for example `my-bucket-prefix/prod` + # 你为 Amazon S3 Bucket 所创建的逻辑层次结构，例如 `my-bucket-prefix/prod` ``` #### 其他 ELB 注解 -还有其他一些注释，用于管理经典弹性负载均衡器，如下所述。 +还有其他一些注解，用于管理经典弹性负载均衡器，如下所述。 ```yaml metadata: @@ -1421,8 +1442,16 @@ There are other annotations to manage Classic Elastic Load Balancers that are de # 此值必须小于 service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval # 默认值为 5，必须介于 2 和 60 之间 + service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f" + # 要添加到所创建的 ELB 之上的已有安全组列表。与注解 + # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 不同，此 + # 注解会替换掉之前指派给 ELB 的所有其他安全组 + service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" # 要添加到 ELB 上的额外安全组列表 + + service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" + # 用逗号分隔的一个键-值偶对列表，用来为负载均衡器选择目标节点 ``` - {{< note >}} NLB 仅适用于某些实例类。有关受支持的实例类型的列表， 请参见 @@ -1540,7 +1568,7 @@ the `my-service` Service in the `prod` namespace to `my.database.example.com`: ### ExternalName 类型 {#externalname} 类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。 -您可以使用 `spec.externalName` 参数指定这些服务。 +你可以使用 `spec.externalName` 参数指定这些服务。 例如，以下 Service 定义将 `prod` 名称空间中的 `my-service` 服务映射到 `my.database.example.com`： @@ -1578,7 +1606,7 @@ Service's `type`. 当查找主机 `my-service.prod.svc.cluster.local` 时，集群 DNS 服务返回 `CNAME` 记录， 其值为 `my.database.example.com`。 访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。 -如果以后您决定将数据库移到群集中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的 `type`。 +如果以后你决定将数据库移到集群中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的 `type`。 ### Service IP 地址 {#ips-and-vips} -不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上不能通过单个主机来进行应答。 -相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向。 +不像 Pod 的 IP 地址，它实际路由到一个固定的目的地，Service 的 IP 实际上 +不能通过单个主机来进行应答。 +相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个 +虚拟 IP 地址（VIP），它可以根据需要透明地进行重定向。 当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。 环境变量和 DNS，实际上会根据 Service 的 VIP 和端口来进行填充。 @@ -1762,9 +1794,11 @@ of which Pods they are actually accessing. 作为一个例子，考虑前面提到的图片处理应用程序。 当创建后端 Service 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。 假设 Service 的端口是 1234，该 Service 会被集群中所有的 `kube-proxy` 实例观察到。 -当代理看到一个新的 Service， 它会打开一个新的端口，建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。 +当代理看到一个新的 Service， 它会打开一个新的端口，建立一个从该 VIP 重定向到 +新端口的 iptables，并开始接收请求连接。 -当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 "服务代理" 的端口。 +当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 +"服务代理" 的端口。 "服务代理" 选择一个后端，并将客户端的流量代理到后端上。 这意味着 Service 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。 @@ -1811,9 +1845,11 @@ through a load-balancer, though in those cases the client IP does get altered. iptables operations slow down dramatically in large scale cluster e.g 10,000 Services. IPVS is designed for load balancing and based on in-kernel hash tables. So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy. Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms (least conns, locality, weighted, persistence). --> -在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 IPVS 专为负载平衡而设计，并基于内核内哈希表。 -因此，您可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。 -同时，基于 IPVS 的 kube-proxy 具有更复杂的负载平衡算法（最小连接，局部性，加权，持久性）。 +在大规模集群（例如 10000 个服务）中，iptables 操作会显着降低速度。 IPVS +专为负载平衡而设计，并基于内核内哈希表。 +因此，你可以通过基于 IPVS 的 kube-proxy 在大量服务中实现性能一致性。 +同时，基于 IPVS 的 kube-proxy 具有更复杂的负载均衡算法（最小连接、局部性、 +加权、持久性）。 ## API 对象 @@ -1821,57 +1857,48 @@ IPVS is designed for load balancing and based on in-kernel hash tables. So you c Service is a top-level resource in the Kubernetes REST API. You can find more details about the API object at: [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). --> -Service 是 Kubernetes REST API 中的顶级资源。您可以在以下位置找到有关A PI 对象的更多详细信息： +Service 是 Kubernetes REST API 中的顶级资源。你可以在以下位置找到有关 API 对象的更多详细信息： [Service 对象 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). ## 受支持的协议 {#protocol-support} ### TCP -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -您可以将 TCP 用于任何类型的服务，这是默认的网络协议。 +你可以将 TCP 用于任何类型的服务，这是默认的网络协议。 ### UDP -{{< feature-state for_k8s_version="v1.0" state="stable" >}} - -您可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。 +你可以将 UDP 用于大多数服务。 对于 type=LoadBalancer 服务，对 UDP 的支持取决于提供此功能的云提供商。 ### HTTP -{{< feature-state for_k8s_version="v1.1" state="stable" >}} - -如果您的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部 HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。 +如果你的云提供商支持它，则可以在 LoadBalancer 模式下使用服务来设置外部 +HTTP/HTTPS 反向代理，并将其转发到该服务的 Endpoints。 {{< note >}} -您还可以使用 {{< glossary_tooltip text="Ingres" term_id="ingress" >}} 代替 Service 来公开 HTTP/HTTPS 服务。 +你还可以使用 {{< glossary_tooltip text="Ingres" term_id="ingress" >}} 代替 +Service 来公开 HTTP/HTTPS 服务。 {{< /note >}} -### PROXY 协议 -{{< feature-state for_k8s_version="v1.1" state="stable" >}} - - +### PROXY 协议 -如果您的云提供商支持它， +如果你的云提供商支持它， 则可以在 LoadBalancer 模式下使用 Service 在 Kubernetes 本身之外配置负载均衡器， -该负载均衡器将转发前缀为 [PROXY协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) +该负载均衡器将转发前缀为 +[PROXY 协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) 的连接。 负载平衡器将发送一系列初始字节，描述传入的连接，类似于此示例 @@ -1899,19 +1928,22 @@ followed by the data from the client. ### SCTP -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} +Kubernetes 支持 SCTP 作为 Service、Endpoint、EndpointSlice, NetworkPolicy +和 Pod 定义中的 `protocol` 值。 +作为一种 Beta 特性，此功能默认是启用的。集群管理员需要在 API 服务器上使用 +`--feature-gates=SCTPSupport=false,...` 来关闭 +`SCTPSupport` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +来在集群级别禁用 SCTP。 -作为一种 alpha 功能，Kubernetes 支持 SCTP 作为 Service、Endpoint、NetworkPolicy 和 Pod 定义中的 `protocol` 值。 -要启用此功能，集群管理员需要在 API 服务器上启用 `SCTPSupport` 特性门控， -例如 `--feature-gates=SCTPSupport=true,...`。 - -启用特性门控后，你可以将 Service、Endpoints、NetworkPolicy 或 Pod 的 `protocol` 字段设置为 `SCTP`。 +启用特性门控后，你可以将 Service、Endpoints、EndpointSlice、NetworkPolicy 或 +Pod 的 `protocol` 字段设置为 `SCTP`。 Kubernetes 相应地为 SCTP 关联设置网络，就像为 TCP 连接所做的一样。 -##### Service 类型为 LoadBalancer 的服务 {#caveat-sctp-loadbalancer-service-type} - - +##### Service 类型为 LoadBalancer 的服务 {#caveat-sctp-loadbalancer-service-type} {{< warning >}} 如果云提供商的负载平衡器实现支持将 SCTP 作为协议，则只能使用 `type` LoadBalancer 加上 @@ -1959,38 +1988,20 @@ SCTP is not supported on Windows based nodes. 基于 Windows 的节点不支持 SCTP。 {{< /warning >}} + ##### 用户空间 kube-proxy {#caveat-sctp-kube-proxy-userspace} +{{< warning >}} -{{< warning >}} 当 kube-proxy 处于用户空间模式时，它不支持 SCTP 关联的管理。 {{< /warning >}} - -## 未来工作 - -未来我们能预见到，代理策略可能会变得比简单的轮转均衡策略有更多细微的差别，比如主控节点选举或分片。 -我们也能想到，某些 Service 将具有 “真正” 的负载均衡器，这种情况下 VIP 将简化数据包的传输。 - -Kubernetes 项目打算为 L7（HTTP）服务改进支持。 - -Kubernetes 项目打算为 Service 实现更加灵活的请求进入模式， -这些模式包含当前的 `ClusterIP`、`NodePort` 和 `LoadBalancer` 模式，或者更多。 - ## {{% heading "whatsnext" %}} - * 阅读[使用服务访问应用](/zh/docs/concepts/services-networking/connect-applications-service/) * 阅读了解 [Ingress](/zh/docs/concepts/services-networking/ingress/) -* 阅读了解 [端点切片](/zh/docs/concepts/services-networking/endpoint-slices/) +* 阅读了解[端点切片（Endpoint Slices）](/zh/docs/concepts/services-networking/endpoint-slices/) diff --git a/content/zh/docs/concepts/storage/ephemeral-volumes.md b/content/zh/docs/concepts/storage/ephemeral-volumes.md index 32190eb3e9..47eab07777 100644 --- a/content/zh/docs/concepts/storage/ephemeral-volumes.md +++ b/content/zh/docs/concepts/storage/ephemeral-volumes.md @@ -72,7 +72,7 @@ different purposes: [downwardAPI](/docs/concepts/storage/volumes/#downwardapi), [secret](/docs/concepts/storage/volumes/#secret): inject different kinds of Kubernetes data into a Pod -- [CSI ephemeral volumes](#csi-ephemeral-volume): +- [CSI ephemeral volumes](#csi-ephemeral-volumes): similar to the previous volume kinds, but provided by special [CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md) which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md index 1a6ba538a0..cd16a93a54 100644 --- a/content/zh/docs/concepts/storage/volumes.md +++ b/content/zh/docs/concepts/storage/volumes.md @@ -14,58 +14,55 @@ weight: 10 - -容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。 -首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失——因为容器会以干净的状态重建。 -其次，当在一个 `Pod` 中同时运行多个容器时，常常需要在这些容器之间共享文件。 -Kubernetes 抽象出 `Volume` 对象来解决这两个问题。 +Container 中的文件在磁盘上是临时存放的，这给 Container 中运行的较重要的应用 +程序带来一些问题。问题之一是当容器崩溃时文件丢失。kubelet 会重新启动容器， +但容器会以干净的状态重启。 +第二个问题会在同一 `Pod` 中运行多个容器并共享文件时出现。 +Kubernetes {{< glossary_tooltip text="卷（Volume）" term_id="volume" >}} +这一抽象概念能够解决这两个问题。 -阅读本文前建议您熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 +阅读本文前建议你熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 +## 背景 {#background} -## 背景 - -Docker 也有 [Volume](https://docs.docker.com/storage/) 的概念，但对它只有少量且松散的管理。 -在 Docker 中，Volume 是磁盘上或者另外一个容器内的一个目录。 -直到最近，Docker 才支持对基于本地磁盘的 Volume 的生存期进行管理。 -虽然 Docker 现在也能提供 Volume 驱动程序，但是目前功能还非常有限 -（例如，截至 Docker 1.7，每个容器只允许有一个 Volume 驱动程序，并且无法将参数传递给卷）。 +Docker 也有 [卷（Volume）](https://docs.docker.com/storage/) 的概念，但对它只有少量且松散的管理。 +Docker 卷是磁盘上或者另外一个容器内的一个目录。 +Docker 提供卷驱动程序，但是其功能非常有限。 -另一方面，Kubernetes 卷具有明确的生命周期——与包裹它的 Pod 相同。 -因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 -当然，当一个 Pod 不再存在时，卷也将不再存在。 -也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。 +Kubernetes 支持很多类型的卷。 +{{< glossary_tooltip term_id="pod" text="Pod" >}} 可以同时使用任意数目的卷类型。 +临时卷类型的生命周期与 Pod 相同，但持久卷可以比 Pod 的存活期长。 +因此，卷的存在时间会超出 Pod 中运行的所有容器，并且在容器重新启动时数据也会得到保留。 +当 Pod 不再存在时，卷也将不再存在。 -卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。 -特定的卷类型可以决定这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。 - - - -使用卷时, Pod 声明中需要提供卷的类型 (`.spec.volumes` 字段)和卷挂载的位置 (`.spec.containers.volumeMounts` 字段). +卷的核心是包含一些数据的一个目录，Pod 中的容器可以访问该目录。 +所采用的特定的卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放 +的内容。 -容器中的进程能看到由它们的 Docker 镜像和卷组成的文件系统视图。 +使用卷时, 在 `.spec.volumes` 字段中设置为 Pod 提供的卷，并在 +`.spec.containers[*].volumeMounts` 字段中声明卷在容器中的挂载位置。 +容器中的进程看到的是由它们的 Docker 镜像和卷组成的文件系统视图。 [Docker 镜像](https://docs.docker.com/userguide/dockerimages/) -位于文件系统层次结构的根部，并且任何 Volume 都挂载在镜像内的指定路径上。 -卷不能挂载到其他卷，也不能与其他卷有硬链接。 -Pod 中的每个容器必须独立地指定每个卷的挂载位置。 +位于文件系统层次结构的根部。各个卷则挂载在镜像内的指定路径上。 +卷不能挂载到其他卷之上，也不能与其他卷有硬链接。 +Pod 配置中的每个容器必须独立指定各个卷的挂载位置。 -## Volume 的类型 +## 卷类型 {#volume-types} Kubernetes 支持下列类型的卷： - - * [awsElasticBlockStore](#awselasticblockstore) - * [azureDisk](#azuredisk) - * [azureFile](#azurefile) - * [cephfs](#cephfs) - * [cinder](#cinder) - * [configMap](#configmap) - * [csi](#csi) - * [downwardAPI](#downwardapi) - * [emptyDir](#emptydir) - * [fc (fibre channel)](#fc) - * [flexVolume](#flexVolume) - * [flocker](#flocker) - * [gcePersistentDisk](#gcepersistentdisk) - * [gitRepo (deprecated)](#gitrepo) - * [glusterfs](#glusterfs) - * [hostPath](#hostpath) - * [iscsi](#iscsi) - * [local](#local) - * [nfs](#nfs) - * [persistentVolumeClaim](#persistentvolumeclaim) - * [projected](#projected) - * [portworxVolume](#portworxvolume) - * [quobyte](#quobyte) - * [rbd](#rbd) - * [scaleIO](#scaleio) - * [secret](#secret) - * [storageos](#storageos) - * [vsphereVolume](#vspherevolume) - - - -我们欢迎大家贡献其他的卷类型支持。 - ### awsElasticBlockStore {#awselasticblockstore} -`awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](https://aws.amazon.com/ebs/) 挂载到您的 Pod 中。 -与 `emptyDir` 在删除 Pod 时会被删除不同，EBS 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 -这意味着 EBS 卷可以预先填充数据，并且可以在 Pod 之间传递数据。 +`awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](https://aws.amazon.com/ebs/) +挂载到你的 Pod 中。与 `emptyDir` 在 Pod 被删除时也被删除不同，EBS 卷的内容在删除 Pod 时 +会被保留，卷只是被卸载掉了。 +这意味着 EBS 卷可以预先填充数据，并且该数据可以在 Pod 之间共享。 -{{< caution >}} -您在使用 EBS 卷之前必须先创建它，可以使用 `aws ec2 create-volume` 命令进行创建；也可以使用 AWS API 进行创建。 -{{< /caution >}} +{{< note >}} +你在使用 EBS 卷之前必须使用 `aws ec2 create-volume` 命令或者 AWS API 创建该卷。 +{{< /note >}} 使用 `awsElasticBlockStore` 卷时有一些限制： -* Pod 正在运行的节点必须是 AWS EC2 实例。 -* 这些实例需要与 EBS 卷在相同的地域（region）和可用区（availability-zone）。 +* Pod 运行所在的节点必须是 AWS EC2 实例。 +* 这些实例需要与 EBS 卷在相同的地域（Region）和可用区（Availability-Zone）。 * EBS 卷只支持被挂载到单个 EC2 实例上。 #### 创建 EBS 卷 -在将 EBS 卷用到 Pod 上之前，您首先要创建它。 +在将 EBS 卷用到 Pod 上之前，你首先要创建它。 ```shell aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 ``` -确保该区域与您的群集所在的区域相匹配。（也要检查卷的大小和 EBS 卷类型都适合您的用途！） +确保该区域与你的群集所在的区域相匹配。还要检查卷的大小和 EBS 卷类型都适合你的用途。 +#### AWS EBS CSI 卷迁移 + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + + +如果启用了对 `awsElasticBlockStore` 的 `CSIMigration` 特性支持，所有插件操作都 +不再指向树内插件（In-Tree Plugin），转而指向 `ebs.csi.aws.com` 容器存储接口 +（Container Storage Interface，CSI）驱动。为了使用此特性，必须在集群中安装 +[AWS EBS CSI 驱动](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)， +并确保 `CSIMigration` 和 `CSIMigrationAWS` Beta 功能特性被启用。 + + +#### AWS EBS CSI 迁移结束 + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + + +如欲禁止 `awsElasticBlockStore` 存储插件被控制器管理器和 kubelet +组件加载，可将 `CSIMigrationAWSComplete` 特性门控设置为 `true`。此特性要求在 +集群中所有工作节点上安装 `ebs.csi.aws.com` 容器存储接口驱动。 + ### azureDisk {#azuredisk} -`azureDisk` 用来在 Pod 上挂载 Microsoft Azure [数据盘（Data Disk）](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) . -更多详情请参考[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)。 +`azureDisk` 卷类型用来在 Pod 上挂载 Microsoft Azure +[数据盘（Data Disk）](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) 。 +若需了解更多详情，请参考 [`azureDisk` 卷插件](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)。 -#### CSI迁移 +#### azureDisk 的 CSI 迁移 {#azuredisk-csi-migration} -{{< feature-state for_k8s_version="v1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -启用azureDisk的CSI迁移功能后，它会将所有插件操作从现有的内建插件填添加disk.csi.azure.com容器存储接口（CSI）驱动程序中。 -为了使用此功能，必须在群集上安装 [Azure磁盘CSI驱动程序](https://github.com/kubernetes-sigs/azuredisk-csi-driver)， -并且 `CSIMigration` 和 `CSIMigrationAzureDisk` Alpha功能 必须启用。 +启用 `azureDisk` 的 `CSIMigration` 功能后，所有插件操作从现有的树内插件重定向到 +`disk.csi.azure.com` 容器存储接口（CSI）驱动程序。 +为了使用此功能，必须在集群中安装 +[Azure 磁盘 CSI 驱动程序](https://github.com/kubernetes-sigs/azuredisk-csi-driver)， +并且 `CSIMigration` 和 `CSIMigrationAzureDisk` 功能必须被启用。 ### azureFile {#azurefile} -`azureFile` 用来在 Pod 上挂载 Microsoft Azure 文件卷（File Volume） (SMB 2.1 和 3.0)。 -更多详情请参考[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)。 +`azureFile` 卷类型用来在 Pod 上挂载 Microsoft Azure 文件卷（File Volume）（SMB 2.1 和 3.0）。 +更多详情请参考 [`azureFile` 卷插件](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)。 -#### CSI迁移 +#### CSI 迁移 {#azurefile-csi-migration} {{< feature-state for_k8s_version="v1.15" state="alpha" >}} -启用azureFile的CSI迁移功能后，它会将所有插件操作从现有的内建插件填添加file.csi.azure.com容器存储接口（CSI）驱动程序中。 -为了使用此功能，必须在群集上安装 [Azure文件CSI驱动程序](https://github.com/kubernetes-sigs/azurefile-csi-driver)， -并且 `CSIMigration` 和 `CSIMigrationAzureFile` Alpha功能 必须启用。 +启用 `azureFile` 的 `CSIMigration` 功能后，所有插件操作将从现有的树内插件重定向到 +`file.csi.azure.com` 容器存储接口（CSI）驱动程序。 +要使用此功能，必须在集群中安装 [Azure 文件 CSI 驱动程序](https://github.com/kubernetes-sigs/azurefile-csi-driver)， +并且 `CSIMigration` 和 `CSIMigrationAzureFile` Alpha 功能特性必须被启用。 ### cephfs {#cephfs} @@ -291,20 +286,21 @@ Alpha features must be enabled. A `cephfs` volume allows an existing CephFS volume to be mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of a `cephfs` volume are preserved and the volume is merely -unmounted. This means that a CephFS volume can be pre-populated with data, and -that data can be "handed off" between Pods. CephFS can be mounted by multiple +unmounted. This means that a `cephfs` volume can be pre-populated with data, and +that data can be shared between Pods. The `cephfs` can be mounted by multiple writers simultaneously. --> -`cephfs` 允许您将现存的 CephFS 卷挂载到 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`cephfs` 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 -这意味着 CephFS 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。CephFS 卷可同时被多个写者挂载。 +`cephfs` 卷允许你将现存的 CephFS 卷挂载到 Pod 中。 +不像 `emptyDir` 那样会在 Pod 被删除的同时也会被删除，`cephfs` 卷的内容在 Pod 被删除 +时会被保留，只是卷被卸载了。这意味着 `cephfs` 卷可以被预先填充数据，且这些数据可以在 +Pod 之间共享。同一 `cephfs` 卷可同时被多个写者挂载。 -{{< caution >}} -在您使用 Ceph 卷之前，您的 Ceph 服务器必须正常运行并且要使用的 share 被导出（exported）。 -{{< /caution >}} +{{< note >}} +在使用 Ceph 卷之前，你的 Ceph 服务器必须已经运行并将要使用的 share 导出（exported）。 +{{< /note >}} {{< note >}} -先决条件：配置了OpenStack Cloud Provider 的 Kubernetes。 +Kubernetes 必须配置了 OpenStack Cloud Provider。 {{< /note >}} -`cinder` 用于将 OpenStack Cinder 卷安装到 Pod 中。 +`cinder` 卷类型用于将 OpenStack Cinder 卷挂载到 Pod 中。 -#### Cinder Volume示例配置 +#### Cinder 卷示例配置 ```yaml apiVersion: v1 @@ -343,55 +339,55 @@ spec: name: test-volume volumes: - name: test-volume - # This OpenStack volume must already exist. + # 此 OpenStack 卷必须已经存在 cinder: - volumeID: + volumeID: "" fsType: ext4 ``` -#### CSI迁移 +#### OpenStack CSI 迁移 -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} +启用 Cinder 的 `CSIMigration` 功能后，所有插件操作会从现有的树内插件重定向到 +`cinder.csi.openstack.org` 容器存储接口（CSI）驱动程序。 +为了使用此功能，必须在集群中安装 [Openstack Cinder CSI 驱动程序](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)， +并且 `CSIMigration` 和 `CSIMigrationOpenStack` Beta 功能必须被启用。 -启用Cinder的CSI迁移功能后，它会将所有插件操作从现有的内建插件填添加 `cinder.csi.openstack.org` 容器存储接口（CSI）驱动程序中。 -为了使用此功能，必须在群集上安装 [Openstack Cinder CSI驱动程序](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)， -并且 `CSIMigration` 和 `CSIMigrationOpenStack` Alpha功能 必须启用。 - - -### configMap {#configmap} +### configMap -[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源提供了向 Pod 注入配置数据的方法。 -`ConfigMap` 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被应用到 Pod 中运行的容器化应用。 +[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 卷 +提供了向 Pod 注入配置数据的方法。 +ConfigMap 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被 Pod 中运行的 +容器化应用使用。 - -当引用 `configMap` 对象时，你可以简单的在 Volume 中通过它名称来引用。 -还可以自定义 ConfigMap 中特定条目所要使用的路径。 -例如，要将名为 `log-config` 的 ConfigMap 挂载到名为 `configmap-pod` 的 Pod 中，您可以使用下面的 YAML： +引用 configMap 对象时，你可以在 volume 中通过它的名称来引用。 +你可以自定义 ConfigMap 中特定条目所要使用的路径。 +下面的配置显示了如何将名为 `log-config` 的 ConfigMap 挂载到名为 `configmap-pod` +的 Pod 中： ```yaml apiVersion: v1 @@ -420,41 +416,41 @@ its `log_level` entry are mounted into the Pod at path "`/etc/config/log_level`" Note that this path is derived from the volume's `mountPath` and the `path` keyed with `log_level`. --> -`log-config` ConfigMap 是以卷的形式挂载的， -存储在 `log_level` 条目中的所有内容都被挂载到 Pod 的 "`/etc/config/log_level`" 路径下。 -请注意，这个路径来源于 Volume 的 `mountPath` 和 `log_level` 键对应的 `path`。 +`log-config` ConfigMap 以卷的形式挂载，并且存储在 `log_level` 条目中的所有内容 +都被挂载到 Pod 的 `/etc/config/log_level` 路径下。 +请注意，这个路径来源于卷的 `mountPath` 和 `log_level` 键对应的 `path`。 -{{< caution >}} -在使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前您首先要创建它。 -{{< /caution >}} +* You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) + before you can use it. - {{< note >}} -容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。 +* 在使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前你首先要创建它。 +* 容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。 +* 文本数据挂载成文件时采用 UTF-8 字符编码。如果使用其他字符编码形式，可使用 + `binaryData` 字段。 {{< /note >}} -### downwardAPI {#downwardapi} +### downwardAPI - `downwardAPI` 卷用于使 downward API 数据对应用程序可用。 -这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。 +这种卷类型挂载一个目录并在纯文本文件中写入所请求的数据。 {{< note >}} -容器以挂载 [subPath](#using-subpath) 卷的方式使用 downwardAPI 时，将不能接收到它的更新。 +容器以 [subPath](#using-subpath) 卷挂载方式使用 downwardAPI 时，将不能接收到它的更新。 {{< /note >}} 更多详细信息请参考 [`downwardAPI` 卷示例](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 -### emptyDir {#emptydir} +### emptyDir - -当 Pod 指定到某个节点上时，首先创建的是一个 `emptyDir` 卷，并且只要 Pod 在该节点上运行，卷就一直存在。 -就像它的名称表示的那样，卷最初是空的。 -尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同，但是这些容器都可以读写 `emptyDir` 卷中相同的文件。 -当 Pod 因为某些原因被从节点上删除时，`emptyDir` 卷中的数据也会永久删除。 +当 Pod 分派到某个 Node 上时，`emptyDir` 卷会被创建，并且在 Pod 在该节点上运行期间，卷一直存在。 +就像其名称表示的那样，卷最初是空的。 +尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同，这些容器都可以读写 +`emptyDir` 卷中相同的文件。 +当 Pod 因为某些原因被从节点上删除时，`emptyDir` 卷中的数据也会被永久删除。 {{< note >}} -容器崩溃并不会导致 Pod 被从节点上移除，因此容器崩溃时 `emptyDir` 卷中的数据是安全的。 +容器崩溃并**不**会导致 Pod 被从节点上移除，因此容器崩溃期间 `emptyDir` 卷中的数据是安全的。 {{< /note >}} -默认情况下， `emptyDir` 卷存储在支持该节点所使用的介质上；这里的介质可以是磁盘或 SSD 或网络存储，这取决于您的环境。 -但是，您可以将 `emptyDir.medium` 字段设置为 `"Memory"`，以告诉 Kubernetes 为您安装 tmpfs（基于 RAM 的文件系统）。 +取决于你的环境，`emptyDir` 卷存储在该节点所使用的介质上；这里的介质可以是磁盘或 SSD +或网络存储。但是，你可以将 `emptyDir.medium` 字段设置为 `"Memory"`，以告诉 Kubernetes +为你挂载 tmpfs（基于 RAM 的文件系统）。 虽然 tmpfs 速度非常快，但是要注意它与磁盘不同。 -tmpfs 在节点重启时会被清除，并且您所写入的所有文件都会计入容器的内存消耗，受容器内存限制约束。 +tmpfs 在节点重启时会被清除，并且你所写入的所有文件都会计入容器的内存消耗，受容器内存限制约束。 -#### Pod 示例 +#### emptyDir 配置示例 ```yaml apiVersion: v1 @@ -538,22 +534,23 @@ spec: ### fc (光纤通道) {#fc} -`fc` 卷允许将现有的光纤通道卷挂载到 Pod 中。 -可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN。 -如果指定多个 WWN，targetWWNs 期望这些 WWN 来自多路径连接。 +`fc` 卷类型允许将现有的光纤通道块存储卷挂载到 Pod 中。 +可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN（World Wide Names）。 +如果指定了多个 WWN，targetWWNs 期望这些 WWN 来自多路径连接。 {{< caution >}} -您必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷），这样 Kubernetes 主机才可以访问它们。 +你必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷）， +这样 Kubernetes 主机才可以访问它们。 {{< /caution >}} -### flocker {#flocker} +### flocker （已弃用） {#flocker} [Flocker](https://github.com/ClusterHQ/flocker) 是一个开源的、集群化的容器数据卷管理器。 -Flocker 提供了由各种存储后备支持的数据卷的管理和编排。 +Flocker 提供了由各种存储后端所支持的数据卷的管理和编排。 -`flocker` 卷允许将一个 Flocker 数据集挂载到 Pod 中。 +使用 `flocker` 卷可以将一个 Flocker 数据集挂载到 Pod 中。 如果数据集在 Flocker 中不存在，则需要首先使用 Flocker CLI 或 Flocker API 创建数据集。 如果数据集已经存在，那么 Flocker 将把它重新附加到 Pod 被调度的节点。 -这意味着数据可以根据需要在 Pod 之间 "传递"。 +这意味着数据可以根据需要在 Pod 之间共享。 -{{< caution >}} -您在使用 Flocker 之前必须先安装运行自己的 Flocker。 -{{< /caution >}} +{{< note >}} +在使用 Flocker 之前你必须先安装运行自己的 Flocker。 +{{< /note >}} - 更多详情请参考 [Flocker 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)。 - ### gcePersistentDisk {#gcepersistentdisk} -`gcePersistentDisk` 卷能将谷歌计算引擎 (GCE) [持久盘（PD）](http://cloud.google.com/compute/docs/disks) 挂载到您的 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，持久盘卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 -这意味着持久盘卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 +`gcePersistentDisk` 卷能将谷歌计算引擎 (GCE) [持久盘（PD）](http://cloud.google.com/compute/docs/disks) +挂载到你的 Pod 中。 +不像 `emptyDir` 那样会在 Pod 被删除的同时也会被删除，持久盘卷的内容在删除 Pod +时会被保留，卷只是被卸载了。 +这意味着持久盘卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 {{< caution >}} -您在使用 PD 前，必须使用 `gcloud` 或者 GCE API 或 UI 创建它。 +在使用 PD 前，你必须使用 `gcloud` 或者 GCE API 或 UI 创建它。 {{< /caution >}} -PD 的一个特点是它们可以同时被多个消费者以只读方式挂载。 -这意味着您可以用数据集预先填充 PD，然后根据需要并行地在尽可能多的 Pod 中提供该数据集。 -不幸的是，PD 只能由单个使用者以读写模式挂载——即不允许同时写入。 +GCE PD 的一个特点是它们可以同时被多个消费者以只读方式挂载。 +这意味着你可以用数据集预先填充 PD，然后根据需要并行地在尽可能多的 Pod 中提供该数据集。 +不幸的是，PD 只能由单个使用者以读写模式挂载 —— 即不允许同时写入。 -在由 ReplicationController 所管理的 Pod 上使用 PD 将会失败，除非 PD 是只读模式或者副本的数量是 0 或 1。 +在由 ReplicationController 所管理的 Pod 上使用 GCE PD 将会失败，除非 PD +是只读模式或者副本的数量是 0 或 1。 -#### 创建持久盘（PD） +#### 创建 GCE 持久盘（PD） {#gce-create-persistent-disk} -在 Pod 中使用 GCE 持久盘之前，您首先要创建它。 +在 Pod 中使用 GCE 持久盘之前，你首先要创建它。 ```shell gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk @@ -665,7 +665,7 @@ gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk -#### Pod 示例 +#### GCE 持久盘配置示例 {#gce-pd-configuration-example} ```yaml apiVersion: v1 @@ -681,7 +681,7 @@ spec: name: test-volume volumes: - name: test-volume - # This GCE PD must already exist. + # 此 GCE PD 必须已经存在 gcePersistentDisk: pdName: my-data-disk fsType: ext4 @@ -689,15 +689,18 @@ spec: -#### 区域持久盘（Regional Persistent Disks） - -{{< feature-state for_k8s_version="v1.10" state="beta" >}} +#### 区域持久盘 {#regional-persistent-disks} -[区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) 功能允许您创建能在同一区域的两个可用区中使用的持久盘。 -要使用这个功能，必须以持久盘的方式提供卷；Pod 不支持直接引用这种卷。 +[区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) 功能允许你创建能在 +同一区域的两个可用区中使用的持久盘。 +要使用这个功能，必须以持久卷（PersistentVolume）的方式提供卷；直接从 Pod 引用这种卷 +是不可以的。 -#### 手动供应基于区域 PD 的 PersistentVolume +#### 手动供应基于区域 PD 的 PersistentVolume {#manually-provisioning-regional-pd-pv} -使用 [为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce) 也可以动态供应。 -在创建 PersistentVolume 之前，您首先要创建 PD。 +使用[为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce) 可以 +实现动态供应。在创建 PersistentVolume 之前，你首先要创建 PD。 ```shell gcloud beta compute disks create --size=500GB my-data-disk @@ -719,7 +722,6 @@ gcloud beta compute disks create --size=500GB my-data-disk - PersistentVolume 示例： ```yaml @@ -737,14 +739,23 @@ spec: gcePersistentDisk: pdName: my-data-disk fsType: ext4 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: failure-domain.beta.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-b ``` -#### CSI迁移 +#### GCE CSI 迁移 {#gce-csi-migration} -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} -启用 GCE PD 的 CSI 迁移功能后，它会将所有插件操作从现有的内建插件填添加 `pd.csi.storage.gke.io` 容器存储接口（ CSI ）驱动程序中。 -为了使用此功能，必须在群集上安装 [GCE PD CSI驱动程序](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)， -并且 `CSIMigration` 和 `CSIMigrationGCE` Alpha功能 必须启用。 - +启用 GCE PD 的 `CSIMigration` 功能后，所有插件操作将从现有的树内插件重定向到 +`pd.csi.storage.gke.io` 容器存储接口（ CSI ）驱动程序。 +为了使用此功能，必须在集群中上安装 +[GCE PD CSI驱动程序](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)， +并且 `CSIMigration` 和 `CSIMigrationGCE` Beta 功能必须被启用。 -### gitRepo (已弃用) +### gitRepo (已弃用) {#gitrepo} {{< warning >}} -gitRepo 卷类型已经被废弃。如果需要在容器中提供 git 仓库，请将一个 [EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git 命令完成仓库的克隆操作，然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。 +`gitRepo` 卷类型已经被废弃。如果需要在容器中提供 git 仓库，请将一个 +[EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git 命令完成仓库的克隆操作， +然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。 {{< /warning >}} - `gitRepo` 卷是一个卷插件的例子。 -该卷类型挂载了一个空目录，并将一个 Git 代码仓库克隆到这个目录中供您使用。 -将来，这种卷可能被移动到一个更加解耦的模型中，而不是针对每个应用案例扩展 Kubernetes API。 +该查卷挂载一个空目录，并将一个 Git 代码仓库克隆到这个目录中供 Pod 使用。 -下面给出一个 gitRepo 卷的示例： +下面给出一个 `gitRepo` 卷的示例： ```yaml apiVersion: v1 @@ -806,7 +817,7 @@ spec: revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` -### glusterfs {#glusterfs} +### glusterfs -`glusterfs` 卷能将 [Glusterfs](https://www.gluster.org) (一个开源的网络文件系统) 挂载到您的 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`glusterfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 -这意味着 `glusterfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。GlusterFS 可以被多个写者同时挂载。 +`glusterfs` 卷能将 [Glusterfs](https://www.gluster.org) (一个开源的网络文件系统) +挂载到你的 Pod 中。不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`glusterfs` +卷的内容在删除 Pod 时会被保存，卷只是被卸载。 +这意味着 `glusterfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 +GlusterFS 可以被多个写者同时挂载。 -{{< caution >}} -在使用前您必须先安装运行自己的 GlusterFS。 -{{< /caution >}} +{{< note >}} +在使用前你必须先安装运行自己的 GlusterFS。 +{{< /note >}} 更多详情请参考 [GlusterFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)。 -### hostPath {#hostpath} +### hostPath - -`hostPath` 卷能将主机节点文件系统上的文件或目录挂载到您的 Pod 中。 +`hostPath` 卷能将主机节点文件系统上的文件或目录挂载到你的 Pod 中。 虽然这不是大多数 Pod 需要的，但是它为一些应用程序提供了强大的逃生舱。 - 例如，`hostPath` 的一些用法有： -* 运行一个需要访问 Docker 引擎内部机制的容器；请使用 `hostPath` 挂载 `/var/lib/docker` 路径。 +* 运行一个需要访问 Docker 内部机制的容器；可使用 `hostPath` 挂载 `/var/lib/docker` 路径。 * 在容器中运行 cAdvisor 时，以 `hostPath` 方式挂载 `/sys`。 * 允许 Pod 指定给定的 `hostPath` 在运行 Pod 之前是否应该存在，是否应该创建以及应该以什么方式存在。 @@ -865,15 +876,13 @@ In addition to the required `path` property, user can optionally specify a `type The supported values for field `type` are: --> - 除了必需的 `path` 属性之外，用户可以选择性地为 `hostPath` 卷指定 `type`。 支持的 `type` 值如下： - - -| 取值 | 行为 | +| 取值 | 行为 | |:------|:---------| | | 空字符串（默认）用于向后兼容，这意味着在安装 hostPath 卷之前不会执行任何检查。 | -| `DirectoryOrCreate` | 如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 Kubelet 相同的组和所有权。 | +| `DirectoryOrCreate` | 如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 kubelet 相同的组和属主信息。 | | `Directory` | 在给定路径上必须存在的目录。| -| `FileOrCreate` | 如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 Kubelet 相同的组和所有权。| +| `FileOrCreate` | 如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 kubelet 相同的组和所有权。| | `File` | 在给定路径上必须存在的文件。| | `Socket` | 在给定路径上必须存在的 UNIX 套接字。| | `CharDevice` | 在给定路径上必须存在的字符设备。| @@ -898,28 +906,25 @@ The supported values for field `type` are: - 当使用这种类型的卷时要小心，因为： -* 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。 -* 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 `hostPath` 使用的资源。 -* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 -[特权容器](/docs/tasks/configure-pod-container/security-context/) -中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 +* 具有相同配置（例如基于同一 PodTemplate 创建）的多个 Pod 会由于节点上文件的不同 + 而在不同节点上有不同的行为。 +* 下层主机上创建的文件或目录只能由 root 用户写入。你需要在 + [特权容器](/zh/docs/tasks/configure-pod-container/security-context/) + 中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 -#### Pod 示例 +#### hostPath 配置示例： ```yaml apiVersion: v1 @@ -936,25 +941,29 @@ spec: volumes: - name: test-volume hostPath: - # directory location on host + # 宿主上目录位置 path: /data - # this field is optional + # 此字段为可选 type: Directory ``` {{< caution >}} -应当注意,`FileOrCreate` 类型不会负责创建文件的父目录。 -如果挂载挂载文件的父目录不存在，pod 启动会失败。 -为了确保这种 `type` 能够工作，可以尝试把文件和它对应的目录分开挂载，如下所示： +`FileOrCreate` 模式不会负责创建文件的父目录。 +如果欲挂载的文件的父目录不存在，Pod 启动会失败。 +为了确保这种模式能够工作，可以尝试把文件和它对应的目录分开挂载，如 +[`FileOrCreate` 配置](#hostpath-fileorcreate-example) 所示。 {{< /caution >}} -#### FileOrCreate pod 示例 + +#### hostPath FileOrCreate 配置示例 {#hostpath-fileorcreate-example} ```yaml apiVersion: v1 @@ -982,36 +991,37 @@ spec: type: FileOrCreate ``` -### iscsi {#iscsi} +### iscsi - -`iscsi` 卷能将 iSCSI (基于 IP 的 SCSI) 挂载到您的 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，持久盘 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 -这意味着 `iscsi` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 +`iscsi` 卷能将 iSCSI (基于 IP 的 SCSI) 卷挂载到你的 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`iscsi` 卷的内容在删除 Pod 时 +会被保留，卷只是被卸载。 +这意味着 `iscsi` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 {{< caution >}} -在您使用 iSCSI 卷之前，您必须拥有自己的 iSCSI 服务器，并在上面创建卷。 +在使用 iSCSI 卷之前，你必须拥有自己的 iSCSI 服务器，并在上面创建卷。 {{< /caution >}} iSCSI 的一个特点是它可以同时被多个用户以只读方式挂载。 -这意味着您可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 上提供它。不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载——不允许同时写入。 +这意味着你可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 上使用它。 +不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载。不允许同时写入。 +### local -### local {#local} - -{{< feature-state for_k8s_version="v1.14" state="stable" >}} - - -{{< note >}} -alpha 版本的 PersistentVolume NodeAffinity 注释已被取消，将在将来的版本中废弃。 -用户必须更新现有的使用该注解的 PersistentVolume，以使用新的 PersistentVolume `NodeAffinity` 字段。 -{{< /note >}} - - +### local -`local` 卷指的是所挂载的某个本地存储设备，例如磁盘、分区或者目录。 +`local` 卷所代表的是某个被挂载的本地存储设备，例如磁盘、分区或者目录。 `local` 卷只能用作静态创建的持久卷。尚不支持动态配置。 - -相比 `hostPath` 卷，`local` 卷可以以持久和可移植的方式使用，而无需手动将 Pod -调度到节点，因为系统通过查看 PersistentVolume 所属节点的亲和性配置，就能了解卷的节点约束。 +与 `hostPath` 卷相比，`local` 卷能够以持久和可移植的方式使用，而无需手动将 Pod +调度到节点。系统通过查看 PersistentVolume 的节点亲和性配置，就能了解卷的节点约束。 -然而，`local` 卷仍然取决于底层节点的可用性，并不是适合所有应用程序。 -如果节点变得不健康，那么`local` 卷也将变得不可访问，并且使用它的 Pod 将不能运行。 -使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征而带来的潜在的数据丢失风险。 +然而，`local` 卷仍然取决于底层节点的可用性，并不适合所有应用程序。 +如果节点变得不健康，那么`local` 卷也将变得不可被 Pod 访问。使用它的 Pod 将不能运行。 +使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征 +而带来的潜在的数据丢失风险。 下面是一个使用 `local` 卷和 `nodeAffinity` 的持久卷示例： @@ -1083,7 +1077,6 @@ metadata: spec: capacity: storage: 100Gi - # volumeMode field requires BlockVolume Alpha feature gate to be enabled. volumeMode: Filesystem accessModes: - ReadWriteOnce @@ -1102,35 +1095,35 @@ spec: ``` -使用 `local` 卷时，需要使用 PersistentVolume 对象的 `nodeAffinity` 字段。 -它使 Kubernetes 调度器能够将使用 `local` 卷的 Pod 正确地调度到合适的节点。 +使用 `local` 卷时，你需要设置 PersistentVolume 对象的 `nodeAffinity` 字段。 +Kubernetes 调度器使用 PersistentVolume 的 `nodeAffinity` 信息来将使用 `local` +卷的 Pod 调度到正确的节点。 -现在，可以将 PersistentVolume 对象的 `volumeMode` 字段设置为 "Block" +PersistentVolume 对象的 `volumeMode` 字段可被设置为 "Block" （而不是默认值 "Filesystem"），以将 `local` 卷作为原始块设备暴露出来。 -`volumeMode` 字段需要启用 Alpha 功能 `BlockVolume`。 - -当使用 `local` 卷时，建议创建一个 StorageClass，将 `volumeBindingMode` 设置为 `WaitForFirstConsumer`。 -请参考[示例](/zh/docs/concepts/storage/storage-classes/#local)。 -延迟卷绑定操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时， -会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。 +使用 `local` 卷时，建议创建一个 StorageClass 并将其 `volumeBindingMode` 设置为 +`WaitForFirstConsumer`。要了解更多详细信息，请参考 +[local StorageClass 示例](/zh/docs/concepts/storage/storage-classes/#local)。 +延迟卷绑定的操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时， +会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod +亲和性和 Pod 反亲和性。 -您可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。 -请注意，此驱动不支持动态配置。 -有关如何运行外部 `local` 卷驱动的示例，请参考 +你可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。 +请注意，此驱动尚不支持动态配置。 +有关如何运行外部 `local` 卷驱动，请参考 [local 卷驱动用户指南](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)。 {{< note >}} -如果不使用外部静态驱动来管理卷的生命周期，则用户需要手动清理和删除 local 类型的持久卷。 +如果不使用外部静态驱动来管理卷的生命周期，用户需要手动清理和删除 local 类型的持久卷。 {{< /note >}} -### nfs {#nfs} +### nfs -`nfs` 卷能将 NFS (网络文件系统) 挂载到您的 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`nfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 -这意味着 `nfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 +`nfs` 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`nfs` 卷的内容在删除 Pod +时会被保存，卷只是被卸载。 +这意味着 `nfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 {{< caution >}} -在您使用 NFS 卷之前，必须运行自己的 NFS 服务器并将目标 share 导出备用。 +在使用 NFS 卷之前，你必须运行自己的 NFS 服务器并将目标 share 导出备用。 {{< /caution >}} -`persistentVolumeClaim` 卷用来将[持久卷](/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。 -持久卷是用户在不知道特定云环境细节的情况下"申领"持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。 +`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume） +挂载到 Pod 中。 +持久卷申领（PersistentVolumeClaim）是用户在不知道特定云环境细节的情况下"申领"持久存储 +（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。 +更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/)。 -更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/) +### portworxVolume {#portworxvolume} -### projected {#projected} + +`portworxVolume` 是一个可伸缩的块存储层，能够以超融合（hyperconverged）的方式与 Kubernetes 一起运行。 +[Portworx](https://portworx.com/use-case/kubernetes-storage/) 支持对服务器上存储的指纹处理、 +基于存储能力进行分层以及跨多个服务器整合存储容量。 +Portworx 可以以 in-guest 方式在虚拟机中运行，也可以在裸金属 Linux 节点上运行。 + + +`portworxVolume` 类型的卷可以通过 Kubernetes 动态创建，也可以预先配备并在 +Kubernetes Pod 内引用。 +下面是一个引用预先配备的 PortworxVolume 的示例 Pod： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # 此 Portworx 卷必须已经存在 + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< note >}} + +在 Pod 中使用 portworxVolume 之前，你要确保有一个名为 `pxvol` 的 PortworxVolume 存在。 +{{< /note >}} + + + +更多详情可以参考 [Portworx 卷](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md)。 + +### projected - `projected` 卷类型能将若干现有的卷来源映射到同一目录上。 目前，可以映射的卷来源类型如下： @@ -1218,27 +1267,14 @@ Currently, the following types of volume sources can be projected: All sources are required to be in the same namespace as the Pod. For more details, see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). --> - 所有的卷来源需要和 Pod 处于相同的命名空间。 更多详情请参考[一体化卷设计文档](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)。 -服务帐户令牌的映射是 Kubernetes 1.11 版本中引入的一个功能，并在 1.12 版本中被提升为 Beta 功能。 -若要在 1.11 版本中启用此特性，需要显式设置 `TokenRequestProjection` -[功能开关](/zh/docs/reference/command-line-tools-reference/feature-gates/) 为 True。 - - - -#### 包含 secret、downwardAPI 和 configmap 的 Pod 示例如下： +#### 包含 Secret、downwardAPI 和 configMap 的 Pod 示例 {#example-configuration-secret-downwardapi-configmap} ```yaml apiVersion: v1 @@ -1279,10 +1315,10 @@ spec: ``` -带有非默认许可模式设置的多个 secret 的 Pod 示例如下： +下面是一个带有非默认访问权限设置的多个 secret 的 Pod 示例： ```yaml apiVersion: v1 @@ -1323,12 +1359,11 @@ parameters are nearly the same with two exceptions: volume source. However, as illustrated above, you can explicitly set the `mode` for each individual projection. --> +每个被投射的卷来源都在规约中的 `sources` 内列出。参数几乎相同，除了两处例外： -每个被投射的卷来源都在 spec 中的 `sources` 内列出。 -参数几乎相同，除了两处例外： - -* 对于 secret，`secretName` 字段已被变更为 `name` 以便与 ConfigMap 命名一致。 -* `defaultMode` 只能根据投射级别指定，而不是针对每个卷来源指定。不过，如上所述，您可以显式地为每个投射项设置 `mode` 值。 +* 对于 `secret`，`secretName` 字段已被变更为 `name` 以便与 ConfigMap 命名一致。 +* `defaultMode` 只能在整个投射卷级别指定，而无法针对每个卷来源指定。 + 不过，如上所述，你可以显式地为每个投射项设置 `mode` 值。 - 示例 Pod 具有包含注入服务帐户令牌的映射卷。 -例如，这个令牌可以被 Pod 容器用来访问 Kubernetes API服务器。 +该令牌可以被 Pod 中的容器用来访问 Kubernetes API 服务器。 `audience` 字段包含令牌的预期受众。 令牌的接收者必须使用令牌的受众中指定的标识符来标识自己，否则应拒绝令牌。 此字段是可选的，默认值是 API 服务器的标识符。 @@ -1380,142 +1414,91 @@ is optional and it defaults to the identifier of the API server. - -`expirationSeconds` 是服务帐户令牌的有效期。 +`expirationSeconds` 是服务帐户令牌的有效期时长。 默认值为 1 小时，必须至少 10 分钟（600 秒）。 -管理员还可以通过指定 API 服务器的 `--service-account-max-token-expiration` 选项来限制其最大值。 +管理员还可以通过设置 API 服务器的 `--service-account-max-token-expiration` 选项来 +限制其最大值。 `path` 字段指定相对于映射卷的挂载点的相对路径。 {{< note >}} 使用投射卷源作为 [subPath](#using-subpath) 卷挂载的容器将不会接收这些卷源的更新。 {{< /note >}} -### portworxVolume {#portworxvolume} - - - -`portworxVolume` 是一个可伸缩的块存储层，能够以超聚合（hyperconverged）的方式与 Kubernetes 一起运行。 -[Portworx](https://portworx.com/use-case/kubernetes-storage/) 支持对服务器上存储的指纹处理、基于存储能力进行分层以及跨多个服务器整合存储容量。 -Portworx 可以以 in-guest 方式在虚拟机中运行，也可以在裸金属 Linux 节点上运行。 - - - -`portworxVolume` 类型的卷可以通过 Kubernetes 动态创建，也可以在 Kubernetes Pod 内预先供应和引用。 -下面是一个引用预先配置的 PortworxVolume 的示例 Pod： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: test-portworx-volume-pod -spec: - containers: - - image: k8s.gcr.io/test-webserver - name: test-container - volumeMounts: - - mountPath: /mnt - name: pxvol - volumes: - - name: pxvol - # This Portworx volume must already exist. - portworxVolume: - volumeID: "pxvol" - fsType: "" -``` - -{{< caution >}} - -在 Pod 中使用 portworxVolume 之前，请确保有一个名为 `pxvol` 的 PortworxVolume 存在。 -{{< /caution >}} - - - -更多详情和示例可以在[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md)找到。 - -### quobyte {#quobyte} +### quobyte -`quobyte` 卷允许将现有的 [Quobyte](https://www.quobyte.com) 卷挂载到您的 Pod 中。 +`quobyte` 卷允许将现有的 [Quobyte](https://www.quobyte.com) 卷挂载到你的 Pod 中。 -{{< caution >}} -在使用 Quobyte 卷之前，您首先要进行安装并创建好卷。 -{{< /caution >}} +{{< note >}} +在使用 Quobyte 卷之前，你首先要进行安装 Quobyte 并创建好卷。 +{{< /note >}} -Quobyte 支持{{< glossary_tooltip text="容器存储接口" term_id="csi" >}}。 +Quobyte 支持{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}。 推荐使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。 -Quobyte 的 GitHub 项目具有[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi)以及使用示例来部署 CSI 的 Quobyte。 +Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi) +及使用示例。 -### rbd {#rbd} +### rbd -`rbd` 卷允许将 [Rados 块设备](https://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 -这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 +`rbd` 卷允许将 [Rados 块设备](https://ceph.com/docs/master/rbd/rbd/) 卷挂载到你的 Pod 中. +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时 +会被保存，卷只是被卸载。 +这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 {{< caution >}} -在使用 RBD 之前，您必须安装运行 Ceph。 +在使用 RBD 之前，你必须安装运行 Ceph。 {{< /caution >}} - -RBD 的一个特点是它可以同时被多个用户以只读方式挂载。 -这意味着您可以用数据集预先填充卷，然后根据需要从尽可能多的 Pod 中并行地提供卷。 -不幸的是，RBD 卷只能由单个使用者以读写模式安装——不允许同时写入。 +RBD 的一个特性是它可以同时被多个用户以只读方式挂载。 +这意味着你可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 中并行地使用卷。 +不幸的是，RBD 卷只能由单个使用者以读写模式安装。不允许同时写入。 更多详情请参考 [RBD 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)。 -### scaleIO {#scaleio} + +### scaleIO （已弃用） {#scaleio} - ScaleIO 是基于软件的存储平台，可以使用现有硬件来创建可伸缩的、共享的而且是网络化的块存储集群。 -`scaleIO` 卷插件允许部署的 Pod 访问现有的 ScaleIO 卷（或者它可以动态地为持久卷申领提供新的卷，参见[ScaleIO 持久卷](/docs/concepts/storage/persistent-volumes/#scaleio))。 +`scaleIO` 卷插件允许部署的 Pod 访问现有的 ScaleIO 卷（或者它可以动态地为持久卷申领提供新的卷， +参见 [ScaleIO 持久卷](/zh/docs/concepts/storage/persistent-volumes/#scaleio)）。 -{{< caution >}} -在使用前，您必须有个安装完毕且运行正常的 ScaleIO 集群，并且创建好了存储卷。 -{{< /caution >}} +{{< note >}} +在使用前，你必须有个安装完毕且运行正常的 ScaleIO 集群，并且创建好了存储卷。 +{{< /note >}} - 更多详情，请参考 [ScaleIO 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio)。 -### secret {#secret} +### secret - -`secret` 卷用来给 Pod 传递敏感信息，例如密码。您可以将 secret 存储在 Kubernetes API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。 -`secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性（持久化的）存储器。 +`secret` 卷用来给 Pod 传递敏感信息，例如密码。你可以将 Secret 存储在 Kubernetes +API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。 +`secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性 +（持久化的）存储器。 -{{< caution >}} -使用前您必须在 Kubernetes API 中创建 secret。 -{{< /caution >}} +{{< note >}} +使用前你必须在 Kubernetes API 中创建 secret。 +{{< /note >}} {{< note >}} -容器以 [subPath](#using-subpath) 卷的方式挂载 Secret 时，它将感知不到 Secret 的更新。 +容器以 [subPath](#using-subpath) 卷挂载方式挂载 Secret 时，将感知不到 Secret 的更新。 {{< /note >}} -Secret 的更多详情请参考[这里](/zh/docs/concepts/configuration/secret/)。 +更多详情请参考[配置 Secrets](/zh/docs/concepts/configuration/secret/)。 ### storageOS {#storageos} @@ -1611,7 +1594,7 @@ Secret 的更多详情请参考[这里](/zh/docs/concepts/configuration/secret/) A `storageos` volume allows an existing [StorageOS](https://www.storageos.com) volume to be mounted into your Pod. --> -`storageos` 卷允许将现有的 [StorageOS](https://www.storageos.com) 卷挂载到您的 Pod 中。 +`storageos` 卷允许将现有的 [StorageOS](https://www.storageos.com) 卷挂载到你的 Pod 中。 -StorageOS 在 Kubernetes 环境中以容器的形式运行，这使得应用能够从 Kubernetes 集群中的任何节点访问本地或关联的存储。 -为应对节点失效状况，可以复制数据。 +StorageOS 在 Kubernetes 环境中以容器的形式运行，这使得应用能够从 Kubernetes +集群中的任何节点访问本地的或挂接的存储。为应对节点失效状况，可以复制数据。 若需提高利用率和降低成本，可以考虑瘦配置（Thin Provisioning）和数据压缩。 {{< caution >}} -您必须在每个希望访问 StorageOS 卷的或者将向存储资源池贡献存储容量的节点上运行 StorageOS 容器。 -有关安装说明，请参阅 [StorageOS 文档](https://docs.storageos.com)。 +你必须在每个希望访问 StorageOS 卷的或者将向存储资源池贡献存储容量的节点上运行 +StorageOS 容器。有关安装说明，请参阅 [StorageOS 文档](https://docs.storageos.com)。 {{< /caution >}} ```yaml @@ -1668,26 +1651,27 @@ spec: volumes: - name: redis-data storageos: - # The `redis-vol01` volume must already exist within StorageOS in the `default` namespace. + # `redis-vol01` 卷必须在 StorageOS 中存在，并位于 `default` 名字空间内 volumeName: redis-vol01 fsType: ext4 ``` -更多关于动态供应和持久卷申领的信息请参考 [StorageOS 示例](https://github.com/kubernetes/examples/blob/master/volumes/storageos)。 +关于 StorageOS 的进一步信息、动态供应和持久卷申领等等，请参考 +[StorageOS 示例](https://github.com/kubernetes/examples/blob/master/volumes/storageos)。 ### vsphereVolume {#vspherevolume} {{< note >}} -前提条件：配备了 vSphere 云驱动的 Kubernetes。云驱动的配置方法请参考 +你必须配置 Kubernetes 的 vSphere 云驱动。云驱动的配置方法请参考 [vSphere 使用指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。 {{< /note >}} @@ -1695,7 +1679,7 @@ configuration please refer [vSphere getting started guide](https://vmware.github A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The contents of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore. --> -`vsphereVolume` 用来将 vSphere VMDK 卷挂载到您的 Pod 中。 +`vsphereVolume` 用来将 vSphere VMDK 卷挂载到你的 Pod 中。 在卸载卷时，卷的内容会被保留。 vSphereVolume 卷类型支持 VMFS 和 VSAN 数据仓库。 @@ -1703,15 +1687,15 @@ vSphereVolume 卷类型支持 VMFS 和 VSAN 数据仓库。 You must create VMDK using one of the following methods before using with Pod. --> {{< caution >}} -在挂载到 Pod 之前，您必须用下列方式之一创建 VMDK。 +在挂载到 Pod 之前，你必须用下列方式之一创建 VMDK。 {{< /caution >}} -#### 创建 VMDK 卷 +#### 创建 VMDK 卷 {#creating-vmdk-volume} 选择下列方式之一创建 VMDK。 @@ -1737,9 +1721,9 @@ vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk -#### vSphere VMDK 配置示例 +#### vSphere VMDK 配置示例 {#vsphere-vmdk-configuration} ```yaml apiVersion: v1 @@ -1755,22 +1739,86 @@ spec: name: test-volume volumes: - name: test-volume - # This VMDK volume must already exist. + # 此 VMDK 卷必须已经存在 vsphereVolume: volumePath: "[DatastoreName] volumes/myDisk" fsType: ext4 ``` -更多示例可以在[这里](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)找到。 +进一步信息可参考[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。 +#### vSphere CSI 迁移 {#vsphere-csi-migration} -Sometimes, it is useful to share one volume for multiple uses in a single Pod. The `volumeMounts.subPath` -property can be used to specify a sub-path inside the referenced volume instead of its root. +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + + +当 `vsphereVolume` 的 `CSIMigration` 特性被启用时，所有插件操作都被从树内插件重定向到 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。 +为了使用此功能特性，必须在集群中安装[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)， +并启用 `CSIMigration` 和 `CSIMigrationvSphere` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 + + +此特性还要求 vSphere vCenter/ESXi 的版本至少为 7.0u1，且 HW 版本至少为 +VM version 15。 + +{{< note >}} + +vSphere CSI 驱动不支持内置 `vsphereVolume` 的以下 StorageClass 参数： + +* `diskformat` +* `hostfailurestotolerate` +* `forceprovisioning` +* `cachereservation` +* `diskstripes` +* `objectspacereservation` +* `iopslimit` + + +使用这些参数创建的现有卷将被迁移到 vSphere CSI 驱动，不过使用 vSphere +CSI 驱动所创建的新卷都不会理会这些参数。 + +{{< /note >}} + + +#### vSphere CSI 迁移完成 {#vsphere-csi-migration-complete} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + + +为了避免控制器管理器和 kubelet 加载 `vsphereVolume` 插件，你需要将 +`CSIMigrationVSphereComplete` 特性设置为 `true`。你还必须在所有工作节点上安装 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。 + + ## 使用 subPath {#using-path} @@ -1778,11 +1826,16 @@ property can be used to specify a sub-path inside the referenced volume instead `volumeMounts.subPath` 属性可用于指定所引用的卷内的子路径，而不是其根路径。 -下面是一个使用同一共享卷的、内含 LAMP 栈（Linux Apache Mysql PHP）的 Pod 的示例。 -HTML 内容被映射到卷的 `html` 文件夹，数据库将被存储在卷的 `mysql` 文件夹中： +下面例子展示了如何配置某包含 LAMP 堆栈（Linux Apache MySQL PHP）的 Pod 使用同一共享卷。 +此示例中的 `subPath` 配置不建议在生产环境中使用。 +PHP 应用的代码和相关数据映射到卷的 `html` 文件夹，MySQL 数据库存储在卷的 `mysql` 文件夹中： ```yaml apiVersion: v1 @@ -1813,28 +1866,30 @@ spec: ``` -### 使用带有扩展环境变量的 subPath +### 使用带有扩展环境变量的 subPath {#using-subpath-expanded-environment} -{{< feature-state for_k8s_version="v1.15" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="stable" >}} -使用 `subPathExpr` 字段从 Downward API 环境变量构造 `subPath` 目录名。 -在使用此特性之前，必须启用 `VolumeSubpathEnvExpansion` 功能开关。 +使用 `subPathExpr` 字段可以基于 Downward API 环境变量来构造 `subPath` 目录名。 `subPath` 和 `subPathExpr` 属性是互斥的。 -在这个示例中，Pod 基于 Downward API 中的 Pod 名称，使用 `subPathExpr` -在 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 -主机目录 `/var/log/pods/pod1` 挂载到了容器的 `/logs` 中。 +在这个示例中，Pod 使用 `subPathExpr` 来 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 +`hostPath` 卷采用来自 `downwardAPI` 的 Pod 名称生成目录名。 +宿主目录 `/var/log/pods/pod1` 被挂载到容器的 `/logs` 中。 ```yaml apiVersion: v1 @@ -1872,44 +1927,43 @@ medium of the filesystem holding the kubelet root dir (typically `hostPath` volume can consume, and no isolation between Containers or between Pods. --> -## 资源 +## 资源 {#resources} -`emptyDir` 卷的存储介质（磁盘、SSD 等）是由保存 kubelet 根目录（通常是 `/var/lib/kubelet`）的文件系统的介质确定。 -`emptyDir` 卷或者 `hostPath` 卷可以消耗的空间没有限制，容器之间或 Pod 之间也没有隔离。 +`emptyDir` 卷的存储介质（磁盘、SSD 等）是由保存 kubelet 数据的根目录 +（通常是 `/var/lib/kubelet`）的文件系统的介质确定。 +Kubernetes 对 `emptyDir` 卷或者 `hostPath` 卷可以消耗的空间没有限制， +容器之间或 Pod 之间也没有隔离。 -将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用 -[resource](/zh/docs/concepts/configuration/manage-resources-containers/) -规约来请求一定量的空间， -并且能够为具有多种介质类型的集群选择要使用的介质类型。 +要了解如何使用资源规约来请求空间，可参考 +[如何管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。 + +## 树外（Out-of-Tree）卷插件 {#out-of-tree-volume-plugins} -## Out-of-Tree 卷插件 - -Out-of-Tree 卷插件包括容器存储接口（CSI）和 FlexVolume。 +Out-of-Tree 卷插件包括 +{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} (CSI) +和 FlexVolume。 它们使存储供应商能够创建自定义存储插件，而无需将它们添加到 Kubernetes 代码仓库。 - -在引入 CSI 和 FlexVolume 之前，所有卷插件（如上面列出的卷类型）都是 "in-tree" 的， -这意味着它们是与 Kubernetes 的核心组件一同构建、链接、编译和交付的，并且这些插件都扩展了 Kubernetes 的核心 API。 +以前，所有卷插件（如上面列出的卷类型）都是“树内（In-Tree）”的。 +“树内”插件是与 Kubernetes 的核心组件一同构建、链接、编译和交付的。 这意味着向 Kubernetes 添加新的存储系统（卷插件）需要将代码合并到 Kubernetes 核心代码库中。 +CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署 +（安装）在 Kubernetes 集群上。 -CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署（安装）在 Kubernetes 集群上。 - -对于希望创建 out-of-tree 卷插件的存储供应商，请参考[这个 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)。 +对于希望创建树外（Out-Of-Tree）卷插件的存储供应商，请参考 +[卷插件常见问题](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)。 ### CSI -{{< feature-state for_k8s_version="v1.10" state="beta" >}} - - [容器存储接口](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) 为容器编排系统（如 Kubernetes）定义标准接口，以将任意存储系统暴露给它们的容器工作负载。 @@ -1944,17 +1996,14 @@ Please read the [CSI design proposal](https://github.com/kubernetes/community/bl CSI support was introduced as alpha in Kubernetes v1.9, moved to beta in Kubernetes v1.10, and is GA in Kubernetes v1.13. --> - 更多详情请阅读 [CSI 设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)。 -CSI 的支持在 Kubernetes v1.9 中作为 alpha 特性引入，在 Kubernetes v1.10 中转为 beta 特性，并在 Kubernetes v1.13 正式 GA。 - {{< note >}} -Kubernetes v1.13中不支持 CSI 规范版本0.2和0.3，并将在以后的版本中删除。 +Kubernetes v1.13 废弃了对 CSI 规范版本 0.2 和 0.3 的支持，并将在以后的版本中删除。 {{< /note >}} {{< note >}} -CSI驱动程序可能并非在所有Kubernetes版本中都兼容。 -请查看特定CSI驱动程序的文档，以获取每个 Kubernetes 版本所支持的部署步骤以及兼容性列表。 +CSI 驱动可能并非兼容所有的 Kubernetes 版本。 +请查看特定 CSI 驱动的文档，以了解各个 Kubernetes 版本所支持的部署步骤以及兼容性列表。 {{< /note >}} +一旦在 Kubernetes 集群上部署了 CSI 兼容卷驱动程序，用户就可以使用 `csi` 卷类型来 +挂接、挂载 CSI 驱动所提供的卷。 + +`csi` 卷可以在 Pod 中以三种方式使用： + +* 通过 PersistentVolumeClaim(#persistentvolumeclaim) 对象引用 +* 使用[一般性的临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) + （Alpha 特性） +* 使用 [CSI 临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)， + 前提是驱动支持这种用法（Beta 特性） + + - -一旦在 Kubernetes 集群上部署了 CSI 兼容卷驱动程序，用户就可以使用 `csi` 卷类型来关联、挂载 CSI 驱动程序暴露出来的卷。 - -`csi` 卷类型不支持来自 Pod 的直接引用，只能通过 `PersistentVolumeClaim` 对象在 Pod 中引用。 - 存储管理员可以使用以下字段来配置 CSI 持久卷： - -- `driver`：指定要使用的卷驱动程序名称的字符串值。 - 这个值必须与 CSI 驱动程序在 `GetPluginInfoResponse` 中返回的值相对应；该接口定义在 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)中。 - Kubernetes 使用所给的值来标识要调用的 CSI 驱动程序；CSI 驱动程序也使用该值来辨识哪些 PV 对象属于该 CSI 驱动程序。 +- `driver`：指定要使用的卷驱动名称的字符串值。 + 这个值必须与 CSI 驱动程序在 `GetPluginInfoResponse` 中返回的值相对应； + 该接口定义在 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)中。 + Kubernetes 使用所给的值来标识要调用的 CSI 驱动程序；CSI 驱动程序也使用该值来辨识 + 哪些 PV 对象属于该 CSI 驱动程序。 - `volumeHandle`：唯一标识卷的字符串值。 - 该值必须与CSI 驱动程序在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应；接口定义在 [CSI spec](https://github.com/container-storageinterface/spec/blob/master/spec.md#createvolume) 中。 + 该值必须与 CSI 驱动在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应； + 接口定义在 [CSI spec](https://github.com/container-storageinterface/spec/blob/master/spec.md#createvolume) 中。 在所有对 CSI 卷驱动程序的调用中，引用该 CSI 卷时都使用此值作为 `volume_id` 参数。 -- `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置该卷为只读。 - 默认值是 false。 - 该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动程序。 +- `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置 + 该卷为只读。默认值是 false。 + 该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动。 - - `volumeAttributes`：一个字符串到字符串的映射表，用来设置卷的静态属性。 - 该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes` 字段的映射相对应；[CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。 - 该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和 `NodePublishVolumeRequest` 中的 `volume_attributes` 字段传递给 CSI 驱动。 + 该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes` + 字段的映射相对应； + [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。 + 该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和 + `NodePublishVolumeRequest` 中的 `volume_attributes` 字段传递给 CSI 驱动。 -- `controllerPublishSecretRef`：对包含敏感信息的 secret 对象的引用；该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 `ControllerUnpublishVolume` 调用。 - 此字段是可选的；在不需要 secret 时可以是空的。 - 如果 secret 对象包含多个 secret，则所有的 secret 都会被传递。 +- `controllerPublishSecretRef`：对包含敏感信息的 Secret 对象的引用； + 该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 + `ControllerUnpublishVolume` 调用。 + 此字段是可选的；在不需要 Secret 时可以是空的。 + 如果 Secret 对象包含多个 Secret 条目，则所有的 Secret 条目都会被传递。 -- `nodeStageSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI `NodeStageVolume` 调用。 - 此字段是可选的，如果不需要 secret，则可能是空的。 - 如果 secret 对象包含多个 secret，则传递所有 secret。 +- `nodeStageSecretRef`：对包含敏感信息的 Secret 对象的引用。 + 该信息会传递给 CSI 驱动来完成 CSI `NodeStageVolume` 调用。 + 此字段是可选的，如果不需要 Secret，则可能是空的。 + 如果 Secret 对象包含多个 Secret 条目，则传递所有 Secret 条目。 -- `nodePublishSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI ``NodePublishVolume` 调用。 - 此字段是可选的，如果不需要 secret，则可能是空的。 - 如果 secret 对象包含多个 secret，则传递所有 secret。 +- `nodePublishSecretRef`：对包含敏感信息的 Secret 对象的引用。 + 该信息传递给 CSI 驱动来完成 CSI `NodePublishVolume` 调用。 + 此字段是可选的，如果不需要 Secret，则可能是空的。 + 如果 Secret 对象包含多个 Secret 条目，则传递所有 Secret 条目。 -#### CSI 原始块卷支持 +#### CSI 原始块卷支持 {#csi-raw-block-volume-support} -{{< feature-state for_k8s_version="v1.14" state="beta" >}} +{{< feature-state for_k8s_version="v1.18" state="stable" >}} - -从 1.11 版本开始，CSI 引入了对原始块卷的支持。该特性依赖于在 Kubernetes 的之前版本中引入的原始块卷（Raw Block Volume）功能。 -该特性将使具有外部 CSI 驱动程序的供应商能够在 Kubernetes 工作负载中实现原始块卷支持。 +具有外部 CSI 驱动程序的供应商能够在 Kubernetes 工作负载中实现原始块卷支持。 - -CSI块卷支持功能已启用，但默认情况下启用。必须为此功能启用的两个功能是“ BlockVolume”和“ CSIBlockVolume”。 - -``` ---feature-gates=BlockVolume=true,CSIBlockVolume=true -``` - -学习怎样[安装您的带有块卷支持的 PV/PVC](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 +你可以和以前一样，安装自己的 +[带有原始块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)， +采用 CSI 对此过程没有影响。 - -#### CSI临时卷 +#### CSI 临时卷 {#csi-ephemeral-volumes} {{< feature-state for_k8s_version="v1.16" state="beta" >}} - -此功能使 CSI 卷可以直接嵌入 Pod 规范中，而不是 PersistentVolume 中。 以这种方式指定的卷是临时的，不会在 Pod 重新启动后持续存在。 - -实例： - -```yaml -kind: Pod -apiVersion: v1 -metadata: - name: my-csi-app -spec: - containers: - - name: my-frontend - image: busybox - volumeMounts: - - mountPath: "/data" - name: my-csi-inline-vol - command: [ "sleep", "1000000" ] - volumes: - - name: my-csi-inline-vol - csi: - driver: inline.storage.kubernetes.io - volumeAttributes: - foo: bar -``` +你可以直接在 Pod 规约中配置 CSI 卷。采用这种方式配置的卷都是临时卷， +无法在 Pod 重新启动后继续存在。 +进一步的信息可参阅[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)。 - -此功能需要启用 CSIInlineVolume 功能门。 从Kubernetes 1.16开始默认启用它。 - -CSI 临时卷仅由一部分 CSI 驱动程序支持。 请在[此处](https://kubernetes-csi.github.io/docs/drivers.html)查看 CSI 驱动程序列表。 - - +有关如何开发 CSI 驱动的更多信息，请参考 [kubernetes-csi 文档](https://kubernetes-csi.github.io/docs/)。 + + +#### 从树内插件迁移到 CSI 驱动程序 {#migrating-to-csi-drivers-from-in-tree-plugins} -# 开发人员资源 -有关如何开发 CSI 驱动程序的更多信息，请参考[kubernetes-csi文档](https://kubernetes-csi.github.io/docs/) - -#### 从 in-tree 插件迁移到 CSI 驱动程序 - -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} +启用 `CSIMigration` 功能后，针对现有树内插件的操作会被重定向到相应的 CSI 插件 +（应已安装和配置）。 +因此，操作员在过渡到取代树内插件的 CSI 驱动时，无需对现有存储类、PV 或 PVC +（指树内插件）进行任何配置更改。 -启用 CSI 迁移功能后，会将针对现有 in-tree 插件的操作定向到相应的 CSI 插件（应安装和配置）。 -该功能实现了必要的转换逻辑和填充以无缝方式重新路由操作。 因此，操作员在过渡到取代树内插件的CSI驱动程序时，无需对现有存储类，PV 或 PVC（指 in-tree 插件)进行任何配置更改。 -在 Alpha 状态下，受支持的操作和功能包括供应/删除，附加/分离，安装/卸载和调整卷大小。 -上面的 "卷类型" 部分列出了支持 CSI 迁移并已实现相应 CSI 驱动程序的树内插件。 +所支持的操作和功能包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、 +挂载（Mount）/卸载（Unmount）和调整卷大小。 -### FlexVolume {#flexVolume} +上面的[卷类型](#volume-types)节列出了支持 `CSIMigration` 并已实现相应 CSI +驱动程序的树内插件。 + +### flexVolume -FlexVolume 是一个自 1.2 版本（在 CSI 之前）以来在 Kubernetes 中一直存在的 out-of-tree 插件接口。 +FlexVolume 是一个自 1.2 版本（在 CSI 之前）以来在 Kubernetes 中一直存在的树外插件接口。 它使用基于 exec 的模型来与驱动程序对接。 -用户必须在每个节点（在某些情况下是主节点）上的预定义卷插件路径中安装 FlexVolume 驱动程序可执行文件。 +用户必须在每个节点（在某些情况下是主控节点）上的预定义卷插件路径中安装 +FlexVolume 驱动程序可执行文件。 -Pod 通过 `flexvolume` in-tree 插件与 Flexvolume 驱动程序交互。 -更多详情请参考[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)。 +Pod 通过 `flexvolume` 树内插件与 Flexvolume 驱动程序交互。 +更多详情请参考 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 示例。 +## 挂载卷的传播 {#mount-propagation} -## 挂载卷的传播 +挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器， +甚至共享到同一节点上的其他 Pod。 -挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器，甚至共享到同一节点上的其他 Pod。 - -卷的挂载传播特性由 Container.volumeMounts 中的 `mountPropagation` 字段控制。 +卷的挂载传播特性由 `Container.volumeMounts` 中的 `mountPropagation` 字段控制。 它的值包括： - * `None` - 此卷挂载将不会感知到主机后续在此卷或其任何子目录上执行的挂载变化。 +* `None` - 此卷挂载将不会感知到主机后续在此卷或其任何子目录上执行的挂载变化。 类似的，容器所创建的卷挂载在主机上是不可见的。这是默认模式。 - 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)中描述的 `private` 挂载传播选项。 + + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + 中描述的 `private` 挂载传播选项。 - * `HostToContainer` - 此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。 +* `HostToContainer` - 此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。 换句话说，如果主机在此挂载卷中挂载任何内容，容器将能看到它被挂载在那里。 - 类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容，挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。 + 类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容， + 挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。 - 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rslave` 挂载传播选项。 + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + 中描述的 `rslave` 挂载传播选项。 - - * `Bidirectional` - 这种卷挂载和 `HostToContainer` 挂载表现相同。 - - 另外，容器创建的卷挂载将被传播回至主机和使用同一卷的所有 Pod 的所有容器。 - - 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rshared` 挂载传播选项。 - - -{{< caution >}} -`Bidirectional` 形式的挂载传播可能比较危险。 -它可以破坏主机操作系统，因此它只被允许在特权容器中使用。 -强烈建议您熟悉 Linux 内核行为。 -此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。 -{{< /caution >}} +* `Bidirectional` - 这种卷挂载和 `HostToContainer` 挂载表现相同。 + 另外，容器创建的卷挂载将被传播回至主机和使用同一卷的所有 Pod 的所有容器。 + + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + 中描述的 `rshared` 挂载传播选项。 + + + {{< warning >}} + `Bidirectional` 形式的挂载传播可能比较危险。 + 它可以破坏主机操作系统，因此它只被允许在特权容器中使用。 + 强烈建议你熟悉 Linux 内核行为。 + 此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。 + {{< /warning >}} -### 配置 +### 配置 {#configuration} -在某些部署环境中，挂载传播正常工作前，必须在 Docker 中正确配置挂载共享（mount share），如下所示。 +在某些部署环境中，挂载传播正常工作前，必须在 Docker 中正确配置挂载共享（mount share）， +如下所示。 -编辑您的 Docker `systemd` 服务文件，按下面的方法设置 `MountFlags`： +编辑你的 Docker `systemd` 服务文件，按下面的方法设置 `MountFlags`： ```shell MountFlags=shared ``` + @@ -2330,14 +2364,12 @@ sudo systemctl daemon-reload sudo systemctl restart docker ``` - - ## {{% heading "whatsnext" %}} -* 参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 +参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md index 76a6199865..75000a7708 100644 --- a/content/zh/docs/reference/_index.md +++ b/content/zh/docs/reference/_index.md @@ -29,13 +29,13 @@ This section of the Kubernetes documentation contains references. ## API 参考 -* [Kubernetes API 概述](/zh/docs/reference/using-api/api-overview/) - Kubernetes API 概述。 -* [Kubernetes API 参考 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [Kubernetes API 参考 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/)。 +* [使用 Kubernetes API ](/zh/docs/reference/using-api/) - Kubernetes 的 API 概述 +Kubernetes API 服务器验证并配置 API 对象的数据， +这些对象包括 pods、services、replicationcontrollers 等。 +API 服务器为 REST 操作提供服务，并为集群的共享状态提供前端， +所有其他组件都通过该前端进行交互。 ``` -kube-apiserver +kube-apiserver [flags] ``` -### 选项 -``` - - --admission-control stringSlice 控制资源进入集群的准入控制插件的顺序列表。逗号分隔的 NamespaceLifecycle 列表。（默认值 [AlwaysAdmit]） - - --admission-control-config-file string 包含准入控制配置的文件。 - - --advertise-address ip 向集群成员通知 apiserver 消息的 IP 地址。这个地址必须能够被集群中其他成员访问。如果 IP 地址为空，将会使用 --bind-address，如果未指定 --bind-address，将会使用主机的默认接口地址。 - - --allow-privileged 如果为 true, 将允许特权容器。 - - --anonymous-auth 启用到 API server 的安全端口的匿名请求。未被其他认证方法拒绝的请求被当做匿名请求。匿名请求的用户名为 system:anonymous，用户组名为 system:unauthenticated。（默认值 true） - - --apiserver-count int 集群中运行的 apiserver 数量，必须为正数。（默认值 1） - - --audit-log-maxage int 基于文件名中的时间戳，旧审计日志文件的最长保留天数。 - - --audit-log-maxbackup int 旧审计日志文件的最大保留个数。 - - --audit-log-maxsize int 审计日志被轮转前的最大兆字节数。 - - --audit-log-path string 如果设置该值，所有到 apiserver 的请求都将会被记录到这个文件。'-' 表示记录到标准输出。 - - --audit-policy-file string 定义审计策略配置的文件的路径。需要打开 'AdvancedAuditing' 特性开关。AdvancedAuditing 需要一个配置来启用审计功能。 - - --audit-webhook-config-file string 一个具有 kubeconfig 格式文件的路径，该文件定义了审计的 webhook 配置。需要打开 'AdvancedAuditing' 特性开关。 - - --audit-webhook-mode string 发送审计事件的策略。 Blocking 模式表示正在发送事件时应该阻塞服务器的响应。 Batch 模式使 webhook 异步缓存和发送事件。 Known 模式为 batch,blocking。（默认值 "batch") - - --authentication-token-webhook-cache-ttl duration 从 webhook 令牌认证者获取的响应的缓存时长。( 默认值 2m0s) - - --authentication-token-webhook-config-file string 包含 webhook 配置的文件，用于令牌认证，具有 kubeconfig 格式。API server 将查询远程服务来决定对 bearer 令牌的认证。 - - --authorization-mode string 在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表，包括：AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.（默认值 "AlwaysAllow"） - - --authorization-policy-file string 包含权限验证策略的 csv 文件，和 --authorization-mode=ABAC 一起使用，作用在安全端口上。 - - --authorization-webhook-cache-authorized-ttl duration 从 webhook 授权者获得的 'authorized' 响应的缓存时长。（默认值 5m0s） - - --authorization-webhook-cache-unauthorized-ttl duration 从 webhook 授权者获得的 'unauthorized' 响应的缓存时长。（默认值 30s） - - --authorization-webhook-config-file string 包含 webhook 配置的 kubeconfig 格式文件，和 --authorization-mode=Webhook 一起使用。API server 将查询远程服务来决定对 API server 安全端口的访问。 - - --azure-container-registry-config string 包含 Azure 容器注册表配置信息的文件的路径。 - - --bind-address ip 监听 --seure-port 的 IP 地址。被关联的接口必须能够被集群其它节点和 CLI/web 客户端访问。如果为空，则将使用所有接口（0.0.0.0）。（默认值 0.0.0.0） - - --cert-dir string 存放 TLS 证书的目录。如果提供了 --tls-cert-file 和 --tls-private-key-file 选项，该标志将被忽略。（默认值 "/var/run/kubernetes"） - - --client-ca-file string 如果设置此标志，对于任何请求，如果存包含 client-ca-file 中的 authorities 签名的客户端证书，将会使用客户端证书中的 CommonName 对应的身份进行认证。 - - --cloud-config string 云服务提供商配置文件路径。空字符串表示无配置文件 . - - --cloud-provider string 云服务提供商，空字符串表示无提供商。 - - --contention-profiling 如果已经启用 profiling，则启用锁竞争 profiling。 - - --cors-allowed-origins stringSlice CORS 的域列表，以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用 CORS. - - --delete-collection-workers int 用于 DeleteCollection 调用的工作者数量。这被用于加速 namespace 的清理。( 默认值 1) - - --deserialization-cache-size int 在内存中缓存的反序列化 json 对象的数量。 - - --enable-aggregator-routing 打开到 endpoints IP 的 aggregator 路由请求，替换 cluster IP。 - - --enable-garbage-collector 启用通用垃圾回收器 . 必须与 kube-controller-manager 对应的标志保持同步。 （默认值 true） - - --enable-logs-handler 如果为 true，则为 apiserver 日志功能安装一个 /logs 处理器。（默认值 true） - - --enable-swagger-ui 在 apiserver 的 /swagger-ui 路径启用 swagger ui。 - - --etcd-cafile string 用于保护 etcd 通信的 SSL CA 文件。 - - --etcd-certfile string 用于保护 etcd 通信的的 SSL 证书文件。 - - --etcd-keyfile string 用于保护 etcd 通信的 SSL 密钥文件 . - - --etcd-prefix string 附加到所有 etcd 中资源路径的前缀。 （默认值 "/registry"） - - --etcd-quorum-read 如果为 true, 启用 quorum 读。 - - --etcd-servers stringSlice 连接的 etcd 服务器列表 , 形式为（scheme://ip:port)，使用逗号分隔。 - - --etcd-servers-overrides stringSlice 针对单个资源的 etcd 服务器覆盖配置 , 以逗号分隔。 单个配置覆盖格式为 : group/resource#servers, 其中 servers 形式为 http://ip:port, 以分号分隔。 - - --event-ttl duration 事件驻留时间。（默认值 1h0m0s) - - --enable-bootstrap-token-auth 启用此选项以允许 'kube-system' 命名空间中的 'bootstrap.kubernetes.io/token' 类型密钥可以被用于 TLS 的启动认证。 - - --experimental-encryption-provider-config string 包含加密提供程序的配置的文件，该加密提供程序被用于在 etcd 中保存密钥。 - - --external-hostname string 为此 master 生成外部 URL 时使用的主机名 ( 例如 Swagger API 文档 )。 - - --feature-gates mapStringBool 一个描述 alpha/experimental 特性开关的键值对列表。 选项包括 : -Accelerators=true|false (ALPHA - default=false) -AdvancedAuditing=true|false (ALPHA - default=false) -AffinityInAnnotations=true|false (ALPHA - default=false) -AllAlpha=true|false (ALPHA - default=false) -AllowExtTrafficLocalEndpoints=true|false (default=true) -AppArmor=true|false (BETA - default=true) -DynamicKubeletConfig=true|false (ALPHA - default=false) -DynamicVolumeProvisioning=true|false (ALPHA - default=true) -ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false) -ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false) -LocalStorageCapacityIsolation=true|false (ALPHA - default=false) -PersistentLocalVolumes=true|false (ALPHA - default=false) -RotateKubeletClientCertificate=true|false (ALPHA - default=false) -RotateKubeletServerCertificate=true|false (ALPHA - default=false) -StreamingProxyRedirects=true|false (BETA - default=true) -TaintBasedEvictions=true|false (ALPHA - default=false) - - --google-json-key string 用于认证的 Google Cloud Platform 服务账号的 JSON 密钥。 - - --insecure-allow-any-token username/group1,group2 如果设置该值 , 你的服务将处于非安全状态。任何令牌都将会被允许，并将从令牌中把用户信息解析成为 username/group1,group2。 - - --insecure-bind-address ip 用于监听 --insecure-port 的 IP 地址 ( 设置成 0.0.0.0 表示监听所有接口 )。（默认值 127.0.0.1) - - --insecure-port int 用于监听不安全和为认证访问的端口。这个配置假设你已经设置了防火墙规则，使得这个端口不能从集群外访问。对集群的公共地址的 443 端口的访问将被代理到这个端口。默认设置中使用 nginx 实现。（默认值 8080） - - --kubelet-certificate-authority string 证书 authority 的文件路径。 - - --kubelet-client-certificate string 用于 TLS 的客户端证书文件路径。 - - --kubelet-client-key string 用于 TLS 的客户端证书密钥文件路径 . - - --kubelet-https 为 kubelet 启用 https。 （默认值 true） - - --kubelet-preferred-address-types stringSlice 用于 kubelet 连接的首选 NodeAddressTypes 列表。 ( 默认值[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP]) - - --kubelet-read-only-port uint 已废弃 : kubelet 端口 . （默认值 10255） - - --kubelet-timeout duration kubelet 操作超时时间。（默认值 - 5s） - - --kubernetes-service-node-port int 如果不为 0，Kubernetes master 服务（用于创建 / 管理 apiserver）将会使用 NodePort 类型，并将这个值作为端口号。如果为 0，Kubernetes master 服务将会使用 ClusterIP 类型。 - - --master-service-namespace string 已废弃 : 注入到 pod 中的 kubernetes master 服务的命名空间。（默认值 "default"） - - --max-connection-bytes-per-sec int 如果不为 0，每个用户连接将会被限速为该值（bytes/sec）。当前只应用于长时间运行的请求。 - - --max-mutating-requests-inflight int 在给定时间内进行中可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0 值表示没有限制。（默认值 200） - - --max-requests-inflight int 在给定时间内进行中不可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0 值表示没有限制。（默认值 400） - - --min-request-timeout int 一个可选字段，表示一个 handler 在一个请求超时前，必须保持它处于打开状态的最小秒数。当前只对监听请求 handler 有效，它基于这个值选择一个随机数作为连接超时值，以达到分散负载的目的（默认值 1800）。 - - --oidc-ca-file string 如果设置该值，将会使用 oidc-ca-file 中的任意一个 authority 对 OpenID 服务的证书进行验证，否则将会使用主机的根 CA 对其进行验证。 - - --oidc-client-id string 使用 OpenID 连接的客户端的 ID，如果设置了 oidc-issuer-url，则必须设置这个值。 - - --oidc-groups-claim string 如果提供该值，这个自定义 OpenID 连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。 - - --oidc-issuer-url string OpenID 颁发者 URL，只接受 HTTPS 方案。如果设置该值，它将被用于验证 OIDC JSON Web Token(JWT)。 - - --oidc-username-claim string 用作用户名的 OpenID 声明值。注意，不保证除默认 ('sub') 外的其他声明值的唯一性和不变性。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。 - - --profiling 在 web 接口 host:port/debug/pprof/ 上启用 profiling。（默认值 true） - - --proxy-client-cert-file string 当必须调用外部程序时，用于证明 aggregator 或者 kube-apiserver 的身份的客户端证书。包括代理到用户 api-server 的请求和调用 webhook 准入控制插件的请求。它期望这个证书包含一个来自于 CA 中的 --requestheader-client-ca-file 标记的签名。该 CA 在 kube-system 命名空间的 'extension-apiserver-authentication' configmap 中发布。从 Kube-aggregator 收到调用的组件应该使用该 CA 进行他们部分的双向 TLS 验证。 - - --proxy-client-key-file string 当必须调用外部程序时，用于证明 aggregator 或者 kube-apiserver 的身份的客户端证书密钥。包括代理到用户 api-server 的请求和调用 webhook 准入控制插件的请求。 - - --repair-malformed-updates 如果为 true，服务将会尽力修复更新请求以通过验证，例如：将更新请求 UID 的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后，可以关闭这个标志。 - - --requestheader-allowed-names stringSlice 使用 --requestheader-username-headers 指定的，允许在头部提供用户名的客户端证书通用名称列表。如果为空，任何通过 --requestheader-client-ca-file 中 authorities 验证的客户端证书都是被允许的。 - - --requestheader-client-ca-file string 在信任请求头中以 --requestheader-username-headers 指示的用户名之前，用于验证接入请求中客户端证书的根证书捆绑。 - - --requestheader-extra-headers-prefix stringSlice 用于检查的请求头的前缀列表。建议使用 X-Remote-Extra-。 - - --requestheader-group-headers stringSlice 用于检查群组的请求头列表。建议使用 X-Remote-Group. - - --requestheader-username-headers stringSlice 用于检查用户名的请求头列表。建议使用 X-Remote-User。 - - --runtime-config mapStringString 传递给 apiserver 用于描述运行时配置的键值对集合。 apis/ 键可以被用来打开 / 关闭特定的 api 版本。apis// 键被用来打开 / 关闭特定的资源 . api/all 和 api/legacy 键分别用于控制所有的和遗留的 api 版本 . - - --secure-port int 用于监听具有认证授权功能的 HTTPS 协议的端口。如果为 0，则不会监听 HTTPS 协议。 （默认值 6443) - - --service-account-key-file stringArray 包含 PEM 加密的 x509 RSA 或 ECDSA 私钥或公钥的文件，用于验证 ServiceAccount 令牌。如果设置该值，--tls-private-key-file 将会被使用。指定的文件可以包含多个密钥，并且这个标志可以和不同的文件一起多次使用。 - - --service-cluster-ip-range ipNet CIDR 表示的 IP 范围，服务的 cluster ip 将从中分配。 一定不要和分配给 nodes 和 pods 的 IP 范围产生重叠。 - - --ssh-keyfile string 如果不为空，在使用安全的 SSH 代理访问节点时，将这个文件作为用户密钥文件。 - - --storage-backend string 持久化存储后端。 选项为 : 'etcd3' ( 默认 ), 'etcd2'. - - --storage-media-type string 在存储中保存对象的媒体类型。某些资源或者存储后端可能仅支持特定的媒体类型，并且忽略该配置项。（默认值 "application/vnd.kubernetes.protobuf") - - --storage-versions string 按组划分资源存储的版本。 以 "group1/version1,group2/version2,..." 的格式指定。当对象从一组移动到另一组时 , 你可以指定 "group1=group2/v1beta1,group3/v1beta1,..." 的格式。你只需要传入你希望从结果中改变的组的列表。默认为从 KUBE_API_VERSIONS 环境变量集成而来，所有注册组的首选版本列表。 （默认值 "admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1") - - --target-ram-mb int apiserver 内存限制，单位为 MB( 用于配置缓存大小等 )。 - - --tls-ca-file string 如果设置该值，这个证书 authority 将会被用于从 Admission Controllers 过来的安全访问。它必须是一个 PEM 加密的合法 CA 捆绑包。此外 , 该证书 authority 可以被添加到以 --tls-cert-file 提供的证书文件中 . - - --tls-cert-file string 包含用于 HTTPS 的默认 x509 证书的文件。（如果有 CA 证书，则附加于 server 证书之后）。如果启用了 HTTPS 服务，并且没有提供 --tls-cert-file 和 --tls-private-key-file，则将为公共地址生成一个自签名的证书和密钥并保存于 /var/run/kubernetes 目录。 - - --tls-private-key-file string 包含匹配 --tls-cert-file 的 x509 证书私钥的文件。 - - --tls-sni-cert-key namedCertKey 一对 x509 证书和私钥的文件路径 , 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀 , 则将提取证书名。 非通配符版本优先于通配符版本 , 显示的域形式优先于证书中提取的名字。 对于多个密钥 / 证书对, 请多次使用 --tls-sni-cert-key。例如 : "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". （默认值[]) - - --token-auth-file string 如果设置该值，这个文件将被用于通过令牌认证来保护 API 服务的安全端口。 - - --version version[=true] 打印版本信息并退出。 - - --watch-cache 启用 apiserver 的监视缓存。（默认值 true） - - --watch-cache-sizes stringSlice 每种资源（pods, nodes 等）的监视缓存大小列表，以逗号分隔。每个缓存配置的形式为：resource#size，size 是一个数字。在 watch-cache 启用时生效。 -``` - -###### Auto generated by spf13/cobra on 11-Jul-2017 +## {{% heading "options" %}} + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--add-dir-header
+ +如果为 true，则将文件目录添加到日志消息的标题中 +
--admission-control-config-file string
+ +包含准入控制配置的文件。 +
--advertise-address ip
+ +向集群成员通知 apiserver 消息的 IP 地址。 +这个地址必须能够被集群中其他成员访问。 +如果 IP 地址为空，将会使用 --bind-address， +如果未指定 --bind-address，将会使用主机的默认接口地址。 +
--allow-privileged
+ +如果为 true, 将允许特权容器。[默认值=false] +
--alsologtostderr
+ +在向文件输出日志的同时，也将日志写到标准输出。 +
+ +--anonymous-auth     默认值：true +
+ +启用到 API server 的安全端口的匿名请求。 +未被其他认证方法拒绝的请求被当做匿名请求。 +匿名请求的用户名为 system:anonymous， +用户组名为 system:unauthenticated。 +
--api-audiences stringSlice
+ +API 的标识符。 +服务帐户令牌验证者将验证针对 API 使用的令牌是否已绑定到这些受众中的至少一个。 +如果配置了 --service-account-issuer 标志，但未配置此标志， +则此字段默认为包含发行者 URL 的单个元素列表。 +
+ +--apiserver-count int     默认值：1 +
+ +集群中运行的 apiserver 数量，必须为正数。 +（在启用 --endpoint-reconciler-type=master-count 时使用。） +
+ +--audit-log-batch-buffer-size int     默认值：10000 +
+ +批处理和写入之前用于存储事件的缓冲区大小。 +仅在批处理模式下使用。 +
+ +--audit-log-batch-max-size int     默认值：1 +
+ +批处理的最大大小。 仅在批处理模式下使用。 +
--audit-log-batch-max-wait duration
+ +强制写入尚未达到最大大小的批处理之前要等待的时间。 +仅在批处理模式下使用。 +
--audit-log-batch-throttle-burst int
+ +如果之前未使用 ThrottleQPS，则同时发送的最大请求数。 +仅在批处理模式下使用。 +
--audit-log-batch-throttle-enable
+ +是否启用了批量限制。 +仅在批处理模式下使用。 +
--audit-log-batch-throttle-qps float32
+ +每秒的最大平均批处理数。 +仅在批处理模式下使用。 +
+ +--audit-log-format string     默认值："json" +
+ +所保存的审计格式。 +"legacy" 表示每行一个事件的文本格式。"json" 表示结构化的 JSON 格式。 +已知格式为 legacy，json。 +
--audit-log-maxage int
+ +根据文件名中编码的时间戳保留旧审计日志文件的最大天数。 +
--audit-log-maxbackup int
+ +保留的旧审计日志文件的最大数量。 +
--audit-log-maxsize int
+ +轮换之前，审计日志文件的最大大小（以兆字节为单位）。 +
+ +--audit-log-mode string     默认值："blocking" +
+ +发送审计事件的策略。 +阻塞（blocking）表示发送事件应阻止服务器响应。 +批处理导致后端异步缓冲和写入事件。 +已知的模式是批处理（batch），阻塞（blocking），严格阻塞（blocking-strict）。 +
--audit-log-path string
+ +如果设置，则所有到达 apiserver 的请求都将记录到该文件中。 +"-" 表示标准输出。 +
--audit-log-truncate-enabled
+ +是否启用事件和批次截断。 +
+ +--audit-log-truncate-max-batch-size int     默认值：10485760 +
+ +发送到下层后端的批次的最大数据量。 +实际的序列化大小可能会增加数百个字节。 +如果一个批次超出此限制，则将其分成几个较小的批次。 +
+ +--audit-log-truncate-max-event-size int     默认值：102400 +
+ +发送到下层后端的批次的最大数据量。 +如果事件的大小大于此数字，则将删除第一个请求和响应， +并且没有减小足够大的程度，则将丢弃事件。 +
+ +--audit-log-version string     默认值："audit.k8s.io/v1" +
+ +用于序列化写入日志的审计事件的 API 组和版本。 +
--audit-policy-file string
+ +定义审计策略配置的文件的路径。 +
+ +--audit-webhook-batch-buffer-size int     默认值：10000 +
+ +划分批次和写入之前用于存储事件的缓冲区大小。 +仅在批处理模式下使用。 +
+ +--audit-webhook-batch-max-size int     默认值：400 +
+ +批次的最大大小。 +仅在批处理模式下使用。 +
+ +--audit-webhook-batch-max-wait duration     默认值：30s +
+ +强制写入尚未达到最大大小的批处理之前要等待的时间。 +仅在批处理模式下使用。 +
+ +--audit-webhook-batch-throttle-burst int     默认值：15 +
+ +如果之前未使用 ThrottleQPS，则同时发送的最大请求数。 +仅在批处理模式下使用。 +
+ +--audit-webhook-batch-throttle-enable     默认值：true +
+ +是否启用了批量限制。 +仅在批处理模式下使用。 +
+ +--audit-webhook-batch-throttle-qps float32     默认值：10 +
+ +每秒的最大平均批次数。 +仅在批处理模式下使用。 +
--audit-webhook-config-file string
+ +定义审计 webhook 配置的 kubeconfig 格式文件的路径。 +
+ +--audit-webhook-initial-backoff duration     默认值：10s +
+ +重试第一个失败的请求之前要等待的时间。 +
+ +--audit-webhook-mode string     默认值："batch" +
+ +发送审计事件的策略。 +阻止（Blocking）表示发送事件应阻止服务器响应。 +批处理导致后端异步缓冲和写入事件。 +已知的模式是批处理（batch），阻塞（blocking），严格阻塞（blocking-strict）。 +
--audit-webhook-truncate-enabled
+ +是否启用事件和批处理截断。 +
+ +--audit-webhook-truncate-max-batch-size int     默认值：10485760 +
+ +发送到下层后端的批次的最大数据量。 +实际的序列化大小可能会增加数百个字节。 +如果一个批次超出此限制，则将其分成几个较小的批次。 +
+ +--audit-webhook-truncate-max-event-size int     默认值：102400 +
+ +发送到下层后端的批次的最大数据量。 +如果事件的大小大于此数字，则将删除第一个请求和响应， +并且如果事件和事件的大小没有足够减小，则将丢弃事件。 +
+ +--audit-webhook-version string     默认值："audit.k8s.io/v1" +
+ +用于序列化写入 Webhook 的审计事件的 API 组和版本。 +
+ +--authentication-token-webhook-cache-ttl duration     默认值：2m0s +
+ +来自 Webhook 令牌身份验证器的缓存响应的持续时间。 +
--authentication-token-webhook-config-file string
+ +包含 Webhook 配置的文件，用于以 kubeconfig 格式进行令牌认证。 +API 服务器将查询远程服务，以对持有者令牌进行身份验证。 +
+ +--authentication-token-webhook-version string     默认值："v1beta1" +
+ +与 Webhook 之间交换 authentication.k8s.io TokenReview 时使用的 API 版本。 +
+ +--authorization-mode stringSlice     默认值：[AlwaysAllow] +
+ +在安全端口上进行鉴权的插件的顺序列表。 +逗号分隔的列表：AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node。 +
--authorization-policy-file string
+ +包含安全策略的文件，其内容为分行 JSON 格式， +在安全端口上与 --authorization-mode=ABAC 一起使用。 +
+ +--authorization-webhook-cache-authorized-ttl duration     默认值：5m0s +
+ +缓存来自 Webhook 鉴权组件的 “授权（authorized）” 响应的持续时间。 +
+ +--authorization-webhook-cache-unauthorized-ttl duration     默认值：30s +
+ +缓存来自 Webhook 鉴权模块的 “未授权（unauthorized）” 响应的持续时间。 +
--authorization-webhook-config-file string
+ +包含 Webhook 配置的文件，其格式为 kubeconfig， +与 --authorization-mode=Webhook 一起使用。 +API 服务器将查询远程服务，以对 API 服务器的安全端口的访问执行鉴权。 +
+ +--authorization-webhook-version string     默认值："v1beta1" +
+ +与 Webhook 之间交换 authorization.k8s.io SubjectAccessReview 时使用的 API 版本。 +
--azure-container-registry-config string
+ +包含 Azure 容器仓库配置信息的文件的路径。 +
+ +--bind-address ip     默认值：0.0.0.0 +
+ +监听 --secure-port 端口的 IP 地址。 +集群的其余部分以及 CLI/web 客户端必须可以访问关联的接口。 +如果为空白或未指定地址（0.0.0.0 或 ::），则将使用所有接口。 +
+ +--cert-dir string     默认值："/var/run/kubernetes" +
+ +TLS 证书所在的目录。 +如果提供了 --tls-cert-file 和 --tls-private-key-file，则将忽略此标志。 +
--client-ca-file string
+ +如果已设置，则使用与客户端证书的 CommonName 对应的标识对任何出示由 +client-ca 文件中的授权机构之一签名的客户端证书的请求进行身份验证。 +
--cloud-config string
+ +云厂商配置文件的路径。 +空字符串表示无配置文件。 +
--cloud-provider string
+ +云服务提供商。 +空字符串表示没有云厂商。 +
+ +--cloud-provider-gce-l7lb-src-cidrs cidrs     默认值：130.211.0.0/22,35.191.0.0/16 +
+ +在 GCE 防火墙中打开 CIDR，以进行 L7 LB 流量代理和运行状况检查 +
--contention-profiling
+ +如果启用了性能分析，则启用锁争用性能分析 +
--cors-allowed-origins stringSlice
+ +CORS 允许的来源清单，以逗号分隔。 +允许的来源可以是支持子域匹配的正则表达式。 +如果此列表为空，则不会启用 CORS。 +
+ +--default-not-ready-toleration-seconds int     默认值：300 +
+ +标明 notReady:NoExecute 的 tolerationSeconds， +默认情况下将其添加到尚未具有此容忍度的每个 pod 中。 +
+ +--default-unreachable-toleration-seconds int     默认值：300 +
+ +标明 unreachable:NoExecute 的 tolerationSeconds， +默认情况下将其添加到尚未具有此容忍度的每个 pod 中。 +
+ +--default-watch-cache-size int     默认值：100 +
+ +默认监听（watch）缓存大小。 +如果为零，则将为没有设置默认监视大小的资源禁用监视缓存。 +
+ +--delete-collection-workers int     默认值：1 +
+ +为 DeleteCollection 调用而产生的工作程序数。 +这些用于加速名字空间清理。 +
--disable-admission-plugins stringSlice
+ +尽管位于默认启用的插件列表中（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota）仍须被禁用的插件。 +
取值为逗号分隔的准入插件列表：AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook。 +
该标志中插件的顺序无关紧要。 +
--egress-selector-config-file string
+ +带有 apiserver 出站选择器配置的文件。 +
--enable-admission-plugins stringSlice
+ +除了默认启用的插件（NamespaceLifecycle、LimitRanger、ServiceAccount、TaintNodesByCondition、Priority、DefaultTolerationSeconds、DefaultStorageClass、StorageObjectInUseProtection、PersistentVolumeClaimResize、RuntimeClass、CertificateApproval、CertificateSigning、CertificateSubjectRestriction、DefaultIngressClass、MutatingAdmissionWebhook、ValidatingAdmissionWebhook、ResourceQuota）之外要启用的插件 +
取值为逗号分隔的准入插件列表：AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook +
该标志中插件的顺序无关紧要。 +
--enable-aggregator-routing
+ +允许聚合器将请求路由到端点 IP 而非集群 IP。 +
--enable-bootstrap-token-auth
+ +启用以允许将 "kube-system" 名字空间中类型为 "bootstrap.kubernetes.io/token" +的 Secret 用于 TLS 引导身份验证。 +
+ +--enable-garbage-collector     默认值：true +
+ +启用通用垃圾收集器。 +必须与 kube-controller-manager 的相应标志同步。 +
+ +--enable-priority-and-fairness     默认值：true +
+ +如果为 true 且启用了 APIPriorityAndFairness 特性门控， +请使用增强的处理程序替换 max-in-flight 处理程序， +以便根据优先级和公平性完成排队和调度。 +
--encryption-provider-config string
+ +包含加密提供程序配置信息的文件，用在 etcd 中所存储的 Secret 上。 +
+ +--endpoint-reconciler-type string     默认值："lease" +
+ +使用端点协调器（master-count, lease, none） +
--etcd-cafile string
+ +用于保护 etcd 通信的 SSL 证书颁发机构文件。 +
--etcd-certfile string
+ +用于保护 etcd 通信的 SSL 证书文件。 +
+ +--etcd-compaction-interval duration     默认值：5m0s +
+ +压缩请求的间隔。 +如果为0，则禁用来自 apiserver 的压缩请求。 +
+ +--etcd-count-metric-poll-period duration     默认值：1m0s +
+ +针对每种类型的资源数量轮询 etcd 的频率。 +0 禁用度量值收集。 +
+ +--etcd-db-metric-poll-interval duration     默认值：30s +
+ +轮询 etcd 和更新度量值的请求间隔。 +0 禁用度量值收集 +
--etcd-keyfile string
+ +用于保护 etcd 通信的 SSL 密钥文件。 +
+ +--etcd-prefix string     默认值："/registry" +
+ +要在 etcd 中所有资源路径之前添加的前缀。 +
--etcd-servers stringSlice
+ +要连接的 etcd 服务器列表（scheme://ip:port），以逗号分隔。 +
--etcd-servers-overrides stringSlice
+ +etcd 服务器针对每个资源的重载设置，以逗号分隔。 +单个替代格式：组/资源#服务器（group/resource#servers），其中服务器是 URL，以分号分隔。 +
+ +--event-ttl duration     默认值：1h0m0s +
+ +事件的保留时长。 +
--external-hostname string
+ +为此主机生成外部化 UR L时要使用的主机名（例如 Swagger API 文档或 OpenID 发现）。 +
--feature-gates mapStringBool
+ +一组 key=value 对，用来描述测试性/试验性功能的特性门控（Feature Gate）。可选项有： +
APIListChunking=true|false (BETA - 默认值=true) +
APIPriorityAndFairness=true|false (ALPHA - 默认值=false) +
APIResponseCompression=true|false (BETA - 默认值=true) +
AllAlpha=true|false (ALPHA - 默认值=false) +
AllBeta=true|false (BETA - 默认值=false) +
AllowInsecureBackendProxy=true|false (BETA - 默认值=true) +
AnyVolumeDataSource=true|false (ALPHA - 默认值=false) +
AppArmor=true|false (BETA - 默认值=true) +
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false) +
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false) +
CPUManager=true|false (BETA - 默认值=true) +
CRIContainerLogRotation=true|false (BETA - 默认值=true) +
CSIInlineVolume=true|false (BETA - 默认值=true) +
CSIMigration=true|false (BETA - 默认值=true) +
CSIMigrationAWS=true|false (BETA - 默认值=false) +
CSIMigrationAWSComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureDisk=true|false (BETA - 默认值=false) +
CSIMigrationAzureDiskComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureFileComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationGCE=true|false (BETA - 默认值=false) +
CSIMigrationGCEComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationOpenStack=true|false (BETA - 默认值=false) +
CSIMigrationOpenStackComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationvSphere=true|false (BETA - 默认值=false) +
CSIMigrationvSphereComplete=true|false (BETA - 默认值=false) +
CSIStorageCapacity=true|false (ALPHA - 默认值=false) +
CSIVolumeFSGroupPolicy=true|false (ALPHA - 默认值=false) +
ConfigurableFSGroupPolicy=true|false (ALPHA - 默认值=false) +
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false) +
DefaultPodTopologySpread=true|false (ALPHA - 默认值=false) +
DevicePlugins=true|false (BETA - 默认值=true) +
DisableAcceleratorUsageMetrics=true|false (ALPHA - 默认值=false) +
DynamicKubeletConfig=true|false (BETA - 默认值=true) +
EndpointSlice=true|false (BETA - 默认值=true) +
EndpointSliceProxying=true|false (BETA - 默认值=true) +
EphemeralContainers=true|false (ALPHA - 默认值=false) +
ExpandCSIVolumes=true|false (BETA - 默认值=true) +
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true) +
ExpandPersistentVolumes=true|false (BETA - 默认值=true) +
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false) +
GenericEphemeralVolume=true|false (ALPHA - 默认值=false) +
HPAScaleToZero=true|false (ALPHA - 默认值=false) +
HugePageStorageMediumSize=true|false (BETA - 默认值=true) +
HyperVContainer=true|false (ALPHA - 默认值=false) +
IPv6DualStack=true|false (ALPHA - 默认值=false) +
ImmutableEphemeralVolumes=true|false (BETA - 默认值=true) +
KubeletPodResources=true|false (BETA - 默认值=true) +
LegacyNodeRoleBehavior=true|false (BETA - 默认值=true) +
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true) +
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false) +
NodeDisruptionExclusion=true|false (BETA - 默认值=true) +
NonPreemptingPriority=true|false (BETA - 默认值=true) +
PodDisruptionBudget=true|false (BETA - 默认值=true) +
PodOverhead=true|false (BETA - 默认值=true) +
ProcMountType=true|false (ALPHA - 默认值=false) +
QOSReserved=true|false (ALPHA - 默认值=false) +
RemainingItemCount=true|false (BETA - 默认值=true) +
RemoveSelfLink=true|false (ALPHA - 默认值=false) +
RotateKubeletServerCertificate=true|false (BETA - 默认值=true) +
RunAsGroup=true|false (BETA - 默认值=true) +
RuntimeClass=true|false (BETA - 默认值=true) +
SCTPSupport=true|false (BETA - 默认值=true) +
SelectorIndex=true|false (BETA - 默认值=true) +
ServerSideApply=true|false (BETA - 默认值=true) +
ServiceAccountIssuerDiscovery=true|false (ALPHA - 默认值=false) +
ServiceAppProtocol=true|false (BETA - 默认值=true) +
ServiceNodeExclusion=true|false (BETA - 默认值=true) +
ServiceTopology=true|false (ALPHA - 默认值=false) +
SetHostnameAsFQDN=true|false (ALPHA - 默认值=false) +
StartupProbe=true|false (BETA - 默认值=true) +
StorageVersionHash=true|false (BETA - 默认值=true) +
SupportNodePidsLimit=true|false (BETA - 默认值=true) +
SupportPodPidsLimit=true|false (BETA - 默认值=true) +
Sysctls=true|false (BETA - 默认值=true) +
TTLAfterFinished=true|false (ALPHA - 默认值=false) +
TokenRequest=true|false (BETA - 默认值=true) +
TokenRequestProjection=true|false (BETA - 默认值=true) +
TopologyManager=true|false (BETA - 默认值=true) +
ValidateProxyRedirects=true|false (BETA - 默认值=true) +
VolumeSnapshotDataSource=true|false (BETA - 默认值=true) +
WarningHeaders=true|false (BETA - 默认值=true) +
WinDSR=true|false (ALPHA - 默认值=false) +
WinOverlay=true|false (ALPHA - 默认值=false) +
WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false) +
--goaway-chance float
+ +为防止 HTTP/2 客户端卡在单个 apiserver 上，可启用随机关闭连接（GOAWAY）。 +客户端的其他运行中请求将不会受到影响，并且客户端将重新连接， +可能会在再次通过负载平衡器后登陆到其他 apiserver 上。 +此参数设置将发送 GOAWAY 的请求的比例。 +具有单个 apiserver 或不使用负载平衡器的群集不应启用此功能。 +最小值为0（关闭），最大值为 .02（1/50 请求）； 建议使用 .001（1/1000）。 +
-h, --help
+ +kube-apiserver 的帮助命令 +
--http2-max-streams-per-connection int
+ +服务器为客户端提供的 HTTP/2 连接中最大流数的限制。 +零表示使用 golang 的默认值。 +
--kubelet-certificate-authority string
+ +证书颁发机构的证书文件的路径。 +
--kubelet-client-certificate string
+ +TLS 的客户端证书文件的路径。 +
--kubelet-client-key string
+ +TLS 客户端密钥文件的路径。 +
+ +--kubelet-preferred-address-types stringSlice     默认值：[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP] +
+ +用于 kubelet 连接的首选 NodeAddressTypes 列表。 +
+ +--kubelet-timeout duration     默认值：5s +
+ +kubelet 操作超时时间。 +
--kubernetes-service-node-port int
+ +如果非零，那么 Kubernetes 主服务（由 apiserver 创建/维护）将是 NodePort 类型，使用它作为端口的值。 +如果为零，则 Kubernetes 主服务将为 ClusterIP 类型。 +
--livez-grace-period duration
+ +此选项代表 apiserver 完成启动序列并生效所需的最长时间。 +从 apiserver 的启动时间到这段时间为止， +/livez 将假定未完成的启动后钩子将成功完成，因此返回 true。 +
+ +
+ +当日志机制执行到'文件 :N'时，生成堆栈跟踪 +
--log-dir string
+ +如果为非空，则在此目录中写入日志文件 +
--log-file string
+ +如果为非空，使用此日志文件 +
+ +--log-file-max-size uint     默认值：1800 +
+ +定义日志文件可以增长到的最大大小。单位为兆字节。 +如果值为 0，则最大文件大小为无限制。 +
+ +--log-flush-frequency duration     默认值：5s +
+ +两次日志刷新之间的最大秒数 +
+ +--logging-format string     默认值："text" +
+ +设置日志格式。允许的格式："text"，"json"。 +
非默认格式不支持以下标志：--add_dir_header、--alsologtostderr、--log_backtrace_at、--log_dir、--log_file、--log_file_max_size、--logtostderr、-skip_headers、-skip_log_headers、-stderrthreshold、-vmodule和--log-flush-frequency。 +
当前非默认选择为 alpha，并且会随时更改而不会发出警告。 +
c + +--logtostderr     默认值：true +
+ +在标准错误而不是文件中输出日志记录 +
+ +--master-service-namespace string     默认值："default" +
+ +已废弃：应该从其中将 Kubernetes 主服务注入到 Pod 中的名字空间。 +
--max-connection-bytes-per-sec int
+ +如果不为零，则将每个用户连接限制为该数（字节数/秒）。 +当前仅适用于长时间运行的请求。 +
+ +--max-mutating-requests-inflight int     默认值：200 +
+ +在给定时间内进行中变更类型请求的最大个数。 +当超过该值时，服务将拒绝所有请求。 +零表示无限制。 +
+ +--max-requests-inflight int     默认值：400 +
+ +在给定时间内进行中非变更类型请求的最大数量。 +当超过该值时，服务将拒绝所有请求。 +零表示无限制。 +
+ +--min-request-timeout int     默认值：1800 +
+ +可选字段，表示处理程序在请求超时前，必须保持其处于打开状态的最小秒数。 +当前只对监听（Watch）请求的处理程序有效，它基于这个值选择一个随机数作为连接超时值，以达到分散负载的目的。 +
--oidc-ca-file string
+ +如果设置该值，将会使用 oidc-ca-file 中的机构之一对 OpenID 服务的证书进行验证， +否则将会使用主机的根 CA 对其进行验证。 +
--oidc-client-id string
+ +OpenID 连接客户端的要使用的客户 ID，如果设置了 oidc-issuer-url，则必须设置这个值。 +
--oidc-groups-claim string
+ +如果提供该值，这个自定义 OpenID 连接声明将被用来设定用户组。 +该声明值需要是一个字符串或字符串数组。 +此标志为实验性的，请查阅身份认证相关文档进一步了解详细信息。 +
--oidc-groups-prefix string
+ +如果提供，则所有组都将以该值作为前缀，以防止与其他身份认证策略冲突。 +
--oidc-issuer-url string
+ +OpenID 颁发者 URL，只接受 HTTPS 方案。 +如果设置该值，它将被用于验证 OIDC JSON Web Token(JWT)。 +
--oidc-required-claim mapStringString
+ +描述 ID 令牌中必需声明的键值对。 +如果设置此值，则会验证 ID 令牌中存在与该声明匹配的值。 +重复此标志以指定多个声明。 +
+ +--oidc-signing-algs stringSlice     默认值：[RS256] +
+ +允许的 JOSE 非对称签名算法的逗号分隔列表。 +若 JWT 所带的 "alg" 标头值不在列表中，则该 JWT 将被拒绝。 +取值依据 RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1 定义。 +
+ +--oidc-username-claim string     默认值："sub" +
+ +要用作用户名的 OpenID 声明。 +请注意，除默认声明（"sub"）以外的其他声明不能保证是唯一且不可变的。 +此标志是实验性的，请参阅身份认证文档以获取更多详细信息。 +
--oidc-username-prefix string
+ +如果提供，则所有用户名都将以该值作为前缀。 +如果未提供，则除 "email" 之外的用户名声明都会添加颁发者 URL 作为前缀，以避免冲突。 +要略过添加前缀处理，请设置值为 "-"。 +
--permit-port-sharing
+ +如果为 true，则在绑定端口时将使用 SO_REUSEPORT， +这样多个实例可以绑定到同一地址和端口上。[默认值 = false] +
+ +--profiling     默认值：true +
+ +通过 Web 界面启用性能分析 host:port/debug/pprof/ +
--proxy-client-cert-file string
+ +当必须调用外部程序以处理请求时，用于证明聚合器或者 kube-apiserver 的身份的客户端证书。 +包括代理转发到用户 api-server 的请求和调用 Webhook 准入控制插件的请求。 +Kubernetes 期望此证书包含来自于 --requestheader-client-ca-file 标志中所给 CA 的签名。 +该 CA 在 kube-system 命名空间的 "extension-apiserver-authentication" ConfigMap 中公开。 +从 kube-aggregator 收到调用的组件应该使用该 CA 进行各自的双向 TLS 验证。 +
--proxy-client-key-file string
+ +当必须调用外部程序来处理请求时，用来证明聚合器或者 kube-apiserver 的身份的客户端私钥。 +这包括代理转发给用户 api-server 的请求和调用 Webhook 准入控制插件的请求。 +
+ +--request-timeout duration     默认值：1m0s +
+ +可选字段，指示处理程序在超时之前必须保持打开请求的持续时间。 +这是请求的默认请求超时，但对于特定类型的请求，可能会被 --min-request-timeout 等标志覆盖。 +
--requestheader-allowed-names stringSlice
+ +此值为客户端证书通用名称（Common Name）的列表；表中所列的表项可以用来提供用户名， +方式是使用 --requestheader-username-headers 所指定的头部。 +如果为空，能够通过 --requestheader-client-ca-file 中机构认证的客户端证书都是被允许的。 +
--requestheader-client-ca-file string
+ +在信任请求头中以 --requestheader-username-headers 指示的用户名之前， +用于验证接入请求中客户端证书的根证书包。 +警告：一般不要假定传入请求已被授权。 +
--requestheader-extra-headers-prefix stringSlice
+ +用于查验请求头部的前缀列表。建议使用 X-Remote-Extra-。 +
--requestheader-group-headers stringSlice
+ +用于查验用户组的请求头部列表。建议使用 X-Remote-Group。 +
--requestheader-username-headers stringSlice
+ +用于查验用户名的请求头头列表。建议使用 X-Remote-User。 +
--runtime-config mapStringString
+ +一组启用或禁用内置 API 的键值对。支持的选项包括： +
v1=true|false（针对核心 API 组） +
<group>/<version>=true|false（针对特定 API 组和版本，例如：apps/v1=true） +
api/all=true|false 控制所有 API 版本 +
api/ga=true|false 控制所有 v[0-9]+ API 版本 +
api/beta=true|false 控制所有 v[0-9]+beta[0-9]+ API 版本 +
api/alpha=true|false 控制所有 v[0-9]+alpha[0-9]+ API 版本 +
api/legacy 已弃用，并将在以后的版本中删除 +
+ +--secure-port int     默认值：6443 +
+ +带身份验证和鉴权机制的 HTTPS 服务端口。 +不能用 0 关闭。 +
--service-account-extend-token-expiration
+ +在生成令牌时，启用投射服务帐户到期时间扩展， +这有助于从旧版令牌安全地过渡到绑定的服务帐户令牌功能。 +如果启用此标志，则准入插件注入的令牌的过期时间将延长至 1 年，以防止过渡期间发生意外故障， +并忽略 service-account-max-token-expiration 的值。 +
--service-account-issuer {service-account-issuer}/.well-known/openid-configuration
+ +服务帐号令牌颁发者的标识符。 +颁发者将在已办法令牌的 "iss" 声明中检查此标识符。 +此值为字符串或 URI。 +如果根据 OpenID Discovery 1.0 规范检查此选项不是有效的 URI，则即使特性门控设置为 true， +ServiceAccountIssuerDiscovery 功能也将保持禁用状态。 +强烈建议该值符合 OpenID 规范：https://openid.net/specs/openid-connect-discovery-1_0.html。 +实践中，这意味着 service-account-issuer 取值必须是 HTTPS URL。 +还强烈建议此 URL 能够在 {service-account-issuer}/.well-known/openid-configuration +处提供 OpenID 发现文档。 +
--service-account-jwks-uri string
+ +覆盖 /.well-known/openid-configuration 提供的发现文档中 JSON Web 密钥集的 URI。 +如果发现文档和密钥集是通过 API 服务器外部 +（而非自动检测到或被外部主机名覆盖）之外的 URL 提供给依赖方的，则此标志很有用。 +仅在启用 ServiceAccountIssuerDiscovery 特性门控的情况下有效。 +
--service-account-key-file stringArray
+ +包含 PEM 编码的 x509 RSA 或 ECDSA 私钥或公钥的文件，用于验证 ServiceAccount 令牌。 +指定的文件可以包含多个键，并且可以使用不同的文件多次指定标志。 +如果未指定，则使用 --tls-private-key-file。 +提供 --service-account-signing-key 时必须指定。 +
+ +--service-account-lookup     默认值：true +
+ +如果为 true，则在身份认证时验证 etcd 中是否存在 ServiceAccount 令牌。 +
--service-account-max-token-expiration duration
+ +服务帐户令牌发布者创建的令牌的最长有效期。 +如果请求有效期大于此值的有效令牌请求，将使用此值的有效期颁发令牌。 +
--service-account-signing-key-file string
+ +包含服务帐户令牌颁发者当前私钥的文件的路径。 +颁发者将使用此私钥签署所颁发的 ID 令牌（需要启用 "TokenRequest" 特性门控）。 +
--service-cluster-ip-range string
+ +CIDR 表示的 IP 范围用来为服务分配集群 IP。 +此地址不得与指定给节点或 Pod 的任何 IP 范围重叠。 +
+ +--service-node-port-range portRange     默认值：30000-32767 +
+ +保留给具有 NodePort 可见性的服务的端口范围。 +例如："30000-32767"。范围的两端都包括在内。 +
--show-hidden-metrics-for-version string
+ +你要显示隐藏指标的先前版本。仅先前的次要版本有意义，不允许其他值。 +格式为 <major>.<minor>，例如："1.16"。 +这种格式的目的是确保您有机会注意到下一个版本是否隐藏了其他指标， +而不是在此之后将它们从发行版中永久删除时感到惊讶。 +
--shutdown-delay-duration duration
+ +延迟终止时间。在此期间，服务器将继续正常处理请求。 +端点 /healthz 和 /livez 将返回成功，但是 /readyz 立即返回失败。 +在此延迟过去之后，将开始正常终止。 +这可用于允许负载平衡器停止向该服务器发送流量。 +
--skip-headers
+ +如果为 true，日志消息中避免标题前缀 +
--skip-log-headers
+ +如果为 true，则在打开日志文件时避免标题 +
+ +--stderrthreshold severity     默认值：2 +
+ +将达到或超过此阈值的日志写到标准错误输出 +
--storage-backend string
+ +持久化存储后端。选项："etcd3"（默认）。 +
+ +--storage-media-type string     默认值："application/vnd.kubernetes.protobuf" +
+ +用于在存储中存储对象的媒体类型。 +某些资源或存储后端可能仅支持特定的媒体类型，并且将忽略此设置。 +
--tls-cert-file string
+ +包含用于 HTTPS 的默认 x509 证书的文件。（CA 证书（如果有）在服务器证书之后并置）。 +如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file， +为公共地址生成一个自签名证书和密钥，并将其保存到 --cert-dir 指定的目录中。 +
--tls-cipher-suites stringSlice
+ +服务器的密码套件的列表，以逗号分隔。如果省略，将使用默认的 Go 密码套件。 +
首选值：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_GCM_SHA256、TLS_RSA_WTLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_RC4_128_SHA。 +
--tls-min-version string
+ +支持的最低 TLS 版本。可能的值：VersionTLS10，VersionTLS11，VersionTLS12，VersionTLS13 +
--tls-private-key-file string
+ +包含匹配 --tls-cert-file 的 x509 证书私钥的文件。 +
+ +--tls-sni-cert-key namedCertKey     默认值：[] +
+ +一对 x509 证书和私钥文件路径，（可选）后缀为全限定域名的域名模式列表，可以使用带有通配符的前缀。 +域模式也允许使用 IP 地址，但仅当 apiserver 对客户端请求的IP地址具有可见性时，才应使用 IP。 +如果未提供域模式，则提取证书的名称。 +非通配符匹配优先于通配符匹配，显式域模式优先于提取出的名称。 +对于多个密钥/证书对，请多次使用 --tls-sni-cert-key。 +示例："example.crt,example.key" 或 "foo.crt,foo.key:*.foo.com,foo.com"。 +
--token-auth-file string
+ +如果设置该值，这个文件将被用于通过令牌认证来保护 API 服务的安全端口。 +
-v, --v Level
+ +日志级别详细程度的数字 +
--version version[=true]
+ +打印版本信息并退出 +
--vmodule moduleSpec
+ +以逗号分隔的 pattern=N 设置列表，用于文件过滤的日志记录 +
+ +--watch-cache     默认值：true +
+ +在 apiserver 中启用监视缓存 +
--watch-cache-sizes stringSlice
+ +某些资源（pods、nodes 等）的监视缓存大小设置，以逗号分隔。 +每个资源对应的设置格式：resource[.group]#size，其中 resource 为小写复数（无版本）， +对于 apiVersion v1（旧版核心 API）的资源要省略 group， +对其它资源要给出 group，size 为一个数字。 +启用 watch-cache 时，此功能生效。 +某些资源（replicationcontrollers、endpoints、nodes、pods、services、apiservices.apiregistration.k8s.io） +具有通过启发式设置的系统默认值，其他资源默认为 default-watch-cache-size +
diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md index 602d0bdbfa..34d86b0bba 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md @@ -262,6 +262,23 @@ kube-controller-manager [flags] 包含 PEM 编码格式的 X509 CA 证书的文件名。该证书用来发放集群范围的证书。 + + + +--cluster-signing-duration duration     默认值: 8760h0m0s + + + + + +所签名证书的有效期限。 + + + --cluster-signing-key-file string     默认值："/etc/kubernetes/ca/ca.key" @@ -271,6 +288,118 @@ kube-controller-manager [flags] 包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名。该私钥用来对集群范围证书签名。 + +--cluster-signing-kube-apiserver-client-cert-file string + + + + +包含 PEM 编码的 X509 CA 证书的文件名， +该证书用于为 kubernetes.io/kube-apiserver-client 签署者颁发证书。 +如果指定，则不得设置 --cluster-signing-{cert,key}-file。 + + + + +--cluster-signing-kube-apiserver-client-key-file string + + + + +包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名， +该私钥用于为 kubernetes.io/kube-apiserver-client 签署者签名证书。 +如果指定，则不得设置 --cluster-signing-{cert,key}-file。 + + + + +--cluster-signing-kubelet-client-cert-file string + + + + +包含 PEM 编码的 X509 CA 证书的文件名， +该证书用于为 kubernetes.io/kube-apiserver-client-kubelet 签署者颁发证书。 +如果指定，则不得设置 --cluster-signing-{cert,key}-file。 + + + + +--cluster-signing-kubelet-client-key-file string + + + + +包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名， +该私钥用于为 kubernetes.io/kube-apiserver-client-kubelet 签署者签名证书。 +如果指定，则不得设置 --cluster-signing-{cert,key}-file。 + + + + +--cluster-signing-kubelet-serving-cert-file string + + + + +包含 PEM 编码的 X509 CA 证书的文件名， +该证书用于为 kubernetes.io/kubelet-serving 签署者颁发证书。 +如果指定，则不得设置 --cluster-signing-{cert,key}-file。 + + + + +--cluster-signing-kubelet-serving-key-file string + + + + +包含 PEM 编码的 RSA或ECDSA 私钥的文件名， +该私钥用于对 kubernetes.io/kubelet-serving 签署者的证书进行签名。 +如果指定，则不得设置 --cluster-signing-{cert,key}-file。 + + + + +--cluster-signing-legacy-unknown-cert-file string + + + + +包含 PEM 编码的 X509 CA 证书的文件名， +用于为 kubernetes.io/legacy-unknown 签署者颁发证书。 +如果指定，则不得设置 --cluster-signing-{cert,key}-file。 + + + + +--cluster-signing-legacy-unknown-key-file string + + + + +包含 PEM 编码的 RSA 或 ECDSA 私钥的文件名， +用于为 kubernetes.io/legacy-unknown 签署者签名证书。 +如果指定，则不得设置 --cluster-signing-{cert,key}-file。 + + + --concurrent-deployment-syncs int32     默认值：5 @@ -409,9 +538,9 @@ kube-controller-manager [flags] --controllers stringSlice     默认值：[*] - + 要启用的控制器列表。* 表示启用所有默认启用的控制器；foo 启用名为 foo 的控制器；-foo 表示禁用名为 foo 的控制器。
-控制器的全集：attachdetach、bootstrapsigner、cloud-node-lifecycle、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、endpointslice、garbagecollector、horizontalpodautoscaling、job、namespace、nodeipam、nodelifecycle、persistentvolume-binder、persistentvolume-expander、podgc、pv-protection、pvc-protection、replicaset、replicationcontroller、resourcequota、root-ca-cert-publisher、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner、ttl、ttl-after-finished
+控制器的全集：attachdetach、bootstrapsigner、cloud-node-lifecycle、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、csrsigning、daemonset、deployment、disruption、endpoint、endpointslice、endpointslicemirroring、ephemeral-volume、garbagecollector、horizontalpodautoscaling、job、namespace、nodeipam、nodelifecycle、persistentvolume-binder、persistentvolume-expander、podgc、pv-protection、pvc-protection、replicaset、replicationcontroller、resourcequota、root-ca-cert-publisher、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner、ttl、ttl-after-finished
默认禁用的控制器有：bootstrapsigner 和 tokencleaner。 @@ -482,14 +611,6 @@ kube-controller-manager [flags] 端点片段（Endpoint Slice）批量更新周期时长。对 Pods 变更的处理会被延迟，以便将其与即将到来的更新操作合并，从而减少端点更新操作次数。较大的数值意味着端点更新的迟滞时间会增长，也意味着所生成的端点版本个数会变少。 - - ---experimental-cluster-signing-duration duration     默认值：8760h0m0s - - -所签署的证书的有效期时长。 - - --external-cloud-volume-plugin string @@ -502,8 +623,180 @@ kube-controller-manager [flags] --feature-gates mapStringBool - -一组 key=value 耦对，用来描述测试性/试验性功能的特性门控（Feature Gate）。可选项有：
APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (ALPHA - default=false)
APIResponseCompression=true|false (BETA - default=true)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AllowInsecureBackendProxy=true|false (BETA - default=true)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
CRIContainerLogRotation=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=false)
CSIMigrationAWSComplete=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (ALPHA - default=false)
CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)
CSIMigrationAzureFile=true|false (ALPHA - default=false)
CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)
CSIMigrationGCE=true|false (BETA - default=false)
CSIMigrationGCEComplete=true|false (ALPHA - default=false)
CSIMigrationOpenStack=true|false (BETA - default=false)
CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)
ConfigurableFSGroupPolicy=true|false (ALPHA - default=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
DefaultIngressClass=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DryRun=true|false (BETA - default=true)
DynamicAuditing=true|false (ALPHA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
EndpointSlice=true|false (BETA - default=true)
EndpointSliceProxying=true|false (ALPHA - default=false)
EphemeralContainers=true|false (ALPHA - default=false)
EvenPodsSpread=true|false (BETA - default=true)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HugePageStorageMediumSize=true|false (ALPHA - default=false)
HyperVContainer=true|false (ALPHA - default=false)
IPv6DualStack=true|false (ALPHA - default=false)
ImmutableEphemeralVolumes=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
LegacyNodeRoleBehavior=true|false (ALPHA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
NodeDisruptionExclusion=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (ALPHA - default=false)
PodDisruptionBudget=true|false (BETA - default=true)
PodOverhead=true|false (BETA - default=true)
ProcMountType=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (ALPHA - default=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)
RotateKubeletClientCertificate=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RunAsGroup=true|false (BETA - default=true)
RuntimeClass=true|false (BETA - default=true)
SCTPSupport=true|false (ALPHA - default=false)
SelectorIndex=true|false (ALPHA - default=false)
ServerSideApply=true|false (BETA - default=true)
ServiceAccountIssuerDiscovery=true|false (ALPHA - default=false)
ServiceAppProtocol=true|false (ALPHA - default=false)
ServiceNodeExclusion=true|false (ALPHA - default=false)
ServiceTopology=true|false (ALPHA - default=false)
StartupProbe=true|false (BETA - default=true)
StorageVersionHash=true|false (BETA - default=true)
SupportNodePidsLimit=true|false (BETA - default=true)
SupportPodPidsLimit=true|false (BETA - default=true)
Sysctls=true|false (BETA - default=true)
TTLAfterFinished=true|false (ALPHA - default=false)
TokenRequest=true|false (BETA - default=true)
TokenRequestProjection=true|false (BETA - default=true)
TopologyManager=true|false (BETA - default=true)
ValidateProxyRedirects=true|false (BETA - default=true)
VolumeSnapshotDataSource=true|false (BETA - default=true)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (ALPHA - default=false) + +一组 key=value 对，用来描述测试性/试验性功能的特性门控（Feature Gate）。可选项有： +
APIListChunking=true|false (BETA - 默认值=true) +
APIPriorityAndFairness=true|false (ALPHA - 默认值=false) +
APIResponseCompression=true|false (BETA - 默认值=true) +
AllAlpha=true|false (ALPHA - 默认值=false) +
AllBeta=true|false (BETA - 默认值=false) +
AllowInsecureBackendProxy=true|false (BETA - 默认值=true) +
AnyVolumeDataSource=true|false (ALPHA - 默认值=false) +
AppArmor=true|false (BETA - 默认值=true) +
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false) +
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false) +
CPUManager=true|false (BETA - 默认值=true) +
CRIContainerLogRotation=true|false (BETA - 默认值=true) +
CSIInlineVolume=true|false (BETA - 默认值=true) +
CSIMigration=true|false (BETA - 默认值=true) +
CSIMigrationAWS=true|false (BETA - 默认值=false) +
CSIMigrationAWSComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureDisk=true|false (BETA - 默认值=false) +
CSIMigrationAzureDiskComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureFileComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationGCE=true|false (BETA - 默认值=false) +
CSIMigrationGCEComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationOpenStack=true|false (BETA - 默认值=false) +
CSIMigrationOpenStackComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationvSphere=true|false (BETA - 默认值=false) +
CSIMigrationvSphereComplete=true|false (BETA - 默认值=false) +
CSIStorageCapacity=true|false (ALPHA - 默认值=false) +
CSIVolumeFSGroupPolicy=true|false (ALPHA - 默认值=false) +
ConfigurableFSGroupPolicy=true|false (ALPHA - 默认值=false) +
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false) +
DefaultPodTopologySpread=true|false (ALPHA - 默认值=false) +
DevicePlugins=true|false (BETA - 默认值=true) +
DisableAcceleratorUsageMetrics=true|false (ALPHA - 默认值=false) +
DynamicKubeletConfig=true|false (BETA - 默认值=true) +
EndpointSlice=true|false (BETA - 默认值=true) +
EndpointSliceProxying=true|false (BETA - 默认值=true) +
EphemeralContainers=true|false (ALPHA - 默认值=false) +
ExpandCSIVolumes=true|false (BETA - 默认值=true) +
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true) +
ExpandPersistentVolumes=true|false (BETA - 默认值=true) +
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false) +
GenericEphemeralVolume=true|false (ALPHA - 默认值=false) +
HPAScaleToZero=true|false (ALPHA - 默认值=false) +
HugePageStorageMediumSize=true|false (BETA - 默认值=true) +
HyperVContainer=true|false (ALPHA - 默认值=false) +
IPv6DualStack=true|false (ALPHA - 默认值=false) +
ImmutableEphemeralVolumes=true|false (BETA - 默认值=true) +
KubeletPodResources=true|false (BETA - 默认值=true) +
LegacyNodeRoleBehavior=true|false (BETA - 默认值=true) +
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true) +
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false) +
NodeDisruptionExclusion=true|false (BETA - 默认值=true) +
NonPreemptingPriority=true|false (BETA - 默认值=true) +
PodDisruptionBudget=true|false (BETA - 默认值=true) +
PodOverhead=true|false (BETA - 默认值=true) +
ProcMountType=true|false (ALPHA - 默认值=false) +
QOSReserved=true|false (ALPHA - 默认值=false) +
RemainingItemCount=true|false (BETA - 默认值=true) +
RemoveSelfLink=true|false (ALPHA - 默认值=false) +
RotateKubeletServerCertificate=true|false (BETA - 默认值=true) +
RunAsGroup=true|false (BETA - 默认值=true) +
RuntimeClass=true|false (BETA - 默认值=true) +
SCTPSupport=true|false (BETA - 默认值=true) +
SelectorIndex=true|false (BETA - 默认值=true) +
ServerSideApply=true|false (BETA - 默认值=true) +
ServiceAccountIssuerDiscovery=true|false (ALPHA - 默认值=false) +
ServiceAppProtocol=true|false (BETA - 默认值=true) +
ServiceNodeExclusion=true|false (BETA - 默认值=true) +
ServiceTopology=true|false (ALPHA - 默认值=false) +
SetHostnameAsFQDN=true|false (ALPHA - 默认值=false) +
StartupProbe=true|false (BETA - 默认值=true) +
StorageVersionHash=true|false (BETA - 默认值=true) +
SupportNodePidsLimit=true|false (BETA - 默认值=true) +
SupportPodPidsLimit=true|false (BETA - 默认值=true) +
Sysctls=true|false (BETA - 默认值=true) +
TTLAfterFinished=true|false (ALPHA - 默认值=false) +
TokenRequest=true|false (BETA - 默认值=true) +
TokenRequestProjection=true|false (BETA - 默认值=true) +
TopologyManager=true|false (BETA - 默认值=true) +
ValidateProxyRedirects=true|false (BETA - 默认值=true) +
VolumeSnapshotDataSource=true|false (BETA - 默认值=true) +
WarningHeaders=true|false (BETA - 默认值=true) +
WinDSR=true|false (ALPHA - 默认值=false) +
WinOverlay=true|false (ALPHA - 默认值=false) +
WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false) + @@ -647,12 +940,20 @@ kube-controller-manager [flags] - ---leader-elect-resource-lock endpoints     默认值："endpointsleases" + + +--leader-elect-resource-lock string     默认值："endpointsleases" + - -在领导者选举期间用来执行锁操作的资源对象类型。可选项为 endpointsleases （默认值）和 configmaps。 + + +在领导者选举期间用于锁定的资源对象的类型。 支持的选项为'endpoints'、'configmaps'、'leases'、'endpointsleases' 和 'configmapsleases'。 + @@ -723,6 +1024,25 @@ kube-controller-manager [flags] 将内存中日志数据清除到日志文件中时，相邻两次清除操作之间最大间隔秒数。 + + + +--logging-format string     默认值："text" + + + + + +设置日志格式。允许的格式："text"，"json"。 +
非默认格式不支持以下标志：--add_dir_header、--alsologtostderr、--log_backtrace_at、--log_dir、--log_file、--log_file_max_size、--logtostderr、--skip_headers、--skip_log_headers、--stderrthreshold、--vmodule、--log-flush-frequency。 +
当前非默认选项为 Alpha，如有更改，恕不另行通知。 + + + --logtostderr     默认值：true @@ -758,6 +1078,58 @@ kube-controller-manager [flags] 自省程序的重新同步时隔下限。实际时隔长度会在 min-resync-period 和 2 * min-resync-period 之间。 + + + +--mirroring-concurrent-service-endpoint-syncs int32     默认值：5 + + + + + +EndpointSliceMirroring 控制器将同时执行的服务端点同步操作数。 +较大的数量 = 更快的端点切片更新，但 CPU（和网络）负载更多。 默认为 5。 + + + + +--mirroring-endpointslice-updates-batch-period duration + + + + +EndpointSlice 的长度更新了 EndpointSliceMirroring 控制器的批处理周期。 +EndpointSlice 更改的处理将延迟此持续时间， +以使它们与潜在的即将进行的更新结合在一起，并减少 EndpointSlice 更新的总数。 +较大的数量 = 较高的端点编程延迟，但是生成的端点修订版本数量较少 + + + + + + +--mirroring-max-endpoints-per-subset int32     默认值：1000 + + + + + +EndpointSliceMirroring 控制器将添加到 EndpointSlice 的最大端点数。 +每个分片的端点越多，端点分片越少，但资源越大。 +默认为 100。 + + + --namespace-sync-period duration     默认值：5m0s @@ -827,6 +1199,20 @@ kube-controller-manager [flags] 在节点启动期间，节点可以处于无响应状态；但超出此标志所设置的时长仍然无响应则该节点被标记为不健康。 + +--permit-port-sharing + + + + +如果为 true，则在绑定端口时将使用 SO_REUSEPORT， +这允许多个实例在同一地址和端口上进行绑定。 +[默认值 = false] + + + --pod-eviction-timeout duration     默认值：5m0s @@ -1058,8 +1444,9 @@ kube-controller-manager [flags] --tls-cipher-suites stringSlice - -供服务器使用的加密包的逗号分隔列表。若忽略此标志，则使用 Go 语言默认的加密包。可选值包括：TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA + +供服务器使用的加密包的逗号分隔列表。若忽略此标志，则使用 Go 语言默认的加密包。可选值包括：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_GCM_SHA256、TLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_256_GCM_SHA384. +
不安全的值: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_RC4_128_SHA diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md b/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md index ffbc4e7ec8..1c98ff35da 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md @@ -209,15 +209,215 @@ Idle timeout for established TCP connections (0 to leave as-is) + +--detect-local-mode LocalMode + + + + +用于检测本地流量的模式 + + + --feature-gates mapStringBool -一组键=值（key=value）对，描述了 alpha/experimental 的特征。可选项有：
APIListChunking=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
AllAlpha=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
AttachVolumeLimit=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
BlockVolume=true|false (BETA - 默认值=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
CPUManager=true|false (BETA - 默认值=true)
CRIContainerLogRotation=true|false (BETA - 默认值=true)
CSIBlockVolume=true|false (BETA - 默认值=true)
CSIDriverRegistry=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (ALPHA - 默认值=false)
CSIMigrationAWS=true|false (ALPHA - 默认值=false)
CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
CSIMigrationGCE=true|false (ALPHA - 默认值=false)
CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)
CSINodeInfo=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
CustomResource默认值ing=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DryRun=true|false (BETA - 默认值=true)
DynamicAuditing=true|false (ALPHA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
EndpointSlice=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
EvenPodsSpread=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespace默认值ing=true|false (BETA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HyperVContainer=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
MountContainers=true|false (ALPHA - 默认值=false)
NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)
NodeLease=true|false (BETA - 默认值=true)
NonPreemptingPriority=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (ALPHA - 默认值=false)
PodShareProcessNamespace=true|false (BETA - 默认值=true)
ProcMountType=true|false (ALPHA - 默认值=false)
QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (ALPHA - 默认值=false)
RequestManagement=true|false (ALPHA - 默认值=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)
ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)
RotateKubeletClientCertificate=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
RunAsGroup=true|false (BETA - 默认值=true)
RuntimeClass=true|false (BETA - 默认值=true)
SCTPSupport=true|false (ALPHA - 默认值=false)
ScheduleDaemonSetPods=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)
ServiceNodeExclusion=true|false (ALPHA - 默认值=false)
StartupProbe=true|false (BETA - 默认值=true)
StorageVersionHash=true|false (BETA - 默认值=true)
StreamingProxyRedirects=true|false (BETA - 默认值=true)
SupportNodePidsLimit=true|false (BETA - 默认值=true)
SupportPodPidsLimit=true|false (BETA - 默认值=true)
Sysctls=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (ALPHA - 默认值=false)
TaintBasedEvictions=true|false (BETA - 默认值=true)
TaintNodesByCondition=true|false (BETA - 默认值=true)
TokenRequest=true|false (BETA - 默认值=true)
TokenRequestProjection=true|false (BETA - 默认值=true)
TopologyManager=true|false (ALPHA - 默认值=false)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
VolumePVCDataSource=true|false (BETA - 默认值=true)
VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)
VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)
WatchBookmark=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (ALPHA - 默认值=false)
WindowsGMSA=true|false (BETA - 默认值=true)
WindowsRunAsUserName=true|false (ALPHA - 默认值=false) +一组键=值（key=value）对，描述了 alpha/experimental 的特征。可选项有： +
APIListChunking=true|false (BETA - 默认值=true) +
APIPriorityAndFairness=true|false (ALPHA - 默认值=false) +
APIResponseCompression=true|false (BETA - 默认值=true) +
AllAlpha=true|false (ALPHA - 默认值=false) +
AllBeta=true|false (BETA - 默认值=false) +
AllowInsecureBackendProxy=true|false (BETA - 默认值=true) +
AnyVolumeDataSource=true|false (ALPHA - 默认值=false) +
AppArmor=true|false (BETA - 默认值=true) +
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false) +
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false) +
CPUManager=true|false (BETA - 默认值=true) +
CRIContainerLogRotation=true|false (BETA - 默认值=true) +
CSIInlineVolume=true|false (BETA - 默认值=true) +
CSIMigration=true|false (BETA - 默认值=true) +
CSIMigrationAWS=true|false (BETA - 默认值=false) +
CSIMigrationAWSComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureDisk=true|false (BETA - 默认值=false) +
CSIMigrationAzureDiskComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false) +
CSIMigrationAzureFileComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationGCE=true|false (BETA - 默认值=false) +
CSIMigrationGCEComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationOpenStack=true|false (BETA - 默认值=false) +
CSIMigrationOpenStackComplete=true|false (ALPHA - 默认值=false) +
CSIMigrationvSphere=true|false (BETA - 默认值=false) +
CSIMigrationvSphereComplete=true|false (BETA - 默认值=false) +
CSIStorageCapacity=true|false (ALPHA - 默认值=false) +
CSIVolumeFSGroupPolicy=true|false (ALPHA - 默认值=false) +
ConfigurableFSGroupPolicy=true|false (ALPHA - 默认值=false) +
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false) +
DefaultPodTopologySpread=true|false (ALPHA - 默认值=false) +
DevicePlugins=true|false (BETA - 默认值=true) +
DisableAcceleratorUsageMetrics=true|false (ALPHA - 默认值=false) +
DynamicKubeletConfig=true|false (BETA - 默认值=true) +
EndpointSlice=true|false (BETA - 默认值=true) +
EndpointSliceProxying=true|false (BETA - 默认值=true) +
EphemeralContainers=true|false (ALPHA - 默认值=false) +
ExpandCSIVolumes=true|false (BETA - 默认值=true) +
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true) +
ExpandPersistentVolumes=true|false (BETA - 默认值=true) +
ExperimentalHostUserNamespace默认值ing=true|false (BETA - 默认值=false) +
GenericEphemeralVolume=true|false (ALPHA - 默认值=false) +
HPAScaleToZero=true|false (ALPHA - 默认值=false) +
HugePageStorageMediumSize=true|false (BETA - 默认值=true) +
HyperVContainer=true|false (ALPHA - 默认值=false) +
IPv6DualStack=true|false (ALPHA - 默认值=false) +
ImmutableEphemeralVolumes=true|false (BETA - 默认值=true) +
KubeletPodResources=true|false (BETA - 默认值=true) +
LegacyNodeRoleBehavior=true|false (BETA - 默认值=true) +
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true) +
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false) +
NodeDisruptionExclusion=true|false (BETA - 默认值=true) +
NonPreemptingPriority=true|false (BETA - 默认值=true) +
PodDisruptionBudget=true|false (BETA - 默认值=true) +
PodOverhead=true|false (BETA - 默认值=true) +
ProcMountType=true|false (ALPHA - 默认值=false) +
QOSReserved=true|false (ALPHA - 默认值=false) +
RemainingItemCount=true|false (BETA - 默认值=true) +
RemoveSelfLink=true|false (ALPHA - 默认值=false) +
RotateKubeletServerCertificate=true|false (BETA - 默认值=true) +
RunAsGroup=true|false (BETA - 默认值=true) +
RuntimeClass=true|false (BETA - 默认值=true) +
SCTPSupport=true|false (BETA - 默认值=true) +
SelectorIndex=true|false (BETA - 默认值=true) +
ServerSideApply=true|false (BETA - 默认值=true) +
ServiceAccountIssuerDiscovery=true|false (ALPHA - 默认值=false) +
ServiceAppProtocol=true|false (BETA - 默认值=true) +
ServiceNodeExclusion=true|false (BETA - 默认值=true) +
ServiceTopology=true|false (ALPHA - 默认值=false) +
SetHostnameAsFQDN=true|false (ALPHA - 默认值=false) +
StartupProbe=true|false (BETA - 默认值=true) +
StorageVersionHash=true|false (BETA - 默认值=true) +
SupportNodePidsLimit=true|false (BETA - 默认值=true) +
SupportPodPidsLimit=true|false (BETA - 默认值=true) +
Sysctls=true|false (BETA - 默认值=true) +
TTLAfterFinished=true|false (ALPHA - 默认值=false) +
TokenRequest=true|false (BETA - 默认值=true) +
TokenRequestProjection=true|false (BETA - 默认值=true) +
TopologyManager=true|false (BETA - 默认值=true) +
ValidateProxyRedirects=true|false (BETA - 默认值=true) +
VolumeSnapshotDataSource=true|false (BETA - 默认值=true) +
WarningHeaders=true|false (BETA - 默认值=true) +
WinDSR=true|false (ALPHA - 默认值=false) +
WinOverlay=true|false (ALPHA - 默认值=false) +
WindowsEndpointSliceProxying=true|false (ALPHA - 默认值=false) + + + + + + +--healthz-bind-address 0.0.0.0     默认值: 0.0.0.0:10256 + + + + + +服务健康检查的 IP 地址和端口（对于所有 IPv4 接口设置为 '0.0.0.0:10256'，对于所有 IPv6 接口设置为 '[::]:10256'） +设置为空则禁用。 @@ -234,24 +434,7 @@ A set of key=value pairs that describe feature gates for alpha/experimental feat -服务健康检查的 IP 地址和端口（对于所有 IPv4 接口设置为 0.0.0.0，对于所有 IPv6 接口设置为 ::） - - - - - - ---healthz-port int32     默认值: 10256 - - - - - -绑定健康检查服务的端口。使用 0 表示禁用。 +服务健康检查的 IP 地址和端口（设置为 0.0.0.0 表示使用所有 IPv4 接口，设置为 :: 表示使用所有 IPv6 接口） @@ -297,7 +480,12 @@ If using the pure iptables proxy, the bit of the fwmark space to mark packets re ---iptables-min-sync-period duration + + + --iptables-min-sync-period duration     默认值：1s + @@ -390,6 +578,43 @@ The maximum interval of how often ipvs rules are refreshed (e.g. '5s', '1m', '2h + + +--ipvs-tcp-timeout duration + + + + +空闲 IPVS TCP 连接的超时时间，0 保持连接（例如 '5s'、'1m'、'2h22m'）。 + + + + +--ipvs-tcpfin-timeout duration + + + + +收到 FIN 数据包后，IPVS TCP 连接的超时，0 保持连接不变（例如 '5s'、'1m'、'2h22m'）。 + + + + +--ipvs-udp-timeout duration + + + + +IPVS UDP 数据包的超时，0 保持连接不动（例如 '5s'、'1m'、'2h22m'）。 + + + ---metrics-bind-address 0.0.0.0     默认值: 127.0.0.1:10249 +--metrics-bind-address ipport 0.0.0.0     默认值: 127.0.0.1:10249 -metrics 服务器要使用的 IP 地址（所有 IPv4 接口设置为 0.0.0.0，所有 IPv6 接口设置为 `::`） +metrics 服务器要使用的 IP 地址和端口 +（设置为 '0.0.0.0:10249' 则使用 IPv4 接口，设置为 '[::]:10249' 则使用所有 IPv6 接口） +设置为空则禁用。 @@ -593,6 +822,22 @@ Range of host ports (beginPort-endPort, single port or beginPort+offset, inclusi + +--show-hidden-metrics-for-version string + + + + +你要显示隐藏指标的先前版本。 +仅先前的次要版本有意义，不允许其他值。 +格式为 <major>.<minor> ，例如：'1.16'。 +这种格式的目的是确保你有机会注意到下一个发行版是否隐藏了其他指标， +而不是在之后将其永久删除时感到惊讶。 + + + -{{< toc >}} - -## Overview + +## 概述 + +kubelet 的 HTTPS 端点公开了 API， +这些 API 可以访问敏感度不同的数据， +并允许你在节点上和容器内以不同级别的权限执行操作。 + +本文档介绍了如何对 kubelet 的 HTTPS 端点的访问进行认证和鉴权。 -## Kubelet authentication + +## Kubelet 认证 + +默认情况下，未被已配置的其他身份认证方法拒绝的对 kubelet 的 HTTPS 端点的请求会被视为匿名请求， +并被赋予 `system:anonymous` 用户名和 `system:unauthenticated` 组。 + +要禁用匿名访问并向未经身份认证的请求发送 `401 Unauthorized` 响应，请执行以下操作： -* start the kubelet with the `--anonymous-auth=false` flag + +* 带 `--anonymous-auth=false` 标志启动 kubelet + +要对 kubelet 的 HTTPS 端点启用 X509 客户端证书认证： + +* 带 `--client-ca-file` 标志启动 kubelet，提供一个 CA 证书包以供验证客户端证书 +* 带 `--kubelet-client-certificate` 和 `--kubelet-client-key` 标志启动 apiserver +* 有关更多详细信息，请参见 [apiserver 身份验证文档](/zh/docs/admin/authentication/#x509-client-certs) + +要启用 API 持有者令牌（包括服务帐户令牌）以对 kubelet 的 HTTPS 端点进行身份验证，请执行以下操作： + +* 确保在 API 服务器中启用了 `authentication.k8s.io/v1beta1` API 组 +* 带 `--authentication-token-webhook` 和 `--kubeconfig` 标志启动 kubelet +* kubelet 调用已配置的 API 服务器上的 `TokenReview` API，以根据持有者令牌确定用户信息 -## Kubelet authorization + +## Kubelet 鉴权 + +任何成功通过身份验证的请求（包括匿名请求）之后都会被鉴权。 +默认的鉴权模式为 `AlwaysAllow`，它允许所有请求。 + +细分对 kubelet API 的访问权限可能有多种原因： + +* 启用了匿名身份验证，但是应限制匿名用户调用 kubelet API 的能力 +* 启用了持有者令牌认证，但应限制任意 API 用户（如服务帐户）调用 kubelet API 的能力 +* 启用了客户端证书身份验证，但仅应允许已配置的 CA 签名的某些客户端证书使用 kubelet API + +要细分对 kubelet API 的访问权限，请将鉴权委派给 API 服务器： + +* 确保在 API 服务器中启用了 `authorization.k8s.io/v1beta1` API 组 +* 带 `--authorization-mode=Webhook` 和 `--kubeconfig` 标志启动 kubelet +* kubelet 调用已配置的 API 服务器上的 `SubjectAccessReview` API，以确定每个请求是否得到鉴权 + +kubelet 使用与 apiserver 相同的[请求属性](/zh/docs/admin/authorization/#request-attributes)方法对 API 请求执行鉴权。 + +请求的动词根据传入请求的 HTTP 动词确定： + +HTTP 动词 | 请求动词 ----------|--------------- POST | create GET, HEAD | get @@ -63,24 +136,38 @@ PUT | update PATCH | patch DELETE | delete + +资源和子资源是根据传入请求的路径确定的： -Kubelet API | resource | subresource + +Kubelet API | 资源 | 子资源 -------------|----------|------------ /stats/\* | nodes | stats /metrics/\* | nodes | metrics /logs/\* | nodes | log /spec/\* | nodes | spec -*all others* | nodes | proxy +*其它所有* | nodes | proxy + +名字空间和 API 组属性始终是空字符串， +资源名称始终是 kubelet 的 `Node` API 对象的名称。 + +在此模式下运行时，请确保传递给 apiserver 的由 `--kubelet-client-certificate` 和 +`--kubelet-client-key` 标志标识的用户具有以下属性的鉴权： * verb=\*, resource=nodes, subresource=proxy * verb=\*, resource=nodes, subresource=stats * verb=\*, resource=nodes, subresource=log * verb=\*, resource=nodes, subresource=spec -* verb=\*, resource=nodes, subresource=metrics +* verb=\*, resource=nodes, subresource=metrics \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/addons.md b/content/zh/docs/reference/glossary/addons.md index 00a871a227..31fc1f0098 100644 --- a/content/zh/docs/reference/glossary/addons.md +++ b/content/zh/docs/reference/glossary/addons.md @@ -1,5 +1,5 @@ --- -title: 附加组件 +title: 附加组件（Add-ons） id: addons date: 2019-12-15 full_link: /zh/docs/concepts/cluster-administration/addons/ @@ -10,14 +10,12 @@ aka: tags: - tool --- - 扩展 Kubernetes 功能的资源。 - + + + + 扩展 Kubernetes 功能的资源。 -[安装附加组件](/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 +[安装附加组件](/zh/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 diff --git a/content/zh/docs/reference/glossary/admission-controller.md b/content/zh/docs/reference/glossary/admission-controller.md index adbd681fae..22567c4861 100644 --- a/content/zh/docs/reference/glossary/admission-controller.md +++ b/content/zh/docs/reference/glossary/admission-controller.md @@ -1,5 +1,5 @@ --- -title: 准入控制器 +title: 准入控制器（Admission Controller） id: admission-controller date: 2019-06-28 full_link: /zh/docs/reference/access-authn-authz/admission-controllers/ @@ -11,12 +11,13 @@ tags: - security --- + + + 在对象持久化之前拦截 Kubernetes Api 服务器请求的一段代码 + + + + 聚合层允许您在自己的集群上安装额外的 Kubernetes 风格的 API。 - + + -当您配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)，您就可以在 Kubernetes API 中增加 `APIService` 对象来 "申领（Claim）" 一个 URL 路径。 +当您配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)，您就可以在 Kubernetes API 中增加 `APIService` 对象来 "申领（Claim）" 一个 URL 路径。 diff --git a/content/zh/docs/reference/glossary/annotation.md b/content/zh/docs/reference/glossary/annotation.md index a5da0a060f..a305352e32 100644 --- a/content/zh/docs/reference/glossary/annotation.md +++ b/content/zh/docs/reference/glossary/annotation.md @@ -1,5 +1,5 @@ --- -title: 注解 +title: 注解（Annotation） id: annotation date: 2018-04-12 full_link: /zh/docs/concepts/overview/working-with-objects/annotations/ @@ -16,7 +16,7 @@ tags: title: Annotation id: annotation date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/annotations/ +full_link: /docs/concepts/overview/working-with-objects/annotations short_description: > A key-value pair that is used to attach arbitrary non-identifying metadata to objects. @@ -26,6 +26,8 @@ tags: --- --> + + @@ -35,8 +37,10 @@ tags: -注解中的元数据可大可小，可以是结构化的也可以是非结构化的，并且能包含标签不允许使用的字符。像工具和软件库这样的客户端可以检索这些元数据。 +注解中的元数据可大可小，可以是结构化的也可以是非结构化的， +并且能包含{{< glossary_tooltip text="标签" term_id="label" >}}不允许使用的字符。 +像工具和软件库这样的客户端可以检索这些元数据。 diff --git a/content/zh/docs/reference/glossary/api-group.md b/content/zh/docs/reference/glossary/api-group.md index 07c222acbe..d2c360a214 100644 --- a/content/zh/docs/reference/glossary/api-group.md +++ b/content/zh/docs/reference/glossary/api-group.md @@ -11,12 +11,13 @@ tags: - fundamental - architecture --- + + Kubernetes API 中的一组相关路径。 - + -通过更改 API server 的配置，可以启用或禁用每个 API Group。你还可以禁用或启用指向特定资源的路径。API group 使扩展 Kubernetes API 更加的容易。API group 在 REST 路径和序列化对象的 `apiVersion` 字段中指定。 +通过更改 API server 的配置，可以启用或禁用每个 API Group。 +你还可以禁用或启用指向特定资源的路径。 +API group 使扩展 Kubernetes API 更加的容易。 +API group 在 REST 路径和序列化对象的 `apiVersion` 字段中指定。 -* 阅读 [API Group](/docs/concepts/overview/kubernetes-api/#api-groups) 了解更多信息。 +* 阅读 [API Group](/zh/docs/concepts/overview/kubernetes-api/#api-groups) 了解更多信息。 diff --git a/content/zh/docs/reference/glossary/app-container.md b/content/zh/docs/reference/glossary/app-container.md index a3238d65dd..3773e1c1b8 100644 --- a/content/zh/docs/reference/glossary/app-container.md +++ b/content/zh/docs/reference/glossary/app-container.md @@ -1,5 +1,5 @@ --- -title: 应用程序容器 +title: 应用程序容器（App Container） id: app-container date: 2019-02-12 full_link: @@ -10,7 +10,6 @@ aka: tags: - workload --- - 应用程序容器（或 app 容器）{{< glossary_tooltip text="容器" term_id="container" >}} 在 {{< glossary_tooltip text="pod" term_id="pod" >}} 中，在 {{< glossary_tooltip text="初始化容器" term_id="init-container" >}} 启动完毕后才开始启动。 + + + 应用程序 {{< glossary_tooltip text="容器" term_id="container" >}} （或 app 容器）在 {{< glossary_tooltip text="pod" term_id="pod" >}} 中，在 {{< glossary_tooltip text="初始化容器" term_id="init-container" >}} 启动完毕后才开始启动。 + + @@ -37,5 +42,6 @@ once the application container has started. If a pod doesn't have any init containers configured, all the containers in that pod are app containers. --> -初始化容器使您可以分离对于 {{< glossary_tooltip text="工作负载" term_id="workload" >}} 整体而言很重要的初始化细节，并且一旦应用容器启动，它不需要继续运行。 +初始化容器使您可以分离对于{{< glossary_tooltip text="工作负载" term_id="workload" >}} +整体而言很重要的初始化细节，并且一旦应用容器启动，它不需要继续运行。 如果 pod 没有配置任何初始化容器，则该 pod 中的所有容器都是应用程序容器。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/application-architect.md b/content/zh/docs/reference/glossary/application-architect.md index 849d1b7685..2ef153ab91 100644 --- a/content/zh/docs/reference/glossary/application-architect.md +++ b/content/zh/docs/reference/glossary/application-architect.md @@ -1,5 +1,5 @@ --- -title: 应用架构师 +title: 应用架构师（Application Architect） id: application-architect date: 2018-04-12 full_link: @@ -10,7 +10,6 @@ aka: tags: - user-type --- - 应用架构师是负责应用高级设计的人。 + + + 应用架构师是负责应用高级设计的人。 + + + -应用架构师确保应用的实现允许它和周边组件进行可扩展的、可持续的交互。周边组件包括数据库、日志基础设施和其他微服务。 +应用架构师确保应用的实现允许它和周边组件进行可扩展的、可持续的交互。 +周边组件包括数据库、日志基础设施和其他微服务。 diff --git a/content/zh/docs/reference/glossary/application-developer.md b/content/zh/docs/reference/glossary/application-developer.md index 65650133da..b379b5092a 100644 --- a/content/zh/docs/reference/glossary/application-developer.md +++ b/content/zh/docs/reference/glossary/application-developer.md @@ -1,5 +1,5 @@ --- -title: 应用开发者 +title: 应用开发者（Application Developer） id: application-developer date: 2018-04-12 full_link: @@ -26,8 +26,9 @@ tags: --- --> + 编写可以在 Kubernetes 集群上运行的应用的人。 diff --git a/content/zh/docs/reference/glossary/applications.md b/content/zh/docs/reference/glossary/applications.md index cbff609142..c1420495fe 100644 --- a/content/zh/docs/reference/glossary/applications.md +++ b/content/zh/docs/reference/glossary/applications.md @@ -1,5 +1,5 @@ --- -title: 应用 +title: 应用（Applications） id: applications date: 2019-05-12 full_link: @@ -24,4 +24,8 @@ tags: --- --> + + 各种容器化应用运行所在的层。 diff --git a/content/zh/docs/reference/glossary/approver.md b/content/zh/docs/reference/glossary/approver.md index 879ef5e58b..b28762cf16 100644 --- a/content/zh/docs/reference/glossary/approver.md +++ b/content/zh/docs/reference/glossary/approver.md @@ -1,5 +1,5 @@ --- -title: 批准者 +title: 批准者（Approver） id: approver date: 2018-04-12 full_link: @@ -26,6 +26,9 @@ tags: --- --> + 可以审核并批准 Kubernetes 代码贡献的人。 @@ -36,5 +39,4 @@ While code review is focused on code quality and correctness, approval is focuse 代码审核的重点是代码质量和正确性，而批准的重点是对贡献的整体接受。 整体接受包括向后/向前兼容性、遵守 API 和参数约定、细微的性能和正确性问题、与系统其他部分的交互等。 -批准者状态的作用域是代码库的一部分。 -审批者以前被称为维护者。 +批准者状态的作用域是代码库的一部分。审批者以前被称为维护者。 diff --git a/content/zh/docs/reference/glossary/certificate.md b/content/zh/docs/reference/glossary/certificate.md index c966aea2cb..05b50e37dc 100644 --- a/content/zh/docs/reference/glossary/certificate.md +++ b/content/zh/docs/reference/glossary/certificate.md @@ -1,5 +1,5 @@ --- -title: 证书 +title: 证书（Certificate） id: certificate date: 2018-04-12 full_link: /zh/docs/tasks/tls/managing-tls-in-a-cluster/ @@ -16,7 +16,7 @@ tags: title: Certificate id: certificate date: 2018-04-12 -full_link: /zh/docs/tasks/tls/managing-tls-in-a-cluster/ +full_link: /docs/tasks/tls/managing-tls-in-a-cluster/ short_description: > A cryptographically secure file used to validate access to the Kubernetes cluster. @@ -26,6 +26,7 @@ tags: --- --> + diff --git a/content/zh/docs/reference/glossary/cgroup.md b/content/zh/docs/reference/glossary/cgroup.md index 10d274a5e5..b1af5e9d9d 100644 --- a/content/zh/docs/reference/glossary/cgroup.md +++ b/content/zh/docs/reference/glossary/cgroup.md @@ -1,5 +1,5 @@ --- -title: cgroup (控制组) +title: 控制组（cgroup） id: cgroup date: 2019-06-25 full_link: diff --git a/content/zh/docs/reference/glossary/cidr.md b/content/zh/docs/reference/glossary/cidr.md index 7e0a97d31e..c99695543c 100644 --- a/content/zh/docs/reference/glossary/cidr.md +++ b/content/zh/docs/reference/glossary/cidr.md @@ -10,9 +10,8 @@ aka: tags: - networking --- -CIDR (无类域间路由) 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。 - + + +CIDR (无类域间路由) 是一种描述 IP 地址块的符号，被广泛使用于各种网络配置中。 + -在 Kubernetes 的上下文中，每个 {{< glossary_tooltip text="节点" term_id="node" >}} 以 CIDR 形式（含起始地址和子网掩码）获得一个 IP 地址段，从而能够为每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 分配一个独一无二的 IP 地址。虽然其概念最初源自 IPv4，CIDR 已经被扩展为涵盖 IPv6。 +在 Kubernetes 的上下文中，每个{{< glossary_tooltip text="节点" term_id="node" >}} +以 CIDR 形式（含起始地址和子网掩码）获得一个 IP 地址段， +从而能够为每个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 分配一个独一无二的 IP 地址。 +虽然其概念最初源自 IPv4，CIDR 已经被扩展为涵盖 IPv6。 diff --git a/content/zh/docs/reference/glossary/cla.md b/content/zh/docs/reference/glossary/cla.md index dae58a89e6..5d9f4229cd 100644 --- a/content/zh/docs/reference/glossary/cla.md +++ b/content/zh/docs/reference/glossary/cla.md @@ -1,5 +1,5 @@ --- -title: CLA (贡献者许可协议) +title: 贡献者许可协议（CLA） id: cla date: 2018-04-12 full_link: https://github.com/kubernetes/community/blob/master/CLA.md @@ -26,7 +26,10 @@ tags: --- --> - {{< glossary_tooltip text="贡献者" term_id="contributor" >}} 对他们在开源项目中所贡献的代码的授权许可条款。 + + {{< glossary_tooltip text="贡献者" term_id="contributor" >}}对他们在开源项目中所贡献的代码的授权许可条款。 diff --git a/content/zh/docs/reference/glossary/cloud-controller-manager.md b/content/zh/docs/reference/glossary/cloud-controller-manager.md index 2fcd729f57..e2f10617e2 100644 --- a/content/zh/docs/reference/glossary/cloud-controller-manager.md +++ b/content/zh/docs/reference/glossary/cloud-controller-manager.md @@ -1,5 +1,5 @@ --- -title: 云控制器管理器 +title: 云控制器管理器（Cloud Controller Manager） id: cloud-controller-manager date: 2018-04-12 full_link: /zh/docs/tasks/administer-cluster/running-cloud-controller/ @@ -18,7 +18,7 @@ tags: title: Cloud Controller Manager id: cloud-controller-manager date: 2018-04-12 -full_link: /zh/docs/tasks/administer-cluster/running-cloud-controller/ +full_link: /docs/concepts/architecture/cloud-controller/ short_description: > Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. @@ -30,18 +30,25 @@ tags: --- --> + -云控制器管理器是 1.8 的 alpha 特性。在未来发布的版本中，这是将 Kubernetes 与任何其他云集成的最佳方式。 +云控制器管理器是指嵌入特定云的控制逻辑的 +{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}组件。 +云控制器管理器允许您链接聚合到云提供商的应用编程接口中， +并分离出相互作用的组件与您的集群交互的组件。 - -Kubernetes v1.6 包含一个新的可执行文件叫做 cloud-controller-manager。cloud-controller-manager 是一个守护进程，其中嵌入了特定于某云环境的控制环。 -这些特定于云环境的控制环最初位于 kube-controller-manager 中。 -由于云供应商的开发和发布节奏与 Kubernetes 项目不同步，将特定于供应商的代码抽象到 cloud-controller-manager 可执行文件可以允许云供应商独立于核心 Kubernetes 代码进行演进。 +通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑， +云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的速度进行发布新特征。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/cloud-provider.md b/content/zh/docs/reference/glossary/cloud-provider.md index 0c07cd6fb8..8ab7e7a06f 100755 --- a/content/zh/docs/reference/glossary/cloud-provider.md +++ b/content/zh/docs/reference/glossary/cloud-provider.md @@ -10,10 +10,10 @@ aka: tags: - community --- - 一个提供云计算平台的商业机构或其他组织。 + + 一个提供云计算平台的商业机构或其他组织。 + + @@ -42,7 +48,7 @@ such as running a Kubernetes cluster. You can also find Kubernetes as a managed service; sometimes called Platform as a Service, or PaaS. With managed Kubernetes, your cloud provider is responsible for the Kubernetes control plane as well -as the glossary_tooltip term_id="node" text="nodes" and the +as the {{< glossary_tooltip term_id="node" text="nodes" >}} and the infrastructure they rely on: networking, storage, and possibly other elements such as load balancers. --> @@ -54,6 +60,6 @@ elements such as load balancers. 你也会看到 Kubernetes 被作为托管服务提供；有时也称作平台即服务或 PaaS。 针对托管的 Kubernetes，你的云供应商负责 Kubernetes 的控制面以及 -{{< glossary_tooltip term_id="node" text="节点" >}}及他们所依赖的基础设施： + {{< glossary_tooltip term_id="node" text="节点" >}} 及他们所依赖的基础设施： 网络、存储以及其他一些诸如负载均衡器之类的元素。 diff --git a/content/zh/docs/reference/glossary/cluster-architect.md b/content/zh/docs/reference/glossary/cluster-architect.md index c45bcfbe34..8636eede42 100644 --- a/content/zh/docs/reference/glossary/cluster-architect.md +++ b/content/zh/docs/reference/glossary/cluster-architect.md @@ -1,5 +1,5 @@ --- -title: 集群架构师 +title: 集群架构师（Cluster Architect） id: cluster-architect date: 2018-04-12 full_link: diff --git a/content/zh/docs/reference/glossary/cluster-infrastructure.md b/content/zh/docs/reference/glossary/cluster-infrastructure.md index 9d9eb4343d..8850abd4b5 100644 --- a/content/zh/docs/reference/glossary/cluster-infrastructure.md +++ b/content/zh/docs/reference/glossary/cluster-infrastructure.md @@ -1,5 +1,5 @@ --- -title: 集群基础设施 +title: 集群基础设施（Cluster Infrastructure） id: cluster-infrastructure date: 2019-05-12 full_link: @@ -12,7 +12,6 @@ tags: --- -基础设施层提供并维护虚拟机、网络、安全组及其他资源。 \ No newline at end of file +基础设施层提供并维护虚拟机、网络、安全组及其他资源。 diff --git a/content/zh/docs/reference/glossary/cluster-operations.md b/content/zh/docs/reference/glossary/cluster-operations.md index 98dcda6505..43a9bba4b0 100644 --- a/content/zh/docs/reference/glossary/cluster-operations.md +++ b/content/zh/docs/reference/glossary/cluster-operations.md @@ -1,10 +1,10 @@ --- -title: 集群操作 +title: 集群操作（Cluster Operations） id: cluster-operations date: 2019-05-12 full_link: short_description: > - 诸如升级集群、实现安全、存储、Ingress、网络、日志和监控之类的活动，以及管理 Kubernetes 集群所涉及的其他操作。 + 管理 Kubernetes 集群所涉及的相关工作。 aka: tags: @@ -18,15 +18,25 @@ id: cluster-operations date: 2019-05-12 full_link: short_description: > - Activities such as upgrading the clusters, implementing security, storage, ingress, networking, logging and monitoring, and other operations involved in managing a Kubernetes cluster. + The work involved in managing a Kubernetes cluster. aka: tags: -- operations +- operation --- --> - 诸如升级集群、实现安全、存储、Ingress、网络、日志和监控之类的活动，以及管理 Kubernetes 集群所涉及的其他操作。 \ No newline at end of file +Kubernetes 管理相关工作包括：日常管理操作和协调升级。 + + +群集操作工作的示例包括：部署新节点来扩容集群；执行软件升级；实施安全控制； +添加或删除存储；配置集群网络；管理集群范围的可观测性；响应集群事件。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/cluster-operator.md b/content/zh/docs/reference/glossary/cluster-operator.md index 8318dd46ed..4be92284b0 100644 --- a/content/zh/docs/reference/glossary/cluster-operator.md +++ b/content/zh/docs/reference/glossary/cluster-operator.md @@ -1,5 +1,5 @@ --- -title: 集群操作者 +title: 集群操作者（Cluster Operator） id: cluster-operator date: 2018-04-12 full_link: @@ -35,6 +35,7 @@ tags: diff --git a/content/zh/docs/reference/glossary/cluster.md b/content/zh/docs/reference/glossary/cluster.md index 1046f9a223..74d48ff2c2 100644 --- a/content/zh/docs/reference/glossary/cluster.md +++ b/content/zh/docs/reference/glossary/cluster.md @@ -1,10 +1,10 @@ --- -title: 集群 +title: 集群（Cluster） id: cluster date: 2019-06-15 full_link: short_description: > - 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点和至少一个主节点。 + 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。 aka: tags: @@ -19,7 +19,7 @@ id: cluster date: 2019-06-15 full_link: short_description: > - A set of machines, called nodes, that run containerized applications managed by Kubernetes. A cluster has at least one worker node and at least one master node. + A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node. aka: tags: @@ -28,9 +28,20 @@ tags: --- --> - -集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点和至少一个主节点。 + +集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。 - -工作节点托管作为应用程序组件的 Pod 。主节点管理集群中的工作节点和 Pod 。多个主节点用于为集群提供故障转移和高可用性。 + +工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。 +为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。 diff --git a/content/zh/docs/reference/glossary/cncf.md b/content/zh/docs/reference/glossary/cncf.md index e6e857b6bc..7910885461 100644 --- a/content/zh/docs/reference/glossary/cncf.md +++ b/content/zh/docs/reference/glossary/cncf.md @@ -1,5 +1,5 @@ --- -title: 云原生计算基金会 (CNCF) +title: 云原生计算基金会（CNCF） id: cncf date: 2019-05-26 full_link: https://cncf.io/ diff --git a/content/zh/docs/reference/glossary/cni.md b/content/zh/docs/reference/glossary/cni.md index 93028f7747..64febe0215 100644 --- a/content/zh/docs/reference/glossary/cni.md +++ b/content/zh/docs/reference/glossary/cni.md @@ -1,5 +1,5 @@ --- -title: CNI (容器网络接口) +title: 容器网络接口（CNI） id: cni date: 2018-05-25 full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni @@ -14,10 +14,10 @@ tags: -* 想了解 Kubernetes 和 CNI 请参考 ["网络插件"](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)。 +* 想了解 Kubernetes 和 CNI 请参考 ["网络插件"](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)。 diff --git a/content/zh/docs/reference/glossary/code-contributor.md b/content/zh/docs/reference/glossary/code-contributor.md index 8d24d7f72f..d42e7d8ae1 100644 --- a/content/zh/docs/reference/glossary/code-contributor.md +++ b/content/zh/docs/reference/glossary/code-contributor.md @@ -1,5 +1,5 @@ --- -title: 代码贡献者 +title: 代码贡献者（Code Contributor） id: code-contributor date: 2018-04-12 full_link: /docs/community/devel/ diff --git a/content/zh/docs/reference/glossary/configmap.md b/content/zh/docs/reference/glossary/configmap.md index d761b26e74..eb936aca66 100644 --- a/content/zh/docs/reference/glossary/configmap.md +++ b/content/zh/docs/reference/glossary/configmap.md @@ -16,9 +16,9 @@ tags: title: ConfigMap id: configmap date: 2018-04-12 -full_link: /zh/docs/tasks/configure-pod-container/configure-pod-configmap/ +full_link: /docs/concepts/configuration/configmap/ short_description: > - An API object used to store non-confidential data in key-value pairs. Can be consumed as environment variables, command-line arguments, or config files in a volume. + An API object used to store non-confidential data in key-value pairs. Can be consumed as environment variables, command-line arguments, or configuration files in a volume. aka: tags: @@ -27,15 +27,18 @@ tags: --> - ConfigMap 是一种 API 对象，用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。 + ConfigMap 是一种 API 对象，用来将非机密性的数据保存到健值对中。使用时， {{< glossary_tooltip text="Pods" term_id="pod" >}} 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。 -ConfigMap 将您的环境配置信息和 {{< glossary_tooltip text="容器镜像" term_id="container" >}} 解耦，便于应用配置的修改。当您需要储存机密信息时可以使用 [Secret](/docs/concepts/configuration/secret/) 对象。 +ConfigMap 将您的环境配置信息和 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 解耦，便于应用配置的修改。 diff --git a/content/zh/docs/reference/glossary/container-env-variables.md b/content/zh/docs/reference/glossary/container-env-variables.md index ae2b134643..e8796a12bd 100644 --- a/content/zh/docs/reference/glossary/container-env-variables.md +++ b/content/zh/docs/reference/glossary/container-env-variables.md @@ -1,10 +1,10 @@ --- -title: 容器环境变量 +title: 容器环境变量（Container Environment Variables） id: container-env-variables date: 2018-04-12 full_link: /zh/docs/concepts/containers/container-environment/ short_description: > - 容器环境变量提供了运行容器化应用所必须的一些重要信息。 + 容器环境变量提供了 name=value 形式的、运行容器化应用所必须的一些重要信息。 aka: tags: @@ -16,7 +16,7 @@ tags: title: Container Environment Variables id: container-env-variables date: 2018-04-12 -full_link: /zh/docs/concepts/containers/container-environment/ +full_link: /docs/concepts/containers/container-environment/ short_description: > Container environment variables are name=value pairs that provide useful information into containers running in a Pod. @@ -27,14 +27,14 @@ tags: --> - 容器环境变量提供了运行容器化应用所必须的一些重要信息。 + 容器环境变量提供了 name=value 形式的、在 {{< glossary_tooltip text="pod" term_id="pod" >}} 中运行的容器所必须的一些重要信息。 容器环境变量为运行中的容器化应用提供必要的信息，同时还提供与 {{< glossary_tooltip text="容器" term_id="container" >}} 重要资源相关的其他信息，例如：文件系统信息、容器自身的信息以及其他像服务端点（Service endpoints）这样的集群资源信息。 diff --git a/content/zh/docs/reference/glossary/container-lifecycle-hooks.md b/content/zh/docs/reference/glossary/container-lifecycle-hooks.md index 20e65157a0..6a43d283c9 100644 --- a/content/zh/docs/reference/glossary/container-lifecycle-hooks.md +++ b/content/zh/docs/reference/glossary/container-lifecycle-hooks.md @@ -1,5 +1,5 @@ --- -title: 容器生命周期钩子 +title: 容器生命周期钩子（Container Lifecycle Hooks） id: container-lifecycle-hooks date: 2018-10-08 full_link: /zh/docs/concepts/containers/container-lifecycle-hooks/ @@ -15,11 +15,11 @@ tags: title: Container Lifecycle Hooks id: container-lifecycle-hooks date: 2018-10-08 -full_link: /zh/docs/concepts/containers/container-lifecycle-hooks/ +full_link: /docs/concepts/containers/container-lifecycle-hooks/ short_description: > The lifecycle hooks expose events in the container management lifecycle and let the user run code when the events occur. -aka: +aka: tags: - extension --- diff --git a/content/zh/docs/reference/glossary/container-runtime.md b/content/zh/docs/reference/glossary/container-runtime.md index 7a68b6fd5c..badb4bcfcd 100644 --- a/content/zh/docs/reference/glossary/container-runtime.md +++ b/content/zh/docs/reference/glossary/container-runtime.md @@ -1,10 +1,10 @@ --- -title: 容器运行环境（Container Runtime） +title: 容器运行时（Container Runtime） id: container-runtime date: 2019-06-05 -full_link: /docs/setup/production-environment/container-runtimes +full_link: /zh/docs/setup/production-environment/container-runtimes short_description: > - 容器运行环境是负责运行容器的软件。 + 容器运行时是负责运行容器的软件。 aka: tags: @@ -28,7 +28,7 @@ tags: --> 容器运行环境是负责运行容器的软件。 diff --git a/content/zh/docs/reference/glossary/container.md b/content/zh/docs/reference/glossary/container.md index 1b2a98d43b..450a8af998 100644 --- a/content/zh/docs/reference/glossary/container.md +++ b/content/zh/docs/reference/glossary/container.md @@ -1,5 +1,5 @@ --- -title: 容器 +title: 容器（Container） id: container date: 2018-04-12 full_link: /zh/docs/concepts/overview/what-is-kubernetes/#why-containers @@ -13,11 +13,10 @@ tags: --- - - 容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。 +容器是可移植、可执行的轻量级的镜像，包含其中的软件及其相关依赖。 - 容器使应用和底层的主机基础设施解耦，降低了应用在不同云环境或者操作系统上的部署难度，便于应用扩展。 diff --git a/content/zh/docs/reference/glossary/containerd.md b/content/zh/docs/reference/glossary/containerd.md index e764362cc6..00d465b8c4 100644 --- a/content/zh/docs/reference/glossary/containerd.md +++ b/content/zh/docs/reference/glossary/containerd.md @@ -35,5 +35,5 @@ that runs as a daemon on Linux or Windows. containerd takes care of fetching and storing container images, executing containers, providing network access, and more. --> -containerd 是一种 {{< glossary_tooltip text="容器" term_id="container" >}} 运行时，能在 Linux 或者 Windows 后台运行。 +containerd 是一种{{< glossary_tooltip text="容器" term_id="container" >}}运行时，能在 Linux 或者 Windows 后台运行。 containerd 能取回、存储容器镜像，执行容器实例，提供网络访问等。 diff --git a/content/zh/docs/reference/glossary/contributor.md b/content/zh/docs/reference/glossary/contributor.md index 32f21a5e54..de79a4c984 100644 --- a/content/zh/docs/reference/glossary/contributor.md +++ b/content/zh/docs/reference/glossary/contributor.md @@ -1,5 +1,5 @@ --- -title: 贡献者 +title: 贡献者（Contributor） id: contributor date: 2018-04-12 full_link: diff --git a/content/zh/docs/reference/glossary/control-plane.md b/content/zh/docs/reference/glossary/control-plane.md index 05f3f57978..edb67bd796 100644 --- a/content/zh/docs/reference/glossary/control-plane.md +++ b/content/zh/docs/reference/glossary/control-plane.md @@ -1,18 +1,16 @@ --- -title: 控制平面 +title: 控制平面（Control Plane） id: control-plane date: 2019-05-12 full_link: short_description: > - 容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 + 控制平面是指容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 aka: tags: - fundamental --- - - 容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 +控制平面（Control Plane）是指容器编排层，它暴露 API 和接口来定义、 +部署容器和管理容器的生命周期。 + + +这个编排层是由多个不同的组件组成，例如以下（但不限于）几种： + + * {{< glossary_tooltip text="etcd" term_id="etcd" >}} + * {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} + * {{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}} + * {{< glossary_tooltip text="控制器管理器" term_id="kube-controller-manager" >}} + * {{< glossary_tooltip text="云控制器管理器" term_id="cloud-controller-manager" >}} + +这些组件可以以传统的系统服务运行也可以以容器的形式运行.运行这些组件的主机过去称为 master 节点。 diff --git a/content/zh/docs/reference/glossary/controller.md b/content/zh/docs/reference/glossary/controller.md index 2b523c8b76..e60b710603 100644 --- a/content/zh/docs/reference/glossary/controller.md +++ b/content/zh/docs/reference/glossary/controller.md @@ -1,8 +1,8 @@ --- -title: 控制器 +title: 控制器（Controller） id: controller date: 2018-04-12 -full_link: /docs/admin/kube-controller-manager/ +full_link: /zh/docs/concepts/architecture/controller/ short_description: > 控制器通过 apiserver 监控集群的公共状态，并致力于将当前状态转变为期望的状态。 @@ -17,7 +17,7 @@ tags: title: Controller id: controller date: 2018-04-12 -full_link: /docs/admin/kube-controller-manager/ +full_link: /docs/concepts/architecture/controller/ short_description: > A control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. @@ -27,14 +27,38 @@ tags: - fundamental --- --> + + - 控制器通过 {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} 监控集群的公共状态，并致力于将当前状态转变为期望的状态。 +在 Kubernetes 中，控制器通过监控{{< glossary_tooltip text="集群" term_id="cluster" >}} +的公共状态，并致力于将当前状态转变为期望的状态。 + + + +控制器（{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的一部分） +通过 {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} 监控你的集群中的公共状态。 - -Kubernetes 当前提供的部分控制器例子包括：副本控制器（replication controller）、端点控制器（endpoints controller）、命名空间控制器（namespace controller）、服务账号控制器（serviceaccounts controller）。 +其中一些控制器是运行在控制平面内部的，对 Kubernetes 来说，他们提供核心控制操作。 +比如：部署控制器（deployment controller）、守护控制器（daemonset controller）、 +命名空间控制器（namespace controller）、持久化数据卷控制器（persistent volume +controller）（等）都是运行在 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 中的。 diff --git a/content/zh/docs/reference/glossary/cri-o.md b/content/zh/docs/reference/glossary/cri-o.md index 8eb19ddbbb..9fd744a971 100644 --- a/content/zh/docs/reference/glossary/cri-o.md +++ b/content/zh/docs/reference/glossary/cri-o.md @@ -2,39 +2,51 @@ title: CRI-O id: cri-o date: 2019-05-14 -full_link: https://cri-o.io/docs/ +full_link: https://cri-o.io/#what-is-cri-o short_description: > - 专用于 Kubernetes 的轻量级容器运行环境 + 专用于 Kubernetes 的轻量级容器运行时软件 aka: tags: - tool --- - - -该工具可让您通过 Kubernetes CRI 使用 OCI 容器运行环境。 +--> + +该工具可让你通过 Kubernetes CRI 使用 OCI 容器运行时。 - -CRI-O 是 {{< glossary_tooltip term_id="cri" >}} 的实现，可启用与开放容器倡议 Open Container Initiative（OCI）兼容的 {{< glossary_tooltip text="container" term_id="container" >}} 运行环境[运行时规范](http://www.github.com/opencontainers/runtime-spec)。 +[runtime spec](https://www.github.com/opencontainers/runtime-spec). +--> +CRI-O 是 {{< glossary_tooltip text="CRI" term_id="cri" >}} 的一种实现， +使得你可以使用与开放容器倡议（Open Container Initiative，OCI） +[运行时规范](https://www.github.com/opencontainers/runtime-spec) +兼容的{{< glossary_tooltip text="容器" term_id="container" >}}。 - -部署 CRI-O 允许 Kubernetes 使用任何符合 OCI 运行环境，作为容器运行环境去运行 {{< glossary_tooltip text="Pods" term_id="pod" >}}，并从远程注册表获取 OCI 容器镜像。 \ No newline at end of file +OCI container images from remote registries. +--> +部署 CRI-O 允许 Kubernetes 使用任何符合 OCI 要求的运行时作为容器运行时 +去运行 {{< glossary_tooltip text="Pods" term_id="pod" >}}， +并从远程容器仓库获取 OCI 容器镜像。 + diff --git a/content/zh/docs/reference/glossary/cri.md b/content/zh/docs/reference/glossary/cri.md index 96fd7f4bf4..8c8da979e9 100644 --- a/content/zh/docs/reference/glossary/cri.md +++ b/content/zh/docs/reference/glossary/cri.md @@ -1,5 +1,5 @@ --- -title: 容器运行时接口 (CRI) +title: 容器运行时接口（CRI） id: cri date: 2019-03-07 full_link: /zh/docs/concepts/overview/components/#container-runtime @@ -18,7 +18,7 @@ tags: title: Container runtime interface (CRI) id: cri date: 2019-03-07 -full_link: /zh/docs/concepts/overview/components/#container-runtime +full_link: /docs/concepts/overview/components/#container-runtime short_description: > An API for container runtimes to integrate with kubelet diff --git a/content/zh/docs/reference/glossary/cronjob.md b/content/zh/docs/reference/glossary/cronjob.md index e6838de86c..fe16d58762 100644 --- a/content/zh/docs/reference/glossary/cronjob.md +++ b/content/zh/docs/reference/glossary/cronjob.md @@ -1,10 +1,10 @@ --- -title: CronJob +title: 周期调度任务（CronJob） id: cronjob date: 2018-04-12 full_link: /zh/docs/concepts/workloads/controllers/cron-jobs/ short_description: > - 管理定期运行的 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 + 周期调度的任务（作业）。 aka: tags: @@ -17,9 +17,9 @@ tags: title: CronJob id: cronjob date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/cron-jobs/ +full_link: /docs/concepts/workloads/controllers/cron-jobs/ short_description: > - Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule. + A repeating task (a Job) that runs on a regular schedule. aka: tags: @@ -29,10 +29,10 @@ tags: --> - 管理定期运行的 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 + 管理定期运行的 [任务](/zh/docs/concepts/workloads/controllers/job/)。 diff --git a/content/zh/docs/reference/glossary/csi.md b/content/zh/docs/reference/glossary/csi.md index 2b77146757..89bb66cafd 100644 --- a/content/zh/docs/reference/glossary/csi.md +++ b/content/zh/docs/reference/glossary/csi.md @@ -1,5 +1,5 @@ --- -title: 容器存储接口 (CSI) +title: 容器存储接口（Container Storage Interface，CSI） id: csi date: 2018-06-25 full_link: /zh/docs/concepts/storage/volumes/#csi @@ -17,7 +17,7 @@ tags: title: Container Storage Interface (CSI) id: csi date: 2018-06-25 -full_link: /zh/docs/concepts/storage/volumes/#csi +full_link: /docs/concepts/storage/volumes/#csi short_description: > The Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers. @@ -31,18 +31,22 @@ tags: The Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers. --> - 容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。 + 容器存储接口 （CSI） 定义了存储系统暴露给容器的标准接口。 -CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件，而无需将这些插件的代码添加到 Kubernetes 代码仓库（外部插件）。要使用某个存储提供商的 CSI 驱动，你首先要[将它部署到你的集群上](https://kubernetes-csi.github.io/docs/Setup.html)。然后你才能创建使用该 CSI 驱动的 {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} 。 +CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件， +而无需将这些插件的代码添加到 Kubernetes 代码仓库（外部插件）。 +要使用某个存储提供商的 CSI 驱动，你首先要 +[将它部署到你的集群上](https://kubernetes-csi.github.io/docs/deploying.html)。 +然后你才能创建使用该 CSI 驱动的 {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} 。 -* [Kubernetes 文档中关于 CSI 的描述](/docs/concepts/storage/volumes/#csi) -* [可用的 CSI 驱动列表](https://kubernetes-csi.github.io/docs/Drivers.html) +* [Kubernetes 文档中关于 CSI 的描述](/zh/docs/concepts/storage/volumes/#csi) +* [可用的 CSI 驱动列表](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/zh/docs/reference/glossary/customresourcedefinition.md b/content/zh/docs/reference/glossary/customresourcedefinition.md index 510d26d3bc..ee0548e78d 100644 --- a/content/zh/docs/reference/glossary/customresourcedefinition.md +++ b/content/zh/docs/reference/glossary/customresourcedefinition.md @@ -2,7 +2,7 @@ title: CustomResourceDefinition id: CustomResourceDefinition date: 2018-04-12 -full_link: docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ +full_link: /zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ short_description: > 通过定制化的代码给您的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 @@ -18,8 +18,7 @@ tags: title: CustomResourceDefinition id: CustomResourceDefinition date: 2018-04-12 -full_link: docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ -short_description: > +full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server. aka: diff --git a/content/zh/docs/reference/glossary/daemonset.md b/content/zh/docs/reference/glossary/daemonset.md index ea250d02bc..5f35ae5012 100644 --- a/content/zh/docs/reference/glossary/daemonset.md +++ b/content/zh/docs/reference/glossary/daemonset.md @@ -18,7 +18,7 @@ tags: title: DaemonSet id: daemonset date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/daemonset/ +full_link: /docs/concepts/workloads/controllers/daemonset short_description: > Ensures a copy of a Pod is running across a set of nodes in a cluster. diff --git a/content/zh/docs/reference/glossary/data-plane.md b/content/zh/docs/reference/glossary/data-plane.md index addd1b032b..7c476d4560 100644 --- a/content/zh/docs/reference/glossary/data-plane.md +++ b/content/zh/docs/reference/glossary/data-plane.md @@ -1,5 +1,5 @@ --- -title: 数据平面 +title: 数据平面（Data Plane） id: data-plane date: 2019-05-12 full_link: diff --git a/content/zh/docs/reference/glossary/deployment.md b/content/zh/docs/reference/glossary/deployment.md index 05bce1377b..ca52523e46 100644 --- a/content/zh/docs/reference/glossary/deployment.md +++ b/content/zh/docs/reference/glossary/deployment.md @@ -18,9 +18,9 @@ tags: title: Deployment id: deployment date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/deployment/ +full_link: /docs/concepts/workloads/controllers/deployment/ short_description: > - An API object that manages a replicated application. + Manages a replicated application on your cluster. aka: tags: @@ -31,15 +31,18 @@ tags: --> - Deployment 是管理应用副本的 API 对象。 + Deployment 是管理应用副本的 API 对象，通常通过运行没有本地状态的Pods来实现。 -应用的每个副本就是一个 {{< glossary_tooltip term_id="pod" >}}，并且这些 Pod 会分散运行在集群的节点上。 +应用的每个副本就是一个 {{< glossary_tooltip text="Pod" term_id="pod" >}}， +并且这些 Pod 会分散运行在集群的{{< glossary_tooltip text="节点" term_id="node" >}}上。 diff --git a/content/zh/docs/reference/glossary/developer.md b/content/zh/docs/reference/glossary/developer.md index 2efbeea6e2..1ca23e374f 100644 --- a/content/zh/docs/reference/glossary/developer.md +++ b/content/zh/docs/reference/glossary/developer.md @@ -1,5 +1,5 @@ --- -title: 开发者 (释疑) +title: 开发者（Developer） id: developer date: 2018-04-12 full_link: @@ -28,7 +28,9 @@ tags: --- --> - 指的是： {{< glossary_tooltip text="应用开发者" term_id="application-developer" >}}、 {{< glossary_tooltip text="代码贡献者" term_id="code-contributor" >}}、或 {{< glossary_tooltip text="平台开发者" term_id="platform-developer" >}}。 + 指的是：{{< glossary_tooltip text="应用开发者" term_id="application-developer" >}}、 + {{< glossary_tooltip text="代码贡献者" term_id="code-contributor" >}}、 + 或{{< glossary_tooltip text="平台开发者" term_id="platform-developer" >}}。 diff --git a/content/zh/docs/reference/glossary/device-plugin.md b/content/zh/docs/reference/glossary/device-plugin.md index af7e491426..30664b8c31 100644 --- a/content/zh/docs/reference/glossary/device-plugin.md +++ b/content/zh/docs/reference/glossary/device-plugin.md @@ -1,32 +1,52 @@ --- -title: 驱动插件 +title: 设备插件（Device Plugin） id: device-plugin date: 2019-02-02 full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > - 在 Kubernetes 中运行的容器提供对供应商特定资源的访问权限。 + 一种软件扩展，可以使 Pod 访问由特定厂商初始化或者安装的设备。 aka: tags: - fundamental - extension --- - - -设备插件是在 Kubernetes 中运行的容器，可用于访问供应商特定资源。 - +--- +--> + +设备插件工作在节点主机上，给 {{< glossary_tooltip term_id="pod" text="Pods ">}} 提供访问资源的权限，比如特定厂商初始化或者安装的本地硬件。 - -[驱动插件](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 是运行在 Kubernetes 中的容器，它提供对供应商特定资源的访问。驱动插件将这些资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。并且可以手动部署或做为 {{< glossary_tooltip term_id="daemonset" >}}，而不用编写定制的 Kubernetes 代码。 + +设备插件将资源告知 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} ，以便相关节点上运行的工作负载Pod可以访问硬件功能。 + +更多信息请查阅[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/disruption.md b/content/zh/docs/reference/glossary/disruption.md index e175b930d7..29c7e1ebe6 100644 --- a/content/zh/docs/reference/glossary/disruption.md +++ b/content/zh/docs/reference/glossary/disruption.md @@ -1,5 +1,5 @@ --- -title: 干扰 +title: 干扰（Disruption） id: disruption date: 2019-09-10 full_link: /zh/docs/concepts/workloads/pods/disruptions/ @@ -17,7 +17,7 @@ tags: title: Disruption id: disruption date: 2019-09-10 -full_link: /zh/docs/concepts/workloads/pods/disruptions/ +full_link: /docs/concepts/workloads/pods/disruptions/ short_description: > An event that leads to Pod(s) going out of service aka: @@ -41,5 +41,7 @@ Kubernetes terms that an _involuntary disruption_. See [Disruptions](/docs/concepts/workloads/pods/disruptions/) for more information. --> -如果您作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为 _自愿干扰_。如果由于节点故障 -或者影响更大区域故障的断电导致 Pod 离线，Kubrenetes 视之为 _非愿干扰_。 \ No newline at end of file +如果您作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为 _自愿干扰（Voluntary Disruption）_。如果由于节点故障 +或者影响更大区域故障的断电导致 Pod 离线，Kubrenetes 视之为 _非愿干扰（Involuntary Disruption）_。 + +更多信息请查阅[Disruptions](/zh/docs/concepts/workloads/pods/disruptions/) \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/docker.md b/content/zh/docs/reference/glossary/docker.md index 55782a84c8..bec6c834f2 100644 --- a/content/zh/docs/reference/glossary/docker.md +++ b/content/zh/docs/reference/glossary/docker.md @@ -1,5 +1,5 @@ --- -title: docker +title: Docker id: docker date: 2018-04-12 full_link: /zh/docs/reference/kubectl/docker-cli-to-kubectl/ @@ -13,10 +13,10 @@ tags: - Docker 是一种可以提供操作系统级别虚拟化（也称作容器）的软件技术 + Docker（这里特指 Docker 引擎） 是一种可以提供操作系统级别虚拟化（也称作{{< glossary_tooltip text="容器" term_id="container" >}}）的软件技术。 @@ -38,4 +38,5 @@ tags: Docker uses the resource isolation features of the Linux kernel such as cgroups and kernel namespaces, and a union-capable file system such as OverlayFS and others to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines (VMs). --> -Docker 使用了 Linux 内核中的资源隔离特性（如 cgroup 和内核命名空间）以及支持联合文件系统（如 OverlayFS 和其他），允许多个相互独立的“容器”一起运行在同一 Linux 实例上，从而避免启动和维护虚拟机（VMs）的开销。 +Docker 使用了 Linux 内核中的资源隔离特性（如 cgroup 和内核命名空间）以及支持联合文件系统（如 OverlayFS 和其他）， +允许多个相互独立的“容器”一起运行在同一 Linux 实例上，从而避免启动和维护虚拟机（VMs）的开销。 diff --git a/content/zh/docs/reference/glossary/downstream.md b/content/zh/docs/reference/glossary/downstream.md index 575d9c74e0..cba0229cb9 100644 --- a/content/zh/docs/reference/glossary/downstream.md +++ b/content/zh/docs/reference/glossary/downstream.md @@ -1,5 +1,5 @@ --- -title: 下游(消除歧义) +title: 下游（Downstream） id: downstream date: 2018-04-12 full_link: diff --git a/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md b/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md index 1d3c67e285..5606af15a4 100644 --- a/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md +++ b/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md @@ -1,5 +1,5 @@ --- -title: 动态卷供应 +title: 动态卷供应（Dynamic Volume Provisioning） id: dynamicvolumeprovisioning date: 2018-04-12 full_link: /zh/docs/concepts/storage/dynamic-provisioning/ @@ -17,7 +17,7 @@ tags: title: Dynamic Volume Provisioning id: dynamicvolumeprovisioning date: 2018-04-12 -full_link: /zh/docs/concepts/storage/dynamic-provisioning/ +full_link: /docs/concepts/storage/dynamic-provisioning short_description: > Allows users to request automatic creation of storage Volumes. @@ -41,4 +41,6 @@ Dynamic provisioning eliminates the need for cluster administrators to pre-provi --> 动态供应让集群管理员无需再预先供应存储。相反，它通过用户请求自动地供应存储。 -动态卷供应是基于 API 对象 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 的，StorageClass 可以引用 {{< glossary_tooltip text="卷插件（Volume Plugin）" term_id="volume-plugin" >}} 提供的 {{< glossary_tooltip text="卷（Volume）" term_id="volume" >}} ，也可以引用传递给卷插件（Volume Plugin）的参数集。 +动态卷供应是基于 API 对象 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} 的， +StorageClass 可以引用 {{< glossary_tooltip text="卷插件" term_id="volume-plugin" >}} 提供的 +{{< glossary_tooltip text="卷" term_id="volume" >}}，也可以引用传递给卷插件（Volume Plugin）的参数集。 diff --git a/content/zh/docs/reference/glossary/endpoint-slice.md b/content/zh/docs/reference/glossary/endpoint-slice.md index c108efd602..dcfc35e308 100644 --- a/content/zh/docs/reference/glossary/endpoint-slice.md +++ b/content/zh/docs/reference/glossary/endpoint-slice.md @@ -1,5 +1,5 @@ --- -title: 端点切片 +title: EndpointSlice id: endpoint-slice date: 2018-04-12 full_link: /zh/docs/concepts/services-networking/endpoint-slices/ @@ -14,10 +14,10 @@ tags: -一种将网络端点组合在一起的可扩缩、可扩展方式。它们将被 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 用于在每个 {{< glossary_tooltip text="节点" term_id="node">}} 上建立网络路由。 +一种将网络端点组合在一起的可扩缩、可扩展方式。 +它们将被 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 用于在 +每个 {{< glossary_tooltip text="节点" term_id="node">}} 上建立网络路由。 diff --git a/content/zh/docs/reference/glossary/endpoint.md b/content/zh/docs/reference/glossary/endpoint.md index ee9342cd6a..642d7c46d2 100644 --- a/content/zh/docs/reference/glossary/endpoint.md +++ b/content/zh/docs/reference/glossary/endpoint.md @@ -23,14 +23,16 @@ short_description: > aka: tags: - networking + Endpoints track the IP addresses of Pods with matching {{< glossary_tooltip text="selectors" term_id="selector" >}}. --> -端点可以手动配置到{{< glossary_tooltip text="服务（Service）" term_id="service" >}}上，而不必设置选择算符。 -{{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} 资源为 Endpoints -提供了一种可伸缩、可扩展的替代方案。 +端点可以手动配置到{{< glossary_tooltip text="服务（Service）" term_id="service" >}}上，而不必指定选择器标识。 + +{{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}}提供了一种可伸缩、可扩展的替代方案。 diff --git a/content/zh/docs/reference/glossary/ephemeral-container.md b/content/zh/docs/reference/glossary/ephemeral-container.md index fa95887e8d..d937404797 100644 --- a/content/zh/docs/reference/glossary/ephemeral-container.md +++ b/content/zh/docs/reference/glossary/ephemeral-container.md @@ -1,5 +1,5 @@ --- -title: 临时容器 +title: 临时容器（Ephemeral Container） id: ephemeral-container date: 2019-08-26 full_link: /zh/docs/concepts/workloads/pods/ephemeral-containers/ @@ -9,14 +9,14 @@ aka: tags: - fundamental --- - 您可以在 {{< glossary_tooltip term_id="pod" >}} 中临时运行的一种 {{< glossary_tooltip term_id="container" >}} 类型 + 您可以在 {{< glossary_tooltip term_id="pod" >}} 中临时运行的一种 {{< glossary_tooltip term_id="container" >}} 类型。 -如果想要调查运行中有问题的 Pod，可以向该 Pod 添加一个临时容器并进行诊断。临时容器没有资源或调度保证，因此不应该使用它们来运行任何部分的工作负荷本身。 \ No newline at end of file +如果想要调查运行中有问题的 Pod，可以向该 Pod 添加一个临时容器并进行诊断。 +临时容器没有资源或调度保证，因此不应该使用它们来运行任何部分的工作负荷本身。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/etcd.md b/content/zh/docs/reference/glossary/etcd.md index e0e11082a8..9dec928b29 100644 --- a/content/zh/docs/reference/glossary/etcd.md +++ b/content/zh/docs/reference/glossary/etcd.md @@ -17,7 +17,7 @@ tags: title: etcd id: etcd date: 2018-04-12 -full_link: /zh/docs/tasks/administer-cluster/configure-upgrade-etcd/ +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ short_description: > Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data. @@ -35,9 +35,14 @@ tags: etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。 - +您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。 + -您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。要了解 etcd 更深层次的信息，请参考 [etcd 文档](https://etcd.io/docs)。 +要了解 etcd 更深层次的信息，请参考 [etcd 文档](https://etcd.io/docs/)。 diff --git a/content/zh/docs/reference/glossary/extensions.md b/content/zh/docs/reference/glossary/extensions.md index ebc25eca05..dca292faf6 100644 --- a/content/zh/docs/reference/glossary/extensions.md +++ b/content/zh/docs/reference/glossary/extensions.md @@ -1,5 +1,5 @@ --- -title: 扩展组件 +title: 扩展组件（Extensions） id: Extensions date: 2019-02-01 full_link: /zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions @@ -17,7 +17,7 @@ tags: title: Extensions id: Extensions date: 2019-02-01 -full_link: /zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions +full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions short_description: > Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware. @@ -35,4 +35,6 @@ tags: Most cluster administrators will use a hosted or distribution instance of Kubernetes. As a result, most Kubernetes users will need to install [extensions](/docs/concepts/extend-kubernetes/extend-cluster/#extensions) and fewer will need to author new ones. --> -大多数集群管理员会使用托管的 Kubernetes 或其某种发行包。因此，大多数 Kubernetes 用户将需要安装 [扩展组件](/docs/concepts/extend-kubernetes/extend-cluster/#extensions)，较少用户会需要编写新的扩展组件。 \ No newline at end of file +大多数集群管理员会使用托管的 Kubernetes 或其某种发行包。因此，大多数 Kubernetes 用户将需要 +安装 [扩展组件](/docs/concepts/extend-kubernetes/extend-cluster/#extensions)， +较少用户会需要编写新的扩展组件。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/flexvolume.md b/content/zh/docs/reference/glossary/flexvolume.md index af28200f40..51b0690392 100644 --- a/content/zh/docs/reference/glossary/flexvolume.md +++ b/content/zh/docs/reference/glossary/flexvolume.md @@ -16,7 +16,7 @@ tags: title: FlexVolume id: flexvolume date: 2018-06-25 -full_link: /zh/docs/concepts/storage/volumes/#flexvolume +full_link: /docs/concepts/storage/volumes/#flexvolume short_description: > FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes. @@ -25,17 +25,26 @@ aka: tags: - storage --- --> - + Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 是比 Flexvolume 更新的接口，它解决了 Flexvolume 的一些问题。 - -Flexvolume 允许用户编写自己的驱动程序，并在 Kubernetes 中加入对用户自己的数据卷的支持。FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。这需要 root 权限。如果可能的话，SIG Storage 建议实现 {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序，因为它解决了 Flexvolumes 的限制。 + +Flexvolume 允许用户编写自己的驱动程序，并在 Kubernetes 中加入对用户自己的数据卷的支持。 +FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。 +这需要 root 权限。如果可能的话，SIG Storage 建议实现 {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序， +因为它解决了 Flexvolumes 的限制。 - + * [Kubernetes 文档中的 Flexvolume](/docs/concepts/storage/volumes/#flexvolume) -* [更多关于 Flexvolumes 的信息](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md) +* [更多关于 Flexvolumes 的信息](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) * [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/helm-chart.md b/content/zh/docs/reference/glossary/helm-chart.md index d76c6a7906..625a897d17 100644 --- a/content/zh/docs/reference/glossary/helm-chart.md +++ b/content/zh/docs/reference/glossary/helm-chart.md @@ -40,4 +40,5 @@ A single chart can be used to deploy something simple, like a memcached Pod, or --> Chart 提供了一种可重现的用来创建和共享 Kubernetes 应用的方法。 -单个 Chart 可用来部署简单的系统（例如一个 memcached Pod），也可以用来部署复杂的系统（例如包含 HTTP 服务器、数据库、缓存等组件的完整 Web 应用堆栈）。 +单个 Chart 可用来部署简单的系统（例如一个 memcached Pod）， +也可以用来部署复杂的系统（例如包含 HTTP 服务器、数据库、缓存等组件的完整 Web 应用堆栈）。 diff --git a/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md index 3a94a04b5a..45e5033a5a 100644 --- a/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md +++ b/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md @@ -1,5 +1,5 @@ --- -title: Pod 水平自动扩缩器 +title: Pod 水平自动扩缩器（Horizontal Pod Autoscaler） id: horizontal-pod-autoscaler date: 2018-04-12 full_link: /zh/docs/tasks/run-application/horizontal-pod-autoscale/ @@ -7,6 +7,7 @@ short_description: > Pod 水平自动扩缩器（Horizontal Pod Autoscaler）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。 aka: +- HPA tags: - operation --- @@ -16,22 +17,26 @@ tags: title: Horizontal Pod Autoscaler id: horizontal-pod-autoscaler date: 2018-04-12 -full_link: /zh/docs/tasks/run-application/horizontal-pod-autoscale/ +full_link: /docs/tasks/run-application/horizontal-pod-autoscale/ short_description: > An API resource that automatically scales the number of pod replicas based on targeted CPU utilization or custom metric targets. aka: +- HPA tags: - operation --- --> - Pod 水平自动扩缩器（Horizontal Pod Autoscaler）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。 + Horizontal Pod Autoscaler（Pod 水平自动扩缩器）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。 -HPA 通常用于 {{< glossary_tooltip text="Replication Controllers" term_id="replication-controller" >}}、{{< glossary_tooltip text="Deployments" term_id="deployment" >}} 或者 Replica Sets 上。HPA 不能用于不支持扩缩的对象，例如 {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}。 +HPA 通常用于 {{< glossary_tooltip text="ReplicationControllers" term_id="replication-controller" >}} +、{{< glossary_tooltip text="Deployments" term_id="deployment" >}} +或者 {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 上。 +HPA 不能用于不支持扩缩的对象，例如 {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}。 diff --git a/content/zh/docs/reference/glossary/host-aliases.md b/content/zh/docs/reference/glossary/host-aliases.md index 6581acf209..c2be10bee2 100644 --- a/content/zh/docs/reference/glossary/host-aliases.md +++ b/content/zh/docs/reference/glossary/host-aliases.md @@ -33,5 +33,6 @@ tags: -[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) 是一个包含主机名和 IP 地址的可选列表，配置后将被注入到 Pod 内的 hosts 文件中。 +[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) +是一个包含主机名和 IP 地址的可选列表，配置后将被注入到 Pod 内的 hosts 文件中。 该选项仅适用于没有配置 hostNetwork 的 Pod. diff --git a/content/zh/docs/reference/glossary/image.md b/content/zh/docs/reference/glossary/image.md index 1fc7db55e5..ea8a7ffda1 100644 --- a/content/zh/docs/reference/glossary/image.md +++ b/content/zh/docs/reference/glossary/image.md @@ -1,5 +1,5 @@ --- -title: 镜像 +title: 镜像（Image） id: image date: 2018-04-12 full_link: @@ -27,10 +27,10 @@ tags: --> -镜像是保存的容器实例，它打包了应用运行所需的一组软件。 +镜像是保存的{{< glossary_tooltip text="容器" term_id="container" >}}实例，它打包了应用运行所需的一组软件。 diff --git a/content/zh/docs/reference/glossary/ingress.md b/content/zh/docs/reference/glossary/ingress.md index 972c2b0873..2b08741574 100644 --- a/content/zh/docs/reference/glossary/ingress.md +++ b/content/zh/docs/reference/glossary/ingress.md @@ -18,7 +18,7 @@ tags: title: Ingress id: ingress date: 2018-04-12 -full_link: /zh/docs/concepts/services-networking/ingress/ +full_link: /docs/concepts/services-networking/ingress/ short_description: > An API object that manages external access to the services in a cluster, typically HTTP. @@ -39,7 +39,7 @@ tags: Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。 diff --git a/content/zh/docs/reference/glossary/init-container.md b/content/zh/docs/reference/glossary/init-container.md index cf8cead312..7efeddb4e5 100644 --- a/content/zh/docs/reference/glossary/init-container.md +++ b/content/zh/docs/reference/glossary/init-container.md @@ -1,5 +1,5 @@ --- -title: 初始化容器 +title: 初始化容器（Init Container） id: init-container date: 2018-04-12 full_link: @@ -18,7 +18,7 @@ id: init-container date: 2018-04-12 full_link: short_description: > - One or more initialization containers that must run to completion before any app containers run. + One or more initialization containers that must run to completion before any app containers run. aka: tags: @@ -27,15 +27,16 @@ tags: --> - 应用容器运行前必须先运行完成的一个或多个初始化容器。 + 应用{{< glossary_tooltip text="容器" term_id="container" >}}运行前必须先运行完成的一个或多个初始化容器。 -初始化（init）容器像常规应用容器一样，只有一点不同：初始化（init）容器必须在应用容器启动前运行完成。Init 容器的运行顺序：一个初始化（init）容器必须在下一个初始化（init）容器开始前运行完成。 +初始化（init）容器像常规应用容器一样，只有一点不同：初始化（init）容器必须在应用容器启动前运行完成。 +Init 容器的运行顺序：一个初始化（init）容器必须在下一个初始化（init）容器开始前运行完成。 diff --git a/content/zh/docs/reference/glossary/istio.md b/content/zh/docs/reference/glossary/istio.md index 58c4cfffcc..4a3300f4f6 100644 --- a/content/zh/docs/reference/glossary/istio.md +++ b/content/zh/docs/reference/glossary/istio.md @@ -2,7 +2,7 @@ title: Istio id: istio date: 2018-04-12 -full_link: https://istio.io/docs/concepts/what-is-istio/overview.html +full_link: https://istio.io/docs/concepts/what-is-istio/ short_description: > Istio 是个开放平台（非 Kubernetes 特有），提供了一种统一的方式来集成微服务、管理流量、实施策略和汇总度量数据。 aka: @@ -17,7 +17,7 @@ tags: title: Istio id: istio date: 2018-04-12 -full_link: https://istio.io/docs/concepts/what-is-istio/overview.html +full_link: https://istio.io/docs/concepts/what-is-istio/ short_description: > An open platform (not Kubernetes-specific) that provides a uniform way to integrate microservices, manage traffic flow, enforce policies, and aggregate telemetry data. @@ -41,5 +41,7 @@ Istio 是个开放平台（非 Kubernetes 特有），提供了一种统一的 Adding Istio does not require changing application code. It is a layer of infrastructure between a service and the network, which when combined with service deployments, is commonly referred to as a service mesh. Istio's control plane abstracts away the underlying cluster management platform, which may be Kubernetes, Mesosphere, etc. --> -添加 Istio 时不需要修改应用代码。它是基础设施的一层，介于服务和网络之间。当它和服务的 Deployment 相结合时，就构成了通常所谓的服务网格（Service Mesh）。Istio 的控制面抽象掉了底层的集群管理平台，这一集群管理平台可以是 Kubernetes、Mesosphere 等。 +添加 Istio 时不需要修改应用代码。它是基础设施的一层，介于服务和网络之间。 +当它和服务的 Deployment 相结合时，就构成了通常所谓的服务网格（Service Mesh）。 +Istio 的控制面抽象掉了底层的集群管理平台，这一集群管理平台可以是 Kubernetes、Mesosphere 等。 diff --git a/content/zh/docs/reference/glossary/job.md b/content/zh/docs/reference/glossary/job.md index 8ce421f280..aa557297be 100644 --- a/content/zh/docs/reference/glossary/job.md +++ b/content/zh/docs/reference/glossary/job.md @@ -2,7 +2,7 @@ title: Job id: job date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +full_link: /zh/docs/concepts/workloads/controllers/job/ short_description: > Job 是需要运行完成的确定性的或批量的任务。 @@ -18,7 +18,7 @@ tags: title: Job id: job date: 2018-04-12 -full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +full_link: /docs/concepts/workloads/controllers/job/ short_description: > A finite or batch task that runs to completion. @@ -42,4 +42,5 @@ tags: Creates one or more {{< glossary_tooltip term_id="pod" >}} objects and ensures that a specified number of them successfully terminate. As Pods successfully complete, the Job tracks the successful completions. --> -Job 创建一个或多个 {{< glossary_tooltip term_id="Pod" >}} 对象，并确保指定数量的 Pod 成功终止。随着各 Pod 成功结束，Job 会跟踪记录成功完成的个数。 +Job 创建一个或多个 {{< glossary_tooltip term_id="Pod" >}} 对象，并确保指定数量的 Pod 成功终止。 +随着各 Pod 成功结束，Job 会跟踪记录成功完成的个数。 diff --git a/content/zh/docs/reference/glossary/kops.md b/content/zh/docs/reference/glossary/kops.md index c1024390e7..d3241b763e 100644 --- a/content/zh/docs/reference/glossary/kops.md +++ b/content/zh/docs/reference/glossary/kops.md @@ -4,7 +4,7 @@ id: kops date: 2018-04-12 full_link: /docs/getting-started-guides/kops/ short_description: > - kops 是一个命令行工具，可以帮助您创建、销毁、升级和维护生产级，高可用性的 Kubernetes 集群。注意：官方仅支持 AWS，GCE 和 VMware vSphere 的支持还处于 alpha* 阶段。 + kops 是一个命令行工具，可以帮助您创建、销毁、升级和维护生产级，高可用性的 Kubernetes 集群。 aka: tags: @@ -19,7 +19,7 @@ id: kops date: 2018-04-12 full_link: /docs/getting-started-guides/kops/ short_description: > - A CLI tool that helps you create, destroy, upgrade and maintain production-grade, highly available, Kubernetes clusters. *NOTE: Officially supports AWS only, with GCE and VMware vSphere in alpha*. + A CLI tool that helps you create, destroy, upgrade and maintain production-grade, highly available, Kubernetes clusters. aka: tags: @@ -29,13 +29,22 @@ tags: --> -kops 是一个命令行工具，可以帮助您创建、销毁、升级和维护生产级，高可用性的 Kubernetes 集群。*注意：官方仅支持 AWS，GCE 和 VMware vSphere 的支持还处于 alpha 阶段*。 +kops 是一个命令行工具，可以帮助您创建、销毁、升级和维护生产级，高可用性的 Kubernetes 集群。 + +注意：官方仅支持 AWS，GCE 和 VMware vSphere 的支持还处于 alpha* 阶段。 + + `kops` 为您的集群提供了： diff --git a/content/zh/docs/reference/glossary/kube-controller-manager.md b/content/zh/docs/reference/glossary/kube-controller-manager.md index c24234e501..5d18857fde 100644 --- a/content/zh/docs/reference/glossary/kube-controller-manager.md +++ b/content/zh/docs/reference/glossary/kube-controller-manager.md @@ -31,9 +31,10 @@ tags: -在主节点上运行{{< glossary_tooltip text="控制器" term_id="controller" >}}的组件。 +在主节点上运行 {{< glossary_tooltip text="控制器" term_id="controller" >}} 的组件。 -从逻辑上讲，每个{{< glossary_tooltip text="控制器" term_id="controller" >}}都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。 +从逻辑上讲，每个{{< glossary_tooltip text="控制器" term_id="controller" >}}都是一个单独的进程， +但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。 diff --git a/content/zh/docs/reference/glossary/kube-proxy.md b/content/zh/docs/reference/glossary/kube-proxy.md index 79c7e2b82a..2b1048147f 100644 --- a/content/zh/docs/reference/glossary/kube-proxy.md +++ b/content/zh/docs/reference/glossary/kube-proxy.md @@ -27,7 +27,8 @@ tags: - [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理,实现 Kubernetes {{< glossary_tooltip term_id="service">}} 概念的一部分。 +[kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理， +实现 Kubernetes {{< glossary_tooltip term_id="service">}} 概念的一部分。 @@ -38,4 +39,4 @@ kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内 -如果操作系统提供了数据包过滤层并可用的话，kube-proxy会通过它来实现网络规则。否则，kube-proxy 仅转发流量本身。 +如果操作系统提供了数据包过滤层并可用的话，kube-proxy 会通过它来实现网络规则。否则， kube-proxy 仅转发流量本身。 diff --git a/content/zh/docs/reference/glossary/kubeadm.md b/content/zh/docs/reference/glossary/kubeadm.md index 3d7ce11b59..f565376100 100644 --- a/content/zh/docs/reference/glossary/kubeadm.md +++ b/content/zh/docs/reference/glossary/kubeadm.md @@ -2,7 +2,7 @@ title: Kubeadm id: kubeadm date: 2018-04-12 -full_link: /docs/admin/kubeadm/ +full_link: /zh/docs/setup/production-environment/tools/kubeadm/ short_description: > 用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 @@ -13,7 +13,6 @@ tags: --- - - 用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 +用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 +你可以使用 kubeadm 安装控制面和 +{{< glossary_tooltip text="工作节点" term_id="node" >}} +组件。 -您可以使用 kubeadm 安装控制面和工作节点组件。 diff --git a/content/zh/docs/reference/glossary/kubelet.md b/content/zh/docs/reference/glossary/kubelet.md index c561109b6e..4562f02f1f 100644 --- a/content/zh/docs/reference/glossary/kubelet.md +++ b/content/zh/docs/reference/glossary/kubelet.md @@ -12,7 +12,6 @@ tags: - core-object --- + -一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 +一个在集群中每个节点上运行的代理。 +它保证容器都运行在 Pod 中。 +kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs +中描述的容器处于运行状态且健康。 +kubelet 不会管理不是由 Kubernetes 创建的容器。 -kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。 diff --git a/content/zh/docs/reference/glossary/node.md b/content/zh/docs/reference/glossary/node.md index 1277aa26ab..a646065b02 100644 --- a/content/zh/docs/reference/glossary/node.md +++ b/content/zh/docs/reference/glossary/node.md @@ -1,5 +1,5 @@ --- -title: 节点 +title: 节点（Node） id: node date: 2018-04-12 full_link: /zh/docs/concepts/architecture/nodes/ @@ -25,19 +25,26 @@ tags: --> - Kubernetes 中的工作机器称作节点。 - 工作机器可以是虚拟机也可以是物理机，取决于集群的配置。 -其上部署了运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} 所必需的{{< glossary_tooltip text="服务" term_id="service" >}}， +其上部署了运行 {{< glossary_tooltip text="Pods" term_id="pod" >}} +所必需的本地守护进程或{{< glossary_tooltip text="服务" term_id="service" >}}， 并由主控组件来管理。 -节点上的{{< glossary_tooltip text="服务" term_id="service" >}}包括 Docker、kubelet 和 kube-proxy。 +节点上的的守护进程包括 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、 +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} +以及一个 {{< glossary_tooltip term_id="docker" >}} 这种 +实现了 {{< glossary_tooltip text="CRI" term_id="cri" >}} +的容器运行时。 + +在早期的 Kubernetes 版本中，节点也称作 "Minions"。 diff --git a/content/zh/docs/reference/glossary/platform-developer.md b/content/zh/docs/reference/glossary/platform-developer.md index 0cc10ac633..d18ad680b7 100644 --- a/content/zh/docs/reference/glossary/platform-developer.md +++ b/content/zh/docs/reference/glossary/platform-developer.md @@ -1,5 +1,5 @@ --- -title: 平台开发者 +title: 平台开发人员（Platform Developer） id: platform-developer date: 2018-04-12 full_link: @@ -12,7 +12,6 @@ tags: --- - 定制 Kubernetes 平台以满足自己的项目需求的人。 +定制 Kubernetes 平台以满足自己的项目需求的人。 -例如，平台开发人员可以使用[定制资源](/docs/concepts/api-extension/custom-resources/)或[使用汇聚层扩展 Kubernetes API](/docs/concepts/api-extension/apiserver-aggregation/) 来为其 Kubernetes 实例增加功能，特别是为其应用程序添加功能。一些平台开发人员也是 Kubrenetes {{< glossary_tooltip text="贡献者" term_id="contributor" >}}，他们会开发贡献给 Kubernetes 社区的扩展；另一些则开发封闭源代码的商业扩展或用于特定功能的扩展。 +平台开发人员可以使用[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +或[使用汇聚层扩展 Kubernetes API](/zh/docs/concepts/api-extension/apiserver-aggregation/) +来为其 Kubernetes 实例增加功能，特别是为其应用程序添加功能。 +一些平台开发人员也是 Kubrenetes {{< glossary_tooltip text="贡献者" term_id="contributor" >}}， +他们会开发贡献给 Kubernetes 社区的扩展。 +另一些平台开发人员则开发封闭源代码的商业扩展或用于特定网站的扩展。 diff --git a/content/zh/docs/reference/glossary/pod-priority.md b/content/zh/docs/reference/glossary/pod-priority.md index d66561d9d7..d58eaed928 100644 --- a/content/zh/docs/reference/glossary/pod-priority.md +++ b/content/zh/docs/reference/glossary/pod-priority.md @@ -1,8 +1,8 @@ --- -title: Pod 优先级 +title: Pod 优先级（Pod Priority） id: pod-priority date: 2019-01-31 -full_link: /docs/concepts/configuration/pod-priority-preemption/#pod-priority +full_link: /zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority short_description: > Pod 优先级表示一个 Pod 相对于其他 Pod 的重要性。 @@ -12,7 +12,6 @@ tags: --- -[Pod 优先级](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) 允许为一个 Pod 设置高于或低于其他 Pod 的优先级 -- 这对于生产集群工作负载而言是一个重要的特性。 \ No newline at end of file +[Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority) +允许用户为 Pod 设置高于或低于其他 Pod 的优先级 -- 这对于生产集群 +工作负载而言是一个重要的特性。 + diff --git a/content/zh/docs/reference/glossary/preemption.md b/content/zh/docs/reference/glossary/preemption.md index 575b329065..3475e6ab01 100644 --- a/content/zh/docs/reference/glossary/preemption.md +++ b/content/zh/docs/reference/glossary/preemption.md @@ -1,10 +1,11 @@ --- -title: 抢占 +title: 抢占（Preemption） id: preemption date: 2019-01-31 -full_link: /docs/concepts/configuration/pod-priority-preemption/#preemption +full_link: /zh/docs/concepts/configuration/pod-priority-preemption/#preemption short_description: > - Kubernetes 中的抢占逻辑通过驱逐节点上的低优先级 Pod 来帮助挂起的 Pod 找到合适的节点。 + Kubernetes 中的抢占逻辑通过驱逐节点上的低优先级 Pod 来帮助悬决的 + Pod 找到合适的节点。 aka: tags: @@ -12,7 +13,6 @@ tags: --- - Kubernetes 中的抢占逻辑通过驱逐节点上的低优先级 Pod 来帮助挂起的 Pod 找到合适的节点。 +Kubernetes 中的抢占逻辑通过驱逐{{< glossary_tooltip term_id="node" >}} +上的低优先级{{< glossary_tooltip term_id="pod" >}} +来帮助悬决的 Pod 找到合适的节点。 -如果一个 Pod 无法调度，调度器会尝试[抢占](/docs/concepts/configuration/pod-priority-preemption/#preemption)较低优先级的 Pod，以使得挂起的 Pod 可能被调度。 \ No newline at end of file +如果一个 Pod 无法调度，调度器会尝试 +[抢占](/zh/docs/concepts/configuration/pod-priority-preemption/#preemption) +较低优先级的 Pod，以使得悬决的 Pod 有可能被调度。 + diff --git a/content/zh/docs/reference/glossary/proxy.md b/content/zh/docs/reference/glossary/proxy.md index e8ab669393..889037e3ad 100644 --- a/content/zh/docs/reference/glossary/proxy.md +++ b/content/zh/docs/reference/glossary/proxy.md @@ -1,5 +1,5 @@ --- -title: 代理 +title: 代理（Proxy） id: proxy date: 2019-09-10 short_description: > diff --git a/content/zh/docs/reference/glossary/qos-class.md b/content/zh/docs/reference/glossary/qos-class.md index 82b18bfe38..b7eac1defe 100644 --- a/content/zh/docs/reference/glossary/qos-class.md +++ b/content/zh/docs/reference/glossary/qos-class.md @@ -1,5 +1,5 @@ --- -title: QoS 类 +title: QoS 类（QoS Class） id: qos-class date: 2019-04-15 full_link: diff --git a/content/zh/docs/reference/glossary/quantity.md b/content/zh/docs/reference/glossary/quantity.md index 70d5a95ffa..03cc80051c 100644 --- a/content/zh/docs/reference/glossary/quantity.md +++ b/content/zh/docs/reference/glossary/quantity.md @@ -1,17 +1,17 @@ --- -title: 数量 +title: 量纲（Quantity） id: quantity date: 2018-08-07 full_link: short_description: > - 使用 SI 后缀的小数或大数的整数表示。 + 使用全数字来表示较小数值或使用 SI 后缀表示较大数值的表示法。 aka: tags: - core-object --- + + +使用全数字来表示较小数值或使用 SI 后缀表示较大数值的表示法。 + -数量是使用紧凑的整数表示法的小数或大数的表示，并带有国际计量单位制（SI）后缀。 -小数用 milli 单位表示，而大数用 kilo、mega 或 giga 单位表示。 - -例如，数字 `1.5` 表示为`1500m`， -而数字`1000`表示为`1k`，`1000000`表示为`1M`。 -您还可以指定二进制表示法后缀; 数字 2048 可以写成`2Ki`。 - -公认的十进制（10的幂）单位是 `m`（milli）、`k`（kilo， -有意小写）、`M`（mega），`G`（giga）、`T`（terra）、`P`（peta）、 -`E`（exa）。 - -公认的二进制（2的幂）单位是 `Ki` (kibi)、 `Mi` (mebi)、`Gi` (gibi)、 -`Ti` (tebi)、 `Pi` (pebi)、 `Ei` (exbi)。 - +量纲是使用紧凑的全数字表示法来表示小数值或带有国际计量单位制（SI） +的大数值的表示法。 +小数用 milli 单位表示，而大数用 kilo、mega 或 giga 单位表示。 + +例如，数字 `1.5` 表示为 `1500m`， +而数字 `1000` 表示为 `1k`，`1000000` 表示为 `1M`。 +你还可以指定二进制表示法后缀；数字 2048 可以写成 `2Ki`。 + +公认的十进制（10 的幂数）单位是 `m`（milli）、`k`（kilo，有意小写）、 +`M`（mega）、`G`（giga）、`T`（terra）、`P`（peta）、`E`（exa）。 + +公认的二进制（2 的幂数）单位是 `Ki` (kibi)、`Mi` (mebi)、`Gi` (gibi)、 +`Ti` (tebi)、 `Pi` (pebi)、 `Ei` (exbi)。 + diff --git a/content/zh/docs/reference/glossary/rbac.md b/content/zh/docs/reference/glossary/rbac.md index e0efa640e7..d0a8eaf88a 100644 --- a/content/zh/docs/reference/glossary/rbac.md +++ b/content/zh/docs/reference/glossary/rbac.md @@ -1,5 +1,5 @@ --- -title: RBAC（基于角色的访问控制） +title: 基于角色的访问控制（RBAC） id: rbac date: 2018-04-12 full_link: /zh/docs/reference/access-authn-authz/rbac/ diff --git a/content/zh/docs/reference/glossary/replication-controller.md b/content/zh/docs/reference/glossary/replication-controller.md index 8fd910e799..3ac4033f42 100644 --- a/content/zh/docs/reference/glossary/replication-controller.md +++ b/content/zh/docs/reference/glossary/replication-controller.md @@ -1,10 +1,10 @@ --- -title: Replication Controller +title: 副本控制器（Replication Controller） id: replication-controller date: 2018-04-12 full_link: short_description: > - Replication Controller 是 Kubernetes 的一种服务，用来确保给定个数的 Pod 一直处于运行状态。 + 一种管理多副本应用的（已启用）的 API 对象。 aka: tags: @@ -13,31 +13,41 @@ tags: --- - -Replication Controller 是 Kubernetes 的一种服务，用来确保给定个数的 Pod 一直处于运行状态。 +一种工作管理多副本应用的负载资源，能够确保特定个数的 +{{< glossary_tooltip text="Pod" term_id="pod" >}} +实例处于运行状态。 +控制面确保所指定的个数的 Pods 处于运行状态，即使某些 Pod 会失效， +比如被你手动删除或者因为其他错误启动过多 Pod 时。 + +{{< note >}} + +ReplicationController 已被启用。请参见 Deployment 执行类似功能。 +{{< /note >}} -Replication Controller 会基于设定值自动增删 Pod 的实例。如果 Pod 被误删除或者启动实例过多，Replication Controller 允许 Pod 的实例个数恢复到设定值。 diff --git a/content/zh/docs/reference/glossary/resource-quota.md b/content/zh/docs/reference/glossary/resource-quota.md index 658a1633ce..4e35800abe 100644 --- a/content/zh/docs/reference/glossary/resource-quota.md +++ b/content/zh/docs/reference/glossary/resource-quota.md @@ -1,5 +1,5 @@ --- -title: 资源配额 +title: 资源配额（Resource Quotas） id: resource-quota date: 2018-04-12 full_link: /zh/docs/concepts/policy/resource-quotas/ diff --git a/content/zh/docs/reference/glossary/reviewer.md b/content/zh/docs/reference/glossary/reviewer.md index a181122927..fb1ffcdf83 100644 --- a/content/zh/docs/reference/glossary/reviewer.md +++ b/content/zh/docs/reference/glossary/reviewer.md @@ -1,5 +1,5 @@ --- -title: 评审者 +title: 评审者（Reviewer） id: reviewer date: 2018-04-12 full_link: diff --git a/content/zh/docs/reference/glossary/rkt.md b/content/zh/docs/reference/glossary/rkt.md deleted file mode 100644 index 6ba0e19d7d..0000000000 --- a/content/zh/docs/reference/glossary/rkt.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: rkt -id: rkt -date: 2019-01-24 -translater: Coffey Gao -full_link: https://coreos.com/rkt/ -short_description: > - 一个安全的、基于标准的容器引擎。 - -aka: -tags: -- security -- tool ---- - - - - - - 一个安全的、基于标准的容器引擎。 - - - - - -rkt 是一个应用程序 {{< glossary_tooltip text="容器" term_id="container" >}} 引擎，它具有原生的 {< glossary_tooltip text="Pod" term_id="pod" >}} 方法、可插拔的执行环境和定义良好的接口。rkt 允许用户在 Pod 和应用程序级别应用不同的配置。每个 Pod 在一个自包含的、独立的经典 Unix 进程模型中直接执行。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/secret.md b/content/zh/docs/reference/glossary/secret.md index 8bbb57df6b..ef1c8e9516 100644 --- a/content/zh/docs/reference/glossary/secret.md +++ b/content/zh/docs/reference/glossary/secret.md @@ -4,7 +4,7 @@ id: secret date: 2018-04-12 full_link: /zh/docs/concepts/configuration/secret/ short_description: > - Secret 用于存储敏感信息，如密码、OAuth 令牌和 SSH 密钥。 + Secret 用于存储敏感信息，如密码、 OAuth 令牌和 SSH 密钥。 aka: tags: @@ -17,7 +17,7 @@ tags: title: Secret id: secret date: 2018-04-12 -full_link: /zh/docs/concepts/configuration/secret/ +full_link: /docs/concepts/configuration/secret/ short_description: > Stores sensitive information, such as passwords, OAuth tokens, and ssh keys. @@ -32,7 +32,7 @@ tags: Stores sensitive information, such as passwords, OAuth tokens, and ssh keys. --> - Secret 用于存储敏感信息，如密码、OAuth 令牌和 SSH 密钥。 + Secret 用于存储敏感信息，如密码、 OAuth 令牌和 SSH 密钥。 @@ -40,6 +40,6 @@ tags: Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) at rest. A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data. --> -Secret 允许用户对如何使用敏感信息进行更多的控制，并减少信息意外暴露的风险，包括静态[加密](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)。 +Secret 允许用户对如何使用敏感信息进行更多的控制，并减少信息意外暴露的风险，包括静态[encryption（加密）](/zh/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)。 {{< glossary_tooltip text="Pod" term_id="pod" >}} 通过挂载卷中的文件的方式引用 Secret，或者通过 kubelet 为 pod 拉取镜像时引用。 -Secret 非常适合机密数据使用，而 [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) 适用于非机密数据。 +Secret 非常适合机密数据使用，而 [ConfigMaps](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 适用于非机密数据。 diff --git a/content/zh/docs/reference/glossary/security-context.md b/content/zh/docs/reference/glossary/security-context.md index 31b99c635c..864e693735 100644 --- a/content/zh/docs/reference/glossary/security-context.md +++ b/content/zh/docs/reference/glossary/security-context.md @@ -2,7 +2,7 @@ title: 安全上下文（Security Context） id: security-context date: 2018-04-12 -full_link: /docs/tasks/configure-pod-container/security-context/ +full_link: /zh/docs/tasks/configure-pod-container/security-context/ short_description: > securityContext 字段定义 Pod 或容器的特权和访问控制设置，包括运行时 UID 和 GID。 @@ -18,7 +18,7 @@ id: security-context date: 2018-04-12 full_link: /docs/tasks/configure-pod-container/security-context/ short_description: > - The securityContext field defines privilege and access control settings for a Pod or Container, including the runtime UID and GID. + The securityContext field defines privilege and access control settings for a Pod or container. aka: tags: @@ -27,17 +27,26 @@ tags: --> -securityContext 字段定义 Pod 或容器的特权和访问控制设置，包括运行时 UID 和 GID。 - +securityContext 字段定义 {{< glossary_tooltip text="Pod" term_id="pod" >}} 或 +{{< glossary_tooltip text="容器" term_id="container" >}}的特权和访问控制设置。 + + -{{< glossary_tooltip term_id="pod" >}} 或者容器中的 securityContext 字段（应用于所有容器）用于设置容器进程使用的用户（runAsUser）和组 （fsGroup）、权能字、特权设置和安全策略（SELinux/AppArmor/Seccomp）。 - +在一个 `securityContext` 字段中，你可以设置进程所属用户和用户组、权限相关设置。你也可以设置安全策略（例如：SELinux、AppArmor、seccomp）。 + +`PodSpec.securityContext` 字段配置会应用到一个 Pod 中的所有的 container 。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/selector.md b/content/zh/docs/reference/glossary/selector.md index a3dcd0b71b..7a1343090f 100644 --- a/content/zh/docs/reference/glossary/selector.md +++ b/content/zh/docs/reference/glossary/selector.md @@ -1,5 +1,5 @@ --- -title: 选择算符 +title: 选择算符（Selector） id: selector date: 2018-04-12 full_link: /zh/docs/concepts/overview/working-with-objects/labels/ @@ -12,11 +12,12 @@ tags: --- + -选择算符允许用户通过标签对一组资源对象进行筛选过滤。 +选择算符允许用户通过{{< glossary_tooltip text="标签（labels）" term_id="label" >}}对一组资源对象进行筛选过滤。 -在查询资源列表时，选择算符可以通过 {{< glossary_tooltip text="标签" term_id="label" >}} 对资源进行过滤筛选。 +在查询资源列表时，选择算符可以通过标签对资源进行过滤筛选。 diff --git a/content/zh/docs/reference/glossary/service-account.md b/content/zh/docs/reference/glossary/service-account.md index 28c7ffd9b6..e54a4ef98b 100644 --- a/content/zh/docs/reference/glossary/service-account.md +++ b/content/zh/docs/reference/glossary/service-account.md @@ -1,5 +1,5 @@ --- -title: 服务账户 +title: ServiceAccount id: service-account date: 2018-04-12 full_link: /zh/docs/tasks/configure-pod-container/configure-service-account/ @@ -14,10 +14,10 @@ tags: + 为在 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中运行的进程提供标识。 - - -当 Pod 中的进程访问集群时，API 服务器将它们作为特定的服务帐户进行身份验证，例如 `default`。当您创建 Pod 时，如果您没有指定服务帐户，它将在相同的命名空间 {{< glossary_tooltip text="命名空间" term_id="namespace" >}} 中自动分配 default 服务账户。 - +当 Pod 中的进程访问集群时，API 服务器将它们作为特定的服务帐户进行身份验证， +例如 `default` ，创建 Pod 时，如果你没有指定服务帐户，它将自动被赋予同一个 +{{< glossary_tooltip text="名字空间" term_id="namespace" >}}中的 default 服务账户。 diff --git a/content/zh/docs/reference/glossary/service-broker.md b/content/zh/docs/reference/glossary/service-broker.md index 8a017d127b..b8afe97d70 100644 --- a/content/zh/docs/reference/glossary/service-broker.md +++ b/content/zh/docs/reference/glossary/service-broker.md @@ -12,6 +12,7 @@ tags: --- - -由第三方提供并维护的一组{{< glossary_tooltip text="托管服务" term_id="managed-service">}} 的访问端点。 +由第三方提供并维护的一组{{< glossary_tooltip text="托管服务" term_id="managed-service">}}的访问端点。 -{{< glossary_tooltip text="服务代理" term_id="service-broker">}}会实现 +{{< glossary_tooltip text="服务代理（Service Brokers）" term_id="service-broker">}}会实现 [开放服务代理 API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) 并为应用提供使用其托管服务的标准接口。 -[服务目录（Service Catalog）](/docs/concepts/service-catalog/)则提供一种方法，用来列举、供应和绑定服务代理商所提供的托管服务。 +[服务目录（Service Catalog）](/zh/docs/concepts/extend-kubernetes/service-catalog/)则提供一种方法，用来列举、供应和绑定服务代理商所提供的托管服务。 diff --git a/content/zh/docs/reference/glossary/service-catalog.md b/content/zh/docs/reference/glossary/service-catalog.md index 726aff57c2..134085e034 100644 --- a/content/zh/docs/reference/glossary/service-catalog.md +++ b/content/zh/docs/reference/glossary/service-catalog.md @@ -1,12 +1,11 @@ --- -title: 服务目录 +title: 服务目录（Service Catalog） id: service-catalog date: 2018-04-12 full_link: short_description: > 服务目录是一种扩展 API，它能让 Kubernetes 集群中运行的应用易于使用外部托管的软件服务，例如云供应商提供的数据仓库服务。 - An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider. aka: tags: - extension @@ -27,11 +26,12 @@ tags: --- --> + -服务目录（Service Catalog）是一种扩展 API，它能让 Kubernetes 集群中运行的应用易于使用外部托管的的软件服务，例如云供应商提供的数据仓库服务。 +服务目录是一种扩展 API，它能让 Kubernetes 集群中运行的应用易于使用外部托管的的软件服务，例如云供应商提供的数据仓库服务。 @@ -39,5 +39,7 @@ tags: It provides a way to list, provision, and bind with external {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} from {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} without needing detailed knowledge about how those services are created or managed. --> -服务目录可以检索、供应、和绑定由 {{< glossary_tooltip text="服务代理人（Service Brokers）" term_id="service-broker" >}} 提供的外部 {{< glossary_tooltip text="托管服务" term_id="managed-service" >}}，而无需知道那些服务具体是怎样创建和托管的。 +服务目录可以检索、供应、和绑定由 {{< glossary_tooltip text="服务代理人（Service Brokers）" term_id="service-broker" >}} +提供的外部{{< glossary_tooltip text="托管服务（Managed Services）" term_id="managed-service" >}}， +而无需知道那些服务具体是怎样创建和托管的。 diff --git a/content/zh/docs/reference/glossary/service.md b/content/zh/docs/reference/glossary/service.md index 95e3b9e007..b6a0fab287 100644 --- a/content/zh/docs/reference/glossary/service.md +++ b/content/zh/docs/reference/glossary/service.md @@ -1,5 +1,5 @@ --- -title: Service +title: 服务（Service） id: service date: 2018-04-12 full_link: /zh/docs/concepts/services-networking/service/ @@ -11,6 +11,24 @@ tags: - fundamental - core-object --- + + + + @@ -22,4 +40,6 @@ An abstract way to expose an application running on a set of {{< glossary_toolti -服务所针对的Pod集（通常）由 {{< glossary_tooltip text="selector" term_id="selector" >}} 确定。 如果添加或删除了更多Pod，则与选择器匹配的Pod集将发生变化。 该服务确保可以将网络流量定向到该工作负载的当前Pod集。 +服务所针对的 Pod 集（通常）由{{< glossary_tooltip text="选择算符" term_id="selector" >}}确定。 +如果有 Pod 被添加或被删除，则与选择算符匹配的 Pod 集合将发生变化。 +服务确保可以将网络流量定向到该工作负载的当前 Pod 集合。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/shuffle-sharding.md b/content/zh/docs/reference/glossary/shuffle-sharding.md index 1f8d8a0990..4bc7f91189 100644 --- a/content/zh/docs/reference/glossary/shuffle-sharding.md +++ b/content/zh/docs/reference/glossary/shuffle-sharding.md @@ -10,9 +10,9 @@ aka: tags: - fundamental --- -一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。 + + + +混排切片（Shuffle Sharding）是指一种将请求指派给队列的技术，其隔离性好过对队列个数哈希取模的方式。 + diff --git a/content/zh/docs/reference/glossary/sig.md b/content/zh/docs/reference/glossary/sig.md index a42a15b0b1..3c2ff7b191 100644 --- a/content/zh/docs/reference/glossary/sig.md +++ b/content/zh/docs/reference/glossary/sig.md @@ -1,5 +1,5 @@ --- -title: SIG （特别兴趣小组） +title: 特别兴趣小组（SIG） id: sig date: 2018-04-12 full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list @@ -12,6 +12,7 @@ tags: --- + @@ -34,13 +37,13 @@ tags: SIG 中的成员对推进某个领域（如体系结构、API 机制构件或者文档）具有相同的兴趣。 -SIGs 必须遵从 [SIG Governance](https://github.com/kubernetes/community/blob/master/sig-governance.md) 的规定， +SIGs 必须遵从 [governance guidelines](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md) 的规定， 不过可以有自己的贡献策略以及通信渠道（方式）。 更多的详细信息可参阅 [kubernetes/community](https://github.com/kubernetes/community) 仓库以及 diff --git a/content/zh/docs/reference/glossary/statefulset.md b/content/zh/docs/reference/glossary/statefulset.md index 8003a09893..6e796d9419 100644 --- a/content/zh/docs/reference/glossary/statefulset.md +++ b/content/zh/docs/reference/glossary/statefulset.md @@ -4,7 +4,7 @@ id: statefulset date: 2018-04-12 full_link: /zh/docs/concepts/workloads/controllers/statefulset/ short_description: > - StatefulSet 用来管理 Deployment 和伸缩一组 Pod，并且能为这些 Pod 提供*序号和唯一性保证*。 + StatefulSet 用来管理某 Pod 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符。 aka: tags: - fundamental @@ -18,9 +18,9 @@ tags: title: StatefulSet id: statefulset date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/statefulset/ +full_link: /docs/concepts/workloads/controllers/statefulset/ short_description: > - Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods. + Manages deployment and scaling of a set of Pods, with durable storage and persistent identifiers for each Pod. aka: tags: @@ -31,19 +31,25 @@ tags: --- --> - StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供*序号和唯一性保证*。 - + +StatefulSet 用来管理某 {{< glossary_tooltip text="Pod" term_id="pod" >}} 集合的部署和扩缩， +并为这些 Pod 提供持久存储和持久标识符。 -和 {{< glossary_tooltip term_id="Deployment" >}} 相同的是，StatefulSet 管理了基于相同容器定义的一组 Pod。但和 Deployment 不同的是，StatefulSet 为它们的每个 Pod 维护了一个固定的 ID。这些 Pod 是基于相同的声明来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。 - +和 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 类似， +StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， +StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， +但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。 -StatefulSet 和其他控制器使用相同的工作模式。你在 StatefulSet *对象* 中定义你期望的状态，然后 StatefulSet 的 *控制器* 就会通过各种更新来达到那种你想要的状态。 - +如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 +尽管 StatefulSet 中的单个 Pod 仍可能出现故障， +但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/static-pod.md b/content/zh/docs/reference/glossary/static-pod.md index 44e2a72bed..e785a96a85 100644 --- a/content/zh/docs/reference/glossary/static-pod.md +++ b/content/zh/docs/reference/glossary/static-pod.md @@ -1,10 +1,10 @@ --- -title: 静态 Pod +title: 静态 Pod（Static Pod） id: static-pod date: 2019-02-12 full_link: /zh/docs/tasks/configure-pod-container/static-pod/ short_description: > - 由特定节点上的 kubelet 守护进程直接管理的 pod。 + 静态Pod（Static Pod）是指由特定节点上的 kubelet 守护进程直接管理的 Pod。 aka: tags: @@ -16,7 +16,7 @@ tags: title: Static Pod id: static-pod date: 2019-02-12 -full_link: /zh/docs/tasks/configure-pod-container/static-pod/ +full_link: /docs/tasks/configure-pod-container/static-pod/ short_description: > A pod managed directly by the kubelet daemon on a specific node. diff --git a/content/zh/docs/reference/glossary/storage-class.md b/content/zh/docs/reference/glossary/storage-class.md index ad102de155..1ad1834b15 100644 --- a/content/zh/docs/reference/glossary/storage-class.md +++ b/content/zh/docs/reference/glossary/storage-class.md @@ -1,10 +1,10 @@ --- -title: 存储类别 +title: StorageClass id: storageclass date: 2018-04-12 full_link: /zh/docs/concepts/storage/storage-classes/ short_description: > - StorageClass 是管理员用来描述不同的可用存储类型的一种方法。 + StorageClass 是管理员用来描述可用的不同存储类型的一种方法。 aka: tags: @@ -12,12 +12,13 @@ tags: - storage --- + - StorageClass 是管理员用来描述不同的可用存储类型的一种方法。 @@ -40,5 +40,7 @@ tags: StorageClasses can map to quality-of-service levels, backup policies, or to arbitrary policies determined by cluster administrators. Each StorageClass contains the fields `provisioner`, `parameters`, and `reclaimPolicy`, which are used when a {{< glossary_tooltip text="Persistent Volume" term_id="persistent-volume" >}} belonging to the class needs to be dynamically provisioned. Users can request a particular class using the name of a StorageClass object. --> -StorageClass 可以映射到服务质量等级（QoS）、备份策略、或者管理员随机定义的策略。每个 StorageClass 对象包含的域有 `provisioner`、 `parameters` 和 `reclaimPolicy`，属于该存储类别的 {{< glossary_tooltip text="永久卷" term_id="persistent-volume" >}} 需要动态分配时就要用到这些域参数。通过 StorageClass 对象的名称，用户可以请求他们需要的特定存储类别。 - +StorageClass 可以映射到服务质量等级（QoS）、备份策略、或者管理员任意定义的策略。 +每个 StorageClass 对象包含的字段有 `provisioner`、`parameters` 和 `reclaimPolicy`。 +动态制备该存储类别的{{< glossary_tooltip text="持久卷" term_id="persistent-volume" >}}时需要用到这些字段值。 +通过设置 StorageClass 对象的名称，用户可以请求特定存储类别。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/sysctl.md b/content/zh/docs/reference/glossary/sysctl.md index 42ed215d6d..b987583df7 100644 --- a/content/zh/docs/reference/glossary/sysctl.md +++ b/content/zh/docs/reference/glossary/sysctl.md @@ -16,7 +16,7 @@ tags: title: sysctl id: sysctl date: 2019-02-12 -full_link: /zh/docs/tasks/administer-cluster/sysctl-cluster/ +full_link: /docs/tasks/administer-cluster/sysctl-cluster/ short_description: > An interface for getting and setting Unix kernel parameters @@ -48,4 +48,4 @@ uses. network plugins may rely on `sysctl` values being set a certain way. --> -{{< glossary_tooltip text="容器" term_id="container" >}} 运行时和网络插件可能对 `sysctl` 的取值有一定的要求。 +{{< glossary_tooltip text="容器" term_id="container" >}}运行时和网络插件可能对 `sysctl` 的取值有一定的要求。 diff --git a/content/zh/docs/reference/glossary/taint.md b/content/zh/docs/reference/glossary/taint.md index 24b54fc16e..8961ce205d 100644 --- a/content/zh/docs/reference/glossary/taint.md +++ b/content/zh/docs/reference/glossary/taint.md @@ -1,20 +1,19 @@ --- -title: 污点 +title: 污点（Taint） id: taint date: 2019-01-11 -full_link: /docs/concepts/configuration/taint-and-toleration/ +full_link: /zh/docs/concepts/scheduling-eviction/taint-and-toleration/ short_description: > - 一个核心对象，由三个必需的属性组成：键，值和效果。污点会阻止在节点或节点组上调度 Pod。 + 污点是一种一个核心对象，包含三个必需的属性：key、value 和 effect。 + 污点会阻止在节点或节点组上调度 Pod。 aka: tags: - core-object - fundamental --- - 一个核心对象，由三个必需的属性组成：键，值和效果。污点会阻止在节点或节点组上调度 Pod。 - + + + +污点是一种一个核心对象，包含三个必需的属性：key、value 和 effect。 +污点会阻止在{{< glossary_tooltip text="节点" term_id="node" >}} +或节点组上调度 {{< glossary_tooltip text="Pods" term_id="pod" >}}。 - -污点和 {{< glossary_tooltip text="容忍度" term_id="toleration" >}} 一起工作，以确保不会将 Pod 调度到不适合的节点上。一个或多个污点应用于 {{< glossary_tooltip text="节点" term_id="node" >}}。节点应该仅能调度那些带着能与污点相匹配容忍度的 pod。 \ No newline at end of file +污点和{{< glossary_tooltip text="容忍度" term_id="toleration" >}}一起工作， +以确保不会将 Pod 调度到不适合的节点上。 +同一{{< glossary_tooltip text="节点" term_id="node" >}}上可标记一个或多个污点。 +节点应该仅调度那些带着能与污点相匹配容忍度的 Pod。 diff --git a/content/zh/docs/reference/glossary/toleration.md b/content/zh/docs/reference/glossary/toleration.md index ba59aed099..963d75b94c 100644 --- a/content/zh/docs/reference/glossary/toleration.md +++ b/content/zh/docs/reference/glossary/toleration.md @@ -1,24 +1,23 @@ --- -title: 容忍度 +title: 容忍度（Toleration） id: toleration date: 2019-01-11 -full_link: /docs/concepts/configuration/taint-and-toleration/ +full_link: /zh/docs/concepts/scheduling-eviction/taint-and-toleration/ short_description: > - 一个核心对象，由三个必需的属性组成：key、value 和 effect。容忍度允许将 Pod 调度到具有对应污点的节点或节点组上。 + 一个核心对象，由三个必需的属性组成：key、value 和 effect。 + 容忍度允许将 Pod 调度到具有对应污点的节点或节点组上。 + aka: tags: - core-object - fundamental --- - 一个核心对象，由三个必需的属性组成：key、value 和 effect。 - 容忍度允许将 Pod 调度到具有匹配 {{< glossary_tooltip text="污点" term_id="taint" >}} 的节点或节点组上。 - + + +一个核心对象，由三个必需的属性组成：key、value 和 effect。 +容忍度允许将 Pod 调度到具有对应{{< glossary_tooltip text="污点" term_id="taint" >}} +的节点或节点组上。 + - 容忍度 和 {{< glossary_tooltip text="污点" term_id="taint" >}} 共同作用以确保不会将 Pod 调度在不适合的节点上。在同一 {{< glossary_tooltip text="pod" term_id="pod" >}} 上可以设置一个或者多个容忍度。容忍度表示在匹配节点或节点组上的 {{< glossary_tooltip text="污点" term_id="taint" >}} 调度 {{< glossary_tooltip text="pod" term_id="pod" >}} 是允许的（但不必要）。 +容忍度和{{< glossary_tooltip text="污点" term_id="taint" >}}共同作用可以 +确保不会将 Pod 调度在不适合的节点上。 +在同一 {{< glossary_tooltip text="Pod" term_id="pod" >}} 上可以设置一个 +或者多个容忍度。 +容忍度表示在包含对应{{< glossary_tooltip text="污点" term_id="taint" >}} +的节点或节点组上调度 {{< glossary_tooltip text="Pod" term_id="pod" >}} +是允许的（但不必要）。 + diff --git a/content/zh/docs/reference/glossary/uid.md b/content/zh/docs/reference/glossary/uid.md index 01805ee534..74faf6d1e7 100644 --- a/content/zh/docs/reference/glossary/uid.md +++ b/content/zh/docs/reference/glossary/uid.md @@ -16,7 +16,7 @@ tags: title: UID id: uid date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/names/ +full_link: /docs/concepts/overview/working-with-objects/names short_description: > A Kubernetes systems-generated string to uniquely identify objects. diff --git a/content/zh/docs/reference/glossary/upstream.md b/content/zh/docs/reference/glossary/upstream.md index 118b3838f7..39d7207da8 100644 --- a/content/zh/docs/reference/glossary/upstream.md +++ b/content/zh/docs/reference/glossary/upstream.md @@ -1,5 +1,5 @@ --- -title: Upstream (disambiguation) +title: 上游（Uptream） id: upstream date: 2018-04-12 full_link: @@ -10,18 +10,33 @@ aka: tags: - community --- + + + +可能指的是：核心 Kubernetes 仓库或作为当前仓库派生来源的仓库。 + + -可以参考：核心 Kubernetes 仓库或作为当前仓库派生来源的来源仓库。 - - - * 在 **Kubernetes社区**：对话中通常使用 *upstream* 来表示核心 Kubernetes 代码库，也就是更广泛的 kubernetes 生态系统、其他代码或第三方工具所依赖的仓库。 例如，[社区成员](#term-member)可能会建议将某个功能特性贡献到 upstream，使其位于核心代码库中，而不是维护于插件或第三方工具中。 * 在 **GitHub** 或 **git** 中：约定是将源仓库称为 *upstream*，而派生的仓库则被视为 *downstream*。 diff --git a/content/zh/docs/reference/glossary/volume-plugin.md b/content/zh/docs/reference/glossary/volume-plugin.md index ca4318d4ad..b04b8d8fbc 100644 --- a/content/zh/docs/reference/glossary/volume-plugin.md +++ b/content/zh/docs/reference/glossary/volume-plugin.md @@ -1,10 +1,10 @@ --- -title: 卷（Volume）插件 +title: 卷插件（Volume Plugin） id: volumeplugin date: 2018-04-12 full_link: short_description: > - 卷（Volume）插件可以让 Pod 集成存储。 + 卷插件可以让 Pod 集成存储。 aka: tags: @@ -40,5 +40,7 @@ tags: A Volume Plugin lets you attach and mount storage volumes for use by a {{< glossary_tooltip text="Pod" term_id="pod" >}}. Volume plugins can be _in tree_ or _out of tree_. _In tree_ plugins are part of the Kubernetes code repository and follow its release cycle. _Out of tree_ plugins are developed independently. --> -卷插件让您能给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 附加和挂载存储卷。卷插件既可以是 _in tree_ 也可以是 _out of tree_ 。_in tree_ 插件是 Kubernetes 代码库的一部分，并遵循其发布周期。而 _Out of tree_ 插件则是独立开发的。 +卷插件让您能给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 附加和挂载存储卷。 +卷插件既可以是 _in tree_ 也可以是 _out of tree_ 。_in tree_ 插件是 Kubernetes 代码库的一部分， +并遵循其发布周期。而 _Out of tree_ 插件则是独立开发的。 diff --git a/content/zh/docs/reference/glossary/volume.md b/content/zh/docs/reference/glossary/volume.md index a170f0f3b8..7ef39eee2f 100644 --- a/content/zh/docs/reference/glossary/volume.md +++ b/content/zh/docs/reference/glossary/volume.md @@ -1,5 +1,5 @@ --- -title: 卷 +title: 卷（Volume） id: volume date: 2018-04-12 full_link: /zh/docs/concepts/storage/volumes/ @@ -13,31 +13,38 @@ tags: --- + +包含可被 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中{{< glossary_tooltip text="容器" term_id="container" >}}访问的数据的目录。 -包含可被 {{< glossary_tooltip text="pod" term_id="pod" >}} 中容器访问的数据的目录。 + - -每个 Kubernetes 卷在所处的{{< glossary_tooltip text="pod" term_id="pod" >}} 存在期间保持存在状态。 -因此，卷的生命期会超出 {{< glossary_tooltip text="pod" term_id="pod" >}} 中运行的{{< glossary_tooltip text="容器" term_id="container" >}}， +每个 Kubernetes 卷在所处的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 存在期间保持存在状态。 +因此，卷的生命期会超出 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中运行的{{< glossary_tooltip text="容器" term_id="container" >}}， 并且保证{{< glossary_tooltip text="容器" term_id="container" >}}重启之后仍保留数据。 + +更多信息可参考[storage](/zh/docs/concepts/storage/) \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/wg.md b/content/zh/docs/reference/glossary/wg.md index 9a42e77ab0..563ebacd69 100644 --- a/content/zh/docs/reference/glossary/wg.md +++ b/content/zh/docs/reference/glossary/wg.md @@ -1,5 +1,5 @@ --- -title: WG (工作组) +title: 工作组（Working Group，WG） id: wg date: 2018-04-12 full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list @@ -26,6 +26,7 @@ tags: --- --> + diff --git a/content/zh/docs/reference/glossary/workload.md b/content/zh/docs/reference/glossary/workload.md index d21e50e3b0..394b42bd1c 100644 --- a/content/zh/docs/reference/glossary/workload.md +++ b/content/zh/docs/reference/glossary/workload.md @@ -1,5 +1,5 @@ --- -title: 工作负载 +title: 工作负载（Workload） id: workloads date: 2019-02-13 full_link: /zh/docs/concepts/workloads/ @@ -11,29 +11,38 @@ tags: - fundamental --- - - +--- +--> + + 工作负载是在 Kubernetes 上运行的应用程序。 - -代表不同类型或部分工作负载的各种核心对象包括 DaemonSet, Deployment, Job, ReplicaSet, and StatefulSet。 +in a {{< glossary_tooltip term_id="Deployment" >}}. +--> +代表不同类型或部分工作负载的各种核心对象包括 DaemonSet， Deployment， Job， ReplicaSet， and StatefulSet。 -例如，具有 Web 服务器和数据库的工作负载可能在一个 {{< glossary_tooltip term_id="StatefulSet" >}} 中运行数据库，而 Web 服务器运行在 {{< glossary_tooltip term_id="Deployment" >}}。 \ No newline at end of file +例如，具有 Web 服务器和数据库的工作负载可能在一个 {{< glossary_tooltip term_id="StatefulSet" >}} 中运行数据库， +而 Web 服务器运行在 {{< glossary_tooltip term_id="Deployment" >}}。 \ No newline at end of file diff --git a/content/zh/docs/reference/issues-security/security.md b/content/zh/docs/reference/issues-security/security.md index e188a53abc..f77b17cb26 100644 --- a/content/zh/docs/reference/issues-security/security.md +++ b/content/zh/docs/reference/issues-security/security.md @@ -31,14 +31,14 @@ This page describes Kubernetes security and disclosure information. ## 安全公告 -加入 [kubernets-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) 组，以获取关于安全性和主要 API 公告的电子邮件。 +加入 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 组，以获取关于安全性和主要 API 公告的电子邮件。 -您也可以使用[此链接](https://groups.google.com/forum/feed/kubernetes-announce/msgs/rss_v2_0.xml?num=50)订阅上述的 RSS 反馈。 +你也可以使用[此链接](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50) 订阅上述的 RSS 反馈。 -如需报告，请连同安全细节以及预期的[所有 Kubernetes bug 报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)详细信息电邮到[security@kubernetes.io](mailto:security@kubernetes.io) 列表。 +如需报告，请连同安全细节以及预期的[所有 Kubernetes bug 报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md) +详细信息电子邮件到[security@kubernetes.io](mailto:security@kubernetes.io)列表。 -您还可以通过电子邮件向私有 [security@kubernetes.io](mailto:security@kubernetes.io) 列表发送电子邮件，邮件中应该包含[所有 Kubernetes 错误报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)所需的详细信息。 +你还可以通过电子邮件向私有 [security@kubernetes.io](mailto:security@kubernetes.io) 列表发送电子邮件，邮件中应该包含[所有 Kubernetes 错误报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)所需的详细信息。 -您可以使用[产品安全团队成员](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#product-security-team-pst)的 GPG 密钥加密您的电子邮件到此列表。 -使用 GPG 加密不需要公开。 +你可以使用[产品安全团队成员](https://git.k8s.io/security/README.md#product-security-committee-psc) +的 GPG 密钥加密你的电子邮件到此列表。使用 GPG 加密不需要公开。 -- 您认为在 Kubernetes 中发现了一个潜在的安全漏洞 -- 您不确定漏洞如何影响 Kubernetes -- 您认为您在 Kubernetes 依赖的另一个项目中发现了一个漏洞 - - 对于具有漏洞报告和披露流程的项目，请直接在该项目处报告 +- 你认为在 Kubernetes 中发现了一个潜在的安全漏洞 +- 你不确定漏洞如何影响 Kubernetes +- 你认为你在 Kubernetes 依赖的另一个项目中发现了一个漏洞 +- 对于具有漏洞报告和披露流程的项目，请直接在该项目处报告 -- 您需要帮助调整 Kubernetes 组件的安全性 -- 您需要帮助应用与安全相关的更新 -- 您的问题与安全无关 +- 你需要帮助调整 Kubernetes 组件的安全性 +- 你需要帮助应用与安全相关的更新 +- 你的问题与安全无关 -另见: [Kubectl 概述](/zh/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/zh/docs/reference/kubectl/jsonpath)。 - -本页面是 `kubectl` 命令的概述。 +本页列举了常用的 “kubectl” 命令和标志 -# kubectl - 备忘单 ## Kubectl 自动补全 @@ -67,12 +62,12 @@ complete -F __start_kubectl k ```bash source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全 -echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全 +echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全 ``` ## Kubectl 上下文和配置 -设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 -[使用 kubeconfig 跨集群授权访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。 +查看[使用 kubeconfig 跨集群授权访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取配置文件详细信息。 -## Apply -`apply` 通过定义 Kubernetes 资源的文件来管理应用。它通过运行 -`kubectl apply` 在集群中创建和更新资源。 +## Kubectl apply +`apply` 通过定义 Kubernetes 资源的文件来管理应用。 +它通过运行 `kubectl apply` 在集群中创建和更新资源。 这是在生产中管理 Kubernetes 应用的推荐方法。 参见 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。 @@ -170,12 +165,19 @@ Kubernetes 配置可以用 YAML 或 JSON 定义。可以使用的文件扩展名 ## 查看和查找资源 @@ -275,7 +284,7 @@ EOF # Get commands with basic output kubectl get services # List all services in the namespace kubectl get pods --all-namespaces # List all pods in all namespaces -kubectl get pods -o wide # List all pods in the namespace, with more details +kubectl get pods -o wide # List all pods in the current namespace, with more details kubectl get deployment my-dep # List a particular deployment kubectl get pods # List all pods in the namespace kubectl get pod my-pod -o yaml # Get a pod's YAML @@ -297,6 +306,10 @@ kubectl get pv --sort-by=.spec.capacity.storage kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' +# Retrieve the value of a key with dots, e.g. 'ca.crt' +kubectl get configmap myconfig \ + -o jsonpath='{.data.ca\.crt}' + # Get all worker nodes (use a selector to exclude results that have a label # named 'node-role.kubernetes.io/master') kubectl get node --selector='!node-role.kubernetes.io/master' @@ -331,6 +344,14 @@ kubectl get events --sort-by=.metadata.creationTimestamp # Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied. kubectl diff -f ./my-manifest.yaml + +# Produce a period-delimited tree of all keys returned for nodes +# Helpful when locating a key within a complex nested JSON structure +kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# Produce a period-delimited tree of all keys returned for pods, etc +kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + ``` --> ```bash @@ -359,6 +380,10 @@ kubectl get pv --sort-by=.spec.capacity.storage kubectl get pods --selector=app=cassandra -o \ jsonpath='{.items[*].metadata.labels.version}' +# 检索带有 “.” 键值，例： 'ca.crt' +kubectl get configmap myconfig \ + -o jsonpath='{.data.ca\.crt}' + # 获取所有工作节点（使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果） kubectl get node --selector='!node-role.kubernetes.io/master' @@ -392,10 +417,18 @@ kubectl get events --sort-by=.metadata.creationTimestamp # 比较当前的集群状态和假定某清单被应用之后的集群状态 kubectl diff -f ./my-manifest.yaml + +# 生成一个句点分隔的树，其中包含为节点返回的所有键 +# 在复杂的嵌套JSON结构中定位键时非常有用 +kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# 生成一个句点分隔的树，其中包含为pod等返回的所有键 +kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + ``` ## 更新资源 @@ -448,7 +481,7 @@ kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解 kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容 ``` - + ## 部分更新资源 ## 编辑资源 @@ -507,7 +540,7 @@ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器 ``` ## 对资源进行伸缩 @@ -526,7 +559,7 @@ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个 ``` ## 删除资源 @@ -535,7 +568,7 @@ kubectl delete -f ./pod.json # Dele kubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo" kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel -kubectl -n my-ns delete po,svc --all # Delete all pods and services in namespace my-ns, +kubectl -n my-ns delete pod,svc --all # Delete all pods and services in namespace my-ns, # Delete all pods matching the awk pattern1 or pattern2 kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` @@ -544,8 +577,7 @@ kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{pr kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务 kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和服务 -kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 Pods 和服务 -kubectl -n my-ns delete po,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务 +kubectl -n my-ns delete pod,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务 # 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` @@ -674,14 +706,14 @@ kubectl api-resources --api-group=extensions # "extensions" API 组中的所有 ### 格式化输出 -要以特定格式将详细信息输出到终端窗口，可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令。 +要以特定格式将详细信息输出到终端窗口，将 `-o`（或者 `--output`）参数添加到支持的 `kubectl` 命令中。 -* 进一步了解 [kubectl 概述](/zh/docs/reference/kubectl/overview/)。 -* 参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 选项. +* 参阅 [kubectl 概述](/zh/docs/reference/kubectl/overview/)，进一步了解[JsonPath](/zh/docs/reference/kubectl/jsonpath)。 +* 参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 选项。 * 参阅 [kubectl 使用约定](/zh/docs/reference/kubectl/conventions/)来理解如何在可复用的脚本中使用它。 * 查看社区中其他的 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。 diff --git a/content/zh/docs/reference/kubectl/jsonpath.md b/content/zh/docs/reference/kubectl/jsonpath.md index 900251c09d..c1302ec3d6 100644 --- a/content/zh/docs/reference/kubectl/jsonpath.md +++ b/content/zh/docs/reference/kubectl/jsonpath.md @@ -34,7 +34,7 @@ JSONPath 模板由 {} 包起来的 JSONPath 表达式组成。Kubectl 使用 JSO --> 1. 使用双引号将 JSONPath 表达式内的文本引起来。 2. 使用 `range`，`end` 运算符来迭代列表。 -3. 使用负片索引后退列表。负索引不会"环绕"列表，并且只要 `-index + listLength> = 0` 就有效。 +3. 使用负片索引后退列表。负索引不会“环绕”列表，并且只要 `-index + listLength> = 0` 就有效。 {{< note >}} -在 Windows 上，您必须 _double_ 引用任何包含空格的 JSONPath 模板(不是上面 bash 所示的单引号)。反过来，这意味着您必须在模板中的所有文字周围使用单引号或转义的双引号。例如: +{{< note >}} +在 Windows 上，您必须用双引号把任何包含空格的 JSONPath 模板（不是上面 bash 所示的单引号）。 +反过来，这意味着您必须在模板中的所有文字周围使用单引号或转义的双引号。 +例如: ```cmd C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}" C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}" ``` +{{< /note >}} + +{{< note >}} +不支持 JSONPath 正则表达式。如需使用正则表达式进行匹配操作，您可以使用如 `jq` 之类的工具。 + +```shell +# kubectl 的 JSONpath 输出不支持正则表达式 +# 下面的命令不会生效 +kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}' + +# 下面的命令可以获得所需的结果 +kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image' +``` +{{< /note >}} diff --git a/content/zh/docs/reference/kubectl/overview.md b/content/zh/docs/reference/kubectl/overview.md index 834175c5d8..4f4125e26a 100644 --- a/content/zh/docs/reference/kubectl/overview.md +++ b/content/zh/docs/reference/kubectl/overview.md @@ -25,14 +25,27 @@ card: -Kubectl 是一个命令行接口，用于对 Kubernetes 集群运行命令。`kubectl` 在 $HOME/.kube 目录中寻找一个名为 config 的文件。您可以通过设置环境变量 KUBECONFIG 或设置 [`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 参数指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 +你可以使用 Kubectl 命令行工具管理 Kubernetes 集群。 +`kubectl` 在 `$HOME/.kube` 目录中查找一个名为 `config` 的配置文件。 +你可以通过设置 KUBECONFIG 环境变量或设置 [`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +参数来指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 -本文概述了 `kubectl` 语法和命令操作描述，并提供了常见的示例。有关每个命令的详细信息，包括所有受支持的参数和子命令，请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。有关安装说明，请参见 [安装 kubectl](/zh/docs/tasks/tools/install-kubectl/) 。 +本文概述了 `kubectl` 语法和命令操作描述，并提供了常见的示例。 +有关每个命令的详细信息，包括所有受支持的参数和子命令， +请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。 +有关安装说明，请参见[安装 kubectl](/zh/docs/tasks/tools/install-kubectl/) 。 @@ -82,7 +95,7 @@ where `command`, `TYPE`, `NAME`, and `flags` are: * `NAME`：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。 - 在对多个资源执行操作时，您可以按类型和名称指定每个资源，或指定一个或多个文件： + 在对多个资源执行操作时，你可以按类型和名称指定每个资源，或指定一个或多个文件： @@ -111,7 +124,7 @@ where `command`, `TYPE`, `NAME`, and `flags` are: * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>` - * [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-config-tips) 因为 YAML 更容易使用，特别是用于配置文件时。
+ * [使用 YAML 而不是 JSON](/docs/concepts/configuration/overview/#general-configuration-tips) 因为 YAML 更容易使用，特别是用于配置文件时。
例子：`kubectl get -f ./pod.yaml` * `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定 Kubernetes API 服务器的地址和端口。
@@ -127,7 +140,7 @@ Flags that you specify from the command line override default values and any cor -如果您需要帮助，只需从终端窗口运行 ` kubectl help ` 即可。 +如果你需要帮助，只需从终端窗口运行 ` kubectl help ` 即可。 操作 | 语法 | 描述 -------------------- | -------------------- | -------------------- +`alpha` | `kubectl alpha SUBCOMMAND [flags]` | 列出与 alpha 特性对应的可用命令，这些特性在 Kubernetes 集群中默认情况下是不启用的。 `annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的注解。 +`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]` | 附加到正在运行的容器，查看输出流或与容器（stdin）交互。 +`auth` | `kubectl auth [flags] [options]` | 检查授权。 `autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 自动伸缩由副本控制器管理的一组 pod。 +`certificate` | `kubectl certificate SUBCOMMAND [options]` | 修改证书资源。 `cluster-info` | `kubectl cluster-info [flags]` | 显示有关集群中主服务器和服务的端口信息。 +`completion` | `kubectl completion SHELL [options]` | 为指定的 shell （bash 或 zsh）输出 shell 补齐代码。 `config` | `kubectl config SUBCOMMAND [flags]` | 修改 kubeconfig 文件。有关详细信息，请参阅各个子命令。 +`convert` | `kubectl convert -f FILENAME [options]` | 在不同的 API 版本之间转换配置文件。配置文件可以是 YAML 或 JSON 格式。 +`cordon` | `kubectl cordon NODE [options]` | 将节点标记为不可调度。 +`cp` | `kubectl cp [options]` | 在容器之间复制文件和目录。 `create` | `kubectl create -f FILENAME [flags]` | 从文件或 stdin 创建一个或多个资源。 `delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | 从文件、标准输入或指定标签选择器、名称、资源选择器或资源中删除资源。 `describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 显示一个或多个资源的详细状态。 `diff` | `kubectl diff -f FILENAME [flags]`| 将 live 配置和文件或标准输入做对比 (**BETA**) +`drain` | `kubectl drain NODE [options]` | 腾空节点以准备维护。 `edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 使用默认编辑器编辑和更新服务器上一个或多个资源的定义。 `exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 对 pod 中的容器执行命令。 `explain` | `kubectl explain [--recursive=false] [flags]` | 获取多种资源的文档。例如 pod, node, service 等。 `expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 将副本控制器、服务或 pod 作为新的 Kubernetes 服务暴露。 `get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 列出一个或多个资源。 +`kustomize` | `kubectl kustomize [flags] [options]` | 列出从 kustomization.yaml 文件中的指令生成的一组 API 资源。参数必须是包含文件的目录的路径，或者是 git 存储库 URL，其路径后缀相对于存储库根目录指定了相同的路径。 `label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的标签。 `logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 在 pod 中打印容器的日志。 +`options` | `kubectl options` | 全局命令行选项列表，适用于所有命令。 `patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | 使用策略合并 patch 程序更新资源的一个或多个字段。 +`plugin` | `kubectl plugin [flags] [options]` | 提供用于与插件交互的实用程序。 `port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 将一个或多个本地端口转发到一个 pod。 `proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 运行 Kubernetes API 服务器的代理。 `replace` | `kubectl replace -f FILENAME` | 从文件或标准输入中替换资源。 -`rolling-update` | kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) [flags] | 通过逐步替换指定的副本控制器及其 pod 来执行滚动更新。 +`rollout` | `kubectl rollout SUBCOMMAND [options]` | 管理资源的部署。有效的资源类型包括：Deployments, DaemonSets 和 StatefulSets。 `run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server | client | none] [--overrides=inline-json] [flags] | 在集群上运行指定的镜像。 `scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 更新指定副本控制器的大小。 -`stop` | `kubectl stop` | 不推荐：相反，请参阅 kubectl delete。 +`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]` | 更新一个或多个节点上的污点。 +`top` | `kubectl top [flags] [options]` | 显示资源（CPU/内存/存储）的使用情况。 +`uncordon` | `kubectl uncordon NODE [options]` | 将节点标记为可调度。 `version` | `kubectl version [--client] [flags]` | 显示运行在客户端和服务器上的 Kubernetes 版本。 +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 实验性：等待一种或多种资源的特定条件。 -记住：有关命令操作的更多信息，请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 +了解更多有关命令操作的信息，请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 (以下输出可以通过 `kubectl api-resources` 获取，内容以 Kubernetes 1.19.1 版本为准。) @@ -351,7 +396,7 @@ The following table includes a list of all the supported resource types and thei ## 输出选项 有关如何格式化或排序某些命令的输出的信息，请使用以下部分。有关哪些命令支持各种输出选项的详细信息，请参阅[kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 @@ -419,7 +464,8 @@ kubectl get pod web-pod-13je7 -o yaml ``` 请记住：有关每个命令支持哪种输出格式的详细信息，请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 @@ -431,7 +477,7 @@ Remember: See the [kubectl](/docs/user-guide/kubectl/) reference documentation f -要定义自定义列并仅将所需的详细信息输出到表中，可以使用该 custom-columns 选项。您可以选择内联定义自定义列或使用模板文件：`-o=custom-columns=` 或 `-o=custom-columns-file=`。 +要定义自定义列并仅将所需的详细信息输出到表中，可以使用该 custom-columns 选项。你可以选择内联定义自定义列或使用模板文件：`-o=custom-columns=` 或 `-o=custom-columns-file=`。 -运行任何一个命令的结果是: +运行任何一个命令的结果类似于: ```shell NAME RSRC @@ -491,10 +537,10 @@ This allows for consistent human-readable output across clients used against the 通过让服务器封装打印的细节，这允许在针对同一集群使用的客户端之间提供一致的人类可读输出。 -默认情况下，此功能在 `kubectl` 1.11 及更高版本中启用。要禁用它，请将该 `--server-print=false` 参数添加到 `kubectl get` 命令中。 +此功能默认启用。要禁用它，请将该 `--server-print=false` 参数添加到 `kubectl get` 命令中。 -输出如下： +输出类似于： ```shell -NAME READY STATUS RESTARTS AGE -pod-name 1/1 Running 0 1m +NAME AGE +pod-name 1m ``` -使用以下示例集来帮助您熟悉运行常用 kubectl 操作： +使用以下示例集来帮助你熟悉运行常用 kubectl 操作： ```shell @@ -651,7 +703,7 @@ kubectl describe pods/ kubectl describe pods # 描述所有的 pod，不包括未初始化的 pod -kubectl describe pods --include-uninitialized=false +kubectl describe pods ``` {{< note >}} @@ -668,7 +720,7 @@ command retrieves not only the information about the node, but also a summary of the pods running on it, the events generated for the node etc. --> `kubectl get` 命令通常用于检索同一资源类型的一个或多个资源。 -它具有丰富的参数，允许您使用 `-o` 或 `--output` 参数自定义输出格式。您可以指定 `-w` 或 `--watch` 参数以开始观察特定对象的更新。 +它具有丰富的参数，允许你使用 `-o` 或 `--output` 参数自定义输出格式。你可以指定 `-w` 或 `--watch` 参数以开始观察特定对象的更新。 `kubectl describe` 命令更侧重于描述指定资源的许多相关方面。它可以调用对 `API 服务器` 的多个 API 调用来为用户构建视图。 例如，该 `kubectl describe node` 命令不仅检索有关节点的信息，还检索在其上运行的 pod 的摘要，为节点生成的事件等。 @@ -680,21 +732,25 @@ the pods running on it, the events generated for the node etc. `kubectl delete` - 从文件、stdin 或指定标签选择器、名称、资源选择器或资源中删除资源。 ```shell # 使用 pod.yaml 文件中指定的类型和名称删除 pod。 kubectl delete -f pod.yaml -# 删除标签名= 的所有 pod 和服务。 -kubectl delete pods,services -l name= - -# 删除所有具有标签名称= 的 pod 和服务，包括未初始化的那些。 -kubectl delete pods,services -l name= --include-uninitialized +# 删除所有带有 '=' 标签的 Pod 和服务。 +kubectl delete pods,services -l = # 删除所有 pod，包括未初始化的 pod。 kubectl delete pods --all @@ -707,19 +763,24 @@ kubectl delete pods --all ```shell # 从 pod 中获取运行 'date' 的输出。默认情况下，输出来自第一个容器。 -kubectl exec date +kubectl exec -- date # 运行输出 'date' 获取在容器的 中 pod 的输出。 -kubectl exec -c date +kubectl exec -c -- date # 获取一个交互 TTY 并运行 /bin/bash 。默认情况下，输出来自第一个容器。 -kubectl exec -ti /bin/bash +kubectl exec -ti -- /bin/bash ``` ```shell @@ -749,26 +813,28 @@ kubectl logs -f -使用以下示例来帮助您熟悉编写和使用 `kubectl` 插件： +使用以下示例来帮助你熟悉编写和使用 `kubectl` 插件： @@ -776,44 +842,51 @@ kubectl hello # 用任何语言创建一个简单的插件，并为生成的可执行文件命名 # 以前缀 "kubectl-" 开始 cat ./kubectl-hello -#!/bin/bash +``` + +```shell +#!/bin/sh # 这个插件打印单词 "hello world" echo "hello world" - -# 我们的插件写好了，让我们把它变成可执行的 -sudo chmod +x ./kubectl-hello +``` +这个插件写好了，把它变成可执行的： +```bash +sudo chmod a+x ./kubectl-hello # 并将其移动到路径中的某个位置 sudo mv ./kubectl-hello /usr/local/bin +sudo chown root:root /usr/local/bin -# 我们现在已经创建并"安装"了一个 kubectl 插件。 -# 我们可以开始使用我们的插件，从 kubectl 调用它，就像它是一个常规命令一样 +# 你现在已经创建并"安装了"一个 kubectl 插件。 +# 你可以开始使用这个插件，从 kubectl 调用它，就像它是一个常规命令一样 kubectl hello ``` ``` hello world ``` -``` -# 我们可以"卸载"一个插件，只需从我们的路径中删除它 +```shell +# 你可以"卸载"一个插件，只需从你的路径中删除它 sudo rm /usr/local/bin/kubectl-hello ``` -为了查看可用的所有 `kubectl` 插件，我们可以使用 `kubectl plugin list` 子命令： +为了查看可用的所有 `kubectl` 插件，你可以使用 `kubectl plugin list` 子命令： ```shell kubectl plugin list ``` +输出类似于： ``` -以下 kubectl-适配 的插件是可用的： +The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-hello /usr/local/bin/kubectl-foo /usr/local/bin/kubectl-bar ``` -``` -# 这个指令也可以警告我们哪些插件 -# 被运行，或是被其它插件覆盖了 -# 例如 -sudo chmod -x /usr/local/bin/kubectl-foo +`kubectl plugin list`指令也可以向你告警哪些插件被运行，或是被其它插件覆盖了,例如: +```shell +sudo chmod -x /usr/local/bin/kubectl-foo # 删除执行权限 kubectl plugin list ``` ``` -以下 kubectl-适配 的插件是可用的： +The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-hello /usr/local/bin/kubectl-foo - - 警告: /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 命令之上构建更复杂功能的一种方法： +你可以将插件视为在现有 kubectl 命令之上构建更复杂功能的一种方法： +```shell cat ./kubectl-whoami +``` + + +接下来的几个示例假设你已经将 `kubectl-whoami` 设置为以下内容: + + - ```shell -cat ./kubectl-whoami #!/bin/bash -# 这个插件借用 `kubectl config` 指令来输出 -# 当前用户的信息，基于当前指定的 context -kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}' +#这个插件利用 `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 文件中当前所选定上下文对应的用户： +运行以上命令将为你提供一个输出，其中包含 KUBECONFIG 文件中当前上下文的用户: - ```shell +#!/bin/bash # 使文件成为可执行的 sudo chmod +x ./kubectl-whoami -# 然后移动到我们的路径中 +# 然后移动到你的路径中 sudo mv ./kubectl-whoami /usr/local/bin kubectl whoami @@ -935,6 +1016,10 @@ To find out more about plugins, take a look at the [example cli plugin](https:// -开始使用 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 命令。 +* 开始使用 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 命令。 + +* 查看更多[示例 cli 插件](https://github.com/kubernetes/sample-cli-plugin)。 diff --git a/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md b/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md index 5a32824da0..44258be00a 100644 --- a/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md +++ b/content/zh/docs/reference/kubernetes-api/labels-annotations-taints.md @@ -14,7 +14,7 @@ This document serves both as a reference to the values and as a coordination poi Kubernetes 保留了 kubernetes.io 命名空间下的所有标签和注解。 -本文既作为这些标签和注解的参考，也就这些标签和注解的赋值进行了说明。 +本文档提供这些标签、注解和污点的参考，也可用来协调对这类标签、注解和污点的设置。 @@ -70,7 +70,7 @@ This label has been deprecated. Please use `kubernetes.io/arch` instead. -该标签已被弃用。请使用 `kubernetes.io/arch`。 +该标签已被弃用。请使用 `kubernetes.io/os`。 ## kubernetes.io/hostname @@ -89,6 +89,11 @@ The Kubelet populates this label with the hostname. Note that the hostname can b Kubelet 用 hostname 值来填充该标签。注意：可以通过向 `kubelet` 传入 `--hostname-override` 参数对 “真正的” hostname 进行修改。 + +此标签还用作拓扑层次结构的一部分。有关更多信息，请参见 [topology.kubernetes.io/zone](#topologykubernetesiozone)。 + @@ -98,7 +103,7 @@ Kubelet 用 hostname 值来填充该标签。注意：可以通过向 `kubelet` -从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用[node.kubernetes.io/instance-type](#nodekubernetesioinstance-type)。 +从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用 [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type)。 {{< /note >}} ## node.kubernetes.io/instance-type {#nodekubernetesioinstance-type} @@ -118,92 +123,47 @@ to rely on the Kubernetes scheduler to perform resource-based scheduling. You sh 用于：Node -Kubelet 用 `cloudprovider` 中定义的实例类型来填充该标签。未使用 `cloudprovider` 时不会设置该标签。该标签在想要将某些负载定向到特定实例类型的节点上时会很有用，但通常用户更希望依赖 Kubernetes 调度器来执行基于资源的调度，所以用户应该致力于基于属性而不是实例类型来进行调度(例如：需要一个 GPU，而不是 `g2.2xlarge`)。 +Kubelet 用 `cloudprovider` 中定义的实例类型来填充该标签。未使用 `cloudprovider` 时不会设置该标签。 +该标签在想要将某些负载定向到特定实例类型的节点上时会很有用，但通常用户更希望依赖 Kubernetes 调度器来执行基于资源的调度， +所以用户应该致力于基于属性而不是实例类型来进行调度（例如：需要一个 GPU，而不是 `g2.2xlarge`）。 ## failure-domain.beta.kubernetes.io/region (已弃用) {#failure-domainbetakubernetesioregion} -参考 [failure-domain.beta.kubernetes.io/zone](#failure-domainbetakubernetesiozone)。 +参考 [topology.kubernetes.io/region](#topologykubernetesioregion)。 {{< note >}} -从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用[topology.kubernetes.io/region](#topologykubernetesioregion)。 +从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用 [topology.kubernetes.io/region](#topologykubernetesioregion)。 {{< /note >}} ## failure-domain.beta.kubernetes.io/zone (已弃用) {#failure-domainbetakubernetesiozone} -示例： - -`failure-domain.beta.kubernetes.io/region=us-east-1` - -`failure-domain.beta.kubernetes.io/zone=us-east-1c` - -用于：Node、PersistentVolume - -对于 Node： Kubelet 用 `cloudprovider` 中定义的区域（zone）信息来填充该标签。未使用 `cloudprovider` 时不会设置该标签，但如果该标签在你的拓扑中有意义的话，应该考虑设置。 - - -用于 PersistentVolume：在 GCE 和 AWS 中，`PersistentVolumeLabel` 准入控制器会自动添加区域标签。 - - - -在单区的集群中，Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。在多区的集群中，这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。跨区分散通过 _SelectorSpreadPriority_ 来实现。 - - -_SelectorSpreadPriority_ 是一种尽力而为（best-effort）的处理方式，如果集群中的区域是异构的 (例如：不同区域之间的节点数量、节点类型或 pod 资源需求不同），可能使得 pod 在各区域间无法均匀分布。如有需要，用户可以使用同质的区域(节点数量和类型相同) 来减小 pod 分布不均的可能性。 - - -由于卷不能跨区域挂载（attach），调度器 (通过 _VolumeZonePredicate_ 预选) 也会保证需要特定卷的 pod -被调度到卷所在的区域中。 - - -区域和地域（region）的实际值无关紧要，两者的层次含义也没有严格的定义。最终期望是，除非整个地域故障， -否则某一区域节点的故障不应该影响到其他区域的节点。例如，通常区域间应该避免共用同一个网络交换机。 -具体的规划取决于特定的基础设备 - three-rack 设备所选择的设置与多数据中心截然不同。 - - -如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签，且用户希望防止 pod -跨区域进行卷的挂载，应考虑手动打标签 (或对 `PersistentVolumeLabel` 增加支持）。如果用户的基础设施没有这种约束，则不需要为卷添加区域标签。 +参考 [topology.kubernetes.io/zone](#topologykubernetesiozone)。 {{< note >}} -从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用[topology.kubernetes.io/zone](#topologykubernetesiozone)。 +从 kubernetes 1.17 版本开始，不推荐使用此标签，而推荐使用 [topology.kubernetes.io/zone](#topologykubernetesiozone)。 {{< /note >}} ## topology.kubernetes.io/region {#topologykubernetesioregion} + +示例： + +`topology.kubernetes.io/region=us-east-1` 示例： -`topology.kubernetes.io/region=us-east-1` - `topology.kubernetes.io/zone=us-east-1c` 用于：Node、PersistentVolume -对于 Node： Kubelet 用 `cloudprovider` 中定义的区域（zone）信息来填充该标签。未使用 `cloudprovider` 时不会设置该标签，但如果该标签在你的拓扑中有意义的话，应该考虑设置。 +对于 Node： `Kubelet` 或外部 `cloud-controller-manager` 用 `cloudprovider` 中定义的区域信息来填充该标签。 +未使用 `cloudprovider` 时不会设置该标签，但如果该标签在你的拓扑中有意义的话，应该考虑设置。 -用于 PersistentVolume：在 GCE 和 AWS 中，`PersistentVolumeLabel` 准入控制器会自动添加区域标签。 +对于 PersistentVolume：可感知拓扑的卷制备程序将自动在 `PersistentVolumes` 上设置节点亲和性约束。 -在单区的集群中，Kubernetes 会自动将同一副本控制器或服务下的 pod 分散到不同的节点上 (以降低故障的影响)。在多区的集群中，这种分散的行为扩展到跨区的层面 (以降低区域故障的影响)。跨区分散通过 _SelectorSpreadPriority_ 来实现。 +区域代表逻辑故障域。Kubernetes 集群通常跨越多个区域以提高可用性。 +虽然区域的确切定义留给基础架构实现，但是区域的常见属性包括区域内的网络延迟非常低，区域内的免费网络流量以及与其他区域的故障独立性。 +例如，一个区域内的节点可能共享一个网络交换机，但不同区域内的节点则不应共享。 +地区代表一个更大的域，由一个或多个区域组成。 +Kubernetes 集群跨越多个地域是不常见的，而地域或区域的确切定义则留给基础设施实现， +地域的共同属性包括它们之间的网络延迟比它们内部更高，它们之间的网络流量成本不为零，故障独立于其他区域或域。 +例如，一个地域内的节点可能共享电力基础设施（例如 UPS 或发电机），但不同地域的节点通常不会共享。 + + +Kubernetes 对区域和区域的结构做了一些假设: +1) 地域和区域是分层的:区域是地域的严格子集，任何区域都不能位于两个地域中。 +2) 区域名称在地域之间是唯一的；例如，地域 “africa-east-1” 可能包含区域 “africa-east-1a” 和 “africa-east-1b”。 + + +标签的使用者可以安全地假设拓扑标签不变。 +即使标签是严格可变的，标签的使用者也可以认为节点只能通过被销毁并重建才能从一个区域迁移到另一个区域。 + + +Kubernetes 可以以各种方式使用这些信息。 +例如，调度器自动尝试将 ReplicaSet 中的多个 Pods 分布到单区域集群中的多个节点上（为了减少节点故障的影响， +请参阅 [kubernetesiohostname](#kubernetesiohostname)）。 +对于多区域集群，这种分布行为也被应用到区域上（以减少区域故障的影响）。 +这是通过 _SelectorSpreadPriority_ 实现的。 + + _SelectorSpreadPriority_ 是一种尽力而为（best-effort）的处理方式，如果集群中的区域是异构的 -(例如：不同区域之间的节点数量、节点类型或 pod 资源需求不同），可能使得 pod 在各区域间无法均匀分布。 -如有需要，用户可以使用同质的区域(节点数量和类型相同) 来减小 pod 分布不均的可能性。 +(例如：不同区域之间的节点数量、节点类型或 Pod 资源需求不同），可能使得 Pod 在各区域间无法均匀分布。 +如有需要，用户可以使用同质的区域(节点数量和类型相同) 来减小 Pod 分布不均的可能性。 -由于卷不能跨区域挂载（attach），调度器 (通过 _VolumeZonePredicate_ 预选) 也会保证需要特定卷的 pod 被调度到卷所在的区域中。 - - -区域和地域（region）的实际值无关紧要，两者的层次含义也没有严格的定义。最终期望是，除非整个地域故障， -否则某一区域节点的故障不应该影响到其他区域的节点。例如，通常区域间应该避免共用同一个网络交换机。 -具体的规划取决于特定的基础设备 - 三机架安装所选择的设置与多数据中心截然不同。 +由于卷不能跨区域挂载（Attach），调度器（通过 _VolumeZonePredicate_ 预选）也会保证需要特定卷的 Pod 被调度到卷所在的区域中。 如果 `PersistentVolumeLabel` 准入控制器不支持自动为 PersistentVolume 打标签，且用户希望防止 pod 跨区域进行卷的挂载， -应考虑手动打标签 (或对 `PersistentVolumeLabel` 增加支持）。如果用户的基础设施没有这种约束，则不需要为卷添加区域标签。 +应考虑手动打标签 (或增加对 `PersistentVolumeLabel` 的支持）。如果用户的基础设施没有这种约束，则不需要为卷添加区域标签。 diff --git a/content/zh/docs/reference/scheduling/config.md b/content/zh/docs/reference/scheduling/config.md index 5fa8497097..15a324fbe6 100644 --- a/content/zh/docs/reference/scheduling/config.md +++ b/content/zh/docs/reference/scheduling/config.md @@ -19,19 +19,22 @@ file and passing its path as a command line argument. + +调度模板（Profile）允许你配置 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} +中的不同调度阶段。每个阶段都暴露于某个扩展点中。插件通过实现一个或多个扩展点来提供调度行为。 - -你可以通过运行 `kube-scheduler --config ` 来设置调度配置， -配置文件使用组件配置的 API ([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration) -或 [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration))。 -`v1alpha2` 可以配置 kube-scheduler 运行[多个配置文件](#multiple-profiles)。 +你可以通过运行 `kube-scheduler --config ` 来设置调度模板， +配置文件使用组件配置的 API ([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.19.0/config/v1beta1?tab=doc#KubeSchedulerConfiguration))。 最简单的配置如下： diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md index 4dce405bfb..861f3a6a66 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md @@ -28,6 +28,37 @@ kubeadm config images list [flags] + + + +--allow-missing-template-keys     默认值：true + + + + + +如果设置为 true，则在模板中缺少字段或哈希表的键时忽略模板中的任何错误。 +仅适用于 golang 和 jsonpath 输出格式。 + + + + + + +-o, --experimental-output string     默认值："text" + + + + + +输出格式：text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file 其中之一 + + + --config string @@ -48,7 +79,10 @@ kubeadm 配置文件的路径。 -一组键值对（key=value），用于描述各种特征。选项有：
Auditing=true|false (ALPHA - 默认值=false)
CoreDNS=true|false (默认值=true)
DynamicKubeletConfig=true|false (BETA - 默认值=false) +一组键值对（key=value），用于描述各种特征。选项是： +
Auditing=true|false (ALPHA - 默认=false) +
CoreDNS=true|false (默认=true) +
DynamicKubeletConfig=true|false (BETA - 默认=false) @@ -64,6 +98,19 @@ list 操作的帮助命令 + + + +--image-repository string     默认值："k8s.gcr.io" + + + + + +选择要从中拉取控制平面镜像的容器仓库 + + + -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 +包含名为 "target[suffix][+patchtype].extension" 的文件的目录路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md index af818dcf7f..00444ac3f4 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md @@ -65,27 +65,6 @@ kubeadm 配置文件的路径。 - ---csr-dir string - - - - -输出 CSR 和私钥的路径 - - - - - ---csr-only - - - - -创建 CSR 而不是生成证书 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md index 81f3965c94..49b2749c06 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md @@ -69,30 +69,6 @@ kubeadm 配置文件路径。 - ---csr-dir string - - - - -输出 CSR 和私钥的路径 - - - - ---csr-only - - - - -创建 CSR 而不是生成证书 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md index d7a28e7ff4..1b096a7424 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md @@ -111,30 +111,6 @@ Specify a stable IP address or DNS name for the control plane. - ---csr-dir string - - - - -输出 CSR 和私钥的路径 - - - - ---csr-only - - - - -创建 CSR 而不是生成证书 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-healthcheck-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-healthcheck-client.md index 8d8e7f3c54..706d70614e 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-healthcheck-client.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-healthcheck-client.md @@ -69,27 +69,6 @@ kubeadm 配置文件的路径。 - ---csr-dir string - - - - -CSR 和私钥的输出路径 - - - - ---csr-only - - - -创建 CSR 而不是生成证书 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md index 271ca5ed6e..9933975b92 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md @@ -71,26 +71,6 @@ kubeadm 配置文件的路径。 - ---csr-dir string - - - - -输出 CSR 和私钥的路径 - - - - ---csr-only - - - - -创建 CSR 而不是生成证书 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md index f8d9abb026..0f5fb4726e 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md @@ -70,30 +70,6 @@ kubeadm 配置文件的路径。 - ---csr-dir string - - - - -输出 CSR 和私钥的路径 - - - - ---csr-only - - - - -创建 CSR 而不是生成证书 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md index 50651388ee..fb39d4a6cf 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md @@ -60,30 +60,6 @@ kubeadm 配置文件的路径。 - ---csr-dir string - - - - -输出 CSR 和私钥的路径 - - - - ---csr-only - - - - -创建 CSR 而不是生成证书 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md index c2f833b8b4..fe02e3d078 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md @@ -141,27 +141,17 @@ A set of extra flags to pass to the Controller Manager or override default ones - --k, --experimental-kustomize string - - - - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 - - - --feature-gates string -一组用来描述各种功能特性的键值（key=value）对。选项是：
IPv6DualStack=true|false (ALPHA - default=false) +一组用来描述各种功能特性的键值（key=value）对。选项是： +
IPv6DualStack=true|false (ALPHA - 默认=false) +
PublicKeysECDSA=true|false (ALPHA - 默认=false) diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md index e74a615053..e480efd952 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md @@ -109,27 +109,17 @@ Specify a stable IP address or DNS name for the control plane. - --k, --experimental-kustomize string - - - - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 - - - --feature-gates string -一组键值对，用于描述各种特征的特征事项。选项是：
IPv6DualStack=true|false (ALPHA - default=false) +一组键值对，用于描述各种特征的特征事项。选项是： +
IPv6DualStack=true|false (ALPHA - 默认=false) +
PublicKeysECDSA=true|false (ALPHA - 默认=false) diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md index f8701e8f43..f13f966676 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md @@ -69,18 +69,6 @@ A set of extra flags to pass to the Controller Manager or override default ones - --k, --experimental-kustomize string - - - - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md index 159b5b8258..fea8bf741a 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md @@ -57,18 +57,6 @@ kubeadm 配置文件的路径。 - --k, --experimental-kustomize string - - - - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 - - - -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md index 05e9534c48..0a09b80c86 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md @@ -75,12 +75,18 @@ kubeadm 配置文件的路径。 --k, --experimental-kustomize string +--experimental-patches string - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 + +包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md index fe166d7196..e113203a1a 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md @@ -7,8 +7,8 @@ 当节点加入 kubeadm 初始化的集群时，我们需要建立双向信任。 @@ -21,7 +21,7 @@ provide a file - a subset of the standard kubeconfig file. This file can be a local file or downloaded via an HTTPS URL. The forms are kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443, kubeadm join --discovery-file path/to/file.conf, or kubeadm join ---discovery-file `https://url/file.conf`. Only one form can be used. If +--discovery-file https://url/file.conf. Only one form can be used. If the discovery information is loaded from a URL, HTTPS must be used. Also, in that case the host installed CA bundle is used to verify the connection. @@ -39,7 +39,9 @@ the connection. -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 +包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_etcd.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_etcd.md index 6f04c064a1..196f9f6840 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_etcd.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_etcd.md @@ -65,14 +65,18 @@ Create a new control plane instance on this node --k, --experimental-kustomize string +--experimental-patches string - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 +包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是"strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md index bc44492c4a..7a75089abb 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md @@ -142,14 +142,18 @@ For token-based discovery, allow joining without --discovery-token-ca-cert-hash --k, --experimental-kustomize string +--experimental-patches string - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 +包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md index 21f9a8c627..7f3da71e80 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md @@ -82,14 +82,18 @@ Create a new control plane instance on this node --k, --experimental-kustomize string +--experimental-patches string - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 +包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md index 69806e77db..de796ebe3a 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md @@ -27,6 +27,37 @@ kubeadm token list [flags] + + + +--allow-missing-template-keys     默认值：true + + + + + +如果设置为 true，则在模板中缺少字段或哈希表的键时忽略模板中的任何错误。 +仅适用于 golang 和 jsonpath 输出格式。 + + + + + + +-o, --experimental-output string     默认值："text" + + + + + +输出格式：text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file 其中之一 + + + -h, --help diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md index ffef1c5e70..e31467b0c5 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md @@ -106,14 +106,18 @@ Perform the upgrade of etcd. --k, --experimental-kustomize string +--experimental-patches string - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 +包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 @@ -125,7 +129,9 @@ The path where kustomize patches for static pod manifests are stored. -一组键值对，用于描述各种功能。选项包括：
IPv6DualStack=true|false (ALPHA - 默认值=false) +一组键值对，用于描述各种功能。选项包括： +
IPv6DualStack=true|false (ALPHA - 默认=false) +
PublicKeysECDSA=true|false (ALPHA - 默认=false) @@ -165,23 +171,6 @@ A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedU - - - ---image-pull-timeout duration     默认值：15m0s - - - - - -等待控制面板 pod 下载的最长时间。 - - - ``` +preflight 执行节点升级前检查 control-plane 如果存在的话，升级部署在该节点上的管理面实例 kubelet-config 更新该节点上的 kubelet 配置 ``` @@ -87,14 +89,18 @@ Perform the upgrade of etcd. --k, --experimental-kustomize string +--experimental-patches string - -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 +包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_control-plane.md b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_control-plane.md index 133f6451c2..4235ef59b5 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_control-plane.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_control-plane.md @@ -62,10 +62,19 @@ kubeadm upgrade node phase control-plane [flags] --> --k, --experimental-kustomize string +--experimental-patches string -用于存储 kustomize 为静态 pod 清单所提供的补丁的路径。 + + +包含名为 "target[suffix][+patchtype].extension" 的文件的目录的路径。 +例如，"kube-apiserver0+merge.yaml" 或仅仅是 "etcd.json"。 +"patchtype" 可以是 "strategic"、"merge" 或 "json" 之一，并且它们与 kubectl 支持的补丁格式匹配。 +默认的 "patchtype" 为 "strategic"。 "extension" 必须为 "json" 或 "yaml"。 +"suffix" 是一个可选字符串，可用于确定首先按字母顺序应用哪些补丁。 + +Kubernetes 证书的操作集合。 + +{{< tabs name="tab-certs" >}} +{{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}} +{{< /tabs >}} + + ## kubeadm alpha certs renew {#cmd-certs-renew} -使用 `all` 子命令来更新所有 Kubernetes 证书或有选择性地更新它们。有关证书到期和续订的更多详细信息，请参见[证书管理文档](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 +使用 `all` 子命令来更新所有 Kubernetes 证书或有选择性地更新它们。 +有关证书到期和续订的更多详细信息， +请参见[证书管理文档](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 {{< tabs name="tab-certs-renew" >}} {{< tab name="renew" include="generated/kubeadm_alpha_certs_renew.md" />}} @@ -53,19 +65,34 @@ This command can be used to generate a new control-plane certificate key. The key can be passed as `--certificate-key` to `kubeadm init` and `kubeadm join` to enable the automatic copy of certificates when joining additional control-plane nodes. --> -该命令可用于生成新的控制平面证书密钥。密钥可以作为 `--certificate-key` 参数传递给 `kubeadm init` 和 `kubeadm join` 操作，以在加入其他控制平面节点时启用证书的自动复制。 +该命令可用于生成新的控制平面证书密钥。 +密钥可以作为 `--certificate-key` 参数传递给 `kubeadm init` 和 `kubeadm join` 操作， +以在加入其他控制平面节点时启用证书的自动复制。 {{< tabs name="tab-certs-certificate-key" >}} {{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} {{< /tabs >}} +## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} + + +该命令可用于生成证书签名请求（CSR），CSR 可以将其提交给证书颁发机构（CA）进行签名。 + +{{< tabs name="tab-certs-generate-csr" >}} +{{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} +{{< /tabs >}} + ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} -此命令检查 kubeadm 管理的本地 PKI 中证书的到期时间。有关证书到期和续订的更多详细信息，请参见[证书管理文档](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 +此命令检查 kubeadm 管理的本地 PKI 中证书的到期时间。 +有关证书到期和续订的更多详细信息，请参见[证书管理文档](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 {{< tabs name="tab-certs-check-expiration" >}} {{< tab name="check-expiration" include="generated/kubeadm_alpha_certs_check-expiration.md" />}} @@ -101,7 +128,7 @@ Use the following command to enable the DynamicKubeletConfiguration feature. -子命令 `pivot` 可用于将 Pod 托管的静态控制平面转换为自托管的控制平面。有关 `pivot` 更多信息，请参见[文档](/docs/setup/production-environment/tools/kubeadm/self-hosting/)。 +子命令 `pivot` 可用于将 Pod 托管的静态控制平面转换为自托管的控制平面。有关 `pivot` 更多信息，请参见[文档](zh/docs/setup/production-environment/tools/kubeadm/self-hosting/)。 -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点 -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 会还原 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改。 +* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点 +* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群 +* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 会还原 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md index d36201165e..6cb9305b6c 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-config.md @@ -6,32 +6,39 @@ weight: 50 - -从 v1.8.0 开始，kubeadm 将集群的配置上传到名为 kube-system 的 ConfigMap 对象中，对象位于 kube-system 命名空间内。并在以后的升级中读取这个 ConfigMap 配置对象。 -这样可以保证系统组件的正确配置，提供无缝的用户体验。 +在 `kubeadm init` 执行期间，kubeadm 将 `ClusterConfiguration` 对象上传到你的集群的 `kube-system` 名字空间下 +名为 `kubeadm-config` 的 ConfigMap 对象中。 +然后在 `kubeadm join`、`kubeadm reset` 和 `kubeadm upgrade` 执行期间读取此配置。 +要查看此 ConfigMap，请调用 `kubeadm config view`。 - -您可以执行 kubeadm config view 来查看 ConfigMap。如果使用 kubeadm v1.7.x 或更低版本来初始化群集，必须先使用 kubeadm config upload 创建 ConfigMap，然后才能使用 kubeadm upgrade。 +你可以使用 `kubeadm config print` 命令打印默认配置， +并使用 `kubeadm config migrate` 命令将旧版本的配置转化成新版本。 +`kubeadm config images list` 和 `kubeadm config images pull` +命令可以用来列出并拉取 kubeadm 所需的镜像。 +For more information navigate to +[Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) +or [Using kubeadm join with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file). -在 Kubernetes v1.11.0 中，添加了一些新命令。你可以使用 kubeadm config print-default -打印默认配置，可以用 kubeadm config migrate 来将旧的配置文件转换到较新的版本，还可以使用 kubeadm config images list 和 kubeadm config images pull -列出并拉取 kubeadm 所需的镜像。 +In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image +the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) +has to be used. +--> +更多信息请浏览[使用带配置文件的 kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) +或[使用带配置文件的 kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file). + +在 Kubernetes v1.13.0 及更高版本中，要列出/拉取 kube-dns 镜像而不是 CoreDNS 镜像， +必须使用[这里](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)所描述的 `--config` 方法。 @@ -65,6 +72,6 @@ to list and pull the images that kubeadm requires. * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version --> -* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) 将 Kubernetes 集群升级到更新版本 [kubeadm upgrade] +* [kubeadm upgrade](/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) 将 Kubernetes 集群升级到更新版本 [kubeadm upgrade] diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md index 70f058f594..69cbc59b4c 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md @@ -23,7 +23,7 @@ if you wish to apply customization. `kubeadm init phase` is consistent with the [kubeadm init workflow](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow), and behind the scene both use the same code. --> -`kubeadm init phase` 与 [kubeadm init 工作流程](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow)一致，后台都使用相同的代码。 +`kubeadm init phase` 与 [kubeadm init 工作流](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow)一致，后台都使用相同的代码。 -可以使用此命令将 kubeadm 配置文件上传到集群。或者，使用 [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/) 方式。 +可以使用此命令将 kubeadm 配置文件上传到集群。或者使用 [kubeadm config](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/)。 {{< tabs name="upload-config" >}} {{< tab name="upload-config" include="generated/kubeadm_init_phase_upload-config.md" />}} @@ -198,6 +198,21 @@ Use the following phase to configure bootstrap tokens. {{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}} {{< /tabs >}} +## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all} + + +使用以下阶段在 TLS 引导后更新与 kubelet 相关的设置。 +你可以使用 `all` 子命令来运行所有 `kubelet-finalize` 阶段。 + +{{< tabs name="tab-kubelet-finalize" >}} +{{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}} +{{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}} +{{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}} +{{< /tabs >}} -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点 -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改 -* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能 +* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导 Kubernetes 控制平面节点 +* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点连接到集群 +* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 恢复通过 `kubeadm init` 或 `kubeadm join` 操作对主机所做的任何更改 +* [kubeadm alpha](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 50042ea558..9d0e64bec5 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -40,28 +40,25 @@ following steps: 1. Runs a series of pre-flight checks to validate the system state before making changes. Some checks only trigger warnings, others are considered errors and will exit kubeadm until the problem is corrected or the - user specifies `-ignore-preflight-errors=`. + user specifies `--ignore-preflight-errors=`. --> 1. 在做出变更前运行一系列的预检项来验证系统状态。一些检查项目仅仅触发警告， 其它的则会被视为错误并且退出 kubeadm，除非问题得到解决或者用户指定了 `--ignore-preflight-errors=` 参数。 -2. 生成一个自签名的 CA 证书 (或者使用现有的证书，如果提供的话) 来为集群中的每一个组件建立身份标识。 - 如果用户已经通过 `--cert-dir` 配置的证书目录（默认为 `/etc/kubernetes/pki`）提供了他们自己的 - CA 证书以及/或者密钥，那么将会跳过这个步骤，正如文档[使用自定义证书](#custom-certificates)所述。 - 如果指定了 `--apiserver-cert-extra-sans` 参数, APIServer 的证书将会有额外的 SAN 条目， - 如果必要的话，将会被转为小写。 +2. 生成一个自签名的 CA 证书来为集群中的每一个组件建立身份标识。 + 用户可以通过将其放入 `--cert-dir` 配置的证书目录中（默认为 `/etc/kubernetes/pki`） + 来提供他们自己的 CA 证书以及/或者密钥。 + APIServer 证书将为任何 `--apiserver-cert-extra-sans` 参数值提供附加的 SAN 条目，必要时将其小写。 4. 为 API 服务器、控制器管理器和调度器生成静态 Pod 的清单文件。假使没有提供一个外部的 etcd 服务的话，也会为 etcd 生成一份额外的静态 Pod 清单文件。 - -静态 Pod 的清单文件被写入到 `/etc/kubernetes/manifests` 目录; kubelet 会监视这个目录以便在系统启动的时候创建 Pod。 - -一旦控制平面的 Pod 都运行起来， `kubeadm init` 的工作流程就继续往下执行。 + 一旦控制平面的 Pod 都运行起来， `kubeadm init` 的工作流程就继续往下执行。 -1. 对控制平面节点应用 labels 和 taints 标记以便不会在它上面运行其它的工作负载。 +5. 对控制平面节点应用标签和污点标记以便不会在它上面运行其它的工作负载。 -2. 生成令牌以便其它节点以后可以使用这个令牌向控制平面节点注册它们自己。 - (可选)，用户可以通过 `--token` 提供一个令牌，正如文档 - [kubeadm token](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) 所述。 +6. 生成令牌，将来其他节点可使用该令牌向控制平面注册自己。 + 如文档 [kubeadm token](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) 所述， + 用户可以选择通过 `--token` 提供令牌。 -3. 为了使得节点能够遵照[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) +7. 为了使得节点能够遵照[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) 和 [TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 这两份文档中描述的机制加入到集群中，kubeadm 会执行所有的必要配置： - 创建一份 ConfigMap 提供添加集群节点所需的信息，并为该 ConfigMap 设置相关的 RBAC 访问规则。 + - 使得 Bootstrap Tokens 可以访问 CSR 签名 API。 - - 对新的 CSR 请求配置为自动签发。 - -查阅[kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)文档以获取更多信息。 + - 配置自动签发新的 CSR 请求。 + 获取更多信息，请查看[kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)。 + -1. 通过 API 服务器安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件。 - 在 1.11 版本以及更新版本的 Kubernetes 中 CoreDNS 是默认的 DNS 服务器。 + To install kube-dns instead of CoreDNS, the DNS addon has to be configured in the kubeadm `ClusterConfiguration`. + For more information about the configuration see the section `Using kubeadm init with a configuration file` below. + Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed. + + {{< warning >}} + kube-dns usage with kubeadm is deprecated as of v1.18 and will be removed in a future release. + {{< /warning >}} +--> +8. 通过 API 服务器安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件。 + 在 Kubernetes 版本 1.11 和更高版本中，CoreDNS 是默认的 DNS 服务器。 要安装 kube-dns 而不是 CoreDNS，必须在 kubeadm `ClusterConfiguration` 中配置 DNS 插件。 有关配置的更多信息，请参见下面的"带配置文件使用 kubeadm init" 一节。 请注意，尽管已部署 DNS 服务器，但直到安装 CNI 时才调度它。 + {{< warning >}} + 从 v1.18 开始，在 kubeadm 中使用 kube-dns 已废弃，并将在以后的版本中将其删除。 + {{< /warning >}} + @@ -209,28 +229,35 @@ The config file is still considered beta and may change in future versions. 通过一份配置文件而不是使用命令行参数来配置 `kubeadm init` 命令是可能的， -但是一些更加高级的功能只能够通过配置文件设定。这份配置文件通过 `--config` 选项参数指定。 +但是一些更加高级的功能只能够通过配置文件设定。 +这份配置文件通过 `--config` 选项参数指定的， +它必须包含 `ClusterConfiguration` 结构，并可能包含更多由 `---\n` 分隔的结构。 +在某些情况下，可能不允许将 `--config` 与其他标志混合使用。 可以使用 [kubeadm config print](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/)命令打印出默认配置。 +如果你的配置没有使用最新版本， **推荐**使用 [kubeadm config migrate](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/) -命令将旧的 `v1beta1` 版本的配置迁移到 `v1beta2` 版本。 +命令进行迁移。 -获取 `v1beta2` 版本配置中每个字段的细节说明，查看我们的 -[API 参考页面](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)。 +有关配置的字段和用法的更多信息， +你可以导航到我们的 API 参考页面并从 +[列表](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories)中选择一个版本。 有关向控制平面组件传递命令行参数的说明请查看： -[控制平面命令行参数](//zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/) +[控制平面命令行参数](/zh/docs/setup/production-environment/tools/kubeadm/control-plane-flags/) 以下阶段命令可用于证书到期后重新上传证书： -``` -kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE +```shell +kubeadm init phase upload-certs --upload-certs --certificate-key=SOME_VALUE --config=SOME_YAML_FILE ``` 以下命令可用于按需生成新密钥： -``` +```shell kubeadm alpha certs certificate-key ``` - -### 使用自定义的证书 {#custom-certificates} + +### 使用 kubeadm 管理证书 - -默认情况下, kubeadm 会生成运行一个集群所需的全部证书。 -你可以通过提供你自己的证书来改变这个行为策略。 - - -如果要这样做, 你必须将证书文件放置在通过 `--cert-dir` 命令行参数或者配置文件里的 -`CertificatesDir` 配置项指明的目录中。默认的值是 `/etc/kubernetes/pki`。 - - -如果在运行 `kubeadm init` 之前存在给定的证书和私钥对，则 kubeadm 将不会重写它们。 -例如，这意味着你可以将现有的 CA 复制到 `/etc/kubernetes/pki/ca.crt` 和 -`/etc/kubernetes/pki/ca.key` 中，而 kubeadm 将使用此 CA 对其余证书进行签名。 - - -#### 外部 CA 模式 {#external-ca-mode} - - -如果只提供了 `ca.crt` 文件但是没有提供 `ca.key` 文件也是可以的 (这只对 CA 根证书可用，其它证书不可用)。 -如果所有的其它证书和 kubeconfig 文件已就绪， kubeadm 检测到满足以上条件就会激活 "外部 CA" 模式。 -kubeadm 将会在没有 CA 密钥文件的情况下继续执行。 - - -否则, kubeadm 将独立运行 controller-manager，附加一个 `--controllers=csrsigner` 的参数， -并且指明 CA 证书和密钥。 +有关使用 kubeadm 进行证书管理的详细信息，请参阅[使用 kubeadm 进行证书管理](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。 +该文档包括有关使用外部 CA，自定义证书和证书更新的信息。 1. 生成一个令牌。这个令牌必须具有以下格式：`< 6 个字符的字符串>.< 16 个字符的字符串>`。 更加正式的说法是，它必须符合以下正则表达式：`[a-z0-9]{6}\.[a-z0-9]{16}`。 + kubeadm 可以为你生成一个令牌： ```shell @@ -536,7 +523,7 @@ provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/ku * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` --> -* 进一步阅读了解[kubeadm init 阶段](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) +* 进一步阅读了解[kubeadm init phase](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) * [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/)启动一个 Kubernetes 工作节点并且将其加入到集群 * [kubeadm upgrade](/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/)将 Kubernetes 集群升级到新版本 * [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/)使用 `kubeadm init` 或 `kubeadm join` 来恢复对节点的变更 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md index 17e604629a..7463121ced 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join-phase.md @@ -14,7 +14,7 @@ weight: 90 Hence, you can let kubeadm do some of the work and you can fill in the gaps if you wish to apply customization. --> -`kubeadm join phase` 使您能够调用 `join` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。 +`kubeadm join phase` 使你能够调用 `join` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。 -使用此阶段，您可以准备一个作为控制平面的节点。 +使用此阶段，你可以准备一个作为控制平面的节点。 {{< tabs name="tab-control-plane-prepare" >}} {{< tab name="control-plane-prepare" include="generated/kubeadm_join_phase_control-plane-prepare.md" />}} @@ -60,7 +60,7 @@ Using this phase you can prepare a node for serving a control-plane. -使用此阶段，您可以配置 kubelet 设置、证书和（重新）启动 kubelet。 +使用此阶段，你可以配置 kubelet 设置、证书和（重新）启动 kubelet。 {{< tabs name="tab-kubelet-start" >}} {{< tab name="kubelet-start" include="generated/kubeadm_join_phase_kubelet-start.md" />}} @@ -71,7 +71,7 @@ Using this phase you can write the kubelet settings, certificates and (re)start -使用此阶段，您可以将节点作为控制平面实例加入。 +使用此阶段，你可以将节点作为控制平面实例加入。 {{< tabs name="tab-control-plane-join" >}} {{< tab name="control-plane-join" include="generated/kubeadm_join_phase_control-plane-join.md" />}} diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md index 00e024ecdd..edb4e56369 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -18,14 +18,14 @@ This command initializes a Kubernetes worker node and joins it to the cluster. {{< include "generated/kubeadm_join.md" >}} +### join 工作流 {#join-workflow} + - -### 加入流程 - `kubeadm join` 初始化 Kubernetes 工作节点并将其加入集群。 该操作过程包含下面几个步骤： @@ -39,85 +39,160 @@ This action consists of the following steps: 默认情况下，它使用引导令牌和 CA 密钥哈希来验证数据的真实性。 也可以通过文件或 URL 直接发现根 CA。 - - -1. 如果调用 kubeadm 时启用了 `--feature-gates=DynamicKubeletConfig`，它首先从主机上检索 kubelet 初始化配置并将其写入磁盘。 - 当 kubelet 启动时，kubeadm 更新节点的 `Node.spec.configSource` 属性。 - 进一步了解动态 kubelet 配置 请参考 [使用配置文件设置 Kubelet 参数](/docs/tasks/administer-cluster/kubelet-config-file/) 和 [重新配置集群中节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/)。 - - + 1. 一旦知道集群信息，kubelet 就可以开始 TLS 引导过程。 + TLS 引导程序使用共享令牌与 Kubernetes API 服务器进行临时的身份验证，以提交证书签名请求 (CSR)； 默认情况下，控制平面自动对该 CSR 请求进行签名。 - - + 1. 最后，kubeadm 配置本地 kubelet 使用分配给节点的确定标识连接到 API 服务器。 + +对于控制平面节点，执行额外的步骤： + +1. 从集群下载控制平面节点之间共享的证书（如果用户明确要求）。 + +1. 生成控制平面组件清单、证书和 kubeconfig。 + +1. 添加新的本地 etcd 成员。 + +1. 将此节点添加到 kubeadm 集群的 ClusterStatus。 + + +### 使用 kubeadm 的 join phase 命令 {#join-phases} + + +Kubeadm 允许你使用 `kubeadm join phase` 分阶段将节点加入集群。 + + +要查看阶段和子阶段的有序列表，可以调用 `kubeadm join --help`。 +该列表将位于帮助屏幕的顶部，每个阶段旁边都有一个描述。 +注意，通过调用 `kubeadm join`，所有阶段和子阶段都将按照此确切顺序执行。 + + +有些阶段具有唯一的标志，因此，如果要查看可用选项列表，请添加 `--help`，例如： + +```shell +kubeadm join phase kubelet-start --help +``` + + +类似于 [kubeadm init phase](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)命令， +`kubeadm join phase` 允许你使用 `--skip-phases` 标志跳过阶段列表。 + +例如： + +```shell +sudo kubeadm join --skip-phases=preflight --config=config.yaml +``` + +### 发现要信任的集群 CA + - -### 发现要信任的集群 CA - Kubeadm 的发现有几个选项，每个选项都有安全性上的优缺点。 -适合您的环境的正确方法取决于节点是如何准备的以及您对网络的安全性期望和节点的生命周期特点。 +适合你的环境的正确方法取决于节点是如何准备的以及你对网络的安全性期望和节点的生命周期特点。 +#### 带 CA 锁定模式的基于令牌的发现 + - -#### 带 CA 锁定模式的基于令牌的发现 - 这是 Kubernetes 1.8 及以上版本中的默认模式。 -在这种模式下，kubeadm 下载集群配置（包括根CA）并使用令牌验证它，并且会验证根 CA 的公钥与所提供的哈希是否匹配，以及 API 服务器证书在根 CA 下是否有效。 +在这种模式下，kubeadm 下载集群配置（包括根CA）并使用令牌验证它， +并且会验证根 CA 的公钥与所提供的哈希是否匹配， +以及 API 服务器证书在根 CA 下是否有效。 - CA 键哈希格式为 `sha256:`。 -默认情况下，在 `kubeadm init` 最后打印的 `kubeadm join` 命令或者 `kubeadm token create --print-join-command` 的输出信息中返回哈希值。 -它使用标准格式 (请参考 [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4)) 并且也能通过第三方工具或者驱动系统进行计算。 +默认情况下，在 `kubeadm init` 最后打印的 `kubeadm join` 命令 +或者 `kubeadm token create --print-join-command` 的输出信息中返回哈希值。 +它使用标准格式 (请参考 [RFC7469](https://tools.ietf.org/html/rfc7469#section-2.4)) +并且也能通过第三方工具或者制备系统进行计算。 例如，使用 OpenSSL CLI： -```bash +```shell openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //' ``` + - **`kubeadm join` 命令示例** -```bash + +对于工作节点： + +```shell kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443 ``` + +对于控制面节点： + +```shell +kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443 +``` + + +如果使用 `--upload-certs` 调用 `kubeadm init` 命令， +你也可以对控制平面节点调用带 `--certificate-key` 参数的 `join` 命令， +将证书复制到该节点。 + +#### 无 CA 锁定模式的基于令牌的发现 + - -#### 无 CA 锁定模式的基于令牌的发现 - _这是 Kubernetes 1.7 和早期版本_中的默认设置；使用时要注意一些重要的补充说明。 此模式仅依赖于对称令牌来签名(HMAC-SHA256)发现信息，这些发现信息为主节点建立信任根。 -在 Kubernetes 1.8 及以上版本中仍然可以使用 `--discovery-token-unsafe-skip-ca-verification` 参数，但是如果可能的话，您应该考虑使用一种其他模式。 +在 Kubernetes 1.8 及以上版本中仍然可以使用 `--discovery-token-unsafe-skip-ca-verification` 参数，但是如果可能的话，你应该考虑使用一种其他模式。 **`kubeadm join` 命令示例** -``` -kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443` +```shell +kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443 ``` - #### 基于 HTTPS 或文件发现 + 这种方案提供了一种带外方式在主节点和引导节点之间建立信任根。 如果使用 kubeadm 构建自动配置，请考虑使用此模式。 +发现文件的格式为常规的 Kubernetes [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文件。 + +如果发现文件不包含凭据，则将使用 TLS 发现令牌。 - **`kubeadm join` 命令示例：** - `kubeadm join --discovery-file path/to/file.conf` （本地文件） @@ -245,82 +326,116 @@ using kubeadm. **劣势：** - - 要求您有某种方法将发现信息从主节点传送到引导节点。 + - 要求你有某种方法将发现信息从主节点传送到引导节点。 例如，这可以通过云提供商或驱动工具实现。 该文件中的信息不是加密的，而是需要 HTTPS 或等效文件来保证其完整性。 +### 确保你的安装更加安全 {#securing-more} + - -### 确保您的安装更加安全 {#securing-more} - Kubeadm 的默认值可能不适用于所有人。 本节说明如何以牺牲可用性为代价来加强 kubeadm 安装。 +#### 关闭节点客户端证书的自动批准 + - -#### 关闭节点客户端证书的自动批准 - 默认情况下，Kubernetes 启用了 CSR 自动批准器，如果在身份验证时使用 Bootstrap Token，它会批准对 kubelet 的任何客户端证书的请求。 如果不希望集群自动批准kubelet客户端证书，可以通过执行以下命令关闭它： -```console -$ kubectl delete clusterrole kubeadm:node-autoapprove-bootstrap +```shell +kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap ``` + - 关闭后，`kubeadm join` 操作将会被阻断，直到管理员已经手动批准了在途中的 CSR 才会继续： -```console -$ kubectl get csr +```shell +kubectl get csr +``` + + +输出类似于： + +``` NAME AGE REQUESTOR CONDITION node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 18s system:bootstrap:878f07 Pending +``` -$ kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ +```shell +kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ +``` + + +输出类似于： + +``` certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved +``` -$ kubectl get csr +```shell +kubectl get csr +``` + + +输出类似于： + +``` NAME AGE REQUESTOR CONDITION node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ 1m system:bootstrap:878f07 Approved,Issued ``` + + +这迫使工作流只有在运行了 kubectl 证书批准后，kubeadm join 才能成功。 + +#### 关闭对集群信息 ConfigMap 的公开访问 + - -只有执行了 `kubectl certificate approve` 后，`kubeadm join` 才会继续。 - -#### 关闭对集群信息 ConfigMap 的公开访问 - 为了实现使用令牌作为唯一验证信息的加入工作流，默认情况下会公开带有验证主节点标识所需数据的 ConfigMap。 虽然此 ConfigMap 中没有私有数据，但一些用户可能希望无论如何都关闭它。 这样做需要禁用 `kubeadm join` 工作流的 `--discovery-token` 参数。 以下是实现步骤： -```console -$ kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml + +* 从 API 服务器获取 `cluster-info` 文件： + +```shell +kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/ //" | tee cluster-info.yaml +``` + + +输出类似于： + +``` apiVersion: v1 +kind: Config clusters: - cluster: certificate-authority-data: @@ -328,7 +443,6 @@ clusters: name: "" contexts: [] current-context: "" -kind: Config preferences: {} users: [] ``` @@ -343,18 +457,18 @@ users: [] * 关闭 `cluster-info` ConfigMap 的公开访问： -```console -$ kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo +```shell +kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo ``` - 这些命令应该在执行 `kubeadm init` 之后、在`kubeadm join` 之前执行。 + ### 使用带有配置文件的 kubeadm join {{< caution >}} @@ -366,25 +480,33 @@ These commands should be run after `kubeadm init` but before `kubeadm join`. It's possible to configure `kubeadm join` with a configuration file instead of command line flags, and some more advanced features may only be available as configuration file options. This file is passed using the `--config` flag and it must -contain a `JoinConfiguration` structure. - -To print the default values of `JoinConfiguration` run the following command: +contain a `JoinConfiguration` structure. Mixing `--config` with others flags may not be +allowed in some cases. --> - 可以用配置文件替代命令行参数的方法配置 `kubeadm join`，一些高级功能也只有在使用配置文件时才可选用。 该文件通过 `--config` 参数来传递，并且文件中必须包含 `JoinConfiguration` 结构。 +在某些情况下，不允许将 `--config` 与其他标志混合使用。 -执行下面的命令可以查看 `JoinConfiguration` 默认值： + +使用 [kubeadm config print](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/) +命令可以打印默认配置。 + +如果你的配置没有使用最新版本， +**推荐**使用 [kubeadm config migrate](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/) +命令转换。 - -要了解 `JoinConfiguration` 中各个字段的详细信息请参考 [godoc](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#JoinConfiguration)。 +有关配置的字段和用法的更多信息，你可以导航到我们的 API 参考页 +并从[列表]中选择一个版本(https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories)。 ## {{% heading "whatsnext" %}} @@ -394,7 +516,7 @@ For details on individual fields in `JoinConfiguration` see [the godoc](https:// * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) to manage tokens for `kubeadm join` * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join` --> -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 初始化 Kubernetes 主节点 -* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/) 管理 `kubeadm join` 的令牌 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 将 `kubeadm init` 或 `kubeadm join` 对主机的更改恢复到之前状态 +* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) 初始化 Kubernetes 主节点 +* [kubeadm token](/zh/docs/reference/setup-tools/kubeadm/kubeadm-token/) 管理 `kubeadm join` 的令牌 +* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 将 `kubeadm init` 或 `kubeadm join` 对主机的更改恢复到之前状态 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md index 785c983d99..74a5118599 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset-phase.md @@ -16,7 +16,7 @@ weight: 90 Hence, you can let kubeadm do some of the work and you can fill in the gaps if you wish to apply customization. --> -`kubeadm reset phase` 使您能够调用 `reset` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。 +`kubeadm reset phase` 使你能够调用 `reset` 过程的基本原子步骤。因此，如果希望执行自定义操作，可以让 kubeadm 做一些工作，然后由用户来补足剩余操作。 -使用此阶段，您可以在要重置的节点上执行启动前检查阶段。 +使用此阶段，你可以在要重置的节点上执行启动前检查阶段。 {{< tabs name="tab-preflight" >}} {{< tab name="preflight" include="generated/kubeadm_reset_phase_preflight.md" />}} @@ -49,7 +49,7 @@ Using this phase you can execute preflight checks on a node that is being reset. -使用此阶段，您可以从 ClusterStatus 对象中删除此控制平面节点。 +使用此阶段，你可以从 ClusterStatus 对象中删除此控制平面节点。 {{< tabs name="tab-update-cluster-status" >}} {{< tab name="update-cluster-status" include="generated/kubeadm_reset_phase_update-cluster-status.md" />}} @@ -63,7 +63,7 @@ Using this phase you can remove this control-plane node from the ClusterStatus o -使用此阶段，您可以从 etcd 集群中删除此控制平面节点的 etcd 成员。 +使用此阶段，你可以从 etcd 集群中删除此控制平面节点的 etcd 成员。 {{< tabs name="tab-remove-etcd-member" >}} {{< tab name="remove-etcd-member" include="generated/kubeadm_reset_phase_remove-etcd-member.md" />}} @@ -77,7 +77,7 @@ Using this phase you can remove this control-plane node's etcd member from the e -使用此阶段，您可以在此节点上执行清理工作。 +使用此阶段，你可以在此节点上执行清理工作。 {{< tabs name="tab-cleanup-node" >}} {{< tab name="cleanup-node" include="generated/kubeadm_reset_phase_cleanup-node.md" />}} diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md index ca87f78ba8..3df205658d 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset.md @@ -35,16 +35,16 @@ etcd member of this node from the etcd cluster and also removes this node's info To skip a list of phases you can use the `--skip-phases` flag, which works in a similar way to the `kubeadm join` and `kubeadm init` phase runners. --> `kubeadm reset phase` 可用于执行上述工作流程的各个阶段。 -要跳过阶段列表，您可以使用 `--skip-phases` 参数，该参数的工作方式类似于 `kubeadm join` 和 `kubeadm init` 阶段运行器。 +要跳过阶段列表，你可以使用 `--skip-phases` 参数，该参数的工作方式类似于 `kubeadm join` 和 `kubeadm init` 阶段运行器。 ### 外部 etcd 清理 -如果使用了外部 etcd，`kubeadm reset` 将不会删除任何 etcd 中的数据。这意味着，如果再次使用相同的 etcd 端点运行 `kubeadm init`，您将看到先前集群的状态。 +如果使用了外部 etcd，`kubeadm reset` 将不会删除任何 etcd 中的数据。这意味着，如果再次使用相同的 etcd 端点运行 `kubeadm init`，你将看到先前集群的状态。 -要清理 etcd 中的数据，建议您使用 etcdctl 这样的客户端，例如： +要清理 etcd 中的数据，建议你使用 etcdctl 这样的客户端，例如： ```bash etcdctl del "" --prefix @@ -58,6 +58,6 @@ etcdctl del "" --prefix -* 参考 [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 来初始化 Kubernetes 主节点。 -* 参考 [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 来初始化 Kubernetes 工作节点并加入集群。 +* 参考 [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) 来初始化 Kubernetes 主节点。 +* 参考 [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) 来初始化 Kubernetes 工作节点并加入集群。 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md index ba49bc9834..4409371db7 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-token.md @@ -1,5 +1,5 @@ --- -title: kubeadm 令牌 +title: kubeadm token content_type: concept weight: 70 --- @@ -22,14 +22,14 @@ Bootstrap tokens are used for establishing bidirectional trust between a node jo the cluster and a master node, as described in [authenticating with bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/). --> -如[使用引导令牌进行身份验证](/docs/reference/access-authn-authz/bootstrap-tokens/)所描述的，引导令牌用于在即将加入集群的节点和主节点间建立双向认证。 +如[使用引导令牌进行身份验证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)所描述的，引导令牌用于在即将加入集群的节点和主节点间建立双向认证。 -`kubeadm init` 创建了一个有效期为 24 小时的令牌，下面的命令允许您管理令牌，也可以创建和管理新的令牌。 +`kubeadm init` 创建了一个有效期为 24 小时的令牌，下面的命令允许你管理令牌，也可以创建和管理新的令牌。 @@ -49,10 +49,7 @@ such a token and also to create and manage new ones. ## {{% heading "whatsnext" %}} -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 引导 Kubernetes 工作节点并将其加入群集 - - - +* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) 引导 Kubernetes 工作节点并将其加入集群 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md index 22633af056..1b970b5097 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade-phase.md @@ -27,6 +27,7 @@ be called on a primary control-plane node. {{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} +{{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}} @@ -40,8 +41,8 @@ be called on a primary control-plane node. * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a kubeadm node * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) to try experimental functionality --> -* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导一个 Kubernetes 控制平面节点 -* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点加入到群集 -* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 还原 `kubeadm init` 或 `kubeadm join` 命令对主机所做的任何更改 -* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) 升级 kubeadm 节点 -* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能 +* [kubeadm init](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/) 引导一个 Kubernetes 控制平面节点 +* [kubeadm join](/zh/docs/reference/setup-tools/kubeadm/kubeadm-join/) 将节点加入到集群 +* [kubeadm reset](/zh/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 还原 `kubeadm init` 或 `kubeadm join` 命令对主机所做的任何更改 +* [kubeadm upgrade](/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) 升级 kubeadm 节点 +* [kubeadm alpha](/zh/docs/reference/setup-tools/kubeadm/kubeadm-alpha/) 尝试实验性功能 diff --git a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md index f387963503..4388edcfe4 100644 --- a/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md +++ b/content/zh/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md @@ -31,18 +31,18 @@ behind one command, with support for both planning an upgrade and actually perfo The steps for performing a upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website. --> -[本文档](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)概述了使用 kubeadm 执行升级的步骤。 +[本文档](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)概述了使用 kubeadm 执行升级的步骤。 有关 kubeadm 旧版本，请参阅 Kubernetes 网站的旧版文档。 -您可以使用 `kubeadm upgrade diff` 来查看将应用于静态 pod 清单的更改。 +你可以使用 `kubeadm upgrade diff` 来查看将应用于静态 pod 清单的更改。 -要在 Kubernetes v1.13.0 及更高版本中使用 kube-dns 进行升级，请遵循[本指南](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)。 +要在 Kubernetes v1.13.0 及更高版本中使用 kube-dns 进行升级，请遵循[本指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon)。 在 Kubernetes v1.15.0 和更高版本中，`kubeadm upgrade apply` 和 `kubeadm upgrade node` 也将自动续订该节点上的 kubeadm 托管证书，包括存储在 kubeconfig 文件中的证书。 -要选择退出，可以传递参数 `--certificate-renewal=false`。有关证书续订的更多详细信息请参见[证书管理文档](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。 +要选择退出，可以传递参数 `--certificate-renewal=false`。有关证书续订的更多详细信息请参见[证书管理文档](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。 +{{< note >}} + +`kubeadm upgrade apply` 和 `kubeadm upgrade plan` 命令都具有遗留的 `--config` 标志， +可以在执行特定控制平面节点的规划或升级时重新配置集群。 +请注意，升级工作流不是为这种情况而设计的，并且有意外结果的报告。 +{{}} + ## kubeadm upgrade plan {#cmd-upgrade-plan} {{< include "generated/kubeadm_upgrade_plan.md" >}} @@ -72,5 +84,5 @@ renewal see the [certificate management documentation](/docs/tasks/administer-cl -* 如果您使用 kubeadm v1.7.x 或更低版本初始化集群，则可以参考[kubeadm 配置](/docs/reference/setup-tools/kubeadm/kubeadm-config/)配置集群用于 `kubeadm upgrade`。 +* 如果你使用 kubeadm v1.7.x 或更低版本初始化集群，则可以参考[kubeadm 配置](/zh/docs/reference/setup-tools/kubeadm/kubeadm-config/)配置集群用于 `kubeadm upgrade`。 diff --git a/content/zh/docs/reference/tools.md b/content/zh/docs/reference/tools.md index caec8028c9..eb348c89ce 100644 --- a/content/zh/docs/reference/tools.md +++ b/content/zh/docs/reference/tools.md @@ -41,11 +41,11 @@ Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernet ## Minikube -[`minikube`](/docs/tasks/tools/install-minikube/) 是一个可以方便用户在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。 +[`minikube`](https://minikube.sigs.k8s.io/docs/) 是一个可以方便用户在其工作站点本地部署一个单节点 Kubernetes 集群的工具，用于开发和测试。 ## Dashboard @@ -84,9 +84,9 @@ Use Helm to: ## Kompose -[`Kompose`](https://github.com/kubernetes-incubator/kompose) 一个转换工具，用来帮助 Docker Compose 用户迁移至 Kubernetes。 +[`Kompose`](https://github.com/kubernetes/kompose) 一个转换工具，用来帮助 Docker Compose 用户迁移至 Kubernetes。 -### 监视书签（Watch Bookmark） +### 监视书签 {#Watch-bookmark} 为了处理历史窗口过短的问题，我们引入了 `bookmark（书签）` 监视事件的概念。 该事件是一种特殊事件，用来标示客户端所请求的、指定的 `resourceVersion` 之前 @@ -233,7 +233,7 @@ Content-Type: application/json -## 分块检视大体量结果 +## 分块检视大体量结果 {#retrieving-large-results-sets-in-chunks} {{< feature-state for_k8s_version="v1.9" state="beta" >}} @@ -367,7 +367,7 @@ list 请求时不指定 `continue` 令牌。 The output from the `kubectl get` command is a simple tabular representation of one or more instances of a particular resource type. In the past, clients were required to reproduce the tabular and describe output implemented in `kubectl` to perform simple lists of objects. A few limitations of that approach include non-trivial logic when dealing with certain objects. Additionally, types provided by API aggregation or third party resources are not known at compile time. This means that generic implementations had to be in place for types unrecognized by a client. --> -## 以表格形式接收资源 +## 以表格形式接收资源 {#receiving-resources-as-tables} `kubectl get` 命令的输出是一个包含一个或多个资源的简单表格形式。 过去，客户端需要重复 `kubectl` 中所实现的表格输出和描述输出逻辑，以执行 @@ -469,7 +469,7 @@ See the API documentation for a list of supported content types for each API. For example: --> -## 资源的其他表示形式 +## 资源的其他表示形式 {#alternate-representations-of-resources} 默认情况下，Kubernetes 返回 JSON 序列化的的对象并设定内容类型为 `application/json`。这是 API 的默认序列化格式。 @@ -531,7 +531,7 @@ their `Accept` header to support fallback to JSON: API 扩展而加入的资源。如果客户端必须能够处理所有资源类型，则应在其 `Accept` 头部指定多种内容类型以便可以回退到 JSON 格式： -``` +```console Accept: application/vnd.kubernetes.protobuf, application/json ``` @@ -553,7 +553,7 @@ Kubernetes 使用封套形式来对 Protobuf 响应进行编码。 封套格式如下： -``` +```console 四个字节的特殊数字前缀： 字节 0-3: "k8s\x00" [0x6b, 0x38, 0x73, 0x00] @@ -623,7 +623,7 @@ Clients that receive a response in `application/vnd.kubernetes.protobuf` that do Resources are deleted in two phases: 1) finalization, and 2) removal. --> -## 资源删除 +## 资源删除 {#resource-deletion} 资源删除要经过两个阶段：1) 终止（finalization），和 2）去除。 @@ -811,775 +811,18 @@ Some values of an object are typically generated before the object is persisted. {{< feature-state for_k8s_version="v1.16" state="beta" >}} -从 Kubernetes v1.18 开始，如果你启动了服务器端应用（Service Side Apply）功能 -特性，则控制面会跟踪所有新创建的对象的托管字段（Managed Fields）。 - - -### 介绍 {#introduction} - -服务器端应用可以通过声明式配置帮助用户和控制器管理其资源。此功能特性允许 -用户和控制器通过将完全设定的意愿发送到服务器以声明式方式创建与/或更改其对象。 - -完全设定的意愿（Fully Specified Intent）是对象的一个部分，仅包含用户希望表达 -其意愿的字段和取值。此意愿或者是要创建一个新的对象，或者是由服务器来负责 -完成的、与现有对象的[合并](#merge-strategy)。 - -系统支持多个施加者（Applier）同一个对象上进行协作。 - - -对对象字段的变更是通过“[字段管理](#field-management)”来进行跟踪的。 -当字段的值发生变化时，其属主从其当前的管理器切换为作出变更的管理器。 -尝试应用对象时，取值不同的字段以及由另一个管理器所拥有的字段都会导致 -[冲突](#conflicts)。引发冲突的目的是通告该操作可能会撤销掉另一协作方 -所做的变更。冲突可以被强制解决，从而导致字段取值被覆盖且其属主关系 -被转移。 - - -如果你从配置中去除了一个字段并应用该配置，服务器端应用组件会检查是否有其他字段 -管理器也拥有该字段。如果该字段不再被任何其他字段管理器所拥有，则或者它会被 -从现时对象上删除，或者会被重置为其默认值（假设有的话）。 -同样的规则也适用于关联列表或映射条目。 - -服务器端应用旨在成为原来的 `kubectl apply` 的替代技术，同时也作为控制器来 -施加其变更的一种更简单的机制。 - - -### 字段管理 {#field-management} - -与 `kubectl` 所管理的 `last-applied` 注解相比，服务器端应用机制使用的是一种 -更为贴近声明式管理的方法。该方法会跟踪用户的字段管理而不是其上一次应用的 -状态。这就意味着，作为服务器端应用的一种副作用，关于哪个字段管理器管理对象中 -哪个字段的信息也变得透明。 - -从服务器端应用的角度，让用户来管理字段意味着用户可以相信并期望字段不会发生变更。 -上次对某字段取值做出断言的用户会被记录为当前的字段管理器。 -这一记录操作可以通过使用 `POST`、`PUT` 或非应用性（non-apply）的 `PATCH` 去 -更改字段值来实现，或者将字段包含在发送该服务器端应用末端的配置中来实现。 -当使用服务器端应用特性时，尝试更给由其他人所管理的字段会导致请求被拒绝 -（这里指非强制应用场景，参见[冲突](#conflicts)）。 - - -当两个或者多个施加者将某字段设置为相同的值，它们会共享字段的属主地位。 -由任何施加者所发起的、尝试变更共享字段取值的请求都会导致冲突。 -共享字段的属主可以通过将字段从其配置中去除来放弃其属主角色。 - -字段管理信息保存在 `managedFields` 字段中，而该字段是对象 -[`metadata`](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#objectmeta-v1-meta) -的一部分。 - -通过服务器端应用创建的对象的一个简单例子看起来可能像这样： - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: test-cm - namespace: default - labels: - test-label: test - managedFields: - - manager: kubectl - operation: Apply - apiVersion: v1 - time: "2010-10-10T0:00:00Z" - fieldsType: FieldsV1 - fieldsV1: - f:metadata: - f:labels: - f:test-label: {} - f:data: - f:key: {} -data: - key: some value -``` - - -上面的对象在其 `metadata.managedFields` 中包含了唯一的管理器。管理器记录中 -包含了管理实体自身的一些基本信息，例如操作类型、API 版本以及所管理的字段。 - -此字段由 API 服务器管理，因而不应被用户修改。 - -尽管如此，通过 `Update` 操作来更改 `metadata.managedFields` 字段值还是可能的。 -这样做是非常不鼓励的，但在某些场合也可能是一种合理的选择。例如，`managedFields` -陷入了某种不一致的状态（很明显这种事不应该发生）。 - -`managedFields` 的格式在[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#fieldsv1-v1-meta) -中有详细描述。 - -### 冲突 {#conflicts} - - -冲突是一种特殊的状态错误，发生在某 `Apply` 操作尝试变更某字段，而另一个用户 -也声称要管理之的时候。冲突的检测可以避免某一施加者不小心覆盖另一个用户所设置 -的字段值。当发生冲突时，解决它的方法有三种： - - -- **覆盖字段值，成为唯一的管理器：** 如果有意要覆盖字段值（或者施加者本身是 - 一个控制器这种自动化进程），施加者应该设置查询参数 `force` 为 `true，并 - 再次发出请求。这样做会强迫操作成功，更改字段值，将字段从 `managedFields` - 中其他管理器项中去除。 - -- **不重载字段值，放弃管理主张：** 如果施加者不再关心字段取值，它们可以将字段 - 从其配置中删除并再次发出请求。这样做会保留字段值不变，同时从 `managedFields` - 中施加者条目中删除该字段。 - -- **不重载字段值，成为共享管理器：** 如果施加者仍然关心字段取值，但不想重载 - 其当前值，它可以将其配置中该字段的值更改为与服务器端对象上的值匹配，并再次 - 发出请求。这样做会保留字段取值不变，同时使得字段的管理权力被施加者以及所有 - 原来声称要管理该字段的其他字段管理器一起分享。 - - -### 管理器 {#managers} - -管理器标示更改对象的不同工作流（尤其是在有冲突的场合），可以作为更改对象的请求 -的一部分，在 `fieldManager` 查询参数中设定。该参数对于 Apply 操作的端点是必需 -的，尽管 `kubectl` 会将其默认设置为 `kubectl`。对于其他更新操作，其默认值是 -基于用户代理（User-agent）计算而来的。 - - -### 应用与更新 {#apply-and-update} - -服务器端应用所考虑的两种操作分别是 `Apply` （内容类型设置为 -`application/apply-patch+yaml` 的 `PATCH` 操作）和 `Update`（所有其他会更改 -对象的操作）。这两种操作都会更新 `managedFields` 字段值，但其行为略有不同。 - - -{{< note >}} -无论你所提交的是 JSON 数据或者 YAML 数据，都应将 `Content-Type` 头部字段 -的值设置为 `application/apply-patch+yaml`。 - -所有 JSON 文档也都是合法的 YAML 文档。 -{{< /note >}} - - -例如，发生冲突时只有 Apply 操作会失败，而 Update 操作不会失败。 -还有，Apply 操作要求通过提供一个 `fieldManager` 查询参数来标识自身，而 -对于 Update 操作而言，这一查询参数是可选的。 -最后，使用 Apply 操作时，被应用的对象中不能包含 `managedFields` 字段。 - -带有多个管理器的一个对象示例可能看起来是这个样子： - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: test-cm - namespace: default - labels: - test-label: test - managedFields: - - manager: kubectl - operation: Apply - apiVersion: v1 - fields: - f:metadata: - f:labels: - f:test-label: {} - - manager: kube-controller-manager - operation: Update - apiVersion: v1 - time: '2019-03-30T16:00:00.000Z' - fields: - f:data: - f:key: {} -data: - key: new value -``` - - -在此例中，第二个操作是由一个称作 `kube-controller-manager` 的管理器所发起的 -`Update` 执行的。该 Update 操作更改了 data 字段的值，导致该字段的管理者被更改 -为 `kube-controller-manager`。 - - -{{< note >}} -如果此操作是一个 Apply 操作，则操作可能已因为属主冲突而失败。 -{{< /note >}} - - -### 合并策略 {#merge-strategy} - -服务器端应用所实现的合并策略能够支持相对更为稳定的对象生命周期。 -服务器端应用机制尝试基于字段的管理器是谁来合并字段而不是仅仅基于字段取值来判断。 -这种机制旨在通过减少意外的干扰而将多个主体更新同一对象的操作变得更为简单和稳定。 - -当用户发送一个“完全指定的意愿”对象到服务器端应用端点，如果字段值同时出现在现时 -对象中和所给的意愿对象中，服务器会优先选择应用配置中的字段值。 -如果应用的配置中存在的条目集合不是同一用户上次应用的条目集合的超集，所有未被其他 -施加者管理的、在应用的配置中缺失的条目都会被移除。 -关于如何使用对象的模式定义（Schema）来决定合并行为的更多信息，可参阅 -[sigs.k8s.io/structured-merge-diff](https://sigs.k8s.io/structured-merge-diff)。 - - -Kubernetes 1.16 和 1.17 中都添加了若干的标志（Markers），便于 API 开发人员 -描述 list、map 和 struct 所支持的合并策略。这些标志可以应用到 Go 文件中 -对应类型的对象或者 [CRD 的 OpenAPI 模式定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)： - - -| Golang 标志 | OpenAPI 扩展 | 可接受的值 | 描述 | 引入版本 | -|---|---|---|---|---| -| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | 可应用到 list 类型。`atomic` 和 `set` 适用于仅包含标量的 list。`map` 适用于由内嵌类型组成的 list。如果配置为 `atomic`，则整个 list 会在合并时被替换掉；每次只会有一个管理器负责总体管理这个 list。如果配置为 `granular`，则不同的管理器可以分别管理不同的表项。 | 1.16 | -| `//+listMapKey` | `x-kubernetes-list-map-keys` | 由 map 主键构成的可唯一标识表项的切片，例如 `["port", "protocol"]` | 仅当标记了 `+listType=map` 时适用。切片中各个字符串对应的取值的组合必须能够唯一性地标识 list 中的表项。尽管主键可以有多个，由于在 Go 语言类型中每个键需要独立设置，这里的 `listMapKey` 是单数形式。 | 1.16 | -| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | 适用于 map 类型。`atomic` 意味着 map 只能被某管理器整体替换。`granular` 则意味着 map 支持使用不同管理器来更新不同字段。 | 1.17 | -| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | 适用于 struct 类型。除此以外，其用法和 OpenAPI 注解都与 `//+mapType` 相同。 | 1.17 | - - -### 定制资源 {#custom-resources} - -默认情况下，服务器端应用机制会将定制资源视为无结构的数据。其中所有键都会 -被视同 struct 的字段，而所有 list 都会被视为 atomic。 - -如果定制资源定义（CRD）定义了包含如[合并策略](#merge-strategy)节所述的注解的 -[模式定义（Schema）](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io)， -则在合并该类型对象时会使用到这些注解。 - - -### 在控制器中使用服务器端应用机制 {#using-server-side-apply-in-a-controller} - -作为控制器的开发人员，你可以将服务器端应用机制作为一种方法来简化你的控制器中的更新逻辑。 -与“读出-更改-写回”或“读出-更改-打补丁”方式相比，区别如下： - -* 所应用的对象必需包含控制器所关心的所有字段； -* 没有办法移除控制器之前未曾应用过的字段（控制器在这些使用场景中仍然可以发送一个 - PATCH/UPDATE 请求）。 -* 对象不需要事先读出，且不必指定 `resourceVersion` 值。 - -强烈建议控制器总是“强制解决”冲突，因为它们可能无法更好地解决或者处理这些冲突。 - - -### 转移属主关系 {#transferring-ownership} - -除了[冲突解决](#conflicts)机制所提供的并发控制外，服务器端应用机制还提供了一些 -方法，通过协作式途径将字段属主从用户转移到控制器。 - -这一转移操作最好通过示例来阐明。我们来看如何安全地将 `replicas` 字段的属主从 -一个用户转移给一个控制器，同时允许使用 HorizontalPodAutoscaler 资源及其相配套 -的控制器为 Deployment 提供自动的水平扩缩。 - -假定一个用户定义了一个 Deployment，并将其 `replicas` 设置为其期望值： - -{{< codenew file="application/ssa/nginx-deployment.yaml" >}} - - -用户使用服务器端应用机制创建了 Deployment： - -```shell -kubectl apply -f application/ssa/nginx-deployment.yaml --server-side -``` - - -再接下来，为 Deployment 启用了 HPA，例如： - -```shell -kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=1 --max=10 -``` - - -现在，用户希望将 `replicas` 从其配置中移除，这样它们就不会与 HPA -控制器产生冲突。不过，仍然会有竞争条件出现：在 HPA 觉得需要调整 `replicas` -之前可能还有一段时间。如果用户在向 `replicas` 字段写入新值进而成为其属主之前， -已经从配置中移除了该字段，则 API 服务器会将 `replicas` 设置为 1，也就是该字段 -的默认值。这一复位操作并非用户希望发生的事情，即使是临时性的复位也不可以。 - - -解决方案有两种： - -- （较容易的方案）在配置中保留 `replicas`，当 HPA 终于向该字段中写入取值时， - 系统会向用户报告一个冲突事件。在这一刻，从配置中移除该字段是相对安全的。 - -- （更高级的方案）如果用户不想等待 HPA 写入字段值的事件，例如他们希望集群状态对 - 他们的同事而言也是清晰明确的，则他们可以采取以下步骤安全地从他们的配置中移除 - `replicas` 字段。 - - -首先，用户定义一个新的，仅包含 `replicas` 字段的配置： - -{{< codenew file="application/ssa/nginx-deployment-replicas-only.yaml" >}} - - -接下来使用名为 `handover-to-hpa` 的字段管理器应用该配置： - -```shell -kubectl apply -f application/ssa/nginx-deployment-replicas-only.yaml --server-side --field-manager=handover-to-hpa --validate=false -``` - - -如果应用操作与 HPA 控制器发生冲突，则什么也不做。冲突恰好表明控制器比平时早了 -一点发出对该字段的主张： - -这时，用户可以从其配置中删除 `replicas` 字段。 - -{{< codenew file="application/ssa/nginx-deployment-no-replicas.yaml" >}} - - -注意，无论 HPA 控制器何时将 `replicas` 字段设置为新的取值，临时性的字段管理器 -都不再拥有任何字段，并且会被自动删除。用户不需要执行清理操作。 - - -### 在用户间移交属主角色 {#transferring-ownership-between-users} - -用户之间可以通过在他们所应用的配置中将字段设置为相同的值来转移字段属主关系， -这样做会共享对字段的拥有权。一旦用户间共享了字段的属主关系，其中一个用户就 -可以从其所应用的配置中移除该字段，放弃属主角色，从而完成了属主关系的移交。 - - -### 与客户端应用的比较 {#comparison-with-client-side-apply} - -服务器端应用机制所实现的冲突检测和解决方案的后果之一是施加者在其本地状态中总是 -能够看到最新的字段值。如果他们看不到，则在下次执行 Apply 操作时会收到冲突事件。 -解决冲突的三种方法中，任何一种都会让所应用的配置成为服务器端对象字段的最新 -子集。 - -这点与客户端应用不同，施加者本地配置中保留的可能是已经被其他用户更改过了的过时 -的取值。只有用户更新该字段时，相应的字段值才会变得准确。施加者也无法知道他们 -下次执行 Apply 操作时是否会重载其他用户做出的变更。 - -另外一点区别在于使用客户端应用的施加者无法更改他们所使用的 API -版本，但是服务器端应用能够支持这种使用场景。 - - -### 从客户端应用升级到服务器端应用 {#upgrading-from-client-side-apply-to-server-side-apply} - -客户端应用机制的用户如果在使用 `kubectl apply` 来管理资源，可以使用下面的标志 -来开始使用服务器端应用： - -```shell -kubectl apply --server-side [--dry-run=server] -``` - - -默认情况下，对象的字段管理会从客户端应用转移到 kubectl -服务器端应用，且不会出现冲突状况。 - - -{{< caution >}} -请保持 `last-applied-configuration` 注解内容是最新的。该注解用来推测客户端 -应用所管理的字段。所有没有被客户端应用管理的字段都会引发冲突。 - -例如，如果你在客户端应用操作后使用 `kubectl scale` 命令更新了 `replicas` -字段，该字段不再由客户端应用所拥有，在 `kubectl apply --server-side` 时会 -引发冲突。 -{{< /caution >}} - - -此行为适用于使用 `kubectl` 字段管理器执行的服务器端应用。 -作为一种例外情况，你也可以选择不采用这种行为，而是像下面的例子中所给的那样， -指定一个不同的、非默认的字段管理器。用 `kubectl` 来执行服务器端应用时，默认 -的字段管理器总是 `kubectl`。 - -```shell -kubectl apply --server-side --field-manager=my-manager [--dry-run=server] -``` - - -### 从服务器端应用降格为客户端应用 {#downgrading-from-server-side-apply-to-client-side-apply} - -如果你使用 `kubectl apply --server-side` 来管理资源，你可以直接使用 -`kubectl apply` 来降格到客户端应用机制。 - -降格操作之所以能够有效是因为 kubectl 服务器端应用在你使用 `kubectl apply` -时会保持 `last-applied-configuration` 注解内容一直是最新的。 - -这一行为适用于使用 `kubectl` 字段管理器执行的服务器端应用。 -作为一种例外情况，你也可以选择不采用这种默认行为，而像下面例子中所展示的 -那样，设置一个不同的、非默认的字段管理器。`kubectl` 所触发的服务器端应用 -默认会将字段管理器设置为 `kubectl`。 - -```shell -kubectl apply --server-side --field-manager=my-manager [--dry-run=server] -``` - - -### API 端点 {#api-endpoint} - -启用了服务器端应用功能特性之后，`PATCH` 操作的端点能够接受 -`application/apply-patch+yaml` 内容类型。 -服务器端应用机制的用户可以以 YAML 格式将部分设定的对象发送到该端点。 -在应用配置时，用户应该包含希望设置的所有字段在内。 - - -### 清除 `managedFields` {#clearing-managedfields} - -通过 `MergePatch`、`StrategicMergePatch`、`JSONPatch` 或 `Update` 等非 Apply -操作是可以清除对象上的所有 `managedFields` 内容的。通过这些操作，用户可以将 -`managedFields` 字段重新设置为空的列表。 -下面是两个例子： - - -```console -PATCH /api/v1/namespaces/default/configmaps/example-cm -Content-Type: application/merge-patch+json -Accept: application/json - -Data: {"metadata":{"managedFields": [{}]}} -``` - -```console -PATCH /api/v1/namespaces/default/configmaps/example-cm -Content-Type: application/json-patch+json -Accept: application/json - -Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}] -``` - - -上面的操作会覆盖 `managedFields` 字段取值，使之成为一个只有一个空表项的列表， -进而使得 `managedFields` 整个会被充对象上剥离。 -注意，仅仅将 `managedFields` 设为空列表还不足以将字段取值复位。 -这样的设计是有意为之的，目的是避免 `managedFields` 字段被不了解该字段的客户端 -意外清除。 - -如果此复位操作和对 `managedFields` 字段之外的其它字段的变更一起提交，则 -`managedFields` 的内容会首先被重置，之后才会处理其他字段变更。因此，施加者会 -成为同一请求中被更新的字段的属主。 - - -{{< caution >}} -服务器端应用机制无法正确地跟踪某些子资源的属主，如果这些子资源不能接收资源 -对象类型数据的话。如果你针对这类子资源使用服务器端应用机制，则所变更的字段 -不会被跟踪记录。 -{{< /caution >}} - - -### 禁用此功能特性 {#disabling-the-feature} - -服务器端应用是一种 Beta 阶段的特性，因此默认是被启用的。如要将此 -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)关闭， -你需要在启动 `kube-apiserver` 时包含 `--feature-gates ServerSideApply=false` -标志。如果你运行了多个 `kube-apiserver` -副本，则每个副本上都要作同样的标志设置。 +从 Kubernetes v1.18 开始，可以启用[服务器端应用](/zh/docs/reference/using-api/server-side-apply/)功能 +特性，启用该特性后，控制面会跟踪所有新创建的对象的托管字段。服务器端应用提供了一种简洁的模式来管理字段冲突，提供服务器端的 `Apply` 和 `Update` 操作，并取代了 +`kubectl apply` 的客户端功能。有关该特性的详细描述，请参见[服务器端应用](/zh/docs/reference/using-api/server-side-apply/)章节 -### `metadata` 中的 `resourceVersion` +### `metadata` 中的 `resourceVersion` {#resourceVersion-in-metadata} 客户端可以在资源中看到资源版本信息，这里的资源包括从服务器返回的 Watch 事件 以及 list 操作响应： @@ -1694,40 +937,42 @@ quorum read to be served. 集群性能和可扩缩性。后者需要提供带票选能力的读操作。 + +{{< table caption="list 操作的 resourceVersionMatch 与分页参数" >}} + | resourceVersionMatch 参数 | 分页参数 | resourceVersion 未设置 | resourceVersion="0" | resourceVersion="\<非零值\>" | |-----------------------------------------|---------------------------------|-------------------------|-----------------------------------------|----------------------------------| -| resourceVersionMatch 未设置 | limit 未设置 | 最新版本 | 任意版本 | 不老于指定版本 | -| resourceVersionMatch 未设置 | limit=n, continue 未设置 | 最新版本 | 任意版本 | 精确匹配 | -| resourceVersionMatch 未设置 | limit=n, continue=\ | Continue 令牌、精确匹配 | 非法请求，视为 Continue 令牌、精确匹配 | 非法请求，HTTP `400 Bad Request` | -| resourceVersionMatch=Exact\* | limit 未设置 | 非法请求 | 非法请求 | 精确匹配 | -| resourceVersionMatch=Exact\* | limit=n, continue 未设置 | 非法请求 | 非法请求 | 精确匹配 | -| resourceVersionMatch=NotOlderThan\* | limit 未设置 | 非法请求 | 任意版本 | 不老于指定版本 | -| resourceVersionMatch=NotOlderThan\* | limit=n, continue 未设置 | 非法请求 | 任意版本 | 不老于指定版本 | +| resourceVersionMatch 未设置 | limit 未设置 | 最新版本 | 任意版本 | 不老于指定版本 | +| resourceVersionMatch 未设置 | limit=\, continue 未设置 | 最新版本 | 任意版本 | 精确匹配 | +| resourceVersionMatch 未设置 | limit=\, continue=\ | 从 token 开始、精确匹配 | 非法请求，视为从 token 开始、精确匹配 | 非法请求，返回 HTTP `400 Bad Request` | +| resourceVersionMatch=Exact [1] | limit 未设置 | 非法请求 | 非法请求 | 精确匹配 | +| resourceVersionMatch=Exact [1] | limit=\, continue 未设置 | 非法请求 | 非法请求 | 精确匹配 | +| resourceVersionMatch=NotOlderThan [1] | limit 未设置 | 非法请求 | 任意版本 | 不老于指定版本 | +| resourceVersionMatch=NotOlderThan [1] | limit=\, continue 未设置 | 非法请求 | 任意版本 | 不老于指定版本 | -
- +{{< /table >}} **脚注：** -\* 如果服务器无法正确处理 `resourceVersionMatch` 参数，其行为与未设置该参数相同。 +[1] 如果服务器无法正确处理 `resourceVersionMatch` 参数，其行为与未设置该参数相同。 + +{{< table caption="watch 操作的 resourceVersion 设置" >}} + | resourceVersion 未设置 | resourceVersion="0" | resourceVersion="\<非零值\>" | |---------------------------|--------------------------|------------------------------| | 读取状态并从最新版本开始 | 读取状态并从任意版本开始 | 从指定版本开始 | +{{< /table >}} + - - - - -此页提供 Kubernetes API 的总览 - - - - - - - -REST API 是 Kubernetes 的基础架构。组件之间的所有操作和通信，以及外部用户命令都是 API Server 处理的 REST API 调用。因此，Kubernetes 平台中的所有资源被视为 API 对象，并且在 -[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 中都有对应的定义项。 - -大多数操作可以通过 [kubectl](/docs/reference/kubectl/overview/) 命令行界面或其他命令行工具执行，例如 [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)，它们本身也使用 API。但是，您也可以使用 REST 调用直接访问 API。 - -如果您正在使用 Kubernetes API 编写应用程序，请考虑使用 [客户端库](/docs/reference/using-api/client-libraries/)。 - - -## API 版本控制 - -为了消除字段或重组资源表示形式，Kubernetes 支持多个 API 版本，每个版本在不同的 API 路径下。例如：`/api/v1` 或者 `/apis/extensions/v1beta1`。 - -版本是在 API 级别而非资源或字段级别配置的： - -- 确保 API 呈现出清晰一致的系统资源和行为视图。 -- 允许控制对已寿终正寝的 API 和/或实验性 API 的访问。 - -JSON 和 Protobuf 序列化模式在出现模式变更时均遵循这些准则。以下说明同时适用于这两种格式。 - - - -{{< note >}} -API 版本和软件版本是间接相关的。[API 和发布版本建议](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) 描述了 API 版本和软件版本之间的关系。 -{{< /note >}} - - -不同的 API 版本表示不同级别的稳定性和支持级别。您可以在 [API 变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable) 中找到有关每个级别的条件的更多信息。 - -以下是每个级别的摘要： - -- Alpha： - - 版本名称包含 `alpha`（例如，`v1alpha1`）。 - - 该软件可能包含错误。启用功能可能会暴露错误。默认情况下，功能可能被禁用。 - - 对功能的支持随时可能被删除，但不另行通知。 - - 在以后的软件版本中，API 可能会以不兼容的方式更改，亦不另行通知。 - - 由于存在更高的错误风险和缺乏长期支持，建议仅在短期测试集群中使用该软件。 - -- Beta： - - 版本名称包含`beta`（例如，`v2beta3`）。 - - 该软件已经过充分测试。启用功能被认为是安全的。默认情况下启用功能。 - - 尽管细节可能会发生变更，对应功能不会被废弃。 - - 在随后的 Beta 或稳定版本中，对象的模式和/或语义可能会以不兼容的方式更改。发生这种情况时，将提供迁移说明。迁移时可能需要删除、编辑和重新创建 API 对象。编辑过程可能需要一些思考。对于依赖该功能的应用程序，可能需要停机。 - - 该软件仅建议用于非关键业务用途，因为在后续版本中可能会发生不兼容的更改。如果您有多个可以独立升级的群集，则可以放宽此限制。 - - {{< note >}} - - - -请试用 Beta 版功能并提供反馈。功能结束 Beta 版之后，再进行变更可能是不切实际的。 - - {{< /note >}} - - - -- 稳定版： - - 版本名称为 `vX`，其中`X`为整数。 - - 功能特性的稳定版本会持续出现在许多后续版本的发行软件中。 - - - -## API 组 - -[ *API 组*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) 使扩展 Kubernetes API 更容易。API 组在 REST 路径和序列化对象的 apiVersion 字段中指定。 - -当前，有几个正在使用的 API 组： - -* *core*（也称为 *legacy*）组，它位于 REST 路径`/api/v1`上，未指定为 apiVersion 字段的一部分，例如`apiVersion: v1`。 -* 特定名称的组位于 REST 路径`/apis/$GROUP_NAME/$VERSION`下，并使用`apiVersion:$GROUP_NAME/$VERSION`（例如，`apiVersion:batch/v1`）。您可以在 [Kubernetes API 参考](/docs/reference/) 中找到受支持的 API Group 的完整列表。 - -有两种途径来使用 [自定义资源](/docs/concepts/api-extension/custom-resources/) 扩展 API，分别是： - - - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) 提供基本的 CRUD 需求。 - - [聚合器（Aggregator）](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)具有完整的 Kubernetes API 语义，用以实现用户自己的 apiserver。 - - -## 启用 API 组 - -默认情况下，某些资源和 API 组处于启用状态。您可以通过设置`--runtime-config`来启用或禁用它们。 -`--runtime-config` 接受逗号分隔的值。例如： - - 要禁用 `batch/v1`，请配置`--runtime-config=batch/v1=false` - - 要启用 `batch/2alpha1`，请配置`--runtime-config=batch/v2alpha1` -该标志接受描述 apiserver 的运行时配置的以逗号分隔的`key=value` 对集合。 - -{{< note >}} - - -启用或禁用组或资源时，需要重新启动 apiserver 和控制器管理器以刷新 `--runtime-config` 的更改。 - -{{< /note >}} - - - -## 启用 extensions/v1beta1 组中具体资源 - -在 `extensions/v1beta1` API 组中，DaemonSets，Deployments，StatefulSet, NetworkPolicies, PodSecurityPolicies 和 ReplicaSets 是默认禁用的。 -例如：要启用 deployments 和 daemonsets，请设置 `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`。 - -{{< note >}} - - -出于遗留原因，仅在 `extensions / v1beta1` API 组中支持各个资源的启用/禁用。 - -{{< /note >}} - - diff --git a/content/zh/docs/reference/using-api/client-libraries.md b/content/zh/docs/reference/using-api/client-libraries.md index 20855fbe48..6cc437b139 100644 --- a/content/zh/docs/reference/using-api/client-libraries.md +++ b/content/zh/docs/reference/using-api/client-libraries.md @@ -24,11 +24,11 @@ API from various programming languages. -在使用 [Kubernetes REST API](/docs/reference/using-api/api-overview/) 编写应用程序时， +在使用 [Kubernetes REST API](/zh/docs/reference/using-api/) 编写应用程序时， 您并不需要自己实现 API 调用和 “请求/响应” 类型。 您可以根据自己的编程语言需要选择使用合适的客户端库。 @@ -36,22 +36,22 @@ You can use a client library for the programming language you are using. Client libraries often handle common tasks such as authentication for you. Most client libraries can discover and use the Kubernetes Service Account to authenticate if the API client is running inside the Kubernetes cluster, or can -understand the [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) +understand the [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) format to read the credentials and the API Server address. --> 客户端库通常为您处理诸如身份验证之类的常见任务。 如果 API 客户端在 Kubernetes 集群中运行，大多数客户端库可以发现并使用 Kubernetes 服务帐户进行身份验证， -或者能够理解 [kubeconfig 文件](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) +或者能够理解 [kubeconfig 文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 格式来读取凭据和 API 服务器地址。 -## 官方支持的 Kubernetes 客户端库 +## 官方支持的 Kubernetes 客户端库 {#officially-supported-kubernetes-client-libraries} 以下客户端库由 [Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) 正式维护。 @@ -78,7 +78,9 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery -## 社区维护的客户端库 +## 社区维护的客户端库 {#community-maintained-client-libraries} + +{{% thirdparty-content %}} | 语言 | 客户端库 | | -------------------- | ---------------------------------------- | @@ -122,28 +129,33 @@ their authors, not the Kubernetes team. | Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | | Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | +| Java | [github.com/manusa/yakc](https://github.com/manusa/yakc) | | Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) | | Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) | | Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | -| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | -| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | | Node.js | [github.com/ajpauwels/easy-k8s](https://github.com/ajpauwels/easy-k8s) +| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | +| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | | Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) | -| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | | PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) | +| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | | PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) | +| PHP | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) | | Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | +| Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | -| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | +| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | +| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | | Scala | [github.com/doriordan/skuber](https://github.com/doriordan/skuber) | -| dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | +| Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | +| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | -| Haskell | [github.com/soundcloud/haskell-kubernetes](https://github.com/soundcloud/haskell-kubernetes) | +| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | diff --git a/content/zh/docs/reference/using-api/deprecation-policy.md b/content/zh/docs/reference/using-api/deprecation-policy.md index a5fa369e96..84e2137528 100644 --- a/content/zh/docs/reference/using-api/deprecation-policy.md +++ b/content/zh/docs/reference/using-api/deprecation-policy.md @@ -39,7 +39,7 @@ Kubernetes 是一个组件众多、贡献者人数众多的大系统。 Since Kubernetes is an API-driven system, the API has evolved over time to reflect the evolving understanding of the problem space. The Kubernetes API is actually a set of APIs, called "API groups", and each API group is -independently versioned. [API versions](/docs/reference/using-api/api-overview/#api-versioning) fall +independently versioned. [API versions](/docs/reference/using-api/#api-versioning) fall into 3 main tracks, each of which has different policies for deprecation: --> ## 弃用 API 的一部分 {#deprecating-parts-of-the-api} @@ -47,7 +47,7 @@ into 3 main tracks, each of which has different policies for deprecation: 由于 Kubernetes 是一个 API 驱动的系统，API 会随着时间推移而演化，以反映 人们对问题共建的认识的变化。Kubernetes API 实际上是一个 API 集合，其中每个 成员称作“API 组（API Group）”，并且每个 API 组都是独立管理版本的。 -[API 版本](/zh/docs/reference/using-api/api-overview/#api-versioning)会有 +[API 版本](/zh/docs/reference/using-api/#api-versioning)会有 三类，每类有不同的废弃策略： -### REST 资源（也即 API 对象） +### REST 资源（也即 API 对象） {#rest-resources-aka-api-objects} 考虑一个假想的名为 Widget 的 REST 资源，在上述时间线中位于 API v1， 而现在打算将其弃用。 @@ -450,12 +450,12 @@ Starting in Kubernetes v1.19, making an API request to a deprecated REST API end 2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug-application-cluster/audit/) recorded for the request. 3. Sets an `apiserver_requested_deprecated_apis` gauge metric to `1` in the `kube-apiserver` process. The metric has labels for `group`, `version`, `resource`, `subresource` that can be joined - to the `apiserver_request_total` metric, and a `removed_version` label that indicates the + to the `apiserver_request_total` metric, and a `removed_release` label that indicates the Kubernetes release in which the API will no longer be served. The following Prometheus query returns information about requests made to deprecated APIs which will be removed in v1.22: - + ```promql - apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total + apiserver_requested_deprecated_apis{removed_release="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total ``` --> 从 Kubernetes v1.19 开始，当 API 请求被发送到一个已弃用的 REST API 末端时： @@ -468,12 +468,12 @@ Starting in Kubernetes v1.19, making an API request to a deprecated REST API end 设置为 `1`。 该度量值还附带 `group`、`version`、`resource` 和 `subresource` 标签 （可供添加到度量值 `apiserver_request_total` 上）， - 和一个 `removed_version` 标签，标明该 API 将消失的 Kubernetes 发布版本。 + 和一个 `removed_release` 标签，标明该 API 将消失的 Kubernetes 发布版本。 下面的 Prometheus 查询会返回对 v1.22 中将移除的、已弃用的 API 的请求的信息： ```promql - apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total + apiserver_requested_deprecated_apis{removed_release="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total ``` | Golang 标记 | OpenAPI extension | 可接受的值 | 描述 | 引入版本 | |---|---|---|---|---| -| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | 适用于 list。 `atomic` 和 `set` 适用于只包含标量元素的 list。 `map` 适用于只包含嵌套类型的 list。 如果配置为 `atomic`, 合并时整个列表会被替换掉; 任何时候，唯一的管理器都把列表作为一个整体来管理。如果是细粒度管理，不同的管理器也可以分开管理条目。 | 1.16 | +| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | 适用于 list。 `atomic` 和 `set` 适用于只包含标量元素的 list。 `map` 适用于只包含嵌套类型的 list。 如果配置为 `atomic`, 合并时整个列表会被替换掉; 任何时候，唯一的管理器都把列表作为一个整体来管理。如果是 `set` 或 `map` ，不同的管理器也可以分开管理条目。 | 1.16 | | `//+listMapKey` | `x-kubernetes-list-map-keys` | 用来唯一标识条目的 map keys 切片，例如 `["port", "protocol"]` | 仅当 `+listType=map` 时适用。组合值的字符串切片必须唯一标识列表中的条目。尽管有多个 key，`listMapKey` 是单数的，这是因为 key 需要在 Go 类型中单独的指定。 | 1.16 | | `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | 适用于 map。 `atomic` 指 map 只能被单个的管理器整个的替换。 `granular` 指 map 支持多个管理器各自更新自己的字段。 | 1.17 | | `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | 适用于 structs；否则就像 `//+mapType` 有相同的用法和 openapi 注释.| 1.17 | diff --git a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md index 80a470cfad..1fd7105edb 100644 --- a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -96,7 +96,7 @@ spec: command: - powershell.exe - -command - - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " + - "<#code used from https://gist.github.com/19WAS85/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " nodeSelector: kubernetes.io/os: windows ``` diff --git a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index a2aa986464..9c3e1cf6fd 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -497,7 +497,7 @@ seconds. Minimum value is 1. to 1 second. Minimum value is 1. * `successThreshold`: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for -liveness. Minimum value is 1. +liveness and startup Probes. Minimum value is 1. * `failureThreshold`: When a probe fails, Kubernetes will try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. Defaults to 3. Minimum value is 1. @@ -506,7 +506,7 @@ Defaults to 3. Minimum value is 1. * `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。 * `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。 * `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。 - 存活探测的这个值必须是 1。最小值是 1。 + 存活和启动探测的这个值必须是 1。最小值是 1。 * `failureThreshold`：当探测失败时，Kubernetes 的重试次数。 存活探测情况下的放弃就意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。 diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md index 65cdbc1841..fa96247305 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -330,7 +330,7 @@ More details about the API object can be found at 创建 HorizontalPodAutoscaler 对象时，需要确保所给的名称是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 有关 API 对象的更多信息，请查阅 -[HorizontalPodAutoscaler 对象设计文档](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)。 +[HorizontalPodAutoscaler 对象设计文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)。