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/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 ce69c5a69c..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; 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-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/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/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/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/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/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 3235361574..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" @@ -575,7 +576,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `AnyVolumeDataSource`: Enable use of any custom resource as the `DataSource` of a {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}. - `AppArmor`: Enable use of AppArmor mandatory access control for Pods running on Linux nodes. - See [AppArmor Tutorial](/docs/tutorials/clusters/apparmor/) for more details. + 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. @@ -769,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 @@ -1089,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)
- - - - - - - - - - - - - - @@ -84,6 +70,13 @@ kube-proxy [flags] + + + + + + + @@ -179,7 +172,7 @@ kube-proxy [flags] - + @@ -308,48 +301,6 @@ kube-proxy [flags] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -357,6 +308,13 @@ kube-proxy [flags] + + + + + + + @@ -385,13 +343,6 @@ kube-proxy [flags] - - - - - - - @@ -427,27 +378,6 @@ kube-proxy [flags] - - - - - - - - - - - - - - - - - - - - - @@ -455,13 +385,6 @@ kube-proxy [flags] - - - - - - - @@ -469,13 +392,6 @@ kube-proxy [flags] - - - - - - - diff --git a/content/ko/docs/reference/glossary/container-runtime-interface.md b/content/ko/docs/reference/glossary/container-runtime-interface.md new file mode 100644 index 0000000000..c0d6155a4a --- /dev/null +++ b/content/ko/docs/reference/glossary/container-runtime-interface.md @@ -0,0 +1,22 @@ +--- +title: 컨테이너 런타임 인터페이스(Container Runtime Interface) +id: container-runtime-interface +date: 2022-01-10 +full_link: /ko/docs/concepts/architecture/cri/ +short_description: > + Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다. + +aka: +tags: + - cri +--- + +Kubelet과 컨테이너 런타임 사이의 통신을 위한 주요 프로토콜이다. + + + +쿠버네티스 컨테이너 런타임 인터페이스(CRI)는 +[클러스터 컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트) +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}과 +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} 사이의 +통신을 위한 주요 [gRPC](https://grpc.io) 프로토콜을 정의한다. diff --git a/content/ko/docs/reference/glossary/pod-disruption.md b/content/ko/docs/reference/glossary/pod-disruption.md index 93a473035c..1855f2118f 100644 --- a/content/ko/docs/reference/glossary/pod-disruption.md +++ b/content/ko/docs/reference/glossary/pod-disruption.md @@ -14,6 +14,11 @@ tags: - operation --- -[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다. +[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 +노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다. -자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 비자발적 중단은 의도하지 않은 것이며, 노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거될 수 있다. + + +자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. +비자발적 중단은 의도하지 않은 것이며, +노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거가 될 수 있다. diff --git a/content/ko/docs/reference/glossary/quantity.md b/content/ko/docs/reference/glossary/quantity.md index 450307841a..9c9c8b7582 100644 --- a/content/ko/docs/reference/glossary/quantity.md +++ b/content/ko/docs/reference/glossary/quantity.md @@ -10,7 +10,7 @@ aka: tags: - core-object --- - SI 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현. + [SI](https://en.wikipedia.org/wiki/International_System_of_Units) 접미사를 사용하는 작거나 큰 숫자의 정수(whole-number) 표현. @@ -19,9 +19,8 @@ tags: 큰 숫자는 킬로(kilo), 메가(mega), 또는 기가(giga) 단위로 표시할 수 있다. - 예를 들어, 숫자 `1.5`는 `1500m`으로, 숫자 `1000`은 `1k`로, `1000000`은 -`1M`으로 표시할 수 있다. 또한, 이진 표기법 접미사도 명시 가능하므로, +`1M`으로 표시할 수 있다. 또한, [이진 표기법](https://en.wikipedia.org/wiki/Binary_prefix) 접미사도 명시 가능하므로, 숫자 2048은 `2Ki`로 표기될 수 있다. 허용되는 10진수(10의 거듭 제곱) 단위는 `m` (밀리), `k` (킬로, 의도적인 소문자), diff --git a/content/ko/docs/reference/glossary/secret.md b/content/ko/docs/reference/glossary/secret.md index 63637adc1a..69923c2b4e 100644 --- a/content/ko/docs/reference/glossary/secret.md +++ b/content/ko/docs/reference/glossary/secret.md @@ -15,4 +15,4 @@ tags: -민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 유휴 상태의 [암호화](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)를 포함하여 우발적인 노출 위험을 줄인다. {{< glossary_tooltip text="파드(Pod)" term_id="pod" >}}는 시크릿을 마운트된 볼륨의 파일로 참조하거나, 파드의 이미지를 풀링하는 kubelet이 시크릿을 참조한다. 시크릿은 기밀 데이터에 적합하고 [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 기밀이 아닌 데이터에 적합하다. +민감한 정보를 사용하는 방식에 대해 더 세밀하게 제어할 수 있으며, 우발적인 노출 위험을 줄인다. 시크릿 값은 기본적으로 base64 문자열로 인코딩되어 암호화되지 않은 채로 저장되지만, [안전하게 암호화](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)되도록 설정할 수 있다. {{< glossary_tooltip text="파드" term_id="pod" >}}는 볼륨 마운트 내의 파일 형태로 시크릿에 접근하며, 시크릿은 또한 kubelet이 파드를 위해 이미지를 풀링할 때에도 사용될 수 있다. 시크릿은 기밀 데이터를 다루는 용도로 적합하며, [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 기밀이 아닌 데이터를 다루는 용도로 적합하다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 71fc5a5f27..b4e39aa736 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -1,5 +1,9 @@ --- title: kubectl 치트 시트 + + + + content_type: concept card: name: reference @@ -215,7 +219,7 @@ kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' # 모든 파드에 대해 ENV를 생성한다(각 파드에 기본 컨테이너가 있고, 기본 네임스페이스가 있고, `env` 명령어가 동작한다고 가정). # `env` 뿐만 아니라 다른 지원되는 명령어를 모든 파드에 실행할 때에도 참고할 수 있다. -for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod env; done +for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod -- env; done ``` ## 리소스 업데이트 @@ -285,11 +289,11 @@ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 여러 개 ## 리소스 삭제 ```bash -kubectl delete -f ./pod.json # pod.json에 지정된 유형 및 이름을 사용하여 파드 삭제 -kubectl delete pod,service baz foo # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제 -kubectl delete pods,services -l name=myLabel # name=myLabel 라벨을 가진 파드와 서비스 삭제 -kubectl delete pods,services -l name=myLabel --include-uninitialized # 초기화되지 않은 것을 포함하여, name=myLabel 라벨을 가진 파드와 서비스 삭제 -kubectl -n my-ns delete pod,svc --all # 초기화되지 않은 것을 포함하여, my-ns 네임스페이스 내 모든 파드와 서비스 삭제 +kubectl delete -f ./pod.json # pod.json에 지정된 유형 및 이름을 사용하여 파드 삭제 +kubectl delete pod unwanted --now # 유예 시간 없이 즉시 파드 삭제 +kubectl delete pod,service baz foo # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제 +kubectl delete pods,services -l name=myLabel # name=myLabel 라벨을 가진 파드와 서비스 삭제 +kubectl -n my-ns delete pod,svc --all # my-ns 네임스페이스 내 모든 파드와 서비스 삭제 # awk pattern1 또는 pattern2에 매칭되는 모든 파드 삭제 kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` @@ -307,8 +311,7 @@ kubectl logs -f my-pod # 실시간 스트림 파드 kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우) kubectl logs -f -l name=myLabel --all-containers # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout) kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행 -kubectl run nginx --image=nginx -n -mynamespace # 특정 네임스페이스에서 nginx 파드 실행 +kubectl run nginx --image=nginx -n mynamespace # mynamespace 네임스페이스에서 nginx 파드 1개 실행 kubectl run nginx --image=nginx # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록 --dry-run=client -o yaml > pod.yaml @@ -320,6 +323,24 @@ kubectl exec my-pod -c my-container -- ls / # 기존 파드에서 명령 kubectl top pod POD_NAME --containers # 특정 파드와 해당 컨테이너에 대한 메트릭 표시 kubectl top pod POD_NAME --sort-by=cpu # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬 ``` +## 컨테이너로/컨테이너에서 파일과 디렉터리 복사 + +```bash +kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir # 로컬 디렉토리 /tmp/foo_dir 를 현재 네임스페이스의 my-pod 파드 안의 /tmp/bar_dir 로 복사 +kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container # 로컬 파일 /tmp/foo 를 my-pod 파드의 my-container 컨테이너 안의 /tmp/bar 로 복사 +kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar # 로컬 파일 /tmp/foo 를 my-namespace 네임스페이스의 my-pod 파드 안의 /tmp/bar 로 복사 +kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # my-namespace 네임스페이스의 my-pod 파드 안의 파일 /tmp/foo 를 로컬의 /tmp/bar 로 복사 +``` +{{< note >}} +`kubectl cp` 명령을 사용하려면 컨테이너 이미지에 'tar' 바이너리가 포함되어 있어야 한다. 'tar'가 없으면, `kubectl cp`는 실패할 것이다. +심볼릭 링크, 와일드카드 확장, 파일 모드 보존과 같은 고급 사용 사례에 대해서는 `kubectl exec` 를 고려해 볼 수 있다. +{{< /note >}} + +```bash +tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar # 로컬 파일 /tmp/foo 를 my-namespace 네임스페이스의 my-pod 파드 안의 /tmp/bar 로 복사 +kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar # my-namespace 네임스페이스의 my-pod 파드 안의 파일 /tmp/foo 를 로컬의 /tmp/bar 로 복사 +``` + ## 디플로이먼트, 서비스와 상호 작용 ```bash diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index c00d0565b5..4b289d50d2 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -91,6 +91,7 @@ kubectl [command] [TYPE] [NAME] [flags] * `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고, * `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고, * kubectl 명령에 네임스페이스를 명시하지 않으면 + kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다. kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다. 이는 클러스터 외부에서 실행되었을 때와는 다른데, diff --git a/content/ko/docs/reference/labels-annotations-taints.md b/content/ko/docs/reference/labels-annotations-taints.md index 2577531042..dbc769179a 100644 --- a/content/ko/docs/reference/labels-annotations-taints.md +++ b/content/ko/docs/reference/labels-annotations-taints.md @@ -36,10 +36,9 @@ Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블 적용 대상: 네임스페이스 -`NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있으면, -쿠버네티스 API 서버가 모든 네임스페이스에 이 레이블을 적용한다. -레이블의 값은 네임스페이스의 이름으로 적용된다. +({{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부인) +쿠버네티스 API 서버가 이 레이블을 모든 네임스페이스에 설정한다. +레이블의 값은 네임스페이스의 이름으로 적용된다. 이 레이블의 값을 변경할 수는 없다. 레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면 이 레이블이 유용할 수 있다. @@ -63,6 +62,16 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k 이 레이블은 토폴로지 계층의 일부로도 사용된다. [`topology.kubernetes.io/zone`](#topologykubernetesiozone)에서 세부 사항을 확인한다. +## kubernetes.io/change-cause {#change-cause} + +예시: `kubernetes.io/change-cause=kubectl edit --record deployment foo` + +적용 대상: 모든 오브젝트 + +이 어노테이션은 어떤 오브젝트가 왜 변경되었는지 그 이유를 담는다. + +어떤 오브젝트를 변경할 수도 있는 `kubectl` 명령에 `--record` 플래그를 사용하면 이 레이블이 추가된다. + ## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} 예시: `controller.kubernetes.io/pod-deletion-cost=10` @@ -425,4 +434,20 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 객체를 만들거나 업데이트할 때에도 경고가 표시된다. 더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 -참고한다. \ No newline at end of file +참고한다. + +## seccomp.security.alpha.kubernetes.io/pod (사용 중단됨) {#seccomp-security-alpha-kubernetes-io-pod} + +이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. +파드의 보안 설정을 지정하려면, 파드 스펙에 `securityContext` 필드를 추가한다. +파드의 `.spec` 내의 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) 필드는 파드 수준 보안 속성을 정의한다. +[파드의 보안 컨텍스트를 설정](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)하면, +해당 설정이 파드 내의 모든 컨테이너에 적용된다. + +## container.seccomp.security.alpha.kubernetes.io/[이름] {#container-seccomp-security-alpha-kubernetes-io} + +이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. +[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/clusters/seccomp/) 튜토리얼에서 +seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다. +튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며, +이는 파드의 `.spec` 내에 `securityContext` 를 설정함으로써 가능하다. diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index d31897054d..1c1db61d1b 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -18,8 +18,8 @@ weight: 20 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. -KubeSchedulerConfiguration ([v1beta1](/docs/reference/config-api/kube-scheduler-config.v1beta1/) -또는 [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)) +KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/) +또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)) 구조에 맞게 파일을 작성하고, `kube-scheduler --config `을 실행하여 스케줄링 프로파일을 지정할 수 있다. @@ -78,6 +78,8 @@ clientConnection: 플러그인은 적어도 하나 이상 필요하다. 1. `postBind`: 파드가 바인드된 후 호출되는 정보성 익스텐션 포인트이다. +1. `multiPoint`: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해 + 플러그인들을 동시에 활성화하거나 비활성화할 수 있게 하는 환경 설정 전용 필드이다. 각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나 자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다. @@ -101,7 +103,7 @@ profiles: 모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데 사용할 수도 있다. -### 스케줄링 플러그인 +### 스케줄링 플러그인 {#scheduling-plugins} 기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중 하나 이상을 구현한다. @@ -178,30 +180,6 @@ profiles: - `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/) 볼륨 제한이 충족될 수 있는지 확인한다. 익스텐션 포인트: `filter`. - -다음 플러그인은 더 이상 사용되지 않으며 `v1beta1`에서만 -사용할 수 있다. - -- `NodeResourcesLeastAllocated`: 리소스 할당이 낮은 노드를 - 선호한다. - Extension points: `score`. -- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를 - 선호한다. - 익스텐션 포인트: `score`. -- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를 - 선호한다. - 익스텐션 포인트: `score`. -- `NodeLabel`: 설정된 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라 - 노드를 필터링하거나 스코어링한다. - 익스텐션 포인트: `Filter`, `Score`. -- `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에 - 속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지 - 확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에 - 분산하는 것을 선호한다. - 익스텐션 포인트: `preFilter`, `filter`, `score`. -- `NodePreferAvoidPods`: 노드 주석 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라 - 노드의 우선 순위를 지정한다. - 익스텐션 포인트: `score`. ### 여러 프로파일 @@ -251,6 +229,186 @@ profiles: 단 하나만 가질 수 있기 때문이다. {{< /note >}} +### 다수의 익스텐션 포인트에 플러그인 적용하기 {#multipoint} + +`kubescheduler.config.k8s.io/v1beta3` 부터, +다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나 +비활성화할 수 있게 하는 프로파일 환경 설정 `multiPoint` 가 추가되었다. +이를 사용하여 사용자와 관리자가 커스텀 프로파일을 사용할 때 환경 설정을 간소화할 수 있다. + +`preScore`, `score`, `preFilter`, `filter` 익스텐션 포인트가 있는 `MyPlugin` 이라는 플러그인이 있다고 가정하자. +모든 사용 가능한 익스텐션 포인트에 대해 `MyPlugin` 을 활성화하려면, +다음과 같은 프로파일 환경 설정을 사용한다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: MyPlugin +``` + +위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 `MyPlugin` 을 수동으로 활성화하는 것과 +동일한 효과를 갖는다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: non-multipoint-scheduler + plugins: + preScore: + enabled: + - name: MyPlugin + score: + enabled: + - name: MyPlugin + preFilter: + enabled: + - name: MyPlugin + filter: + enabled: + - name: MyPlugin +``` + +여기서 `multiPoint` 를 사용했을 때의 이점은, +추후 `MyPlugin` 이 다른 익스텐션 포인트에 대한 구현을 추가했을 때, +새로운 익스텐션에 대해서도 `multiPoint` 환경 설정이 자동으로 활성화될 것이라는 점이다. + +`disabled` 필드를 사용하여, `MultiPoint` 확장으로부터 특정 익스텐션 포인트를 제외할 수 있다. +기본 플러그인을 비활성화하거나, 기본이 아닌(non-default) 플러그인을 비활성화하거나, +와일드카드(`'*'`)를 사용하여 모든 플러그인을 비활성화할 수 있다. +다음은 `Score` 와 `PreScore` 에 대해 비활성화하는 예시이다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: non-multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: 'MyPlugin' + preScore: + disabled: + - name: '*' + score: + disabled: + - name: '*' +``` + +`v1beta3` 에서, `MultiPoint` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다. +그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다. +예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고 +각각의 가중치가 `1` 이라고 하자. +이 때, 다음과 같이 가중치를 다르게 설정하여 순서를 바꿀 수 있다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + score: + enabled: + - name: 'DefaultScore2' + weight: 5 +``` + +이 예제에서, 이 플러그인들을 `MultiPoint` 에 명시할 필요는 없는데, +이는 이 플러그인들이 기본 플러그인이기 때문이다. +그리고 `Score` 에는 `DefaultScore2` 플러그인만 명시되었다. +이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 `MultiPoint` 플러그인보다 우선순위가 높기 때문이다. +결론적으로, 위의 예시에서는 두 플러그인을 모두 명시하지 않고도 두 플러그인의 순서를 조정하였다. + +`MultiPoint` 플러그인을 설정할 때, 일반적인 우선 순위는 다음과 같다. +1. 명시된 익스텐션 포인트가 먼저 실행되며, 여기에 명시된 환경 설정은 다른 모든 곳에 설정된 내용보다 우선한다. +2. `MultiPoint` 및 플러그인 설정을 통해 수동으로 구성된 플러그인 +3. 기본 플러그인 및 기본 플러그인의 기본 설정 + +위의 우선 순위를 설명하기 위해, 다음과 같은 예시를 가정한다. +| 플러그인 | 익스텐션 포인트 | +|---|---| +|`DefaultQueueSort`|`QueueSort`| +|`CustomQueueSort`|`QueueSort`| +|`DefaultPlugin1`|`Score`, `Filter`| +|`DefaultPlugin2`|`Score`| +|`CustomPlugin1`|`Score`, `Filter`| +|`CustomPlugin2`|`Score`, `Filter`| + +이들 플러그인에 대한 유효한 예시 환경 설정은 다음과 같다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: 'CustomQueueSort' + - name: 'CustomPlugin1' + weight: 3 + - name: 'CustomPlugin2' + disabled: + - name: 'DefaultQueueSort' + filter: + disabled: + - name: 'DefaultPlugin1' + score: + enabled: + - name: 'DefaultPlugin2' +``` + +명시한 익스텐션 포인트 내에 `MultiPoint` 플러그인을 재정의해도 에러가 발생하지 않음에 유의한다. +명시한 익스텐션 포인트의 우선 순위가 더 높으므로, +이 재정의는 무시되고 로그에만 기록된다. + +대부분의 환경 설정을 한 곳에서 관리하는 것 말고도, 이 예시는 다음과 같은 내용을 포함한다. +* 커스텀 `queueSort` 플러그인을 활성화하고 기존의 기본 플러그인을 비활성화한다 +* `CustomPlugin1` 과 `CustomPlugin2` 플러그인을 활성화하며, 이 플러그인에 연결된 모든 익스텐션 포인트를 위해 이 플러그인들이 먼저 실행된다 +* `filter` 에 대해서만 `DefaultPlugin1` 을 비활성화한다 +* `score` 에 대해, `DefaultPlugin2` 플러그인이 (심지어 커스텀 플러그인보다도) 가장 먼저 실행되도록 순서를 조정한다 + +`multiPoint` 필드가 없는 `v1beta3` 이전 버전의 환경 설정에서는, 위의 스니펫을 다음과 같이 표현할 수 있다. +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta2 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + + # 기본 QueueSort 플러그인을 비활성화한다 + queueSort: + enabled: + - name: 'CustomQueueSort' + disabled: + - name: 'DefaultQueueSort' + + # 커스텀 Filter 플러그인을 활성화한다 + filter: + enabled: + - name: 'CustomPlugin1' + - name: 'CustomPlugin2' + - name: 'DefaultPlugin2' + disabled: + - name: 'DefaultPlugin1' + + # 커스텀 score 플러그인을 활성화하고 순서를 조정한다 + score: + enabled: + - name: 'DefaultPlugin2' + weight: 1 + - name: 'DefaultPlugin1' + weight: 3 +``` + +다소 복잡한 예시를 통해, 익스텐션 포인트를 설정함에 있어서 `MultiPoint` 환경 설정의 유연성과 +기존 방법과의 끊김없는 통합을 확인할 수 있다. + ## 스케줄러 설정 전환 {{< tabs name="tab_with_md" >}} @@ -284,8 +442,14 @@ profiles: * v1beta2 설정 파일에서 활성화된 플러그인은 해당 플러그인의 기본 설정값보다 v1beta2 설정 파일의 값이 우선 적용된다. -* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port`가 잘못 설정되면 검증 실패를 유발한다. +* 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port` 가 잘못 설정되면 검증 실패를 유발한다. +{{% /tab %}} +{{% tab name="v1beta2 → v1beta3" %}} +* 세 플러그인의 가중치 기본값이 다음과 같이 증가한다. + * `InterPodAffinity`: 1 에서 2 로 + * `NodeAffinity`: 1 에서 2 로 + * `TaintToleration`: 1 에서 3 으로 {{% /tab %}} {{< /tabs >}} @@ -293,5 +457,5 @@ profiles: * [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 -* [kube-scheduler 설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기 * [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/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md index 1146ba033a..462b044bff 100644 --- a/content/ko/docs/reference/scheduling/policies.md +++ b/content/ko/docs/reference/scheduling/policies.md @@ -1,102 +1,20 @@ --- title: 스케줄링 정책 content_type: concept -weight: 10 +sitemap: + priority: 0.2 # Scheduling priorities are deprecated --- -스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다. +쿠버네티스 v1.23 이전 버전에서는, *단정(predicates)* 및 *우선순위(priorities)* 프로세스를 지정하기 위해 스케줄링 정책을 사용할 수 있다. +예를 들어, `kube-scheduler --policy-config-file ` 또는 `kube-scheduler --policy-configmap ` 명령을 실행하여 스케줄링 정책을 설정할 수 있다. -`kube-scheduler --policy-config-file ` 또는 `kube-scheduler --policy-configmap `을 실행하고 [정책 유형](/docs/reference/config-api/kube-scheduler-policy-config.v1/)을 사용하여 스케줄링 정책을 설정할 수 있다. - - - -## 단정 {#predicates} - -다음의 *단정* 은 필터링을 구현한다. - -- `PodFitsHostPorts`: 파드가 요청하는 파드의 포트에 대해 노드에 사용할 수 있는 - 포트(네트워크 프로토콜 종류)가 있는지 확인한다. - -- `PodFitsHost`: 파드가 호스트 이름으로 특정 노드를 지정하는지 확인한다. - -- `PodFitsResources`: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는 - 리소스(예: CPU 및 메모리)가 있는지 확인한다. - -- `MatchNodeSelector`: 파드의 노드 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 - 노드의 {{< glossary_tooltip text="레이블" term_id="label" >}}과 일치하는지 확인한다. - -- `NoVolumeZoneConflict`: 해당 스토리지에 대한 장애 영역 제한이 주어지면 - 파드가 요청하는 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 노드에서 사용할 수 있는지 - 평가한다. - -- `NoDiskConflict`: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해 - 파드가 노드에 적합한지 평가한다. - -- `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와 - 구성된 제한을 초과하는지 여부를 결정한다. - -- `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이 - 노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다. - -- `CheckVolumeBinding`: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다. - 이는 바인딩된 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}와 - 바인딩되지 않은 PVC 모두에 적용된다. - -## 우선순위 {#priorities} - -다음의 *우선순위* 는 스코어링을 구현한다. - -- `SelectorSpreadPriority`: 동일한 {{< glossary_tooltip text="서비스" term_id="service" >}}, - {{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는 - {{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}에 속하는 - 파드를 고려하여, 파드를 여러 호스트에 파드를 분산한다. - -- `InterPodAffinityPriority`: 선호된 - [파드간 어피니티와 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 구현한다. - -- `LeastRequestedPriority`: 요청된 리소스가 적은 노드를 선호한다. 즉, - 노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가 - 많을수록 이 정책이 부여하는 순위가 낮아진다. - -- `MostRequestedPriority`: 요청된 리소스가 가장 많은 노드를 선호한다. - 이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된 - 파드를 맞춘다. - -- `RequestedToCapacityRatioPriority`: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다. - -- `BalancedResourceAllocation`: 균형 잡힌 리소스 사용의 노드를 선호한다. - -- `NodePreferAvoidPodsPriority`: 노드 어노테이션 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라 - 노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가 - 동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다. - -- `NodeAffinityPriority`: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링 - 설정에 따라 노드의 우선순위를 지정한다. - 이에 대한 자세한 내용은 [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)에서 확인할 수 있다. - -- `TaintTolerationPriority`: 노드에서 용인할 수 없는 테인트 수를 기반으로, - 모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을 - 고려하여 노드의 순위를 조정한다. - -- `ImageLocalityPriority`: 해당 파드의 - {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}가 이미 로컬로 캐시된 - 노드를 선호한다. - -- `ServiceSpreadingPriority`: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한 - 파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한 - 파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는 - 서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다. - -- `EqualPriority`: 모든 노드에 동일한 가중치를 부여한다. - -- `EvenPodsSpreadPriority`: 선호된 - [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다. +이러한 스케줄링 정책은 쿠버네티스 v1.23 버전부터 지원되지 않는다. 관련된 플래그인 `policy-config-file`, `policy-configmap`, `policy-configmap-namespace`, `use-legacy-policy-config` 플래그도 지원되지 않는다. 대신, 비슷한 효과를 얻기 위해 [스케줄러 구성](/ko/docs/reference/scheduling/config/)을 사용한다. ## {{% heading "whatsnext" %}} * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기 * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기 -* [kube-scheduler configuration 레퍼런스 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2) 읽어보기 +* [kube-scheduler configuration 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3) 읽어보기 * [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기 diff --git a/content/ko/docs/reference/tools/_index.md b/content/ko/docs/reference/tools/_index.md index e618bcacc5..6cf9e76a3c 100644 --- a/content/ko/docs/reference/tools/_index.md +++ b/content/ko/docs/reference/tools/_index.md @@ -49,3 +49,19 @@ Kompose의 용도 * 도커 컴포즈 파일을 쿠버네티스 오브젝트로 변환 * 로컬 도커 개발 환경에서 나의 애플리케이션을 쿠버네티스를 통해 관리하도록 이전 * V1 또는 V2 도커 컴포즈 `yaml` 파일 또는 [분산 애플리케이션 번들](https://docs.docker.com/compose/bundles/)을 변환 + +## Kui + +[`Kui`](https://github.com/kubernetes-sigs/kui)는 입력으로 일반적인 `kubectl` 커맨드 라인 요청을 받고 +출력으로 그래픽적인 응답을 제공하는 GUI 도구이다. + +Kui는 입력으로 일반적인 `kubectl` 커맨드 라인 요청을 받고 출력으로 그래픽적인 응답을 제공한다. +Kui는 ASCII 표 대신 정렬 가능한 표를 GUI로 제공한다. + +Kui를 사용하면 다음의 작업이 가능하다. + +* 자동으로 생성되어 길이가 긴 리소스 이름을 클릭하여 복사할 수 있다. +* `kubectl` 명령을 입력하면 실행되는 모습을 볼 수 있으며, `kubectl` 보다 더 빠른 경우도 있다. +* {{< glossary_tooltip text="잡" term_id="job">}}을 조회하여 + 실행 형상을 워터폴 그림으로 확인한다. +* 탭이 있는 UI를 이용하여 클러스터의 자원을 클릭 동작으로 확인할 수 있다. diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 11d2e793bc..aad89380f6 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -1,5 +1,7 @@ --- title: 클라이언트 라이브러리 + + content_type: concept weight: 30 --- @@ -35,7 +37,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) | Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) - ## 커뮤니티에 의해 관리되는 클라이언트 라이브러리 {{% thirdparty-content %}} @@ -70,7 +71,6 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | | Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | -| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/k8s-ruby/k8s-ruby](https://github.com/k8s-ruby/k8s-ruby) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | diff --git a/content/ko/docs/reference/using-api/health-checks.md b/content/ko/docs/reference/using-api/health-checks.md index d9277c25f9..3e4b113e6d 100644 --- a/content/ko/docs/reference/using-api/health-checks.md +++ b/content/ko/docs/reference/using-api/health-checks.md @@ -1,5 +1,7 @@ --- title: 쿠버네티스 API 헬스(health) 엔드포인트 + + content_type: concept weight: 50 --- @@ -18,11 +20,11 @@ weight: 50 `/readyz` 엔드포인트는 `--shutdown-delay-duration` [플래그](/docs/reference/command-line-tools-reference/kube-apiserver) 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다. API 서버의 `healthz`/`livez`/`readyz` 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다. 상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 `healthy`/`live`/`ready` 상태를 나타낸다. -아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다. +아래 표시된 더 자세한 옵션은 운영자가 클러스터를 디버깅하거나 특정 API 서버의 상태를 이해하는 데 사용할 수 있다. 다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다. -모든 엔드포인트는 `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다. +모든 엔드포인트에 대해, `verbose` 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다. 이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다. ```shell @@ -91,7 +93,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' {{< feature-state state="alpha" >}} -각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다. +각 개별 헬스 체크는 HTTP 엔드포인트를 노출하며 개별적으로 체크할 수 있다. 개별 체크를 위한 스키마는 `/livez/` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다. `` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다. 이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다. diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 999bfd192e..71520bf0e8 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -67,7 +67,7 @@ sudo sysctl --system 자세한 내용은 [네트워크 플러그인 요구 사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#네트워크-플러그인-요구-사항) 페이지를 참고한다. ## 필수 포트 확인 {#check-required-ports} -[필수 포트들](/docs/reference/ports-and-protocols/)은 +[필수 포트들](/ko/docs/reference/ports-and-protocols/)은 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야 한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다. @@ -243,7 +243,7 @@ sudo mkdir -p $DOWNLOAD_DIR crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요) ```bash -CRICTL_VERSION="v1.17.0" +CRICTL_VERSION="v1.22.0" ARCH="amd64" curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` diff --git a/content/ko/docs/setup/production-environment/tools/kubespray.md b/content/ko/docs/setup/production-environment/tools/kubespray.md index 6e7d9c8185..598ad32609 100644 --- a/content/ko/docs/setup/production-environment/tools/kubespray.md +++ b/content/ko/docs/setup/production-environment/tools/kubespray.md @@ -38,8 +38,8 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h * 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)) * 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다 * **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다 -* **방화벽은 관리되지 않는다**. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다 -* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다 +* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다 +* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다 Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다: diff --git a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index aadf5847d9..a648edc980 100644 --- a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -998,7 +998,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 -[섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 +[섹션](/ko/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index aaa96a4fcf..7e0ac5763b 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -1,4 +1,9 @@ --- + + + + + title: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드 content_type: concept weight: 75 @@ -155,7 +160,21 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동 노드셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. + {{< note >}} +`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면, +파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). +리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다. +윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을 +`windows`로 설정한다. +스케줄러는 파드를 노드에 할당할 때 `.spec.os.name` 필드의 값을 사용하지 않는다. +컨트롤 플레인이 파드를 적절한 운영 체제가 실행되고 있는 노드에 배치하도록 하려면, +[파드를 노드에 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)하는 +일반적인 쿠버네티스 메카니즘을 사용해야 한다. +`.spec.os.name` 필드는 윈도우 파드의 스케줄링에는 영향을 미치지 않기 때문에, +윈도우 파드가 적절한 윈도우 노드에 할당되도록 하려면 테인트, +톨러레이션 및 노드 셀렉터가 여전히 필요하다. + {{< /note >}} ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기 사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다. diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 9e7c9b4fc7..810259621a 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -214,117 +214,9 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. ## 클러스터에서 실행되는 서비스로 접근 -이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 -쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. +이전 섹션에서는 쿠버네티스 API 서버에 연결하는 방법을 소개하였다. 쿠버네티스 클러스터에서 실행되는 다른 서비스에 연결하는 방법은 [클러스터 접근](/ko/docs/tasks/access-application-cluster/access-cluster/) 페이지를 참조한다. -쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), -[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 -고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 -클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을 -할 수 없을 것이다. - -### 통신을 위한 방식들 - -클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다. - - - 공인 IP를 통해 서비스에 접근. - - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 - 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 - [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며, - 인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. - 해당 서비스는 자체적으로 인증을 수행하는가? - - 파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 - 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다. - - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 - 접근할 필요는 없다. - - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근. - - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다. - 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에 - 접근을 하려고 하거나 debugging을 하려면 이를 사용한다. - - 어떤 web 애플리케이션에서는 프록시가 문제를 일으킬 수 있다. - - HTTP/HTTPS에서만 동작한다. - - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. - - 클러스터 내 노드 또는 파드에서 접근. - - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. - 해당 셸에서 다른 노드, 파드, 서비스에 연결한다. - - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 - 클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 - 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. - -### 빌트인 서비스 검색 - -일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. -`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다. - -```shell -kubectl cluster-info -``` - -결괏값은 다음과 같을 것이다. - -``` -Kubernetes master is running at https://104.197.5.247 -elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy -kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy -kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy -grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy -heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy -``` - -이는 각 서비스에 접근하기 위한 proxy-verb URL을 보여준다. -예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 -`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 접근할 수 있다. 예를 들어 kubectl proxy로 -`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 접근할 수도 있다. -(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [쿠버네티스 API를 사용해서 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)을 참조한다.) - -#### 수작업으로 apiserver proxy URL을 구축 - -위에서 언급한 것처럼 서비스의 proxy URL을 검색하는 데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에 -`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. - -당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다. - -기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다. -`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy` - -URL의 네임 부분에 지원되는 양식은 다음과 같다. - -* `` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. -* `:` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. -* `https::` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의) -* `https::` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. - -##### 예제들 - - * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 접근하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다. - * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 접근하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다. - -```json -{ - "cluster_name" : "kubernetes_logging", - "status" : "yellow", - "timed_out" : false, - "number_of_nodes" : 1, - "number_of_data_nodes" : 1, - "active_primary_shards" : 5, - "active_shards" : 5, - "relocating_shards" : 0, - "initializing_shards" : 0, - "unassigned_shards" : 5 -} -``` - -### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 접근 - -브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만 - - - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, - 당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다. - - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 - 구성하는 client side javascript를 가진 web app은 동작하지 않을 수 있다. - -## 요청 redirect +## redirect 요청하기 redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다. diff --git a/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md index 11afa655e8..01888bf2cb 100644 --- a/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -26,7 +26,7 @@ weight: 70 이 작업은 지원되는 환경이 필요한 -[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#nodeport) 서비스 타입을 +[외부 로드밸런서가 있는 서비스](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 사용한다. 만약, 이를 지원하지 않는 환경이라면, [노드포트](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스 타입을 대신 사용할 수 있다. diff --git a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md index f777d192cd..a6f4f086d2 100644 --- a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -70,7 +70,7 @@ jsonpath에서 `.items[*]` 부분은 생략해야 하는데, 이는 명령어가 반복하여 출력할 수 있다. ```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 ``` @@ -80,7 +80,7 @@ sort 명령어 결과값은 `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 ``` ## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기 diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md index 8019e46c25..ab083d3690 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -86,7 +86,17 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi 위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 서비스의 프록시 URL에 추가하면 된다. `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy` -포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. +포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다. 또한, 이름이 지정된 포트와 지정되지 않은 포트 모두에 대해, *port_name* 자리에 포트 번호를 기재할 수도 있다. + +기본적으로, API 서버는 서비스로의 프록시를 HTTP로 제공한다. HTTPS를 사용하려면, 서비스 이름 앞에 `https:`를 추가한다. +`http://<쿠버네티스_컨트롤_플레인_주소>/api/v1/namespaces/<네임스페이스_이름>/services/<서비스_이름>/proxy` + +URL에서 `<서비스_이름>`이 지원하는 형식은 다음과 같다. + +* `<서비스_이름>` - 기본 포트 또는 이름이 지정되지 않은 포트로 http를 사용하여 프록시 +* `<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 http를 사용하여 프록시 +* `https:<서비스_이름>:` - 기본 포트 또는 이름이 지정되지 않은 포트로 https를 사용하여 프록시(맨 끝의 콜론에 유의) +* `https:<서비스_이름>:<포트_이름>` - 기재된 포트 이름 또는 포트 번호로 https를 사용하여 프록시 ##### 예제 diff --git a/content/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints.md b/content/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints.md deleted file mode 100644 index c0342fb377..0000000000 --- a/content/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: 토폴로지 인지 힌트 활성화하기 -content_type: task -min-kubernetes-server-version: 1.21 ---- - - -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} - -_토폴로지 인지 힌트_ 는 {{< glossary_tooltip text="엔드포인트슬라이스(EndpointSlices)" term_id="endpoint-slice" >}}에 포함되어 있는 -토폴로지 정보를 이용해 토폴로지 인지 라우팅을 가능하게 한다. -이 방법은 트래픽을 해당 트래픽이 시작된 곳과 최대한 근접하도록 라우팅하는데, -이를 통해 비용을 줄이거나 네트워크 성능을 향상시킬 수 있다. - -## {{% heading "prerequisites" %}} - - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -토폴로지 인지 힌트를 활성화하기 위해서는 다음의 필수 구성 요소가 필요하다. - -* {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가 - iptables 모드 혹은 IPVS 모드로 동작하도록 설정 -* 엔드포인트슬라이스가 비활성화되지 않았는지 확인 - -## 토폴로지 인지 힌트 활성화하기 - -서비스 토폴로지 힌트를 활성화하기 위해서는 kube-apiserver, kube-controller-manager, kube-proxy에 대해 -`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -활성화한다. - -``` ---feature-gates="TopologyAwareHints=true" -``` - -## {{% heading "whatsnext" %}} - -* 서비스 항목 아래의 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints)를 참고 -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 참고 diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md b/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md deleted file mode 100644 index b9949922c5..0000000000 --- a/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md +++ /dev/null @@ -1,224 +0,0 @@ ---- - - -title: 고가용성 쿠버네티스 클러스터 컨트롤 플레인 설정하기 -content_type: task - ---- - - - -{{< feature-state for_k8s_version="v1.5" state="alpha" >}} - -구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 컨트롤 플레인 노드를 복제할 수 있다. 하지만 이러한 스크립트들은 프로덕션 용도로 사용하기에 적합하지 않으며, 프로젝트의 CI에서만 주로 사용된다. -이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 컨트롤 플레인을 관리하는 방법과 GCE와 함께 사용하기 위해 HA 컨트롤 플레인을 구현하는 방법에 관해 설명한다. - - - - -## {{% heading "prerequisites" %}} - - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - - - -## HA 호환 클러스터 시작 - -새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다. - -* `MULTIZONE=true` - 서버의 기본 영역(zone)과 다른 영역에서 컨트롤 플레인 kubelet이 제거되지 않도록 한다. -여러 영역에서 컨트롤 플레인 노드를 실행(권장됨)하려는 경우에 필요하다. - -* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다. -true인 경우, Etcd의 리더 복제본에서 읽는다. -이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다. - -선택적으로, 첫 번째 컨트롤 플레인 노드가 생성될 GCE 영역을 지정할 수 있다. -다음 플래그를 설정한다. - -* `KUBE_GCE_ZONE=zone` - 첫 번째 컨트롤 플레인 노드가 실행될 영역. - -다음 샘플 커맨드는 europe-west1-b GCE 영역에 HA 호환 클러스터를 구성한다. - -```shell -MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh -``` - -위의 커맨드는 하나의 컨트롤 플레인 노드를 포함하는 클러스터를 생성한다. -그러나 후속 커맨드로 새 컨트롤 플레인 노드를 추가할 수 있다. - -## 새 컨트롤 플레인 노드 추가 - -HA 호환 클러스터를 생성했다면, 여기에 컨트롤 플레인 노드를 추가할 수 있다. -`kube-up` 스크립트에 다음 플래그를 사용하여 컨트롤 플레인 노드를 추가한다. - -* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 컨트롤 플레인 노드의 복제본을 -만든다. - -* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 실행될 영역. -반드시 다른 컨트롤 플레인 노드가 존재하는 영역과 동일한 지역(region)에 있어야 한다. - -HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로 -설정할 필요는 없다. - -다음 샘플 커맨드는 기존 HA 호환 클러스터에서 -컨트롤 플레인 노드를 복제한다. - -```shell -KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh -``` - -## 컨트롤 플레인 노드 제거 - -다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 컨트롤 플레인 노드를 제거할 수 있다. - -* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다. - -* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 제거될 영역. - -* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 컨트롤 플레인 노드의 이름. -명시하지 않으면, 해당 영역의 모든 복제본이 제거된다. - -다음 샘플 커맨드는 기존 HA 클러스터에서 컨트롤 플레인 노드를 제거한다. - -```shell -KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh -``` - -## 동작에 실패한 컨트롤 플레인 노드 처리 - -HA 클러스터의 컨트롤 플레인 노드 중 하나가 동작에 실패하면, -클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인 -노드를 추가하는 것이 가장 좋다. -다음 샘플 커맨드로 이 과정을 시연한다. - -1. 손상된 복제본을 제거한다. - -```shell -KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh -``` - -
  1. 기존 복제본을 대신할 새 노드를 추가한다.
- -```shell -KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh -``` - -## HA 클러스터에서 컨트롤 플레인 노드 복제에 관한 모범 사례 - -* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안, -해당 영역에 있는 컨트롤 플레인 노드도 모두 동작에 실패할 것이다. -영역 장애를 극복하기 위해 노드를 여러 영역에 배치한다 -(더 자세한 내용은 [멀티 영역](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다). - -* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된 -컨트롤 플레인에서의 합의를 위해서는 지속적 상태(persistent state) 변경 시 두 컨트롤 플레인 노드가 모두 정상적으로 동작 중이어야 한다. -결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도 -클러스터의 심각한 장애 상태를 초래한다. -따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은 -단일 노드로 구성된 컨트롤 플레인보다도 못하다. - -* 컨트롤 플레인 노드를 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다. -클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다. -이 작업은 [etcd 관리 가이드](https://etcd.io/docs/v2.3/admin_guide/#member-migration)에 기술한 대로 -Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다. -(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다) - - - - - -## 구현 지침 - -![ha-control-plane](/docs/images/ha-control-plane.svg) - -### 개요 -위의 그림은 3개의 컨트롤 플레인 노드와 컴포넌트를 고가용 클러스터로 구성한 형상을 보여준다. 해당 컨트롤 플레인 노드의 컴포넌트들은 다음의 방법을 차용하고 있다. - -- etcd: 인스턴스는 합의(consensus)를 통해서 클러스터링되어 있다. - -- 컨트롤러들, 스케줄러, 클러스터 오토-스케일러: 리스(lease) 메커니즘을 통해 클러스터에서 각각 단 하나의 인스턴스만 활성화될 것이다. - -- 애드-온(add-on) 메니저: 애드-온들이 동기화를 유지하도록 각각 독립적으로 동작한다. - -추가적으로, API 서버들 앞에서 동작하는 로드 밸런서는 내부와 외부 트래픽을 컨트롤 플레인 노드들로 연결(route)한다. -각 컨트롤 플레인 노드는 다음 모드에서 다음 구성 요소를 실행한다. - -* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다. - -* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다. - -* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다. - -* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다. - -또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다. - -### 로드 밸런싱 - -두 번째 컨트롤 플레인 노드를 배치할 때, 두 개의 복제본에 대한 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다. -비슷하게 끝에서 두 번째의 컨트롤 플레인 노드를 제거한 후에는 로드 밸런서가 제거되고 -해당 IP 주소는 마지막으로 남은 복제본에 할당된다. -로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다. - -### 컨트롤 플레인 서비스와 Kubelet - -쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신, -시스템은 모든 트래픽을 외부 IP 주소로 보낸다. - -* 단일 노드 컨트롤 플레인의 경우, IP 주소는 단일 컨트롤 플레인 노드를 가리킨다. - -* 고가용성 컨트롤 플레인의 경우, IP 주소는 컨트롤 플레인 노드 앞의 로드밸런서를 가리킨다. - -마찬가지로 Kubelet은 외부 IP 주소를 사용하여 컨트롤 플레인과 통신한다. - -### 컨트롤 플레인 노드 인증서 - -쿠버네티스는 각 컨트롤 플레인 노드의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 TLS 인증서를 발급한다. -컨트롤 플레인 노드의 임시 퍼블릭 IP 주소에 대한 인증서는 없다. -임시 퍼블릭 IP 주소를 통해 컨트롤 플레인 노드에 접근하려면, TLS 검증을 건너뛰어야 한다. - -### etcd 클러스터화 - -etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용). -이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다. - -### API 서버 신원 - -{{< feature-state state="alpha" for_k8s_version="v1.20" >}} - -API 서버 식별 기능은 -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에 -의해 제어되며 기본적으로 활성화되지 않는다. -{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} -시작 시 `APIServerIdentity` 라는 기능 게이트를 활성화하여 API 서버 신원을 활성화할 수 있다. - -```shell -kube-apiserver \ ---feature-gates=APIServerIdentity=true \ - # …다른 플래그는 평소와 같다. -``` - -부트스트랩 중에 각 kube-apiserver는 고유한 ID를 자신에게 할당한다. ID는 -`kube-apiserver-{UUID}` 형식이다. 각 kube-apiserver는 -_kube-system_ {{< glossary_tooltip text="네임스페이스" term_id="namespace">}}에 -[임대](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)를 생성한다. -임대 이름은 kube-apiserver의 고유 ID이다. 임대에는 -`k8s.io/component=kube-apiserver` 라는 레이블이 있다. 각 kube-apiserver는 -`IdentityLeaseRenewIntervalSeconds` (기본값은 10초)마다 임대를 새로 갱신한다. 각 -kube-apiserver는 `IdentityLeaseDurationSeconds` (기본값은 3600초)마다 -모든 kube-apiserver 식별 ID 임대를 확인하고, -`IdentityLeaseDurationSeconds` 이상 갱신되지 않은 임대를 삭제한다. -`IdentityLeaseRenewIntervalSeconds` 및 `IdentityLeaseDurationSeconds`는 -kube-apiserver 플래그 `identity-lease-renew-interval-seconds` -및 `identity-lease-duration-seconds`로 구성된다. - -이 기능을 활성화하는 것은 HA API 서버 조정과 관련된 기능을 -사용하기 위한 전제조건이다(예: `StorageVersionAPI` 기능 게이트). - -## 추가 자료 - -[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index e7a1b8fb79..4ce00186a3 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -1,4 +1,9 @@ --- + + + + + title: 윈도우 노드 추가 min-kubernetes-server-version: 1.17 content_type: tutorial diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 0e76e46c93..440f9d5026 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -78,10 +78,6 @@ OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리 apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다. @@ -175,10 +171,6 @@ sudo kubeadm upgrade apply apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 @@ -218,10 +210,6 @@ sudo systemctl restart kubelet apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 @@ -256,10 +244,6 @@ sudo systemctl restart kubelet apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - - - # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 - apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 diff --git a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md index 8adf5c4564..33bc3de55d 100644 --- a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md @@ -10,8 +10,20 @@ content_type: task {{< feature-state for_k8s_version="v1.21" state="stable" >}} 이 문서는 쿠버네티스 클러스터에서 {{< glossary_tooltip term_id="sysctl" >}} 인터페이스를 사용하여 -커널 파라미터를 어떻게 구성하고, 사용하는지를 설명한다. +커널 파라미터를 어떻게 구성하고, 사용하는지를 +설명한다. +{{< note >}} +쿠버네티스 버전 1.23부터, kubelet은 `/` 또는 `.`를 +sysctl 이름의 구분자로 사용하는 것을 지원한다. +예를 들어, 동일한 sysctl 이름을 `kernel.shm_rmid_forced`와 같이 마침표를 구분자로 사용하여 나타내거나 +`kernel/shm_rmid_forced`와 같이 슬래시를 구분자로 사용하여 나타낼 수 있다. +sysctl 파라미터 변환에 대한 세부 사항은 +리눅스 맨페이지 프로젝트의 +[sysctl.d(5)](https://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다. +파드와 파드시큐리티폴리시(PodSecurityPolicy)에 대해 sysctl을 설정하는 기능에서는 +아직 슬래시 구분자를 지원하지 않는다. +{{< /note >}} ## {{% heading "prerequisites" %}} @@ -20,6 +32,7 @@ content_type: task 일부 단계에서는 실행 중인 클러스터의 kubelet에서 커맨드 라인 옵션을 재구성할 필요가 있다. + ## 모든 sysctl 파라미터 나열 @@ -52,12 +65,13 @@ sysctl은 _safe_ sysctl과 _unsafe_ sysctl로 구성되어 있다. _safe_ sysctl 허용하지 않아야 한다 아직까지 대부분 _네임스페이스된_ sysctl은 _safe_ sysctl로 고려되지 않았다. ->>> 다음 sysctl은 _safe_ 명령을 지원한다. +다음 sysctl은 _safe_ 명령을 지원한다. - `kernel.shm_rmid_forced`, - `net.ipv4.ip_local_port_range`, - `net.ipv4.tcp_syncookies`, -- `net.ipv4.ping_group_range` (Kubernetes 1.18 이후). +- `net.ipv4.ping_group_range` (쿠버네티스 1.18 이후), +- `net.ipv4.ip_unprivileged_port_start` (쿠버네티스 1.22 이후). {{< note >}} `net.ipv4.tcp_syncookies` 예시는 리눅스 커널 버전 4.4 또는 이하에서 네임스페이스되지 않는다. @@ -112,10 +126,13 @@ _네임스페이스_ sysctl만 이 방법을 사용할 수 있다. 이를 설정해야 한다면, 각 노드의 OS에서 수동으로 구성하거나 특권있는 컨테이너의 데몬셋을 사용하여야 한다. -네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. securityContext는 동일한 파드의 모든 컨테이너에 적용된다. +네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. +securityContext는 동일한 파드의 모든 컨테이너에 적용된다. 이 예시는 safe sysctl `kernel.shm_rmid_forced`와 두 개의 unsafe sysctl인 `net.core.somaxconn` 과 `kernel.msgmax` 를 설정하기 위해 파드 securityContext를 사용한다. +스펙에 따르면 _safe_ sysctl과 _unsafe_ sysctl 간 +차이는 없다. {{< warning >}} 파라미터의 영향을 파악한 후에만 운영체제가 diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 3461c57061..a2bac74f99 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -96,11 +96,10 @@ hostPath 퍼시스턴트볼륨의 설정 파일은 아래와 같다. 설정 파일에 클러스터 노드의 `/mnt/data` 에 볼륨이 있다고 지정한다. 또한 설정에서 볼륨 크기를 10 기가바이트로 지정하고 단일 노드가 -읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 -지정한다. 여기서는 +읽기-쓰기 모드로 볼륨을 마운트할 수 있는 `ReadWriteOnce` 접근 모드를 지정한다. 여기서는 퍼시스턴트볼륨클레임의 [스토리지클래스 이름](/ko/docs/concepts/storage/persistent-volumes/#클래스)을 `manual` 로 정의하며, 퍼시스턴트볼륨클레임의 요청을 -이 퍼시스턴트볼륨에 바인딩하는데 사용한다. +이 퍼시스턴트볼륨에 바인딩하는 데 사용한다. 퍼시스턴트볼륨을 생성한다. @@ -237,8 +236,14 @@ sudo rmdir /mnt/data 이제 사용자 노드에서 셸을 종료해도 된다. +## 하나의 퍼시스턴트볼륨을 두 경로에 마운트하기 +{{< codenew file="pods/storage/pv-duplicate.yaml" >}} +하나의 퍼시스턴트볼륨을 nginx 컨테이너의 두 경로에 마운트할 수 있다. + +`/usr/share/nginx/html` - 정적 웹사이트 용 +`/etc/nginx/nginx.conf` - 기본 환경 설정 용 diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index bb14d1c0ac..3a33d7a5fc 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -6,29 +6,36 @@ weight: 100 -이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 +이 페이지는 프라이빗 컨테이너 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 +{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}}을 사용하는 파드를 생성하는 방법을 보여준다. +{{% thirdparty-content single="true" %}} + ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* {{< include "task-tutorial-prereqs.md" >}} -* 이 실습을 수행하기 위해, -[도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다. +* 이 실습을 수행하기 위해, `docker` 명령줄 도구와 +[도커 ID](https://docs.docker.com/docker-id/) 및 비밀번호가 필요하다. -## 도커 로그인 +## 도커 허브 로그인 노트북에 프라이빗 이미지를 받아오기 위하여 레지스트리 인증을 필수로 수행해야 한다. +`docker` 도구를 사용하여 도커 허브에 로그인한다. 자세한 정보는 +[도커 ID 계정](https://docs.docker.com/docker-id/#log-in)의 _로그 인_ 섹션을 참조한다. + ```shell docker login ``` -프롬프트가 나타나면, 도커 사용자 이름(username)과 비밀번호(password)를 입력하자. +프롬프트가 나타나면, 도커 ID를 입력한 다음, 사용하려는 자격증명(액세스 토큰, +또는 도커 ID의 비밀번호)을 입력한다. -로그인 프로세스는 권한 토큰 정보를 가지고 있는 `config.json` 파일을 생성하거나 업데이트 한다. +로그인 프로세스를 수행하면 권한 토큰 정보를 가지고 있는 `config.json` 파일이 생성되거나 업데이트된다. [쿠버네티스가 이 파일을 어떻게 해석하는지](/ko/docs/concepts/containers/images#config-json) 참고한다. `config.json` 파일을 확인하자. @@ -171,14 +178,14 @@ janedoe:xxxxxxxxxxx ## 시크릿을 사용하는 파드 생성하기 -다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 파드의 구성 파일이다. +다음은 `regcred` 에 있는 도커 자격 증명에 접근해야 하는 예제 파드의 매니페스트이다. {{< codenew file="pods/private-reg-pod.yaml" >}} -아래의 파일을 다운로드받는다. +위 파일을 컴퓨터에 다운로드한다. ```shell -wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml +curl -L -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yaml ``` `my-private-reg-pod.yaml` 파일 안에서, `` 값을 다음과 같은 프라이빗 저장소 안의 이미지 경로로 변경한다. @@ -200,9 +207,9 @@ kubectl get pod private-reg ## {{% heading "whatsnext" %}} -* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기. +* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기 + * 또는 {{< api-reference page="config-and-storage-resources/secret-v1" >}} API 레퍼런스 읽어보기 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기. * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기. * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기. -* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기. -* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기. +* 파드의 [컨테이너 정의](/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers)의 `imagePullSecrets` 필드에 대해 읽어보기 diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md b/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md new file mode 100644 index 0000000000..674eb75945 --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/debug-cluster.md @@ -0,0 +1,124 @@ +--- + + +title: 클러스터 트러블슈팅 +content_type: concept +--- + + + +이 문서는 클러스터 트러블슈팅에 대해 설명한다. 사용자가 겪고 있는 문제의 근본 원인으로서 사용자의 애플리케이션을 +이미 배제했다고 가정한다. +애플리케이션 디버깅에 대한 팁은 [애플리케이션 트러블슈팅 가이드](/docs/tasks/debug-application-cluster/debug-application/)를 참조한다. +자세한 내용은 [트러블슈팅 문서](/ko/docs/tasks/debug-application-cluster/troubleshooting/)를 참조한다. + + + +## 클러스터 나열하기 + +클러스터에서 가장 먼저 디버그해야 할 것은 노드가 모두 올바르게 등록되었는지 여부이다. + +다음을 실행한다. + +```shell +kubectl get nodes +``` + +그리고 보일 것으로 예상되는 모든 노드가 존재하고 모두 `Ready` 상태인지 확인한다. + +클러스터의 전반적인 상태에 대한 자세한 정보를 얻으려면 다음을 실행할 수 있다. + +```shell +kubectl cluster-info dump +``` +## 로그 보기 + +현재로서는 클러스터를 더 깊이 파고들려면 관련 머신에서 로그 확인이 필요하다. 관련 로그 파일 +위치는 다음과 같다. (systemd 기반 시스템에서는 `journalctl`을 대신 사용해야 할 수도 있다.) + +### 마스터 + + * `/var/log/kube-apiserver.log` - API 서버, API 제공을 담당 + * `/var/log/kube-scheduler.log` - 스케줄러, 스케줄 결정을 담당 + * `/var/log/kube-controller-manager.log` - 레플리케이션 컨트롤러를 담당하는 컨트롤러 + +### 워커 노드 + + * `/var/log/kubelet.log` - Kubelet, 노드에서 컨테이너 실행을 담당 + * `/var/log/kube-proxy.log` - Kube Proxy, 서비스 로드밸런싱을 담당 + +## 클러스터 장애 모드의 일반적인 개요 + +아래에 일부 오류 상황 예시 및 문제를 완화하기 위해 클러스터 설정을 조정하는 방법을 나열한다. + +### 근본 원인 + + - VM(들) 종료 + - 클러스터 내 또는 클러스터와 사용자 간의 네트워크 분할 + - 쿠버네티스 소프트웨어의 충돌 + - 데이터 손실 또는 퍼시스턴트 스토리지 사용 불가 (e.g. GCE PD 또는 AWS EBS 볼륨) + - 운영자 오류, 예를 들면 잘못 구성된 쿠버네티스 소프트웨어 또는 애플리케이션 소프트웨어 + +### 특정 시나리오 + + - API 서버 VM 종료 또는 API 서버 충돌 + - 다음의 현상을 유발함 + - 새로운 파드, 서비스, 레플리케이션 컨트롤러를 중지, 업데이트 또는 시작할 수 없다. + - 쿠버네티스 API에 의존하지 않는 기존 파드 및 서비스는 계속 정상적으로 작동할 것이다. + - API 서버 백업 스토리지 손실 + - 다음의 현상을 유발함 + - API 서버가 구동되지 않을 것이다. + - kubelet에 도달할 수 없게 되지만, kubelet이 여전히 동일한 파드를 계속 실행하고 동일한 서비스 프록시를 제공할 것이다. + - API 서버를 재시작하기 전에, 수동으로 복구하거나 API서버 상태를 재생성해야 한다. + - 지원 서비스 (노드 컨트롤러, 레플리케이션 컨트롤러 매니저, 스케쥴러 등) VM 종료 또는 충돌 + - 현재 그것들은 API 서버와 같은 위치에 있기 때문에 API 서버와 비슷한 상황을 겪을 것이다. + - 미래에는 이들도 복제본을 가질 것이며 API서버와 별도로 배치될 수도 있다. + - 지원 서비스들은 상태(persistent state)를 자체적으로 유지하지는 않는다. + - 개별 노드 (VM 또는 물리적 머신) 종료 + - 다음의 현상을 유발함 + - 해당 노드의 파드가 실행을 중지 + - 네트워크 분할 + - 다음의 현상을 유발함 + - 파티션 A는 파티션 B의 노드가 다운되었다고 생각한다. 파티션 B는 API 서버가 다운되었다고 생각한다. (마스터 VM이 파티션 A에 있다고 가정) + - Kubelet 소프트웨어 오류 + - 다음의 현상을 유발함 + - 충돌한 kubelet은 노드에서 새 파드를 시작할 수 없다. + - kubelet이 파드를 삭제할 수도 있고 삭제하지 않을 수도 있다. + - 노드는 비정상으로 표시된다. + - 레플리케이션 컨트롤러는 다른 곳에서 새 파드를 시작한다. + - 클러스터 운영자 오류 + - 다음의 현상을 유발함 + - 파드, 서비스 등의 손실 + - API 서버 백업 저장소 분실 + - API를 읽을 수 없는 사용자 + - 기타 + +### 완화 + +- 조치: IaaS VM을 위한 IaaS 공급자의 자동 VM 다시 시작 기능을 사용한다. + - 다음을 완화할 수 있음: API 서버 VM 종료 또는 API 서버 충돌 + - 다음을 완화할 수 있음: 지원 서비스 VM 종료 또는 충돌 + +- 조치: API 서버+etcd가 있는 VM에 IaaS 제공자의 안정적인 스토리지(예: GCE PD 또는 AWS EBS 볼륨)를 사용한다. + - 다음을 완화할 수 있음: API 서버 백업 스토리지 손실 + +- 조치: [고가용성](/docs/setup/production-environment/tools/kubeadm/high-availability/) 구성을 사용한다. + - 다음을 완화할 수 있음: 컨트롤 플레인 노드 종료 또는 컨트롤 플레인 구성 요소(스케줄러, API 서버, 컨트롤러 매니저) 충돌 + - 동시에 발생하는 하나 이상의 노드 또는 구성 요소 오류를 허용한다. + - 다음을 완화할 수 있음: API 서버 백업 스토리지(i.e., etcd의 데이터 디렉터리) 손실 + - 고가용성 etcd 구성을 사용하고 있다고 가정 + +- 조치: API 서버 PD/EBS 볼륨의 주기적인 스냅샷 + - 다음을 완화할 수 있음: API 서버 백업 스토리지 손실 + - 다음을 완화할 수 있음: 일부 운영자 오류 사례 + - 다음을 완화할 수 있음: 일부 쿠버네티스 소프트웨어 오류 사례 + +- 조치: 파드 앞에 레플리케이션 컨트롤러와 서비스 사용 + - 다음을 완화할 수 있음: 노드 종료 + - 다음을 완화할 수 있음: Kubelet 소프트웨어 오류 + +- 조치: 예기치 않은 재시작을 허용하도록 설계된 애플리케이션(컨테이너) + - 다음을 완화할 수 있음: 노드 종료 + - 다음을 완화할 수 있음: Kubelet 소프트웨어 오류 + + diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md index 1c2073a21b..cbd69454f5 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -73,24 +73,16 @@ kubectl exec -it cassandra -- sh ## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container} -{{< feature-state state="alpha" for_k8s_version="v1.18" >}} +{{< feature-state state="beta" for_k8s_version="v1.23" >}} -컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 -컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아 -`kubectl exec`가 충분하지 않을 경우에는 +컨테이너가 크래시 됐거나 +[distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 +컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아 `kubectl exec`로는 충분하지 않은 경우에는 {{< glossary_tooltip text="임시(Ephemeral) 컨테이너" term_id="ephemeral-container" >}}를 사용하는 것이 -인터랙티브한 트러블슈팅에 유용하다. `kubectl` `v1.18` -버전부터는 임시 컨테이너를 생성할 수 있는 알파 단계의 -명령어가 있다. +인터랙티브한 트러블슈팅에 유용하다. ### 임시 컨테이너를 사용한 디버깅 예시 {#ephemeral-container-example} -{{< note >}} -이 섹션에서 소개하는 예시를 사용하기 위해서는 -여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다. -{{< /note >}} - `kubectl debug` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다. 먼저, 다음과 같이 파드를 추가한다. diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index e4bf6a1715..a4d64e016e 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -1,4 +1,7 @@ --- + + + title: 리소스 메트릭 파이프라인 content_type: concept --- @@ -62,3 +65,12 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다. [설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다. + +### 요약(Summary) API 소스 +[Kubelet](/docs/reference/command-line-tools-reference/kubelet/)은 노드, 볼륨, 파드, 컨테이너 수준의 통계를 수집하며, +소비자(consumer)가 읽을 수 있도록 이를 +[요약 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` 기능 게이트가 추가되면서, 컨테이너 및 파드 수준 통계를 CRI 구현에서 수집할 수 있게 되었다. +참고: 이를 위해서는 CRI 구현에서도 이 기능을 지원해야 한다(containerd >= 1.6.0, CRI-O >= 1.23.0). diff --git a/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md b/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md new file mode 100644 index 0000000000..91501a05bc --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/troubleshooting.md @@ -0,0 +1,107 @@ +--- + + + +content_type: concept +title: 트러블슈팅하기 +--- + + + +때때로 문제가 발생할 수 있다. 이 가이드는 이러한 상황을 해결하기 위해 작성되었다. 문제 해결에는 +다음 두 가지를 참고해 볼 수 있다. + +* [애플리케이션 트러블슈팅하기](/docs/tasks/debug-application-cluster/debug-application/) - 쿠버네티스에 + 코드를 배포하였지만 제대로 동작하지 않는 사용자들에게 유용한 가이드이다. +* [클러스터 트러블슈팅하기](/ko/docs/tasks/debug-application-cluster/debug-cluster/) - 쿠버네티스 클러스터에 + 문제를 겪고 있는 클러스터 관리자 혹은 기분이 나쁜 사람들에게 유용한 가이드이다. + +여러분이 현재 사용중인 릴리스에 대한 알려진 이슈들을 다음의 [릴리스](https://github.com/kubernetes/kubernetes/releases) +페이지에서 확인해 볼 수도 있다. + + + +## 도움 받기 + +여러분의 문제가 위에 소개된 어떠한 가이드로도 해결할 수 없다면, +쿠버네티스 커뮤니티로부터 도움을 받을 수 있는 다양한 방법들을 시도해 볼 수 있다. + +### 질문 + +이 사이트의 문서들은 다양한 질문들에 대한 답변을 제공할 수 있도록 구성되어 있다. +[개념](/ko/docs/concepts/)은 쿠버네티스의 아키텍처와 각 컴포넌트들이 어떻게 동작하는지에 대해 설명하고, +[시작하기](/ko/docs/setup/)는 쿠버네티스를 시작하는 데 유용한 지침들을 제공한다. +[태스크](/ko/docs/tasks/)는 흔히 사용되는 작업들을 수행하는 방법에 대해 소개하고, +[튜토리얼](/ko/docs/tutorials/)은 실무, 산업 특화 혹은 종단간 개발에 특화된 시나리오를 통해 차근차근 설명한다. +[레퍼런스](/ko/docs/reference/) 섹션에서는 +[쿠버네티스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)와 +[`kubectl`](/ko/docs/reference/kubectl/overview/)과 같은 커맨드 라인 인터페이스(CLI)에 대한 +상세한 설명을 다룬다. + +## 도와주세요! 내 질문이 다뤄지지 않았어요! 도움이 필요해요! + +### 스택 오버플로우 + +여러분들이 겪고 있는 문제와 동일한 문제에 대한 도움을 위해 커뮤니티의 다른 사람들이 이미 +질문을 올렸을 수 있다. 쿠버네티스 팀은 +[쿠버네티스 태그가 등록된 글](https://stackoverflow.com/questions/tagged/kubernetes)들을 모니터링하고 있다. +발생한 문제와 도움이 되는 질문이 없다면, +[새로운 질문](https://stackoverflow.com/questions/ask?tags=kubernetes)을 올려라! + +### 슬랙 + +쿠버네티스 슬랙의 `#kubernetes-users` 채널을 통해 쿠버네티스 커뮤니티의 여러 사람들을 접할 수도 있다. +쿠버네티스 슬랙을 사용하기 위해서는 등록이 필요한데, 다음을 통해 [채널 초대 요청](https://slack.kubernetes.io)을 할 수 있다. +(누구나 가입할 수 있다). 슬랙 채널은 여러분이 어떠한 질문을 할 수 있도록 언제나 열려있다. +가입하고 나면 여러분의 웹 브라우저나 슬랙 앱을 통해 [쿠버네티스 슬랙](https://kubernetes.slack.com) +에 참여할 수 있다. + +쿠버네티스 슬랙에 참여하게 된다면, 다양한 주제의 흥미와 관련된 여러 채널들에 대해 +살펴본다. 가령, 쿠버네티스를 처음 접하는 사람이라면 +[`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice) 채널에 가입할 수 있다. 혹은, 만약 당신이 개발자라면 +[`#kubernetes-dev`](https://kubernetes.slack.com/messages/kubernetes-dev) 채널에 가입할 수 있다. + +또한 각 국가 및 사용 언어별 채널들이 여럿 존재한다. 사용하는 언어로 도움을 받거나 정보를 +얻기 위해서는 다음의 채널에 참가한다. + +{{< table caption="국가 / 언어별 슬랙 채널" >}} +국가 | 채널 +:---------|:------------ +China(중국) | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events) +Finland(핀란드) | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users) +France(프랑스) | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events) +Germany(독일) | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events) +India(인도) | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events) +Italy(이탈리아) | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events) +Japan(일본) | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events) +Korea(한국) | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users) +Netherlands(네덜란드) | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users) +Norway(노르웨이) | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users) +Poland(폴란드) | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users) +Russia(러시아) | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users) +Spain(스페인) | [`#es-users`](https://kubernetes.slack.com/messages/es-users) +Sweden(스웨덴) | [`#se-users`](https://kubernetes.slack.com/messages/se-users) +Turkey(터키) | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events) +{{< /table >}} + +### 포럼 + +공식 쿠버네티스 포럼에 참여하는 것도 추천되는 방법이다. [discuss.kubernetes.io](https://discuss.kubernetes.io). + +### 버그와 기능 추가 요청 + +만약 여러분이 버그처럼 보이는 것을 발견했거나, 기능 추가 요청을 하기 위해서는 +[GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 사용한다. + +이슈를 작성하기 전에는, 여러분의 이슈가 기존 이슈에서 이미 +다뤄졌는지 검색해 본다. + +버그를 보고하는 경우에는, 해당 문제를 어떻게 재현할 수 있는지에 관련된 상세한 정보를 포함한다. +포함되어야 하는 정보들은 다음과 같다. + +* 쿠버네티스 버전: `kubectl version` +* 클라우드 프로바이더, OS 배포판, 네트워크 구성, 및 도커 버전 +* 문제를 재현하기 위한 절차 + + + diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md index fdf671a52a..5bc131af19 100644 --- a/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md +++ b/content/ko/docs/tasks/extend-kubernetes/setup-konnectivity.md @@ -11,7 +11,11 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} +쿠버네티스 클러스터가 있어야 하며, kubectl 명령줄 도구가 +클러스터와 통신하도록 설정되어 있어야 한다. 컨트롤 플레인 호스트가 아닌 +두 개 이상의 노드로 구성된 클러스터에서 이 튜토리얼을 수행하는 것을 권장한다. +클러스터가 없다면, [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)를 +이용하여 생성할 수 있다. @@ -24,16 +28,9 @@ Konnectivity 서비스는 컨트롤 플레인에 클러스터 통신을 위한 T Konnectivity 서비스를 사용하고 네트워크 트래픽을 클러스터 노드로 보내도록 API 서버를 구성해야 한다. -1. `ServiceAccountTokenVolumeProjection` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 -활성화되어 있는지 -확인한다. kube-apiserver에 다음과 같은 플래그를 제공하여 -[서비스 어카운트 토큰 볼륨 보호](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)를 -활성화할 수 있다. - ``` - --service-account-issuer=api - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key - --api-audiences=system:konnectivity-server - ``` +1. [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) +기능이 활성화되어 있는지 확인한다. +쿠버네티스 v1.20부터는 기본적으로 활성화되어 있다. 1. `admin/konnectivity/egress-selector-configuration.yaml`과 같은 송신 구성 파일을 생성한다. 1. API 서버의 `--egress-selector-config-file` 플래그를 API 서버 송신 구성 파일의 경로로 설정한다. diff --git a/content/ko/docs/tasks/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md index fbf105024d..5870b4b314 100644 --- a/content/ko/docs/tasks/job/parallel-processing-expansion.md +++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md @@ -178,13 +178,13 @@ kubectl delete job -l jobgroup=jobexample ```liquid -{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, +{% set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, { "name": "banana", "url": "http://dbpedia.org/resource/Banana", }, { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }] %} -{%- for p in params %} -{%- set name = p["name"] %} -{%- set url = p["url"] %} +{% for p in params %} +{% set name = p["name"] %} +{% set url = p["url"] %} --- apiVersion: batch/v1 kind: Job @@ -204,7 +204,7 @@ spec: image: busybox command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] restartPolicy: Never -{%- endfor %} +{% endfor %} ``` 위의 템플릿은 파이썬 딕셔너리(dicts)로 구성된 항목(1-4행)을 사용하여 각 잡 오브젝트에 대해 diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 97753165f1..6c14644db1 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -3,7 +3,7 @@ -min-kubernetes-server-version: v1.20 +min-kubernetes-server-version: v1.23 title: IPv4/IPv6 이중 스택 검증 content_type: task --- @@ -21,6 +21,9 @@ content_type: task {{< version-check >}} +{{< note >}} +v1.23 이전 버전에서도 검증을 수행할 수 있지만 GA 기능으로만 제공되며, v1.23부터 공식적으로 지원된다. +{{< /note >}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index a910dc5c48..d1e864476a 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -4,42 +4,59 @@ -title: Horizontal Pod Autoscaler 연습 +title: HorizontalPodAutoscaler 연습 content_type: task weight: 100 +min-kubernetes-server-version: 1.23 --- -Horizontal Pod Autoscaler는 -CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 -레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. +[HorizontalPodAutoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)(약어: HPA)는 +워크로드 리소스(예: {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는 +{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 +자동으로 업데이트하며, +워크로드의 크기를 수요에 맞게 +자동으로 스케일링하는 것을 목표로 한다. -이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. -Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 -[Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. +수평 스케일링은 부하 증가에 대해 +{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다. +이는 _수직_ 스케일링(쿠버네티스에서는, +해당 워크로드를 위해 이미 실행 중인 파드에 +더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다. + +부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, +HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, +또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다. + +이 문서는 예제 웹 앱의 크기를 자동으로 조절하도록 +HorizontalPodAutoscaler를 설정하는 예시를 다룬다. +이 예시 워크로드는 PHP 코드를 실행하는 아파치 httpd이다. ## {{% heading "prerequisites" %}} -이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다. -[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 -[메트릭 API](https://github.com/kubernetes/metrics)를 통해 메트릭을 제공해야 한다. -Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 방법에 대해 배우려면, -[메트릭-서버 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다. +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} 이전 버전의 +쿠버네티스를 사용하고 있다면, 해당 버전의 문서를 +참고한다([사용 가능한 문서의 버전](/ko/docs/home/supported-doc-versions/) 참고). -Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, -버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 -사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. -마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우, -버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 -메트릭 API와 통신이 가능해야 한다. -자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#사용자-정의-메트릭을-위한-지원)를 참고하길 바란다. +이 예제를 실행하기 위해, 클러스터에 [Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme)가 +배포 및 구성되어 있어야 한다. 쿠버네티스 Metrics Server는 클러스터의 +{{}}으로부터 +리소스 메트릭을 수집하고, 수집한 메트릭을 +[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 통해 노출시키며, +메트릭 수치를 나타내는 새로운 종류의 리소스를 추가하기 위해 +[APIService](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용할 수 있다. + +Metrics Server를 실행하는 방법을 보려면 +[metrics-server 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다. ## php-apache 서버 구동 및 노출 -Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다. +HorizontalPodAutoscaler 예시에서, +먼저 도커 허브의 `php-apache` 이미지를 베이스로 하는 커스텀 컨테이너 이미지를 만들어 시작점으로 삼을 것이다. +`Dockerfile`은 미리 준비되어 있으며, 내용은 다음과 같다. ```dockerfile FROM php:5-apache @@ -47,7 +64,8 @@ COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` -index.php는 CPU 과부하 연산을 수행한다. +아래의 코드는 CPU 과부하 연산을 수행하는 간단한 `index.php` 페이지를 정의하며, +이를 이용해 클러스터에 부하를 시뮬레이트한다. ```php ``` -첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를 -시작하고 서비스로 노출시킨다. +컨테이너 이미지를 만들었다면, +방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를 +{{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다. {{< codenew file="application/php-apache.yaml" >}} -다음의 명령어를 실행한다. +이를 위해, 다음의 명령어를 실행한다. ```shell kubectl apply -f https://k8s.io/examples/application/php-apache.yaml @@ -75,16 +94,27 @@ deployment.apps/php-apache created service/php-apache created ``` -## Horizontal Pod Autoscaler 생성 +## HorizontalPodAutoscaler 생성 {#create-horizontal-pod-autoscaler} -이제 서비스가 동작중이므로, -[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를 사용하여 오토스케일러를 생성한다. -다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 -1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다. -간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. -kubectl run으로 각 파드는 200 밀리코어를 요청하므로, -여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다. -이에 대한 자세한 알고리즘은 [여기](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고하기 바란다. +이제 서비스가 동작중이므로, +`kubectl`을 사용하여 오토스케일러를 생성한다. 이를 위해 +[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 서브커맨드를 사용할 수 있다. + +아래에서는 첫 번째 단계에서 만든 php-apache +디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 +Horizontal Pod Autoscaler를 생성하는 명령어를 실행할 것이다. + +간단히 이야기하면, HPA {{}}는 +평균 CPU 사용량을 50%로 유지하기 위해 (디플로이먼트를 업데이트하여) 레플리카의 개수를 늘리고 줄인다. +그러면 디플로이먼트는 레플리카셋을 업데이트하며(이는 모든 쿠버네티스 디플로이먼트의 동작 방식 중 일부이다), +레플리카셋은 자신의 `.spec` 필드의 변경 사항에 따라 파드를 추가하거나 제거한다. + +`kubectl run`으로 각 파드는 200 밀리코어를 요청하므로, 평균 CPU 사용은 100 밀리코어이다. +알고리즘에 대한 세부 사항은 +[알고리즘 세부 정보](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고한다. + + +HorizontalPodAutoscaler를 생성한다. ```shell kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 @@ -94,47 +124,64 @@ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 horizontalpodautoscaler.autoscaling/php-apache autoscaled ``` -실행 중인 오토스케일러의 현재 상태를 확인해본다. +다음을 실행하여, 새로 만들어진 HorizontalPodAutoscaler의 현재 상태를 확인할 수 있다. ```shell +# "hpa" 또는 "horizontalpodautoscaler" 둘 다 사용 가능하다. kubectl get hpa ``` +출력은 다음과 같다. ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s ``` -아직 서버로 어떠한 요청도 하지 않았기 때문에, 현재 CPU 소비는 0%임을 확인할 수 있다. -(``TARGET``은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다) +(HorizontalPodAutoscalers 이름이 다르다면, 이미 기존에 존재하고 있었다는 뜻이며, +보통은 문제가 되지 않는다.) -## 부하 증가 +아직 서버로 요청을 보내는 클라이언트가 없기 때문에, 현재 CPU 사용량이 0%임을 확인할 수 있다. +(``TARGET`` 열은 디플로이먼트에 의해 제어되는 파드들의 평균을 나타낸다) -이번에는 부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지를 살펴볼 것이다. 먼저 컨테이너를 하나 실행하고, php-apache 서비스에 무한루프의 쿼리를 전송한다(다른 터미널을 열어 수행하기 바란다). +## 부하 증가시키기 {#increase-load} +다음으로, 부하가 증가함에 따라 오토스케일러가 어떻게 반응하는지를 살펴볼 것이다. +이를 위해, 클라이언트 역할을 하는 다른 파드를 실행할 것이다. +클라이언트 파드 안의 컨테이너가 php-apache 서비스에 쿼리를 보내는 무한 루프를 실행한다. ```shell +# 부하 생성을 유지하면서 나머지 스텝을 수행할 수 있도록, +# 다음의 명령을 별도의 터미널에서 실행한다. kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done" ``` -실행 후, 약 1분 정도 후에 CPU 부하가 올라가는 것을 볼 수 있다. - +이제 아래 명령을 실행한다. ```shell +# 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다. kubectl get hpa ``` +1분 쯤 지나면, 다음과 같이 CPU 부하가 올라간 것을 볼 수 있다. + ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 305% / 50% 1 10 1 3m ``` -CPU 소비가 305%까지 증가하였다. -결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다. +그리고 다음과 같이 레플리카의 수가 증가한 것도 볼 수 있다. +``` +NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE +php-apache Deployment/php-apache/scale 305% / 50% 1 10 7 3m +``` + +CPU 사용률이 305%까지 증가하였다. +결과적으로, 디플로이먼트의 레플리카 개수가 7개까지 증가하였다. ```shell kubectl get deployment php-apache ``` +HorizontalPodAutoscaler를 조회했을 때와 동일한 레플리카 수를 확인할 수 있다. ``` NAME READY UP-TO-DATE AVAILABLE AGE php-apache 7/7 7 7 19m @@ -146,24 +193,27 @@ php-apache 7/7 7 7 19m 최종 레플리카의 개수는 본 예제와 다를 수 있다. {{< /note >}} -## 부하 중지 +## 부하 발생 중지하기 {#stop-load} 본 예제를 마무리하기 위해 부하를 중단시킨다. -`busybox` 컨테이너를 띄운 터미널에서, +`busybox` 파드를 띄운 터미널에서, ` + C`로 부하 발생을 중단시킨다. 그런 다음 (몇 분 후에) 결과를 확인한다. ```shell -kubectl get hpa +# 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다. +kubectl get hpa php-apache --watch ``` +출력은 다음과 같다. ``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m ``` +디플로이먼트도 스케일 다운 했음을 볼 수 있다. ```shell kubectl get deployment php-apache ``` @@ -173,7 +223,7 @@ NAME READY UP-TO-DATE AVAILABLE AGE php-apache 1/1 1 1 27m ``` -CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮췄다. +CPU 사용량이 0으로 떨어져서, HPA가 자동으로 레플리카의 개수를 1로 줄였다. {{< note >}} 레플리카 오토스케일링은 몇 분 정도 소요된다. @@ -184,9 +234,9 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮 ## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링 `php-apache` 디플로이먼트를 오토스케일링할 때, -`autoscaling/v2beta2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다. +`autoscaling/v2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다. -첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. +첫 번째로, `autoscaling/v2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. ```shell kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml @@ -195,7 +245,7 @@ kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml 에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다. ```yaml -apiVersion: autoscaling/v2beta2 +apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache @@ -287,7 +337,7 @@ HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수 `kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다. ```yaml -apiVersion: autoscaling/v2beta2 +apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache @@ -411,7 +461,7 @@ object: ## 부록: Horizontal Pod Autoscaler 상태 조건 -HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면, +HorizontalPodAutoscaler의 `autoscaling/v2` 형식을 사용하면, HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 확인할 수 있다. 이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지, 어떤 방식으로든 제한되어 있는지 여부를 나타낸다. @@ -449,12 +499,12 @@ Events: 백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다. 두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지), 원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우, -일반적으로 메트릭을 가져오는데 문제가 있다. +일반적으로 메트릭을 가져오는 데 문제가 있다. 마지막으로, 마지막 조건인 `ScalingLimited`는 원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다. 이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다. -## 부록: 수량 +## 수량 HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 쿠버네티스에서 사용하는 @@ -464,16 +514,16 @@ HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 일반적으로 수량을 밀리단위로 반환한다. 10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다. -## 부록: 다른 가능한 시나리오 +## 다른 가능한 시나리오 ### 명시적으로 오토스케일러 만들기 HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고, -명시적으로 다음 파일을 사용하여 만들 수 있다. +명시적으로 다음 매니페스트를 사용하여 만들 수 있다. {{< codenew file="application/hpa/php-apache.yaml" >}} -다음 명령어를 실행하여 오토스케일러를 생성할 것이다. +다음으로, 아래의 명령어를 실행하여 오토스케일러를 생성한다. ```shell kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 96f86ac046..3e0856e511 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -3,41 +3,59 @@ -title: Horizontal Pod Autoscaler +title: Horizontal Pod Autoscaling feature: title: Horizontal 스케일링 description: > 간단한 명령어나 UI를 통해서 또는 CPU 사용량에 따라 자동으로 애플리케이션의 스케일을 업 또는 다운한다. - content_type: concept weight: 90 --- -Horizontal Pod Autoscaler는 CPU 사용량 -(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), -아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 -컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal -Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다. +쿠버네티스에서, _HorizontalPodAutoscaler_ 는 워크로드 리소스(예: +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는 +{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 자동으로 업데이트하며, +워크로드의 크기를 수요에 맞게 자동으로 스케일링하는 것을 목표로 한다. -Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다. -리소스는 컨트롤러의 동작을 결정한다. -컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다. +수평 스케일링은 부하 증가에 대해 +{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다. +이는 _수직_ 스케일링(쿠버네티스에서는, +해당 워크로드를 위해 이미 실행 중인 파드에 +더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다. +부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, +HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, +또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다. +Horizontal Pod Autoscaling은 크기 조절이 불가능한 오브젝트(예: +{{< glossary_tooltip text="데몬셋" term_id="daemonset" >}})에는 적용할 수 없다. + +HorizontalPodAutoscaler는 쿠버네티스 API 자원 및 +{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 형태로 구현되어 있다. +HorizontalPodAutoscaler API 자원은 컨트롤러의 행동을 결정한다. +쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} +내에서 실행되는 HPA 컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률, +또는 다른 커스텀 메트릭 등의 관측된 메트릭을 목표에 맞추기 위해 +목표물(예: 디플로이먼트)의 적정 크기를 주기적으로 조정한다. + +Horizontal Pod Autoscaling을 활용하는 +[연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)가 존재한다. -## Horizontal Pod Autoscaler는 어떻게 작동하는가? +## HorizontalPodAutoscaler는 어떻게 작동하는가? -![Horizontal Pod Autoscaler 다이어그램](/images/docs/horizontal-pod-autoscaler.svg) +{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다" class="diagram-medium">}} -Horizontal Pod Autoscaler는 컨트롤러 -관리자의 `--horizontal-pod-autoscaler-sync-period` 플래그(기본값은 -15초)에 의해 제어되는 주기를 가진 컨트롤 루프로 구현된다. +쿠버네티스는 Horizontal Pod Autoscaling을 +간헐적으로(intermittently) 실행되는 +컨트롤 루프 형태로 구현했다(지숙적인 프로세스가 아니다). +실행 주기는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의 +`--horizontal-pod-autoscaler-sync-period` 파라미터에 의해 설정된다(기본 주기는 15초이다). -각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에 +각 주기마다, 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에 지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스 메트릭 API(파드 단위 리소스 메트릭 용) 또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다. @@ -45,7 +63,8 @@ Horizontal Pod Autoscaler는 컨트롤러 * 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가 대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다. 그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의 - 컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을 + 컨테이너에 대한 동등한 [자원 요청](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을 + 퍼센트 단위로 하여 사용률 값을 계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다. 그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된 대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데 @@ -54,32 +73,36 @@ Horizontal Pod Autoscaler는 컨트롤러 파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우, 파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는 해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링 - 알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보) - 섹션을 참조하기 바란다. + 알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보) 섹션을 참조하기 바란다. * 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을 제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다. * 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는 단일 메트릭을 가져온다. 이 메트릭은 목표 값과 - 비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API + 비교되어 위와 같은 비율을 생성한다. `autoscaling/v2` API 버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로 선택적으로 나눌 수 있다. -HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`, -`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로 -시작해야 하는 메트릭-서버에 의해 제공된다. 더 자세한 정보는 [메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참조한다. +HorizontalPodAutoscaler를 사용하는 일반적인 방법은 +{{< glossary_tooltip text="집약된 API" term_id="aggregation-layer" >}}(`metrics.k8s.io`, +`custom.metrics.k8s.io`, 또는 `external.metrics.k8s.io`)로부터 메트릭을 가져오도록 설정하는 것이다. +`metrics.k8s.io` API는 보통 메트릭 서버(Metrics Server)라는 애드온에 의해 제공되며, +Metrics Server는 별도로 실행해야 한다. 자원 메트릭에 대한 추가 정보는 +[Metrics Server](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참고한다. -자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다. +[메트릭 API를 위한 지원](#메트릭-api를-위한-지원)에서 위의 API들에 대한 안정성 보장 및 지원 상태를 +확인할 수 있다. -오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다. -스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다. -하위 리소스 스케일에 대한 자세한 내용은 -[여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource)에서 확인할 수 있다. +HorizontalPodAutoscaler 컨트롤러는 스케일링을 지원하는 상응하는 +워크로드 리소스(예: 디플로이먼트 및 스테이트풀셋)에 접근한다. +이들 리소스 각각은 `scale`이라는 하위 리소스를 갖고 있으며, +이 하위 리소스는 레플리카의 수를 동적으로 설정하고 각각의 현재 상태를 확인할 수 있도록 하는 인터페이스이다. +쿠버네티스 API의 하위 리소스에 대한 일반적인 정보는 [쿠버네티스 API 개념](/docs/reference/using-api/api-concepts/)에서 확인할 수 있다. ### 알고리즘 세부 정보 -가장 기본적인 관점에서, Horizontal Pod Autoscaler 컨트롤러는 +가장 기본적인 관점에서, HorizontalPodAutoscaler 컨트롤러는 원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로 작동한다. @@ -90,28 +113,30 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`, 예를 들어 현재 메트릭 값이 `200m`이고 원하는 값이 `100m`인 경우 `200.0 / 100.0 == 2.0`이므로 복제본 수가 두 배가 된다. 만약 현재 값이 `50m` 이면, `50.0 / 100.0 == 0.5` 이므로 -복제본 수를 반으로 줄일 것이다. 비율이 1.0(0.1을 기본값으로 사용하는 +복제본 수를 반으로 줄일 것이다. 컨트롤 플레인은 비율이 1.0(기본값이 0.1인 `-horizontal-pod-autoscaler-tolerance` 플래그를 사용하여 전역적으로 구성 가능한 허용 오차 내)에 충분히 가깝다면 스케일링을 건너 뛸 것이다. `targetAverageValue` 또는 `targetAverageUtilization`가 지정되면, `currentMetricValue`는 HorizontalPodAutoscaler의 스케일 목표 안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다. -허용치를 확인하고 최종 값을 결정하기 전에, 파드 -준비 상태와 누락된 메트릭을 고려한다. -삭제 타임 스탬프가 설정된 모든 파드(즉, 종료 -중인 파드) 및 실패한 파드는 모두 폐기된다. +허용치를 확인하고 최종 값을 결정하기 전에, +컨트롤 플레인은 누락된 메트릭이 있는지, +그리고 몇 개의 파드가 [`Ready`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)인지도 고려한다. +삭제 타임스탬프가 설정된 모든 파드(파드에 삭제 타임스탬프가 있으면 +셧다운/삭제 중임을 뜻한다)는 무시되며, 모든 실패한 파드는 +버려진다. 특정 파드에 메트릭이 누락된 경우, 나중을 위해 처리를 미뤄두는데, 이와 같이 누락된 메트릭이 있는 모든 파드는 최종 스케일 량을 조정하는데 사용된다. -CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (즉, 여전히 -초기화 중인 경우) * 또는 * 파드의 최신 메트릭 포인트가 준비되기 +CPU를 스케일할 때, 파드가 아직 Ready되지 않았거나(여전히 +초기화중이거나, unhealthy하여서) *또는* 파드의 최신 메트릭 포인트가 준비되기 전이라면, 마찬가지로 해당 파드는 나중에 처리된다. 기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는 - 특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는 +특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는 시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지 않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로 전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다. @@ -124,20 +149,21 @@ CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 ( `현재 메트릭 값 / 원하는 메트릭 값` 기본 스케일 비율은 나중에 사용하기로 되어 있거나 위에서 폐기되지 않은 남아있는 파드를 사용하여 계산된다. -누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우 +누락된 메트릭이 있는 경우, 컨트롤 플레인은 파드가 스케일 다운의 경우 원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고 가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인 스케일의 크기를 약화시킨다. -또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나 -아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우, -아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고 +또한, 아직-준비되지-않은 파드가 있고, 누락된 메트릭이나 +아직-준비되지-않은 파드가 고려되지 않고 워크로드가 스케일업 된 경우, +컨트롤러는 아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고 보수적으로 가정하고 스케일 확장의 크기를 약화시킨다. -아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용 -비율을 다시 계산한다. 새 비율이 스케일 방향을 -바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새 -비율을 사용하여 스케일한다. +아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에, +컨트롤러가 사용률을 다시 계산한다. +새로 계산한 사용률이 스케일 방향을 바꾸거나, 허용 오차 내에 있으면, +컨트롤러가 스케일링을 건너뛴다. +그렇지 않으면, 새로 계산한 사용률를 이용하여 파드 수 변경 결정을 내린다. 평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는 경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한 @@ -161,32 +187,25 @@ HPA가 여전히 확장할 수 있음을 의미한다. ## API 오브젝트 -Horizontal Pod Autoscaler는 쿠버네티스 `autoscaling` API 그룹의 API 리소스이다. -CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은 -`autoscaling/v1` API 버전에서 찾을 수 있다. - -메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은 -`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된 -새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다. +Horizontal Pod Autoscaler는 +쿠버네티스 `autoscaling` API 그룹의 API 리소스이다. +현재의 안정 버전은 `autoscaling/v2` API 버전이며, +메모리와 커스텀 메트릭에 대한 스케일링을 지원한다. +`autoscaling/v2`에서 추가된 새로운 필드는 `autoscaling/v1`를 이용할 때에는 +어노테이션으로 보존된다. HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다. API 오브젝트에 대한 자세한 내용은 -[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다. +[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling)에서 찾을 수 있다. +## 워크로드 스케일링의 안정성 {#flapping} -## kubectl에서 Horizontal Pod Autoscaler 지원 +HorizontalPodAutoscaler를 사용하여 레플리카 그룹의 크기를 관리할 때, +측정하는 메트릭의 동적 특성 때문에 레플리카 수가 계속 자주 요동칠 수 있다. +이는 종종 *thrashing* 또는 *flapping*이라고 불린다. +이는 사이버네틱스 분야의 *이력 현상(hysteresis)* 개념과 비슷하다. -Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다. -`kubectl create` 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다. -`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다. -마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다. - -또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다. -예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을 -실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`, -그리고 2와 5 사이의 레플리카 개수로 설정된다. -`kubectl autoscale`에 대한 자세한 문서는 [여기](/docs/reference/generated/kubectl/kubectl-commands/#autoscale)에서 찾을 수 있다. ## 롤링 업데이트 중 오토스케일링 @@ -203,31 +222,6 @@ HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한 스테이트풀셋이 직접 파드의 숫자를 관리한다(즉, 레플리카셋과 같은 중간 리소스가 없다). -## 쿨-다운 / 지연에 대한 지원 - -Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때, -평가된 메트릭의 동적인 특징 때문에 레플리카 수가 -자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다. - -v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로 -노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다. - -v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한 -필요성을 제거하였다. - -- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이 - 안정화되기까지의 시간 간격을 지정한다. - Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고, - 이 시간 간격에서의 가장 큰 크기에서만 작동한다. 기본값은 5분(`5m0s`)이다. - -{{< note >}} -이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야 -한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가 -워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을 -너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수 -있다. -{{< /note >}} - ## 리소스 메트릭 지원 모든 HPA 대상은 스케일링 대상에서 파드의 리소스 사용량을 기준으로 스케일링할 수 있다. @@ -260,7 +254,7 @@ resource: {{< feature-state for_k8s_version="v1.20" state="alpha" >}} -`HorizontalPodAutoscaler` 는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의 +HorizontalPodAutoscaler API는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의 리소스 사용량을 추적할 수 있는 컨테이너 메트릭 소스도 지원한다. 이를 통해 특정 파드에서 가장 중요한 컨테이너의 스케일링 임계값을 구성할 수 있다. 예를 들어 웹 애플리케이션 프로그램과 로깅 사이드카가 있는 경우 사이드카 컨테이너와 해당 리소스 사용을 무시하고 @@ -272,6 +266,7 @@ resource: 해당 파드는 무시되고 권장 사항이 다시 계산된다. 계산에 대한 자세한 내용은 [알고리즘](#알고리즘-세부-정보)을 을 참조한다. 컨테이너 리소스를 오토스케일링에 사용하려면 다음과 같이 메트릭 소스를 정의한다. + ```yaml type: ContainerResource containerResource: @@ -297,27 +292,31 @@ HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는 이전 컨테이너 이름을 제거하여 정리한다. {{< /note >}} -## 멀티 메트릭을 위한 지원 -Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API -버전을 사용하여 Horizontal Pod Autoscaler가 스케일을 조정할 멀티 메트릭을 지정할 수 있다. 그런 다음 Horizontal Pod -Autoscaler 컨트롤러가 각 메트릭을 평가하고, 해당 메트릭을 기반으로 새 스케일을 제안한다. -제안된 스케일 중 가장 큰 것이 새로운 스케일로 사용된다. +## 사용자 정의 메트릭을 이용하는 스케일링 -## 사용자 정의 메트릭을 위한 지원 +{{< feature-state for_k8s_version="v1.23" state="stable" >}} -{{< note >}} -쿠버네티스 1.2는 특수 어노테이션을 사용하여 애플리케이션 관련 메트릭을 기반으로 하는 스케일의 알파 지원을 추가했다. -쿠버네티스 1.6에서는 이러한 어노테이션 지원이 제거되고 새로운 오토스케일링 API가 추가되었다. 이전 사용자 정의 -메트릭 수집 방법을 계속 사용할 수는 있지만, Horizontal Pod Autoscaler에서는 이 메트릭을 사용할 수 없다. 그리고 -Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용자 정의 메트릭을 지정하는 이전 어노테이션을 사용할 수 없다. -{{< /note >}} +(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.) -쿠버네티스 1.6에서는 Horizontal Pod Autoscaler에서 사용자 정의 메트릭을 사용할 수 있도록 지원한다. -`autoscaling/v2beta2` API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다. -그리고 쿠버네티스는 새 사용자 정의 메트릭 API에 질의하여 적절한 사용자 정의 메트릭의 값을 가져온다. +`autoscaling/v2beta2` API 버전을 사용하는 경우, +(쿠버네티스 또는 어느 쿠버네티스 구성 요소에도 포함되어 있지 않은) +커스텀 메트릭을 기반으로 스케일링을 수행하도록 HorizontalPodAutoscaler를 구성할 수 있다. +이 경우 HorizontalPodAutoscaler 컨트롤러가 이러한 커스텀 메트릭을 쿠버네티스 API로부터 조회한다. -요구 사항은 [메트릭을 위한 지원](#메트릭-API를-위한-지원)을 참조한다. +요구 사항에 대한 정보는 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다. + +## 복수의 메트릭을 이용하는 스케일링 + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.) + +`autoscaling/v2beta2` API 버전을 사용하는 경우, +HorizontalPodAutoscaler가 스케일링에 사용할 복수의 메트릭을 설정할 수 있다. +이 경우 HorizontalPodAutoscaler 컨트롤러가 각 메트릭을 확인하고 해당 단일 메트릭에 대한 새로운 스케일링 크기를 제안한다. +HorizontalPodAutoscaler는 새롭게 제안된 스케일링 크기 중 가장 큰 값을 선택하여 워크로드 사이즈를 +조정한다(이 값이 이전에 설정한 '총 최대값(overall maximum)'보다는 크지 않을 때에만). ## 메트릭 API를 위한 지원 @@ -332,8 +331,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. 클러스터 애드온으로 시작할 수 있다. * 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다. - 메트릭 파이프라인 또는 [알려진 솔루션 목록](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)으로 확인한다. - 직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다. + 사용 가능한 쿠버네티스 메트릭 어댑터가 있는지 확인하려면 사용하고자 하는 메트릭 파이프라인을 확인한다. * 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다. @@ -345,16 +343,21 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. 어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#다양한-메트릭-및-사용자-정의-메트릭을-기초로한-오토스케일링)과 [외부 메트릭스 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#쿠버네티스-오브젝트와-관련이-없는-메트릭을-기초로한-오토스케일링)을 참조한다. -## 구성가능한 스케일링 동작 지원 +## 구성가능한 스케일링 동작 -[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md) -부터 `v2beta2` API는 HPA `behavior` 필드를 통해 -스케일링 동작을 구성할 수 있다. -동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown` -섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는 -스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는 -양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면 -스케일링 중 레플리카 변경 속도를 제어할 수 있다. +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.) + +`v2` 버전의 HorizontalPodAutoscaler API를 사용한다면, +`behavior` 필드([API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec) 참고)를 +사용하여 스케일업 동작과 스케일다운 동작을 별도로 구성할 수 있다. +각 방향에 대한 동작은 `behavior` 필드 아래의 +`scaleUp` / `scaleDown`를 설정하여 지정할 수 있다. + +_안정화 윈도우_ 를 명시하여 스케일링 목적물의 +레플리카 수 [흔들림](#flapping)을 방지할 수 있다. 스케일링 정책을 이용하여 스케일링 시 +레플리카 수 변화 속도를 조절할 수도 있다. ### 스케일링 정책 @@ -391,23 +394,29 @@ behavior: 확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다. 레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다. 값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히 -비활성화 된다. +비활성화된다. ### 안정화 윈도우 -안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을 -다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터 -계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다. -다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어 있다. +안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 +레플리카 수의 [흔들림](#flapping)을 제한하기 위해 사용된다. +오토스케일링 알고리즘은 이전의 목표 상태를 추론하고 +워크로드 수의 원치 않는 변화를 방지하기 위해 이 안정화 윈도우를 활용한다. + +예를 들어, 다음 예제 스니펫에서, `scaleDown`에 대해 안정화 윈도우가 설정되었다. ```yaml -scaleDown: - stabilizationWindowSeconds: 300 +behavior: + scaleDown: + stabilizationWindowSeconds: 300 ``` -메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은 -이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다. -위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다. +메트릭 관측 결과 스케일링 목적물이 스케일 다운 되어야 하는 경우, +알고리즘은 이전에 계산된 목표 상태를 확인하고, 해당 구간에서 계산된 값 중 가장 높은 값을 사용한다. +위의 예시에서, 이전 5분 동안의 모든 목표 상태가 고려 대상이 된다. + +이를 통해 동적 최대값(rolling maximum)을 근사화하여, +스케일링 알고리즘이 빠른 시간 간격으로 파드를 제거하고 바로 다시 동일한 파드를 재생성하는 현상을 방지할 수 있다. ### 기본 동작 @@ -453,7 +462,7 @@ behavior: stabilizationWindowSeconds: 60 ``` -### 예시: 스케일 다운 비율 제한 +### 예시: 스케일 다운 속도 제한 HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해 다음 동작이 HPA에 추가된다. @@ -467,9 +476,7 @@ behavior: periodSeconds: 60 ``` -마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택 -전략을 추가할 수 있다. -분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소 +분당 제거되는 파드 수가 5를 넘지 않도록 하기 위해, 크기가 5로 고정된 두 번째 축소 정책을 추가하고, `selectPolicy` 를 최소로 설정하면 된다. `selectPolicy` 를 `Min` 으로 설정하면 자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다. @@ -497,6 +504,18 @@ behavior: selectPolicy: Disabled ``` +## kubectl의 HorizontalPodAutoscaler 지원 + +Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다. +`kubectl create` 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다. +`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다. +마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다. + +또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다. +예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을 +실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`, +그리고 2와 5 사이의 레플리카 개수로 설정된다. + ## 암시적 유지 관리 모드 비활성화 HPA 구성 자체를 변경할 필요없이 대상에 대한 @@ -506,9 +525,54 @@ HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한 다시 활성화할 때까지 HPA는 대상 조정을 중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정). +### 디플로이먼트와 스테이트풀셋을 horizontal autoscaling으로 전환하기 + +HPA가 활성화되어 있으면, 디플로이먼트, 스테이트풀셋 모두 또는 둘 중 하나의 +{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}에서 +`spec.replicas`의 값을 삭제하는 것이 바람직하다. +이렇게 적용하지 않으면, (예를 들어 `kubectl apply -f deployment.yaml` 명령으로) +오브젝트에 변경이 생길 때마다 쿠버네티스가 파드의 수를 +`spec.replicas`에 기재된 값으로 조정할 것이다. +이는 바람직하지 않으며 HPA가 활성화된 경우에 문제가 될 수 있다. + +`spec.replicas` 값을 제거하면 1회성으로 파드 숫자가 줄어들 수 있는데, +이는 이 키의 기본값이 1이기 때문이다(레퍼런스: +[디플로이먼트 레플리카](/ko/docs/concepts/workloads/controllers/deployment#레플리카)). +값을 업데이트하면, 파드 1개를 제외하고 나머지 파드가 종료 절차에 들어간다. +이후의 디플로이먼트 애플리케이션은 정상적으로 작동하며 롤링 업데이트 구성도 의도한 대로 동작한다. +이러한 1회성 저하를 방지하는 방법이 존재하며, +디플로이먼트 수정 방법에 따라 다음 중 한 가지 방법을 선택한다. + +{{< tabs name="fix_replicas_instructions" >}} +{{% tab name="클라이언트 쪽에 적용하기 (기본값))" %}} + +1. `kubectl apply edit-last-applied deployment/<디플로이먼트_이름>` +2. 에디터에서 `spec.replicas`를 삭제한다. 저장하고 에디터를 종료하면, `kubectl`이 + 업데이트 사항을 적용한다. 이 단계에서 파드 숫자가 변경되지는 않는다. +3. 이제 매니페스트에서 `spec.replicas`를 삭제할 수 있다. + 소스 코드 관리 도구를 사용하고 있다면, 변경 사항을 추적할 수 있도록 + 변경 사항을 커밋하고 추가 필요 단계를 수행한다. +4. 이제 `kubectl apply -f deployment.yaml`를 실행할 수 있다. + +{{% /tab %}} +{{% tab name="서버 쪽에 적용하기" %}} + +[서버 쪽에 적용하기](/docs/reference/using-api/server-side-apply/)를 수행하려면, +정확히 이러한 사용 사례를 다루고 있는 [소유권 이전하기](/docs/reference/using-api/server-side-apply/#transferring-ownership) +가이드라인을 참조한다. + +{{% /tab %}} +{{< /tabs >}} + ## {{% heading "whatsnext" %}} +클러스터에 오토스케일링을 구성한다면, [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)와 같은 +클러스터 수준의 오토스케일러 사용을 고려해 볼 수 있다. -* 디자인 문서: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md). -* kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). -* [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제. +HorizontalPodAutoscaler에 대한 더 많은 정보는 아래를 참고한다. + +* horizontal pod autoscaling에 대한 [연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 확인한다. +* [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 문서를 확인한다. +* 커스텀 메트릭 어댑터를 직접 작성하고 싶다면, + [샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다. +* HorizontalPodAutoscaler [API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)를 확인한다. diff --git a/content/ko/docs/tasks/run-application/scale-stateful-set.md b/content/ko/docs/tasks/run-application/scale-stateful-set.md new file mode 100644 index 0000000000..52fe7ac593 --- /dev/null +++ b/content/ko/docs/tasks/run-application/scale-stateful-set.md @@ -0,0 +1,100 @@ +--- + + + + + + + + +title: 스테이트풀셋(StatefulSet) 확장하기 +content_type: task +weight: 50 +--- + + +이 작업은 스테이트풀셋을 확장하는 방법을 보여준다. 스테이트풀셋 확장은 레플리카 수를 늘리거나 줄이는 것을 의미한다. + + +## {{% heading "prerequisites" %}} + + +* 스테이트풀셋은 쿠버네티스 버전 1.5 이상에서만 사용할 수 있다. + 쿠버네티스 버전을 확인하려면 `kubectl version`을 실행한다. + +* 모든 스테이트풀 애플리케이션이 제대로 확장되는 것은 아니다. 스테이트풀셋을 확장할지 여부가 확실하지 않은 경우에 자세한 내용은 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 또는 [스테이트풀셋 튜토리얼](/ko/docs/tutorials/stateful-application/basic-stateful-set/)을 참조한다. + +* 스테이트풀 애플리케이션 클러스터가 완전히 정상이라고 확신할 때만 + 확장을 수행해야 한다. + + + + + +## 스테이트풀셋 확장하기 + +### kubectl을 사용하여 스테이트풀셋 확장 + +먼저 확장하려는 스테이트풀셋을 찾는다. + +```shell +kubectl get statefulsets +``` + +스테이트풀셋의 레플리카 수를 변경한다. + +```shell +kubectl scale statefulsets --replicas= +``` + +### 스테이트풀셋 인플레이스(in-place) 업데이트 + +대안으로 스테이트풀셋에 [인플레이스 업데이트](/ko/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources)를 수행할 수 있다. + +스테이트풀셋이 처음에 `kubectl apply`로 생성된 경우, +스테이트풀셋 매니페스트의 `.spec.replicas`를 업데이트한 다음 `kubectl apply`를 수행한다. + +```shell +kubectl apply -f +``` + +그렇지 않으면 `kubectl edit`로 해당 필드를 편집한다. + +```shell +kubectl edit statefulsets +``` + +또는 `kubectl patch`를 사용한다. + +```shell +kubectl patch statefulsets -p '{"spec":{"replicas":}}' +``` + +## 트러블슈팅 + +### 축소가 제대로 작동하지 않음 + +스테이트풀셋에서 관리하는 스테이트풀 파드가 비정상인 경우에는 스테이트풀셋을 축소할 수 없다. 축소는 +스테이트풀 파드가 실행되고 준비된 후에만 발생한다. + +spec.replicas > 1인 경우 쿠버네티스는 비정상 파드의 원인을 결정할 수 없다. 영구적인 오류 또는 일시적인 오류의 결과일 수 있다. 일시적인 오류는 업그레이드 또는 유지 관리에 필요한 재시작으로 인해 발생할 수 있다. + +영구적인 오류로 인해 파드가 비정상인 경우 +오류를 수정하지 않고 확장하면 스테이트풀셋 멤버십이 올바르게 작동하는 데 필요한 +특정 최소 레플리카 수 아래로 떨어지는 상태로 이어질 수 있다. +이로 인해 스테이트풀셋을 사용할 수 없게 될 수 있다. + +일시적인 오류로 인해 파드가 비정상 상태이고 파드를 다시 사용할 수 있게 되면 +일시적인 오류가 확장 또는 축소 작업을 방해할 수 있다. 일부 분산 +데이터베이스에는 노드가 동시에 가입 및 탈퇴할 때 문제가 있다. 이러한 경우 +애플리케이션 수준에서 확장 작업에 대해 추론하고 스테이트풀 애플리케이션 클러스터가 +완전히 정상이라고 확신할 때만 확장을 수행하는 것이 좋다. + + + +## {{% heading "whatsnext" %}} + + +* [스테이트풀셋 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)에 대해 더 배워보기 + + diff --git a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md index d6f29e780d..3272038ea4 100644 --- a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -1,6 +1,10 @@ --- title: 클러스터에서 TLS 인증서 관리 content_type: task + + + + --- @@ -158,9 +162,19 @@ Events: ## 인증서 서명 요청 승인 받기 -인증서 서명 요청을 승인하는 것은 자동화된 승인 프로세스나 -클러스터 관리자에 의해 일회성으로 수행한다. 여기에 -관련된 내용에 대한 자세한 내용은 아래에서 설명한다. +[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 승인은 +자동화된 승인 프로세스 또는 클러스터 관리자의 일회성 승인으로 수행된다. +인증서 요청 승인 권한을 갖고 있다면, +`kubectl`을 이용하여 다음과 같이 수동으로 승인할 수 있다. + +```shell +kubectl certificate approve my-svc.my-namespace +``` + +```none +certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved +``` + ## 인증서 다운로드 및 사용 diff --git a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-pwsh.md b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-pwsh.md new file mode 100644 index 0000000000..5e6d3d2ecc --- /dev/null +++ b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-pwsh.md @@ -0,0 +1,23 @@ +--- +title: "PowerShell 자동 완성" +description: "PowerShell 자동 완성을 위한 몇 가지 선택적 구성에 대해 설명한다." +headless: true +--- + +PowerShell용 kubectl 자동 완성 스크립트는 `kubectl completion powershell` 명령으로 생성할 수 있다. + +모든 셸 세션에서 사용하려면, `$PROFILE` 파일에 다음을 추가한다. + +```powershell +kubectl completion powershell | Out-String | Invoke-Expression +``` + +이 명령은 PowerShell을 실행할 때마다 자동 완성 스크립트를 재생성한다. 아니면, 생성된 스크립트를 `$PROFILE` 파일에 직접 추가할 수도 있다. + +생성된 스크립트를 `$PROFILE` 파일에 직접 추가하려면, PowerShell 프롬프트에서 다음 명령줄을 실행한다. + +```powershell +kubectl completion powershell >> $PROFILE +``` + +셸을 다시 불러오면, kubectl 자동 완성이 동작할 것이다. diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md index 71858e3e92..08887c1063 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-linux.md +++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md @@ -176,7 +176,7 @@ kubectl version --client ### 셸 자동 완성 활성화 -kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다. +kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다. 다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다. diff --git a/content/ko/docs/tasks/tools/install-kubectl-macos.md b/content/ko/docs/tasks/tools/install-kubectl-macos.md index 0fc350f02f..59e648dc1b 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-macos.md +++ b/content/ko/docs/tasks/tools/install-kubectl-macos.md @@ -159,7 +159,7 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하 ### 셸 자동 완성 활성화 -kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다. +kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다. 다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다. diff --git a/content/ko/docs/tasks/tools/install-kubectl-windows.md b/content/ko/docs/tasks/tools/install-kubectl-windows.md index e1a62c613c..205849e9f2 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-windows.md +++ b/content/ko/docs/tasks/tools/install-kubectl-windows.md @@ -22,7 +22,6 @@ card: - [윈도우에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-windows) - [Chocolatey 또는 Scoop을 사용하여 윈도우에 설치](#install-on-windows-using-chocolatey-or-scoop) - ### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-windows} 1. [최신 릴리스 {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)를 다운로드한다. @@ -134,11 +133,11 @@ card: ### 셸 자동 완성 활성화 -kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다. +kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다. -다음은 Zsh에 대한 자동 완성을 설정하는 절차이다. +다음은 PowerShell에 대한 자동 완성을 설정하는 절차이다. -{{< include "included/optional-kubectl-configs-zsh.md" >}} +{{< include "included/optional-kubectl-configs-pwsh.md" >}} ### `kubectl convert` 플러그인 설치 diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 0de52da42a..fd3c8a7b45 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -52,10 +52,16 @@ content_type: concept * [AppArmor](/ko/docs/tutorials/clusters/apparmor/) * [seccomp](/docs/tutorials/clusters/seccomp/) + ## 서비스 * [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/) +## 보안 + +* [파드 보안 표준을 클러스터 수준으로 적용하기](/docs/tutorials/security/cluster-level-pss/) +* [파드 보안 표준을 네임스페이스 수준으로 적용하기](/docs/tutorials/security/ns-level-pss/) + ## {{% heading "whatsnext" %}} 튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는 diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index a8facdaa67..7dde58e298 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -233,7 +233,7 @@ kubectl get events | grep hello-apparmor proc attr을 확인하여 컨테이너가 실제로 해당 프로파일로 실행 중인지 확인할 수 있다. ```shell -kubectl exec hello-apparmor cat /proc/1/attr/current +kubectl exec hello-apparmor -- cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) @@ -242,7 +242,7 @@ k8s-apparmor-example-deny-write (enforce) 마지막으로 파일 쓰기를 통해 프로파일을 위반하면 어떻게 되는지 확인할 수 있다. ```shell -kubectl exec hello-apparmor touch /tmp/test +kubectl exec hello-apparmor -- touch /tmp/test ``` ``` touch: /tmp/test: Permission denied diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index da8cce3e17..415b79362b 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -72,7 +72,7 @@ weight: 10

컨트롤 플레인은 클러스터 관리를 담당한다. 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.

-

노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다. 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.

+

노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다. 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 하는데, 이는 한 노드가 다운되면 etcd 멤버와 컨트롤 플레인 인스턴스가 사라져 중복성(redundancy)을 잃기 때문이다. 컨트롤 플레인 노드를 추가하여 이러한 위험을 줄일 수 있다.

diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 7300b06615..f18da2888a 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -163,7 +163,7 @@ command=GET ## `Type=NodePort` 인 서비스에서 소스 IP -[`Type=NodePort`](/ko/docs/concepts/services-networking/service/#nodeport)인 +[`Type=NodePort`](/ko/docs/concepts/services-networking/service/#type-nodeport)인 서비스로 보내진 패킷은 소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다. diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index db500f5699..c2e16a86f1 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -127,8 +127,8 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase) 참고) -및 _Ready_ ([파드의 조건](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건-condition)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. +참고로 `web-1` 파드는 `web-0` 파드가 _Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고) +및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. ## 스테이트풀셋 안에 파드 diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 4e82a6d07f..62d43ea4af 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -283,6 +283,6 @@ kubectl apply -f cassandra-statefulset.yaml ## {{% heading "whatsnext" %}} -* 어떻게 [스테이트풀셋 스케일](/docs/tasks/run-application/scale-stateful-set/)하는지 살펴본다. +* 어떻게 [스테이트풀셋 스케일](/ko/docs/tasks/run-application/scale-stateful-set/)하는지 살펴본다. * [*쿠버네티스시드제공자*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)에 대해 더 살펴본다. * 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 248d6d1d4d..392612e059 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -894,8 +894,7 @@ kubernetes-node-2g2d kubectl get nodes ``` -[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여 -클러스터 내에 4개 노드를 제외하고 다른 모든 노드를 통제해보자. +이 튜토리얼에서는 클러스터가 최소 4개의 노드로 구성되었다고 가정한다. 클러스터의 노드가 4개보다 많다면, [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) 명령을 이용하여 4개 노드를 제외하고 다른 모든 노드를 통제(cordon)한다. 이렇게 4개 노드만 사용하도록 제한하여, 다음의 유지보수 시뮬레이션 예시에서 주키퍼 파드를 스케줄링할 때 어피니티와 PodDisruptionBudget 제약이 발생하도록 할 수 있다. ```shell kubectl cordon <노드-이름> diff --git a/content/ko/examples/pods/storage/pv-duplicate.yaml b/content/ko/examples/pods/storage/pv-duplicate.yaml new file mode 100644 index 0000000000..15a48acbed --- /dev/null +++ b/content/ko/examples/pods/storage/pv-duplicate.yaml @@ -0,0 +1,20 @@ + +apiVersion: v1 +kind: Pod +metadata: + name: test +spec: + containers: + - name: test + image: nginx + volumeMounts: + - name: site-data + mountPath: /usr/share/nginx/html + subPath: html + - name: config + mountPath: /etc/nginx/nginx.conf + subPath: nginx.conf + volumes: + - name: config + persistentVolumeClaim: + claimName: test-nfs-claim \ No newline at end of file diff --git a/content/pt-br/_index.html b/content/pt-br/_index.html index 628047e85c..15782b8423 100644 --- a/content/pt-br/_index.html +++ b/content/pt-br/_index.html @@ -42,12 +42,12 @@ O Kubernetes é Open Source, o que te oferece a liberdade de utilizá-lo em seu

- KubeCon em Barcelona on Maio 20-23, 2019 + KubeCon na Europa de 16 a 20 de maio de 2022



- KubeCon em Shanghai em Junho, 24-26 de 2019 + KubeCon na América do Norte de 24 a 28 de outubro de 2022
diff --git a/data/i18n/en/en.toml b/data/i18n/en/en.toml index 53467e42de..ccd6dd35b3 100644 --- a/data/i18n/en/en.toml +++ b/data/i18n/en/en.toml @@ -202,6 +202,12 @@ other = "Objectives" [options_heading] other = "Options" +[outdated_blog__message] +other = "The Kubernetes project considers this article to be outdated because it is more than one year old. Check that the information in the page has not become incorrect since its publication." + +[outdated_blog__title] +other = "Outdated article" + [post_create_issue] other = "Create an issue" diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index 1a6cbe442b..e6649c5b0d 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -18,11 +18,14 @@ schedules: targetDate: 2021-12-16 - release: 1.22 releaseDate: 2021-08-04 - next: 1.22.6 - cherryPickDeadline: 2022-01-14 - targetDate: 2022-01-19 + next: 1.22.7 + cherryPickDeadline: 2022-02-11 + targetDate: 2022-02-16 endOfLifeDate: 2022-10-28 previousPatches: + - release: 1.22.6 + cherryPickDeadline: 2022-01-14 + targetDate: 2022-01-19 - release: 1.22.5 cherryPickDeadline: 2021-12-10 targetDate: 2021-12-15 @@ -40,11 +43,14 @@ schedules: targetDate: 2021-08-19 - release: 1.21 releaseDate: 2021-04-08 - next: 1.21.9 - cherryPickDeadline: 2022-01-14 - targetDate: 2022-01-19 + next: 1.21.10 + cherryPickDeadline: 2022-02-11 + targetDate: 2022-02-16 endOfLifeDate: 2022-06-28 previousPatches: + - release: 1.21.9 + cherryPickDeadline: 2022-01-14 + targetDate: 2022-01-19 - release: 1.21.8 cherryPickDeadline: 2021-12-10 targetDate: 2021-12-15 @@ -72,11 +78,14 @@ schedules: note: Regression https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs - release: 1.20 releaseDate: 2020-12-08 - next: 1.20.15 - cherryPickDeadline: 2022-01-14 - targetDate: 2022-01-19 + next: 1.20.16 + cherryPickDeadline: 2022-02-11 + targetDate: 2022-02-16 endOfLifeDate: 2022-02-28 previousPatches: + - release: 1.20.15 + cherryPickDeadline: 2022-01-14 + targetDate: 2022-01-19 - release: 1.20.14 cherryPickDeadline: 2021-12-10 targetDate: 2021-12-15 diff --git a/layouts/partials/deprecation-warning.html b/layouts/partials/deprecation-warning.html index 14261d73dd..1e72e45cca 100644 --- a/layouts/partials/deprecation-warning.html +++ b/layouts/partials/deprecation-warning.html @@ -9,4 +9,11 @@

+{{ else if and (eq .Section "blog") .Date (.Date.Before (now.AddDate -1 0 0)) -}} +
+
+

{{ T "outdated_blog__title" }}

+

{{ T "outdated_blog__message" }}

+
+
{{ end }} \ No newline at end of file diff --git a/layouts/partials/navbar.html b/layouts/partials/navbar.html index ed269dc6b0..b243965a41 100644 --- a/layouts/partials/navbar.html +++ b/layouts/partials/navbar.html @@ -10,7 +10,7 @@ {{ with site.GetPage "section" . }}
  • {{ $active := eq .Section $.Section }} - {{ .Title }} + {{ .Title }}
    • {{ end }} {{ end }} diff --git a/static/css/newcommunity.css b/static/css/newcommunity.css index 3ac0e73bf6..e62e4ab8c5 100644 --- a/static/css/newcommunity.css +++ b/static/css/newcommunity.css @@ -59,11 +59,6 @@ code { margin-top: 25px; } - -footer { - float: left !important; -} - p { font-weight: 300 !important; } @@ -311,8 +306,7 @@ a { .resources { width: 100%; - margin-top; - 5%; + margin-top: 5%; margin-bottom: 3%; float: left; } @@ -491,13 +485,7 @@ h2:after { font-weight: bold; } - - /* .fullbutton { - - padding: 3% !important; - - - } */ + } @media (max-width:1000px) { @@ -760,8 +748,7 @@ h2:after { .resources { width: 100%; - margin-top; - 8%; + margin-top: 8%; margin-bottom: 8%; float: left; } @@ -774,10 +761,6 @@ h2:after { margin-left: 5%; } - - - - .contributor { float: left; width: 100%; @@ -853,7 +836,4 @@ h2:after { font-size: 0.7em !important; } - - - } \ No newline at end of file diff --git a/static/images/sequence_diagram.svg b/static/images/sequence_diagram.svg new file mode 100644 index 0000000000..dd1739b21e --- /dev/null +++ b/static/images/sequence_diagram.svg @@ -0,0 +1 @@ +Developer (service-owner)K8S api-serverAdmission Controller ServiceRun "kubectl exec ..." commandAdmit "exec" request by calling the validating webhookAllow the exec admission requestExecute the exec commandEvict tagged pods after a predefined intervalloopEvictPod()Execute the eviction commandDeveloper (service-owner)K8S api-serverAdmission Controller Service \ No newline at end of file
    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/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/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/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/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/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/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/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/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/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/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/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/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=
    --add-dir-header

    true로 되어 있으면, 로그 메시지의 헤더에 파일 디렉터리를 기재한다.

    --alsologtostderr

    로그를 파일뿐만 아니라 표준 에러(standard error)로도 출력한다.

    --azure-container-registry-config string

    boot-id를 위해 확인할 파일 목록(쉼표로 분리). 가장 먼저 발견되는 항목을 사용한다.
    --boot_id_file string     기본값: "/proc/sys/kernel/random/boot_id"

    boot-id를 체크할 파일들의 콤마로 구분된 목록. 목록 중에서, 존재하는 첫 번째 파일을 사용한다.

    --cleanup
    --feature-gates mapStringBool

    알파/실험 기능에 대한 기능 게이트를 설명하는 키=값 쌍 집합. 옵션은 다음과 같다.
    APIListChunking=true|false (BETA - 기본값=true)
    APIPriorityAndFairness=true|false (BETA - 기본값=true)
    APIResponseCompression=true|false (BETA - 기본값=true)
    APIServerIdentity=true|false (ALPHA - 기본값=false)
    APIServerTracing=true|false (ALPHA - 기본값=false)
    AllAlpha=true|false (ALPHA - 기본값=false)
    AllBeta=true|false (BETA - 기본값=false)
    AnyVolumeDataSource=true|false (ALPHA - 기본값=false)
    AppArmor=true|false (BETA - 기본값=true)
    CPUManager=true|false (BETA - 기본값=true)
    CPUManagerPolicyOptions=true|false (ALPHA - 기본값=false)
    CSIInlineVolume=true|false (BETA - 기본값=true)
    CSIMigration=true|false (BETA - 기본값=true)
    CSIMigrationAWS=true|false (BETA - 기본값=false)
    CSIMigrationAzureDisk=true|false (BETA - 기본값=false)
    CSIMigrationAzureFile=true|false (BETA - 기본값=false)
    CSIMigrationGCE=true|false (BETA - 기본값=false)
    CSIMigrationOpenStack=true|false (BETA - 기본값=true)
    CSIMigrationvSphere=true|false (BETA - 기본값=false)
    CSIStorageCapacity=true|false (BETA - 기본값=true)
    CSIVolumeFSGroupPolicy=true|false (BETA - 기본값=true)
    CSIVolumeHealth=true|false (ALPHA - 기본값=false)
    CSRDuration=true|false (BETA - 기본값=true)
    ConfigurableFSGroupPolicy=true|false (BETA - 기본값=true)
    ControllerManagerLeaderMigration=true|false (BETA - 기본값=true)
    CustomCPUCFSQuotaPeriod=true|false (ALPHA - 기본값=false)
    DaemonSetUpdateSurge=true|false (BETA - 기본값=true)
    DefaultPodTopologySpread=true|false (BETA - 기본값=true)
    DelegateFSGroupToCSIDriver=true|false (ALPHA - 기본값=false)
    DevicePlugins=true|false (BETA - 기본값=true)
    DisableAcceleratorUsageMetrics=true|false (BETA - 기본값=true)
    DisableCloudProviders=true|false (ALPHA - 기본값=false)
    DownwardAPIHugePages=true|false (BETA - 기본값=false)
    EfficientWatchResumption=true|false (BETA - 기본값=true)
    EndpointSliceTerminatingCondition=true|false (BETA - 기본값=true)
    EphemeralContainers=true|false (ALPHA - 기본값=false)
    ExpandCSIVolumes=true|false (BETA - 기본값=true)
    ExpandInUsePersistentVolumes=true|false (BETA - 기본값=true)
    ExpandPersistentVolumes=true|false (BETA - 기본값=true)
    ExpandedDNSConfig=true|false (ALPHA - 기본값=false)
    ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 기본값=false)
    GenericEphemeralVolume=true|false (BETA - 기본값=true)
    GracefulNodeShutdown=true|false (BETA - 기본값=true)
    HPAContainerMetrics=true|false (ALPHA - 기본값=false)
    HPAScaleToZero=true|false (ALPHA - 기본값=false)
    IPv6DualStack=true|false (BETA - 기본값=true)
    InTreePluginAWSUnregister=true|false (ALPHA - 기본값=false)
    InTreePluginAzureDiskUnregister=true|false (ALPHA - 기본값=false)
    InTreePluginAzureFileUnregister=true|false (ALPHA - 기본값=false)
    InTreePluginGCEUnregister=true|false (ALPHA - 기본값=false)
    InTreePluginOpenStackUnregister=true|false (ALPHA - 기본값=false)
    InTreePluginvSphereUnregister=true|false (ALPHA - 기본값=false)
    IndexedJob=true|false (BETA - 기본값=true)
    IngressClassNamespacedParams=true|false (BETA - 기본값=true)
    JobTrackingWithFinalizers=true|false (ALPHA - 기본값=false)
    KubeletCredentialProviders=true|false (ALPHA - 기본값=false)
    KubeletInUserNamespace=true|false (ALPHA - 기본값=false)
    KubeletPodResources=true|false (BETA - 기본값=true)
    KubeletPodResourcesGetAllocatable=true|false (ALPHA - 기본값=false)
    LocalStorageCapacityIsolation=true|false (BETA - 기본값=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 기본값=false)
    LogarithmicScaleDown=true|false (BETA - 기본값=true)
    MemoryManager=true|false (BETA - 기본값=true)
    MemoryQoS=true|false (ALPHA - 기본값=false)
    MixedProtocolLBService=true|false (ALPHA - 기본값=false)
    NetworkPolicyEndPort=true|false (BETA - 기본값=true)
    NodeSwap=true|false (ALPHA - 기본값=false)
    NonPreemptingPriority=true|false (BETA - 기본값=true)
    PodAffinityNamespaceSelector=true|false (BETA - 기본값=true)
    PodDeletionCost=true|false (BETA - 기본값=true)
    PodOverhead=true|false (BETA - 기본값=true)
    PodSecurity=true|false (ALPHA - 기본값=false)
    PreferNominatedNode=true|false (BETA - 기본값=true)
    ProbeTerminationGracePeriod=true|false (BETA - 기본값=false)
    ProcMountType=true|false (ALPHA - 기본값=false)
    ProxyTerminatingEndpoints=true|false (ALPHA - 기본값=false)
    QOSReserved=true|false (ALPHA - 기본값=false)
    ReadWriteOncePod=true|false (ALPHA - 기본값=false)
    RemainingItemCount=true|false (BETA - 기본값=true)
    RemoveSelfLink=true|false (BETA - 기본값=true)
    RotateKubeletServerCertificate=true|false (BETA - 기본값=true)
    Seccomp기본값=true|false (ALPHA - 기본값=false)
    ServiceInternalTrafficPolicy=true|false (BETA - 기본값=true)
    ServiceLBNodePortControl=true|false (BETA - 기본값=true)
    ServiceLoadBalancerClass=true|false (BETA - 기본값=true)
    SizeMemoryBackedVolumes=true|false (BETA - 기본값=true)
    StatefulSetMinReadySeconds=true|false (ALPHA - 기본값=false)
    StorageVersionAPI=true|false (ALPHA - 기본값=false)
    StorageVersionHash=true|false (BETA - 기본값=true)
    SuspendJob=true|false (BETA - 기본값=true)
    TTLAfterFinished=true|false (BETA - 기본값=true)
    TopologyAwareHints=true|false (ALPHA - 기본값=false)
    TopologyManager=true|false (BETA - 기본값=true)
    VolumeCapacityPriority=true|false (ALPHA - 기본값=false)
    WinDSR=true|false (ALPHA - 기본값=false)
    WinOverlay=true|false (BETA - 기본값=true)
    WindowsHostProcessContainers=true|false (ALPHA - 기본값=false)

    A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
    APIListChunking=true|false (BETA - default=true)
    APIPriorityAndFairness=true|false (BETA - default=true)
    APIResponseCompression=true|false (BETA - default=true)
    APIServerIdentity=true|false (ALPHA - default=false)
    APIServerTracing=true|false (ALPHA - default=false)
    AllAlpha=true|false (ALPHA - default=false)
    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 (BETA - default=true)
    CSIInlineVolume=true|false (BETA - default=true)
    CSIMigration=true|false (BETA - default=true)
    CSIMigrationAWS=true|false (BETA - default=true)
    CSIMigrationAzureDisk=true|false (BETA - default=true)
    CSIMigrationAzureFile=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)
    CSIVolumeHealth=true|false (ALPHA - default=false)
    CSRDuration=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 (BETA - default=true)
    DevicePlugins=true|false (BETA - default=true)
    DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
    DisableCloudProviders=true|false (ALPHA - 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 (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)
    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)
    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)
    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 (BETA - default=true)
    LocalStorageCapacityIsolation=true|false (BETA - default=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
    LogarithmicScaleDown=true|false (BETA - default=true)
    MemoryManager=true|false (BETA - default=true)
    MemoryQoS=true|false (ALPHA - default=false)
    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 (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)
    SeccompDefault=true|false (ALPHA - default=false)
    ServerSideFieldValidation=true|false (ALPHA - default=false)
    ServiceInternalTrafficPolicy=true|false (BETA - default=true)
    ServiceLBNodePortControl=true|false (BETA - default=true)
    ServiceLoadBalancerClass=true|false (BETA - default=true)
    SizeMemoryBackedVolumes=true|false (BETA - default=true)
    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)
    TopologyAwareHints=true|false (BETA - default=false)
    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 (BETA - default=true)
    csiMigrationRBD=true|false (ALPHA - default=false)

    인증 정보가 있는 kubeconfig 파일의 경로(마스터 위치는 마스터 플래그로 설정됨).
    --log-backtrace-at <'file:N' 형태의 문자열>     기본값: :0

    로깅 과정에서 file:N 번째 라인에 도달하면 스택 트레이스를 출력한다.

    --log-dir string

    로그 파일이 저장될 디렉터리

    --log-file string

    사용할 로그 파일

    --log-file-max-size uint     기본값: 1800

    로그 파일의 최대 크기(단위: MB). 0으로 설정하면 무제한이다.

    --log-flush-frequency duration     기본값: 5s

    로그 플러시 사이의 최대 시간

    --logtostderr     기본값: true

    로그를 파일에 기록하지 않고 표준 에러로만 출력

    --machine-id-file string     기본값: "/etc/machine-id,/var/lib/dbus/machine-id"

    machine-id를 위해 확인할 파일 목록(쉼표로 분리). 가장 먼저 발견되는 항목을 사용한다.
    --machine_id_file string     기본값: "/etc/machine-id,/var/lib/dbus/machine-id"

    machine-id를 위해 확인할 파일 목록(쉼표로 분리). 가장 먼저 발견되는 항목을 사용한다.

    --masquerade-all

    NodePort에 사용할 주소를 지정하는 값의 문자열 조각. 값은 유효한 IP 블록(예: 1.2.3.0/24, 1.2.3.4/32). 기본값인 빈 문자열 조각값은([]) 모든 로컬 주소를 사용하는 것을 의미한다.
    --one-output

    true이면, 해당 로그가 속하는 심각성 레벨에만 각 로그를 기록한다(원래는 하위 심각성 레벨에도 기록한다).

    --oom-score-adj int32     기본값: -999

    숨겨진 메트릭을 표시하려는 이전 버전. 이전 마이너 버전만 인식하며, 다른 값은 허용하지 않는다. 포멧은 <메이저>.<마이너> 와 같으며, 예를 들면 '1.16' 과 같다. 이 포멧의 목적은, 다음 릴리스가 숨길 추가적인 메트릭을 사용자에게 공지하여, 그 이후 릴리스에서 메트릭이 영구적으로 삭제됐을 때 사용자가 놀라지 않도록 하기 위함이다.
    --skip-headers

    true이면, 로그 메시지에서 헤더 접두사를 붙이지 않는다.

    --skip-log-headers

    true이면, 로그 파일을 열 때 헤더를 붙이지 않는다.

    --stderrthreshold int     기본값: 2

    이 값 이상의 로그는 표준 에러(stderr)로 출력되도록 한다.

    --udp-timeout duration     기본값: 250ms

    유휴 UDP 연결이 열린 상태로 유지되는 시간(예: '250ms', '2s'). 값은 0보다 커야 한다. 프록시 모드 userspace에만 적용 가능함.
    -v, --v int

    로그 상세 레벨(verbosity)

    --version version[=true]

    버전 정보를 출력하고 종료
    --vmodule <쉼표로 구분된 'pattern=N' 설정>

    파일-필터된 로깅을 위한 'pattern=N' 설정들(쉼표로 구분됨)

    --write-config-to string