diff --git a/.github/ISSUE_TEMPLATE/support.md b/.github/ISSUE_TEMPLATE/support.md index fd223c8991..cab9c54a05 100644 --- a/.github/ISSUE_TEMPLATE/support.md +++ b/.github/ISSUE_TEMPLATE/support.md @@ -11,7 +11,7 @@ STOP -- PLEASE READ! GitHub is not the right place for support requests. -If you're looking for help, check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) +If you're looking for help, check [Server Fault](https://serverfault.com/questions/tagged/kubernetes). You can also post your question on the [Kubernetes Slack](http://slack.k8s.io/) or the [Discuss Kubernetes](https://discuss.kubernetes.io/) forum. diff --git a/Makefile b/Makefile index 984c261466..57fca6e2d1 100644 --- a/Makefile +++ b/Makefile @@ -19,10 +19,10 @@ CCEND=\033[0m help: ## Show this help. @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) -module-check: +module-check: ## Check if all of the required submodules are correctly initialized. @git submodule status --recursive | awk '/^[+-]/ {err = 1; printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2} END { if (err != 0) print "You need to run \033[32mmake module-init\033[0m to initialize missing modules first"; exit err }' 1>&2 -module-init: +module-init: ## Initialize required submodules. @echo "Initializing submodules..." 1>&2 @git submodule update --init --recursive --depth 1 diff --git a/README-pl.md b/README-pl.md index 06bde04303..7544de4583 100644 --- a/README-pl.md +++ b/README-pl.md @@ -5,9 +5,9 @@ W tym repozytorium znajdziesz wszystko, czego potrzebujesz do zbudowania [strony internetowej Kubernetesa wraz z dokumentacją](https://kubernetes.io/). Bardzo nam miło, że chcesz wziąć udział w jej współtworzeniu! + [Twój wkład w dokumentację](#twój-wkład-w-dokumentację) -+ [Informacje o wersjach językowych](#informacje-o-wersjach-językowych) ++ [Informacje o wersjach językowych](#różne-wersje-językowe-readmemd) -# Jak używać tego repozytorium +## Jak używać tego repozytorium Możesz uruchomić serwis lokalnie poprzez Hugo (Extended version) lub ze środowiska kontenerowego. Zdecydowanie zalecamy korzystanie z kontenerów, bo dzięki temu lokalna wersja będzie spójna z tym, co jest na oficjalnej stronie. @@ -22,14 +22,14 @@ Aby móc skorzystać z tego repozytorium, musisz lokalnie zainstalować: Przed rozpoczęciem zainstaluj niezbędne zależności. Sklonuj repozytorium i przejdź do odpowiedniego katalogu: -``` +```bash git clone https://github.com/kubernetes/website.git cd website ``` Strona Kubernetesa używa [Docsy Hugo theme](https://github.com/google/docsy#readme). Nawet jeśli planujesz uruchomić serwis w środowisku kontenerowym, zalecamy pobranie podmodułów i innych zależności za pomocą polecenia: -``` +```bash # pull in the Docsy submodule git submodule update --init --recursive --depth 1 ``` @@ -38,14 +38,14 @@ git submodule update --init --recursive --depth 1 Aby zbudować i uruchomić serwis wewnątrz środowiska kontenerowego, wykonaj następujące polecenia: -``` +```bash make container-image make container-serve ``` Jeśli widzisz błędy, prawdopodobnie kontener z Hugo nie dysponuje wystarczającymi zasobami. Aby rozwiązać ten problem, zwiększ ilość dostępnych zasobów CPU i pamięci dla Dockera na Twojej maszynie ([MacOSX](https://docs.docker.com/docker-for-mac/#resources) i [Windows](https://docs.docker.com/docker-for-windows/#resources)). -Aby obejrzeć zawartość serwisu, otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce. +Aby obejrzeć zawartość serwisu, otwórz w przeglądarce adres . Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce. ## Jak uruchomić lokalną kopię strony przy pomocy Hugo? @@ -59,13 +59,14 @@ npm ci make serve ``` -Zostanie uruchomiony lokalny serwer Hugo na porcie 1313. Otwórz w przeglądarce adres http://localhost:1313, aby obejrzeć zawartość serwisu. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce. +Zostanie uruchomiony lokalny serwer Hugo na porcie 1313. Otwórz w przeglądarce adres , aby obejrzeć zawartość serwisu. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce. ## Budowanie dokumentacji źródłowej API Budowanie dokumentacji źródłowej API zostało opisane w [angielskiej wersji pliku README.md](README.md#building-the-api-reference-pages). ## Rozwiązywanie problemów + ### 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 Z przyczyn technicznych, Hugo jest rozprowadzany w dwóch wersjach. Aktualny serwis używa tylko wersji **Hugo Extended**. Na stronie z [wydaniami](https://github.com/gohugoio/hugo/releases) poszukaj archiwum z `extended` w nazwie. Dla potwierdzenia, uruchom `hugo version` i poszukaj słowa `extended`. @@ -74,7 +75,7 @@ Z przyczyn technicznych, Hugo jest rozprowadzany w dwóch wersjach. Aktualny ser Jeśli po uruchomieniu `make serve` na macOS widzisz następujący błąd: -``` +```bash ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files make: *** [serve] Error 1 ``` @@ -104,36 +105,36 @@ sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist ``` -Przedstawiony sposób powinien działać dla MacOS w wersji Catalina i Mojave. +Przedstawiony sposób powinien działać dla MacOS w wersjach Catalina i Mojave. - -# Zaangażowanie w prace SIG Docs +## Zaangażowanie w prace SIG Docs O społeczności SIG Docs i terminach spotkań dowiesz z [jej strony](https://github.com/kubernetes/community/tree/master/sig-docs#meetings). Możesz kontaktować się z gospodarzami projektu za pomocą: -- [Komunikatora Slack](https://kubernetes.slack.com/messages/sig-docs) [Tutaj możesz dostać zaproszenie do tej grupy Slack-a](https://slack.k8s.io/) +- [Komunikatora Slack](https://kubernetes.slack.com/messages/sig-docs) + - [Tutaj możesz dostać zaproszenie do tej grupy Slacka](https://slack.k8s.io/) - [List dyskusyjnych](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) -# Twój wkład w dokumentację +## Twój wkład w dokumentację Możesz kliknąć w przycisk **Fork** w prawym górnym rogu ekranu, aby stworzyć kopię tego repozytorium na swoim koncie GitHub. Taki rodzaj kopii (odgałęzienia) nazywa się *fork*. Zmieniaj w nim, co chcesz, a kiedy będziesz już gotowy/a przesłać te zmiany do nas, przejdź do swojej kopii i stwórz nowy *pull request*, abyśmy zostali o tym poinformowani. -Po stworzeniu *pull request*, jeden z recenzentów projektu Kubernetes podejmie się przekazania jasnych wskazówek pozwalających podjąć następne działania. Na Tobie, jako właścicielu *pull requesta*, **spoczywa odpowiedzialność za wprowadzenie poprawek zgodnie z uwagami recenzenta.** +Po stworzeniu *pull request*, jeden z recenzentów projektu Kubernetes podejmie się przekazania jasnych wskazówek pozwalających podjąć następne działania. Na Tobie, jako właścicielu *pull requesta*, **spoczywa odpowiedzialność za wprowadzenie poprawek zgodnie z uwagami recenzenta.** Może też się zdarzyć, że swoje uwagi zgłosi więcej niż jeden recenzent, lub że recenzję będzie robił ktoś inny, niż ten, kto został przydzielony na początku. -W niektórych przypadkach, jeśli zajdzie taka potrzeba, recenzent może poprosić dodatkowo o recenzję jednego z [recenzentów technicznych](https://github.com/kubernetes/website/wiki/Tech-reviewers). Recenzenci zrobią wszystko, aby odpowiedzieć sprawnie, ale konkretny czas odpowiedzi zależy od wielu czynników. +W niektórych przypadkach, jeśli zajdzie taka potrzeba, recenzent może poprosić dodatkowo o recenzję jednego z recenzentów technicznych. Recenzenci zrobią wszystko, aby odpowiedzieć sprawnie, ale konkretny czas odpowiedzi zależy od wielu czynników. Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz na stronach: -* [Udział w rozwijaniu dokumentacji](https://kubernetes.io/docs/contribute/) -* [Rodzaje 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/) +- [Udział w rozwijaniu dokumentacji](https://kubernetes.io/docs/contribute/) +- [Rodzaje stron](https://kubernetes.io/docs/contribute/style/page-content-types/) +- [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/) +- [Lokalizacja dokumentacji Kubernetesa](https://kubernetes.io/docs/contribute/localization/) -# Różne wersje językowe `README.md` +## Różne wersje językowe `README.md` | Język | Język | |---|---| @@ -145,10 +146,10 @@ Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz | [wietnamski](README-vi.md) | [rosyjski](README-ru.md) | | [włoski](README-it.md) | [ukraiński](README-uk.md) | -# Zasady postępowania +## Zasady postępowania Udział w działaniach społeczności Kubernetesa jest regulowany przez [Kodeks postępowania CNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/pl.md). -# Dziękujemy! +## Dziękujemy! Kubernetes rozkwita dzięki zaangażowaniu społeczności — doceniamy twój wkład w tworzenie naszego serwisu i dokumentacji! diff --git a/README.md b/README.md index d7691e7f0d..87dd03e7eb 100644 --- a/README.md +++ b/README.md @@ -65,9 +65,9 @@ This will start the local Hugo server on port 1313. Open up your browser to . -To update the reference pages for a new Kubernetes release (replace v1.20 in the following examples with the release to update to): +To update the reference pages for a new Kubernetes release follow these steps: -1. Pull the `kubernetes-resources-reference` submodule: +1. Pull in the `api-ref-generator` submodule: ```bash git submodule update --init --recursive --depth 1 @@ -75,9 +75,9 @@ To update the reference pages for a new Kubernetes release (replace v1.20 in the 2. Update the Swagger specification: -``` -curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json -``` + ```bash + curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json + ``` 3. In `api-ref-assets/config/`, adapt the files `toc.yaml` and `fields.yaml` to reflect the changes of the new release. diff --git a/api-ref-assets/config/fields.yaml b/api-ref-assets/config/fields.yaml index 25b0588619..1c18d231ab 100644 --- a/api-ref-assets/config/fields.yaml +++ b/api-ref-assets/config/fields.yaml @@ -50,11 +50,9 @@ - securityContext - name: Beta level fields: + - ephemeralContainers - preemptionPolicy - overhead - - name: Alpha level - fields: - - ephemeralContainers - name: Deprecated fields: - serviceAccount @@ -227,6 +225,9 @@ - stdin - stdinOnce - tty + - name: Security context + fields: + - securityContext - name: Not allowed fields: - ports @@ -234,7 +235,6 @@ - lifecycle - livenessProbe - readinessProbe - - securityContext - startupProbe - definition: io.k8s.api.core.v1.ReplicationControllerSpec diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index aefa29e1ff..82ebd232c0 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -215,10 +215,6 @@ body.td-404 main .error-details { } } -body > footer { - width: 100vw; -} - /* FOOTER */ footer { background-color: #303030; @@ -317,6 +313,12 @@ footer { padding-top: 1.5rem !important; top: 5rem !important; + @supports (position: sticky) { + position: sticky !important; + height: calc(100vh - 10rem); + overflow-y: auto; + } + #TableOfContents { padding-top: 1rem; } diff --git a/assets/scss/_reset.scss b/assets/scss/_reset.scss old mode 100755 new mode 100644 diff --git a/assets/scss/_skin.scss b/assets/scss/_skin.scss old mode 100755 new mode 100644 diff --git a/content/de/_index.html b/content/de/_index.html index fc7926ec93..7eea7bf947 100644 --- a/content/de/_index.html +++ b/content/de/_index.html @@ -42,12 +42,12 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or

- Besuche die KubeCon North America vom 11. bis 15. Oktober 2021 + Besuche die KubeCon Europe vom 16. bis 20. Mai 2022



- Besuche die KubeCon Europe vom 17. bis 20. Mai 2022 + Besuchen die KubeCon North America vom 24. bis 28. Oktober 2022
diff --git a/content/en/_index.html b/content/en/_index.html index 4615b5db0e..7557fe8f99 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -48,7 +48,7 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise


- Attend KubeCon North America on October 24-28, 2022 + Attend KubeCon North America on October 24-28, 2022
diff --git a/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md b/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md index 19d79d3f44..a361c4d0be 100644 --- a/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md +++ b/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md @@ -190,7 +190,8 @@ kubectl get configmap No resources found in default namespace. ``` -To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=orphan option for `kubectl delete` to delete an object and orphan its children. +To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=orphan option for `kubectl delete` to delete an object and orphan its children. *Update: starting with kubectl v1.20, the default for cascade is `background`.* + In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=orphan, the parent is deleted but the child still exists: diff --git a/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md index cd65d69f8b..624075fb4e 100644 --- a/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md +++ b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md @@ -138,4 +138,5 @@ Stay tuned for what comes next, and if you have any questions, comments or sugge * Chat with us on the Kubernetes [Slack](http://slack.k8s.io/):[#cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) * Join the SIG Cluster Lifecycle [Google Group](https://groups.google.com/g/kubernetes-sig-cluster-lifecycle) to receive calendar invites and gain access to documents * Join our [Zoom meeting](https://zoom.us/j/861487554), every Wednesday at 10:00 Pacific Time -* Check out the [ClusterClass tutorial](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-classes.html) in the Cluster API book. \ No newline at end of file +* Check out the [ClusterClass quick-start](https://cluster-api.sigs.k8s.io/user/quick-start.html) for the Docker provider (CAPD) in the Cluster API book. +* _UPDATE_: Check out the [ClusterClass experimental feature](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-class/index.html) documentation in the Cluster API book. diff --git a/content/en/blog/_posts/2021-12-21-admission-controllers-for-container-drift/index.md b/content/en/blog/_posts/2021-12-21-admission-controllers-for-container-drift/index.md index fda7be0401..977a65c147 100644 --- a/content/en/blog/_posts/2021-12-21-admission-controllers-for-container-drift/index.md +++ b/content/en/blog/_posts/2021-12-21-admission-controllers-for-container-drift/index.md @@ -67,8 +67,11 @@ As you can see in the above event messages, the affected Pod is not evicted imme For our production clusters, we specify a lower time limit so as to avoid the impacted Pods serving traffic abidingly. The *kube-exec-controller* internally sets and tracks a timer for each Pod that matches the associated TTL. Once the timer is up, the controller evicts that Pod using K8s API. The eviction (rather than deletion) is to ensure service availability, since the cluster respects any configured [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB). Let's say if a user has defined *x* number of Pods as critical in their PDB, the eviction (as requested by *kube-exec-controller*) does not continue when the target workload has fewer than *x* Pods running. -Here comes a sequence diagram of the entire workflow mentioned above:  -{{< figure src="workflow-diagram.svg" alt="Workflow Diagram" class="diagram-medium" >}} +Here comes a sequence diagram of the entire workflow mentioned above: + + + +![Sequence Diagram](/images/sequence_diagram.svg) ## A new kubectl plugin for better user experience Our admission controller component works great for solving the container drift issue we had on the platform. It is also able to submit all related Events to the target Pod that has been affected. However, K8s clusters don't retain Events very long (the default retention period is one hour). We need to provide other ways for developers to get their Pod interaction activity. A [kubectl plugin](/docs/tasks/extend-kubectl/kubectl-plugins/) is a perfect choice for us to expose this information. We named our plugin `kubectl pi` (short for `pod-interaction`) and provide two subcommands: `get` and `extend`. diff --git a/content/en/blog/_posts/2022-02-07-sig-multicluster-spotlight/index.md b/content/en/blog/_posts/2022-02-07-sig-multicluster-spotlight/index.md new file mode 100644 index 0000000000..4f155ed54d --- /dev/null +++ b/content/en/blog/_posts/2022-02-07-sig-multicluster-spotlight/index.md @@ -0,0 +1,63 @@ +--- +layout: blog +title: "Spotlight on SIG Multicluster" +date: 2022-02-07 +slug: sig-multicluster-spotlight-2022 +canonicalUrl: https://www.kubernetes.dev/blog/2022/02/04/sig-multicluster-spotlight-2022/ +--- + +**Authors:** Dewan Ahmed (Aiven) and Chris Short (AWS) + +## Introduction + +[SIG Multicluster](https://github.com/kubernetes/community/tree/master/sig-multicluster) is the SIG focused on how Kubernetes concepts are expanded and used beyond the cluster boundary. Historically, Kubernetes resources only interacted within that boundary - KRU or Kubernetes Resource Universe (not an actual Kubernetes concept). Kubernetes clusters, even now, don't really know anything about themselves or, about other clusters. Absence of cluster identifiers is a case in point. With the growing adoption of multicloud and multicluster deployments, the work SIG Multicluster doing is gaining a lot of attention. In this blog, [Jeremy Olmsted-Thompson, Google](https://twitter.com/jeremyot) and [Chris Short, AWS](https://twitter.com/ChrisShort) discuss the interesting problems SIG Multicluster is solving and how you can get involved. Their initials **JOT** and **CS** will be used for brevity. + +## A summary of their conversation + +**CS**: How long has the SIG Multicluster existed and how was the SIG in its infancy? How long have you been with this SIG? + +**JOT**: I've been around for almost two years in the SIG Multicluster. All I know about the infancy years is from the lore but even in the early days, it was always about solving this same problem. Early efforts have been things like [KubeFed](https://github.com/kubernetes-sigs/kubefed). I think there are still folks using KubeFed but it's a smaller slice. Back then, I think people out there deploying large numbers of Kubernetes clusters were really not at a point where we had a ton of real concrete use cases. Projects like KubeFed and [Cluster Registry](https://github.com/kubernetes-retired/cluster-registry) were developed around that time and the need back then can be associated to these projects. The motivation for these projects were how do we solve the problems that we think people are **going to have**, when they start expanding to multiple clusters. Honestly, in some ways, it was trying to do too much at that time. + +**CS**: How does KubeFed differ from the current state of SIG Multicluster? How does the **lore** differ from the **now**? + +**JOT**: Yeah, it was like trying to get ahead of potential problems instead of addressing specific problems. I think towards the end of 2019, there was a slow down in SIG multicluster work and we kind of picked it back up with one of the most active recent projects that is the [SIG Multicluster services (MCS)](https://github.com/kubernetes-sigs/mcs-api). + +Now this is the shift to solving real specific problems. For example, + +> I've got workloads that are spread across multiple clusters and I need them to talk to each other. + +Okay, that's very straightforward and we know that we need to solve that. To get started, let's make sure that these projects can work together on a common API so you get the same kind of portability that you get with Kubernetes. + +There's a few implementations of the MCS API out there and more are being developed. But, we didn't build an implementation because depending on how you're deploying things there could be hundreds of implementations. As long as you only need the basic Multicluster service functionality, it'll just work on whatever background you want, whether it's Submariner, GKE, or a service mesh. + +My favorite example of "then vs. now" is cluster ID. A few years ago, there was an effort to define a cluster ID. A lot of really good thought went into this concept, for example, how do we make a cluster ID is unique across multiple clusters. How do we make this ID globally unique so it'll work in every contact? Let's say, there's an acquisition or merger of teams - does the cluster IDs still remain unique for those teams? + +With Multicluster services, we found the need for an actual cluster ID, and it has a very specific need. To address this specific need, we're no longer considering every single Kubernetes cluster out there rather the ClusterSets - a grouping of clusters that work together in some kind of bounds. That's a much narrower scope than considering clusters everywhere in time and space. It also leaves flexibility for an implementer to define the boundary (a ClusterSet) beyond which this cluster ID will no longer be unique. + + +**CS**: How do you feel about the current state of SIG Multicluster versus where you're hoping to be in future? + +**JOT**: There's a few projects that are kind of getting started, for example, Work API. In the future, I think that some common practices around how do we deploy things across clusters are going to develop. +> If I have clusters deployed in a bunch of different regions; what's the best way to actually do that? + +The answer is, almost always, "it depends". Why are you doing this? Is it because there's some kind of compliance that makes you care about locality? Is it performance? Is it availability? + +I think revisiting registry patterns will probably be a natural step after we have cluster IDs, that is, how do you actually associate these clusters together? Maybe you've got a distributed deployment that you run in your own data centers all over the world. I imagine that expanding the API in that space is going to be important as more multi cluster features develop. It really depends on what the community starts doing with these tools. + +**CS**: In the early days of Kubernetes, we used to have a few large Kubernetes clusters and now we're dealing with many small Kubernetes clusters - even multiple clusters for our own dev environments. How has this shift from a few large clusters to many small clusters affected the SIG? Has it accelerated the work or make it challenging in any way? + +**JOT**: I think that it has created a lot of ambiguity that needs solving. Originally, you'd have a dev cluster, a staging cluster, and a prod cluster. When the multi region thing came in, we started needing dev/staging/prod clusters, per region. And then, sometimes clusters really need more isolation due to compliance or some regulations issues. Thus, we're ending up with a lot of clusters. I think figuring out the right balance on how many clusters should you actually have is important. The power of Kubernetes is being able to deploy a lot of things managed by a single control plane. So, it's not like every single workload that gets deployed should be in its own cluster. But I think it's pretty clear that we can't put every single workload in a single cluster. + +**CS**: What are some of your favorite things about this SIG? + +**JOT**: The complexity of the problems, the people and the newness of the space. We don't have right answers and we have to figure this out. At the beginning, we couldn't even think about multi clusters because there was no way to connect services across clusters. Now there is and we're starting to go tackle those problems, I think that this is a really fun place to be in because I expect that the SIG is going to get a lot busier the next couple of years. It's a very collaborative group and we definitely would like more people to come join us, get involved, raise their problems and bring their ideas. + +**CS**: What do you think keeps people in this group? How has the pandemic affected you? + +**JOT**: I think it definitely got a little bit quieter during the pandemic. But for the most part; it's a very distributed group so whether you're calling in to our weekly meetings from a conference room or from your home, it doesn't make that huge of a difference. During the pandemic, a lot of people had time to focus on what's next for their scale and growth. I think that's what keeps people in the group - we have real problems that need to be solved which are very new in this space. And it's fun :) + +## Wrap up + +**CS**: That's all we have for today. Thanks Jeremy for your time. + +**JOT**: Thanks Chris. Everybody is welcome at our [bi-weekly meetings](https://github.com/kubernetes/community/tree/master/sig-multicluster#meetings). We love as many people to come as possible and welcome all questions and all ideas. It's a new space and it'd be great to grow the community. \ No newline at end of file diff --git a/content/en/case-studies/peardeck/index.html b/content/en/case-studies/peardeck/index.html index 4398277677..77d94873fd 100644 --- a/content/en/case-studies/peardeck/index.html +++ b/content/en/case-studies/peardeck/index.html @@ -20,7 +20,7 @@ case_study_details:

Solution

-

In 2016, the company began moving their code from Heroku to Docker containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

+

In 2016, the company began moving their code from Heroku to containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

Impact

@@ -42,7 +42,7 @@ With the speed befitting a startup, Pear Deck delivered its first prototype to c

On top of that, many of Pear Deck's customers are behind government firewalls and connect through Firebase, not Pear Deck's servers, making troubleshooting even more difficult.

-

The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to Docker containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

+

The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

{{< case-studies/quote image="/images/case-studies/peardeck/banner1.jpg" >}} "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. diff --git a/content/en/case-studies/prowise/index.html b/content/en/case-studies/prowise/index.html index b8b584aa41..8e2a89c385 100644 --- a/content/en/case-studies/prowise/index.html +++ b/content/en/case-studies/prowise/index.html @@ -70,7 +70,7 @@ If you haven't set foot in a school in awhile, you might be surprised by what yo

Recently, the team launched a new single sign-on solution for use in an internal application. "Due to the resource based architecture of the Kubernetes platform, we were able to bring that application into an entirely new production environment in less than a day, most of that time used for testing after applying the already well-known resource definitions from staging to the new environment," says van den Bosch. "On a traditional VM this would have likely cost a day or two, and then probably a few weeks to iron out the kinks in our provisioning scripts as we apply updates."

-

Legacy applications are also being moved to Kubernetes. Not long ago, the team needed to set up a Java-based application for compiling and running a frontend. "On a traditional VM, it would have taken quite a bit of time to set it up and keep it up to date, not to mention maintenance for that setup down the line," says van den Bosch. Instead, it took less than half a day to Dockerize it and get it running on Kubernetes. "It was much easier, and we were able to save costs too because we didn't have to spin up new VMs specially for it."

+

Legacy applications are also being moved to Kubernetes. Not long ago, the team needed to set up a Java-based application for compiling and running a frontend. "On a traditional VM, it would have taken quite a bit of time to set it up and keep it up to date, not to mention maintenance for that setup down the line," says van den Bosch. Instead, it took less than half a day to containerize it and get it running on Kubernetes. "It was much easier, and we were able to save costs too because we didn't have to spin up new VMs specially for it."

{{< case-studies/quote author="VICTOR VAN DEN BOSCH, SENIOR DEVOPS ENGINEER, PROWISE" >}} "We're really trying to deliver integrated solutions with our hardware and software and making it as easy as possible for users to use and collaborate from different places," says van den Bosch. And, says Haalstra, "We cannot do it without Kubernetes." diff --git a/content/en/case-studies/squarespace/index.html b/content/en/case-studies/squarespace/index.html index 461e466d8c..d39ce0b6f6 100644 --- a/content/en/case-studies/squarespace/index.html +++ b/content/en/case-studies/squarespace/index.html @@ -46,7 +46,7 @@ Since it was started in a dorm room in 2003, Squarespace has made it simple for After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." {{< /case-studies/quote >}} -

Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects Prometheus and fluentd to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Docker file, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."

+

Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects Prometheus and fluentd to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Dockerfile, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."

And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. "From end to end that probably took half an hour, and that's not accounting for the fact that an infrastructure engineer would be responsible for doing that, so there's some business delay in there as well."

diff --git a/content/en/case-studies/wink/index.html b/content/en/case-studies/wink/index.html index 1f8ea4c89d..7b5a3f8541 100644 --- a/content/en/case-studies/wink/index.html +++ b/content/en/case-studies/wink/index.html @@ -58,9 +58,9 @@ How many people does it take to turn on a light bulb?

In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service," says Klein. "We've always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker."

-

At the time – just over two years ago – Docker wasn't yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn't really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads."

+

In 2015, Docker wasn't yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn't really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads."

-

Once Wink's backend engineering team decided on a Dockerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."

+

Once Wink's backend engineering team decided on a containerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."

{{< case-studies/quote image="/images/case-studies/wink/banner4.jpg" >}} "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure." @@ -68,7 +68,7 @@ How many people does it take to turn on a light bulb?

Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed," he says. "We didn't have to futz around with trying to take something like a Linux distro and install everything. It's got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It's not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed."

-

Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.

+

Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the containerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.

Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn't take care of routing, sharing configurations, secrets, et cetera, among instances of a service," Klein says. "All of those layers of functionality can be implemented, of course, but if you don't want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did."

diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 1ea3b4cf7b..9e8f2a7923 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -42,21 +42,21 @@ Fairness feature enabled. ## Enabling/Disabling API Priority and Fairness The API Priority and Fairness feature is controlled by a feature gate -and is enabled by default. See -[Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/) +and is enabled by default. See [Feature +Gates](/docs/reference/command-line-tools-reference/feature-gates/) for a general explanation of feature gates and how to enable and disable them. The name of the feature gate for APF is "APIPriorityAndFairness". This feature also involves an {{< glossary_tooltip term_id="api-group" text="API Group" >}} with: (a) a -`v1alpha1` version, disabled by default, and (b) a `v1beta1` -version, enabled by default. You can disable the feature -gate and API group v1beta1 version by adding the following +`v1alpha1` version, disabled by default, and (b) `v1beta1` and +`v1beta2` versions, enabled by default. You can disable the feature +gate and API group beta versions by adding the following command-line flags to your `kube-apiserver` invocation: ```shell kube-apiserver \ --feature-gates=APIPriorityAndFairness=false \ ---runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=false \ +--runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=false,flowcontrol.apiserver.k8s.io/v1beta2=false \ # …and other flags as usual ``` @@ -127,86 +127,13 @@ any of the limitations imposed by this feature. These exemptions prevent an improperly-configured flow control configuration from totally disabling an API server. -## Defaults - -The Priority and Fairness feature ships with a suggested configuration that -should suffice for experimentation; if your cluster is likely to -experience heavy load then you should consider what configuration will work -best. The suggested configuration groups requests into five priority -classes: - -* The `system` priority level is for requests from the `system:nodes` group, - i.e. Kubelets, which must be able to contact the API server in order for - workloads to be able to schedule on them. - -* The `leader-election` priority level is for leader election requests from - built-in controllers (in particular, requests for `endpoints`, `configmaps`, - or `leases` coming from the `system:kube-controller-manager` or - `system:kube-scheduler` users and service accounts in the `kube-system` - namespace). These are important to isolate from other traffic because failures - in leader election cause their controllers to fail and restart, which in turn - causes more expensive traffic as the new controllers sync their informers. - -* The `workload-high` priority level is for other requests from built-in - controllers. - -* The `workload-low` priority level is for requests from any other service - account, which will typically include all requests from controllers running in - Pods. - -* The `global-default` priority level handles all other traffic, e.g. - interactive `kubectl` commands run by nonprivileged users. - -Additionally, there are two PriorityLevelConfigurations and two FlowSchemas that -are built in and may not be overwritten: - -* The special `exempt` priority level is used for requests that are not subject - to flow control at all: they will always be dispatched immediately. The - special `exempt` FlowSchema classifies all requests from the `system:masters` - group into this priority level. You may define other FlowSchemas that direct - other requests to this priority level, if appropriate. - -* The special `catch-all` priority level is used in combination with the special - `catch-all` FlowSchema to make sure that every request gets some kind of - classification. Typically you should not rely on this catch-all configuration, - and should create your own catch-all FlowSchema and PriorityLevelConfiguration - (or use the `global-default` configuration that is installed by default) as - appropriate. To help catch configuration errors that miss classifying some - requests, the mandatory `catch-all` priority level only allows one concurrency - share and does not queue requests, making it relatively likely that traffic - that only matches the `catch-all` FlowSchema will be rejected with an HTTP 429 - error. - -## Health check concurrency exemption - -The suggested configuration gives no special treatment to the health -check requests on kube-apiservers from their local kubelets --- which -tend to use the secured port but supply no credentials. With the -suggested config, these requests get assigned to the `global-default` -FlowSchema and the corresponding `global-default` priority level, -where other traffic can crowd them out. - -If you add the following additional FlowSchema, this exempts those -requests from rate limiting. - -{{< caution >}} -Making this change also allows any hostile party to then send -health-check requests that match this FlowSchema, at any volume they -like. If you have a web traffic filter or similar external security -mechanism to protect your cluster's API server from general internet -traffic, you can configure rules to block any health check requests -that originate from outside your cluster. -{{< /caution >}} - -{{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}} - ## Resources The flow control API involves two kinds of resources. -[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1beta1-flowcontrol-apiserver-k8s-io) +[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1beta2-flowcontrol-apiserver-k8s-io) define the available isolation classes, the share of the available concurrency budget that each can handle, and allow for fine-tuning queuing behavior. -[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1beta1-flowcontrol-apiserver-k8s-io) +[FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1beta2-flowcontrol-apiserver-k8s-io) are used to classify individual inbound requests, matching each to a single PriorityLevelConfiguration. There is also a `v1alpha1` version of the same API group, and it has the same Kinds with the same syntax and @@ -329,6 +256,153 @@ omitted entirely), in which case all requests matched by this FlowSchema will be considered part of a single flow. The correct choice for a given FlowSchema depends on the resource and your particular environment. +## Defaults + +Each kube-apiserver maintains two sorts of APF configuration objects: +mandatory and suggested. + +### Mandatory Configuration Objects + +The four mandatory configuration objects reflect fixed built-in +guardrail behavior. This is behavior that the servers have before +those objects exist, and when those objects exist their specs reflect +this behavior. The four mandatory objects are as follows. + +* The mandatory `exempt` priority level is used for requests that are + not subject to flow control at all: they will always be dispatched + immediately. The mandatory `exempt` FlowSchema classifies all + requests from the `system:masters` group into this priority + level. You may define other FlowSchemas that direct other requests + to this priority level, if appropriate. + +* The mandatory `catch-all` priority level is used in combination with + the mandatory `catch-all` FlowSchema to make sure that every request + gets some kind of classification. Typically you should not rely on + this catch-all configuration, and should create your own catch-all + FlowSchema and PriorityLevelConfiguration (or use the suggested + `global-default` priority level that is installed by default) as + appropriate. Because it is not expected to be used normally, the + mandatory `catch-all` priority level has a very small concurrency + share and does not queue requests. + +### Suggested Configuration Objects + +The suggested FlowSchemas and PriorityLevelConfigurations constitute a +reasonable default configuration. You can modify these and/or create +additional configuration objects if you want. If your cluster is +likely to experience heavy load then you should consider what +configuration will work best. + +The suggested configuration groups requests into six priority levels: + +* The `node-high` priority level is for health updates from nodes. + +* The `system` priority level is for non-health requests from the + `system:nodes` group, i.e. Kubelets, which must be able to contact + the API server in order for workloads to be able to schedule on + them. + +* The `leader-election` priority level is for leader election requests from + built-in controllers (in particular, requests for `endpoints`, `configmaps`, + or `leases` coming from the `system:kube-controller-manager` or + `system:kube-scheduler` users and service accounts in the `kube-system` + namespace). These are important to isolate from other traffic because failures + in leader election cause their controllers to fail and restart, which in turn + causes more expensive traffic as the new controllers sync their informers. + +* The `workload-high` priority level is for other requests from built-in + controllers. + +* The `workload-low` priority level is for requests from any other service + account, which will typically include all requests from controllers running in + Pods. + +* The `global-default` priority level handles all other traffic, e.g. + interactive `kubectl` commands run by nonprivileged users. + +The suggested FlowSchemas serve to steer requests into the above +priority levels, and are not enumerated here. + +### Maintenance of the Mandatory and Suggested Configuration Objects + +Each `kube-apiserver` independently maintains the mandatory and +suggested configuration objects, using initial and periodic behavior. +Thus, in a situation with a mixture of servers of different versions +there may be thrashing as long as different servers have different +opinions of the proper content of these objects. + +Each `kube-apiserver` makes an inital maintenance pass over the +mandatory and suggested configuration objects, and after that does +periodic maintenance (once per minute) of those objects. + +For the mandatory configuration objects, maintenance consists of +ensuring that the object exists and, if it does, has the proper spec. +The server refuses to allow a creation or update with a spec that is +inconsistent with the server's guardrail behavior. + +Maintenance of suggested configuration objects is designed to allow +their specs to be overridden. Deletion, on the other hand, is not +respected: maintenance will restore the object. If you do not want a +suggested configuration object then you need to keep it around but set +its spec to have minimal consequences. Maintenance of suggested +objects is also designed to support automatic migration when a new +version of the `kube-apiserver` is rolled out, albeit potentially with +thrashing while there is a mixed population of servers. + +Maintenance of a suggested configuration object consists of creating +it --- with the server's suggested spec --- if the object does not +exist. OTOH, if the object already exists, maintenance behavior +depends on whether the `kube-apiservers` or the users control the +object. In the former case, the server ensures that the object's spec +is what the server suggests; in the latter case, the spec is left +alone. + +The question of who controls the object is answered by first looking +for an annotation with key `apf.kubernetes.io/autoupdate-spec`. If +there is such an annotation and its value is `true` then the +kube-apiservers control the object. If there is such an annotation +and its value is `false` then the users control the object. If +neither of those condtions holds then the `metadata.generation` of the +object is consulted. If that is 1 then the kube-apiservers control +the object. Otherwise the users control the object. These rules were +introduced in release 1.22 and their consideration of +`metadata.generation` is for the sake of migration from the simpler +earlier behavior. Users who wish to control a suggested configuration +object should set its `apf.kubernetes.io/autoupdate-spec` annotation +to `false`. + +Maintenance of a mandatory or suggested configuration object also +includes ensuring that it has an `apf.kubernetes.io/autoupdate-spec` +annotation that accurately reflects whether the kube-apiservers +control the object. + +Maintenance also includes deleting objects that are neither mandatory +nor suggested but are annotated +`apf.kubernetes.io/autoupdate-spec=true`. + +## Health check concurrency exemption + +The suggested configuration gives no special treatment to the health +check requests on kube-apiservers from their local kubelets --- which +tend to use the secured port but supply no credentials. With the +suggested config, these requests get assigned to the `global-default` +FlowSchema and the corresponding `global-default` priority level, +where other traffic can crowd them out. + +If you add the following additional FlowSchema, this exempts those +requests from rate limiting. + +{{< caution >}} +Making this change also allows any hostile party to then send +health-check requests that match this FlowSchema, at any volume they +like. If you have a web traffic filter or similar external security +mechanism to protect your cluster's API server from general internet +traffic, you can configure rules to block any health check requests +that originate from outside your cluster. +{{< /caution >}} + +{{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}} + ## Diagnostics Every HTTP response from an API server with the priority and fairness feature diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index 1bf057f23e..fb2d37ed58 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -12,7 +12,9 @@ weight: 60 Application logs can help you understand what is happening inside your application. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism. Likewise, container engines are designed to support logging. The easiest and most adopted logging method for containerized applications is writing to standard output and standard error streams. However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. -For example, you may want access your application's logs if a container crashes; a pod gets evicted; or a node dies. + +For example, you may want to access your application's logs if a container crashes, a pod gets evicted, or a node dies. + In a cluster, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level logging_. @@ -141,7 +143,7 @@ as a `DaemonSet`. Node-level logging creates only one agent per node and doesn't require any changes to the applications running on the node. -Containers write stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation. +Containers write to stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation. ### Using a sidecar container with the logging agent {#sidecar-container-with-logging-agent} diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index 6d90ed5fff..181dd4c6cb 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -709,13 +709,13 @@ Allocated resources: 680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%) ``` -In the preceding output, you can see that if a Pod requests more than 1.120 CPUs, +In the preceding output, you can see that if a Pod requests more than 1.120 CPUs or more than 6.23Gi of memory, that Pod will not fit on the node. By looking at the “Pods” section, you can see which Pods are taking up space on the node. -The amount of resources available to Pods is less than the node capacity, because +The amount of resources available to Pods is less than the node capacity because system daemons use a portion of the available resources. Within the Kubernetes API, each Node has a `.status.allocatable` field (see [NodeStatus](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeStatus) @@ -736,7 +736,7 @@ prevent one team from using so much of any resource that this over-use affects o You should also consider what access you grant to that namespace: **full** write access to a namespace allows someone with that access to remove any -resource, include a configured ResourceQuota. +resource, including a configured ResourceQuota. ### My container is terminated diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index 3c4c153927..f773178b54 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -35,13 +35,12 @@ The Pod name and namespace are available as environment variables through the [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/). User defined environment variables from the Pod definition are also available to the Container, -as are any environment variables specified statically in the Docker image. +as are any environment variables specified statically in the container image. ### Cluster information A list of all services that were running when a Container was created is available to that Container as environment variables. This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services. -Those environment variables match the syntax of Docker links. For a service named *foo* that maps to a Container named *bar*, the following variables are defined: diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md index 78c0a43b99..cb953eecbc 100644 --- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md @@ -105,22 +105,22 @@ The logs for a Hook handler are not exposed in Pod events. If a handler fails for some reason, it broadcasts an event. For `PostStart`, this is the `FailedPostStartHook` event, and for `PreStop`, this is the `FailedPreStopHook` event. -You can see these events by running `kubectl describe pod `. -Here is some example output of events from running this command: +To generate a failed `FailedPreStopHook` event yourself, modify the [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) file to change the postStart command to "badcommand" and apply it. +Here is some example output of the resulting events you see from running `kubectl describe pod lifecycle-demo`: ``` Events: - FirstSeen LastSeen Count From SubObjectPath Type Reason Message - --------- -------- ----- ---- ------------- -------- ------ ------- - 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd - 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" - 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] - 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" - 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 - 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 - 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 - 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" - 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2... + Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms + Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx" + Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container + Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container + Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n" + Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook + Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms + Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container ``` diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index 96858d32af..849cd98782 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -109,6 +109,11 @@ For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/ #### dockershim +{{< feature-state for_k8s_version="v1.20" state="deprecated" >}} + +Dockershim is deprecated as of Kubernetes v1.20, and will be removed in v1.24. For more information on the deprecation, +see [dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) + RuntimeClasses with dockershim must set the runtime handler to `docker`. Dockershim does not support custom configurable runtime handlers. diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 234327094e..77998a74c4 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -101,6 +101,21 @@ across namespaces, you need to use the fully qualified domain name (FQDN). As a result, all namespace names must be valid [RFC 1123 DNS labels](/docs/concepts/overview/working-with-objects/names/#dns-label-names). +{{< warning >}} +By creating namespaces with the same name as [public top-level +domains](https://data.iana.org/TLD/tlds-alpha-by-domain.txt), Services in these +namespaces can have short DNS names that overlap with public DNS records. +Workloads from any namespace performing a DNS lookup without a [trailing dot](https://datatracker.ietf.org/doc/html/rfc1034#page-8) will +be redirected to those services, taking precedence over public DNS. + +To mitigate this, limit privileges for creating namespaces to trusted users. If +required, you could additionally configure third-party security controls, such +as [admission +webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/), +to block creating any namespace with the name of [public +TLDs](https://data.iana.org/TLD/tlds-alpha-by-domain.txt). +{{< /warning >}} + ## Not All Objects are in a Namespace Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index 36172faba5..34ea1ecf3f 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -11,7 +11,8 @@ weight: 30 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}} -PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. For more information on the deprecation, +PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. It has been replaced by +[Pod Security Admission](/docs/concepts/security/pod-security-admission/). For more information on the deprecation, see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). Pod Security Policies enable fine-grained authorization of pod creation and diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md index 205d4ddc8e..73341e4c71 100644 --- a/content/en/docs/concepts/security/pod-security-standards.md +++ b/content/en/docs/concepts/security/pod-security-standards.md @@ -305,34 +305,22 @@ fail validation. Volume Types -

In addition to restricting HostPath volumes, the restricted policy limits usage of non-core volume types to those defined through PersistentVolumes.

+

The restricted policy only permits the following volume types.

Restricted Fields

    -
  • spec.volumes[*].hostPath
    • -
  • spec.volumes[*].gcePersistentDisk
    • -
  • spec.volumes[*].awsElasticBlockStore
    • -
  • spec.volumes[*].gitRepo
    • -
  • spec.volumes[*].nfs
    • -
  • spec.volumes[*].iscsi
    • -
  • spec.volumes[*].glusterfs
    • -
  • spec.volumes[*].rbd
    • -
  • spec.volumes[*].flexVolume
    • -
  • spec.volumes[*].cinder
    • -
  • spec.volumes[*].cephfs
    • -
  • spec.volumes[*].flocker
    • -
  • spec.volumes[*].fc
    • -
  • spec.volumes[*].azureFile
    • -
  • spec.volumes[*].vsphereVolume
    • -
  • spec.volumes[*].quobyte
    • -
  • spec.volumes[*].azureDisk
    • -
  • spec.volumes[*].portworxVolume
    • -
  • spec.volumes[*].scaleIO
    • -
  • spec.volumes[*].storageos
    • -
  • spec.volumes[*].photonPersistentDisk
    • +
  • spec.volumes[*]

Allowed Values

+ Every item in the spec.volumes[*] list must set one of the following fields to a non-null value:
    -
  • Undefined/nil
    • +
  • spec.volumes[*].configMap
    • +
  • spec.volumes[*].csi
    • +
  • spec.volumes[*].downwardAPI
    • +
  • spec.volumes[*].emptyDir
    • +
  • spec.volumes[*].ephemeral
    • +
  • spec.volumes[*].persistentVolumeClaim
    • +
  • spec.volumes[*].projected
    • +
  • spec.volumes[*].secret
@@ -391,26 +379,6 @@ fail validation. - - Non-root groups (optional) - -

Containers should be forbidden from running with a root primary or supplementary GID.

-

Restricted Fields

-
    -
  • spec.securityContext.runAsGroup
    • -
  • spec.securityContext.supplementalGroups[*]
    • -
  • spec.securityContext.fsGroup
    • -
  • spec.containers[*].securityContext.runAsGroup
    • -
  • spec.initContainers[*].securityContext.runAsGroup
    • -
  • spec.ephemeralContainers[*].securityContext.runAsGroup
    • -
-

Allowed Values

-
    -
  • Undefined/nil (except for *.runAsGroup)
    • -
  • Non-zero
    • -
- - Seccomp (v1.19+) diff --git a/content/en/docs/concepts/services-networking/connect-applications-service.md b/content/en/docs/concepts/services-networking/connect-applications-service.md index 07bab7965b..4aa4c4d29b 100644 --- a/content/en/docs/concepts/services-networking/connect-applications-service.md +++ b/content/en/docs/concepts/services-networking/connect-applications-service.md @@ -13,11 +13,9 @@ weight: 30 ## The Kubernetes model for connecting containers -Now that you have a continuously running, replicated application you can expose it on a network. Before discussing the Kubernetes approach to networking, it is worthwhile to contrast it with the "normal" way networking works with Docker. +Now that you have a continuously running, replicated application you can expose it on a network. -By default, Docker uses host-private networking, so containers can talk to other containers only if they are on the same machine. In order for Docker containers to communicate across nodes, there must be allocated ports on the machine's own IP address, which are then forwarded or proxied to the containers. This obviously means that containers must either coordinate which ports they use very carefully or ports must be allocated dynamically. - -Coordinating port allocations across multiple developers or teams that provide containers is very difficult to do at scale, and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model. +Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model. This guide uses a simple nginx server to demonstrate proof of concept. @@ -52,7 +50,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP podIP: 10.244.2.5 ``` -You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interfaces, but the need for this is radically diminished because of the networking model. +You should be able to ssh into any node in your cluster and use a tool such as `curl` to make queries against both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same `containerPort`, and access them from any other pod or node in your cluster using the assigned IP address for the Service. If you want to arrange for a specific port on the host Node to be forwarded to backing Pods, you can - but the networking model should mean that you do not need to do so. You can read more about the [Kubernetes Networking Model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) if you're curious. diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index aea058c7e1..4e55d8a3f4 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -106,10 +106,9 @@ and the domain name for your cluster is `cluster.local`, then the Pod has a DNS `172-17-0-3.default.pod.cluster.local`. -Any pods created by a Deployment or DaemonSet exposed by a Service have the -following DNS resolution available: +Any pods exposed by a Service have the following DNS resolution available: -`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`. +`pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`. ### Pod's hostname and subdomain fields diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md index 3186b56748..08b715ac7b 100644 --- a/content/en/docs/concepts/services-networking/ingress-controllers.md +++ b/content/en/docs/concepts/services-networking/ingress-controllers.md @@ -48,6 +48,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet is an ingress controller driving [Kong Gateway](https://konghq.com/kong/). * The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/) works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy). +* The [Pomerium Ingress Controller](https://www.pomerium.com/docs/k8s/ingress.html) is based on [Pomerium](https://pomerium.com/), which offers context-aware access policy. * [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. diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index a543ce1e0c..fa07048b52 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -485,9 +485,7 @@ web traffic to the IP address of your Ingress controller can be matched without virtual host being required. For example, the following Ingress routes traffic -requested for `first.bar.com` to `service1`, `second.bar.com` to `service2`, and any traffic -to the IP address without a hostname defined in request (that is, without a request header being -presented) to `service3`. +requested for `first.bar.com` to `service1`, `second.bar.com` to `service2`, and any traffic whose request host header doesn't match `first.bar.com` and `second.bar.com` to `service3`. {{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}} diff --git a/content/en/docs/concepts/services-networking/service-traffic-policy.md b/content/en/docs/concepts/services-networking/service-traffic-policy.md index 0a62cb4934..b7a367a4b7 100644 --- a/content/en/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/en/docs/concepts/services-networking/service-traffic-policy.md @@ -9,7 +9,7 @@ weight: 45 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.23" state="beta" >}} _Service Internal Traffic Policy_ enables internal traffic restrictions to only route internal traffic to endpoints within the node the traffic originated from. The @@ -20,9 +20,9 @@ cluster. This can help to reduce costs and improve performance. ## Using Service Internal Traffic Policy -Once you have enabled the `ServiceInternalTrafficPolicy` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), -you can enable an internal-only traffic policy for a +The `ServiceInternalTrafficPolicy` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +is a Beta feature and enabled by default. +When the feature is enabled, you can enable the internal-only traffic policy for a {{< glossary_tooltip text="Services" term_id="service" >}}, by setting its `.spec.internalTrafficPolicy` to `Local`. This tells kube-proxy to only use node local endpoints for cluster internal traffic. diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 81e25d17ef..0298854137 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -450,10 +450,7 @@ variables and DNS. ### Environment variables When a Pod is run on a Node, the kubelet adds a set of environment variables -for each active Service. It supports both [Docker links -compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) -and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, -where the Service name is upper-cased and dashes are converted to underscores. +for each active Service. It adds `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, where the Service name is upper-cased and dashes are converted to underscores. It also supports variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) that are compatible with Docker Engine's "_[legacy container links](https://docs.docker.com/network/links/)_" feature. For example, the Service `redis-master` which exposes TCP port 6379 and has been allocated cluster IP address 10.0.0.11, produces the following environment @@ -687,21 +684,28 @@ The set of protocols that can be used for LoadBalancer type of Services is still #### Disabling load balancer NodePort allocation {#load-balancer-nodeport-allocation} -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} -Starting in v1.20, you can optionally disable node port allocation for a Service Type=LoadBalancer by setting +You can optionally disable node port allocation for a Service of `type=LoadBalancer`, by setting the field `spec.allocateLoadBalancerNodePorts` to `false`. This should only be used for load balancer implementations that route traffic directly to pods as opposed to using node ports. By default, `spec.allocateLoadBalancerNodePorts` is `true` and type LoadBalancer Services will continue to allocate node ports. If `spec.allocateLoadBalancerNodePorts` -is set to `false` on an existing Service with allocated node ports, those node ports will NOT be de-allocated automatically. +is set to `false` on an existing Service with allocated node ports, those node ports will **not** be de-allocated automatically. You must explicitly remove the `nodePorts` entry in every Service port to de-allocate those node ports. -You must enable the `ServiceLBNodePortControl` feature gate to use this field. +Your cluster must have the `ServiceLBNodePortControl` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +enabled to use this field. +For Kubernetes v{{< skew currentVersion >}}, this feature gate is enabled by default, +and you can use the `spec.allocateLoadBalancerNodePorts` field. For clusters running +other versions of Kubernetes, check the documentation for that release. #### Specifying class of load balancer implementation {#load-balancer-class} {{< feature-state for_k8s_version="v1.22" state="beta" >}} -`spec.loadBalancerClass` enables you to use a load balancer implementation other than the cloud provider default. This feature is available from v1.21, you must enable the `ServiceLoadBalancerClass` feature gate to use this field in v1.21, and the feature gate is enabled by default from v1.22 onwards. +`spec.loadBalancerClass` enables you to use a load balancer implementation other than the cloud provider default. +Your cluster must have the `ServiceLoadBalancerClass` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled to use this field. For Kubernetes v{{< skew currentVersion >}}, this feature gate is enabled by default. For clusters running +other versions of Kubernetes, check the documentation for that release. By default, `spec.loadBalancerClass` is `nil` and a `LoadBalancer` type of Service uses the cloud provider's default load balancer implementation if the cluster is configured with a cloud provider using the `--cloud-provider` component flag. diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 41dab6b043..11a5611b36 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -422,7 +422,7 @@ Helper programs relating to the volume type may be required for consumption of a ### Capacity -Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) to understand the units expected by `capacity`. +Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. Read the glossary term [Quantity](/docs/reference/glossary/?all=true#term-quantity) to understand the units expected by `capacity`. Currently, storage size is the only resource that can be set or requested. Future attributes may include IOPS, throughput, etc. @@ -535,19 +535,19 @@ Not all Persistent Volume types support mount options. The following volume types support mount options: -* AWSElasticBlockStore -* AzureDisk -* AzureFile -* CephFS -* Cinder (OpenStack block storage) -* GCEPersistentDisk -* Glusterfs -* NFS -* Quobyte Volumes -* RBD (Ceph Block Device) -* StorageOS -* VsphereVolume -* iSCSI +* `awsElasticBlockStore` +* `azureDisk` +* `azureFile` +* `cephfs` +* `cinder` (**deprecated** in v1.18) +* `gcePersistentDisk` +* `glusterfs` +* `iscsi` +* `nfs` +* `quobyte` (**deprecated** in v1.22) +* `rbd` +* `storageos` (**deprecated** in v1.22) +* `vsphereVolume` Mount options are not validated. If a mount option is invalid, the mount fails. diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index f80224e2e6..ad3170b1d2 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -842,6 +842,13 @@ Kubernetes marks a Deployment as _progressing_ when one of the following tasks i * The Deployment is scaling down its older ReplicaSet(s). * New Pods become ready or available (ready for at least [MinReadySeconds](#min-ready-seconds)). +When the rollout becomes “progressing”, the Deployment controller adds a condition with the following +attributes to the Deployment's `.status.conditions`: + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated` + You can monitor the progress for a Deployment by using `kubectl rollout status`. ### Complete Deployment @@ -853,6 +860,17 @@ updates you've requested have been completed. * All of the replicas associated with the Deployment are available. * No old replicas for the Deployment are running. +When the rollout becomes “complete”, the Deployment controller sets a condition with the following +attributes to the Deployment's `.status.conditions`: + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetAvailable` + +This `Progressing` condition will retain a status value of `"True"` until a new rollout +is initiated. The condition holds even when availability of replicas changes (which +does instead affect the `Available` condition). + You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed successfully, `kubectl rollout status` returns a zero exit code. @@ -890,7 +908,7 @@ number of seconds the Deployment controller waits before indicating (in the Depl Deployment progress has stalled. The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report -lack of progress for a Deployment after 10 minutes: +lack of progress of a rollout for a Deployment after 10 minutes: ```shell kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' @@ -902,15 +920,18 @@ deployment.apps/nginx-deployment patched Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following attributes to the Deployment's `.status.conditions`: -* Type=Progressing -* Status=False -* Reason=ProgressDeadlineExceeded +* `type: Progressing` +* `status: "False"` +* `reason: ProgressDeadlineExceeded` + +This condition can also fail early and is then set to status value of `"False"` due to reasons as `ReplicaSetCreateError`. +Also, the deadline is not taken into account anymore once the Deployment rollout completes. See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for more information on status conditions. {{< note >}} Kubernetes takes no action on a stalled Deployment other than to report a status condition with -`Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for +`reason: ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for example, rollback the Deployment to its previous version. {{< /note >}} @@ -984,7 +1005,7 @@ Conditions: You can address an issue of insufficient quota by scaling down your Deployment, by scaling down other controllers you may be running, or by increasing quota in your namespace. If you satisfy the quota conditions and the Deployment controller then completes the Deployment rollout, you'll see the -Deployment's status update with a successful condition (`Status=True` and `Reason=NewReplicaSetAvailable`). +Deployment's status update with a successful condition (`status: "True"` and `reason: NewReplicaSetAvailable`). ``` Conditions: @@ -994,11 +1015,11 @@ Conditions: Progressing True NewReplicaSetAvailable ``` -`Type=Available` with `Status=True` means that your Deployment has minimum availability. Minimum availability is dictated -by the parameters specified in the deployment strategy. `Type=Progressing` with `Status=True` means that your Deployment +`type: Available` with `status: "True"` means that your Deployment has minimum availability. Minimum availability is dictated +by the parameters specified in the deployment strategy. `type: Progressing` with `status: "True"` means that your Deployment is either in the middle of a rollout and it is progressing or that it has successfully completed its progress and the minimum required new replicas are available (see the Reason of the condition for the particulars - in our case -`Reason=NewReplicaSetAvailable` means that the Deployment is complete). +`reason: NewReplicaSetAvailable` means that the Deployment is complete). You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status` returns a non-zero exit code if the Deployment has exceeded the progression deadline. @@ -1155,8 +1176,8 @@ total number of Pods running at any time during the update is at most 130% of de `.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want to wait for your Deployment to progress before the system reports back that the Deployment has -[failed progressing](#failed-deployment) - surfaced as a condition with `Type=Progressing`, `Status=False`. -and `Reason=ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep +[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: "False"`. +and `reason: ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep retrying the Deployment. This defaults to 600. In the future, once automatic rollback will be implemented, the Deployment controller will roll back a Deployment as soon as it observes such a condition. diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index 70967853e8..1daf567c66 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/content/en/docs/concepts/workloads/controllers/replicaset.md @@ -313,7 +313,7 @@ ensures that a desired number of Pods with a matching label selector are availab When scaling down, the ReplicaSet controller chooses which pods to delete by sorting the available pods to prioritize scaling down pods based on the following general algorithm: 1. Pending (and unschedulable) pods are scaled down first - 2. If controller.kubernetes.io/pod-deletion-cost annotation is set, then + 2. If `controller.kubernetes.io/pod-deletion-cost` annotation is set, then the pod with the lower value will come first. 3. Pods on nodes with more replicas come before pods on nodes with fewer replicas. 4. If the pods' creation times differ, the pod that was created more recently diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md index d07ecee16c..063fc46267 100644 --- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md @@ -266,7 +266,7 @@ Note that we recommend using Deployments instead of directly using Replica Sets, ### Deployment (Recommended) -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods. Deployments are recommended if you want this rolling update functionality because, they are declarative, server-side, and have additional features. +[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods. Deployments are recommended if you want the rolling update functionality because, they are declarative, server-side, and have additional features. ### Bare Pods diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md index a5807216a4..5463019ac0 100644 --- a/content/en/docs/contribute/style/hugo-shortcodes/index.md +++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md @@ -12,11 +12,13 @@ Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content ## Feature state -In a Markdown page (`.md` file) on this site, you can add a shortcode to display version and state of the documented feature. +In a Markdown page (`.md` file) on this site, you can add a shortcode to +display version and state of the documented feature. ### Feature state demo -Below is a demo of the feature state snippet, which displays the feature as stable in the latest Kubernetes version. +Below is a demo of the feature state snippet, which displays the feature as +stable in the latest Kubernetes version. ``` {{}} @@ -50,16 +52,22 @@ Renders to: There are two glossary shortcodes: `glossary_tooltip` and `glossary_definition`. -You can reference glossary terms with an inclusion that automatically updates and replaces content with the relevant links from [our glossary](/docs/reference/glossary/). When the glossary term is moused-over, the glossary entry displays a tooltip. The glossary term also displays as a link. +You can reference glossary terms with an inclusion that automatically updates +and replaces content with the relevant links from [our glossary](/docs/reference/glossary/). +When the glossary term is moused-over, the glossary entry displays a tooltip. +The glossary term also displays as a link. As well as inclusions with tooltips, you can reuse the definitions from the glossary in page content. -The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary), with a content file for each glossary term. +The raw data for glossary terms is stored at +[the glossary directory](https://github.com/kubernetes/website/tree/main/content/en/docs/reference/glossary), +with a content file for each glossary term. ### Glossary demo -For example, the following include within the Markdown renders to {{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip: +For example, the following include within the Markdown renders to +{{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip: ``` {{}} @@ -85,7 +93,9 @@ which renders as: ## Links to API Reference -You can link to a page of the Kubernetes API reference using the `api-reference` shortcode, for example to the {{< api-reference page="workload-resources/pod-v1" >}} reference: +You can link to a page of the Kubernetes API reference using the +`api-reference` shortcode, for example to the +{{< api-reference page="workload-resources/pod-v1" >}} reference: ``` {{}} @@ -94,7 +104,10 @@ You can link to a page of the Kubernetes API reference using the `api-reference` The content of the `page` parameter is the suffix of the URL of the API reference page. -You can link to a specific place into a page by specifying an `anchor` parameter, for example to the {{< api-reference page="workload-resources/pod-v1" anchor="PodSpec" >}} reference or the {{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" >}} section of the page: +You can link to a specific place into a page by specifying an `anchor` +parameter, for example to the {{< api-reference page="workload-resources/pod-v1" anchor="PodSpec" >}} +reference or the {{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" >}} +section of the page: ``` {{}} @@ -102,17 +115,20 @@ You can link to a specific place into a page by specifying an `anchor` parameter ``` -You can change the text of the link by specifying a `text` parameter, for example by linking to the {{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" text="Environment Variables">}} section of the page: +You can change the text of the link by specifying a `text` parameter, for +example by linking to the +{{< api-reference page="workload-resources/pod-v1" anchor="environment-variables" text="Environment Variables">}} +section of the page: ``` {{}} ``` - - ## Table captions -You can make tables more accessible to screen readers by adding a table caption. To add a [caption](https://www.w3schools.com/tags/tag_caption.asp) to a table, enclose the table with a `table` shortcode and specify the caption with the `caption` parameter. +You can make tables more accessible to screen readers by adding a table caption. To add a +[caption](https://www.w3schools.com/tags/tag_caption.asp) to a table, +enclose the table with a `table` shortcode and specify the caption with the `caption` parameter. {{< note >}} Table captions are visible to screen readers but invisible when viewed in standard HTML. @@ -138,7 +154,8 @@ Parameter | Description | Default `logLevel` | The log level for log output | `INFO` {{< /table >}} -If you inspect the HTML for the table, you should see this element immediately after the opening `` element: +If you inspect the HTML for the table, you should see this element immediately +after the opening `
` element: ```html @@ -146,14 +163,25 @@ If you inspect the HTML for the table, you should see this element immediately a ## Tabs -In a markdown page (`.md` file) on this site, you can add a tab set to display multiple flavors of a given solution. +In a markdown page (`.md` file) on this site, you can add a tab set to display +multiple flavors of a given solution. The `tabs` shortcode takes these parameters: * `name`: The name as shown on the tab. -* `codelang`: If you provide inner content to the `tab` shortcode, you can tell Hugo what code language to use for highlighting. -* `include`: The file to include in the tab. If the tab lives in a Hugo [leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles), the file -- which can be any MIME type supported by Hugo -- is looked up in the bundle itself. If not, the content page that needs to be included is looked up relative to the current page. Note that with the `include`, you do not have any shortcode inner content and must use the self-closing syntax. For example, {{}}. The language needs to be specified under `codelang` or the language is taken based on the file name. Non-content files are code-highlighted by default. -* If your inner content is markdown, you must use the `%`-delimiter to surround the tab. For example, `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}` +* `codelang`: If you provide inner content to the `tab` shortcode, you can tell Hugo + what code language to use for highlighting. +* `include`: The file to include in the tab. If the tab lives in a Hugo + [leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles), + the file -- which can be any MIME type supported by Hugo -- is looked up in the bundle itself. + If not, the content page that needs to be included is looked up relative to the current page. + Note that with the `include`, you do not have any shortcode inner content and must use the + self-closing syntax. For example, + `{{}}`. The language needs to be specified + under `codelang` or the language is taken based on the file name. + Non-content files are code-highlighted by default. +* If your inner content is markdown, you must use the `%`-delimiter to surround the tab. + For example, `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}` * You can combine the variations mentioned above inside a tab set. Below is a demo of the tabs shortcode. @@ -288,13 +316,17 @@ The two most commonly used version parameters are `latest` and `version`. ### `{{}}` -The `{{}}` shortcode generates the value of the current version of -the Kubernetes documentation from the `version` site parameter. The `param` shortcode accepts the name of one site parameter, in this case: `version`. +The `{{}}` shortcode generates the value of the current +version of the Kubernetes documentation from the `version` site parameter. The +`param` shortcode accepts the name of one site parameter, in this case: +`version`. {{< note >}} -In previously released documentation, `latest` and `version` parameter values are not equivalent. -After a new version is released, `latest` is incremented and the value of `version` for the documentation set remains unchanged. For example, a previously released version of the documentation displays `version` as -`v1.19` and `latest` as `v1.20`. +In previously released documentation, `latest` and `version` parameter values +are not equivalent. After a new version is released, `latest` is incremented +and the value of `version` for the documentation set remains unchanged. For +example, a previously released version of the documentation displays `version` +as `v1.19` and `latest` as `v1.20`. {{< /note >}} Renders to: @@ -313,7 +345,8 @@ Renders to: ### `{{}}` -The `{{}}` shortcode generates the value of `latest` without the "v" prefix. +The `{{}}` shortcode generates the value of `latest` +without the "v" prefix. Renders to: @@ -330,8 +363,9 @@ Renders to: ### `{{}}` -The `{{}}` shortcode generates a version string from `latest` and removes -the "v" prefix. The shortcode prints a new URL for the release note CHANGELOG page with the modified version string. +The `{{}}` shortcode generates a version string +from `latest` and removes the "v" prefix. The shortcode prints a new URL for +the release note CHANGELOG page with the modified version string. Renders to: @@ -344,3 +378,4 @@ Renders to: * Learn about [page content types](/docs/contribute/style/page-content-types/). * Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/). * Learn about [advanced contributing](/docs/contribute/advanced/). + diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 92ac9529cd..1b7f98d599 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -25,7 +25,8 @@ on each Kubernetes component. Each Kubernetes component lets you enable or disable a set of feature gates that are relevant to that component. Use `-h` flag to see a full set of feature gates for all components. -To set feature gates for a component, such as kubelet, use the `--feature-gates` flag assigned to a list of feature pairs: +To set feature gates for a component, such as kubelet, use the `--feature-gates` +flag assigned to a list of feature pairs: ```shell --feature-gates="...,GracefulNodeShutdown=true" @@ -562,7 +563,10 @@ Each feature gate is designed for enabling/disabling a specific feature: - `APIResponseCompression`: Compress the API responses for `LIST` or `GET` requests. - `APIServerIdentity`: Assign each API server an ID in a cluster. - `APIServerTracing`: Add support for distributed tracing in the API server. -- `Accelerators`: Enable Nvidia GPU support when using Docker +- `Accelerators`: Provided an early form of plugin to enable Nvidia GPU support when using + Docker Engine; no longer available. See + [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for + an alternative. - `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit) - `AffinityInAnnotations`: Enable setting [Pod affinity or anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity). @@ -571,8 +575,8 @@ Each feature gate is designed for enabling/disabling a specific feature: kubelets on Pod log requests. - `AnyVolumeDataSource`: Enable use of any custom resource as the `DataSource` of a {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}. -- `AppArmor`: Enable AppArmor based mandatory access control on Linux nodes when using Docker. - See [AppArmor Tutorial](/docs/tutorials/clusters/apparmor/) for more details. +- `AppArmor`: Enable use of AppArmor mandatory access control for Pods running on Linux nodes. + See [AppArmor Tutorial](/docs/tutorials/security/apparmor/) for more details. - `AttachVolumeLimit`: Enable volume plugins to report limits on number of volumes that can be attached to a node. See [dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits) for more details. @@ -766,12 +770,12 @@ Each feature gate is designed for enabling/disabling a specific feature: - `EnableEquivalenceClassCache`: Enable the scheduler to cache equivalence of nodes when scheduling Pods. - `EndpointSlice`: Enables EndpointSlices for more scalable and extensible - network endpoints. See [Enabling EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices/). + network endpoints. See [Enabling EndpointSlices](/docs/concepts/services-networking/endpoint-slices/). - `EndpointSliceNodeName`: Enables EndpointSlice `nodeName` field. - `EndpointSliceProxying`: When enabled, kube-proxy running on Linux will use EndpointSlices as the primary data source instead of Endpoints, enabling scalability and performance improvements. See - [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/). + [Enabling Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/). - `EndpointSliceTerminatingCondition`: Enables EndpointSlice `terminating` and `serving` condition fields. - `EphemeralContainers`: Enable the ability to add @@ -1086,7 +1090,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `WindowsEndpointSliceProxying`: When enabled, kube-proxy running on Windows will use EndpointSlices as the primary data source instead of Endpoints, enabling scalability and performance improvements. See - [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/). + [Enabling Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/). - `WindowsGMSA`: Enables passing of GMSA credential specs from pods to container runtimes. - `WindowsHostProcessContainers`: Enables support for Windows HostProcess containers. - `WindowsRunAsUserName` : Enable support for running applications in Windows containers diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index ac54718b01..dc23747c22 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -44,16 +44,16 @@ kubelet [flags] - + - + - + @@ -65,7 +65,7 @@ kubelet [flags] - + @@ -90,10 +90,10 @@ kubelet [flags] - + - + @@ -243,7 +243,7 @@ kubelet [flags] - + @@ -273,7 +273,7 @@ kubelet [flags] - + @@ -290,14 +290,14 @@ kubelet [flags] - + - + @@ -397,13 +397,6 @@ kubelet [flags] - - - - - - - @@ -416,7 +409,7 @@ kubelet [flags] - + @@ -455,55 +448,63 @@ AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
+CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
+CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (ALPHA - default=false)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=false)
-CSIMigrationAzureDisk=true|false (BETA - default=false)
+CSIMigrationAzureDisk=true|false (BETA - default=true)
CSIMigrationAzureFile=true|false (BETA - default=false)
-CSIMigrationGCE=true|false (BETA - default=false)
+CSIMigrationGCE=true|false (BETA - default=true)
CSIMigrationOpenStack=true|false (BETA - default=true)
+CSIMigrationPortworx=true|false (ALPHA - default=false)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIStorageCapacity=true|false (BETA - default=true)
-CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
CSIVolumeHealth=true|false (ALPHA - default=false)
CSRDuration=true|false (BETA - default=true)
-ConfigurableFSGroupPolicy=true|false (BETA - default=true)
ControllerManagerLeaderMigration=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
+CustomResourceValidationExpressions=true|false (ALPHA - default=false)
DaemonSetUpdateSurge=true|false (BETA - default=true)
DefaultPodTopologySpread=true|false (BETA - default=true)
-DelegateFSGroupToCSIDriver=true|false (ALPHA - default=false)
+DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
DisableCloudProviders=true|false (ALPHA - default=false)
-DownwardAPIHugePages=true|false (BETA - default=false)
+DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
+DownwardAPIHugePages=true|false (BETA - default=true)
EfficientWatchResumption=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (BETA - default=true)
-EphemeralContainers=true|false (ALPHA - default=false)
+EphemeralContainers=true|false (BETA - default=true)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExpandedDNSConfig=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
-GenericEphemeralVolume=true|false (BETA - default=true)
+GRPCContainerProbe=true|false (ALPHA - default=false)
GracefulNodeShutdown=true|false (BETA - default=true)
+GracefulNodeShutdownBasedOnPodPriority=true|false (ALPHA - default=false)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
-IPv6DualStack=true|false (BETA - default=true)
+HonorPVReclaimPolicy=true|false (ALPHA - default=false)
+IdentifyPodOS=true|false (ALPHA - default=false)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
+InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
+InTreePluginRBDUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
IndexedJob=true|false (BETA - default=true)
-IngressClassNamespacedParams=true|false (BETA - default=true)
-JobTrackingWithFinalizers=true|false (ALPHA - default=false)
+JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
+JobReadyPods=true|false (ALPHA - default=false)
+JobTrackingWithFinalizers=true|false (BETA - default=true)
KubeletCredentialProviders=true|false (ALPHA - default=false)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
-KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
+KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
@@ -513,16 +514,20 @@ MixedProtocolLBService=true|false (ALPHA - default=false)
NetworkPolicyEndPort=true|false (BETA - default=true)
NodeSwap=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (BETA - default=true)
+OpenAPIEnums=true|false (ALPHA - default=false)
+OpenAPIV3=true|false (ALPHA - default=false)
PodAffinityNamespaceSelector=true|false (BETA - default=true)
+PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
PodDeletionCost=true|false (BETA - default=true)
PodOverhead=true|false (BETA - default=true)
-PodSecurity=true|false (ALPHA - default=false)
+PodSecurity=true|false (BETA - default=true)
PreferNominatedNode=true|false (BETA - default=true)
ProbeTerminationGracePeriod=true|false (BETA - default=false)
ProcMountType=true|false (ALPHA - default=false)
ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ReadWriteOncePod=true|false (ALPHA - default=false)
+RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
@@ -531,17 +536,18 @@ ServiceInternalTrafficPolicy=true|false (BETA - default=true)
ServiceLBNodePortControl=true|false (BETA - default=true)
ServiceLoadBalancerClass=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
-StatefulSetMinReadySeconds=true|false (ALPHA - default=false)
+StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
+StatefulSetMinReadySeconds=true|false (BETA - default=true)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
SuspendJob=true|false (BETA - default=true)
-TTLAfterFinished=true|false (BETA - default=true)
-TopologyAwareHints=true|false (ALPHA - default=false)
+TopologyAwareHints=true|false (BETA - default=true)
TopologyManager=true|false (BETA - default=true)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
-WindowsHostProcessContainers=true|false (ALPHA - default=false)
+WindowsHostProcessContainers=true|false (BETA - default=true)
+csiMigrationRBD=true|false (ALPHA - default=false)
(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) @@ -635,21 +641,21 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- + - + - + @@ -682,7 +688,7 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- + @@ -724,28 +730,28 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- + - + - + - + @@ -755,6 +761,20 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
+ + + + + + + + + + + + + + @@ -766,7 +786,7 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- + @@ -789,13 +809,14 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
+ - + @@ -898,7 +919,7 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- + @@ -989,7 +1010,7 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- + @@ -1003,7 +1024,7 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- + @@ -1090,14 +1111,6 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- - - - - - - @@ -1109,28 +1122,28 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
- + - + - + - + @@ -1174,7 +1187,7 @@ WindowsHostProcessContainers=true|false (ALPHA - default=false)
@@ -267,22 +269,6 @@ API versions are supported in a series of subsequent releases. - - - - - - - - - - - -
Configuration parameters
--add-dir-header
If true, adds the file directory to the header of the log messagesIf true, adds the file directory to the header of the log messages (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--address string     Default: 0.0.0.0
The IP address for the Kubelet to serve on (set to 0.0.0.0 or :: for listening in all interfaces and IP families) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--allowed-unsafe-sysctls strings
--alsologtostderr
Log to standard error as well as filesLog to standard error as well as files (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--authorization-mode string--authorization-mode string     Default: AlwaysAllow
Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. Default AlwaysAllow when --config flag is not provided; Webhook when --config flag presents. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
[Experimental] The endpoint of remote runtime service. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples: unix:///var/run/dockershim.sock, npipe:////./pipe/dockershim.
--contention-profiling
--cpu-manager-policy-options strings--cpu-manager-policy-options mapStringString
Comma-separated list of options to fine-tune the behavior of the selected CPU Manager policy. If not supplied, keep the default behaviour. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)--docker-endpoint string     Default: unix:///var/run/docker.sock
Use this for the docker endpoint to communicate with. This docker-specific flag only works when container-runtime is set to docker.Use this for the docker endpoint to communicate with. This docker-specific flag only works when container-runtime is set to docker. (DEPRECATED: will be removed along with dockershim.)
--dynamic-config-dir string
The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The DynamicKubeletConfig feature gate must be enabled to pass this flag. (DEPRECATED: Feature DynamicKubeletConfig is deprecated in 1.22 and will not move to GA. It is planned to be removed from Kubernetes in the version 1.23. Please use alternative ways to update kubelet configuration.)The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The DynamicKubeletConfig feature gate must be enabled to pass this flag. (DEPRECATED: Feature DynamicKubeletConfig is deprecated in 1.22 and will not move to GA. It is planned to be removed from Kubernetes in the version 1.23. Please use alternative ways to update kubelet configuration.)
When set to true, hard eviction thresholds will be ignored while calculating node allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: will be removed in 1.23)
--experimental-bootstrap-kubeconfig string
DEPRECATED: Use --bootstrap-kubeconfig
--experimental-check-node-capabilities-before-mount--experimental-kernel-memcg-notification
If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. This flag will be removed in 1.23. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Use kernelMemcgNotification configuration, this flag will be removed in 1.23. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
[Experimental] The endpoint of remote image service. If not specified, it will be the same with --container-runtime-endpoint by default. Currently UNIX socket endpoint is supported on Linux, while npipe and TCP endpoints are supported on Windows. Examples: unix:///var/run/dockershim.sock, npipe:////./pipe/dockershim
--iptables-drop-bit int32     Default: 15
The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--iptables-masquerade-bit int32     Default: 14
The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--keep-terminated-pod-volumes
--kube-api-qps int32     Default: 5
QPS to use while talking with kubernetes API server. The number must be >= 0. If 0 will use default QPS (5). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)QPS to use while talking with kubernetes API server. The number must be >= 0. If 0 will use default QPS (5). Doesn't cover events and node heartbeat apis which rate limiting is controlled by a different set of flags. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--log-backtrace-at <A string of format 'file:line'>     Default: ":0"
When logging hits line :, emit a stack trace.When logging hits line :, emit a stack trace. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--log-dir string
If non-empty, write log files in this directoryIf non-empty, write log files in this directory. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--log-file string
If non-empty, use this log fileIf non-empty, use this log file. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--log-file-max-size uint     Default: 1800
Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited.Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
Maximum number of seconds between log flushes.
--log-json-info-buffer-size string     Default: '0'
[Experimental] In JSON format with split output streams, the info messages can be buffered for a while to increase performance. The default value of zero bytes disables buffering. The size can be specified as number of bytes (512), multiples of 1000 (1K), multiples of 1024 (2Ki), or powers of those (3M, 4G, 5Mi, 6Gi). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--log-json-split-stream
[Experimental] In JSON format, write error messages to stderr and info messages to stdout. The default is to write a single stream to stdout. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--logging-format string     Default: text
--logtostderr     Default: true
log to standard error instead of files.log to standard error instead of files. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
Comma-separated list of HTTP headers to use when accessing the URL provided to --manifest-url. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful' (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--master-service-namespace string     Default: default
The namespace from which the kubernetes master services should be injected into pods. (DEPRECATED: This flag will be removed in a future version.)
--max-open-files int     Default: 1000000
--one-output
If true, only write logs to their native severity level (vs also writing to each lower severity level).If true, only write logs to their native severity level (vs also writing to each lower severity level). (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--register-node     Default: true
Register the node with the API server. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an API server to register with.Register the node with the API server. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an API server to register with. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--register-with-taints mapStringString
Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if --register-node is false.Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if --register-node is false. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
<Warning: Alpha feature> Enable the use of RuntimeDefault as the default seccomp profile for all workloads. The SeccompDefault feature gate must be enabled to allow this flag, which is disabled by default.
--seccomp-profile-root string     Default: /var/lib/kubelet/seccomp
<Warning: Alpha feature> Directory path for seccomp profiles. (DEPRECATED: will be removed in 1.23, in favor of using the /seccomp directory) -
--serialize-image-pulls     Default: true
--skip-headers
If true, avoid header prefixes in the log messagesIf true, avoid header prefixes in the log messages. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--skip-log-headers
If true, avoid headers when opening log filesIf true, avoid headers when opening log files. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--stderrthreshold int     Default: 2
logs at or above this threshold go to stderr.logs at or above this threshold go to stderr. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
--streaming-connection-idle-timeout duration     Default: 4h0m0s
Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: 5m. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: 5m. Note: All connections to the kubelet server have a maximum duration of 4 hours. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.
Preferred values: -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_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_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_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
Insecure values: 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. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md index b237f9c732..e5d2a565dd 100644 --- a/content/en/docs/reference/issues-security/security.md +++ b/content/en/docs/reference/issues-security/security.md @@ -19,8 +19,6 @@ This page describes Kubernetes security and disclosure information. Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements. -You can also subscribe to an RSS feed of the above using [this link](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50). - ## Report a Vulnerability We're extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers. diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md index a93d0e1c12..3b8bab7b3a 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md @@ -489,6 +489,12 @@ PodSpec is a description of a pod. ### Beta level +- **ephemeralContainers** ([]}}">EphemeralContainer) + + *Patch strategy: merge on key `name`* + + List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing pod to perform user-initiated actions such as debugging. This list cannot be specified when creating a pod, and it cannot be modified by updating the pod spec. In order to add an ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource. This field is beta-level and available on clusters that haven't disabled the EphemeralContainers feature gate. + - **preemptionPolicy** (string) PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset. This field is beta-level, gated by the NonPreemptingPriority feature-gate. @@ -497,15 +503,6 @@ PodSpec is a description of a pod. Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. This field will be autopopulated at admission time by the RuntimeClass admission controller. If the RuntimeClass admission controller is enabled, overhead must not be set in Pod create requests. The RuntimeClass admission controller will reject Pod create requests which have the overhead already set. If RuntimeClass is configured and selected in the PodSpec, Overhead will be set to the value defined in the corresponding RuntimeClass, otherwise it will remain unset and treated as zero. More info: https://git.k8s.io/enhancements/keps/sig-node/688-pod-overhead/README.md This field is beta-level as of Kubernetes v1.18, and is only honored by servers that enable the PodOverhead feature. -### Alpha level - - -- **ephemeralContainers** ([]}}">EphemeralContainer) - - *Patch strategy: merge on key `name`* - - List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing pod to perform user-initiated actions such as debugging. This list cannot be specified when creating a pod, and it cannot be modified by updating the pod spec. In order to add an ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource. This field is beta-level and available on clusters that haven't disabled the EphemeralContainers feature gate. - ### Deprecated @@ -1220,83 +1217,9 @@ This is a beta feature available on clusters that haven't disabled the Ephemeral Whether this container should allocate a TTY for itself, also requires 'stdin' to be true. Default is false. -### Not allowed +### Security context -- **ports** ([]ContainerPort) - - *Patch strategy: merge on key `containerPort`* - - *Map: unique values on keys `containerPort, protocol` will be kept during a merge* - - Ports are not allowed for ephemeral containers. - - - *ContainerPort represents a network port in a single container.* - - - **ports.containerPort** (int32), required - - Number of port to expose on the pod's IP address. This must be a valid port number, 0 \< x \< 65536. - - - **ports.hostIP** (string) - - What host IP to bind the external port to. - - - **ports.hostPort** (int32) - - Number of port to expose on the host. If specified, this must be a valid port number, 0 \< x \< 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. - - - **ports.name** (string) - - If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. - - - **ports.protocol** (string) - - Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". - - Possible enum values: - - `"SCTP"` is the SCTP protocol. - - `"TCP"` is the TCP protocol. - - `"UDP"` is the UDP protocol. - -- **resources** (ResourceRequirements) - - Resources are not allowed for ephemeral containers. Ephemeral containers use spare resources already allocated to the pod. - - - *ResourceRequirements describes the compute resource requirements.* - - - **resources.limits** (map[string]}}">Quantity) - - Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - - - **resources.requests** (map[string]}}">Quantity) - - Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - -- **lifecycle** (Lifecycle) - - Lifecycle is not allowed for ephemeral containers. - - - *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* - - - **lifecycle.postStart** (}}">LifecycleHandler) - - PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - - - **lifecycle.preStop** (}}">LifecycleHandler) - - PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The Pod's termination grace period countdown begins before the PreStop hook is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period (unless delayed by finalizers). Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - -- **livenessProbe** (}}">Probe) - - Probes are not allowed for ephemeral containers. - -- **readinessProbe** (}}">Probe) - - Probes are not allowed for ephemeral containers. - - **securityContext** (SecurityContext) Optional: SecurityContext defines the security options the ephemeral container should be run with. If set, the fields of SecurityContext override the equivalent fields of PodSecurityContext. @@ -1415,6 +1338,83 @@ This is a beta feature available on clusters that haven't disabled the Ephemeral The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. +### Not allowed + + +- **ports** ([]ContainerPort) + + *Patch strategy: merge on key `containerPort`* + + *Map: unique values on keys `containerPort, protocol` will be kept during a merge* + + Ports are not allowed for ephemeral containers. + + + *ContainerPort represents a network port in a single container.* + + - **ports.containerPort** (int32), required + + Number of port to expose on the pod's IP address. This must be a valid port number, 0 \< x \< 65536. + + - **ports.hostIP** (string) + + What host IP to bind the external port to. + + - **ports.hostPort** (int32) + + Number of port to expose on the host. If specified, this must be a valid port number, 0 \< x \< 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. + + - **ports.name** (string) + + If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. + + - **ports.protocol** (string) + + Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". + + Possible enum values: + - `"SCTP"` is the SCTP protocol. + - `"TCP"` is the TCP protocol. + - `"UDP"` is the UDP protocol. + +- **resources** (ResourceRequirements) + + Resources are not allowed for ephemeral containers. Ephemeral containers use spare resources already allocated to the pod. + + + *ResourceRequirements describes the compute resource requirements.* + + - **resources.limits** (map[string]}}">Quantity) + + Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ + + - **resources.requests** (map[string]}}">Quantity) + + Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ + +- **lifecycle** (Lifecycle) + + Lifecycle is not allowed for ephemeral containers. + + + *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* + + - **lifecycle.postStart** (}}">LifecycleHandler) + + PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks + + - **lifecycle.preStop** (}}">LifecycleHandler) + + PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The Pod's termination grace period countdown begins before the PreStop hook is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period (unless delayed by finalizers). Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks + +- **livenessProbe** (}}">Probe) + + Probes are not allowed for ephemeral containers. + +- **readinessProbe** (}}">Probe) + + Probes are not allowed for ephemeral containers. + - **startupProbe** (}}">Probe) Probes are not allowed for ephemeral containers. diff --git a/content/en/docs/reference/labels-annotations-taints.md b/content/en/docs/reference/labels-annotations-taints.md index 2009577366..9e8d49950a 100644 --- a/content/en/docs/reference/labels-annotations-taints.md +++ b/content/en/docs/reference/labels-annotations-taints.md @@ -159,6 +159,20 @@ The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure tha If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all. +## volume.beta.kubernetes.io/storage-provisioner (deprecated) + +Example: `volume.beta.kubernetes.io/storage-provisioner: k8s.io/minikube-hostpath` + +Used on: PersistentVolumeClaim + +This annotation has been deprecated. + +## volume.kubernetes.io/storage-provisioner + +Used on: PersistentVolumeClaim + +This annotation will be added to dynamic provisioning required PVC. + ## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build} Example: `node.kubernetes.io/windows-build=10.0.17763` diff --git a/content/en/docs/reference/node/_index.md b/content/en/docs/reference/node/_index.md new file mode 100644 index 0000000000..6ffb648381 --- /dev/null +++ b/content/en/docs/reference/node/_index.md @@ -0,0 +1,4 @@ +--- +title: Node Reference Information +weight: 40 +--- diff --git a/content/en/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md b/content/en/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md new file mode 100644 index 0000000000..9af2a1eb4a --- /dev/null +++ b/content/en/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md @@ -0,0 +1,39 @@ +--- +title: External Articles on dockershim Removal and on Using CRI-compatible Runtimes +content_type: reference +weight: 20 +--- + +This is a list of articles about: + + - the Kubernetes' deprecation and removal of _dockershim_ + - using CRI-compatible container runtimes + + +## Primary sources + +* [Kubernetes Blog: "Dockershim Deprecation FAQ", 2020/12/02](/blog/2020/12/02/dockershim-faq/) + +* [Kubernetes Documentation: "Migrating from dockershim"](/docs/tasks/administer-cluster/migrating-from-dockershim/) + +* [Kubernetes Documentation: "Container runtimes"](/docs/setup/production-environment/container-runtimes/) + +* [Kubernetes enhancement issue: "Removing dockershim from kubelet" (`kubernetes/enhancements#2221`)](https://github.com/kubernetes/enhancements/issues/2221) + +* [Kubernetes enhancement proposal: "KEP-2221: Removing dockershim from kubelet"](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2221-remove-dockershim/README.md) + +* [Kubernetes Blog: "Dockershim removal is coming. Are you ready?", 2021/11/12](/blog/2021/11/12/are-you-ready-for-dockershim-removal/) + +## Secondary sources + +* [Docker.com blog: "What developers need to know about Docker, Docker Engine, and Kubernetes v1.20", 2020/12/04](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/) + +* [Tripwire.com: "How Dockershim’s Forthcoming Deprecation Affects Your Kubernetes"](https://www.tripwire.com/state-of-security/security-data-protection/cloud/how-dockershim-forthcoming-deprecation-affects-your-kubernetes/) + +* [Amazon EKS documentation: "Dockershim deprecation"](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html) + +* ["Google Open Source" channel on YouTube: "Learn Kubernetes with Google - Migrating from Dockershim to Containerd"](https://youtu.be/fl7_4hjT52g) + +* [Mirantis Blog: "The Future of Dockershim is cri-dockerd", 2021/04/21](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/) + +* [Github.com: "Mirantis/cri-dockerd" repo](https://github.com/Mirantis/cri-dockerd) diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md index f912285f7d..a5684ecceb 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md @@ -6,6 +6,9 @@ weight: 90 `kubeadm kubeconfig` provides utilities for managing kubeconfig files. +For examples on how to use `kubeadm kubeconfig user` see +[Generating kubeconfig files for additional users](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users). + ## kubeadm kubeconfig {#cmd-kubeconfig} {{< tabs name="tab-kubeconfig" >}} diff --git a/content/en/docs/reference/tools/_index.md b/content/en/docs/reference/tools/_index.md index f582f992f5..ad10ad1e7c 100644 --- a/content/en/docs/reference/tools/_index.md +++ b/content/en/docs/reference/tools/_index.md @@ -12,16 +12,17 @@ Kubernetes contains several tools to help you work with the Kubernetes system. -## Minikube +## crictl -[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that -runs a single-node Kubernetes cluster locally on your workstation for -development and testing purposes. +[`crictl`](https://github.com/kubernetes-sigs/cri-tools) is a command-line +interface for inspecting and debugging {{}}-compatible +container runtimes. ## Dashboard [`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), the web-based user interface of Kubernetes, allows you to deploy containerized applications -to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself. +to a Kubernetes cluster, troubleshoot them, and manage the cluster and its +resources itself. ## Helm {{% thirdparty-content single="true" %}} @@ -64,4 +65,10 @@ Kui lets you: * Type in `kubectl` commands and see them execute, even sometimes faster than `kubectl` itself * Query a {{< glossary_tooltip text="Job" term_id="job">}} and see its execution rendered as a waterfall diagram -* Click through resources in your cluster using a tabbed UI \ No newline at end of file +* Click through resources in your cluster using a tabbed UI + +## Minikube + +[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that +runs a single-node Kubernetes cluster locally on your workstation for +development and testing purposes. \ No newline at end of file diff --git a/content/en/docs/reference/tools/map-crictl-dockercli.md b/content/en/docs/reference/tools/map-crictl-dockercli.md new file mode 100644 index 0000000000..7fc021451c --- /dev/null +++ b/content/en/docs/reference/tools/map-crictl-dockercli.md @@ -0,0 +1,76 @@ +--- +title: Mapping from dockercli to crictl +content_type: reference +--- + +{{% thirdparty-content %}} + +{{}} +This page is deprecated and will be removed in Kubernetes 1.27. +{{}} + +`crictl` is a command-line interface for {{}}-compatible container runtimes. +You can use it to inspect and debug container runtimes and applications on a +Kubernetes node. `crictl` and its source are hosted in the +[cri-tools](https://github.com/kubernetes-sigs/cri-tools) repository. + +This page provides a reference for mapping common commands for the `docker` +command-line tool into the equivalent commands for `crictl`. + +## Mapping from docker CLI to crictl + +The exact versions for the mapping table are for `docker` CLI v1.40 and `crictl` +v1.19.0. This list is not exhaustive. For example, it doesn't include +experimental `docker` CLI commands. + +{{< note >}} +The output format of `crictl` is similar to `docker` CLI, despite some missing +columns for some CLI. Make sure to check output for the specific command if your +command output is being parsed programmatically. +{{< /note >}} + +### Retrieve debugging information + +{{< table caption="mapping from docker cli to crictl - retrieve debugging information" >}} +docker cli | crictl | Description | Unsupported Features +-- | -- | -- | -- +`attach` | `attach` | Attach to a running container | `--detach-keys`, `--sig-proxy` +`exec` | `exec` | Run a command in a running container | `--privileged`, `--user`, `--detach-keys` +`images` | `images` | List images |   +`info` | `info` | Display system-wide information |   +`inspect` | `inspect`, `inspecti` | Return low-level information on a container, image or task |   +`logs` | `logs` | Fetch the logs of a container | `--details` +`ps` | `ps` | List containers |   +`stats` | `stats` | Display a live stream of container(s) resource usage statistics | Column: NET/BLOCK I/O, PIDs +`version` | `version` | Show the runtime (Docker, ContainerD, or others) version information |   +{{< /table >}} + +### Perform Changes + +{{< table caption="mapping from docker cli to crictl - perform changes" >}} +docker cli | crictl | Description | Unsupported Features +-- | -- | -- | -- +`create` | `create` | Create a new container |   +`kill` | `stop` (timeout = 0) | Kill one or more running container | `--signal` +`pull` | `pull` | Pull an image or a repository from a registry | `--all-tags`, `--disable-content-trust` +`rm` | `rm` | Remove one or more containers |   +`rmi` | `rmi` | Remove one or more images |   +`run` | `run` | Run a command in a new container |   +`start` | `start` | Start one or more stopped containers | `--detach-keys` +`stop` | `stop` | Stop one or more running containers |   +`update` | `update` | Update configuration of one or more containers | `--restart`, `--blkio-weight` and some other resource limit not supported by CRI. +{{< /table >}} + +### Supported only in crictl + +{{< table caption="mapping from docker cli to crictl - supported only in crictl" >}} +crictl | Description +-- | -- +`imagefsinfo` | Return image filesystem info +`inspectp` | Display the status of one or more pods +`port-forward` | Forward local port to a pod +`pods` | List pods +`runp` | Run a new pod +`rmp` | Remove one or more pods +`stopp` | Stop one or more running pods +{{< /table >}} \ No newline at end of file diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md index 6bbd9be9e1..e1c378c4ac 100644 --- a/content/en/docs/reference/using-api/deprecation-policy.md +++ b/content/en/docs/reference/using-api/deprecation-policy.md @@ -73,21 +73,23 @@ knows how to convert between them in both directions. Additionally, any new field added in v2 must be able to round-trip to v1 and back, which means v1 might have to add an equivalent field or represent it as an annotation. -**Rule #3: An API version in a given track may not be deprecated until a new -API version at least as stable is released.** +**Rule #3: An API version in a given track may not be deprecated in favor of a less stable API version.** -GA API versions can replace GA API versions as well as beta and alpha API -versions. Beta API versions *may not* replace GA API versions. + * GA API versions can replace beta and alpha API versions. + * Beta API versions can replace earlier beta and alpha API versions, but *may not* replace GA API versions. + * Alpha API versions can replace earlier alpha API versions, but *may not* replace GA or beta API versions. -**Rule #4a: Other than the most recent API versions in each track, older API -versions must be supported after their announced deprecation for a duration of -no less than:** +**Rule #4a: minimum API lifetime is determined by the API stability level** - * **GA: 12 months or 3 releases (whichever is longer)** - * **Beta: 9 months or 3 releases (whichever is longer)** - * **Alpha: 0 releases** + * **GA API versions may be marked as deprecated, but must not be removed within a major version of Kubernetes** + * **Beta API versions must be supported for 9 months or 3 releases (whichever is longer) after deprecation** + * **Alpha API versions may be removed in any release without prior deprecation notice** -This covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/). +This ensures beta API support covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/). + +{{< note >}} +There are no current plans for a major version revision of Kubernetes that removes GA APIs. +{{< /note >}} {{< note >}} Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is @@ -237,7 +239,7 @@ API versions are supported in a series of subsequent releases.
  • v2beta2 is deprecated, "action required" relnote
    • -
  • v1 is deprecated, "action required" relnote
    • +
  • v1 is deprecated in favor of v2, but will not be removed
X+16v2, v1 (deprecated)v2
X+17v2v2 -
    -
  • v1 is removed, "action required" relnote
    • -
-
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index b78d6dcd1a..3d351c4dda 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -83,13 +83,17 @@ If systemd doesn't use cgroup v2 by default, you can configure the system to use `systemd.unified_cgroup_hierarchy=1` to the kernel command line. ```shell -# dnf install -y grubby && \ +# This example is for a Linux OS that uses the DNF package manager +# Your system might use a different method for setting the command line +# that the Linux kernel uses. +sudo dnf install -y grubby && \ sudo grubby \ --update-kernel=ALL \ --args="systemd.unified_cgroup_hierarchy=1" ``` -To apply the configuration, it is necessary to reboot the node. +If you change the command line for the kernel, you must reboot the node before your +change takes effect. There should not be any noticeable difference in the user experience when switching to cgroup v2, unless users are accessing the cgroup file system directly, either on the node or from within the containers. @@ -168,7 +172,7 @@ installing the `containerd.io` package can be found at {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} -Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), +Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`), and then run the following commands: 1. Download containerd: diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 9d7b717594..e8b0a6d1a7 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -210,7 +210,8 @@ export KUBECONFIG=/etc/kubernetes/admin.conf Kubeadm signs the certificate in the `admin.conf` to have `Subject: O = system:masters, CN = kubernetes-admin`. `system:masters` is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC). Do not share the `admin.conf` file with anyone and instead grant users custom permissions by generating -them a kubeconfig file using the `kubeadm kubeconfig user` command. +them a kubeconfig file using the `kubeadm kubeconfig user` command. For more details see +[Generating kubeconfig files for additional users](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users). {{< /warning >}} Make a record of the `kubeadm join` command that `kubeadm init` outputs. You @@ -384,8 +385,8 @@ A few seconds later, you should notice this node in the output from `kubectl get nodes` when run on the control-plane node. {{< note >}} -As the cluster nodes are usually initialized sequentially, the CoreDNS Pods are likely to all run -on the first control-plane node. To provide higher availability, please rebalance the CoreDNS Pods +As the cluster nodes are usually initialized sequentially, the CoreDNS Pods are likely to all run +on the first control-plane node. To provide higher availability, please rebalance the CoreDNS Pods with `kubectl -n kube-system rollout restart deployment coredns` after at least one new node is joined. {{< /note >}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md index 53b1f38024..4a1a8ae903 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -1,7 +1,7 @@ --- reviewers: - sig-cluster-lifecycle -title: Options for Highly Available topology +title: Options for Highly Available Topology content_type: concept weight: 50 --- diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md index 922b01c2ef..a26209e7a3 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -1,7 +1,7 @@ --- reviewers: - sig-cluster-lifecycle -title: Creating Highly Available clusters with kubeadm +title: Creating Highly Available Clusters with kubeadm content_type: task weight: 60 --- @@ -12,17 +12,17 @@ This page explains two different approaches to setting up a highly available Kub cluster using kubeadm: - With stacked control plane nodes. This approach requires less infrastructure. The etcd members -and control plane nodes are co-located. + and control plane nodes are co-located. - With an external etcd cluster. This approach requires more infrastructure. The -control plane nodes and etcd members are separated. + control plane nodes and etcd members are separated. Before proceeding, you should carefully consider which approach best meets the needs of your applications -and environment. [This comparison topic](/docs/setup/production-environment/tools/kubeadm/ha-topology/) outlines the advantages and disadvantages of each. +and environment. [Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/) outlines the advantages and disadvantages of each. -If you encounter issues with setting up the HA cluster, please provide us with feedback +If you encounter issues with setting up the HA cluster, please report these in the kubeadm [issue tracker](https://github.com/kubernetes/kubeadm/issues/new). -See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). +See also the [upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). {{< caution >}} This page does not address running your cluster on a cloud provider. In a cloud @@ -32,22 +32,80 @@ LoadBalancer, or with dynamic PersistentVolumes. ## {{% heading "prerequisites" %}} +The prerequisites depend on which topology you have selected for your cluster's +control plane: -For both methods you need this infrastructure: +{{< tabs name="prerequisite_tabs" >}} +{{% tab name="Stacked etcd" %}} + -- Three machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for - the control-plane nodes -- Three machines that meet [kubeadm's minimum +You need: + +- Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for + the control-plane nodes. Having an odd number of control plane nodes can help + with leader selection in the case of machine or zone failure. + - including a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, already set up and working +- Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers + - including a container runtime, already set up and working - Full network connectivity between all machines in the cluster (public or private network) -- sudo privileges on all machines +- Superuser privileges on all machines using `sudo` + - You can use a different tool; this guide uses `sudo` in the examples. - SSH access from one device to all nodes in the system -- `kubeadm` and `kubelet` installed on all machines. `kubectl` is optional. +- `kubeadm` and `kubelet` already installed on all machines. -For the external etcd cluster only, you also need: +_See [Stacked etcd topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology) for context._ -- Three additional machines for etcd members +{{% /tab %}} +{{% tab name="External etcd" %}} + +You need: + +- Three or more machines that meet [kubeadm's minimum requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for + the control-plane nodes. Having an odd number of control plane nodes can help + with leader selection in the case of machine or zone failure. + - including a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, already set up and working +- Three or more machines that meet [kubeadm's minimum + requirements](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) for the workers + - including a container runtime, already set up and working +- Full network connectivity between all machines in the cluster (public or + private network) +- Superuser privileges on all machines using `sudo` + - You can use a different tool; this guide uses `sudo` in the examples. +- SSH access from one device to all nodes in the system +- `kubeadm` and `kubelet` already installed on all machines. + + + +And you also need: +- Three or more additional machines, that will become etcd cluster members. + Having an odd number of members in the etcd cluster is a requirement for achieving + optimal voting quorum. + - These machines again need to have `kubeadm` and `kubelet` installed. + - These machines also require a container runtime, that is already set up and working. + +_See [External etcd topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/#external-etcd-topology) for context._ +{{% /tab %}} +{{< /tabs >}} + +### Container images + +Each host should have access read and fetch images from the Kubernetes container image registry, `k8s.gcr.io`. +If you want to deploy a highly-available cluster where the hosts do not have access to pull images, this is possible. You must ensure by some other means that the correct container images are already available on the relevant hosts. + +### Command line interface {#kubectl} + +To manage Kubernetes once your cluster is set up, you should +[install kubectl](/docs/tasks/tools/#kubectl) on your PC. It is also useful +to install the `kubectl` tool on each control plane node, as this can be +helpful for troubleshooting. @@ -60,147 +118,146 @@ There are many configurations for load balancers. The following example is only option. Your cluster requirements may need a different configuration. {{< /note >}} -1. Create a kube-apiserver load balancer with a name that resolves to DNS. +1. Create a kube-apiserver load balancer with a name that resolves to DNS. - - In a cloud environment you should place your control plane nodes behind a TCP - forwarding load balancer. This load balancer distributes traffic to all - healthy control plane nodes in its target list. The health check for - an apiserver is a TCP check on the port the kube-apiserver listens on - (default value `:6443`). + - In a cloud environment you should place your control plane nodes behind a TCP + forwarding load balancer. This load balancer distributes traffic to all + healthy control plane nodes in its target list. The health check for + an apiserver is a TCP check on the port the kube-apiserver listens on + (default value `:6443`). - - It is not recommended to use an IP address directly in a cloud environment. + - It is not recommended to use an IP address directly in a cloud environment. - - The load balancer must be able to communicate with all control plane nodes - on the apiserver port. It must also allow incoming traffic on its - listening port. + - The load balancer must be able to communicate with all control plane nodes + on the apiserver port. It must also allow incoming traffic on its + listening port. - - Make sure the address of the load balancer always matches - the address of kubeadm's `ControlPlaneEndpoint`. + - Make sure the address of the load balancer always matches + the address of kubeadm's `ControlPlaneEndpoint`. - - Read the [Options for Software Load Balancing](https://git.k8s.io/kubeadm/docs/ha-considerations.md#options-for-software-load-balancing) - guide for more details. + - Read the [Options for Software Load Balancing](https://git.k8s.io/kubeadm/docs/ha-considerations.md#options-for-software-load-balancing) + guide for more details. -1. Add the first control plane nodes to the load balancer and test the - connection: +1. Add the first control plane node to the load balancer, and test the + connection: - ```sh - nc -v LOAD_BALANCER_IP PORT - ``` + ```shell + nc -v + ``` - - A connection refused error is expected because the apiserver is not yet - running. A timeout, however, means the load balancer cannot communicate - with the control plane node. If a timeout occurs, reconfigure the load - balancer to communicate with the control plane node. + A connection refused error is expected because the API server is not yet + running. A timeout, however, means the load balancer cannot communicate + with the control plane node. If a timeout occurs, reconfigure the load + balancer to communicate with the control plane node. -1. Add the remaining control plane nodes to the load balancer target group. +1. Add the remaining control plane nodes to the load balancer target group. ## Stacked control plane and etcd nodes ### Steps for the first control plane node -1. Initialize the control plane: +1. Initialize the control plane: - ```sh - sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs - ``` + ```sh + sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs + ``` - - You can use the `--kubernetes-version` flag to set the Kubernetes version to use. - It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. - - The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer. + - You can use the `--kubernetes-version` flag to set the Kubernetes version to use. + It is recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match. + - The `--control-plane-endpoint` flag should be set to the address or DNS and port of the load balancer. - - The `--upload-certs` flag is used to upload the certificates that should be shared - across all the control-plane instances to the cluster. If instead, you prefer to copy certs across - control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual - certificate distribution](#manual-certs) section below. + - The `--upload-certs` flag is used to upload the certificates that should be shared + across all the control-plane instances to the cluster. If instead, you prefer to copy certs across + control-plane nodes manually or using automation tools, please remove this flag and refer to [Manual + certificate distribution](#manual-certs) section below. - {{< note >}} - The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want - to use the [kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) - you must add the `certificateKey` field in the appropriate config locations - (under `InitConfiguration` and `JoinConfiguration: controlPlane`). - {{< /note >}} + {{< note >}} + The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want + to use the [kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) + you must add the `certificateKey` field in the appropriate config locations + (under `InitConfiguration` and `JoinConfiguration: controlPlane`). + {{< /note >}} - {{< note >}} - Some CNI network plugins require additional configuration, for example specifying the pod IP CIDR, while others do not. - See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). - To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file - set the `podSubnet` field under the `networking` object of `ClusterConfiguration`. - {{< /note >}} + {{< note >}} + Some CNI network plugins require additional configuration, for example specifying the pod IP CIDR, while others do not. + See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). + To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file + set the `podSubnet` field under the `networking` object of `ClusterConfiguration`. + {{< /note >}} - - The output looks similar to: + The output looks similar to: - ```sh - ... - You can now join any number of control-plane node by running the following command on each as a root: - kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + ```sh + ... + You can now join any number of control-plane node by running the following command on each as a root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 - Please note that the certificate-key gives access to cluster sensitive data, keep it secret! - As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. + Please note that the certificate-key gives access to cluster sensitive data, keep it secret! + As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. - Then you can join any number of worker nodes by running the following on each as root: - kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 - ``` + Then you can join any number of worker nodes by running the following on each as root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 + ``` - - Copy this output to a text file. You will need it later to join control plane and worker nodes to the cluster. - - When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane - are encrypted and uploaded in the `kubeadm-certs` Secret. - - To re-upload the certificates and generate a new decryption key, use the following command on a control plane - node that is already joined to the cluster: + - Copy this output to a text file. You will need it later to join control plane and worker nodes to + the cluster. + - When `--upload-certs` is used with `kubeadm init`, the certificates of the primary control plane + are encrypted and uploaded in the `kubeadm-certs` Secret. + - To re-upload the certificates and generate a new decryption key, use the following command on a + control plane + node that is already joined to the cluster: - ```sh - sudo kubeadm init phase upload-certs --upload-certs - ``` + ```sh + sudo kubeadm init phase upload-certs --upload-certs + ``` - - You can also specify a custom `--certificate-key` during `init` that can later be used by `join`. - To generate such a key you can use the following command: + - You can also specify a custom `--certificate-key` during `init` that can later be used by `join`. + To generate such a key you can use the following command: - ```sh - kubeadm certs certificate-key - ``` + ```sh + kubeadm certs certificate-key + ``` - {{< note >}} - The `kubeadm-certs` Secret and decryption key expire after two hours. - {{< /note >}} + {{< note >}} + The `kubeadm-certs` Secret and decryption key expire after two hours. + {{< /note >}} - {{< caution >}} - As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret! - {{< /caution >}} + {{< caution >}} + As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret! + {{< /caution >}} -1. Apply the CNI plugin of your choice: - [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) - to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable. - - {{< note >}} - You must pick a network plugin that suits your use case and deploy it before you move on to next step. - If you don't do this, you will not be able to launch your cluster properly. - {{< /note >}} +1. Apply the CNI plugin of your choice: + [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) + to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the + kubeadm configuration file (if applicable). -1. Type the following and watch the pods of the control plane components get started: + {{< note >}} + You must pick a network plugin that suits your use case and deploy it before you move on to next step. + If you don't do this, you will not be able to launch your cluster properly. + {{< /note >}} - ```sh - kubectl get pod -n kube-system -w - ``` +1. Type the following and watch the pods of the control plane components get started: + + ```sh + kubectl get pod -n kube-system -w + ``` ### Steps for the rest of the control plane nodes -{{< note >}} -Since kubeadm version 1.15 you can join multiple control-plane nodes in parallel. -Prior to this version, you must join new control plane nodes sequentially, only after -the first node has finished initializing. -{{< /note >}} - For each additional control plane node you should: -1. Execute the join command that was previously given to you by the `kubeadm init` output on the first node. - It should look something like this: +1. Execute the join command that was previously given to you by the `kubeadm init` output on the first node. + It should look something like this: - ```sh - sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 - ``` + ```sh + sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + ``` - - The `--control-plane` flag tells `kubeadm join` to create a new control plane. - - The `--certificate-key ...` will cause the control plane certificates to be downloaded - from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key. + - The `--control-plane` flag tells `kubeadm join` to create a new control plane. + - The `--certificate-key ...` will cause the control plane certificates to be downloaded + from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key. + +You can join multiple control-plane nodes in parallel. ## External etcd nodes @@ -210,64 +267,69 @@ in the kubeadm config file. ### Set up the etcd cluster -1. Follow [these instructions](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) to set up the etcd cluster. +1. Follow these [instructions](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) to set up the etcd cluster. -1. Setup SSH as described [here](#manual-certs). +1. Setup SSH as described [here](#manual-certs). -1. Copy the following files from any etcd node in the cluster to the first control plane node: +1. Copy the following files from any etcd node in the cluster to the first control plane node: - ```sh - export CONTROL_PLANE="ubuntu@10.0.0.7" - scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": - scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": - scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": - ``` + ```sh + export CONTROL_PLANE="ubuntu@10.0.0.7" + scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": + ``` - - Replace the value of `CONTROL_PLANE` with the `user@host` of the first control-plane node. + - Replace the value of `CONTROL_PLANE` with the `user@host` of the first control-plane node. ### Set up the first control plane node -1. Create a file called `kubeadm-config.yaml` with the following contents: +1. Create a file called `kubeadm-config.yaml` with the following contents: - apiVersion: kubeadm.k8s.io/v1beta3 - kind: ClusterConfiguration - kubernetesVersion: stable - controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" - etcd: - external: - endpoints: - - https://ETCD_0_IP:2379 - - https://ETCD_1_IP:2379 - - https://ETCD_2_IP:2379 - caFile: /etc/kubernetes/pki/etcd/ca.crt - certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt - keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key - {{< note >}} - The difference between stacked etcd and external etcd here is that the external etcd setup requires - a configuration file with the etcd endpoints under the `external` object for `etcd`. - In the case of the stacked etcd topology this is managed automatically. - {{< /note >}} + ```yaml + --- + apiVersion: kubeadm.k8s.io/v1beta3 + kind: ClusterConfiguration + kubernetesVersion: stable + controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # change this (see below) + etcd: + external: + endpoints: + - https://ETCD_0_IP:2379 # change ETCD_0_IP appropriately + - https://ETCD_1_IP:2379 # change ETCD_1_IP appropriately + - https://ETCD_2_IP:2379 # change ETCD_2_IP appropriately + caFile: /etc/kubernetes/pki/etcd/ca.crt + certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt + keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key + ``` - - Replace the following variables in the config template with the appropriate values for your cluster: + {{< note >}} + The difference between stacked etcd and external etcd here is that the external etcd setup requires + a configuration file with the etcd endpoints under the `external` object for `etcd`. + In the case of the stacked etcd topology, this is managed automatically. + {{< /note >}} - - `LOAD_BALANCER_DNS` - - `LOAD_BALANCER_PORT` - - `ETCD_0_IP` - - `ETCD_1_IP` - - `ETCD_2_IP` + - Replace the following variables in the config template with the appropriate values for your cluster: + + - `LOAD_BALANCER_DNS` + - `LOAD_BALANCER_PORT` + - `ETCD_0_IP` + - `ETCD_1_IP` + - `ETCD_2_IP` The following steps are similar to the stacked etcd setup: -1. Run `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` on this node. +1. Run `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` on this node. -1. Write the output join commands that are returned to a text file for later use. +1. Write the output join commands that are returned to a text file for later use. -1. Apply the CNI plugin of your choice. The given example is for Weave Net: +1. Apply the CNI plugin of your choice. - ```sh - kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" - ``` + {{< note >}} + You must pick a network plugin that suits your use case and deploy it before you move on to next step. + If you don't do this, you will not be able to launch your cluster properly. + {{< /note >}} ### Steps for the rest of the control plane nodes @@ -275,7 +337,7 @@ The steps are the same as for the stacked etcd setup: - Make sure the first control plane node is fully initialized. - Join each control plane node with the join command you saved to a text file. It's recommended -to join the control plane nodes one at a time. + to join the control plane nodes one at a time. - Don't forget that the decryption key from `--certificate-key` expires after two hours, by default. ## Common tasks after bootstrapping control plane @@ -295,79 +357,81 @@ If you choose to not use `kubeadm init` with the `--upload-certs` flag this mean you are going to have to manually copy the certificates from the primary control plane node to the joining control plane nodes. -There are many ways to do this. In the following example we are using `ssh` and `scp`: +There are many ways to do this. The following example uses `ssh` and `scp`: SSH is required if you want to control all nodes from a single machine. -1. Enable ssh-agent on your main device that has access to all other nodes in - the system: +1. Enable ssh-agent on your main device that has access to all other nodes in + the system: - ``` - eval $(ssh-agent) + ``` + eval $(ssh-agent) + ``` + +1. Add your SSH identity to the session: + + ``` + ssh-add ~/.ssh/path_to_private_key + ``` + +1. SSH between nodes to check that the connection is working correctly. + + - When you SSH to any node, add the `-A` flag. This flag allows the node that you + have logged into via SSH to access the SSH agent on your PC. Consider alternative + methods if you do not fully trust the security of your user session on the node. + + ``` + ssh -A 10.0.0.7 + ``` + + - When using sudo on any node, make sure to preserve the environment so SSH + forwarding works: + + ``` + sudo -E -s + ``` + +1. After configuring SSH on all the nodes you should run the following script on the first + control plane node after running `kubeadm init`. This script will copy the certificates from + the first control plane node to the other control plane nodes: + + In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the + other control plane nodes. + ```sh + USER=ubuntu # customizable + CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8" + for host in ${CONTROL_PLANE_IPS}; do + scp /etc/kubernetes/pki/ca.crt "${USER}"@$host: + scp /etc/kubernetes/pki/ca.key "${USER}"@$host: + scp /etc/kubernetes/pki/sa.key "${USER}"@$host: + scp /etc/kubernetes/pki/sa.pub "${USER}"@$host: + scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host: + scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host: + scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt + # Skip the next line if you are using external etcd + scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key + done ``` -1. Add your SSH identity to the session: - - ``` - ssh-add ~/.ssh/path_to_private_key - ``` - -1. SSH between nodes to check that the connection is working correctly. - - - When you SSH to any node, make sure to add the `-A` flag: - - ``` - ssh -A 10.0.0.7 - ``` - - - When using sudo on any node, make sure to preserve the environment so SSH - forwarding works: - - ``` - sudo -E -s - ``` - -1. After configuring SSH on all the nodes you should run the following script on the first control plane node after - running `kubeadm init`. This script will copy the certificates from the first control plane node to the other - control plane nodes: - - In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the - other control plane nodes. - ```sh - USER=ubuntu # customizable - CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8" - for host in ${CONTROL_PLANE_IPS}; do - scp /etc/kubernetes/pki/ca.crt "${USER}"@$host: - scp /etc/kubernetes/pki/ca.key "${USER}"@$host: - scp /etc/kubernetes/pki/sa.key "${USER}"@$host: - scp /etc/kubernetes/pki/sa.pub "${USER}"@$host: - scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host: - scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host: - scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt - # Quote this line if you are using external etcd - scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key - done - ``` - - {{< caution >}} - Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates - with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake, - the creation of additional nodes could fail due to a lack of required SANs. - {{< /caution >}} + {{< caution >}} + Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates + with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake, + the creation of additional nodes could fail due to a lack of required SANs. + {{< /caution >}} 1. Then on each joining control plane node you have to run the following script before running `kubeadm join`. This script will move the previously copied certificates from the home directory to `/etc/kubernetes/pki`: - ```sh - USER=ubuntu # customizable - mkdir -p /etc/kubernetes/pki/etcd - mv /home/${USER}/ca.crt /etc/kubernetes/pki/ - mv /home/${USER}/ca.key /etc/kubernetes/pki/ - mv /home/${USER}/sa.pub /etc/kubernetes/pki/ - mv /home/${USER}/sa.key /etc/kubernetes/pki/ - mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/ - mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/ - mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt - # Quote this line if you are using external etcd - mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key - ``` + ```sh + USER=ubuntu # customizable + mkdir -p /etc/kubernetes/pki/etcd + mv /home/${USER}/ca.crt /etc/kubernetes/pki/ + mv /home/${USER}/ca.key /etc/kubernetes/pki/ + mv /home/${USER}/sa.pub /etc/kubernetes/pki/ + mv /home/${USER}/sa.key /etc/kubernetes/pki/ + mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/ + mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/ + mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt + # Skip the next line if you are using external etcd + mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key + ``` diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index b14cd79613..c21b58d771 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -1,7 +1,7 @@ --- reviewers: - sig-cluster-lifecycle -title: Set up a High Availability etcd cluster with kubeadm +title: Set up a High Availability etcd Cluster with kubeadm content_type: task weight: 70 --- @@ -19,7 +19,8 @@ aspects. By default, kubeadm runs a local etcd instance on each control plane node. It is also possible to treat the etcd cluster as external and provision etcd instances on separate hosts. The differences between the two approaches are covered in the -[Options for Highly Available topology][/docs/setup/production-environment/tools/kubeadm/ha-topology] page. +[Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology) page. + This task walks through the process of creating a high availability external etcd cluster of three members that can be used by kubeadm during cluster creation. diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index a8cc1be51c..a0fd004b2e 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -27,6 +27,11 @@ The `kube-apiserver` process accepts an argument `--encryption-provider-config` that controls how API data is encrypted in etcd. An example configuration is provided below. +{{< caution >}} +**IMPORTANT:** For multi-master configurations (with two or more control plane nodes) the encryption configuration file must be the same! +Otherwise, the kube-apiserver can't decrypt data stored inside the key-value store. +{{< /caution >}} + ## Understanding the encryption at rest configuration. ```yaml diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 094b7a767a..789723777e 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -10,7 +10,9 @@ weight: 10 {{< feature-state for_k8s_version="v1.15" state="stable" >}} -Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year. This page explains how to manage certificate renewals with kubeadm. +Client certificates generated by [kubeadm](/docs/reference/setup-tools/kubeadm/) expire after 1 year. +This page explains how to manage certificate renewals with kubeadm. It also covers other tasks related +to kubeadm certificate management. ## {{% heading "prerequisites" %}} @@ -126,13 +128,13 @@ command. In that case, you should explicitly set `--certificate-renewal=true`. You can renew your certificates manually at any time with the `kubeadm certs renew` command. -This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. +This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. After running the command you should restart the control plane Pods. This is required since dynamic certificate reload is currently not supported for all components and certificates. [Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet and not by the API Server, thus kubectl cannot be used to delete and restart them. -To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` +To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/). The kubelet will terminate the Pod if it's no longer in the manifest directory. You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate @@ -289,3 +291,52 @@ Such a controller is not a secure mechanism unless it not only verifies the Comm in the CSR but also verifies the requested IPs and domain names. This would prevent a malicious actor that has access to a kubelet client certificate to create CSRs requesting serving certificates for any IP or domain name. + +## Generating kubeconfig files for additional users {#kubeconfig-additional-users} + +During cluster creation, kubeadm signs the certificate in the `admin.conf` to have +`Subject: O = system:masters, CN = kubernetes-admin`. +[`system:masters`](/docs/reference/access-authn-authz/rbac/#user-facing-roles) +is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC). +Sharing the `admin.conf` with additional users is **not recommended**! + +Instead, you can use the [`kubeadm kubeconfig user`](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig) +command to generate kubeconfig files for additional users. +The command accepts a mixture of command line flags and +[kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) options. +The generated kubeconfig will be written to stdout and can be piped to a file +using `kubeadm kubeconfig user ... > somefile.conf`. + +Example configuration file that can be used with `--config`: + +```yaml +# example.yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +# Will be used as the target "cluster" in the kubeconfig +clusterName: "kubernetes" +# Will be used as the "server" (IP or DNS name) of this cluster in the kubeconfig +controlPlaneEndpoint: "some-dns-address:6443" +# The cluster CA key and certificate will be loaded from this local directory +certificatesDir: "/etc/kubernetes/pki" +``` + +Make sure that these settings match the desired target cluster settings. +To see the settings of an existing cluster use: + +```shell +kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}" +``` + +The following example will generate a kubeconfig file with credentials valid for 24 hours +for a new user `johndoe` that is part of the `appdevs` group: + +```shell +kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h +``` + +The following example will generate a kubeconfig file with administrator credentials valid for 1 week: + +```shell +kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h +``` diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index e3758e05c9..bb472ed647 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -2,14 +2,18 @@ title: Configure Minimum and Maximum CPU Constraints for a Namespace content_type: task weight: 40 +description: >- + Define a range of valid CPU resource limits for a namespace, so that every new Pod + in that namespace falls within the range you configure. --- -This page shows how to set minimum and maximum values for the CPU resources used by Containers -and Pods in a namespace. You specify minimum and maximum CPU values in a -[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) +This page shows how to set minimum and maximum values for the CPU resources used by containers +and Pods in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}. You specify minimum +and maximum CPU values in a +[LimitRange](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created in the namespace. @@ -19,11 +23,13 @@ in the namespace. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -Your cluster must have at least 1 CPU available for use to run the task examples. +{{< include "task-tutorial-prereqs.md" >}} +You must have access to create namespaces in your cluster. +Your cluster must have at least 1.0 CPU available for use to run the task examples. +See [meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu) +to learn what Kubernetes means by “1 CPU”. @@ -39,7 +45,7 @@ kubectl create namespace constraints-cpu-example ## Create a LimitRange and a Pod -Here's the configuration file for a LimitRange: +Here's an example manifest for a LimitRange: {{< codenew file="admin/resource/cpu-constraints.yaml" >}} @@ -72,15 +78,15 @@ limits: type: Container ``` -Now whenever a Container is created in the constraints-cpu-example namespace, Kubernetes -performs these steps: +Now whenever you create a Pod in the constraints-cpu-example namespace (or some other client +of the Kubernetes API creates an equivalent Pod), Kubernetes performs these steps: -* If the Container does not specify its own CPU request and limit, assign the default -CPU request and limit to the Container. +* If any container in that Pod does not specify its own CPU request and limit, the control plane + assigns the default CPU request and limit to that container. -* Verify that the Container specifies a CPU request that is greater than or equal to 200 millicpu. +* Verify that every container in that Pod specifies a CPU request that is greater than or equal to 200 millicpu. -* Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu. +* Verify that every container in that Pod specifies a CPU limit that is less than or equal to 800 millicpu. {{< note >}} When creating a `LimitRange` object, you can specify limits on huge-pages @@ -88,7 +94,7 @@ or GPUs as well. However, when both `default` and `defaultRequest` are specified on these resources, the two values must be the same. {{< /note >}} -Here's the configuration file for a Pod that has one Container. The Container manifest +Here's a manifest for a Pod that has one container. The container manifest specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the minimum and maximum CPU constraints imposed by the LimitRange. @@ -100,7 +106,7 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example ``` -Verify that the Pod's Container is running: +Verify that the Pod is running and that its container is healthy: ```shell kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example @@ -112,7 +118,7 @@ View detailed information about the Pod: kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-example ``` -The output shows that the Container has a CPU request of 500 millicpu and CPU limit +The output shows that the Pod's only container has a CPU request of 500 millicpu and CPU limit of 800 millicpu. These satisfy the constraints imposed by the LimitRange. ```yaml @@ -131,7 +137,7 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example ## Attempt to create a Pod that exceeds the maximum CPU constraint -Here's the configuration file for a Pod that has one Container. The Container specifies a +Here's a manifest for a Pod that has one container. The container specifies a CPU request of 500 millicpu and a cpu limit of 1.5 cpu. {{< codenew file="admin/resource/cpu-constraints-pod-2.yaml" >}} @@ -142,8 +148,8 @@ Attempt to create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example ``` -The output shows that the Pod does not get created, because the Container specifies a CPU limit that is -too large: +The output shows that the Pod does not get created, because it defines an unacceptable container. +That container is not acceptable because it specifies a CPU limit that is too large: ``` Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-2.yaml": @@ -152,7 +158,7 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8 ## Attempt to create a Pod that does not meet the minimum CPU request -Here's the configuration file for a Pod that has one Container. The Container specifies a +Here's a manifest for a Pod that has one container. The container specifies a CPU request of 100 millicpu and a CPU limit of 800 millicpu. {{< codenew file="admin/resource/cpu-constraints-pod-3.yaml" >}} @@ -163,8 +169,9 @@ Attempt to create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example ``` -The output shows that the Pod does not get created, because the Container specifies a CPU -request that is too small: +The output shows that the Pod does not get created, because it defines an unacceptable container. +That container is not acceptable because it specifies a CPU limit that is lower than the +enforced minimum: ``` Error from server (Forbidden): error when creating "examples/admin/resource/cpu-constraints-pod-3.yaml": @@ -173,8 +180,8 @@ pods "constraints-cpu-demo-3" is forbidden: minimum cpu usage per Container is 2 ## Create a Pod that does not specify any CPU request or limit -Here's the configuration file for a Pod that has one Container. The Container does not -specify a CPU request, and it does not specify a CPU limit. +Here's a manifest for a Pod that has one container. The container does not +specify a CPU request, nor does it specify a CPU limit. {{< codenew file="admin/resource/cpu-constraints-pod-4.yaml" >}} @@ -190,8 +197,9 @@ View detailed information about the Pod: kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --output=yaml ``` -The output shows that the Pod's Container has a CPU request of 800 millicpu and a CPU limit of 800 millicpu. -How did the Container get those values? +The output shows that the Pod's single container has a CPU request of 800 millicpu and a +CPU limit of 800 millicpu. +How did that container get those values? ```yaml resources: @@ -201,11 +209,12 @@ resources: cpu: 800m ``` -Because your Container did not specify its own CPU request and limit, it was given the +Because that container did not specify its own CPU request and limit, the control plane +applied the [default CPU request and limit](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) -from the LimitRange. +from the LimitRange for this namespace. -At this point, your Container might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. +At this point, your Pod might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. Delete your Pod: diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index 0156d67e4d..14d50aa4d7 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -2,23 +2,36 @@ title: Configure Default CPU Requests and Limits for a Namespace content_type: task weight: 20 +description: >- + Define a default CPU resource limits for a namespace, so that every new Pod + in that namespace has a CPU resource limit configured. --- -This page shows how to configure default CPU requests and limits for a namespace. -A Kubernetes cluster can be divided into namespaces. If a Container is created in a namespace -that has a default CPU limit, and the Container does not specify its own CPU limit, then -the Container is assigned the default CPU limit. Kubernetes assigns a default CPU request -under certain conditions that are explained later in this topic. +This page shows how to configure default CPU requests and limits for a +{{< glossary_tooltip text="namespace" term_id="namespace" >}}. +A Kubernetes cluster can be divided into namespaces. If you create a Pod within a +namespace that has a default CPU +[limit](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits), and any container in that Pod does not specify +its own CPU limit, then the +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} assigns the default +CPU limit to that container. +Kubernetes assigns a default CPU +[request](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits), +but only under certain conditions that are explained later in this page. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} +You must have access to create namespaces in your cluster. + +If you're not already familiar with what Kubernetes means by 1.0 CPU, +read [meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu). @@ -33,8 +46,8 @@ kubectl create namespace default-cpu-example ## Create a LimitRange and a Pod -Here's the configuration file for a LimitRange object. The configuration specifies -a default CPU request and a default CPU limit. +Here's a manifest for an example {{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}. +The manifest specifies a default CPU request and a default CPU limit. {{< codenew file="admin/resource/cpu-defaults.yaml" >}} @@ -44,12 +57,12 @@ Create the LimitRange in the default-cpu-example namespace: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example ``` -Now if a Container is created in the default-cpu-example namespace, and the -Container does not specify its own values for CPU request and CPU limit, -the Container is given a default CPU request of 0.5 and a default +Now if you create a Pod in the default-cpu-example namespace, and any container +in that Pod does not specify its own values for CPU request and CPU limit, +then the control plane applies default values: a CPU request of 0.5 and a default CPU limit of 1. -Here's the configuration file for a Pod that has one Container. The Container +Here's a manifest for a Pod that has one container. The container does not specify a CPU request and limit. {{< codenew file="admin/resource/cpu-defaults-pod.yaml" >}} @@ -66,8 +79,9 @@ View the Pod's specification: kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example ``` -The output shows that the Pod's Container has a CPU request of 500 millicpus and -a CPU limit of 1 cpu. These are the default values specified by the LimitRange. +The output shows that the Pod's only container has a CPU request of 500m `cpu` +(which you can read as “500 millicpu”), and a CPU limit of 1 `cpu`. +These are the default values specified by the LimitRange. ```shell containers: @@ -81,9 +95,9 @@ containers: cpu: 500m ``` -## What if you specify a Container's limit, but not its request? +## What if you specify a container's limit, but not its request? -Here's the configuration file for a Pod that has one Container. The Container +Here's a manifest for a Pod that has one container. The container specifies a CPU limit, but not a request: {{< codenew file="admin/resource/cpu-defaults-pod-2.yaml" >}} @@ -95,14 +109,15 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example ``` -View the Pod specification: +View the [specification](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status) +of the Pod that you created: ``` kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example ``` -The output shows that the Container's CPU request is set to match its CPU limit. -Notice that the Container was not assigned the default CPU request value of 0.5 cpu. +The output shows that the container's CPU request is set to match its CPU limit. +Notice that the container was not assigned the default CPU request value of 0.5 `cpu`: ``` resources: @@ -112,9 +127,9 @@ resources: cpu: "1" ``` -## What if you specify a Container's request, but not its limit? +## What if you specify a container's request, but not its limit? -Here's the configuration file for a Pod that has one Container. The Container +Here's an example manifest for a Pod that has one container. The container specifies a CPU request, but not a limit: {{< codenew file="admin/resource/cpu-defaults-pod-3.yaml" >}} @@ -125,15 +140,16 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example ``` -View the Pod specification: +View the specification of the Pod that you created: ``` kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example ``` -The output shows that the Container's CPU request is set to the value specified in the -Container's configuration file. The Container's CPU limit is set to 1 cpu, which is the -default CPU limit for the namespace. +The output shows that the container's CPU request is set to the value you specified at +the time you created the Pod (in other words: it matches the manifest). +However, the same container's CPU limit is set to 1 `cpu`, which is the default CPU limit +for that namespace. ``` resources: @@ -145,16 +161,22 @@ resources: ## Motivation for default CPU limits and requests -If your namespace has a -[resource quota](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/), +If your namespace has a CPU {{< glossary_tooltip text="resource quota" term_id="resource-quota" >}} +configured, it is helpful to have a default value in place for CPU limit. -Here are two of the restrictions that a resource quota imposes on a namespace: +Here are two of the restrictions that a CPU resource quota imposes on a namespace: -* Every Container that runs in the namespace must have its own CPU limit. -* The total amount of CPU used by all Containers in the namespace must not exceed a specified limit. +* For every Pod that runs in the namespace, each of its containers must have a CPU limit. +* CPU limits apply a resource reservation on the node where the Pod in question is scheduled. + The total amount of CPU that is reserved for use by all Pods in the namespace must not + exceed a specified limit. + +When you add a LimitRange: + +If any Pod in that namespace that includes a container does not specify its own CPU limit, +the control plane applies the default CPU limit to that container, and the Pod can be +allowed to run in a namespace that is restricted by a CPU ResourceQuota. -If a Container does not specify its own CPU limit, it is given the default limit, and then -it can be allowed to run in a namespace that is restricted by a quota. ## Clean up diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index de80b80ce3..3efd899075 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -2,12 +2,15 @@ title: Configure Minimum and Maximum Memory Constraints for a Namespace content_type: task weight: 30 +description: >- + Define a range of valid memory resource limits for a namespace, so that every new Pod + in that namespace falls within the range you configure. --- -This page shows how to set minimum and maximum values for memory used by Containers +This page shows how to set minimum and maximum values for memory used by containers running in a namespace. You specify minimum and maximum memory values in a [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) object. If a Pod does not meet the constraints imposed by the LimitRange, @@ -15,16 +18,14 @@ it cannot be created in the namespace. - ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -Each node in your cluster must have at least 1 GiB of memory. - +{{< include "task-tutorial-prereqs.md" >}} +You must have access to create namespaces in your cluster. +Each node in your cluster must have at least 1 GiB of memory available for Pods. @@ -39,7 +40,7 @@ kubectl create namespace constraints-mem-example ## Create a LimitRange and a Pod -Here's the configuration file for a LimitRange: +Here's an example manifest for a LimitRange: {{< codenew file="admin/resource/memory-constraints.yaml" >}} @@ -72,18 +73,19 @@ file for the LimitRange, they were created automatically. type: Container ``` -Now whenever a Container is created in the constraints-mem-example namespace, Kubernetes +Now whenever you define a Pod within the constraints-mem-example namespace, Kubernetes performs these steps: -* If the Container does not specify its own memory request and limit, assign the default -memory request and limit to the Container. +* If any container in that Pod does not specify its own memory request and limit, assign +the default memory request and limit to that container. -* Verify that the Container has a memory request that is greater than or equal to 500 MiB. +* Verify that every container in that Pod requests at least 500 MiB of memory. -* Verify that the Container has a memory limit that is less than or equal to 1 GiB. +* Verify that every container in that Pod requests no more than 1024 MiB (1 GiB) + of memory. -Here's the configuration file for a Pod that has one Container. The Container manifest -specifies a memory request of 600 MiB and a memory limit of 800 MiB. These satisfy the +Here's a manifest for a Pod that has one container. Within the Pod spec, the sole +container specifies a memory request of 600 MiB and a memory limit of 800 MiB. These satisfy the minimum and maximum memory constraints imposed by the LimitRange. {{< codenew file="admin/resource/memory-constraints-pod.yaml" >}} @@ -94,7 +96,7 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example ``` -Verify that the Pod's Container is running: +Verify that the Pod is running and that its container is healthy: ```shell kubectl get pod constraints-mem-demo --namespace=constraints-mem-example @@ -106,8 +108,9 @@ View detailed information about the Pod: kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-example ``` -The output shows that the Container has a memory request of 600 MiB and a memory limit -of 800 MiB. These satisfy the constraints imposed by the LimitRange. +The output shows that the container within that Pod has a memory request of 600 MiB and +a memory limit of 800 MiB. These satisfy the constraints imposed by the LimitRange for +this namespace: ```yaml resources: @@ -125,7 +128,7 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example ## Attempt to create a Pod that exceeds the maximum memory constraint -Here's the configuration file for a Pod that has one Container. The Container specifies a +Here's a manifest for a Pod that has one container. The container specifies a memory request of 800 MiB and a memory limit of 1.5 GiB. {{< codenew file="admin/resource/memory-constraints-pod-2.yaml" >}} @@ -136,8 +139,8 @@ Attempt to create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example ``` -The output shows that the Pod does not get created, because the Container specifies a memory limit that is -too large: +The output shows that the Pod does not get created, because it defines a container that +requests more memory than is allowed: ``` Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-2.yaml": @@ -146,7 +149,7 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i ## Attempt to create a Pod that does not meet the minimum memory request -Here's the configuration file for a Pod that has one Container. The Container specifies a +Here's a manifest for a Pod that has one container. That container specifies a memory request of 100 MiB and a memory limit of 800 MiB. {{< codenew file="admin/resource/memory-constraints-pod-3.yaml" >}} @@ -157,8 +160,8 @@ Attempt to create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example ``` -The output shows that the Pod does not get created, because the Container specifies a memory -request that is too small: +The output shows that the Pod does not get created, because it defines a container +that requests less memory than the enforced minimum: ``` Error from server (Forbidden): error when creating "examples/admin/resource/memory-constraints-pod-3.yaml": @@ -167,9 +170,7 @@ pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container i ## Create a Pod that does not specify any memory request or limit - - -Here's the configuration file for a Pod that has one Container. The Container does not +Here's a manifest for a Pod that has one container. The container does not specify a memory request, and it does not specify a memory limit. {{< codenew file="admin/resource/memory-constraints-pod-4.yaml" >}} @@ -182,12 +183,12 @@ kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4 View detailed information about the Pod: -``` +```shell kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --output=yaml ``` -The output shows that the Pod's Container has a memory request of 1 GiB and a memory limit of 1 GiB. -How did the Container get those values? +The output shows that the Pod's only container has a memory request of 1 GiB and a memory limit of 1 GiB. +How did that container get those values? ``` resources: @@ -197,11 +198,20 @@ resources: memory: 1Gi ``` -Because your Container did not specify its own memory request and limit, it was given the +Because your Pod did not define any memory request and limit for that container, the cluster +applied a [default memory request and limit](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) from the LimitRange. -At this point, your Container might be running or it might not be running. Recall that a prerequisite +This means that the definition of that Pod shows those values. You can check it using +`kubectl describe`: + +```shell +# Look for the "Requests:" section of the output +kubectl describe pod constraints-mem-demo-4 --namespace=constraints-mem-example +``` + +At this point, your Pod might be running or it might not be running. Recall that a prerequisite for this task is that your Nodes have at least 1 GiB of memory. If each of your Nodes has only 1 GiB of memory, then there is not enough allocatable memory on any Node to accommodate a memory request of 1 GiB. If you happen to be using Nodes with 2 GiB of memory, then you probably have @@ -209,7 +219,7 @@ enough space to accommodate the 1 GiB request. Delete your Pod: -``` +```shell kubectl delete pod constraints-mem-demo-4 --namespace=constraints-mem-example ``` @@ -224,12 +234,12 @@ Pods that were created previously. As a cluster administrator, you might want to impose restrictions on the amount of memory that Pods can use. For example: -* Each Node in a cluster has 2 GB of memory. You do not want to accept any Pod that requests -more than 2 GB of memory, because no Node in the cluster can support the request. +* Each Node in a cluster has 2 GiB of memory. You do not want to accept any Pod that requests +more than 2 GiB of memory, because no Node in the cluster can support the request. * A cluster is shared by your production and development departments. -You want to allow production workloads to consume up to 8 GB of memory, but -you want development workloads to be limited to 512 MB. You create separate namespaces +You want to allow production workloads to consume up to 8 GiB of memory, but +you want development workloads to be limited to 512 MiB. You create separate namespaces for production and development, and you apply memory constraints to each namespace. ## Clean up @@ -241,7 +251,6 @@ kubectl delete namespace constraints-mem-example ``` - ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index d2f4790abc..ff2a4082c2 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -2,21 +2,35 @@ title: Configure Default Memory Requests and Limits for a Namespace content_type: task weight: 10 +description: >- + Define a default memory resource limit for a namespace, so that every new Pod + in that namespace has a memory resource limit configured. --- -This page shows how to configure default memory requests and limits for a namespace. -If a Container is created in a namespace that has a default memory limit, and the Container -does not specify its own memory limit, then the Container is assigned the default memory limit. +This page shows how to configure default memory requests and limits for a +{{< glossary_tooltip text="namespace" term_id="namespace" >}}. + +A Kubernetes cluster can be divided into namespaces. Once you have a namespace that +that has a default memory +[limit](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits), +and you then try to create a Pod with a container that does not specify its own memory +limit its own memory limit, then the +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} assigns the default +memory limit to that container. + Kubernetes assigns a default memory request under certain conditions that are explained later in this topic. + ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + +You must have access to create namespaces in your cluster. Each node in your cluster must have at least 2 GiB of memory. @@ -35,8 +49,9 @@ kubectl create namespace default-mem-example ## Create a LimitRange and a Pod -Here's the configuration file for a LimitRange object. The configuration specifies -a default memory request and a default memory limit. +Here's a manifest for an example {{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}. +The manifest specifies a default memory +request and a default memory limit. {{< codenew file="admin/resource/memory-defaults.yaml" >}} @@ -46,12 +61,13 @@ Create the LimitRange in the default-mem-example namespace: kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example ``` -Now if a Container is created in the default-mem-example namespace, and the -Container does not specify its own values for memory request and memory limit, -the Container is given a default memory request of 256 MiB and a default -memory limit of 512 MiB. +Now if you create a Pod in the default-mem-example namespace, and any container +within that Pod does not specify its own values for memory request and memory limit, +then the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} +applies default values: a memory request of 256MiB and a memory limit of 512MiB. -Here's the configuration file for a Pod that has one Container. The Container + +Here's an example manifest for a Pod that has one container. The container does not specify a memory request and limit. {{< codenew file="admin/resource/memory-defaults-pod.yaml" >}} @@ -68,7 +84,7 @@ View detailed information about the Pod: kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example ``` -The output shows that the Pod's Container has a memory request of 256 MiB and +The output shows that the Pod's container has a memory request of 256 MiB and a memory limit of 512 MiB. These are the default values specified by the LimitRange. ```shell @@ -89,9 +105,9 @@ Delete your Pod: kubectl delete pod default-mem-demo --namespace=default-mem-example ``` -## What if you specify a Container's limit, but not its request? +## What if you specify a container's limit, but not its request? -Here's the configuration file for a Pod that has one Container. The Container +Here's a manifest for a Pod that has one container. The container specifies a memory limit, but not a request: {{< codenew file="admin/resource/memory-defaults-pod-2.yaml" >}} @@ -109,8 +125,8 @@ View detailed information about the Pod: kubectl get pod default-mem-demo-2 --output=yaml --namespace=default-mem-example ``` -The output shows that the Container's memory request is set to match its memory limit. -Notice that the Container was not assigned the default memory request value of 256Mi. +The output shows that the container's memory request is set to match its memory limit. +Notice that the container was not assigned the default memory request value of 256Mi. ``` resources: @@ -120,9 +136,9 @@ resources: memory: 1Gi ``` -## What if you specify a Container's request, but not its limit? +## What if you specify a container's request, but not its limit? -Here's the configuration file for a Pod that has one Container. The Container +Here's a manifest for a Pod that has one container. The container specifies a memory request, but not a limit: {{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}} @@ -139,9 +155,9 @@ View the Pod's specification: kubectl get pod default-mem-demo-3 --output=yaml --namespace=default-mem-example ``` -The output shows that the Container's memory request is set to the value specified in the -Container's configuration file. The Container's memory limit is set to 512Mi, which is the -default memory limit for the namespace. +The output shows that the container's memory request is set to the value specified in the +container's manifest. The container is limited to use no more than 512MiB of +memory, which matches the default memory limit for the namespace. ``` resources: @@ -153,15 +169,23 @@ resources: ## Motivation for default memory limits and requests -If your namespace has a resource quota, +If your namespace has a memory {{< glossary_tooltip text="resource quota" term_id="resource-quota" >}} +configured, it is helpful to have a default value in place for memory limit. Here are two of the restrictions that a resource quota imposes on a namespace: -* Every Container that runs in the namespace must have its own memory limit. -* The total amount of memory used by all Containers in the namespace must not exceed a specified limit. +* For every Pod that runs in the namespace, the Pod and each of its containers must have a memory limit. + (If you specify a memory limit for every container in a Pod, Kubernetes can infer the Pod-level memory + limit by adding up the limits for its containers). +* CPU limits apply a resource reservation on the node where the Pod in question is scheduled. + The total amount of memory reserved for all Pods in the namespace must not exceed a specified limit. +* The total amount of memory actually used by all Pods in the namespace must also not exceed a specified limit. -If a Container does not specify its own memory limit, it is given the default limit, and then -it can be allowed to run in a namespace that is restricted by a quota. +When you add a LimitRange: + +If any Pod in that namespace that includes a container does not specify its own memory limit, +the control plane applies the default memory limit to that container, and the Pod can be +allowed to run in a namespace that is restricted by a memory ResourceQuota. ## Clean up diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md index 4869c35e06..161c3a12a9 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md @@ -2,14 +2,17 @@ title: Configure Memory and CPU Quotas for a Namespace content_type: task weight: 50 +description: >- + Define overall memory and CPU resource limits for a namespace. --- This page shows how to set quotas for the total amount memory and CPU that -can be used by all Containers running in a namespace. You specify quotas in a -[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) +can be used by all Pods running in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +You specify quotas in a +[ResourceQuota](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) object. @@ -17,14 +20,13 @@ object. ## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +You must have access to create namespaces in your cluster. Each node in your cluster must have at least 1 GiB of memory. - - ## Create a namespace @@ -38,7 +40,7 @@ kubectl create namespace quota-mem-cpu-example ## Create a ResourceQuota -Here is the configuration file for a ResourceQuota object: +Here is a manifest for an example ResourceQuota: {{< codenew file="admin/resource/quota-mem-cpu.yaml" >}} @@ -56,15 +58,18 @@ kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --outpu The ResourceQuota places these requirements on the quota-mem-cpu-example namespace: -* Every Container must have a memory request, memory limit, cpu request, and cpu limit. -* The memory request total for all Containers must not exceed 1 GiB. -* The memory limit total for all Containers must not exceed 2 GiB. -* The CPU request total for all Containers must not exceed 1 cpu. -* The CPU limit total for all Containers must not exceed 2 cpu. +* For every Pod in the namespace, each container must have a memory request, memory limit, cpu request, and cpu limit. +* The memory request total for all Pods in that namespace must not exceed 1 GiB. +* The memory limit total for all Pods in that namespace must not exceed 2 GiB. +* The CPU request total for all Pods in that namespace must not exceed 1 cpu. +* The CPU limit total for all Pods in that namespace must not exceed 2 cpu. + +See [meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu) +to learn what Kubernetes means by “1 CPU”. ## Create a Pod -Here is the configuration file for a Pod: +Here is a manifest for an example Pod: {{< codenew file="admin/resource/quota-mem-cpu-pod.yaml" >}} @@ -75,15 +80,15 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example ``` -Verify that the Pod's Container is running: +Verify that the Pod is running and that its (only) container is healthy: -``` +```shell kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example ``` Once again, view detailed information about the ResourceQuota: -``` +```shell kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example --output=yaml ``` @@ -105,15 +110,22 @@ status: requests.memory: 600Mi ``` +If you have the `jq` tool, you can also query (using [JSONPath](/docs/reference/kubectl/jsonpath/)) +for just the `used` values, **and** pretty-print that that of the output. For example: + +```shell +kubectl get resourcequota mem-cpu-demo --namespace=quota-mem-cpu-example -o jsonpath='{ .status.used }' | jq . +``` + ## Attempt to create a second Pod -Here is the configuration file for a second Pod: +Here is a manifest for a second Pod: {{< codenew file="admin/resource/quota-mem-cpu-pod-2.yaml" >}} -In the configuration file, you can see that the Pod has a memory request of 700 MiB. +In the manifest, you can see that the Pod has a memory request of 700 MiB. Notice that the sum of the used memory request and this new memory -request exceeds the memory request quota. 600 MiB + 700 MiB > 1 GiB. +request exceeds the memory request quota: 600 MiB + 700 MiB > 1 GiB. Attempt to create the Pod: @@ -133,11 +145,12 @@ requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests. ## Discussion As you have seen in this exercise, you can use a ResourceQuota to restrict -the memory request total for all Containers running in a namespace. +the memory request total for all Pods running in a namespace. You can also restrict the totals for memory limit, cpu request, and cpu limit. -If you want to restrict individual Containers, instead of totals for all Containers, use a -[LimitRange](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). +Instead of managing total resource use within a namespace, you might want to restrict +individual Pods, or the containers in those Pods. To achieve that kind of limiting, use a +[LimitRange](/docs/concepts/policy/limit-range/). ## Clean up diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index b0485f2b45..3cdb1a9f24 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -2,14 +2,16 @@ title: Configure a Pod Quota for a Namespace content_type: task weight: 60 +description: >- + Restrict how many Pods you can create within a namespace. --- This page shows how to set a quota for the total number of Pods that can run -in a namespace. You specify quotas in a -[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) +in a {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. You specify quotas in a +[ResourceQuota](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) object. @@ -18,10 +20,9 @@ object. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - +{{< include "task-tutorial-prereqs.md" >}} +You must have access to create namespaces in your cluster. @@ -36,7 +37,7 @@ kubectl create namespace quota-pod-example ## Create a ResourceQuota -Here is the configuration file for a ResourceQuota object: +Here is an example manifest for a ResourceQuota: {{< codenew file="admin/resource/quota-pod.yaml" >}} @@ -66,11 +67,12 @@ status: pods: "0" ``` -Here is the configuration file for a Deployment: +Here is an example manifest for a {{< glossary_tooltip term_id="deployment" >}}: {{< codenew file="admin/resource/quota-pod-deployment.yaml" >}} -In the configuration file, `replicas: 3` tells Kubernetes to attempt to create three Pods, all running the same application. +In that manifest, `replicas: 3` tells Kubernetes to attempt to create three new Pods, all +running the same application. Create the Deployment: @@ -85,7 +87,7 @@ kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yam ``` The output shows that even though the Deployment specifies three replicas, only two -Pods were created because of the quota. +Pods were created because of the quota you defined earlier: ```yaml spec: @@ -95,11 +97,18 @@ spec: status: availableReplicas: 2 ... -lastUpdateTime: 2017-07-07T20:57:05Z +lastUpdateTime: 2021-04-02T20:57:05Z message: 'unable to create pods: pods "pod-quota-demo-1650323038-" is forbidden: exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2' ``` +### Choice of resource + +In this task you have defined a ResourceQuota that limited the total number of Pods, but +you could also limit the total number of other kinds of object. For example, you +might decide to limit how many {{< glossary_tooltip text="CronJobs" term_id="cronjob" >}} +that can live in a single namespace. + ## Clean up Delete your namespace: diff --git a/content/en/docs/tasks/administer-cluster/memory-manager.md b/content/en/docs/tasks/administer-cluster/memory-manager.md index 3680bfb7c6..282c3e064a 100644 --- a/content/en/docs/tasks/administer-cluster/memory-manager.md +++ b/content/en/docs/tasks/administer-cluster/memory-manager.md @@ -138,7 +138,8 @@ The sum of their values will account for the total amount of reserved memory. A new `--reserved-memory` flag was added to Memory Manager to allow for this total reserved memory to be split (by a node administrator) and accordingly reserved across many NUMA nodes. -The flag specifies a comma-separated list of memory reservations per NUMA node. +The flag specifies a comma-separated list of memory reservations of different memory types per NUMA node. +Memory reservations across multiple NUMA nodes can be specified using semicolon as separator. This parameter is only useful in the context of the Memory Manager feature. The Memory Manager will not use this reserved memory for the allocation of container workloads. @@ -180,6 +181,10 @@ or `--reserved-memory 0:memory=1Gi --reserved-memory 1:memory=2Gi` +or + +`--reserved-memory '0:memory=1Gi;1:memory=2Gi'` + When you specify values for `--reserved-memory` flag, you must comply with the setting that you prior provided via Node Allocatable Feature flags. That is, the following rule must be obeyed for each memory type: @@ -215,7 +220,7 @@ Here is an example of a correct configuration: --kube-reserved=cpu=4,memory=4Gi --system-reserved=cpu=1,memory=1Gi --memory-manager-policy=Static ---reserved-memory 0:memory=3Gi --reserved-memory 1:memory=2148Mi +--reserved-memory '0:memory=3Gi;1:memory=2148Mi' ``` Let us validate the configuration above: diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md index da3bdc1148..87ab93b1fc 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -8,37 +8,35 @@ weight: 70 -With Kubernetes 1.20 dockershim was deprecated. From the -[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) -you might already know that most apps do not have a direct dependency on runtime hosting -containers. However, there are still a lot of telemetry and security agents -that has a dependency on docker to collect containers metadata, logs and -metrics. This document aggregates information on how to detect these -dependencies and links on how to migrate these agents to use generic tools or -alternative runtimes. +Kubernetes' support for direct integration with Docker Engine is deprecated, and will be removed. Most apps do not have a direct dependency on runtime hosting containers. However, there are still a lot of telemetry and monitoring agents that has a dependency on docker to collect containers metadata, logs and metrics. This document aggregates information on how to detect these dependencies and links on how to migrate these agents to use generic tools or alternative runtimes. ## Telemetry and security agents -There are a few ways agents may run on Kubernetes cluster. Agents may run on -nodes directly or as DaemonSets. +Within a Kubernetes cluster there are a few different ways to run telemetry or security agents. +Some agents have a direct dependency on Docker Engine when they as DaemonSets or +directly on nodes. -### Why do telemetry agents rely on Docker? +### Why do some telemetry agents communicate with Docker Engine? -Historically, Kubernetes was built on top of Docker. Kubernetes is managing -networking and scheduling, Docker was placing and operating containers on a -node. So you can get scheduling-related metadata like a pod name from Kubernetes -and containers state information from Docker. Over time more runtimes were -created to manage containers. Also there are projects and Kubernetes features -that generalize container status information extraction across many runtimes. +Historically, Kubernetes was written to work specifically with Docker Engine. +Kubernetes took care of networking and scheduling, relying on Docker Engine for launching +and running containers (within Pods) on a node. Some information that is relevant to telemetry, +such as a pod name, is only available from Kubernetes components. Other data, such as container +metrics, is not the responsibility of the container runtime. Early yelemetry agents needed to query the +container runtime **and** Kubernetes to report an accurate picture. Over time, Kubernetes gained +the ability to support multiple runtimes, and now supports any runtime that is compatible with +the container runtime interface. -Some agents are tied specifically to the Docker tool. The agents may run -commands like [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/) +Some telemetry agents rely specifically on Docker Engine tooling. For example, an agent +might run a command such as +[`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/) or [`docker top`](https://docs.docker.com/engine/reference/commandline/top/) to list -containers and processes or [docker logs](https://docs.docker.com/engine/reference/commandline/logs/) -to subscribe on docker logs. With the deprecating of Docker as a container runtime, +containers and processes or [`docker logs`](https://docs.docker.com/engine/reference/commandline/logs/) +to receive streamed logs. If nodes in your existing cluster use +Docker Engine, and you switch to a different container runtime, these commands will not work any longer. -### Identify DaemonSets that depend on Docker {#identify-docker-dependency} +### Identify DaemonSets that depend on Docker Engine {#identify-docker-dependency} If a pod wants to make calls to the `dockerd` running on the node, the pod must either: diff --git a/content/en/docs/tasks/administer-cluster/nodelocaldns.md b/content/en/docs/tasks/administer-cluster/nodelocaldns.md index 4568182251..92abbc32b5 100644 --- a/content/en/docs/tasks/administer-cluster/nodelocaldns.md +++ b/content/en/docs/tasks/administer-cluster/nodelocaldns.md @@ -100,4 +100,31 @@ shown in [the example](/docs/tasks/administer-cluster/dns-custom-nameservers/#ex The `node-local-dns` ConfigMap can also be modified directly with the stubDomain configuration in the Corefile format. Some cloud providers might not allow modifying `node-local-dns` ConfigMap directly. In those cases, the `kube-dns` ConfigMap can be updated. - + +## Setting memory limits + +node-local-dns pods use memory for storing cache entries and processing queries. Since they do not watch Kubernetes objects, the cluster size or the number of Services/Endpoints do not directly affect memory usage. Memory usage is influenced by the DNS query pattern. +From [CoreDNS docs](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md), +> The default cache size is 10000 entries, which uses about 30 MB when completely filled. + +This would be the memory usage for each server block (if the cache gets completely filled). +Memory usage can be reduced by specifying smaller cache sizes. + +The number of concurrent queries is linked to the memory demand, because each extra +goroutine used for handling a query requires an amount of memory. You can set an upper limit +using the `max_concurrent` option in the forward plugin. + +If a node-local-dns pod attempts to use more memory than is available (because of total system +resources, or because of a configured +[resource limit](/docs/concepts/configuration/manage-resources-containers/)), the operating system +may shut down that pod's container. +If this happens, the container that is terminated (“OOMKilled”) does not clean up the custom +packet filtering rules that it previously added during startup. +The node-local-dns container should get restarted (since managed as part of a DaemonSet), but this +will lead to a brief DNS downtime each time that the container fails: the packet filtering rules direct +DNS queries to a local Pod that is unhealthy. + +You can determine a suitable memory limit by running node-local-dns pods without a limit and +measuring the peak usage. You can also set up and use a +[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) +in _recommender mode_, and then check its recommendations. diff --git a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md index d4cce14870..06e4958697 100644 --- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -67,7 +67,7 @@ transient slices for resources that are supported by that init system. Depending on the configuration of the associated container runtime, operators may have to choose a particular cgroup driver to ensure proper system behavior. For example, if operators use the `systemd` -cgroup driver provided by the `docker` runtime, the `kubelet` must +cgroup driver provided by the `containerd` runtime, the `kubelet` must be configured to use the `systemd` cgroup driver. ### Kube Reserved diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md index 52941ab6e8..b07c8e0689 100644 --- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md @@ -70,7 +70,7 @@ The following sysctls are supported in the _safe_ set: - `kernel.shm_rmid_forced`, - `net.ipv4.ip_local_port_range`, - `net.ipv4.tcp_syncookies`, -- `net.ipv4.ping_group_range` (since Kubernetes 1.18). +- `net.ipv4.ping_group_range` (since Kubernetes 1.18), - `net.ipv4.ip_unprivileged_port_start` (since Kubernetes 1.22). {{< note >}} diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md index d52a4acc66..8adc4071f4 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -8,10 +8,12 @@ card: --- +Many applications rely on configuration which is used during either application initialization or runtime. +Most of the times there is a requirement to adjust values assigned to configuration parameters. +ConfigMaps is the kubernetes way to inject application pods with configuration data. ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps. - ## {{% heading "prerequisites" %}} diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index 1b3ea1ebc4..408f0bc956 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -290,10 +290,18 @@ To enable and use token request projection, you must specify each of the followi command line arguments to `kube-apiserver`: * `--service-account-issuer` + + It can be used as the Identifier of the service account token issuer. You can specify the `--service-account-issuer` argument multiple times, this can be useful to enable a non-disruptive change of the issuer. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted. You must be running running Kubernetes v1.22 or later to be able to specify `--service-account-issuer` multiple times. * `--service-account-key-file` + + File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If specified multiple times, tokens signed by any of the specified keys are considered valid by the Kubernetes API server. * `--service-account-signing-key-file` + + Path to the file that contains the current private key of the service account token issuer. The issuer signs issued ID tokens with this private key. * `--api-audiences` (can be omitted) + The service account token authenticator validates that tokens used against the API are bound to at least one of these audiences. If `api-audiences` is specified multiple times, tokens for any of the specified audiences are considered valid by the Kubernetes API server. If the `--service-account-issuer` flag is configured and this flag is not, this field defaults to a single element list containing the issuer URL. + {{< /note >}} The kubelet can also project a service account token into a Pod. You can diff --git a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md index 10052fd68e..b3bbcaa06d 100644 --- a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md +++ b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md @@ -31,7 +31,7 @@ as Windows server containers, meaning that the version of the base images does n to match that of the host. It is, however, recommended that you use the same base image version as your Windows Server container workloads to ensure you do not have any unused images taking up space on the node. HostProcess containers also support -[volume mounts](./create-hostprocess-pod#volume-mounts) within the container volume. +[volume mounts](#volume-mounts) within the container volume. ### When should I use a Windows HostProcess container? @@ -73,19 +73,20 @@ documentation for more details. These limitations are relevant for Kubernetes v{{< skew currentVersion >}}: - HostProcess containers require containerd 1.6 or higher -{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. + {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. - HostProcess pods can only contain HostProcess containers. This is a current limitation -of the Windows OS; non-privileged Windows containers cannot share a vNIC with the host IP namespace. + of the Windows OS; non-privileged Windows containers cannot share a vNIC with the host IP namespace. - HostProcess containers run as a process on the host and do not have any degree of -isolation other than resource constraints imposed on the HostProcess user account. Neither -filesystem or Hyper-V isolation are supported for HostProcess containers. -- Volume mounts are supported and are mounted under the container volume. See [Volume Mounts](#volume-mounts) + isolation other than resource constraints imposed on the HostProcess user account. Neither + filesystem or Hyper-V isolation are supported for HostProcess containers. +- Volume mounts are supported and are mounted under the container volume. See + [Volume Mounts](#volume-mounts) - A limited set of host user accounts are available for HostProcess containers by default. See [Choosing a User Account](#choosing-a-user-account). - Resource limits (disk, memory, cpu count) are supported in the same fashion as processes -on the host. + on the host. - Both Named pipe mounts and Unix domain sockets are **not** supported and should instead -be accessed via their path on the host (e.g. \\\\.\\pipe\\\*) + be accessed via their path on the host (e.g. \\\\.\\pipe\\\*) ## HostProcess Pod configuration requirements diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index c889570dc7..fcaa0d9db4 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -42,7 +42,7 @@ The `spec` of a static Pod cannot refer to other API objects {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run Pods, +This page assumes you're using {{< glossary_tooltip term_id="cri-o" >}} to run Pods, and that your nodes are running the Fedora operating system. Instructions for other distributions or Kubernetes installations may vary. @@ -156,15 +156,20 @@ already be running. You can view running containers (including static Pods) by running (on the node): ```shell # Run this command on the node where the kubelet is running -docker ps +crictl ps ``` The output might be something like: +```console +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106 ``` -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c -``` + +{{< note >}} +`crictl` outputs the image URI and SHA-256 checksum. `NAME` will look more like: +`docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31`. +{{< /note >}} You can see the mirror Pod on the API server: @@ -172,8 +177,8 @@ You can see the mirror Pod on the API server: kubectl get pods ``` ``` -NAME READY STATUS RESTARTS AGE -static-web-my-node1 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +static-web 1/1 Running 0 2m ``` {{< note >}} @@ -181,7 +186,6 @@ Make sure the kubelet has permission to create the mirror Pod in the API server. [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/). {{< /note >}} - {{< glossary_tooltip term_id="label" text="Labels" >}} from the static Pod are propagated into the mirror Pod. You can use those labels as normal via {{< glossary_tooltip term_id="selector" text="selectors" >}}, etc. @@ -190,34 +194,33 @@ If you try to use `kubectl` to delete the mirror Pod from the API server, the kubelet _doesn't_ remove the static Pod: ```shell -kubectl delete pod static-web-my-node1 +kubectl delete pod static-web ``` ``` -pod "static-web-my-node1" deleted +pod "static-web" deleted ``` You can see that the Pod is still running: ```shell kubectl get pods ``` ``` -NAME READY STATUS RESTARTS AGE -static-web-my-node1 1/1 Running 0 12s +NAME READY STATUS RESTARTS AGE +static-web 1/1 Running 0 4s ``` -Back on your node where the kubelet is running, you can try to stop the Docker -container manually. +Back on your node where the kubelet is running, you can try to stop the container manually. You'll see that, after a time, the kubelet will notice and will restart the Pod automatically: ```shell # Run these commands on the node where the kubelet is running -docker stop f6d05272b57e # replace with the ID of your container +crictl stop 129fd7d382018 # replace with the ID of your container sleep 20 -docker ps +crictl ps ``` -``` -CONTAINER ID IMAGE COMMAND CREATED ... -5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... +```console +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` ## Dynamic addition and removal of static pods @@ -230,14 +233,13 @@ The running kubelet periodically scans the configured directory (`/etc/kubelet.d # mv /etc/kubelet.d/static-web.yaml /tmp sleep 20 -docker ps +crictl ps # You see that no nginx container is running mv /tmp/static-web.yaml /etc/kubelet.d/ sleep 20 -docker ps +crictl ps ``` +```console +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` -CONTAINER ID IMAGE COMMAND CREATED ... -e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago -``` - diff --git a/content/en/docs/tasks/debug-application-cluster/crictl.md b/content/en/docs/tasks/debug-application-cluster/crictl.md index 343e3b1cb0..cb04f1673e 100644 --- a/content/en/docs/tasks/debug-application-cluster/crictl.md +++ b/content/en/docs/tasks/debug-application-cluster/crictl.md @@ -17,15 +17,11 @@ You can use it to inspect and debug container runtimes and applications on a Kubernetes node. `crictl` and its source are hosted in the [cri-tools](https://github.com/kubernetes-sigs/cri-tools) repository. - - ## {{% heading "prerequisites" %}} `crictl` requires a Linux operating system with a CRI runtime. - - ## Installing crictl @@ -41,27 +37,37 @@ of Kubernetes. Extract it and move it to a location on your system path, such as The `crictl` command has several subcommands and runtime flags. Use `crictl help` or `crictl help` for more details. -`crictl` connects to `unix:///var/run/dockershim.sock` by default. For other -runtimes, you can set the endpoint in multiple different ways: +You can set the endpoint for `crictl` by doing one of the following: -- By setting flags `--runtime-endpoint` and `--image-endpoint` -- By setting environment variables `CONTAINER_RUNTIME_ENDPOINT` and `IMAGE_SERVICE_ENDPOINT` -- By setting the endpoint in the config file `--config=/etc/crictl.yaml` +* Set the `--runtime-endpoint` and `--image-endpoint` flags. +* Set the `CONTAINER_RUNTIME_ENDPOINT` and `IMAGE_SERVICE_ENDPOINT` environment + variables. +* Set the endpoint in the configuration file `/etc/crictl.yaml`. To specify a + different file, use the `--config=PATH_TO_FILE` flag when you run `crictl`. + +{{}} +If you don't set an endpoint, `crictl` attempts to connect to a list of known +endpoints, which might result in an impact to performance. +{{}} You can also specify timeout values when connecting to the server and enable or disable debugging, by specifying `timeout` or `debug` values in the configuration file or using the `--timeout` and `--debug` command-line flags. -To view or edit the current configuration, view or edit the contents of `/etc/crictl.yaml`. +To view or edit the current configuration, view or edit the contents of +`/etc/crictl.yaml`. For example, the configuration when using the `containerd` +container runtime would be similar to this: -```shell -cat /etc/crictl.yaml -runtime-endpoint: unix:///var/run/dockershim.sock -image-endpoint: unix:///var/run/dockershim.sock +``` +runtime-endpoint: unix:///var/run/containerd/containerd.sock +image-endpoint: unix:///var/run/containerd/containerd.sock timeout: 10 debug: true ``` +To learn more about `crictl`, refer to the [`crictl` +documentation](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md). + ## Example crictl commands The following examples show some `crictl` commands and example output. @@ -348,64 +354,9 @@ CONTAINER ID IMAGE CREATED STATE 3e025dd50a72d busybox About a minute ago Running busybox 0 ``` +## {{% heading "whatsnext" %}} +* [Learn more about `crictl`](https://github.com/kubernetes-sigs/cri-tools). +* [Map `docker` CLI commands to `crictl`](/reference/tools/map-crictl-dockercli/). - - - -See [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools) -for more information. - -## Mapping from docker cli to crictl - -The exact versions for below mapping table are for docker cli v1.40 and crictl v1.19.0. Please note that the list is not exhaustive. For example, it doesn't include experimental commands of docker cli. - -{{< note >}} -The output format of CRICTL is similar to Docker CLI, despite some missing columns for some CLI. Make sure to check output for the specific command if your script output parsing. -{{< /note >}} - -### Retrieve Debugging Information - -{{< table caption="mapping from docker cli to crictl - retrieve debugging information" >}} -docker cli | crictl | Description | Unsupported Features --- | -- | -- | -- -`attach` | `attach` | Attach to a running container | `--detach-keys`, `--sig-proxy` -`exec` | `exec` | Run a command in a running container | `--privileged`, `--user`, `--detach-keys` -`images` | `images` | List images |   -`info` | `info` | Display system-wide information |   -`inspect` | `inspect`, `inspecti` | Return low-level information on a container, image or task |   -`logs` | `logs` | Fetch the logs of a container | `--details` -`ps` | `ps` | List containers |   -`stats` | `stats` | Display a live stream of container(s) resource usage statistics | Column: NET/BLOCK I/O, PIDs -`version` | `version` | Show the runtime (Docker, ContainerD, or others) version information |   -{{< /table >}} - -### Perform Changes - -{{< table caption="mapping from docker cli to crictl - perform changes" >}} -docker cli | crictl | Description | Unsupported Features --- | -- | -- | -- -`create` | `create` | Create a new container |   -`kill` | `stop` (timeout = 0) | Kill one or more running container | `--signal` -`pull` | `pull` | Pull an image or a repository from a registry | `--all-tags`, `--disable-content-trust` -`rm` | `rm` | Remove one or more containers |   -`rmi` | `rmi` | Remove one or more images |   -`run` | `run` | Run a command in a new container |   -`start` | `start` | Start one or more stopped containers | `--detach-keys` -`stop` | `stop` | Stop one or more running containers |   -`update` | `update` | Update configuration of one or more containers | `--restart`, `--blkio-weight` and some other resource limit not supported by CRI. -{{< /table >}} - -### Supported only in crictl - -{{< table caption="mapping from docker cli to crictl - supported only in crictl" >}} -crictl | Description --- | -- -`imagefsinfo` | Return image filesystem info -`inspectp` | Display the status of one or more pods -`port-forward` | Forward local port to a pod -`pods` | List pods -`runp` | Run a new pod -`rmp` | Remove one or more pods -`stopp` | Stop one or more running pods -{{< /table >}} \ No newline at end of file + \ No newline at end of file diff --git a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md index a5385b25fc..6c6641f382 100644 --- a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md +++ b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md @@ -45,8 +45,9 @@ and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/ Someone else from the community may have already asked a similar question or may be able to help with your problem. The Kubernetes team will also monitor [posts tagged Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes). -If there aren't any existing questions that help, please -[ask a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)! +If there aren't any existing questions that help, **please [ensure that your question is on-topic on Stack Overflow](https://stackoverflow.com/help/on-topic) +and that you read through the guidance on [how to ask a new question](https://stackoverflow.com/help/how-to-ask)**, +before [asking a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)! ### Slack diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index e58b313acb..d36f487794 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -39,7 +39,7 @@ You may want to set (default to 1), [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) and -[`.spec.maxSurge`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge) +[`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (a beta feature and defaults to 0) as well. ### Creating a DaemonSet with `RollingUpdate` update strategy diff --git a/content/en/docs/tasks/run-application/configure-pdb.md b/content/en/docs/tasks/run-application/configure-pdb.md index 3110c2f807..b4c735a330 100644 --- a/content/en/docs/tasks/run-application/configure-pdb.md +++ b/content/en/docs/tasks/run-application/configure-pdb.md @@ -173,7 +173,10 @@ automatically responds to changes in the number of replicas of the corresponding ## Create the PDB object -You can create or update the PDB object with a command like `kubectl apply -f mypdb.yaml`. +You can create or update the PDB object using kubectl. +```shell +kubectl apply -f mypdb.yaml +``` ## Check the status of the PDB diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 02018745d4..04d3e3daaa 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -321,7 +321,7 @@ object: metric: name: requests-per-second describedObject: - apiVersion: networking.k8s.io/v1beta1 + apiVersion: networking.k8s.io/v1 kind: Ingress name: main-route target: @@ -367,7 +367,7 @@ spec: metric: name: requests-per-second describedObject: - apiVersion: networking.k8s.io/v1beta1 + apiVersion: networking.k8s.io/v1 kind: Ingress name: main-route target: @@ -390,7 +390,7 @@ status: metric: name: requests-per-second describedObject: - apiVersion: networking.k8s.io/v1beta1 + apiVersion: networking.k8s.io/v1 kind: Ingress name: main-route current: diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 2eb0410a8b..d7e667d3fa 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -56,8 +56,9 @@ Kubernetes implements horizontal pod autoscaling as a control loop that runs int (and the default interval is 15 seconds). Once during each period, the controller manager queries the resource utilization against the -metrics specified in each HorizontalPodAutoscaler definition. The controller manager -obtains the metrics from either the resource metrics API (for per-pod resource metrics), +metrics specified in each HorizontalPodAutoscaler definition. The controller manager +finds the target resource defined by the `scaleTargetRef`, +then selects the pods based on the target resource's `.spec.selector` labels, and obtains the metrics from either the resource metrics API (for per-pod resource metrics), or the custom metrics API (for all other metrics). * For per-pod resource metrics (like CPU), the controller fetches the metrics diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md index de3b8fc09d..e715de5fd1 100644 --- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -76,16 +76,11 @@ cat < Annotations: -CreationTimestamp: Tue, 21 Mar 2017 07:03:51 -0700 +CreationTimestamp: Tue, 01 Feb 2022 11:49:15 -0500 Requesting User: yourname@example.com +Signer: example.com/serving Status: Pending Subject: - Common Name: my-svc.my-namespace.svc.cluster.local + Common Name: my-pod.my-namespace.pod.cluster.local Serial Number: Subject Alternative Names: - DNS Names: my-svc.my-namespace.svc.cluster.local + DNS Names: my-pod.my-namespace.pod.cluster.local + my-svc.my-namespace.svc.cluster.local IP Addresses: 192.0.2.24 10.0.34.2 Events: @@ -175,30 +172,136 @@ kubectl certificate approve my-svc.my-namespace certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved ``` - -## Download the Certificate and Use It - -Once the CSR is signed and approved you should see the following: +You should now see the following: ```shell kubectl get csr ``` ```none -NAME AGE REQUESTOR CONDITION -my-svc.my-namespace 10m yourname@example.com Approved,Issued +NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION +my-svc.my-namespace 10m example.com/serving yourname@example.com Approved ``` -You can download the issued certificate and save it to a `server.crt` file -by running the following: +This means the certificate request has been approved and is waiting for the +requested signer to sign it. + +## Sign the Certificate Signing Request + +Next, you'll play the part of a certificate signer, issue the certificate, and upload it to the API. + +A signer would typically watch the Certificate Signing Request API for objects with its `signerName`, +check that they have been approved, sign certificates for those requests, +and update the API object status with the issued certificate. + +### Create a Certificate Authority + +First, create a signing certificate by running the following: + +```shell +cat <}} + +Use a `server-signing-config.json` signing configuration and the certificate authority key file +and certificate to sign the certificate request: + +```shell +kubectl get csr my-svc.my-namespace -o jsonpath='{.spec.request}' | \ + base64 --decode | \ + cfssl sign -ca ca.pem -ca-key ca-key.pem -config server-signing-config.json - | \ + cfssljson -bare ca-signed-server +``` + +You should see the output similar to: + +``` +2022/02/01 11:52:26 [INFO] signed certificate with serial number 576048928624926584381415936700914530534472870337 +``` + +This produces a signed serving certificate file, `ca-signed-server.pem`. + +### Upload the Signed Certificate + +Finally, populate the signed certificate in the API object's status: + +```shell +kubectl get csr my-svc.my-namespace -o json | \ + jq '.status.certificate = "'$(base64 ca-signed-server.pem | tr -d '\n')'"' | \ + kubectl replace --raw /apis/certificates.k8s.io/v1/certificatesigningrequests/my-svc.my-namespace/status -f - +``` + +{{< note >}} +This uses the command line tool [jq](https://stedolan.github.io/jq/) to populate the base64-encoded content in the `.status.certificate` field. +If you do not have `jq`, you can also save the JSON output to a file, populate this field manually, and upload the resulting file. +{{< /note >}} + +Once the CSR is approved and the signed certificate is uploaded you should see the following: + +```shell +kubectl get csr +``` + +```none +NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION +my-svc.my-namespace 20m example.com/serving yourname@example.com Approved,Issued +``` + +## Download the Certificate and Use It + +Now, as the requesting user, you can download the issued certificate +and save it to a `server.crt` file by running the following: ```shell kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \ | base64 --decode > server.crt ``` -Now you can use `server.crt` and `server-key.pem` as the keypair to start -your HTTPS server. +Now you can populate `server.crt` and `server-key.pem` in a secret and mount +it into a pod to use as the keypair to start your HTTPS server: + +```shell +kubectl create secret tls server --cert server.crt --key server-key.pem +``` + +```none +secret/server created +``` + +Finally, you can populate `ca.pem` in a configmap and use it as the trust root +to verify the serving certificate: + +```shell +kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem +``` + +```none +configmap/example-serving-ca created +``` ## Approving Certificate Signing Requests diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index f9ca81a9b0..faf8dbf444 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -85,7 +85,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type: chmod +x kubectl mkdir -p ~/.local/bin/kubectl mv ./kubectl ~/.local/bin/kubectl - # and then add ~/.local/bin/kubectl to $PATH + # and then append (or prepend) ~/.local/bin to $PATH ``` {{< /note >}} diff --git a/content/en/docs/tasks/tools/install-kubectl-windows.md b/content/en/docs/tasks/tools/install-kubectl-windows.md index 43bb4e0bfa..707217df2d 100644 --- a/content/en/docs/tasks/tools/install-kubectl-windows.md +++ b/content/en/docs/tasks/tools/install-kubectl-windows.md @@ -59,7 +59,7 @@ The following methods exist for installing kubectl on Windows: $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256) ``` -1. Add the binary in to your `PATH`. +1. Append or prepend the kubectl binary folder to your `PATH` environment variable. 1. Test to ensure the version of `kubectl` is the same as downloaded: @@ -172,7 +172,7 @@ Below are the procedures to set up autocompletion for PowerShell. $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) ``` -1. Add the binary in to your `PATH`. +1. Append or prepend the kubectl binary folder to your `PATH` environment variable. 1. Verify plugin is successfully installed diff --git a/content/en/docs/tutorials/security/seccomp.md b/content/en/docs/tutorials/security/seccomp.md index 465dd1b1a0..5a3fa4a641 100644 --- a/content/en/docs/tutorials/security/seccomp.md +++ b/content/en/docs/tutorials/security/seccomp.md @@ -174,6 +174,15 @@ of security defaults while preserving the functionality of the workload. It is possible that the default profiles differ between container runtimes and their release versions, for example when comparing those from CRI-O and containerd. +{{< note >}} +Enabling the feature will neither change the Kubernetes +`securityContext.seccompProfile` API field nor add the deprecated annotations of +the workload. This provides users the possibility to rollback anytime without +actually changing the workload configuration. Tools like +[`crictl inspect`](https://github.com/kubernetes-sigs/cri-tools) can be used to +verify which seccomp profile is being used by a container. +{{< /note >}} + Some workloads may require a lower amount of syscall restrictions than others. This means that they can fail during runtime even with the `RuntimeDefault` profile. To mitigate such a failure, you can: @@ -203,6 +212,51 @@ kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 featureGates: SeccompDefault: true +nodes: + - role: control-plane + image: kindest/node:v1.23.0@sha256:49824ab1727c04e56a21a5d8372a402fcd32ea51ac96a2706a12af38934f81ac + kubeadmConfigPatches: + - | + kind: JoinConfiguration + nodeRegistration: + kubeletExtraArgs: + seccomp-default: "true" + - role: worker + image: kindest/node:v1.23.0@sha256:49824ab1727c04e56a21a5d8372a402fcd32ea51ac96a2706a12af38934f81ac + kubeadmConfigPatches: + - | + kind: JoinConfiguration + nodeRegistration: + kubeletExtraArgs: + feature-gates: SeccompDefault=true + seccomp-default: "true" +``` + +If the cluster is ready, then running a pod: + +```shell +kubectl run --rm -it --restart=Never --image=alpine alpine -- sh +``` + +Should now have the default seccomp profile attached. This can be verified by +using `docker exec` to run `crictl inspect` for the container on the kind +worker: + +```shell +docker exec -it kind-worker bash -c \ + 'crictl inspect $(crictl ps --name=alpine -q) | jq .info.runtimeSpec.linux.seccomp' +``` + +```json +{ + "defaultAction": "SCMP_ACT_ERRNO", + "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"], + "syscalls": [ + { + "names": ["..."] + } + ] +} ``` ## Create a Pod with a seccomp profile for syscall auditing diff --git a/content/en/examples/admin/sched/my-scheduler.yaml b/content/en/examples/admin/sched/my-scheduler.yaml index b44123b61a..5addf9e0e6 100644 --- a/content/en/examples/admin/sched/my-scheduler.yaml +++ b/content/en/examples/admin/sched/my-scheduler.yaml @@ -30,7 +30,6 @@ roleRef: name: system:volume-scheduler apiGroup: rbac.authorization.k8s.io --- - apiVersion: v1 kind: ConfigMap metadata: @@ -44,7 +43,6 @@ data: - schedulerName: my-scheduler leaderElection: leaderElect: false - --- apiVersion: apps/v1 kind: Deployment @@ -76,13 +74,15 @@ spec: livenessProbe: httpGet: path: /healthz - port: 10251 + port: 10259 + scheme: HTTPS initialDelaySeconds: 15 name: kube-second-scheduler readinessProbe: httpGet: path: /healthz - port: 10251 + port: 10259 + scheme: HTTPS resources: requests: cpu: '0.1' diff --git a/content/en/examples/priority-and-fairness/health-for-strangers.yaml b/content/en/examples/priority-and-fairness/health-for-strangers.yaml index ec74077bbd..c57e2cae37 100644 --- a/content/en/examples/priority-and-fairness/health-for-strangers.yaml +++ b/content/en/examples/priority-and-fairness/health-for-strangers.yaml @@ -1,4 +1,4 @@ -apiVersion: flowcontrol.apiserver.k8s.io/v1beta1 +apiVersion: flowcontrol.apiserver.k8s.io/v1beta2 kind: FlowSchema metadata: name: health-for-strangers diff --git a/content/en/examples/tls/server-signing-config.json b/content/en/examples/tls/server-signing-config.json new file mode 100644 index 0000000000..86860d7369 --- /dev/null +++ b/content/en/examples/tls/server-signing-config.json @@ -0,0 +1,15 @@ +{ + "signing": { + "default": { + "usages": [ + "digital signature", + "key encipherment", + "server auth" + ], + "expiry": "876000h", + "ca_constraint": { + "is_ca": false + } + } + } +} \ No newline at end of file diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index ff1b75de9d..72c0e9e300 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -78,9 +78,10 @@ releases may also occur in between these. | Monthly Patch Release | Cherry Pick Deadline | Target date | | --------------------- | -------------------- | ----------- | -| January 2022 | 2022-01-14 | 2022-01-19 | | February 2022 | 2022-02-11 | 2022-02-16 | | March 2022 | 2022-03-11 | 2022-03-16 | +| April 2022 | 2022-04-08 | 2022-04-13 | +| May 2022 | 2022-05-13 | 2022-05-18 | ## Detailed Release History for Active Branches @@ -92,6 +93,7 @@ End of Life for **1.23** is **2023-02-28**. | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.23.4 | 2022-02-11 | 2022-02-16 | | | 1.23.3 | 2022-01-24 | 2022-01-25 | [Out-of-Band Release](https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) | | 1.23.2 | 2022-01-14 | 2022-01-19 | | | 1.23.1 | 2021-12-14 | 2021-12-16 | | @@ -104,6 +106,7 @@ End of Life for **1.22** is **2022-10-28** | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.22.7 | 2022-02-11 | 2022-02-16 | | | 1.22.6 | 2022-01-14 | 2022-01-19 | | | 1.22.5 | 2021-12-10 | 2021-12-15 | | | 1.22.4 | 2021-11-12 | 2021-11-17 | | @@ -119,6 +122,7 @@ End of Life for **1.21** is **2022-06-28** | Patch Release | Cherry Pick Deadline | Target Date | Note | | ------------- | -------------------- | ----------- | ---------------------------------------------------------------------- | +| 1.21.10 | 2022-02-11 | 2022-02-16 | | | 1.21.9 | 2022-01-14 | 2022-01-19 | | | 1.21.8 | 2021-12-10 | 2021-12-15 | | | 1.21.7 | 2021-11-12 | 2021-11-17 | | @@ -137,6 +141,7 @@ End of Life for **1.20** is **2022-02-28** | Patch Release | Cherry Pick Deadline | Target Date | Note | | ------------- | -------------------- | ----------- | ----------------------------------------------------------------------------------- | +| 1.20.16 | 2022-02-11 | 2022-02-16 | If there is critical/blocker patches to be released | | 1.20.15 | 2022-01-14 | 2022-01-19 | | | 1.20.14 | 2021-12-10 | 2021-12-15 | | | 1.20.13 | 2021-11-12 | 2021-11-17 | | diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index e45c2858d6..b3a562c9e3 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -169,9 +169,9 @@ of each minor (1.Y) and patch (1.Y.Z) release GitHub team: [@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins) - Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp)) -- Amit Watve ([@amwat](https://github.com/amwat)) - Benjamin Elder ([@BenTheElder](https://github.com/BenTheElder)) - Grant McCloskey ([@MushuEE](https://github.com/MushuEE)) +- Juan Escobar ([@juanfescobar](https://github.com/juanfescobar)) ## SIG Release Leads diff --git a/content/es/docs/concepts/configuration/manage-resources-containers.md b/content/es/docs/concepts/configuration/manage-resources-containers.md index a74f463b7c..919f1c515b 100644 --- a/content/es/docs/concepts/configuration/manage-resources-containers.md +++ b/content/es/docs/concepts/configuration/manage-resources-containers.md @@ -110,11 +110,11 @@ CPU es siempre solicitada como una cantidad absoluta, nunca como una cantidad re Los límites y peticiones de `memoria` son medidos en bytes. Puedes expresar la memoria como un número entero o como un número decimal usando alguno de estos sufijos: -E, P, T, G, M, K. También puedes usar los equivalentes en potencia de dos: Ei, Pi, Ti, Gi, +E, P, T, G, M, k, m (millis). También puedes usar los equivalentes en potencia de dos: Ei, Pi, Ti, Gi, Mi, Ki. Por ejemplo, los siguientes valores representan lo mismo: ```shell -128974848, 129e6, 129M, 123Mi +128974848, 129e6, 129M, 128974848000m, 123Mi ``` Aquí un ejemplo. diff --git a/content/es/docs/concepts/storage/dynamic-provisioning.md b/content/es/docs/concepts/storage/dynamic-provisioning.md new file mode 100644 index 0000000000..2a8b40461a --- /dev/null +++ b/content/es/docs/concepts/storage/dynamic-provisioning.md @@ -0,0 +1,102 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Aprovisionamiento Dinámico de volumen +content_type: concept +weight: 40 +--- + + + +El aprovisionamiento dinámico de volúmenes permite crear volúmenes de almacenamiento bajo demanda. Sin el aprovisionamiento dinámico, los administradores de clústeres tienen que realizar llamadas manualmente a su proveedor de almacenamiento o nube para crear nuevos volúmenes de almacenamiento y luego crear [objetos de `PersistentVolume`](/docs/concepts/storage/persistent-volumes/) +para representarlos en Kubernetes. La función de aprovisionamiento dinámico elimina la necesidad de que los administradores del clúster aprovisionen previamente el almacenamiento. En cambio, el aprovisionamiento ocurre automáticamente cuando los usuarios lo solicitan. + + + +## Antecedentes + +La implementación del aprovisionamiento dinámico de volúmenes se basa en el objeto API `StorageClass` +del grupo API `storage.k8s.io`. Un administrador de clúster puede definir tantos objetos +`StorageClass` como sea necesario, cada uno especificando un _volume plugin_ (aka +_provisioner_) que aprovisiona un volumen y el conjunto de parámetros para pasar a ese aprovisionador. Un administrador de clúster puede definir y exponer varios tipos de almacenamiento (del mismo o de diferentes sistemas de almacenamiento) dentro de un clúster, cada uno con un conjunto personalizado de parámetros. Este diseño también garantiza que los usuarios finales no tengan que preocuparse por la complejidad y los matices de cómo se aprovisiona el almacenamiento, pero que aún tengan la capacidad de seleccionar entre múltiples opciones de almacenamiento. + +Puede encontrar más información sobre las clases de almacenamiento +[aqui](/docs/concepts/storage/storage-classes/). + +## Habilitación del aprovisionamiento dinámico + +Para habilitar el aprovisionamiento dinámico, un administrador de clúster debe crear previamente uno o más objetos StorageClass para los usuarios. Los objetos StorageClass definen qué aprovisionador se debe usar y qué parámetros se deben pasar a ese aprovisionador cuando se invoca el aprovisionamiento dinámico. +El nombre de un objeto StorageClass debe ser un +[nombre de subdominio de DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +El siguiente manifiesto crea una clase de almacenamiento llamada "slow" que aprovisiona discos persistentes estándar similares a discos. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: slow +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-standard +``` + +El siguiente manifiesto crea una clase de almacenamiento llamada "fast" que aprovisiona discos persistentes similares a SSD. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: fast +provisioner: kubernetes.io/gce-pd +parameters: + type: pd-ssd +``` + +## Usar Aprovisionamiento Dinámico + +Los usuarios solicitan almacenamiento aprovisionado dinámicamente al incluir una clase de almacenamiento en su `PersistentVolumeClaim`. Antes de Kubernetes v1.6, esto se hacía a través del la anotación +`volume.beta.kubernetes.io/storage-class`. Sin embargo, esta anotación está obsoleta desde v1.9. Los usuarios ahora pueden y deben usar el campo +`storageClassName` del objeto `PersistentVolumeClaim`. El valor de este campo debe coincidir con el nombre de un `StorageClass` configurada por el administrador +(ver [documentación](#habilitación-del-aprovisionamiento-dinámico)). + +Para seleccionar la clase de almacenamiento llamada "fast", por ejemplo, un usuario crearía el siguiente PersistentVolumeClaim: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: claim1 +spec: + accessModes: + - ReadWriteOnce + storageClassName: fast + resources: + requests: + storage: 30Gi +``` + +Esta afirmación da como resultado que se aprovisione automáticamente un disco persistente similar a SSD. Cuando se elimina la petición, se destruye el volumen. + +## Comportamiento Predeterminado + +El aprovisionamiento dinámico se puede habilitar en un clúster de modo que todas las peticiones se aprovisionen dinámicamente si no se especifica una clase de almacenamiento. Un administrador de clúster puede habilitar este comportamiento al: + +- Marcar un objeto `StorageClass` como _default_; +- Asegúrese de que el [controlador de admisión `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) esté habilitado en el servidor de API. + +Un administrador puede marcar un `StorageClass` específico como predeterminada agregando la anotación +`storageclass.kubernetes.io/is-default-class`. +Cuando existe un `StorageClass` predeterminado en un clúster y un usuario crea un +`PersistentVolumeClaim` con `storageClassName` sin especificar, el controlador de admisión +`DefaultStorageClass` agrega automáticamente el campo +`storageClassName` que apunta a la clase de almacenamiento predeterminada. + +Tenga en cuenta que puede haber como máximo una clase de almacenamiento _default_, o un `PersistentVolumeClaim` sin `storageClassName` especificado explícitamente. + +## Conocimiento de la Topología + +En los clústeres [Multi-Zone](/docs/setup/multiple-zones), los Pods se pueden distribuir en zonas de una región. Los backends de almacenamiento de zona única deben aprovisionarse en las zonas donde se programan los Pods. Esto se puede lograr configurando el [Volume Binding +Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode). diff --git a/content/es/docs/concepts/storage/storage-capacity.md b/content/es/docs/concepts/storage/storage-capacity.md new file mode 100644 index 0000000000..e729232844 --- /dev/null +++ b/content/es/docs/concepts/storage/storage-capacity.md @@ -0,0 +1,74 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Capacidad de Almacenamiento +content_type: concept +weight: 45 +--- + + + +La capacidad de almacenamiento es limitada y puede variar según el nodo en el que un Pod se ejecuta: es posible que no todos los nodos puedan acceder al almacenamiento conectado a la red o que, para empezar, el almacenamiento sea local en un nodo. + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +Esta página describe cómo Kubernetes realiza un seguimiento de la capacidad de almacenamiento y cómo el planificador usa esa información para programar Pods en nodos que tienen acceso a suficiente capacidad de almacenamiento para los volúmenes restantes que faltan. Sin el seguimiento de la capacidad de almacenamiento, el planificador puede elegir un nodo que no tenga suficiente capacidad para aprovisionar un volumen y se necesitarán varios reintentos de planificación. + +El seguimiento de la capacidad de almacenamiento es compatible con los controladores de la {{< glossary_tooltip +text="Interfaz de Almacenamiento de Contenedores" term_id="csi" >}} (CSI) y +[necesita estar habilitado](#enabling-storage-capacity-tracking) al instalar un controlador CSI. + + + +## API + +Hay dos extensiones de API para esta función: + +- Los objetos CSIStorageCapacity: + son producidos por un controlador CSI en el Namespace donde está instalado el controlador. Cada objeto contiene información de capacidad para una clase de almacenamiento y define qué nodos tienen acceso a ese almacenamiento. +- [El campo `CSIDriverSpec.StorageCapacity`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): + cuando se establece en `true`, el [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) considerará la capacidad de almacenamiento para los volúmenes que usan el controlador CSI. + +## Planificación + +El planificador de Kubernetes utiliza la información sobre la capacidad de almacenamiento si: + +- la Feature gate de `CSIStorageCapacity` es `true`, +- un Pod usa un volumen que aún no se ha creado, +- ese volumen usa un {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} que hace referencia a un controlador CSI y usa el [modo de enlace de volumen] (/docs/concepts/storage/storage-classes/#volume-binding-mode)`WaitForFirstConsumer`, + y +- el objeto `CSIDriver` para el controlador tiene `StorageCapacity` establecido en `true`. + +En ese caso, el planificador sólo considera los nodos para el Pod que tienen suficiente almacenamiento disponible. Esta verificación es muy simplista y solo compara el tamaño del volumen con la capacidad indicada en los objetos `CSIStorageCapacity` con una topología que incluye el nodo. + +Para los volúmenes con el modo de enlace de volumen `Immediate`, el controlador de almacenamiento decide dónde crear el volumen, independientemente de los pods que usarán el volumen. +Luego, el planificador programa los pods en los nodos donde el volumen está disponible después de que se haya creado. + +Para los [volúmenes efímeros de CSI](/docs/concepts/storage/volumes/#csi), +la planificación siempre ocurre sin considerar la capacidad de almacenamiento. Esto se basa en la suposición de que este tipo de volumen solo lo utilizan controladores CSI especiales que son locales a un nodo y no necesitan allí recursos importantes. + +## Replanificación + +Cuando se selecciona un nodo para un Pod con volúmenes `WaitForFirstConsumer`, esa decisión sigue siendo tentativa. El siguiente paso es que se le pide al controlador de almacenamiento CSI que cree el volumen con una pista de que el volumen está disponible en el nodo seleccionado. + +Debido a que Kubernetes pudo haber elegido un nodo basándose en información de capacidad desactualizada, es posible que el volumen no se pueda crear realmente. Luego, la selección de nodo se restablece y el planificador de Kubernetes intenta nuevamente encontrar un nodo para el Pod. + +## Limitaciones + +El seguimiento de la capacidad de almacenamiento aumenta las posibilidades de que la planificación funcione en el primer intento, pero no puede garantizarlo porque el planificador tiene que decidir basándose en información potencialmente desactualizada. Por lo general, el mismo mecanismo de reintento que para la planificación sin información de capacidad de almacenamiento es manejado por los errores de planificación. + +Una situación en la que la planificación puede fallar de forma permanente es cuando un pod usa varios volúmenes: es posible que un volumen ya se haya creado en un segmento de topología que luego no tenga suficiente capacidad para otro volumen. La intervención manual es necesaria para recuperarse de esto, por ejemplo, aumentando la capacidad o eliminando el volumen que ya se creó. [ +Trabajo adicional](https://github.com/kubernetes/enhancements/pull/1703) para manejar esto automáticamente. + +## Habilitación del seguimiento de la capacidad de almacenamiento + +El seguimiento de la capacidad de almacenamiento es una función beta y está habilitada de forma predeterminada en un clúster de Kubernetes desde Kubernetes 1.21. Además de tener la función habilitada en el clúster, un controlador CSI también tiene que admitirlo. Consulte la documentación del controlador para obtener más detalles. + +## {{% heading "whatsnext" %}} + +- Para obtener más información sobre el diseño, consulte las + [Restricciones de Capacidad de Almacenamiento para la Planificación de Pods KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md). +- Para obtener más información sobre un mayor desarrollo de esta función, consulte [problema de seguimiento de mejoras #1472](https://github.com/kubernetes/enhancements/issues/1472). +- Aprender sobre [Planificador de Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) diff --git a/content/es/docs/concepts/storage/volume-pvc-datasource.md b/content/es/docs/concepts/storage/volume-pvc-datasource.md new file mode 100644 index 0000000000..dcb2690d0e --- /dev/null +++ b/content/es/docs/concepts/storage/volume-pvc-datasource.md @@ -0,0 +1,66 @@ +--- +reviewers: + - edithturn + - raelga + - electrocucaracha +title: Clonación de volumen CSI +content_type: concept +weight: 30 +--- + + + +Este documento describe el concepto para clonar volúmenes CSI existentes en Kubernetes. Se sugiere estar familiarizado con [Volúmenes](/docs/concepts/storage/volumes). + + + +## Introducción + +La función de clonación de volumen {{< glossary_tooltip text="CSI" term_id="csi" >}} agrega soporte para especificar {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s existentes en el campo `dataSource` para indicar que un usuario desea clonar un {{< glossary_tooltip term_id="volume" >}}. + +Un Clon se define como un duplicado de un volumen de Kubernetes existente que se puede consumir como lo sería cualquier volumen estándar. La única diferencia es que al aprovisionar, en lugar de crear un "nuevo" Volumen vacío, el dispositivo de backend crea un duplicado exacto del Volumen especificado. + +La implementación de la clonación, desde la perspectiva de la API de Kubernetes, agrega la capacidad de especificar un PVC existente como dataSource durante la creación de un nuevo PVC. El PVC de origen debe estar vinculado y disponible (no en uso). + +Los usuarios deben tener en cuenta lo siguiente cuando utilicen esta función: + +- El soporte de clonación (`VolumePVCDataSource`) sólo está disponible para controladores CSI. +- El soporte de clonación sólo está disponible para aprovisionadores dinámicos. +- Los controladores CSI pueden haber implementado o no la funcionalidad de clonación de volúmenes. +- Sólo puede clonar un PVC cuando existe en el mismo Namespace que el PVC de destino (el origen y el destino deben estar en el mismo Namespace). +- La clonación sólo se admite dentro de la misma Clase de Almacenamiento. + - El volumen de destino debe ser de la misma clase de almacenamiento que el origen + - Se puede utilizar la clase de almacenamiento predeterminada y se puede omitir storageClassName en la especificación +- La clonación sólo se puede realizar entre dos volúmenes que usan la misma configuración de VolumeMode (si solicita un volumen en modo de bloqueo, la fuente DEBE también ser en modo de bloqueo) + +## Aprovisionamiento + +Los clones se aprovisionan como cualquier otro PVC con la excepción de agregar un origen de datos que hace referencia a un PVC existente en el mismo Namespace. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: clone-of-pvc-1 + namespace: myns +spec: + accessModes: + - ReadWriteOnce + storageClassName: cloning + resources: + requests: + storage: 5Gi + dataSource: + kind: PersistentVolumeClaim + name: pvc-1 +``` + +{{< note >}} +Debe especificar un valor de capacidad para `spec.resources.requests.storage` y el valor que especifique debe ser igual o mayor que la capacidad del volumen de origen. +{{< /note >}} + +El resultado es un nuevo PVC con el nombre `clone-of-pvc-1` que tiene exactamente el mismo contenido que la fuente especificada `pvc-1`. + +## Uso + +Una vez disponible el nuevo PVC, el PVC clonado se consume igual que el resto de PVC. También se espera en este punto que el PVC recién creado sea un objeto independiente. Se puede consumir, clonar, tomar snapshots, o eliminar de forma independiente y sin tener en cuenta sus datos originales. Esto también implica que la fuente no está vinculada de ninguna manera al clon recién creado, también puede modificarse o eliminarse sin afectar al clon recién creado. diff --git a/content/es/docs/tasks/tools/included/_index.md b/content/es/docs/tasks/tools/included/_index.md new file mode 100644 index 0000000000..dda878fac7 --- /dev/null +++ b/content/es/docs/tasks/tools/included/_index.md @@ -0,0 +1,6 @@ +--- +title: "Herramientas incluidas" +description: "Fragmentos que se incluirán en las páginas principales de kubectl-installs-*." +headless: true +toc_hide: true +--- \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/install-kubectl-linux.md b/content/es/docs/tasks/tools/included/install-kubectl-linux.md new file mode 100644 index 0000000000..de189f3ab3 --- /dev/null +++ b/content/es/docs/tasks/tools/included/install-kubectl-linux.md @@ -0,0 +1,244 @@ +--- +reviewers: +title: Instalar y configurar kubectl en Linux +content_type: task +weight: 10 +card: + name: tasks + weight: 20 + title: Instalar kubectl en Linux +--- + +## {{% heading "prerequisites" %}} + +Debes usar una versión de kubectl que esté dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v{{< skew latestVersion >}} puede comunicarse con v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, y v{{< skew nextMinorVersion >}} del plano de control. +El uso de la última versión de kubectl ayuda a evitar problemas inesperados. + +## Instalar kubectl en Linux + +Existen los siguientes métodos para instalar kubectl en Linux: + +- [Instalar el binario kubectl con curl en Linux](#install-kubectl-binary-with-curl-on-linux) +- [Instalar usando la administración nativa de paquetes](#install-using-native-package-management) +- [Instalar usando otra administración de paquetes](#install-using-other-package-management) + +### Instale el binario kubectl con curl en Linux + +1. Descargue la última versión con el comando: + + ```bash + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" + ``` + + {{< note >}} +Para descargar una versión específica, reemplace la parte de `$(curl -L -s https://dl.k8s.io/release/stable.txt)` del comando con la versión específica. + +Por ejemplo, para descargar la versión {{< param "fullversion" >}} en Linux, escriba: + + ```bash + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl + ``` + {{< /note >}} + +1. Validar el binario (opcional) + + Descargue el archivo de comprobación de kubectl: + + ```bash + curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256" + ``` + + Valide el binario kubectl con el archivo de comprobación: + + ```bash + echo "$(}} + Descargue la misma versión del binario y el archivo de comprobación. + {{< /note >}} + +1. Instalar kubectl + + ```bash + sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl + ``` + + {{< note >}} + Si no tiene acceso de root en el sistema de destino, aún puede instalar kubectl en el `~/.local/bin` directorio: + + ```bash + chmod +x kubectl + mkdir -p ~/.local/bin/kubectl + mv ./kubectl ~/.local/bin/kubectl + # y luego agregue ~/.local/bin/kubectl en el $PATH + ``` + + {{< /note >}} + +1. Para asegurarse de que la versión que instaló este actualizada ejecute: + + ```bash + kubectl version --client + ``` + +### Instalar usando la administración nativa de paquetes + +{{< tabs name="kubectl_install" >}} +{{% tab name="Debian-based distributions" %}} + +1. Actualice el índice de paquetes de `apt` e instale los paquetes necesarios para usar Kubernetes con el repositorio `apt`: + + ```shell + sudo apt-get update + sudo apt-get install -y apt-transport-https ca-certificates curl + ``` + +2. Descargue la clave de firma pública de Google Cloud: + + ```shell + sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg + ``` + +3. Agregue el repositorio de Kubernetes a `apt`: + + ```shell + echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list + ``` + +4. Actualice el índice de paquetes de `apt` con el nuevo repositorio e instale kubectl: + + ```shell + sudo apt-get update + sudo apt-get install -y kubectl + ``` + +{{% /tab %}} + +{{< tab name="Red Hat-based distributions" codelang="bash" >}} +cat < /etc/yum.repos.d/kubernetes.repo +[kubernetes] +name=Kubernetes +baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64 +enabled=1 +gpgcheck=1 +repo_gpgcheck=1 +gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg +EOF +yum install -y kubectl +{{< /tab >}} +{{< /tabs >}} + +### Instalar usando otra administración de paquetes + +{{< tabs name="other_kubectl_install" >}} +{{% tab name="Snap" %}} +Si está en Ubuntu u otra distribución de Linux que admita el administrador de paquetes [snap](https://snapcraft.io/docs/core/install), kubectl estará disponible como solicitud de [snap](https://snapcraft.io/). + +```shell +snap install kubectl --classic +kubectl version --client +``` + +{{% /tab %}} + +{{% tab name="Homebrew" %}} +Si está en Linux y usa [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) como administrador de paquetes, kubectl está disponible para [instalación](https://docs.brew.sh/Homebrew-on-Linux#install). + +```shell +brew install kubectl +kubectl version --client +``` + +{{% /tab %}} + +{{< /tabs >}} + +## Verificar la configuración de kubectl + +{{< include "verify-kubectl.md" >}} + +## Plugins y configuraciones opcionales de kubectl + +### Habilitar el autocompletado de shell + +kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al interactuar con la herramienta. + +A continuación, se muestran los procedimientos para configurar el autocompletado para Bash y Zsh. + +{{< tabs name="kubectl_autocompletion" >}} +{{< tab name="Bash" include="optional-kubectl-configs-bash-linux.md" />}} +{{< tab name="Zsh" include="optional-kubectl-configs-zsh.md" />}} +{{< /tabs >}} + +### Instalar en pc `kubectl convert` plugin + +{{< include "kubectl-convert-overview.md" >}} + +1. Descargue la última versión con el comando: + + ```bash + curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert + ``` + +1. Valide el binario (opcional) + + Descargue el archivo de comprobación kubectl-convert: + + ```bash + curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256" + ``` + + Valide el binario kubectl-convert con el archivo de comprobación: + + ```bash + echo "$(}} + Descargue la misma versión del binario y el archivo de comprobación. + {{< /note >}} + +1. Instale kubectl-convert en pc + + ```bash + sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert + ``` + +1. Verifique que el plugin se haya instalado correctamente + + ```shell + kubectl convert --help + ``` + + Si no ve un error, significa que el plugin se instaló correctamente. + +## {{% heading "whatsnext" %}} + +{{< include "kubectl-whats-next.md" >}} \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/install-kubectl-macos.md b/content/es/docs/tasks/tools/included/install-kubectl-macos.md new file mode 100644 index 0000000000..71642b7ff1 --- /dev/null +++ b/content/es/docs/tasks/tools/included/install-kubectl-macos.md @@ -0,0 +1,248 @@ +--- +reviewers: +title: Instalar y configurar kubectl en macOS +content_type: task +weight: 10 +card: + name: tasks + weight: 20 + title: Instalar kubectl en macOS +--- + +## {{% heading "prerequisites" %}} + +Debes usar una versión de kubectl que esté dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v{{< skew latestVersion >}} puede comunicarse con v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, y v{{< skew nextMinorVersion >}} del plano de control. +El uso de la última versión de kubectl ayuda a evitar problemas imprevistos. + +## Instalar kubectl en macOS + +Existen los siguientes métodos para instalar kubectl en macOS: + +- [Instalar el binario de kubectl con curl en macOS](#install-kubectl-binary-with-curl-on-macos) +- [Instalar con Homebrew en macOS](#install-with-homebrew-on-macos) +- [Instalar con Macports en macOS](#install-with-macports-on-macos) + +### Instalar el binario de kubectl con curl en macOS + +1. Descargue la última versión: + + {{< tabs name="download_binary_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl" + {{< /tab >}} + {{< /tabs >}} + + {{< note >}} + Para descargar una versión específica, reemplace el `$(curl -L -s https://dl.k8s.io/release/stable.txt)` parte del comando con la versión específica. + + Por ejemplo, para descargar la versión {{< param "fullversion" >}} en Intel macOS, escriba: + + ```bash + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl" + ``` + + Y para macOS en Apple Silicon, escriba: + + ```bash + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/arm64/kubectl" + ``` + + {{< /note >}} + +1. Validar el binario (opcional) + + Descargue el archivo de comprobación de kubectl: + + {{< tabs name="download_checksum_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256" + {{< /tab >}} + {{< /tabs >}} + + Valide el binario kubectl con el archivo de comprobación: + + ```bash + echo "$(}} + Descargue la misma versión del binario y el archivo de comprobación. + {{< /note >}} + +1. Hacer ejecutable el binario de kubectl. + + ```bash + chmod +x ./kubectl + ``` + +1. Mueva el binario kubectl a una ubicación de archivo en su sistema `PATH`. + + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl + sudo chown root: /usr/local/bin/kubectl + ``` + + {{< note >}} + Asegúrese de que `/usr/local/bin` se encuentre definida en su variable de entorno PATH. + {{< /note >}} + +1. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute: + + ```bash + kubectl version --client + ``` + +### Instalar con Homebrew en macOS + +Si está en macOS y usa [Homebrew](https://brew.sh/) como administrador de paquetes, puede instalar kubectl con Homebrew. + +1. Ejecute el comando de instalación: + + ```bash + brew install kubectl + ``` + + or + + ```bash + brew install kubernetes-cli + ``` + +1. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute: + + ```bash + kubectl version --client + ``` + +### Instalar con Macports en macOS + +Si está en macOS y usa [Macports](https://macports.org/) como administrador de paquetes, puede instalar kubectl con Macports. + +1. Ejecute el comando de instalación: + + ```bash + sudo port selfupdate + sudo port install kubectl + ``` + +1. Para asegurarse de que la versión que instaló se encuentra actualizada, ejecute: + + ```bash + kubectl version --client + ``` + +## Verificar la configuración de kubectl + +{{< include "verify-kubectl.md" >}} + +## Plugins y configuraciones opcionales de kubectl + +### Habilitar el autocompletado de shell + +kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al escribir. + +A continuación, se muestran los procedimientos para configurar el autocompletado para Bash y Zsh. + +{{< tabs name="kubectl_autocompletion" >}} +{{< tab name="Bash" include="optional-kubectl-configs-bash-mac.md" />}} +{{< tab name="Zsh" include="optional-kubectl-configs-zsh.md" />}} +{{< /tabs >}} + +### Instalar el plugin `kubectl-convert` + +{{< include "kubectl-convert-overview.md" >}} + +1. Descargue la última versión con el comando: + + {{< tabs name="download_convert_binary_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert" + {{< /tab >}} + {{< /tabs >}} + +1. Validar el binario (opcional) + + Descargue el archivo de comprobación de kubectl: + + {{< tabs name="download_convert_checksum_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256" + {{< /tab >}} + {{< /tabs >}} + + Valide el binario kubectl-convert con el archivo de comprobación: + + ```bash + echo "$(}} + Descargue la misma versión del binario y el archivo de comprobación. + {{< /note >}} + +1. Hacer ejecutable el binario de kubectl-convert + + ```bash + chmod +x ./kubectl-convert + ``` + +1. Mueva el binario kubectl-convert a una ubicación de archivo en su sistema `PATH`. + + ```bash + sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert + sudo chown root: /usr/local/bin/kubectl-convert + ``` + + {{< note >}} + Asegúrese de que `/usr/local/bin` se encuentre definida en su variable de entorno PATH. + {{< /note >}} + +1. Verifique que el complemento se haya instalado correctamente + + ```shell + kubectl convert --help + ``` + + Si no ve algun error, significa que el complemento se instaló correctamente. + +## {{% heading "whatsnext" %}} + +{{< include "kubectl-whats-next.md" >}} \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/install-kubectl-windows.md b/content/es/docs/tasks/tools/included/install-kubectl-windows.md new file mode 100644 index 0000000000..427d0bcc75 --- /dev/null +++ b/content/es/docs/tasks/tools/included/install-kubectl-windows.md @@ -0,0 +1,190 @@ +--- +reviewers: +title: Instalar y configurar kubectl en Windows +content_type: task +weight: 10 +card: + name: tasks + weight: 20 + title: Instalar kubectl en Windows +--- + +## {{% heading "prerequisites" %}} + +Debes usar una versión de kubectl que este dentro de una diferencia de versión menor de tu clúster. Por ejemplo, un cliente v{{< skew latestVersion >}} puede comunicarse con versiones v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, y v{{< skew nextMinorVersion >}} del plano de control. + +El uso de la última versión de kubectl ayuda a evitar problemas imprevistos. + +## Instalar kubectl en Windows + +Existen los siguientes métodos para instalar kubectl en Windows: + +- [Instalar el binario de kubectl con curl en Windows](#install-kubectl-binary-with-curl-on-windows) +- [Instalar en Windows usando Chocolatey o Scoop](#install-on-windows-using-chocolatey-or-scoop) + + +### Instalar el binario de kubectl con curl en Windows + +1. Descarga la [última versión {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). + + O si tiene `curl` instalado, use este comando: + + ```powershell + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ``` + + {{< note >}} + Para conocer la última versión estable (por ejemplo, para secuencias de comandos), eche un vistazo a [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt). + {{< /note >}} + +1. Validar el binario (opcional) + + Descargue el archivo de comprobación de kubectl: + + ```powershell + curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256 + ``` + + Valide el binario kubectl con el archivo de comprobación: + + - Usando la consola del sistema para comparar manualmente la salida de `CertUtil` con el archivo de comprobación descargado: + + ```cmd + CertUtil -hashfile kubectl.exe SHA256 + type kubectl.exe.sha256 + ``` + + - Usando PowerShell puede automatizar la verificación usando el operador `-eq` para obtener un resultado de `True` o `False`: + + ```powershell + $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256) + ``` + +1. Agregue el binario a su `PATH`. + +1. Para asegurar que la versión de`kubectl` es la misma que descargada, ejecute: + + ```cmd + kubectl version --client + ``` + +{{< note >}} +[Docker Desktop para Windows](https://docs.docker.com/docker-for-windows/#kubernetes) agrega su propia versión de `kubectl` a el `PATH`. +Si ha instalado Docker Desktop antes, es posible que deba colocar su entrada en el `PATH` antes de la agregada por el instalador de Docker Desktop o elimine el `kubectl`. +{{< /note >}} + +### Instalar en Windows usando Chocolatey o Scoop + +1. Para instalar kubectl en Windows, puede usar [Chocolatey](https://chocolatey.org) +como administrador de paquetes o el instalador [Scoop](https://scoop.sh) desde línea de comandos. + + {{< tabs name="kubectl_win_install" >}} + {{% tab name="choco" %}} + ```powershell + choco install kubernetes-cli + ``` + {{% /tab %}} + {{% tab name="scoop" %}} + ```powershell + scoop install kubectl + ``` + {{% /tab %}} + {{< /tabs >}} + + +1. Para asegurarse de que la versión que instaló esté actualizada, ejecute: + + ```powershell + kubectl version --client + ``` + +1. Navegue a su directorio de inicio: + + ```powershell + # Si estas usando cmd.exe, correr: cd %USERPROFILE% + cd ~ + ``` + +1. Cree el directorio `.kube`: + + ```powershell + mkdir .kube + ``` + +1. Cambie al directorio `.kube` que acaba de crear: + + ```powershell + cd .kube + ``` + +1. Configure kubectl para usar un clúster de Kubernetes remoto: + + ```powershell + New-Item config -type file + ``` + +{{< note >}} +Edite el archivo de configuración con un editor de texto de su elección, como el Bloc de notas. +{{< /note >}} + +## Verificar la configuración de kubectl + +{{< include "verify-kubectl.md" >}} + +## Plugins y configuraciones opcionales de kubectl + +### Habilitar el autocompletado de shell + +kubectl proporciona soporte de autocompletado para Bash y Zsh, lo que puede ahorrarle mucho tiempo al escribir. + +A continuación se muestran los procedimientos para configurar el autocompletado para Zsh, si lo está ejecutando en Windows. + +{{< include "optional-kubectl-configs-zsh.md" >}} + +### Instalar el plugin `kubectl-convert` + +{{< include "kubectl-convert-overview.md" >}} + +1. Descargue la última versión con el comando: + + ```powershell + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe + ``` + +1. Validar el binario (opcional) + + Descargue el archivo de comprobación kubectl-convert: + + ```powershell + curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256 + ``` + + Valide el binario kubectl-convert con el archivo de comprobación: + + - Usando la consola del sistema puede comparar manualmente la salida de `CertUtil` con el archivo de comprobación descargado: + + ```cmd + CertUtil -hashfile kubectl-convert.exe SHA256 + type kubectl-convert.exe.sha256 + ``` + + - Usando PowerShell puede automatizar la verificación usando el operador `-eq` + para obtener un resultado de `True` o `False`: + + ```powershell + $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) + ``` + +1. Agregue el binario a su `PATH`. + +1. Verifique que el plugin se haya instalado correctamente + + ```shell + kubectl convert --help + ``` + + Si no ve un error, significa que el plugin se instaló correctamente. + +## {{% heading "whatsnext" %}} + +{{< include "kubectl-whats-next.md" >}} \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/kubectl-convert-overview.md b/content/es/docs/tasks/tools/included/kubectl-convert-overview.md new file mode 100644 index 0000000000..8a9da57c43 --- /dev/null +++ b/content/es/docs/tasks/tools/included/kubectl-convert-overview.md @@ -0,0 +1,9 @@ +--- +title: "Descripción general de kubectl-convert" +description: >- + Un plugin de kubectl que le permite convertir manifiestos de una versión +headless: true +--- + +Un plugin para la herramienta de línea de comandos de Kubernetes `kubectl`, que le permite convertir manifiestos entre diferentes versiones de la API. Esto puede ser particularmente útil para migrar manifiestos a una versión no obsoleta de la API con la versión más reciente de Kubernetes. +Para obtener más información, visite [migrar a APIs no obsoletas](/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/kubectl-whats-next.md b/content/es/docs/tasks/tools/included/kubectl-whats-next.md new file mode 100644 index 0000000000..87b3246f6e --- /dev/null +++ b/content/es/docs/tasks/tools/included/kubectl-whats-next.md @@ -0,0 +1,12 @@ +--- +title: "¿Que sigue?" +description: "¿Qué sigue después de instalar kubectl." +headless: true +--- + +* [Instalar Minikube](https://minikube.sigs.k8s.io/docs/start/) +* Consulte las [guías de introducción](/docs/setup/) para obtener más información sobre la creación de clústeres. +* [Aprenda a iniciar y exponer su aplicación.](/docs/tasks/access-application-cluster/service-access-application-cluster/) +* Si necesita acceso a un clúster que no creó, consulte la guia de + [Compartir el acceso al clúster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). +* Lea los [documentos de referencia de kubectl](/docs/reference/kubectl/kubectl/) \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/es/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md new file mode 100644 index 0000000000..fd470c2633 --- /dev/null +++ b/content/es/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -0,0 +1,54 @@ +--- +title: "Autocompletar bash en Linux" +description: "Alguna configuración opcional para la finalización automática de bash en Linux." +headless: true +--- + +### Introducción + +El script de completado de kubectl para Bash se puede generar con el comando `kubectl completion bash`. Obtener el script de completado en su shell habilita el autocompletado de kubectl. + +Sin embargo, el script de completado depende de [**bash-completion**](https://github.com/scop/bash-completion), lo que significa que primero debe instalar este software (puedes probar si tienes bash-completion ya instalado ejecutando `type _init_completion`). + +### Instalar bash-complete + +El completado de bash es proporcionado por muchos administradores de paquetes (ver [aquí](https://github.com/scop/bash-completion#installation)). Puedes instalarlo con `apt-get install bash-completion` o `yum install bash-completion`, etc. + +Los comandos anteriores crean `/usr/share/bash-completion/bash_completion`, que es el script principal de bash-complete. Dependiendo de su administrador de paquetes, debe obtener manualmente este archivo de perfil en su `~/.bashrc`. + +Para averiguarlo, recargue su shell y ejecute `type _init_completion`. Si el comando tiene éxito, ya está configurado; de lo contrario, agregue lo siguiente a su archivo `~/.bashrc`: + +```bash +source /usr/share/bash-completion/bash_completion +``` + +Vuelva a cargar su shell y verifique que la finalización de bash esté correctamente instalada escribiendo `type _init_completion`. + +### Habilitar el autocompletado de kubectl + +Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay dos formas de hacer esto: + +- Obtenga el script de completado en su perfil `~/.bashrc`: + + ```bash + echo 'source <(kubectl completion bash)' >>~/.bashrc + ``` + +- Agregue el script de completado al directorio de `/etc/bash_completion.d`: + + ```bash + kubectl completion bash >/etc/bash_completion.d/kubectl + ``` + +Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias: + +```bash +echo 'alias k=kubectl' >>~/.bashrc +echo 'complete -F __start_kubectl k' >>~/.bashrc +``` + +{{< note >}} +El código fuente de bash-complete todos los scripts se encuentra en `/etc/bash_completion.d`. +{{< /note >}} + +Ambos enfoques son equivalentes. Después de recargar su shell, el autocompletado de kubectl debería estar funcionando. \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md b/content/es/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md new file mode 100644 index 0000000000..5c6dd3d8e6 --- /dev/null +++ b/content/es/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md @@ -0,0 +1,88 @@ +--- +title: "Autocompletar bash en macOS" +description: "Alguna configuración opcional para la finalización automática de bash en macOS." +headless: true +--- + +### Introducción + +El script de completado de kubectl para Bash se puede generar con `kubectl completion bash`. Obtener este script en su shell permite el completado de kubectl. + +Sin embargo, el script de finalización de kubectl depende de [**bash-completion**](https://github.com/scop/bash-completion) que, por lo tanto, debe instalar previamente. + +{{< warning>}} +Hay dos versiones de bash-complete, v1 y v2. V1 es para Bash 3.2 ( +que es el predeterminado en macOS), y v2 es para Bash 4.1+. El script de completado de kubectl **no funciona** correctamente con bash-complete v1 y Bash 3.2. Requiere **bash-complete v2** y **Bash 4.1+**. Por lo tanto, para poder usar correctamente la finalización de kubectl en macOS, debe instalar y usar Bash 4.1+ ([*instrucciones*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). Las siguientes instrucciones asumen que usa Bash 4.1+ (es decir, cualquier versión de Bash de 4.1 o posterior). +{{< /warning >}} + +### Actualizar Bash + +Las siguientes instrucciones asumen que usa Bash 4.1+. Puede verificar la versión de su Bash ejecutando: + +```bash +echo $BASH_VERSION +``` +Si es demasiado antiguo, puede instalarlo o actualizarlo usando Homebrew: + +```bash +brew install bash +``` +Vuelva a cargar su shell y verifique que se esté utilizando la versión deseada: + +```bash +echo $BASH_VERSION $SHELL +``` + +Homebrew generalmente lo instala en `/usr/local/bin/bash`. + +### Instalar bash-complete + +{{< note >}} +Como se mencionó antes, estas instrucciones asumen que usa Bash 4.1+, lo que significa que instalará bash-completacion v2 (a diferencia de Bash 3.2 y bash-deployment v1, en cuyo caso el completado de kubectl no funcionará). +{{< /note >}} + +Puede probar si ya tiene instalado bash-complete v2 con `type _init_completion`. Si no es así, puede instalarlo con Homebrew: + +```bash +brew install bash-completion@2 +``` + +Como se indica en el resultado de este comando, agregue lo siguiente a su archivo `~/.bash_profile`: + +```bash +export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" +[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" +``` + +Vuelva a cargar su shell y verifique que bash-complete v2 esté instalado correctamente con `type _init_completion`. + +### Habilitar el autocompletado de kubectl + +Ahora debe asegurarse de que el script de completado de kubectl se obtenga en todas sus sesiones de shell. Hay varias formas de lograrlo: + +- Obtenga el script de finalización en su perfil `~/.bash_profile`: + + ```bash + echo 'source <(kubectl completion bash)' >>~/.bash_profile + ``` + +- Agregue el script de completado al directorio `/usr/local/etc/bash_completion.d`: + + ```bash + kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl + ``` + +- Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias: + + ```bash + echo 'alias k=kubectl' >>~/.bash_profile + echo 'complete -F __start_kubectl k' >>~/.bash_profile + ``` + +- Si instaló kubectl con Homebrew (como se explica [aquí](/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)), entonces el script de completado de kubectl ya debería estar en `/usr/local/etc/bash_completion.d/kubectl`. En ese caso, no necesita hacer nada. + + {{< note >}} + La instalación de Homebrew de bash-completion v2 genera todos los archivos en el directorio `BASH_COMPLETION_COMPAT_DIR`, es por eso que los dos últimos métodos funcionan. + {{< /note >}} + +En cualquier caso, después de recargar su shell, el completado de kubectl debería estar funcionando. \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/optional-kubectl-configs-zsh.md b/content/es/docs/tasks/tools/included/optional-kubectl-configs-zsh.md new file mode 100644 index 0000000000..9a8d586c28 --- /dev/null +++ b/content/es/docs/tasks/tools/included/optional-kubectl-configs-zsh.md @@ -0,0 +1,29 @@ +--- +title: "Autocompletar zsh" +description: "Alguna configuración opcional para la finalización automática de zsh." +headless: true +--- + +El script de completado de kubectl para Zsh se puede generar con el comando `kubectl completion zsh`. Obtener el script de completado en su shell habilita el autocompletado de kubectl. + +Para hacerlo en todas sus sesiones de shell, agregue lo siguiente a su perfil `~/.zshrc`: + +```zsh +source <(kubectl completion zsh) +``` +Si tiene un alias para kubectl, puede extender el completado del shell para trabajar con ese alias: + +```zsh +echo 'alias k=kubectl' >>~/.zshrc +echo 'compdef __start_kubectl k' >>~/.zshrc +``` + +Después de recargar su shell, el autocompletado de kubectl debería estar funcionando. + +Si recibe un error como `complete:13: command not found: compdef`, +luego agregue lo siguiente al comienzo de su perfil `~/.zshrc`: + +```zsh +autoload -Uz compinit +compinit +``` \ No newline at end of file diff --git a/content/es/docs/tasks/tools/included/verify-kubectl.md b/content/es/docs/tasks/tools/included/verify-kubectl.md new file mode 100644 index 0000000000..15bd90692c --- /dev/null +++ b/content/es/docs/tasks/tools/included/verify-kubectl.md @@ -0,0 +1,31 @@ +--- +title: "verificar la instalación de kubectl" +description: "Cómo verificar kubectl." +headless: true +--- + +Para que kubectl encuentre y acceda a un clúster de Kubernetes, necesita un +[archivo kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), que se crea automáticamente cuando creas un clúster usando +[kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) +o implementar con éxito un clúster de Minikube. +De forma predeterminada, la configuración de kubectl se encuentra en `~/.kube/config`. + +Verifique que kubectl esté configurado correctamente obteniendo el estado del clúster: + +```shell +kubectl cluster-info +``` +Si ve una respuesta de URL, kubectl está configurado correctamente para acceder a su clúster. + +Si ve un mensaje similar al siguiente, kubectl no está configurado correctamente o no puede conectarse a un clúster de Kubernetes. +``` +The connection to the server was refused - did you specify the right host or port? +``` + +Por ejemplo, si tiene la intención de ejecutar un clúster de Kubernetes en su computadora portátil (localmente), primero necesitará instalar una herramienta como Minikube y luego volver a ejecutar los comandos indicados anteriormente. + +Si kubectl cluster-info devuelve la respuesta de la URL pero no puede acceder a su clúster, para verificar si está configurado correctamente, use: + +```shell +kubectl cluster-info dump +``` \ No newline at end of file diff --git a/content/es/docs/tasks/tools/install-kubectl.md b/content/es/docs/tasks/tools/install-kubectl.md deleted file mode 100644 index acc140d425..0000000000 --- a/content/es/docs/tasks/tools/install-kubectl.md +++ /dev/null @@ -1,515 +0,0 @@ ---- -title: Instalar y Configurar kubectl -content_type: task -weight: 10 -card: - name: tasks - weight: 20 - title: Instalar kubectl ---- - - -Usa la herramienta de línea de comandos de Kubernetes, [kubectl](/docs/reference/kubectl/kubectl/), para desplegar y gestionar aplicaciones en Kubernetes. Usando kubectl, puedes inspeccionar recursos del clúster; crear, eliminar, y actualizar componentes; explorar tu nuevo clúster; y arrancar aplicaciones de ejemplo. Para ver la lista completa de operaciones de kubectl, se puede ver [el resumen de kubectl](/docs/reference/kubectl/overview/). - - -## {{% heading "prerequisites" %}} - -Debes usar una versión de kubectl que esté a menos de una versión menor de diferencia con tu clúster. Por ejemplo, un cliente v1.2 debería funcionar con un máster v1.1, v1.2, y v1.3. Usar la última versión de kubectl ayuda a evitar problemas inesperados. - - - - - -## Instalar kubectl en Linux - -### Instalar el binario de kubectl con curl en Linux - -1. Descargar la última entrega: - - ``` - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" - ``` - -Para descargar una versión específica, remplaza el comando `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` con la versión específica. - -Por ejemplo, para descarga la versión {{< param "fullversion" >}} en Linux, teclea: - - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl - ``` - -2. Habilita los permisos de ejecución del binario `kubectl`. - - ``` - chmod +x ./kubectl - ``` - -3. Mueve el binario dentro de tu PATH. - - ``` - sudo mv ./kubectl /usr/local/bin/kubectl - ``` - -4. Comprueba que la versión que se ha instalado es la más reciente. - - ``` - kubectl version --client - ``` - - -## Instalar mediante el gestor de paquetes del sistema - -{{< tabs name="kubectl_install" >}} -{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}} -sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl -curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - -echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list -sudo apt-get update -sudo apt-get install -y kubectl -{{< /tab >}} - -{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat <}} -{{< /tabs >}} - -### Instalar usando otro gestor de paquetes - -{{< tabs name="other_kubectl_install" >}} -{{% tab name="Snap" %}} -Si usas Ubuntu o alguna de las otras distribuciones de Linux que soportan el gestor de paquetes [snap](https://snapcraft.io/docs/core/install), kubectl está disponible como una aplicación [snap](https://snapcraft.io/). - -```shell -snap install kubectl --classic - -kubectl version --client -``` - -{{% /tab %}} - -{{% tab name="Homebrew" %}} -Si usas alguna de las otras distribuciones de Linux que soportan el gestor de paquetes [Homebrew](https://docs.brew.sh/Homebrew-on-Linux), kubectl está disponible como una aplicación de [Homebrew]((https://docs.brew.sh/Homebrew-on-Linux#install). - -```shell -brew install kubectl - -kubectl version --client -``` - -{{% /tab %}} - -{{< /tabs >}} - - -## Instalar kubectl en macOS - -### Instalar el binario de kubectl usando curl en macOS - -1. Descarga la última entrega: - - ```bash - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" - ``` - - Para descargar una versión específica, remplaza el comando `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` con la versión específica. - - Por ejemplo, para descargar la versión {{< param "fullversion" >}} en macOS, teclea: - - ```bash - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl - ``` - -2. Habilita los permisos de ejecución del binario `kubectl`. - - ```bash - chmod +x ./kubectl - ``` - -3. Mueve el binario dentro de tu PATH. - - ```bash - sudo mv ./kubectl /usr/local/bin/kubectl - ``` - -4. Para asegurar que la versión utilizada sea la más actual puedes probar: - - ```bash - kubectl version --client - ``` - -### Instalar con Homebrew en macOS - -Si estás usando macOS y el gestor de paquetes es [Homebrew](https://brew.sh/), puedes instalar `kubectl` con `brew`. - -1. Ejecuta el comando de instalación: - - ```bash - brew install kubectl - ``` - - o - - ```bash - brew install kubernetes-cli - ``` - -2. Para asegurar que la versión utilizada sea la más actual, puedes ejecutar: - - ```bash - kubectl version --client - ``` - -### Instalar con Macports en macOS - -Si estás en macOS y utilizas el gestor de paquetes [Macports](https://macports.org/), puedes instalar `kubectl` con `port`. - -1. Ejecuta los comandos de instalación: - - ```bash - sudo port selfupdate - sudo port install kubectl - ``` - -2. Para asegurar que la versión utilizada sea la más actual puedes ejecutar: - - ```bash - kubectl version --client - ``` - -# Instalar kubectl en Windows - -### Instalar el binario de kubectl con curl en Windows - -1. Descargar la última entrega {{< param "fullversion" >}} de [este link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). - - o si tiene `curl` instalada, utiliza este comando: - - ```bash - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe - ``` - - Para averiguar la última versión estable (por ejemplo, para secuencias de comandos), echa un vistazo a [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt). - -2. Añade el binario a tu PATH. - -3. Para asegurar que la versión utilizada sea la más actual, puedes ejecutar: - - ```bash - kubectl version --client - ``` - -{{< note >}} -[Docker Desktop para Windows](https://docs.docker.com/docker-for-windows/#kubernetes) añade su propia versión de `kubectl` a PATH. - -Si tienes Docker Desktop instalado, es posible que tengas que modificar tu PATH al PATH añadido por Docker Desktop o eliminar la versión de `kubectl` proporcionada por Docker Desktop. -{{< /note >}} - -### Instalar con Powershell desde PSGallery - -Si estás en Windows y utilizas el gestor de paquetes [Powershell Gallery](https://www.powershellgallery.com/), puedes instalar y actualizar kubectl con Powershell. - -1. Ejecuta los comandos de instalación (asegurándote de especificar una `DownloadLocation`): - - ```powershell - Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation ] - ``` - - {{< note >}}Si no especificas una `DownloadLocation`, `kubectl` se instalará en el directorio temporal del usuario.{{< /note >}} - - El instalador crea `$HOME/.kube` y crea un archivo de configuración - -2. Para asegurar que la versión utilizada sea la más actual puedes probar: - - ```powershell - kubectl version --client - ``` - -{{< note >}} -Actualizar la instalación se realiza mediante la re-ejecución de los dos comandos listados en el paso 1.{{< /note >}} - -### Instalar en Windows usando Chocolatey o scoop - -1. Para instalar kubectl en Windows puedes usar el gestor de paquetes [Chocolatey](https://chocolatey.org) o el instalador de línea de comandos [scoop](https://scoop.sh). - - {{< tabs name="kubectl_win_install" >}} - {{% tab name="choco" %}} -Using [Chocolatey](https://chocolatey.org). - - ```powershell - choco install kubernetes-cli - ``` - {{% /tab %}} - {{% tab name="scoop" %}} -Using [scoop](https://scoop.sh). - - ```powershell - scoop install kubectl - ``` - {{% /tab %}} - {{< /tabs >}} - -2. Para asegurar que la versión utilizada sea la más actual puedes probar: - - ```powershell - kubectl version --client - ``` - -3. Navega a tu directorio de inicio: - - ```powershell - # Si estas usando cmd.exe, ejecuta: cd %USERPROFILE% - cd ~ - ``` - -4. Crea el directorio `.kube`: - - ```powershell - mkdir .kube - ``` - -5. Cambia al directorio `.kube` que acabas de crear: - - ```powershell - cd .kube - ``` - -6. Configura kubectl para usar un clúster remoto de Kubernetes: - - ```powershell - New-Item config -type file - ``` - -{{< note >}}Edita el fichero de configuración con un editor de texto de tu elección, como Notepad.{{< /note >}} - -## Descarga como parte del Google Cloud SDK - -Puedes instalar kubectl como parte del Google Cloud SDK. - -1. Instala el [Google Cloud SDK](https://cloud.google.com/sdk/). -2. Ejecuta el comando de instalación de `kubectl`: - - ```shell - gcloud components install kubectl - ``` - -3. Para asegurar que la versión utilizada sea la más actual puedes probar: - - ```shell - kubectl version --client - ``` - -## Comprobar la configuración kubectl - -Para que kubectl pueda encontrar y acceder a un clúster de Kubernetes, necesita un [fichero kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), que se crea de forma automática cuando creas un clúster usando [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) o despliegas de forma satisfactoria un clúster de Minikube. Revisa las [guías para comenzar](/docs/setup/) para más información acerca de crear clústers. Si necesitas acceso a un clúster que no has creado, ver el [documento de Compartir Acceso a un Clúster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). -Por defecto, la configuración de kubectl se encuentra en `~/.kube/config`. - -Comprueba que kubectl está correctamente configurado obteniendo el estado del clúster: - -```shell -kubectl cluster-info -``` - -Si ves una respuesta en forma de URL, kubectl está correctamente configurado para acceder a tu clúster. - -Si ves un mensaje similar al siguiente, kubectl no está correctamente configurado o no es capaz de conectar con un clúster de Kubernetes. - -``` -The connection to the server was refused - did you specify the right host or port? -``` - -Por ejemplo, si intentas ejecutar un clúster de Kubernetes en tu portátil (localmente), necesitarás una herramienta como minikube que esté instalada primero y entonces volver a ejecutar los comandos indicados arriba. - -Si kubectl cluster-info devuelve la respuesta en forma de url, pero no puedes acceder a tu clúster, para comprobar si está configurado adecuadamente, usa: - -```shell -kubectl cluster-info dump -``` - -## kubectl configuraciones opcionales - -### Habilitar el auto-completado en el intérprete de comandos - -kubectl provee de soporte para auto-completado para Bash y Zsh, ¡que te puede ahorrar mucho uso del teclado! - -Abajo están los procedimientos para configurar el auto-completado para Bash (incluyendo la diferencia entre Linux y macOS) y Zsh. - -{{< tabs name="kubectl_autocompletion" >}} - -{{% tab name="Bash en Linux" %}} - -### Introducción - -La secuencia de comandos de completado de kubectl para Bash puede ser generado con el comando `kubectl completion bash`. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl. - -Sin embargo, la secuencia de comandos de completado depende de [*bash-completion**](https://github.com/scop/bash-completion), lo que significa que tienes que instalar primero este programa (puedes probar si ya tienes bash-completion instalado ejecutando `type _init_completion`). - -### Instalar bash-completion - -bash-completion es ofrecido por muchos gestores de paquetes (ver [aquí](https://github.com/scop/bash-completion#installation)). Puedes instalarlo con `apt-get install bash-completion` o `yum install bash-completion`, etc. - -Los comandos de arriba crean `/usr/share/bash-completion/bash_completion`, que es la secuencia de comandos principal de bash-completion. Dependiendo de tu gestor de paquetes, tienes que correr manualmente este archivo en tu `~/.bashrc`. - -Para averiguarlo, recarga tu intérprete de comandos y ejecuta `type _init_completion`. Si el comando tiene éxito, ya has terminado; si no, añade lo siguiente a tu `~/.bashrc`: - -```shell -source /usr/share/bash-completion/bash_completion -``` - -recarga tu intérprete de comandos y verifica que bash-completion está correctamente instalado tecleando `type _init_completion`. - -### Habilitar el auto-completado de kubectl - -Debes asegurarte que la secuencia de comandos de completado de kubectl corre en todas tus sesiones de tu intérprete de comandos. Hay dos formas en que puedes hacer esto: - -- Corre la secuencia de comandos de completado en tu `~/.bashrc`: - - ```bash - echo 'source <(kubectl completion bash)' >>~/.bashrc - ``` - -- Añade la secuencia de comandos de completado al directorio `/etc/bash_completion.d`: - - ```bash - kubectl completion bash >/etc/bash_completion.d/kubectl - ``` - -Si tienes un alias para `kubectl`, puedes extender los comandos de shell para funcionar con ese alias: - -```bash -echo 'alias k=kubectl' >>~/.bashrc -echo 'complete -F __start_kubectl k' >>~/.bashrc -``` - -{{< note >}} -bash-completion corre todas las secuencias de comandos de completado en `/etc/bash_completion.d`. -{{< /note >}} - -Ambas estrategias son equivalentes. Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería estar funcionando. - -{{% /tab %}} - - -{{% tab name="Bash en macOS" %}} - -### Introducción - -La secuencia de comandos de completado de kubectl para Bash puede generarse con el comando `kubectl completion bash`. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl. - -Sin embargo, la secuencia de comandos de completado depende de [*bash-completion**](https://github.com/scop/bash-completion), lo que significa que tienes que instalar primero este programa (puedes probar si ya tienes bash-completion instalado ejecutando `type _init_completion`). - -{{< warning>}} -macOS incluye Bash 3.2 por defecto. La secuencia de comandos de completado de kubectl requiere Bash 4.1+ y no funciona con Bash 3.2. Una posible alternativa es instalar una nueva versión de Bash en macOS (ver instrucciones [aquí](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). Las instrucciones de abajo sólo funcionan si estás usando Bash 4.1+. -{{< /warning >}} - -### Actualizar bash - -Las instrucciones asumen que usa Bash 4.1+. Puedes comprobar tu versión de bash con: - -```bash -echo $BASH_VERSION -``` - -Si no es 4.1+, puede actualizar bash con Homebrew: - -```bash -brew install bash -``` - -Recarga tu intérprete de comandos y verifica que estás usando la versión deseada: - -```bash -echo $BASH_VERSION $SHELL -``` - -Usualmente, Homebrew lo instala en `/usr/local/bin/bash`. - -### Instalar bash-completion - -Puedes instalar bash-completion con Homebrew: - -```bash -brew install bash-completion@2 -``` - -{{< note >}} -El `@2` simboliza bash-completion 2, que es requerido por la secuencia de comandos de completado de kubectl (no funciona con bash-completion 1). Luego, bash-completion 2 requiere Bash 4.1+, eso es por lo que necesitabas actualizar Bash. -{{< /note >}} - -Como se indicaba en la salida de `brew install` (sección "Caveats"), añade las siguientes líneas a tu `~/.bashrc` o `~/.bash_profile`: - -```bash -export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" -[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh" -``` - -Recarga tu intérprete de comandos y verifica que bash-completion está correctamente instalado tecleando `type _init_completion`. - -### Habilitar el auto-completado de kubectl - -Debes asegurarte que la secuencia de comandos de completado de kubectl corre en todas tus sesiones de tu intérprete de comenados. Hay múltiples formas en que puedes hacer esto: - -- Corre la secuencia de comandos de completado en tu `~/.bashrc`: - - ```shell - echo 'source <(kubectl completion bash)' >>~/.bashrc - - ``` - -- Añade la secuencia de comandos de completado al directorio `/usr/local/etc/bash_completion.d`: - - ```shell - kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl - ``` - -- Si has instalado kubectl con Homebrew (como se explica [aquí](#install-with-homebrew-on-macos)), entonces la secuencia de comandos de completado se instaló automáticamente en `/usr/local/etc/bash_completion.d/kubectl`. En este caso, no tienes que hacer nada. - -{{< note >}} -bash-completion (si se instaló con Homebrew) corre todas las secuencias de comandos de completado en el directorio que se ha puesto en la variable de entorno `BASH_COMPLETION_COMPAT_DIR`. -{{< /note >}} - -Todas las estrategias son equivalentes. Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería funcionar. -{{% /tab %}} - -{{% tab name="Zsh" %}} - -La secuencia de comandos de completado de kubectl para Zsh puede ser generada con el comando `kubectl completion zsh`. Corriendo la secuencia de comandos de completado en tu intérprete de comandos habilita el auto-completado de kubectl. - -Para hacerlo en todas tus sesiones de tu intérprete de comandos, añade lo siguiente a tu `~/.zshrc`: - -```zsh -source <(kubectl completion zsh) -``` - -Si tienes alias para kubectl, puedes extender el completado de intérprete de comandos para funcionar con ese alias. - -```zsh -echo 'alias k=kubectl' >>~/.zshrc -echo 'compdef __start_kubectl k' >>~/.zshrc -``` - -Tras recargar tu intérprete de comandos, el auto-completado de kubectl debería funcionar. - -Si obtienes un error como `complete:13: command not found: compdef`, entonces añade lo siguiente al principio de tu `~/.zshrc`: - -```zsh -autoload -Uz compinit -compinit -``` -{{% /tab %}} -{{< /tabs >}} - -## {{% heading "whatsnext" %}} -* [Instalar Minikube](https://minikube.sigs.k8s.io/docs/start/) -* Ver las [guías](/docs/setup/) para ver mas información sobre como crear clusteres. -* [Aprender cómo lanzar y exponer tu aplicación.](/docs/tasks/access-application-cluster/service-access-application-cluster/). -* Si necesita acceso a un clúster que no se creó, ver el documento de [compartiendo acceso a clúster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). -* Leer ´la documentación de kubectl reference](/docs/reference/kubectl/kubectl/) diff --git a/content/fr/docs/concepts/services-networking/ingress.md b/content/fr/docs/concepts/services-networking/ingress.md index 5a611a6ad7..2699864484 100644 --- a/content/fr/docs/concepts/services-networking/ingress.md +++ b/content/fr/docs/concepts/services-networking/ingress.md @@ -97,7 +97,7 @@ Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a b  est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).  Différents [Ingress controller](/docs/concepts/services-networking/ingress-controllers) prennent en charge différentes annotations. Consultez la documentation du contrôleur Ingress de votre choix pour savoir quelles annotations sont prises en charge. -La [spécification de la ressource Ingress](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) dispose de toutes les informations nécessaires pour configurer un loadbalancer ou un serveur proxy. Plus important encore, il +La [spécification de la ressource Ingress](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) dispose de toutes les informations nécessaires pour configurer un loadbalancer ou un serveur proxy. Plus important encore, il contient une liste de règles d'appariement de toutes les demandes entrantes. La ressource Ingress ne supporte que les règles pour diriger le trafic HTTP. diff --git a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md index 114bcc784b..1c90abcc91 100644 --- a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -59,7 +59,7 @@ Lors de la récupération d'un seul pod par son nom, par exemple `kubectl get po Le formatage peut être contrôlé davantage en utilisant l'opération `range` pour parcourir les éléments individuellement. ```shell -kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort ``` @@ -69,7 +69,7 @@ Pour cibler uniquement les pods correspondant à un label spécifique, utilisez Les éléments suivants correspondent uniquement aux pods avec les labels `app=nginx`. ```shell -kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## Filtrage des images de conteneur de liste par namespace de pod diff --git a/content/id/docs/tasks/administer-cluster/sysctl-cluster.md b/content/id/docs/tasks/administer-cluster/sysctl-cluster.md index 7120f087fa..42acb5d0f5 100644 --- a/content/id/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/id/docs/tasks/administer-cluster/sysctl-cluster.md @@ -55,7 +55,8 @@ Sysctl berikut ini didukung dalam kelompok _safe_: - `kernel.shm_rmid_forced`, - `net.ipv4.ip_local_port_range`, - `net.ipv4.tcp_syncookies`, -- `net.ipv4.ping_group_range` (sejak Kubernetes 1.18). +- `net.ipv4.ping_group_range` (sejak Kubernetes 1.18), +- `net.ipv4.ip_unprivileged_port_start` (sejak Kubernetes 1.22). {{< note >}} Contoh `net.ipv4.tcp_syncookies` bukan merupakan Namespace pada kernel Linux versi 4.4 atau lebih rendah. diff --git a/content/ja/_index.html b/content/ja/_index.html index b0a1005072..203711cdfd 100644 --- a/content/ja/_index.html +++ b/content/ja/_index.html @@ -41,12 +41,12 @@ Kubernetesはオープンソースなので、オンプレミスやパブリッ

- 2020年11月17日-20日のKubeCon NAバーチャルに参加する + 2022年5月16日〜20日のKubeCon EUバーチャルに参加する



- 2021年5月4日-7日のKubeCon EUバーチャルに参加する + 2022年10月24日-28日のKubeCon NAバーチャルに参加する
diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md new file mode 100644 index 0000000000..09e2a5592e --- /dev/null +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -0,0 +1,46 @@ +--- +layout: blog +title: "Don't Panic: Kubernetes and Docker" +date: 2020-12-02 +slug: dont-panic-kubernetes-and-docker +--- + +**著者:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas + +Kubernetesはv1.20より新しいバージョンで、コンテナランタイムとして[Dockerをサポートしません](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)。 + +**パニックを起こす必要はありません。これはそれほど抜本的なものではないのです。** + +概要: ランタイムとしてのDockerは、Kubernetesのために開発された[Container Runtime Interface(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)を利用しているランタイムを選んだ結果としてサポートされなくなります。しかし、Dockerによって生成されたイメージはこれからも、今までもそうだったように、みなさんのクラスターで使用可能です。 + +もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとして今後Dockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたイメージはKubernetesクラスタ上でこれからも動作可能なのです。 + +もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、ワーカーノードがサポート対象のランタイムを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。 +もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダーと確認し、アップグレードのための適切なテストと計画を立ててください。 + +もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど) + +## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 +ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。 + +お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。 +このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスタはDockershimと呼ばれるほかのツールを使い、本当に必要な機能つまりcontainerdを利用してきました。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。今回の変更で実際に行われることというのは、Dockershimを最も早い場合でv1.23のリリースでkubeletから除外することです。その結果として、Dockerのサポートがなくなるということなのです。 +ここで、containerdがDockerに含まれているなら、なぜDockershimが必要なのかと疑問に思われる方もいるでしょう。 + +DockerはCRI([Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/))に準拠していません。もしそうであればshimは必要ないのですが、現実はそうでありません。 +しかし、これは世界の終わりでありません、心配しないでください。みなさんはContainer runtimeをDockerから他のサポート対象であるContainer runtimeに切り替えるだけでよいのです。 + +1つ注意すべきことは、クラスターで行われる処理のなかでDocker socket(`/var/run/docker.sock`)に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょう。このパターンはしばしばDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。[kaniko](https://github.com/GoogleContainerTools/kaniko)、[img](https://github.com/genuinetools/img)、[buildah](https://github.com/containers/buildah)などです。 + +## では開発者にとって、この変更は何を意味するのか。これからもDockerfileを使ってよいのか。これからもDockerでビルドを行ってよいのか。 + +この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょう。 +みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスタの内部で使われているDocker runtimeは関係ありません。これがわかりにくいことは理解しています。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI([Open Container Initiative](https://opencontainers.org/)) Imageと呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかによらず、Kubernetesから見れば同じものなのです。[containerd](https://containerd.io/)も[CRI-O](https://cri-o.io/)も、そのようなImageをPullし、起動することが出来ます。 +これがコンテナの仕様について、共通の仕様を策定している理由なのです。 + +さて、この変更は決定しています。いくつかの問題は発生するかもしてませんが、決して壊滅的なものではなく、ほとんどの場合は良い変化となるでしょう。Kubernetesをどのように使用しているかによりますが、この変更が特に何の影響も及ぼさない人もいるでしょうし、影響がとても少ない場合もあります。長期的に見れば、物事を簡単にするのに役立つものです。 +もし、この問題がまだわかりにくいとしても、心配しないでください。Kubernetesでは多くのものが変化しており、その全てに完璧に精通している人など存在しません。 +経験の多寡や難易度にかかわらず、どんなことでも質問してください。我々の目標は、全ての人が将来の変化について、可能な限りの知識と理解を得られることです。 +このブログが多くの質問の答えとなり、不安を和らげることができればと願っています。 + +別の情報をお探してあれば、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)を参照してください。 diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 74bc641df6..33adb3627c 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -18,7 +18,7 @@ weight: 10 - JSONではなくYAMLを使って設定ファイルを書いてください。これらのフォーマットはほとんどすべてのシナリオで互換的に使用できますが、YAMLはよりユーザーフレンドリーになる傾向があります。 -- 意味がある場合は常に、関連オブジェクトを単一ファイルにグループ化します。多くの場合、1つのファイルの方が管理が簡単です。例として[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml)ファイルを参照してください。 +- 意味がある場合は常に、関連オブジェクトを単一ファイルにグループ化します。多くの場合、1つのファイルの方が管理が簡単です。例として[guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml)ファイルを参照してください。 - 多くの`kubectl`コマンドがディレクトリに対しても呼び出せることも覚えておきましょう。たとえば、設定ファイルのディレクトリで `kubectl apply`を呼び出すことができます。 diff --git a/content/ja/docs/concepts/services-networking/service-traffic-policy.md b/content/ja/docs/concepts/services-networking/service-traffic-policy.md new file mode 100644 index 0000000000..741c38c12a --- /dev/null +++ b/content/ja/docs/concepts/services-networking/service-traffic-policy.md @@ -0,0 +1,57 @@ +--- +title: サービス内部トラフィックポリシー +content_type: concept +weight: 45 +--- + + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +*サービス内部トラフィックポリシー*を使用すると、内部トラフィック制限により、トラフィックが発信されたノード内のエンドポイントにのみ内部トラフィックをルーティングできます。 +ここでの「内部」トラフィックとは、現在のクラスターのPodから発信されたトラフィックを指します。これは、コストを削減し、パフォーマンスを向上させるのに役立ちます。 + + + +## ServiceInternalTrafficPolicyの使用 + +`ServiceInternalTrafficPolicy` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定して、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 +これにより、kube-proxyは、クラスター内部トラフィックにノードローカルエンドポイントのみを使用するようになります。 + +{{< note >}} +特定のServiceのエンドポイントがないノード上のPodの場合、Serviceに他のノードのエンドポイントがある場合でも、Serviceは(このノード上のポッドの)エンドポイントがゼロであるかのように動作します。 +{{< /note >}} + +次の例は、`.spec.internalTrafficPolicy`を`Local`に設定した場合のServiceの様子を示しています： + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + internalTrafficPolicy: Local +``` + +## 使い方 + +kube-proxyは、`spec.internalTrafficPolicy`の設定に基づいて、ルーティング先のエンドポイントをフィルタリングします。 +`spec.internalTrafficPolicy`が`Local`であれば、ノードのローカルエンドポイントにのみルーティングできるようにします。`Cluster`または未設定であればすべてのエンドポイントにルーティングできるようにします。 +`ServiceInternalTrafficPolicy`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、`spec.internalTrafficPolicy`のデフォルトは`Cluster`です。 + +## 制約 + +* Serviceで`externalTrafficPolicy`が`Local`に設定されている場合、サービス内部トラフィックポリシーは使用されません。同じServiceだけではなく、同じクラスター内の異なるServiceで両方の機能を使用することができます。 + +## {{% heading "whatsnext" %}} + +* [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints)を読む +* [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)を読む +* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む diff --git a/content/ja/docs/reference/kubectl/conventions.md b/content/ja/docs/reference/kubectl/conventions.md new file mode 100644 index 0000000000..338c97152a --- /dev/null +++ b/content/ja/docs/reference/kubectl/conventions.md @@ -0,0 +1,58 @@ +--- +title: kubectlの使用規則 +content_type: concept +--- + + +`kubectl`の推奨される使用規則です。 + + + +## 再利用可能なスクリプトでの`kubectl`の使用 + +スクリプトでの安定した出力のために: + +* `-o name`, `-o json`, `-o yaml`, `-o go-template`, `-o jsonpath` などの機械指向の出力形式のいずれかを必要します。 +* バージョンを完全に指定します。例えば、`jobs.v1.batch/myjob`のようにします。これにより、kubectlが時間とともに変化する可能性のあるデフォルトのバージョンを使用しないようにします。 +* コンテキストや設定、その他の暗黙的な状態に頼ってはいけません。 + +## ベストプラクティス + +### `kubectl run` + +`kubectl run`がインフラのコード化を満たすために: + +* イメージにバージョン固有のタグを付けて、そのタグを新しいバージョンに移さない。例えば、`:latest`ではなく、`:v1234`、`v1.2.3`、`r03062016-1-4`を使用してください(詳細は、[Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images)を参照してください)。 +* パラメーターが多用されているイメージをスクリプトでチェックします。 +* `kubectl run` フラグでは表現できない機能を、ソースコントロールでチェックした設定ファイルに切り替えます。 + +`dry-run=client` フラグを使用すると、実際に送信することなく、クラスターに送信されるオブジェクトを確認することができます。 + +{{< note >}} +すべての`kubectl run`ジェネレーターは非推奨です。ジェネレーターの[リスト](https://v1-17.docs.kubernetes.io/docs/reference/kubectl/conventions/#generators)とその使用方法については、Kubernetes v1.17のドキュメントを参照してください。 +{{< /note >}} + +#### Generators +`kubectl create --dry-run=client -o yaml`というkubectlコマンドで以下のリソースを生成することができます。 + +* `clusterrole`: ClusterRoleを作成します。 +* `clusterrolebinding`: 特定のClusterRoleに対するClusterRoleBindingを作成します。 +* `configmap`: ローカルファイル、ディレクトリ、またはリテラル値からConfigMapを作成します。 +* `cronjob`: 指定された名前のCronJobを作成します。 +* `deployment`: 指定された名前でDeploymentを作成します。 +* `job`: 指定された名前でJobを作成します。 +* `namespace`: 指定された名前でNamespaceを作成します。 +* `poddisruptionbudget`: 指定された名前でPodDisruptionBudgetを作成します。 +* `priorityclass`: 指定された名前でPriorityClassを作成します。 +* `quota`: 指定された名前でQuotaを作成します。 +* `role`: 1つのルールでRoleを作成します。 +* `rolebinding`: 特定のロールやClusterRoleに対するRoleBindingを作成します。 +* `secret`: 指定されたサブコマンドを使用してSecretを作成します。 +* `service`: 指定されたサブコマンドを使用してServiceを作成します。 +* `ServiceAccount`: 指定された名前でServiceAccountを作成します。 + +### `kubectl apply` + +* リソースの作成や更新には `kubectl apply` を使用できます。kubectl applyを使ったリソースの更新については、[Kubectl Book](https://kubectl.docs.kubernetes.io)を参照してください。 + + diff --git a/content/ja/docs/reference/using-api/_index.md b/content/ja/docs/reference/using-api/_index.md new file mode 100644 index 0000000000..2dff67b71f --- /dev/null +++ b/content/ja/docs/reference/using-api/_index.md @@ -0,0 +1,114 @@ +--- +title: API概要 +content_type: concept +weight: 10 +no_list: true +card: + name: reference + weight: 50 + title: API概要 +--- + + + +このセクションでは、Kubernetes APIのリファレンス情報を提供します。 + +REST APIはKubernetesの基本的な構造です。 +すべての操作とコンポーネント間のと通信、および外部ユーザーのコマンドは、REST API呼び出しでありAPIサーバーが処理します。 + +その結果、Kubernetesプラットフォーム内のすべてのものは、APIオブジェクトとして扱われ、[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)に対応するエントリーがあります。 + +[Kubernetes APIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)は、Kubernetesバージョン{{< param "version" >}}のAPI一覧を提供します。 + +一般的な背景情報を知るには、[The Kubernetes API](/docs/concepts/overview/kubernetes-api/)、 +[Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/)を読んでください。 +それらはKubernetes APIサーバーがクライアントを認証する方法とリクエストを認可する方法を説明します。 + +## APIバージョニング + +JSONとProtobufなどのシリアル化スキーマの変更については同じガイドラインに従います。 +以下の説明は、両方のフォーマットをカバーしています。 + +APIのバージョニングとソフトウェアのバージョニングは間接的に関係しています。 +[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)は、APIバージョニングとソフトウェアバージョニングの関係を説明しています。 + +APIのバージョンが異なると、安定性やサポートのレベルも異なります。 +各レベルの基準については、[API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)で詳しく説明しています。 + +各レベルの概要は以下の通りです: + +- Alpha: + - バージョン名に「alpha」が含まれています（例：「v1alpha1」）。 + - バグが含まれている可能性があります。 + 機能を有効にするとバグが露呈する可能性があります。 + 機能がデフォルトで無効になっている可能性があります。 + - ある機能のサポートは、予告なしにいつでも中止される可能性があります。 + - 後にリリースされるソフトウェアで、互換性のない方法で予告なく変更される可能性があります。 + - バグのリスクが高く、長期的なサポートが得られないため、短期間のテストクラスターのみでの使用を推奨します。 + +- Beta: + - バージョン名には `beta` が含まれています(例：`v2beta3`)。 + - ソフトウェアは十分にテストされています。 + 機能を有効にすることは安全であると考えられています。 + 機能はデフォルトで有効になっています。 + - 機能のサポートが打ち切られることはありませんが、詳細は変更される可能性があります。 + + - オブジェクトのスキーマやセマンティクスは、その後のベータ版や安定版のリリースで互換性のない方法で変更される可能性があります。 + このような場合には、移行手順が提供されます。 + スキーマの変更に伴い、APIオブジェクトの削除、編集、再作成が必要になる場合があります。 + 編集作業は単純ではないかもしれません。 + 移行に伴い、その機能に依存しているアプリケーションのダウンタイムが必要になる場合があります。 + + - 本番環境での使用は推奨しません。 + 後続のリリース は、互換性のない変更を導入する可能性があります。 + 独立してアップグレード可能な複数のクラスターがある場合、この制限を緩和できる可能性があります。 + + {{< note >}} +ベータ版の機能をお試しいただき、ご意見をお寄せください。 +ベータ版の機能が終了した後はこれ以上の変更ができない場合があります。 + {{< /note >}} + +- Stable: + - バージョン名は `vX` であり、`X` は整数である。 + - 安定版の機能は、リリースされたソフトウェアの中で、その後の多くのバージョンに登場します。 + +## APIグループ + +[API groups](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)で、KubernetesのAPIを簡単に拡張することができます。 +APIグループは、RESTパスとシリアル化されたオブジェクトの`apiVersion`フィールドで指定されます。 + +KubernetesにはいくつかのAPIグループがあります: + +* *core*(*legacy*とも呼ばれる)グループは、RESTパス `/api/v1` にあります。 + コアグループは `apiVersion` フィールドの一部としては指定されません。 + 例えば、`apiVersion: v1` のように。 +* 名前付きのグループは、RESTパス `/apis/$GROUP_NAME/$VERSION` にあり、以下のように使用します。 + `apiVersion: $GROUP_NAME/$VERSION`を使用します(例：`apiVersion: batch/v1`)。 + サポートされているAPIグループの完全なリストは以下にあります。 + [Kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#strong-api-groups-strong-)。 + +## APIグループの有効化と無効化 {#enabling-or-disabling} + +一部のリソースやAPIグループはデフォルトで有効になっています。 +APIサーバー上で`--runtime-config`を設定することで、有効にしたり無効にしたりすることができます。 +また`runtime-config`フラグには、APIサーバーのランタイム構成を記述したコンマ区切りの`[=]`ペアを指定します。 +もし`=`の部分が省略された場合には、`=true`が指定されたものとして扱われます。 + +例えば: + + - `batch/v1`を無効するには、`--runtime-config=batch/v1=false`を設定する + - `batch/v2alpha1`を有効するには、`--runtime-config=batch/v2alpha1`を設定する + +{{< note >}} +グループやリソースを有効または無効にした場合、 +APIサーバーとコントローラマネージャーを再起動して、`--runtime-config`の変更を反映させる必要があります。 +{{< /note >}} + +## 永続化 + +Kubernetesはシリアライズされた状態を、APIリソースとして{{< glossary_tooltip term_id="etcd" >}}に書き込んで保存します。 + +## {{% heading "whatsnext" %}} + +- [API conventions](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/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md index b20a1d77d0..c1eb59241f 100644 --- a/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/ja/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -62,7 +62,7 @@ jsonpathは次のように解釈されます: `range`を使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。 ```shell -kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort ``` @@ -71,7 +71,7 @@ sort 特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、`app=nginx`に一致するラベルを持つPodのみに一致します。 ```shell -kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +kubectl get pods --all-namespaces -o jsonpath="{..image}" -l app=nginx ``` ## Podの名前空間でコンテナイメージ一覧をフィルタリングする {#list-container-images-filtering-by-pod-namespace} diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md new file mode 100644 index 0000000000..ce0e054225 --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -0,0 +1,399 @@ +--- +content_type: concept +title: アプリケーションの自己観察とデバッグ +--- + + + +アプリケーションが稼働すると、必然的にその問題をデバッグする必要が出てきます。 +先に、`kubectl get pods`を使って、Podの簡単なステータス情報を取得する方法を説明しました。 +しかし、アプリケーションに関するより多くの情報を取得する方法がいくつかあります。 + + + +## `kubectl describe pod`を使ってpodの詳細を取得 + +この例では、先ほどの例と同様に、Deploymentを使用して2つのpodを作成します。 + +{{< codenew file="application/nginx-with-request.yaml" >}} + +以下のコマンドを実行して、Deploymentを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml +``` + +```none +deployment.apps/nginx-deployment created +``` + +以下のコマンドでPodの状態を確認します: + +```shell +kubectl get pods +``` + +```none +NAME READY STATUS RESTARTS AGE +nginx-deployment-1006230814-6winp 1/1 Running 0 11s +nginx-deployment-1006230814-fmgu3 1/1 Running 0 11s +``` + +`kubectl describe pod`を使うと、これらのPodについてより多くの情報を得ることができます。 +例えば: + +```shell +kubectl describe pod nginx-deployment-1006230814-6winp +``` + +```none +Name: nginx-deployment-1006230814-6winp +Namespace: default +Node: kubernetes-node-wul5/10.240.0.9 +Start Time: Thu, 24 Mar 2016 01:39:49 +0000 +Labels: app=nginx,pod-template-hash=1006230814 +Annotations: kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1956810328","uid":"14e607e7-8ba1-11e7-b5cb-fa16" ... +Status: Running +IP: 10.244.0.6 +Controllers: ReplicaSet/nginx-deployment-1006230814 +Containers: + nginx: + Container ID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149 + Image: nginx + Image ID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707 + Port: 80/TCP + QoS Tier: + cpu: Guaranteed + memory: Guaranteed + Limits: + cpu: 500m + memory: 128Mi + Requests: + memory: 128Mi + cpu: 500m + State: Running + Started: Thu, 24 Mar 2016 01:39:51 +0000 + Ready: True + Restart Count: 0 + Environment: + Mounts: + /var/run/secrets/kubernetes.io/serviceaccount from default-token-5kdvl (ro) +Conditions: + Type Status + Initialized True + Ready True + PodScheduled True +Volumes: + default-token-4bcbi: + Type: Secret (a volume populated by a Secret) + SecretName: default-token-4bcbi + Optional: false +QoS Class: Guaranteed +Node-Selectors: +Tolerations: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 54s 54s 1 {default-scheduler } Normal Scheduled Successfully assigned nginx-deployment-1006230814-6winp to kubernetes-node-wul5 + 54s 54s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Pulling pulling image "nginx" + 53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Pulled Successfully pulled image "nginx" + 53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Created Created container with docker id 90315cc9f513 + 53s 53s 1 {kubelet kubernetes-node-wul5} spec.containers{nginx} Normal Started Started container with docker id 90315cc9f513 +``` + +ここでは、コンテナ(複数可)とPodに関する構成情報(ラベル、リソース要件など)や、コンテナ(複数可)とPodに関するステータス情報(状態、準備状況、再起動回数、イベントなど)を確認できます。 + +コンテナの状態は、Waiting(待機中)、Running(実行中)、Terminated(終了)のいずれかです。状態に応じて、追加の情報が提供されます。ここでは、Running状態のコンテナについて、コンテナがいつ開始されたかが表示されています。 + +Readyは、コンテナが最後のReadiness Probeに合格したかどうかを示す。(この場合、コンテナにはReadiness Probeが設定されていません。Readiness Probeが設定されていない場合、コンテナは準備が完了した状態であるとみなされます)。 + +Restart Countは、コンテナが何回再起動されたかを示します。この情報は、再起動ポリシーが「always」に設定されているコンテナのクラッシュループを検出するのに役立ちます。 + +現在、Podに関連する条件は、二値のReady条件のみです。これは、Podがリクエストに対応可能であり、マッチングするすべてのサービスのロードバランシングプールに追加されるべきであることを示します。 + +最後に、Podに関連する最近のイベントのログが表示されます。このシステムでは、複数の同一イベントを圧縮して、最初に見られた時刻と最後に見られた時刻、そして見られた回数を示します。"From"はイベントを記録しているコンポーネントを示し、"SubobjectPath"はどのオブジェクト(例: Pod内のコンテナ)が参照されているかを示し、"Reason"と "Message"は何が起こったかを示しています。 + +## 例: Pending Podsのデバッグ + +イベントを使って検出できる一般的なシナリオは、どのノードにも収まらないPodを作成した場合です。例えば、Podがどのノードでも空いている以上のリソースを要求したり、どのノードにもマッチしないラベルセレクターを指定したりする場合です。例えば、各(仮想)マシンが1つのCPUを持つ4ノードのクラスター上で、(2つではなく)5つのレプリカを持ち、500ではなく600ミリコアを要求する前のDeploymentを作成したとします。この場合、Podの1つがスケジュールできなくなります。(なお、各ノードではfluentdやskydnsなどのクラスターアドオンPodが動作しているため、もし1000ミリコアを要求した場合、どのPodもスケジュールできなくなります) + +```shell +kubectl get pods +``` + +```none +NAME READY STATUS RESTARTS AGE +nginx-deployment-1006230814-6winp 1/1 Running 0 7m +nginx-deployment-1006230814-fmgu3 1/1 Running 0 7m +nginx-deployment-1370807587-6ekbw 1/1 Running 0 1m +nginx-deployment-1370807587-fg172 0/1 Pending 0 1m +nginx-deployment-1370807587-fz9sd 0/1 Pending 0 1m +``` + +nginx-deployment-1370807587-fz9sdのPodが実行されていない理由を調べるには、保留中のPodに対して`kubectl describe pod`を使用し、そのイベントを見てみましょう + +```shell +kubectl describe pod nginx-deployment-1370807587-fz9sd +``` + +```none + Name: nginx-deployment-1370807587-fz9sd + Namespace: default + Node: / + Labels: app=nginx,pod-template-hash=1370807587 + Status: Pending + IP: + Controllers: ReplicaSet/nginx-deployment-1370807587 + Containers: + nginx: + Image: nginx + Port: 80/TCP + QoS Tier: + memory: Guaranteed + cpu: Guaranteed + Limits: + cpu: 1 + memory: 128Mi + Requests: + cpu: 1 + memory: 128Mi + Environment Variables: + Volumes: + default-token-4bcbi: + Type: Secret (a volume populated by a Secret) + SecretName: default-token-4bcbi + Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 48s 7 {default-scheduler } Warning FailedScheduling pod (nginx-deployment-1370807587-fz9sd) failed to fit in any node + fit failure on node (kubernetes-node-6ta5): Node didn't have enough resource: CPU, requested: 1000, used: 1420, capacity: 2000 + fit failure on node (kubernetes-node-wul5): Node didn't have enough resource: CPU, requested: 1000, used: 1100, capacity: 2000 +``` + +ここでは、理由 `FailedScheduling` (およびその他の理由)でPodのスケジュールに失敗したという、スケジューラーによって生成されたイベントを見ることができます。このメッセージは、どのノードでもPodに十分なリソースがなかったことを示しています。 + +この状況を修正するには、`kubectl scale`を使用して、4つ以下のレプリカを指定するようにDeploymentを更新します。(あるいは、1つのPodを保留にしたままにしておいても害はありません。) + +`kubectl describe pod`の最後に出てきたようなイベントは、etcdに永続化され、クラスターで何が起こっているかについての高レベルの情報を提供します。 + +すべてのイベントをリストアップするには、次のようにします: + + +```shell +kubectl get events +``` + +しかし、イベントは名前空間に所属することを忘れてはいけません。つまり、名前空間で管理されているオブジェクトのイベントに興味がある場合(例: 名前空間 `my-namespace`のPods で何が起こったか)、コマンドに名前空間を明示的に指定する必要があります。 + +```shell +kubectl get events --namespace=my-namespace +``` + +すべての名前空間からのイベントを見るには、`--all-namespaces` 引数を使用できます。 + +`kubectl describe pod`に加えて、(`kubectl get pod` で提供される以上の)Podに関する追加情報を得るためのもう一つの方法は、`-o yaml`出力形式フラグを `kubectl get pod`に渡すことです。これにより、`kubectl describe pod`よりもさらに多くの情報、つまりシステムが持っているPodに関するすべての情報をYAML形式で得ることができます。ここでは、アノテーション(Kubernetesのシステムコンポーネントが内部的に使用している、ラベル制限のないキーバリューのメタデータ)、再起動ポリシー、ポート、ボリュームなどが表示されます。 + +```shell +kubectl get pod nginx-deployment-1006230814-6winp -o yaml +``` + +```yaml +apiVersion: v1 +kind: Pod +metadata: + annotations: + kubernetes.io/created-by: | + {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-deployment-1006230814","uid":"4c84c175-f161-11e5-9a78-42010af00005","apiVersion":"extensions","resourceVersion":"133434"}} + creationTimestamp: 2016-03-24T01:39:50Z + generateName: nginx-deployment-1006230814- + labels: + app: nginx + pod-template-hash: "1006230814" + name: nginx-deployment-1006230814-6winp + namespace: default + resourceVersion: "133447" + uid: 4c879808-f161-11e5-9a78-42010af00005 +spec: + containers: + - image: nginx + imagePullPolicy: Always + name: nginx + ports: + - containerPort: 80 + protocol: TCP + resources: + limits: + cpu: 500m + memory: 128Mi + requests: + cpu: 500m + memory: 128Mi + terminationMessagePath: /dev/termination-log + volumeMounts: + - mountPath: /var/run/secrets/kubernetes.io/serviceaccount + name: default-token-4bcbi + readOnly: true + dnsPolicy: ClusterFirst + nodeName: kubernetes-node-wul5 + restartPolicy: Always + securityContext: {} + serviceAccount: default + serviceAccountName: default + terminationGracePeriodSeconds: 30 + volumes: + - name: default-token-4bcbi + secret: + secretName: default-token-4bcbi +status: + conditions: + - lastProbeTime: null + lastTransitionTime: 2016-03-24T01:39:51Z + status: "True" + type: Ready + containerStatuses: + - containerID: docker://90315cc9f513c724e9957a4788d3e625a078de84750f244a40f97ae355eb1149 + image: nginx + imageID: docker://6f62f48c4e55d700cf3eb1b5e33fa051802986b77b874cc351cce539e5163707 + lastState: {} + name: nginx + ready: true + restartCount: 0 + state: + running: + startedAt: 2016-03-24T01:39:51Z + hostIP: 10.240.0.9 + phase: Running + podIP: 10.244.0.6 + startTime: 2016-03-24T01:39:49Z +``` + +## 例: ダウン/到達不可能なノードのデバッグ + +例えば、ノード上で動作しているPodのおかしな挙動に気付いたり、Podがノード上でスケジュールされない原因を探ったりと、デバッグ時にノードのステータスを見ることが有用な場合があります。Podと同様に、`kubectl describe node`や`kubectl get node -o yaml`を使ってノードの詳細情報を取得することができます。例えば、ノードがダウンした場合(ネットワークから切断された、またはkubeletが死んで再起動しないなど)に表示される内容は以下の通りです。ノードがNotReadyであることを示すイベントに注目してください。また、Podが実行されなくなっていることにも注目してください(NotReady状態が5分続くと、Podは退避されます)。 + +```shell +kubectl get nodes +``` + +```none +NAME STATUS ROLES AGE VERSION +kubernetes-node-861h NotReady 1h v1.13.0 +kubernetes-node-bols Ready 1h v1.13.0 +kubernetes-node-st6x Ready 1h v1.13.0 +kubernetes-node-unaj Ready 1h v1.13.0 +``` + +```shell +kubectl describe node kubernetes-node-861h +``` + +```none +Name: kubernetes-node-861h +Role +Labels: kubernetes.io/arch=amd64 + kubernetes.io/os=linux + kubernetes.io/hostname=kubernetes-node-861h +Annotations: node.alpha.kubernetes.io/ttl=0 + volumes.kubernetes.io/controller-managed-attach-detach=true +Taints: +CreationTimestamp: Mon, 04 Sep 2017 17:13:23 +0800 +Phase: +Conditions: + Type Status LastHeartbeatTime LastTransitionTime Reason Message + ---- ------ ----------------- ------------------ ------ ------- + OutOfDisk Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + MemoryPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + DiskPressure Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. + Ready Unknown Fri, 08 Sep 2017 16:04:28 +0800 Fri, 08 Sep 2017 16:20:58 +0800 NodeStatusUnknown Kubelet stopped posting node status. +Addresses: 10.240.115.55,104.197.0.26 +Capacity: + cpu: 2 + hugePages: 0 + memory: 4046788Ki + pods: 110 +Allocatable: + cpu: 1500m + hugePages: 0 + memory: 1479263Ki + pods: 110 +System Info: + Machine ID: 8e025a21a4254e11b028584d9d8b12c4 + System UUID: 349075D1-D169-4F25-9F2A-E886850C47E3 + Boot ID: 5cd18b37-c5bd-4658-94e0-e436d3f110e0 + Kernel Version: 4.4.0-31-generic + OS Image: Debian GNU/Linux 8 (jessie) + Operating System: linux + Architecture: amd64 + Container Runtime Version: docker://1.12.5 + Kubelet Version: v1.6.9+a3d1dfa6f4335 + Kube-Proxy Version: v1.6.9+a3d1dfa6f4335 +ExternalID: 15233045891481496305 +Non-terminated Pods: (9 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- +...... +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 900m (60%) 2200m (146%) 1009286400 (66%) 5681286400 (375%) +Events: +``` + +```shell +kubectl get node kubernetes-node-861h -o yaml +``` + +```yaml +apiVersion: v1 +kind: Node +metadata: + creationTimestamp: 2015-07-10T21:32:29Z + labels: + kubernetes.io/hostname: kubernetes-node-861h + name: kubernetes-node-861h + resourceVersion: "757" + uid: 2a69374e-274b-11e5-a234-42010af0d969 +spec: + externalID: "15233045891481496305" + podCIDR: 10.244.0.0/24 + providerID: gce://striped-torus-760/us-central1-b/kubernetes-node-861h +status: + addresses: + - address: 10.240.115.55 + type: InternalIP + - address: 104.197.0.26 + type: ExternalIP + capacity: + cpu: "1" + memory: 3800808Ki + pods: "100" + conditions: + - lastHeartbeatTime: 2015-07-10T21:34:32Z + lastTransitionTime: 2015-07-10T21:35:15Z + reason: Kubelet stopped posting node status. + status: Unknown + type: Ready + nodeInfo: + bootID: 4e316776-b40d-4f78-a4ea-ab0d73390897 + containerRuntimeVersion: docker://Unknown + kernelVersion: 3.16.0-0.bpo.4-amd64 + kubeProxyVersion: v0.21.1-185-gffc5a86098dc01 + kubeletVersion: v0.21.1-185-gffc5a86098dc01 + machineID: "" + osImage: Debian GNU/Linux 7 (wheezy) + systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E +``` + + + +## {{% heading "whatsnext" %}} + +以下のような追加のデバッグツールについて学びます: + +* [Logging](/docs/concepts/cluster-administration/logging/) +* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) +* [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/) +* [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/) +* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) +* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/) diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-application.md b/content/ja/docs/tasks/debug-application-cluster/debug-application.md new file mode 100644 index 0000000000..b9be05c3f7 --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/debug-application.md @@ -0,0 +1,142 @@ +--- +title: アプリケーションのトラブルシューティング +content_type: concept +--- + + + +このガイドは、Kubernetesにデプロイされ、正しく動作しないアプリケーションをユーザーがデバッグするためのものです。 +これは、自分のクラスターをデバッグしたい人のためのガイドでは *ありません*。 +そのためには、[debug-cluster](/docs/tasks/debug-application-cluster/debug-cluster)を確認する必要があります。 + + + +## 問題の診断 + +トラブルシューティングの最初のステップは切り分けです。何が問題なのでしょうか？ +Podなのか、レプリケーションコントローラーなのか、それともサービスなのか？ + + * [Debugging Pods](#debugging-pods) + * [Debugging Replication Controllers](#debugging-replication-controllers) + * [Debugging Services](#debugging-services) + +### Podのデバッグ + +デバッグの第一歩は、Podを見てみることです。 +以下のコマンドで、Podの現在の状態や最近のイベントを確認します。 + +```shell +kubectl describe pods ${POD_NAME} +``` + +Pod内のコンテナの状態を見てください。 +すべて`Running`ですか？ 最近、再起動がありましたか？ +Podの状態に応じてデバッグを続けます。 + +#### PodがPendingのまま + +Podが`Pending`で止まっている場合、それはノードにスケジュールできないことを意味します。 +一般に、これはある種のリソースが不十分で、スケジューリングできないことが原因です。 +上の`kubectl describe ...`コマンドの出力を見てください。 + +なぜあなたのPodをスケジュールできないのか、スケジューラーからのメッセージがあるはずです。 +理由は以下の通りです。 + +* **リソースが不足しています。** クラスターのCPUまたはメモリーを使い果たしている可能性があります。Podを削除するか、リソースの要求値を調整するか、クラスターに新しいノードを追加する必要があります。詳しくは[Compute Resources document](/ja/docs/concepts/configuration/manage-resources-containers/)を参照してください。 + +* **あなたが使用しているのは`hostPort`**です。Podを`hostPort`にバインドすると、そのPodがスケジュールできる場所が限定されます。ほとんどの場合、`hostPort`は不要なので、Serviceオブジェクトを使ってPodを公開するようにしてください。もし`hostPort` が必要な場合は、Kubernetesクラスターのノード数だけPodをスケジュールすることができます。 + + +#### Podがwaitingのまま + +Podが`Waiting`状態で止まっている場合、ワーカーノードにスケジュールされていますが、そのノード上で実行することができません。この場合も、`kubectl describe ...`の情報が参考になるはずです。`Waiting`状態のPodの最も一般的な原因は、コンテナイメージのプルに失敗することです。 + +確認すべきことは3つあります。 + +* イメージの名前が正しいかどうか確認してください。 +* イメージをレジストリにプッシュしましたか？ +* あなたのマシンで手動で`docker pull `を実行し、イメージをプルできるかどうか確認してください。 + +#### Podがクラッシュするなどの不健全な状態 + +Podがスケジュールされると、[Debug Running Pods](/docs/tasks/debug-application-cluster/debug-running-pod/)で説明されている方法がデバッグに利用できるようになります。 + +#### Podが期待する通りに動きません + +Podが期待した動作をしない場合、ポッドの記述(ローカルマシンの `mypod.yaml` ファイルなど)に誤りがあり、Pod作成時にその誤りが黙って無視された可能性があります。Pod記述のセクションのネストが正しくないか、キー名が間違って入力されていることがよくあり、そのようなとき、そのキーは無視されます。たとえば、`command`のスペルを`commnd`と間違えた場合、Podは作成されますが、あなたが意図したコマンドラインは使用されません。 + +まずPodを削除して、`--validate` オプションを付けて再度作成してみてください。 +例えば、`kubectl apply --validate -f mypod.yaml`と実行します。 +`command`のスペルを`commnd`に間違えると、以下のようなエラーになります。 + +```shell +I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd +I0805 10:43:25.129973 46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842 +pods/mypod +``` + + + +次に確認することは、apiserver上のPodが、作成しようとしたPod(例えば、ローカルマシンのyamlファイル)と一致しているかどうかです。 +例えば、`kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml` を実行して、元のポッドの説明である`mypod.yaml`とapiserverから戻ってきた`mypod-on-apiserver.yaml`を手動で比較してみてください。 +通常、"apiserver" バージョンには、元のバージョンにはない行がいくつかあります。これは予想されることです。 +しかし、もし元のバージョンにある行がapiserverバージョンにない場合、これはあなたのPod specに問題があることを示している可能性があります。 + +### レプリケーションコントローラーのデバッグ + +レプリケーションコントローラーはかなり単純なものです。 +彼らはPodを作ることができるか、できないか、どちらかです。 +もしPodを作成できないのであれば、[上記の説明](#debugging-pods)を参照して、Podをデバッグしてください。 +また、`kubectl describe rc ${CONTROLLER_NAME}`を使用すると、レプリケーションコントローラーに関連するイベントを確認することができます。 + +### Serviceのデバッグ + +Serviceは、Podの集合全体でロードバランシングを提供します。 +Serviceが正しく動作しない原因には、いくつかの一般的な問題があります。 + +以下の手順は、Serviceの問題をデバッグするのに役立つはずです。 + +まず、Serviceに対応するEndpointが存在することを確認します。 +全てのServiceオブジェクトに対して、apiserverは `endpoints` リソースを利用できるようにします。 +このリソースは次のようにして見ることができます。 + +```shell +kubectl get endpoints ${SERVICE_NAME} +``` + +EndpointがServiceのメンバーとして想定されるPod数と一致していることを確認してください。 +例えば、3つのレプリカを持つnginxコンテナ用のServiceであれば、ServiceのEndpointには3つの異なるIPアドレスが表示されるはずです。 + +#### Serviceに対応するEndpointがありません + +Endpointが見つからない場合は、Serviceが使用しているラベルを使用してPodをリストアップしてみてください。 +ラベルがあるところにServiceがあると想像してください。 + +```yaml +... +spec: + - selector: + name: nginx + type: frontend +``` + +セレクタに一致するPodを一覧表示するには、次のコマンドを使用します。 + +```shell +kubectl get pods --selector=name=nginx,type=frontend +``` + +リストがServiceを提供する予定のPodと一致することを確認します。 +Podの`containerPort`がServiceの`targetPort`と一致することを確認します。 + +#### ネットワークトラフィックが転送されません + +詳しくは[Serviceのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-service/)を参照してください。 + +## {{% heading "whatsnext" %}} + +上記のいずれの方法でも問題が解決しない場合は、以下の手順に従ってください。 +[Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)で、`Service` が実行されていること、`Endpoints`があること、`Pods`が実際にサービスを提供していること、DNS が機能していること、IPtablesルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。 + +[トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)に詳細が記載されています。 + diff --git a/content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md new file mode 100644 index 0000000000..006dfcd1d8 --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -0,0 +1,62 @@ +--- +title: リソースメトリクスパイプライン +content_type: concept +--- + + + +Kubernetesでは、コンテナのCPU使用率やメモリ使用率といったリソース使用量のメトリクスが、メトリクスAPIを通じて提供されています。これらのメトリクスは、ユーザーが`kubectl top`コマンドで直接アクセスするか、クラスター内のコントローラー(例えばHorizontal Pod Autoscaler)が判断するためにアクセスすることができます。 + + + +## メトリクスAPI + +メトリクスAPIを使用すると、指定したノードやPodが現在使用しているリソース量を取得することができます。 +このAPIはメトリックの値を保存しないので、例えば10分前に指定されたノードが使用したリソース量を取得することはできません。 + +メトリクスAPIは他のAPIと何ら変わりはありません。 + +- 他のKubernetes APIと同じエンドポイントを経由して、`/apis/metrics.k8s.io/`パスの下で発見できます。 +- 同じセキュリティ、スケーラビリティ、信頼性の保証を提供します。 + +メトリクスAPIは[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)リポジトリで定義されています。 +メトリクスAPIについての詳しい情報はそちらをご覧ください。 + +{{< note >}} +メトリクスAPIを使用するには、クラスター内にメトリクスサーバーが配置されている必要があります。そうでない場合は利用できません。 +{{< /note >}} + +## リソース使用量の測定 + +### CPU + +CPUは、一定期間の平均使用量を[CPU cores](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)という単位で報告されます。 +この値は、カーネルが提供する累積CPUカウンターの比率を取得することで得られます(LinuxとWindowsの両カーネルで)。 +kubeletは、比率計算のためのウィンドウを選択します。 + +### メモリ + +メモリは、測定値が収集された時点のワーキングセットとして、バイト単位で報告されます。 +理想的な世界では、「ワーキングセット」は、メモリ不足で解放できない使用中のメモリ量です。 +しかし、ワーキングセットの計算はホストOSによって異なり、一般に推定値を生成するために経験則を多用しています。 +Kubernetesはスワップをサポートしていないため、すべての匿名(非ファイルバックアップ)メモリが含まれます。 +ホストOSは常にそのようなページを再請求することができないため、メトリックには通常、一部のキャッシュされた(ファイルバックされた)メモリも含まれます。 + +## メトリクスサーバー + +[メトリクスサーバー](https://github.com/kubernetes-sigs/metrics-server)は、クラスター全体のリソース使用量データのアグリゲーターです。 +デフォルトでは、`kube-up.sh`スクリプトで作成されたクラスターにDeploymentオブジェクトとしてデプロイされます。 +別のKubernetesセットアップ機構を使用する場合は、提供される[deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases)ファイルを使用してデプロイすることができます。 +メトリクスサーバーは、Summary APIからメトリクスを収集します。 +各ノードの[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)から[Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)経由でメインAPIサーバーに登録されるようになっています。 + +メトリクスサーバーについては、[Design proposals](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/metrics-server.md)で詳しく解説しています。 + + +### Summary APIソース + +[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)は、ノード、ボリューム、Pod、コンテナレベルの統計情報を収集し、[Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)で省略して消費者が読めるようにするものです。 + +1.23以前は、これらのリソースは主に[cAdvisor](https://github.com/google/cadvisor)から収集されていました。しかし、1.23では`PodAndContainerStatsFromCRI`フィーチャーゲートの導入により、コンテナとPodレベルの統計情報をCRI実装で収集することができます。 + +注意: これはCRI実装によるサポートも必要です(containerd >= 1.6.0, CRI-O >= 1.23.0)。 diff --git a/content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md new file mode 100644 index 0000000000..68c0841038 --- /dev/null +++ b/content/ja/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -0,0 +1,41 @@ +--- +content_type: concept +title: リソース監視のためのツール +--- + + + +アプリケーションを拡張し、信頼性の高いサービスを提供するために、デプロイ時にアプリケーションがどのように動作するかを理解する必要があります。 +コンテナ、[Pod](/docs/concepts/workloads/pods/)、[Service](/docs/concepts/services-networking/service/)、クラスター全体の特性を調べることにより、Kubernetesクラスターのアプリケーションパフォーマンスを調査することができます。 +Kubernetesは、これらの各レベルでアプリケーションのリソース使用に関する詳細な情報を提供します。 +この情報により、アプリケーションのパフォーマンスを評価し、ボトルネックを取り除くことで全体のパフォーマンスを向上させることができます。 + + + +Kubernetesでは、アプリケーションの監視は1つの監視ソリューションに依存することはありません。 +新しいクラスターでは、[リソースメトリクス](#resource-metrics-pipeline)または[フルメトリクス](#full-metrics-pipeline)パイプラインを使用してモニタリング統計を収集することができます。 + +## リソースメトリクスパイプライン + +リソースメトリックパイプラインは、[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)コントローラーなどのクラスターコンポーネントや、`kubectl top`ユーティリティに関連する限定的なメトリックセットを提供します。 + +これらのメトリクスは軽量、短期、インメモリーの[metrics-server](https://github.com/kubernetes-sigs/metrics-server)によって収集され、`metrics.k8s.io` APIを通じて公開されます。 + +metrics-serverはクラスター上のすべてのノードを検出し +各ノードの[kubelet](/docs/reference/command-line-tools-reference/kubelet/)にCPUとメモリーの使用量を問い合わせます。 + +kubeletはKubernetesマスターとノードの橋渡し役として、マシン上で動作するPodやコンテナを管理する。 +kubeletは各Podを構成するコンテナに変換し、コンテナランタイムインターフェースを介してコンテナランタイムから個々のコンテナ使用統計情報を取得します。この情報は、レガシーDocker統合のための統合cAdvisorから取得されます。 + +そして、集約されたPodリソース使用統計情報を、metrics-server Resource Metrics APIを通じて公開します。 +このAPIは、kubeletの認証済みおよび読み取り専用ポート上の `/metrics/resource/v1beta1` で提供されます。 + +## フルメトリクスパイプライン + +フルメトリクスパイプラインは、より豊富なメトリクスにアクセスすることができます。 +Kubernetesは、Horizontal Pod Autoscalerなどのメカニズムを使用して、現在の状態に基づいてクラスターを自動的にスケールまたは適応させることによって、これらのメトリクスに対応することができます。 +モニタリングパイプラインは、kubeletからメトリクスを取得し、`custom.metrics.k8s.io` または `external.metrics.k8s.io` APIを実装してアダプタ経由でKubernetesにそれらを公開します。 +CNCFプロジェクトの[Prometheus](https://prometheus.io)は、Kubernetes、ノード、Prometheus自身をネイティブに監視することができます。 +CNCFに属さない完全なメトリクスパイプラインのプロジェクトは、Kubernetesのドキュメントの範囲外です。 + + diff --git a/content/ko/_index.html b/content/ko/_index.html index e5c54b6a8a..0925f2ef7e 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -30,7 +30,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 {{% blocks/feature image="suitcase" %}} #### K8s를 어디서나 실행 -쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. +쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는 데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. {{% /blocks/feature %}} @@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준

- Attend KubeCon Europe on May 17-20, 2022 + KubeCon Europe (2022년 5월 17~20일) 참가하기



- Attend KubeCon North America on October 24-28, 2022 + KubeCon North America (2022년 10월 24~28일) 참가하기
diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 9666cd4a14..30ede236bc 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -19,6 +19,7 @@ cid: community
+기여자 커뮤니티      커뮤니티 가치      행동 강령       비디오      diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index e5e7d315c5..eccfe091ce 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -44,10 +44,10 @@ weight: 40 ### 노드 컨트롤러 노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 {{< glossary_tooltip text="노드" term_id="node" >}} -오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 +오브젝트를 업데이트하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다. -1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다. +1. 클라우드 공급자 API를 통해 획득한 해당 서버의 고유 ID를 노드 오브젝트에 업데이트한다. 2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를 사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다. 3. 노드의 호스트 이름과 네트워크 주소를 가져온다. diff --git a/content/ko/docs/concepts/architecture/cri.md b/content/ko/docs/concepts/architecture/cri.md new file mode 100644 index 0000000000..69175432d1 --- /dev/null +++ b/content/ko/docs/concepts/architecture/cri.md @@ -0,0 +1,50 @@ +--- +title: 컨테이너 런타임 인터페이스(CRI) +content_type: concept +weight: 50 +--- + + + +컨테이너 런타임 인터페이스(CRI)는 클러스터 컴포넌트를 다시 컴파일하지 않아도 Kubelet이 다양한 +컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스다. + +클러스터의 모든 노드에 동작 중인 +{{}}이 존재해야, +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 +{{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을 +구동할 수 있다. + +{{< glossary_definition term_id="container-runtime-interface" length="all" >}} + + + +## API {#api} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Kubelet은 gRPC를 통해 컨테이너 런타임과 연결할 때 클라이언트의 역할을 수행한다. +런타임과 이미지 서비스 엔드포인트는 컨테이너 런타임 내에서 사용 가능해야 하며, +이는 각각 Kubelet 내에서 `--image-service-endpoint`와 `--container-runtime-endpoint` +[커맨드라인 플래그](/docs/reference/command-line-tools-reference/kubelet) +를 통해 설정할 수 있다. + +쿠버네티스 v{{< skew currentVersion >}}에서는, Kubelet은 CRI `v1`을 사용하는 것을 권장한다. +컨테이너 런타임이 CRI `v1` 버전을 지원하지 않는다면, +Kubelet은 지원 가능한 이전 지원 버전으로 협상을 시도한다. +또한 v{{< skew currentVersion >}} Kubelet은 CRI `v1alpha2`버전도 협상할 수 있지만, +해당 버전은 사용 중단(deprecated)으로 간주한다. +Kubelet이 지원되는 CRI 버전을 협상할 수 없는 경우, +Kubelet은 협상을 포기하고 노드로 등록하지 않는다. + +## 업그레이드 + +쿠버네티스를 업그레이드할 때, Kubelet은 컴포넌트의 재시작 시점에서 최신 CRI 버전을 자동으로 선택하려고 시도한다. +이 과정이 실패하면 위에서 언급한 대로 이전 버전을 선택하는 과정을 거친다. +컨테이너 런타임이 업그레이드되어 gRPC 재다이얼이 필요하다면, +컨테이너 런타임도 처음에 선택된 버전을 지원해야 하며, +그렇지 못한 경우 재다이얼은 실패하게 될 것이다. 이 과정은 Kubelet의 재시작이 필요하다. + +## {{% heading "whatsnext" %}} + +- CRI [프로토콜 정의](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)를 자세히 알아보자. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index c71462d9b3..86a9856b47 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -385,7 +385,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. -## 그레이스풀(Graceful) 노드 셧다운 {#graceful-node-shutdown} +## 그레이스풀(Graceful) 노드 셧다운(shutdown) {#graceful-node-shutdown} {{< feature-state state="beta" for_k8s_version="v1.21" >}} @@ -402,7 +402,7 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 제어된다. 기본적으로, 아래 설명된 두 구성 옵션, -`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, +`shutdownGracePeriod` 및 `shutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, 그레이스풀 노드 셧다운 기능이 활성화되지 않는다. 기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다. @@ -412,32 +412,116 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다. 그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다. -* `ShutdownGracePeriod`: +* `shutdownGracePeriod`: * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다. -* `ShutdownGracePeriodCriticalPods`: - * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다. +* `shutdownGracePeriodCriticalPods`: + * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `shutdownGracePeriod` 보다 작아야 한다. -예를 들어, `ShutdownGracePeriod=30s`, -`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 +예를 들어, `shutdownGracePeriod=30s`, +`shutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의 유예 종료에 할당되고, 마지막 10초는 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다. {{< note >}} -그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다. -`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Shutdown`으로 표시된다. +그레이스풀 노드 셧다운 과정에서 축출된 파드는 셧다운(shutdown)된 것으로 표시된다. +`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Terminated`으로 표시된다. 그리고 `kubectl describe pod` 명령을 실행하면 노드 셧다운으로 인해 파드가 축출되었음을 알 수 있다. ``` -Status: Failed -Reason: Shutdown -Message: Node is shutting, evicting pods +Reason: Terminated +Message: Pod was terminated in response to imminent node shutdown. ``` -실패한 파드 오브젝트는 명시적으로 삭제하거나 [가비지 콜렉션에 의해 정리](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)되기 전까지는 보존된다. -이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다. {{< /note >}} +### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown} + +{{< feature-state state="alpha" for_k8s_version="v1.23" >}} + +그레이스풀 노드 셧다운 시 파드 셧다운 순서에 더 많은 유연성을 제공할 수 있도록, +클러스터에 프라이어리티클래스(PriorityClass) 기능이 활성화되어 있으면 +그레이스풀 노드 셧다운 과정에서 파드의 프라이어리티클래스가 고려된다. +이 기능으로 그레이스풀 노드 셧다운 시 파드가 종료되는 순서를 클러스터 관리자가 +[프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스) +기반으로 명시적으로 정할 수 있다. + +위에서 기술된 것처럼, [그레이스풀 노드 셧다운](#graceful-node-shutdown) 기능은 파드를 +중요하지 않은(non-critical) 파드와 +중요한(critical) 파드 2단계(phase)로 구분하여 종료시킨다. +셧다운 시 파드가 종료되는 순서를 명시적으로 더 상세하게 정해야 한다면, +파드 우선순위 기반 그레이스풀 노드 셧다운을 사용할 수 있다. + +그레이스풀 노드 셧다운 과정에서 파드 우선순위가 고려되기 때문에, +그레이스풀 노드 셧다운이 여러 단계로 일어날 수 있으며, +각 단계에서 특정 프라이어리티 클래스의 파드를 종료시킨다. +정확한 단계와 단계별 셧다운 시간은 kubelet에 설정할 수 있다. + +다음과 같이 클러스터에 커스텀 파드 +[프라이어리티 클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)가 있다고 +가정하자. + +|파드 프라이어리티 클래스 이름|파드 프라이어리티 클래스 값| +|-------------------------|------------------------| +|`custom-class-a` | 100000 | +|`custom-class-b` | 10000 | +|`custom-class-c` | 1000 | +|`regular/unset` | 0 | + +[kubelet 환경 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 안의 +`shutdownGracePeriodByPodPriority` 설정은 다음과 같을 수 있다. + +|파드 프라이어리티 클래스 값|종료 대기 시간| +|------------------------|---------------| +| 100000 |10 seconds | +| 10000 |180 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + +이를 나타내는 kubelet 환경 설정 YAML은 다음과 같다. + +```yaml +shutdownGracePeriodByPodPriority: + - priority: 100000 + shutdownGracePeriodSeconds: 10 + - priority: 10000 + shutdownGracePeriodSeconds: 180 + - priority: 1000 + shutdownGracePeriodSeconds: 120 + - priority: 0 + shutdownGracePeriodSeconds: 60 +``` + +위의 표에 의하면 우선순위 값이 100000 이상인 파드는 종료까지 10초만 주어지며, +10000 이상 ~ 100000 미만이면 180초, +1000 이상 ~ 10000 미만이면 120초가 주어진다. +마지막으로, 다른 모든 파드는 종료까지 60초가 주어질 것이다. + +모든 클래스에 대해 값을 명시할 필요는 없다. +예를 들어, 대신 다음과 같은 구성을 사용할 수도 있다. + +|파드 프라이어리티 클래스 값|종료 대기 시간| +|------------------------|---------------| +| 100000 |300 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + + +위의 경우, custom-class-b에 속하는 파드와 custom-class-c에 속하는 파드는 +동일한 종료 대기 시간을 갖게 될 것이다. + +특정 범위에 해당되는 파드가 없으면, +kubelet은 해당 범위에 해당되는 파드를 위해 기다려 주지 않는다. +대신, kubelet은 즉시 다음 프라이어리티 클래스 값 범위로 넘어간다. + +기능이 활성화되어 있지만 환경 설정이 되어 있지 않으면, +순서 지정 동작이 수행되지 않을 것이다. + +이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority` 기능 게이트를 활성화해야 하고, +kubelet 환경 설정의 `ShutdownGracePeriodByPodPriority`를 +파드 프라이어리티 클래스 값과 +각 값에 대한 종료 대기 시간을 명시하여 지정해야 한다. + ## 스왑(swap) 메모리 관리 {#swap-memory} {{< feature-state state="alpha" for_k8s_version="v1.22" >}} @@ -451,6 +535,11 @@ kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 [구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가 false로 지정되어야 한다. +{{< warning >}} +메모리 스왑 기능이 활성화되면, 시크릿 오브젝트의 내용과 같은 +tmpfs에 기록되었던 쿠버네티스 데이터가 디스크에 스왑될 수 있다. +{{< /warning >}} + 사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, 이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면, diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 2c06588988..75ccfabb2d 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -25,7 +25,7 @@ content_type: concept * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. -* Multus 는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다. +* Multus는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. @@ -45,6 +45,11 @@ content_type: concept ## 인프라스트럭처 * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다. +* [node problem detector](https://github.com/kubernetes/node-problem-detector)는 + 리눅스 노드에서 실행되며, + 시스템 이슈를 + [이벤트](/docs/reference/kubernetes-api/cluster-resources/event-v1/) 또는 + [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition) 형태로 보고한다. ## 레거시 애드온 diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index 5922bf3ef3..d916a09105 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -64,7 +64,7 @@ weight: 50 VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다. -이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. +이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. 비슷하게, 사용자가 선택한 네트워킹 옵션이 [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/)을 지원할 수도 있으며, 구현 방법은 다양할 수 있다. `Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를 요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은 @@ -169,49 +169,6 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네 충족하는 매우 간단한 오버레이 네트워크이다. 많은 경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다. -### Google 컴퓨트 엔진(GCE) - -Google 컴퓨트 엔진 클러스터 구성 스크립트의 경우, [고급 -라우팅](https://cloud.google.com/vpc/docs/routes)을 사용하여 -각 VM에 서브넷을 할당한다(기본값은 `/24` - 254개 IP). 해당 서브넷에 바인딩된 -모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이는 -아웃 바운드 인터넷 접근을 위해 NAT로 구성된 VM에 할당된 "기본" -IP 주소에 추가된다. 리눅스 브릿지(`cbr0`)는 해당 서브넷에 존재하도록 -구성되며, 도커의 `--bridge` 플래그로 전달된다. - -도커는 다음의 설정으로 시작한다. - -```shell -DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" -``` - -이 브릿지는 노드의 `.spec.podCIDR`에 따라 Kubelet(`--network-plugin=kubenet` -플래그로 제어되는)에 의해 생성된다. - -도커는 이제 `cbr-cidr` 블록에서 IP를 할당한다. 컨테이너는 `cbr0` 브릿지를 -통해 서로 `Node` 에 도달할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크 -내에서 라우팅할 수 있다. - -그러나, GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로, 아웃 바운드 인터넷 트래픽을 위해 -IP를 NAT하지 않는다. 그것을 달성하기 위해 iptables 규칙을 사용하여 -GCE 프로젝트 네트워크(10.0.0.0/8) 외부의 IP에 바인딩된 트래픽을 -마스커레이드(일명 SNAT - 마치 패킷이 `Node` 자체에서 온 것처럼 -보이게 함)한다. - -```shell -iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE -``` - -마지막으로 커널에서 IP 포워딩이 활성화되어 있으므로, 커널은 브릿지된 컨테이너에 -대한 패킷을 처리한다. - -```shell -sysctl net.ipv4.ip_forward=1 -``` - -이 모든 것의 결과는 모든 `Pod` 가 서로에게 도달할 수 있고 인터넷으로 트래픽을 -송신할 수 있다는 것이다. - ### 재규어(Jaguar) [재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다. @@ -246,7 +203,7 @@ Lars Kellogg-Stedman이 제공하는 ### Multus(멀티 네트워크 플러그인) -Multus 는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. +Multus는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK 및 VPP](https://github.com/intel/vhost-user-net-plugin) 워크로드를 지원한다. @@ -260,12 +217,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https:// [NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만 -오버레이 네트워크를 구축하는 복잡한 방법이다. 이것은 네트워킹 분야의 몇몇 -"대형 벤더"에 의해 승인되었다. - ### OVN(오픈 버추얼 네트워킹) OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 @@ -274,10 +225,6 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에 특정 쿠버네티스 플러그인 및 문서가 있다. -### 로마나 - -[로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. - ### Weaveworks의 위브넷 [위브넷](https://www.weave.works/products/weave-net/)은 diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index fa7ec69fc9..78e7ecfba6 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -74,8 +74,7 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 수량이다. 이것은 [API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및 [서비스](/ko/docs/concepts/services-networking/service/)와 같은 API 리소스는 -쿠버네티스 API 서버를 통해 읽고 수정할 수 -있는 오브젝트이다. +쿠버네티스 API 서버를 통해 읽고 수정할 수 있는 오브젝트이다. ## 파드와 컨테이너의 리소스 요청 및 제한 @@ -100,9 +99,10 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다. 쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다. -분수의 요청이 허용된다. -`0.5` 의 `spec.containers[].resources.requests.cpu` 요청을 가진 -컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은 +요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의 +`spec.containers[].resources.requests.cpu`를 `0.5`로 설정한다는 것은, +`1.0` CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다. +CPU 자원의 단위와 관련하여, `0.1` 이라는 표현은 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다. `0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, @@ -115,12 +115,12 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. ### 메모리의 의미 `memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다. -E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를 +E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메모리를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다. ```shell -128974848, 129e6, 129M, 123Mi +128974848, 129e6, 129M, 128974848000m, 123Mi ``` 다음은 예제이다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 64b6bc3395..8b33e3322e 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -55,7 +55,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다. - 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다. + 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스를 사용하는 것을 고려할 수 있다. - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 73d48cd18b..d27faddc20 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -244,7 +244,7 @@ kubectl create secret docker-registry secret-tiger-docker \ `kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기 위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가 -다음의 두 키를 포함해야 한다. +다음의 두 키 중 하나를 포함해야 한다. - `username`: 인증을 위한 사용자 이름 - `password`: 인증을 위한 암호나 토큰 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 5ab09dd64a..d0c1d4bf7a 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -54,13 +54,15 @@ weight: 10 컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다. -다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다. +다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 +효과이다. `IfNotPresent` : 이미지가 로컬에 없는 경우에만 내려받는다. `Always` -: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의 +: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 + 이미지 레지스트리에 이름과 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다. 일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다. 이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서 @@ -78,7 +80,8 @@ weight: 10 {{< note >}} 프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데, -이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다. +이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 +제대로 롤백하기 어렵게 되기 때문이다. 대신, `v1.42.0`과 같이 의미있는 태그를 명기한다. {{< /note >}} @@ -90,7 +93,8 @@ weight: 10 이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다. -파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 +파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 +태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다. 이는 레지스트리에서 태그가 변경되는 일이 발생해도 구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다. @@ -104,7 +108,9 @@ weight: 10 `:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. - `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. -- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. +- `imagePullPolicy` 필드를 생략하고, + 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, + `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. {{< note >}} 컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상 @@ -127,6 +133,7 @@ weight: 10 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다. + ### 이미지풀백오프(ImagePullBackOff) kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, @@ -258,6 +265,73 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다. +### config.json 파일 해석 {#config-json} + +`config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다. +도커에서는 `auths` 키에 특정 루트 URL만 기재할 수 있으나, +쿠버네티스에서는 glob URL과 접두사-매칭 경로도 기재할 수 있다. +이는 곧 다음과 같은 `config.json`도 유효하다는 뜻이다. + +```json +{ + "auths": { + "*my-registry.io/images": { + "auth": "…" + } + } +} +``` + +루트 URL(`*my-registry.io`)은 다음 문법을 사용하여 매치된다. + +``` +pattern: + { term } + +term: + '*' 구분자가 아닌 모든 문자와 매치됨 + '?' 구분자가 아닌 문자 1개와 매치됨 + '[' [ '^' ] { character-range } ']' + 문자 클래스 (비어 있으면 안 됨)) + c 문자 c에 매치됨 (c != '*', '?', '\\', '[') + '\\' c 문자 c에 매치됨 + +character-range: + c 문자 c에 매치됨 (c != '\\', '-', ']') + '\\' c 문자 c에 매치됨 + lo '-' hi lo <= c <= hi 인 문자 c에 매치됨 +``` + +이미지 풀 작업 시, 모든 유효한 패턴에 대해 크리덴셜을 CRI 컨테이너 런타임에 제공할 것이다. +예를 들어 다음과 같은 컨테이너 이미지 이름은 +성공적으로 매치될 것이다. + +- `my-registry.io/images` +- `my-registry.io/images/my-image` +- `my-registry.io/images/another-image` +- `sub.my-registry.io/images/my-image` +- `a.sub.my-registry.io/images/my-image` + +kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미지 풀을 수행한다. 즉, +`config.json`에 다음과 같이 여러 항목을 기재할 수도 있다. + +```json +{ + "auths": { + "my-registry.io/images": { + "auth": "…" + }, + "my-registry.io/images/subpath": { + "auth": "…" + } + } +} +``` + +이제 컨테이너가 `my-registry.io/images/subpath/my-image` +이미지를 풀 해야 한다고 명시하면, +kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다. + ### 미리 내려받은 이미지 {#pre-pulled-images} {{< note >}} @@ -383,3 +457,4 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config. * [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기. * [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기. +* [프라이빗 레지스트리에서 이미지 받아오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry) diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index 79466e8df3..f6be1ea390 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -77,7 +77,7 @@ no_list: true 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. 바이너리 플러그인은 kubelet(예: -[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과 +[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 kubectl에서 사용한다. @@ -145,7 +145,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### 인가 -[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. +[인가](/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. ### 동적 어드미션 컨트롤 @@ -163,6 +163,8 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다. +FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 추천하는 방식이다. 자세한 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 찾을 수 있다. + ### 장치 플러그인 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 e6e0203eb9..d5179790aa 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 @@ -37,7 +37,8 @@ _선언적(declarative) API_ 를 제공하게 된다. 쿠버네티스 [선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는 책임의 분리를 강제한다. 사용자는 리소스의 의도한 상태를 선언한다. -쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 선언한 의도한 상태에 동기화 되도록 한다. +쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 +선언한 의도한 상태에 동기화 되도록 한다. 이는 서버에 무엇을 해야할지 *지시하는* 명령적인 API와는 대조된다. 클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고 @@ -146,9 +147,9 @@ CRD 오브젝트의 이름은 유효한 일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 ​​있다. -[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 독립형 API 서버를 +[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를 작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다. -기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 사용자에게 위임하여 +주(main) API 서버는 사용자의 커스텀 리소스에 대한 요청을 사용자의 자체 API 서버에 위임하여 모든 클라이언트가 사용할 수 있게 한다. ## 커스텀 리소스를 추가할 방법 선택 diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 9d4ad5525c..1d9b23b3aa 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -197,6 +197,8 @@ service PodResourcesLister { } ``` +### `List` gRPC 엔드포인트 {#grpc-endpoint-list} + `List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며, 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID, 이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다. @@ -246,10 +248,35 @@ message ContainerDevices { TopologyInfo topology = 3; } ``` +{{< note >}} +`List` 엔드포인트의 `ContainerResources` 내부에 있는 cpu_ids은 특정 컨테이너에 할당된 +독점 CPU들에 해당한다. 만약 공유 풀(shared pool)에 있는 CPU들을 확인(evaluate)하는 것이 목적이라면, 해당 `List` +엔드포인트는 다음에 설명된 것과 같이, `GetAllocatableResources` 엔드포인트와 함께 사용되어야 +한다. +1. `GetAllocatableResources`를 호출하여 할당 가능한 모든 CPU 목록을 조회 +2. 시스템의 모든 `ContainerResources`에서 `GetCpuIds`를 호출 +3. `GetAllocateableResources` 호출에서 `GetCpuIds` 호출로 얻은 모든 CPU를 빼기 +{{< /note >}} + +### `GetAllocatableResources` gRPC 엔드포인트 {#grpc-endpoint-getallocatableresources} + +{{< feature-state state="beta" for_k8s_version="v1.23" >}} GetAllocatableResources는 워커 노드에서 처음 사용할 수 있는 리소스에 대한 정보를 제공한다. kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다. +{{< note >}} +`GetAllocatableResources`는 [할당 가능(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 리소스를 확인(evaluate)하기 위해서만 +사용해야 한다. 만약 목적이 free/unallocated 리소스를 확인하기 위한 것이라면 +List() 엔드포인트와 함께 사용되어야 한다. `GetAllocableResources`로 얻은 결과는 kubelet에 +노출된 기본 리소스가 변경되지 않는 한 동일하게 유지된다. 이러한 변경은 드물지만, 발생하게 된다면 +(예를 들면: hotplug/hotunplug, 장치 상태 변경) 클라이언트가 `GetAlloctableResources` 엔드포인트를 +호출할 것으로 가정한다. +그러나 CPU 및/또는 메모리가 갱신된 경우 `GetAllocateableResources` 엔드포인트를 호출하는 것만으로는 +충분하지 않으며, Kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다. +{{< /note >}} + + ```gRPC // AllocatableResourcesResponses에는 kubelet이 알고 있는 모든 장치에 대한 정보가 포함된다. message AllocatableResourcesResponse { @@ -259,6 +286,13 @@ message AllocatableResourcesResponse { } ``` +쿠버네티스 v1.23부터, `GetAllocatableResources`가 기본으로 활성화된다. +이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를 +끄면 된다. + +쿠버네티스 v1.23 이전 버전에서 이 기능을 활성화하려면 `kubelet`이 다음 플래그를 가지고 시작되어야 한다. + +`--feature-gates=KubeletPodResourcesGetAllocatable=true` `ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다. NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은 diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index d3ac7a4212..36b217db9c 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -31,9 +31,7 @@ weight: 30 및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을 자동화할 수 있다. -쿠버네티스의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}} -개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을 -확장할 수 있다. +쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} 개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 하나 이상의 사용자 정의 리소스(custom resource)에 연결하여 클러스터의 동작을 확장할 수 있다. 오퍼레이터는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)의 컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다. diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md index 8d1cb3ee05..fa3d50aeb6 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: ## {{% heading "whatsnext" %}} -* 만약 당신이 {{< 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/)할 수 있다. +* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다. * [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 * [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 * [svc-cat.io](https://svc-cat.io/docs/) 살펴보기 diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 919d59b459..cc043139c4 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -1,4 +1,6 @@ --- + + title: 쿠버네티스 API content_type: concept weight: 30 @@ -35,36 +37,39 @@ card: 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. -OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. -다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다. +### OpenAPI V2 + +쿠버네티스 API 서버는 `/openapi/v2` 엔드포인트를 통해 +통합된(aggregated) OpenAPI v2 스펙을 제공한다. +요청 헤더에 다음과 같이 기재하여 응답 형식을 지정할 수 있다. - + - - - + + + - + - + - + - +
Valid request header values for OpenAPI v2 queries OpenAPI v2 질의에 사용할 수 있는 유효한 요청 헤더 값
HeaderPossible valuesNotes헤더사용할 수 있는 값참고
Accept-Encoding gzipnot supplying this header is also acceptable이 헤더를 제공하지 않는 것도 가능
Accept application/com.github.proto-openapi.spec.v2@v1.0+protobufmainly for intra-cluster use주로 클러스터 내부 용도로 사용
application/jsondefault기본값
*serves application/jsonJSON으로 응답
@@ -75,6 +80,55 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한 IDL(인터페이스 정의 언어) 파일을 참고한다. +### OpenAPI V3 + +{{< feature-state state="alpha" for_k8s_version="v1.23" >}} + +쿠버네티스 v1.23은 OpenAPI v3 API 발행(publishing)에 대한 초기 지원을 제공한다. +이는 알파 기능이며 기본적으로 비활성화되어 있다. +kube-apiserver 구성 요소에 +`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 +이 알파 기능을 활성화할 수 있다. + +이 기능이 활성화되면, 쿠버네티스 API 서버는 +통합된(aggregated) OpenAPI v3 스펙을 쿠버네티스 그룹 버전별로 +`/openapi/v3/apis//` 엔드포인트에 제공한다. +사용할 수 있는 요청 헤더는 아래의 표를 참고한다. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OpenAPI v3 질의에 사용할 수 있는 유효한 요청 헤더 값
헤더사용할 수 있는 값참고
Accept-Encodinggzip이 헤더를 제공하지 않는 것도 가능
Acceptapplication/com.github.proto-openapi.spec.v3@v1.0+protobuf주로 클러스터 내부 용도로 사용
application/json기본값
*JSON으로 응답
+ +`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든 +그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다. + ## 지속성 쿠버네티스는 오브젝트의 직렬화된 상태를 diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 1c4424a047..0ab5b4b76f 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 -* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기 +* [kube-scheduler 구성(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index e2fb1cdcf9..5fd12dc521 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 마치 100을 설정한 것처럼 작동한다. 값을 변경하려면, -[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을 +[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta3/)을 편집한 다음 스케줄러를 재시작한다. 대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다. @@ -161,4 +161,4 @@ percentageOfNodesToScore: 50 ## {{% heading "whatsnext" %}} -* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인 +* [kube-scheduler 구성 레퍼런스(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 확인 diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index f6d8c13a19..f6321e4aa7 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -203,7 +203,7 @@ tolerations: * `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된 시간 동안 바인딩된 상태로 유지된다. -노드 컨트롤러는 특정 조건이 참일 때 자동으로 +노드 컨트롤러는 특정 컨디션이 참일 때 자동으로 노드를 테인트시킨다. 다음은 빌트인 테인트이다. * `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition @@ -264,19 +264,19 @@ tolerations: 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다. -## 조건(condition)을 기준으로 노드 테인트하기 +## 컨디션(condition)을 기준으로 노드 테인트하기 컨트롤 플레인은 노드 {{}}를 이용하여 -[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. +[노드 컨디션](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. -스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. -이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다. -예를 들어 `DiskPressure` 노드 조건이 활성화된 경우 +스케줄러는 스케줄링 결정을 내릴 때 노드 컨디션을 확인하는 것이 아니라 테인트를 확인한다. +이렇게 하면 노드 컨디션이 스케줄링에 직접적인 영향을 주지 않는다. +예를 들어 `DiskPressure` 노드 컨디션이 활성화된 경우 컨트롤 플레인은 `node.kubernetes.io/disk-pressure` 테인트를 추가하고 영향을 받는 노드에 새 파드를 할당하지 않는다. -`MemoryPressure` 노드 조건이 활성화되면 +`MemoryPressure` 노드 컨디션이 활성화되면 컨트롤 플레인이 `node.kubernetes.io/memory-pressure` 테인트를 추가한다. -새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 조건을 무시하도록 할 수 있다. +새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 컨디션을 무시하도록 할 수 있다. 또한 컨트롤 플레인은 `BestEffort` 이외의 {{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}를 가지는 파드에 `node.kubernetes.io/memory-pressure` 톨러레이션을 추가한다. diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index bb7a9154c3..b7e5b26056 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -1,4 +1,8 @@ --- + + + + title: 서비스와 애플리케이션 연결하기 content_type: concept weight: 30 @@ -50,7 +54,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP 클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다. -만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다. +만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다. ## 서비스 생성하기 diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 3544d7e745..c23556172b 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -39,7 +39,7 @@ DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다 DNS 쿼리는 파드의 `/etc/resolv.conf` 를 사용하여 확장될 수 있을 것이다. Kubelet은 각 파드에 대해서 파일을 설정한다. 예를 들어, `data` 만을 위한 쿼리는 -`data.test.cluster.local` 로 확장된다. `search` 옵션의 값은 +`data.test.svc.cluster.local` 로 확장된다. `search` 옵션의 값은 쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우, [`resolv.conf` 설명 페이지.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)를 참고한다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 821ca34989..c77bba06c8 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -1,4 +1,9 @@ --- + + + + + title: IPv4/IPv6 이중 스택 feature: title: IPv4/IPv6 이중 스택 @@ -11,7 +16,7 @@ weight: 70 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다. @@ -42,8 +47,6 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 ## IPv4/IPv6 이중 스택 구성 -IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.) - IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다. * kube-apiserver: @@ -60,9 +63,6 @@ IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도 IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.) -1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다. -필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에 -`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다. {{< /note >}} ## 서비스 @@ -76,7 +76,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. * `PreferDualStack`: - * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.) + * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. * `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다. * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다. @@ -119,7 +119,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 #### 기존 서비스의 이중 스택 기본값 -이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.) +이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.) 1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다. diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index c66a9b6e84..a8b2cf1d5f 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -28,6 +28,7 @@ weight: 40 컨트롤러다. * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다. +* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe)는 [BFE](https://www.bfe-networks.net) 기반 인그레스 컨트롤러다. * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는 Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index bafb216014..cccd947bb9 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -51,7 +51,7 @@ graph LR; 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 -[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는 +[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 또는 [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. ## 전제 조건들 @@ -219,20 +219,98 @@ Events: {{< codenew file="service/networking/external-lb.yaml" >}} -IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한 -추가 구현 별 구성을 참조하는데 사용할 수 있다. +인그레스클래스의 `.spec.parameters` 필드를 사용하여 +해당 인그레스클래스와 연관있는 환경 설정을 제공하는 다른 리소스를 참조할 수 있다. -#### 네임스페이스 범위의 파라미터 +사용 가능한 파라미터의 상세한 타입은 +인그레스클래스의 `.spec.parameters` 필드에 명시한 인그레스 컨트롤러의 종류에 따라 다르다. -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +### 인그레스클래스 범위 -`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데 -사용할 수 있는 `scope` 및 `namespace` 필드가 있다. -`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의 -리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를 -설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다. +인그레스 컨트롤러의 종류에 따라, 클러스터 범위로 설정한 파라미터의 사용이 가능할 수도 있고, +또는 한 네임스페이스에서만 사용 가능할 수도 있다. -{{< codenew file="service/networking/namespaced-params.yaml" >}} +{{< tabs name="tabs_ingressclass_parameter_scope" >}} +{{% tab name="클러스터" %}} +인그레스클래스 파라미터의 기본 범위는 클러스터 범위이다. + +`.spec.parameters` 필드만 설정하고 `.spec.parameters.scope` 필드는 지정하지 않거나, +`.spec.parameters.scope` 필드를 `Cluster`로 지정하면, +인그레스클래스는 클러스터 범위의 리소스를 참조한다. +파라미터의 `kind`(+`apiGroup`)는 +클러스터 범위의 API (커스텀 리소스일 수도 있음) 를 참조하며, +파라미터의 `name`은 +해당 API에 대한 특정 클러스터 범위 리소스를 가리킨다. + +예시는 다음과 같다. +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-1 +spec: + controller: example.com/ingress-controller + parameters: + # 이 인그레스클래스에 대한 파라미터는 "external-config-1" 라는 + # ClusterIngressParameter(API 그룹 k8s.example.net)에 기재되어 있다. + # 이 정의는 쿠버네티스가 + # 클러스터 범위의 파라미터 리소스를 검색하도록 한다. + scope: Cluster + apiGroup: k8s.example.net + kind: ClusterIngressParameter + name: external-config-1 +``` +{{% /tab %}} +{{% tab name="네임스페이스" %}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +`.spec.parameters` 필드를 설정하고 +`.spec.parameters.scope` 필드를 `Namespace`로 지정하면, +인그레스클래스는 네임스페이스 범위의 리소스를 참조한다. +사용하고자 하는 파라미터가 속한 네임스페이스를 +`.spec.parameters` 의 `namespace` 필드에 설정해야 한다. + +파라미터의 `kind`(+`apiGroup`)는 +네임스페이스 범위의 API (예: 컨피그맵) 를 참조하며, +파라미터의 `name`은 +`namespace`에 명시한 네임스페이스의 특정 리소스를 가리킨다. + +네임스페이스 범위의 파라미터를 이용하여, +클러스터 운영자가 워크로드에 사용되는 환경 설정(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임할 수 있다. +클러스터 범위의 파라미터를 사용했다면 다음 중 하나에 해당된다. + +- 다른 팀의 새로운 환경 설정 변경을 적용하려고 할 때마다 + 클러스터 운영 팀이 매번 승인을 해야 한다. 또는, +- 애플리케이션 팀이 클러스터 범위 파라미터 리소스를 변경할 수 있게 하는 + [RBAC](/docs/reference/access-authn-authz/rbac/) 롤, 바인딩 등의 특별 접근 제어를 + 클러스터 운영자가 정의해야 한다. + +인그레스클래스 API 자신은 항상 클러스터 범위이다. + +네임스페이스 범위의 파라미터를 참조하는 인그레스클래스 예시가 +다음과 같다. +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-2 +spec: + controller: example.com/ingress-controller + parameters: + # 이 인그레스클래스에 대한 파라미터는 + # "external-configuration" 환경 설정 네임스페이스에 있는 + # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다. + scope: Namespace + apiGroup: k8s.example.com + kind: IngressParameter + namespace: external-configuration + name: external-config +``` + +{{% /tab %}} +{{< /tabs >}} ### 사용중단(Deprecated) 어노테이션 @@ -559,12 +637,12 @@ Events: 사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다. * [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용. -* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용. +* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 사용. ## {{% heading "whatsnext" %}} -* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 +* [인그레스](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/) diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index f658cd6cfa..8088d05366 100644 --- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되 ## {{% heading "whatsnext" %}} -* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기 +* [토폴로지 인식 힌트](/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기 * [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 798c0b4e97..db1c510ed0 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -550,7 +550,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 * `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면 클러스터 내에서만 서비스에 도달할 수 있다. 이것은 `ServiceTypes`의 기본 값이다. -* [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를 +* [`NodePort`](#type-nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를 노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가 자동으로 생성된다. `:`를 요청하여, 클러스터 외부에서 @@ -568,7 +568,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 [인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다. -### NodePort 유형 {#nodeport} +### NodePort 유형 {#type-nodeport} `type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은 `--service-node-port-range` 플래그로 지정된 범위에서 포트를 할당한다 (기본값 : 30000-32767). diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 4bc8926e3b..c249864c96 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -10,14 +10,13 @@ feature: title: 스토리지 오케스트레이션 description: > 로컬 스토리지, GCP나 AWS와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다. - content_type: concept weight: 20 --- -이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. +이 페이지에서는 쿠버네티스의 _퍼시스턴트 볼륨_ 에 대해 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. @@ -221,19 +220,19 @@ spec: {{< feature-state for_k8s_version="v1.11" state="beta" >}} -이제 퍼시스턴트볼륨클레임(PVC) 확장 지원이 기본적으로 활성화되어 있다. 다음 유형의 +퍼시스턴트볼륨클레임(PVC) 확장 지원은 기본적으로 활성화되어 있다. 다음 유형의 볼륨을 확장할 수 있다. -* gcePersistentDisk +* azureDisk +* azureFile * awsElasticBlockStore -* Cinder +* cinder (deprecated) +* {{< glossary_tooltip text="csi" term_id="csi" >}} +* flexVolume (deprecated) +* gcePersistentDisk * glusterfs * rbd -* Azure File -* Azure Disk -* Portworx -* FlexVolumes -* {{< glossary_tooltip text="CSI" term_id="csi" >}} +* portworxVolume 스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다. @@ -270,7 +269,7 @@ CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확 경우에만 파일시스템의 크기가 조정된다. 파일시스템 확장은 파드가 시작되거나 파드가 실행 중이고 기본 파일시스템이 온라인 확장을 지원할 때 수행된다. -FlexVolumes는 `RequiresFSResize` 기능으로 드라이버가 `true`로 설정된 경우 크기 조정을 허용한다. +FlexVolumes(쿠버네티스 v1.23부터 사용 중단됨)는 드라이버의 `RequiresFSResize` 기능이 `true`로 설정된 경우 크기 조정을 허용한다. FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. #### 사용 중인 퍼시스턴트볼륨클레임 크기 조정 @@ -299,6 +298,11 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 #### 볼륨 확장 시 오류 복구 +사용자가 기반 스토리지 시스템이 제공할 수 있는 것보다 더 큰 사이즈를 지정하면, 사용자 또는 클러스터 관리자가 조치를 취하기 전까지 PVC 확장을 계속 시도한다. 이는 바람직하지 않으며 따라서 쿠버네티스는 이러한 오류 상황에서 벗어나기 위해 다음과 같은 방법을 제공한다. + +{{< tabs name="recovery_methods" >}} +{{% tab name="클러스터 관리자 접근 권한을 이용하여 수동으로" %}} + 기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다. 1. 퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 `Retain` 반환 정책으로 표시한다. @@ -307,6 +311,30 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 4. PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 `volumeName` 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다. 5. PV의 반환 정책을 복원하는 것을 잊지 않는다. +{{% /tab %}} +{{% tab name="더 작은 크기로의 확장을 요청하여" %}} +{{% feature-state for_k8s_version="v1.23" state="alpha" %}} + +{{< note >}} +PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다. +{{< /note >}} + +클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure` +기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면 +이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다. +더 작은 크기를 지정하여 확장 시도를 요청하려면, +이전에 요청했던 값보다 작은 크기로 PVC의 `.spec.resources` 값을 수정한다. +이는 총 용량 제한(capacity constraint)으로 인해 큰 값으로의 확장이 실패한 경우에 유용하다. +만약 확장이 실패했다면, 또는 실패한 것 같다면, 기반 스토리지 공급자의 용량 제한보다 작은 값으로 확장을 재시도할 수 있다. +`.status.resizeStatus`와 PVC의 이벤트를 감시하여 리사이즈 작업의 상태를 모니터할 수 있다. + +참고: +이전에 요청했던 값보다 작은 크기를 요청했더라도, +새로운 값이 여전히 `.status.capacity`보다 클 수 있다. +쿠버네티스는 PVC를 현재 크기보다 더 작게 축소하는 것은 지원하지 않는다. +{{% /tab %}} +{{% /tabs %}} + ## 퍼시스턴트 볼륨의 유형 @@ -318,7 +346,6 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 * [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨 * [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI) * [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지 -* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume * [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk * [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨 * [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨 @@ -336,6 +363,8 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 * [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지) (v1.18에서 **사용 중단**) +* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexvolume) - FlexVolume + (v1.23에서 **사용 중단**) * [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지 (v1.22에서 **사용 중단**) * [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨 @@ -415,10 +444,13 @@ spec: 접근 모드는 다음과 같다. `ReadWriteOnce` -: 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다. +: 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파드가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다. + +`ReadOnlyMany` +: 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다. `ReadWriteMany` -: 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다. +: 볼륨이 다수의 노드에서 읽기-쓰기로 마운트 될 수 있다. `ReadWriteOncePod` : 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다. diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md index 4aeb1ba8c1..86c95ae13a 100644 --- a/content/ko/docs/concepts/storage/storage-capacity.md +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -7,7 +7,7 @@ title: 스토리지 용량 content_type: concept -weight: 45 +weight: 70 --- @@ -16,7 +16,6 @@ weight: 45 예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며, 또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다. -{{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< feature-state for_k8s_version="v1.21" state="beta" >}} 이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index c915b65fad..c47f053a31 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -470,14 +470,14 @@ parameters: vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다. -- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com` +- [CSI 프로비저닝 도구](#vsphere-provisioner-csi): `csi.vsphere.vmware.com` - [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume` 인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다. #### CSI 프로비저닝 도구 {#vsphere-provisioner-csi} -vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다. +vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml)를 참조한다. #### vCP 프로비저닝 도구 diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index e9857885d7..365f780230 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -1,7 +1,12 @@ --- + + + + + title: CSI 볼륨 복제하기 content_type: concept -weight: 30 +weight: 60 --- diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 862c900fee..594d100772 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -8,7 +8,7 @@ title: 볼륨 스냅샷 클래스 content_type: concept -weight: 30 +weight: 41 # just after volume snapshots --- diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index b01a8affa4..d54ed5c45c 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -1,7 +1,14 @@ --- + + + + + + + title: 볼륨 스냅샷 content_type: concept -weight: 20 +weight: 40 --- diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 5983c37647..a4245a7daa 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -44,12 +44,21 @@ weight: 10 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다. -컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 -뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는 -파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에 -마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 -가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로 -지정해야 한다. +컨테이너의 프로세스는 +{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}의 최초 내용물과 +컨테이너 안에 마운트된 볼륨(정의된 경우에 한함)으로 구성된 파일시스템을 보게 된다. +프로세스는 컨테이너 이미지의 최초 내용물에 해당되는 루트 파일시스템을 +보게 된다. +쓰기가 허용된 경우, 해당 파일시스템에 쓰기 작업을 하면 +추후 파일시스템에 접근할 때 변경된 내용을 보게 될 것이다. +볼륨은 이미지의 [특정 경로](#using-subpath)에 +마운트된다. +파드에 정의된 각 컨테이너에 대해, +컨테이너가 사용할 각 볼륨을 어디에 마운트할지 명시해야 한다. + +볼륨은 다른 볼륨 안에 마운트될 수 없다 +(하지만, [서브패스 사용](#using-subpath)에서 관련 메커니즘을 확인한다). +또한, 볼륨은 다른 볼륨에 있는 내용물을 가리키는 하드 링크를 포함할 수 없다. ## 볼륨 유형들 {#volume-types} @@ -802,142 +811,7 @@ spec: ### projected `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. - -현재, 다음 유형의 볼륨 소스를 프로젝티드한다. - -* [`secret`](#secret) -* [`downwardAPI`](#downwardapi) -* [`configMap`](#configmap) -* `serviceAccountToken` - -모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은 -[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다. - -#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: volume-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: all-in-one - mountPath: "/projected-volume" - readOnly: true - volumes: - - name: all-in-one - projected: - sources: - - secret: - name: mysecret - items: - - key: username - path: my-group/my-username - - downwardAPI: - items: - - path: "labels" - fieldRef: - fieldPath: metadata.labels - - path: "cpu_limit" - resourceFieldRef: - containerName: container-test - resource: limits.cpu - - configMap: - name: myconfigmap - items: - - key: config - path: my-group/my-config -``` - -#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#example-configuration-secrets-nondefault-permission-mode} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: volume-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: all-in-one - mountPath: "/projected-volume" - readOnly: true - volumes: - - name: all-in-one - projected: - sources: - - secret: - name: mysecret - items: - - key: username - path: my-group/my-username - - secret: - name: mysecret2 - items: - - key: password - path: my-group/my-password - mode: 511 -``` - -각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다. -파라미터는 두 가지 예외를 제외하고 거의 동일하다. - -* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록 - `name` 으로 변경되었다. -* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만 - 지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode` - 를 명시적으로 설정할 수 있다. - -`TokenRequestProjection` 기능이 활성화 되면, 현재 -[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에 -대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: sa-token-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: token-vol - mountPath: "/service-account" - readOnly: true - volumes: - - name: token-vol - projected: - sources: - - serviceAccountToken: - audience: api - expirationSeconds: 3600 - path: token -``` - -예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이 -있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데 -사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을 -포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며, -그렇지 않으면 토큰을 거부해야 한다. 이 필드는 -선택 사항이며 기본값은 API 서버의 식별자이다. - -`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효 -기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는 -API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서 -최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한 -상대 경로를 지정한다. - -{{< note >}} -projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 -해당 볼륨 소스의 업데이트를 수신하지 않는다. -{{< /note >}} +더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다. ### quobyte (사용 중단됨) {#quobyte} @@ -975,6 +849,38 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를 참고한다. +#### RBD CSI 마이그레이션 {#rbd-csi-migration} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +`RBD`를 위한 `CSIMigration` 기능이 활성화되어 있으면, +사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을 +`rbd.csi.ceph.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} +드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 +[Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고 +`CSIMigration`, `CSIMigrationRBD` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. + +{{< note >}} + +스토리지를 관리하는 쿠버네티스 클러스터 관리자는, +RBD CSI 드라이버로의 마이그레이션을 시도하기 전에 +다음의 선행 사항을 완료해야 한다. + +* 쿠버네티스 클러스터에 Ceph CSI 드라이버 (`rbd.csi.ceph.com`) v3.5.0 + 이상을 설치해야 한다. +* CSI 드라이버가 동작하기 위해 `clusterID` 필드가 필수이지만 + 트리 내(in-tree) 스토리지클래스는 `monitors` 필드가 필수임을 감안하여, + 쿠버네티스 저장소 관리자는 monitors 값의 + 해시(예: `#echo -n '' | md5sum`) + 기반으로 clusterID를 CSI 컨피그맵 내에 만들고 + 이 clusterID 환경 설정 아래에 monitors 필드를 유지해야 한다. +* 또한, 트리 내(in-tree) 스토리지클래스의 + `adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의 + `adminSecretName` 값이 `adminId` 파라미터 값의 + base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. + ### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 @@ -1144,6 +1050,16 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 `vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다. +#### Portworx CSI 마이그레이션 +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +Portworx를 위한 `CSIMigration` 기능이 쿠버네티스 1.23에 추가되었지만 +알파 상태이기 때문에 기본적으로는 비활성화되어 있다. +이 기능은 사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을 +`pxd.portworx.com` CSI 드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 [Portworx CSI 드라이버](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)가 +설치되어 있고, kube-controller-manager와 kubelet에 `CSIMigrationPortworx=true`로 설정해야 한다. + ## subPath 사용하기 {#using-subpath} 때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. @@ -1239,8 +1155,7 @@ spec: ## 아웃-오브-트리(out-of-tree) 볼륨 플러그인 아웃-오브-트리 볼륨 플러그인에는 -{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 -FlexVolume이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 +{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 FlexVolume(사용 중단됨)이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. 이전에는 모든 볼륨 플러그인이 "인-트리(in-tree)"에 있었다. "인-트리" 플러그인은 쿠버네티스 핵심 바이너리와 @@ -1373,13 +1288,21 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트 ### flexVolume -FlexVolume은 버전 1.2(CSI 이전) 이후 쿠버네티스에 존재하는 -아웃-오브-트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 -접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드와 일부 경우에 컨트롤 플레인 노드의 -미리 정의된 볼륨 플러그인 경로에 설치해야 한다. +{{< feature-state for_k8s_version="v1.23" state="deprecated" >}} + +FlexVolume은 스토리지 드라이버와 인터페이싱하기 위해 exec 기반 모델을 사용하는 아웃-오브-트리 플러그인 인터페이스이다. +FlexVolume 드라이버 바이너리 파일은 각 노드의 미리 정의된 볼륨 플러그인 경로에 설치되어야 하며, +일부 경우에는 컨트롤 플레인 노드에도 설치되어야 한다. 파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다. -더 자세한 내용은 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 예제를 참고한다. +더 자세한 내용은 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 문서를 참고한다. + +{{< note >}} +FlexVolume은 사용 중단되었다. 쿠버네티스에 외부 스토리지를 연결하려면 아웃-오브-트리 CSI 드라이버를 사용하는 것을 권장한다. + +FlexVolume 드라이버 메인테이너는 CSI 드라이버를 구현하고 사용자들이 FlexVolume 드라이버에서 CSI로 마이그레이트할 수 있도록 지원해야 한다. +FlexVolume 사용자는 워크로드가 동등한 CSI 드라이버를 사용하도록 이전해야 한다. +{{< /note >}} ## 마운트 전파(propagation) diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 3ae5659806..34ac547b73 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -17,8 +17,6 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text=" 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. -추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=