diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 2c1452beabb..76c412ba1a5 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -1,17 +1,16 @@ aliases: sig-docs-blog-owners: # Approvers for blog content - - onlydole - mrbobbytables - - sftim - nate-double-u + - onlydole + - sftim sig-docs-blog-reviewers: # Reviewers for blog content - mrbobbytables + - nate-double-u - onlydole - sftim - - nate-double-u sig-docs-localization-owners: # Admins for localization content - a-mccarthy - - bradtopol - divya-mohan0209 - jimangel - kbhawkey @@ -33,7 +32,6 @@ aliases: - bradtopol - divya-mohan0209 - jimangel - - jlbutler - kbhawkey - krol3 - natalisucks @@ -44,7 +42,6 @@ aliases: - tengqm sig-docs-en-reviews: # PR reviews for English content - bradtopol - - daminisatya - divya-mohan0209 - jimangel - kbhawkey @@ -52,7 +49,6 @@ aliases: - natalisucks - nate-double-u - onlydole - - rajeshdeshpande02 - reylejano - sftim - shannonxtreme @@ -255,17 +251,19 @@ aliases: # authoritative source: https://git.k8s.io/sig-release/OWNERS_ALIASES sig-release-leads: - cpanato # SIG Technical Lead - - jeremyrickard # SIG Technical Lead + - jeremyrickard # SIG Chair - justaugustus # SIG Chair - puerco # SIG Technical Lead - saschagrunert # SIG Chair + - Verolop # SIG Technical Lead release-engineering-approvers: - - cpanato # Release Manager - - palnabarun # Release Manager - - puerco # Release Manager - - saschagrunert # subproject owner / Release Manager + - cpanato # subproject owner / Release Manager + - jeremyrickard # subproject owner / Release Manager - justaugustus # subproject owner / Release Manager - - Verolop # Release Manager + - palnabarun # Release Manager + - puerco # subproject owner / Release Manager + - saschagrunert # subproject owner / Release Manager + - Verolop # subproject owner / Release Manager - xmudrii # Release Manager release-engineering-reviewers: - ameukam # Release Manager Associate diff --git a/SECURITY_CONTACTS b/SECURITY_CONTACTS index 839e7bed14e..45a06ee063d 100644 --- a/SECURITY_CONTACTS +++ b/SECURITY_CONTACTS @@ -11,5 +11,9 @@ # INSTRUCTIONS AT https://kubernetes.io/security/ divya-mohan0209 -jimangel +reylejano sftim +tengqm +onlydole +kbhawkey +natalisucks diff --git a/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md b/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md index 73043a67e00..0f75a90a28a 100644 --- a/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md +++ b/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md @@ -4,9 +4,12 @@ title: "PodSecurityPolicy Deprecation: Past, Present, and Future" date: 2021-04-06 slug: podsecuritypolicy-deprecation-past-present-and-future --- - **Author:** Tabitha Sable (Kubernetes SIG Security) +{{% pageinfo color="primary" %}} +**Update:** *With the release of Kubernetes v1.25, PodSecurityPolicy has been removed.* *You can read more information about the removal of PodSecurityPolicy in the [Kubernetes 1.25 release notes](/blog/2022/08/23/kubernetes-v1-25-release/#pod-security-changes).* +{{% /pageinfo %}} + PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, to be released later this week. This starts the countdown to its removal, but doesn’t change anything else. PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely. In the meantime, we are developing a replacement for PSP that covers key use cases more easily and sustainably. What are Pod Security Policies? Why did we need them? Why are they going away, and what’s next? How does this affect you? These key questions come to mind as we prepare to say goodbye to PSP, so let’s walk through them together. We’ll start with an overview of how features get removed from Kubernetes. diff --git a/content/en/blog/_posts/2022-10-18-kubernetes-1.26-deprecations-and-removals.md b/content/en/blog/_posts/2022-10-18-kubernetes-1.26-deprecations-and-removals.md index 8574208d87f..3dc8a65ef8d 100644 --- a/content/en/blog/_posts/2022-10-18-kubernetes-1.26-deprecations-and-removals.md +++ b/content/en/blog/_posts/2022-10-18-kubernetes-1.26-deprecations-and-removals.md @@ -11,7 +11,7 @@ Change is an integral part of the Kubernetes life-cycle: as Kubernetes grows and ## The Kubernetes API Removal and Deprecation process {#k8s-api-deprecation-process} -The Kubernetes project has a [well-documented deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API is one that has been marked for removal in a future Kubernetes release; it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. +The Kubernetes project has a [well-documented deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API is one that has been marked for removal in a future Kubernetes release; it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. * Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes. * Beta or pre-release API versions must be supported for 3 releases after deprecation. @@ -21,7 +21,7 @@ Whether an API is removed as a result of a feature graduating from beta to stabl ## A note about the removal of the CRI `v1alpha2` API and containerd 1.5 support {#cri-api-removal} -Following the adoption of the [Container Runtime Interface](https://kubernetes.io/docs/concepts/architecture/cri/) (CRI) and the [removal of dockershim] in v1.24 , the CRI is the supported and documented way through which Kubernetes interacts withdifferent container runtimes. Each kubelet negotiates which version of CRI to use with the container runtime on that node. +Following the adoption of the [Container Runtime Interface](/docs/concepts/architecture/cri/) (CRI) and the [removal of dockershim] in v1.24 , the CRI is the supported and documented way through which Kubernetes interacts with different container runtimes. Each kubelet negotiates which version of CRI to use with the container runtime on that node. The Kubernetes project recommends using CRI version `v1`; in Kubernetes v1.25 the kubelet can also negotiate the use of CRI `v1alpha2` (which was deprecated along at the same time as adding support for the stable `v1` interface). @@ -37,11 +37,11 @@ In addition to the above, Kubernetes v1.26 is targeted to include several additi ### Removal of the `v1beta1` flow control API group -The `flowcontrol.apiserver.k8s.io/v1beta1` API version of FlowSchema and PriorityLevelConfiguration [will no longer be served in v1.26](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#flowcontrol-resources-v126). Users should migrate manifests and API clients to use the `flowcontrol.apiserver.k8s.io/v1beta2` API version, available since v1.23. +The `flowcontrol.apiserver.k8s.io/v1beta1` API version of FlowSchema and PriorityLevelConfiguration [will no longer be served in v1.26](/docs/reference/using-api/deprecation-guide/#flowcontrol-resources-v126). Users should migrate manifests and API clients to use the `flowcontrol.apiserver.k8s.io/v1beta2` API version, available since v1.23. ### Removal of the `v2beta2` HorizontalPodAutoscaler API -The `autoscaling/v2beta2` API version of HorizontalPodAutoscaler [will no longer be served in v1.26](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#horizontalpodautoscaler-v126). Users should migrate manifests and API clients to use the `autoscaling/v2` API version, available since v1.23. +The `autoscaling/v2beta2` API version of HorizontalPodAutoscaler [will no longer be served in v1.26](/docs/reference/using-api/deprecation-guide/#horizontalpodautoscaler-v126). Users should migrate manifests and API clients to use the `autoscaling/v2` API version, available since v1.23. ### Removal of in-tree credential management code @@ -64,14 +64,14 @@ The `userspace` proxy mode, deprecated for over a year, is [no longer supported ### Removal of in-tree OpenStack cloud provider Kubernetes is switching from in-tree code for storage integrations, in favor of the Container Storage Interface (CSI). -As part of this, Kubernetes v1.26 will remove the the deprecated in-tree storage integration for OpenStack +As part of this, Kubernetes v1.26 will remove the deprecated in-tree storage integration for OpenStack (the `cinder` volume type). You should migrate to external cloud provider and CSI driver from https://github.com/kubernetes/cloud-provider-openstack instead. For more information, visit [Cinder in-tree to CSI driver migration](https://github.com/kubernetes/enhancements/issues/1489). ### Removal of the GlusterFS in-tree driver -The in-tree GlusterFS driver was [deprecated in v1.25](https://kubernetes.io/blog/2022/08/23/kubernetes-v1-25-release/#deprecations-and-removals), and will be removed from Kubernetes v1.26. +The in-tree GlusterFS driver was [deprecated in v1.25](/blog/2022/08/23/kubernetes-v1-25-release/#deprecations-and-removals), and will be removed from Kubernetes v1.26. ### Deprecation of non-inclusive `kubectl` flag @@ -91,7 +91,7 @@ Dynamic kubelet configuration was removed from the kubelet in v1.24, and will be The `--master-service-namespace` command line argument to the kube-apiserver doesn't have any effect, and was already informally [deprecated](https://github.com/kubernetes/kubernetes/pull/38186). -That command line argument wil be formally marked as deprecated in v1.26, preparing for its +That command line argument will be formally marked as deprecated in v1.26, preparing for its removal in a future release. The Kubernetes project does not expect any impact from this deprecation and removal. @@ -108,7 +108,7 @@ Several unused option arguments for the `kubectl run` subcommand will be [marked * `--timeout` * `--wait` -These arguments are already ignored so no impact is expected: the explicit deprecation sets a warning message and prepares the removal of the argumentsin a future release. +These arguments are already ignored so no impact is expected: the explicit deprecation sets a warning message and prepares the removal of the arguments in a future release. ### Removal of legacy command line arguments relating to logging @@ -119,7 +119,7 @@ For more information, see [Deprecate klog specific flags in Kubernetes Component ## Looking ahead {#looking-ahead} -The official list of [API removals](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-27) planned for Kubernetes 1.27 includes: +The official list of [API removals](/docs/reference/using-api/deprecation-guide/#v1-27) planned for Kubernetes 1.27 includes: * All beta versions of the CSIStorageCapacity API; specifically: `storage.k8s.io/v1beta1` diff --git a/content/en/blog/_posts/2022-11-28-registry-k8s-io-change.md b/content/en/blog/_posts/2022-11-28-registry-k8s-io-change.md new file mode 100644 index 00000000000..604c6e738ea --- /dev/null +++ b/content/en/blog/_posts/2022-11-28-registry-k8s-io-change.md @@ -0,0 +1,75 @@ +--- +layout: blog +title: "registry.k8s.io: faster, cheaper and Generally Available (GA)" +date: 2022-11-28 +slug: registry-k8s-io-faster-cheaper-ga +--- + +**Authors**: Adolfo García Veytia (Chainguard), Bob Killen (Google) + +Starting with Kubernetes 1.25, our container image registry has changed from k8s.gcr.io to [registry.k8s.io](https://registry.k8s.io). This new registry spreads the load across multiple Cloud Providers & Regions, functioning as a sort of content delivery network (CDN) for Kubernetes container images. This change reduces the project’s reliance on a single entity and provides a faster download experience for a large number of users. + +## TL;DR: What you need to know about this change + +* Container images for Kubernetes releases from 1.25 onward are no longer published to k8s.gcr.io, only to registry.k8s.io. +* In the upcoming December patch releases, the new registry domain default will be backported to all branches still in support (1.22, 1.23, 1.24). +* If you run in a restricted environment and apply strict domain/IP address access policies limited to k8s.gcr.io, the __image pulls will not function__ after the migration to this new registry. For these users, the recommended method is to mirror the release images to a private registry. + +If you’d like to know more about why we made this change, or some potential issues you might run into, keep reading. + +## Why has Kubernetes changed to a different image registry? + +k8s.gcr.io is hosted on a custom [Google Container Registry](https://cloud.google.com/container-registry) (GCR) domain that was setup solely for the Kubernetes project. This has worked well since the inception of the project, and we thank Google for providing these resources, but today there are other cloud providers and vendors that would like to host images to provide a better experience for the people on their platforms. In addition to Google’s [renewed commitment to donate $3 million](https://www.cncf.io/google-cloud-recommits-3m-to-kubernetes/) to support the project's infrastructure, Amazon announced a matching donation during their Kubecon NA 2022 keynote in Detroit. This will provide a better experience for users (closer servers = faster downloads) and will reduce the egress bandwidth and costs from GCR at the same time. registry.k8s.io will spread the load between Google and Amazon, with other providers to follow in the future. + +## Why isn’t there a stable list of domains/IPs? Why can’t I restrict image pulls? + +registry.k8s.io is a [secure blob redirector](https://github.com/kubernetes/registry.k8s.io/blob/main/cmd/archeio/docs/request-handling.md) that connects clients to the closest cloud provider. The nature of this change means that a client pulling an image could be redirected to any one of a large number of backends. We expect the set of backends to keep changing and will only increase as more and more cloud providers and vendors come on board to help mirror the release images. + +Restrictive control mechanisms like man-in-the-middle proxies or network policies that restrict access to a specific list of IPs/domains will break with this change. For these scenarios, we encourage you to mirror the release images to a local registry that you have strict control over. + +For more information on this policy, please see the [stability section of the registry.k8s.io documentation](https://github.com/kubernetes/registry.k8s.io#stability). + +## What kind of errors will I see? How will I know if I’m still using the old address? + +Errors may depend on what kind of container runtime you are using, and what endpoint you are routed to, but it should present as a container failing to be created with the warning `FailedCreatePodSandBox`. + +Below is an example error message showing a proxied deployment failing to pull due to an unknown certificate: + +``` +FailedCreatePodSandBox: Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Head “https://us-west1-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.8”: x509: certificate signed by unknown authority +``` + +## I’m impacted by this change, how do I revert to the old registry address? + +If using the new registry domain name is not an option, you can revert to the old domain name for cluster versions less than 1.25. Keep in mind that, eventually, you will have to switch to the new registry, as new image tags will no longer be pushed to GCR. + +### Reverting the registry name in kubeadm +The registry used by kubeadm to pull its images can be controlled by two methods: + +Setting the `--image-repository` flag. + +``` +kubeadm init --image-repository=k8s.gcr.io +``` + +Or in [kubeadm config](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/) `ClusterConfiguration`: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +imageRepository: "k8s.gcr.io" +``` + +### Reverting the Registry Name in kubelet + +The image used by kubelet for the pod sandbox (`pause`) can be overridden by setting the `--pod-infra-container-image` flag. For example: + +``` +kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5 +``` + +## Acknowledgments + +__Change is hard__, and evolving our image-serving platform is needed to ensure a sustainable future for the project. We strive to make things better for everyone using Kubernetes. Many contributors from all corners of our community have been working long and hard to ensure we are making the best decisions possible, executing plans, and doing our best to communicate those plans. + +Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen, and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from the Security Response Committee. Also a big thank you to our friends acting as liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson Jr. from Google. diff --git a/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/conmonrs_spans.png b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/conmonrs_spans.png new file mode 100644 index 00000000000..c33e99b9782 Binary files /dev/null and b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/conmonrs_spans.png differ diff --git a/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/create_container.png b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/create_container.png new file mode 100644 index 00000000000..18d9235ab68 Binary files /dev/null and b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/create_container.png differ diff --git a/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/crio_spans.png b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/crio_spans.png new file mode 100644 index 00000000000..fa759903a28 Binary files /dev/null and b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/crio_spans.png differ diff --git a/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/index.md b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/index.md new file mode 100644 index 00000000000..389089e9de9 --- /dev/null +++ b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/index.md @@ -0,0 +1,279 @@ +--- +layout: blog +title: "Boosting Kubernetes container runtime observability with OpenTelemetry" +date: 2022-12-01 +slug: runtime-observability-opentelemetry +--- + +**Authors:** Sascha Grunert + +When speaking about observability in the cloud native space, then probably +everyone will mention [OpenTelemetry (OTEL)][otel] at some point in the +conversation. That's great, because the community needs standards to rely on +for developing all cluster components into the same direction. OpenTelemetry +enables us to combine logs, metrics, traces and other contextual information +(called baggage) into a single resource. Cluster administrators or software +engineers can use this resource to get a viewport about what is going on in the +cluster over a defined period of time. But how can Kubernetes itself make use of +this technology stack? + +[otel]: https://opentelemetry.io + +Kubernetes consists of multiple components where some are independent and others +are stacked together. Looking at the architecture from a container runtime +perspective, then there are from the top to the bottom: + +- **kube-apiserver**: Validates and configures data for the API objects +- **kubelet**: Agent running on each node +- **CRI runtime**: Container Runtime Interface (CRI) compatible container runtime + like [CRI-O][crio] or [containerd][containerd] +- **OCI runtime**: Lower level [Open Container Initiative (OCI)][oci] runtime + like [runc][runc] or [crun][crun] +- **Linux kernel** or **Microsoft Windows**: Underlying operating system + +[crio]: https://cri-o.io +[containerd]: https://containerd.io +[oci]: https://opencontainers.org +[runc]: https://github.com/opencontainers/runc +[crun]: https://github.com/containers/crun + +That means if we encounter a problem with running containers in Kubernetes, then +we start looking at one of those components. Finding the root cause for problems +is one of the most time consuming actions we face with the increased +architectural complexity from today's cluster setups. Even if we know the +component which seems to cause the issue, we still have to take the others into +account to maintain a mental timeline of events which are going on. How do we +achieve that? Well, most folks will probably stick to scraping logs, filtering +them and assembling them together over the components borders. We also have +metrics, right? Correct, but bringing metrics values in correlation with plain +logs makes it even harder to track what is going on. Some metrics are also not +made for debugging purposes. They have been defined based on the end user +perspective of the cluster for linking usable alerts and not for developers +debugging a cluster setup. + +OpenTelemetry to the rescue: the project aims to combine signals such as +[traces][traces], [metrics][metrics] and [logs][logs] together to maintain the +right viewport on the cluster state. + +[traces]: https://opentelemetry.io/docs/concepts/signals/traces +[metrics]: https://opentelemetry.io/docs/concepts/signals/metrics +[logs]: https://opentelemetry.io/docs/concepts/signals/logs + +What is the current state of OpenTelemetry tracing in Kubernetes? From an API +server perspective, we have alpha support for tracing since Kubernetes v1.22, +which will graduate to beta in one of the upcoming releases. Unfortunately the +beta graduation has missed the v1.26 Kubernetes release. The design proposal can +be found in the [_API Server Tracing_ Kubernetes Enhancement Proposal +(KEP)][kep-647] which provides more information about it. + +[kep-647]: https://github.com/kubernetes/enhancements/issues/647 + +The kubelet tracing part is tracked [in another KEP][kep-2831], which was +implemented in an alpha state in Kubernetes v1.25. A beta graduation is not +planned as time of writing, but more may come in the v1.27 release cycle. +There are other side-efforts going on beside both KEPs, for example [klog is +considering OTEL support][klog-otel], which would boost the observability by +linking log messages to existing traces. Within SIG Instrumentation and SIG Node, +we're also discussing [how to link the +kubelet traces together][issue-113414], because right now they're focused on the +[gRPC][grpc] calls between the kubelet and the CRI container runtime. + +[kep-647]: https://github.com/kubernetes/enhancements/issues/647 +[kep-2831]: https://github.com/kubernetes/enhancements/issues/2831 +[klog-otel]: https://github.com/kubernetes/klog/issues/356 +[issue-113414]: https://github.com/kubernetes/kubernetes/issues/113414 +[grpc]: https://grpc.io + +CRI-O features OpenTelemetry tracing support [since v1.23.0][pr-4883] and is +working on continuously improving them, for example by [attaching the logs to the +traces][pr-6294] or extending the [spans to logical parts of the +application][pr-6343]. This helps users of the traces to gain the same +information like parsing the logs, but with enhanced capabilities of scoping and +filtering to other OTEL signals. The CRI-O maintainers are also working on a +container monitoring replacement for [conmon][conmon], which is called +[conmon-rs][conmon-rs] and is purely written in [Rust][rust]. One benefit of +having a Rust implementation is to be able to add features like OpenTelemetry +support, because the crates (libraries) for those already exist. This allows a +tight integration with CRI-O and lets consumers see the most low level tracing +data from their containers. + +[pr-4883]: https://github.com/cri-o/cri-o/pull/4883 +[pr-6294]: https://github.com/cri-o/cri-o/pull/6294 +[pr-6343]: https://github.com/cri-o/cri-o/pull/6343 +[conmon]: https://github.com/containers/conmon +[conmon-rs]: https://github.com/containers/conmon-rs +[rust]: https://www.rust-lang.org + +The [containerd][containerd] folks added tracing support since v1.6.0, which is +available [by using a plugin][containerd-docs]. Lower level OCI runtimes like +[runc][runc] or [crun][crun] feature no support for OTEL at all and it does not +seem to exist a plan for that. We always have to consider that there is a +performance overhead when collecting the traces as well as exporting them to a +data sink. I still think it would be worth an evaluation on how extended +telemetry collection could look like in OCI runtimes. Let's see if the Rust OCI +runtime [youki][youki-1348] is considering something like that in the future. + +[containerd-docs]: https://github.com/containerd/containerd/blob/7def13d/docs/tracing.md +[youki-1348]: https://github.com/containers/youki/issues/1348 + +I'll show you how to give it a try. For my demo I'll stick to a stack with a single local node +that has runc, conmon-rs, CRI-O, and a kubelet. To enable tracing in the kubelet, I need to +apply the following `KubeletConfiguration`: + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +featureGates: + KubeletTracing: true +tracing: + samplingRatePerMillion: 1000000 +``` + +A `samplingRatePerMillion` equally to one million will internally translate to +sampling everything. A similar configuration has to be applied to CRI-O; I can +either start the `crio` binary with `--enable-tracing` and +`--tracing-sampling-rate-per-million 1000000` or we use a drop-in configuration +like this: + +```shell +cat /etc/crio/crio.conf.d/99-tracing.conf +``` + +```toml +[crio.tracing] +enable_tracing = true +tracing_sampling_rate_per_million = 1000000 +``` + +To configure CRI-O to use conmon-rs, you require at least the latest CRI-O +v1.25.x and conmon-rs v0.4.0. Then a configuration drop-in like this can be used +to make CRI-O use conmon-rs: + +```shell +cat /etc/crio/crio.conf.d/99-runtimes.conf +``` + +```toml +[crio.runtime] +default_runtime = "runc" + +[crio.runtime.runtimes.runc] +runtime_type = "pod" +monitor_path = "/path/to/conmonrs" # or will be looked up in $PATH +``` + +That's it, the default configuration will point to an [OpenTelemetry +collector][collector] [gRPC][grpc] endpoint of `localhost:4317`, which has to be up and +running as well. There are multiple ways to run OTLP as [described in the +docs][collector], but it's also possible to `kubectl proxy` into an existing +instance running within Kubernetes. + +[collector]: https://opentelemetry.io/docs/collector/getting-started + +If everything is set up, then the collector should log that there are incoming +traces: + +``` +ScopeSpans #0 +ScopeSpans SchemaURL: +InstrumentationScope go.opentelemetry.io/otel/sdk/tracer +Span #0 + Trace ID : 71896e69f7d337730dfedb6356e74f01 + Parent ID : a2a7714534c017e6 + ID : 1d27dbaf38b9da8b + Name : github.com/cri-o/cri-o/server.(*Server).filterSandboxList + Kind : SPAN_KIND_INTERNAL + Start time : 2022-11-15 09:50:20.060325562 +0000 UTC + End time : 2022-11-15 09:50:20.060326291 +0000 UTC + Status code : STATUS_CODE_UNSET + Status message : +Span #1 + Trace ID : 71896e69f7d337730dfedb6356e74f01 + Parent ID : a837a005d4389579 + ID : a2a7714534c017e6 + Name : github.com/cri-o/cri-o/server.(*Server).ListPodSandbox + Kind : SPAN_KIND_INTERNAL + Start time : 2022-11-15 09:50:20.060321973 +0000 UTC + End time : 2022-11-15 09:50:20.060330602 +0000 UTC + Status code : STATUS_CODE_UNSET + Status message : +Span #2 + Trace ID : fae6742709d51a9b6606b6cb9f381b96 + Parent ID : 3755d12b32610516 + ID : 0492afd26519b4b0 + Name : github.com/cri-o/cri-o/server.(*Server).filterContainerList + Kind : SPAN_KIND_INTERNAL + Start time : 2022-11-15 09:50:20.0607746 +0000 UTC + End time : 2022-11-15 09:50:20.060795505 +0000 UTC + Status code : STATUS_CODE_UNSET + Status message : +Events: +SpanEvent #0 + -> Name: log + -> Timestamp: 2022-11-15 09:50:20.060778668 +0000 UTC + -> DroppedAttributesCount: 0 + -> Attributes:: + -> id: Str(adf791e5-2eb8-4425-b092-f217923fef93) + -> log.message: Str(No filters were applied, returning full container list) + -> log.severity: Str(DEBUG) + -> name: Str(/runtime.v1.RuntimeService/ListContainers) +``` + +I can see that the spans have a trace ID and typically have a parent attached. +Events such as logs are part of the output as well. In the above case, the kubelet is +periodically triggering a `ListPodSandbox` RPC to CRI-O caused by the Pod +Lifecycle Event Generator (PLEG). Displaying those traces can be done via, +for example, [Jaeger][jaeger]. When running the tracing stack locally, then a Jaeger +instance should be exposed on `http://localhost:16686` per default. + +[jaeger]: https://www.jaegertracing.io/ + +The `ListPodSandbox` requests are directly visible within the Jaeger UI: + +![ListPodSandbox RPC in the Jaeger UI](list_pod_sandbox.png) + +That's not too exciting, so I'll run a workload directly via `kubectl`: + +```shell +kubectl run -it --rm --restart=Never --image=alpine alpine -- echo hi +``` + +``` +hi +pod "alpine" deleted +``` + +Looking now at Jaeger, we can see that we have traces for `conmonrs`, `crio` as +well as the `kubelet` for the `RunPodSandbox` and `CreateContainer` CRI RPCs: + +![Container creation in the Jaeger UI](create_container.png) + +The kubelet and CRI-O spans are connected to each other to make investigation +easier. If we now take a closer look at the spans, then we can see that CRI-O's +logs are correctly accosted with the corresponding functionality. For example we +can extract the container user from the traces like this: + +![CRI-O in the Jaeger UI](crio_spans.png) + +The lower level spans of conmon-rs are also part of this trace. For example +conmon-rs maintains an internal `read_loop` for handling IO between the +container and the end user. The logs for reading and writing bytes are part of +the span. The same applies to the `wait_for_exit_code` span, which tells us that +the container exited successfully with code `0`: + +![conmon-rs in the Jaeger UI](conmonrs_spans.png) + +Having all that information at hand side by side to the filtering capabilities +of Jaeger makes the whole stack a great solution for debugging container issues! +Mentioning the "whole stack" also shows the biggest downside of the overall +approach: Compared to parsing logs it adds a noticeable overhead on top of the +cluster setup. Users have to maintain a sink like [Elasticsearch][elastic] to +persist the data, expose the Jaeger UI and possibly take the performance +drawback into account. Anyways, it's still one of the best ways to increase the +observability aspect of Kubernetes. + +[elastic]: https://www.elastic.co + +Thank you for reading this blog post, I'm pretty sure we're looking into a +bright future for OpenTelemetry support in Kubernetes to make troubleshooting +simpler. diff --git a/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/list_pod_sandbox.png b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/list_pod_sandbox.png new file mode 100644 index 00000000000..1361e1796b8 Binary files /dev/null and b/content/en/blog/_posts/2022-12-01-runtime-observability-opentelemetry/list_pod_sandbox.png differ diff --git a/content/en/blog/_posts/2022-12-02-seccomp-notifier.md b/content/en/blog/_posts/2022-12-02-seccomp-notifier.md new file mode 100644 index 00000000000..55b4e502a96 --- /dev/null +++ b/content/en/blog/_posts/2022-12-02-seccomp-notifier.md @@ -0,0 +1,346 @@ +--- +layout: blog +title: "Finding suspicious syscalls with the seccomp notifier" +date: 2022-12-02 +slug: seccomp-notifier +--- + +**Authors:** Sascha Grunert + +Debugging software in production is one of the biggest challenges we have to +face in our containerized environments. Being able to understand the impact of +the available security options, especially when it comes to configuring our +deployments, is one of the key aspects to make the default security in +Kubernetes stronger. We have all those logging, tracing and metrics data already +at hand, but how do we assemble the information they provide into something +human readable and actionable? + +[Seccomp][seccomp] is one of the standard mechanisms to protect a Linux based +Kubernetes application from malicious actions by interfering with its [system +calls][syscalls]. This allows us to restrict the application to a defined set of +actionable items, like modifying files or responding to HTTP requests. Linking +the knowledge of which set of syscalls is required to, for example, modify a +local file, to the actual source code is in the same way non-trivial. Seccomp +profiles for Kubernetes have to be written in [JSON][json] and can be understood +as an architecture specific allow-list with superpowers, for example: + +[seccomp]: https://en.wikipedia.org/wiki/Seccomp +[syscalls]: https://en.wikipedia.org/wiki/Syscall +[json]: https://www.json.org + +```json +{ + "defaultAction": "SCMP_ACT_ERRNO", + "defaultErrnoRet": 38, + "defaultErrno": "ENOSYS", + "syscalls": [ + { + "names": ["chmod", "chown", "open", "write"], + "action": "SCMP_ACT_ALLOW" + } + ] +} +``` + +The above profile errors by default specifying the `defaultAction` of +`SCMP_ACT_ERRNO`. This means we have to allow a set of syscalls via +`SCMP_ACT_ALLOW`, otherwise the application would not be able to do anything at +all. Okay cool, for being able to allow file operations, all we have to do is +adding a bunch of file specific syscalls like `open` or `write`, and probably +also being able to change the permissions via `chmod` and `chown`, right? +Basically yes, but there are issues with the simplicity of that approach: + +Seccomp profiles need to include the minimum set of syscalls required to start +the application. This also includes some syscalls from the lower level +[Open Container Initiative (OCI)][oci] container runtime, for example +[runc][runc] or [crun][crun]. Beside that, we can only guarantee the required +syscalls for a very specific version of the runtimes and our application, +because the code parts can change between releases. The same applies to the +termination of the application as well as the target architecture we're +deploying on. Features like executing commands within containers also require +another subset of syscalls. Not to mention that there are multiple versions for +syscalls doing slightly different things and the seccomp profiles are able to +modify their arguments. It's also not always clearly visible to the developers +which syscalls are used by their own written code parts, because they rely on +programming language abstractions or frameworks. + +[oci]: https://opencontainers.org +[runc]: https://github.com/opencontainers/runc +[crun]: https://github.com/containers/crun + +_How can we know which syscalls are even required then? Who should create and +maintain those profiles during its development life-cycle?_ + +Well, recording and distributing seccomp profiles is one of the problem domains +of the [Security Profiles Operator][spo], which is already solving that. The +operator is able to record [seccomp][seccomp], [SELinux][selinux] and even +[AppArmor][apparmor] profiles into a [Custom Resource Definition (CRD)][crd], +reconciles them to each node and makes them available for usage. + +[spo]: https://github.com/kubernetes-sigs/security-profiles-operator +[selinux]: https://en.wikipedia.org/wiki/Security-Enhanced_Linux +[apparmor]: https://en.wikipedia.org/wiki/AppArmor +[crd]: https://k8s.io/docs/concepts/extend-kubernetes/api-extension/custom-resources + +The biggest challenge about creating security profiles is to catch all code +paths which execute syscalls. We could achieve that by having **100%** logical +coverage of the application when running an end-to-end test suite. You get the +problem with the previous statement: It's too idealistic to be ever fulfilled, +even without taking all the moving parts during application development and +deployment into account. + +Missing a syscall in the seccomp profiles' allow list can have tremendously +negative impact on the application. It's not only that we can encounter crashes, +which are trivially detectable. It can also happen that they slightly change +logical paths, change the business logic, make parts of the application +unusable, slow down performance or even expose security vulnerabilities. We're +simply not able to see the whole impact of that, especially because blocked +syscalls via `SCMP_ACT_ERRNO` do not provide any additional [audit][audit] +logging on the system. + +[audit]: https://linux.die.net/man/8/auditd + +Does that mean we're lost? Is it just not realistic to dream about a Kubernetes +where [everyone uses the default seccomp profile][seccomp-default]? Should we +stop striving towards maximum security in Kubernetes and accept that it's not +meant to be secure by default? + +[seccomp-default]: https://github.com/kubernetes/enhancements/issues/2413 + +**Definitely not.** Technology evolves over time and there are many folks +working behind the scenes of Kubernetes to indirectly deliver features to +address such problems. One of the mentioned features is the _seccomp notifier_, +which can be used to find suspicious syscalls in Kubernetes. + +The seccomp notify feature consists of a set of changes introduced in Linux 5.9. +It makes the kernel capable of communicating seccomp related events to the user +space. That allows applications to act based on the syscalls and opens for a +wide range of possible use cases. We not only need the right kernel version, +but also at least runc v1.1.0 (or crun v0.19) to be able to make the notifier +work at all. The Kubernetes container runtime [CRI-O][cri-o] gets [support for +the seccomp notifier in v1.26.0][cri-o-notifier]. The new feature allows us to +identify possibly malicious syscalls in our application, and therefore makes it +possible to verify profiles for consistency and completeness. Let's give that a +try. + +[cri-o]: https://cri-o.io +[cri-o-notifier]: https://github.com/cri-o/cri-o/pull/6120 + +First of all we need to run the latest `main` version of CRI-O, because v1.26.0 +has not been released yet at time of writing. You can do that by either +compiling it from the [source code][sources] or by using the pre-built binary +bundle via [the get-script][script]. The seccomp notifier feature of CRI-O is +guarded by an annotation, which has to be explicitly allowed, for example by +using a configuration drop-in like this: + +```console +> cat /etc/crio/crio.conf.d/02-runtimes.conf +``` + +```toml +[crio.runtime] +default_runtime = "runc" + +[crio.runtime.runtimes.runc] +allowed_annotations = [ "io.kubernetes.cri-o.seccompNotifierAction" ] +``` + +[sources]: https://github.com/cri-o/cri-o/blob/main/install.md#build-and-install-cri-o-from-source +[script]: https://github.com/cri-o/cri-o#installing-cri-o + +If CRI-O is up and running, then it should indicate that the seccomp notifier is +available as well: + +```console +> sudo ./bin/crio --enable-metrics +… +INFO[…] Starting seccomp notifier watcher +INFO[…] Serving metrics on :9090 via HTTP +… +``` + +We also enable the metrics, because they provide additional telemetry data about +the notifier. Now we need a running Kubernetes cluster for demonstration +purposes. For this demo, we mainly stick to the +[`hack/local-up-cluster.sh`][local-up] approach to locally spawn a single node +Kubernetes cluster. + +[local-up]: https://github.com/cri-o/cri-o#running-kubernetes-with-cri-o + +If everything is up and running, then we would have to define a seccomp profile +for testing purposes. But we do not have to create our own, we can just use the +`RuntimeDefault` profile which gets shipped with each container runtime. For +example the `RuntimeDefault` profile for CRI-O can be found in the +[containers/common][runtime-default] library. + +[runtime-default]: https://github.com/containers/common/blob/afff1d6/pkg/seccomp/seccomp.json + +Now we need a test container, which can be a simple [nginx][nginx] pod like +this: + +[nginx]: https://www.nginx.com + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + annotations: + io.kubernetes.cri-o.seccompNotifierAction: "stop" +spec: + restartPolicy: Never + containers: + - name: nginx + image: nginx:1.23.2 + securityContext: + seccompProfile: + type: RuntimeDefault +``` + +Please note the annotation `io.kubernetes.cri-o.seccompNotifierAction`, which +enables the seccomp notifier for this workload. The value of the annotation can +be either `stop` for stopping the workload or anything else for doing nothing +else than logging and throwing metrics. Because of the termination we also use +the `restartPolicy: Never` to not automatically recreate the container on +failure. + +Let's run the pod and check if it works: + +```console +> kubectl apply -f nginx.yaml +``` + +```console +> kubectl get pods -o wide +NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES +nginx 1/1 Running 0 3m39s 10.85.0.3 127.0.0.1 +``` + +We can also test if the web server itself works as intended: + +```console +> curl 10.85.0.3 + + + +Welcome to nginx! +… +``` + +While everything is now up and running, CRI-O also indicates that it has started +the seccomp notifier: + +``` +… +INFO[…] Injecting seccomp notifier into seccomp profile of container 662a3bb0fdc7dd1bf5a88a8aa8ef9eba6296b593146d988b4a9b85822422febb +… +``` + +If we would now run a forbidden syscall inside of the container, then we can +expect that the workload gets terminated. Let's give that a try by running +`chroot` in the containers namespaces: + +```console +> kubectl exec -it nginx -- bash +``` + +```console +root@nginx:/# chroot /tmp +chroot: cannot change root directory to '/tmp': Function not implemented +root@nginx:/# command terminated with exit code 137 +``` + +The exec session got terminated, so it looks like the container is not running +any more: + +```console +> kubectl get pods +NAME READY STATUS RESTARTS AGE +nginx 0/1 seccomp killed 0 96s +``` + +Alright, the container got killed by seccomp, do we get any more information +about what was going on? + +```console +> kubectl describe pod nginx +Name: nginx +… +Containers: + nginx: + … + State: Terminated + Reason: seccomp killed + Message: Used forbidden syscalls: chroot (1x) + Exit Code: 137 + Started: Mon, 14 Nov 2022 12:19:46 +0100 + Finished: Mon, 14 Nov 2022 12:20:26 +0100 +… +``` + +The seccomp notifier feature of CRI-O correctly set the termination reason and +message, including which forbidden syscall has been used how often (`1x`). How +often? Yes, the notifier gives the application up to 5 seconds after the last +seen syscall until it starts the termination. This means that it's possible to +catch multiple forbidden syscalls within one test by avoiding time-consuming +trial and errors. + +```console +> kubectl exec -it nginx -- chroot /tmp +chroot: cannot change root directory to '/tmp': Function not implemented +command terminated with exit code 125 +> kubectl exec -it nginx -- chroot /tmp +chroot: cannot change root directory to '/tmp': Function not implemented +command terminated with exit code 125 +> kubectl exec -it nginx -- swapoff -a +command terminated with exit code 32 +> kubectl exec -it nginx -- swapoff -a +command terminated with exit code 32 +``` + +```console +> kubectl describe pod nginx | grep Message + Message: Used forbidden syscalls: chroot (2x), swapoff (2x) +``` + +The CRI-O metrics will also reflect that: + +```console +> curl -sf localhost:9090/metrics | grep seccomp_notifier +# HELP container_runtime_crio_containers_seccomp_notifier_count_total Amount of containers stopped because they used a forbidden syscalls by their name +# TYPE container_runtime_crio_containers_seccomp_notifier_count_total counter +container_runtime_crio_containers_seccomp_notifier_count_total{name="…",syscalls="chroot (1x)"} 1 +container_runtime_crio_containers_seccomp_notifier_count_total{name="…",syscalls="chroot (2x), swapoff (2x)"} 1 +``` + +How does it work in detail? CRI-O uses the chosen seccomp profile and injects +the action `SCMP_ACT_NOTIFY` instead of `SCMP_ACT_ERRNO`, `SCMP_ACT_KILL`, +`SCMP_ACT_KILL_PROCESS` or `SCMP_ACT_KILL_THREAD`. It also sets a local listener +path which will be used by the lower level OCI runtime (runc or crun) to create +the seccomp notifier socket. If the connection between the socket and CRI-O has +been established, then CRI-O will receive notifications for each syscall being +interfered by seccomp. CRI-O stores the syscalls, allows a bit of timeout for +them to arrive and then terminates the container if the chosen +`seccompNotifierAction=stop`. Unfortunately, the seccomp notifier is not able to +notify on the `defaultAction`, which means that it's required to have +a list of syscalls to test for custom profiles. CRI-O does also state that +limitation in the logs: + +```log +INFO[…] The seccomp profile default action SCMP_ACT_ERRNO cannot be overridden to SCMP_ACT_NOTIFY, + which means that syscalls using that default action can't be traced by the notifier +``` + +As a conclusion, the seccomp notifier implementation in CRI-O can be used to +verify if your applications behave correctly when using `RuntimeDefault` or any +other custom profile. Alerts can be created based on the metrics to create long +running test scenarios around that feature. Making seccomp understandable and +easier to use will increase adoption as well as help us to move towards a more +secure Kubernetes by default! + +Thank you for reading this blog post. If you'd like to read more about the +seccomp notifier, checkout the following resources: + +- The Seccomp Notifier - New Frontiers in Unprivileged Container Development: https://brauner.io/2020/07/23/seccomp-notify.html +- Bringing Seccomp Notify to Runc and Kubernetes: https://kinvolk.io/blog/2022/03/bringing-seccomp-notify-to-runc-and-kubernetes +- Seccomp Agent reference implementation: https://github.com/opencontainers/runc/tree/6b16d00/contrib/cmd/seccompagent diff --git a/content/en/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md b/content/en/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md new file mode 100644 index 00000000000..14293556a43 --- /dev/null +++ b/content/en/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md @@ -0,0 +1,209 @@ +--- +layout: blog +title: "Forensic container checkpointing in Kubernetes" +date: 2022-12-05 +slug: forensic-container-checkpointing-alpha +--- + +**Authors:** Adrian Reber (Red Hat) + +Forensic container checkpointing is based on [Checkpoint/Restore In +Userspace](https://criu.org/) (CRIU) and allows the creation of stateful copies +of a running container without the container knowing that it is being +checkpointed. The copy of the container can be analyzed and restored in a +sandbox environment multiple times without the original container being aware +of it. Forensic container checkpointing was introduced as an alpha feature in +Kubernetes v1.25. + +## How does it work? + +With the help of CRIU it is possible to checkpoint and restore containers. +CRIU is integrated in runc, crun, CRI-O and containerd and forensic container +checkpointing as implemented in Kubernetes uses these existing CRIU +integrations. + +## Why is it important? + +With the help of CRIU and the corresponding integrations it is possible to get +all information and state about a running container on disk for later forensic +analysis. Forensic analysis might be important to inspect a suspicious +container without stopping or influencing it. If the container is really under +attack, the attacker might detect attempts to inspect the container. Taking a +checkpoint and analysing the container in a sandboxed environment offers the +possibility to inspect the container without the original container and maybe +attacker being aware of the inspection. + +In addition to the forensic container checkpointing use case, it is also +possible to migrate a container from one node to another node without loosing +the internal state. Especially for stateful containers with long initialization +times restoring from a checkpoint might save time after a reboot or enable much +faster startup times. + +## How do I use container checkpointing? + +The feature is behind a [feature gate][container-checkpoint-feature-gate], so +make sure to enable the `ContainerCheckpoint` gate before you can use the new +feature. + +The runtime must also support container checkpointing: + +* containerd: support is currently under discussion. See containerd + pull request [#6965][containerd-checkpoint-restore-pr] for more details. + +* CRI-O: v1.25 has support for forensic container checkpointing. + +[containerd-checkpoint-restore-pr]: https://github.com/containerd/containerd/pull/6965 +[container-checkpoint-feature-gate]: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/ + +### Usage example with CRI-O + +To use forensic container checkpointing in combination with CRI-O, the runtime +needs to be started with the command-line option `--enable-criu-support=true`. +For Kubernetes, you need to run your cluster with the `ContainerCheckpoint` +feature gate enabled. As the checkpointing functionality is provided by CRIU it +is also necessary to install CRIU. Usually runc or crun depend on CRIU and +therefore it is installed automatically. + +It is also important to mention that at the time of writing the checkpointing functionality is +to be considered as an alpha level feature in CRI-O and Kubernetes and the +security implications are still under consideration. + +Once containers and pods are running it is possible to create a checkpoint. +[Checkpointing](https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/) +is currently only exposed on the **kubelet** level. To checkpoint a container, +you can run `curl` on the node where that container is running, and trigger a +checkpoint: + +```shell +curl -X POST "https://localhost:10250/checkpoint/namespace/podId/container" +``` + +For a container named *counter* in a pod named *counters* in a namespace named +*default* the **kubelet** API endpoint is reachable at: + +```shell +curl -X POST "https://localhost:10250/checkpoint/default/counters/counter" +``` + +For completeness the following `curl` command-line options are necessary to +have `curl` accept the *kubelet*'s self signed certificate and authorize the +use of the *kubelet* `checkpoint` API: + +```shell +--insecure --cert /var/run/kubernetes/client-admin.crt --key /var/run/kubernetes/client-admin.key +``` + +Triggering this **kubelet** API will request the creation of a checkpoint from +CRI-O. CRI-O requests a checkpoint from your low-level runtime (for example, +`runc`). Seeing that request, `runc` invokes the `criu` tool +to do the actual checkpointing. + +Once the checkpointing has finished the checkpoint should be available at +`/var/lib/kubelet/checkpoints/checkpoint-_--.tar` + +You could then use that tar archive to restore the container somewhere else. + +### Restore a checkpointed container outside of Kubernetes (with CRI-O) {#restore-checkpointed-container-standalone} + +With the checkpoint tar archive it is possible to restore the container outside +of Kubernetes in a sandboxed instance of CRI-O. For better user experience +during restore, I recommend that you use the latest version of CRI-O from the +*main* CRI-O GitHub branch. If you're using CRI-O v1.25, you'll need to +manually create certain directories Kubernetes would create before starting the +container. + +The first step to restore a container outside of Kubernetes is to create a pod sandbox +using *crictl*: +```shell +crictl runp pod-config.json +``` + +Then you can restore the previously checkpointed container into the newly created pod sandbox: +```shell +crictl create container-config.json pod-config.json +``` + +Instead of specifying a container image in a registry in `container-config.json` +you need to specify the path to the checkpoint archive that you created earlier: +```json +{ + "metadata": { + "name": "counter" + }, + "image":{ + "image": "/var/lib/kubelet/checkpoints/.tar" + } +} +``` + +Next, run `crictl start ` to start that container, and then a +copy of the previously checkpointed container should be running. + +### Restore a checkpointed container within of Kubernetes {#restore-checkpointed-container-k8s} + +To restore the previously checkpointed container directly in Kubernetes it is +necessary to convert the checkpoint archive into an image that can be pushed to +a registry. + +One possible way to convert the local checkpoint archive consists of the +following steps with the help of [buildah](https://buildah.io/): +```shell +newcontainer=$(buildah from scratch) +buildah add $newcontainer /var/lib/kubelet/checkpoints/checkpoint-_--.tar / +buildah config --annotation=io.kubernetes.cri-o.annotations.checkpoint.name= $newcontainer +buildah commit $newcontainer checkpoint-image:latest +buildah rm $newcontainer +``` + +The resulting image is not standardized and only works in combination with +CRI-O. Please consider this image format as pre-alpha. There are ongoing +[discussions][image-spec-discussion] to standardize the format of checkpoint +images like this. Important to remember is that this not yet standardized image +format only works if CRI-O has been started with `--enable-criu-support=true`. +The security implications of starting CRI-O with CRIU support are not yet clear +and therefore the functionality as well as the image format should be used with +care. + +Now, you'll need to push that image to a container image registry. For example: +```shell +buildah push localhost/checkpoint-image:latest container-image-registry.example/user/checkpoint-image:latest +``` + +To restore this checkpoint image (`container-image-registry.example/user/checkpoint-image:latest`), the +image needs to be listed in the specification for a Pod. Here's an example +manifest: +```yaml +apiVersion: v1 +kind: Pod +metadata: + namePrefix: example- +spec: + containers: + - name: + image: container-image-registry.example/user/checkpoint-image:latest + nodeName: +``` + +Kubernetes schedules the new Pod onto a node. The kubelet on that node +instructs the container runtime (CRI-O in this example) to create and start a +container based on an image specified as `registry/user/checkpoint-image:latest`. +CRI-O detects that `registry/user/checkpoint-image:latest` +is a reference to checkpoint data rather than a container image. Then, +instead of the usual steps to create and start a container, +CRI-O fetches the checkpoint data and restores the container from that +specified checkpoint. + +The application in that Pod would continue running as if the checkpoint had not been taken; +within the container, the application looks and behaves like any other container that had been +started normally and not restored from a checkpoint. + +With these steps, it is possible to replace a Pod running on one node +with a new equivalent Pod that is running on a different node, +and without losing the state of the containers in that Pod. + +[image-spec-discussion]: https://github.com/opencontainers/image-spec/issues/962 + +## How do I get involved? +You can reach SIG Node by several means: +- Slack: [#sig-node](https://kubernetes.slack.com/messages/sig-node) +- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node) diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 0d4a0391e3a..b4bd4894726 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -52,20 +52,20 @@ 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) `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: +`v1alpha1` version and a `v1beta1` version, disabled by default, and +(b) `v1beta2` and `v1beta3` 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,flowcontrol.apiserver.k8s.io/v1beta2=false \ +--runtime-config=flowcontrol.apiserver.k8s.io/v1beta2=false,flowcontrol.apiserver.k8s.io/v1beta3=false \ # …and other flags as usual ``` -Alternatively, you can enable the v1alpha1 version of the API group -with `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true`. +Alternatively, you can enable the v1alpha1 and v1beta1 versions of the API group +with `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true,flowcontrol.apiserver.k8s.io/v1beta1=true`. The command-line flag `--enable-priority-and-fairness=false` will disable the API Priority and Fairness feature, even if other flags have enabled it. @@ -89,7 +89,7 @@ Without APF enabled, overall concurrency in the API server is limited by the defined by these flags are summed and then the sum is divided up among a configurable set of _priority levels_. Each incoming request is assigned to a single priority level, and each priority level will only dispatch as many -concurrent requests as its configuration allows. +concurrent requests as its particular limit allows. The default configuration, for example, includes separate priority levels for leader-election requests, requests from built-in controllers, and requests from @@ -97,6 +97,13 @@ Pods. This means that an ill-behaved Pod that floods the API server with requests cannot prevent leader election or actions by the built-in controllers from succeeding. +The concurrency limits of the priority levels are periodically +adjusted, allowing under-utilized priority levels to temporarily lend +concurrency to heavily-utilized levels. These limits are based on +nominal limits and bounds on how much concurrency a priority level may +lend and how much it may borrow, all derived from the configuration +objects mentioned below. + ### Seats Occupied by a Request The above description of concurrency management is the baseline story. @@ -187,15 +194,38 @@ A PriorityLevelConfiguration represents a single priority level. Each PriorityLevelConfiguration has an independent limit on the number of outstanding requests, and limitations on the number of queued requests. -Concurrency limits for PriorityLevelConfigurations are not specified in absolute -number of requests, but rather in "concurrency shares." The total concurrency -limit for the API Server is distributed among the existing -PriorityLevelConfigurations in proportion with these shares. This allows a -cluster administrator to scale up or down the total amount of traffic to a -server by restarting `kube-apiserver` with a different value for -`--max-requests-inflight` (or `--max-mutating-requests-inflight`), and all -PriorityLevelConfigurations will see their maximum allowed concurrency go up (or -down) by the same fraction. +The nominal oncurrency limit for a PriorityLevelConfiguration is not +specified in an absolute number of seats, but rather in "nominal +concurrency shares." The total concurrency limit for the API Server is +distributed among the existing PriorityLevelConfigurations in +proportion to these shares, to give each level its nominal limit in +terms of seats. This allows a cluster administrator to scale up or +down the total amount of traffic to a server by restarting +`kube-apiserver` with a different value for `--max-requests-inflight` +(or `--max-mutating-requests-inflight`), and all +PriorityLevelConfigurations will see their maximum allowed concurrency +go up (or down) by the same fraction. + +{{< caution >}} +In the versions before `v1beta3` the relevant +PriorityLevelConfiguration field is named "assured concurrency shares" +rather than "nominal concurrency shares". Also, in Kubernetes release +1.25 and earlier there were no periodic adjustments: the +nominal/assured limits were always applied without adjustment. +{{< /caution >}} + +The bounds on how much concurrency a priority level may lend and how +much it may borrow are expressed in the PriorityLevelConfiguration as +percentages of the level's nominal limit. These are resolved to +absolute numbers of seats by multiplying with the nominal limit / +100.0 and rounding. The dynamically adjusted concurrency limit of a +priority level is constrained to lie between (a) a lower bound of its +nominal limit minus its lendable seats and (b) an upper bound of its +nominal limit plus the seats it may borrow. At each adjustment the +dynamic limits are derived by each priority level reclaiming any lent +seats for which demand recently appeared and then jointly fairly +responding to the recent seat demand on the priority levels, within +the bounds just described. {{< caution >}} With the Priority and Fairness feature enabled, the total concurrency limit for @@ -606,10 +636,55 @@ poorly-behaved workloads that may be harming system health. to increase that PriorityLevelConfiguration's concurrency shares. {{< /note >}} -* `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector - holding the computed concurrency limit (based on the API server's - total concurrency limit and PriorityLevelConfigurations' concurrency - shares), broken down by the label `priority_level`. +* `apiserver_flowcontrol_request_concurrency_limit` is the same as + `apiserver_flowcontrol_nominal_limit_seats`. Before the + introduction of concurrency borrowing between priority levels, this + was always equal to `apiserver_flowcontrol_current_limit_seats` + (which did not exist as a distinct metric). + +* `apiserver_flowcontrol_nominal_limit_seats` is a gauge vector + holding each priority level's nominal concurrency limit, computed + from the API server's total concurrency limit and the priority + level's configured nominal concurrency shares. + +* `apiserver_flowcontrol_lower_limit_seats` is a gauge vector holding + the lower bound on each priority level's dynamic concurrency limit. + +* `apiserver_flowcontrol_upper_limit_seats` is a gauge vector holding + the upper bound on each priority level's dynamic concurrency limit. + +* `apiserver_flowcontrol_demand_seats` is a histogram vector counting + observations, at the end of every nanosecond, of each priority + level's ratio of (seat demand) / (nominal concurrency limit). A + priority level's seat demand is the sum, over both queued requests + and those in the initial phase of execution, of the maximum of the + number of seats occupied in the request's initial and final + execution phases. + +* `apiserver_flowcontrol_demand_seats_high_watermark` is a gauge vector + holding, for each priority level, the maximum seat demand seen + during the last concurrency borrowing adjustment period. + +* `apiserver_flowcontrol_demand_seats_average` is a gauge vector + holding, for each priority level, the time-weighted average seat + demand seen during the last concurrency borrowing adjustment period. + +* `apiserver_flowcontrol_demand_seats_stdev` is a gauge vector + holding, for each priority level, the time-weighted population + standard deviation of seat demand seen during the last concurrency + borrowing adjustment period. + +* `apiserver_flowcontrol_target_seats` is a gauge vector holding, for + each priority level, the concurrency target going into the borrowing + allocation problem. + +* `apiserver_flowcontrol_seat_fair_frac` is a gauge holding the fair + allocation fraction determined in the last borrowing adjustment. + +* `apiserver_flowcontrol_current_limit_seats` is a gauge vector + holding, for each priority level, the dynamic concurrency limit + derived in the last adjustment. + * `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram vector of how long requests spent queued, broken down by the labels diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 8d9490b8289..3adab67be31 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -39,6 +39,18 @@ Resource quotas work like this: See the [walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) for an example of how to avoid this problem. +{{< note >}} +- For `cpu` and `memory` resources, ResourceQuotas enforce that **every** +(new) pod in that namespace sets a limit for that resource. +If you enforce a resource quota in a namespace for either `cpu` or `memory`, +you, and other clients, **must** specify either `requests` or `limits` for that resource, +for every new Pod you submit. If you don't, the control plane may reject admission +for that Pod. +- For other resources: ResourceQuota works and will ignore pods in the namespace without setting a limit or request for that resource. It means that you can create a new pod without limit/request ephemeral storage if the resource quota limits the ephemeral storage of this namespace. +You can use a [LimitRange](/docs/concepts/policy/limit-range/) to automatically set +a default request for these resources. +{{< /note >}} + The name of a ResourceQuota object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index 9cd70f9e976..c88274eb0b5 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -2,7 +2,7 @@ reviewers: - davidopp - kevin-wangzefeng -- bsalamat +- alculquicondor title: Assigning Pods to Nodes content_type: concept weight: 20 @@ -144,13 +144,13 @@ to repel Pods from specific nodes. If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the Pod to be scheduled onto a node. -If you specify multiple `nodeSelectorTerms` associated with `nodeAffinity` -types, then the Pod can be scheduled onto a node if one of the specified `nodeSelectorTerms` can be -satisfied. +If you specify multiple terms in `nodeSelectorTerms` associated with `nodeAffinity` +types, then the Pod can be scheduled onto a node if one of the specified terms +can be satisfied (terms are ORed). -If you specify multiple `matchExpressions` associated with a single `nodeSelectorTerms`, -then the Pod can be scheduled onto a node only if all the `matchExpressions` are -satisfied. +If you specify multiple expressions in a single `matchExpressions` field associated with a +term in `nodeSelectorTerms`, then the Pod can be scheduled onto a node only +if all the expressions are satisfied (expressions are ANDed). {{}} See [Assign Pods to Nodes using Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/) diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md index 09d20a35979..5e84c43bdd7 100644 --- a/content/en/docs/concepts/services-networking/endpoint-slices.md +++ b/content/en/docs/concepts/services-networking/endpoint-slices.md @@ -233,11 +233,12 @@ different EndpointSlice objects can arrive at the Kubernetes client watch / cach at different times. {{< note >}} -Clients of the EndpointSlice API must be able to handle the situation where -a particular endpoint address appears in more than one slice. +Clients of the EndpointSlice API must iterate through all the existing EndpointSlices +associated to a Service and build a complete list of unique network endpoints. It is +important to mention that endpoints may be duplicated in different EndointSlices. -You can find a reference implementation for how to perform this endpoint deduplication -as part of the `EndpointSliceCache` code within `kube-proxy`. +You can find a reference implementation for how to perform this endpoint aggregation +and deduplication as part of the `EndpointSliceCache` code within `kube-proxy`. {{< /note >}} ## Comparison with Endpoints {#motivation} diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 366a94264c0..0c9e5c1df36 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -101,7 +101,7 @@ Each HTTP rule contains the following information: Service. * A backend is a combination of Service and port names as described in the [Service doc](/docs/concepts/services-networking/service/) or a [custom resource backend](#resource-backend) by way of a {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}}. HTTP (and HTTPS) requests to the - Ingress that matches the host and path of the rule are sent to the listed backend. + Ingress that match the host and path of the rule are sent to the listed backend. A `defaultBackend` is often configured in an Ingress controller to service any requests that do not match a path in the spec. diff --git a/content/en/docs/concepts/services-networking/service-topology.md b/content/en/docs/concepts/services-networking/service-topology.md index 3778bb40356..b833ff6e3b0 100644 --- a/content/en/docs/concepts/services-networking/service-topology.md +++ b/content/en/docs/concepts/services-networking/service-topology.md @@ -18,7 +18,6 @@ This feature, specifically the alpha `topologyKeys` API, is deprecated since Kubernetes v1.21. [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/), introduced in Kubernetes v1.21, provide similar functionality. - {{}} _Service Topology_ enables a service to route traffic based upon the Node @@ -194,12 +193,7 @@ spec: - "*" ``` - - - ## {{% heading "whatsnext" %}} - -* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology) +* Read about [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/) * Read [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) - diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 8e47d534ede..9bd08bc8ac6 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -145,14 +145,16 @@ spec: targetPort: http-web-svc ``` + This works even if there is a mixture of Pods in the Service using a single configured name, with the same network protocol available via different port numbers. This offers a lot of flexibility for deploying and evolving your Services. For example, you can change the port numbers that Pods expose in the next version of your backend software, without breaking clients. -The default protocol for Services is TCP; you can also use any other -[supported protocol](#protocol-support). +The default protocol for Services is +[TCP](/docs/reference/networking/service-protocols/#protocol-tcp); you can also +use any other [supported protocol](/docs/reference/networking/service-protocols/). As many Services need to expose more than one port, Kubernetes supports multiple port definitions on a Service object. @@ -316,150 +318,6 @@ This field follows standard Kubernetes label syntax. Values should either be [IANA standard service names](https://www.iana.org/assignments/service-names) or domain prefixed names such as `mycompany.com/my-custom-protocol`. -## Virtual IPs and service proxies - -Every node in a Kubernetes cluster runs a `kube-proxy`. `kube-proxy` is -responsible for implementing a form of virtual IP for `Services` of type other -than [`ExternalName`](#externalname). - -### Why not use round-robin DNS? - -A question that pops up every now and then is why Kubernetes relies on -proxying to forward inbound traffic to backends. What about other -approaches? For example, would it be possible to configure DNS records that -have multiple A values (or AAAA for IPv6), and rely on round-robin name -resolution? - -There are a few reasons for using proxying for Services: - -* There is a long history of DNS implementations not respecting record TTLs, - and caching the results of name lookups after they should have expired. -* Some apps do DNS lookups only once and cache the results indefinitely. -* Even if apps and libraries did proper re-resolution, the low or zero TTLs - on the DNS records could impose a high load on DNS that then becomes - difficult to manage. - -Later in this page you can read about how various kube-proxy implementations work. Overall, -you should note that, when running `kube-proxy`, kernel level rules may be -modified (for example, iptables rules might get created), which won't get cleaned up, -in some cases until you reboot. Thus, running kube-proxy is something that should -only be done by an administrator which understands the consequences of having a -low level, privileged network proxying service on a computer. Although the `kube-proxy` -executable supports a `cleanup` function, this function is not an official feature and -thus is only available to use as-is. - -### Configuration - -Note that the kube-proxy starts up in different modes, which are determined by its configuration. -- The kube-proxy's configuration is done via a ConfigMap, and the ConfigMap for kube-proxy - effectively deprecates the behavior for almost all of the flags for the kube-proxy. -- The ConfigMap for the kube-proxy does not support live reloading of configuration. -- The ConfigMap parameters for the kube-proxy cannot all be validated and verified on startup. - For example, if your operating system doesn't allow you to run iptables commands, - the standard kernel kube-proxy implementation will not work. - Likewise, if you have an operating system which doesn't support `netsh`, - it will not run in Windows userspace mode. - -### User space proxy mode {#proxy-mode-userspace} - -In this (legacy) mode, kube-proxy watches the Kubernetes control plane for the addition and -removal of Service and Endpoint objects. For each Service it opens a -port (randomly chosen) on the local node. Any connections to this "proxy port" -are proxied to one of the Service's backend Pods (as reported via -Endpoints). kube-proxy takes the `SessionAffinity` setting of the Service into -account when deciding which backend Pod to use. - -Lastly, the user-space proxy installs iptables rules which capture traffic to -the Service's `clusterIP` (which is virtual) and `port`. The rules -redirect that traffic to the proxy port which proxies the backend Pod. - -By default, kube-proxy in userspace mode chooses a backend via a round-robin algorithm. - -![Services overview diagram for userspace proxy](/images/docs/services-userspace-overview.svg) - -### `iptables` proxy mode {#proxy-mode-iptables} - -In this mode, kube-proxy watches the Kubernetes control plane for the addition and -removal of Service and Endpoint objects. For each Service, it installs -iptables rules, which capture traffic to the Service's `clusterIP` and `port`, -and redirect that traffic to one of the Service's -backend sets. For each Endpoint object, it installs iptables rules which -select a backend Pod. - -By default, kube-proxy in iptables mode chooses a backend at random. - -Using iptables to handle traffic has a lower system overhead, because traffic -is handled by Linux netfilter without the need to switch between userspace and the -kernel space. This approach is also likely to be more reliable. - -If kube-proxy is running in iptables mode and the first Pod that's selected -does not respond, the connection fails. This is different from userspace -mode: in that scenario, kube-proxy would detect that the connection to the first -Pod had failed and would automatically retry with a different backend Pod. - -You can use Pod [readiness probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) -to verify that backend Pods are working OK, so that kube-proxy in iptables mode -only sees backends that test out as healthy. Doing this means you avoid -having traffic sent via kube-proxy to a Pod that's known to have failed. - -![Services overview diagram for iptables proxy](/images/docs/services-iptables-overview.svg) - -### IPVS proxy mode {#proxy-mode-ipvs} - -{{< feature-state for_k8s_version="v1.11" state="stable" >}} - -In `ipvs` mode, kube-proxy watches Kubernetes Services and Endpoints, -calls `netlink` interface to create IPVS rules accordingly and synchronizes -IPVS rules with Kubernetes Services and Endpoints periodically. -This control loop ensures that IPVS status matches the desired -state. -When accessing a Service, IPVS directs traffic to one of the backend Pods. - -The IPVS proxy mode is based on netfilter hook function that is similar to -iptables mode, but uses a hash table as the underlying data structure and works -in the kernel space. -That means kube-proxy in IPVS mode redirects traffic with lower latency than -kube-proxy in iptables mode, with much better performance when synchronizing -proxy rules. Compared to the other proxy modes, IPVS mode also supports a -higher throughput of network traffic. - -IPVS provides more options for balancing traffic to backend Pods; -these are: - -* `rr`: round-robin -* `lc`: least connection (smallest number of open connections) -* `dh`: destination hashing -* `sh`: source hashing -* `sed`: shortest expected delay -* `nq`: never queue - -{{< note >}} -To run kube-proxy in IPVS mode, you must make IPVS available on -the node before starting kube-proxy. - -When kube-proxy starts in IPVS proxy mode, it verifies whether IPVS -kernel modules are available. If the IPVS kernel modules are not detected, then kube-proxy -falls back to running in iptables proxy mode. -{{< /note >}} - -![Services overview diagram for IPVS proxy](/images/docs/services-ipvs-overview.svg) - -In these proxy models, the traffic bound for the Service's IP:Port is -proxied to an appropriate backend without the clients knowing anything -about Kubernetes or Services or Pods. - -If you want to make sure that connections from a particular client -are passed to the same Pod each time, you can select the session affinity based -on the client's IP addresses by setting `service.spec.sessionAffinity` to "ClientIP" -(the default is "None"). -You can also set the maximum session sticky time by setting -`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately. -(the default value is 10800, which works out to be 3 hours). - -{{< note >}} -On Windows, setting the maximum session sticky time for Services is not supported. -{{< /note >}} - ## Multi-Port Services For some Services, you need to expose more than one port. @@ -507,46 +365,6 @@ The IP address that you choose must be a valid IPv4 or IPv6 address from within If you try to create a Service with an invalid clusterIP address value, the API server will return a 422 HTTP status code to indicate that there's a problem. -## Traffic policies - -### External traffic policy - -You can set the `spec.externalTrafficPolicy` field to control how traffic from external sources is routed. -Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route external traffic to all ready endpoints -and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are no node-local -endpoints, the kube-proxy does not forward any traffic for the relevant Service. - -### Internal traffic policy - -{{< feature-state for_k8s_version="v1.22" state="beta" >}} - -You can set the `spec.internalTrafficPolicy` field to control how traffic from internal sources is routed. -Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route internal traffic to all ready endpoints -and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are no node-local -endpoints, traffic is dropped by kube-proxy. - -### Traffic to Terminating Endpoints - -{{< feature-state for_k8s_version="v1.26" state="beta" >}} - -If the `ProxyTerminatingEndpoints` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) -is enabled in kube-proxy and the traffic policy is `Local`, that node's -kube-proxy uses a more complicated algorithm to select endpoints for a Service. -With the feature enabled, kube-proxy checks if the node -has local endpoints and whether or not all the local endpoints are marked as terminating. -If there are local endpoints and **all** of them are terminating, then kube-proxy -will forward traffic to those terminating endpoints. Otherwise, kube-proxy will always -prefer forwarding traffic to endpoints that are not terminating. - -This forwarding behavior for terminating endpoints exist to allow `NodePort` and `LoadBalancer` Services to -gracefully drain connections when using `externalTrafficPolicy=Local`. As a deployment goes through -a rolling update, nodes backing a loadbalancer may transition from N to 0 replicas of that deployment. -In some cases, external load balancers can send traffic to a node with 0 replicas in between health check probes. -Routing traffic to terminating endpoints ensures that Node's that are scaling down Pods can gracefully receive -and drain traffic to those terminating Pods. By the time the Pod completes termination, the external load balancer -should have seen the node's health check failing and fully removed the node from the backend pool. - ## Discovering services Kubernetes supports 2 primary modes of finding a Service - environment @@ -672,6 +490,12 @@ Kubernetes `ServiceTypes` allow you to specify what kind of Service you want. to use the `ExternalName` type. {{< /note >}} +The `type` field was designed as nested functionality - each level adds to the +previous. This is not strictly required on all cloud providers (for example: Google +Compute Engine does not need to allocate a node port to make `type: LoadBalancer` work, +but another cloud provider integration might do). Although strict nesting is not required, +but the Kubernetes API design for Service requires it anyway. + You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple @@ -799,6 +623,7 @@ _As an alpha feature_, you can configure a load balanced Service to [omit](#load-balancer-nodeport-allocation) assigning a node port, provided that the cloud provider implementation supports this. + {{< note >}} On **Azure**, if you want to use a user-specified public type `loadBalancerIP`, you first need @@ -816,9 +641,14 @@ or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https:// #### Load balancers with mixed protocol types -{{< feature-state for_k8s_version="v1.26" state="stable" >}} +{{< feature-state for_k8s_version="v1.24" state="beta" >}} -You can use different protocols for LoadBalancer type of Services, when there is more than one port defined. +By default, for LoadBalancer type of Services, when there is more than one port defined, all +ports must have the same protocol, and the protocol must be one which is supported +by the cloud provider. + +The feature gate `MixedProtocolLBService` (enabled by default for the kube-apiserver as of v1.24) allows the use of +different protocols for LoadBalancer type of Services, when there is more than one port defined. {{< note >}} @@ -1353,201 +1183,34 @@ spec: - 80.11.12.10 ``` -## Shortcomings +## Session stickiness -Using the userspace proxy for VIPs works at small to medium scale, but will -not scale to very large clusters with thousands of Services. The -[original design proposal for portals](https://github.com/kubernetes/kubernetes/issues/1107) -has more details on this. - -Using the userspace proxy obscures the source IP address of a packet accessing -a Service. -This makes some kinds of network filtering (firewalling) impossible. The iptables -proxy mode does not -obscure in-cluster source IPs, but it does still impact clients coming through -a load balancer or node-port. - -The `Type` field is designed as nested functionality - each level adds to the -previous. This is not strictly required on all cloud providers (e.g. Google Compute Engine does -not need to allocate a `NodePort` to make `LoadBalancer` work, but AWS does) -but the Kubernetes API design for Service requires it anyway. - -## Virtual IP implementation {#the-gory-details-of-virtual-ips} - -The previous information should be sufficient for many people who want to -use Services. However, there is a lot going on behind the scenes that may be -worth understanding. - -### Avoiding collisions - -One of the primary philosophies of Kubernetes is that you should not be -exposed to situations that could cause your actions to fail through no fault -of your own. For the design of the Service resource, this means not making -you choose your own port number if that choice might collide with -someone else's choice. That is an isolation failure. - -In order to allow you to choose a port number for your Services, we must -ensure that no two Services can collide. Kubernetes does that by allocating each -Service its own IP address from within the `service-cluster-ip-range` -CIDR range that is configured for the API server. - -To ensure each Service receives a unique IP, an internal allocator atomically -updates a global allocation map in {{< glossary_tooltip term_id="etcd" >}} -prior to creating each Service. The map object must exist in the registry for -Services to get IP address assignments, otherwise creations will -fail with a message indicating an IP address could not be allocated. - -In the control plane, a background controller is responsible for creating that -map (needed to support migrating from older versions of Kubernetes that used -in-memory locking). Kubernetes also uses controllers to check for invalid -assignments (e.g. due to administrator intervention) and for cleaning up allocated -IP addresses that are no longer used by any Services. - -Services are using an [allocation strategy](/docs/concepts/services-networking/cluster-ip-allocation/) that divides the `ClusterIP` range into two bands, based on -the size of the configured `service-cluster-ip-range` by using the following formula -`min(max(16, cidrSize / 16), 256)`, described as _never less than 16 or more than 256, -with a graduated step function between them_. Dynamic IP allocations will be preferentially -chosen from the upper band, reducing risks of conflicts with the IPs -assigned from the lower band. -This allows users to use the lower band of the `service-cluster-ip-range` for their -Services with static IPs assigned with a very low risk of running into conflicts. - -### Service IP addresses {#ips-and-vips} - -Unlike Pod IP addresses, which actually route to a fixed destination, -Service IPs are not actually answered by a single host. Instead, kube-proxy -uses iptables (packet processing logic in Linux) to define _virtual_ IP addresses -which are transparently redirected as needed. When clients connect to the -VIP, their traffic is automatically transported to an appropriate endpoint. -The environment variables and DNS for Services are actually populated in -terms of the Service's virtual IP address (and port). - -kube-proxy supports three proxy modes—userspace, iptables and IPVS—which -each operate slightly differently. - -#### Userspace - -As an example, consider the image processing application described above. -When the backend Service is created, the Kubernetes master assigns a virtual -IP address, for example 10.0.0.1. Assuming the Service port is 1234, the -Service is observed by all of the kube-proxy instances in the cluster. -When a proxy sees a new Service, it opens a new random port, establishes an -iptables redirect from the virtual IP address to this new port, and starts accepting -connections on it. - -When a client connects to the Service's virtual IP address, the iptables -rule kicks in, and redirects the packets to the proxy's own port. -The "Service proxy" chooses a backend, and starts proxying traffic from the client to the backend. - -This means that Service owners can choose any port they want without risk of -collision. Clients can connect to an IP and port, without being aware -of which Pods they are actually accessing. - -#### iptables - -Again, consider the image processing application described above. -When the backend Service is created, the Kubernetes control plane assigns a virtual -IP address, for example 10.0.0.1. Assuming the Service port is 1234, the -Service is observed by all of the kube-proxy instances in the cluster. -When a proxy sees a new Service, it installs a series of iptables rules which -redirect from the virtual IP address to per-Service rules. The per-Service -rules link to per-Endpoint rules which redirect traffic (using destination NAT) -to the backends. - -When a client connects to the Service's virtual IP address the iptables rule kicks in. -A backend is chosen (either based on session affinity or randomly) and packets are -redirected to the backend. Unlike the userspace proxy, packets are never -copied to userspace, the kube-proxy does not have to be running for the virtual -IP address to work, and Nodes see traffic arriving from the unaltered client IP -address. - -This same basic flow executes when traffic comes in through a node-port or -through a load-balancer, though in those cases the client IP does get altered. - -#### IPVS - -iptables operations slow down dramatically in large scale cluster e.g. 10,000 Services. -IPVS is designed for load balancing and based on in-kernel hash tables. -So you can achieve performance consistency in large number of Services from IPVS-based kube-proxy. -Meanwhile, IPVS-based kube-proxy has more sophisticated load balancing algorithms -(least conns, locality, weighted, persistence). +If you want to make sure that connections from a particular client are passed to +the same Pod each time, you can configure session affinity based on the client's +IP address. Read [session affinity](/docs/reference/networking/virtual-ips/#session-affinity) +to learn more. ## API Object Service is a top-level resource in the Kubernetes REST API. You can find more details about the [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). -## Supported protocols {#protocol-support} + + -### TCP +## Virtual IP addressing mechanism -You can use TCP for any kind of Service, and it's the default network protocol. - -### UDP - -You can use UDP for most Services. For type=LoadBalancer Services, UDP support -depends on the cloud provider offering this facility. - -### SCTP - -{{< feature-state for_k8s_version="v1.20" state="stable" >}} - -When using a network plugin that supports SCTP traffic, you can use SCTP for -most Services. For type=LoadBalancer Services, SCTP support depends on the cloud -provider offering this facility. (Most do not). - -#### Warnings {#caveat-sctp-overview} - -##### Support for multihomed SCTP associations {#caveat-sctp-multihomed} - -{{< warning >}} -The support of multihomed SCTP associations requires that the CNI plugin can support the -assignment of multiple interfaces and IP addresses to a Pod. - -NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules. -{{< /warning >}} - -##### Windows {#caveat-sctp-windows-os} - -{{< note >}} -SCTP is not supported on Windows based nodes. -{{< /note >}} - -##### Userspace kube-proxy {#caveat-sctp-kube-proxy-userspace} - -{{< warning >}} -The kube-proxy does not support the management of SCTP associations when it is in userspace mode. -{{< /warning >}} - -### HTTP - -If your cloud provider supports it, you can use a Service in LoadBalancer mode -to set up external HTTP / HTTPS reverse proxying, forwarded to the Endpoints -of the Service. - -{{< note >}} -You can also use {{< glossary_tooltip term_id="ingress" >}} in place of Service -to expose HTTP/HTTPS Services. -{{< /note >}} - -### PROXY protocol - -If your cloud provider supports it, -you can use a Service in LoadBalancer mode to configure a load balancer outside -of Kubernetes itself, that will forward connections prefixed with -[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). - -The load balancer will send an initial series of octets describing the -incoming connection, similar to this example - -``` -PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n -``` - -followed by the data from the client. +Read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) to learn about the +mechanism Kubernetes provides to expose a Service with a virtual IP address. ## {{% heading "whatsnext" %}} * Follow the [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) tutorial * Read about [Ingress](/docs/concepts/services-networking/ingress/) * Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) + +For more context: +* Read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) +* Read the [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API +* Read the [API reference](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) for the Endpoints API +* Read the [API reference](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) for the EndpointSlice API diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 441fd635715..9a69ed9b8ae 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -45,8 +45,8 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up In this example: * A Deployment named `nginx-deployment` is created, indicated by the `.metadata.name` field. -* The Deployment creates three replicated Pods, indicated by the `.spec.replicas` field. -* The `.spec.selector` field defines how the Deployment finds which Pods to manage. +* The Deployment creates a ReplicaSet that creates three replicated Pods, indicated by the `.spec.replicas` field. +* The `.spec.selector` field defines how the created ReplicaSet finds which Pods to manage. In this case, you select a label that is defined in the Pod template (`app: nginx`). However, more sophisticated selection rules are possible, as long as the Pod template itself satisfies the rule. diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 2e79726c96a..08855b8b08e 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -264,7 +264,8 @@ Jobs with _fixed completion count_ - that is, jobs that have non null - As part of the Pod hostname, following the pattern `$(job-name)-$(index)`. When you use an Indexed Job in combination with a {{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use - the deterministic hostnames to address each other via DNS. + the deterministic hostnames to address each other via DNS. For more information about + how to configure this, see [Job with Pod-to-Pod Communication](/docs/tasks/job/job-with-pod-to-pod-communication/). - From the containerized task, in the environment variable `JOB_COMPLETION_INDEX`. The Job is considered complete when there is one successfully completed Pod @@ -475,12 +476,13 @@ The tradeoffs are: The tradeoffs are summarized here, with columns 2 to 4 corresponding to the above tradeoffs. The pattern names are also links to examples and more detailed description. -| Pattern | Single Job object | Fewer pods than work items? | Use app unmodified? | -| ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:| -| [Queue with Pod Per Work Item] | ✓ | | sometimes | -| [Queue with Variable Pod Count] | ✓ | ✓ | | -| [Indexed Job with Static Work Assignment] | ✓ | | ✓ | -| [Job Template Expansion] | | | ✓ | +| Pattern | Single Job object | Fewer pods than work items? | Use app unmodified? | +| ----------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:| +| [Queue with Pod Per Work Item] | ✓ | | sometimes | +| [Queue with Variable Pod Count] | ✓ | ✓ | | +| [Indexed Job with Static Work Assignment] | ✓ | | ✓ | +| [Job Template Expansion] | | | ✓ | +| [Job with Pod-to-Pod Communication] | ✓ | sometimes | sometimes | When you specify completions with `.spec.completions`, each Pod created by the Job controller has an identical [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). This means that @@ -491,17 +493,19 @@ are different ways to arrange for pods to work on different things. This table shows the required settings for `.spec.parallelism` and `.spec.completions` for each of the patterns. Here, `W` is the number of work items. -| Pattern | `.spec.completions` | `.spec.parallelism` | -| ----------------------------------------- |:-------------------:|:--------------------:| -| [Queue with Pod Per Work Item] | W | any | -| [Queue with Variable Pod Count] | null | any | -| [Indexed Job with Static Work Assignment] | W | any | -| [Job Template Expansion] | 1 | should be 1 | +| Pattern | `.spec.completions` | `.spec.parallelism` | +| ----------------------------------------------- |:-------------------:|:--------------------:| +| [Queue with Pod Per Work Item] | W | any | +| [Queue with Variable Pod Count] | null | any | +| [Indexed Job with Static Work Assignment] | W | any | +| [Job Template Expansion] | 1 | should be 1 | +| [Job with Pod-to-Pod Communication] | W | W | [Queue with Pod Per Work Item]: /docs/tasks/job/coarse-parallel-processing-work-queue/ [Queue with Variable Pod Count]: /docs/tasks/job/fine-parallel-processing-work-queue/ [Indexed Job with Static Work Assignment]: /docs/tasks/job/indexed-parallel-processing-static/ [Job Template Expansion]: /docs/tasks/job/parallel-processing-expansion/ +[Job with Pod-to-Pod Communication]: /docs/tasks/job/job-with-pod-to-pod-communication/ ## Advanced usage diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md index 6a6da8655a9..c2acd154c0b 100644 --- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -268,7 +268,7 @@ The certificate value is in Base64-encoded format under `status.certificate`. Export the issued certificate from the CertificateSigningRequest. -``` +```shell kubectl get csr myuser -o jsonpath='{.status.certificate}'| base64 -d > myuser.crt ``` @@ -295,20 +295,20 @@ The last step is to add this user into the kubeconfig file. First, you need to add new credentials: -``` +```shell kubectl config set-credentials myuser --client-key=myuser.key --client-certificate=myuser.crt --embed-certs=true ``` Then, you need to add the context: -``` +```shell kubectl config set-context myuser --cluster=kubernetes --user=myuser ``` To test it, change the context to `myuser`: -``` +```shell kubectl config use-context myuser ``` diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index fdcbd44afbf..aa5ec669b12 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -317,6 +317,12 @@ objects with an `aggregationRule` set. The `aggregationRule` defines a label uses to match other ClusterRole objects that should be combined into the `rules` field of this one. +{{< caution >}} +The control plane overwrites any values that you manually specify in the `rules` field of an +aggregate ClusterRole. If you want to change or add rules, do so in the `ClusterRole` objects +that are selected by the `aggregationRule`. +{{< /caution >}} + Here is an example aggregated ClusterRole: ```yaml diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates-removed.md b/content/en/docs/reference/command-line-tools-reference/feature-gates-removed.md index e1a3b9b9365..26f6663e902 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates-removed.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates-removed.md @@ -204,7 +204,7 @@ In the following table: | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | 1.18 | | `RootCAConfigMap` | `false` | Alpha | 1.13 | 1.19 | | `RootCAConfigMap` | `true` | Beta | 1.20 | 1.20 | -| `RootCAConfigMap` | `true` | GA | 1.21 | 1.12 | +| `RootCAConfigMap` | `true` | GA | 1.21 | 1.22 | | `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | 1.18 | | `RotateKubeletClientCertificate` | `true` | GA | 1.19 | 1.21 | | `RunAsGroup` | `true` | Beta | 1.14 | 1.20 | 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 bc7a023a156..d06eb78fbca 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 @@ -74,12 +74,12 @@ For a reference to old feature gates that are removed, please refer to | `CPUManagerPolicyBetaOptions` | `true` | Beta | 1.23 | | | `CPUManagerPolicyOptions` | `false` | Alpha | 1.22 | 1.22 | | `CPUManagerPolicyOptions` | `true` | Beta | 1.23 | | -| `CrossNamespaceVolumeDataSource` | `false` | Alpha| 1.26 | | | `CSIMigrationPortworx` | `false` | Alpha | 1.23 | 1.24 | | `CSIMigrationPortworx` | `false` | Beta | 1.25 | | | `CSIMigrationRBD` | `false` | Alpha | 1.23 | | | `CSINodeExpandSecret` | `false` | Alpha | 1.25 | | | `CSIVolumeHealth` | `false` | Alpha | 1.21 | | +| `CrossNamespaceVolumeDataSource` | `false` | Alpha| 1.26 | | | `ContainerCheckpoint` | `false` | Alpha | 1.25 | | | `ContextualLogging` | `false` | Alpha | 1.24 | | | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | | @@ -118,6 +118,10 @@ For a reference to old feature gates that are removed, please refer to | `JobPodFailurePolicy` | `true` | Beta | 1.26 | | | `JobReadyPods` | `false` | Alpha | 1.23 | 1.23 | | `JobReadyPods` | `true` | Beta | 1.24 | | +| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | 1.22 | +| `JobTrackingWithFinalizers` | `false` | Beta | 1.23 | 1.24 | +| `JobTrackingWithFinalizers` | `true` | Beta | 1.25 | | +| `KMSv2` | `false` | Alpha | 1.25 | | | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | 1.23 | | `KubeletCredentialProviders` | `true` | Beta | 1.24 | | | `KubeletInUserNamespace` | `false` | Alpha | 1.22 | | @@ -615,6 +619,7 @@ Each feature gate is designed for enabling/disabling a specific feature: completions without relying on Pods remaining in the cluster indefinitely. The Job controller uses Pod finalizers and a field in the Job status to keep track of the finished Pods to count towards completion. +- `KMSv2`: Enables KMS v2 API for encryption at rest. See [Using a KMS Provider for data encryption](/docs/tasks/administer-cluster/kms-provider) for more details. - `KubeletCredentialProviders`: Enable kubelet exec credential providers for image pull credentials. - `KubeletInUserNamespace`: Enables support for running kubelet in a diff --git a/content/en/docs/reference/instrumentation/metrics.md b/content/en/docs/reference/instrumentation/metrics.md index 682a4161f47..196c9b97d3e 100644 --- a/content/en/docs/reference/instrumentation/metrics.md +++ b/content/en/docs/reference/instrumentation/metrics.md @@ -5,10 +5,9 @@ description: >- Details of the metric data that Kubernetes components export. --- -## Metrics (v1.26) - - +## Metrics (auto-generated 2022 Nov 01) + This page details the metrics that different Kubernetes components export. You can query the metrics endpoint for these components using an HTTP scrape, and fetch the current metrics data in Prometheus format. @@ -23,7 +22,6 @@ components using an HTTP scrape, and fetch the current metrics data in Prometheu Help Labels Const Labels - Deprecated Version @@ -33,176 +31,121 @@ components using an HTTP scrape, and fetch the current metrics data in Prometheu Histogram Admission controller latency histogram in seconds, identified by name and broken out for each operation and API resource and type (validate or admit).
name
operation
rejected
type
- - +None apiserver_admission_step_admission_duration_seconds STABLE Histogram Admission sub-step latency histogram in seconds, broken out for each operation and API resource and step type (validate or admit).
operation
rejected
type
- - +None apiserver_admission_webhook_admission_duration_seconds STABLE Histogram Admission webhook latency histogram in seconds, identified by name and broken out for each operation and API resource and type (validate or admit).
name
operation
rejected
type
- - +None apiserver_current_inflight_requests STABLE Gauge Maximal number of currently used inflight request limit of this apiserver per request kind in last second.
request_kind
- - +None apiserver_longrunning_requests STABLE Gauge Gauge of all active long-running apiserver requests broken out by verb, group, version, resource, scope and component. Not all requests are tracked this way.
component
group
resource
scope
subresource
verb
version
- - +None apiserver_request_duration_seconds STABLE Histogram Response latency distribution in seconds for each verb, dry run value, group, version, resource, subresource, scope and component.
component
dry_run
group
resource
scope
subresource
verb
version
- - +None apiserver_request_total STABLE Counter Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code.
code
component
dry_run
group
resource
scope
subresource
verb
version
- - +None apiserver_requested_deprecated_apis STABLE Gauge Gauge of deprecated APIs that have been requested, broken out by API group, version, resource, subresource, and removed_release.
group
removed_release
resource
subresource
version
- - +None apiserver_response_sizes STABLE Histogram Response size distribution in bytes for each group, version, verb, resource, subresource, scope and component.
component
group
resource
scope
subresource
verb
version
- - +None apiserver_storage_objects STABLE Gauge Number of stored objects at the time of last check split by kind.
resource
- - -cronjob_controller_job_creation_skew_duration_seconds -STABLE -Histogram -Time between when a cronjob is scheduled to be run, and when the corresponding job is created - - - -job_controller_job_pods_finished_total -STABLE -Counter -The number of finished Pods that are fully tracked -
completion_mode
result
- - -job_controller_job_sync_duration_seconds -STABLE -Histogram -The time it took to sync a job -
action
completion_mode
result
- - -job_controller_job_syncs_total -STABLE -Counter -The number of job syncs -
action
completion_mode
result
- - -job_controller_jobs_finished_total -STABLE -Counter -The number of finished jobs -
completion_mode
reason
result
- - +None node_collector_evictions_total STABLE Counter Number of Node evictions that happened since current instance of NodeController started.
zone
- - +None scheduler_framework_extension_point_duration_seconds STABLE Histogram Latency for running all plugins of a specific extension point.
extension_point
profile
status
- - +None scheduler_pending_pods STABLE Gauge -Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulablePods that the scheduler attempted to schedule and failed; 'gated' is the number of unschedulable pods that the scheduler never attempted to schedule because they are gated. +Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulablePods.
queue
- - +None scheduler_pod_scheduling_attempts STABLE Histogram Number of attempts to successfully schedule a pod. - - - +None +None scheduler_pod_scheduling_duration_seconds STABLE Histogram E2e latency for a pod being scheduled which may include multiple scheduling attempts.
attempts
- - +None scheduler_preemption_attempts_total STABLE Counter Total preemption attempts in the cluster till now - - - +None +None scheduler_preemption_victims STABLE Histogram Number of selected preemption victims - - - +None +None scheduler_queue_incoming_pods_total STABLE Counter Number of pods added to scheduling queues by event and queue type.
event
queue
- - +None scheduler_schedule_attempts_total STABLE Counter Number of attempts to schedule pods, by the result. 'unschedulable' means a pod could not be scheduled, while 'error' means an internal scheduler problem.
profile
result
- - +None scheduler_scheduling_attempt_duration_seconds STABLE Histogram Scheduling attempt latency in seconds (scheduling algorithm + binding)
profile
result
- - +None @@ -217,7 +160,6 @@ components using an HTTP scrape, and fetch the current metrics data in Prometheu Help Labels Const Labels - Deprecated Version @@ -227,2275 +169,1878 @@ components using an HTTP scrape, and fetch the current metrics data in Prometheu Counter Counter of OpenAPI v2 spec regeneration count broken down by causing APIService name and reason.
apiservice
reason
- - +None aggregator_openapi_v2_regeneration_duration ALPHA Gauge Gauge of OpenAPI v2 spec regeneration duration in seconds.
reason
- - +None aggregator_unavailable_apiservice ALPHA Custom Gauge of APIServices which are marked as unavailable broken down by APIService name.
name
- - +None aggregator_unavailable_apiservice_total ALPHA Counter Counter of APIServices which are marked as unavailable broken down by APIService name and reason.
name
reason
- - +None apiextensions_openapi_v2_regeneration_count ALPHA Counter Counter of OpenAPI v2 spec regeneration count broken down by causing CRD name and reason.
crd
reason
- - +None apiextensions_openapi_v3_regeneration_count ALPHA Counter Counter of OpenAPI v3 spec regeneration count broken down by group, version, causing CRD and reason.
crd
group
reason
version
- - +None apiserver_admission_step_admission_duration_seconds_summary ALPHA Summary Admission sub-step latency summary in seconds, broken out for each operation and API resource and step type (validate or admit).
operation
rejected
type
- - +None apiserver_admission_webhook_fail_open_count ALPHA Counter Admission webhook fail open count, identified by name and broken out for each admission type (validating or mutating).
name
type
- - +None apiserver_admission_webhook_rejection_count ALPHA Counter Admission webhook rejection count, identified by name and broken out for each admission type (validating or admit) and operation. Additional labels specify an error type (calling_webhook_error or apiserver_internal_error if an error occurred; no_error otherwise) and optionally a non-zero rejection code if the webhook rejects the request with an HTTP status code (honored by the apiserver when the code is greater or equal to 400). Codes greater than 600 are truncated to 600, to keep the metrics cardinality bounded.
error_type
name
operation
rejection_code
type
- - +None apiserver_admission_webhook_request_total ALPHA Counter Admission webhook request total, identified by name and broken out for each admission type (validating or mutating) and operation. Additional labels specify whether the request was rejected or not and an HTTP status code. Codes greater than 600 are truncated to 600, to keep the metrics cardinality bounded.
code
name
operation
rejected
type
- - +None apiserver_audit_error_total ALPHA Counter Counter of audit events that failed to be audited properly. Plugin identifies the plugin affected by the error.
plugin
- - +None apiserver_audit_event_total ALPHA Counter Counter of audit events generated and sent to the audit backend. - - - +None +None apiserver_audit_level_total ALPHA Counter Counter of policy levels for audit events (1 per request).
level
- - +None apiserver_audit_requests_rejected_total ALPHA Counter Counter of apiserver requests rejected due to an error in audit logging backend. - - - +None +None apiserver_cache_list_fetched_objects_total ALPHA Counter Number of objects read from watch cache in the course of serving a LIST request
index
resource_prefix
- - +None apiserver_cache_list_returned_objects_total ALPHA Counter Number of objects returned for a LIST request from watch cache
resource_prefix
- - +None apiserver_cache_list_total ALPHA Counter Number of LIST requests served from watch cache
index
resource_prefix
- - +None apiserver_cel_compilation_duration_seconds ALPHA Histogram - - - +None +None apiserver_cel_evaluation_duration_seconds ALPHA Histogram - - - +None +None apiserver_certificates_registry_csr_honored_duration_total ALPHA Counter Total number of issued CSRs with a requested duration that was honored, sliced by signer (only kubernetes.io signer names are specifically identified)
signerName
- - +None apiserver_certificates_registry_csr_requested_duration_total ALPHA Counter Total number of issued CSRs with a requested duration, sliced by signer (only kubernetes.io signer names are specifically identified)
signerName
- - +None apiserver_client_certificate_expiration_seconds ALPHA Histogram Distribution of the remaining lifetime on the certificate used to authenticate a request. - - - +None +None apiserver_crd_webhook_conversion_duration_seconds ALPHA Histogram CRD webhook conversion duration in seconds
crd_name
from_version
succeeded
to_version
- - +None apiserver_current_inqueue_requests ALPHA Gauge Maximal number of queued requests in this apiserver per request kind in last second.
request_kind
- - +None apiserver_delegated_authn_request_duration_seconds ALPHA Histogram Request latency in seconds. Broken down by status code.
code
- - +None apiserver_delegated_authn_request_total ALPHA Counter Number of HTTP requests partitioned by status code.
code
- - +None apiserver_delegated_authz_request_duration_seconds ALPHA Histogram Request latency in seconds. Broken down by status code.
code
- - +None apiserver_delegated_authz_request_total ALPHA Counter Number of HTTP requests partitioned by status code.
code
- - +None apiserver_egress_dialer_dial_duration_seconds ALPHA Histogram Dial latency histogram in seconds, labeled by the protocol (http-connect or grpc), transport (tcp or uds)
protocol
transport
- - +None apiserver_egress_dialer_dial_failure_count ALPHA Counter Dial failure count, labeled by the protocol (http-connect or grpc), transport (tcp or uds), and stage (connect or proxy). The stage indicates at which stage the dial failed
protocol
stage
transport
- - -apiserver_egress_dialer_dial_start_total -ALPHA -Counter -Dial starts, labeled by the protocol (http-connect or grpc) and transport (tcp or uds). -
protocol
transport
- - +None apiserver_envelope_encryption_dek_cache_fill_percent ALPHA Gauge Percent of the cache slots currently occupied by cached DEKs. - - - +None +None apiserver_envelope_encryption_dek_cache_inter_arrival_time_seconds ALPHA Histogram Time (in seconds) of inter arrival of transformation requests.
transformation_type
- - +None apiserver_flowcontrol_current_executing_requests ALPHA Gauge Number of requests in initial (for a WATCH) or any (for a non-WATCH) execution stage in the API Priority and Fairness subsystem
flow_schema
priority_level
- - +None apiserver_flowcontrol_current_inqueue_requests ALPHA Gauge Number of requests currently pending in queues of the API Priority and Fairness subsystem
flow_schema
priority_level
- - -apiserver_flowcontrol_current_limit_seats -ALPHA -Gauge -current derived number of execution seats available to each priority level -
priority_level
- - +None apiserver_flowcontrol_current_r ALPHA Gauge R(time of last change)
priority_level
- - -apiserver_flowcontrol_demand_seats -ALPHA -TimingRatioHistogram -Observations, at the end of every nanosecond, of (the number of seats each priority level could use) / (nominal number of seats for that level) -
priority_level
- - -apiserver_flowcontrol_demand_seats_average -ALPHA -Gauge -Time-weighted average, over last adjustment period, of demand_seats -
priority_level
- - -apiserver_flowcontrol_demand_seats_high_watermark -ALPHA -Gauge -High watermark, over last adjustment period, of demand_seats -
priority_level
- - -apiserver_flowcontrol_demand_seats_smoothed -ALPHA -Gauge -Smoothed seat demands -
priority_level
- - -apiserver_flowcontrol_demand_seats_stdev -ALPHA -Gauge -Time-weighted standard deviation, over last adjustment period, of demand_seats -
priority_level
- - +None apiserver_flowcontrol_dispatch_r ALPHA Gauge R(time of last dispatch)
priority_level
- - +None apiserver_flowcontrol_dispatched_requests_total ALPHA Counter Number of requests executed by API Priority and Fairness subsystem
flow_schema
priority_level
- - +None apiserver_flowcontrol_epoch_advance_total ALPHA Counter Number of times the queueset's progress meter jumped backward
priority_level
success
- - +None apiserver_flowcontrol_latest_s ALPHA Gauge S(most recently dispatched request)
priority_level
- - -apiserver_flowcontrol_lower_limit_seats -ALPHA -Gauge -Configured lower bound on number of execution seats available to each priority level -
priority_level
- - +None apiserver_flowcontrol_next_discounted_s_bounds ALPHA Gauge min and max, over queues, of S(oldest waiting request in queue) - estimated work in progress
bound
priority_level
- - +None apiserver_flowcontrol_next_s_bounds ALPHA Gauge min and max, over queues, of S(oldest waiting request in queue)
bound
priority_level
- - -apiserver_flowcontrol_nominal_limit_seats -ALPHA -Gauge -Nominal number of execution seats configured for each priority level -
priority_level
- - +None apiserver_flowcontrol_priority_level_request_utilization ALPHA TimingRatioHistogram Observations, at the end of every nanosecond, of number of requests (as a fraction of the relevant limit) waiting or in any stage of execution (but only initial stage for WATCHes)
phase
priority_level
- - +None apiserver_flowcontrol_priority_level_seat_utilization ALPHA TimingRatioHistogram Observations, at the end of every nanosecond, of utilization of seats for any stage of execution (but only initial stage for WATCHes)
priority_level
-
phase:executing
- +map[phase:executing] apiserver_flowcontrol_read_vs_write_current_requests ALPHA TimingRatioHistogram Observations, at the end of every nanosecond, of the number of requests (as a fraction of the relevant limit) waiting or in regular stage of execution
phase
request_kind
- - +None apiserver_flowcontrol_rejected_requests_total ALPHA Counter Number of requests rejected by API Priority and Fairness subsystem
flow_schema
priority_level
reason
- - +None apiserver_flowcontrol_request_concurrency_in_use ALPHA Gauge Concurrency (number of seats) occupied by the currently executing (initial stage for a WATCH, any stage otherwise) requests in the API Priority and Fairness subsystem
flow_schema
priority_level
- - +None apiserver_flowcontrol_request_concurrency_limit ALPHA Gauge Shared concurrency limit in the API Priority and Fairness subsystem
priority_level
- - +None apiserver_flowcontrol_request_dispatch_no_accommodation_total ALPHA Counter Number of times a dispatch attempt resulted in a non accommodation due to lack of available seats
flow_schema
priority_level
- - +None apiserver_flowcontrol_request_execution_seconds ALPHA Histogram Duration of initial stage (for a WATCH) or any (for a non-WATCH) stage of request execution in the API Priority and Fairness subsystem
flow_schema
priority_level
type
- - +None apiserver_flowcontrol_request_queue_length_after_enqueue ALPHA Histogram Length of queue in the API Priority and Fairness subsystem, as seen by each request after it is enqueued
flow_schema
priority_level
- - +None apiserver_flowcontrol_request_wait_duration_seconds ALPHA Histogram Length of time a request spent waiting in its queue
execute
flow_schema
priority_level
- - -apiserver_flowcontrol_seat_fair_frac -ALPHA -Gauge -Fair fraction of server's concurrency to allocate to each priority level that can use it - - - -apiserver_flowcontrol_target_seats -ALPHA -Gauge -Seat allocation targets -
priority_level
- - -apiserver_flowcontrol_upper_limit_seats -ALPHA -Gauge -Configured upper bound on number of execution seats available to each priority level -
priority_level
- - +None apiserver_flowcontrol_watch_count_samples ALPHA Histogram count of watchers for mutating requests in API Priority and Fairness
flow_schema
priority_level
- - +None apiserver_flowcontrol_work_estimated_seats ALPHA Histogram Number of estimated seats (maximum of initial and final seats) associated with requests in API Priority and Fairness
flow_schema
priority_level
- - +None apiserver_init_events_total ALPHA Counter Counter of init events processed in watch cache broken by resource type.
resource
- - +None apiserver_kube_aggregator_x509_insecure_sha1_total ALPHA Counter Counts the number of requests to servers with insecure SHA1 signatures in their serving certificate OR the number of connection failures due to the insecure SHA1 signatures (either/or, based on the runtime environment) - - - +None +None apiserver_kube_aggregator_x509_missing_san_total ALPHA Counter Counts the number of requests to servers missing SAN extension in their serving certificate OR the number of connection failures due to the lack of x509 certificate SAN extension missing (either/or, based on the runtime environment) - - - +None +None apiserver_request_aborts_total ALPHA Counter Number of requests which apiserver aborted possibly due to a timeout, for each group, version, verb, resource, subresource and scope
group
resource
scope
subresource
verb
version
- - +None apiserver_request_body_sizes ALPHA Histogram Apiserver request body sizes broken out by size.
resource
verb
- - +None apiserver_request_filter_duration_seconds ALPHA Histogram Request filter latency distribution in seconds, for each filter type
filter
- - +None apiserver_request_post_timeout_total ALPHA Counter Tracks the activity of the request handlers after the associated requests have been timed out by the apiserver
source
status
- - -apiserver_request_sli_duration_seconds -ALPHA -Histogram -Response latency distribution (not counting webhook duration) in seconds for each verb, group, version, resource, subresource, scope and component. -
component
group
resource
scope
subresource
verb
version
- - +None apiserver_request_slo_duration_seconds ALPHA Histogram Response latency distribution (not counting webhook duration) in seconds for each verb, group, version, resource, subresource, scope and component.
component
group
resource
scope
subresource
verb
version
- -1.27.0 +None apiserver_request_terminations_total ALPHA Counter Number of requests which apiserver terminated in self-defense.
code
component
group
resource
scope
subresource
verb
version
- - +None apiserver_request_timestamp_comparison_time ALPHA Histogram Time taken for comparison of old vs new objects in UPDATE or PATCH requests
code_path
- - +None apiserver_selfrequest_total ALPHA Counter Counter of apiserver self-requests broken out for each verb, API resource and subresource.
resource
subresource
verb
- - +None apiserver_storage_data_key_generation_duration_seconds ALPHA Histogram Latencies in seconds of data encryption key(DEK) generation operations. - - - +None +None apiserver_storage_data_key_generation_failures_total ALPHA Counter Total number of failed data encryption key(DEK) generation operations. - - - +None +None apiserver_storage_db_total_size_in_bytes ALPHA Gauge Total size of the storage database file physically allocated in bytes.
endpoint
- - +None apiserver_storage_envelope_transformation_cache_misses_total ALPHA Counter Total number of cache misses while accessing key decryption key(KEK). - - - +None +None apiserver_storage_list_evaluated_objects_total ALPHA Counter Number of objects tested in the course of serving a LIST request from storage
resource
- - +None apiserver_storage_list_fetched_objects_total ALPHA Counter Number of objects read from storage in the course of serving a LIST request
resource
- - +None apiserver_storage_list_returned_objects_total ALPHA Counter Number of objects returned for a LIST request from storage
resource
- - +None apiserver_storage_list_total ALPHA Counter Number of LIST requests served from storage
resource
- - +None apiserver_storage_transformation_duration_seconds ALPHA Histogram Latencies in seconds of value transformation operations.
transformation_type
- - +None apiserver_storage_transformation_operations_total ALPHA Counter Total number of transformations.
status
transformation_type
transformer_prefix
- - +None apiserver_terminated_watchers_total ALPHA Counter Counter of watchers closed due to unresponsiveness broken by resource type.
resource
- - +None apiserver_tls_handshake_errors_total ALPHA Counter Number of requests dropped with 'TLS handshake error from' error - - - +None +None apiserver_validating_admission_policy_check_duration_seconds ALPHA Histogram -Validation admission latency for individual validation expressions in seconds, labeled by policy and further including binding, state and enforcement action taken. -
enforcement_action
policy
policy_binding
state
- - +Validation admission latency for individual validation expressions in seconds, labeled by policy and param resource, further including binding, state and enforcement action taken. +
enforcement_action
params
policy
policy_binding
state
validation_expression
+None apiserver_validating_admission_policy_check_total ALPHA Counter -Validation admission policy check total, labeled by policy and further identified by binding, enforcement action taken, and state. -
enforcement_action
policy
policy_binding
state
- - +Validation admission policy check total, labeled by policy and param resource, and further identified by binding, validation expression, enforcement action taken, and state. +
enforcement_action
params
policy
policy_binding
state
validation_expression
+None apiserver_validating_admission_policy_definition_total ALPHA Counter Validation admission policy count total, labeled by state and enforcement action.
enforcement_action
state
- - +None apiserver_watch_cache_events_dispatched_total ALPHA Counter Counter of events dispatched in watch cache broken by resource type.
resource
- - +None apiserver_watch_cache_initializations_total ALPHA Counter Counter of watch cache initializations broken by resource type.
resource
- - +None apiserver_watch_events_sizes ALPHA Histogram Watch event size distribution in bytes
group
kind
version
- - +None apiserver_watch_events_total ALPHA Counter Number of events sent in watch clients
group
kind
version
- - +None apiserver_webhooks_x509_insecure_sha1_total ALPHA Counter Counts the number of requests to servers with insecure SHA1 signatures in their serving certificate OR the number of connection failures due to the insecure SHA1 signatures (either/or, based on the runtime environment) - - - +None +None apiserver_webhooks_x509_missing_san_total ALPHA Counter Counts the number of requests to servers missing SAN extension in their serving certificate OR the number of connection failures due to the lack of x509 certificate SAN extension missing (either/or, based on the runtime environment) - - - +None +None attachdetach_controller_forced_detaches ALPHA Counter Number of times the A/D Controller performed a forced detach - - - +None +None attachdetach_controller_total_volumes ALPHA Custom Number of volumes in A/D Controller
plugin_name
state
- - +None authenticated_user_requests ALPHA Counter Counter of authenticated requests broken out by username.
username
- - +None authentication_attempts ALPHA Counter Counter of authenticated attempts.
result
- - +None authentication_duration_seconds ALPHA Histogram Authentication duration in seconds broken out by result.
result
- - +None authentication_token_cache_active_fetch_count ALPHA Gauge
status
- - +None authentication_token_cache_fetch_total ALPHA Counter
status
- - +None authentication_token_cache_request_duration_seconds ALPHA Histogram
status
- - +None authentication_token_cache_request_total ALPHA Counter
status
- - +None cloudprovider_aws_api_request_duration_seconds ALPHA Histogram Latency of AWS API calls
request
- - +None cloudprovider_aws_api_request_errors ALPHA Counter AWS API errors
request
- - +None cloudprovider_aws_api_throttled_requests_total ALPHA Counter AWS API throttled requests
operation_name
- - +None cloudprovider_azure_api_request_duration_seconds ALPHA Histogram Latency of an Azure API call
request
resource_group
source
subscription_id
- - +None cloudprovider_azure_api_request_errors ALPHA Counter Number of errors for an Azure API call
request
resource_group
source
subscription_id
- - +None cloudprovider_azure_api_request_ratelimited_count ALPHA Counter Number of rate limited Azure API calls
request
resource_group
source
subscription_id
- - +None cloudprovider_azure_api_request_throttled_count ALPHA Counter Number of throttled Azure API calls
request
resource_group
source
subscription_id
- - +None cloudprovider_azure_op_duration_seconds ALPHA Histogram Latency of an Azure service operation
request
resource_group
source
subscription_id
- - +None cloudprovider_azure_op_failure_count ALPHA Counter Number of failed Azure service operations
request
resource_group
source
subscription_id
- - +None cloudprovider_gce_api_request_duration_seconds ALPHA Histogram Latency of a GCE API call
region
request
version
zone
- - +None cloudprovider_gce_api_request_errors ALPHA Counter Number of errors for an API call
region
request
version
zone
- - +None cloudprovider_vsphere_api_request_duration_seconds ALPHA Histogram Latency of vsphere api call
request
- - +None cloudprovider_vsphere_api_request_errors ALPHA Counter vsphere Api errors
request
- - +None cloudprovider_vsphere_operation_duration_seconds ALPHA Histogram Latency of vsphere operation call
operation
- - +None cloudprovider_vsphere_operation_errors ALPHA Counter vsphere operation errors
operation
- - +None cloudprovider_vsphere_vcenter_versions ALPHA Custom Versions for connected vSphere vCenters
hostname
version
build
- - +None container_cpu_usage_seconds_total ALPHA Custom Cumulative cpu time consumed by the container in core-seconds
container
pod
namespace
- - +None container_memory_working_set_bytes ALPHA Custom Current working set of the container in bytes
container
pod
namespace
- - +None container_start_time_seconds ALPHA Custom Start time of the container since unix epoch in seconds
container
pod
namespace
- - +None +cronjob_controller_cronjob_job_creation_skew_duration_seconds +ALPHA +Histogram +Time between when a cronjob is scheduled to be run, and when the corresponding job is created +None +None csi_operations_seconds ALPHA Histogram Container Storage Interface operation duration with gRPC error code status total
driver_name
grpc_status_code
method_name
migrated
- - +None endpoint_slice_controller_changes ALPHA Counter Number of EndpointSlice changes
operation
- - +None endpoint_slice_controller_desired_endpoint_slices ALPHA Gauge Number of EndpointSlices that would exist with perfect endpoint allocation - - - +None +None endpoint_slice_controller_endpoints_added_per_sync ALPHA Histogram Number of endpoints added on each Service sync - - - +None +None endpoint_slice_controller_endpoints_desired ALPHA Gauge Number of endpoints desired - - - +None +None endpoint_slice_controller_endpoints_removed_per_sync ALPHA Histogram Number of endpoints removed on each Service sync - - - +None +None endpoint_slice_controller_endpointslices_changed_per_sync ALPHA Histogram Number of EndpointSlices changed on each Service sync
topology
- - +None endpoint_slice_controller_num_endpoint_slices ALPHA Gauge Number of EndpointSlices - - - +None +None endpoint_slice_controller_syncs ALPHA Counter Number of EndpointSlice syncs
result
- - +None endpoint_slice_mirroring_controller_addresses_skipped_per_sync ALPHA Histogram Number of addresses skipped on each Endpoints sync due to being invalid or exceeding MaxEndpointsPerSubset - - - +None +None endpoint_slice_mirroring_controller_changes ALPHA Counter Number of EndpointSlice changes
operation
- - +None endpoint_slice_mirroring_controller_desired_endpoint_slices ALPHA Gauge Number of EndpointSlices that would exist with perfect endpoint allocation - - - +None +None endpoint_slice_mirroring_controller_endpoints_added_per_sync ALPHA Histogram Number of endpoints added on each Endpoints sync - - - +None +None endpoint_slice_mirroring_controller_endpoints_desired ALPHA Gauge Number of endpoints desired - - - +None +None endpoint_slice_mirroring_controller_endpoints_removed_per_sync ALPHA Histogram Number of endpoints removed on each Endpoints sync - - - +None +None endpoint_slice_mirroring_controller_endpoints_sync_duration ALPHA Histogram Duration of syncEndpoints() in seconds - - - +None +None endpoint_slice_mirroring_controller_endpoints_updated_per_sync ALPHA Histogram Number of endpoints updated on each Endpoints sync - - - +None +None endpoint_slice_mirroring_controller_num_endpoint_slices ALPHA Gauge Number of EndpointSlices - - - +None +None ephemeral_volume_controller_create_failures_total ALPHA Counter Number of PersistenVolumeClaims creation requests - - - +None +None ephemeral_volume_controller_create_total ALPHA Counter Number of PersistenVolumeClaims creation requests - - - +None +None etcd_bookmark_counts ALPHA Gauge Number of etcd bookmarks (progress notify events) split by kind.
resource
- - +None etcd_lease_object_counts ALPHA Histogram Number of objects attached to a single etcd lease. - - - +None +None etcd_request_duration_seconds ALPHA Histogram Etcd request latency in seconds for each operation and object type.
operation
type
- - +None etcd_version_info ALPHA Gauge Etcd server's binary version
binary_version
- - +None field_validation_request_duration_seconds ALPHA Histogram Response latency distribution in seconds for each field validation value and whether field validation is enabled or not
enabled
field_validation
- - +None garbagecollector_controller_resources_sync_error_total ALPHA Counter Number of garbage collector resources sync errors - - - +None +None get_token_count ALPHA Counter Counter of total Token() requests to the alternate token source - - - +None +None get_token_fail_count ALPHA Counter Counter of failed Token() requests to the alternate token source - - - +None +None +job_controller_job_finished_total +ALPHA +Counter +The number of finished job +
completion_mode
reason
result
+None +job_controller_job_pods_finished_total +ALPHA +Counter +The number of finished Pods that are fully tracked +
completion_mode
result
+None +job_controller_job_sync_duration_seconds +ALPHA +Histogram +The time it took to sync a job +
action
completion_mode
result
+None +job_controller_job_sync_total +ALPHA +Counter +The number of job syncs +
action
completion_mode
result
+None job_controller_pod_failures_handled_by_failure_policy_total ALPHA Counter `The number of failed Pods handled by failure policy with, respect to the failure policy action applied based on the matched, rule. Possible values of the action label correspond to the, possible values for the failure policy rule action, which are:, "FailJob", "Ignore" and "Count".`
action
- - +None job_controller_terminated_pods_tracking_finalizer_total ALPHA Counter `The number of terminated pods (phase=Failed|Succeeded), that have the finalizer batch.kubernetes.io/job-tracking, The event label can be "add" or "delete".`
event
- - +None kube_apiserver_clusterip_allocator_allocated_ips ALPHA Gauge Gauge measuring the number of allocated IPs for Services
cidr
- - +None kube_apiserver_clusterip_allocator_allocation_errors_total ALPHA Counter Number of errors trying to allocate Cluster IPs
cidr
scope
- - +None kube_apiserver_clusterip_allocator_allocation_total ALPHA Counter Number of Cluster IPs allocations
cidr
scope
- - +None kube_apiserver_clusterip_allocator_available_ips ALPHA Gauge Gauge measuring the number of available IPs for Services
cidr
- - +None kube_apiserver_pod_logs_pods_logs_backend_tls_failure_total ALPHA Counter Total number of requests for pods/logs that failed due to kubelet server TLS verification - - - +None +None kube_apiserver_pod_logs_pods_logs_insecure_backend_total ALPHA Counter Total number of requests for pods/logs sliced by usage type: enforce_tls, skip_tls_allowed, skip_tls_denied
usage
- - +None kube_pod_resource_limit ALPHA Custom Resources limit for workloads on the cluster, broken down by pod. This shows the resource usage the scheduler and kubelet expect per pod for resources along with the unit for the resource if any.
namespace
pod
node
scheduler
priority
resource
unit
- - +None kube_pod_resource_request ALPHA Custom Resources requested by workloads on the cluster, broken down by pod. This shows the resource usage the scheduler and kubelet expect per pod for resources along with the unit for the resource if any.
namespace
pod
node
scheduler
priority
resource
unit
- - +None kubelet_certificate_manager_client_expiration_renew_errors ALPHA Counter Counter of certificate renewal errors. - - - +None +None kubelet_certificate_manager_client_ttl_seconds ALPHA Gauge Gauge of the TTL (time-to-live) of the Kubelet's client certificate. The value is in seconds until certificate expiry (negative if already expired). If client certificate is invalid or unused, the value will be +INF. - - - +None +None kubelet_certificate_manager_server_rotation_seconds ALPHA Histogram Histogram of the number of seconds the previous certificate lived before being rotated. - - - +None +None kubelet_certificate_manager_server_ttl_seconds ALPHA Gauge Gauge of the shortest TTL (time-to-live) of the Kubelet's serving certificate. The value is in seconds until certificate expiry (negative if already expired). If serving certificate is invalid or unused, the value will be +INF. - - - +None +None kubelet_cgroup_manager_duration_seconds ALPHA Histogram Duration in seconds for cgroup manager operations. Broken down by method.
operation_type
- - +None kubelet_container_log_filesystem_used_bytes ALPHA Custom Bytes used by the container's logs on the filesystem.
uid
namespace
pod
container
- - +None kubelet_containers_per_pod_count ALPHA Histogram The number of containers per pod. - - - +None +None kubelet_cpu_manager_pinning_errors_total ALPHA Counter The number of cpu core allocations which required pinning failed. - - - +None +None kubelet_cpu_manager_pinning_requests_total ALPHA Counter The number of cpu core allocations which required pinning. - - - -kubelet_credential_provider_plugin_duration -ALPHA -Histogram -Duration of execution in seconds for credential provider plugin -
plugin_name
- - -kubelet_credential_provider_plugin_errors -ALPHA -Counter -Number of errors from credential provider plugin -
plugin_name
- - +None +None kubelet_device_plugin_alloc_duration_seconds ALPHA Histogram Duration in seconds to serve a device plugin Allocation request. Broken down by resource name.
resource_name
- - +None kubelet_device_plugin_registration_total ALPHA Counter Cumulative number of device plugin registrations. Broken down by resource name.
resource_name
- - +None kubelet_eviction_stats_age_seconds ALPHA Histogram Time between when stats are collected, and when pod is evicted based on those stats by eviction signal
eviction_signal
- - +None kubelet_evictions ALPHA Counter Cumulative number of pod evictions by eviction signal
eviction_signal
- - +None kubelet_graceful_shutdown_end_time_seconds ALPHA Gauge Last graceful shutdown start time since unix epoch in seconds - - - +None +None kubelet_graceful_shutdown_start_time_seconds ALPHA Gauge Last graceful shutdown start time since unix epoch in seconds - - - +None +None kubelet_http_inflight_requests ALPHA Gauge Number of the inflight http requests
long_running
method
path
server_type
- - +None kubelet_http_requests_duration_seconds ALPHA Histogram Duration in seconds to serve http requests
long_running
method
path
server_type
- - +None kubelet_http_requests_total ALPHA Counter Number of the http requests received since the server started
long_running
method
path
server_type
- - +None +kubelet_kubelet_credential_provider_plugin_duration +ALPHA +Histogram +Duration of execution in seconds for credential provider plugin +
plugin_name
+None +kubelet_kubelet_credential_provider_plugin_errors +ALPHA +Counter +Number of errors from credential provider plugin +
plugin_name
+None kubelet_lifecycle_handler_http_fallbacks_total ALPHA Counter The number of times lifecycle handlers successfully fell back to http from https. - - - +None +None kubelet_managed_ephemeral_containers ALPHA Gauge Current number of ephemeral containers in pods managed by this kubelet. Ephemeral containers will be ignored if disabled by the EphemeralContainers feature gate, and this number will be 0. - - - +None +None kubelet_node_name ALPHA Gauge The node's name. The count is always 1.
node
- - +None kubelet_pleg_discard_events ALPHA Counter The number of discard events in PLEG. - - - +None +None kubelet_pleg_last_seen_seconds ALPHA Gauge Timestamp in seconds when PLEG was last seen active. - - - +None +None kubelet_pleg_relist_duration_seconds ALPHA Histogram Duration in seconds for relisting pods in PLEG. - - - +None +None kubelet_pleg_relist_interval_seconds ALPHA Histogram Interval in seconds between relisting in PLEG. - - - +None +None kubelet_pod_resources_endpoint_errors_get_allocatable ALPHA Counter Number of requests to the PodResource GetAllocatableResources endpoint which returned error. Broken down by server api version.
server_api_version
- - +None kubelet_pod_resources_endpoint_errors_list ALPHA Counter Number of requests to the PodResource List endpoint which returned error. Broken down by server api version.
server_api_version
- - +None kubelet_pod_resources_endpoint_requests_get_allocatable ALPHA Counter Number of requests to the PodResource GetAllocatableResources endpoint. Broken down by server api version.
server_api_version
- - +None kubelet_pod_resources_endpoint_requests_list ALPHA Counter Number of requests to the PodResource List endpoint. Broken down by server api version.
server_api_version
- - +None kubelet_pod_resources_endpoint_requests_total ALPHA Counter Cumulative number of requests to the PodResource endpoint. Broken down by server api version.
server_api_version
- - +None kubelet_pod_start_duration_seconds ALPHA Histogram Duration in seconds from kubelet seeing a pod for the first time to the pod starting to run - - - -kubelet_pod_start_sli_duration_seconds -ALPHA -Histogram -Duration in seconds to start a pod, excluding time to pull images and run init containers, measured from pod creation timestamp to when all its containers are reported as started and observed via watch - - - +None +None kubelet_pod_status_sync_duration_seconds ALPHA Histogram Duration in seconds to sync a pod status update. Measures time from detection of a change to pod status until the API is successfully updated for that pod, even if multiple intevening changes to pod status occur. - - - +None +None kubelet_pod_worker_duration_seconds ALPHA Histogram Duration in seconds to sync a single pod. Broken down by operation type: create, update, or sync
operation_type
- - +None kubelet_pod_worker_start_duration_seconds ALPHA Histogram Duration in seconds from kubelet seeing a pod to starting a worker. - - - +None +None kubelet_preemptions ALPHA Counter Cumulative number of pod preemptions by preemption resource
preemption_signal
- - +None kubelet_run_podsandbox_duration_seconds ALPHA Histogram Duration in seconds of the run_podsandbox operations. Broken down by RuntimeClass.Handler.
runtime_handler
- - +None kubelet_run_podsandbox_errors_total ALPHA Counter Cumulative number of the run_podsandbox operation errors by RuntimeClass.Handler.
runtime_handler
- - +None kubelet_running_containers ALPHA Gauge Number of containers currently running
container_state
- - +None kubelet_running_pods ALPHA Gauge Number of pods that have a running pod sandbox - - - +None +None kubelet_runtime_operations_duration_seconds ALPHA Histogram Duration in seconds of runtime operations. Broken down by operation type.
operation_type
- - +None kubelet_runtime_operations_errors_total ALPHA Counter Cumulative number of runtime operation errors by operation type.
operation_type
- - +None kubelet_runtime_operations_total ALPHA Counter Cumulative number of runtime operations by operation type.
operation_type
- - +None kubelet_server_expiration_renew_errors ALPHA Counter Counter of certificate renewal errors. - - - +None +None kubelet_started_containers_errors_total ALPHA Counter Cumulative number of errors when starting containers
code
container_type
- - +None kubelet_started_containers_total ALPHA Counter Cumulative number of containers started
container_type
- - +None kubelet_started_host_process_containers_errors_total ALPHA Counter Cumulative number of errors when starting hostprocess containers. This metric will only be collected on Windows and requires WindowsHostProcessContainers feature gate to be enabled.
code
container_type
- - +None kubelet_started_host_process_containers_total ALPHA Counter Cumulative number of hostprocess containers started. This metric will only be collected on Windows and requires WindowsHostProcessContainers feature gate to be enabled.
container_type
- - +None kubelet_started_pods_errors_total ALPHA Counter Cumulative number of errors when starting pods - - - +None +None kubelet_started_pods_total ALPHA Counter Cumulative number of pods started - - - +None +None kubelet_volume_metric_collection_duration_seconds ALPHA Histogram Duration in seconds to calculate volume stats
metric_source
- - +None kubelet_volume_stats_available_bytes ALPHA Custom Number of available bytes in the volume
namespace
persistentvolumeclaim
- - +None kubelet_volume_stats_capacity_bytes ALPHA Custom Capacity in bytes of the volume
namespace
persistentvolumeclaim
- - +None kubelet_volume_stats_health_status_abnormal ALPHA Custom Abnormal volume health status. The count is either 1 or 0. 1 indicates the volume is unhealthy, 0 indicates volume is healthy
namespace
persistentvolumeclaim
- - +None kubelet_volume_stats_inodes ALPHA Custom Maximum number of inodes in the volume
namespace
persistentvolumeclaim
- - +None kubelet_volume_stats_inodes_free ALPHA Custom Number of free inodes in the volume
namespace
persistentvolumeclaim
- - +None kubelet_volume_stats_inodes_used ALPHA Custom Number of used inodes in the volume
namespace
persistentvolumeclaim
- - +None kubelet_volume_stats_used_bytes ALPHA Custom Number of used bytes in the volume
namespace
persistentvolumeclaim
- - +None kubeproxy_network_programming_duration_seconds ALPHA Histogram In Cluster Network Programming Latency in seconds - - - +None +None kubeproxy_sync_proxy_rules_duration_seconds ALPHA Histogram SyncProxyRules latency in seconds - - - +None +None kubeproxy_sync_proxy_rules_endpoint_changes_pending ALPHA Gauge Pending proxy rules Endpoint changes - - - +None +None kubeproxy_sync_proxy_rules_endpoint_changes_total ALPHA Counter Cumulative proxy rules Endpoint changes - - - -kubeproxy_sync_proxy_rules_iptables_partial_restore_failures_total -ALPHA -Counter -Cumulative proxy iptables partial restore failures - - - +None +None kubeproxy_sync_proxy_rules_iptables_restore_failures_total ALPHA Counter Cumulative proxy iptables restore failures - - - +None +None kubeproxy_sync_proxy_rules_iptables_total ALPHA Gauge Number of proxy iptables rules programmed
table
- - +None kubeproxy_sync_proxy_rules_last_queued_timestamp_seconds ALPHA Gauge The last time a sync of proxy rules was queued - - - +None +None kubeproxy_sync_proxy_rules_last_timestamp_seconds ALPHA Gauge The last time proxy rules were successfully synced - - - +None +None kubeproxy_sync_proxy_rules_no_local_endpoints_total ALPHA Gauge Number of services with a Local traffic policy and no endpoints
traffic_policy
- - +None kubeproxy_sync_proxy_rules_service_changes_pending ALPHA Gauge Pending proxy rules Service changes - - - +None +None kubeproxy_sync_proxy_rules_service_changes_total ALPHA Counter Cumulative proxy rules Service changes - - - +None +None kubernetes_build_info ALPHA Gauge A metric with a constant '1' value labeled by major, minor, git version, git commit, git tree state, build date, Go version, and compiler from which Kubernetes was built, and platform on which it is running.
build_date
compiler
git_commit
git_tree_state
git_version
go_version
major
minor
platform
- - +None kubernetes_feature_enabled ALPHA Gauge This metric records the data about the stage and enablement of a k8s feature.
name
stage
- - +None kubernetes_healthcheck ALPHA Gauge This metric records the result of a single healthcheck.
name
type
- - +None kubernetes_healthchecks_total ALPHA Counter This metric records the results of all healthcheck.
name
status
type
- - +None leader_election_master_status ALPHA Gauge Gauge of if the reporting system is master of the relevant lease, 0 indicates backup, 1 indicates master. 'name' is the string used to identify the lease. Please make sure to group by name.
name
- - +None node_authorizer_graph_actions_duration_seconds ALPHA Histogram Histogram of duration of graph actions in node authorizer.
operation
- - +None node_collector_evictions_number ALPHA Counter Number of Node evictions that happened since current instance of NodeController started, This metric is replaced by node_collector_evictions_total.
zone
- -1.24.0 +None node_collector_unhealthy_nodes_in_zone ALPHA Gauge Gauge measuring number of not Ready Nodes per zones.
zone
- - +None node_collector_zone_health ALPHA Gauge Gauge measuring percentage of healthy nodes per zone.
zone
- - +None node_collector_zone_size ALPHA Gauge Gauge measuring number of registered Nodes per zones.
zone
- - +None node_cpu_usage_seconds_total ALPHA Custom Cumulative cpu time consumed by the node in core-seconds - - - +None +None node_ipam_controller_cidrset_allocation_tries_per_request ALPHA Histogram Number of endpoints added on each Service sync
clusterCIDR
- - +None node_ipam_controller_cidrset_cidrs_allocations_total ALPHA Counter Counter measuring total number of CIDR allocations.
clusterCIDR
- - +None node_ipam_controller_cidrset_cidrs_releases_total ALPHA Counter Counter measuring total number of CIDR releases.
clusterCIDR
- - +None node_ipam_controller_cidrset_usage_cidrs ALPHA Gauge Gauge measuring percentage of allocated CIDRs.
clusterCIDR
- - +None node_ipam_controller_multicidrset_allocation_tries_per_request ALPHA Histogram Histogram measuring CIDR allocation tries per request.
clusterCIDR
- - +None node_ipam_controller_multicidrset_cidrs_allocations_total ALPHA Counter Counter measuring total number of CIDR allocations.
clusterCIDR
- - +None node_ipam_controller_multicidrset_cidrs_releases_total ALPHA Counter Counter measuring total number of CIDR releases.
clusterCIDR
- - +None node_ipam_controller_multicidrset_usage_cidrs ALPHA Gauge Gauge measuring percentage of allocated CIDRs.
clusterCIDR
- - +None node_memory_working_set_bytes ALPHA Custom Current working set of the node in bytes - - - +None +None number_of_l4_ilbs ALPHA Gauge Number of L4 ILBs
feature
- - +None plugin_manager_total_plugins ALPHA Custom Number of plugins in Plugin Manager
socket_path
state
- - +None pod_cpu_usage_seconds_total ALPHA Custom Cumulative cpu time consumed by the pod in core-seconds
pod
namespace
- - -pod_gc_collector_force_delete_pod_errors_total -ALPHA -Counter -Number of errors encountered when forcefully deleting the pods since the Pod GC Controller started. - - - -pod_gc_collector_force_delete_pods_total -ALPHA -Counter -Number of pods that are being forcefully deleted since the Pod GC Controller started. - - - +None pod_memory_working_set_bytes ALPHA Custom Current working set of the pod in bytes
pod
namespace
- - +None pod_security_errors_total ALPHA Counter Number of errors preventing normal evaluation. Non-fatal errors may result in the latest restricted profile being used for evaluation.
fatal
request_operation
resource
subresource
- - +None pod_security_evaluations_total ALPHA Counter Number of policy evaluations that occurred, not counting ignored or exempt requests.
decision
mode
policy_level
policy_version
request_operation
resource
subresource
- - +None pod_security_exemptions_total ALPHA Counter Number of exempt requests, not counting ignored or out of scope requests.
request_operation
resource
subresource
- - +None prober_probe_duration_seconds ALPHA Histogram Duration in seconds for a probe response.
container
namespace
pod
probe_type
- - +None prober_probe_total ALPHA Counter Cumulative number of a liveness, readiness or startup probe for a container by result.
container
namespace
pod
pod_uid
probe_type
result
- - +None pv_collector_bound_pv_count ALPHA Custom Gauge measuring number of persistent volume currently bound
storage_class
- - +None pv_collector_bound_pvc_count ALPHA Custom Gauge measuring number of persistent volume claim currently bound
namespace
- - +None pv_collector_total_pv_count ALPHA Custom Gauge measuring total number of persistent volumes
plugin_name
volume_mode
- - +None pv_collector_unbound_pv_count ALPHA Custom Gauge measuring number of persistent volume currently unbound
storage_class
- - +None pv_collector_unbound_pvc_count ALPHA Custom Gauge measuring number of persistent volume claim currently unbound
namespace
- - +None replicaset_controller_sorting_deletion_age_ratio ALPHA Histogram The ratio of chosen deleted pod's ages to the current youngest pod's age (at the time). Should be <2.The intent of this metric is to measure the rough efficacy of the LogarithmicScaleDown feature gate's effect onthe sorting (and deletion) of pods when a replicaset scales down. This only considers Ready pods when calculating and reporting. - - - +None +None rest_client_exec_plugin_call_total ALPHA Counter Number of calls to an exec plugin, partitioned by the type of event encountered (no_error, plugin_execution_error, plugin_not_found_error, client_internal_error) and an optional exit code. The exit code will be set to 0 if and only if the plugin call was successful.
call_status
code
- - +None rest_client_exec_plugin_certificate_rotation_age ALPHA Histogram Histogram of the number of seconds the last auth exec plugin client certificate lived before being rotated. If auth exec plugin client certificates are unused, histogram will contain no data. - - - +None +None rest_client_exec_plugin_ttl_seconds ALPHA Gauge Gauge of the shortest TTL (time-to-live) of the client certificate(s) managed by the auth exec plugin. The value is in seconds until certificate expiry (negative if already expired). If auth exec plugins are unused or manage no TLS certificates, the value will be +INF. - - - +None +None rest_client_rate_limiter_duration_seconds ALPHA Histogram Client side rate limiter latency in seconds. Broken down by verb, and host.
host
verb
- - +None rest_client_request_duration_seconds ALPHA Histogram Request latency in seconds. Broken down by verb, and host.
host
verb
- - +None rest_client_request_size_bytes ALPHA Histogram Request size in bytes. Broken down by verb and host.
host
verb
- - +None rest_client_requests_total ALPHA Counter Number of HTTP requests, partitioned by status code, method, and host.
code
host
method
- - +None rest_client_response_size_bytes ALPHA Histogram Response size in bytes. Broken down by verb and host.
host
verb
- - +None retroactive_storageclass_errors_total ALPHA Counter Total number of failed retroactive StorageClass assignments to persistent volume claim - - - +None +None retroactive_storageclass_total ALPHA Counter Total number of retroactive StorageClass assignments to persistent volume claim - - - +None +None root_ca_cert_publisher_sync_duration_seconds ALPHA Histogram Number of namespace syncs happened in root ca cert publisher.
code
- - +None root_ca_cert_publisher_sync_total ALPHA Counter Number of namespace syncs happened in root ca cert publisher.
code
- - +None running_managed_controllers ALPHA Gauge Indicates where instances of a controller are currently running
manager
name
- - +None scheduler_e2e_scheduling_duration_seconds ALPHA Histogram E2e scheduling latency in seconds (scheduling algorithm + binding). This metric is replaced by scheduling_attempt_duration_seconds.
profile
result
- -1.23.0 +None scheduler_goroutines ALPHA Gauge Number of running goroutines split by the work they do such as binding.
operation
- - +None scheduler_permit_wait_duration_seconds ALPHA Histogram Duration of waiting on permit.
result
- - +None scheduler_plugin_execution_duration_seconds ALPHA Histogram Duration for running a plugin at a specific extension point.
extension_point
plugin
status
- - +None scheduler_scheduler_cache_size ALPHA Gauge Number of nodes, pods, and assumed (bound) pods in the scheduler cache.
type
- - +None scheduler_scheduler_goroutines ALPHA Gauge Number of running goroutines split by the work they do such as binding. This metric is replaced by the \"goroutines\" metric.
work
- -1.26.0 +None scheduler_scheduling_algorithm_duration_seconds ALPHA Histogram Scheduling algorithm latency in seconds - - - +None +None scheduler_unschedulable_pods ALPHA Gauge The number of unschedulable pods broken down by plugin name. A pod will increment the gauge for all plugins that caused it to not schedule and so this metric have meaning only when broken down by plugin.
plugin
profile
- - +None scheduler_volume_binder_cache_requests_total ALPHA Counter Total number for request volume binding cache
operation
- - +None scheduler_volume_scheduling_stage_error_total ALPHA Counter Volume scheduling stage error count
operation
- - +None scrape_error ALPHA Custom 1 if there was an error while getting container metrics, 0 otherwise - - - +None +None service_controller_nodesync_latency_seconds ALPHA Histogram A metric measuring the latency for nodesync which updates loadbalancer hosts on cluster node updates. - - - +None +None service_controller_update_loadbalancer_host_latency_seconds ALPHA Histogram A metric measuring the latency for updating each load balancer hosts. - - - +None +None serviceaccount_legacy_tokens_total ALPHA Counter Cumulative legacy service account tokens used - - - +None +None serviceaccount_stale_tokens_total ALPHA Counter Cumulative stale projected service account tokens used - - - +None +None serviceaccount_valid_tokens_total ALPHA Counter Cumulative valid projected service account tokens used - - - +None +None storage_count_attachable_volumes_in_use ALPHA Custom Measure number of volumes in use
node
volume_plugin
- - +None storage_operation_duration_seconds ALPHA Histogram Storage operation duration
migrated
operation_name
status
volume_plugin
- - +None ttl_after_finished_controller_job_deletion_duration_seconds ALPHA Histogram The time it took to delete the job since it became eligible for deletion - - - +None +None volume_manager_selinux_container_errors_total ALPHA Gauge Number of errors when kubelet cannot compute SELinux context for a container. Kubelet can't start such a Pod then and it will retry, therefore value of this metric may not represent the actual nr. of containers. - - - +None +None volume_manager_selinux_container_warnings_total ALPHA Gauge Number of errors when kubelet cannot compute SELinux context for a container that are ignored. They will become real errors when SELinuxMountReadWriteOncePod feature is expanded to all volume access modes. - - - +None +None volume_manager_selinux_pod_context_mismatch_errors_total ALPHA Gauge Number of errors when a Pod defines different SELinux contexts for its containers that use the same volume. Kubelet can't start such a Pod then and it will retry, therefore value of this metric may not represent the actual nr. of Pods. - - - +None +None volume_manager_selinux_pod_context_mismatch_warnings_total ALPHA Gauge Number of errors when a Pod defines different SELinux contexts for its containers that use the same volume. They are not errors yet, but they will become real errors when SELinuxMountReadWriteOncePod feature is expanded to all volume access modes. - - - +None +None volume_manager_selinux_volume_context_mismatch_errors_total ALPHA Gauge Number of errors when a Pod uses a volume that is already mounted with a different SELinux context than the Pod needs. Kubelet can't start such a Pod then and it will retry, therefore value of this metric may not represent the actual nr. of Pods. - - - +None +None volume_manager_selinux_volume_context_mismatch_warnings_total ALPHA Gauge Number of errors when a Pod uses a volume that is already mounted with a different SELinux context than the Pod needs. They are not errors yet, but they will become real errors when SELinuxMountReadWriteOncePod feature is expanded to all volume access modes. - - - +None +None volume_manager_selinux_volumes_admitted_total ALPHA Gauge Number of volumes whose SELinux context was fine and will be mounted with mount -o context option. - - - +None +None volume_manager_total_volumes ALPHA Custom Number of volumes in Volume Manager
plugin_name
state
- - +None volume_operation_total_errors ALPHA Counter Total volume operation errors
operation_name
plugin_name
- - +None volume_operation_total_seconds ALPHA Histogram Storage operation end to end duration in seconds
operation_name
plugin_name
- - +None watch_cache_capacity ALPHA Gauge Total capacity of watch cache broken by resource type.
resource
- - +None watch_cache_capacity_decrease_total ALPHA Counter Total number of watch cache capacity decrease events broken by resource type.
resource
- - +None watch_cache_capacity_increase_total ALPHA Counter Total number of watch cache capacity increase events broken by resource type.
resource
- - +None workqueue_adds_total ALPHA Counter Total number of adds handled by workqueue
name
- - +None workqueue_depth ALPHA Gauge Current depth of workqueue
name
- - +None workqueue_longest_running_processor_seconds ALPHA Gauge How many seconds has the longest running processor for workqueue been running.
name
- - +None workqueue_queue_duration_seconds ALPHA Histogram How long in seconds an item stays in workqueue before being requested.
name
- - +None workqueue_retries_total ALPHA Counter Total number of retries handled by workqueue
name
- - +None workqueue_unfinished_work_seconds ALPHA Gauge How many seconds of work has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.
name
- - +None workqueue_work_duration_seconds ALPHA Histogram How long in seconds processing an item from workqueue takes.
name
- - +None diff --git a/content/en/docs/reference/instrumentation/node-metrics.md b/content/en/docs/reference/instrumentation/node-metrics.md new file mode 100644 index 00000000000..ce5984e5ed8 --- /dev/null +++ b/content/en/docs/reference/instrumentation/node-metrics.md @@ -0,0 +1,55 @@ +--- +title: Node metrics data +content_type: reference +weight: 50 +description: >- + Mechanisms for accessing metrics at node, volume, pod and container level, + as seen by the kubelet. +--- + +The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) +gathers metric statistics at the node, volume, pod and container level, +and emits this information in the +[Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go). + +You can send a proxied request to the stats summary API via the +Kubernetes API server. + +Here is an example of a Summary API request for a node named `minikube`: + +```shell +kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary" +``` + +Here is the same API call using `curl`: + +```shell +# You need to run "kubectl proxy" first +# Change 8080 to the port that "kubectl proxy" assigns +curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary +``` + +{{< note >}} +Beginning with `metrics-server` 0.6.x, `metrics-server` queries the `/metrics/resource` +kubelet endpoint, and not `/stats/summary`. +{{< /note >}} + +## Summary metrics API source {#summary-api-source} + +By default, Kubernetes fetches node summary metrics data using an embedded +[cAdvisor](https://github.com/google/cadvisor) that runs within the kubelet. + +## Summary API data via CRI {#pod-and-container-stats-from-cri} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +If you enable the `PodAndContainerStatsFromCRI` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) in your +cluster, and you use a container runtime that supports statistics access via +{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI), then +the kubelet fetches Pod- and container-level metric data using CRI, and not via cAdvisor. + +## {{% heading "whatsnext" %}} + +The task pages for [Troubleshooting Clusters](/docs/tasks/debug/debug-cluster/) discuss +how to use a metrics pipeline that rely on these data. diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index fa846232ec7..0e3e3f285d5 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -22,7 +22,7 @@ This page contains a list of commonly used `kubectl` commands and flags. ### BASH ```bash -source <(kubectl completion bash) # setup autocomplete in bash into the current shell, bash-completion package should be installed first. +source <(kubectl completion bash) # set up autocomplete in bash into the current shell, bash-completion package should be installed first. echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell. ``` @@ -36,12 +36,12 @@ complete -o default -F __start_kubectl k ### ZSH ```bash -source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell +source <(kubectl completion zsh) # set up autocomplete in zsh into the current shell echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # add autocomplete permanently to your zsh shell ``` -### A Note on --all-namespaces +### A note on `--all-namespaces` -Appending `--all-namespaces` happens frequently enough where you should be aware of the shorthand for `--all-namespaces`: +Appending `--all-namespaces` happens frequently enough where you should be aware of the shorthand for `--all-namespaces`: ```kubectl -A``` @@ -155,7 +155,7 @@ EOF ``` -## Viewing, finding resources +## Viewing and finding resources ```bash # Get commands with basic output @@ -269,6 +269,7 @@ kubectl expose rc nginx --port=80 --target-port=8000 kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - kubectl label pods my-pod new-label=awesome # Add a Label +kubectl label pods my-pod new-label- # Remove a label kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annotation kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo" ``` @@ -349,7 +350,7 @@ kubectl exec my-pod -c my-container -- ls / # Run command in existing po kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers kubectl top pod POD_NAME --sort-by=cpu # Show metrics for a given pod and sort it by 'cpu' or 'memory' ``` -## Copy files and directories to and from containers +## Copying files and directories to and from containers ```bash kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir # Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the current namespace @@ -358,7 +359,7 @@ kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar # Copy /tmp/foo local fil kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally ``` {{< note >}} -`kubectl cp` requires that the 'tar' binary is present in your container image. If 'tar' is not present,`kubectl cp` will fail. +`kubectl cp` requires that the 'tar' binary is present in your container image. If 'tar' is not present, `kubectl cp` will fail. For advanced use cases, such as symlinks, wildcard expansion or file mode preservation consider using `kubectl exec`. {{< /note >}} diff --git a/content/en/docs/reference/networking/_index.md b/content/en/docs/reference/networking/_index.md new file mode 100644 index 00000000000..e771d23f861 --- /dev/null +++ b/content/en/docs/reference/networking/_index.md @@ -0,0 +1,11 @@ +--- +title: Networking Reference +content_type: reference +weight: 85 +--- + + +This section of the Kubernetes documentation provides reference details +of Kubernetes networking. + + \ No newline at end of file diff --git a/content/en/docs/reference/ports-and-protocols.md b/content/en/docs/reference/networking/ports-and-protocols.md similarity index 99% rename from content/en/docs/reference/ports-and-protocols.md rename to content/en/docs/reference/networking/ports-and-protocols.md index cdba8383c7b..2e716e4d46f 100644 --- a/content/en/docs/reference/ports-and-protocols.md +++ b/content/en/docs/reference/networking/ports-and-protocols.md @@ -1,7 +1,7 @@ --- title: Ports and Protocols content_type: reference -weight: 90 +weight: 40 --- When running Kubernetes in an environment with strict network boundaries, such diff --git a/content/en/docs/reference/networking/service-protocols.md b/content/en/docs/reference/networking/service-protocols.md new file mode 100644 index 00000000000..578020d30cb --- /dev/null +++ b/content/en/docs/reference/networking/service-protocols.md @@ -0,0 +1,127 @@ +--- +title: Protocols for Services +content_type: reference +weight: 10 +--- + + +If you configure a {{< glossary_tooltip text="Service" term_id="service" >}}, +you can select from any network protocol that Kubernetes supports. + +Kubernetes supports the following protocols with Services: + +- [`SCTP`](#protocol-sctp) +- [`TCP`](#protocol-tcp) _(the default)_ +- [`UDP`](#protocol-udp) + +When you define a Service, you can also specify the +[application protocol](/docs/concepts/services-networking/service/#application-protocol) +that it uses. + +This document details some special cases, all of them typically using TCP +as a transport protocol: + +- [HTTP](#protocol-http-special) and [HTTPS](#protocol-http-special) +- [PROXY protocol](#protocol-proxy-special) +- [TLS](#protocol-tls-special) termination at the load balancer + + +## Supported protocols {#protocol-support} + +There are 3 valid values for the `protocol` of a port for a Service: + +### `SCTP` {#protocol-sctp} + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +When using a network plugin that supports SCTP traffic, you can use SCTP for +most Services. For `type: LoadBalancer` Services, SCTP support depends on the cloud +provider offering this facility. (Most do not). + +SCTP is not supported on nodes that run Windows. + +#### Support for multihomed SCTP associations {#caveat-sctp-multihomed} + +The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a Pod. + +NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules. + +{{< note >}} +The kube-proxy does not support the management of SCTP associations when it is in userspace mode. +{{< /note >}} + + +### `TCP` {#protocol-tcp} + +You can use TCP for any kind of Service, and it's the default network protocol. + +### `UDP` {#protocol-udp} + +You can use UDP for most Services. For `type: LoadBalancer` Services, +UDP support depends on the cloud provider offering this facility. + + +## Special cases + +### HTTP {#protocol-http-special} + +If your cloud provider supports it, you can use a Service in LoadBalancer mode to +configure a load balancer outside of your Kubernetes cluster, in a special mode +where your cloud provider's load balancer implements HTTP / HTTPS reverse proxying, +with traffic forwarded to the backend endpoints for that Service. + +Typically, you set the protocol for the Service to `TCP` and add an +{{< glossary_tooltip text="annotation" term_id="annotation" >}} +(usually specific to your cloud provider) that configures the load balancer +to handle traffic at the HTTP level. +This configuration might also include serving HTTPS (HTTP over TLS) and +reverse-proxying plain HTTP to your workload. + +{{< note >}} +You can also use an {{< glossary_tooltip term_id="ingress" >}} to expose +HTTP/HTTPS Services. +{{< /note >}} + +You might additionally want to specify that the +[application protocol](/docs/concepts/services-networking/service/#application-protocol) +of the connection is `http` or `https`. Use `http` if the session from the +load balancer to your workload is HTTP without TLS, and use `https` if the +session from the load balancer to your workload uses TLS encryption. + +### PROXY protocol {#protocol-proxy-special} + +If your cloud provider supports it, you can use a Service set to `type: LoadBalancer` +to configure a load balancer outside of Kubernetes itself, that will forward connections +wrapped with the +[PROXY protocol](https://www.haproxy.org/download/2.5/doc/proxy-protocol.txt). + +The load balancer then sends an initial series of octets describing the +incoming connection, similar to this example (PROXY protocol v1): + +``` +PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n +``` + +The data after the proxy protocol preamble are the original +data from the client. When either side closes the connection, +the load balancer also triggers a connection close and sends +any remaining data where feasible. + +Typically, you define a Service with the protocol to `TCP`. +You also set an annotation, specific to your +cloud provider, that configures the load balancer to wrap each incoming connection in the PROXY protocol. + +### TLS {#protocol-tls-special} + +If your cloud provider supports it, you can use a Service set to `type: LoadBalancer` as +a way to set up external reverse proxying, where the connection from client to load +balancer is TLS encrypted and the load balancer is the TLS server peer. +The connection from the load balancer to your workload can also be TLS, +or might be plain text. The exact options available to you depend on your +cloud provider or custom Service implementation. + +Typically, you set the protocol to `TCP` and set an annotation +(usually specific to your cloud provider) that configures the load balancer +to act as a TLS server. You would configure the TLS identity (as server, +and possibly also as a client that connects to your workload) using +mechanisms that are specific to your cloud provider. diff --git a/content/en/docs/reference/networking/virtual-ips.md b/content/en/docs/reference/networking/virtual-ips.md new file mode 100644 index 00000000000..d89d1bcdffc --- /dev/null +++ b/content/en/docs/reference/networking/virtual-ips.md @@ -0,0 +1,343 @@ +--- +title: Virtual IPs and Service Proxies +content_type: reference +weight: 50 +--- + + +Every {{< glossary_tooltip term_id="node" text="node" >}} in a Kubernetes +cluster runs a [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) +(unless you have deployed your own alternative component in place of `kube-proxy`). + +The `kube-proxy` component is responsible for implementing a _virtual IP_ +mechanism for {{< glossary_tooltip term_id="service" text="Services">}} +of `type` other than +[`ExternalName`](/docs/concepts/services-networking/service/#externalname). + + +A question that pops up every now and then is why Kubernetes relies on +proxying to forward inbound traffic to backends. What about other +approaches? For example, would it be possible to configure DNS records that +have multiple A values (or AAAA for IPv6), and rely on round-robin name +resolution? + +There are a few reasons for using proxying for Services: + +* There is a long history of DNS implementations not respecting record TTLs, + and caching the results of name lookups after they should have expired. +* Some apps do DNS lookups only once and cache the results indefinitely. +* Even if apps and libraries did proper re-resolution, the low or zero TTLs + on the DNS records could impose a high load on DNS that then becomes + difficult to manage. + +Later in this page you can read about how various kube-proxy implementations work. +Overall, you should note that, when running `kube-proxy`, kernel level rules may be modified +(for example, iptables rules might get created), which won't get cleaned up, in some +cases until you reboot. Thus, running kube-proxy is something that should only be done +by an administrator which understands the consequences of having a low level, privileged +network proxying service on a computer. Although the `kube-proxy` executable supports a +`cleanup` function, this function is not an official feature and thus is only available +to use as-is. + + + +Some of the details in this reference refer to an example: the back end Pods for a stateless +image-processing workload, running with three replicas. Those replicas are +fungible—frontends do not care which backend they use. While the actual Pods that +compose the backend set may change, the frontend clients should not need to be aware of that, +nor should they need to keep track of the set of backends themselves. + + + + +## Proxy modes + +Note that the kube-proxy starts up in different modes, which are determined by its configuration. + +- The kube-proxy's configuration is done via a ConfigMap, and the ConfigMap for + kube-proxy effectively deprecates the behavior for almost all of the flags for + the kube-proxy. +- The ConfigMap for the kube-proxy does not support live reloading of configuration. +- The ConfigMap parameters for the kube-proxy cannot all be validated and verified on startup. + For example, if your operating system doesn't allow you to run iptables commands, + the standard kernel kube-proxy implementation will not work. + Likewise, if you have an operating system which doesn't support `netsh`, + it will not run in Windows userspace mode. + +### User space proxy mode {#proxy-mode-userspace} + +{{< feature-state for_k8s_version="v1.23" state="deprecated" >}} + +This (legacy) mode uses iptables to install interception rules, and then performs +traffic forwarding with the assistance of the kube-proxy tool. +The kube-procy watches the Kubernetes control plane for the addition, modification +and removal of Service and EndpointSlice objects. For each Service, the kube-proxy +opens a port (randomly chosen) on the local node. Any connections to this _proxy port_ +are proxied to one of the Service's backend Pods (as reported via +EndpointSlices). The kube-proxy takes the `sessionAffinity` setting of the Service into +account when deciding which backend Pod to use. + +The user-space proxy installs iptables rules which capture traffic to the +Service's `clusterIP` (which is virtual) and `port`. Those rules redirect that traffic +to the proxy port which proxies the backend Pod. + +By default, kube-proxy in userspace mode chooses a backend via a round-robin algorithm. + +{{< figure src="/images/docs/services-userspace-overview.svg" title="Services overview diagram for userspace proxy" class="diagram-medium" >}} + + +#### Example {#packet-processing-userspace} + +As an example, consider the image processing application described [earlier](#example) +in the page. +When the backend Service is created, the Kubernetes control plane assigns a virtual +IP address, for example 10.0.0.1. Assuming the Service port is 1234, the +Service is observed by all of the kube-proxy instances in the cluster. +When a proxy sees a new Service, it opens a new random port, establishes an +iptables redirect from the virtual IP address to this new port, and starts accepting +connections on it. + +When a client connects to the Service's virtual IP address, the iptables +rule kicks in, and redirects the packets to the proxy's own port. +The "Service proxy" chooses a backend, and starts proxying traffic from the client to the backend. + +This means that Service owners can choose any port they want without risk of +collision. Clients can connect to an IP and port, without being aware +of which Pods they are actually accessing. + +#### Scaling challenges {#scaling-challenges-userspace} + +Using the userspace proxy for VIPs works at small to medium scale, but will +not scale to very large clusters with thousands of Services. The +[original design proposal for portals](https://github.com/kubernetes/kubernetes/issues/1107) +has more details on this. + +Using the userspace proxy obscures the source IP address of a packet accessing +a Service. +This makes some kinds of network filtering (firewalling) impossible. The iptables +proxy mode does not +obscure in-cluster source IPs, but it does still impact clients coming through +a load balancer or node-port. + +### `iptables` proxy mode {#proxy-mode-iptables} + +In this mode, kube-proxy watches the Kubernetes control plane for the addition and +removal of Service and EndpointSlice objects. For each Service, it installs +iptables rules, which capture traffic to the Service's `clusterIP` and `port`, +and redirect that traffic to one of the Service's +backend sets. For each endpoint, it installs iptables rules which +select a backend Pod. + +By default, kube-proxy in iptables mode chooses a backend at random. + +Using iptables to handle traffic has a lower system overhead, because traffic +is handled by Linux netfilter without the need to switch between userspace and the +kernel space. This approach is also likely to be more reliable. + +If kube-proxy is running in iptables mode and the first Pod that's selected +does not respond, the connection fails. This is different from userspace +mode: in that scenario, kube-proxy would detect that the connection to the first +Pod had failed and would automatically retry with a different backend Pod. + +You can use Pod [readiness probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) +to verify that backend Pods are working OK, so that kube-proxy in iptables mode +only sees backends that test out as healthy. Doing this means you avoid +having traffic sent via kube-proxy to a Pod that's known to have failed. + +{{< figure src="/images/docs/services-iptables-overview.svg" title="Services overview diagram for iptables proxy" class="diagram-medium" >}} + +#### Example {#packet-processing-iptables} + +Again, consider the image processing application described [earlier](#example). +When the backend Service is created, the Kubernetes control plane assigns a virtual +IP address, for example 10.0.0.1. For this example, assume that the +Service port is 1234. +All of the kube-proxy instances in the cluster observe the creation of the new +Service. + +When kube-proxy on a node sees a new Service, it installs a series of iptables rules +which redirect from the virtual IP address to more iptables rules, defined per Service. +The per-Service rules link to further rules for each backend endpoint, and the per- +endpoint rules redirect traffic (using destination NAT) to the backends. + +When a client connects to the Service's virtual IP address the iptables rule kicks in. +A backend is chosen (either based on session affinity or randomly) and packets are +redirected to the backend. Unlike the userspace proxy, packets are never +copied to userspace, the kube-proxy does not have to be running for the virtual +IP address to work, and Nodes see traffic arriving from the unaltered client IP +address. + +This same basic flow executes when traffic comes in through a node-port or +through a load-balancer, though in those cases the client IP address does get altered. + +### IPVS proxy mode {#proxy-mode-ipvs} + +In `ipvs` mode, kube-proxy watches Kubernetes Services and EndpointSlices, +calls `netlink` interface to create IPVS rules accordingly and synchronizes +IPVS rules with Kubernetes Services and EndpointSlices periodically. +This control loop ensures that IPVS status matches the desired +state. +When accessing a Service, IPVS directs traffic to one of the backend Pods. + +The IPVS proxy mode is based on netfilter hook function that is similar to +iptables mode, but uses a hash table as the underlying data structure and works +in the kernel space. +That means kube-proxy in IPVS mode redirects traffic with lower latency than +kube-proxy in iptables mode, with much better performance when synchronizing +proxy rules. Compared to the other proxy modes, IPVS mode also supports a +higher throughput of network traffic. + +IPVS provides more options for balancing traffic to backend Pods; +these are: + +* `rr`: round-robin +* `lc`: least connection (smallest number of open connections) +* `dh`: destination hashing +* `sh`: source hashing +* `sed`: shortest expected delay +* `nq`: never queue + +{{< note >}} +To run kube-proxy in IPVS mode, you must make IPVS available on +the node before starting kube-proxy. + +When kube-proxy starts in IPVS proxy mode, it verifies whether IPVS +kernel modules are available. If the IPVS kernel modules are not detected, then kube-proxy +falls back to running in iptables proxy mode. +{{< /note >}} + +{{< figure src="/images/docs/services-ipvs-overview.svg" title="Services overview diagram for IPVS proxy" class="diagram-medium" >}} + +## Session affinity + +In these proxy models, the traffic bound for the Service's IP:Port is +proxied to an appropriate backend without the clients knowing anything +about Kubernetes or Services or Pods. + +If you want to make sure that connections from a particular client +are passed to the same Pod each time, you can select the session affinity based +on the client's IP addresses by setting `.spec.sessionAffinity` to `ClientIP` +for a Service (the default is `None`). + +### Session stickiness timeout + +You can also set the maximum session sticky time by setting +`.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately for a Service. +(the default value is 10800, which works out to be 3 hours). + +{{< note >}} +On Windows, setting the maximum session sticky time for Services is not supported. +{{< /note >}} + +## IP address assignment to Services + +Unlike Pod IP addresses, which actually route to a fixed destination, +Service IPs are not actually answered by a single host. Instead, kube-proxy +uses packet processing logic (such as Linux iptables) to define _virtual_ IP +addresses which are transparently redirected as needed. + +When clients connect to the VIP, their traffic is automatically transported to an +appropriate endpoint. The environment variables and DNS for Services are actually +populated in terms of the Service's virtual IP address (and port). + +### Avoiding collisions + +One of the primary philosophies of Kubernetes is that you should not be +exposed to situations that could cause your actions to fail through no fault +of your own. For the design of the Service resource, this means not making +you choose your own port number if that choice might collide with +someone else's choice. That is an isolation failure. + +In order to allow you to choose a port number for your Services, we must +ensure that no two Services can collide. Kubernetes does that by allocating each +Service its own IP address from within the `service-cluster-ip-range` +CIDR range that is configured for the API server. + +To ensure each Service receives a unique IP, an internal allocator atomically +updates a global allocation map in {{< glossary_tooltip term_id="etcd" >}} +prior to creating each Service. The map object must exist in the registry for +Services to get IP address assignments, otherwise creations will +fail with a message indicating an IP address could not be allocated. + +In the control plane, a background controller is responsible for creating that +map (needed to support migrating from older versions of Kubernetes that used +in-memory locking). Kubernetes also uses controllers to check for invalid +assignments (e.g. due to administrator intervention) and for cleaning up allocated +IP addresses that are no longer used by any Services. + +#### IP address ranges for Service virtual IP addresses {#service-ip-static-sub-range} + +{{< feature-state for_k8s_version="v1.25" state="beta" >}} + +Kubernetes divides the `ClusterIP` range into two bands, based on +the size of the configured `service-cluster-ip-range` by using the following formula +`min(max(16, cidrSize / 16), 256)`. That formula paraphrases as _never less than 16 or +more than 256, with a graduated step function between them_. + +Kubernetes prefers to allocate dynamic IP addresses to Services by choosing from the upper band, +which means that if you want to assign a specific IP address to a `type: ClusterIP` +Service, you should manually assign an IP address from the **lower** band. That approach +reduces the risk of a conflict over allocation. + +If you disable the `ServiceIPStaticSubrange` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) then Kubernetes +uses a single shared pool for both manually and dynamically assigned IP addresses, +that are used for `type: ClusterIP` Services. + +## Traffic policies + +You can set the `.spec.internalTrafficPolicy` and `.spec.externalTrafficPolicy` fields +to control how Kubernetes routes traffic to healthy (“ready”) backends. + +### Internal traffic policy + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +You can set the `.spec.internalTrafficPolicy` field to control how traffic from +internal sources is routed. Valid values are `Cluster` and `Local`. Set the field to +`Cluster` to route internal traffic to all ready endpoints and `Local` to only route +to ready node-local endpoints. If the traffic policy is `Local` and there are no +node-local endpoints, traffic is dropped by kube-proxy. + +### External traffic policy + +You can set the `.spec.externalTrafficPolicy` field to control how traffic from +external sources is routed. Valid values are `Cluster` and `Local`. Set the field +to `Cluster` to route external traffic to all ready endpoints and `Local` to only +route to ready node-local endpoints. If the traffic policy is `Local` and there are +are no node-local endpoints, the kube-proxy does not forward any traffic for the +relevant Service. + +### Traffic to terminating endpoints + +{{< feature-state for_k8s_version="v1.26" state="beta" >}} + +If the `ProxyTerminatingEndpoints` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +is enabled in kube-proxy and the traffic policy is `Local`, that node's +kube-proxy uses a more complicated algorithm to select endpoints for a Service. +With the feature enabled, kube-proxy checks if the node +has local endpoints and whether or not all the local endpoints are marked as terminating. +If there are local endpoints and **all** of them are terminating, then kube-proxy +will forward traffic to those terminating endpoints. Otherwise, kube-proxy will always +prefer forwarding traffic to endpoints that are not terminating. + +This forwarding behavior for terminating endpoints exist to allow `NodePort` and `LoadBalancer` +Services to gracefully drain connections when using `externalTrafficPolicy: Local`. + +As a deployment goes through a rolling update, nodes backing a load balancer may transition from +N to 0 replicas of that deployment. In some cases, external load balancers can send traffic to +a node with 0 replicas in between health check probes. Routing traffic to terminating endpoints +ensures that Node's that are scaling down Pods can gracefully receive and drain traffic to +those terminating Pods. By the time the Pod completes termination, the external load balancer +should have seen the node's health check failing and fully removed the node from the backend pool. + +## {{% heading "whatsnext" %}} + +To learn more about Services, +read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/). + +You can also: + +* Read about [Services](/docs/concepts/services-networking/service/) +* Read the [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API \ No newline at end of file diff --git a/content/en/docs/reference/node/_index.md b/content/en/docs/reference/node/_index.md index d3004a3849c..9d015e7e3c7 100644 --- a/content/en/docs/reference/node/_index.md +++ b/content/en/docs/reference/node/_index.md @@ -1,4 +1,17 @@ --- title: Node Reference Information weight: 80 +no_list: true --- + +This section contains the following reference topics about nodes: + +* the kubelet's [checkpoint API](/docs/reference/node/kubelet-checkpoint-api/) +* a list of [Articles on dockershim Removal and on Using CRI-compatible Runtimes](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) + +You can also read node reference details from elsewhere in the +Kubernetes documentation, including: + +* [Node Metrics Data](/docs/reference/instrumentation/node-metrics). + + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 9dd86532108..b40a7832646 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -156,13 +156,13 @@ For more information on version skews, see: 2. Download the Google Cloud public signing key: ```shell - sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg + sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg ``` 3. Add the Kubernetes `apt` repository: ```shell - echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list + echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list ``` 4. Update `apt` package index, install kubelet, kubeadm and kubectl, and pin their version: @@ -172,6 +172,10 @@ For more information on version skews, see: sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` +{{< note >}} +In releases older than Debian 12 and Ubuntu 22.04, `/etc/apt/keyrings` does not exist by default. +You can create this directory if you need to, making it world-readable but writeable only by admins. +{{< /note >}} {{% /tab %}} {{% tab name="Red Hat-based distributions" %}} diff --git a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md deleted file mode 100644 index 550772d80c4..00000000000 --- a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -reviewers: -- andrewsykim -- johnbelamaric -- imroc -title: Enabling Service Topology -content_type: task -min-kubernetes-server-version: 1.17 ---- - - -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - -This feature, specifically the alpha `topologyKeys` field, is deprecated since -Kubernetes v1.21. -[Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/), -introduced in Kubernetes v1.21, provide similar functionality. - -_Service Topology_ enables a {{< glossary_tooltip term_id="service">}} to route traffic based upon the Node -topology of the cluster. For example, a service can specify that traffic be -preferentially routed to endpoints that are on the same Node as the client, or -in the same availability zone. - -## {{% heading "prerequisites" %}} - - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -The following prerequisites are needed in order to enable topology aware service -routing: - - * Kubernetes v1.17 or later - * Configure {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} to run in iptables mode or IPVS mode - - - - -## Enable Service Topology - -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - -To enable service topology, enable the `ServiceTopology` -[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for all Kubernetes components: - -``` ---feature-gates="ServiceTopology=true` -``` - -## {{% heading "whatsnext" %}} - -* Read about [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/), the replacement for the `topologyKeys` field. -* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) -* Read about the [Service Topology](/docs/concepts/services-networking/service-topology/) concept -* Read [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) - diff --git a/content/en/docs/tasks/administer-cluster/memory-manager.md b/content/en/docs/tasks/administer-cluster/memory-manager.md index d50f82c43bd..55d61c3313c 100644 --- a/content/en/docs/tasks/administer-cluster/memory-manager.md +++ b/content/en/docs/tasks/administer-cluster/memory-manager.md @@ -92,7 +92,7 @@ illustrates how the management of groups occurs. ## Memory Manager configuration -Other Managers should be first pre-configured. Next, the Memory Manger feature should be enabled +Other Managers should be first pre-configured. Next, the Memory Manager feature should be enabled and be run with `Static` policy (section [Static policy](#policy-static)). Optionally, some amount of memory can be reserved for system or kubelet processes to increase node stability (section [Reserved memory flag](#reserved-memory-flag)). 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 9ebd36c5ee6..51ca8744070 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 @@ -423,7 +423,7 @@ often good enough for the application to load the token on a schedule {{< feature-state for_k8s_version="v1.21" state="stable" >}} -If you have enabled [token projection](#service-account-token-volume-projection) +If you have enabled [token projection](#serviceaccount-token-volume-projection) for ServiceAccounts in your cluster, then you can also make use of the discovery feature. Kubernetes provides a way for clients to federate as an _identity provider_, so that one or more external systems can act as a _relying party_. diff --git a/content/en/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md index 2319a878be3..b02fd03d646 100644 --- a/content/en/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md +++ b/content/en/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md @@ -232,6 +232,8 @@ to collect metrics from each node. Depending on the metrics-server version it us * Metrics resource endpoint `/metrics/resource` in version v0.6.0+ or * Summary API endpoint `/stats/summary` in older versions +## {{% heading "whatsnext" %}} + To learn more about the metrics-server, see the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-server). @@ -243,26 +245,5 @@ You can also check out the following: * [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases) * [Horizontal Pod Autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale/) -### Summary API source - -The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at the node, -volume, pod and container level, and emits this information in -the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) -for consumers to read. - -Here is an example of a Summary API request for a `minikube` node: - -```shell -kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary" -``` - -Here is the same API call using `curl`: - -```shell -curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary -``` - -{{< note >}} -The summary API `/stats/summary` endpoint will be replaced by the `/metrics/resource` endpoint -beginning with metrics-server 0.6.x. -{{< /note >}} +To learn about how the kubelet serves node metrics, and how you can access those via +the Kubernetes API, read [Node Metrics Data](/docs/reference/instrumentation/node-metrics). diff --git a/content/en/docs/tasks/job/job-with-pod-to-pod-communication.md b/content/en/docs/tasks/job/job-with-pod-to-pod-communication.md new file mode 100644 index 00000000000..85c7085f7a8 --- /dev/null +++ b/content/en/docs/tasks/job/job-with-pod-to-pod-communication.md @@ -0,0 +1,128 @@ +--- +title: Job with Pod-to-Pod Communication +content_type: task +min-kubernetes-server-version: v1.21 +weight: 30 +--- + + + +In this example, you will run a Job in [Indexed completion mode](/blog/2021/04/19/introducing-indexed-jobs/) configured such that +the pods created by the Job can communicate with each other using pod hostnames rather than pod IP addresses. + +Pods within a Job might need to communicate among themselves. The user workload running in each pod could query the Kubernetes API server +to learn the IPs of the other Pods, but it's much simpler to rely on Kubernetes' built-in DNS resolution. + +Jobs in Indexed completion mode automatically set the pods' hostname to be in the format of +`${jobName}-${completionIndex}`. You can use this format to deterministically build +pod hostnames and enable pod communication *without* needing to create a client connection to +the Kubernetes control plane to obtain pod hostnames/IPs via API requests. + +This configuration is useful +for use cases where pod networking is required but you don't want to depend on a network +connection with the Kubernetes API server. + +## {{% heading "prerequisites" %}} + +You should already be familiar with the basic use of [Job](/docs/concepts/workloads/controllers/job/). + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{}} +If you are using MiniKube or a similar tool, you may need to take +[extra steps](https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/) +to ensure you have DNS. +{{}} + + + +## Starting a Job with Pod-to-Pod Communication + +To enable pod-to-pod communication using pod hostnames in a Job, you must do the following: + +1. Set up a [headless service](/docs/concepts/services-networking/service/#headless-services) +with a valid label selector for the pods created by your Job. The headless service must be in the same namespace as +the Job. One easy way to do this is to use the `job-name: ` selector, since the `job-name` label will be automatically added by Kubernetes. This configuration will trigger the DNS system to create records of the hostnames of +the pods running your Job. + +2. Configure the headless service as subdomain service for the Job pods by including the following value in your Job template spec: + + ```yaml + subdomain: + ``` + +### Example +Below is a working example of a Job with pod-to-pod communication via pod hostnames enabled. +The Job is completed only after all pods successfully ping each other using hostnames. + +{{}} +In the Bash script executed on each pod in the example below, the pod hostnames can be prefixed +by the namespace as well if the pod needs to be reached from outside the namespace. +{{}} + +```yaml + +apiVersion: v1 +kind: Service +metadata: + name: headless-svc +spec: + clusterIP: None # clusterIP must be None to create a headless service + selector: + job-name: example-job # must match Job name +--- +apiVersion: batch/v1 +kind: Job +metadata: + name: example-job +spec: + completions: 3 + parallelism: 3 + completionMode: Indexed + template: + spec: + subdomain: headless-svc # has to match Service name + restartPolicy: Never + containers: + - name: example-workload + image: bash:latest + command: + - bash + - -c + - | + for i in 0 1 2 + do + gotStatus="-1" + wantStatus="0" + while [ $gotStatus -ne $wantStatus ] + do + ping -c 1 example-job-${i}.headless-svc > /dev/null 2>&1 + gotStatus=$? + if [ $gotStatus -ne $wantStatus ]; then + echo "Failed to ping pod example-job-${i}.headless-svc, retrying in 1 second..." + sleep 1 + fi + done + echo "Successfully pinged pod: example-job-${i}.headless-svc" + done +``` + +After applying the example above, reach each other over the network +using: `.`. You should see output similar to the following: + +```shell +kubectl logs example-job-0-qws42 +``` + +``` +Failed to ping pod example-job-0.headless-svc, retrying in 1 second... +Successfully pinged pod: example-job-0.headless-svc +Successfully pinged pod: example-job-1.headless-svc +Successfully pinged pod: example-job-2.headless-svc +``` + +{{}} +Keep in mind that the `.` name format used +in this example would not work with DNS policy set to `None` or `Default`. +You can learn more about pod DNS policies [here](/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy). +{{}} 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 590bd6d7999..97da59dcdd6 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -47,7 +47,30 @@ horizontal pod autoscaling. ## How does a HorizontalPodAutoscaler work? -{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler controls the scale of a Deployment and its ReplicaSet" class="diagram-medium">}} +{{< mermaid >}} +graph BT + +hpa[Horizontal Pod Autoscaler] --> scale[Scale] + +subgraph rc[RC / Deployment] + scale +end + +scale -.-> pod1[Pod 1] +scale -.-> pod2[Pod 2] +scale -.-> pod3[Pod N] + +classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +class hpa hpa; +class rc rc; +class scale scale; +class pod1,pod2,pod3 pod +{{< /mermaid >}} + +Figure 1. HorizontalPodAutoscaler controls the scale of a Deployment and its ReplicaSet Kubernetes implements horizontal pod autoscaling as a control loop that runs intermittently (it is not a continuous process). The interval is set by the diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md index 5f1b517141a..defc68ad0ae 100644 --- a/content/en/docs/tasks/tools/_index.md +++ b/content/en/docs/tasks/tools/_index.md @@ -35,7 +35,7 @@ shows you what you need to do to get up and running with kind. ## minikube Like `kind`, [`minikube`](https://minikube.sigs.k8s.io/) is a tool that lets you run Kubernetes -locally. `minikube` runs a single-node Kubernetes cluster on your personal +locally. `minikube` runs an all-in-one or a multi-node local Kubernetes cluster on your personal computer (including Windows, macOS and Linux PCs) so that you can try out Kubernetes, or for daily development work. diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index f575b416b0c..a48dcd654e6 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -120,13 +120,13 @@ For example, to download version {{< param "fullversion" >}} on Linux, type: 2. Download the Google Cloud public signing key: ```shell - sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg + sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg ``` 3. Add the Kubernetes `apt` repository: ```shell - echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list + echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list ``` 4. Update `apt` package index with the new repository and install kubectl: @@ -135,6 +135,10 @@ For example, to download version {{< param "fullversion" >}} on Linux, type: sudo apt-get update sudo apt-get install -y kubectl ``` +{{< note >}} +In releases older than Debian 12 and Ubuntu 22.04, `/etc/apt/keyrings` does not exist by default. +You can create this directory if you need to, making it world-readable but writeable only by admins. +{{< /note >}} {{% /tab %}} diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index bb0556a50b0..7a87ed9cee2 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -194,6 +194,7 @@ GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/ ### Chairs +- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) - Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert)) - Stephen Augustus ([@justaugustus](https://github.com/justaugustus)) @@ -201,7 +202,7 @@ GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/ - Adolfo García Veytia ([@puerco](https://github.com/puerco)) - Carlos Panato ([@cpanato](https://github.com/cpanato)) -- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) +- Verónica López ([@verolop](https://github.com/verolop)) --- diff --git a/content/es/docs/concepts/configuration/secret.md b/content/es/docs/concepts/configuration/secret.md index aeb11d0c102..969078a67a4 100644 --- a/content/es/docs/concepts/configuration/secret.md +++ b/content/es/docs/concepts/configuration/secret.md @@ -899,7 +899,7 @@ Un Secret solo se envía a un nodo si un pod en ese nodo lo requiere. Kubelet al Puede haber Secrets para varios Pods en el mismo nodo. Sin embargo, solo los Secrets que solicita un Pod son potencialmente visibles dentro de sus contenedores. Por lo tanto, un Pod no tiene acceso a los Secrets de otro Pod. -Puede haver varios contenedores en un Pod. Sin embargo, cada contenedor en un pod tiene que solicitar el volumen del Secret en su +Puede haber varios contenedores en un Pod. Sin embargo, cada contenedor en un pod tiene que solicitar el volumen del Secret en su `volumeMounts` para que sea visible dentro del contenedor. Esto se puede usar para construir particiones de seguridad útiles en el Pod level](#use-case-secret-visible-to-one-container-in-a-pod). En la mayoría de las distribuciones Kubernetes-project-maintained, la comunicación entre usuario a el apiserver, y del apiserver a kubelets, ista protegido por SSL/TLS. diff --git a/content/fr/docs/concepts/storage/persistent-volumes.md b/content/fr/docs/concepts/storage/persistent-volumes.md index 1f149bb6e55..f4fc315a20f 100644 --- a/content/fr/docs/concepts/storage/persistent-volumes.md +++ b/content/fr/docs/concepts/storage/persistent-volumes.md @@ -242,7 +242,7 @@ Au lieu de cela, un volume existant est redimensionné. #### Redimensionnement de volume CSI -{{< feature-state for_k8s_version="v1.16" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} La prise en charge du redimensionnement des volumes CSI est activée par défaut, mais elle nécessite également un pilote CSI spécifique pour prendre en charge le redimensionnement des volumes. Reportez-vous à la documentation du pilote CSI spécifique pour plus d'informations. diff --git a/content/hi/docs/reference/glossary/replica-set.md b/content/hi/docs/reference/glossary/replica-set.md new file mode 100644 index 00000000000..83aa7d27eb8 --- /dev/null +++ b/content/hi/docs/reference/glossary/replica-set.md @@ -0,0 +1,20 @@ +--- +title: रेप्लिकासेट (ReplicaSet) +id: replica-set +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/replicaset/ +short_description: > + रेप्लिकासेट यह सुनिश्चित करता है कि किसी एक अवसर पर निर्दिष्ट संख्या में पॉड प्रतिकृतियां चल रही हैं। + +aka: +tags: +- fundamental +- core-object +- workload +--- + एक रेप्लिकासेट (का उद्देश्य) किसी भी समय चल रहे रेप्लिका पॉड्स का एक समूह बनाए रखना है। + + + +वर्कलोड ऑब्जेक्ट्स, जैसे {{< glossary_tooltip text="डिप्लॉयमेंट" term_id="deployment" >}}, रेप्लिकासेट्स +के विनिर्देश के आधार पर आपके क्लस्टर पर कॉन्फ़िगर की गई संख्या में {{< glossary_tooltip term_id="pod" text="पॉड्स" >}} चल रहे है ये सुनिश्चित करते हैं। diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 5885e529631..262fea7e00c 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -91,7 +91,7 @@ Kubernetes {{< param "version" >}}では、OpenAPI v3によるAPI仕様をベー } } ``` - + クライアントサイドのキャッシングを改善するために、相対URLはイミュータブルな(不変の)OpenAPI記述を指しています。 また、APIサーバーも、同様の目的で適切なHTTPキャッシュヘッダー(`Expires`には1年先の日付、`Cache-Control`には`immutable`)をセットします。廃止されたURLが使用された場合、APIサーバーは最新のURLへのリダイレクトを返します。 diff --git a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md index f88da29e8ff..c50c0756a35 100644 --- a/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ja/docs/concepts/scheduling-eviction/pod-overhead.md @@ -6,7 +6,7 @@ weight: 30 -{{< feature-state for_k8s_version="v1.18" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} PodをNode上で実行する時に、Pod自身は大量のシステムリソースを消費します。これらのリソースは、Pod内のコンテナ(群)を実行するために必要なリソースとして追加されます。Podのオーバーヘッドは、コンテナの要求と制限に加えて、Podのインフラストラクチャで消費されるリソースを計算するための機能です。 @@ -29,16 +29,15 @@ Podのオーバーヘッドを有効にした場合、Podのスケジューリ Podのオーバーヘッド機能を使用するためには、`overhead`フィールドが定義されたRuntimeClassが必要です。例として、仮想マシンとゲストOSにPodあたり約120MiBを使用する仮想化コンテナランタイムで、次のようなRuntimeClassを定義できます。 ```yaml ---- -kind: RuntimeClass apiVersion: node.k8s.io/v1 +kind: RuntimeClass metadata: - name: kata-fc + name: kata-fc handler: kata-fc overhead: - podFixed: - memory: "120Mi" - cpu: "250m" + podFixed: + memory: "120Mi" + cpu: "250m" ``` `kata-fc`RuntimeClassハンドラーを指定して作成されたワークロードは、リソースクォータの計算や、Nodeのスケジューリング、およびPodのcgroupのサイズ決定にメモリーとCPUのオーバーヘッドが考慮されます。 @@ -54,7 +53,7 @@ spec: runtimeClassName: kata-fc containers: - name: busybox-ctr - image: busybox + image: busybox:1.28 stdin: true tty: true resources: @@ -108,9 +107,9 @@ kubectl describe node | grep test-pod -B2 出力では、2250mのCPUと320MiBのメモリーが要求されており、Podのオーバーヘッドが含まれていることが分かります。 ``` - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE - --------- ---- ------------ ---------- --------------- ------------- --- - default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m ``` ## Podのcgroupの制限を確認 @@ -132,7 +131,7 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath 結果のcgroupパスにはPodの`ポーズ中`コンテナも含まれます。Podレベルのcgroupは１つ上のディレクトリです。 ``` - "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" + "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` 今回のケースでは、Podのcgroupパスは、`kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`となります。メモリーのPodレベルのcgroupの設定を確認しましょう。 diff --git a/content/ja/docs/concepts/services-networking/service-topology.md b/content/ja/docs/concepts/services-networking/service-topology.md index 1df3ad8b1eb..95f8e85b6b2 100644 --- a/content/ja/docs/concepts/services-networking/service-topology.md +++ b/content/ja/docs/concepts/services-networking/service-topology.md @@ -5,13 +5,17 @@ feature: description: > Serviceのトラフィックをクラスタートポロジーに基づいてルーティングします。 content_type: concept -weight: 10 +weight: 150 --- -{{< feature-state for_k8s_version="v1.17" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + +{{< note >}} +この機能、特にアルファ版の`topologyKeys`APIは、Kubernetes v1.21以降では非推奨です。Kubernetes v1.21で導入された、[トポロジーを意識したヒント](/ja/docs/concepts/services-networking/topology-aware-hints/)が同様の機能を提供します。 +{{}} *Serviceトポロジー*を利用すると、Serviceのトラフィックをクラスターのノードトポロジーに基づいてルーティングできるようになります。たとえば、あるServiceのトラフィックに対して、できるだけ同じノードや同じアベイラビリティゾーン上にあるエンドポイントを優先してルーティングするように指定できます。 @@ -139,6 +143,6 @@ spec: ## {{% heading "whatsnext" %}} -* [Serviceトポトジーを有効にする](/ja/docs/tasks/administer-cluster/enabling-service-topology)を読む。 -* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。 +* [トポロジーを意識したヒント](/ja/docs/concepts/services-networking/topology-aware-hints/)を読む。 +* [サービスとアプリケーションの接続](/ja/docs/tutorials/services/connect-applications-service/)を読む。 diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 7f6b65b8c24..d976b7ef29c 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -243,7 +243,7 @@ PVCに対してさらに大きなボリュームを要求するには、PVCオ #### CSIボリュームの拡張 -{{< feature-state for_k8s_version="v1.16" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} CSIボリュームの拡張のサポートはデフォルトで有効になっていますが、ボリューム拡張をサポートするにはボリューム拡張を利用できるCSIドライバーも必要です。詳細については、それぞれのCSIドライバーのドキュメントを参照してください。 diff --git a/content/ja/docs/concepts/storage/volume-health-monitoring.md b/content/ja/docs/concepts/storage/volume-health-monitoring.md new file mode 100644 index 00000000000..825572faf99 --- /dev/null +++ b/content/ja/docs/concepts/storage/volume-health-monitoring.md @@ -0,0 +1,30 @@ +--- +title: ボリュームヘルスモニタリング +content_type: concept +weight: 100 +--- + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +{{< glossary_tooltip text="CSI" term_id="csi" >}}ボリュームヘルスモニタリングにより、CSIドライバーは、基盤となるストレージシステムから異常なボリューム状態を検出し、それらを{{< glossary_tooltip text="PVC" term_id= "persistent-volume-claim" >}}または{{< glossary_tooltip text="Pod" term_id="pod" >}}のイベントとして報告できます。 + + +## ボリュームヘルスモニタリング + +Kubernetes _volume health monitoring_ は、KubernetesがContainerStorageInterface(CSI)を実装する方法の一部です。ボリュームヘルスモニタリング機能は、外部のヘルスモニターコントローラーと{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}の2つのコンポーネントで実装されます。 + +CSIドライバーがコントローラー側からのボリュームヘルスモニタリング機能をサポートしている場合、CSIボリュームで異常なボリューム状態が検出されると、関連する{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}(PVC)でイベントが報告されます。 + +外部ヘルスモニター{{< glossary_tooltip text="コントローラー" term_id="controller" >}}も、ノード障害イベントを監視します。`enable-node-watcher`フラグをtrueに設定することで、ノード障害の監視を有効にできます。外部ヘルスモニターがノード障害イベントを検出すると、コントローラーは、このPVCを使用するポッドが障害ノード上にあることを示すために、PVCでイベントが報告されることを報告します。 + +CSIドライバーがノード側からのボリュームヘルスモニタリング機能をサポートしている場合、CSIボリュームで異常なボリューム状態が検出されると、PVCを使用するすべてのPodでイベントが報告されます。さらに、ボリュームヘルス情報はKubelet VolumeStatsメトリクスとして公開されます。新しいメトリックkubelet_volume_stats_health_status_abnormalが追加されました。このメトリックには`namespace`と`persistentvolumeclaim`の2つのラベルが含まれます。カウントは1または0です。1はボリュームが異常であることを示し、0はボリュームが正常であることを示します。詳細については、[KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)を確認してください。 + +{{< note >}} +ノード側からこの機能を使用するには、`CSIVolumeHealth`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。 +{{< /note >}} + +## {{% heading "whatsnext" %}} + +[CSIドライバーのドキュメント](https://kubernetes-csi.github.io/docs/drivers.html)を参照して、この機能を実装しているCSIドライバーを確認してください。 diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index b8b84402e61..9150d77b499 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -35,121 +35,154 @@ content_type: concept | 機能名 | デフォルト値 | ステージ | 導入開始バージョン | 最終利用可能バージョン | |---------|---------|-------|-------|-------| -| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | | | `APIListChunking` | `false` | Alpha | 1.8 | 1.8 | | `APIListChunking` | `true` | Beta | 1.9 | | -| `APIPriorityAndFairness` | `false` | Alpha | 1.17 | | -| `APIResponseCompression` | `false` | Alpha | 1.7 | | +| `APIPriorityAndFairness` | `false` | Alpha | 1.18 | 1.19 | +| `APIPriorityAndFairness` | `true` | Beta | 1.20 | | +| `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 | +| `APIResponseCompression` | `true` | Beta | 1.16 | | +| `APIServerIdentity` | `false` | Alpha | 1.20 | | +| `APIServerTracing` | `false` | Alpha | 1.22 | | +| `AllowInsecureBackendProxy` | `true` | Beta | 1.17 | | +| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | 1.23 | +| `AnyVolumeDataSource` | `true` | Beta | 1.24 | | | `AppArmor` | `true` | Beta | 1.4 | | -| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | | -| `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | | | `CPUManager` | `false` | Alpha | 1.8 | 1.9 | | `CPUManager` | `true` | Beta | 1.10 | | -| `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 | -| `CRIContainerLogRotation` | `true` | Beta| 1.11 | | -| `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 | -| `CSIInlineVolume` | `true` | Beta | 1.16 | - | -| `CSIMigration` | `false` | Alpha | 1.14 | 1.16 | -| `CSIMigration` | `true` | Beta | 1.17 | | -| `CSIMigrationAWS` | `false` | Alpha | 1.14 | | -| `CSIMigrationAWS` | `false` | Beta | 1.17 | | -| `CSIMigrationAWSComplete` | `false` | Alpha | 1.17 | | -| `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | | -| `CSIMigrationAzureDiskComplete` | `false` | Alpha | 1.17 | | -| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | | -| `CSIMigrationAzureFileComplete` | `false` | Alpha | 1.17 | | -| `CSIMigrationGCE` | `false` | Alpha | 1.14 | 1.16 | -| `CSIMigrationGCE` | `false` | Beta | 1.17 | | -| `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | | -| `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | | -| `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | | -| `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | | +| `CPUManagerPolicyAlphaOptions` | `false` | Alpha | 1.23 | | +| `CPUManagerPolicyBetaOptions` | `true` | Beta | 1.23 | | +| `CPUManagerPolicyOptions` | `false` | Alpha | 1.22 | 1.22 | +| `CPUManagerPolicyOptions` | `true` | Beta | 1.23 | | +| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | 1.20 | +| `CSIMigrationAzureFile` | `false` | Beta | 1.21 | 1.23 | +| `CSIMigrationAzureFile` | `true` | Beta | 1.24 | | +| `CSIMigrationPortworx` | `false` | Alpha | 1.23 | 1.24 | +| `CSIMigrationPortworx` | `false` | Beta | 1.25 | | +| `CSIMigrationRBD` | `false` | Alpha | 1.23 | | +| `CSIMigrationvSphere` | `false` | Alpha | 1.18 | 1.18 | +| `CSIMigrationvSphere` | `false` | Beta | 1.19 | 1.24 | +| `CSIMigrationvSphere` | `true` | Beta | 1.25 | | +| `CSINodeExpandSecret` | `false` | Alpha | 1.25 | | +| `CSIVolumeHealth` | `false` | Alpha | 1.21 | | +| `ContainerCheckpoint` | `false` | Alpha | 1.25 | | +| `ContextualLogging` | `false` | Alpha | 1.24 | | | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | | -| `CustomResourceDefaulting` | `false` | Alpha| 1.15 | 1.15 | -| `CustomResourceDefaulting` | `true` | Beta | 1.16 | | +| `CustomResourceValidationExpressions` | `false` | Alpha | 1.23 | 1.24 | +| `CustomResourceValidationExpressions` | `true` | Beta | 1.25 | | +| `DelegateFSGroupToCSIDriver` | `false` | Alpha | 1.22 | 1.22 | +| `DelegateFSGroupToCSIDriver` | `true` | Beta | 1.23 | | | `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 | | `DevicePlugins` | `true` | Beta | 1.10 | | -| `DryRun` | `false` | Alpha | 1.12 | 1.12 | -| `DryRun` | `true` | Beta | 1.13 | | -| `DynamicAuditing` | `false` | Alpha | 1.13 | | -| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 | -| `DynamicKubeletConfig` | `true` | Beta | 1.11 | | -| `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 | -| `EndpointSlice` | `false` | Beta | 1.17 | | -| `EndpointSlice` | `true` | Beta | 1.18 | | -| `EndpointSliceProxying` | `false` | Alpha | 1.18 | | -| `EphemeralContainers` | `false` | Alpha | 1.16 | | -| `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 | -| `ExpandCSIVolumes` | `true` | Beta | 1.16 | | -| `ExpandInUsePersistentVolumes` | `false` | Alpha | 1.11 | 1.14 | -| `ExpandInUsePersistentVolumes` | `true` | Beta | 1.15 | | -| `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 | -| `ExpandPersistentVolumes` | `true` | Beta | 1.11 | | +| `DisableCloudProviders` | `false` | Alpha | 1.22 | | +| `DisableKubeletCloudCredentialProviders` | `false` | Alpha | 1.23 | | +| `DownwardAPIHugePages` | `false` | Alpha | 1.20 | 1.20 | +| `DownwardAPIHugePages` | `false` | Beta | 1.21 | 1.21 | +| `DownwardAPIHugePages` | `true` | Beta | 1.22 | | +| `EndpointSliceTerminatingCondition` | `false` | Alpha | 1.20 | 1.21 | +| `EndpointSliceTerminatingCondition` | `true` | Beta | 1.22 | | +| `ExpandedDNSConfig` | `false` | Alpha | 1.22 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | | -| `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 | -| `EvenPodsSpread` | `true` | Beta | 1.18 | | +| `GRPCContainerProbe` | `false` | Alpha | 1.23 | 1.23 | +| `GRPCContainerProbe` | `true` | Beta | 1.24 | | +| `GracefulNodeShutdown` | `false` | Alpha | 1.20 | 1.20 | +| `GracefulNodeShutdown` | `true` | Beta | 1.21 | | +| `GracefulNodeShutdownBasedOnPodPriority` | `false` | Alpha | 1.23 | 1.23 | +| `GracefulNodeShutdownBasedOnPodPriority` | `true` | Beta | 1.24 | | +| `HPAContainerMetrics` | `false` | Alpha | 1.20 | | | `HPAScaleToZero` | `false` | Alpha | 1.16 | | -| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | | -| `HyperVContainer` | `false` | Alpha | 1.10 | | -| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | | +| `HonorPVReclaimPolicy` | `false` | Alpha | 1.23 | | +| `InTreePluginAWSUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginAzureDiskUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginAzureFileUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginGCEUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginOpenStackUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginPortworxUnregister` | `false` | Alpha | 1.23 | | +| `InTreePluginRBDUnregister` | `false` | Alpha | 1.23 | | +| `InTreePluginvSphereUnregister` | `false` | Alpha | 1.21 | | +| `IPTablesOwnershipCleanup` | `false` | Alpha | 1.25 | | +| `JobMutableNodeSchedulingDirectives` | `true` | Beta | 1.23 | | +| `JobPodFailurePolicy` | `false` | Alpha | 1.25 | - | +| `JobReadyPods` | `false` | Alpha | 1.23 | 1.23 | +| `JobReadyPods` | `true` | Beta | 1.24 | | +| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | 1.22 | +| `JobTrackingWithFinalizers` | `false` | Beta | 1.23 | 1.24 | +| `JobTrackingWithFinalizers` | `true` | Beta | 1.25 | | +| `KubeletCredentialProviders` | `false` | Alpha | 1.20 | 1.23 | +| `KubeletCredentialProviders` | `true` | Beta | 1.24 | | +| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | | | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | -| `LegacyNodeRoleBehavior` | `true` | Alpha | 1.16 | | -| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 | -| `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | | -| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | | -| `MountContainers` | `false` | Alpha | 1.9 | | -| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | | -| `NonPreemptingPriority` | `false` | Alpha | 1.15 | | -| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 | -| `PodDisruptionBudget` | `true` | Beta | 1.5 | | -| `PodOverhead` | `false` | Alpha | 1.16 | - | +| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | 1.22 | +| `KubeletPodResourcesGetAllocatable` | `true` | Beta | 1.23 | | +| `KubeletTracing` | `false` | Alpha | 1.25 | | +| `LegacyServiceAccountTokenNoAutoGeneration` | `true` | Beta | 1.24 | | +| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | 1.24 | +| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `true` | Beta | 1.25 | | +| `LogarithmicScaleDown` | `false` | Alpha | 1.21 | 1.21 | +| `LogarithmicScaleDown` | `true` | Beta | 1.22 | | +| `MatchLabelKeysInPodTopologySpread` | `false` | Alpha | 1.25 | | +| `MaxUnavailableStatefulSet` | `false` | Alpha | 1.24 | | +| `MemoryManager` | `false` | Alpha | 1.21 | 1.21 | +| `MemoryManager` | `true` | Beta | 1.22 | | +| `MemoryQoS` | `false` | Alpha | 1.22 | | +| `MinDomainsInPodTopologySpread` | `false` | Alpha | 1.24 | 1.24 | +| `MinDomainsInPodTopologySpread` | `false` | Beta | 1.25 | | +| `MixedProtocolLBService` | `false` | Alpha | 1.20 | 1.23 | +| `MixedProtocolLBService` | `true` | Beta | 1.24 | | +| `MultiCIDRRangeAllocator` | `false` | Alpha | 1.25 | | +| `NetworkPolicyStatus` | `false` | Alpha | 1.24 | | +| `NodeInclusionPolicyInPodTopologySpread` | `false` | Alpha | 1.25 | | +| `NodeOutOfServiceVolumeDetach` | `false` | Alpha | 1.24 | | +| `NodeSwap` | `false` | Alpha | 1.22 | | +| `OpenAPIEnums` | `false` | Alpha | 1.23 | 1.23 | +| `OpenAPIEnums` | `true` | Beta | 1.24 | | +| `OpenAPIV3` | `false` | Alpha | 1.23 | 1.23 | +| `OpenAPIV3` | `true` | Beta | 1.24 | | +| `PodAndContainerStatsFromCRI` | `false` | Alpha | 1.23 | | +| `PodDeletionCost` | `false` | Alpha | 1.21 | 1.21 | +| `PodDeletionCost` | `true` | Beta | 1.22 | | +| `PodDisruptionConditions` | `false` | Alpha | 1.25 | - | +| `PodHasNetworkCondition` | `false` | Alpha | 1.25 | | +| `ProbeTerminationGracePeriod` | `false` | Alpha | 1.21 | 1.21 | +| `ProbeTerminationGracePeriod` | `false` | Beta | 1.22 | 1.24 | +| `ProbeTerminationGracePeriod` | `true` | Beta | 1.25 | | | `ProcMountType` | `false` | Alpha | 1.12 | | +| `ProxyTerminatingEndpoints` | `false` | Alpha | 1.22 | | | `QOSReserved` | `false` | Alpha | 1.11 | | -| `RemainingItemCount` | `false` | Alpha | 1.15 | | -| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | | -| `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | | +| `ReadWriteOncePod` | `false` | Alpha | 1.22 | | +| `RecoverVolumeExpansionFailure` | `false` | Alpha | 1.23 | | +| `RemainingItemCount` | `false` | Alpha | 1.15 | 1.15 | +| `RemainingItemCount` | `true` | Beta | 1.16 | | +| `RetroactiveDefaultStorageClass` | `false` | Alpha | 1.25 | | | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | | -| `RunAsGroup` | `true` | Beta | 1.14 | | -| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 | -| `RuntimeClass` | `true` | Beta | 1.14 | | -| `SCTPSupport` | `false` | Alpha | 1.12 | | -| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | -| `ServerSideApply` | `true` | Beta | 1.16 | | -| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | | -| `ServiceAppProtocol` | `false` | Alpha | 1.18 | | -| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | | -| `ServiceTopology` | `false` | Alpha | 1.17 | | -| `StartupProbe` | `false` | Alpha | 1.16 | 1.17 | -| `StartupProbe` | `true` | Beta | 1.18 | | +| `SELinuxMountReadWriteOncePod` | `false` | Alpha | 1.25 | | +| `SeccompDefault` | `false` | Alpha | 1.22 | 1.24 | +| `SeccompDefault` | `true` | Beta | 1.25 | | +| `ServerSideFieldValidation` | `false` | Alpha | 1.23 | 1.24 | +| `ServerSideFieldValidation` | `true` | Beta | 1.25 | | +| `ServiceIPStaticSubrange` | `false` | Alpha | 1.24 | 1.24 | +| `ServiceIPStaticSubrange` | `true` | Beta | 1.25 | | +| `ServiceInternalTrafficPolicy` | `false` | Alpha | 1.21 | 1.21 | +| `ServiceInternalTrafficPolicy` | `true` | Beta | 1.22 | | +| `SizeMemoryBackedVolumes` | `false` | Alpha | 1.20 | 1.21 | +| `SizeMemoryBackedVolumes` | `true` | Beta | 1.22 | | +| `StatefulSetAutoDeletePVC` | `false` | Alpha | 1.22 | | +| `StorageVersionAPI` | `false` | Alpha | 1.20 | | | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 | | `StorageVersionHash` | `true` | Beta | 1.15 | | -| `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 | -| `StreamingProxyRedirects` | `true` | Beta | 1.6 | | -| `SupportNodePidsLimit` | `false` | Alpha | 1.14 | 1.14 | -| `SupportNodePidsLimit` | `true` | Beta | 1.15 | | -| `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 | -| `SupportPodPidsLimit` | `true` | Beta | 1.14 | | -| `Sysctls` | `true` | Beta | 1.11 | | -| `TokenRequest` | `false` | Alpha | 1.10 | 1.11 | -| `TokenRequest` | `true` | Beta | 1.12 | | -| `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 | -| `TokenRequestProjection` | `true` | Beta | 1.12 | | -| `TTLAfterFinished` | `false` | Alpha | 1.12 | 1.20 | -| `TTLAfterFinished` | `true` | Beta | 1.21 | | +| `TopologyAwareHints` | `false` | Alpha | 1.21 | 1.22 | +| `TopologyAwareHints` | `false` | Beta | 1.23 | 1.23 | +| `TopologyAwareHints` | `true` | Beta | 1.24 | | | `TopologyManager` | `false` | Alpha | 1.16 | 1.17 | | `TopologyManager` | `true` | Beta | 1.18 | | -| `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 | -| `ValidateProxyRedirects` | `true` | Beta | 1.14 | | -| `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 | -| `VolumePVCDataSource` | `true` | Beta | 1.16 | | -| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 | -| `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | - | -| `WindowsGMSA` | `false` | Alpha | 1.14 | | -| `WindowsGMSA` | `true` | Beta | 1.16 | | +| `UserNamespacesStatelessPodsSupport` | `false` | Alpha | 1.25 | | +| `VolumeCapacityPriority` | `false` | Alpha | 1.21 | - | | `WinDSR` | `false` | Alpha | 1.14 | | -| `WinOverlay` | `false` | Alpha | 1.14 | | +| `WinOverlay` | `false` | Alpha | 1.14 | 1.19 | +| `WinOverlay` | `true` | Beta | 1.20 | | +| `WindowsHostProcessContainers` | `false` | Alpha | 1.22 | 1.22 | +| `WindowsHostProcessContainers` | `true` | Beta | 1.23 | | {{< /table >}} ### GraduatedまたはDeprecatedのフィーチャーゲート {#feature-gates-for-graduated-or-deprecated-features} diff --git a/content/ja/docs/reference/tools.md b/content/ja/docs/reference/tools.md index 7c6548b24ac..dc925deffa9 100644 --- a/content/ja/docs/reference/tools.md +++ b/content/ja/docs/reference/tools.md @@ -11,7 +11,7 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組 [`kubectl`](/ja/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。 ## Kubeadm -[`kubeadm`](docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。 +[`kubeadm`](/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。 ## Minikube [`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。 diff --git a/content/ja/docs/tasks/administer-cluster/enabling-service-topology.md b/content/ja/docs/tasks/administer-cluster/enabling-service-topology.md deleted file mode 100644 index 304e0937a63..00000000000 --- a/content/ja/docs/tasks/administer-cluster/enabling-service-topology.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Serviceトポロジーを有効にする -content_type: task ---- - - -このページでは、Kubernetes上でServiceトポロジーを有効にする方法の概要について説明します。 - - -## {{% heading "prerequisites" %}} - - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - - -## はじめに - -*Serviceトポロジー*は、クラスターのノードのトポロジーに基づいてトラフィックをルーティングできるようにする機能です。たとえば、あるServiceのトラフィックに対して、できるだけ同じノードや同じアベイラビリティゾーン上にあるエンドポイントを優先してルーティングするように指定できます。 - -## 前提 - -トポロジーを考慮したServiceのルーティングを有効にするには、以下の前提を満たしている必要があります。 - - * Kubernetesバージョン1.17以降である - * {{< glossary_tooltip text="Kube-proxy" term_id="kube-proxy" >}}がiptableモードまたはIPVSモードで稼働している - * [Endpoint Slice](/docs/concepts/services-networking/endpoint-slices/)を有効にしている - -## Serviceトポロジーを有効にする - -{{< feature-state for_k8s_version="v1.17" state="alpha" >}} - -Serviceトポロジーを有効にするには、すべてのKubernetesコンポーネントで`ServiceTopology`と`EndpointSlice`フィーチャーゲートを有効にする必要があります。 - -``` ---feature-gates="ServiceTopology=true,EndpointSlice=true" -``` - -## {{% heading "whatsnext" %}} - -* [Serviceトポロジー](/ja/docs/concepts/services-networking/service-topology)のコンセプトについて読む -* [Endpoint Slice](/docs/concepts/services-networking/endpoint-slices)について読む -* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む - diff --git a/content/ko/_index.html b/content/ko/_index.html index 741e7ecd2f1..9decd7e08ea 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -8,7 +8,7 @@ sitemap: {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} -K8s라고도 알려진 [쿠버네티스]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. +K8s라고도 알려진 [쿠버네티스]({{< relref "/docs/concepts/overview/" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. 애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](https://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다. {{% /blocks/feature %}} diff --git a/content/ko/blog/_posts/2018-11-07-grpc-load-balancing-with-linkerd.md b/content/ko/blog/_posts/2018-11-07-grpc-load-balancing-with-linkerd.md new file mode 100644 index 00000000000..05ba02ada82 --- /dev/null +++ b/content/ko/blog/_posts/2018-11-07-grpc-load-balancing-with-linkerd.md @@ -0,0 +1,173 @@ +--- +layout: blog +title: '쿠버네티스에서 어려움 없이 gRPC 로드밸런싱하기' +date: 2018-11-07 +--- + +**저자**: William Morgan (Buoyant) + +**번역**: 송원석 (쏘카), 김상홍 (국민대), 손석호 (ETRI) + +다수의 새로운 gRPC 사용자는 쿠버네티스의 기본 로드 +밸런싱이 종종 작동하지 않는 것에 놀란다. 예를 들어, 만약 +[단순한 gRPC Node.js 마이크로서비스 +앱](https://github.com/sourishkrout/nodevoto)을 만들고 쿠버네티스에 배포하면 어떤 일이 생기는지 살펴보자. + +![](/images/blog/grpc-load-balancing-with-linkerd/Screenshot2018-11-0116-c4d86100-afc1-4a08-a01c-16da391756dd.34.36.png) + +여기 표시된 `voting` 서비스는 여러 개의 파드로 구성되어 있지만, 쿠버네티스의 CPU 그래프는 명확하게 +파드 중 하나만 실제 작업을 수행하고 있는 것(하나의 파드만 트래픽을 수신하고 있으므로)을 +보여준다. 왜 그런 것일까? + +이 블로그 게시물에서는, 이런 일이 발생하는 이유를 설명하고, +[CNCF](https://cncf.io)의 서비스 메시(mesh)인 [Linkerd](https://linkerd.io) 및 서비스 사이드카(sidecar)를 활용한 +gRPC 로드밸런싱을 쿠버네티스 앱에 추가하여, 이 문제를 쉽게 해결할 수 있는 방법을 설명한다. + +# 왜 gRPC에 특별한 로드밸런싱이 필요한가? + +먼저, 왜 gRPC를 위해 특별한 작업이 필요한지 살펴보자. + +gRPC는 애플리케이션 개발자에게 점점 더 일반적인 선택지가 되고 있다. +JSON-over-HTTP와 같은 대체 프로토콜에 비해, gRPC는 +극적으로 낮은 (역)직렬화 비용과, 자동 타입 +체크, 공식화된 APIs, 적은 TCP 관리 오버헤드 등에 상당한 이점이 있다. + +그러나, gRPC는 쿠버네티스에서 제공하는 것과 마찬가지로 +표준(일반)적으로 사용되는 연결 수준 로드밸런싱(connection-level load balancing)을 어렵게 만드는 측면도 있다. gRPC는 HTTP/2로 +구축되었고, HTTP/2는 하나의 오래 지속되는 TCP 연결을 갖도록 설계되있기 때문에, +모든 요청은 *다중화(multiplexed)*(특정 시점에 다수의 요청이 +하나의 연결에서만 동작하는 것을 의미)된다. 일반적으로, 그것은 +연결 관리 오버헤드를 줄이는 장점이 있다. 그러나, 그것은 또한 +(상상할 수 있듯이) 연결 수준의 밸런싱(balancing)에는 유용하지 않다는 것을 의미한다. 일단 +연결이 설정되면, 더 이상 밸런싱을 수행할 수 없기 때문이다. 모든 요청이 +아래와 같이 단일 파드에 고정될 것이다. + +![](/images/blog/grpc-load-balancing-with-linkerd/Mono-8d2e53ef-b133-4aa0-9551-7e36a880c553.png) + +# 왜 HTTP/1.1에는 이러한 일이 발생하지 않는가? + +HTTP/1.1 또한 수명이 긴 연결의 개념이 있지만, +HTTP/1.1에는 TCP 연결을 순환시키게 만드는 여러 특징들이 있기 때문에, +이러한 문제가 발생하지 않는다. 그래서, +연결 수준 밸런싱은 "충분히 양호"하며, 대부분의 HTTP/1.1 앱에 대해서는 +더 이상 아무것도 할 필요가 없다. + +그 이유를 이해하기 위해, HTTP/1.1을 자세히 살펴보자. HTTP/2와 달리 +HTTP/1.1은 요청을 다중화할 수 없다. TCP 연결 시점에 하나의 HTTP 요청만 +활성화될 수 있다. 예를 들어 클라이언트가 'GET /foo'를 요청하고, +서버가 응답할 때까지 대기한다. 요청-응답 주기가 +발생하면, 해당 연결에서 다른 요청을 실행할 수 없다. + +일반적으로, 우리는 병렬로 많은 요청이 발생하기 원한다. 그러므로, +HTTP/1.1 동시 요청을 위해, 여러 HTTP/1.1 연결을 만들어야 하고, +그 모두에 걸쳐 우리의 요청을 발행해야 한다. 또한, 수명이 긴 HTTP/1.1 +연결은 일반적으로 일정 시간 후 만료되고 클라이언트(또는 서버)에 의해 끊어진다. +이 두 가지 요소를 결합하면 일반적으로 HTTP/1.1 요청이 +여러 TCP 연결에서 순환하며, 연결 수준 밸런싱이 작동한다. + +# 그래서 우리는 어떻게 gRPC의 부하를 분산할 수 있을까?? + +이제 gRPC로 돌아가보자. 연결 수준에서 밸런싱을 맞출 수 없기 때문에, gRPC 로드 밸런싱을 +수행하려면, 연결 밸런싱에서 *요청* 밸런싱으로 전환해야 +한다. 즉, 각각에 대한 HTTP/2 연결을 열어야 +하고, 아래와 같이, 이러한 연결들로 *요청*의 밸런싱을 맞춘다. + +![](/images/blog/grpc-load-balancing-with-linkerd/Stereo-09aff9d7-1c98-4a0a-9184-9998ed83a531.png) + +네트워크 측면에서, L3/L4에서 결정을 내리기 보다는 L5/L7에서 결정을 +내려야 한다. 즉, TCP 연결을 통해 전송된 프로토콜을 이해해야 한다. + +우리는 이것을 어떻게 달성해야할까? 몇 가지 옵션이 있다. 먼저, 우리의 애플리케이션 +코드는 대상에 대한 자체 로드 밸런싱 풀을 수동으로 유지 관리할 수 있고, +gRPC 클라이언트에 [로드 밸런싱 풀을 +사용](https://godoc.org/google.golang.org/grpc/balancer)하도록 구성할 수 있다. 이 접근 방식은 +우리에게 높은 제어력을 제공하지만, 시간이 지남에 따라 파드가 리스케줄링(reschedule)되면서 풀이 변경되는 +쿠버네티스와 같은 환경에서는 매우 복잡할 수 있다. 이 경우, 우리의 +애플리케이션은 파드와 쿠버네티스 API를 관찰하고 자체적으로 최신 상태를 +유지해야 한다. + +대안으로, 쿠버네티스에서 앱을 [헤드리스(headless) +서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)로 배포할 수 있다. +이 경우, 쿠버네티스는 서비스를 위한 DNS 항목에 +[다중 A 레코드를 생성할 것이다](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스). +만약 충분히 진보한 gRPC 클라이언트를 사용한다면, +해당 DNS 항목에서 로드 밸런싱 풀을 자동으로 유지 관리할 수 있다. +그러나 이 접근 방식은 우리를 특정 gRPC 클라이언트로를 사용하도록 제한할 뿐만 아니라, +헤드리스 서비스만 사용하는 경우도 거의 없으므로 제약이 크다. + +마지막으로, 세 번째 접근 방식을 취할 수 있다. 경량 프록시를 사용하는 것이다. + +# Linkerd를 사용하여 쿠버네티스에서 gRPC 로드 밸런싱 + +[Linkerd](https://linkerd.io)는 [CNCF](https://cncf.io)에서 관리하는 쿠버네티스용 +*서비스 메시*이다. 우리의 목적과 가장 관련이 깊은 Linkerd는, 클러스터 수준의 권한 +없이도 단일 서비스에 적용할 수 있는 +*서비스 사이드카*로써도 작동한다. Linkerd를 서비스에 추가하는 +것은, ​​각 파드에 작고, 초고속인 프록시를 추가하는 것을 의미하며, 이러한 프록시가 +쿠버네티스 API를 와치(watch)하고 gRPC 로드 밸런싱을 자동으로 수행하는 것을 의미이다. 우리가 수행한 배포는 +다음과 같다. + +![](/images/blog/grpc-load-balancing-with-linkerd/Linkerd-8df1031c-cdd1-4164-8e91-00f2d941e93f.io.png) + +Linkerd를 사용하면 몇 가지 장점이 있다. 첫째, 어떠한 언어로 작성된 서비스든지, 어떤 gRPC 클라이언트든지 +그리고 어떠한 배포 모델과도 (헤드리스 여부와 상관없이) 함께 작동한다. +Linkerd의 프록시는 완전히 투명하기 때문에, HTTP/2와 HTTP/1.x를 자동으로 감지하고 +L7 로드 밸런싱을 수행하며, 다른 모든 트래픽을 +순수한 TCP로 통과(pass through)시킨다. 이것은 모든 것이 *그냥 작동*한다는 것을 의미한다. + +둘째, Linkerd의 로드 밸런싱은 매우 정교하다. Linkerd는 +쿠버네티스 API에 대한 와치(watch)를 유지하고 파드가 리스케술링 될 때 +로드 밸런싱 풀을 자동으로 갱신할 뿐만 아니라, Linkerd는 응답 대기 시간이 가장 빠른 파드에 +요청을 자동으로 보내기 위해 *지수 가중 이동 평균(exponentially-weighted moving average)* 을 +사용한다. 하나의 파드가 잠시라도 느려지면, Linkerd가 트래픽을 +변경할 것이다. 이를 통해 종단 간 지연 시간을 줄일 수 있다. + +마지막으로, Linkerd의 Rust 기반 프록시는 매우 작고 빠르다. 그것은 1ms 미만의 +p99 지연 시간(<1ms of p99 latency)을 지원할 뿐만 아니라, 파드당 10mb 미만의 RSS(<10mb of RSS)만 필요로 하므로 +시스템 성능에도 거의 영향을 미치지 않는다. + +# 60초 안에 gRPC 부하 분산 + +Linkerd는 시도하기가 매우 쉽다. 단지 —랩탑에 CLI를 설치하고— [Linkerd 시작 +지침](https://linkerd.io/2/getting-started/)의 단계만 따르면 된다. +클러스터에 컨트롤 플레인과 "메시" +서비스(프록시를 각 파드에 주입)를 설치한다. 서비스에 Linkerd가 즉시 +실행될 것이므로 적절한 gRPC 밸런싱을 즉시 확인할 수 있다. + +Linkerd 설치 후에, 예시 `voting` 서비스를 +다시 살펴보자. + +![](/images/blog/grpc-load-balancing-with-linkerd/Screenshot2018-11-0116-24b8ee81-144c-4eac-b73d-871bbf0ea22e.57.42.png) + +그림과 같이, 모든 파드에 대한 CPU 그래프가 활성화되어 모든 파드가 +—코드를 변경하지 않았지만— 트래픽을 받고 있다. 짜잔, +마법처럼 gRPC 로드 밸런싱이 됐다! + +Linkerd는 또한 내장된 트래픽 수준 대시보드를 제공하므로, 더 이상 +CPU 차트에서 무슨 일이 일어나고 있는지 추측하는 것이 필요하지 않다. 다음은 각 파드의 +성공률, 요청 볼륨 및 지연 시간 백분위수를 보여주는 +Linkerd 그래프이다. + +![](/images/blog/grpc-load-balancing-with-linkerd/Screenshot2018-11-0212-15ed0448-5424-4e47-9828-20032de868b5.08.38.png) + +각 파드가 약 5 RPS를 얻고 있음을 알 수 있다. 또한, +로드 밸런싱 문제는 해결되었지만 해당 서비스의 +성공률에 대해서는 아직 할 일이 남았다는 것도 살펴볼 수 있다. (데모 앱은 독자에 대한 연습을 위해 의도적으로 +실패 상태로 만들었다. Linkerd 대시보드를 사용하여 +문제를 해결할 수 있는지 살펴보자!) + +# 마지막으로 + +쿠버네티스 서비스에 gRPC 로드 밸런싱을 추가하는 방법에 +흥미가 있다면, 어떤 언어로 작성되었든 상관없이, 어떤 gRPC +클라이언트를 사용중이든지, 또는 어떻게 배포되었든지, Linkerd를 사용하여 단 몇 개의 명령으로 +gRPC 로드 밸런싱을 추가할 수 있다. + +보안, 안정성 및 디버깅을 포함하여 Linkerd에는 더 많은 특징 +및 진단 기능이 있지만 이는 향후 블로그 게시물의 주제로 남겨두려 한다. + +더 알고 싶은가? 빠르게 성장하고 있는 우리 커뮤니티는 여러분의 참여를 환영한다! +Linkerd는 [CNCF](https://cncf.io) 프로젝트로 +[GitHub에 호스팅 되어 있고](https://github.com/linkerd/linkerd2), [Slack](https://slack.linkerd.io), +[Twitter](https://twitter.com/linkerd), 그리고 [이메일 리스트](https://lists.cncf.io/g/cncf-linkerd-users)를 통해 커뮤니티를 만날 수 있다. +접속하여 커뮤니티에 참여하는 즐거움을 느껴보길 바란다! \ No newline at end of file diff --git a/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index af962fae028..3715ea1a609 100644 --- a/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -6,7 +6,7 @@ slug: dont-panic-kubernetes-and-docker evergreen: true --- -**업데이트:** _쿠버네티스의 `dockershim`을 통한 도커 지원이 제거되었습니다. +**업데이트:** _쿠버네티스의 도커심을 통한 도커 지원이 제거되었습니다. 더 자세한 정보는 [제거와 관련된 자주 묻는 질문](/dockershim/)을 참고하세요. 또는 지원 중단에 대한 [GitHub 이슈](https://github.com/kubernetes/kubernetes/issues/106917)에서 논의를 할 수도 있습니다._ diff --git a/content/ko/community/static/cncf-code-of-conduct.md b/content/ko/community/static/cncf-code-of-conduct.md index 9d191a81bbc..6066d34f94e 100644 --- a/content/ko/community/static/cncf-code-of-conduct.md +++ b/content/ko/community/static/cncf-code-of-conduct.md @@ -1,6 +1,6 @@ -## CNCF 커뮤니티 행동 강령 v1.1 +## CNCF 커뮤니티 행동 강령 v1.2 ### 기여자 행동 강령 @@ -9,58 +9,63 @@ CNCF 커뮤니티의 기여자 및 메인테이너(maintainer)로서 개방적 풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는 모든 분들을 존중할 것을 약속합니다. -우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression), -성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, +우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression), 성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, 또는 국적에 상관 없이 모두가 차별 없는 환경에서 CNCF 커뮤니티에 참여할 수 있도록 최선을 다하고 있습니다. ## 범위 + 본 행동 강령은 프로젝트 활동 영역 내에서뿐만 아니라 개인이 프로젝트 또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다. ## CNCF 이벤트 + CNCF 이벤트, 혹은 리눅스 재단에서 이벤트 전문 직원과 운영하는 이벤트는 이벤트 페이지에 명시된 Linux Foundation [이벤트 행동 강령](https://events.linuxfoundation.org/code-of-conduct)에 의거하여 운영됩니다. 해당 행동 강령은 CNCF의 행동 강령과 함께 사용하도록 고안되었습니다. ## 우리의 원칙 긍정적인 환경을 조성하는 행위는 다음과 같습니다. + * 타인에게 친절과 공감 실천 * 타인의 의견, 관점, 그리고 경험에 대한 포용 * 건설적 피드백에 대한 수용 -* 실수에 대한 책임과 사과, 그리고 경험을 통한 배움 -* 개인의 최선이 아닌 커뮤니티 전반의 선을 위한 노력 - +* 실수에 대한 책임과 사과, + 그리고 경험을 통한 배움 +* 개인의 최선이 아닌 커뮤니티 전반의 + 선을 위한 노력 참여자에게 금지하는 행위의 예시는 다음과 같습니다. -* 성적인 언어 또는 이미지 사용, 혹은 그 외 성적으로 부적절한 행동 +* 성적인 언어 또는 이미지 사용, 혹은 + 그 외 성적으로 부적절한 행동 * 선동적, 모욕적, 경멸적 언사, 그리고 개인적 혹은 정치적 공격 * 공개적이거나 사적인 괴롭힘 -* 타인의 주소 및 전자주소와 같은 개인 정보의 동의 없는 공개 +* 타인의 주소 및 전자주소와 같은 + 개인 정보의 동의 없는 공개 * 기타 비윤리적이거나 비전문적인 행동 -프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit), -코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정, + +프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit), 코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정, 거부할 수 있는 권한과 책임이 있습니다. 프로젝트 메인테이너는 프로젝트 관리의 모든 관점에서 이러한 행동 강령 원칙을 공정하고 일관되게 적용할 것을 약속해야 합니다. 행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서 영구적으로 제적될 수 있습니다. ## 신고 -쿠버네티스 커뮤니티에서 발생하는 사건들은 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 신고시 3일 내 회신을 받을 수 있습니다. -기타 다른 프로젝트에 관해서는 CNCF 직원에게 이메일 으로 문의하십시오. +쿠버네티스 커뮤니티에서 발생하는 사건들은 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 영업일 기준 3일 이내에 답변을 받으실 수 있습니다. -CNCF는 외부 중재자로 Mishi Choudhary 를 두고 있습니다. 외부 중재자는 CNCF 직원의 안내에 따라 의뢰 가능합니다. 보통의 경우 로 직접 연락하는 것을 추천합니다. - -쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 으로 문의하십시오. +기타 다른 프로젝트, 프로젝트에 무관하거나, 여러 CNCF 프로젝트에 영향을 주는 사건들은 [CNCF 행동 강령 위원회](https://www.cncf.io/conduct/committee/)에 이메일 를 통해 신고할 수 있습니다. 또는 [CNCF 행동 강령 위원회](https://www.cncf.io/conduct/committee/)의 각 구성원에게 연락하여 보고서를 제출할 수 있습니다. 익명으로 보고서를 제출하는 방법을 포함하여 보고서 제출 방법에 대한 자세한 내용은 [사건 해결 절차](https://www.cncf.io/conduct/procedures/)를 참조하십시오. 영업일 기준 3일 이내에 답변을 받으실 수 있습니다. ## 집행 -쿠버네티 프로젝트의 [행동 강령 위원회](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)가 행동 강령 발행을 시행합니다. 기타 프로젝트에 관하여는 CNCF가 행동강력 발행을 시행합니다. + +쿠버네티 프로젝트의 [행동 강령 위원회](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)가 쿠버네티스 프로젝트에 대하여 행동 강령 이슈에 대한 집행을 수행합니다. + +자체 행동 강령 위원회 또는 행동 강령 사고 대응자가 없는 모든 프로젝트와, 프로젝트에 해당하지 않거나(project-agnostic) 여러 프로젝트에 영향을 미치는 사건에 대해서는 [CNCF 행동 강령 위원회](https://www.cncf.io/conduct/committee/)가 행동 강령 이슈에 대한 집행을 수행합니다. 자세한 내용은 [관할(jurisdiction) 및 에스컬레이션(escalation) 정책](https://www.cncf.io/conduct/jurisdiction/)을 참조하십시오. 양 기관은 처벌 없는 문제 해결을 추구합니다. 하지만 CNCF의 재량에 따라 회원 혹은 프로젝트를 퇴출시킬 수 있습니다. ### 확인 -본 행동 강령은 기여자 서약(https://contributor-covenant.org)에서 +본 행동 강령은 기여자 서약(http://contributor-covenant.org)에서 제공하는 버전 2.0을 적용하였으며, 해당 내용은 -https://contributor-covenant.org/version/2/0/code_of_conduct/ 에서 확인할 수 있습니다. +http://contributor-covenant.org/version/2/0/code_of_conduct/ 에서 확인할 수 있습니다. diff --git a/content/ko/docs/concepts/architecture/garbage-collection.md b/content/ko/docs/concepts/architecture/garbage-collection.md index 657d1735ec1..8b049bbd65c 100644 --- a/content/ko/docs/concepts/architecture/garbage-collection.md +++ b/content/ko/docs/concepts/architecture/garbage-collection.md @@ -8,7 +8,6 @@ weight: 50 {{}} 다음과 같은 리소스를 정리한다: - * [실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) * [종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/) * [소유자 참조가 없는 오브젝트](#owners-dependents) * [사용되지 않는 컨테이너와 컨테이너 이미지](#containers-images) diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index bd0d9915d56..ce2f0eab364 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -194,9 +194,9 @@ kubectl describe node {{< /table >}} {{< note >}} -커맨드 라인 도구를 사용해서 코드화된 노드의 세부 정보를 출력하는 경우 조건에는 +커맨드 라인 도구를 사용해서 통제된(cordoned) 노드의 세부 정보를 출력하는 경우 조건에는 `SchedulingDisabled` 이 포함된다. `SchedulingDisabled` 은 쿠버네티스 API의 조건이 아니며, -대신 코드화된 노드는 사양에 스케줄 불가로 표시된다. +대신 통제된(cordoned) 노드는 사양에 스케줄 불가로 표시된다. {{< /note >}} 쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 @@ -476,9 +476,8 @@ kubelet의 노드 셧다운 관리자(Node Shutdown Mananger)가 기존의 셧다운된 노드가 정상으로 돌아오지 못하면, 이러한 파드는 셧다운된 노드에 '종료 중(terminating)' 상태로 영원히 고착될 것이다. -위와 같은 상황을 완화하기 위해, 사용자가 `node.kubernetes.io/out-of-service` 테인트를 -`NoExecute` 또는 `NoSchedule` 값으로 추가하여 -노드를 서비스 불가(out-of-service) 상태로 표시할 수 있다. +위와 같은 상황을 완화하기 위해, 사용자가 `node.kubernetes.io/out-of-service` 테인트를 `NoExecute` 또는 `NoSchedule` 값으로 +추가하여 노드를 서비스 불가(out-of-service) 상태로 표시할 수 있다. `kube-controller-manager`에 `NodeOutOfServiceVolumeDetach`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화되어 있고, 노드가 이 테인트에 의해 서비스 불가 상태로 표시되어 있는 경우, 노드에 매치되는 톨러레이션이 없다면 노드 상의 파드는 강제로 삭제될 것이고, diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index 59b1af0b4ca..4633d23cd00 100644 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -74,7 +74,7 @@ no_list: true 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다 . -* [감사(audit)](/docs/tasks/debug/debug-cluster/audit/)는 +* [감사(audit)](/ko/docs/tasks/debug/debug-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다. ### kubelet 보안 diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 0c2cd0f4fa6..3ba3e35c2a3 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -9,7 +9,7 @@ content_type: concept 애드온은 쿠버네티스의 기능을 확장한다. -이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다. +이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다. 이 목차에서 전체를 다루지는 않는다. @@ -19,7 +19,7 @@ content_type: concept * [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다. * [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다. * [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다. -* [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다. +* [Cilium](https://github.com/cilium/cilium)은 네트워킹, 관측 용의성(Observability), 보안 특징을 지닌 eBPF 기반 데이터 플레인을 갖춘 솔루션입니다. Cilium은 기본 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 여러 클러스터를 포괄할 수 있는 단순한 플랫(flat) Layer 3 네트워크를 제공합니다. 또한, Cilium은 (네트워크 주소 지정 방식에서 분리된) 신원 기반 보안 모델(identity-based security model)을 사용하여 L3-L7에서 네트워크 정책을 시행할 수 있습니다. Cilium은 kube-proxy를 대체하는 역할을 할 수 있습니다. 또한 부가적으로, 옵트인(opt-in) 형태로 관측 용의성(Observability) 및 보안 기능을 제공합니다. * [CNI-Genie](https://github.com/cni-genie/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다. * [Contiv](https://contivpp.io/)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. @@ -27,7 +27,7 @@ content_type: concept * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. * [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 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 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. +* [Nodus](https://github.com/akraino-edge-stack/icn-nodus)는 클라우드 네이티브 기반 서비스 기능 체인(SFC)을 제공하는 OVN 기반 CNI 컨트롤러 플러그인이다. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다. * [Romana](https://github.com/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index cc3c1b9c3b7..cc3df4d5f59 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -34,170 +34,9 @@ weight: 50 ## 쿠버네티스 네트워크 모델의 구현 방법 -이 네트워크 모델을 구현할 수 있는 방법에는 여러 가지가 있다. 이 -문서는 다양한 방법에 대한 철저한 연구는 아니지만, 다양한 기술에 대한 -소개로 활용되며 도약하는 포인트로 사용되기를 바란다. +네트워크 모델은 각 노드의 컨테이너 런타임에 의해 구현된다. 가장 일반적인 컨테이너 런타임은 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 사용하여 네트워크 및 보안 기능을 관리한다. 여러 공급 업체의 다양한 CNI 플러그인이 존재하며, 이들 중 일부는 네트워크 인터페이스를 추가 및 제거하는 기본 기능만 제공하는 반면, 다른 일부는 다른 컨테이너 오케스트레이션 시스템과의 통합, 여러 CNI 플러그인 실행, 고급 IPAM 기능 등과 같은 보다 정교한 솔루션을 제공한다. -이 목록은 알파벳 순으로 정렬되어 있으며, 정렬된 순서가 -우선 상태를 의미하는 것은 아니다. - -{{% thirdparty-content %}} - -### ACI - -[Cisco 애플리케이션 센트릭 인프라스트럭처(Application Centric Infrastructure)](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html)는 컨테이너, 가상 머신 및 베어메탈 서버를 지원하는 통합 오버레이 및 언더레이 SDN 솔루션을 제공한다. [ACI](https://www.github.com/noironetworks/aci-containers)는 ACI를 위한 컨테이너 네트워킹 통합을 제공한다. 통합의 개요는 [여기](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf)에서 제공된다. - -### Antrea - -프로젝트 [Antrea](https://github.com/vmware-tanzu/antrea)는 쿠버네티스 고유의 오픈소스 쿠버네티스 네트워킹 솔루션이다. 네트워킹 데이터 플레인으로 Open vSwitch를 활용한다. Open vSwitch는 리눅스와 윈도우를 모두 지원하는 고성능의 프로그래밍이 가능한 가상 스위치이다. Antrea는 Open vSwitch를 통해 쿠버네티스 네트워크 정책을 고성능의 효율적인 방식으로 구현할 수 있다. -Antrea는 Open vSwitch의 "프로그래밍이 가능한" 특성으로 인해 Open vSwitch 위에 광범위한 네트워킹 및 보안 기능과 서비스를 구현할 수 있다. - -### 쿠버네티스용 AWS VPC CNI - -[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)는 쿠버네티스 클러스터를 위한 통합된 AWS 버추얼 프라이빗 클라우드(Virtual Private Cloud, VPC) 네트워킹을 제공한다. 이 CNI 플러그인은 높은 처리량과 가용성, 낮은 레이턴시(latency) 그리고 최소 네트워크 지터(jitter)를 제공한다. 또한, 사용자는 쿠버네티스 클러스터를 구축하기 위한 기존의 AWS VPC 네트워킹 및 보안 모범 사례를 적용할 수 있다. 여기에는 VPC 플로우 로그, VPC 라우팅 정책과 네트워크 트래픽 격리를 위한 보안 그룹을 사용하는 기능이 포함되어 있다. - -이 CNI 플러그인을 사용하면 쿠버네티스 파드는 VPC 네트워크와 동일한 IP 주소를 파드 내부에 가질 수 있다. CNI는 각 쿠버네티스 노드에 AWS 엘라스틱 네트워킹 인터페이스(Elastic Networking Interfaces, ENI)를 할당하고 노드의 파드에 대해 각 ENI의 보조 IP 범위를 사용한다. CNI에는 파드를 빠르게 시작하기 위해 ENI와 IP 주소의 사전 할당 제어 기능이 포함되어 있으며 최대 2,000개의 노드로 구성된 대규모 클러스터가 가능하다. - -또한, CNI는 [네트워크 폴리시 적용을 위해 캘리코(Calico)](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)와 함께 실행할 수 있다. AWS VPC CNI 프로젝트는 [GitHub의 문서](https://github.com/aws/amazon-vpc-cni-k8s)와 함께 오픈소스로 공개되어 있다. - -### 쿠버네티스용 Azure CNI -[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview)는 VM과 동등한 네트워크 성능을 제공하는 Azure 버추얼 네트워크(VNet이라고도 알려진)와 쿠버네티스 파드를 통합하는 [오픈소스](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) 플러그인이다. 파드는 피어링된 VNet과 Express Route 또는 사이트 간 VPN을 통해 온-프레미스에 연결할 수 있으며 이러한 네트워크에서 직접 연결할 수도 있다. 파드는 서비스 엔드포인트 또는 프라이빗 링크로 보호되는 스토리지와 SQL과 같은 Azure 서비스에 접근할 수 있다. VNet 보안 정책과 라우팅을 사용하여 파드 트래픽을 필터링할 수 있다. 플러그인은 쿠버네티스 노드의 네트워크 인터페이스에 사전 구성된 보조 IP 풀을 활용하여 VNet IP를 파드에 할당한다. - -Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni)에서 기본적으로 사용할 수 있다. - -### 캘리코 - -[캘리코](https://projectcalico.docs.tigera.io/about/about-calico/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다. - -### 실리움(Cilium) - -[실리움](https://github.com/cilium/cilium)은 애플리케이션 컨테이너 간에 -네트워크 연결을 제공하고 투명하게 보호하기 위한 오픈소스 소프트웨어이다. -실리움은 L7/HTTP를 인식하며 네트워크 주소 지정에서 분리된 ID 기반 보안 모델을 사용하여 L3-L7에서 -네트워크 정책을 적용할 수 있으며, -다른 CNI 플러그인과 함께 사용할 수 있다. - -### 화웨이의 CNI-Genie - -[CNI-Genie](https://github.com/cni-genie/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)의 [서로 다른 구현에 동시에 접근](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/flannel-io/flannel#flannel), [캘리코](https://projectcalico.docs.tigera.io/about/about-calico/), [위브넷(Weave-net)](https://www.weave.works/oss/net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다. - -CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다. - -### cni-ipvlan-vpc-k8s -[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s)는 -L2 모드에서 리눅스 커널의 IPvlan 드라이버를 사용하여 Amazon 엘라스틱 네트워크 인터페이스(ENI)를 -사용하고 AWS 매니지드 IP를 파드에 바인딩하는 -Amazon 버추얼 프라이빗 클라우드(VPC) 환경 내에서 쿠버네티스를 위한 -간단하고, 호스트 로컬, 낮은 레이턴시, 높은 처리량 및 호환 네트워킹 스택을 제공하는 -CNI와 IPAM 플러그인 셋을 포함한다. - -플러그인은 VPC 내에서 구성하고 배포할 수 있도록 간단하게 설계되었다. -Kubelets는 오버레이 네트워크 관리, BGP 관리, 소스/대상 확인 비활성화 또는 -VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브넷을 -제공(VPC별 50-100개 항목으로 제한)하는 등의 자주 권장되는 복잡성을 요구하지 않고 -부팅한 다음 필요에 따라 IP 사용량을 자체 구성하고 확장할 -수 있다. 즉, cni-ipvlan-vpc-k8s는 AWS 내에서 쿠버네티스를 -대규모로 배포하는 데 필요한 네트워크 복잡성을 크게 줄인다. - -### Coil - -[Coil](https://github.com/cybozu-go/coil)은 통합이 용이하도록 설계된 CNI 플러그인으로 유연한 이그레스(egress) 네트워킹을 제공한다. -Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네트워크에 대해 임의의 이그레스 NAT 게이트웨이를 정의할 수 있다. - -### 콘티브-VPP(Contiv-VPP) - -[Contiv-VPP](https://contivpp.io/)는 유저 스페이스에서 동작하고 성능을 중시하는 쿠버네티스 네트워크 플러그인이며, -데이터 플레인으로 [fd.io](https://fd.io/)를 사용한다. - -### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric) - -[텅스텐 패브릭](https://tungsten.io)을 기반으로 하는 [콘트레일](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 진정한 개방형 멀티 클라우드 네트워크 가상화 및 정책 관리 플랫폼이다. 콘트레일 및 텅스텐 패브릭은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 다양한 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어메탈 워크로드에 대해 서로 다른 격리 모드를 제공한다. - -### DANM - -[DANM](https://github.com/nokia/danm)은 쿠버네티스 클러스터에서 실행되는 통신사 워크로드를 위한 네트워킹 솔루션이다. 다음의 컴포넌트로 구성된다. - - * 고급 기능들로 IPVLAN 인터페이스를 프로비저닝할 수 있는 CNI 플러그인 - * 여러 클러스터 전체의 불연속 L3 네트워크를 관리하고 요청 시 동적, 정적 또는 IP를 할당하지 않는 방식을 제공하는 내장 IPAM 모듈 - * 자체 CNI를 통해서, 또는 SRI-OV나 플라넬과 같은 널리 사용되는 CNI 솔루션에 잡을 동시에 위임하여 여러 네트워크 인터페이스를 컨테이너에 연결할 수 있는 CNI 메타플러그인 - * 모든 쿠버네티스 호스트의 VxLAN 및 VLAN 인터페이스를 중앙에서 관리할 수 있는 쿠버네티스 컨트롤러 - * 쿠버네티스의 서비스 기반의 서비스 검색 개념을 확장하여 파드의 모든 네트워크 인터페이스에서 작동하는 다른 쿠버네티스 컨트롤러 - -이 도구 셋을 통해 DANM은 여러 개의 분리된 네트워크 인터페이스를 제공할 수 있으며, 파드에 다른 네트워킹 백엔드 및 고급 IPAM 기능을 사용할 수 있다. - -### 플라넬 - -[플라넬](https://github.com/flannel-io/flannel#flannel)은 쿠버네티스 요구 사항을 -충족하는 매우 간단한 오버레이 네트워크이다. 많은 -경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다. - -### Hybridnet - -[Hybridnet](https://github.com/alibaba/hybridnet)은 하이브리드 클라우드를 위해 디자인된 오픈소스 CNI 플러그인이며 하나 또는 다수의 클러스터에 있는 컨테이너를 위한 오버레이 및 언더레이 네트워킹을 제공한다. 오버레이 및 언더레이 컨테이너는 동일한 노드에서 실행될 수 있으며 클러스터 범위의 양방향 네트워크 연결성을 가진다. - -### 재규어(Jaguar) - -[재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다. - -### k-vswitch - -[k-vswitch](https://github.com/k-vswitch/k-vswitch)는 [Open vSwitch](https://www.openvswitch.org/) 기반의 간단한 쿠버네티스 네트워킹 플러그인이다. Open vSwitch의 기존 기능을 활용하여 운영하기 쉽고, 성능이 뛰어나고 안전한 강력한 네트워킹 플러그인을 제공한다. - -### Knitter - -[Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스에서 여러 네트워킹을 지원하는 네트워크 솔루션이다. 테넌트 관리 및 네트워크 관리 기능을 제공한다. Knitter에는 애플리케이션의 IP 주소 유지, IP 주소 마이그레이션 등과 같은 여러 네트워크 플레인 외에 엔드-투-엔드 NFV 컨테이너 네트워킹 솔루션 셋이 포함되어 있다. - -### Kube-OVN - -[Kube-OVN](https://github.com/alauda/kube-ovn)은 기업을 위한 OVN 기반 쿠버네티스 네트워크 패브릭이다. OVN/OVS의 도움으로, 서브넷, QoS, 고정 IP 할당, 트래픽 미러링, 게이트웨이, 오픈플로우 기반 네트워크 정책 및 서비스 프록시와 같은 고급 오버레이 네트워크 기능을 제공한다. - -### Kube-router - -[kube-router](https://github.com/cloudnativelabs/kube-router)는 쿠버네티스를 위한 특수 목적의 네트워킹 솔루션으로 고성능 및 운영 단순성을 제공한다. 큐브 라우터는 리눅스 [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html) 기반 서비스 프록시, 오버레이가 없는 리눅스 커널 포워딩 기반의 파드 간 네트워킹 솔루션 그리고 iptables/ipset 기반 네트워크 정책 집행도구를 제공한다. - -### L2 네트워크 및 리눅스 브릿지 - -"베어메탈" 환경의 간단한 스위치와 같은 "더미(dumb)" L2 네트워크가 있는 경우, -위의 GCE 설정과 비슷한 작업을 수행할 수 있어야 한다. -이 방법은 매우 우연히 시도되었고 작동하는 것으로 보이지만 -철저히 테스트되지 않았다. 이 기술을 사용하여 -프로세스를 완료한 경우, 알려주길 바란다. - -Lars Kellogg-Stedman이 제공하는 -[이 훌륭한 튜토리얼](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)의 -"With Linux Bridge devices" 섹션을 참고한다. - -### Multus(멀티 네트워크 플러그인) - -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) 워크로드를 지원한다. - -### OVN4NFV-K8s-Plugin (OVN 기반의 CNI 컨트롤러 & 플러그인) - -[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. - -### NSX-T - -[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html)는 네트워크 가상화 및 보안 플랫폼이다. NSX-T는 멀티 클라우드 및 멀티 하이퍼바이저 환경에 네트워크 가상화를 제공할 수 있으며 이기종 엔드포인트와 기술 스택이 있는 새로운 애플리케이션 프레임워크 및 아키텍처에 중점을 둔다. vSphere 하이퍼바이저 외에도, 이러한 환경에는 KVM, 컨테이너 및 베어메탈과 같은 다른 하이퍼바이저가 포함된다. - -[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 플랫폼 간의 통합을 제공한다. - -### OVN(오픈 버추얼 네트워킹) - -OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 -가상화 솔루션이다. 논리적 스위치, 논리적 라우터, 스테이트풀 ACL, 로드 밸런서 등을 생성하여 -서로 다른 가상 네트워킹 토폴로지를 구축할 수 있다. 이 프로젝트에는 -[ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에 -특정 쿠버네티스 플러그인 및 문서가 있다. - -### Weaveworks의 위브넷 - -[위브넷](https://www.weave.works/oss/net/)은 -쿠버네티스 및 호스팅된 애플리케이션을 위한 탄력적이고 사용하기 쉬운 네트워크이다. -위브넷은 [CNI 플러그인](https://www.weave.works/docs/net/latest/cni-plugin/) 또는 -독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며, -두 경우 모두, 쿠버네티스의 표준과 같이 네트워크에서 파드별로 하나의 IP 주소를 제공한다. +쿠버네티스에서 지원하는 네트워킹 애드온의 일부 목록은 [이 페이지](/ko/docs/concepts/cluster-administration/addons/#network-and-networking-policy)를 참조한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/cluster-administration/proxies.md b/content/ko/docs/concepts/cluster-administration/proxies.md index ab1f6611fd7..28599acdfaf 100644 --- a/content/ko/docs/concepts/cluster-administration/proxies.md +++ b/content/ko/docs/concepts/cluster-administration/proxies.md @@ -23,7 +23,7 @@ weight: 90 - API 서버를 찾는다. - 인증 헤더를 추가한다. -1. [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#빌트인-서비스들의-발견): +1. [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services): - API 서버에 내장된 요새(bastion)이다. - 클러스터 외부의 사용자가 도달할 수 없는 클러스터 IP 주소로 연결한다. diff --git a/content/ko/docs/concepts/cluster-administration/system-traces.md b/content/ko/docs/concepts/cluster-administration/system-traces.md index b85dda39061..e79800b1277 100644 --- a/content/ko/docs/concepts/cluster-administration/system-traces.md +++ b/content/ko/docs/concepts/cluster-administration/system-traces.md @@ -29,7 +29,7 @@ gRPC exporter를 이용하여 추적을 생성하고 기본적으로, 쿠버네티스 컴포넌트들은 [IANA OpenTelemetry 포트](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry)인 4317 포트로 OTLP에 대한 grpc exporter를 이용하여 추적를 내보낸다. 예를 들면, 수집기가 쿠버네티스 컴포넌트에 대해 사이드카(sidecar)로 동작한다면, -다음과 같은 리시버 설정을 통해 span을 수집하고 그 로그를 표준 출력(standard output)으로 내보낼 것이다. +다음과 같은 리시버 설정을 통해 스팬(span)을 수집하고 그 로그를 표준 출력(standard output)으로 내보낼 것이다. ```yaml receivers: @@ -76,10 +76,40 @@ samplingRatePerMillion: 100 `TracingConfiguration` 구조체에 대해 더 많은 정보를 얻고 싶다면 [API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)를 참고한다. +### kubelet 추적 + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +kubelet CRI 인터페이스와 인증된 http 서버는 추적(trace) 스팬(span)을 생성하도록 설정 할수 있다. +apiserver와 마찬가지로 해당 엔드포인트 및 샘플링률을 구성할 수 있다. +추적 컨텍스트 전파(trace context propagation)도 구성할 수 있다. 상위 스팬(span)의 샘플링 설정이 항상 적용된다. +제공되는 설정의 샘플링률은 상위가 없는 스팬(span)에 기본 적용된다. +엔드포인트를 구성하지 않고 추적을 활성화로 설정하면, 기본 OpenTelemetry Collector receiver 주소는 "localhost:4317"으로 기본 설정된다. + +#### kubelet tracing 활성화 + +추적을 활성화하려면 kubelet에서 `KubeletTracing` +[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)을 활성화한다. +또한 kubelet에서 +[tracing configuration](https://github.com/kubernetes/component-base/blob/release-1.25/tracing/api/v1/types.go)을 제공한다. +[tracing 구성](https://github.com/kubernetes/component-base/blob/release-1.25/tracing/api/v1/types.go)을 참조한다. +다음은 10000개 요청 중 1개에 대하여 스팬(span)을 기록하고, 기본 OpenTelemetry 앤드포인트를 사용하도록 한 kubelet 구성 예시이다. + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +featureGates: + KubeletTracing: true +tracing: + # 기본값 + #endpoint: localhost:4317 + samplingRatePerMillion: 100 +``` + ## 안정성 추적의 계측화(tracing instrumentation)는 여전히 활발히 개발되는 중이어서 다양한 형태로 변경될 수 있다. -span의 이름, 첨부되는 속성, 계측될 엔드포인트(instrumented endpoints)들 등이 그렇다. +스팬(span)의 이름, 첨부되는 속성, 계측될 엔드포인트(instrumented endpoints)들 등이 그렇다. 이 속성이 안정화(graduates to stable)되기 전까지는 이전 버전과의 호환성은 보장되지 않는다. diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 6882903627e..b4687ec73e2 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -236,7 +236,7 @@ kubelet은 파드의 리소스 사용량을 파드 ## 로컬 임시(ephemeral) 스토리지 -{{< feature-state for_k8s_version="v1.10" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} 노드에는 로컬에 연결된 쓰기 가능 장치 또는, 때로는 RAM에 의해 지원되는 로컬 임시 스토리지가 있다. @@ -305,14 +305,9 @@ kubelet에 지시하는 디렉터리는 이 두 번째 파일시스템에 있다 {{% /tab %}} {{< /tabs >}} -kubelet은 사용 중인 로컬 스토리지 양을 측정할 수 있다. 이것은 다음을 -제공한다. - -- `LocalStorageCapacityIsolation` - [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)(이 - 기능이 기본적으로 설정되어 있음)를 활성화하고, -- 로컬 임시 스토리지에 대한 지원되는 구성 중 하나를 - 사용하여 노드를 설정한다. +kubelet은 사용 중인 로컬 스토리지 양을 측정할 수 있다. +임시 볼륨(ephemeral storage)을 설정하기 위해 지원되는 구성 중 하나를 사용하여 +노드를 설정한 경우 제공된다. 다른 구성을 사용하는 경우, kubelet은 임시 로컬 스토리지에 대한 리소스 제한을 적용하지 않는다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 84c85306f12..6625fe615a5 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -566,7 +566,7 @@ metadata: spec: containers: - name: test-container - image: k8s.gcr.io/busybox + image: registry.k8s.io/busybox command: [ "/bin/sh", "-c", "env" ] envFrom: - secretRef: @@ -794,7 +794,7 @@ spec: secretName: dotfile-secret containers: - name: dotfile-test-container - image: k8s.gcr.io/busybox + image: registry.k8s.io/busybox command: - ls - "-l" diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md index ee3f0a4af36..21d5b3327fd 100644 --- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md @@ -103,9 +103,9 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다. 훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다. 만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다. -`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며, -`PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다. -실패한 `FailedPreStopHook` 이벤트를 직접 생성하려면, [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) 파일을 수정하여 postStart 명령을 "badcommand"로 변경하고 이를 적용한다. +`PostStart`의 경우 `FailedPostStartHook` 이벤트이며, +`PreStop`의 경우 `FailedPreStopHook` 이벤트이다. +실패한 `FailedPostStartHook` 이벤트를 직접 생성하려면, [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) 파일을 수정하여 postStart 명령을 "badcommand"로 변경하고 이를 적용한다. 다음은 `kubectl describe pod lifecycle-demo` 를 실행하여 볼 수 있는 이벤트 출력 예시이다. ``` diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index d725169975f..5ad0fa4ec68 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -24,8 +24,8 @@ weight: 10 ## 이미지 이름 컨테이너 이미지는 일반적으로 `pause`, `example/mycontainer` 또는 `kube-apiserver` 와 같은 이름을 부여한다. -이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들면, `fictional.registry.example/imagename` -과 같다. 그리고 포트 번호도 포함할 수 있다. 예를 들면, `fictional.registry.example:10443/imagename` 과 같다. +이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들어 `fictional.registry.example/imagename` +와 같다. 그리고 `fictional.registry.example:10443/imagename` 와 같이 포트 번호도 포함할 수 있다. 레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다. @@ -275,6 +275,8 @@ kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다. {{< /note >}} 쿠버네티스는 파드에 컨테이너 이미지 레지스트리 키를 명시하는 것을 지원한다. +`imagePullSecrets`은 모두 파드와 동일한 네임스페이스에 있어야 한다. +참조되는 시크릿의 타입은 `kubernetes.io/dockercfg` 이거나 `kubernetes.io/dockerconfigjson` 이어야 한다. #### 도커 구성으로 시크릿 생성 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 34ec15dfaee..5f7d9a072af 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 @@ -26,7 +26,7 @@ weight: 10 동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며 클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다. 커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로 -[kubectl](/ko/docs/reference/kubectl/)을 사용하여 해당 오브젝트를 생성하고 +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}을 사용하여 해당 오브젝트를 생성하고 접근할 수 있다. ## 커스텀 컨트롤러 @@ -99,7 +99,7 @@ _선언적(declarative) API_ 를 제공하게 된다. * 파일이 업데이트될 때 디플로이먼트 등을 통해 롤링 업데이트를 수행하려고 한다. {{< note >}} -민감한 데이터에는 [시크릿](/ko/docs/concepts/configuration/secret/)을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전한다. +민감한 데이터에는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}을 사용하자. 이는 컨피그맵과 비슷하지만 더 안전하다. {{< /note >}} 다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated 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 81e753b00ae..bd48985467a 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 @@ -68,7 +68,7 @@ metadata: spec: containers: - name: demo-container-1 - image: k8s.gcr.io/pause:2.0 + image: registry.k8s.io/pause:2.0 resources: limits: hardware-vendor.example/foo: 2 diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index c5568f5af1a..525a2b11d8d 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -32,7 +32,7 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/ 쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 kubelet이 CNI 플러그인을 관리하게 할 수도 있었다. 이 커맨드 라인 파라미터들은 쿠버네티스 1.24에서 제거되었으며, CNI 관리는 더 이상 kubelet 범위에 포함되지 않는다. -dockershim 제거 후 문제가 발생하는 경우 +도커심 제거 후 문제가 발생하는 경우 [CNI 플러그인 관련 오류 문제 해결](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)을 참조하자. {{< /note >}} diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 67bde697bac..f59f470f3f1 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -15,7 +15,7 @@ weight: 30 ## 동기 부여 -오퍼레이터 패턴은 서비스 또는 서비스 셋을 관리하는 운영자의 +_오퍼레이터 패턴_은 서비스 또는 서비스 셋을 관리하는 운영자의 주요 목표를 포착하는 것을 목표로 한다. 특정 애플리케이션 및 서비스를 돌보는 운영자는 시스템의 작동 방식, 배포 방법 및 문제가 있는 경우 대처 방법에 대해 깊이 알고 있다. diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md index 353b2227855..eed332a41fc 100644 --- a/content/ko/docs/concepts/overview/_index.md +++ b/content/ko/docs/concepts/overview/_index.md @@ -1,7 +1,97 @@ --- -title: "개요" -weight: 20 -description: 쿠버네티스와 그 컴포넌트에 대한 하이-레벨(high-level) 개요를 제공한다. -sitemap: - priority: 0.9 +# reviewers: +# - bgrant0607 +# - mikedanese +title: 쿠버네티스란 무엇인가? +description: > + 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다. +content_type: concept +weight: 10 +card: + name: concepts + weight: 10 +no_list: true --- + + +이 페이지에서는 쿠버네티스 개요를 설명한다. + + + +쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. + +쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. + +## 여정 돌아보기 + +시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자. + +![배포 혁명](/images/docs/Container_Evolution.svg) + +**전통적인 배포 시대:** +초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다. + +**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다. + +가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다. + +각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다. + +**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. + +컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다. + +* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임. +* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다. +* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다. +* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다. +* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다. +* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다. +* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다. +* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다. +* 리소스 격리: 애플리케이션 성능을 예측할 수 있다. +* 리소스 사용량: 고효율 고집적. + +## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do} + +컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까? + +그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다. + +쿠버네티스는 다음을 제공한다. + +* **서비스 디스커버리와 로드 밸런싱** +쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다. +* **스토리지 오케스트레이션** +쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다. +* **자동화된 롤아웃과 롤백** +쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다. +* **자동화된 빈 패킹(bin packing)** +컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다. +* **자동화된 복구(self-healing)** +쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다. +* **시크릿과 구성 관리** +쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다. + +## 쿠버네티스가 아닌 것 + +쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. + +쿠버네티스는: + +* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다. +* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다. +* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. +* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다. +* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. +* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. +* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. + + + +## {{% heading "whatsnext" %}} + +* [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기 +* [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/) 살펴보기 +* [클러스터 아키텍처](/ko/docs/concepts/architecture/) 살펴보기 +* [시작하기](/ko/docs/setup/) 준비가 되었는가? diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 113e183dc78..e02d749121c 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -51,8 +51,8 @@ card: 이들 컨트롤러는 다음을 포함한다. * 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다. - * 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 - 유지시켜 주는 책임을 가진다. + * 잡 컨트롤러: 일회성 작업을 나타내는 잡 오브젝트를 감시한 다음, 해당 작업을 + 완료할 때까지 동작하는 파드를 생성한다. * 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.) * 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다. diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 8acfb841021..a45a77b3844 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -93,19 +93,22 @@ kube-apiserver 구성 요소에 `/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든 그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다. 이러한 그룹/버전은 다음과 같은 형식으로 제공된다. -```json + +```yaml { "paths": { - ... + ..., "api/v1": { "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF" }, "apis/admissionregistration.k8s.io/v1": { "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597" }, - ... + .... + } } ``` + 위의 상대 URL은 변경 불가능한(immutable) OpenAPI 상세를 가리키고 있으며, 이는 클라이언트에서의 캐싱을 향상시키기 위함이다. diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md deleted file mode 100644 index 437a8b491b0..00000000000 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -# reviewers: -# - bgrant0607 -# - mikedanese -title: 쿠버네티스란 무엇인가? -description: > - 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다. -content_type: concept -weight: 10 -card: - name: concepts - weight: 10 -sitemap: - priority: 0.9 ---- - - -이 페이지에서는 쿠버네티스 개요를 설명한다. - - - -쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. - -쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. - -## 여정 돌아보기 - -시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자. - -![배포 혁명](/images/docs/Container_Evolution.svg) - -**전통적인 배포 시대:** -초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다. - -**가상화된 배포 시대:** 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다. - -가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다. - -각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다. - -**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. - -컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다. - -* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임. -* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다. -* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다. -* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다. -* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다. -* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다. -* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다. -* 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다. -* 리소스 격리: 애플리케이션 성능을 예측할 수 있다. -* 자원 사용량: 리소스 사용량: 고효율 고집적. - -## 쿠버네티스가 왜 필요하고 무엇을 할 수 있나 {#why-you-need-kubernetes-and-what-can-it-do} - -컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까? - -그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다. - -쿠버네티스는 다음을 제공한다. - -* **서비스 디스커버리와 로드 밸런싱** -쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다. -* **스토리지 오케스트레이션** -쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다. -* **자동화된 롤아웃과 롤백** -쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다. -* **자동화된 빈 패킹(bin packing)** -컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다. -* **자동화된 복구(self-healing)** -쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다. -* **시크릿과 구성 관리** -쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다. - -## 쿠버네티스가 아닌 것 - -쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다. - -쿠버네티스는: - -* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다. -* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다. -* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. -* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다. -* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. -* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. -* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. - - - -## {{% heading "whatsnext" %}} - -* [쿠버네티스 구성요소](/ko/docs/concepts/overview/components/) 살펴보기 -* [시작하기](/ko/docs/setup/) 준비가 되었는가? diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index 05bb5bd0749..05022d47c5f 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -40,7 +40,6 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 | `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 | | `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 | | `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는 데 사용되는 도구 | `helm` | 문자열 | -| `app.kubernetes.io/created-by` | 이 리소스를 만든 컨트롤러/사용자 | `controller-manager` | 문자열 | 위 레이블의 실제 예시는 다음 {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} 오브젝트를 고려한다. @@ -56,7 +55,6 @@ metadata: app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress app.kubernetes.io/managed-by: helm - app.kubernetes.io/created-by: controller-manager ``` ## 애플리케이션과 애플리케이션 인스턴스 diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index a91da3de2e2..fb151cc62a6 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -124,7 +124,7 @@ metadata: spec: containers: - name: cuda-test - image: "k8s.gcr.io/cuda-vector-add:v0.1" + image: "registry.k8s.io/cuda-vector-add:v0.1" resources: limits: nvidia.com/gpu: 1 diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md index 409b0a80fb5..4d2754c7183 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -203,7 +203,6 @@ spec: 정보를 제공한다. 파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다. -The scheduler always tries the "nominated Node" before iterating over any other nodes. 스케줄러는 다른 노드에 스케줄링을 시도하기 전에 항상 "지정된 노드"부터 시도한다. 피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다. 스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수 diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index 6ed35356597..fcabf42c3a3 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -54,8 +54,8 @@ profiles: 할당된 리소스의 구성된 기능에 따라 노드를 선호하게 한다. `NodeResourcesFit`점수 기능의 `RequestedToCapacityRatio` 동작은 [scoringStrategy](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-ScoringStrategy)필드를 이용하여 제어할 수 있다. -`scoringStrategy` 필드에서 `requestedToCapacityRatioParam`와 `resources`라는 두 개의 파라미터를 -구성할 수 있다. `requestedToCapacityRatioParam`파라미터의 +`scoringStrategy` 필드에서 `requestedToCapacityRatio`와 `resources`라는 두 개의 파라미터를 +구성할 수 있다. `requestedToCapacityRatio`파라미터의 `shape`를 사용하면 `utilization`과 `score` 값을 기반으로 최소 요청 혹은 최대 요청된 대로 기능을 조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과 @@ -77,7 +77,7 @@ profiles: weight: 3 - name: intel.com/bar weight: 3 - requestedToCapacityRatioParam: + requestedToCapacityRatio: shape: - utilization: 0 score: 0 diff --git a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md index 668cf715156..b831f73f46c 100644 --- a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md +++ b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md @@ -48,7 +48,8 @@ weight: 40 ## `topologySpreadConstraints` 필드 -파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 예시는 다음과 같다. +파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 이 필드는 다음과 같이 +쓰인다. ```yaml --- @@ -60,14 +61,18 @@ spec: # 토폴로지 분배 제약 조건을 구성한다. topologySpreadConstraints: - maxSkew: - minDomains: # 선택 사항이며, v1.24에서 알파 기능으로 도입되었다. + minDomains: # 선택 사항이며, v1.25에서 베타 기능으로 도입되었다. topologyKey: whenUnsatisfiable: labelSelector: + matchLabelKeys: # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다. + nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다. + nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다. ### 파드의 다른 필드가 이 아래에 오게 된다. ``` -`kubectl explain Pod.spec.topologySpreadConstraints` 명령을 실행하여 이 필드에 대해 좀 더 알아볼 수 있다. +`kubectl explain Pod.spec.topologySpreadConstraints` 명령을 실행하거나 파드에 관한 API 레퍼런스의 +[스케줄링](/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling) 섹션을 참조해서 이 필드에 대해 좀 더 알아볼 수 있다. ### 분배 제약 조건 정의 @@ -81,10 +86,10 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 - `whenUnsatisfiable: DoNotSchedule`을 선택했다면, `maxSkew`는 대상 토폴로지에서 일치하는 파드 수와 - _전역 최솟값(global minimum)_ (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수) + _전역 최솟값(global minimum)_ (적절한 도메인 내에서 일치하는 파드의 최소 수, 또는 적절한 도메인의 수가 `minDomains`보다 작은 경우에는 0) 사이의 최대 허용 차이를 나타낸다. - 예를 들어, 3개의 존에 각각 2, 4, 5개의 일치하는 파드가 있으면, - 전역 최솟값은 2이며 시스템은 이 숫자를 `maxSkew`와 비교한다. + 예를 들어, 3개의 존에 각각 2, 2, 1개의 일치하는 파드가 있으면, + `maxSkew`는 1로 설정되고 전역 최솟값은 1로 설정된다. - `whenUnsatisfiable: ScheduleAnyway`를 선택하면, 스케줄러는 차이(skew)를 줄이는 데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다. @@ -93,9 +98,8 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다. {{< note >}} - `minDomains` 필드는 1.24에서 추가된 알파 필드이다. - 이를 사용하려면 `MinDomainsInPodToplogySpread` - [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. + `minDomains` 필드는 1.25에서 기본적으로 사용하도록 설정된 베타 필드이다. 사용을 원하지 않을 경우 + `MinDomainsInPodToplogySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다. {{< /note >}} - `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다. @@ -108,10 +112,12 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 이 값은 스케줄링에 영향을 미치지 않는다. - `minDomains`를 명시하지 않으면, 분배 제약 조건은 `minDomains`가 1이라고 가정하고 동작한다. -- **topologyKey** 는 [노드 레이블](#node-labels)의 키(key)이다. - 만약 두 노드가 이 키로 레이블이 지정되고 레이블이 동일한 값을 가진다면, - 스케줄러는 두 노드를 같은 토폴로지에 있는 것으로 여기게 된다. - 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다. +- **topologyKey** 는 [노드 레이블](#node-labels)의 키(key)이다. 이 키와 동일한 값을 가진 + 레이블이 있는 노드는 동일한 토폴로지에 있는 것으로 간주된다. + 토폴로지의 각 인스턴스(즉, <키, 값> 쌍)를 도메인이라고 한다. 스케줄러는 + 각 도메인에 균형잡힌 수의 파드를 배치하려고 시도할 것이다. + 또한, 노드가 nodeAffinityPolicy 및 nodeTaintsPolicy의 요구 사항을 충족하는 도메인을 + 적절한 도메인이라고 정의한다. - **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 파드를 처리하는 방법을 나타낸다. - `DoNotSchedule`(기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다. @@ -123,6 +129,54 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다. +- **matchLabelKeys** 는 분배도(spreading)가 계산될 파드를 선택하기 위한 파드 레이블 + 키 목록이다. 키는 파드 레이블에서 값을 조회하는 데 사용되며, 이러한 키-값 레이블은 `labelSelector`와 AND 처리되어 들어오는 파드(incoming pod)에 대해 분배도가 계산될 기존 파드 그룹의 선택에 사용된다. 파드 레이블에 없는 키는 무시된다. null 또는 비어 있는 목록은 `labelSelector`와만 일치함을 의미한다. + + `matchLabelKeys`를 사용하면, 사용자는 다른 리비전 간에 `pod.spec`을 업데이트할 필요가 없다. 컨트롤러/오퍼레이터는 다른 리비전에 대해 동일한 `label`키에 다른 값을 설정하기만 하면 된다. 스케줄러는 `matchLabelKeys`를 기준으로 값을 자동으로 가정할 것이다. 예를 들어 사용자가 디플로이먼트를 사용하는 경우, 디플로이먼트 컨트롤러에 의해 자동으로 추가되는 `pod-template-hash`로 키가 지정된 레이블을 사용함으로써 단일 디플로이먼트에서 서로 다른 리비전을 구별할 수 있다. + + ```yaml + topologySpreadConstraints: + - maxSkew: 1 + topologyKey: kubernetes.io/hostname + whenUnsatisfiable: DoNotSchedule + matchLabelKeys: + - app + - pod-template-hash + ``` + + {{< note >}} + `matchLabelKeys` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면 + `MatchLabelKeysInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) + 를 활성화시켜야 한다. + {{< /note >}} + +- **nodeAffinityPolicy**는 파드 토폴로지의 스프레드 스큐(spread skew)를 계산할 때 + 파드의 nodeAffinity/nodeSelector를 다루는 방법을 나타낸다. 옵션은 다음과 같다. + - Honor: nodeAffinity/nodeSelector와 일치하는 노드만 계산에 포함된다. + - Ignore: nodeAffinity/nodeSelector는 무시된다. 모든 노드가 계산에 포함된다. + + 옵션의 값이 null일 경우, Honor 정책과 동일하게 동작한다. + + {{< note >}} + `nodeAffinityPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면 + `NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) + 를 활성화시켜야 한다. + {{< /note >}} + +- **nodeTaintsPolicy**는 파드 토폴로지의 스프레드 스큐(spread skew)를 계산할 때 노드 테인트(taint)를 + 다루는 방법을 나타낸다. 옵션은 다음과 같다. + - Honor: 테인트가 없는 노드, 그리고 노드가 톨러레이션이 있는 들어오는 파드(incoming pod)를 위한 테인트가 설정된 + 노드가 포함된다. + - Ignore: 노드 테인트는 무시된다. 모든 노드가 포함된다. + + 옵션의 값이 null일 경우, Ignore 정책과 동일하게 동작한다. + + {{< note >}} + `nodeTaintsPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면 + `NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) + 를 활성화시켜야 한다. + {{< /note >}} + 파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 논리 AND 연산으로 조합되며, kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다. @@ -557,6 +611,7 @@ profiles: 예를 들어 노드 풀(또는 노드 그룹)이 0으로 스케일 다운되고, 클러스터가 다시 스케일 업 되기를 기대하는 경우, 해당 토폴로지 도메인은 적어도 1개의 노드가 존재하기 전에는 고려가 되지 않을 것이다. + 이를 극복하기 위해, 파드 토폴로지 분배 제약 조건과 전반적인 토폴로지 도메인 집합에 대한 정보를 인지하고 동작하는 클러스터 오토스케일링 도구를 이용할 수 있다. diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index 88a83a627db..7c526a4a3b5 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -136,7 +136,7 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre 쿠버네티스 감사는 클러스터에서 발생하는 일들의 순서를 문서로 기록하여, 보안과 관련되어 있고 시간 순서로 정리된 기록을 제공한다. 클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션, 그리고 컨트롤 플레인 자신이 생성한 활동을 감사한다. -더 많은 정보는 [감사](/docs/tasks/debug/debug-cluster/audit/)를 참고한다. +더 많은 정보는 [감사](/ko/docs/tasks/debug/debug-cluster/audit/)를 참고한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/security/multi-tenancy.md b/content/ko/docs/concepts/security/multi-tenancy.md new file mode 100755 index 00000000000..e91f159b9f8 --- /dev/null +++ b/content/ko/docs/concepts/security/multi-tenancy.md @@ -0,0 +1,516 @@ +--- +title: 멀티 테넌시(multi-tenancy) +content_type: concept +weight: 70 +--- + + + +이 페이지는 클러스터 멀티 테넌시를 구현하기 위해 유효한 구성 옵션과 모범 사례에 대한 개요를 +제공한다. + +클러스터 공유를 통해 비용 절감 및 운영을 간편화할 수 있다. 그러나 클러스터를 공유하게 되면 +보안, 공평성, _소란스러운 이웃(noisy neighbors)_ 관리와 같이 여러 문제 상황이 발생할 수 있다. + +클러스터는 다양한 방법을 통해 공유될 수 있다. 특정 경우에는 같은 클러스터 내 서로 다른 애플리케이션이 실행될 수 있다. +또 다른 경우에는 하나의 애플리케이션에서 각 엔드유저에 대한 인스턴스가 모여 여러 인스턴스가 같은 클러스터 내에서 실행될 수 있다. +이러한 모든 종류의 공유 방법은 주로 +_멀티 테넌시_ 라는 포괄적 용어로 통칭한다. + +쿠버네티스에서는 엔드 유저 또는 테넌트에 대한 정형화된 개념을 정해놓고 있지는 않지만, +다양한 테넌시 요구사항을 관리하기 위한 몇 가지 기능을 제공한다. 이에 대한 내용은 밑에서 다룬다. + + +## 유스케이스 + +클러스터를 공유하기 위해 고려해야 하는 첫 번째 단계는, +사용 가능한 패턴과 툴을 산정하기 위해 유스케이스를 이해하는 것이다. 일반적으로 쿠버네티스에서의 멀티 테넌시는 +다양한 형태로 변형 또는 혼합이 가능하지만, 넓게는 두 가지 범주로 분류된다. + +### 다수의 팀 + +흔히 사용하는 멀티 테넌시의 형태는 하나 또는 그 이상의 워크로드를 +운영하는 한 조직 소속의 여러 팀이 하나의 클러스터를 공유하는 형태이다. 이러한 워크로드는 +같은 클러스터 내외의 다른 워크로드와 잦은 통신이 필요하다. + +이러한 시나리오에서 팀에 속한 멤버는 보통 `kubectl`과 같은 툴을 통해 쿠버네티스 리소스에 직접적으로 접근하거나, +GitOps 컨트롤러 혹은 다른 종류의 배포 자동화 툴을 통해 간접적으로 접근한다. +대개는 다른 팀 멤버 간에 일정량의 신뢰가 형성되어 있지만, +안전하고 공평한 클러스터 공유를 위해서는 +RBAC, 쿼터(quota), 네트워크 정책과 같은 쿠버네티스 정책이 필수이다. + +### 다수의 고객 + +다른 주요 멀티 테넌시 형태로는 서비스형소프트웨어(SaaS) 사업자가 +여러 고객의 워크로드 인스턴스를 실행하는 것과 관련이 있다. +이러한 비즈니스 모델은 많은 이들이 "SaaS 테넌시"라고 부르는 배포 스타일과 밀접한 연관이 있다. +그러나 SaaS 사업자는 다른 배포 모델을 사용할 수 있기도 하며 SaaS가 아니어도 이러한 배포 모델의 적용이 가능하기 때문에, +"다중 고객 테넌시(multi-customer tenancy)"를 더 적합한 용어로 볼 수 있다. + +고객은 이러한 시나리오에서 클러스터에 대한 접근 권한을 가지지 않는다. 쿠버네티스는 그들의 +관점에서는 보이지 않으며, 사업자가 워크로드를 관리하기 위해서만 사용된다. 비용 최적화는 +주로 중대한 관심사가 되며, +워크로드 간의 확실한 격리를 보장하기 위해 쿠버네티스 정책이 사용된다. + +## 용어 + +### 테넌트 + +쿠버네티스에서의 멀티 테넌시를 논할 때는, +"테넌트(tenant)"를 하나의 의미로 해석할 수 없다. +오히려 다중 팀 혹은 다중 고객 테넌시의 여부에 따라 테넌트의 정의는 달라진다. + +다중 팀 사용(multi-team usage)에서의 테넌트는 일반적으로 하나의 팀을 의미하며, +이 팀은 일반적으로 서비스의 복잡도에 따라 스케일 하는 작은 양의 워크로드를 다수 배포한다. +그러나 "팀" 자체에 대한 정의도 상위 조직으로 +구성될 수 있기도 하고 작은 팀으로 세분화될 수 있기 때문에 정의가 모호할 수 있다. + +반대로 각 팀이 새로운 고객에 대한 전용 워크로드를 배포하게 된다면, +다중 고객 테넌시 모델을 사용한다고 볼 수 있다. 이와 같은 경우에서는, +"테넌트"는 하나의 워크로드를 공유하는 사용자의 집합을 의미한다. +이는 하나의 기업만큼 큰 규모일 수도 있고, 해당 기업의 한 팀 정도의 작은 규모일수도 있다. + +같은 조직이 "테넌트"에 대한 두 개의 정의를 서로 다른 맥락에서 사용할 수 있는 경우가 많다. +예를 들어, 플랫폼 팀은 다수의 내부 "고객"을 위해 보안 툴 및 데이터베이스와 같은 공유된 서비스를 제공할 수 있고, +SaaS 사업자는 공유된 개발 클러스터를 다수의 팀에게 제공할 수 있다. +마지막으로, SaaS 제공자는 민감한 데이터를 다루는 고객별 워크로드와 +공유된 서비스를 다루는 멀티 테넌트를 혼합하여 제공하는 하이브리드 구조도 +사용이 가능하다. + +{{< figure src="/images/docs/multi-tenancy.png" title="공존하는 테넌시 모델을 나타내고 있는 클러스터" class="diagram-large" >}} + +### 격리 + +쿠버네티스에서 멀티 테넌트 솔루션을 설계하고 빌드 하는 방법은 몇 가지가 있다. +각 방법은 격리 수준, 구현 비용, 운영 복잡도, 서비스 비용에 +영향을 미치는 각자만의 상충 요소를 가지고 있다. + +각 쿠버네티스 클러스터는 쿠버네티스 소프트웨어를 실행하는 컨트롤 플레인과 +테넌트의 워크로드가 파드의 형태로 실행되고 있는 워커 노드로 구성된 데이터 플레인으로 구성되어 있다. +테넌트 격리는 조직의 요구사항에 따라 컨트롤 플레인 및 데이터 플레인 모두에 대해 적용할 수 있다. + +제공되는 격리의 수준은 강한 격리를 의미하는 "하드(hard)" 멀티 테넌시와 +약한 격리를 의미하는 "소프트(soft)" 멀티 테넌시와 같은 용어를 통해 정의한다. +특히 "하드" 멀티 테넌시는 주로 보안이나 리소스 공유 관점(예를 들어, 데이터 유출 및 DoS 공격에 대한 방어)에서 +테넌트가 서로 신뢰하지 않는 상황을 설명할 때 주로 사용한다. +데이터 플레인은 일반적으로 더 큰 공격 영역을 가지고 있기 때문에, +컨트롤 플레인 격리 또한 중요하지만 데이터 플레인을 격리하는 데 있어서 +"하드" 멀티 테넌시는 추가적인 주의를 요구한다. + +그러나 모든 사용자에게 적용할 수 있는 하나의 정의가 없기 때문에, +"하드"와 "소프트" 용어에 대한 혼동이 생길 수 있다. +오히려 요구사항에 따라 클러스터 내에서 다양한 종류의 격리를 유지할 수 있는 다양한 기법을 다루는 "하드한 정도" +혹은 "소프트한 정도"가 넓은 범위에서는 이해하기에 편하다. + +극단적인 경우에는 클러스터 레벨의 공유를 모두 포기하고 각 테넌트에 대한 전용 클러스터를 할당하거나, +가상머신을 통한 보안 경계가 충분하지 않다고 판단될 시에는 +전용 하드웨어에서 실행하는 것이 쉽고 적절한 방법일 수 있다. +클러스터를 생성하고 운영하는데 필요한 오버헤드를 클라우드 공급자가 맡게 되는 +매니지드 쿠버네티스 클러스터에서는 이와 같은 방식을 사용하기에 더 쉬울 수 있다. +강한 테넌트 격리의 장점은 여러 클러스터를 관리하는데 필요한 비용과 복잡도와 비교하여 산정되어야 한다. +[멀티 클러스터 SIG](https://git.k8s.io/community/sig-multicluster/README.md)는 이러한 종류의 유스케이스를 다루는 작업을 담당한다. + +이 페이지의 남은 부분에서는 공유 쿠버네티스 클러스터에서 사용되는 격리 기법을 중점적으로 다룬다. +그러나 전용 클러스터를 고려하고 있다 하더라도, 요구사항 혹은 기능에 대한 변화가 생겼을 때 +공유 클러스터로 전환할 수 있는 유연성을 제공할 수 있기 때문에, +이러한 권고사항을 검토해 볼 가치가 있다. + +## 컨트롤 플레인 격리 + +컨트롤 플레인 격리는 서로 다른 테넌트가 서로의 쿠버네티스 API 리소스에 +대한 접근 및 영향을 미치지 못하도록 보장한다. + +### 네임스페이스 + +쿠버네티스에서 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}는 +하나의 클러스터 내에서 API 리소스 그룹을 격리하는 데 사용하는 기능이다. +이러한 격리는 두 가지 주요 특징을 지닌다. + +1. 네임스페이스 내의 오브젝트 이름은 폴더 내의 파일과 유사하게 다른 네임스페이스에 속한 +이름과 중첩될 수 있다. 이를 통해 각 테넌트는 다른 테넌트의 활동과 무관하게 자신의 +리소스에 대한 이름을 정할 수 있다. + +2. 많은 쿠버네티스 보안 정책은 네임스페이스 범위에서 사용한다. 예를 들어, RBAC 역할과 +네트워크 정책은 네임스페이스 범위의 리소스이다. RBAC를 사용함으로써 사용자 및 서비스 +어카운트는 하나의 네임스페이스에 대해 제한될 수 있다. + +멀티 테넌트 환경에서의 각 네임스페이스는 테넌트의 워크로드를 논리적이고 구별되는 관리 +단위로 분할할 수 있다. 실제로 일반적인 관습에서는 여러 워크로드가 하나의 테넌트에 의해 +운영되더라도, 각 워크로드를 개별 네임스페이스로 격리한다. 이를 통해 각 워크로드는 개별 +정체성을 가질 수 있으며 적절한 보안 정책을 적용 받을 수 있게끔 보장한다. + +네임스페이스 격리 모델은 테넌트 워크로드를 제대로 격리 시키기 위해 몇 가지 다른 +쿠버네티스 리소스, 네트워크 플러그인, 보안 모범 사례에 대한 준수가 필요하다. 이와 같이 +고려해야 하는 사항은 아래에 명시되어 있다. + +### 접근 제어 + +컨트롤 플레인에서의 가장 중요한 격리 방식은 인증이다. 만일 팀 또는 해당 팀의 워크로드가 +서로 다른 API 리소스에 대한 접근 및 수정이 가능하다면, 다른 종류의 정책을 모두 바꾸거나 +비활성화할 수 있게 되어 해당 정책이 제공하는 보호를 무효화한다. 따라서 각 테넌트가 필요로 +하는 네임스페이스에 대한 적절한 최소의 권한만을 부여하는 것이 중요하다. 이는 "최소 권한의 +원칙(Principle of Least Privilege)"이라고 부른다. + + +역할 기반 접근 제어(RBAC)는 흔히 쿠버네티스 컨트롤 플레인에서의 사용자와 워크로드에 +(서비스 어카운트) 대한 인증을 시행하기 위해 사용된다. +[롤(Roles)](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)과 +[롤바인딩(RoleBindings)](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)은 네임스페이스 레벨에서 애플리케이션의 +접근 제어를 시행하기 위해 사용되는 쿠버네티스 오브젝트이다. +클러스터 레벨의 오브젝트에 대한 접근 권한을 인증하기 위해 사용되는 유사한 오브젝트도 존재하지만, 이는 멀티 테넌트 클러스터에서는 비교적 유용성이 떨어진다. + +다중 팀 환경에서는, 클러스터 전범위 리소스에 대해 클러스터 운영자와 같이 특권을 가진 +사용자에 의해서만 접근 또는 수정이 가능하도록 보장하기 위해 RBAC를 사용하여 테넌트의 +접근을 적합한 네임스페이스로 제한해야 한다. + +만일 사용자에게 필요 이상으로 권한을 부여하는 정책이 있다면, 이는 영향 받는 리소스를 +포함하고 있는 네임스페이스가 더 세분화된 네임스페이스로 재구성 되어야 한다는 신호일 +가능성이 높다. 네임스페이스 관리 툴을 통해 공통된 RBAC 정책을 서로 다른 네임스페이스에 +적용하고 필요에 따라 세분화된 정책은 허용하며, 세분화된 네임스페이스를 +간편하게 관리할 수 있다. + +### 쿼터 + +쿠버네티스 워크로드는 CPU 및 메모리와 같은 노드 리소스를 소모한다. 멀티 테넌트 환경에서는, +테넌트 워크로드의 리소스 사용량을 관리하기 위해 [리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/)를 사용할 수 있다. +테넌트가 쿠버네티스 API에 대한 접근 권한을 가지는 다수 팀 유스케이스의 경우에는, +테넌트가 생성할 수 있는 API 리소스(예를 들어, 파드의 개수 혹은 컨피그맵의 개수)의 +개수를 리소스 쿼터를 사용하여 제한할 수 있다. +오브젝트 개수에 대한 제한은 공평성을 보장하고 같은 컨트롤 플레인을 공유하는 테넌트 간 침범이 발생하는 +_소란스러운 이웃_ 문제를 예방하기 위한 목적을 가지고 있다. + +리소스 쿼터는 네임스페이스 오브젝트이다. 테넌트를 네임스페이스에 대해 매핑함으로써, +클러스터 운영자는 쿼터를 사용하여 하나의 테넌트가 클러스터의 리소스를 독점하거나 컨트롤 +플레인을 압도하지 못하도록 보장할 수 있다. 네임스페이스 관리 툴은 쿼터 운영을 +간편화해준다. 이에 더해 쿠버네티스 쿼터는 하나의 네임스페이스 내에서만 적용이 가능하지만, +특정 네임스페이스 관리 툴은 네임스페이스 그룹이 쿼터를 공유할 수 있도록 허용함으로써 +운영자에게 내장된 쿼터에 비해 적은 수고로 더 많은 유연성을 제공한다. + +쿼터는 하나의 테넌트가 자신에게 할당된 몫의 리소스 보다 많이 사용하는 것을 방지하며, 이를 +통해 하나의 테넌트가 다른 테넌트의 워크로드 성능에 부정적 영향을 미치는 "소란스러운 이웃" +문제를 최소화할 수 있다. + +쿠버네티스에서 네임스페이스에 대한 쿼터를 적용할 시에는 각 컨테이너에 대한 리소스 요청과 +제한을 명시하도록 요구한다. 제한은 각 컨테이너가 소모할 수 있는 리소스의 양에 대한 +상한선이다. 설정된 제한을 초과하여 리소스 소모를 시도하는 컨테이너는 리소스의 종류에 따라 +스로틀(throttled)되거나 종료(killed)된다. 리소스 요청이 제한보다 낮게 설정되었을 시에는, +각 컨테이너가 요청한 리소스의 양은 보장되지만 +워크로드 간의 영향이 있을 가능성은 존재한다. + +쿼터는 네트워크 트래픽과 같이 모든 종류의 리소스 공유에 대한 보호는 할 수 없다. +노드 격리(아래에서 설명)가 이러한 문제에 대해서는 더 나은 해결책일 수 있다. + +## 데이터 플레인 격리 + +데이터 플레인 격리는 다른 테넌트의 파드 및 워크로드와 충분히 격리가 이루어질 수 있도록 +보장한다. + +### 네트워크 격리 + +기본적으로 쿠버네티스 클러스터의 모든 파드는 서로 통신을 할 수 있도록 허용되어 있으며 모든 +네트워크 트래픽은 암호화되어 있지 않다. 이는 트래픽이 실수 또는 악의적으로 의도되지 않은 +목적지로 전송되거나 신뢰가 손상된(compromised) 노드 상의 워크로드에 의해 가로채지는 것과 +같은 보안 취약점으로 이어질 수 있다. + +파드에서 파드로의 통신은 네임스페이스 레이블 혹은 IP 주소 범위를 통해 파드 간의 통신을 +제한하는 [네트워크 정책](/ko/docs/concepts/services-networking/network-policies/)에 +의해 제어될 수 있다. 테넌트 간의 엄격한 네트워크 격리가 필요한 멀티 테넌트 환경에서는, +파드 간의 통신을 거부하는 기본 정책과 모든 파드가 네임 해석(name resolution)을 위해 +DNS 서버를 쿼리하도록 하는 규칙을 시작에 설정하는 것을 권고한다. 이러한 기본 정책을 +기반으로 하여, 네임스페이스 내에서 통신을 허용하는 관대한 규칙을 추가할 수 있다. 이러한 +방식은 요구에 따라 한 단계 더 정제할 수 있다. 이는 하나의 컨트롤 플레인 내의 파드에 +대해서만 적용된다는 것을 알아두어야 한다. 서로 다른 가상의 컨트롤 플레인에 소속된 파드는 +쿠버네티스 네트워킹을 통해 통신할 수 없다. + +네임스페이스 관리 툴을 통해 기본 또는 공통 네트워크 정책을 간편하게 생성할 수 있다. 이에 +더해, 몇 가지 툴은 클러스터 상에서 일관된 집합의 네임스페이스 레이블을 사용할 수 있게 +함으로써 정책에 대한 신뢰 가능한 기반이 마련될 수 있도록 보장한다. + +{{< warning >}} +네트워크 정책은 구현 과정에서 지원되는 [CNI 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)을 요구한다. +만일 그렇지 않으면, 네트워크폴리시 리소스는 무시된다. +{{< /warning >}} + +추가적으로, 서비스 메쉬(service mesh)는 워크로드 특징에 따른 OSI 7 계층 정책을 +제공하므로 네임스페이스보다 더 고도의 네트워크 격리를 제공할 수 있다. 이러한 상위 정책은 특히 +하나의 테넌트에 대한 여러 네임스페이스가 있는 경우와 같이, 네임스페이스 기반 멀티 테넌시를 +더욱 쉽게 관리할 수 있도록 한다. 신뢰가 손상된(compromised) 노드가 발생했을 시에도 데이터를 보호할 수 +있는 상호 간의 TLS을 통해 암호화도 제공하며 전용 또는 가상의 클러스터 사이에서도 +동작한다. 그러나 관리하기에 더 복잡할 수 있으며 모든 사용자에게 적합한 방법이 아닐 수 있다. + +### 스토리지 격리 + +쿠버네티스는 워크로드가 퍼시스턴트 스토리지로 사용할 수 있는 몇 가지 종류의 볼륨을 +제공한다. 보안 및 데이터 격리를 위해서는 [동적 볼륨 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 +권고하며 노드 리소스를 사용하는 볼륨 타입은 피해야 한다. + +[스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)는 클러스터에 +제공하는 사용자 정의 "클래스"를 서비스 품질 수준(quality-of-service level), 백업 정책 혹은 클러스터 운영자에 의해 +결정된 사용자 정의 정책을 기반으로 명시할 수 있도록 허용한다. + +파드는 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/)을 +통해 스토리지를 요청할 수 있다. 퍼시스턴트 볼륨 클레임은 공용 쿠버네티스 클러스터 내에서 +스토리지 시스템의 부분 단위 격리를 가능하게끔 하는 네임스페이스 리소스이다. 그러나 +퍼시스턴트 볼륨은 클러스터 전범위(cluster-wide)의 리소스이며 워크로드와 네임스페이스의 라이프사이클에 +독립적이므로, 이를 염두에 둘 필요가 있다. + +예를 들어, 각 테넌트에 대한 별도의 스토리지 클래스를 설정할 수 있으며 이를 통해 격리를 강화할 수 있다. +만일 스토리지 클래스가 공유된다면, [`Delete` 리클레임(reclaim) 정책](/ko/docs/concepts/storage/storage-classes/#리클레임-정책)을 설정하여 +퍼시스턴트 볼륨이 다른 네임스페이스에서 재사용되지 못하도록 보장해야 한다. + +### 컨테이너 샌드박싱(sandboxing) + +{{% thirdparty-content %}} + +쿠버네티스 파드는 워커 노드 상에서 실행되는 하나 또는 그 이상의 컨테이너로 구성되어 있다. +컨테이너는 OS 레벨의 가상화를 활용하기 때문에 하드웨어 기반의 가상화를 활용하는 +가상 머신에 비해 격리의 경계가 약하다. + +공유 환경에서 애플리케이션 및 시스템 계층 상 패치되지 않은 취약점은 +컨테이너 탈출(container breakout) 또는 원격 코드 실행과 같이 호스트 리소스에 대한 +접근을 허용하여 공격자에 의해 악용될 수 있다. 컨텐츠 매니지먼트 시스템(CMS)과 같은 특정 +애플리케이션에서는, 고객이 신뢰되지 않은 스크립트 및 코드를 업로드할 수 있는 기능이 허용될 수 있다. +어떤 경우이든, 강한 격리를 통해 워크로드를 한 단계 더 격리하고 보호하기 위한 기능은 필요하다. + +샌드박싱은 공유 클러스터에서 실행되는 워크로드를 격리하는 방법을 제공한다. 일반적으로 각 +파드를 가상 머신 또는 유저스페이스 커널(userspace kernel)과 같은 별도의 실행 환경에서 실행하는 것과 연관이 +있다. 샌드박싱은 주로 워크로드가 악의적으로 판단되는 신뢰되지 않은 코드를 실행할 때 +권고된다. 이러한 격리가 필요한 이유는 컨테이너가 공유된 커널에서 실행되기 때문이다. +컨테이너는 하위 호스트의 `/sys` 및 `/proc` 와 같은 파일 시스템을 마운트 하기 때문에, +개별 커널을 가지는 가상 머신에서 실행되는 애플리케이션과 비교하였을 때는 보안성이 낮다. +Seccomp, AppArmor, SELinux와 같은 제어를 통해 컨테이너의 보안을 강화할 수 있지만, +공유 클러스터에서 실행되고 있는 모든 워크로드에 대해 공통된 규칙을 적용하는 데는 어려움이 +있다. 워크로드를 샌드박스 환경에서 실행함으로써, 공격자가 호스트의 취약점을 악용하여 +호스트 시스템 및 해당 호스트에서 실행되고 있느 모든 프로세스와 파일 대한 권한을 얻을 수 +있는 컨테이너 탈출로 부터 호스트를 보호할 수 있다. + +가상 머신 및 유저스페이스 커널은 샌드박싱을 제공하는 대표적인 두 가지 방법이다. +다음과 같은 샌드박싱 구현이 가능하다. + +* [gVisor](https://gvisor.dev/)는 컨테이너로부터 시스템 호출을 가로채 Go로 작성된 + 유저스페이스 커널을 통해 실행하므로, 컨테이너가 호스트 내부(underlying host)에 대한 제한적인 접근 권한만 가진다. +* [Kata 컨테이너](https://katacontainers.io/)는 OCI에 부합하는 런타임으로 가상 머신 내에서 + 컨테이너가 실행되도록 한다. Kata는 하드웨어 가상화를 통해, 신뢰되지 않은 + 코드를 실행하는 컨테이너에 대해 추가적인 보안 계층을 제공한다. + +### 노드 격리 + +노드 격리는 테넌트 워크로드를 서로 격리시킬 수 있는 또 다른 기법이다. 노드 격리를 통해 +하나의 노드 집합은 특정 테넌트의 파드를 전용으로 실행할 수 있으며 테넌트 파드 간의 혼합(co-mingling)은 +금지되어 있다. 이러한 구성을 사용하게 되면 노드 상에서 실행되는 파드가 모두 하나의 테넌트 +소유이기 때문에 소란스러운 테넌트 문제를 줄일 수 있다. 컨테이너 탈출에 성공한 공격자가 +있다 하더라도, 해당 노드의 컨테이너 및 마운트 된 볼륨에 대해서만 접근 권한을 가지므로, +노드 격리를 통해 정보 유출의 위험도 비교적 감소한다. + +다른 테넌트의 워크로드가 다른 노드에서 실행되고 있다 하더라도, Kubelet과 (가상 컨트롤 +플레인을 사용하지 않는 한) API 서비스는 여전히 공유되고 있다는 사실을 이해하는 것은 중요하다. +능숙한 공격자는 Kubelet 또는 노드에서 실행되고 있는 다른 파드에 부여된 권한을 이용하여 +클러스터 내에서 좌우로 이동하며 다른 노드에서 실행되고 있는 테넌트 워크로드에 대한 접근 +권한을 얻을 수 있다. 만일 이러한 사항이 우려된다면, seccomp, AppArmor, SELinux와 같은 +제어 방식을 이용하거나, 샌드박스 컨테이너 이용 또는 각 테넌트에 대한 개별 클러스터를 +생성하는 방안을 검토해 보아야 한다. + +노드 격리를 통해 파드가 아닌 노드 별 비용을 청구할 수 있으므로, 비용 관점에서는 샌드박스 컨테이너에 +비해 이해 및 파악이 수월하다. 또한 호환성 및 +성능 문제 발생 가능성이 낮으며 샌드박스 컨테이너 보다 구현도 더 쉬운 편이다. 예를 들어, 각 +테넌트에 대한 노드는 대응하는 톨러레이션(toleration)을 가진 파드만 실행할 수 있도록 테인트(taint)를 통해 +설정할 수 있다. 변화하는 웹훅을 통해 자동으로 톨러레이션과 노드 어피니티를 테넌트 +네임스페이스에 배포된 파드에 추가하여, 해당 파드를 특정 테넌트를 위해 지정된 특정 노드의 +집합에서 실행될 수 있도록 한다. + +노드 격리는 [파드 노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) +또는 [가상 Kubelet(Virtual Kubelet)](https://github.com/virtual-kubelet)을 통해 구현할 수 있다. + +## 추가적인 고려 사항 + +해당 섹션에서는 멀티 테넌시와 연관 있는 이외의 쿠버네티스 구성 및 패턴에 대한 내용을 다룬다. + +### API 우선순위와 공평성 + +[API 우선순위(priority)와 공평성(fairness)](/docs/concepts/cluster-administration/flow-control/)은 +쿠버네티스의 기능 중 하나로, 클러스터 내 실행 중인 특정 파드에 대해 우선순위를 부여할 수 +있다. 애플리케이션이 쿠버네티스 API를 호출하게 되면, API 서버는 해당 파드에 부여된 +우선순위를 산정한다. 더 높은 우선순위를 가진 파드의 호출은 낮은 우선순위를 가진 파드의 +호출보다 먼저 수행된다. 경합률(contention)이 높을 시에는 낮은 우선순위의 호출은 서버 리소스가 한가해질 +때까지 대기하거나 해당 요청을 거부할 수 있다. + +고객이 쿠버네티스 API와 상호작용하는 애플리케이션(예를 들어, 컨트롤러)을 실행하지 않은 한, +SaaS 환경에서 API 우선순위와 공평성을 사용하는 일은 +흔치 않을 것이다. + +### 서비스 품질(QoS) {#qos} + +SaaS 애플리케이션을 실행할 시에는, 각 테넌트에게 다른 수준의 서비스 품질 티어(tier)를 +제공하는 기능이 필요할 수 있다. 예를 들어, 낮은 성능 및 기능을 보장하는 무료 서비스와 특정 +수준의 성능을 보장하는 유료 서비스를 제공할 수 있다. 다행히 쿠버네티스는 이러한 티어를 공유 클러스터 +내에서 구현하기 위한 네트워크 QoS, 스토리지 클래스, 파드 우선순위 및 선점과 같은 +몇 가지 구성들을 제공한다. 이는 각 테넌트가 지불한 비용에 적합한 서비스 품질을 +제공하기 위한 목적이다. +우선 네트워크 QoS에 대해 먼저 살펴본다. + +일반적으로 하나의 노드에 위치한 모든 파드는 네트워크 인터페이스를 공유한다. 네트워크 +QoS 없이는, 몇 개의 파드가 가용 대역폭 중 다른 파드의 대역폭까지 +소모하여 불공평한 공유를 야기할 수 있다. +쿠버네티스 [대역폭 플러그인](https://www.cni.dev/plugins/current/meta/bandwidth/)은 +리눅스 tc 큐를 이용하여 파드에 비율 제한을 적용할 수 있는 쿠버네티스 리소스 구성(예를 들어, 요청/제한)을 사용 가능하게 하는 네트워킹 +[확장 리소스](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를 생성한다. +[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#support-traffic-shaping) +문서에 따르면 해당 플러그인은 아직은 실험 목적으로 사용되고 있다는 점에 대한 주의가 +필요하며 프로덕션 환경에서 사용하기 전에는 철저한 테스트가 이루어져야 한다. + +스토리지 서비스 품질과 같은 경우에는, 각 성능 특징을 나타내기 위해 서로 다른 스토리지 +클래스 또는 프로필을 생성할 필요가 있다. 각 스토리지 프로필은 IO, 중복성, 처리량과 같이 +서로 다른 워크로드에 최적화된 티어의 서비스와 묶을 수 있다. 테넌트가 자신의 워크로드에 +적합한 스토리지 프로필을 적용하기 위해서는 +추가적인 로직이 필요할 수 있다. + +마지막으로, 파드에 우선순위 값을 부여할 수 있는 +[파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)이 있다. +파드 스케줄링 시에 우선순위가 높은 파드를 스케줄링하기 위한 리소스가 부족하다면, +스케줄러는 낮은 우선순위의 파드에 대한 축출을 시도한다. 공유 클러스터 내에서 다른 서비스 +티어(예를 들어, 무료 및 유료)를 사용하는 테넌트를 가진 유스케이스가 있다면, 이러한 기능을 +활용하여 특정 티어에 더 높은 우선순위를 부여할 수 있다. + +### DNS + +쿠버네티스 클러스터는 네임과 IP 주소 간의 변환을 제공하기 위해 모든 서비스와 파드에서 +도메인 네임 시스템(DNS) 서비스를 포함하고 있다. 기본적으로 쿠버네티스 DNS 서비스를 통해 +클러스터 내 모든 네임스페이스를 조회할 수 있다. + +테넌트가 파드 및 다른 쿠버네티스 리소스에 접근할 수 있거나, +더욱 강력한 격리가 필요한 멀티 테넌트 환경에서는 +파드가 다른 네임스페이스의 서비스를 조회하는 것을 막는 것이 적절할 수 있다. +네임스페이스 교차 DNS 조회(cross-namespace DNS lookup)는 DNS 서비스의 보안 규칙 설정을 통해 제한할 수 있다. +예를 들어, CoreDNS(쿠버네티스 기본 DNS 서비스)는 쿠버네티스 메타데이터를 이용하여 네임스페이스 내의 파드 및 서비스에 대한 쿼리를 제한할 수 있다. +추가적인 정보는 +CoreDNS 문서에 포함된 해당 사항을 설정하는 +[예시](https://github.com/coredns/policy#kubernetes-metadata-multi-tenancy-policy)에서 확인할 수 있다. + +[테넌트 별 가상 컨트롤 플레인](#테넌트-별-가상-컨트롤-플레인) 모델이 사용될 시에는, +테넌트 별 DNS 서비스가 설정하거나 멀티 테넌트 DNS 서비스를 사용해야 한다. +[CoreDNS 사용자 맞춤 버전](https://github.com/kubernetes-sigs/cluster-api-provider-nested/blob/main/virtualcluster/doc/tenant-dns.md)은 +멀티 테넌트를 지원하는 하나의 예시이다. + +### 오퍼레이터 + +[오퍼레이터](/ko/docs/concepts/extend-kubernetes/operator/)는 +애플리케이션을 관리하는 쿠버네티스 컨트롤러이다. 오퍼레이터는 데이터베이스 서비스와 +유사하게 애플리케이션의 여러 인스턴스를 간편하게 관리할 수 있어, 다중 소비자 (SaaS) 멀티 +테넌시 유스케이스의 중요한 기반이 된다. + +멀티 테넌트 환경에서 사용되는 오퍼레이터는 더욱 엄격한 가이드라인을 준수해야 한다. +다음은 오퍼레이터가 지켜야 할 사항이다. + +* 오퍼레이터가 배포된 네임스페이스뿐만 아니라, +다른 테넌트 네임스페이스에서의 리소스 생성도 지원해야 한다. +* 스케줄링과 공평성을 보장하기 위해, 파드에 대한 리소스 요청 및 제한을 설정한다. +* 파드에서 노드 격리 및 샌드박스 컨테이너와 같은 데이터 플레인 격리 기법을 설정할 수 +있도록 지원한다. + +## 구현 + +{{% thirdparty-content %}} + +멀티 테넌시를 위해 쿠버네티스 클러스터를 공유하는 대표적인 방법은 두 가지가 있으며, +이는 네임스페이스 사용 (테넌트 별 네임스페이스) 또는 컨트롤 플레인 가상화 (테넌트 별 가상 +컨트롤 플레인)이다. + +두 경우 모두 데이터 플레인 격리와 API 우선순위 및 공평성과 같은 추가적인 고려 사항에 대한 +관리를 권고한다. + +네임스페이스 격리는 쿠버네티스에서 지원이 잘 이루어지고 있으며, 아주 적은 리소스 비용을 +소모하며 서비스 간의 통신과 같은 테넌트가 상호작용하기 위한 기능을 제공한다. 그러나 +설정하는 과정이 복잡하며 커스텀 리소스 데피니션 정의, 스토리지 클래스, 웹훅과 같이 +네임스페이스 적용을 받지 않은 쿠버네티스 리소스에 대해서는 적용되지 않는다. + +컨트롤 플레인 가상화는 더 많은 리소스 사용량과 더 어려운 테넌트 교차 공유(cross-tenant sharing)를 대가로, +네임스페이스 되지 않은 리소스에 대한 격리 기능을 제공한다. +네임스페이스 격리로는 충분하지 않으며 높은 운영 비용 (특히 온 프레미스) +또는 큰 오버헤드와 리소스 공유의 부재로 인한 전용 클러스터는 사용하지 못할 때 좋은 선택지다. +그러나, 가상 컨트롤 플레인을 사용하더라도 네임스페이스를 +같이 사용하면 이익을 볼 수 있다. + +두 가지의 옵션은 다음 섹션에서 상세히 다룬다. + +### 테넌트 별 네임스페이스 + +이전에 언급하였듯이, 전용 클러스터 또는 가상 컨트롤 플레인을 사용하더라도 각 워크로드를 +개별 네임스페이스로 격리하는 것을 고려해 보아야 한다. +이를 통해 각 워크로드는 컨피그맵 및 시크릿과 같이 자신의 리소스에만 접근할 수 있으며 +각 워크로드에 대한 전용 보안 정책을 조정할 수 있다. +추가적으로, 전용 및 공유 클러스터 간 전환 혹은 서비스 메쉬와 같은 멀티 +클러스터 툴을 이용할 수 있는 유연성을 제공받기 위해 각 네임스페이스 이름을 전체 클러스터 +무리 사이에서도 고유하게 짓는 것이 (즉, 서로 다른 클러스터에 위치하더라도) 모범 사례이다. + +반대로 워크로드 레벨이 아닌, 하나의 테넌트가 소유한 모든 워크로드에 대해 적용되는 정책도 +있기 때문에 테넌트 레벨에서의 네임스페이스 적용도 장점이 있다. 그러나 이는 또 다른 문제를 +제기한다. 첫 번째로 개별 워크로드에 대한 맞춤 정책을 적용하는 것이 어렵거나 불가능해지며, +두 번째로는 네임스페이스를 적용받을 하나의 "테넌시" 레벨을 정하는 것이 어려울 수 있다. +예를 들어, 하나의 조직에 부서, 팀, 하위 팀이 있다고 하면 어떤 단위에 대해 +네임스페이스를 적용해야 하는가? + +이러한 문제의 해결책으로, 네임스페이스를 계층으로 정리하고 특정 정책 및 리소스를 사이에서 +공유할 수 있는 [계층적 네임스페이스 컨트롤러(HNC)](https://github.com/kubernetes-sigs/hierarchical-namespaces)를 +쿠버네티스에서 제공하고 있다. 또한 네임스페이스 레이블 관리, 네임스페이스 라이프사이클, +관리 위임, 관련된 네임스페이스 사이에서 리소스 쿼터 공유와 같은 이점도 있다. 이러한 +기능은 다중 팀 및 다중 고객 시나리오에서도 유용하다. + +유사한 기능을 제공하며 네임스페이스 리소스 관리를 돕는 다른 프로젝트는 +다음과 같다. + +#### 다중 팀 테넌시 + +* [Capsule](https://github.com/clastix/capsule) +* [Kiosk](https://github.com/loft-sh/kiosk) + +#### 다중 고객 테넌시 + +* [Kubeplus](https://github.com/cloud-ark/kubeplus) + +#### 정책 엔진 + +정책 엔진은 테넌트 구성을 생성하고 검증하는 기능을 제공한다. + +* [Kyverno](https://kyverno.io/) +* [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper) + +### 테넌트 별 가상 컨트롤 플레인 + +컨트롤 플레인 격리의 또 다른 형태로는 쿠버네티스 확장을 이용하여 클러스터 전범위의 API +리소스를 세분화할 수 있는, 각 테넌트에 가상 컨트롤 플레인을 제공하는 형태이다. +[데이터 플레인 격리](#데이터-플레인-격리) 기법을 이러한 모델과 함께 이용하여 테넌트 +간의 워커 노드를 안전하게 관리할 수 있다. + +가상 컨트롤 플레인 기반의 멀티 테넌시 모델은 각 테넌트에게 전용 컨트롤 플레인 요소를 +제공하며 클러스터 전범위 리소스 및 애드온 서비스에 대한 완전한 제어를 부여하게 되어 +네임스페이스 기반 멀티 테넌시를 확장한다. 워커 노드는 모든 테넌트 간 공유 되며, +일반적으로 테넌트에 의해 접근이 불가능한 쿠버네티스 클러스터에 의해 관리된다. +이러한 클러스터를 _슈퍼 클러스터_ (혹은 _호스트 클러스터_)라고 부른다. +테넌트의 컨트롤 플레인은 하위 컴퓨팅 리소스와 직접적으로 연결된 것이 아니기 때문에 +_가상 컨트롤 플레인_ 이라고 부른다. + +가상 컨트롤 플레인은 일반적으로 쿠버네티스 API 서버, 컨트롤러 매니저, etcd 데이터 +스토어로 구성되어 있다. 테넌트 컨트롤 플레인과 슈퍼 클러스터 컨트롤 플레인 간 변화를 +조정하는 메타데이터 동기화 컨트롤러를 통해 +슈퍼 클러스터와 상호작용한다. + +하나의 API 서버를 사용하였을 때 나타나는 격리 문제는 테넌트 별 전용 컨트롤 플레인을 +이용하면 해결된다. 몇 가지 예시로는, 컨트롤 플레인 내의 소란스러운 이웃 문제, +잘못된 정책 설정으로 인한 제어불능 영향 반경, 웹훅 및 CRD와 같은 +클러스터 범위 오브젝트 간의 충돌이 있다. +그러므로 각 테넌트가 쿠버네티스 API 서버에 대한 접근 권한 및 완전한 클러스터 관리 +기능이 필요한 경우, 가상 컨트롤 플레인 모델이 적합하다. + +개선된 격리의 대가는 각 테넌트 별 가상 컨트롤 플레인을 운영하고 유지하는 비용에서 +나타난다. 추가적으로, 각 테넌트 컨트롤 플레인은 노드 레벨에서의 소란스러운 이웃 문제 또는 +보안 위협과 같은 데이터 플레인에서의 격리 문제를 해결하지 못한다. 이러한 문제에 대해서는 +별도로 대응해야 한다. + +쿠버네티스 [클러스터 API - 네스티드(CAPN)](https://github.com/kubernetes-sigs/cluster-api-provider-nested/tree/main/virtualcluster) +프로젝트는 가상 컨트롤 플레인 구현 방식을 제공한다. + +#### 이외의 구현 방식 + +* [Kamaji](https://github.com/clastix/kamaji) +* [vcluster](https://github.com/loft-sh/vcluster) + diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index 324fd1d4df2..bc9d9763de0 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -58,6 +58,7 @@ IaaS 공급자 | 링크 | Alibaba Cloud | https://www.alibabacloud.com/trust-center | Amazon Web Services | https://aws.amazon.com/security/ | Google Cloud Platform | https://cloud.google.com/security/ | +Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety.html | IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | Oracle Cloud Infrastructure | https://www.oracle.com/security/ | diff --git a/content/ko/docs/concepts/security/pod-security-policy.md b/content/ko/docs/concepts/security/pod-security-policy.md index 134d1eb249d..f30c57d79b3 100644 --- a/content/ko/docs/concepts/security/pod-security-policy.md +++ b/content/ko/docs/concepts/security/pod-security-policy.md @@ -1,6 +1,6 @@ --- # reviewers: -# - pweil- +# - liggitt # - tallclair title: 파드 시큐리티 폴리시 content_type: concept @@ -11,770 +11,19 @@ weight: 30 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}} -{{< caution >}} -파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더 이상 사용되지 않으며, **v1.25에서 제거될 예정**이다. -[파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 혹은 써드파티 어드미션 플러그인으로 대체하는 것을 권장한다. -상세 가이드는 [파드시큐리티폴리시를 파드 시큐리티 어드미션 컨트롤러로 대체하기](/docs/tasks/configure-pod-container/migrate-from-psp/)를 참조한다. -사용 중단에 대한 상세 사항은 -[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다. -{{< /caution >}} - -파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을 -부여할 수 있다. - - - -## 파드 시큐리티 폴리시란? - -_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의 -리소스이다. -[파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는 -관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는 -조건 셋을 정의한다. -관리자는 다음을 제어할 수 있다. - -| 제어 측면 | 필드 이름 | -| ----------------------------------------------------| ------------------------------------------- | -| 특권을 가진(privileged) 컨테이너의 실행 | [`privileged`](#특권을-가진) | -| 호스트 네임스페이스의 사용 | [`hostPID`, `hostIPC`](#호스트-네임스페이스) | -| 호스트 네트워킹과 포트의 사용 | [`hostNetwork`, `hostPorts`](#호스트-네임스페이스) | -| 볼륨 유형의 사용 | [`volumes`](#볼륨-및-파일시스템) | -| 호스트 파일시스템의 사용 | [`allowedHostPaths`](#볼륨-및-파일시스템) | -| 특정 FlexVolume 드라이버의 허용 | [`allowedFlexVolumes`](#flexvolume-드라이버) | -| 파드 볼륨을 소유한 FSGroup 할당 | [`fsGroup`](#볼륨-및-파일시스템) | -| 읽기 전용 루트 파일시스템 사용 필요 | [`readOnlyRootFilesystem`](#볼륨-및-파일시스템) | -| 컨테이너의 사용자 및 그룹 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#사용자-및-그룹) | -| 루트 특권으로의 에스컬레이션 제한 | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#권한-에스컬레이션) | -| 리눅스 기능 | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#기능) | -| 컨테이너의 SELinux 컨텍스트 | [`seLinux`](#selinux) | -| 컨테이너에 허용된 Proc 마운트 유형 | [`allowedProcMountTypes`](#allowedprocmounttypes) | -| 컨테이너가 사용하는 AppArmor 프로파일 | [어노테이션](#apparmor) | -| 컨테이너가 사용하는 seccomp 프로파일 | [어노테이션](#seccomp) | -| 컨테이너가 사용하는 sysctl 프로파일 | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl) | - - -## 파드 시큐리티 폴리시 활성화 - -파드 시큐리티 폴리시 제어는 선택 사항인 [어드미션 -컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로 구현된다. -[어드미션 컨트롤러를 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면 -파드시큐리티폴리시가 적용되지만, -정책을 승인하지 않고 활성화하면 클러스터에 -**파드가 생성되지 않는다.** - -파드 시큐리티 폴리시 API(`policy/v1beta1/podsecuritypolicy`)는 -어드미션 컨트롤러와 독립적으로 활성화되므로 기존 클러스터의 경우 -어드미션 컨트롤러를 활성화하기 전에 정책을 추가하고 권한을 -부여하는 것이 좋다. - -## 정책 승인 - -파드시큐리티폴리시 리소스가 생성되면 아무 것도 수행하지 않는다. 이를 사용하려면 -요청 사용자 또는 대상 파드의 -[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)는 -정책에서 `use` 동사를 허용하여 정책을 사용할 권한이 있어야 한다. - -대부분의 쿠버네티스 파드는 사용자가 직접 만들지 않는다. 대신 일반적으로 -컨트롤러 관리자를 통해 -[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/), -[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는 기타 -템플릿 컨트롤러의 일부로 간접적으로 생성된다. 컨트롤러에 정책에 대한 접근 권한을 부여하면 -해당 컨트롤러에 의해 생성된 *모든* 파드에 대한 접근 권한이 부여되므로 정책을 승인하는 -기본 방법은 파드의 서비스 어카운트에 대한 접근 권한을 -부여하는 것이다([예](#다른-파드를-실행) 참고). - -### RBAC을 통한 방법 - -[RBAC](/docs/reference/access-authn-authz/rbac/)은 표준 쿠버네티스 권한 부여 모드이며, -정책 사용 권한을 부여하는 데 쉽게 사용할 수 있다. - -먼저, `Role` 또는 `ClusterRole`은 원하는 정책을 `use` 하려면 접근 권한을 부여해야 한다. -접근 권한을 부여하는 규칙은 다음과 같다. - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: -rules: -- apiGroups: ['policy'] - resources: ['podsecuritypolicies'] - verbs: ['use'] - resourceNames: - - -``` - -그런 다음 `(Cluster)Role`이 승인된 사용자에게 바인딩된다. - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRoleBinding -metadata: - name: -roleRef: - kind: ClusterRole - name: - apiGroup: rbac.authorization.k8s.io -subjects: -# 네임스페이스의 모든 서비스 어카운트 승인(권장): -- kind: Group - apiGroup: rbac.authorization.k8s.io - name: system:serviceaccounts: -# 특정 서비스 어카운트 승인(권장하지 않음): -- kind: ServiceAccount - name: - namespace: -# 특정 사용자 승인(권장하지 않음): -- kind: User - apiGroup: rbac.authorization.k8s.io - name: -``` - -`RoleBinding`(`ClusterRoleBinding` 아님)을 사용하는 경우, 바인딩과 동일한 네임스페이스에서 -실행되는 파드에 대해서만 사용 권한을 부여한다. 네임스페이스에서 실행되는 모든 파드에 접근 권한을 -부여하기 위해 시스템 그룹과 쌍을 이룰 수 있다. -```yaml -# 네임스페이스의 모든 서비스 어카운트 승인: -- kind: Group - apiGroup: rbac.authorization.k8s.io - name: system:serviceaccounts -# 또는 동일하게, 네임스페이스의 모든 승인된 사용자에게 사용 권한 부여 -- kind: Group - apiGroup: rbac.authorization.k8s.io - name: system:authenticated -``` - -RBAC 바인딩에 대한 자세한 예는, -[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고한다. -파드시큐리티폴리시 인증에 대한 전체 예제는 -[아래](#예제)를 참고한다. - -### 추천 예제 - -파드시큐리티폴리시는 새롭고 간결해진 `PodSecurity` {{< glossary_tooltip -text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되고 있다. -이 변경에 대한 상세사항은 -[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다. -다음 가이드라인을 참조하여 파드시큐리티폴리시를 -새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다. - -1. 파드시큐리티폴리시를 - [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다. - - - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} - - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} - - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} - -1. `system:serviceaccounts:` (여기서 ``는 타겟 네임스페이스) 그룹을 사용하여 - 파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다. - - ```yaml - apiVersion: rbac.authorization.k8s.io/v1 - # 이 클러스터롤바인딩(ClusterRoleBinding)을 통해 "development" 네임스페이스의 모든 파드가 기준 파드시큐리티폴리시(PSP)를 사용할 수 있다. - kind: ClusterRoleBinding - metadata: - name: psp-baseline-namespaces - roleRef: - kind: ClusterRole - name: psp-baseline - apiGroup: rbac.authorization.k8s.io - subjects: - - kind: Group - name: system:serviceaccounts:development - apiGroup: rbac.authorization.k8s.io - - kind: Group - name: system:serviceaccounts:canary - apiGroup: rbac.authorization.k8s.io - ``` - -### 문제 해결 - -- [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는 - 보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다. - API 서버 접근 제어에 대한 자세한 내용은 - [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다. - 컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를 - 통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고, - 모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를 - 만들 수 있는 권한을 부여할 수 있다. - - 컨트롤러 관리자 권한 구성에 대한 자세한 내용은 - [컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고한다. - -## 정책 순서 - -파드 생성 및 업데이트를 제한할 뿐만 아니라 파드 시큐리티 폴리시를 사용하여 -제어하는 많은 필드에 기본값을 제공할 수도 있다. 여러 정책을 -사용할 수 있는 경우 파드 시큐리티 폴리시 컨트롤러는 -다음 기준에 따라 정책을 선택한다. - -1. 기본 설정을 변경하거나 파드를 변경하지 않고 파드를 있는 그대로 허용하는 파드시큐리티폴리시가 - 선호된다. 이러한 비-변이(non-mutating) 파드시큐리티폴리시의 - 순서는 중요하지 않다. -2. 파드를 기본값으로 설정하거나 변경해야 하는 경우, 파드를 허용할 첫 번째 파드시큐리티폴리시 - (이름순)가 선택된다. - -파드시큐리티폴리시에 대해 파드의 유효성이 검증되면, -파드시큐리티폴리시의 이름을 어노테이션 값으로 사용하는 [`kubernetes.io/psp` 어노테이션]이 파드에 추가된다. - {{< note >}} -업데이트 작업 중(파드 스펙에 대한 변경이 허용되지 않는 동안) 비-변이 파드시큐리티폴리시만 -파드의 유효성을 검사하는 데 사용된다. +파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 1.21 버전부터 [사용 중단(deprecated)](/blog/2021/04/08/kubernetes-1-21-release-announcement/#podsecuritypolicy-deprecation)되었으며, +v1.25 버전 때 쿠버네티스에서 제거되었다. +파드시큐리티폴리시를 사용하는 것 대신, 다음 중 하나를 사용하거나 둘 다 사용하여 파드에 유사한 제한을 +적용할 수 있다. + +- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) +- 직접 배포하고 구성할 수 있는 서드파티 어드미션 플러그인 + +마이그레이션에 관한 설명이 필요하다면 [파드시큐리티폴리시(PodSecurityPolicy)에서 빌트인 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp/)을 참고한다. +이 API 제거에 대해 더 많은 정보가 필요하다면, +[파드시큐리티폴리시(PodSecurityPolicy) 사용 중단: 과거, 현재, 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참고한다. + +쿠버네티스 v{{< skew currentVersion >}} 이외의 버전을 실행 중이라면, +해당 쿠버네티스 버전에 대한 문서를 확인한다. {{< /note >}} - -## 예제 - -_이 예에서는 파드시큐리티폴리시 어드미션 컨트롤러가 활성화된 클러스터가 실행 중이고 -클러스터 관리자 권한이 있다고 가정한다._ - -### 설정 - -이 예제와 같이 네임스페이스와 서비스 어카운트를 설정한다. -이 서비스 어카운트를 사용하여 관리자가 아닌 사용자를 조정한다. - -```shell -kubectl create namespace psp-example -kubectl create serviceaccount -n psp-example fake-user -kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user -``` - -어떤 사용자로 활동하고 있는지 명확하게 하고 입력 내용을 저장하려면 2개의 별칭(alias)을 -만든다. - -```shell -alias kubectl-admin='kubectl -n psp-example' -alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example' -``` - -### 정책과 파드 생성 - -이는 특권있는 파드를 만들지 못하게 하는 정책이다. -파드시큐리티폴리시 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. - -{{< codenew file="policy/example-psp.yaml" >}} - -그리고 kubectl로 생성한다. - -```shell -kubectl-admin create -f https://k8s.io/examples/policy/example-psp.yaml -``` - -이제 권한이 없는 사용자로서 간단한 파드를 생성해보자. - -```shell -kubectl-user create -f- <}} -이 방법은 권장하지 않는다! 선호하는 방법은 [다음 절](#다른-파드를-실행)을 -참고하길 바란다. -{{< /note >}} - -```shell -kubectl-admin create role psp:unprivileged \ - --verb=use \ - --resource=podsecuritypolicy \ - --resource-name=example -``` - -``` -role "psp:unprivileged" created -``` - -```shell -kubectl-admin create rolebinding fake-user:psp:unprivileged \ - --role=psp:unprivileged \ - --serviceaccount=psp-example:fake-user -``` - -``` -rolebinding "fake-user:psp:unprivileged" created -``` - -```shell -kubectl-user auth can-i use podsecuritypolicy/example -``` - -``` -yes -``` - -이제 파드 생성을 다시 시도하자. - -```shell -kubectl-user create -f- <}} - -다음은 권한이 없는 사용자로서의 실행을 필요로 하고, 루트로의 에스컬레이션(escalation) 가능성을 차단하고, -여러 보안 메커니즘을 사용을 필요로 하는 제한적 -정책의 예제이다. - -{{< codenew file="policy/restricted-psp.yaml" >}} - -더 많은 예제는 -[파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/#정책-초기화)을 본다. - -## 정책 레퍼런스 - -### 특권을 가진 - -**Privileged** - 파드의 컨테이너가 특권 모드를 사용할 수 있는지 여부를 결정한다. -기본적으로 컨테이너는 호스트의 모든 장치에 접근할 수 없지만 -"특권을 가진" 컨테이너는 호스트의 모든 장치에 접근할 수 있다. 이것은 -컨테이너가 호스트에서 실행되는 프로세스와 거의 동일한 접근을 허용한다. -이것은 네트워크 스택 조작 및 장치 접근과 같은 -리눅스 기능을 사용하려는 컨테이너에 유용하다. - -### 호스트 네임스페이스 - -**HostPID** - 파드 컨테이너가 호스트 프로세스 ID 네임스페이스를 공유할 수 있는지 여부를 -제어한다. ptrace와 함께 사용하면 컨테이너 외부로 권한을 에스컬레이션하는 데 사용할 수 -있다(ptrace는 기본적으로 금지되어 있음). - -**HostIPC** - 파드 컨테이너가 호스트 IPC 네임스페이스를 공유할 수 있는지 여부를 -제어한다. - -**HostNetwork** - 파드가 노드 네트워크 네임스페이스를 사용할 수 있는지 여부를 제어한다. -이렇게 하면 파드에 루프백 장치에 접근 권한을 주고, 서비스는 로컬호스트(localhost)를 리스닝할 수 있으며, -동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데 -사용할 수 있다. - -**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 목록을 -제공한다. `min`과 `max`를 포함하여 `HostPortRange`의 목록으로 정의된다. -기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다. - -### 볼륨 및 파일시스템 - -**Volumes** - 허용되는 볼륨 유형의 목록을 제공한다. 허용 가능한 값은 -볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은 -[볼륨 유형들](/ko/docs/concepts/storage/volumes/#볼륨-유형들)에서 참고한다. -또한 `*`를 사용하여 모든 볼륨 유형을 -허용할 수 있다. - -새 PSP에 허용되는 볼륨의 **최소 권장 셋** 은 다음과 같다. - -- 컨피그맵 -- 다운워드API -- emptyDir -- 퍼시스턴트볼륨클레임 -- 시크릿 -- 프로젝티드(projected) - -{{< warning >}} -파드시큐리티폴리시는 `PersistentVolumeClaim`이 참조할 수 있는 `PersistentVolume` -오브젝트의 유형을 제한하지 않으며 hostPath 유형 -`PersistentVolumes`은 읽기-전용 접근 모드를 지원하지 않는다. 신뢰할 수 있는 사용자만 -`PersistentVolume` 오브젝트를 생성할 수 있는 권한을 부여 받아야 한다. -{{< /warning >}} - -**FSGroup** - 일부 볼륨에 적용되는 보충 그룹(supplemental group)을 제어한다. - -- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을 -기본값으로 사용한다. 모든 범위에 대해 검증한다. -- *MayRunAs* - 하나 이상의 `range`를 지정해야 한다. 기본값을 제공하지 않고 -`FSGroups`을 설정하지 않은 상태로 둘 수 있다. `FSGroups`이 설정된 경우 모든 범위에 대해 -유효성을 검사한다. -- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `fsGroup` ID의 지정도 허용한다. - -**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 목록을 -지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다. -이는 단일 `pathPrefix` 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은 -허용된 접두사로 시작하는 경로를 마운트할 수 있으며 `readOnly` 필드는 -읽기-전용으로 마운트 되어야 함을 나타낸다. -예를 들면 다음과 같습니다. - -```yaml - allowedHostPaths: - # 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만, - # "/fool", "/etc/foo" 등은 허용하지 않는다. - # "/foo/../" 는 절대 유효하지 않다. - - pathPrefix: "/foo" - readOnly: true # 읽기 전용 마운트만 허용 -``` - -{{< warning >}} -호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션 -(다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할 -수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다. - -쓰기 가능한 hostPath 디렉터리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의 -호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다. -쿠버네티스 1.11 이상 버전에서 사용 가능한 `readOnly: true`는 지정된 `pathPrefix`에 대한 -접근을 효과적으로 제한하기 위해 **모든** `allowedHostPaths`에서 사용해야 한다. -{{< /warning >}} - -**ReadOnlyRootFilesystem** - 컨테이너는 읽기-전용 루트 파일시스템(즉, 쓰기 가능한 레이어 없음)으로 -실행해야 한다. - -### FlexVolume 드라이버 - -flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 목록을 지정한다. -빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다. -[`volumes`](#볼륨-및-파일시스템) 필드에 `flexVolume` 볼륨 유형이 포함되어 -있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다. - -예를 들면 다음과 같다. - -```yaml -apiVersion: policy/v1beta1 -kind: PodSecurityPolicy -metadata: - name: allow-flex-volumes -spec: - # ... 다른 스펙 필드 - volumes: - - flexVolume - allowedFlexVolumes: - - driver: example/lvm - - driver: example/cifs -``` - -### 사용자 및 그룹 - -**RunAsUser** - 컨테이너를 실행할 사용자 ID를 제어힌다. - -- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을 -기본값으로 사용한다. 모든 범위에 대해 검증한다. -- *MustRunAsNonRoot* - 파드가 0이 아닌 `runAsUser`로 제출되거나 -이미지에 `USER` 지시문이 정의되어 있어야 한다(숫자 UID 사용). `runAsNonRoot` 또는 -`runAsUser` 설정을 지정하지 않은 파드는 `runAsNonRoot=true`를 설정하도록 -변경되므로 컨테이너에 0이 아닌 숫자가 정의된 `USER` 지시문이 -필요하다. 기본값은 제공되지 않는다. -이 전략에서는 `allowPrivilegeEscalation=false`를 설정하는 것이 좋다. -- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `runAsUser`의 지정도 허용한다. - -**RunAsGroup** - 컨테이너가 실행될 기본 그룹 ID를 제어한다. - -- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을 -기본값으로 사용한다. 모든 범위에 대해 검증한다. -- *MayRunAs* - `RunAsGroup`을 지정할 필요가 없다. 그러나 `RunAsGroup`을 지정하면 -정의된 범위에 속해야 한다. -- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `runAsGroup`의 지정도 허용한다. - - -**SupplementalGroups** - 컨테이너가 추가할 그룹 ID를 제어한다. - -- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을 -기본값으로 사용한다. 모든 범위에 대해 검증한다. -- *MayRunAs* - 하나 이상의 `range`를 지정해야 한다. `supplementalGroups`에 -기본값을 제공하지 않고 설정하지 않은 상태로 둘 수 있다. -`supplementalGroups`가 설정된 경우 모든 범위에 대해 유효성을 검증한다. -- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `supplementalGroups`의 지정도 -허용한다. - -### 권한 에스컬레이션 - -이 옵션은 `allowPrivilegeEscalation` 컨테이너 옵션을 제어한다. 이 bool은 -컨테이너 프로세스에서 -[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) -플래그가 설정되는지 여부를 직접 제어한다. 이 플래그는 `setuid` 바이너리가 -유효 사용자 ID를 변경하지 못하게 하고 파일에 추가 기능을 활성화하지 못하게 -한다(예: `ping` 도구 사용을 못하게 함). `MustRunAsNonRoot`를 효과적으로 -강제하려면 이 동작이 필요하다. - -**AllowPrivilegeEscalation** - 사용자가 컨테이너의 보안 컨텍스트를 -`allowPrivilegeEscalation=true`로 설정할 수 있는지 여부를 게이트한다. -이 기본값은 setuid 바이너리를 중단하지 않도록 허용한다. 이를 `false`로 설정하면 -컨테이너의 하위 프로세스가 상위 프로세스보다 더 많은 권한을 얻을 수 없다. - -**DefaultAllowPrivilegeEscalation** - `allowPrivilegeEscalation` 옵션의 -기본값을 설정한다. 이것이 없는 기본 동작은 setuid 바이너리를 중단하지 않도록 -권한 에스컬레이션을 허용하는 것이다. 해당 동작이 필요하지 않은 경우 이 필드를 사용하여 -기본적으로 허용하지 않도록 설정할 수 있지만 파드는 여전히 `allowPrivilegeEscalation`을 -명시적으로 요청할 수 있다. - -### 기능 - -리눅스 기능은 전통적으로 슈퍼유저와 관련된 권한을 보다 세밀하게 분류한다. -이러한 기능 중 일부는 권한 에스컬레이션 또는 컨테이너 분류에 사용될 수 있으며 -파드시큐리티폴리시에 의해 제한될 수 있다. 리눅스 기능에 대한 자세한 내용은 -[기능(7)](https://man7.org/linux/man-pages/man7/capabilities.7.html)을 -참고하길 바란다. - -다음 필드는 대문자로 표기된 기능 이름 목록을 -`CAP_` 접두사 없이 가져온다. - -**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 목록을 -제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은 -기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을 -의미한다. `*`는 모든 기능을 허용하는 데 사용할 수 있다. - -**RequiredDropCapabilities** - 컨테이너에서 삭제해야 하는 기능이다. -이러한 기능은 기본 셋에서 제거되며 추가해서는 안된다. -`RequiredDropCapabilities`에 나열된 기능은 `AllowedCapabilities` 또는 -`DefaultAddCapabilities`에 포함되지 않아야 한다. - -**DefaultAddCapabilities** - 런타임 기본값 외에 기본적으로 컨테이너에 추가되는 기능이다. -도커 런타임을 사용할 때 기본 기능 목록은 -[도커 문서](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)를 참고한다. - -### SELinux - -- *MustRunAs* - `seLinuxOptions`을 구성해야 한다. -`seLinuxOptions`을 기본값으로 사용한다. `seLinuxOptions`에 대해 유효성을 검사한다. -- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `seLinuxOptions`의 지정도 -허용한다. - -### AllowedProcMountTypes - -`allowedProcMountTypes`는 허용된 ProcMountTypes의 목록이다. -비어 있거나 nil은 `DefaultProcMountType`만 사용할 수 있음을 나타낸다. - -`DefaultProcMount`는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임 -기본값을 사용한다. 대부분의 컨테이너 런타임은 특수 장치나 정보가 실수로 보안에 -노출되지 않도록 /proc의 특정 경로를 마스킹한다. 이것은 문자열 -`Default`로 표시된다. - -유일하게 다른 ProcMountType은 `UnmaskedProcMount`로, 컨테이너 런타임의 -기본 마스킹 동작을 무시하고 새로 작성된 /proc 컨테이너가 수정없이 -그대로 유지되도록 한다. 이 문자열은 -`Unmasked`로 표시된다. - -### AppArmor - -파드시큐리티폴리시의 어노테이션을 통해 제어된다. [AppArmor -문서](/ko/docs/tutorials/security/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다. - -### Seccomp - -쿠버네티스 v1.19부터 파드나 컨테이너의 `securityContext` 에서 -`seccompProfile` 필드를 사용하여 [seccomp 프로파일 사용을 -제어](/docs/tutorials/security/seccomp/)할 수 있다. -이전 버전에서는, 파드에 어노테이션을 추가하여 seccomp를 제어했다. -두 버전에서 동일한 파드시큐리티폴리시를 사용하여 -이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다. - -**seccomp.security.alpha.kubernetes.io/defaultProfileName** - 컨테이너에 -적용할 기본 seccomp 프로파일을 지정하는 어노테이션이다. 가능한 값은 -다음과 같다. - -- `unconfined` - 대안이 제공되지 않으면 Seccomp가 컨테이너 프로세스에 적용되지 - 않는다(쿠버네티스의 기본값임). -- `runtime/default` - 기본 컨테이너 런타임 프로파일이 사용된다. -- `docker/default` - 도커 기본 seccomp 프로파일이 사용된다. 쿠버네티스 1.11 부터 사용 중단(deprecated) - 되었다. 대신 `runtime/default` 사용을 권장한다. -- `localhost/` - `/`에 있는 노드에서 파일을 프로파일로 - 지정한다. 여기서 ``는 Kubelet의 `--seccomp-profile-root` 플래그를 - 통해 정의된다. `--seccomp-profile-root` 플래그가 - 정의되어 있지 않으면, `` 이 `--root-dir` 플래그로 - 지정된 `/seccomp` 기본 경로가 사용된다. - -{{< note >}} - `--seccomp-profile-root` 플래그는 쿠버네티스 v1.19부터 더 이상 사용되지 - 않는다. 사용자는 기본 경로를 사용하는 것이 좋다. -{{< /note >}} - -**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 파드 seccomp -어노테이션에 허용되는 값을 지정하는 어노테이션. 쉼표로 구분된 -허용된 값의 목록으로 지정된다. 가능한 값은 위에 나열된 값과 -모든 프로파일을 허용하는 `*` 이다. -이 주석이 없으면 기본값을 변경할 수 없다. - -### Sysctl - -기본적으로 모든 안전한 sysctls가 허용된다. - -- `forbiddenSysctls` - 특정 sysctls를 제외한다. - 목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다. - 모든 sysctls 설정을 금지하려면 자체적으로 `*`를 사용한다. -- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 - 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다. - -[Sysctl 문서](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다. - -## {{% heading "whatsnext" %}} - -- [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 -미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)에서 -파드시큐리티폴리시의 미래에 대해 알아본다. - -- 폴리시 권장 사항에 대해서는 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)을 참조한다. - -- API 세부 정보는 - [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. - diff --git a/content/ko/docs/concepts/security/pod-security-standards.md b/content/ko/docs/concepts/security/pod-security-standards.md index 8100e5a1d51..13847be2f63 100644 --- a/content/ko/docs/concepts/security/pod-security-standards.md +++ b/content/ko/docs/concepts/security/pod-security-standards.md @@ -407,7 +407,7 @@ weight: 10

컨테이너는 ALL 능력을 내려놓아야 하며, - NET_BIND_SERVICE 능력을 다시 추가하기 위한 목적일 때만 허용되어야 한다. v1.25+에서는 리눅스 전용 정책이다.(spec.os.name != windows)

+ NET_BIND_SERVICE 능력을 다시 추가하기 위한 목적일 때만 허용되어야 한다. v1.25+에서는 리눅스 전용 정책이다.(spec.os.name != windows)

제한된 필드

    @@ -521,3 +521,4 @@ v1.24 이전 Kubelet은 파드 OS 필드를 필수로 요구하지 않으며, 추가적으로, 샌드박스 방식에 따라 샌드박스 워크로드에 대한 보호가 달라진다. 이와 같은 경우에는, 하나의 프로필만을 모든 샌드박스 워크로드에 대해 권장할 수 없다. + diff --git a/content/ko/docs/concepts/security/rbac-good-practices.md b/content/ko/docs/concepts/security/rbac-good-practices.md index 8a3da4033d6..024c898f44b 100644 --- a/content/ko/docs/concepts/security/rbac-good-practices.md +++ b/content/ko/docs/concepts/security/rbac-good-practices.md @@ -12,7 +12,7 @@ weight: 60 쿠버네티스 {{< glossary_tooltip text="RBAC" term_id="rbac" >}}는 클러스터 사용자 및 워크로드가 자신의 역할을 수행하기 위해 필요한 자원에 대해서만 접근 권한을 가지도록 보장하는 핵심 보안 제어 방식이다. 클러스터 관리자가 클러스터 사용자 권한을 설정할 시에는, -보안 사고로 이어지는 과도한 접근 권한 부여의 위험을 줄이기 위해 +보안 사고로 이어지는 과도한 접근 권한 부여의 위험을 줄이기 위해 권한 에스컬레이션 발생 가능성에 대해 이해하는 것이 중요하다. 여기서 제공하는 모범 사례는 [RBAC 문서](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update) @@ -33,7 +33,7 @@ weight: 60 - 와일드카드(wildcard)를 사용한 권한 지정을 할 시에는, 특히 모든 리소스에 대해서는 가능하면 지양한다. 쿠버네티스는 확장성을 지니는 시스템이기 때문에, 와일드카드를 이용한 권한 지정은 현재 클러스터에 있는 모든 오브젝트 타입뿐만 아니라 - 추후에 생성될 오브젝트 타입에 대해서도 권한을 부여하게 된다. + 모든 오브젝트 타입에 대해서도 권한을 부여하게 된다. - 운영자는 `cluster-admin` 계정이 필수로 요구되지 않을시에는 사용을 지양한다. 적은 권한을 가진 계정과 [가장 (impersonation) 권한](/docs/reference/access-authn-authz/authentication/#user-impersonation)을 @@ -99,10 +99,13 @@ weight: 60 ### 워크로드 생성 -워크로드(파드 혹은 파드를 관리하는 -[워크로드 리소스](/ko/docs/concepts/workloads/controllers/))를 생성할 수 있는 사용자는 -[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)에 -기반한 제한 사항이 없을 시에는 해당 노드에 대한 접근 권한을 부여받을 수 있다. +네임스페이스에 워크로드(파드 혹은 파드를 관리하는 +[워크로드 리소스](/ko/docs/concepts/workloads/controllers/))를 생성할 수 있는 권한은 +파드에 마운트할 수 있는 시크릿, 컨피그맵 그리고 퍼시스턴트볼륨(PersistentVolume)과 같은 해당 네임스페이스의 다른 많은 리소스에 대한 +액세스 권한을 암묵적으로 부여한다. 또한 파드는 모든 [서비스어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)로 +실행할 수 있기 때문에, 워크로드 생성 권한을 부여하면 +해당 네임스페이스에 있는 모든 서비스어카운트의 API 액세스 수준도 암묵적으로 +부여된다. 특권 파드 실행 권한을 가지는 사용자는 해당 노드에 대한 권한을 부여받을 수 있으며, 더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다. @@ -111,13 +114,10 @@ weight: 60 이는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다. -사용자의 특권을 가진 파드 생성 자격을 제한하기 위해, -현재는 사용이 중지 된 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/) -매커니즘도 사용할 수 있다. (주의 - 파드시큐리티폴리시는 1.25 버전 이후로 중지될 예정이다.) - -사용자가 네임스페이스 내에서 워크로드를 생성하면, 해당 네임스페이스에 위치한 시크릿에 대한 간접적 접근 권한을 부여 받게 된다. -사용자가 kube-system 또는 유사한 특권을 가진 네임스페이스에서 파드를 생성하게 되면, -RBAC를 통해 직접적으로는 접근 권한을 가지지 못할 시크릿에 대한 권한도 부여받게 된다. +이러한 이유로, 네임스페이스는 서로 다른 수준의 보안 또는 테넌시가 필요한 리소스들을 분리하는 데 사용해야 +한다. [최소 권한](#least-privilege) 원칙을 따르고 권한을 가장 적게 할당하는 것이 +바람직하지만, 네임스페이스 내의 경계는 약한 것으로 간주되어야 +한다. ### 퍼시스턴트 볼륨 생성 @@ -186,4 +186,3 @@ CSR API를 통해 CSR에 대한 `create` 권한 및 `certificatesigningrequests/ ## {{% heading "whatsnext" %}} * RBAC에 대한 추가적인 정보를 얻기 위해서는 [RBAC 문서](/docs/reference/access-authn-authz/rbac/)를 참고한다. - 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 7bbdceff241..b0afada7b76 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -45,9 +45,10 @@ my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 파드의 IP를 확인한다. ```shell -kubectl get pods -l run=my-nginx -o yaml | grep podIP - podIP: 10.244.3.4 - podIP: 10.244.2.5 +kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs + POD_IP + [map[ip:10.244.3.4]] + [map[ip:10.244.2.5]] ``` 이제 클러스터의 모든 노드로 ssh 접속하거나 `curl`과 같은 도구를 사용하여 두 IP 주소에 질의를 전송할 수 있을 것이다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 `containerPort`를 사용하여 동일한 노드에서 여러 nginx 파드를 실행하는 것이 가능하고, 또한 서비스에 할당된 IP 주소를 사용하여 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 호스트 노드의 특정 포트를 배후(backing) 파드로 포워드하고 싶다면, 가능은 하지만 네트워킹 모델을 사용하면 그렇게 할 필요가 없어야 한다. @@ -243,7 +244,6 @@ kubectl get secrets ``` ``` NAME TYPE DATA AGE -default-token-il9rc kubernetes.io/service-account-token 1 1d nginxsecret kubernetes.io/tls 2 1m ``` 그리고 또한 컨피그맵: @@ -290,7 +290,6 @@ kubectl get secrets ``` ``` NAME TYPE DATA AGE -default-token-il9rc kubernetes.io/service-account-token 1 1d nginxsecret kubernetes.io/tls 2 1m ``` @@ -314,8 +313,12 @@ kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.ya 이 시점에서 모든 노드에서 nginx 서버에 연결할 수 있다. ```shell -kubectl get pods -o yaml | grep -i podip - podIP: 10.244.3.5 +kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs + POD_IP + [map[ip:10.244.3.5]] +``` + +```shell node $ curl -k https://10.244.3.5 ...

    Welcome to nginx!

    @@ -424,3 +427,5 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el * [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다. * [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/ko/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다. * [외부 로드 밸런서를 생성하기](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다. + + 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 59ed5efc577..760505b3c6b 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -308,7 +308,7 @@ kubectl exec -it dns-example -- cat /etc/resolv.conf ``` 출력은 다음과 같은 형식일 것이다. ``` -nameserver fd00:79:30::a +nameserver 2001:db8:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example options ndots:5 ``` @@ -344,6 +344,5 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화 ## {{% heading "whatsnext" %}} - DNS 구성 관리에 대한 지침은 [DNS 서비스 구성](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 9d3db08643d..0b2e98138ec 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -108,7 +108,7 @@ endpoints: #### 제공(Serving) -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} `serving`은 종료 상태를 고려하지 않는다는 점을 제외하면 `ready` 조건과 동일하다. 엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면 @@ -127,7 +127,7 @@ endpoints: #### 종료(Terminating) -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} `종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다. 파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다. diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 94db199ed34..4b550a04ffa 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -70,7 +70,7 @@ __egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙 따라서 예시의 네트워크폴리시는 다음과 같이 동작한다. 1. 인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우). -2. (인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다. +2. (인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6379로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다. * "role=frontend" 레이블이 있는 "default" 네임스페이스의 모든 파드 * 네임스페이스와 "project=myproject" 를 레이블로 가지는 모든 파드 @@ -195,7 +195,7 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex ## 포트 범위 지정 -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} 네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다. @@ -228,10 +228,6 @@ spec: TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다. 이 필드를 사용할 때 다음의 제한 사항이 적용된다. -* 베타 기능으로, 기본적으로 활성화되어 있다. -클러스터 수준에서 `endPort` 필드를 비활성화하려면, 사용자(또는 클러스터 관리자)가 -API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 이용하여 -`NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다. * `endPort` 필드는 `port` 필드보다 크거나 같아야 한다. * `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다. * 두 포트 모두 숫자여야 한다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index f87dcc42491..21bb82f9194 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -287,7 +287,7 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 낮거나 0이면 DNS에 부하가 높아 관리하기가 어려워 질 수 있다. -본 페이지의 뒷 부분에서 다양한 kube-proxy 구현의 동작에 대해 읽을 수 있다. +본 페이지의 뒷 부분에서 다양한 kube-proxy 구현이 동작하는 방식에 대해 읽을 수 있다. 우선 알아두어야 할 것은, `kube-proxy`를 구동할 때, 커널 수준의 규칙이 수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고, 이는 때로는 리부트 전까지 정리되지 않을 수도 있다. @@ -504,17 +504,17 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는 지원한다. 예를 들어, TCP 포트 6379를 개방하고 -클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-master`는, +클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-primary`는, 다음 환경 변수를 생성한다. ```shell -REDIS_MASTER_SERVICE_HOST=10.0.0.11 -REDIS_MASTER_SERVICE_PORT=6379 -REDIS_MASTER_PORT=tcp://10.0.0.11:6379 -REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379 -REDIS_MASTER_PORT_6379_TCP_PROTO=tcp -REDIS_MASTER_PORT_6379_TCP_PORT=6379 -REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11 +REDIS_PRIMARY_SERVICE_HOST=10.0.0.11 +REDIS_PRIMARY_SERVICE_PORT=6379 +REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379 +REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379 +REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp +REDIS_PRIMARY_PORT_6379_TCP_PORT=6379 +REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11 ``` {{< note >}} @@ -1325,15 +1325,15 @@ IP 주소를 정리한다. #### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range} -{{< feature-state for_k8s_version="v1.24" state="alpha" >}} +{{< feature-state for_k8s_version="v1.25" state="beta" >}} 그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데, 그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address). 이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면 충돌이 발생할 수 있다. `ServiceIPStaticSubrange` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면, -할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 v1.25 이상에서 기본적으로 활성화되며, +이 때 사용하는 할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진 `service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며, 여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다. 동적 IP 할당은 상위 대역에서 우선적으로 선택하며, diff --git a/content/ko/docs/concepts/services-networking/topology-aware-hints.md b/content/ko/docs/concepts/services-networking/topology-aware-hints.md index d596aaf69cc..4f11ff8dd32 100644 --- a/content/ko/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ko/docs/concepts/services-networking/topology-aware-hints.md @@ -147,7 +147,7 @@ kube-proxy 구성요소는 엔드포인트슬라이스 컨트롤러가 설정한 준비되지 않은(unready) 노드는 무시한다. 이 때문에 많은 노드가 준비되지 않은 상태에서는 의도하지 않은 결과가 나타날 수도 있다. -* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때 +* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 배포하거나 계산할 때 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}은 고려하지 않는다. 서비스를 구성하는 파드가 클러스터의 일부 노드에만 배치되어 있는 경우, 이러한 상황은 고려되지 않을 것이다. diff --git a/content/ko/docs/concepts/storage/ephemeral-volumes.md b/content/ko/docs/concepts/storage/ephemeral-volumes.md index ba7a14f1c91..5f5bf13fb4e 100644 --- a/content/ko/docs/concepts/storage/ephemeral-volumes.md +++ b/content/ko/docs/concepts/storage/ephemeral-volumes.md @@ -74,10 +74,7 @@ kubelet에서 관리하는 디스크와 성능 특성이 다른 스토리지, ### CSI 임시 볼륨 {#csi-ephemeral-volumes} -{{< feature-state for_k8s_version="v1.16" state="beta" >}} - -이 기능을 사용하려면 `CSIInlineVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. -쿠버네티스 1.16부터는 기본적으로 활성화되어 있다. +{{< feature-state for_k8s_version="v1.25" state="stable" >}} {{< note >}} CSI 드라이버 중 일부만 CSI 임시 볼륨을 지원한다. diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 8bc33b00af6..e66e4fe6175 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -9,7 +9,7 @@ title: 퍼시스턴트 볼륨 feature: title: 스토리지 오케스트레이션 description: > - 로컬 스토리지, GCP나 AWS와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다. + 로컬 스토리지, AWS나 GCP와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Ceph, Cinder와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다. content_type: concept weight: 20 --- @@ -166,7 +166,7 @@ spec: path: /any/path/it/will/be/replaced containers: - name: pv-recycler - image: "k8s.gcr.io/busybox" + image: "registry.k8s.io/busybox" command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] volumeMounts: - name: vol @@ -238,10 +238,9 @@ Source: Events: ``` -특정 인-트리 볼륨 플러그인에 대해 `CSIMigration` 기능을 활성화하면 `kubernetes.io/pv-controller` 파이널라이저는 제거되고, -`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저가 추가된다. -이와 비슷하게, `CSIMigration` 기능을 비활성화하면 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 제거되고, -`kubernetes.io/pv-controller` 파이널라이저가 추가된다. +특정 인-트리 볼륨 플러그인에 대해 `CSIMigration{provider}` 기능 플래그가 활성화되어 있을 때, +`kubernetes.io/pv-controller` 파이널라이저는 +`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저로 대체된다. ### 퍼시스턴트볼륨 예약 @@ -286,7 +285,7 @@ spec: ### 퍼시스턴트 볼륨 클레임 확장 -{{< feature-state for_k8s_version="v1.11" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} 퍼시스턴트볼륨클레임(PVC) 확장 지원은 기본적으로 활성화되어 있다. 다음 유형의 볼륨을 확장할 수 있다. @@ -413,14 +412,9 @@ PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 퍼시스턴트볼륨 유형은 플러그인으로 구현된다. 쿠버네티스는 현재 다음의 플러그인을 지원한다. -* [`awsElasticBlockStore`](/ko/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) -* [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk) - Azure Disk -* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File * [`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) 스토리지 -* [`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 볼륨 (단일 노드 테스트 전용. 다중-노드 클러스터에서 작동하지 않음. 대신 `로컬` 볼륨 사용 고려) @@ -428,29 +422,41 @@ PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 * [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된 로컬 스토리지 디바이스 * [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - 네트워크 파일 시스템 (NFS) 스토리지 -* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨 * [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) 볼륨 -* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨 아래의 PersistentVolume 타입은 사용 중단되었다. 이 말인 즉슨, 지원은 여전히 제공되지만 추후 쿠버네티스 릴리스에서는 삭제될 예정이라는 것이다. +* [`awsElasticBlockStore`](/ko/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) + (v1.17에서 **사용 중단**) +* [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk) - Azure Disk + (v1.19에서 **사용 중단**) +* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File + (v1.21에서 **사용 중단**) * [`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 볼륨 - (v1.22에서 **사용 중단**) -* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨 - (v1.22에서 **사용 중단**) +* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk + (v1.17에서 **사용 중단**) +* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨 + (v1.25에서 **사용 중단**) +* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨 + (v1.25에서 **사용 중단**) +* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨 + (v1.19에서 **사용 중단**) 이전 쿠버네티스 버전은 아래의 인-트리 PersistentVolume 타입도 지원했었다. * `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크. - (v1.15 이후 **사용 불가**) + (v1.15부터 **사용 불가**) * [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨 - (v1.21 이후 **사용 불가**) + (v1.21부터 **사용 불가**) +* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지 + (v1.25부터 **사용 불가**) +* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨 + (v1.25부터 **사용 불가**) +* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨 + (v1.25부터 **사용 불가**) ## 퍼시스턴트 볼륨 @@ -562,17 +568,14 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다. | CSI | 드라이버에 의존 | 드라이버에 의존 | 드라이버에 의존 | 드라이버에 의존 | | FC | ✓ | ✓ | - | - | | FlexVolume | ✓ | ✓ | 드라이버에 의존 | - | -| Flocker | ✓ | - | - | - | | GCEPersistentDisk | ✓ | ✓ | - | - | | Glusterfs | ✓ | ✓ | ✓ | - | | HostPath | ✓ | - | - | - | | iSCSI | ✓ | ✓ | - | - | -| Quobyte | ✓ | ✓ | ✓ | - | | NFS | ✓ | ✓ | ✓ | - | | RBD | ✓ | ✓ | - | - | | VsphereVolume | ✓ | - | - (파드를 배치할(collocated) 때 동작한다) | - | | PortworxVolume | ✓ | - | ✓ | - | - | -| StorageOS | ✓ | - | - | - | ### 클래스 @@ -616,9 +619,7 @@ PV는 `storageClassName` 속성을 * `glusterfs` * `iscsi` * `nfs` -* `quobyte` (v1.22에서 **사용 중단됨**) * `rbd` -* `storageos` (v1.22에서 **사용 중단됨**) * `vsphereVolume` 마운트 옵션의 유효성이 검사되지 않는다. 마운트 옵션이 유효하지 않으면, 마운트가 실패한다. @@ -718,9 +719,13 @@ PVC는 항상 클래스가 없는 PV를 요청하는 것으로 해석되므로 플러그인은 모든 PVC 생성을 금지한다. * 어드미션 플러그인이 꺼져 있으면 기본 스토리지클래스에 대한 기본값 자체가 없다. - `storageClassName`이 없는 모든 PVC는 클래스가 없는 PV에만 바인딩할 수 있다. 이 경우 - `storageClassName`이 없는 PVC는 `storageClassName`이 `""`로 설정된 PVC와 - 같은 방식으로 처리된다. + `storageClassName`이 `""`으로 설정된 모든 PVC는 + `storageClassName`이 마찬가지로 `""`로 설정된 PV에만 바인딩할 수 있다. + 하지만, `storageClassName`이 없는 PVC는 + 기본 스토리지클래스가 사용 가능해지면 갱신될 수 있다. PVC가 갱신되면 + 해당 PVC는 더 이상 `storageClassName`이 `""`로 설정된 PV와 바인딩되어있지 않게 된다. + +더 자세한 정보는 [retroactive default StorageClass assignment](#retroactive-default-storageclass-assignment)를 참조한다. 설치 방법에 따라 설치 중에 애드온 관리자가 기본 스토리지클래스를 쿠버네티스 클러스터에 배포할 수 있다. @@ -737,6 +742,20 @@ AND 조건으로 동작한다. 요청된 클래스와 요청된 레이블이 있 속성 대신 사용되었다. 이 어노테이션은 아직까지는 사용할 수 있지만, 향후 쿠버네티스 릴리스에서는 지원되지 않는다. + +#### 기본 스토리지클래스 할당 소급 적용하기 {#retroactive-default-storageclass-assignment} + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +새로운 PVC를 위한 `storageClassName`을 설정하지 않고 퍼시스턴트볼륨클레임을 생성할 수 있으며, 이는 클러스터에 기본 스토리지클래스가 존재하지 않을 때에도 가능하다. 이 경우, 새로운 PVC는 정의된 대로 생성되며, 해당 PVC의 `storageClassName`은 기본값이 사용 가능해질 때까지 미설정 상태로 남는다. +하지만, [`RetroactiveDefaultStorageClass` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면 쿠버네티스는 다르게 동작하여, 기존에 존재하는 PVC 중 `storageClassName`가 설정되지 않은 PVC는 새로운 기본 스토리지클래스를 사용하도록 갱신된다. + +기본 스토리지클래스가 사용 가능해지면, 컨트롤플레인은 `storageClassName`가 없는 PVC를 찾는다. `storageClassName`의 값이 비어있거나 해당 키 자체가 없는 PVC라면, 컨트롤플레인은 해당 PVC의 `storageClassName`가 새로운 기본 스토리지클래스와 일치하도록 설정하여 갱신한다. `storageClassName`가 `""`인 PVC가 있고, 기본 스토리지클래스를 설정한다면, 해당 PVC는 갱신되지 않는다. + +기본 스토리지클래스가 존재할 때 `storageClassName`가 `""`로 설정된 PV와의 바인딩을 유지하고싶다면, 연결된 PVC의 `storageClassName`를 `""`로 설정해야 한다. + +이 행동은 관리자가 오래된 기본 스토리지클래스를 삭제하고 새로운 기본 스토리지클래스를 생성하거나 설정하여 기본 스토리지클래스를 변경하는 데 도움이 된다. 기본값이 설정되어있지 않을 때의 이 작은 틈새로 인해 이 때 생성된 `storageClassName`가 없는 PVC는 아무런 기본값도 없이 생성될 수 있지만, 기본 스토리지클래스 할당 소급 적용에 의해 이러한 방식으로 기본값을 변경하는 것은 안전하다. + ## 볼륨으로 클레임하기 클레임을 볼륨으로 사용해서 파드가 스토리지에 접근한다. 클레임은 클레임을 사용하는 파드와 동일한 네임스페이스에 있어야 한다. 클러스터는 파드의 네임스페이스에서 클레임을 찾고 이를 사용하여 클레임과 관련된 퍼시스턴트볼륨을 얻는다. 그런 다음 볼륨이 호스트와 파드에 마운트된다. diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md index 1dc395e6f87..ee0460c1294 100644 --- a/content/ko/docs/concepts/storage/storage-capacity.md +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -70,7 +70,7 @@ weight: 70 볼륨을 생성한 후에, 스케줄러는 볼륨을 사용할 수 있는 노드에 파드를 스케줄링한다. -[CSI 임시 볼륨](/ko/docs/concepts/storage/volumes/#csi)의 경우에는 +[CSI 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)의 경우에는 볼륨 유형이 로컬 볼륨이고 큰 자원이 필요하지 않은 특정 CSI 드라이버에서만 사용된다는 가정하에, 항상 스토리지 용량을 고려하지 않고 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index a34b01d813f..e7190fd7d0e 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -71,17 +71,13 @@ volumeBindingMode: Immediate | Cinder | ✓ | [OpenStack Cinder](#openstack-cinder)| | FC | - | - | | FlexVolume | - | - | -| Flocker | ✓ | - | | GCEPersistentDisk | ✓ | [GCE PD](#gce-pd) | | Glusterfs | ✓ | [Glusterfs](#glusterfs) | | iSCSI | - | - | -| Quobyte | ✓ | [Quobyte](#quobyte) | | NFS | - | [NFS](#nfs) | | RBD | ✓ | [Ceph RBD](#ceph-rbd) | | VsphereVolume | ✓ | [vSphere](#vsphere) | | PortworxVolume | ✓ | [Portworx 볼륨](#portworx-볼륨) | -| ScaleIO | ✓ | [ScaleIO](#scaleio) | -| StorageOS | ✓ | [StorageOS](#storageos) | | Local | - | [Local](#local) | 여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이 @@ -413,7 +409,7 @@ parameters: * Distribute 볼륨: `volumetype: none` 사용 가능한 볼륨 유형과 관리 옵션에 대해서는 - [관리 가이드](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)를 참조한다. + [관리 가이드](https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/)를 참조한다. 자세한 정보는 [Heketi 구성 방법](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)을 참조한다. @@ -473,7 +469,7 @@ vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구 - [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-마이그레이션)을 참고한다. +인-트리 프로비저닝 도구는 [사용 중단](/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/#vsphere-csi-migration)을 참고한다. #### CSI 프로비저닝 도구 {#vsphere-provisioner-csi} @@ -544,7 +540,7 @@ vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티 스토어에 분산되어 요구 사항을 충족시키게 된다. 퍼시스턴트 볼륨 관리에 스토리지 정책을 사용하는 방법에 대한 자세한 내용은 - [볼륨의 동적 프로비저닝을 위한 스토리지 정책 기반 관리(SPBM)](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)를 + [볼륨의 동적 프로비저닝을 위한 스토리지 정책 기반 관리(SPBM)](https://github.com/vmware-archive/vsphere-storage-for-kubernetes/blob/fa4c8b8ad46a85b6555d715dd9d27ff69839df53/documentation/policy-based-mgmt.md)를 참조한다. vSphere용 쿠버네티스 내에서 퍼시스턴트 볼륨 관리를 시도하는 @@ -599,61 +595,6 @@ parameters: 경우에만 사용해야 한다. 현재 `layering` 에서만 기능이 지원된다. 기본값은 ""이며, 기능이 설정되어 있지 않다. -### Quobyte - -{{< feature-state for_k8s_version="v1.22" state="deprecated" >}} - -Quobyte 인-트리 스토리지 플러그인은 사용 중단되었으며, -아웃-오브-트리 Quobyte 플러그인에 대한 [예제](https://github.com/quobyte/quobyte-csi/blob/master/example/StorageClass.yaml) -`StorageClass`는 Quobyte CSI 저장소에서 찾을 수 있다. - -```yaml -apiVersion: storage.k8s.io/v1 -kind: StorageClass -metadata: - name: slow -provisioner: kubernetes.io/quobyte -parameters: - quobyteAPIServer: "http://138.68.74.142:7860" - registry: "138.68.74.142:7861" - adminSecretName: "quobyte-admin-secret" - adminSecretNamespace: "kube-system" - user: "root" - group: "root" - quobyteConfig: "BASE" - quobyteTenant: "DEFAULT" -``` - -* `quobyteAPIServer`: `"http(s)://api-server:7860"` 형식의 - Quobyte의 API 서버이다. -* `registry`: 볼륨을 마운트하는 데 사용할 Quobyte 레지스트리이다. 레지스트리를 - ``:`` 의 쌍으로 지정하거나 여러 레지스트리를 - 지정하려면 쉼표만 있으면 된다. - 예: ``:,:,:`` - 호스트는 IP 주소이거나 DNS가 작동 중인 경우 - DNS 이름을 제공할 수도 있다. -* `adminSecretNamespace`: `adminSecretName` 의 네임스페이스. - 기본값은 "default". -* `adminSecretName`: 시크릿은 API 서버에 대해 인증하기 위한 Quobyte 사용자와 암호에 - 대한 정보를 담고 있다. 제공된 시크릿은 "kubernetes.io/quobyte" - 유형과 `user` 및 `password` 키를 가져야 하며, 예를 들면 - 다음과 같다. - - ```shell - kubectl create secret generic quobyte-admin-secret \ - --type="kubernetes.io/quobyte" --from-literal=user='admin' --from-literal=password='opensesame' \ - --namespace=kube-system - ``` - -* `user`: 이 사용자에 대한 모든 접근을 매핑한다. 기본값은 "root". -* `group`: 이 그룹에 대한 모든 접근을 매핑한다. 기본값은 "nfsnobody". -* `quobyteConfig`: 지정된 구성을 사용해서 볼륨을 생성한다. 웹 콘솔 - 또는 quobyte CLI를 사용해서 새 구성을 작성하거나 기존 구성을 - 수정할 수 있다. 기본값은 "BASE". -* `quobyteTenant`: 지정된 테넌트 ID를 사용해서 볼륨을 생성/삭제한다. - 이 Quobyte 테넌트는 이미 Quobyte에 있어야 한다. - 기본값은 "DEFAULT". - ### Azure 디스크 #### Azure 비관리 디스크 스토리지 클래스 {#azure-unmanaged-disk-storage-class} @@ -782,96 +723,6 @@ parameters: 카산드라와 같은 데이터베이스는 false로 설정해야 한다. `true/false` (기본값 `false`) 여기에는 문자열, 즉 `true` 가 아닌, `"true"` 가 필요하다. -### ScaleIO - -```yaml -apiVersion: storage.k8s.io/v1 -kind: StorageClass -metadata: - name: slow -provisioner: kubernetes.io/scaleio -parameters: - gateway: https://192.168.99.200:443/api - system: scaleio - protectionDomain: pd0 - storagePool: sp1 - storageMode: ThinProvisioned - secretRef: sio-secret - readOnly: "false" - fsType: xfs -``` - -* `provisioner`: 속성이 `kubernetes.io/scaleio` 로 설정되어 있다. -* `gateway`: ScaleIO API 게이트웨이 주소(필수) -* `system`: ScaleIO 시스템의 이름(필수) -* `protectionDomain`: ScaleIO 보호 도메인의 이름(필수) -* `storagePool`: 볼륨 스토리지 풀의 이름(필수) -* `storageMode`: 스토리지 프로비전 모드: `ThinProvisioned` (기본값) 또는 - `ThickProvisioned` -* `secretRef`: 구성된 시크릿 오브젝트에 대한 참조(필수) -* `readOnly`: 마운트된 볼륨에 대한 접근 모드의 지정(기본값: false) -* `fsType`: 볼륨에 사용할 파일 시스템 유형(기본값: ext4) - -ScaleIO 쿠버네티스 볼륨 플러그인에는 구성된 시크릿 오브젝트가 필요하다. -시크릿은 다음 명령에 표시된 것처럼 `kubernetes.io/scaleio` 유형으로 -작성해야 하며, PVC와 동일한 네임스페이스 -값을 사용해야 한다. - -```shell -kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \ ---from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \ ---namespace=default -``` - -### StorageOS - -```yaml -apiVersion: storage.k8s.io/v1 -kind: StorageClass -metadata: - name: fast -provisioner: kubernetes.io/storageos -parameters: - pool: default - description: Kubernetes volume - fsType: ext4 - adminSecretNamespace: default - adminSecretName: storageos-secret -``` - -* `pool`: 볼륨을 프로비전할 StorageOS 분산 용량 - 풀의 이름. 지정되지 않은 경우 일반적으로 존재하는 `default` 풀을 사용한다. -* `description`: 동적으로 생성된 볼륨에 할당할 설명. - 모든 볼륨 설명은 스토리지 클래스에 대해 동일하지만, 서로 다른 - 유스케이스에 대한 설명을 허용하기 위해 다른 스토리지 클래스를 사용할 수 있다. - 기본값은 `Kubernetes volume`. -* `fsType`: 요청할 기본 파일 시스템 유형. StorageOS 내의 사용자 - 정의 규칙이 이 값을 무시할 수 있다. 기본 값은 `ext4`. -* `adminSecretNamespace`: API 구성 시크릿이 있는 네임스페이스. - adminSecretName 이 설정된 경우 필수이다. -* `adminSecretName`: StorageOS API 자격증명을 얻는 데 사용할 시크릿의 이름. - 지정하지 않으면 기본값이 시도된다. - -StorageOS 쿠버네티스 볼륨 플러그인은 시크릿 오브젝트를 사용해서 StorageOS API에 -접근하기 위한 엔드포인트와 자격증명을 지정할 수 있다. 이것은 기본값이 -변경된 경우에만 필요하다. -시크릿은 다음의 명령과 같이 `kubernetes.io/storageos` 유형으로 -만들어야 한다. - -```shell -kubectl create secret generic storageos-secret \ ---type="kubernetes.io/storageos" \ ---from-literal=apiAddress=tcp://localhost:5705 \ ---from-literal=apiUsername=storageos \ ---from-literal=apiPassword=storageos \ ---namespace=default -``` - -동적으로 프로비전된 볼륨에 사용되는 시크릿은 모든 네임스페이스에서 -생성할 수 있으며 `adminSecretNamespace` 파라미터로 참조될 수 있다. -사전에 프로비전된 볼륨에서 사용하는 시크릿은 이를 참조하는 PVC와 -동일한 네임스페이스에서 작성해야 한다. - ### Local {{< feature-state for_k8s_version="v1.14" state="stable" >}} @@ -892,3 +743,4 @@ volumeBindingMode: WaitForFirstConsumer 볼륨 바인딩을 지연시키면 스케줄러가 퍼시스턴트볼륨클레임에 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링 제약 조건을 고려할 수 있다. + diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index fe5971222b9..f887f6e4a6b 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -32,8 +32,8 @@ weight: 60 * 복제 지원은 동적 프로비저너만 사용할 수 있다. * CSI 드라이버는 볼륨 복제 기능을 구현했거나 구현하지 않았을 수 있다. * PVC는 대상 PVC와 동일한 네임스페이스에 있는 경우에만 복제할 수 있다(소스와 대상은 동일한 네임스페이스에 있어야 함). -* 복제는 동일한 스토리지 클래스 내에서만 지원된다. - - 대상 볼륨은 소스와 동일한 스토리지 클래스여야 한다. +* 복제는 서로 다른 스토리지 클래스에 대해서도 지원된다. + - 대상 볼륨은 소스와 동일하거나 다른 스토리지 클래스여도 된다. - 기본 스토리지 클래스를 사용할 수 있으며, 사양에 storageClassName을 생략할 수 있다. * 동일한 VolumeMode 설정을 사용하는 두 볼륨에만 복제를 수행할 수 있다(블록 모드 볼륨을 요청하는 경우에는 반드시 소스도 블록 모드여야 한다). diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 472a47630a4..a47246872e8 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -155,6 +155,8 @@ spec: 소스 볼륨 모드가 명시되어 있지 않으면, 쿠버네티스는 해당 스냅샷의 소스 볼륨 모드를 알려지지 않은 상태(unknown)로 간주하여 스냅샷을 처리한다. +`volumeSnapshotRef`은 상응하는 `VolumeSnapshot`의 참조이다. `VolumeSnapshotContent`이 이전에 프로비전된 스냅샷으로 생성된 경우, `volumeSnapshotRef`에서 참조하는 `VolumeSnapshot`은 아직 존재하지 않을 수도 있음에 주의한다. + ## 스냅샷의 볼륨 모드 변환하기 {#convert-volume-mode} 클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면, diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index cf5252852e6..aa12838fa0b 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -104,7 +104,7 @@ metadata: name: test-ebs spec: containers: - - image: k8s.gcr.io/test-webserver + - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /test-ebs @@ -121,14 +121,13 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} `awsElasticBlockStore` 의 `CSIMigration` 기능이 활성화된 경우, 기존 인-트리 플러그인의 모든 플러그인 작업을 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리디렉션한다. 이 기능을 사용하려면, 클러스터에 [AWS EBS CSI 드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)를 -설치하고 `CSIMigration` 과 `CSIMigrationAWS` -베타 기능을 활성화해야 한다. +설치해야 한다. #### AWS EBS CSI 마이그레이션 완료 @@ -152,8 +151,8 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} -`flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다. -{{< /note >}} - -더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker)를 참조한다. - ### gcePersistentDisk (사용 중단됨) {#gcepersistentdisk} {{< feature-state for_k8s_version="v1.17" state="deprecated" >}} @@ -446,7 +427,7 @@ metadata: name: test-pd spec: containers: - - image: k8s.gcr.io/test-webserver + - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /test-pd @@ -507,14 +488,13 @@ spec: #### GCE CSI 마이그레이션 -{{< feature-state for_k8s_version="v1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러그인에서 `pd.csi.storage.gke.io` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 리디렉션한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI 드라이버](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) -를 설치하고 `CSIMigration` 과 `CSIMigrationGCE` -베타 기능을 활성화해야 한다. +를 설치해야 한다. #### GCE CSI 마이그레이션 완료 @@ -554,7 +534,9 @@ spec: revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` -### glusterfs +### glusterfs (사용 중단됨) + +{{< feature-state for_k8s_version="v1.25" state="deprecated" >}} `glusterfs` 볼륨을 사용하면 [Glusterfs](https://www.gluster.org) (오픈 소스 네트워크 파일시스템) 볼륨을 파드에 마운트할 수 있다. 파드를 @@ -629,7 +611,7 @@ metadata: name: test-pd spec: containers: - - image: k8s.gcr.io/test-webserver + - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /test-pd @@ -660,7 +642,7 @@ metadata: spec: containers: - name: test-webserver - image: k8s.gcr.io/test-webserver:latest + image: registry.k8s.io/test-webserver:latest volumeMounts: - mountPath: /var/local/aaa name: mydir @@ -796,7 +778,9 @@ iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다. 더 자세한 내용은 [퍼시스턴트볼륨 예시](/ko/docs/concepts/storage/persistent-volumes)를 본다. -### portworxVolume {#portworxvolume} +### portworxVolume (사용 중단됨) {#portworxvolume} + +{{< feature-state for_k8s_version="v1.25" state="deprecated" >}} `portworxVolume` 은 쿠버네티스와 하이퍼컨버지드(hyperconverged)를 실행하는 탄력적인 블록 스토리지 계층이다. [Portworx](https://portworx.com/use-case/kubernetes-storage/)는 서버의 @@ -814,7 +798,7 @@ metadata: name: test-portworx-volume-pod spec: containers: - - image: k8s.gcr.io/test-webserver + - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /mnt @@ -834,25 +818,22 @@ spec: 자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) 예제를 참고한다. +#### Portworx CSI 마이그레이션 +{{< feature-state for_k8s_version="v1.25" state="beta" >}} + +Portworx를 위한 `CSIMigration` 기능이 쿠버네티스 1.23에 추가되었지만 알파 상태이기 때문에 기본적으로는 비활성화되어 있었다. +v1.25 이후 이 기능은 베타 상태가 되었지만 여전히 기본적으로는 비활성화되어 있다. +이 기능은 사용 중인 트리 내(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`를 설정해야 한다. + ### projected `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. 더 자세한 사항은 [projected volumes](/ko/docs/concepts/storage/projected-volumes/)를 참고한다. -### quobyte (사용 중단됨) {#quobyte} - -`quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을 -파드에 마운트할 수 있다. - -{{< note >}} -사용하기 위해선 먼저 Quobyte를 설정하고 생성한 볼륨과 -함께 실행해야 한다. -{{< /note >}} - -Quobyte는 {{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}를 지원한다. -CSI 는 쿠버네티스 내에서 Quobyte 볼륨을 사용하기 위해 권장하는 플러그인이다. Quobyte의 -깃헙 프로젝트에는 예시와 함께 CSI를 사용해서 Quobyte를 배포하기 위한 [사용 설명서](https://github.com/quobyte/quobyte-csi#quobyte-csi)가 있다. - ### rbd `rbd` 볼륨을 사용하면 @@ -885,8 +866,9 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 드라이버로 리다이렉트한다. 이 기능을 사용하려면, 클러스터에 [Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고 -`CSIMigration`, `csiMigrationRBD` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. +`csiMigrationRBD` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화되어 있어야 한다. (v1.24 릴리즈에서 `csiMigrationRBD` 플래그는 삭제되었으며 +`CSIMigrationRBD`로 대체되었음에 주의한다.) {{< note >}} @@ -926,61 +908,6 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토 더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다. -### storageOS (사용 중단됨) {#storageos} - -`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) -볼륨을 파드에 마운트할 수 있다. - -StorageOS 는 쿠버네티스 환경에서 컨테이너로 실행되므로 -쿠버네티스 클러스터의 모든 노드의 로컬 또는 연결된 스토리지에 접근할 수 있다. -노드 장애로부터 보호하기 위해 데이터를 복제할 수 있다. 씬(Thin) 프로비저닝과 -압축은 활용률을 높이고 비용을 절감할 수 있게 한다. - -StorageOS의 핵심은 컨테이너에 파일시스템을 통해 접근할 수 있는 블록 스토리지를 제공하는 것이다. - -StorageOS 컨테이너는 64 비트 리눅스가 필요하고 추가적인 종속성이 없다. -무료 개발자 라이선스를 사용할 수 있다. - -{{< caution >}} -StorageOS 볼륨에 접근하거나 스토리지 용량을 -풀에 제공할 StorageOS 컨테이너를 실행해야 한다. -설치 설명서는 -[StorageOS 문서](https://docs.storageos.com)를 찾아본다. -{{< /caution >}} - -다음의 예시는 StorageOS를 사용한 파드 구성이다. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - labels: - name: redis - role: master - name: test-storageos-redis -spec: - containers: - - name: master - image: kubernetes/redis:v1 - env: - - name: MASTER - value: "true" - ports: - - containerPort: 6379 - volumeMounts: - - mountPath: /redis-master-data - name: redis-data - volumes: - - name: redis-data - storageos: - # `redis-vol01` 볼륨은 StorageOS에 `default` 네임스페이스로 있어야 한다. - volumeName: redis-vol01 - fsType: ext4 -``` - -StorageOS, 동적 프로비저닝과 퍼시스턴트 볼륨 클래임에 대한 더 자세한 정보는 -[StorageOS 예제](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 참고한다. - ### vsphereVolume (사용 중단됨) {#vspherevolume} {{< note >}} @@ -996,20 +923,22 @@ StorageOS, 동적 프로비저닝과 퍼시스턴트 볼륨 클래임에 대한 {{< feature-state for_k8s_version="v1.19" state="beta" >}} -`vsphereVolume` 용 `CSIMigration` 기능이 활성화되면, 기존 인-트리 플러그인에서 -`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다. 이 기능을 사용하려면, +`vsphereVolume` 용 `CSIMigrationvSphere` 기능은 쿠버네티스 v1.25부터 기본적으로 활성화되어 있다. +인-트리 `vspherevolume`의 모든 플러그인 작업은 `CSIMigrationvSphere` 기능 게이트가 비활성화된 경우를 제외하고 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}}로 리다이렉트된다. + + [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 -클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. -마이그레이션에 대한 추가 조언은 VMware의 문서 페이지 +클러스터에 설치되어 있어야 한다. 인-트리 `vsphereVolume` 마이그레이션에 대한 추가 조언은 VMware의 문서 페이지 [인-트리 vSphere 볼륨을 vSphere 컨테이너 스토리지 플러그인으로 마이그레이션하기](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html)를 참고한다. -쿠버네티스 v{{< skew currentVersion >}} 버전에서 외부(out-of-tree) CSI 드라이버로 마이그레이션하려면 -vSphere 7.0u2 이상을 사용하고 있어야 한다. +쿠버네티스 v1.25 현재, 7.0u2 이하의 vSphere는 +(사용 중단된) 인-트리 vSphere 스토리지 드라이버가 지원되지 않는다. +사용 중단된 드라이버를 계속 사용하거나, 교체된 CSI 드라이버로 +마이그레이션하기 위해서는 vSphere 7.0u2 이상을 사용해야 한다. + v{{< skew currentVersion >}} 외의 쿠버네티스 버전을 사용 중인 경우, 해당 쿠버네티스 버전의 문서를 참고한다. -쿠버네티스 v{{< skew currentVersion >}} 버전과 vSphere 이전 버전을 사용 중이라면, -vSphere 버전을 7.0u2 이상으로 업그레이드하는 것을 추천한다. + {{< note >}} 빌트인 `vsphereVolume` 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다. @@ -1032,16 +961,6 @@ 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} 때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. @@ -1179,8 +1098,7 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 * [퍼시스턴트볼륨클레임](#persistentvolumeclaim)에 대한 참조를 통해서 * [일반 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)과 함께 -* 드라이버가 지원하는 경우 - [CSI 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)과 함께 (베타 기능) +* 드라이버가 지원하는 경우 [CSI 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)과 함께 스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을 구성할 수 있다. @@ -1218,16 +1136,28 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에 둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다. +`nodeExpandSecretRef`: CSI `NodeExpandVolume` 호출을 완료하기 위해 + CSI 드라이버에 전달하려는 민감한 정보를 포함하고 있는 시크릿에 대한 + 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 경우 + 비어있을 수 있다. 오브젝트에 둘 이상의 시크릿이 포함된 경우에도, 모든 + 시크릿이 전달된다. 노드에 의해 시작된 볼륨 확장을 위한 + 시크릿 정보를 설정하면, kubelet은 `NodeExpandVolume()` 호출을 통해 CSI 드라이버에 + 해당 데이터를 전달한다. `nodeExpandSecretRef` 필드를 사용하기 위해, + 클러스터는 쿠버네티스 버전 1.25 이상을 실행 중이어야 하며 + 모든 노드의 모든 kube-apiserver와 kubelet을 대상으로 `CSINodeExpandSecret` + [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 + 활성화해야 한다. 또한 노드에 의해 시작된 스토리지 크기 조정 작업 시 시크릿 정보를 지원하거나 필요로 하는 + CSI 드라이버를 사용해야 한다. +* `nodePublishSecretRef`: CSI의 `NodePublishVolume` 호출을 완료하기 위해 + CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 + 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 + 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 + 모든 시크릿이 전달된다. * `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해 CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에 둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다. -* `nodePublishSecretRef`: CSI의 `NodePublishVolume` 호출을 완료하기위해 - CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 - 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 - 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 - 모든 시크릿이 전달된다. #### CSI 원시(raw) 블록 볼륨 지원 @@ -1241,7 +1171,7 @@ CSI 설정 변경 없이 평소와 같이 #### CSI 임시(ephemeral) 볼륨 -{{< feature-state for_k8s_version="v1.16" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} 파드 명세 내에서 CSI 볼륨을 직접 구성할 수 있다. 이 방식으로 지정된 볼륨은 임시 볼륨이며 @@ -1268,9 +1198,9 @@ CSI 노드 플러그인은 권한 있는 컨테이너로 배포된다. 윈도우 #### 인-트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기 -{{< feature-state for_k8s_version="v1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} -`CSIMigration` 기능이 활성화 되면 기존의 인-트리 플러그인에 +`CSIMigration` 기능은 기존의 인-트리 플러그인에 대한 작업을 해당 CSI 플러그인(설치와 구성이 될 것으로 예상한)으로 유도한다. 결과적으로, 운영자는 인-트리 플러그인을 대체하는 CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임(인-트리 플러그인 참조)에 @@ -1290,7 +1220,7 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트 * [`gcePersistentDisk`](#gcepersistentdisk) * [`vsphereVolume`](#vspherevolume) -### flexVolume +### flexVolume (사용 중단됨) {#flexvolume-deprecated} {{< feature-state for_k8s_version="v1.23" state="deprecated" >}} diff --git a/content/ko/docs/concepts/storage/windows-storage.md b/content/ko/docs/concepts/storage/windows-storage.md index e84fe66347b..9dae4c3271c 100644 --- a/content/ko/docs/concepts/storage/windows-storage.md +++ b/content/ko/docs/concepts/storage/windows-storage.md @@ -56,7 +56,7 @@ content_type: concept [플러그인](/ko/docs/concepts/storage/volumes/#volume-types) 형태로 제공된다. 윈도우는 다음의 광역 쿠버네티스 볼륨 플러그인 클래스를 지원한다. -* [`FlexVolume 플러그인`](/ko/docs/concepts/storage/volumes/#flexVolume) +* [`FlexVolume 플러그인`](/ko/docs/concepts/storage/volumes/#flexvolume-deprecated) * FlexVolumes은 1.23부터 사용 중단되었음에 유의한다. * [`CSI 플러그인`](/ko/docs/concepts/storage/volumes/#csi) diff --git a/content/ko/docs/concepts/windows/intro.md b/content/ko/docs/concepts/windows/intro.md index 4cdae9af3f5..42eabf61b6e 100644 --- a/content/ko/docs/concepts/windows/intro.md +++ b/content/ko/docs/concepts/windows/intro.md @@ -88,13 +88,12 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * OS 필드: 특정 파드가 윈도우 컨테이너를 사용하고 있다는 것을 나타내려면 `.spec.os.name` 필드를 `windows`로 설정해야 한다. - 이 필드가 인식되도록 하기 위해서는 `IdentifyPodOS` 기능 게이트가 활성화되어야 한다. {{< note >}} - 쿠버네티스 1.24부터, `IdentifyPodOS` 기능 게이트는 베타 단계이며 기본적으로 활성화되어 있다. + 쿠버네티스 1.25부터, `IdentifyPodOS` 기능 게이트는 GA 단계이며 기본적으로 활성화되어 있다. {{< /note >}} - `IdentifyPodOS` 기능 게이트가 활성화되어 있고 `.spec.os.name` 필드를 `windows`로 설정했다면, + `.spec.os.name` 필드를 `windows`로 설정했다면, 해당 파드의 `.spec` 내의 다음 필드는 설정하지 않아야 한다. * `spec.hostPID` @@ -285,7 +284,7 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 쿠버네티스는 윈도우 지원을 포함하는 다중 아키텍처 이미지를 유지보수한다. 쿠버네티스 v{{< skew currentVersion >}}의 경우 -권장 퍼즈 이미지는 `k8s.gcr.io/pause:3.6`이다. +권장 퍼즈 이미지는 `registry.k8s.io/pause:3.6`이다. [소스 코드](https://github.com/kubernetes/kubernetes/tree/master/build/pause)는 GitHub에서 찾을 수 있다. Microsoft는 리눅스 및 윈도우 amd64를 지원하는 다중 아키텍처 이미지를 diff --git a/content/ko/docs/concepts/windows/user-guide.md b/content/ko/docs/concepts/windows/user-guide.md index 1ecb608480a..8321d70cdeb 100644 --- a/content/ko/docs/concepts/windows/user-guide.md +++ b/content/ko/docs/concepts/windows/user-guide.md @@ -158,14 +158,13 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. -`IdentifyPodOS` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면, -파드의 컨테이너가 어떤 운영 체제용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). +1.25부터, 파드의 컨테이너가 어떤 운영체제 용인지를 파드의 `.spec.os.name`에 설정할 수 있다(그리고 설정해야 한다). 리눅스 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `linux`로 설정한다. 윈도우 컨테이너를 실행하는 파드에는 `.spec.os.name`을 `windows`로 설정한다. {{< note >}} -1.24부터, `IdentifyPodOS` 기능은 베타 단계이며 기본적으로 활성화되어 있다. +1.25부터, `IdentifyPodOS` 기능은 GA 단계이며 기본적으로 활성화되어 있다. {{< /note >}} 스케줄러는 파드를 노드에 할당할 때 diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 7a28dd02e06..4979858b413 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -94,7 +94,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 ## 타임 존 크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다. -{{< feature-state for_k8s_version="v1.24" state="alpha" >}} +{{< feature-state for_k8s_version="v1.25" state="beta" >}} `CronJobTimeZone` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면, 크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나, diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index f808131e9ee..385fa7269eb 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -121,8 +121,8 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml * `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. * `AGE` 는 애플리케이션의 실행된 시간을 표시한다. - 레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[RANDOM-STRING]` 형식으로 된 것을 알 수 있다. 무작위 문자열은 - 무작위로 생성되며, `pod-template-hash` 를 시드(seed)로 사용한다. + 레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[HASH]` 형식으로 된 것을 알 수 있다. + `HASH` 문자열은 레플리카셋의 `pod-template-hash` 레이블과 같다. 6. 각 파드에 자동으로 생성된 레이블을 보려면, `kubectl get pods --show-labels` 를 실행한다. 다음과 유사하게 출력된다. @@ -532,7 +532,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 ``` deployment.apps/nginx-deployment rolled back ``` - Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`: + 또는 특정 수정 버전으로 롤백하려면 `--to-revision` 옵션에 해당 수정 버전을 명시한다. ```shell kubectl rollout undo deployment/nginx-deployment --to-revision=2 diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 3d971108718..25a5926f4d1 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -695,6 +695,89 @@ spec: `manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있으며 이런 불일치를 허용한다고 알릴 수 있다. +### 파드 실패 정책{#pod-failure-policy} + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +{{< note >}} +잡(Job)에 대한 파드 실패 정책은 +`JobPodFailurePolicy` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 +클러스터에서 활성화됐을 경우에만 구성할 수 있다. 추가적으로, +파드 장애 정책의 파드 중단 조건 (참조: +[파드 중단 조건](/ko/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions))을 +감지하고 처리할 수 있도록 `PodDisruptionConditions` 기능 게이트를 활성화하는 것을 권장한다. 두 기능 게이트 모두 +쿠버네티스 v1.25에서 사용할 수 있다. +{{< /note >}} + +`.spec.podFailurePolicy` 필드로 정의되는 파드 실패 정책은, 클러스터가 +컨테이너 종료 코드와 파드 상태를 기반으로 파드의 실패를 +처리하도록 활성화한다. + +어떤 상황에서는, 파드의 실패를 처리할 때 잡(Job)의 `.spec.backoffLimit`을 기반으로 하는 +[파드 백오프(backoff) 실패 정책](#pod-backoff-failure-policy)에서 +제공하는 제어보다 더 나은 제어를 원할 수 있다. 다음은 사용 사례의 몇 가지 예시다. +* 불필요한 파드 재시작을 방지하여 워크로드 실행 비용을 최적화하려면, + 파드 중 하나가 소프트웨어 버그를 나타내는 종료 코드와 함께 실패하는 즉시 + 잡을 종료할 수 있다. +* 중단이 있더라도 잡이 완료되도록 하려면, + 중단(예: {{< glossary_tooltip text="선점(preemption)" term_id="preemption" >}}, + {{< glossary_tooltip text="API를 이용한 축출(API-initiated Eviction)" term_id="api-eviction" >}} + 또는 축출 기반 {{< glossary_tooltip text="테인트(Taints)" term_id="taint" >}})으로 인한 + 파드 실패를 무시하여 `.spec.backoffLimit` 재시도 한도에 포함되지 않도록 할 수 있다. + +위의 사용 사례를 충족하기 위해 +`.spec.podFailurePolicy` 필드에 파드 실패 정책을 구성할 수 있다. +이 정책은 컨테이너 종료 코드 및 파드 상태를 기반으로 파드 실패를 처리할 수 있다. + +다음은 `podFailurePolicy`를 정의하는 잡의 매니페스트이다. + +{{< codenew file="/controllers/job-pod-failure-policy-example.yaml" >}} + +위 예시에서, 파드 실패 정책의 첫 번째 규칙은 `main` 컨테이너가 42 종료코드와 +함께 실패하면 잡도 실패로 표시되는 것으로 +지정한다. 다음은 구체적으로 `main` 컨테이너에 대한 규칙이다. + +- 종료 코드 0은 컨테이너가 성공했음을 의미한다. +- 종료 코드 42는 **전체 잡**이 실패했음을 의미한다. +- 다른 모든 종료 코드는 컨테이너 및 전체 파드가 실패했음을 + 나타낸다. 재시작 횟수인 `backoffLimit`까지 파드가 + 다시 생성된다. 만약 `backoffLimit`에 도달하면 **전체 잡**이 실패한다. + +{{< note >}} +파드 템플릿이 `restartPolicy: Never`로 지정되었기 때문에, +kubelet은 특정 파드에서 `main` 컨테이너를 재시작하지 않는다. +{{< /note >}} + +`DisruptionTarget` 컨디션을 갖는 실패한 파드에 대해 +`Ignore` 동작을 하도록 명시하고 있는 파드 실패 정책의 두 번째 규칙으로 인해, +`.spec.backoffLimit` 재시도 한도 계산 시 파드 중단(disruption)은 횟수에서 제외된다. + +{{< note >}} +파드 실패 정책 또는 파드 백오프 실패 정책에 의해 잡이 실패하고, +잡이 여러 파드를 실행중이면, 쿠버네티스는 아직 보류(Pending) 또는 +실행(Running) 중인 해당 잡의 모든 파드를 종료한다. +{{< /note >}} + +다음은 API의 몇 가지 요구 사항 및 의미이다. +- 잡에 `.spec.podFailurePolicy` 필드를 사용하려면, + `.spec.restartPolicy`가 `Never`로 설정된 잡의 파드 템플릿 또한 정의해야 한다. +- `spec.podFailurePolicy.rules`에 기재한 파드 실패 정책 규칙은 기재한 순서대로 평가된다. + 파드 실패 정책 규칙이 파드 실패와 매치되면 나머지 규칙은 무시된다. + 파드 실패와 매치되는 파드 실패 정책 규칙이 없으면 + 기본 처리 방식이 적용된다. +- `spec.podFailurePolicy.rules[*].containerName`에 컨테이너 이름을 지정하여 파드 실패 규칙을 특정 컨테이너에게만 제한할 수 있다. + 컨테이너 이름을 지정하지 않으면 파드 실패 규칙은 모든 컨테이너에 적용된다. + 컨테이너 이름을 지정한 경우, + 이는 파드 템플릿의 컨테이너 또는 `initContainer` 이름 중 하나와 일치해야 한다. +- 파드 실패 정책이 `spec.podFailurePolicy.rules[*].action`과 일치할 때 취할 동작을 지정할 수 있다. + 사용 가능한 값은 다음과 같다. + - `FailJob`: 파드의 잡을 `Failed`로 표시하고 + 실행 중인 모든 파드를 종료해야 함을 나타낸다. + - `Ignore`: `.spec.backoffLimit`에 대한 카운터가 증가하지 않아야 하고 + 대체 파드가 생성되어야 함을 나타낸다. + - `Count`: 파드가 기본 방식으로 처리되어야 함을 나타낸다. + `.spec.backoffLimit`에 대한 카운터가 증가해야 한다. + ### 종료자(finalizers)를 이용한 잡 추적 {{< feature-state for_k8s_version="v1.23" state="beta" >}} @@ -740,7 +823,7 @@ API 서버에서 파드가 제거되면 이를 알아챈다. ### 베어(Bare) 파드 파드가 실행 중인 노드가 재부팅되거나 실패하면 파드가 종료되고 -다시 시작되지 않는다. 그러나 잡은 종료된 항목을 대체하기 위해 새 파드를 생성한다. +재시작되지 않는다. 그러나 잡은 종료된 항목을 대체하기 위해 새 파드를 생성한다. 따라서, 애플리케이션에 단일 파드만 필요한 경우에도 베어 파드 대신 잡을 사용하는 것을 권장한다. @@ -780,6 +863,7 @@ API 서버에서 파드가 제거되면 이를 알아챈다. * `Job`은 쿠버네티스 REST API의 일부이다. 잡 API에 대해 이해하기 위해 {{< api-reference page="workload-resources/job-v1" >}} - 오브젝트 정의를 읽은다. + 오브젝트 정의를 읽는다. * 스케줄을 기반으로 실행되는 일련의 잡을 정의하는데 사용할 수 있고, 유닉스 툴 `cron`과 유사한 [`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)에 대해 읽는다. +* 단계별로 구성된 [예제](/docs/tasks/job/pod-failure-policy/)를 통해, `podFailurePolicy`를 사용하여 재시도 가능 및 재시도 불가능 파드의 실패 처리를 하기위한 구성 방법을 연습한다. \ No newline at end of file diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index cc571ffab4b..b01aca022c1 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -94,7 +94,7 @@ spec: terminationGracePeriodSeconds: 10 containers: - name: nginx - image: k8s.gcr.io/nginx-slim:0.8 + image: registry.k8s.io/nginx-slim:0.8 ports: - containerPort: 80 name: web @@ -138,13 +138,12 @@ spec: ### 최소 준비 시간 초 {#minimum-ready-seconds} -{{< feature-state for_k8s_version="v1.23" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} `.spec.minReadySeconds` 는 파드가 '사용 가능(available)'이라고 간주될 수 있도록 파드의 모든 컨테이너가 -문제 없이 실행되어야 하는 최소 시간(초)을 나타내는 선택적인 필드이다. 이 기능은 베타이며 기본적으로 활성화되어 -있음에 유의한다. 이 기능을 사용하지 않으려면 -StatefulSetMinReadySeconds 플래그를 설정 해제한다. -이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.) +문제 없이 실행되고 준비되는 최소 시간(초)을 나타내는 선택적인 필드이다. +[롤링 업데이트](#롤링-업데이트) 전략을 사용할 때 롤아웃 진행 상황을 확인하는 데 사용된다. +이 필드의 기본값은 0이다(이 경우, 파드가 Ready 상태가 되면 바로 사용 가능하다고 간주된다.) 파드가 언제 사용 가능하다고 간주되는지에 대한 자세한 정보는 [컨테이너 프로브(probe)](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참고한다. diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 54c91e5f35e..2338eccc4c6 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -138,6 +138,23 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo 파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다. +### 파드 OS + +{{< feature-state state="stable" for_k8s_version="v1.25" >}} + +파드를 실행할 때 OS를 표시하려면 `.spec.os.name` 필드를 `windows` 또는 +`linux`로 설정해야 한다. 이 두 가지 운영체제는 현재 쿠버네티스에서 지원되는 +유일한 운영체제이다. 앞으로 이 목록이 확장될 수 있다. + +쿠버네티스 v{{< skew currentVersion >}}에서, 이 필드에 대해 설정한 값은 +파드의 {{< glossary_tooltip text="스케줄링" term_id="kube-scheduler" >}}에 영향을 미치지 않는다. +`.spec.os.name`을 설정하면 파드 검증 시 +OS를 식별하는 데 도움이 된다. +kubelet은 +자신이 실행되고 있는 노드의 운영체제와 +동일하지 않은 파드 OS가 명시된 파드의 실행을 거부한다. +[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)도 이 필드를 사용하여 해당 운영체제와 관련이 없는 정책을 시행하지 않도록 한다. + ### 파드와 컨트롤러 워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는 diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index ea0536ae96e..c53dd81358a 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -227,6 +227,44 @@ drain 커멘드는 `pod-b` 를 축출하는데 성공했다. - 컨트롤러의 유형 - 클러스터의 리소스 용량 +## 파드 중단 조건 {#pod-disruption-conditions} + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +{{< note >}} +클러스터에서 이 동작을 사용하려면 `PodDisruptionConditions` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화해야 한다. +{{< /note >}} + +이 기능이 활성화되면, 파드 전용 `DisruptionTarget` [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)이 추가되어 +{{}}으로 인해 파드가 삭제될 예정임을 나타낸다. +추가로 컨디션의 `reason` 필드는 +파드 종료에 대한 다음 원인 중 하나를 나타낸다. + +`PreemptionByKubeScheduler` +: 파드는 더 높은 우선순위를 가진 새 파드를 수용하기 위해 스케줄러에 의해 {{}}된다. 자세한 내용은 [파드 우선순위(priority)와 선점(preemption)](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)을 참조해보자. + +`DeletionByTaintManager` +: 허용하지 않는 `NoExecute` 테인트(taint) 때문에 파드가 테인트 매니저(`kube-controller-manager` 내의 노드 라이프사이클 컨트롤러의 일부)에 의해 삭제될 예정이다. {{}} 기반 축출을 참조해보자. + +`EvictionByEvictionAPI` +: 파드에 {{}}이 표시되었다. + +`DeletionByPodGC` +: 더 이상 존재하지 않는 노드에 바인딩된 파드는 [파드의 가비지 콜렉션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)에 의해 삭제될 예정이다. + +{{< note >}} +파드 중단은 중단될 수 있다. 컨트롤 플레인은 동일한 파드의 중단을 +계속 다시 시도하지만, 파드의 중단이 보장되지는 않는다. 결과적으로, +`DisruptionTarget` 컨디션이 파드에 추가될 수 있지만, 해당 파드는 사실상 +삭제되지 않았을 수 있다. 이러한 상황에서는, 일정 시간이 지난 뒤에 +파드 중단 상태가 해제된다. +{{< /note >}} + +잡(또는 크론잡(CronJob))을 사용할 때, 이러한 파드 중단 조건을 잡의 +[파드 실패 정책](/ko/docs/concepts/workloads/controllers/job#pod-failure-policy)의 일부로 사용할 수 있다. + ## 클러스터 소유자와 애플리케이션 소유자의 역할 분리 보통 클러스터 매니저와 애플리케이션 소유자는 diff --git a/content/ko/docs/concepts/workloads/pods/downward-api.md b/content/ko/docs/concepts/workloads/pods/downward-api.md index 5b1af7bbd17..8d458f52d46 100644 --- a/content/ko/docs/concepts/workloads/pods/downward-api.md +++ b/content/ko/docs/concepts/workloads/pods/downward-api.md @@ -22,7 +22,7 @@ description: > 쿠버네티스에는 실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다. -* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api) +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) * [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 @@ -127,5 +127,5 @@ CPU와 메모리에 할당 가능한 최댓값을 노출시킨다. 자세한 정보는 [`다운워드API` 볼륨](/ko/docs/concepts/storage/volumes/#downwardapi)를 참고한다. 다운워드 API를 사용하여 파드 및 컨테이너 정보를 노출시켜보자. -* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api) +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) * [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index c90bd72bc88..4d1a0d80c5e 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -9,7 +9,7 @@ weight: 80 -{{< feature-state state="beta" for_k8s_version="v1.23" >}} +{{< feature-state state="stable" for_k8s_version="v1.25" >}} 이 페이지는 임시 컨테이너에 대한 개요를 제공한다. 이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index b5a83a77209..1c42f27982f 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -154,9 +154,12 @@ kubelet은 해당 컨테이너의 재시작 백오프 타이머를 재설정한 파드는 하나의 PodStatus를 가지며, 그것은 파드가 통과했거나 통과하지 못한 -[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. +[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. kubelet은 다음 +PodConditions를 관리한다. * `PodScheduled`: 파드가 노드에 스케줄되었다. +* `PodHasNetwork`: (알파 기능; 반드시 [명시적으로 활성화](#pod-has-network)해야 함) +샌드박스가 성공적으로 생성되고 네트워킹이 구성되었다. * `ContainersReady`: 파드의 모든 컨테이너가 준비되었다. * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가 성공적으로 완료(completed)되었다. @@ -231,6 +234,36 @@ status: 파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 컨디션이 빠졌거나 `False` 이면, kubelet은 파드의 [컨디션](#파드의-컨디션)을 `ContainerReady` 로 설정한다. +### 파드 네트워크 준비성(readiness) {#pod-has-network} + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +파드가 노드에 스케줄링되면, kubelet이 이 파드를 승인해야 하고 +모든 볼륨이 마운트되어야 한다. 이러한 단계가 완료되면 kubelet은 +({{< glossary_tooltip term_id="cri" >}}를 사용하여) 컨테이너 런타임과 +통신하여 런타임 샌드박스를 설정하고 파드에 대한 네트워킹을 구성한다. 만약 +`PodHasNetworkCondition` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, +Kubelet은 파드의 `status.conditions` 필드에 있는 `PodHasNetwork` 컨디션을 통해 +파드가 초기화 마일스톤에 도달했는지 여부를 보고한다. + +Kubelet이 파드에 네트워킹이 구성된 런타임 샌드박스가 +없음을 탐지했을 때 `PodHasNetwork` 컨디션은 `False`로 설정된다. 이것은 다음 +시나리오에서 발생한다. +* 파드 라이프사이클 초기에, kubelet이 컨테이너 런타임을 사용하여 파드를 위한 샌드박스 생성을 아직 ​​시작하지 않은 때. +* 파드 라이프사이클 후기에, 파드 샌드박스가 다음중 하나의 이유로 +파괴되었을 때. + * 파드 축출 없이, 노드가 재부팅됨 + * 격리를 위해 가상 머신을 사용하는 컨테이너 런타임을 사용하는 경우, + 파드 샌드박스 가상 머신이 재부팅됨(이후, 새로운 샌드박스 및 새로운 컨테이너 네트워크 구성 생성이 필요함) + +런타임 플러그인이 파드를 위한 샌드박스 생성 및 네트워크 구성을 성공적으로 완료하면 +kubelet이 `PodHasNetwork` 컨디션을 `True`로 설정한다. +`PodHasNetwork` 컨디션이 `True`로 설정되면 kubelet이 컨테이너 이미지를 풀링하고 컨테이너를 생성할 수 있다. + +초기화 컨테이너가 있는 파드의 경우, kubelet은 초기화 컨테이너가 성공적으로 완료(런타임 플러그인에 의한 성공적인 샌드박스 생성 및 네트워크 구성이 완료되었음을 의미)된 후 `Initialized` 컨디션을 `True`로 설정한다. +초기화 컨테이너가 없는 파드의 경우, kubelet은 샌드박스 생성 및 네트워크 구성이 시작되기 전에 `Initialized` 컨디션을 `True`로 설정한다. + + ## 컨테이너 프로브(probe) _프로브_ 는 @@ -466,7 +499,7 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파 [스테이트풀셋에서 파드를 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 태스크 문서를 참고한다. -### 실패한 파드의 가비지 콜렉션 {#pod-garbage-collection} +### 종료된 파드의 가비지 콜렉션 {#pod-garbage-collection} 실패한 파드의 경우, API 오브젝트는 사람이나 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 프로세스가 diff --git a/content/ko/docs/concepts/workloads/pods/user-namespaces.md b/content/ko/docs/concepts/workloads/pods/user-namespaces.md new file mode 100644 index 00000000000..309045066d1 --- /dev/null +++ b/content/ko/docs/concepts/workloads/pods/user-namespaces.md @@ -0,0 +1,164 @@ +--- +title: 사용자 네임스페이스 +reviewers: +content_type: concept +weight: 160 +min-kubernetes-server-version: v1.25 +--- + + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +이 페이지에서는 사용자 네임스페이스가 쿠버네티스 파드에서 사용되는 방법에 대해 설명한다. +사용자 네임스페이스는 컨테이너 내에서 실행 중인 사용자와 +호스트의 사용자를 분리할 수 있도록 한다. + +컨테이너에서 루트(root)로 실행되는 프로세스는 +호스트에서 다른 (루트가 아닌) 사용자로 실행될 수 있다. +즉, 프로세스는 사용자 네임스페이스 내부 작업에 대해 특권을 갖지만(privileged) +네임스페이스 외부의 작업에서는 특권을 갖지 않는다. + +이러한 기능을 사용하여 훼손(compromised)된 컨테이너가 +호스트나 동일한 노드의 다른 파드에 미칠 수 있는 손상을 줄일 수 있다. +**HIGH** 또는 **CRITICAL** 등급의 일부 [보안 취약점][KEP-vulns]은 +사용자 네임스페이스가 Active 상태일 때 사용할 수 없다. +사용자 네임스페이스는 일부 미래의 취약점들도 완화시킬 수 있을 것으로 기대된다. + +[KEP-vulns]: https://github.com/kubernetes/enhancements/tree/217d790720c5aef09b8bd4d6ca96284a0affe6c2/keps/sig-node/127-user-namespaces#motivation + + +## {{% heading "prerequisites" %}} + +{{% thirdparty-content single="true" %}} + + +이것은 리눅스 전용 기능이다. 또한 +{{< glossary_tooltip term_id="container-runtime" >}}에서 +이 기능을 쿠버네티스 스테이트리스(stateless) 파드와 함께 사용하려면 지원이 필요하다. + +* CRI-O: v1.25에는 사용자 네임스페이스가 지원된다. + +* containerd: 1.7 릴리즈에서 지원이 계획돼 있다. + 자세한 내용은 containerd 이슈 [#7063][containerd-userns-issue]를 참조한다. + +[cri-dockerd에서의 지원][CRI-dockerd-issue]은 아직 계획되지 않았다. + +[CRI-dockerd-issue]: https://github.com/Mirantis/cri-dockerd/issues/74 +[containerd-userns-issue]: https://github.com/containerd/containerd/issues/7063 + +## 개요 + +사용자 네임스페이스는 컨테이너의 사용자를 +호스트의 다른 사용자에게 매핑할 수 있는 리눅스 기능이다. +또한 사용자 네임스페이스의 파드에 부여된 기능은 네임스페이스 내부에서만 유효하고 외부에서는 무효하다. + +파드는 `pod.spec.hostUsers` 필드를 `false`로 설정해 +사용자 네임스페이스를 사용하도록 선택할 수 있다. + +kubelet은 동일 노드에 있는 두 개의 스테이트리스 파드가 동일한 매핑을 +사용하지 않도록 보장하는 방식으로 파드가 매핑된 호스트 UID나 GID를 선택한다. + +`pod.spec`의 `runAsUser`, `runAsGroup`, `fsGroup` 등의 필드는 항상 +컨테이너 내의 사용자를 가리킨다. + +이 기능을 활성화한 경우 유효한 UID/GID의 범위는 0부터 65535까지이다. +이는 파일 및 프로세스(`runAsUser`, `runAsGroup` 등)에 적용된다. + +이 범위를 벗어나는 UID/GID를 사용하는 파일은 오버플로 ID, +주로 65534(`/proc/sys/kernel/overflowuid`와 `/proc/sys/kernel/overflowgid`에서 설정됨)에 +속하는 것으로 간주된다. +그러나 65534 사용자/그룹으로 실행하더라도 이러한 파일을 수정할 수 없다. + +루트로 실행돼야 하지만 다른 호스트 네임스페이스나 리소스에 접근하지 않는 +대부분의 애플리케이션은 사용자 네임스페이스를 활성화한 경우 +변경할 필요 없이 계속 정상적으로 실행돼야 한다. + +## 스테이트리스 파드의 사용자 네임스페이스 이해하기 + +기본 설정의 여러 컨테이너 런타임(Docker Engine, containerd, CRI-O 등)은 +격리를 위해 리눅스 네임스페이스를 사용한다. +다른 기술도 존재하며 위와 같은 런타임에도 사용할 수 있다. +(예를 들어, Kata Container는 리눅스 네임스페이스 대신 VM을 사용한다.) +이 페이지는 격리를 위해 리눅스 네임스페이스를 사용하는 컨테이너 런타임에 주안을 둔다. + +파드를 생성할 때 기본적으로 컨테이너의 네트워크를 분리하는 네임스페이스, +프로세스 보기를 분리하는 PID 네임스페이스 등 +여러 새로운 네임스페이스가 격리에 사용된다. +사용자 네임스페이스를 사용하면 컨테이너의 사용자와 노드의 사용자가 격리된다. + +이는 컨테이너가 루트로 실행될 수 있고 호스트의 루트가 아닌 사용자에게 매핑될 수 있다는 것을 의미한다. +컨테이너 내부에서 프로세스는 자신이 루트로 실행된다고 생각하지만 +(따라서 `apt`, `yum` 등과 같은 도구가 정상적으로 작동) +실제로 프로세스는 호스트에 대한 권한이 없다. +예를 들어, 컨테이너 프로세스가 호스트에서 `ps`를 실행하고 +있는 사용자를 확인하는 경우 이를 확인 할 수 있다. +사용자 `ps`는 컨테이너 안에서 명령 `id`를 실행하면 나타나는 사용자와 동일하지 않다. + +이 추상화는 컨테이너가 호스트로 탈출하는 것과 같은 상황을 제한한다. +컨테이너가 호스트에서 권한이 없는 사용자로 실행 중이기 때문에 +호스트에게 수행할 수 있는 작업은 제한된다. + +또한, 각 파드의 사용자는 호스트의 서로 겹치지 않는 다른 사용자에게 매핑되므로 +다른 파드에 대해서도 수행할 수 있는 작업이 제한된다. + +파드에 부여된 기능 또한 파드 사용자 네임스페이스로 제한되는데 +대부분 유효하지 않고 심지어 일부는 완전히 무효하다. 다음은 두 가지 예시이다. +- `CAP_SYS_MODULE`은 사용자 네임스페이스를 사용하여 파드에 부여돼도 +아무런 효과가 없으며 파드는 커널 모듈을 로드할 수 없다. +- `CAP_SYS_ADMIN`은 파드의 사용자 네임스페이스로 제한되며 +네임스페이스 외부에서는 유효하지 않다. + +사용자 네임스페이스를 사용하지 않고 루트로 실행되는 컨테이너는 +컨테이너 브레이크아웃(container breakout)의 경우 노드에 대한 루트 권한을 가진다. +컨테이너에 일부 기능이 부여된 경우 호스트에서도 해당 기능이 유효하다. +사용자 네임스페이스를 사용할 경우 이 중 어느 것도 사실이 아니다. + +사용자 네임스페이스 사용 시 변경사항에 대한 자세한 내용은 +`man 7 user_namespace`를 참조한다. + +## 사용자 네임스페이스를 지원하도록 노드 설정하기 + +호스트의 파일 및 프로세스에서 0 ~ 65535 범위의 +UID/GID를 사용하는 것이 좋다. + +kubelet은 파드에 그것보다 더 높은 UID/GID를 할당한다. +따라서 가능한 많은 격리를 보장하려면 호스트의 파일 및 호스트의 프로세스에 사용되는 +UID/GID가 0-65535 범위여야 한다. + +이 권장 사항은 파드가 호스트의 임의의 파일을 +잠재적으로 읽을 수 있는 [CVE-2021-25741][CVE-2021-25741]과 +같은 CVE의 영향을 완화하기 위해 중요하다. +파드와 호스트의 UID/GID가 겹치지 않으면 파드가 수행할 수 있는 작업이 제한된다. +즉, 파드 UID/GID가 호스트의 파일 소유자/그룹과 일치하지 않게 된다. + +[CVE-2021-25741]: https://github.com/kubernetes/kubernetes/issues/104980 + +## 제약 사항 + +파드에 사용자 네임스페이스를 사용하는 경우 +다른 호스트 네임스페이스를 사용할 수 없다. +특히 `hostUsers: false`를 설정하면 다음 중 하나를 설정할 수 없다. + + * `hostNetwork: true` + * `hostIPC: true` + * `hostPID: true` + +파드는 볼륨을 전혀 사용하지 않거나 +볼륨을 사용하는 경우에는 다음 볼륨 유형만 사용할 수 있다. + + * configmap + * secret + * projected + * downwardAPI + * emptyDir + +파드가 이러한 볼륨의 파일을 읽을 수 있도록 하기 위해 +파드에 `.spec.securityContext.fsGroup`을 +`0`으로 지정한 것처럼 볼륨이 생성된다. +이 값이 다른 값으로 지정되면 당연히 이 다른 값이 대신 적용된다. + +이로 인해 볼륨의 특정 항목에 대한 `defaultMode`나 `mode`가 +그룹에 대한 권한 없이 지정되었더라도 +이러한 볼륨에 대한 폴더와 파일은 그룹에 대한 권한을 갖는다. +예를 들어 파일에 소유자에 대한 권한만 있는 방식으로 +이러한 볼륨을 마운트할 수 없다. diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md index 80983b9215d..b6ff9c284af 100644 --- a/content/ko/docs/contribute/participate/_index.md +++ b/content/ko/docs/contribute/participate/_index.md @@ -53,7 +53,7 @@ GitHub 팀과 OWNERS 파일이다. GitHub의 SIG Docs [팀]에는 두 분류가 있다. - 승인자와 리더를 위한 `@sig-docs-{language}-owners` -- 리뷰어를 위한 `@sig-docs-{language}-reviewers` +- 리뷰어를 위한 `@sig-docs-{language}-reviews` 그룹의 전원과 의사소통하기 위해서 각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다. diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 5571756c358..21529e0ce80 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -97,17 +97,17 @@ YAML 블록이다. 여기 예시가 있다. 파일에 코드를 직접 삽입하자. 다음 경우에 권장된다. (전체 목록은 아님) -- 이 코드는 `kubectl get deploy mydeployment -o json | jq '.status'`와 같은 - 명령어의 출력을 보여준다. -- 이 코드는 시도해보기에 적절하지 않다. 예를 들어 +- `kubectl get deploy mydeployment -o json | jq '.status'`와 같은 + 명령어의 출력을 보여주는 코드. +- 시도해보기에는 적절하지 않은 코드. 예를 들어 특정 [FlexVolume](/ko/docs/concepts/storage/volumes#flexvolume) 구현에 따라 파드를 만들기 위해 YAML 파일을 포함할 수 있다. -- 이 코드의 목적은 더 큰 파일의 일부를 강조하는 것이기 때문에 - 불완전한 예제다. 예를 들어 몇 가지 이유로 - [PodSecurityPolicy](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy) - 를 사용자 정의 방법을 설명할 때 문서 파일에서 직접 짧은 요약 정보를 제공할 수 있다. -- 이 코드는 사용자가 다른 이유로 시도하기 위한 것이 아니다. 예를 들어 +- 더 큰 파일의 일부분을 강조하기 위한 불완전한 예제 코드. + 예를 들어 [롤바인딩(RoleBinding)](/docs/reference/access-authn-authz/rbac/#role-binding-examples) + 에 대한 사용자 정의 방법을 설명할 때, + 문서 파일에서 직접 짧은 요약 정보를 제공할 수 있다. +- 사용자가 다른 이유로 시도하기 위한 것이 아닌 코드. 예를 들어 `kubectl edit` 명령을 사용하여 리소스에 새 속성을 추가하는 방법을 설명할 때 추가할 만한 속성을 포함하는 간단한 예를 제공할 수 있다. diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md index 46aa5a0b4cb..637e35af823 100644 --- a/content/ko/docs/reference/access-authn-authz/authorization.md +++ b/content/ko/docs/reference/access-authn-authz/authorization.md @@ -80,8 +80,6 @@ DELETE | delete(개별 리소스), deletecollection(리소스 모음) 쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면, -* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/) - * `policy` API 그룹의 `podsecuritypolicies` 리소스에 대한 `use` 동사. * [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) * `rbac.authorization.k8s.io` API 그룹의 `roles` 및 `clusterroles` 리소스에 대한 `bind` 동사. * [인증](/docs/reference/access-authn-authz/authentication/) diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md index aa4db94cb1d..85df22f0375 100644 --- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md @@ -56,15 +56,21 @@ weight: 50 1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다. 1. 이전 단계는 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다. -1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 어느 것도 `false` 로 설정되어 있지 않다면, API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다. -1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다. -1. 파드에 `imagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `imagePullSecrets` 이 파드에 추가된다. +1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 + 어느 것도 `false` 로 설정되어 있지 않다면, + API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다. +1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, + `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 + `volumeSource` 를 추가한다. +1. 파드에 `imagePullSecrets` 이 없는 경우, + `ServiceAccount` 의 `imagePullSecrets` 이 파드에 추가된다. #### 바인딩된 서비스 어카운트 토큰 볼륨 {{< feature-state for_k8s_version="v1.22" state="stable" >}} -서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. +서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 +시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. ```yaml - name: kube-api-access- @@ -89,11 +95,13 @@ weight: 50 프로젝티드 볼륨은 세 가지로 구성된다. -1. kube-apiserver로부터 TokenRequest API를 통해 얻은 서비스어카운트토큰(ServiceAccountToken). 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다. -1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 컨피그맵(ConfigMap). 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 기능 게이트인 `RootCAConfigMap`에 의해 동작한다. `RootCAConfigMap` 기능 게이트는 1.21에서 GA로 전환되었으며 기본적으로 활성화되어 있다. (이 플래그는 1.22에서 `--feature-gate` 인자에서 제외될 예정이다.) -1. 파드의 네임스페이스를 참조하는 DownwardAPI. +1. `kube-apiserver`로부터 TokenRequest API를 통해 얻은 `서비스어카운트토큰(ServiceAccountToken)`. + 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. + 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다. +1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 `컨피그맵(ConfigMap)`. +1. 파드의 네임스페이스를 참조하는 `DownwardAPI`. -상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다. +상세 사항은 [프로젝티드 볼륨](/ko/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다. ### 토큰 컨트롤러 @@ -119,7 +127,8 @@ weight: 50 컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다. 서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해 -서비스어카운트를 참조하는 어노테이션과 함께 `kubernetes.io/service-account-token` 유형의 시크릿을 생성하면 +서비스어카운트를 참조하는 어노테이션과 함께 +`kubernetes.io/service-account-token` 유형의 시크릿을 생성하면 컨트롤러가 새로 생성된 토큰으로 갱신한다. 다음은 시크릿에 대한 샘플 구성이다. @@ -149,3 +158,4 @@ kubectl delete secret mysecretname 서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고 "default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다. + diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index aca56d3dfb8..a9eb842e5a8 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -42,8 +42,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - 기능이 알파 또는 베타 상태인 경우, [알파/베타 기능 게이트 테이블](#알파-또는-베타-기능을-위한-기능-게이트)에서 나열된 기능을 찾을 수 있다. - 기능이 안정된 경우 해당 기능에 대한 모든 단계를 - [GA(graduated)/사용 중단(deprecated) 기능 게이트 테이블](#GA-또는-사용-중단된-기능을-위한-기능-게이트)에 나열할 수 있다. -- [GA/사용 중단 기능 게이트 테이블](#GA-또는-사용-중단된-기능을-위한-기능-게이트)에는 + [승급(graduated)/사용 중단(deprecated) 기능 게이트 테이블](#승급-또는-사용-중단된-기능을-위한-기능-게이트)에 나열할 수 있다. +- [승급/사용 중단 기능 게이트 테이블](#승급-또는-사용-중단된-기능을-위한-기능-게이트)에는 사용 중단된 기능과 철회(withdrawn) 기능의 목록도 있다. ### 알파 또는 베타 기능을 위한 기능 게이트 @@ -64,34 +64,28 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | 1.23 | | `AnyVolumeDataSource` | `true` | 베타 | 1.24 | | | `AppArmor` | `true` | 베타 | 1.4 | | +| `ContainerCheckpoint` | `false` | 알파 | 1.25 | | | `CPUManager` | `false` | 알파 | 1.8 | 1.9 | | `CPUManager` | `true` | 베타 | 1.10 | | | `CPUManagerPolicyAlphaOptions` | `false` | 알파 | 1.23 | | | `CPUManagerPolicyBetaOptions` | `true` | 베타 | 1.23 | | | `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | 1.22 | | `CPUManagerPolicyOptions` | `true` | 베타 | 1.23 | | -| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 | -| `CSIInlineVolume` | `true` | 베타 | 1.16 | - | -| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 | -| `CSIMigration` | `true` | 베타 | 1.17 | | -| `CSIMigrationAWS` | `false` | 알파 | 1.14 | 1.16 | -| `CSIMigrationAWS` | `false` | 베타 | 1.17 | 1.22 | -| `CSIMigrationAWS` | `true` | 베타 | 1.23 | | -| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 | +| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.20 | | `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | 1.23 | | `CSIMigrationAzureFile` | `true` | 베타 | 1.24 | | -| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 | -| `CSIMigrationGCE` | `false` | 베타 | 1.17 | 1.22 | -| `CSIMigrationGCE` | `true` | 베타 | 1.23 | | -| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | | -| `CSIMigrationPortworx` | `false` | 알파 | 1.23 | | -| `csiMigrationRBD` | `false` | 알파 | 1.23 | | +| `CSIMigrationPortworx` | `false` | 알파 | 1.23 | 1.24 | +| `CSIMigrationPortworx` | `false` | 베타 | 1.25 | | +| `CSIMigrationRBD` | `false` | 알파 | 1.23 | | +| `CSIMigrationvSphere` | `false` | 알팝 | 1.18 | 1.18 | +| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | 1.24 | +| `CSIMigrationvSphere` | `true` | 베타 | 1.25 | | +| `CSINodeExpandSecret` | `false` | 알파 | 1.25 | | | `CSIVolumeHealth` | `false` | 알파 | 1.21 | | | `ContextualLogging` | `false` | 알파 | 1.24 | | | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | -| `CustomResourceValidationExpressions` | `false` | 알파 | 1.23 | | -| `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 | -| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | | +| `CustomResourceValidationExpressions` | `false` | 알파 | 1.23 | 1.24 | +| `CustomResourceValidationExpressions` | `true` | 베타 | 1.25 | | | `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | 1.22 | | `DelegateFSGroupToCSIDriver` | `true` | 베타 | 1.23 | | | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | @@ -105,8 +99,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `DownwardAPIHugePages` | `true` | 베타 | 1.22 | | | `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | 1.21 | | `EndpointSliceTerminatingCondition` | `true` | 베타 | 1.22 | | -| `EphemeralContainers` | `false` | 알파 | 1.16 | 1.22 | -| `EphemeralContainers` | `true` | 베타 | 1.23 | | | `ExpandedDNSConfig` | `false` | 알파 | 1.22 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | | | `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 | @@ -118,8 +110,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | | | `HPAContainerMetrics` | `false` | 알파 | 1.20 | | | `HPAScaleToZero` | `false` | 알파 | 1.16 | | -| `IdentifyPodOS` | `false` | 알파 | 1.23 | 1.23 | -| `IdentifyPodOS` | `true` | 베타 | 1.24 | | | `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | | | `InTreePluginAzureDiskUnregister` | `false` | 알파 | 1.21 | | | `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | | @@ -141,21 +131,21 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `KubeletPodResources` | `true` | 베타 | 1.15 | | | `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | 1.22 | | `KubeletPodResourcesGetAllocatable` | `true` | 베타 | 1.23 | | -| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | -| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | +| `KubeletTracing` | `false` | 알파 | 1.25 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | | `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 | | `LogarithmicScaleDown` | `true` | 베타 | 1.22 | | +| `MatchLabelKeysInPodTopologySpread` | `false` | 알파 | 1.25 | | | `MaxUnavailableStatefulSet` | `false` | 알파 | 1.24 | | | `MemoryManager` | `false` | 알파 | 1.21 | 1.21 | | `MemoryManager` | `true` | 베타 | 1.22 | | | `MemoryQoS` | `false` | 알파 | 1.22 | | -| `MinDomainsInPodTopologySpread` | `false` | 알파 | 1.24 | | +| `MinDomainsInPodTopologySpread` | `false` | 알파 | 1.24 | 1.24 | +| `MinDomainsInPodTopologySpread` | `true` | 베타 | 1.25 | | | `MixedProtocolLBService` | `false` | 알파 | 1.20 | 1.23 | | `MixedProtocolLBService` | `true` | 베타 | 1.24 | | -| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | 1.21 | -| `NetworkPolicyEndPort` | `true` | 베타 | 1.22 | | | `NetworkPolicyStatus` | `false` | 알파 | 1.24 | | +| `NodeInclusionPolicyInPodTopologySpread` | `false` | 알파 | 1.25 | | | `NodeSwap` | `false` | 알파 | 1.22 | | | `NodeOutOfServiceVolumeDetach` | `false` | 알파 | 1.24 | | | `OpenAPIEnums` | `false` | 알파 | 1.23 | 1.23 | @@ -165,10 +155,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | | | `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 | | `PodDeletionCost` | `true` | 베타 | 1.22 | | +| `PodHasNetworkCondition` | `false` | 알파 | 1.25 | | | `PodSecurity` | `false` | 알파 | 1.22 | 1.22 | | `PodSecurity` | `true` | 베타 | 1.23 | | | `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 | -| `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | | +| `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | 1.24 | +| `ProbeTerminationGracePeriod` | `true` | 베타 | 1.25 | | | `ProcMountType` | `false` | 알파 | 1.12 | | | `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | | | `QOSReserved` | `false` | 알파 | 1.11 | | @@ -178,16 +170,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `RemainingItemCount` | `true` | 베타 | 1.16 | | | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | | -| `SeccompDefault` | `false` | 알파 | 1.22 | | -| `ServerSideFieldValidation` | `false` | 알파 | 1.23 | - | +| `SeccompDefault` | `false` | 알파 | 1.22 | 1.24 | +| `SeccompDefault` | `true` | 베타 | 1.25 | | +| `ServerSideFieldValidation` | `false` | 알파 | 1.23 | 1.24 | +| `ServerSideFieldValidation` | `true` | 베타 | 1.25 | | | `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | 1.21 | | `ServiceInternalTrafficPolicy` | `true` | 베타 | 1.22 | | -| `ServiceIPStaticSubrange` | `false` | 알파 | 1.24 | | +| `ServiceIPStaticSubrange` | `false` | 알파 | 1.24 | 1.24 | +| `ServiceIPStaticSubrange` | `true` | 베타 | 1.25 | | | `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 | | `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | | | `StatefulSetAutoDeletePVC` | `false` | 알파 | 1.22 | | -| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | 1.22 | -| `StatefulSetMinReadySeconds` | `true` | 베타 | 1.23 | | | `StorageVersionAPI` | `false` | 알파 | 1.20 | | | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | @@ -204,26 +197,26 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `WindowsHostProcessContainers` | `true` | 베타 | 1.23 | | {{< /table >}} -### GA 또는 사용 중단된 기능을 위한 기능 게이트 +### 승급 또는 사용 중단된 기능을 위한 기능 게이트 -{{< table caption="GA 또는 사용 중단 기능을 위한 기능 게이트" >}} +{{< table caption="승급 또는 사용 중단 기능을 위한 기능 게이트" >}} | 기능 | 디폴트 | 단계 | 도입 | 종료 | |---------|---------|-------|-------|-------| | `Accelerators` | `false` | 알파 | 1.6 | 1.10 | -| `Accelerators` | - | Deprecated | 1.11 | - | +| `Accelerators` | - | 사용 중단 | 1.11 | - | | `AdvancedAuditing` | `false` | 알파 | 1.7 | 1.7 | | `AdvancedAuditing` | `true` | 베타 | 1.8 | 1.11 | | `AdvancedAuditing` | `true` | GA | 1.12 | - | | `AffinityInAnnotations` | `false` | 알파 | 1.6 | 1.7 | -| `AffinityInAnnotations` | - | Deprecated | 1.8 | - | +| `AffinityInAnnotations` | - | 사용 중단 | 1.8 | - | | `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 | | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | | `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 | | `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 | | `AttachVolumeLimit` | `true` | GA | 1.17 | - | | `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | 1.21 | -| `BalanceAttachedNodeVolumes` | `false` | Deprecated | 1.22 | | +| `BalanceAttachedNodeVolumes` | `false` | 사용 중단 | 1.22 | | | `BlockVolume` | `false` | 알파 | 1.9 | 1.12 | | `BlockVolume` | `true` | 베타 | 1.13 | 1.17 | | `BlockVolume` | `true` | GA | 1.18 | - | @@ -245,25 +238,39 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 | | `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 | | `CSIDriverRegistry` | `true` | GA | 1.18 | - | +| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 | +| `CSIInlineVolume` | `true` | 베타 | 1.16 | 1.24 | +| `CSIInlineVolume` | `true` | GA | 1.25 | - | +| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 | +| `CSIMigration` | `true` | 베타 | 1.17 | 1.24 | +| `CSIMigration` | `true` | GA | 1.25 | - | +| `CSIMigrationAWS` | `false` | 알파 | 1.14 | 1.16 | +| `CSIMigrationAWS` | `false` | 베타 | 1.17 | 1.22 | +| `CSIMigrationAWS` | `true` | 베타 | 1.23 | 1.24 | +| `CSIMigrationAWS` | `true` | GA | 1.25 | - | | `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAWSComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationAWSComplete` | - | 사용 중단 | 1.21 | - | | `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 | | `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | 1.22 | | `CSIMigrationAzureDisk` | `true` | 베타 | 1.23 | 1.23 | | `CSIMigrationAzureDisk` | `true` | GA | 1.24 | | | `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAzureDiskComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationAzureDiskComplete` | - | 사용 중단 | 1.21 | - | | `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAzureFileComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationAzureFileComplete` | - | 사용 중단 | 1.21 | - | +| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 | +| `CSIMigrationGCE` | `false` | 베타 | 1.17 | 1.22 | +| `CSIMigrationGCE` | `true` | 베타 | 1.23 | 1.24 | +| `CSIMigrationGCE` | `true` | GA | 1.25 | - | | `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationGCEComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationGCEComplete` | - | 사용 중단 | 1.21 | - | | `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 | | `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | 1.23 | | `CSIMigrationOpenStack` | `true` | GA | 1.24 | | | `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationOpenStackComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationOpenStackComplete` | - | 사용 중단 | 1.21 | - | | `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | 1.21 | -| `CSIMigrationvSphereComplete` | - | Deprecated | 1.22 | - | +| `CSIMigrationvSphereComplete` | - | 사용 중단 | 1.22 | - | | `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 | | `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 | | `CSINodeInfo` | `true` | GA | 1.17 | - | @@ -284,7 +291,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 | | `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 | | `CronJobControllerV2` | `true` | GA | 1.22 | - | -| `CronJobTimeZone` | `false` | 알파 | 1.24 | | +| `CronJobTimeZone` | `false` | 알파 | 1.24 | 1.24 | +| `CronJobTimeZone` | `true` | 베타 | 1.25 | | | `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 | | `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 | | `CustomPodDNS` | `true` | GA | 1.14 | - | @@ -303,6 +311,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 | | `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 | | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - | +| `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 | +| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | 1.24 | +| `DaemonSetUpdateSurge` | `true` | GA | 1.25 | - | | `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 | | `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | 1.23 | | `DefaultPodTopologySpread` | `true` | GA | 1.24 | - | @@ -310,20 +321,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `DryRun` | `true` | 베타 | 1.13 | 1.18 | | `DryRun` | `true` | GA | 1.19 | - | | `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 | -| `DynamicAuditing` | - | Deprecated | 1.19 | - | +| `DynamicAuditing` | - | 사용 중단 | 1.19 | - | | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | | `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 | -| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - | +| `DynamicKubeletConfig` | `false` | 사용 중단 | 1.22 | - | | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 | -| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - | +| `DynamicProvisioningScheduling` | - | 사용 중단| 1.12 | - | | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | | `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 | | `EfficientWatchResumption` | `true` | 베타 | 1.21 | 1.23 | | `EfficientWatchResumption` | `true` | GA | 1.24 | - | -| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - | +| `EnableAggregatedDiscoveryTimeout` | `true` | 사용 중단 | 1.16 | - | | `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 | -| `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - | +| `EnableEquivalenceClassCache` | - | 사용 중단 | 1.15 | - | | `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | | `EndpointSlice` | `false` | 베타 | 1.17 | 1.17 | | `EndpointSlice` | `true` | 베타 | 1.18 | 1.20 | @@ -333,6 +344,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 | | `EndpointSliceProxying` | `true` | 베타 | 1.19 | 1.21 | | `EndpointSliceProxying` | `true` | GA | 1.22 | - | +| `EphemeralContainers` | `false` | 알파 | 1.16 | 1.22 | +| `EphemeralContainers` | `true` | 베타 | 1.23 | 1.24 | +| `EphemeralContainers` | `true` | GA | 1.25 | - | | `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | | `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 | | `EvenPodsSpread` | `true` | GA | 1.19 | - | @@ -347,7 +361,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | 1.23 | | `ExpandPersistentVolumes` | `true` | GA | 1.24 |- | | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | -| `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - | +| `ExperimentalCriticalPodAnnotation` | `false` | 사용 중단 | 1.13 | - | | `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | @@ -361,7 +375,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `HugePages` | `true` | 베타| 1.10 | 1.13 | | `HugePages` | `true` | GA | 1.14 | - | | `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 | -| `HyperVContainer` | `false` | Deprecated | 1.20 | - | +| `HyperVContainer` | `false` | 사용 중단 | 1.20 | - | +| `IdentifyPodOS` | `false` | 알파 | 1.23 | 1.23 | +| `IdentifyPodOS` | `true` | 베타 | 1.24 | 1.24 | +| `IdentifyPodOS` | `true` | GA | 1.25 | - | | `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 | | `IPv6DualStack` | `true` | 베타 | 1.21 | 1.22 | | `IPv6DualStack` | `true` | GA | 1.23 | - | @@ -375,9 +392,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | 1.22 | | `IngressClassNamespacedParams` | `true` | GA | 1.23 | - | | `Initializers` | `false` | 알파 | 1.7 | 1.13 | -| `Initializers` | - | Deprecated | 1.14 | - | +| `Initializers` | - | 사용 중단 | 1.14 | - | +| `JobPodFailurePolicy` | `false` | 알파 | 1.25 | - | | `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 | -| `KubeletConfigFile` | - | Deprecated | 1.10 | - | +| `KubeletConfigFile` | - | 사용 중단 | 1.10 | - | | `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 | | `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 | | `KubeletPluginsWatcher` | `true` | GA | 1.13 | - | @@ -385,13 +403,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | | `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - | | `LegacyServiceAccountTokenNoAutoGeneration` | `true` | 베타 | 1.24 | | +| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | +| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | 1.24 | +| `LocalStorageCapacityIsolation` | `true` | GA | 1.25 | - | | `MountContainers` | `false` | 알파 | 1.9 | 1.16 | -| `MountContainers` | `false` | Deprecated | 1.17 | - | +| `MountContainers` | `false` | 사용 중단 | 1.17 | - | | `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | | `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | | `MountPropagation` | `true` | GA | 1.12 | - | | `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 | | `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - | +| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | 1.21 | +| `NetworkPolicyEndPort` | `true` | 베타 | 1.22 | 1.24 | +| `NetworkPolicyEndPort` | `true` | GA | 1.25 | - | | `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | | `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 | | `NodeDisruptionExclusion` | `true` | GA | 1.21 | - | @@ -402,7 +426,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `NonPreemptingPriority` | `true` | 베타 | 1.19 | 1.23 | | `NonPreemptingPriority` | `true` | GA | 1.24 | - | | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 | -| `PVCProtection` | - | Deprecated | 1.10 | - | +| `PVCProtection` | - | 사용 중단 | 1.10 | - | | `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 | | `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 | | `PersistentLocalVolumes` | `true` | GA | 1.14 | - | @@ -412,6 +436,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | | `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 | | `PodDisruptionBudget` | `true` | GA | 1.21 | - | +| `PodDisruptionConditions` | `false` | 알파 | 1.25 | - | | `PodOverhead` | `false` | 알파 | 1.16 | 1.17 | | `PodOverhead` | `true` | 베타 | 1.18 | 1.23 | | `PodOverhead` | `true` | GA | 1.24 | - | @@ -431,9 +456,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `RemoveSelfLink` | `true` | 베타 | 1.20 | 1.23 | | `RemoveSelfLink` | `true` | GA | 1.24 | - | | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 | -| `RequestManagement` | - | Deprecated | 1.17 | - | +| `RequestManagement` | - | 사용 중단 | 1.17 | - | | `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 | -| `ResourceLimitsPriorityFunction` | - | Deprecated | 1.19 | - | +| `ResourceLimitsPriorityFunction` | - | 사용 중단 | 1.19 | - | | `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 | | `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 | | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - | @@ -478,19 +503,22 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 | | `ServiceNodeExclusion` | `true` | GA | 1.21 | - | | `ServiceTopology` | `false` | 알파 | 1.17 | 1.19 | -| `ServiceTopology` | `false` | Deprecated | 1.20 | - | +| `ServiceTopology` | `false` | 사용 중단 | 1.20 | - | | `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 | | `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | 1.21 | | `SetHostnameAsFQDN` | `true` | GA | 1.22 | - | | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | | `StartupProbe` | `true` | 베타 | 1.18 | 1.19 | | `StartupProbe` | `true` | GA | 1.20 | - | +| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | 1.22 | +| `StatefulSetMinReadySeconds` | `true` | 베타 | 1.23 | 1.24 | +| `StatefulSetMinReadySeconds` | `true` | GA | 1.25 | - | | `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 | | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | | `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | | `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.17 | -| `StreamingProxyRedirects` | `true` | Deprecated | 1.18 | 1.21 | -| `StreamingProxyRedirects` | `false` | Deprecated | 1.22 | - | +| `StreamingProxyRedirects` | `true` | 사용 중단 | 1.18 | 1.21 | +| `StreamingProxyRedirects` | `false` | 사용 중단 | 1.22 | - | | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 | | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 | | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 | @@ -523,7 +551,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `TokenRequestProjection` | `true` | GA | 1.20 | - | | `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 | | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | 1.21 | -| `ValidateProxyRedirects` | `true` | Deprecated | 1.22 | - | +| `ValidateProxyRedirects` | `true` | 사용 중단 | 1.22 | - | | `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 | | `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 | | `VolumePVCDataSource` | `true` | GA | 1.18 | - | @@ -603,11 +631,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다. - `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다. - `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다. + 자세한 내용은 [쿠버네티스 시스템 컴포넌트에 대한 추적](/ko/docs/concepts/cluster-administration/system-traces/)페이지를 살펴본다. - `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는 플러그인의 초기 형태를 제공하였으며, 사용 중단되었다. 대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 확인한다. -- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug/debug-cluster/audit/#advanced-audit) 기능을 활성화한다. +- `AdvancedAuditing`: [고급 감사](/ko/docs/tasks/debug/debug-cluster/audit/#advanced-audit) 기능을 활성화한다. - `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 설정을 활성화한다. - `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다. @@ -634,6 +663,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. +- `ContainerCheckpoint`: kubelet의 `체크포인트` API를 활성화한다. + 자세한 내용은 [kubelet 체크포인트 API](/docs/reference/node/kubelet-checkpoint-api/)를 확인한다. - `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가 kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면, cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록 @@ -645,11 +676,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 미세 조정을 허용한다. 이 기능 게이트는 품질 수준이 알파인 CPUManager 옵션의 *그룹*을 보호한다. - 이 기능 게이트는 베타 또는 안정(stable) 상태로 변경되지 않을 것이다. + 이 기능 게이트는 베타 또는 안정(stable) 상태로 승급되지 않을 것이다. - `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 미세 조정을 허용한다. 이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다. - 이 기능 게이트는 안정(stable) 상태로 변경되지 않을 것이다. + 이 기능 게이트는 안정(stable) 상태로 승급되지 않을 것이다. - `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다. - `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며, @@ -760,6 +791,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다. - `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. +- `CSINodeExpandSecret`: CSI 드라이버가 `NodeExpandVolume` 작업 수행 중에 사용할 수 있도록 + 시크릿 인증 데이터를 드라이버에 전송 가능하게 한다. - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 마운트할 수 있다. @@ -940,7 +973,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능을 활성화한다. - `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의 파드 템플릿에 있는 노드 스케줄링 지시를 업데이트할 수 있게 한다. -- `JobReadyPods`: 파드 [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)이 +- `JobPodFailurePolicy`: 사용자가 컨테이너의 종료 코드나 파드 상태에 따라 파드의 장애를 처리할 수 있도록 한다. +- `JobReadyPods`: 파드 [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)이 `Ready`인 파드의 수를 추적하는 기능을 활성화한다. `Ready`인 파드의 수는 [잡](/ko/docs/concepts/workloads/controllers/job/) 상태의 [status](/docs/reference/kubernetes-api/workload-resources/job-v1/#JobStatus) @@ -971,6 +1005,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다. +- `KubeletTracing`: kubelet에 분산 추적에 대한 지원을 추가한다. + 활성화된 경우, kubelet CRI 인터페이스와 인증된 http 서버들은 + OpenTelemetry 추적 범위를 형성하는 데 도움을 준다. + 자세한 내용은 [쿠버네티스 시스템 컴포넌트에 대한 추적](/ko/docs/concepts/cluster-administration/system-traces/) 페이지를 확인한다. - `LegacyServiceAccountTokenNoAutoGeneration`: 시크릿 기반 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)의 자동 생성을 중단한다. - `LocalStorageCapacityIsolation`: @@ -986,6 +1024,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 향상시킨다. - `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여 축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다. +- `MatchLabelKeysInPodTopologySpread`: [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)의 + `matchLabelKeys` 필드를 활성화한다. - `MaxUnavailableStatefulSet`: 스테이트풀셋의 [롤링 업데이트 전략](/ko/docs/concepts/workloads/controllers/statefulset/#롤링-업데이트)에 대해 `maxUnavailable` 필드를 설정할 수 있도록 한다. @@ -994,7 +1034,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 메모리 어피니티를 설정할 수 있다. - `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다. -- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/) 내의 +- `MinDomainsInPodTopologySpread`: [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/) 내의 `minDomains` 사용을 활성화한다. - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다. @@ -1007,6 +1047,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다. - `NetworkPolicyStatus`: 네트워크폴리시 오브젝트에 대해 `status` 서브리소스를 활성화한다. +- `NodeInclusionPolicyInPodTopologySpread`: 파드 토폴로지 분배 비대칭도를 계산할 때 + [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)의 + `nodeAffinityPolicy`와 `nodeTaintsPolicy`를 활성화한다. - `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다. - `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. @@ -1025,13 +1068,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다. - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. -- `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라 - CRI 컨테이너 런타임으로부터 수집하도록 설정한다. -- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. - `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과 [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다. +- `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드에 대한 통계치들을 + cAdvisor가 아닌 CRI 컨테이너 런타임으로부터 수집하도록 설정한다. +- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. +- `PodDisruptionConditions`: 중단(disruption)으로 인해 파드가 삭제되고 있음을 나타내는 파드 컨디션을 추가하도록 지원한다. +- `PodHasNetworkCondition`: kubelet이 파드에 [파드 네트워크 준비성](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-has-network) 컨디션을 표시하도록 지원한다. - `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다. - `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 @@ -1104,6 +1149,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다. - `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여 목록 작업을 가속화할 수 있다. +- `SELinuxMountReadWriteOncePod`: kubelet으로 하여금, + 볼륨에 있는 모든 파일에 대해 SELinux 레이블을 재귀적으로 적용하는 대신 + 올바른 SELinux 레이블을 가지고 볼륨을 마운트할 수 있도록 한다. - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다. - `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md index ecf66c07570..21742e3d709 100644 --- a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md @@ -144,7 +144,7 @@ kube-proxy [flags] --feature-gates <쉼표로 구분된 'key=True|False' 쌍들> -

    알파/실험적 기능의 기능 게이트를 나타내는 `key=value` 쌍의 집합. 사용 가능한 옵션은 다음과 같다:

    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 (BETA - default=true)
    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)
    CSIMigrationAzureFile=true|false (BETA - default=true)
    CSIMigrationGCE=true|false (BETA - default=true)
    CSIMigrationPortworx=true|false (ALPHA - default=false)
    CSIMigrationRBD=true|false (ALPHA - default=false)
    CSIMigrationvSphere=true|false (BETA - default=false)
    CSIVolumeHealth=true|false (ALPHA - default=false)
    CronJobTimeZone=true|false (ALPHA - default=false)
    CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
    CustomResourceValidationExpressions=true|false (ALPHA - default=false)
    DaemonSetUpdateSurge=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)
    EndpointSliceTerminatingCondition=true|false (BETA - default=true)
    EphemeralContainers=true|false (BETA - default=true)
    ExpandedDNSConfig=true|false (ALPHA - default=false)
    ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
    GRPCContainerProbe=true|false (BETA - default=true)
    GracefulNodeShutdown=true|false (BETA - default=true)
    GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
    HPAContainerMetrics=true|false (ALPHA - default=false)
    HPAScaleToZero=true|false (ALPHA - default=false)
    HonorPVReclaimPolicy=true|false (ALPHA - default=false)
    IdentifyPodOS=true|false (BETA - default=true)
    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)
    JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
    JobReadyPods=true|false (BETA - default=true)
    JobTrackingWithFinalizers=true|false (BETA - default=false)
    KubeletCredentialProviders=true|false (BETA - default=true)
    KubeletInUserNamespace=true|false (ALPHA - default=false)
    KubeletPodResources=true|false (BETA - default=true)
    KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
    LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)
    LocalStorageCapacityIsolation=true|false (BETA - default=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
    LogarithmicScaleDown=true|false (BETA - default=true)
    MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
    MemoryManager=true|false (BETA - default=true)
    MemoryQoS=true|false (ALPHA - default=false)
    MinDomainsInPodTopologySpread=true|false (ALPHA - default=false)
    MixedProtocolLBService=true|false (BETA - default=true)
    NetworkPolicyEndPort=true|false (BETA - default=true)
    NetworkPolicyStatus=true|false (ALPHA - default=false)
    NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)
    NodeSwap=true|false (ALPHA - default=false)
    OpenAPIEnums=true|false (BETA - default=true)
    OpenAPIV3=true|false (BETA - default=true)
    PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
    PodDeletionCost=true|false (BETA - default=true)
    PodSecurity=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)
    RotateKubeletServerCertificate=true|false (BETA - default=true)
    SeccompDefault=true|false (ALPHA - default=false)
    ServerSideFieldValidation=true|false (ALPHA - default=false)
    ServiceIPStaticSubrange=true|false (ALPHA - default=false)
    ServiceInternalTrafficPolicy=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)
    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 (BETA - default=true)

    --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

    +

    알파/실험적 기능의 기능 게이트를 나타내는 `key=value` 쌍의 집합. 사용 가능한 옵션은 다음과 같다:

    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 (BETA - default=true)
    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)
    CSIMigrationAzureFile=true|false (BETA - default=true)
    CSIMigrationPortworx=true|false (BETA - default=false)
    CSIMigrationRBD=true|false (ALPHA - default=false)
    CSIMigrationvSphere=true|false (BETA - default=true)
    CSINodeExpandSecret=true|false (ALPHA - default=false)
    CSIVolumeHealth=true|false (ALPHA - default=false)
    ContainerCheckpoint=true|false (ALPHA - default=false)
    CronJobTimeZone=true|false (BETA - default=true)
    CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
    CustomResourceValidationExpressions=true|false (BETA - default=true)
    DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
    DevicePlugins=true|false (BETA - default=true)
    DisableCloudProviders=true|false (ALPHA - default=false)
    DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
    DownwardAPIHugePages=true|false (BETA - default=true)
    EndpointSliceTerminatingCondition=true|false (BETA - default=true)
    ExpandedDNSConfig=true|false (ALPHA - default=false)
    ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
    GRPCContainerProbe=true|false (BETA - default=true)
    GracefulNodeShutdown=true|false (BETA - default=true)
    GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
    HPAContainerMetrics=true|false (ALPHA - default=false)
    HPAScaleToZero=true|false (ALPHA - default=false)
    HonorPVReclaimPolicy=true|false (ALPHA - default=false)
    IPTablesOwnershipCleanup=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)
    JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
    JobPodFailurePolicy=true|false (ALPHA - default=false)
    JobReadyPods=true|false (BETA - default=true)
    JobTrackingWithFinalizers=true|false (BETA - default=true)
    KMSv2=true|false (ALPHA - default=false)
    KubeletCredentialProviders=true|false (BETA - default=true)
    KubeletInUserNamespace=true|false (ALPHA - default=false)
    KubeletPodResources=true|false (BETA - default=true)
    KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
    KubeletTracing=true|false (ALPHA - default=false)
    LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (BETA - default=true)
    LogarithmicScaleDown=true|false (BETA - default=true)
    MatchLabelKeysInPodTopologySpread=true|false (ALPHA - default=false)
    MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
    MemoryManager=true|false (BETA - default=true)
    MemoryQoS=true|false (ALPHA - default=false)
    MinDomainsInPodTopologySpread=true|false (BETA - default=false)
    MixedProtocolLBService=true|false (BETA - default=true)
    MultiCIDRRangeAllocator=true|false (ALPHA - default=false)
    NetworkPolicyStatus=true|false (ALPHA - default=false)
    NodeInclusionPolicyInPodTopologySpread=true|false (ALPHA - default=false)
    NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)
    NodeSwap=true|false (ALPHA - default=false)
    OpenAPIEnums=true|false (BETA - default=true)
    OpenAPIV3=true|false (BETA - default=true)
    PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
    PodDeletionCost=true|false (BETA - default=true)
    PodDisruptionConditions=true|false (ALPHA - default=false)
    PodHasNetworkCondition=true|false (ALPHA - default=false)
    ProbeTerminationGracePeriod=true|false (BETA - default=true)
    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)
    RetroactiveDefaultStorageClass=true|false (ALPHA - default=false)
    RotateKubeletServerCertificate=true|false (BETA - default=true)
    SELinuxMountReadWriteOncePod=true|false (ALPHA - default=false)
    SeccompDefault=true|false (BETA - default=true)
    ServerSideFieldValidation=true|false (BETA - default=true)
    ServiceIPStaticSubrange=true|false (BETA - default=true)
    ServiceInternalTrafficPolicy=true|false (BETA - default=true)
    SizeMemoryBackedVolumes=true|false (BETA - default=true)
    StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
    StorageVersionAPI=true|false (ALPHA - default=false)
    StorageVersionHash=true|false (BETA - default=true)
    TopologyAwareHints=true|false (BETA - default=true)
    TopologyManager=true|false (BETA - default=true)
    UserNamespacesStatelessPodsSupport=true|false (ALPHA - default=false)
    VolumeCapacityPriority=true|false (ALPHA - default=false)
    WinDSR=true|false (ALPHA - default=false)
    WinOverlay=true|false (BETA - default=true)
    WindowsHostProcessContainers=true|false (BETA - default=true)

    --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

    @@ -382,7 +382,7 @@ kube-proxy [flags] --proxy-mode ProxyMode -

    사용할 프록시 모드: 'iptables' (리눅스), 'ipvs' (리눅스), 'kernelspace' (윈도우), or 'userspace' (리눅스/윈도우, 지원 중단). 리눅스에서의 기본값은 'iptables'이며, 윈도우에서의 기본값은 'userspace'이다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

    +

    사용할 프록시 모드: 'iptables' (리눅스), 'ipvs' (리눅스), 'kernelspace' (윈도우), 또는 'userspace' (리눅스/윈도우, 지원 중단). 리눅스에서의 기본값은 'iptables'이며, 윈도우에서의 기본값은 'userspace'(추후 'kernelspace'로 변경될 예정)이다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

    diff --git a/content/ko/docs/reference/glossary/cni.md b/content/ko/docs/reference/glossary/cni.md index 28fc3602f3f..9abff8ae8b3 100644 --- a/content/ko/docs/reference/glossary/cni.md +++ b/content/ko/docs/reference/glossary/cni.md @@ -2,7 +2,7 @@ title: 컨테이너 네트워크 인터페이스(Container network interface, CNI) id: cni date: 2018-05-25 -full_link: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni +full_link: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ short_description: > 컨테이너 네트워크 인터페이스(CNI) 플러그인은 appc/CNI 스팩을 따르는 네트워크 플러그인의 일종이다. @@ -11,8 +11,8 @@ aka: tags: - networking --- - 컨테이너 네트워크 인터페이스(CNI) 플러그인은 appc/CNI 스팩을 따르는 네트워크 플러그인의 일종이다. + 컨테이너 네트워크 인터페이스(CNI) 플러그인은 appc/CNI 스펙을 따르는 네트워크 플러그인의 일종이다. + -* 쿠버네티스와 CNI에 대한 정보는 [여기](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)를 참고한다. -* 쿠버네티스와 CNI에 대한 정보는 ["네트워크 플러그인"](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)에서 볼 수 있다. +* 쿠버네티스와 CNI에 대한 정보는 ["네트워크 플러그인"](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)에서 볼 수 있다. diff --git a/content/ko/docs/reference/glossary/code-contributor.md b/content/ko/docs/reference/glossary/code-contributor.md index 7ef546a578b..281b02fb002 100644 --- a/content/ko/docs/reference/glossary/code-contributor.md +++ b/content/ko/docs/reference/glossary/code-contributor.md @@ -2,7 +2,7 @@ title: 코드 컨트리뷰터(Code Contributor) id: code-contributor date: 2018-04-12 -full_link: /ko/docs/community/devel/ +full_link: https://github.com/kubernetes/community/tree/master/contributors/devel short_description: > 쿠버네티스 오픈소스 코드베이스에 코드를 개발하고 기여하는 사람. diff --git a/content/ko/docs/reference/glossary/event.md b/content/ko/docs/reference/glossary/event.md index 78ce256a173..5fa0139ecd7 100644 --- a/content/ko/docs/reference/glossary/event.md +++ b/content/ko/docs/reference/glossary/event.md @@ -21,4 +21,4 @@ tags: 이벤트는 유익(imformative)해야 하고, 최선을 다한(best-effort), 보완적(supplemental) 데이터로 취급되어야 한다. -쿠버네티스에서, [감사(auditing)](/docs/tasks/debug/debug-cluster/audit/)는 다른 종류의 이벤트 레코드를 생성한다. (API 그룹 `audit.k8s.io`). +쿠버네티스에서, [감사(auditing)](/ko/docs/tasks/debug/debug-cluster/audit/)는 다른 종류의 이벤트 레코드를 생성한다. (API 그룹 `audit.k8s.io`). diff --git a/content/ko/docs/reference/glossary/persistent-volume-claim.md b/content/ko/docs/reference/glossary/persistent-volume-claim.md index 122b754d239..beba587ab82 100644 --- a/content/ko/docs/reference/glossary/persistent-volume-claim.md +++ b/content/ko/docs/reference/glossary/persistent-volume-claim.md @@ -2,7 +2,7 @@ title: 퍼시스턴트 볼륨 클레임(Persistent Volume Claim) id: persistent-volume-claim date: 2018-04-12 -full_link: /ko/docs/concepts/storage/persistent-volumes/ +full_link: /ko/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims short_description: > 컨테이너의 볼륨으로 마운트될 수 있도록 퍼시스턴트볼륨(PersistentVolume)에 정의된 스토리지 리소스를 요청한다. diff --git a/content/ko/docs/reference/glossary/pod-security-policy.md b/content/ko/docs/reference/glossary/pod-security-policy.md index 8dd0a09af44..444d9f70f73 100644 --- a/content/ko/docs/reference/glossary/pod-security-policy.md +++ b/content/ko/docs/reference/glossary/pod-security-policy.md @@ -17,4 +17,5 @@ tags: 파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스. `PodSecurityPolicy` 오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다. -파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거될 예정이다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 또는 써드파티 어드미션 플러그인으로 이전(migrate)하는 것을 추천한다. +파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거되었다. +그 대신에 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 또는 써드파티 어드미션 플러그인을 사용한다. diff --git a/content/ko/docs/reference/glossary/sig.md b/content/ko/docs/reference/glossary/sig.md index fbd6a3c86ba..ee24fadecba 100644 --- a/content/ko/docs/reference/glossary/sig.md +++ b/content/ko/docs/reference/glossary/sig.md @@ -2,7 +2,7 @@ title: SIG(special interest group) id: sig date: 2018-04-12 -full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups short_description: > 대규모 쿠버네티스 오픈소스 프로젝트에서 진행되는 내용을 공동으로 관리하는 커뮤니티 멤버들이다. diff --git a/content/ko/docs/reference/issues-security/issues.md b/content/ko/docs/reference/issues-security/issues.md index 6fa7fd03e2b..dac24d11cb2 100644 --- a/content/ko/docs/reference/issues-security/issues.md +++ b/content/ko/docs/reference/issues-security/issues.md @@ -7,6 +7,9 @@ weight: 10 쿠버네티스 코드 작업 및 공개 이슈는 [깃허브 이슈](https://github.com/kubernetes/kubernetes/issues/)를 사용하여 추적된다. -* [CVE-연관된 이슈들](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) +* [잘 알려진 CVE에 대한] 공식 리스트(/docs/reference/issues-security/official-cve-feed/) + [보안 대응 위원회(Security Response Committee)](https://github.com/kubernetes/committee-security-response) + 가 발표한 (보안 취약점) +* [CVE-연관된 깃허브 이슈들](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE) -보안에 관련된 공지사항은 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 메일 리스트로 전송된다. +보안에 관련된 공지사항은 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 메일 리스트로 전송된다. \ No newline at end of file diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index f5393b5963d..d328b8fbd01 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -439,8 +439,8 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image' # `default` 네임스페이스의 모든 이미지를 파드별로 그룹지어 출력 kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image" - # "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지 -kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image' + # "registry.k8s.io/coredns:1.6.2" 를 제외한 모든 이미지 +kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry.k8s.io/coredns:1.6.2")].image' # 이름에 관계없이 메타데이터 아래의 모든 필드 kubectl get pods -A -o=custom-columns='DATA:metadata.*' diff --git a/content/ko/docs/reference/labels-annotations-taints/_index.md b/content/ko/docs/reference/labels-annotations-taints/_index.md index dd273fd349a..fd517c8fab2 100644 --- a/content/ko/docs/reference/labels-annotations-taints/_index.md +++ b/content/ko/docs/reference/labels-annotations-taints/_index.md @@ -7,7 +7,7 @@ weight: 20 -쿠버네티스는 모든 레이블과 어노테이션을 `kubernetes.io` 네임스페이스 아래에 정의해 놓았다. +쿠버네티스는 모든 레이블과 어노테이션을 `kubernetes.io`와 `k8s.io` 네임스페이스 아래에 정의해 놓았다. 이 문서는 각 값에 대한 레퍼런스를 제공하며, 값을 할당하기 위한 협력 포인트도 제공한다. @@ -25,7 +25,7 @@ weight: 20 [추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. -### app.kubernetes.io/created-by +### app.kubernetes.io/created-by (사용 중단됨) 예시: `app.kubernetes.io/created-by: "controller-manager"` @@ -33,7 +33,9 @@ weight: 20 리소스를 생성한 컨트롤러/사용자. -[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. +{{< note >}} +v1.9부터 이 레이블은 더 이상 사용되지 않는다. +{{< /note >}} ### app.kubernetes.io/instance @@ -85,6 +87,18 @@ weight: 20 [추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. +### cluster-autoscaler.kubernetes.io/safe-to-evict + +예시: `cluster-autoscaler.kubernetes.io/safe-to-evict: "true"` + +적용 대상: 파드 + +이 어노테이션이 `"true"`로 설정된 경우, 파드 축출을 막는 다른 규칙이 있는 경우에도 +클러스터 오토스케일러가 파드를 축출할 수 있다. +클러스터 오토스케일러는 명시적으로 이 어노테이션이 `"false"`로 설정된 파드를 절대 축출하지 않는다. +따라서, 계속해서 실행을 유지하고자 하는 중요한 파드에 설정할 수 있다. +이 어노테이션이 설정되지 않은 경우, 클러스터 오토스케일러는 파드 수준(Pod-level) 동작을 따른다. + ## kubernetes.io/arch 예시: `kubernetes.io/arch=amd64` @@ -168,6 +182,23 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k 이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을 설정하기 위해 사용한다. 명시된 값은 `int32` 타입으로 파싱된다. +### cluster-autoscaler.kubernetes.io/enable-ds-eviction + +예시: `cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"` + +적용 대상: Pod + +이 어노테이션은 클러스터 오토스케일러가 데몬셋 파드를 축출할 것인지 여부를 제어한다. +이 어노테이션은 데몬셋 매니페스트 내 데몬셋 파드에 명시되어야 한다. +이 어노테이션이 `"true"`로 설정된 경우, 파드 축출을 막는 다른 규칙이 있는 경우에도 +클러스터 오토스케일러가 파드를 축출할 수 있다. 클러스터 오토스케일러가 데몬셋 파드를 축출하는 것을 허용하지 않기 위해서는, +중요한 데몬셋 파드에 이 어노테이션을 `"false"`로 설정한다. +이 어노테이션이 설정되지 않은 경우, 클러스터 오토스케일러는 전체 동작을 따른다. 즉, 해당 구성에 따라서 데몬셋을 축출한다. + +{{< note >}} +이 어노테이션은 데몬셋 파드에만 적용된다. +{{< /note >}} + ### kubernetes.io/ingress-bandwidth {{< note >}} @@ -420,7 +451,7 @@ v1.18부터, `spec.ingressClassName`으로 대체되었다. kubelet이 노드에 할당된 IPv4 주소를 명시하기 위해 이 어노테이션을 사용할 수 있다. -kubelet이 "외부" 클라우드 제공자에 의해 실행되었다면, 명령줄 플래그(`--node-ip`)를 통해 설정된 IP 주소를 명시하기 위해 kubelet이 이 어노테이션을 노드에 설정한다. cloud-controller-manager는 클라우드 제공자에게 이 IP 주소가 유효한지를 검증한다. +kubelet이 `--cloud-provider` 플래그를 사용하여 어떤 값을 갖게 되었다면 (외부 또는 레거시 트리 내(in-tree) 클라우드 공급자 모두 포함), kubelet은 이 어노테이션을 노드에 설정하여 명령줄 플래그(`--node-ip`)를 통해 설정된 IP 주소를 명시한다. cloud-controller-manager는 클라우드 제공자에게 이 IP 주소가 유효한지를 검증한다. ## batch.kubernetes.io/job-completion-index @@ -622,15 +653,19 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 예시: `kubernetes.io/psp: restricted` -이 어노테이션은 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/)를 사용하는 경우에만 관련있다. +적용 대상: 파드 -파드시큐리티폴리시 어드미션 컨트롤러가 파드를 승인하면, -어드미션 컨트롤러는 파드가 이 어노테이션을 갖도록 수정한다. -이 어노테이션 값은 유효성 검사에서 사용된 파드시큐리티폴리시의 이름이다. +이 어노테이션은 파드시큐리티폴리시(PodSecurityPolicy)[PodSecurityPolicies](/ko/docs/concepts/security/pod-security-policy/)를 사용하는 경우에만 관련이 있다. +쿠버네티스 v{{< skew currentVersion >}}은 파드시큐리티폴리시 API를 지원하지 않는다. + +파드시큐리티폴리시 어드미션 컨트롤러가 파드를 승인했을 때, +어드미션 컨트롤러는 파드가 이 어노테이션을 갖도록 수정했다. +이 어노테이션 값은 유효성 검사에서 사용된 파드시큐리티폴리시의 이름이었다. ## seccomp.security.alpha.kubernetes.io/pod (사용 중단됨) {#seccomp-security-alpha-kubernetes-io-pod} -이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. +이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 향후 릴리스에서는 작동하지 않을 것이다. +대신 해당 파드 또는 컨테이너의 `securityContext.seccompProfile` 필드를 사용한다. 파드의 보안 설정을 지정하려면, 파드 스펙에 `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)하면, @@ -638,7 +673,8 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 ## container.seccomp.security.alpha.kubernetes.io/[이름] {#container-seccomp-security-alpha-kubernetes-io} -이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다. +이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 향후 릴리스에서는 작동하지 않을 것이다. +대신 해당 파드 또는 컨테이너의 `securityContext.seccompProfile` 필드를 사용한다. [seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/security/seccomp/) 튜토리얼에서 seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다. 튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며, @@ -655,7 +691,7 @@ seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 볼륨스냅샷(VolumeSnapshot)으로부터 생성될 경우, 사용자가 소스 볼륨의 모드를 수정할 수 있는지 여부를 결정한다. -자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/ko/docs/concepts/storage/volume-snapshots/#convert-volume-mode)와 +자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/ko/docs/concepts/storage/volume-snapshots/#convert-volume-mode)와 [쿠버네티스 CSI 개발자용 문서](https://kubernetes-csi.github.io/docs/)를 참조한다. ## Audit을 위한 어노테이션들 @@ -723,14 +759,3 @@ kubeadm이 관리하는 컨트롤 플레인 노드에 적용되는 레이블. 적용 대상: 노드 중요한 워크로드만 스케줄링할 수 있도록 컨트롤 플레인 노드에 적용시키는 테인트. - -### node-role.kubernetes.io/master - -예시: `node-role.kubernetes.io/master:NoSchedule` - -적용 대상: 노드 - -중요한 워크로드만 스케줄링할 수 있도록 컨트롤 플레인 노드에 적용시키는 테인트. - -{{< note >}} 버전 v1.20 부터, 이 테인트는 `node-role.kubernetes.io/control-plane`의 등장으로 더 이상 사용되지 않으며, -버전 v1.25에서 삭제될 예정이다.{{< /note >}} diff --git a/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md b/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md index eb0dc3f845b..3ed3b7cfceb 100644 --- a/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md +++ b/content/ko/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes.md @@ -12,13 +12,15 @@ content_type: reference ## 쿠버네티스 프로젝트 -* 쿠버네티스 블로그: [도커심 제거 FAQ](/blog/2022/02/17/dockershim-faq/) (originally published 2022/02/17) +* 쿠버네티스 블로그: [도커심 제거 FAQ](/blog/2020/12/02/dockershim-faq/) (originally published 2020/12/02) + +* 쿠버네티스 블로그: [업데이트: 도커심 제거 FAQ](/blog/2022/02/17/dockershim-faq/) (updated published 2022/02/17) * 쿠버네티스 블로그: [도커심에서 움직이는 쿠버네티스: 약속과 다음 단계](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/) (published 2022/01/07) * 쿠버네티스 블로그: [도커심 제거가 다가오고 있다. 준비됐는가?](/blog/2021/11/12/are-you-ready-for-dockershim-removal/) (published 2021/11/12) -* 쿠버네티스 문서: [도커심에서 마이그레이션하기](/docs/tasks/administer-cluster/migrating-from-dockershim/) +* 쿠버네티스 문서: [도커심에서 마이그레이션하기](/ko/docs/tasks/administer-cluster/migrating-from-dockershim/) * 쿠버네티스 문서: [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/) @@ -27,24 +29,24 @@ content_type: reference * 쿠버네티스 개선 제안 이슈: [kubelet에서 도커심 제거하기](https://github.com/kubernetes/enhancements/issues/2221) (_k/enhancements#2221_) -GitHub 이슈를 통해 피드백을 제공할 수 있다. [**도커심 제거 피드백 및 이슈**](https://github.com/kubernetes/kubernetes/issues/106917). +GitHub 이슈를 통해 피드백을 제공할 수 있다. [**도커심 제거 피드백 및 이슈**](https://github.com/kubernetes/kubernetes/issues/106917). (_k/kubernetes/#106917_) ## 외부 소스 {#third-party} -* 아마존 웹 서비스 EKS 문서: [Dockershim deprecation](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html) +* 아마존 웹 서비스 EKS 문서: [아마존 EKS 도커심 지원 종료](https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html) -* CNCF 컨퍼런스 영상: [Lessons Learned Migrating Kubernetes from Docker to containerd Runtime](https://www.youtube.com/watch?v=uDOu6rK4yOk) (Ana Caylin, at KubeCon Europe 2019) +* CNCF 컨퍼런스 영상: [도커에서 containerd 런타임으로 마이그레이션하며 얻은 교훈](https://www.youtube.com/watch?v=uDOu6rK4yOk) (Ana Caylin, at KubeCon Europe 2019) -* 도커닷컴 블로그: [What developers need to know about Docker, Docker Engine, and Kubernetes v1.20](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/) (published 2020/12/04) +* 도커닷컴 블로그: [개발자가 도커, 도커 엔진 및 쿠버네티스 v1.20에 관해 알아야 할 사항](https://www.docker.com/blog/what-developers-need-to-know-about-docker-docker-engine-and-kubernetes-v1-20/) (published 2020/12/04) -* "_구글 오픈소스_" 유튜브 채널: [Learn Kubernetes with Google - Migrating from Dockershim to Containerd](https://youtu.be/fl7_4hjT52g) +* "_구글 오픈소스_" 유튜브 채널: [구글과 함께 쿠버네티스 배우기 - 도커심에서 containerd로 마이그레이션하기](https://youtu.be/fl7_4hjT52g) -* Azure의 Microsoft 앱 블로그: [Dockershim deprecation and AKS](https://techcommunity.microsoft.com/t5/apps-on-azure-blog/dockershim-deprecation-and-aks/ba-p/3055902) (published 2022/01/21) +* Azure의 Microsoft 앱 블로그: [도커심 지원 중단 및 AKS](https://techcommunity.microsoft.com/t5/apps-on-azure-blog/dockershim-deprecation-and-aks/ba-p/3055902) (published 2022/01/21) -* Mirantis 블로그: [The Future of Dockershim is cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/) (published 2021/04/21) +* Mirantis 블로그: [도커심의 미래는 cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/) (published 2021/04/21) -* Mirantis: [Mirantis/cri-dockerd](https://github.com/Mirantis/cri-dockerd) Git repository (on GitHub) +* Mirantis: [Mirantis/cri-dockerd](https://github.com/Mirantis/cri-dockerd) Git 리포지터리 (깃허브) -* Tripwire: [How Dockershim’s Forthcoming Deprecation Affects Your Kubernetes](https://www.tripwire.com/state-of-security/security-data-protection/cloud/how-dockershim-forthcoming-deprecation-affects-your-kubernetes/) +* Tripwire: [곧 다가올 도커심의 지원 중단이 당신의 쿠버네티스에 미칠 영향](https://www.tripwire.com/state-of-security/security-data-protection/cloud/how-dockershim-forthcoming-deprecation-affects-your-kubernetes/) (published 2021/07/01) diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index 633df3c6baf..9a3aa1b13a4 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -4,7 +4,7 @@ content_type: concept weight: 20 --- -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.25" state="stable" >}} 구성 파일을 작성하고 해당 경로를 커맨드 라인 인수로 전달하여 `kube-scheduler` 의 동작을 사용자 정의할 수 있다. @@ -18,8 +18,8 @@ weight: 20 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. -KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/) -또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/)) +KubeSchedulerConfiguration ([v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/) +또는 [v1](/docs/reference/config-api/kube-scheduler-config.v1/)) 구조에 맞게 파일을 작성하고, `kube-scheduler --config `을 실행하여 스케줄링 프로파일을 지정할 수 있다. @@ -27,12 +27,18 @@ KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler- 최소 구성은 다음과 같다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta2 +apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig ``` + {{< note >}} + KubeSchedulerConfiguration [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)는 + v1.25부터 사용 중단되었고 v1.26부터 제거된다. KubeSchedulerConfiguration을 + [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 또는 [v1](/docs/reference/config-api/kube-scheduler-config.v1/)로 전환한 뒤에 + 쿠버네티스를 v1.25로 업그레이드하도록 한다. + {{< /note >}} ## 프로파일 스케줄링 프로파일을 사용하면 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}에서 @@ -85,7 +91,7 @@ clientConnection: 자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta2 +apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - plugins: @@ -172,11 +178,6 @@ profiles: 기본으로 활성화되지 않는 다음의 플러그인을 컴포넌트 구성 API를 통해 활성화할 수도 있다. -- `SelectorSpread`: {{< glossary_tooltip text="Services" term_id="service" >}}, - {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}와 - {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}에 속하는 파드의 경우, - 노드간에 퍼지는 것을 선호한다. - 익스텐션 포인트: `preScore`, `score`. - `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/) 볼륨 제한이 충족될 수 있는지 확인한다. 익스텐션 포인트: `filter`. @@ -192,7 +193,7 @@ profiles: 실행된다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta2 +apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler @@ -241,7 +242,7 @@ profiles: 다음과 같은 프로파일 환경 설정을 사용한다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta3 +apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler @@ -255,7 +256,7 @@ profiles: 동일한 효과를 갖는다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta3 +apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: non-multipoint-scheduler @@ -284,7 +285,7 @@ profiles: 다음은 `Score` 와 `PreScore` 에 대해 비활성화하는 예시이다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta3 +apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: non-multipoint-scheduler @@ -300,14 +301,15 @@ profiles: - name: '*' ``` -`v1beta3` 에서, `MultiPoint` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다. +`kubescheduler.config.k8s.io/v1beta3` 부터, `MultiPoint` 필드를 통해 +내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다. 그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다. 예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고 각각의 가중치가 `1` 이라고 하자. 이 때, 다음과 같이 가중치를 다르게 설정하여 순서를 바꿀 수 있다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta3 +apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler @@ -342,7 +344,7 @@ profiles: 이들 플러그인에 대한 유효한 예시 환경 설정은 다음과 같다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta3 +apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler @@ -451,6 +453,11 @@ profiles: * `NodeAffinity`: 1 에서 2 로 * `TaintToleration`: 1 에서 3 으로 {{% /tab %}} + +{{% tab name="v1beta3 → v1" %}} +* 스케줄러 플러그인 `SelectorSpread`는 제거되었다. 대신, 비슷한 효과를 얻기 위해 +`PodTopologySpread` 플러그인(기본적으로 활성화되어 있음)을 사용한다. +{{% /tab %}} {{< /tabs >}} ## {{% heading "whatsnext" %}} @@ -459,3 +466,4 @@ profiles: * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 * [kube-scheduler 설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기 * [kube-scheduler 설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽어보기 +* [kube-scheduler 설정 (v1)](/docs/reference/config-api/kube-scheduler-config.v1/) 레퍼런스 읽어보기 \ No newline at end of file diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md index 8be0974edea..47518285ed7 100644 --- a/content/ko/docs/reference/scheduling/policies.md +++ b/content/ko/docs/reference/scheduling/policies.md @@ -16,4 +16,4 @@ sitemap: * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기 * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기 -* [kube-scheduler configuration 레퍼런스 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3) 읽어보기 +* [kube-scheduler configuration 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-config.v1/) 읽어보기 diff --git a/content/ko/docs/setup/best-practices/node-conformance.md b/content/ko/docs/setup/best-practices/node-conformance.md index aa9a71a7071..abfe0524944 100644 --- a/content/ko/docs/setup/best-practices/node-conformance.md +++ b/content/ko/docs/setup/best-practices/node-conformance.md @@ -40,7 +40,7 @@ weight: 30 # $LOG_DIR는 테스트 출력 경로이다. sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ - k8s.gcr.io/node-test:0.2 + registry.k8s.io/node-test:0.2 ``` ## 다른 아키텍처에서 노드 적합성 테스트 실행 @@ -61,7 +61,7 @@ sudo docker run -it --rm --privileged --net=host \ sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e FOCUS=MirrorPod \ # MirrorPod 테스트만 실행 - k8s.gcr.io/node-test:0.2 + registry.k8s.io/node-test:0.2 ``` 특정 테스트를 건너뛰기 위해서는, 환경 변수 `SKIP`에 건너뛰고자 하는 테스트를 정규식으로 지정한다. @@ -70,7 +70,7 @@ sudo docker run -it --rm --privileged --net=host \ sudo docker run -it --rm --privileged --net=host \ -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ -e SKIP=MirrorPod \ # MirrorPod 테스트만 건너뛰고 모든 적합성 테스트를 실행한다 - k8s.gcr.io/node-test:0.2 + registry.k8s.io/node-test:0.2 ``` 노드 적합성 테스트는 [노드 e2e 테스트](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md)를 컨테이너화한 버전이다. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index eda9c1f8f63..d05c52a065c 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -31,14 +31,14 @@ weight: 20 {{< note >}} 쿠버네티스 v1.24 이전 릴리스는 -_dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 통합을 지원했다. +_도커심_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 통합을 지원했다. 이 특별한 직접 통합은 더 이상 쿠버네티스에 포함되지 않는다(이 제거는 v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다). 이 제거가 어떻게 영향을 미치는지 알아보려면 -[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. -dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면, -[dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다. +[도커심 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. +도커심을 사용하던 환경에서 이전(migrating)하는 방법을 보려면, +[도커심에서 이전하기](/ko/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다. v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 있다면, 해당 버전의 문서를 참고한다. @@ -87,22 +87,67 @@ sudo sysctl --system 리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은 프로세스에 할당된 리소스를 제한하는데 사용된다. +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}과 +그에 연계된 컨테이너 런타임 모두 컨트롤 그룹(control group)들과 상호작용 해야 하는데, 이는 +[파드 및 컨테이너 자원 관리](/ko/docs/concepts/configuration/manage-resources-containers/)가 수정될 수 있도록 하고 +cpu 혹은 메모리와 같은 자원의 요청(request)과 상한(limit)을 설정하기 위함이다. 컨트롤 +그룹과 상호작용하기 위해서는, kubelet과 컨테이너 런타임이 *cgroup 드라이버*를 사용해야 한다. +매우 중요한 점은, kubelet과 컨테이너 런타임이 같은 cgroup +group 드라이버를 사용해야 하며 구성도 동일해야 한다는 것이다. + +두 가지의 cgroup 드라이버가 이용 가능하다. + +* [`cgroupfs`](#cgroupfs-cgroup-driver) +* [`systemd`](#systemd-cgroup-driver) + +### cgroupfs 드라이버 {#cgroupfs-cgroup-driver} + +`cgroupfs` 드라이버는 kubelet의 기본 cgroup 드라이버이다. `cgroupfs` +드라이버가 사용될 때, kubelet과 컨테이너 런타임은 직접적으로 +cgroup 파일시스템과 상호작용하여 cgroup들을 설정한다. + +`cgroupfs` 드라이버가 권장되지 **않는** 때가 있는데, +[systemd](https://www.freedesktop.org/wiki/Software/systemd/)가 +init 시스템인 경우이다. 이것은 systemd가 시스템에 단 하나의 cgroup 관리자만 있을 것으로 기대하기 때문이다. +또한, [cgroup v2](/docs/concepts/architecture/cgroups)를 사용할 경우에도 +`cgroupfs` 대신 `systemd` cgroup 드라이버를 +사용한다. + +### systemd cgroup 드라이버 {#systemd-cgroup-driver} + 리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인 경우, init 프로세스는 root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. -Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. -컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. systemd와 함께 -`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다. -단일 cgroup 관리자는 할당되는 리소스가 무엇인지를 단순화하고, -기본적으로 사용할 수 있는 리소스와 사용 중인 리소스를 일관성있게 볼 수 있다. -시스템에 두 개의 cgroup 관리자가 있으면, 이런 리소스도 두 개의 관점에서 보게 된다. -현장에서 사람들은 kubelet과 도커에 `cgroupfs`를 사용하고, -나머지 프로세스는 `systemd`를 사용하도록 노드가 설정된 경우, 리소스가 부족할 때 -불안정해지는 사례를 보고했다. +systemd는 cgroup과 긴밀하게 통합되어 있으며 매 systemd 단위로 cgroup을 +할당한다. 결과적으로, `systemd`를 init 시스템으로 사용하고 `cgroupfs` +드라이버를 사용하면, 그 시스템은 두 개의 다른 cgroup 관리자를 갖게 된다. -컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면 -시스템이 안정화된다. 도커에 대해 구성하려면, `native.cgroupdriver=systemd`를 설정한다. +두 개의 cgroup 관리자는 시스템 상 사용 가능한 자원과 사용 중인 자원들에 대하여 두 가지 관점을 가져 혼동을 +초래한다. 예를 들어, kubelet과 컨테이너 런타임은 `cgroupfs`를 사용하고 +나머지 프로세스는 `systemd`를 사용하도록 노드를 구성한 경우, 노드가 +자원 압박으로 인해 불안정해질 수 있다. + +이러한 불안정성을 줄이는 방법은, `systemd`가 init 시스템으로 선택되었을 때에는 `systemd`를 +kubelet과 컨테이너 런타임의 cgroup 드라이버로 사용하는 것이다. + +`systemd`를 cgroup 드라이버로 사용하기 위해서는, +[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/)를 수정하여 +`cgroupDriver` 옵션을 `systemd`로 지정하는 것이다. 예를 들면 다음과 같다. + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +... +cgroupDriver: systemd +``` + +`systemd`를 kubelet의 cgroup 드라이버로 구성했다면, 반드시 +컨테이너 런타임의 cgroup 드라이버 또한 `systemd`로 설정해야 한다. 자세한 설명은 +컨테이너 런타임 대한 문서를 참조한다. 예를 들면 다음과 같다. + +* [containerd](#containerd-systemd) +* [CRI-O](#cri-o) {{< caution >}} 클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 신중하게 수행해야 한다. @@ -114,41 +159,6 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. 교체하거나, 자동화를 사용하여 다시 설치한다. {{< /caution >}} -### Cgroup 버전 2 {#cgroup-v2} - -cgroup v2는 cgroup Linux API의 다음 버전이다. -cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다. - -새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다. - -- API를 더 쉽고 깔끔하게 사용할 수 있음 -- 컨테이너로의 안전한 하위 트리 위임 -- 압력 중지 정보와 같은 새로운 기능 - -일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도, -쿠버네티스는 모든 컨트롤러를 관리하기 위해 -동일한 cgroup 버전만 지원한다. - -systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을 -추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다. - -```shell -# 이 예제는 리눅스 OS에서 DNF 패키지 관리자를 사용하는 경우에 대한 것이다. -# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해 -# 사용자의 시스템이 다른 방법을 사용하고 있을 수도 있다. -sudo dnf install -y grubby && \ - sudo grubby \ - --update-kernel=ALL \ - --args="systemd.unified_cgroup_hierarchy=1" -``` - -커널이 사용하는 커맨드 라인을 업데이트하려면, -변경 사항을 적용하기 위해 노드를 재시작해야 한다. - -cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서 -cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다. - -cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다. ### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기 @@ -197,6 +207,9 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true ``` + +[cgroup v2](/docs/concepts/architecture/cgroups)을 사용할 경우 `systemd` cgroup 드라이버가 권장된다. + {{< note >}} 만약 containerd를 패키지(RPM, `.deb` 등)를 통해 설치하였다면, CRI integration 플러그인은 기본적으로 비활성화되어 있다. @@ -222,7 +235,7 @@ kubeadm을 사용하는 경우, ```toml [plugins."io.containerd.grpc.v1.cri"] - sandbox_image = "k8s.gcr.io/pause:3.2" + sandbox_image = "registry.k8s.io/pause:3.2" ``` 설정 파일을 변경하는 경우 역시 `systemctl restart containerd`를 통해 `containerd`를 재시작해야 한다. @@ -282,12 +295,6 @@ live configuration reload 기능을 지원한다. `cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다. -#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd} - -`cri-dockerd` 어댑터는, -파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다. -해당 커맨드라인 인자는 `--pod-infra-container-image`이다. - ### 미란티스 컨테이너 런타임 {#mcr} [미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며 diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index a8f284548e4..83e6ce9a7c8 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -134,13 +134,13 @@ etcd: election-timeout: 1000 ``` -## 패치를 통해 컨트롤 플레인 사용자 정의하기 {#patches} +## 패치를 통해 사용자 정의하기 {#patches} {{< feature-state for_k8s_version="v1.22" state="beta" >}} Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에 대한 `InitConfiguration`과 `JoinConfiguration`에 -전달할 수 있다. 이 패치는 컨트롤 플레인 컴포넌트 메니패스트가 디스크에 기록되기 전에 -최종 사용자 정의 단계로 사용될 수 있다. +전달할 수 있다. 이 패치는 컴포넌트 구성이 디스크에 기록되기 전에 최종 사용자 정의 단계로 +사용될 수 있다. `--config `을 사용하여 이 파일을 `kubeadm init`에 전달할 수 있다. @@ -168,7 +168,8 @@ kind: JoinConfiguration 디렉토리는 `target[suffix][+patchtype].extension` 형태의 파일을 포함해야 한다. 예를 들면, `kube-apiserver0+merge.yaml` 또는 단순히 `etcd.json`의 형태이다. -- `target`은 `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` 그리고 `etcd` 중 하나가 될 수 있다. +- `target`은 `kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `etcd` +그리고 `kubeletconfiguration` 중 하나가 될 수 있다. - `patchtype`은 `strategic`, `merge` 그리고 `json` 중 하나가 될 수 있으며 [kubectl에서 지원하는](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch) 패치 형식을 준수해야 한다. `patchtype`의 기본값은 `strategic`이다. @@ -183,20 +184,22 @@ kind: JoinConfiguration API 구조를 현재는 지원하지 않는다. {{< /note >}} -## kubelet 사용자 정의하기 +## kubelet 사용자 정의하기 {#kubelet} -kubelet을 사용자 정의하려면, `KubeletConfiguration`을 동일한 구성 파일 내에서 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration` 다음에 추가하면 -된다. 그런 다음 `kubeadm init`에 해당 파일을 전달한다. +kubelet을 사용자 정의하려면, [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)을 +동일한 구성 파일 내에서 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration` 다음에 추가하면 된다. +그런 다음 `kubeadm init`에 해당 파일을 전달하면, kubeadm은 동일한 기본 `KubeletConfiguration`을 +클러스터의 모든 노드에 적용한다. -{{< note >}} -kubeadm은 클러스터의 모든 노드에 동일한 `KubeletConfiguration`을 적용한다. 노드별 설정을 -적용하려면 kubelet 플래그를 덮어쓰기(overrides)로 사용하여, `InitConfiguration` 및 -`JoinConfiguration` 모두에서 지원되는 `nodeRegistration.kubeletExtraArgs`에 전달할 수 있다. -일부 kubelet 플래그는 더 이상 사용되지 않는다(deprecated). 따라서 사용하기 전에 [kubelet 참조 문서](/docs/reference/command-line-tools-reference/kubelet)를 통해 -상태를 확인해야 한다. -{{< /note >}} +기본 `KubeletConfiguration`에 더하여 인스턴스별 구성을 적용하기 위해서는 +[`kubeletconfiguration` 패치 target](#patches)을 이용할 수 있다. -자세한 사항은 [kubeadm을 통해 클러스터의 각 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)에서 살펴본다. +다른 방법으로는, kubelet 플래그를 덮어쓰기(overrides)로 사용하여, +`InitConfiguration` 및 `JoinConfiguration` 모두에서 지원되는 `nodeRegistration.kubeletExtraArgs`에 전달할 수 있다. +일부 kubelet 플래그는 더 이상 사용되지 않는다(deprecated). 따라서 사용하기 전에 +[kubelet 참조 문서](/docs/reference/command-line-tools-reference/kubelet)를 통해 상태를 확인해야 한다. + +이 외 더 자세한 사항은 [kubeadm을 통해 클러스터의 각 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)에서 살펴본다. ## kube-proxy 사용자 정의하기 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 9697ec82ac1..448b25b0ff4 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 @@ -12,7 +12,7 @@ card: 이 페이지에서는 `kubeadm` 툴박스 설치 방법을 보여준다. -이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm 으로 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다. +이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm으로 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다. ## {{% heading "prerequisites" %}} @@ -212,28 +212,29 @@ sudo systemctl enable --now kubelet CNI 플러그인 설치(대부분의 파드 네트워크에 필요) ```bash -CNI_VERSION="v0.8.2" +CNI_PLUGINS_VERSION="v1.1.1" ARCH="amd64" -sudo mkdir -p /opt/cni/bin -curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz +DEST="/opt/cni/bin" +sudo mkdir -p "$DEST" +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGINS_VERSION}/cni-plugins-linux-${ARCH}-${CNI_PLUGINS_VERSION}.tgz" | sudo tar -C "$DEST" -xz ``` 명령어 파일을 다운로드할 디렉터리 정의 {{< note >}} `DOWNLOAD_DIR` 변수는 쓰기 가능한 디렉터리로 설정되어야 한다. -Flatcar Container Linux를 실행 중인 경우, `DOWNLOAD_DIR=/opt/bin` 을 설정한다. +Flatcar Container Linux를 실행 중인 경우, `DOWNLOAD_DIR="/opt/bin"` 을 설정한다. {{< /note >}} ```bash -DOWNLOAD_DIR=/usr/local/bin -sudo mkdir -p $DOWNLOAD_DIR +DOWNLOAD_DIR="/usr/local/bin" +sudo mkdir -p "$DOWNLOAD_DIR" ``` crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 필요) ```bash -CRICTL_VERSION="v1.22.0" +CRICTL_VERSION="v1.25.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/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index c228a1d9375..5827925e828 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -37,7 +37,7 @@ card: 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다. ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml ``` ## 대시보드 UI 접근 diff --git a/content/ko/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/ko/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md new file mode 100644 index 00000000000..cbbf6acdc03 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md @@ -0,0 +1,45 @@ +--- +title: "도커심으로부터 마이그레이션" +weight: 10 +content_type: task +no_list: true +--- + + + +이 섹션은 도커심에서 다른 컨테이너 런타임으로 +마이그레이션할 때에 알아야 할 정보를 제공한다. + +쿠버네티스 1.20에서의 [도커심 사용 중단(deprecation)](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) 발표 이후, +이것이 다양한 워크로드와 쿠버네티스 설치에 +어떻게 영향을 미칠지에 대한 질문이 많았다. [도커심 제거 FAQ](/blog/2022/02/17/dockershim-faq/)는 +관련된 문제를 더 잘 이해할 수 있도록 도움을 준다. + +도커심은 쿠버네티스 릴리스 v1.24부터 제거되었다. +컨테이너 런타임으로 도커 엔진을 통한 도커심을 사용하는 상황에서 v1.24로 +업그레이드하려는 경우, 다른 런타임으로 마이그레이션하거나 다른 방법을 찾아 도커 엔진 지원을 받는 것이 좋다. +선택 가능한 옵션은 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/) 섹션에서 확인한다. +마이그레이션 중 문제를 마주한다면 +[문제를 보고](https://github.com/kubernetes/kubernetes/issues)하면 좋다. 이를 통해 문제를 시기적절하게 +해결할 수 있으며, 클러스터도 도커심 제거에 +대비할 수 있다. + +클러스터는 두 종류 이상의 노드들을 포함할 수 있지만 +이는 일반적인 구성은 아니다. + +다음 작업을 통해 마이그레이션을 수행할 수 있다. + +- [도커심 제거가 당신에게 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) +- [도커 엔진 노드를 도커심에서 cri-dockerd로 마이그레이션하기](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) +- [도커심으로부터 보안 및 텔레메트리 에이전트 마이그레이션하기](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) + +## {{% heading "whatsnext" %}} + +- 컨테이너 런타임에 대한 옵션을 이해하기 위해 + [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 확인한다. +* 도커심의 + 사용 중단 및 제거에 대한 논의를 추적하는 + [깃허브 이슈](https://github.com/kubernetes/kubernetes/issues/106917)가 있다. +* 도커심에서 마이그레이션하는 것에 관한 + 결함이나 다른 기술적 문제를 발견한다면, + 쿠버네티스 프로젝트에 [이슈를 남길 수 있다.](https://github.com/kubernetes/kubernetes/issues/new/choose) \ No newline at end of file diff --git a/content/ko/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd.md b/content/ko/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd.md new file mode 100644 index 00000000000..78a8458306e --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd.md @@ -0,0 +1,121 @@ +--- +title: "도커 엔진 노드를 도커심에서 cri-dockerd로 마이그레이션하기" +weight: 9 +content_type: task +--- + +{{% thirdparty-content %}} + +이 페이지는 도커 엔진 노드가 도커심 대신 `cri-dockerd`를 사용하도록 마이그레이션하는 방법을 보여 준다. +다음 시나리오에서는 아래 단계를 따라야 한다. + + * 도커심 사용은 중단하고 싶지만, + 쿠버네티스의 컨테이너 실행에는 여전히 도커 엔진을 사용하기를 원하는 경우 + * 쿠버네티스 버전 v{{< skew currentVersion >}}로 업그레이드를 원하고 + 기존 클러스터가 도커심을 사용하는 경우. + 이러한 경우에는 도커심을 다른 것으로 대체해야 하며 `cri-dockerd`도 선택지 중 하나이다. + +도커심 제거에 관하여 더 배우려면, [FAQ page](/dockershim)를 읽어보자. + +## cri-dockerd란 무엇인가? {#what-is-cri-dockerd} + +쿠버네티스 1.23 이하에서는 _도커심_ 이라는 이름의 쿠버네티스 내장 구성요소를 사용하여 +도커 엔진을 쿠버네티스 컨테이너 런타임으로 사용할 수 있었다. +도커심 구성 요소는 쿠버네티스 1.24 릴리스에서 제거되었지만, +대신 서드 파티 대체제 `cri-dockerd`를 사용할 수 있다. +`cri-dockerd` 어댑터를 사용하면 {{}}를 통해 도커 엔진을 사용할 수 있다. + +{{}} +이미 `cri-dockerd`를 사용한다면, 도커심 제거에 의한 영향은 받지 않는다. +시작하기 전에, [노드가 도커심을 사용하는지 확인](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)하자. +{{}} + +컨테이너 런타임으로 도커 엔진을 계속 사용할 수 있도록 +`cri-dockerd`로 마이그레이션하려는 경우 +영향을 받는 각각의 노드에 아래 내용을 진행해야 한다. + +1. `cri-dockerd`를 설치한다. +1. 노드를 통제(cordon)하고 비운다(drain). +1. `cri-dockerd`를 사용하도록 kubelet를 설정한다. +1. kubelet을 재시작한다. +1. 노드가 정상(healthy)인지 확인한다. + +중요하지 않은(non-critical) 노드에서 먼저 테스트한다. + +`cri-dockerd`로 마이그레이션하려는 각 노드에 대해 +아래 단계를 수행해야 한다. + +## {{% heading "prerequisites" %}} + +* [`cri-dockerd`](https://github.com/mirantis/cri-dockerd#build-and-install)를 + 각 노드에 설치하고 시작한다. +* [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). + +## 노드의 통제(Cordon)와 비우기(drain) + +1. 새로운 파드를 노드에 스케줄링하는 것을 막기 위해 노드를 통제한다. + + ```shell + kubectl cordon + ``` + `` 부분에 노드의 이름을 입력한다. + +1. 실행 중인 파드를 안전하게 축출하기 위해 노드를 비운다. + + ```shell + kubectl drain \ + --ignore-daemonsets + ``` + +## cri-dockerd를 사용하도록 kubelet 설정 + +아래의 단계는 kubeadm 도구를 사용하여 생성된 클러스터에 적용된다. +다른 도구를 사용했다면, 해당 도구에 대한 환경 설정 방법을 참고하여 +kubelet 환경 설정을 수정해야 한다. + +1. 영향 받는 각 노드의 `/var/lib/kubelet/kubeadm-flags.env`를 연다. +1. `--container-runtime-endpoint` 플래그를 + `unix:///var/run/cri-dockerd.sock`로 수정한다. + +kubeadm 도구는 노드의 소켓을 컨트롤 플레인의 `Node` 오브젝트의 어노테이션으로 저장한다. +영향을 받는 각 노드의 해당 소켓을 수정하려면 다음을 따른다. + +1. `Node` 오브젝트의 YAML 표현식을 편집한다. + + ```shell + KUBECONFIG=/path/to/admin.conf kubectl edit no + ``` + 각 인자는 다음과 같이 입력한다. + + * `/path/to/admin.conf`: + kubectl 환경 설정 파일(`admin.conf`)의 경로. + * ``: 수정을 원하는 노드의 이름. + +1. `kubeadm.alpha.kubernetes.io/cri-socket`의 값 + `/var/run/dockershim.sock`을 `unix:///var/run/cri-dockerd.sock`로 변경한다. +1. 변경을 저장한다. `Node` 오브젝트는 저장 시 업데이트된다. + +## kubelet 재시작 + +```shell +systemctl restart kubelet +``` + +## 노드가 정상(healthy)인지 확인 + +노드가 `cri-dockerd` 엔드포인트를 사용하는지 확인하려면, +[사용 런타임 찾기](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/) 지침을 따른다. +kubelet의 `--container-runtime-endpoint` 플래그는 `unix:///var/run/cri-dockerd.sock` 이어야 한다. + +## 노드 통제 해제(Uncordon) + +노드에 파드를 스케줄 하도록 통제를 해제한다. + +```shell +kubectl uncordon +``` + +## {{% heading "whatsnext" %}} + +* [도커심 제거 FAQ](/dockershim/) 읽기. +* [도커 엔진의 도커심을 containerd로 마이그레이션하는 방법 알아보기](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/). \ No newline at end of file diff --git a/content/ko/docs/tasks/administer-cluster/namespaces.md b/content/ko/docs/tasks/administer-cluster/namespaces.md index df33bf8de52..e46db9b8525 100644 --- a/content/ko/docs/tasks/administer-cluster/namespaces.md +++ b/content/ko/docs/tasks/administer-cluster/namespaces.md @@ -192,12 +192,12 @@ kubectl delete namespaces 하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 내용을 볼 수 없다. - 이를 보여주기 위해 `development` 네임스페이스에서 간단히 디플로이먼트와 파드를 생성하자. + 이를 보여주기 위해 `development` 네임스페이스에 간단한 디플로이먼트와 파드를 생성하자. ```shell - kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development --replicas=2 + kubectl create deployment snowflake --image=registry.k8s.io/serve_hostname -n=development --replicas=2 ``` - 호스트 이름을 제공하는 기본 컨테이너로 `snowflake`라는 이름의 파드를 실행하는 레플리카 사이즈 2의 디플로이먼트를 생성했다. + 단순히 호스트명을 제공해주는 `snowflake`라는 파드의 개수를 2개로 유지하는 디플로이먼트를 생성하였다. ```shell kubectl get deployment -n=development @@ -226,10 +226,10 @@ kubectl delete namespaces kubectl get pods -n=production ``` - 프로덕션은 마치 가축을 키우는 것과 같다. 그래서 우리도 cattle(가축)이라는 이름의 파드들을 생성하도록 하겠다. + 프로덕션이 가축 키우는 것을 좋아하듯이, 우리도 `production` 네임스페이스에 cattle(가축)이라는 이름의 파드를 생성한다. ```shell - kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production + kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production kubectl scale deployment cattle --replicas=5 -n=production kubectl get deployment -n=production diff --git a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md index b0b8a3aacc0..516f7efee3f 100644 --- a/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/ko/docs/tasks/administer-cluster/sysctl-cluster.md @@ -15,14 +15,13 @@ content_type: task {{< note >}} 쿠버네티스 버전 1.23부터, kubelet은 `/` 또는 `.`를 -sysctl 이름의 구분자로 사용하는 것을 지원한다. +sysctl 이름의 구분자로 사용하는 것을 지원한다. +쿠버네티스 1.25 버전부터, 파드에 대해서도 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을 설정하는 기능에서는 -아직 슬래시 구분자를 지원하지 않는다. +[sysctl.d(5)](https://man7.org/linux/man-pages/man5/sysctl.d.5.html) 페이지를 참고한다. {{< /note >}} ## {{% heading "prerequisites" %}} @@ -176,55 +175,3 @@ sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다. [노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 사용하여 해당 파드를 오른쪽 노드에 스케줄하는 것을 추천한다. - -## 파드시큐리티폴리시(PodSecurityPolicy) - -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - -또한 파드시큐리티폴리시의 `forbiddenSysctls` 및/또는 `allowedUnsafeSysctls` 필드에 -sysctl 또는 sysctl 패턴 목록을 지정하여 파드에서 설정할 -수 있는 sysctl를 제어할 수 있다. sysctl 패턴은 `kernel.*`과 같은 `*` -문자로 끝난다. `*` 문자 자체는 -모든 sysctl와 일치한다. - -기본적으로 모든 safe sysctl은 허용된다. - -`forbiddenSysctls`와 `allowedUnsafeSysctls`는 모두 단순한 sysctl 이름 또는 -sysctl 패턴 목록이다(`*`로 끝남). `*` 문자는 모든 sysctl과 일치한다. - -`forbiddenSysctls` 필드에는 특정 sysctl이 제외된다. -목록에서 safe sysctl과 unsafe sysctl의 조합을 금지할 수 있다. -sysctl 설정을 금지하기 위해서는 `*`를 사용한다. - -`allowedUnsafeSysctls` 필드에 unsafe sysctl을 지정하고 `forbiddenSysctls` 필드가 -존재하지 않는 경우, 파드시큐리티폴리시를 사용하여 -sysctl을 파드에서 사용할 수 있다. -파드시큐리티폴리시의 모든 unsafe sysctl을 설정하려면 `*`를 사용한다. - -이 두 필드를 겹치도록 구성하지 않는다. -이는 지정된 sysctl이 허용 및 금지됨을 의미한다. - -{{< warning >}} -파드시큐리티폴리시의 'allowedUnsafeSysctls' 필드를 통해 unsafe sysctl을 -허용하는 경우, 해당 노드에서 sysctl이 -'--allowed-unsafe-sysctls' kubelet 플래그를 통해 허용되지 않으면, -sysctl을 사용하는 모든 파드가 시작에 실패한다. -{{< /warning >}} - -이 예에서는 `kernel.msg` 접두사가 붙은 unsafe sysctl을 설정할 수 있으며, -`kernel.shm_rmid_forced` sysctl의 설정을 허용하지 않는다. - -```yaml -apiVersion: policy/v1beta1 -kind: PodSecurityPolicy -metadata: - name: sysctl-psp -spec: - allowedUnsafeSysctls: - - kernel.msg* - forbiddenSysctls: - - kernel.shm_rmid_forced - ... -``` - - diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md index 3e3e21ceeaa..a34628eed3d 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -182,7 +182,7 @@ static-web 1/1 Running 0 2m ``` {{< note >}} -Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 및 [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/)를 확인한다. +API 서버에서 미러 파드를 생성할 수 있는 권한이 kubelet에게 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. {{< /note >}} 스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은 diff --git a/content/ko/docs/tasks/configure-pod-container/user-namespaces.md b/content/ko/docs/tasks/configure-pod-container/user-namespaces.md new file mode 100644 index 00000000000..b0e1dc1d0ed --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/user-namespaces.md @@ -0,0 +1,100 @@ +--- +title: 파드에 유저 네임스페이스 사용하기 +reviewers: +content_type: task +weight: 160 +min-kubernetes-server-version: v1.25 +--- + + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +이 페이지는 스테이트리스(stateless) 파드에 유저 네임스페이스를 구성하는 방법을 다룬다. 이를 통해 +컨테이너 내부에서 실행 중인 유저를 호스트의 유저로부터 분리할 수 +있다. + +컨테이너에서 루트로 실행되는 프로세스는 호스트에서 다른(루트가 아닌) 유저로 실행할 수 +있다. 즉, 프로세스는 유저 네임스페이스 내부의 작업에 대한 +모든 권한을 갖지만 네임스페이스 외부의 작업에 대해서는 +권한이 없다. + +이 기능을 사용하여 손상된 컨테이너가 호스트 또는 동일한 노드의 다른 파드에 미칠 +피해를 줄일 수 있다. 유저 네임스페이스를 이용하면, +**HIGH** 또는 **CRITICAL** 로 분류되는 여러 [보안 취약점][KEP-vulns]을 +보완할 수 있다. 유저 네임스페이스는 향후 발생할 수 있는 여러 취약점도 +완화시킬 것으로 예상된다. + +유저 네임스페이스를 사용하지 않고 루트로 실행하는 컨테이너는 +컨테이너 브레이크아웃(breakout)이 발생하면 노드의 루트 권한을 갖는다. 그리고 컨테이너에 +어떤 기능이 부여되어 있다면 해당 기능은 호스트에서도 유효하다. 유저 네임스페이스를 +이용한다면 전혀 해당되지 않는 내용이다. + +[KEP-vulns]: https://github.com/kubernetes/enhancements/tree/217d790720c5aef09b8bd4d6ca96284a0affe6c2/keps/sig-node/127-user-namespaces#motivation + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% thirdparty-content single="true" %}} + + +* 노드의 운영체제는 리눅스를 사용한다. +* 호스트에서 커맨드를 exec 할 수 있어야 한다. +* 파드 내부로 exec 할 수 있어야 한다. +* 기능 게이트 'UserNamespacesStatelessPodsSupport'를 활성화해야 한다. + +추가적으로, 쿠버네티스 스테이트리스(stateless) 파드에서 +이 기능을 사용하려면 +{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}에서 지원이 필요하다. + +* CRI-O: v1.25는 유저 네임스페이스를 지원한다. + +**컨테이너 런타임이 유저 네임스페이스를 지원하지 않으면, +새 `pod.spec` 필드는 별다른 경고 없이 무시되고 파드는 유저 네임스페이스 없이 생성된다** 는 +사실을 명심한다. + + + +## 유저 네임스페이스를 사용하는 파드를 동작시키기 {#create-pod} + +스테이트리스 파드의 유저 네임스페이스는 `.spec`의 `hostUsers` 필드를 +`false`로 설정하여 사용할 수 있다. 다음은 예시이다. + +{{< codenew file="pods/user-namespaces-stateless.yaml" >}} + +1. 클러스터에 파드를 생성한다. + + ```shell + kubectl apply -f https://k8s.io/examples/pods/user-namespaces-stateless.yaml + ``` + +1. 컨테이너에 연결하고 `readlink /proc/self/ns/user`를 실행한다. + + ```shell + kubectl attach -it userns bash + ``` + +그리고 명령을 실행한다. 결과는 다음과 유사하다. + +```none +readlink /proc/self/ns/user +user:[4026531837] +cat /proc/self/uid_map +0 0 4294967295 +``` + +그런 다음 호스트에서 셸을 열고 동일한 명령을 실행한다. + +결과는 분명 다를 것이다. 이는 호스트와 파드가 다른 유저 네임스페이스를 사용하고 있음을 +의미한다. 유저 네임스페이스를 따로 만들지 않으면 호스트와 파드는 동일한 +유저 네임스페이스를 사용한다. + +유저 네임스페이스 내에서 kubelet을 실행하고 있다면, +파드에서 실행한 명령의 결과와 호스트에서 실행한 결과를 비교한다. + +```none +readlink /proc/$pid/ns/user +user:[4026534732] +``` + +`$pid`은 kubelet의 PID로 대체한다. diff --git a/content/ko/docs/tasks/debug/debug-application/debug-running-pod.md b/content/ko/docs/tasks/debug/debug-application/debug-running-pod.md index 59484f3abb6..90e3cc86b4b 100644 --- a/content/ko/docs/tasks/debug/debug-application/debug-running-pod.md +++ b/content/ko/docs/tasks/debug/debug-application/debug-running-pod.md @@ -378,7 +378,7 @@ kubectl exec -it cassandra -- sh ## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container} -{{< feature-state state="beta" for_k8s_version="v1.23" >}} +{{< feature-state state="stable" for_k8s_version="v1.25" >}} 컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 @@ -392,7 +392,7 @@ kubectl exec -it cassandra -- sh 먼저, 다음과 같이 파드를 추가한다. ```shell -kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never +kubectl run ephemeral-demo --image=registry.k8s.io/pause:3.1 --restart=Never ``` 이 섹션의 예시에서는 디버깅 도구가 포함되지 않은 이미지의 사례를 보여드리기 위해 @@ -611,7 +611,7 @@ kubectl delete pod myapp myapp-debug ## 노드의 쉘을 사용해서 디버깅하기 {#node-shell-session} 만약 위의 어떠한 방법도 사용할 수 없다면, 파드가 현재 동작 중인 노드를 찾아 -호스트의 네임스페이스로 동작하는 특권 파드를 생성할 수 있다. +해당 노드에서 실행되는 파드를 생성할 수 있다. 다음 `kubectl debug` 명령을 통해 해당 노드에서 인터랙티브한 쉘을 생성할 수 있다. ```shell @@ -628,8 +628,9 @@ root@ek8s:/# * `kubectl debug`는 노드의 이름에 기반해 새로운 파드의 이름을 자동으로 생성한다. -* 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다. * 노드의 루트 파일시스템은 `/host`에 마운트된다. +* 파드가 특권을 가지고 있지 않더라도, 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다. 따라서 몇몇 프로세스 정보를 읽어오거나, `chroot /host` 등의 작업은 수행될 수 없다. +* 특권을 가진 파드가 필요한 경우에는 직접 생성한다. 사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다. diff --git a/content/ko/docs/tasks/debug/debug-cluster/_index.md b/content/ko/docs/tasks/debug/debug-cluster/_index.md index b47a59ac390..40179bd8ac0 100644 --- a/content/ko/docs/tasks/debug/debug-cluster/_index.md +++ b/content/ko/docs/tasks/debug/debug-cluster/_index.md @@ -311,6 +311,6 @@ status: * [리소스 메트릭 파이프라인](/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/)에서 사용할 수 있는 메트릭에 대해 알아 본다. * [리소스 사용량 모니터링](/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)을 위한 추가 도구에 대해 알아 본다. * Node Problem Detector를 사용하여 [노드 헬스(health)를 모니터링](/ko/docs/tasks/debug/debug-cluster/monitor-node-health/)한다. -* `crictl`을 사용하여 [쿠버네티스 노드를 디버깅](/docs/tasks/debug/debug-cluster/crictl/)한다. -* [쿠버네티스 감사(auditing)](/docs/tasks/debug/debug-cluster/audit/)에 대한 더 자세한 정보를 본다. +* `crictl`을 사용하여 [쿠버네티스 노드를 디버깅](/ko/docs/tasks/debug/debug-cluster/crictl/)한다. +* [쿠버네티스 감사(auditing)](/ko/docs/tasks/debug/debug-cluster/audit/)에 대한 더 자세한 정보를 본다. * `telepresence`를 사용하여 [서비스를 로컬에서 개발 및 디버깅](/ko/docs/tasks/debug/debug-cluster/local-debugging/)한다. diff --git a/content/ko/docs/tasks/debug/debug-cluster/audit.md b/content/ko/docs/tasks/debug/debug-cluster/audit.md new file mode 100644 index 00000000000..471857e268b --- /dev/null +++ b/content/ko/docs/tasks/debug/debug-cluster/audit.md @@ -0,0 +1,257 @@ +--- +#reviewers: +#- soltysh +#- sttts +#- ericchiang +content_type: concept +title: 감사(auditing) +--- + + + +쿠버네티스 _감사(auditing)_ 는 클러스터의 작업 순서를 문서화하는 보안 관련 시간별 레코드 세트를 제공한다. +클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션 및 +컨트롤 플레인 자체에서 생성된 활동을 감사한다. + +감사를 통해 클러스터 관리자는 다음 질문에 답할 수 있다. + + - 무슨 일이 일어났는지? + - 언제 일어난 일인지? + - 누가 시작했는지? + - 어떤 일이 있었는지? + - 어디서 관찰되었는지? + - 어디서부터 시작되었는지? + - 그래서 어디까지 갔는지? + + + +감사 기록은 [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +컴포넌트 내에서 수명주기를 시작한다. +실행의 각 단계에서 각 요청은 감사 이벤트를 생성하고, +감사 이벤트는 특정 정책에 따라 사전 처리되고 백엔드에 기록된다. +정책은 기록된 내용을 결정하고 백엔드는 기록을 유지한다. +현재 백엔드 구현에는 로그 파일 및 +웹훅이 포함된다. + +각 요청들은 연관된 _단계(stage)_ 와 함께 기록될 수 있다. 정의된 단계는 다음과 같다. + +- `RequestReceived` - 감사 핸들러가 요청을 수신한 직후, + 그리고 핸들러 체인으로 위임되기 전에 + 생성되는 이벤트에 대한 단계이다. +- `ResponseStarted` - 응답 헤더는 전송되었지만, + 응답 본문(body)은 전송되기 전인 단계이다. + 이 단계는 오래 실행되는 요청(예: watch)에 대해서만 생성된다. +- `ResponseComplete` - 응답 내용이 완료되었으며, + 더 이상 바이트가 전송되지 않을 때의 단계이다. +- `Panic` - 패닉이 발생했을 때 생성되는 이벤트이다. + +{{< note >}} +[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) +의 구성은 +[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) +API 오브젝트와는 +다르다. +{{< /note >}} + +감사 로깅 기능은 감사에 필요한 일부 컨텍스트가 요청마다 +저장되기 때문에 API 서버의 메모리 사용량을 증가시킨다. +메모리 소비량은 감사 로깅 구성에 따라 다르다. + +## 감사 정책 + +감사 정책은 기록해야 하는 이벤트와 포함해야 하는 +데이터에 대한 규칙을 정의한다. 감사 정책 오브젝트 구조는 +[`audit.k8s.io` API 그룹](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)에 정의되어 있다. +이벤트가 처리되면 규칙 목록과 순서대로 비교된다. +첫번째 일치 규칙은 이벤트의 _감사 수준(audit level)_ 을 설정한다. +정의된 감사 수준은 다음과 같다. + +- `None` - 이 규칙에 해당되는 이벤트는 로깅하지 않는다. +- `Metadata` - 요청 메타데이터(요청하는 사용자, 타임스탬프, 리소스, 동사(verb) 등)는 로깅하지만 + 요청/응답 본문은 로깅하지 않는다. +- `Request` - 이벤트 메타데이터 및 요청 본문을 로깅하지만 응답 본문은 로깅하지 않는다. + 리소스 외의 요청에는 적용되지 않는다. +- `RequestResponse` - 이벤트 메타데이터 및 요청/응답 본문을 로깅한다. + 리소스 외의 요청에는 적용되지 않는다. + +`--audit-policy-file` 플래그를 사용하여 정책이 포함된 파일을 +`kube-apiserver`에 전달할 수 있다. 플래그를 생략하면 이벤트가 기록되지 않는다. +감사 정책 파일에 `rules` 필드 **반드시** 가 제공되어야 한다. +규칙이 없는(0개인) 정책은 적절하지 않은(illegal) 것으로 간주된다. + +다음은 감사 정책 파일의 예이다. + +{{< codenew file="audit/audit-policy.yaml" >}} + +최소 감사 정책 파일을 사용하여 `Metadata` 수준에서 모든 요청을 기록할 수 있다. + +```yaml +# Log all requests at the Metadata level. +apiVersion: audit.k8s.io/v1 +kind: Policy +rules: +- level: Metadata +``` + +자체 감사 프로필을 만드는 경우 Google Container-Optimized OS에 대한 감사 프로필을 시작점으로 사용할 수 있다. +감사 정책 파일을 생성하는 [configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh) +스크립트를 확인하면 된다. 스크립트로 대부분의 감사 정책 파일을 볼 수 있다. + +정의된 필드에 대한 자세한 내용은 [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)를 +참조할 수도 있다. + +## 감사 백엔드 + +감사 백엔드는 감사 이벤트를 외부 저장소에 유지한다. +기본적으로 kube-apiserver는 두 가지 백엔드를 제공한다. + +- 이벤트를 파일 시스템에 기록하는 로그 백엔드 +- 이벤트를 외부 HTTP API로 보내는 Webhook 백엔드 + +모든 경우에 감사 이벤트는 쿠버네티스 API의 +[`audit.k8s.io` API 그룹](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)에서 정의한 구조를 따른다. + +{{< note >}} +패치의 경우 요청 내용은 적절한 쿠버네티스 API 오브젝트를 포함하는 JSON 오브젝트가 아니라 +패치 작업을 포함하는 JSON 배열이다. 예를 들어 다음 요청 내용은 +`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`에 대한 유효한 패치 요청이다. + +```json +[ + { + "op": "replace", + "path": "/spec/parallelism", + "value": 0 + }, + { + "op": "remove", + "path": "/spec/template/spec/containers/0/terminationMessagePolicy" + } +] +``` + +{{< /note >}} + +### 로그 백엔드 + +로그 백엔드는 감사이벤트를 [JSONlines](https://jsonlines.org/) 형식으로 파일에 기록한다. +다음의 `kube-apiserver` 플래그를 사용하여 로그 감사 백엔드를 구성할 수 있다. + +- `--audit-log-path` 는 로그 백엔드가 감사 이벤트를 쓰는 데 사용하는 로그 파일 경로를 지정한다. + 이 플래그를 지정하지 않으면 로그 백엔드가 비활성화된다. `-` 는 표준 출력을 의미한다. +- `--audit-log-maxage` 는 오래된 감사 로그 파일을 보관할 최대 일수를 정의한다. +- `--audit-log-maxbackup` 은 보관할 감사 로그 파일의 최대 수를 정의한다. +- `--audit-log-maxsize` 는 감사 로그 파일이 로테이트 되기 전의 최대 크기(MB)를 정의한다. + +클러스터의 컨트롤 플레인이 kube-apiserver를 파드로 실행하는 경우 감사 레코드가 지속되도록 +정책 파일 및 로그 파일의 위치에 `hostPath` 를 마운트 해야한다. 예를 들면 +```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml \ + --audit-log-path=/var/log/kubernetes/audit/audit.log +``` +그런 다음 볼륨을 마운트 한다. + +```yaml +... +volumeMounts: + - mountPath: /etc/kubernetes/audit-policy.yaml + name: audit + readOnly: true + - mountPath: /var/log/kubernetes/audit/ + name: audit-log + readOnly: false +``` +그리고 마지막으로 `hostPath` 를 구성한다. + +```yaml +... +volumes: +- name: audit + hostPath: + path: /etc/kubernetes/audit-policy.yaml + type: File + +- name: audit-log + hostPath: + path: /var/log/kubernetes/audit/ + type: DirectoryOrCreate +``` + +### 웹훅 백엔드 + +웹훅 감사 백엔드는 원격 웹 API로 감사 이벤트를 전송하는데, 이는 인증 수단을 포함하여 +쿠버네티스 API의 한 형태로 간주된다. +다음 kube-apiserver 플래그를 사용하여 웹훅 감사 백엔드를 구성할 수 있다. + +- `--audit-webhook-config-file` 은 웹훅 구성이 있는 파일의 경로를 지정한다. + 웹훅 구성은 효과적으로 전문화된 + [kubeconfig](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)이다. +- `--audit-webhook-initial-backoff` 는 첫 번째 실패한 요청 후 다시 시도하기 전에 대기할 시간을 지정한다. + 이후 요청은 지수의 백오프로 재시도 된다. + +웹훅 구성 파일은 kubeconfig 형식을 사용하여 +서비스의 원격 주소와 서비스에 연결하는 데 사용되는 자격 증명을 지정한다. + +## 이벤트 배치 {#배치} + +로그 및 웹 훅 백엔드는 모두 배치를 지원한다. 웹훅 사용을 예로 들면, 다음은 사용 가능한 플래그 목록이다. +로그 백엔드에 대해 동일한 플래그를 가져오려면 플래그 이름에 있는 `webhook` 을 `log` 로 바꾼다. +기본적으로 배치 기능은 `webhook` 에서 활성화되고 `log` 에서 비활성화된다. 마찬가지로, 기본적으로 +쓰로틀링은 `webhook` 에서는 활성화되고 `log` 에서는 비활성화된다. + +- `--audit-webhook-mode` 은 버퍼링 전략을 정의한다. 다음 중 하나이다. + - `batch` - 이벤트를 버퍼링하고 비동기식으로 배치한다. 이것이 기본값이다. + - `blocking` - 각 개별 이벤트를 처리할 때 API 서버 응답을 차단한다. + - `blocking-strict` - `blocking`과 동일하지만, RequestReceived 단계에서 감사 로깅 중에 오류가 발생하면 + kube-apiserver에 대한 전체 요청이 실패한다. + +다음 플래그는 `batch` 모드에서만 사용된다. + +- `--audit-webhook-batch-buffer-size` 는 배치하기 전에 버퍼링할 이벤트 수를 정의한다. + 들어오는 이벤트의 비율이 버퍼를 초과하면 이벤트가 삭제된다. +- `--audit-webhook-batch-max-size` 는 한 배치의 최대 이벤트 수를 정의한다. +- `--audit-webhook-batch-max-wait` 는 대기열에서 이벤트를 무조건 배치하기 전에 + 대기할 최대 시간을 정의한다. +- `--audit-webhook-batch-throttle-qps` 는 초당 생성되는 최대 평균 배치 수를 + 정의한다. +- `--audit-webhook-batch-throttle-burst` 는 허용된 QPS가 이전에 충분히 활용되지 않은 경우 + 동시에 생성되는 최대 배치 수를 정의한다. + +## 파라미터 튜닝 + +파라미터는 API 서버의 로드를 수용할 수 있도록 설정해야 한다. + +예를 들어 kube-apiserver가 초당 100건의 요청을 수신하고 각 요청이 +`ResponseStarted` 와 `ResponseComplete` 단계에서만 감사되는 경우 초당 생성되는 ≅200건의 감사 이벤트를 고려해야 한다. +일괄적으로 최대 100개의 이벤트가 있다고 가정할 때 +초당 최소 2개의 쿼리 조절 수준을 설정해야 한다. +백엔드가 이벤트를 쓰는 데 최대 5초가 걸릴 수 있다고 가정하면 버퍼크기를 최대 5초의 이벤트를 보유하도록 설정해야 한다. +즉, 10개의 배치 또는 100개의 이벤트이다. + +그러나 대부분의 경우 기본 매개 변수만 있으면 충분하며 수동으로 설정할 필요가 없다. +kube-apiserver에서 노출된 다음과 같은 프로메테우스 메트릭과 로그에서 +감사 하위 시스템의 상태를 모니터링할 수 있다. + +- `apiserver_audit_event_total` 의 메트릭에는 내보낸 감사 이벤트의 총 수가 포함된다. +- `apiserver_audit_error_total` 의 메트릭에는 내보내기 중 오류로 인해 삭제된 총 이벤트 + 수가 포함된다. + +### 로그 항목 자르기 {#truncate} + +로그 및 웹훅 백엔드는 모두 로깅되는 이벤트의 크기 제한을 지원한다. +예를 들어 로그 백엔드에 사용할 수 있는 플래그 목록은 다음과 같다. + +- `audit-log-truncate-enabled` 는 이벤트 및 자르기 배치가 활성화 되었는지 여부를 나타낸다. +- `audit-log-truncate-max-batch-size` 는 기본 백엔드로 전송되는 배치의 바이트 단위의 최대 크기이다. +- `audit-log-truncate-max-event-size` 는 기본 백엔드로 전송된 감사 이벤트의 바이트 단위의 최대 크기이다. + +기본적으로 `webhook` 과 `log` 모두에서 자르기 기능이 비활성화되어 있으므로 이 기능을 활성화 하기 위해 +클러스터 관리자는 `audit-log-truncate-enabled` 또는 `audit-webhook-truncate-enabled` 를 설정해야 한다. + +## {{% heading "whatsnext" %}} + +* [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations) 에 대해 알아보기. +* [`Event`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) 에 대해 알아보고 + 감사 구성 참조를 읽고 [`Policy`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) + 리소스 유형 확인하기. + diff --git a/content/ko/docs/tasks/debug/debug-cluster/crictl.md b/content/ko/docs/tasks/debug/debug-cluster/crictl.md new file mode 100644 index 00000000000..2cae1d62bf0 --- /dev/null +++ b/content/ko/docs/tasks/debug/debug-cluster/crictl.md @@ -0,0 +1,378 @@ +--- +# reviewers: +# - Random-Liu +# - feiskyer +# - mrunalp +title: crictl로 쿠버네티스 노드 디버깅하기 +content_type: task +weight: 30 +--- + + + + +{{< feature-state for_k8s_version="v1.11" state="stable" >}} + +`crictl`은 CRI-호환 컨테이너 런타임에 사용할 수 있는 커맨드라인 인터페이스이다. +쿠버네티스 노드에서 컨테이너 런타임과 애플리케이션을 검사하고 +디버그하는 데 사용할 수 있다. +`crictl`과 그 소스는 [cri-tools](https://github.com/kubernetes-sigs/cri-tools) 저장소에서 호스팅한다. + +## {{% heading "prerequisites" %}} + +`crictl`은 CRI 런타임이 있는 리눅스 운영체제를 필요로 한다. + + + +## crictl 설치하기 + +cri-tools [릴리스 페이지](https://github.com/kubernetes-sigs/cri-tools/releases)에서 +다양한 아키텍처 별로 압축된 `crictl` 아카이브(archive)를 다운로드할 수 있다. +설치된 쿠버네티스 버전에 해당하는 버전을 다운로드한다. +`/usr/local/bin/`와 같은 시스템 경로의 위치에 +압축을 푼다. + +## 일반적인 사용법 + +`crictl` 커맨드에는 여러 하위 커맨드와 런타임 플래그가 있다. +자세한 내용은 `crictl help` 또는 `crictl help`를 참조한다. + +아래 내용 중 하나를 통해 `crictl`의 엔드포인트를 설정할 수 있다. + +* `--runtime-endpoint`와 `--image-endpoint` 플래그 설정. +* `CONTAINER_RUNTIME_ENDPOINT`와 `IMAGE_SERVICE_ENDPOINT` 환경 변수 + 설정. +* 구성 파일 `/etc/crictl.yaml`에 엔드포인트 설정. + 다른 파일을 지정하기 위해서는 `crictl`을 실행할 때 `--config=PATH_TO_FILE` 플래그를 사용한다. + +{{}} +엔드포인트를 설정하지 않으면, +`crictl`이 알려진 엔드포인트 목록에 연결을 시도하므로 성능에 영향을 줄 수 있다. +{{}} + +서버에 연결할 때 구성 파일에서 `timeout` 또는 `debug` 값을 명시하거나, +`--timeout` 그리고 `--debug` 커맨드라인 플래그를 사용하여 +타임아웃 값을 지정하고 디버깅을 활성화하거나 비활성화할 수 있다. + +현재 구성을 보거나 편집하려면 `/etc/crictl.yaml`의 내용을 보거나 편집한다. +예를 들어, +`containerd` 컨테이너 런타임 사용 시 구성은 아래와 유사하다. + +``` +runtime-endpoint: unix:///var/run/containerd/containerd.sock +image-endpoint: unix:///var/run/containerd/containerd.sock +timeout: 10 +debug: true +``` + +`crictl`에 대해 자세히 알고 싶다면, +[`crictl` 문서](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)를 참조한다. + +## crictl 커맨드 예시 + +아래 예시를 통해 `crictl` 커맨드와 출력을 확인해보자. + +{{< warning >}} +구동 중인 쿠버네티스 클러스터에서 `crictl`을 사용하여 파드 샌드박스(sandbox)나 컨테이너를 만들게 되면, +결국에는 kubelet이 그것들을 삭제하게 된다. +`crictl`은 일반적인 워크플로우 툴이 아니라 디버깅에 유용한 툴임을 명심해야 한다. +{{< /warning >}} + +### 파드 목록 조회 + +모든 파드의 목록 조회 + +```shell +crictl pods +``` + +출력은 다음과 유사하다. + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0 +4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0 +a86316e96fa89 17 hours ago Ready kube-proxy-gblk4 kube-system 0 +919630b8f81f1 17 hours ago Ready nvidia-device-plugin-zgbbv kube-system 0 +``` + +이름으로 파드의 목록 조회 + +```shell +crictl pods --name nginx-65899c769f-wv2gp +``` + +출력은 다음과 유사하다. + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + +레이블로 파드의 목록 조회 + +```shell +crictl pods --label run=nginx +``` + +출력은 다음과 유사하다. + +``` +POD ID CREATED STATE NAME NAMESPACE ATTEMPT +4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0 +``` + +### 이미지 목록 조회 + +모든 이미지의 목록 조회 + +```shell +crictl images +``` + +출력은 다음과 유사하다. + +``` +IMAGE TAG IMAGE ID SIZE +busybox latest 8c811b4aec35f 1.15MB +k8s-gcrio.azureedge.net/hyperkube-amd64 v1.10.3 e179bbfe5d238 665MB +k8s-gcrio.azureedge.net/pause-amd64 3.1 da86e6ba6ca19 742kB +nginx latest cd5239a0906a6 109MB +``` + +저장소로 이미지 목록 조회 + +```shell +crictl images nginx +``` + +출력은 다음과 유사하다. + +``` +IMAGE TAG IMAGE ID SIZE +nginx latest cd5239a0906a6 109MB +``` + +이미지의 IDs 목록만 조회 + +```shell +crictl images -q +``` + +출력은 다음과 유사하다. + +``` +sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a +sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5 +sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e +sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569 +``` + +### 컨테이너 목록 조회 + +모든 컨테이너 목록 조회 + +```shell +crictl ps -a +``` + +출력은 다음과 유사하다. + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1 +9c5951df22c78 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 8 minutes ago Exited sh 0 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 8 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 18 hours ago Running kube-proxy 0 +``` + +실행 중인 컨테이너 목록 조회 + +```shell +crictl ps +``` + +출력은 다음과 유사하다. + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1 +87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 7 minutes ago Running nginx 0 +1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 17 hours ago Running kube-proxy 0 +``` + +### 실행 중인 컨테이너 안에서 명령 실행 + +```shell +crictl exec -i -t 1f73f2d81bf98 ls +``` + +출력은 다음과 유사하다. + +``` +bin dev etc home proc root sys tmp usr var +``` + +### 컨테이너의 로그 조회 + +모든 컨테이너의 로그 조회 + +```shell +crictl logs 87d3992f84f74 +``` + +출력은 다음과 유사하다. + +``` +10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + +최신 `N`개 줄의 로그만 조회 + +```shell +crictl logs --tail=1 87d3992f84f74 +``` + +출력은 다음과 유사하다. + +``` +10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-" +``` + +### 파드 샌드박스 실행 + +`crictl`을 사용하여 파드 샌드박스를 실행하는 것은 컨테이너 런타임 디버깅에 유용하다. +구동 중인 쿠버네티스 클러스터에서 +이러한 샌드박스는 kubelet에 의해서 결국 중지 및 삭제된다. + +1. 다음과 같은 JSON 파일 생성한다. + + ```json + { + "metadata": { + "name": "nginx-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "hdishd83djaidwnduwk28bcsb" + }, + "log_directory": "/tmp", + "linux": { + } + } + ``` + +2. `crictl runp` 커맨드를 사용하여 JSON을 적용하고 샌드박스를 실행한다. + + ```shell + crictl runp pod-config.json + ``` + + 결과로 샌드박스의 ID가 반환될 것이다. + +### 컨테이너 생성 + +`crictl`을 사용하여 컨테이너를 만드는 것은 컨테이너 런타임 디버깅에 유용하다. +구동 중인 쿠버네티스 클러스터에서 +이러한 샌드박스는 kubelet에 의해서 결국 중지 및 삭제된다. + +1. busybox 이미지 가져오기 + + ```shell + crictl pull busybox + ``` + ```none + Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 + ``` + +2. 파드와 컨테이너 구성(config) 생성 + + **파드 구성**: + + ```json + { + "metadata": { + "name": "busybox-sandbox", + "namespace": "default", + "attempt": 1, + "uid": "aewi4aeThua7ooShohbo1phoj" + }, + "log_directory": "/tmp", + "linux": { + } + } + ``` + + **컨테이너 구성**: + + ```json + { + "metadata": { + "name": "busybox" + }, + "image":{ + "image": "busybox" + }, + "command": [ + "top" + ], + "log_path":"busybox.log", + "linux": { + } + } + ``` + +3. 이전에 생성한 파드의 ID 및 컨테이너 구성 파일과 파드 구성 파일을 커맨드 인자로 전달하여, +컨테이너를 생성한다. +결과로 컨테이너의 ID가 반환될 것이다. + + ```shell + crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json + ``` + +4. 모든 컨테이너의 목록을 조회하여 + 새로 생성된 컨테이너의 상태가 `Created`임을 확인한다. + + ```shell + crictl ps -a + ``` + + 출력은 다음과 유사하다. + + ``` + CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT + 3e025dd50a72d busybox 32 seconds ago Created busybox 0 + ``` + +### 컨테이너 시작하기 + +컨테이너를 시작하기 위해서 컨테이너 ID를 `crictl start`에 인자로 전달한다. + +```shell +crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + +출력은 다음과 유사하다. + +``` +3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60 +``` + +컨테이너의 상태가 `Running`임을 확인한다. + +```shell +crictl ps +``` +출력은 다음과 유사하다. + +``` +CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT +3e025dd50a72d busybox About a minute ago Running busybox 0 +``` + +## {{% heading "whatsnext" %}} + +* [`crictl` 더 알아보기](https://github.com/kubernetes-sigs/cri-tools). +* [`docker` CLI 커맨드를 `crictl`로 매핑하기](/docs/reference/tools/map-crictl-dockercli/). + diff --git a/content/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md index a3e41c5ad21..92bb749d80f 100644 --- a/content/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md @@ -70,6 +70,6 @@ CNCF 프로젝트가 아닌 완전한 메트릭 파이프라인 프로젝트는 * [로깅](/ko/docs/concepts/cluster-administration/logging/) * [모니터링](/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) * [`exec`를 통해 컨테이너에 접속하기](/ko/docs/tasks/debug/debug-application/get-shell-running-container/) -* [프록시를 통해 컨테이너에 연결하기](/docs/tasks/extend-kubernetes/http-proxy-access-api/) +* [프록시를 통해 컨테이너에 연결하기](/ko/docs/tasks/extend-kubernetes/http-proxy-access-api/) * [포트 포워딩을 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) -* [crictl을 사용하여 쿠버네티스 노드 조사하기](/docs/tasks/debug/debug-cluster/crictl/) +* [crictl을 사용하여 쿠버네티스 노드 조사하기](/ko/docs/tasks/debug/debug-cluster/crictl/) diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md b/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md index bd7f8b37423..9d9f34ff167 100644 --- a/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md +++ b/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md @@ -25,7 +25,7 @@ weight: 15 -## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정 +## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정하기 다음 단계는 확장 API 서버를 *높은 수준* 으로 설정하는 방법을 설명한다. 이 단계는 YAML 구성을 사용하거나 API를 사용하는 것에 상관없이 적용된다. 둘 사이의 차이점을 구체적으로 식별하려고 시도한다. YAML 구성을 사용하여 구현하는 방법에 대한 구체적인 예를 보려면, 쿠버네티스 리포지터리에서 [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md)를 참고할 수 있다. diff --git a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md index e785dcf39b1..19eafd4b6ca 100644 --- a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md @@ -46,33 +46,33 @@ weight: 10 1. YAML 구성 파일을 활용해 파드를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/pods/commands.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/commands.yaml + ``` 1. 실행 중인 파드들의 목록을 조회한다. - ```shell - kubectl get pods - ``` + ```shell + kubectl get pods + ``` - 출력은 command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 표시할 - 것이다. + command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 출력될 + 것이다. 1. 컨테이너 안에서 실행된 커맨드의 출력을 보기 위해, 파드의 로그를 확인한다. - ```shell - kubectl logs command-demo - ``` + ```shell + kubectl logs command-demo + ``` - 출력은 HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들을 표시할 - 것이다. + HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들이 출력될 + 것이다. - ``` - command-demo - tcp://10.3.240.1:443 - ``` + ``` + command-demo + tcp://10.3.240.1:443 + ``` ## 인자를 정의하기 위해 환경 변수를 사용하기 diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md index 40272c30603..5bac1381052 100644 --- a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -30,39 +30,39 @@ weight: 20 1. YAML 구성 파일을 활용해 파드를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml + ``` 1. 실행 중인 파드들의 목록을 조회한다. - ```shell - kubectl get pods -l purpose=demonstrate-envars - ``` + ```shell + kubectl get pods -l purpose=demonstrate-envars + ``` - 출력은 아래와 비슷할 것이다. + 결과는 다음과 같다. - ``` - NAME READY STATUS RESTARTS AGE - envar-demo 1/1 Running 0 9s - ``` + ``` + NAME READY STATUS RESTARTS AGE + envar-demo 1/1 Running 0 9s + ``` 1. 파드의 컨테이너 환경 변수를 나열한다. - ```shell - kubectl exec envar-demo -- printenv - ``` + ```shell + kubectl exec envar-demo -- printenv + ``` - 출력은 아래와 비슷할 것이다. + 결과는 다음과 같다. - ``` - NODE_VERSION=4.4.2 - EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237 - HOSTNAME=envar-demo - ... - DEMO_GREETING=Hello from the environment - DEMO_FAREWELL=Such a sweet sorrow - ``` + ``` + NODE_VERSION=4.4.2 + EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237 + HOSTNAME=envar-demo + ... + DEMO_GREETING=Hello from the environment + DEMO_FAREWELL=Such a sweet sorrow + ``` {{< note >}} `env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 diff --git a/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md index 54e809cf00c..58286068947 100644 --- a/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md +++ b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md @@ -20,50 +20,55 @@ weight: 20 ## 컨테이너를 위한 종속 환경 변수 정의하기 -파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다. -종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다. +파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다. 종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다. -이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다. +이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다. +파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. +다음은 파드를 위한 구성 매니페스트 예시이다. {{< codenew file="pods/inject/dependent-envars.yaml" >}} 1. YAML 구성 파일을 활용해 파드를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml - ``` - ``` - pod/dependent-envars-demo created - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml + ``` + ``` + pod/dependent-envars-demo created + ``` 2. 실행 중인 파드의 목록을 조회한다. - ```shell - kubectl get pods dependent-envars-demo - ``` - ``` - NAME READY STATUS RESTARTS AGE - dependent-envars-demo 1/1 Running 0 9s - ``` + ```shell + kubectl get pods dependent-envars-demo + ``` + ``` + NAME READY STATUS RESTARTS AGE + dependent-envars-demo 1/1 Running 0 9s + ``` 3. 파드 안에서 동작 중인 컨테이너의 로그를 확인한다. - ```shell - kubectl logs pod/dependent-envars-demo - ``` - ``` + ```shell + kubectl logs pod/dependent-envars-demo + ``` + ``` - UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 - SERVICE_ADDRESS=https://172.17.0.1:80 - ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 - ``` + UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + SERVICE_ADDRESS=https://172.17.0.1:80 + ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + ``` 위에서 보듯이, `SERVICE_ADDRESS`는 올바른 종속성 참조, `UNCHANGED_REFERENCE`는 잘못된 종속성 참조를 정의했으며 `ESCAPED_REFERENCE`는 종속성 참조를 건너뛴다. -환경 변수가 참조될 때 해당 환경 변수가 미리 정의되어 있으면 `SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다. +미리 정의된 환경 변수를 참조할 때는, +`SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다. -환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다. -일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다. +`env` 목록 안에서의 순서가 영향을 준다는 것을 주의하자. +목록에서 더 아래쪽에 명시된 환경 변수는, "정의된" 것으로 보지 않는다. +이것이 바로 위의 예시에서 `UNCHANGED_REFERENCE`가 `$(PROTOCOL)`을 해석하지 못한 이유이다. + +환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다. 일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다. `$(VAR_NAME)` 구문은 이중 $로 이스케이프될 수 있다. (예: `$$(VAR_NAME)`) 이스케이프된 참조는 참조된 변수가 정의되었는지 여부에 관계없이 해석을 수행하지 않는다. diff --git a/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md index 0ff081f99ac..f539b8103a8 100644 --- a/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md +++ b/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -9,6 +9,7 @@ min-kubernetes-server-version: v1.6 본 페이지는 암호 및 암호화 키와 같은 민감한 데이터를 파드에 안전하게 주입하는 방법을 설명한다. + ## {{% heading "prerequisites" %}} @@ -42,44 +43,44 @@ echo -n '39528$vdg7Jb' | base64 1. 시크릿을 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml + ``` 2. 시크릿에 대한 정보를 확인한다. - ```shell - kubectl get secret test-secret - ``` + ```shell + kubectl get secret test-secret + ``` - Output: + 결과는 다음과 같다. - ``` - NAME TYPE DATA AGE - test-secret Opaque 2 1m - ``` + ``` + NAME TYPE DATA AGE + test-secret Opaque 2 1m + ``` 3. 시크릿에 대한 자세한 정보를 확인한다. - ```shell - kubectl describe secret test-secret - ``` + ```shell + kubectl describe secret test-secret + ``` - Output: + 결과는 다음과 같다. - ``` - Name: test-secret - Namespace: default - Labels: - Annotations: + ``` + Name: test-secret + Namespace: default + Labels: + Annotations: - Type: Opaque + Type: Opaque - Data - ==== - password: 13 bytes - username: 7 bytes - ``` + Data + ==== + password: 13 bytes + username: 7 bytes + ``` ### kubectl로 직접 시크릿 생성하기 diff --git a/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index 97db3f944b0..105eba0d3cb 100644 --- a/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -13,7 +13,7 @@ weight: 40 쿠버네티스에는 실행 중인 컨테이너에 파드 필드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다. -* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api) +* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) * 볼륨 파일 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 @@ -161,11 +161,14 @@ total 8 단일 컨테이너는 `/etc/podinfo`에 볼륨을 마운트하는 것을 확인할 수 있다. -`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는 downward API 볼륨의 파일을 의미한다. +`downwardAPI` 아래의 `items` 배열을 살펴보자. +배열의 각 요소는 downward API 볼륨의 파일을 의미한다. 첫 번째 요소는 `client-container`라는 컨테이너에서 `1m`으로 지정된 형식의 `limits.cpu` 필드 값이 -`cpu_limit`이라는 파일에 배포되어야 함을 지정한다. `divisor` 필드는 선택 사항이다. divisor 1은 `cpu` 리소스를 위한 코어 수를 의미하거나 `memory` 리소스에 대한 바이트 수를 의미한다. +`cpu_limit`이라는 파일에 배포되어야 함을 지정한다. +`divisor` 필드는 선택 사항이며, 지정하지 않을 경우 `1`의 값을 갖는다. +divisor 1은 `cpu` 리소스를 위한 코어 수를 의미하거나 `memory` 리소스에 대한 바이트 수를 의미한다. 파드를 생성한다. diff --git a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md index e48b08b8a30..3743e9b267a 100644 --- a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -9,12 +9,9 @@ weight: 10 -쿠버네티스 버전 1.21에서 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}이 GA (General Availability)로 승격되었다. -이전 버전의 쿠버네티스를 사용하고 있다면, 해당 쿠버네티스 버전의 문서를 참고하여 정확한 정보를 확인할 수 있다. -이전 버전의 쿠버네티스는 `batch/v1` 크론잡 API를 지원하지 않는다. - -시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다. -이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다. +{{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용하여 +{{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 시간 기반의 스케줄에 따라 실행할 수 있다. +이러한 자동화된 잡은 리눅스 또는 유닉스 시스템의 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다. 크론 잡은 백업을 수행하거나 이메일을 보내는 것과 같이 주기적이고 반복적인 작업들을 생성하는 데 유용하다. 크론 잡은 시스템 사용이 적은 시간에 잡을 스케줄하려는 경우처럼 특정 시간에 개별 작업을 스케줄할 수도 있다. @@ -25,15 +22,10 @@ weight: 10 제한 사항에 대한 자세한 내용은 [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 참고한다. - - ## {{% heading "prerequisites" %}} - * {{< include "task-tutorial-prereqs.md" >}} - - ## 크론잡(CronJob) 생성 {#creating-a-cron-job} @@ -96,8 +88,7 @@ NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE hello */1 * * * * False 0 50s 75s ``` -크론 잡 `hello` 가 지정된 시간에 성공적으로 잡을 스케줄했는지 -`LAST SCHEDULE`에서 확인해야 한다. +크론 잡 `hello` 가 `LAST SCHEDULE` 열에 명시된 시간에 잡을 성공적으로 스케줄링한 것을 볼 수 있다. 현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다. 이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다. @@ -135,19 +126,25 @@ kubectl delete cronjob hello ## 크론잡(CronJob) 명세 작성 {#writing-a-cron-job-spec} -다른 모든 쿠버네티스 오브젝트들과 마찬가지로, 크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다. Kubernetes 개체 작업과 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 대한 자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와 +다른 모든 쿠버네티스 오브젝트들과 마찬가지로, +크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다. +쿠버네티스 오브젝트 및 그 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 다루기에 대한 +자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와 [kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다. 크론잡(CronJob)의 각 매니페스트에는 [`.spec`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status) 섹션도 필요하다. {{< note >}} -크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._ +크론잡(CronJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. +이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. +즉, 크론잡(CronJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._ {{< /note >}} ### 스케줄 `.spec.schedule` 은 `.spec` 의 필수 필드이다. -이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다. +이 필드는 `0 * * * *` 또는 `@hourly`와 같은 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아, +해당 잡이 생성 및 실행될 스케줄 시간으로 설정한다. 이 형식은 확장된 "Vixie cron" 스텝(step) 값도 포함한다. 이 내용은 [FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다. @@ -160,13 +157,15 @@ kubectl delete cronjob hello > "2시간마다"라고 지정하고 싶으면, 간단히 `*/2` 를 사용하면 된다. {{< note >}} -스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, 주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다. +스케줄에서 물음표(`?`)는 별표 `*` 와 동일한 의미를 가지며, +주어진 필드에 대해 사용할 수 있는 모든 값을 나타낸다. {{< /note >}} ### 잡 템플릿 `.spec.jobTemplate` 은 잡에 대한 템플릿이며, 이것은 필수 필드다. -이것은 중첩되고 `apiVersion` 이나 `kind` 가 없는 것을 제외하고 [잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다. +이것은 중첩되어(nested) 있고 `apiVersion` 이나 `kind` 가 없다는 것을 제외하면, +[잡](/ko/docs/concepts/workloads/controllers/job/)과 정확히 같은 스키마를 가진다. 잡 `.spec` 을 작성하는 것에 대한 내용은 [잡 명세 작성하기](/ko/docs/concepts/workloads/controllers/job/#잡-사양-작성하기)를 참고한다. ### 시작 기한 @@ -178,10 +177,11 @@ kubectl delete cronjob hello 이 필드를 지정하지 않으면, 잡에 기한이 없다. `.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면, -크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고, +크론잡 컨트롤러는 예상 잡 생성 시각과 현재 시각의 차이를 측정하고, 시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다. -예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다. +예를 들어, `200` 으로 설정되었다면, +예상 잡 생성 시각으로부터 200초까지는 잡이 생성될 수 있다. ### 동시성 정책 @@ -190,8 +190,10 @@ kubectl delete cronjob hello 명세는 다음의 동시성 정책 중 하나만 지정할 수 있다. * `Allow`(기본값): 크론 잡은 동시에 실행되는 잡을 허용한다. -* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다. -* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다. +* `Forbid`: 크론 잡은 동시 실행을 허용하지 않는다. + 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, 크론 잡은 새로운 잡 실행을 건너뛴다. +* `Replace`: 새로운 잡을 실행할 시간이고 이전 잡 실행이 아직 완료되지 않은 경우, + 크론 잡은 현재 실행 중인 잡 실행을 새로운 잡 실행으로 대체한다. 참고로 동시성 정책은 동일한 크론 잡에 의해 생성된 잡에만 적용된다. 크론 잡이 여러 개인 경우, 각각의 잡은 항상 동시에 실행될 수 있다. @@ -205,11 +207,13 @@ kubectl delete cronjob hello {{< caution >}} 스케줄된 시간 동안 잡이 일시 정지되어 있다면 누락된 잡으로 간주한다. -[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, 누락된 잡들이 즉시 스케줄된다. +[시작 기한](#시작-기한) 없이 기존의 크론 잡에 대해 `.spec.suspend` 가 `true` 에서 `false` 로 변경되면, +누락된 잡들이 즉시 스케줄된다. {{< /caution >}} ### 잡 히스토리 한도 `.spec.successfulJobsHistoryLimit` 와 `.spec.failedJobsHistoryLimit` 필드는 선택 사항이다. 이들 필드는 기록을 보관해야 하는 완료 및 실패한 잡의 개수를 지정한다. -기본적으로, 각각 3과 1로 설정된다. 한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다. +기본적으로, 각각 3과 1로 설정된다. +한도를 `0` 으로 설정하는 것은 잡 완료 후에 해당 잡 유형의 기록을 보관하지 않는다는 것이다. diff --git a/content/ko/docs/tasks/job/indexed-parallel-processing-static.md b/content/ko/docs/tasks/job/indexed-parallel-processing-static.md index 512b11758e2..f193d23fc9d 100644 --- a/content/ko/docs/tasks/job/indexed-parallel-processing-static.md +++ b/content/ko/docs/tasks/job/indexed-parallel-processing-static.md @@ -19,7 +19,7 @@ weight: 30 파드 인덱스는 10진수 값을 문자열로 표현한 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}} `batch.kubernetes.io/job-completion-index` 를 통해 사용할 수 있다. 컨테이너화된 태스크 프로세스가 이 인덱스 정보를 가져갈 수 있도록, -[downward API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) +[다운워드(downward) API](/ko/docs/concepts/workloads/pods/downward-api/) 메커니즘을 사용하여 어노테이션의 값을 발행할 수 있다. 편의상, 컨트롤 플레인은 downward API를 자동 설정하여 `JOB_COMPLETION_INDEX` 환경변수에 인덱스를 노출할 수 있도록 한다. diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 7ae472280e5..b1d818ed426 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -39,7 +39,7 @@ weight: 10 [`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) (기본값은 0), [`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec) -(베타 기능, 기본값은 0)를 +(기본값은 0)를 설정할 수도 있다. ### `RollingUpdate` 업데이트 전략으로 데몬셋 생성 diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index fe0263c5385..1a98164bd13 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -6,8 +6,6 @@ title: GPU 스케줄링 description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다. --- - - {{< feature-state state="beta" for_k8s_version="v1.10" >}} @@ -65,7 +63,7 @@ spec: containers: - name: cuda-vector-add # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile - image: "k8s.gcr.io/cuda-vector-add:v0.1" + image: "registry.k8s.io/cuda-vector-add:v0.1" resources: limits: nvidia.com/gpu: 1 # GPU 1개 요청하기 @@ -208,7 +206,7 @@ spec: containers: - name: cuda-vector-add # https://github.com/kubernetes/kubernetes/blob/v1.7.11/test/images/nvidia-cuda/Dockerfile - image: "k8s.gcr.io/cuda-vector-add:v0.1" + image: "registry.k8s.io/cuda-vector-add:v0.1" resources: limits: nvidia.com/gpu: 1 diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index 224dd639021..896f042c03b 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -86,20 +86,12 @@ metadata: name: example-configmap-1-8mbdf7882g ``` -env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. `=` 및 값을 생략하여 로컬 환경 변수로부터 값을 설정할 수도 있다. - -{{< note >}} -로컬 환경 변수 채우기 기능은 꼭 필요한 경우에만 사용하는 것이 좋은데, 이는 패치를 할 수 있는 오버레이가 있는 편이 유지 관리에 더 유리하기 때문이다. 로컬 환경 변수 채우기 기능은 git SHA와 같이 그 값을 쉽게 예측할 수 없는 경우에 유용할 수 있다. -{{< /note >}} - -다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다. +env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다. ```shell # .env 파일 생성 -# BAZ 에는 로컬 환경 변수 $BAZ 의 값이 입력될 것이다 cat <.env FOO=Bar -BAZ EOF cat <./kustomization.yaml @@ -113,7 +105,7 @@ EOF 생성된 컨피그맵은 다음 명령어로 검사할 수 있다. ```shell -BAZ=Qux kubectl kustomize ./ +kubectl kustomize ./ ``` 생성된 컨피그맵은 다음과 같다. @@ -121,11 +113,10 @@ BAZ=Qux kubectl kustomize ./ ```yaml apiVersion: v1 data: - BAZ: Qux FOO: Bar kind: ConfigMap metadata: - name: example-configmap-1-892ghb99c8 + name: example-configmap-1-42cfbf598f ``` {{< note >}} @@ -1020,3 +1011,4 @@ deployment.apps "dev-my-nginx" deleted * [Kubectl 문서](https://kubectl.docs.kubernetes.io) * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 47126cd4f41..9246f79ecb9 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -39,7 +39,7 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range . ``` ``` 10.244.1.0/24 -a00:100::/24 +2001:db8::/64 ``` 단일 IPv4 블록과 단일 IPv6 블록이 할당되어야 한다. @@ -50,8 +50,8 @@ kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range . ``` ``` Hostname: k8s-linuxpool1-34450317-0 -InternalIP: 10.240.0.5 -InternalIP: 2001:1234:5678:9abc::5 +InternalIP: 10.0.0.5 +InternalIP: 2001:db8:10::5 ``` ### 파드 어드레싱 검증 @@ -63,7 +63,7 @@ kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{prin ``` ``` 10.244.1.4 -a00:100::4 +2001:db8::4 ``` `status.podIPs` fieldPath를 통한 다운워드(downward) API로 파드 IP들을 검증할 수도 있다. 다음 스니펫은 컨테이너 내 `MY_POD_IPS` 라는 환경 변수를 통해 파드 IP들을 어떻게 노출시킬 수 있는지 보여준다. @@ -82,7 +82,7 @@ a00:100::4 kubectl exec -it pod01 -- set | grep MY_POD_IPS ``` ``` -MY_POD_IPS=10.244.1.4,a00:100::4 +MY_POD_IPS=10.244.1.4,2001:db8::4 ``` 파드의 IP 주소는 또한 컨테이너 내 `/etc/hosts` 에 적힐 것이다. 다음 커맨드는 이중 스택 파드의 `/etc/hosts` 에 cat을 실행시킨다. 출력 값을 통해 파드의 IPv4 및 IPv6 주소 모두 검증할 수 있다. @@ -99,7 +99,7 @@ fe00::0 ip6-mcastprefix fe00::1 ip6-allnodes fe00::2 ip6-allrouters 10.244.1.4 pod01 -a00:100::4 pod01 +2001:db8::4 pod01 ``` ## 서비스 검증 @@ -161,9 +161,9 @@ metadata: app.kubernetes.io/name: MyApp name: my-service spec: - clusterIP: fd00::5118 + clusterIP: 2001:db8:fd00::5118 clusterIPs: - - fd00::5118 + - 2001:db8:fd00::5118 ipFamilies: - IPv6 ipFamilyPolicy: SingleStack @@ -210,7 +210,7 @@ Type: ClusterIP IP Family Policy: PreferDualStack IP Families: IPv4,IPv6 IP: 10.0.216.242 -IPs: 10.0.216.242,fd00::af55 +IPs: 10.0.216.242,2001:db8:fd00::af55 Port: 80/TCP TargetPort: 9376/TCP Endpoints: @@ -233,6 +233,8 @@ kubectl get svc -l app.kubernetes.io/name: MyApp 서비스가 IPv6 주소 블록에서 `CLUSTER-IP` 주소 및 `EXTERNAL-IP` 주소를 할당받는지 검증한다. 그리고 나서 IP 및 포트로 서비스 접근이 가능한지 검증할 수 있다. ```shell -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-service LoadBalancer 2001:db8:fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s ``` + + 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 da1f9dc6a6d..1b6ae0f36ae 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 @@ -54,31 +54,8 @@ Metrics Server를 실행하는 방법을 보려면 ## php-apache 서버 구동 및 노출 -HorizontalPodAutoscaler 예시에서, -먼저 도커 허브의 `php-apache` 이미지를 베이스로 하는 커스텀 컨테이너 이미지를 만들어 시작점으로 삼을 것이다. -`Dockerfile`은 미리 준비되어 있으며, 내용은 다음과 같다. - -```dockerfile -FROM php:5-apache -COPY index.php /var/www/html/index.php -RUN chmod a+rx index.php -``` - -아래의 코드는 CPU 과부하 연산을 수행하는 간단한 `index.php` 페이지를 정의하며, -이를 이용해 클러스터에 부하를 시뮬레이트한다. - -```php - -``` - -컨테이너 이미지를 만들었다면, -방금 만든 이미지로부터 컨테이너를 실행하는 디플로이먼트를 시작하고, 다음의 매니페스트를 사용하여 디플로이먼트를 +HorizontalPodAutoscaler 시연을 위해, `hpa-example` 이미지를 사용하여 컨테이너를 실행하는 디플로이먼트를 시작하고, +다음의 매니페스트를 사용하여 디플로이먼트를 {{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다. {{< codenew file="application/php-apache.yaml" >}} 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 0839ad95874..e932a2c4dc3 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 @@ -362,3 +362,4 @@ CSR이 다음 두 가지 요구 사항을 충족하는지 확인하는 것이다 활성화하려면 인증 기관(CA)의 키 쌍에 대한 경로와 함께 `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 매개 변수를 컨트롤러 관리자에 전달한다. + diff --git a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md index cf1096aeb6f..33ce4a7afa7 100644 --- a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md +++ b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -31,12 +31,12 @@ source /usr/share/bash-completion/bash_completion 이제 kubectl 자동 완성 스크립트가 모든 셸 세션에서 제공되도록 해야 한다. 이를 수행할 수 있는 두 가지 방법이 있다. {{< tabs name="kubectl_bash_autocompletion" >}} -{{{< tab name="현재 사용자에만 적용" codelang="bash" >}} +{{< tab name="현재 사용자에만 적용" codelang="bash" >}} echo 'source <(kubectl completion bash)' >>~/.bashrc {{< /tab >}} {{< tab name="시스템 전체에 적용" codelang="bash" >}} kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null -{{< /tab >}}} +{{< /tab >}} {{< /tabs >}} kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 자동 완성을 확장할 수 있다. @@ -51,3 +51,7 @@ bash-completion은 `/etc/bash_completion.d` 에 있는 모든 자동 완성 스 {{< /note >}} 두 방법 모두 동일하다. 셸을 다시 로드하면, kubectl 자동 완성 기능이 작동할 것이다. +셸의 현재 세션에서 bash 자동 완성을 활성화하려면 `exec bash`를 실행한다. +```bash +exec bash +``` diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index ce93967a598..fc360d1d065 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -94,7 +94,7 @@ minikube dashboard --url 파드는 제공된 Docker 이미지를 기반으로 한 컨테이너를 실행한다. ```shell - kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4 + kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4 ``` 2. 디플로이먼트 보기 @@ -155,7 +155,7 @@ minikube dashboard --url `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기 원한다는 뜻이다. - `k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를 + `registry.k8s.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를 사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다. 2. 생성한 서비스 살펴보기 @@ -303,3 +303,4 @@ minikube delete * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다. * [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다. * [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. + diff --git a/content/ko/docs/tutorials/security/apparmor.md b/content/ko/docs/tutorials/security/apparmor.md index c454fef9155..f8eff05b434 100644 --- a/content/ko/docs/tutorials/security/apparmor.md +++ b/content/ko/docs/tutorials/security/apparmor.md @@ -6,8 +6,6 @@ content_type: tutorial weight: 10 --- - - {{< feature-state for_k8s_version="v1.4" state="beta" >}} @@ -108,7 +106,7 @@ AppArmor 지원이 포함된 Kubelet (>= v1.4)이면 노드 준비 조건 메시지를 확인하여(이후 릴리스에서는 삭제될 것 같지만) 검증할 수 있다. ```shell -kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}' +kubectl get nodes -o=jsonpath='{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}{"\n"}{end}' ``` ``` gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled @@ -120,10 +118,10 @@ gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor e -## 파드 보안 강화하기 {#securing-a-pod} +## 파드 보안 강화하기 {{< note >}} -AppArmor는 현재 베타라서 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면, +AppArmor는 현재 베타이며, 이 때문에 옵션은 어노테이션 형식으로 지정한다. 일반 사용자 버전이 되면, 어노테이션은 최상위 종류의 필드로 대체될 것이다(자세한 내용은 [일반 사용자 버전으로 업그레이드 방법](#upgrade-path-to-general-availability) 참고) {{< /note >}} @@ -166,7 +164,7 @@ kubectl exec cat /proc/1/attr/current k8s-apparmor-example-deny-write (enforce) ``` -## 예시 {#example} +## 예시 *이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.* @@ -327,9 +325,9 @@ Events: 파드 상태는 Pending이며, 오류 메시지는 `Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded`이다. 이벤트도 동일한 메시지로 기록되었다. -## 관리 {#administration} +## 관리 -### 프로파일과 함께 노드 설정하기 {#setting-up-nodes-with-profiles} +### 프로파일과 함께 노드 설정하기 현재 쿠버네티스는 AppArmor 프로파일을 노드에 적재하기 위한 네이티브 메커니즘을 제공하지 않는다. 프로파일을 설정하는 여러 방법이 있다. 예를 들면 다음과 같다. @@ -348,36 +346,9 @@ Events: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다. -### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy} +### AppArmor 비활성화 -{{< note >}} -파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다. -더 자세한 내용은 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/) 문서를 참고한다. -{{< /note >}} - -만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다. -파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다. - -``` ---enable-admission-plugins=PodSecurityPolicy[,others...] -``` - -AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다. - -```yaml -apparmor.security.beta.kubernetes.io/defaultProfileName: -apparmor.security.beta.kubernetes.io/allowedProfileNames: [,others...] -``` - -기본 프로파일 이름 옵션은 프로파일을 지정하지 않았을 때에 -컨테이너에 기본으로 적용하는 프로파일을 지정한다. -허용하는 프로파일 이름 옵션은 파드 컨테이너가 함께 실행하도록 허용되는 프로파일 목록을 지정한다. -두 옵션을 모두 사용하는 경우, 기본값은 반드시 필요하다. -프로파일은 컨테이너에서 같은 형식으로 지정된다. 전체 사양은 [API 참조](#api-reference)를 찾아본다. - -### AppArmor 비활성화 {#disabling-apparmor} - -클러스터에서 AppArmor 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다. +클러스터에서 AppArmor를 사용하지 않으려면, 커맨드라인 플래그로 비활성화 할 수 있다. ``` --feature-gates=AppArmor=false @@ -392,7 +363,7 @@ AppArmor가 general availability (GA) 상태로 바뀌면 AppArmor 기능을 비활성화하는 옵션은 제거될 것이다. {{}} -## 프로파일 제작 {#authoring-profiles} +## 프로파일 제작 AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까다로울 수 있다. 다행히 이 작업에 도움 되는 도구가 있다. @@ -409,9 +380,9 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나 [AppArmor 실패](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)에서 제공한다. -## API 참조 {#api-reference} +## API 참조 -### 파드 어노테이션 {#pod-annotation} +### 파드 어노테이션 컨테이너를 실행할 프로파일을 지정한다. @@ -420,7 +391,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나 분리된 프로파일은 파드 내에 각 컨테이너로 지정할 수 있다. - **값**: 아래 기술된 프로파일 참조 -### 프로파일 참조 {#profile-reference} +### 프로파일 참조 - `runtime/default`: 기본 런타임 프로파일을 참조한다. - (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고 @@ -434,22 +405,6 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나 다른 어떤 프로파일 참조 형식도 유효하지 않다. -### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations} - -아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기 - -* **키**: `apparmor.security.beta.kubernetes.io/defaultProfileName` -* **값**: 프로파일 참조. 위에 기술됨. - -파드 컨테이너에서 지정을 허용하는 프로파일 목록 지정하기 - -* **키**: `apparmor.security.beta.kubernetes.io/allowedProfileNames` -* **값**: 컴마로 구분된 참조 프로파일 목록(위에 기술함) - - 비록 이스케이프된 쉼표(%2C ',')도 프로파일 이름에서 유효한 문자이지만 - 여기에서 명시적으로 허용하지 않는다. - - - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 227e981e4bf..7617e336856 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -48,7 +48,7 @@ min-kubernetes-server-version: v1.5 작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다. ```shell -kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4 +kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.4 ``` 출력은 다음과 같다. ``` @@ -323,10 +323,10 @@ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort ``` `service.spec.healthCheckNodePort` 필드는 `/healthz`에서 헬스 체크를 제공하는 -모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다. +모든 노드의 포트를 가리킨다. 이것을 테스트할 수 있다. ```shell -kubectl get pod -o wide -l run=source-ip-app +kubectl get pod -o wide -l app=source-ip-app ``` 출력은 다음과 유사하다. ``` 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 2ce20300af6..b961580a734 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,9 @@ 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/#파드의-단계) 참고) -및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에 시작하지 않음을 주의하자. +참고로 `web-1` 파드는 `web-0` 파드가 +_Running_ ([파드의 단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계) 참고) +및 _Ready_ ([파드의 컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-컨디션)에서 `type` 참고) 상태가 되기 전에는 시작되지 않음에 주의한다. ## 스테이트풀셋 안에 파드 @@ -214,6 +215,8 @@ kubectl get pod -w -l app=nginx ```shell kubectl delete pod -l app=nginx +``` +``` pod "web-0" deleted pod "web-1" deleted ``` @@ -334,8 +337,9 @@ web-1 {{< note >}} 위에 curl 명령어로 **403 Forbidden** 아닌 응답을 보려면 -다음을 실행해서 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 -([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함). +다음을 실행하여 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 +([hostPath 볼륨을 사용할 때의 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 +인함). `for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done` @@ -521,7 +525,8 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO ### 롤링 업데이트 -`RollingUpdate` 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다. +`RollingUpdate` 업데이트 전략은 스테이트풀셋의 보장사항을 유지하면서 +스테이트풀셋 내의 모든 파드를 역순으로 업데이트한다. 스테이트풀셋 `web`의 업데이트 전략을 `RollingUpdate`으로 패치하자. @@ -601,9 +606,9 @@ web-0 1/1 Running 0 10s for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done ``` ``` -k8s.gcr.io/nginx-slim:0.8 -k8s.gcr.io/nginx-slim:0.8 -k8s.gcr.io/nginx-slim:0.8 +registry.k8s.io/nginx-slim:0.8 +registry.k8s.io/nginx-slim:0.8 +registry.k8s.io/nginx-slim:0.8 ``` @@ -630,10 +635,10 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda statefulset.apps/web patched ``` -컨테이너의 이미지를 바꾸도록 스테이트풀셋을 또 패치하자. +컨테이너의 이미지를 바꾸도록 스테이트풀셋을 다시 패치한다. ```shell -kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' +kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.7"}]' ``` ``` statefulset.apps/web patched @@ -667,7 +672,7 @@ web-2 1/1 Running 0 18s kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' ``` ``` -k8s.gcr.io/nginx-slim:0.8 +registry.k8s.io/nginx-slim:0.8 ``` 비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은 @@ -708,7 +713,7 @@ web-2 1/1 Running 0 18s kubectl get po web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' ``` ``` -k8s.gcr.io/nginx-slim:0.7 +registry.k8s.io/nginx-slim:0.7 ``` @@ -751,13 +756,14 @@ web-1 1/1 Running 0 18s kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' ``` ``` -k8s.gcr.io/nginx-slim:0.8 +registry.k8s.io/nginx-slim:0.8 ``` `web-1` 는 원래 환경설정으로 복원되었는데 이는 파드의 순번이 partition보다 작기 때문이다. -스테이트풀셋의 `.spec.template`이 갱신되면, 지정된 partition 이상의 순번을 -가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나 +스테이트풀셋의 `.spec.template`이 갱신되면, +지정된 partition 이상의 순번을 가진 모든 파드는 업데이트된다. +미만의 순번을 가진 파드라면 삭제되거나 종료되어 원래 환경설정으로 복원된다. #### 단계적 롤아웃 @@ -807,10 +813,9 @@ web-0 1/1 Running 0 3s for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done ``` ``` -k8s.gcr.io/nginx-slim:0.7 -k8s.gcr.io/nginx-slim:0.7 -k8s.gcr.io/nginx-slim:0.7 - +registry.k8s.io/nginx-slim:0.7 +registry.k8s.io/nginx-slim:0.7 +registry.k8s.io/nginx-slim:0.7 ``` `partition`을 `0`으로 이동하여 스테이트풀셋에서 계속해서 @@ -819,10 +824,12 @@ k8s.gcr.io/nginx-slim:0.7 ### 삭제 시 동작 `OnDelete` 업데이트 전략은 예전 동작(1.6 이하)으로, -이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의 +이 업데이트 전략을 선택하면, +스테이트풀셋 컨트롤러는 스테이트풀셋의 `.spec.template` 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다. 이 전략은 `.spec.template.updateStrategy.type`을 `OnDelete`로 설정하여 선택할 수 있다. + ## 스테이트풀셋 삭제하기 스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다. diff --git a/content/ko/examples/admin/konnectivity/konnectivity-server.yaml b/content/ko/examples/admin/konnectivity/konnectivity-server.yaml index 8d8ef56195d..0f2fe702a03 100644 --- a/content/ko/examples/admin/konnectivity/konnectivity-server.yaml +++ b/content/ko/examples/admin/konnectivity/konnectivity-server.yaml @@ -8,7 +8,7 @@ spec: hostNetwork: true containers: - name: konnectivity-server-container - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.16 + image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.32 command: ["/proxy-server"] args: [ "--logtostderr=true", diff --git a/content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml index ddfb8104cb9..a621a9fb2ac 100644 --- a/content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml +++ b/content/ko/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml @@ -22,7 +22,7 @@ spec: - name: varlog mountPath: /var/log - name: count-agent - image: k8s.gcr.io/fluentd-gcp:1.30 + image: registry.k8s.io/fluentd-gcp:1.30 env: - name: FLUENTD_ARGS value: -c /etc/fluentd-config/fluentd.conf diff --git a/content/ko/examples/admin/sched/pod1.yaml b/content/ko/examples/admin/sched/pod1.yaml index 560b6aa0fb3..7183dd62c0f 100644 --- a/content/ko/examples/admin/sched/pod1.yaml +++ b/content/ko/examples/admin/sched/pod1.yaml @@ -7,4 +7,4 @@ metadata: spec: containers: - name: pod-with-no-annotation-container - image: k8s.gcr.io/pause:2.0 \ No newline at end of file + image: registry.k8s.io/pause:2.0 \ No newline at end of file diff --git a/content/ko/examples/admin/sched/pod2.yaml b/content/ko/examples/admin/sched/pod2.yaml index 2f065efe65f..b78ab64a4bc 100644 --- a/content/ko/examples/admin/sched/pod2.yaml +++ b/content/ko/examples/admin/sched/pod2.yaml @@ -8,4 +8,4 @@ spec: schedulerName: default-scheduler containers: - name: pod-with-default-annotation-container - image: k8s.gcr.io/pause:2.0 + image: registry.k8s.io/pause:2.0 diff --git a/content/ko/examples/admin/sched/pod3.yaml b/content/ko/examples/admin/sched/pod3.yaml index a1b8db32008..66141438291 100644 --- a/content/ko/examples/admin/sched/pod3.yaml +++ b/content/ko/examples/admin/sched/pod3.yaml @@ -8,4 +8,4 @@ spec: schedulerName: my-scheduler containers: - name: pod-with-second-annotation-container - image: k8s.gcr.io/pause:2.0 + image: registry.k8s.io/pause:2.0 diff --git a/content/ko/examples/application/php-apache.yaml b/content/ko/examples/application/php-apache.yaml index 5eb04cfb899..d29d2b91593 100644 --- a/content/ko/examples/application/php-apache.yaml +++ b/content/ko/examples/application/php-apache.yaml @@ -14,7 +14,7 @@ spec: spec: containers: - name: php-apache - image: k8s.gcr.io/hpa-example + image: registry.k8s.io/hpa-example ports: - containerPort: 80 resources: @@ -22,9 +22,7 @@ spec: cpu: 500m requests: cpu: 200m - --- - apiVersion: v1 kind: Service metadata: @@ -36,4 +34,3 @@ spec: - port: 80 selector: run: php-apache - diff --git a/content/ko/examples/application/web/web-parallel.yaml b/content/ko/examples/application/web/web-parallel.yaml index 4eab2dc2066..a6633f476c1 100644 --- a/content/ko/examples/application/web/web-parallel.yaml +++ b/content/ko/examples/application/web/web-parallel.yaml @@ -30,7 +30,7 @@ spec: spec: containers: - name: nginx - image: k8s.gcr.io/nginx-slim:0.8 + image: registry.k8s.io/nginx-slim:0.8 ports: - containerPort: 80 name: web diff --git a/content/ko/examples/application/web/web.yaml b/content/ko/examples/application/web/web.yaml index 37c1fabf9c5..95244cd72b8 100644 --- a/content/ko/examples/application/web/web.yaml +++ b/content/ko/examples/application/web/web.yaml @@ -29,7 +29,7 @@ spec: spec: containers: - name: nginx - image: k8s.gcr.io/nginx-slim:0.8 + image: registry.k8s.io/nginx-slim:0.8 ports: - containerPort: 80 name: web diff --git a/content/ko/examples/application/zookeeper/zookeeper.yaml b/content/ko/examples/application/zookeeper/zookeeper.yaml index 4d893b369bd..0f3f6cf9d18 100644 --- a/content/ko/examples/application/zookeeper/zookeeper.yaml +++ b/content/ko/examples/application/zookeeper/zookeeper.yaml @@ -68,7 +68,7 @@ spec: containers: - name: kubernetes-zookeeper imagePullPolicy: Always - image: "k8s.gcr.io/kubernetes-zookeeper:1.0-3.4.10" + image: "registry.k8s.io/kubernetes-zookeeper:1.0-3.4.10" resources: requests: memory: "1Gi" diff --git a/content/ko/examples/audit/audit-policy.yaml b/content/ko/examples/audit/audit-policy.yaml new file mode 100644 index 00000000000..8267ca00b91 --- /dev/null +++ b/content/ko/examples/audit/audit-policy.yaml @@ -0,0 +1,68 @@ +apiVersion: audit.k8s.io/v1 # 필수사항임. +kind: Policy +# Request Received 단계의 모든 요청에 대해 감사 이벤트를 생성하지 않음. +omitStages: + - "RequestReceived" +rules: + # RequestResponse 수준에서 파드 변경 사항 기록 + - level: RequestResponse + resources: + - group: "" + # 리소스 "파드" 가 RBAC 정책과 부합하는 파드의 하위 리소스에 대한 + # 요청과 일치하지 않음. + resources: ["pods"] + # 메타데이터 수준에서 "pods/log", "pods/status"를 기록함. + - level: Metadata + resources: + - group: "" + resources: ["pods/log", "pods/status"] + + # "controller-leader" 라는 컨피그맵에 요청을 기록하지 않음." + - level: None + resources: + - group: "" + resources: ["configmaps"] + resourceNames: ["controller-leader"] + + # 엔드포인트 또는 서비스의 "system:kube-proxy"에 의한 감시 요청 기록하지 않음. + - level: None + users: ["system:kube-proxy"] + verbs: ["watch"] + resources: + - group: "" # 핵심 API 그룹 + resources: ["endpoints", "services"] + + # 인증된 요청을 특정 리소스가 아닌 URL 경로에 기록하지 않음. + - level: None + userGroups: ["system:authenticated"] + nonResourceURLs: + - "/api*" # 와일드카드 매칭(wildcard matching). + - "/version" + + # kube-system에 컨피그맵 변경 사항의 요청 본문을 기록함. + - level: Request + resources: + - group: "" # 핵심 API 그룹 + resources: ["configmaps"] + # 이 정책은 "kube-system" 네임스페이스의 리소스에만 적용됨. + # 빈 문자열 "" 은 네임스페이스가 없는 리소스를 선택하는데 사용할 수 있음. + namespaces: ["kube-system"] + + # 메타데이터 수준에서 다른 모든 네임스페이스의 컨피그맵과 시크릿 변경 사항을 기록함. + - level: Metadata + resources: + - group: "" # 핵심 API 그룹 + resources: ["secrets", "configmaps"] + + # 요청 수준에서 코어 및 확장에 있는 다른 모든 리소스를 기록함. + - level: Request + resources: + - group: "" # 핵심 API 그룹 + - group: "extensions" # 그룹의 버전을 기재하면 안 된다. + + # 메타데이터 수준에서 다른 모든 요청을 기록하기 위한 모든 수집 정책. + - level: Metadata + # 이 정책에 해당하는 감시자와 같은 장기 실행 요청은 + # RequestReceived에서 감사 이벤트를 생성하지 않음. + omitStages: + - "RequestReceived" diff --git a/content/ko/examples/controllers/job-pod-failure-policy-example.yaml b/content/ko/examples/controllers/job-pod-failure-policy-example.yaml new file mode 100644 index 00000000000..6e846d9ecd9 --- /dev/null +++ b/content/ko/examples/controllers/job-pod-failure-policy-example.yaml @@ -0,0 +1,28 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: job-pod-failure-policy-example +spec: + completions: 12 + parallelism: 3 + template: + spec: + restartPolicy: Never + containers: + - name: main + image: docker.io/library/bash:5 + command: ["bash"] # FailJob 액션을 트리거시키는 버그를 만들어내는 예제 명령어 + args: + - -c + - echo "Hello world!" && sleep 5 && exit 42 + backoffLimit: 6 + podFailurePolicy: + rules: + - action: FailJob + onExitCodes: + containerName: main # 선택 사항 + operator: In # [In / NotIn] 중 하나 + values: [42] + - action: Ignore # [Ignore, FailJob, Count] 중 하나 + onPodConditions: + - type: DisruptionTarget # 파드의 중단을 나타냄 diff --git a/content/ko/examples/debug/node-problem-detector-configmap.yaml b/content/ko/examples/debug/node-problem-detector-configmap.yaml index 168714f7539..cbdc783414e 100644 --- a/content/ko/examples/debug/node-problem-detector-configmap.yaml +++ b/content/ko/examples/debug/node-problem-detector-configmap.yaml @@ -23,7 +23,7 @@ spec: hostNetwork: true containers: - name: node-problem-detector - image: k8s.gcr.io/node-problem-detector:v0.1 + image: registry.k8s.io/node-problem-detector:v0.1 securityContext: privileged: true resources: diff --git a/content/ko/examples/debug/node-problem-detector.yaml b/content/ko/examples/debug/node-problem-detector.yaml index 6ffa19bcc3a..f106c327efc 100644 --- a/content/ko/examples/debug/node-problem-detector.yaml +++ b/content/ko/examples/debug/node-problem-detector.yaml @@ -23,7 +23,7 @@ spec: hostNetwork: true containers: - name: node-problem-detector - image: k8s.gcr.io/node-problem-detector:v0.1 + image: registry.k8s.io/node-problem-detector:v0.1 securityContext: privileged: true resources: diff --git a/content/ko/examples/pods/inject/dapi-envars-container.yaml b/content/ko/examples/pods/inject/dapi-envars-container.yaml index 55bd4dd263a..4267053a069 100644 --- a/content/ko/examples/pods/inject/dapi-envars-container.yaml +++ b/content/ko/examples/pods/inject/dapi-envars-container.yaml @@ -5,7 +5,7 @@ metadata: spec: containers: - name: test-container - image: k8s.gcr.io/busybox:1.24 + image: registry.k8s.io/busybox:1.24 command: [ "sh", "-c"] args: - while true; do diff --git a/content/ko/examples/pods/inject/dapi-envars-pod.yaml b/content/ko/examples/pods/inject/dapi-envars-pod.yaml index 071fa82bb3b..d5a646e0877 100644 --- a/content/ko/examples/pods/inject/dapi-envars-pod.yaml +++ b/content/ko/examples/pods/inject/dapi-envars-pod.yaml @@ -5,7 +5,7 @@ metadata: spec: containers: - name: test-container - image: k8s.gcr.io/busybox + image: registry.k8s.io/busybox command: [ "sh", "-c"] args: - while true; do diff --git a/content/ko/examples/pods/inject/dapi-volume-resources.yaml b/content/ko/examples/pods/inject/dapi-volume-resources.yaml index ecb231e0cf9..5b52bf8448f 100644 --- a/content/ko/examples/pods/inject/dapi-volume-resources.yaml +++ b/content/ko/examples/pods/inject/dapi-volume-resources.yaml @@ -5,7 +5,7 @@ metadata: spec: containers: - name: client-container - image: k8s.gcr.io/busybox:1.24 + image: registry.k8s.io/busybox:1.24 command: ["sh", "-c"] args: - while true; do diff --git a/content/ko/examples/pods/inject/dapi-volume.yaml b/content/ko/examples/pods/inject/dapi-volume.yaml index 0f0a9f2e5cc..682098d27f3 100644 --- a/content/ko/examples/pods/inject/dapi-volume.yaml +++ b/content/ko/examples/pods/inject/dapi-volume.yaml @@ -12,7 +12,7 @@ metadata: spec: containers: - name: client-container - image: k8s.gcr.io/busybox + image: registry.k8s.io/busybox command: ["sh", "-c"] args: - while true; do diff --git a/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml index 10d3056f2d2..cb8c5650b08 100644 --- a/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml +++ b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -29,4 +29,4 @@ spec: - key-2 containers: - name: with-node-affinity - image: k8s.gcr.io/pause:2.0 + image: registry.k8s.io/pause:2.0 diff --git a/content/ko/examples/pods/pod-with-node-affinity.yaml b/content/ko/examples/pods/pod-with-node-affinity.yaml index ebc6f144903..5fedc554bfd 100644 --- a/content/ko/examples/pods/pod-with-node-affinity.yaml +++ b/content/ko/examples/pods/pod-with-node-affinity.yaml @@ -23,4 +23,4 @@ spec: - another-node-label-value containers: - name: with-node-affinity - image: k8s.gcr.io/pause:2.0 \ No newline at end of file + image: registry.k8s.io/pause:2.0 \ No newline at end of file diff --git a/content/ko/examples/pods/pod-with-pod-affinity.yaml b/content/ko/examples/pods/pod-with-pod-affinity.yaml index 6d075e08608..1a4fd74fd7a 100644 --- a/content/ko/examples/pods/pod-with-pod-affinity.yaml +++ b/content/ko/examples/pods/pod-with-pod-affinity.yaml @@ -26,4 +26,4 @@ spec: topologyKey: topology.kubernetes.io/zone containers: - name: with-pod-affinity - image: k8s.gcr.io/pause:2.0 + image: registry.k8s.io/pause:2.0 diff --git a/content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml b/content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml index 98823f9d869..12b117a8145 100644 --- a/content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml +++ b/content/ko/examples/pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml @@ -23,4 +23,4 @@ spec: - zoneC containers: - name: pause - image: k8s.gcr.io/pause:3.1 \ No newline at end of file + image: registry.k8s.io/pause:3.1 \ No newline at end of file diff --git a/content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml b/content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml index a0a41188ec3..02d2c6ca406 100644 --- a/content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml +++ b/content/ko/examples/pods/topology-spread-constraints/one-constraint.yaml @@ -14,4 +14,4 @@ spec: foo: bar containers: - name: pause - image: k8s.gcr.io/pause:3.1 \ No newline at end of file + image: registry.k8s.io/pause:3.1 \ No newline at end of file diff --git a/content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml b/content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml index aa142b7abbd..c1111951559 100644 --- a/content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml +++ b/content/ko/examples/pods/topology-spread-constraints/two-constraints.yaml @@ -20,4 +20,4 @@ spec: foo: bar containers: - name: pause - image: k8s.gcr.io/pause:3.1 \ No newline at end of file + image: registry.k8s.io/pause:3.1 \ No newline at end of file diff --git a/content/ko/examples/pods/user-namespaces-stateless.yaml b/content/ko/examples/pods/user-namespaces-stateless.yaml new file mode 100644 index 00000000000..d254259f66c --- /dev/null +++ b/content/ko/examples/pods/user-namespaces-stateless.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: userns +spec: + hostUsers: false + containers: + - name: shell + command: ["sleep", "infinity"] + image: debian diff --git a/content/ko/releases/version-skew-policy.md b/content/ko/releases/version-skew-policy.md index 7640bd18595..af0594e3d89 100644 --- a/content/ko/releases/version-skew-policy.md +++ b/content/ko/releases/version-skew-policy.md @@ -1,11 +1,11 @@ --- - - - - - - - +# reviewers: +# - sig-api-machinery +# - sig-architecture +# - sig-cli +# - sig-cluster-lifecycle +# - sig-node +# - sig-release title: 버전 차이(skew) 정책 type: docs description: > @@ -23,7 +23,7 @@ description: > 쿠버네티스 버전은 **x.y.z** 로 표현되는데, 여기서 **x** 는 메이저 버전, **y** 는 마이너 버전, **z** 는 패치 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/) 용어에 따른 것이다. 자세한 내용은 [쿠버네티스 릴리스 버전](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning)을 참조한다. -쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다. +쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 [1년간의 패치 지원](/releases/patch-releases/#support-period)을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다. 보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다. 패치 릴리스는 각 브랜치별로 [정기적인 주기](/releases/patch-releases/#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다. diff --git a/content/pt-br/docs/concepts/cluster-administration/certificates.md b/content/pt-br/docs/concepts/cluster-administration/certificates.md index 660471eb3d6..9d23774b575 100644 --- a/content/pt-br/docs/concepts/cluster-administration/certificates.md +++ b/content/pt-br/docs/concepts/cluster-administration/certificates.md @@ -103,7 +103,7 @@ manualmente através `easyrsa`, `openssl` ou `cfssl`. openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf + -extensions v3_ext -extfile csr.conf -sha256 1. Veja o certificado: openssl x509 -noout -text -in ./server.crt diff --git a/content/pt-br/docs/reference/glossary/csi.md b/content/pt-br/docs/reference/glossary/csi.md new file mode 100644 index 00000000000..51f71544904 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/csi.md @@ -0,0 +1,22 @@ +--- +title: Interface de Armazenamento de Contêiner +id: csi +date: 2018-06-25 +full_link: /pt-br/docs/concepts/storage/volumes/#csi +short_description: > + A Interface de Armazenamento de Contêiner (_Container Storage Interface_, CSI) define um padrão de interface para expor sistemas de armazenamento a contêineres. + +aka: +tags: +- storage +--- + A Interface de Armazenamento de Contêiner (_Container Storage Interface_, CSI) define um padrão de interface para expor sistemas de armazenamento a contêineres. + + + +O CSI permite que os fornecedores criem plugins personalizados de armazenamento para o Kubernetes sem adicioná-los ao repositório Kubernetes (plugins fora da árvore). +Para usar um driver CSI de um provedor de armazenamento, você deve primeiro [instalá-lo no seu cluster](https://kubernetes-csi.github.io/docs/deploying.html). +Você poderá então criar uma {{< glossary_tooltip text="Classe de Armazenamento" term_id="storage-class" >}} que use esse driver CSI. + +* [CSI na documentação do Kubernetes](/pt-br/docs/concepts/storage/volumes/#csi) +* [Lista de drivers CSI disponíveis](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/pt-br/docs/reference/issues-security/_index.md b/content/pt-br/docs/reference/issues-security/_index.md new file mode 100644 index 00000000000..df968fbd085 --- /dev/null +++ b/content/pt-br/docs/reference/issues-security/_index.md @@ -0,0 +1,4 @@ +--- +title: Problemas e Alertas de Segurança do Kubernetes +weight: 70 +--- \ No newline at end of file diff --git a/content/zh-cn/blog/_posts/2018-07-12-resizing-persistent-volumes-using-kubernetes.md b/content/zh-cn/blog/_posts/2018-07-12-resizing-persistent-volumes-using-kubernetes.md new file mode 100644 index 00000000000..5f72b85afec --- /dev/null +++ b/content/zh-cn/blog/_posts/2018-07-12-resizing-persistent-volumes-using-kubernetes.md @@ -0,0 +1,159 @@ +--- +layout: blog +title: '使用 Kubernetes 调整 PersistentVolume 的大小' +date: 2018-07-12 +slug: resize-pv-using-k8s +--- + + + +**作者**: Hemant Kumar (Red Hat) + + +**编者注：这篇博客是[深度文章系列](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/)的一部分，这个系列介绍了 Kubernetes 1.11 中的新增特性** + +在 Kubernetes v1.11 中，持久化卷扩展功能升级为 Beta。 +该功能允许用户通过编辑 `PersistentVolumeClaim`（PVC）对象，轻松调整已存在数据卷的大小。 +用户不再需要手动与存储后端交互，或者删除再重建 PV 和 PVC 对象来增加卷的大小。缩减持久化卷暂不支持。 + +卷扩展是在 v1.8 版本中作为 Alpha 功能引入的， +在 v1.11 之前的版本都需要开启特性门控 `ExpandPersistentVolumes` 以及准入控制器 `PersistentVolumeClaimResize`（防止扩展底层存储供应商不支持调整大小的 PVC）。 +在 Kubernetes v1.11+ 中，特性门控和准入控制器都是默认启用的。 + +虽然该功能默认是启用的，但集群管理员必须选择允许用户调整数据卷的大小。 +Kubernetes v1.11 为以下树内卷插件提供了卷扩展支持： +AWS-EBS、GCE-PD、Azure Disk、Azure File、Glusterfs、Cinder、Portworx 和 Ceph RBD。 +一旦管理员确定底层供应商支持卷扩展， +就可以通过在 `StorageClass` 对象中设置 `allowVolumeExpansion` 字段为 `true`，让用户可以使用该功能。 +只有由这个 `StorageClass` 创建的 PVC 才能触发卷扩展。 + +``` +~> cat standard.yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: standard +parameters: + type: pd-standard +provisioner: kubernetes.io/gce-pd +allowVolumeExpansion: true +reclaimPolicy: Delete +``` + +从这个 `StorageClass` 创建的任何 PVC 都可以被编辑（如下图所示）以请求更多的空间。 +Kubernetes 会将存储字段的变化解释为对更多空间的请求，并触发卷大小的自动调整。 + +![PVC StorageClass](/images/blog/2018-07-12-resizing-persistent-volumes-using-kubernetes/pvc-storageclass.png) + + +## 文件系统扩展 {#file-system-expansion} + +如 GCE-PD、AWS-EBS、Azure Disk、Cinder 和 Ceph RBD 这类的块存储卷类型， +通常需要在扩展卷的额外空间被 Pod 使用之前进行文件系统扩展。 +Kubernetes 会在引用数据卷的 Pod 重新启动时自动处理这个问题。 + +网络附加文件系统（如 Glusterfs 和 Azure File）可以被扩展，而不需要重新启动引用的 Pod， +因为这些系统不需要特殊的文件系统扩展。 + +文件系统扩展必须通过终止使用该卷的 Pod 来触发。更具体地说： + +* 编辑 PVC 以请求更多的空间。 +* 一旦底层卷被存储提供商扩展后， PersistentVolume 对象将反映更新的大小，PVC 会有 `FileSystemResizePending` 状态。 + +你可以通过运行 `kubectl get pvc -o yaml` 来验证这一点。 + +``` +~> kubectl get pvc myclaim -o yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myclaim + namespace: default + uid: 02d4aa83-83cd-11e8-909d-42010af00004 +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 14Gi + storageClassName: standard + volumeName: pvc-xxx +status: + capacity: + storage: 9G + conditions: + - lastProbeTime: null + lastTransitionTime: 2018-07-11T14:51:10Z + message: Waiting for user to (re-)start a pod to finish file system resize of + volume on node. + status: "True" + type: FileSystemResizePending + phase: Bound +``` + +* 一旦 PVC 具有 `FileSystemResizePending` 状态 ，就可以重启使用该 PVC 的 Pod 以完成节点上的文件系统大小调整。 +重新启动可以通过删除并重新创建 Pod，或者通过 Deployment 缩容后再扩容来实现。 +* 一旦文件系统的大小调整完成，PVC 将自动更新以展现新的大小。 + +在扩展文件系统时遇到的任何错误都应作为 Pod 的事件而存在。 + + +## 在线文件系统扩展 {#online-file-system-expansion} + +Kubernetes v1.11 里还引入了一个名为在线文件系统扩展的 Alpha 功能。 +该功能可以让一个正在被 Pod 使用的卷进行文件系统扩展。 +因为这个功能是 Alpha 阶段，所以它需要启用特性门控 `ExpandInUsePersistentVolumes`。 +树内卷插件 GCE-PD、AWS-EBS、Cinder 和 Ceph RBD 都支持该功能。 +当这个功能被启用时，引用调整后的卷的 Pod 不需要被重新启动。 +相反，在使用中文件系统将作为卷扩展的一部分自动调整大小。 +文件系统的扩展是在一个 Pod 引用调整后的卷时才发生的，所以如果没有引用卷的 Pod 在运行，文件系统的扩展就不会发生。 + + +## 更多信息 {#how-can-i-learn-more} + +在这里查看有关这一特性的其他文档： +https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes/ \ No newline at end of file diff --git a/content/zh-cn/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md b/content/zh-cn/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md index e7384b78b29..56ab64ab547 100644 --- a/content/zh-cn/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md +++ b/content/zh-cn/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md @@ -39,7 +39,7 @@ This strategy worked. It worked so well that the project quickly scaled past its ## The Work --> -##　工作 +## 工作 + -这里，很重要的一点是，控制器做出了一些变更以使得事物更接近你的期望状态， +这里的重点是，控制器做出了一些变更以使得事物更接近你的期望状态， 之后将当前状态报告给集群的 API 服务器。 其他控制回路可以观测到所汇报的数据的这种变化并采取其各自的行动。 diff --git a/content/zh-cn/docs/concepts/architecture/cri.md b/content/zh-cn/docs/concepts/architecture/cri.md index 9ab03d9d099..c80a2af5c6f 100644 --- a/content/zh-cn/docs/concepts/architecture/cri.md +++ b/content/zh-cn/docs/concepts/architecture/cri.md @@ -64,7 +64,7 @@ and doesn't register as a node. 系统组件的日志记录集群中发生的事件，这对于调试非常有用。 你可以配置日志的精细度，以展示更多或更少的细节。 @@ -34,16 +36,16 @@ generates log messages for the Kubernetes system components. For more information about klog configuration, see the [Command line tool reference](/docs/reference/command-line-tools-reference/). --> -klog 是 Kubernetes 的日志库。 -[klog](https://github.com/kubernetes/klog) +klog 是 Kubernetes 的日志库。 +[klog](https://github.com/kubernetes/klog) 为 Kubernetes 系统组件生成日志消息。 有关 klog 配置的更多信息，请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。 Kubernetes 正在进行简化其组件日志的努力。下面的 klog 命令行参数从 Kubernetes 1.23 @@ -63,18 +65,17 @@ Kubernetes 正在进行简化其组件日志的努力。下面的 klog 命令行 - `--stderrthreshold` 输出总会被写到标准错误输出（stderr）之上，无论输出格式如何。 对输出的重定向将由调用 Kubernetes 组件的软件来处理。 这一软件可以是 POSIX Shell 或者类似 systemd 这样的工具。 在某些场合下，例如对于无发行主体的（distroless）容器或者 Windows 系统服务， -这些替代方案都是不存在的。那么你可以使用 +这些替代方案都是不存在的。那么你可以使用 [`kube-log-runner`](https://github.com/kubernetes/kubernetes/blob/d2a8a81639fcff8d1221b900f66d28361a170654/staging/src/k8s.io/component-base/logs/kube-log-runner/README.md) 可执行文件来作为 Kubernetes 的封装层，完成对输出的重定向。 在很多 Kubernetes 基础镜像中，都包含一个预先构建的可执行程序。 @@ -113,7 +114,7 @@ This table shows how `kube-log-runner` invocations correspond to shell redirecti An example of the traditional klog native format: --> -### klog 输出 +### klog 输出 {#klog-output} 传统的 klog 原生格式示例： @@ -134,13 +135,14 @@ which has a line break. -### 结构化日志 +### 结构化日志 {#structured-logging} {{< feature-state for_k8s_version="v1.23" state="beta" >}} {{< warning >}} @@ -151,17 +153,18 @@ Log formatting and value serialization are subject to change. {{< /warning>}} 结构化日志记录旨在日志消息中引入统一结构，以便以编程方式提取信息。 你可以方便地用更小的开销来处理结构化日志。 生成日志消息的代码决定其使用传统的非结构化的 klog 还是结构化的日志。 默认的结构化日志消息是以文本形式呈现的，其格式与传统的 klog 保持向后兼容： @@ -195,7 +198,7 @@ second line.} -### 上下文日志 +### 上下文日志 {#contextual-logging} {{< feature-state for_k8s_version="v1.24" state="alpha" >}} @@ -203,17 +206,17 @@ second line.} Contextual logging builds on top of structured logging. It is primarily about how developers use logging calls: code based on that concept is more flexible and supports additional use cases as described in the [Contextual Logging -KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging). +KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging). --> 上下文日志建立在结构化日志之上。 它主要是关于开发人员如何使用日志记录调用：基于该概念的代码将更加灵活， -并且支持在[结构化日志 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging) +并且支持在[结构化日志 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging) 中描述的额外用例。 如果开发人员在他们的组件中使用额外的函数，比如 `WithValues` 或 `WithName`， 那么日志条目将会包含额外的信息，这些信息会被调用者传递给函数。 @@ -224,7 +227,7 @@ disabled by default. The infrastructure for this was added in 1.24 without modifying components. The [`component-base/logs/example`](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go) command demonstrates how to use the new logging calls and how a component -behaves that supports contextual logging. +behaves that supports contextual logging. --> 目前这一特性是由 `StructuredLogging` 特性门控所控制的，默认关闭。 这个基础设施是在 1.24 中被添加的，并不需要修改组件。 @@ -271,15 +274,17 @@ I0404 18:03:31.171962 452150 logger.go:95] "another runtime" duration="1m0s" -### JSON 日志格式 +### JSON 日志格式 {#json-log-format} {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< warning >}} @@ -298,6 +303,7 @@ Example of JSON log format (pretty printed): --> `--logging-format=json` 参数将日志格式从 klog 原生格式改为 JSON 格式。 JSON 日志格式示例（美化输出）： + ```json { "ts": 1580306777.04728, @@ -322,12 +328,13 @@ Keys with special meaning: List of components currently supporting JSON format: --> 具有特殊意义的 key： + * `ts` - Unix 时间风格的时间戳（必选项，浮点值） * `v` - 精细度（仅用于 info 级别，不能用于错误信息，整数） * `err` - 错误字符串（可选项，字符串） * `msg` - 消息（必选项，字符串） -当前支持JSON格式的组件列表： +当前支持 JSON 格式的组件列表： * {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} * {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} @@ -337,10 +344,11 @@ List of components currently supporting JSON format: -### 日志精细度级别 +### 日志精细度级别 {#log-verbosity-level} 参数 `-v` 控制日志的精细度。增大该值会增大日志事件的数量。 减小该值可以减小日志事件的数量。增大精细度会记录更多的不太严重的事件。 @@ -356,7 +364,7 @@ that do not run in a container. For example: * The kubelet and {{}} do not run in containers. --> -### 日志位置 +### 日志位置 {#log-location} 有两种类型的系统组件：运行在容器中的组件和不运行在容器中的组件。例如： @@ -377,7 +385,7 @@ The `logrotate` tool rotates logs daily, or once the log size is greater than 10 容器中的系统组件总是绕过默认的日志记录机制，写入 `/var/log` 目录下的 `.log` 文件。 与容器日志类似，你应该轮转 `/var/log` 目录下系统组件日志。 在 `kube-up.sh` 脚本创建的 Kubernetes 集群中，日志轮转由 `logrotate` 工具配置。 - `logrotate` 工具，每天或者当日志大于 100MB 时，轮转日志。 +`logrotate` 工具，每天或者当日志大于 100MB 时，轮转日志。 ## {{% heading "whatsnext" %}} diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md index 2487cdf851e..02a742a418f 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md @@ -17,7 +17,8 @@ weight: 70 -## Kubernetes 中组件的指标 +## Kubernetes 中组件的指标 {#metrics-in-kubernetes} 在大多数情况下，可以通过 HTTP 访问组件的 `/metrics` 端点来获取组件的度量值。 对于那些默认情况下不暴露端点的组件，可以使用 `--bind-address` 标志启用。 @@ -51,13 +53,17 @@ Examples of those components: * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 在生产环境中，你可能需要配置 [Prometheus 服务器](https://prometheus.io/) 或 某些其他指标搜集器以定期收集这些指标，并使它们在某种时间序列数据库中可用。 @@ -96,7 +102,7 @@ Stable metrics are guaranteed to not change. This means: Deprecated metrics are slated for deletion, but are still available for use. These metrics include an annotation about the version in which they became deprecated. --> -## 指标生命周期 +## 指标生命周期 {#metric-lifecycle} Alpha 指标 → 稳定的指标 → 弃用的指标 → 隐藏的指标 → 删除的指标 @@ -137,7 +143,8 @@ For example: ``` @@ -149,13 +156,21 @@ Deleted metrics are no longer published and cannot be used. ## 显示隐藏指标 {#show-hidden-metrics} @@ -174,10 +189,13 @@ Take metric `A` as an example, here assumed that `A` is deprecated in 1.n. Accor * 在版本 `1.n` 中，这个指标已经弃用，且默认情况下可以生成。 * 在版本 `1.n+1` 中，这个指标默认隐藏，可以通过命令行参数 `show-hidden-metrics-for-version=1.n` 来再度生成。 @@ -189,13 +207,20 @@ If you're upgrading from release `1.12` to `1.13`, but still depend on a metric -## 禁用加速器指标 +## 禁用加速器指标 {#disable-accelerator-metrics} kubelet 通过 cAdvisor 收集加速器指标。为了收集这些指标，对于 NVIDIA GPU 之类的加速器， kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结构更改（例如更新驱动程序）， @@ -213,19 +238,20 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结 ### kube-controller-manager metrics -Controller manager metrics provide important insight into the performance and health of the controller manager. -These metrics include common Go language runtime metrics such as go_routine count and controller specific metrics such as -etcd request latencies or Cloudprovider (AWS, GCE, OpenStack) API latencies that can be used -to gauge the health of a cluster. +Controller manager metrics provide important insight into the performance and health of the +controller manager. These metrics include common Go language runtime metrics such as go_routine +count and controller specific metrics such as etcd request latencies or Cloudprovider (AWS, GCE, +OpenStack) API latencies that can be used to gauge the health of a cluster. -Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations for GCE, AWS, Vsphere and OpenStack. +Starting from Kubernetes 1.7, detailed Cloudprovider metrics are available for storage operations +for GCE, AWS, Vsphere and OpenStack. These metrics can be used to monitor health of persistent volume operations. For example, for GCE these metrics are called: --> -## 组件指标 +## 组件指标 {#component-metrics} -### kube-controller-manager 指标 +### kube-controller-manager 指标 {#kube-controller-manager-metrics} 控制器管理器指标可提供有关控制器管理器性能和运行状况的重要洞察。 这些指标包括通用的 Go 语言运行时指标（例如 go_routine 数量）和控制器特定的度量指标， @@ -253,7 +279,10 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} {{< feature-state for_k8s_version="v1.21" state="beta" >}} 调度器会暴露一些可选的指标，报告所有运行中 Pods 所请求的资源和期望的约束值。 这些指标可用来构造容量规划监控面板、访问调度约束的当前或历史数据、 @@ -261,7 +290,9 @@ The scheduler exposes optional metrics that reports the requested resources and 与其请求值进行比较。 一旦 Pod 进入完成状态（其 `restartPolicy` 为 `Never` 或 `OnFailure`，且 其处于 `Succeeded` 或 `Failed` Pod 阶段，或者已经被删除且所有容器都具有 @@ -301,7 +336,9 @@ endpoint on the scheduler. You must use the `-show-hidden-metrics-for-version=1. ## 禁用指标 {#disabling-metrics} @@ -312,7 +349,9 @@ You can explicitly turn off metrics via command line flag `--disabled-metrics`. ## 指标顺序性保证 {#metric-cardinality-enforcement} @@ -322,22 +361,31 @@ Metrics with unbounded dimensions could cause memory issues in the components th 最终的格式看起来会是这样： -`--allow-label-value <指标名称>,<标签名称>='<可用值1>,<可用值2>...', <指标名称2>,<标签名称>='<可用值1>, <可用值2>...', ...`. + +``` +--allow-label-value <指标名称>,<标签名称>='<可用值1>,<可用值2>...', <指标名称2>,<标签名称>='<可用值1>, <可用值2>...', ... +``` 下面是一个例子： -`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'` +```none +--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday' +``` ## {{% heading "whatsnext" %}} * 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) diff --git a/content/zh-cn/docs/concepts/containers/_index.md b/content/zh-cn/docs/concepts/containers/_index.md index de66ab39eab..96cd55db9d1 100644 --- a/content/zh-cn/docs/concepts/containers/_index.md +++ b/content/zh-cn/docs/concepts/containers/_index.md @@ -3,7 +3,6 @@ title: "容器" weight: 40 description: 打包应用及其运行依赖环境的技术。 content_type: concept -no_list: true --- @@ -14,6 +13,11 @@ run it. Containers decouple applications from underlying host infrastructure. This makes deployment easier in different cloud or OS environments. + +Each {{< glossary_tooltip text="node" term_id="node" >}} in a Kubernetes +cluster runs the containers that form the +[Pods](/docs/concepts/workloads/pods/) assigned to that node. +Containers in a Pod are co-located and co-scheduled to run on the same node. --> 每个运行的容器都是可重复的； 包含依赖环境在内的标准，意味着无论你在哪里运行它都会得到相同的行为。 @@ -21,6 +25,10 @@ This makes deployment easier in different cloud or OS environments. 容器将应用程序从底层的主机设施中解耦。 这使得在不同的云或 OS 环境中部署更加容易。 +Kubernetes 集群中的每个{{< glossary_tooltip text="节点" term_id="node" >}}都会运行容器， +这些容器构成分配给该节点的 [Pod](/zh-cn/docs/concepts/workloads/pods/)。 +单个 Pod 中的容器会在共同调度下，于同一位置运行在相同的节点上。 + ## 容器镜像 {#container-images} [容器镜像](/zh-cn/docs/concepts/containers/images/)是一个随时可以运行的软件包， 包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。 -根据设计，容器是不可变的：你不能更改已经运行的容器的代码。 -如果有一个容器化的应用程序需要修改，则需要构建包含更改的新镜像，然后再基于新构建的镜像重新运行容器。 +容器旨在设计成无状态且[不可变的](https://glossary.cncf.io/immutable-infrastructure/)： +你不应更改已经运行的容器的代码。如果有一个容器化的应用程序需要修改， +正确的流程是：先构建包含更改的新镜像，再基于新构建的镜像重新运行容器。 ## 容器运行时 {#container-runtimes} {{< glossary_definition term_id="container-runtime" length="all" >}} -## {{% heading "whatsnext" %}} +通常，你可以允许集群为一个 Pod 选择其默认的容器运行时。如果你需要在集群中使用多个容器运行时， +你可以为一个 Pod 指定 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)， +以确保 Kubernetes 会使用特定的容器运行时来运行这些容器。 -* 进一步阅读[容器镜像](/zh-cn/docs/concepts/containers/images/) -* 进一步阅读 [Pods](/zh-cn/docs/concepts/workloads/pods/) - - +你还可以通过 RuntimeClass，使用相同的容器运行时，但使用不同设定的配置来运行不同的 Pod。 diff --git a/content/zh-cn/docs/concepts/containers/runtime-class.md b/content/zh-cn/docs/concepts/containers/runtime-class.md index 297fe4d57b7..d3743667da6 100644 --- a/content/zh-cn/docs/concepts/containers/runtime-class.md +++ b/content/zh-cn/docs/concepts/containers/runtime-class.md @@ -2,14 +2,16 @@ title: 容器运行时类（Runtime Class） content_type: concept weight: 30 +hide_summary: true # 单独在章节索引中列出 --- @@ -74,7 +76,7 @@ The configurations available through RuntimeClass are Container Runtime Interfac implementation dependent. See the corresponding documentation ([below](#cri-configuration)) for your CRI implementation for how to configure. --> -RuntimeClass 的配置依赖于 运行时接口（CRI）的实现。 +RuntimeClass 的配置依赖于运行时接口（CRI）的实现。 根据你使用的 CRI 实现，查阅相关的文档（[下方](#cri-configuration)）来了解如何配置。 {{< note >}} @@ -84,7 +86,7 @@ that all nodes are configured the same way with respect to container runtimes). heterogeneous node configurations, see [Scheduling](#scheduling) below. --> RuntimeClass 假设集群中的节点配置是同构的（换言之，所有的节点在容器运行时方面的配置是相同的）。 -如果需要支持异构节点，配置方法请参阅下面的 [调度](#scheduling)。 +如果需要支持异构节点，配置方法请参阅下面的[调度](#scheduling)。 {{< /note >}} -这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 pod。 +这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 Pod。 如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler， -那么 pod 将会进入 `Failed` 终止[阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 +那么 Pod 将会进入 `Failed` 终止[阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 你可以查看相应的[事件](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)， 获取执行过程中的错误信息。 @@ -243,7 +245,6 @@ By specifying the `scheduling` field for a RuntimeClass, you can set constraints ensure that Pods running with this RuntimeClass are scheduled to nodes that support it. If `scheduling` is not set, this RuntimeClass is assumed to be supported by all nodes. --> - 通过为 RuntimeClass 指定 `scheduling` 字段， 你可以通过设置约束，确保运行该 RuntimeClass 的 Pod 被调度到支持该 RuntimeClass 的节点上。 如果未设置 `scheduling`，则假定所有节点均支持此 RuntimeClass。 @@ -257,7 +258,7 @@ rejected. --> 为了确保 pod 会被调度到支持指定运行时的 node 上，每个 node 需要设置一个通用的 label 用于被 `runtimeclass.scheduling.nodeSelector` 挑选。在 admission 阶段，RuntimeClass 的 nodeSelector 将会与 -pod 的 nodeSelector 合并，取二者的交集。如果有冲突，pod 将会被拒绝。 +Pod 的 nodeSelector 合并，取二者的交集。如果有冲突，Pod 将会被拒绝。 -如果 node 需要阻止某些需要特定 RuntimeClass 的 pod，可以在 `tolerations` 中指定。 -与 `nodeSelector` 一样，tolerations 也在 admission 阶段与 pod 的 tolerations 合并，取二者的并集。 +如果 node 需要阻止某些需要特定 RuntimeClass 的 Pod，可以在 `tolerations` 中指定。 +与 `nodeSelector` 一样，tolerations 也在 admission 阶段与 Pod 的 tolerations 合并，取二者的并集。 -你可以指定与运行 Pod 相关的 _开销_ 资源。声明开销即允许集群（包括调度器）在决策 Pod 和资源时将其考虑在内。 +你可以指定与运行 Pod 相关的**开销**资源。声明开销即允许集群（包括调度器）在决策 Pod 和资源时将其考虑在内。 - [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) -- 阅读关于 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) 的概念 +- 阅读关于 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/)的概念 - [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 9e5b912068e..b342c7c6681 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -4,6 +4,10 @@ content_type: concept weight: 10 --- Kubernetes {{< skew currentVersion >}} 支持用于集群联网的[容器网络接口](https://github.com/containernetworking/cni) (CNI) 插件。 你必须使用和你的集群相兼容并且满足你的需求的 CNI 插件。 在更广泛的 Kubernetes 生态系统中你可以使用不同的插件（开源和闭源）。 要实现 [Kubernetes 网络模型](/zh-cn/docs/concepts/services-networking/#the-kubernetes-network-model)，你需要一个 CNI 插件。 @@ -29,7 +36,7 @@ You must use a CNI plugin that is compatible with the [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) or later releases of the CNI specification. The Kubernetes project recommends using a plugin that is compatible with the [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/SPEC.md) -CNI specification (plugins can be compatible with multiple spec versions). +CNI specification (plugins can be compatible with multiple spec versions). --> 你必须使用与 [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 或更高版本的 CNI 规范相符合的 CNI 插件。 @@ -41,7 +48,9 @@ CNI 规范的插件（插件可以兼容多个规范版本）。 ## 安装 {#installation} @@ -51,8 +60,10 @@ CNI 插件，从而实现 Kubernetes 网络模型。 {{< note >}} 在 Kubernetes 1.24 之前，CNI 插件也可以由 kubelet 使用命令行参数 `cni-bin-dir` 和 `network-plugin` 管理。Kubernetes 1.24 移除了这些命令行参数， @@ -62,11 +73,13 @@ CNI 的管理不再是 kubelet 的工作。 See [Troubleshooting CNI plugin-related errors](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/) if you are facing issues following the removal of dockershim. --> -如果你在移除 dockershim 之后遇到问题，请参阅[排查 CNI 插件相关的错误](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)。 +如果你在移除 dockershim 之后遇到问题， +请参阅[排查 CNI 插件相关的错误](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)。 {{< /note >}} 要了解容器运行时如何管理 CNI 插件的具体信息，可参见对应容器运行时的文档，例如： @@ -74,7 +87,8 @@ For specific information about how a Container Runtime manages the CNI plugins, - [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md) 要了解如何安装和管理 CNI 插件的具体信息，可参阅对应的插件或 [网络驱动（Networking Provider）](/zh-cn/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model) @@ -83,10 +97,14 @@ For specific information about how to install and manage a CNI plugin, see the d ## 网络插件要求 {#network-plugin-requirements} @@ -99,9 +117,10 @@ sysctl 参数设置为 `1`，以确保 iptables 代理正常工作。 它应该确保为代理对容器通信执行正确的路由。 - 默认情况下，如果未指定 kubelet 网络插件，则使用 `noop` 插件， 该插件设置 `net/bridge/bridge-nf-call-iptables=1`，以确保简单的配置 （如带网桥的 Docker ）与 iptables 代理正常工作。 @@ -109,8 +128,13 @@ By default if no kubelet network plugin is specified, the `noop` plugin is used, ### 本地回路 CNI {#loopback-cni} @@ -124,15 +148,16 @@ Implementing the loopback interface can be accomplished by re-using the [CNI loo ### 支持 hostPort {#support-hostport} -CNI 网络插件支持 `hostPort`。 你可以使用官方 +CNI 网络插件支持 `hostPort`。你可以使用官方 [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) 插件，它由 CNI 插件团队提供，或者使用你自己的带有 portMapping 功能的插件。 @@ -173,17 +198,19 @@ CNI 网络插件支持 `hostPort`。 你可以使用官方 **Experimental Feature** -The CNI networking plugin also supports pod ingress and egress traffic shaping. You can use the official [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) +The CNI networking plugin also supports pod ingress and egress traffic shaping. You can use the +official [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) plugin offered by the CNI plugin team or use your own plugin with bandwidth control functionality. -If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI configuration file -(default `/etc/cni/net.d`) and ensure that the binary is included in your CNI bin dir (default `/opt/cni/bin`). +If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI +configuration file (default `/etc/cni/net.d`) and ensure that the binary is included in your CNI +bin dir (default `/opt/cni/bin`). --> ### 支持流量整形 {#support-traffic-shaping} **实验功能** -CNI 网络插件还支持 pod 入口和出口流量整形。 +CNI 网络插件还支持 Pod 入站和出站流量整形。 你可以使用 CNI 插件团队提供的 [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth) 插件，也可以使用你自己的具有带宽控制功能的插件。 @@ -220,12 +247,13 @@ CNI 网络插件还支持 pod 入口和出口流量整形。 ] } ``` + 现在，你可以将 `kubernetes.io/ingress-bandwidth` 和 `kubernetes.io/egress-bandwidth` -注解添加到 pod 中。例如： +注解添加到 Pod 中。例如： ```yaml apiVersion: v1 diff --git a/content/zh-cn/docs/concepts/overview/_index.md b/content/zh-cn/docs/concepts/overview/_index.md index 7a12edec1d9..51d28eb4be3 100644 --- a/content/zh-cn/docs/concepts/overview/_index.md +++ b/content/zh-cn/docs/concepts/overview/_index.md @@ -148,12 +148,12 @@ Containers are a good way to bundle and run your applications. In a production e 如果此行为交由给系统处理，是不是会更容易一些？ 这就是 Kubernetes 要来做的事情！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移你的应用、提供部署模式等。 -例如，Kubernetes 可以轻松管理系统的 Canary 部署。 +例如，Kubernetes 可以轻松管理系统的 Canary (金丝雀) 部署。 * **服务发现和负载均衡** - Kubernetes 可以使用 DNS 名称或自己的 IP 地址来曝露容器。 + Kubernetes 可以使用 DNS 名称或自己的 IP 地址来暴露容器。 如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。 @@ -249,8 +249,7 @@ Kubernetes： * 不提供应用程序级别的服务作为内置服务，例如中间件（例如消息中间件）、 数据处理框架（例如 Spark）、数据库（例如 MySQL）、缓存、集群存储系统 （例如 Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 - Kubernetes 上的应用程序通过可移植机制 - （例如[开放服务代理](https://openservicebrokerapi.org/)）来访问。 + Kubernetes 上的应用程序通过可移植机制（例如[开放服务代理](https://openservicebrokerapi.org/)）来访问。 +对于生产集群，请考虑**不要**使用 `default` 名字空间，而是创建其他名字空间来使用。 +{{< /note >}} + + +## 初始名字空间 {#initial-namespaces} + + +Kubernetes 启动时会创建四个初始名字空间： + +`default` +: Kubernetes 包含这个名字空间，以便于你无需创建新的名字空间即可开始使用新集群。 + +`kube-node-lease` +: 该名字空间包含用于与各个节点关联的 [Lease（租约）](/zh-cn/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。 + 节点租约允许 kubelet 发送[心跳](/zh-cn/docs/concepts/architecture/nodes/#heartbeats)，由此控制面能够检测到节点故障。 + +`kube-public` +: **所有**的客户端（包括未经身份验证的客户端）都可以读取该名字空间。 + 该名字空间主要预留为集群使用，以便某些资源需要在整个集群中可见可读。 + 该名字空间的公共属性只是一种约定而非要求。 + +`kube-system` +: 该名字空间用于 Kubernetes 系统创建的对象。 + -Kubernetes 会创建四个初始名字空间： - - * `default` 没有指明使用其它名字空间的对象所使用的默认名字空间 - * `kube-system` Kubernetes 系统创建对象所使用的名字空间 - * `kube-public` 这个名字空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。 - 这个名字空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。 - 这个名字空间的公共方面只是一种约定，而不是要求。 - * `kube-node-lease` 此名字空间用于与各个节点相关的 - [租约（Lease）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。 - 节点租期允许 kubelet 发送[心跳](/zh-cn/docs/concepts/architecture/nodes/#heartbeats)，由此控制面能够检测到节点故障。 - ## 并非所有对象都在名字空间中 {#not-all-objects-are-in-a-namespace} @@ -222,11 +244,11 @@ Most Kubernetes resources (e.g. pods, services, replication controllers, and oth in some namespaces. However namespace resources are not themselves in a namespace. And low-level resources, such as [nodes](/docs/concepts/architecture/nodes/) and -persistentVolumes, are not in any namespace. +[persistentVolumes](/docs/concepts/storage/persistent-volumes/), are not in any namespace. --> 大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中。而且底层资源， -例如[节点](/zh-cn/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。 +例如[节点](/zh-cn/docs/concepts/architecture/nodes/)和[持久化卷](/zh-cn/docs/concepts/storage/persistent-volumes/)不属于任何名字空间。 +- 对于 `cpu` 和 `memory` 资源：ResourceQuota 强制该命名空间中的每个（新）Pod 为该资源设置限制。 + 如果你在命名空间中为 `cpu` 和 `memory` 制实施资源配额， + 你或其他客户端**必须**为你提交的每个新 Pod 指定该资源的 `requests` 或 `limits`。 + 否则，控制平面可能会拒绝接纳该 Pod。 +- 对于其他资源：ResourceQuota 可以工作，并且会忽略命名空间中的 Pod，而无需为该资源设置限制或请求。 + 这意味着，如果资源配额限制了此命名空间的临时存储，则可以创建没有限制/请求临时存储的新 Pod。 + 你可以使用[限制范围](/zh-cn/docs/concepts/policy/limit-range/)自动设置对这些资源的默认请求。 +{{< /note >}} + -## 启用资源配额 +## 启用资源配额 {#enabling-resource-quota} 资源配额的支持在很多 Kubernetes 版本中是默认启用的。 当 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} @@ -126,7 +147,7 @@ You can limit the total sum of [compute resources](/docs/concepts/configuration/manage-resources-containers/) that can be requested in a given namespace. --> -## 计算资源配额 +## 计算资源配额 {#compute-resource-quota} 用户可以对给定命名空间下的可被请求的 [计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/) @@ -164,7 +185,7 @@ The following resource types are supported: In addition to the resources mentioned above, in release 1.10, quota support for [extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) is added. --> -### 扩展资源的资源配额 +### 扩展资源的资源配额 {#resource-quota-for-extended-resources} 除上述资源外，在 Kubernetes 1.10 版本中，还添加了对 [扩展资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources) @@ -199,7 +220,7 @@ You can limit the total sum of [storage resources](/docs/concepts/storage/persis In addition, you can limit consumption of storage resources based on associated storage-class. --> -## 存储资源配额 +## 存储资源配额 {#storage-resource-quota} 用户可以对给定命名空间下的[存储资源](/zh-cn/docs/concepts/storage/persistent-volumes/) 总量进行限制。 @@ -270,7 +291,7 @@ namespaced resource types using the following syntax: * `count/.` for resources from non-core groups * `count/` for resources from the core group --> -## 对象数量配额 +## 对象数量配额 {#object-count-quota} 你可以使用以下语法对所有标准的、命名空间域的资源类型进行配额设置： @@ -472,7 +493,7 @@ specified. -### 基于优先级类（PriorityClass）来设置资源配额 +### 基于优先级类（PriorityClass）来设置资源配额 {#resource-quota-per-priorityclass} {{< feature-state for_k8s_version="v1.17" state="stable" >}} @@ -979,7 +1000,7 @@ restrictions around nodes: pods from several namespaces may run on the same node It may be desired that pods at a particular priority, eg. "cluster-services", should be allowed in a namespace, if and only if, a matching quota object exists. --> -## 默认情况下限制特定优先级的资源消耗 +## 默认情况下限制特定优先级的资源消耗 {#limit-priority-class-consumption-by-default} 有时候可能希望当且仅当某名字空间中存在匹配的配额对象时，才可以创建特定优先级 （例如 "cluster-services"）的 Pod。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md index 3c51646bdb3..4f58e3541eb 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -9,6 +9,7 @@ reviewers: - davidopp - kevin-wangzefeng - bsalamat +- alculquicondor title: Assigning Pods to Nodes content_type: concept weight: 20 @@ -278,20 +279,20 @@ for the Pod to be scheduled onto a node. 才能将 Pod 调度到候选节点上。 -如果你指定了多个与 `nodeAffinity` 类型关联的 `nodeSelectorTerms`， -只要其中一个 `nodeSelectorTerms` 满足的话，Pod 就可以被调度到节点上。 +如果你在与 nodeAffinity 类型关联的 nodeSelectorTerms 中指定多个条件， +只要其中一个 `nodeSelectorTerms` 满足（各个条件按逻辑或操作组合）的话，Pod 就可以被调度到节点上。 -如果你指定了多个与同一 `nodeSelectorTerms` 关联的 `matchExpressions`， -则只有当所有 `matchExpressions` 都满足时 Pod 才可以被调度到节点上。 +如果你在与 `nodeSelectorTerms` 中的条件相关联的单个 `matchExpressions` 字段中指定多个表达式， +则只有当所有表达式都满足（各表达式按逻辑与操作组合）时，Pod 才能被调度到节点上。 {{< /note >}} +[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/)教程通过一个实际的示例让你了解 +Service 和 Kubernetes 如何联网。 + [集群网络](/zh-cn/docs/concepts/cluster-administration/networking/)解释了如何为集群设置网络， 还概述了所涉及的技术。 diff --git a/content/zh-cn/docs/concepts/services-networking/connect-applications-service.md b/content/zh-cn/docs/concepts/services-networking/connect-applications-service.md deleted file mode 100644 index b1498328922..00000000000 --- a/content/zh-cn/docs/concepts/services-networking/connect-applications-service.md +++ /dev/null @@ -1,634 +0,0 @@ ---- -title: 使用 Service 连接到应用 -content_type: concept -weight: 30 ---- - - - - - - -## Kubernetes 连接容器的模型 {#the-kubernetes-model-for-connecting-containers} - -既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。 - -Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上。 -Kubernetes 给每一个 Pod 分配一个集群私有 IP 地址，所以没必要在 -Pod 与 Pod 之间创建连接或将容器的端口映射到主机端口。 -这意味着同一个 Pod 内的所有容器能通过 localhost 上的端口互相连通，集群中的所有 Pod -也不需要通过 NAT 转换就能够互相看到。 -本文档的剩余部分详述如何在上述网络模型之上运行可靠的服务。 - -本指南使用一个简单的 Nginx 服务器来演示概念验证原型。 - - - - -## 在集群中暴露 Pod {#exposing-pods-to-the-cluster} - -我们在之前的示例中已经做过，然而让我们以网络连接的视角再重做一遍。 -创建一个 Nginx Pod，注意其中包含一个容器端口的规约： - -{{< codenew file="service/networking/run-my-nginx.yaml" >}} - - - -这使得可以从集群中任何一个节点来访问它。检查节点，该 Pod 正在运行： - -```shell -kubectl apply -f ./run-my-nginx.yaml -kubectl get pods -l run=my-nginx -o wide -``` -``` -NAME READY STATUS RESTARTS AGE IP NODE -my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m -my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd -``` - - -检查 Pod 的 IP 地址： - -```shell -kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs - POD_IP - [map[ip:10.244.3.4]] - [map[ip:10.244.2.5]] -``` - - -你应该能够通过 ssh 登录到集群中的任何一个节点上，并使用诸如 `curl` 之类的工具向这两个 IP 地址发出查询请求。 -需要注意的是，容器 **不会** 使用该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。 -这意味着可以在同一个节点上运行多个 Nginx Pod，使用相同的 `containerPort`，并且可以从集群中任何其他的 -Pod 或节点上使用 IP 的方式访问到它们。 -如果你想的话，你依然可以将宿主节点的某个端口的流量转发到 Pod 中，但是出于网络模型的原因，你不必这么做。 - -如果对此好奇，请参考 [Kubernetes 网络模型](/zh-cn/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model)。 - - -## 创建 Service {#creating-a-service} - -我们有一组在一个扁平的、集群范围的地址空间中运行 Nginx 服务的 Pod。 -理论上，你可以直接连接到这些 Pod，但如果某个节点死掉了会发生什么呢？ -Pod 会终止，Deployment 将创建新的 Pod，且使用不同的 IP。这正是 Service 要解决的问题。 - -Kubernetes Service 是集群中提供相同功能的一组 Pod 的抽象表达。 -当每个 Service 创建时，会被分配一个唯一的 IP 地址（也称为 clusterIP）。 -这个 IP 地址与 Service 的生命周期绑定在一起，只要 Service 存在，它就不会改变。 -可以配置 Pod 使它与 Service 进行通信，Pod 知道与 Service 通信将被自动地负载均衡到该 Service 中的某些 Pod 上。 - -可以使用 `kubectl expose` 命令为 2个 Nginx 副本创建一个 Service： - -```shell -kubectl expose deployment/my-nginx -``` -``` -service/my-nginx exposed -``` - - -这等价于使用 `kubectl create -f` 命令及如下的 yaml 文件创建： - -{{< codenew file="service/networking/nginx-svc.yaml" >}} - - -上述规约将创建一个 Service，该 Service 会将所有具有标签 `run: my-nginx` 的 Pod 的 TCP -80 端口暴露到一个抽象的 Service 端口上（`targetPort`：容器接收流量的端口；`port`：可任意取值的抽象的 Service -端口，其他 Pod 通过该端口访问 Service）。 -查看 [Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) -API 对象以了解 Service 所能接受的字段列表。 -查看你的 Service 资源: - -```shell -kubectl get svc my-nginx -``` -``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-nginx ClusterIP 10.0.162.149 80/TCP 21s -``` - - -正如前面所提到的，一个 Service 由一组 Pod 提供支撑。这些 Pod 通过 -{{}} 暴露出来。 -Service Selector 将持续评估，结果被 POST -到使用{{< glossary_tooltip text="标签" term_id="label" >}}与该 Service 连接的一个 EndpointSlice。 -当 Pod 终止后，它会自动从包含该 Pod 的 EndpointSlices 中移除。 -新的能够匹配上 Service Selector 的 Pod 将自动地被为该 Service 添加到 EndpointSlice 中。 -检查 Endpoint，注意到 IP 地址与在第一步创建的 Pod 是相同的。 - -```shell -kubectl describe svc my-nginx -``` -``` -Name: my-nginx -Namespace: default -Labels: run=my-nginx -Annotations: -Selector: run=my-nginx -Type: ClusterIP -IP: 10.0.162.149 -Port: 80/TCP -Endpoints: 10.244.2.5:80,10.244.3.4:80 -Session Affinity: None -Events: -``` -```shell -kubectl get endpointslices -l kubernetes.io/service-name=my-nginx -``` -``` -NAME ADDRESSTYPE PORTS ENDPOINTS AGE -my-nginx-7vzhx IPv4 80 10.244.2.5,10.244.3.4 21s -``` - - -现在，你应该能够从集群中任意节点上使用 curl 命令向 `:` 发送请求以访问 Nginx Service。 -注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇， -可以进一步阅读[服务代理](/zh-cn/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)的内容。 - - -## 访问 Service {#accessing-the-service} - -Kubernetes支持两种查找服务的主要模式: 环境变量和 DNS。前者开箱即用，而后者则需要 -[CoreDNS 集群插件](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns)。 - -{{< note >}} - -如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在 -[pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) -上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。 -{{< /note >}} - - -### 环境变量 {#environment-variables} - -当 Pod 在节点上运行时，kubelet 会针对每个活跃的 Service 为 Pod 添加一组环境变量。 -这就引入了一个顺序的问题。为解释这个问题，让我们先检查正在运行的 Nginx Pod -的环境变量（你的环境中的 Pod 名称将会与下面示例命令中的不同）： - -```shell -kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE -``` -``` -KUBERNETES_SERVICE_HOST=10.0.0.1 -KUBERNETES_SERVICE_PORT=443 -KUBERNETES_SERVICE_PORT_HTTPS=443 -``` - - -能看到环境变量中并没有你创建的 Service 相关的值。这是因为副本的创建先于 Service。 -这样做的另一个缺点是，调度器可能会将所有 Pod 部署到同一台机器上，如果该机器宕机则整个 Service 都会离线。 -要改正的话，我们可以先终止这 2 个 Pod，然后等待 Deployment 去重新创建它们。 -这次 Service 会 **先于** 副本存在。这将实现调度器级别的 Pod 按 Service -分布（假定所有的节点都具有同样的容量），并提供正确的环境变量： - -```shell -kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2; - -kubectl get pods -l run=my-nginx -o wide -``` -``` -NAME READY STATUS RESTARTS AGE IP NODE -my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd -my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m -``` - - -你可能注意到，Pod 具有不同的名称，这是因为它们是被重新创建的。 - -```shell -kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE -``` -``` -KUBERNETES_SERVICE_PORT=443 -MY_NGINX_SERVICE_HOST=10.0.162.149 -KUBERNETES_SERVICE_HOST=10.0.0.1 -MY_NGINX_SERVICE_PORT=80 -KUBERNETES_SERVICE_PORT_HTTPS=443 -``` - -### DNS - - -Kubernetes 提供了一个自动为其它 Service 分配 DNS 名字的 DNS 插件 Service。 -你可以通过如下命令检查它是否在工作： - -```shell -kubectl get services kube-dns --namespace=kube-system -``` -``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m -``` - - -本段剩余的内容假设你已经有一个拥有持久 IP 地址的 Service（my-nginx），以及一个为其 -IP 分配名称的 DNS 服务器。 这里我们使用 CoreDNS 集群插件（应用名为 `kube-dns`）， -所以在集群中的任何 Pod 中，你都可以使用标准方法（例如：`gethostbyname()`）与该 Service 通信。 -如果 CoreDNS 没有在运行，你可以参照 -[CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) -或者[安装 CoreDNS](/zh-cn/docs/tasks/administer-cluster/coredns/#installing-coredns) 来启用它。 -让我们运行另一个 curl 应用来进行测试： - -```shell -kubectl run curl --image=radial/busyboxplus:curl -i --tty -``` -``` -Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false -Hit enter for command prompt -``` - - -然后，按回车并执行命令 `nslookup my-nginx`： - -```shell -[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx -Server: 10.0.0.10 -Address 1: 10.0.0.10 - -Name: my-nginx -Address 1: 10.0.162.149 -``` - - -## 保护 Service {#securing-the-service} - -到现在为止，我们只在集群内部访问了 Nginx 服务器。在将 Service 暴露到因特网之前，我们希望确保通信信道是安全的。 -为实现这一目的，需要： - -* 用于 HTTPS 的自签名证书（除非已经有了一个身份证书） -* 使用证书配置的 Nginx 服务器 -* 使 Pod 可以访问证书的 [Secret](/zh-cn/docs/concepts/configuration/secret/) - -你可以从 -[Nginx https 示例](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)获取所有上述内容。 -你需要安装 go 和 make 工具。如果你不想安装这些软件，可以按照后文所述的手动执行步骤执行操作。简要过程如下： - -```shell -make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt -kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt -``` -``` -secret/nginxsecret created -``` -```shell -kubectl get secrets -``` -``` -NAME TYPE DATA AGE -nginxsecret kubernetes.io/tls 2 1m -``` - - -以下是 configmap： -```shell -kubectl create configmap nginxconfigmap --from-file=default.conf -``` -``` -configmap/nginxconfigmap created -``` -```shell -kubectl get configmaps -``` -``` -NAME DATA AGE -nginxconfigmap 1 114s -``` - - -以下是你在运行 make 时遇到问题时要遵循的手动步骤（例如，在 Windows 上）： - -```shell -# 创建公钥和相对应的私钥 -openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx" -# 对密钥实施 base64 编码 -cat /d/tmp/nginx.crt | base64 -cat /d/tmp/nginx.key | base64 -``` - - -使用前面命令的输出来创建 yaml 文件，如下所示。 base64 编码的值应全部放在一行上。 - -```yaml -apiVersion: "v1" -kind: "Secret" -metadata: - name: "nginxsecret" - namespace: "default" -type: kubernetes.io/tls -data: - tls.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K" - tls.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K" -``` - - -现在使用文件创建 Secret： - -```shell -kubectl apply -f nginxsecrets.yaml -kubectl get secrets -``` -``` -NAME TYPE DATA AGE -nginxsecret kubernetes.io/tls 2 1m -``` - - -现在修改 nginx 副本以启动一个使用 Secret 中的证书的 HTTPS 服务器以及相应的用于暴露其端口（80 和 443）的 Service： - -{{< codenew file="service/networking/nginx-secure-app.yaml" >}} - - -关于 nginx-secure-app 清单，值得注意的几点如下： - -- 它将 Deployment 和 Service 的规约放在了同一个文件中。 -- [Nginx 服务器](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)通过 - 80 端口处理 HTTP 流量，通过 443 端口处理 HTTPS 流量，而 Nginx Service 则暴露了这两个端口。 -- 每个容器能通过挂载在 `/etc/nginx/ssl` 的卷访问秘钥。卷和密钥需要在 Nginx 服务器启动 **之前** 配置好。 - -```shell -kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml -``` - - -这时，你可以从任何节点访问到 Nginx 服务器。 - -```shell -kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs - POD_IP - [map[ip:10.244.3.5]] -``` - -```shell -node $ curl -k https://10.244.3.5 -... -

    Welcome to nginx!

    -``` - - -注意最后一步我们是如何提供 `-k` 参数执行 curl 命令的，这是因为在证书生成时， -我们不知道任何关于运行 nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 -通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod 使用的实际 DNS 名字。 -让我们从一个 Pod 来测试（为了方便，这里使用同一个 Secret，Pod 仅需要使用 nginx.crt 去访问 Service）： - -{{< codenew file="service/networking/curlpod.yaml" >}} - -```shell -kubectl apply -f ./curlpod.yaml -kubectl get pods -l app=curlpod -``` -``` -NAME READY STATUS RESTARTS AGE -curl-deployment-1515033274-1410r 1/1 Running 0 1m -``` -```shell -kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt -... -Welcome to nginx! -... -``` - - -## 暴露 Service {#exposing-the-service} - -对应用的某些部分，你可能希望将 Service 暴露在一个外部 IP 地址上。 -Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。 -在上一段创建的 Service 使用了 `NodePort`，因此，如果你的节点有一个公网 -IP，那么 Nginx HTTPS 副本已经能够处理因特网上的流量。 - -```shell -kubectl get svc my-nginx -o yaml | grep nodePort -C 5 -``` - -``` - uid: 07191fb3-f61a-11e5-8ae5-42010af00002 -spec: - clusterIP: 10.0.162.149 - ports: - - name: http - nodePort: 31704 - port: 8080 - protocol: TCP - targetPort: 80 - - name: https - nodePort: 32453 - port: 443 - protocol: TCP - targetPort: 443 - selector: - run: my-nginx -``` - -```shell -kubectl get nodes -o yaml | grep ExternalIP -C 1 -``` - -``` - - address: 104.197.41.11 - type: ExternalIP - allocatable: --- - - address: 23.251.152.56 - type: ExternalIP - allocatable: -... - -$ curl https://: -k -... -

    Welcome to nginx!

    -``` - - -让我们重新创建一个 Service 以使用云负载均衡器。 -将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`： - -```shell -kubectl edit svc my-nginx -kubectl get svc my-nginx -``` -``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s -``` -``` -curl https:// -k -... -Welcome to nginx! -``` - - -在 `EXTERNAL-IP` 列中的 IP 地址能在公网上被访问到。`CLUSTER-IP` 只能从集群/私有云网络中访问。 - -注意，在 AWS 上，类型 `LoadBalancer` 的服务会创建一个 ELB，且 ELB 使用主机名（比较长），而不是 IP。 -ELB 的主机名太长以至于不能适配标准 `kubectl get svc` 的输出，所以需要通过执行 -`kubectl describe service my-nginx` 命令来查看它。 -可以看到类似如下内容： - -```shell -kubectl describe service my-nginx -... -LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com -... -``` - -## {{% heading "whatsnext" %}} - - -* 进一步了解如何[使用 Service 访问集群中的应用](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/) -* 进一步了解如何[使用 Service 将前端连接到后端](/zh-cn/docs/tasks/access-application-cluster/connecting-frontend-backend/) -* 进一步了解如何[创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md index 82b36504f94..a24fce895b2 100644 --- a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md @@ -384,13 +384,15 @@ following Pod-specific DNS policies. These policies are specified in the See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers) for more details. - "`ClusterFirst`": Any DNS query that does not match the configured cluster - domain suffix, such as "`www.kubernetes.io`", is forwarded to the upstream - nameserver inherited from the node. Cluster administrators may have extra + domain suffix, such as "`www.kubernetes.io`", is forwarded to an upstream + nameserver by the DNS server. Cluster administrators may have extra stub-domain and upstream DNS servers configured. See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers) for details on how DNS queries are handled in those cases. - "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should - explicitly set its DNS policy "`ClusterFirstWithHostNet`". + explicitly set its DNS policy to "`ClusterFirstWithHostNet`". Otherwise, Pods + running with hostNetwork and `"ClusterFirst"` will fallback to the behavior + of the `"Default"` policy. - Note: This is not supported on Windows. See [below](#dns-windows) for details - "`None`": It allows a Pod to ignore DNS settings from the Kubernetes environment. All DNS settings are supposed to be provided using the @@ -405,11 +407,12 @@ DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod - "`Default`": Pod 从运行所在的节点继承名称解析配置。 参考[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers)获取更多信息。 - "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"） - 都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 + 都会由 DNS 服务器转发到上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 参阅[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) 了解在这些场景中如何处理 DNS 查询的信息。 -- "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略 - "`ClusterFirstWithHostNet`"。 +- "`ClusterFirstWithHostNet`": 对于以 hostNetwork 方式运行的 Pod，应将其 DNS 策略显式设置为 + "`ClusterFirstWithHostNet`"。否则，以 hostNetwork 方式和 `"ClusterFirst"` 策略运行的 + Pod 将会做出回退至 `"Default"` 策略的行为。 - 注意：这在 Windows 上不支持。 有关详细信息，请参见[下文](#dns-windows)。 - "`None`": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其 `dnsConfig` 字段所提供的 DNS 设置。 diff --git a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md index 3190908d794..7831c400a5f 100644 --- a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md @@ -24,12 +24,14 @@ description: >- {{< feature-state for_k8s_version="v1.21" state="stable" >}} -**端点切片（EndpointSlices）** 提供了一种简单的方法来跟踪 Kubernetes 集群中的网络端点（network endpoints）。 -它们为 Endpoints 提供了一种可扩缩和可拓展的替代方案。 +Kubernetes 的**端点切片（EndpointSlices）** 提供了一种简单的方法来跟踪 +Kubernetes 集群中的网络端点（network endpoints）。EndpointSlices 为 +Endpoints(/zh-cn/docs/concepts/services-networking/service/#endpoints) +提供了一种可扩缩和可拓展的替代方案。 @@ -429,16 +431,17 @@ at different times. {{< note >}} -EndpointSlice API 的客户端必须能够处理特定端点地址出现在多个 EndpointSlice 中的情况。 - -你可以在 `kube-proxy` 中的 `EndpointSliceCache` 代码中找到有关如何执行这个端点去重的参考实现。 +EndpointSlice API 的客户端必须遍历与 Service 关联的所有现有 EndpointSlices， +并构建唯一网络端点的完整列表。值得一提的是端点可能在不同的 EndointSlices 中重复。 +你可以在 `kube-proxy` 中的 `EndpointSliceCache` 代码中找到有关如何执行此端点聚合和重复数据删除的参考实现。 {{< /note >}} -* 阅读[使用 Service 连接到应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) +* 遵循[使用 Service 连接到应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)教程 +* 阅读 EndpointSlice API 的 [API 参考](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) +* 阅读 Endpoints API 的 [API 参考](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoints-v1/) diff --git a/content/zh-cn/docs/concepts/services-networking/network-policies.md b/content/zh-cn/docs/concepts/services-networking/network-policies.md index d9392dd9c8d..15f89295d03 100644 --- a/content/zh-cn/docs/concepts/services-networking/network-policies.md +++ b/content/zh-cn/docs/concepts/services-networking/network-policies.md @@ -1,13 +1,22 @@ --- title: 网络策略 content_type: concept -weight: 50 +weight: 70 +description: >- + 如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量， + NetworkPolicy 可以让你为集群内以及 Pod 与外界之间的网络流量指定规则。 + 你的集群必须使用支持 NetworkPolicy 实施的网络插件。 --- diff --git a/content/zh-cn/docs/concepts/services-networking/service-topology.md b/content/zh-cn/docs/concepts/services-networking/service-topology.md index e899786565d..f605350272e 100644 --- a/content/zh-cn/docs/concepts/services-networking/service-topology.md +++ b/content/zh-cn/docs/concepts/services-networking/service-topology.md @@ -1,7 +1,7 @@ --- title: 使用拓扑键实现拓扑感知的流量路由 content_type: concept -weight: 10 +weight: 150 --- @@ -52,14 +52,12 @@ to endpoints within the same zone. By setting `topologyKeys` on a Service, you're able to define a policy for routing traffic based upon the Node labels for the originating and destination Nodes. --> -## 拓扑感知的流量路由 +## 拓扑感知的流量路由 {#topology-aware-traffic-routing} -默认情况下，发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到 -服务的任一后端的地址。Kubernetes 1.7 允许将“外部”流量路由到接收到流量的 -节点上的 Pod。对于 `ClusterIP` 服务，无法完成同节点优先的路由，你也无法 -配置集群优选路由到同一可用区中的端点。 -通过在 Service 上配置 `topologyKeys`，你可以基于来源节点和目标节点的 -标签来定义流量路由策略。 +默认情况下，发往 `ClusterIP` 或者 `NodePort` 服务的流量可能会被路由到服务的任一后端的地址。 +Kubernetes 1.7 允许将“外部”流量路由到接收到流量的节点上的 Pod。对于 `ClusterIP` +服务，无法完成同节点优先的路由，你也无法配置集群优选路由到同一可用区中的端点。 +通过在 Service 上配置 `topologyKeys`，你可以基于来源节点和目标节点的标签来定义流量路由策略。 -## 示例 +## 示例 {#examples} 以下是使用服务拓扑功能的常见示例。 @@ -192,7 +190,7 @@ The following are common examples of using the Service Topology feature. A Service that only routes to node local endpoints. If no endpoints exist on the node, traffic is dropped: --> -### 仅节点本地端点 +### 仅节点本地端点 {#only-node-local-endpoints} 仅路由到节点本地端点的一种服务。如果节点上不存在端点，流量则被丢弃： @@ -217,7 +215,7 @@ spec: A Service that prefers node local Endpoints but falls back to cluster wide endpoints if node local endpoints do not exist: --> -### 首选节点本地端点 +### 首选节点本地端点 {#prefer-node-local-endpoints} 首选节点本地端点，如果节点本地端点不存在，则回退到集群范围端点的一种服务： @@ -243,7 +241,7 @@ spec: A Service that prefers zonal then regional endpoints. If no endpoints exist in either, traffic is dropped. --> -### 仅地域或区域端点 +### 仅地域或区域端点 {#only-zonal-or-regional-endpoints} 首选地域端点而不是区域端点的一种服务。 如果以上两种范围内均不存在端点， 流量则被丢弃。 @@ -270,10 +268,9 @@ spec: A Service that prefers node local, zonal, then regional endpoints but falls back to cluster wide endpoints. --> -### 优先选择节点本地端点、地域端点，然后是区域端点 +### 优先选择节点本地端点、地域端点，然后是区域端点 {#prefer-node-local-zonal-then-regional-endpoints} -优先选择节点本地端点，地域端点，然后是区域端点，最后才是集群范围端点的 -一种服务。 +优先选择节点本地端点，地域端点，然后是区域端点，最后才是集群范围端点的一种服务。 ```yaml apiVersion: v1 @@ -294,12 +291,11 @@ spec: - "*" ``` - ## {{% heading "whatsnext" %}} -* 阅读关于[启用服务拓扑](/zh-cn/docs/tasks/administer-cluster/enabling-service-topology/) -* 阅读[用服务连接应用程序](/zh-cn/docs/concepts/services-networking/connect-applications-service/) +* 阅读关于[拓扑感知提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints/) +* 阅读[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md index fa48cbf0e77..16203a05507 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md @@ -5,6 +5,10 @@ weight: 80 --- -_CronJob_ 创建基于时隔重复调度的 {{< glossary_tooltip term_id="job" text="Jobs" >}}。 +**CronJob** 创建基于时隔重复调度的 {{< glossary_tooltip term_id="job" text="Job" >}}。 -一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。 +一个 CronJob 对象就像 **crontab** (cron table) 文件中的一行。 它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写， 并周期性地在给定的调度时间执行 Job。 +{{< caution >}} - -{{< caution >}} 所有 **CronJob** 的 `schedule:` 时间都是基于 -{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}. +{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} 的时区。 如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager， 那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区。 {{< /caution >}} +{{< caution >}} - -{{< caution >}} 如 [v1 CronJob API](/zh-cn/docs/reference/kubernetes-api/workload-resources/cron-job-v1/) 所述，官方并不支持设置时区。 Kubernetes 项目官方并不支持设置如 `CRON_TZ` 或者 `TZ` 等变量。 @@ -101,8 +103,7 @@ This example CronJob manifest prints the current time and a hello message every {{< codenew file="application/job/cronjob.yaml" >}} -[使用 CronJob 运行自动化任务](/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/) -一文会为你详细讲解此例。 +[使用 CronJob 运行自动化任务](/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/)一文会为你详细讲解此例。 | 输入 | 描述 | 相当于 | | ------------- | ------------- |------------- | -| @yearly (or @annually) | 每年 1 月 1 日的午夜运行一次 | 0 0 1 1 * | +| @yearly (或 @annually) | 每年 1 月 1 日的午夜运行一次 | 0 0 1 1 * | | @monthly | 每月第一天的午夜运行一次 | 0 0 1 * * | | @weekly | 每周的周日午夜运行一次 | 0 0 * * 0 | -| @daily (or @midnight) | 每天午夜运行一次 | 0 0 * * * | +| @daily (或 @midnight) | 每天午夜运行一次 | 0 0 * * * | | @hourly | 每小时的开始一次 | 0 * * * * | +## 时区 {#time-zones} + +对于没有指定时区的 CronJob，kube-controller-manager 基于本地时区解释排期表（Schedule）。 {{< feature-state for_k8s_version="v1.25" state="beta" >}} + - -## 时区 {#time-zones} -对于没有指定时区的 CronJob，kube-controller-manager 基于本地时区解释排期表（Schedule）。 - -{{< feature-state for_k8s_version="v1.25" state="beta" >}} - 如果启用了 `CronJobTimeZone` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， 你可以为 CronJob 指定一个时区（如果你没有启用该特性门控，或者你使用的是不支持试验性时区功能的 Kubernetes 版本，集群中所有 CronJob 的时区都是未指定的）。 启用该特性后，你可以将 `spec.timeZone` -设置为有效[时区](https://zh.wikipedia.org/wiki/%E6%97%B6%E5%8C%BA%E4%BF%A1%E6%81%AF%E6%95%B0%E6%8D%AE%E5%BA%93)名称。 +设置为有效[时区](https://zh.wikipedia.org/wiki/%E6%97%B6%E5%8C%BA%E4%BF%A1%E6%81%AF%E6%95%B0%E6%8D%AE%E5%BA%93)名称。 例如，设置 `spec.timeZone: "Etc/UTC"` 指示 Kubernetes 采用 UTC 来解释排期表。 Go 标准库中的时区数据库包含在二进制文件中，并用作备用数据库，以防系统上没有可用的外部数据库。 - 对于每个 CronJob，CronJob {{< glossary_tooltip term_text="控制器" term_id="controller" >}} 检查从上一次调度的时间点到现在所错过了调度次数。如果错过的调度次数超过 100 次， 那么它就不会启动这个任务，并记录这个错误: -```` +``` Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. -```` +``` 如果未能在调度时间内创建 CronJob，则计为错过。 例如，如果 `concurrencyPolicy` 被设置为 `Forbid`，并且当前有一个调度仍在运行的情况下， @@ -245,16 +243,16 @@ be down from `08:29:00` to `10:21:00`, the job will not start as the number of m --> 例如，假设一个 CronJob 被设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job， 并且它的 `startingDeadlineSeconds` 字段未被设置。如果 CronJob 控制器从 -`08:29:00` 到 `10:21:00` 终止运行，则该 Job 将不会启动，因为其错过的调度 -次数超过了 100。 +`08:29:00` 到 `10:21:00` 终止运行，则该 Job 将不会启动， +因为其错过的调度次数超过了 100。 为了进一步阐述这个概念，假设将 CronJob 设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job， -并将其 `startingDeadlineSeconds` 字段设置为 200 秒。 +并将其 `startingDeadlineSeconds` 字段设置为 200 秒。 如果 CronJob 控制器恰好在与上一个示例相同的时间段（`08:29:00` 到 `10:21:00`）终止运行， 则 Job 仍将从 `10:22:00` 开始。 造成这种情况的原因是控制器现在检查在最近 200 秒（即 3 个错过的调度）中发生了多少次错过的 @@ -271,7 +269,7 @@ CronJob 仅负责创建与其调度时间相匹配的 Job，而 Job 又负责管 Starting with Kubernetes v1.21 the second version of the CronJob controller is the default implementation. To disable the default CronJob controller -and use the original CronJob controller instead, one pass the `CronJobControllerV2` +and use the original CronJob controller instead, pass the `CronJobControllerV2` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) flag to the {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}, and set this flag to `false`. For example: @@ -289,6 +287,7 @@ and set this flag to `false`. For example: ``` ## {{% heading "whatsnext" %}} + - * 了解 CronJob 所依赖的 [Pod](/zh-cn/docs/concepts/workloads/pods/) 与 [Job](/zh-cn/docs/concepts/workloads/controllers/job/) 的概念。 * 阅读 CronJob `.spec.schedule` 字段的[格式](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)。 -* 有关创建和使用 CronJob 的说明及示例规约文件，请参见 - [使用 CronJob 运行自动化任务](/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/)。 +* 有关创建和使用 CronJob 的说明及示例规约文件， + 请参见[使用 CronJob 运行自动化任务](/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/)。 * 有关自动清理失败或完成作业的说明，请参阅[自动清理作业](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) * `CronJob` 是 Kubernetes REST API 的一部分， 阅读 {{< api-reference page="workload-resources/cron-job-v1" >}} diff --git a/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md index 0b39fb3de76..cb443b9905b 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md @@ -1,10 +1,5 @@ --- title: ReplicationController -feature: - title: 自我修复 - anchor: ReplicationController 如何工作 - description: > - 重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会将它们公布给客户端。 content_type: concept weight: 90 --- @@ -14,12 +9,6 @@ reviewers: - bprashanth - janetkuo title: ReplicationController -feature: - title: Self-healing - anchor: How a ReplicationController Works - description: > - Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve. - content_type: concept weight: 90 --> diff --git a/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md index 054554bda5f..3e2beb7bc01 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md @@ -5,6 +5,9 @@ weight: 80 --- -- 临时容器没有端口配置，因此像 `ports`，`livenessProbe`，`readinessProbe` +- 临时容器没有端口配置，因此像 `ports`、`livenessProbe`、`readinessProbe` 这样的字段是不允许的。 - Pod 资源分配是不可变的，因此 `resources` 配置是不允许的。 - 有关允许字段的完整列表，请参见 @@ -94,6 +97,13 @@ after you have added it to a Pod. --> 与常规容器一样，将临时容器添加到 Pod 后，将不能更改或删除临时容器。 +{{< note >}} + +临时容器不被[静态 Pod](/zh-cn/docs/tasks/configure-pod-container/static-pod/) 支持。 +{{< /note >}} + -使用临时容器时，启用 -[进程名字空间共享](/zh-cn/docs/tasks/configure-pod-container/share-process-namespace/) -很有帮助，可以查看其他容器中的进程。 +使用临时容器时， +启用[进程名字空间共享](/zh-cn/docs/tasks/configure-pod-container/share-process-namespace/)很有帮助， +可以查看其他容器中的进程。 {{% heading "whatsnext" %}} + diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates.md index 0476ef1efed..f9f588a2daf 100644 --- a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates.md @@ -174,7 +174,9 @@ For a reference to old feature gates that are removed, please refer to | `JobReadyPods` | `false` | Alpha | 1.23 | 1.23 | | `JobReadyPods` | `true` | Beta | 1.24 | | | `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | 1.22 | -| `JobTrackingWithFinalizers` | `true` | Beta | 1.23 | | +| `JobTrackingWithFinalizers` | `false` | Beta | 1.23 | 1.24 | +| `JobTrackingWithFinalizers` | `true` | Beta | 1.25 | | +| `KMSv2` | `false` | Alpha | 1.25 | | | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | 1.23 | | `KubeletCredentialProviders` | `true` | Beta | 1.24 | | | `KubeletInUserNamespace` | `false` | Alpha | 1.22 | | @@ -925,12 +927,16 @@ Each feature gate is designed for enabling/disabling a specific feature: 完成情况，而不是永远从集群剩余 Pod 来获取信息判断完成情况。Job 控制器使用 Pod finalizers 和 Job 状态中的一个字段来跟踪已完成的 Pod 以计算完成。 +- `KMSv2`：启用 KMS v2 API 以实现静态加密。 + 详情参见[使用 KMS 驱动进行数据加密](/zh-cn/docs/tasks/administer-cluster/kms-provider)。 - `KubeletCredentialProviders`：允许使用 kubelet exec 凭据提供程序来设置镜像拉取凭据。 - `KubeletInUserNamespace`：支持在{{}}里运行 kubelet。 请参见[使用非 Root 用户来运行 Kubernetes 节点组件](/zh-cn/docs/tasks/administer-cluster/kubelet-in-userns/)。 diff --git a/content/zh-cn/docs/reference/glossary/container.md b/content/zh-cn/docs/reference/glossary/container.md index 7a79f2233a0..bd652d8e520 100644 --- a/content/zh-cn/docs/reference/glossary/container.md +++ b/content/zh-cn/docs/reference/glossary/container.md @@ -34,5 +34,7 @@ tags: -容器使应用和底层的主机基础设施解耦，降低了应用在不同云环境或者操作系统上的部署难度，便于应用扩展。 \ No newline at end of file +容器使应用和底层的主机基础设施解耦，降低了应用在不同云环境或者操作系统上的部署难度，便于应用扩展。 +在容器内运行的应用程序称为容器化应用程序。 将这些应用程序及其依赖项捆绑到容器映像中的过程称为容器化。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/ephemeral-container.md b/content/zh-cn/docs/reference/glossary/ephemeral-container.md index cc8efd79374..591c85b3f53 100644 --- a/content/zh-cn/docs/reference/glossary/ephemeral-container.md +++ b/content/zh-cn/docs/reference/glossary/ephemeral-container.md @@ -31,6 +31,8 @@ A {{< glossary_tooltip term_id="container" >}} type that you can temporarily run 如果想要调查运行中有问题的 Pod，可以向该 Pod 添加一个临时容器（Ephemeral Container）并进行诊断。 临时容器没有资源或调度保证，因此不应该使用它们来运行任何部分的工作负荷本身。 +{{{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}} 不支持临时容器。 diff --git a/content/zh-cn/docs/reference/glossary/static-pod.md b/content/zh-cn/docs/reference/glossary/static-pod.md index fd9103c322a..1243cf46042 100644 --- a/content/zh-cn/docs/reference/glossary/static-pod.md +++ b/content/zh-cn/docs/reference/glossary/static-pod.md @@ -4,7 +4,7 @@ id: static-pod date: 2019-02-12 full_link: /zh-cn/docs/tasks/configure-pod-container/static-pod/ short_description: > - 静态Pod（Static Pod）是指由特定节点上的 kubelet 守护进程直接管理的 Pod。 + 静态 Pod（Static Pod）是指由特定节点上的 kubelet 守护进程直接管理的 Pod。 aka: tags: @@ -12,7 +12,6 @@ tags: --- -由特定节点上的 kubelet 守护进程直接管理的 {{< glossary_tooltip text="pod" term_id="pod" >}}， +由特定节点上的 kubelet 守护进程直接管理的 {{< glossary_tooltip text="Pod" term_id="pod" >}}， -API 服务器不了解它的存在。 \ No newline at end of file +API 服务器不了解它的存在。 + + +静态 Pod 不支持{{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}}。 diff --git a/content/zh-cn/docs/reference/instrumentation/_index.md b/content/zh-cn/docs/reference/instrumentation/_index.md new file mode 100644 index 00000000000..00927ca5dee --- /dev/null +++ b/content/zh-cn/docs/reference/instrumentation/_index.md @@ -0,0 +1,8 @@ +--- +title: 插桩 +weight: 60 +--- + \ No newline at end of file diff --git a/content/zh-cn/docs/reference/instrumentation/node-metrics.md b/content/zh-cn/docs/reference/instrumentation/node-metrics.md new file mode 100644 index 00000000000..f3d029c5899 --- /dev/null +++ b/content/zh-cn/docs/reference/instrumentation/node-metrics.md @@ -0,0 +1,100 @@ +--- +title: 节点指标数据 +content_type: reference +weight: 50 +description: >- + 访问 kubelet 所观测到的节点、卷、Pod 和容器级别指标的机制。 +--- + + + +[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) +在节点、卷、Pod 和容器级别收集统计信息，并在 +[概要 API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) +中输出这些信息。 + + +你可以通过 Kubernetes API 服务器将代理的请求发送到 stats 概要 API。 + +下面是一个名为 `minikube` 的节点的概要 API 请求示例： + +```shell +kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary" +``` + + +下面是使用 `curl` 所执行的相同 API 调用： + +```shell +# 你需要先运行 "kubectl proxy" +# 更改 8080 为 "kubectl proxy" 指派的端口 +curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary +``` + +{{< note >}} + +从 `metrics-server` 0.6.x 开始，`metrics-server` 查询 `/metrics/resource` kubelet 端点， +不查询 `/stats/summary`。 +{{< /note >}} + + +## 概要指标 API 源 {#summary-api-source} + +默认情况下，Kubernetes 使用 kubelet 内运行的嵌入式 [cAdvisor](https://github.com/google/cadvisor) +获取节点概要指标数据。 + +## 通过 CRI 获得概要 API 数据 {#pod-and-container-stats-from-cri} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + + +如果你在自己的集群中启用 `PodAndContainerStatsFromCRI` +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， +且你通过{{< glossary_tooltip term_id="cri" text="容器运行时接口">}} (CRI) 使用支持统计访问的容器运行时， +则 kubelet 将使用 CRI 而不是 cAdvisor 来获取 Pod 和容器级别的指标数据。 + +## {{% heading "whatsnext" %}} + + +[集群故障排查](/zh-cn/docs/tasks/debug/debug-cluster/)任务页面讨论了如何使用依赖这些数据的指标管道。 diff --git a/content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-details.md index 55c0614a4d0..501f472a8ec 100644 --- a/content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -794,8 +794,8 @@ Please note that: 2. If you run kubeadm in `--dry-run` mode, the etcd static Pod manifest is written into a temporary folder. 3. You can directly invoke static Pod manifest generation for local etcd, using the - [`kubeadm init phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) - command. + [`kubeadm init phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) + command. --> 1. etcd 容器镜像默认从 `registry.gcr.io` 拉取。有关自定义镜像仓库， 请参阅[使用自定义镜像](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-images)。 @@ -829,7 +829,7 @@ kubeadm 依靠 kubelet 拉取控制平面镜像并将其作为静态 Pod 正确 -### 将 kubeadm ClusterConfiguration 保存在 ConfigMap 中以供以后参考 {#save-the-kubeadm-clusterConfiguration-in-a-configMap-for-later-reference} +### 将 kubeadm ClusterConfiguration 保存在 ConfigMap 中以供以后参考 {#save-the-kubeadm-clusterconfiguration-in-a-configmap-for-later-reference} `kubeadm init` 创建第一个引导令牌，该令牌是自动生成的或由用户提供的 `--token` 标志的值；如引导令牌规范文档中所述，令牌应保存在 `kube-system` 名字空间下名为 @@ -1035,7 +1033,7 @@ Kubeadm 确保节点启用了证书轮换，csrapprover 控制器将自动批准 这是通过在 `system:nodes` 组和 @@ -1046,7 +1044,7 @@ ClusterRoleBinding 来实现的。 -#### 创建公共 cluster-info ConfigMap +#### 创建公共 cluster-info ConfigMap {#create-the-public-cluster-info-configmap} -### 安装插件 {##install-addons} +### 安装插件 {#install-addons} -1. `kubeadm join` 预检基本上是 `kubeadm init` 预检的一个子集 +1. `kubeadm join` 预检基本上是 `kubeadm init` 预检的一个子集。 2. 从 1.24 开始，kubeadm 使用 crictl 与所有已知的 CRI 端点进行通信。 3. 从 1.9 开始，kubeadm 支持加入在 Windows 上运行的节点；在这种情况下， 将跳过 Linux 特定的控制参数。 diff --git a/content/zh-cn/docs/setup/_index.md b/content/zh-cn/docs/setup/_index.md index 78af857c3a0..bfd81654197 100644 --- a/content/zh-cn/docs/setup/_index.md +++ b/content/zh-cn/docs/setup/_index.md @@ -38,20 +38,17 @@ card: -本节列出了设置和运行 Kubernetes 的不同方法。 - - +本节列出了设置和运行 Kubernetes 的不同方法。 安装 Kubernetes 时，请根据以下条件选择安装类型：易于维护、安全性、可控制性、可用资源以及操作和管理 Kubernetes 集群所需的专业知识。 你可以[下载 Kubernetes](/zh-cn/releases/download/)，在本地机器、云或你自己的数据中心上部署 Kubernetes 集群。 -某些 [Kubernetes 组件](/zh-cn/docs/concepts/overview/components/)， -比如 `kube-apiserver` 或 `kube-proxy` 等， -可以在集群中以[容器镜像](/zh-cn/releases/download/#container-images)部署。 +诸如 {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} 或 +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} +等某些 [Kubernetes 组件](/zh-cn/docs/concepts/overview/components/)可以在集群中以[容器镜像](/zh-cn/releases/download/#container-images)部署。 **建议**尽可能将 Kubernetes 组件作为容器镜像运行，并且让 Kubernetes 管理这些组件。 但是运行容器的相关组件 —— 尤其是 kubelet，不在此列。 @@ -79,7 +76,7 @@ bare metal environments. -## 学习环境 +## 学习环境 {#learning-environment} -## 生产环境 +## 生产环境 {#production-environment} -## {{% heading "whatsnext" %}} - - [下载 Kubernetes](/zh-cn/releases/download/) -- 下载并[安装工具](/zh-cn/docs/tasks/tools/)，包括 kubectl 在内 +- [下载并安装包括 kubectl 在内的工具](/zh-cn/docs/tasks/tools/) - 为新集群选择[容器运行时](/zh-cn/docs/setup/production-environment/container-runtimes/) - 了解集群设置的[最佳实践](/zh-cn/docs/setup/best-practices/) Kubernetes 的设计是让其{{< glossary_tooltip term_id="control-plane" text="控制平面" >}}在 Linux 上运行的。 在集群中，你可以在 Linux 或其他操作系统（包括 Windows）上运行应用程序。 + - 学习[配置包含 Windows 节点的集群](/zh-cn/docs/concepts/windows/) diff --git a/content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index b5e7b76e488..afacfc075d2 100644 --- a/content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -95,11 +95,11 @@ slightly as the tool evolves, but the overall implementation should be pretty st `kubeadm` 工具的整体功能状态为一般可用性（GA）。一些子功能仍在积极开发中。 随着工具的发展，创建集群的实现可能会略有变化，但总体实现应相当稳定。 +{{< note >}} -{{< note >}} -根据定义，在 `kubeadm alpha` 下的所有命令均在 alpha 级别上受支持。 +根据定义，在 `kubeadm alpha` 下的所有命令均在 Alpha 级别上受支持。 {{< /note >}} @@ -134,6 +134,7 @@ For detailed instructions and other prerequisites, see [Installing kubeadm](/doc 在所有主机上安装 {{< glossary_tooltip term_id="container-runtime" text="容器运行时" >}} 和 kubeadm。 详细说明和其他前提条件，请参见[安装 kubeadm](/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)。 +{{< note >}} -{{< note >}} 如果你已经安装了kubeadm，执行 `apt-get update && apt-get upgrade` 或 `yum update` 以获取 kubeadm 的最新版本。 @@ -193,8 +193,8 @@ The control-plane node is the machine where the control plane components run, in communicates with). --> 控制平面节点是运行控制平面组件的机器， -包括 {{< glossary_tooltip term_id="etcd" >}} （集群数据库） -和 {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} +包括 {{< glossary_tooltip term_id="etcd" >}}（集群数据库） +和 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} （命令行工具 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 与之通信）。 -要重新配置一个已经创建的集群，请参见 -[重新配置一个 kubeadm 集群](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)。 +要重新配置一个已经创建的集群， +请参见[重新配置一个 kubeadm 集群](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)。 -`kubeadm init` 首先运行一系列预检查以确保机器 -准备运行 Kubernetes。这些预检查会显示警告并在错误时退出。然后 `kubeadm init` +`kubeadm init` 首先运行一系列预检查以确保机器为运行 Kubernetes 准备就绪。 +这些预检查会显示警告并在错误时退出。然后 `kubeadm init` 下载并安装集群控制平面组件。这可能会需要几分钟。 完成之后你应该看到： @@ -464,8 +464,9 @@ Cluster DNS (CoreDNS) will not start up before a network is installed.** Make sure that your Pod network plugin supports RBAC, and so do any manifests that you use to deploy it. --> -- 默认情况下，`kubeadm` 将集群设置为使用和强制使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)（基于角色的访问控制）。 - 确保你的 Pod 网络插件支持 RBAC，以及用于部署它的 manifests 也是如此。 +- 默认情况下，`kubeadm` 将集群设置为使用和强制使用 + [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)（基于角色的访问控制）。 + 确保你的 Pod 网络插件支持 RBAC，以及用于部署它的清单也是如此。 -{{< note >}} kubeadm 应该是与 CNI 无关的，对 CNI 驱动进行验证目前不在我们的端到端测试范畴之内。 如果你发现与 CNI 插件相关的问题，应在其各自的问题跟踪器中记录而不是在 kubeadm 或 kubernetes 问题跟踪器中记录。 @@ -530,13 +531,12 @@ If your network is not working or CoreDNS is not in the `Running` state, check o [troubleshooting guide](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/) for `kubeadm`. --> -如果你的网络无法正常工作或 CoreDNS 不在“运行中”状态，请查看 `kubeadm` 的 -[故障排除指南](/zh-cn/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)。 +如果你的网络无法正常工作或 CoreDNS 不在 `Running` 状态，请查看 `kubeadm` +的[故障排除指南](/zh-cn/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)。 - ### 托管节点标签 {#managed-node-labels} 默认情况下，kubeadm 启用 [NodeRestriction](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction) -准入控制器来限制 kubelets 在节点注册时可以应用哪些标签。准入控制器文档描述 kubelet `--node-labels` 选项允许使用哪些标签。 +准入控制器来限制 kubelet 在节点注册时可以应用哪些标签。准入控制器文档描述 kubelet `--node-labels` 选项允许使用哪些标签。 其中 `node-role.kubernetes.io/control-plane` 标签就是这样一个受限制的标签， kubeadm 在节点创建后使用特权客户端手动应用此标签。 你可以使用一个有特权的 kubeconfig，比如由 kubeadm 管理的 `/etc/kubernetes/admin.conf`， @@ -568,15 +568,17 @@ for example for a single machine Kubernetes cluster, run: 如果你希望能够在控制平面节点上调度 Pod，例如单机 Kubernetes 集群，请运行: ```bash -kubectl taint nodes --all node-role.kubernetes.io/control-plane- node-role.kubernetes.io/master- +kubectl taint nodes --all node-role.kubernetes.io/control-plane- ``` + 输出看起来像： -```console +``` node "test-01" untainted +... ``` -{{< note >}} 要为 `:` 指定 IPv6 元组，必须将 IPv6 地址括在方括号中，例如：`[2001:db8::101]:2073` {{< /note >}} @@ -706,12 +708,12 @@ nodes` when run on the control-plane node. --> 几秒钟后，当你在控制平面节点上执行 `kubectl get nodes`，你会注意到该节点出现在输出中。 +{{< note >}} -{{< note >}} 由于集群节点通常是按顺序初始化的，CoreDNS Pod 很可能都运行在第一个控制面节点上。 为了提供更高的可用性，请在加入至少一个新节点后 使用 `kubectl -n kube-system rollout restart deployment coredns` 命令，重新平衡这些 CoreDNS Pod。 @@ -734,6 +736,8 @@ to your workstation like this: scp root@:/etc/kubernetes/admin.conf . kubectl --kubeconfig ./admin.conf get nodes ``` + +{{< note >}} -{{< note >}} 上面的示例假定为 root 用户启用了 SSH 访问。如果不是这种情况， 你可以使用 `scp` 将 `admin.conf` 文件复制给其他允许访问的用户。 @@ -773,6 +776,7 @@ If you want to connect to the API Server from outside the cluster you can use scp root@:/etc/kubernetes/admin.conf . kubectl --kubeconfig ./admin.conf proxy ``` + @@ -789,7 +793,8 @@ switch those off and do no further clean up. You can use `kubectl config delete-cluster` to delete your local references to the cluster. --> -如果你在集群中使用了一次性服务器进行测试，则可以关闭这些服务器，而无需进一步清理。你可以使用 `kubectl config delete-cluster` 删除对集群的本地引用。 +如果你在集群中使用了一次性服务器进行测试，则可以关闭这些服务器，而无需进一步清理。 +你可以使用 `kubectl config delete-cluster` 删除对集群的本地引用。 -有关此子命令及其选项的更多信息，请参见 [`kubeadm reset`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 参考文档。 +有关此子命令及其选项的更多信息，请参见 +[`kubeadm reset`](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-reset/) 参考文档。 @@ -903,8 +909,7 @@ options. * 有关 Pod 网络附加组件的更多列表，请参见[集群网络](/zh-cn/docs/concepts/cluster-administration/networking/)页面。 * 请参阅[附加组件列表](/zh-cn/docs/concepts/cluster-administration/addons/)以探索其他附加组件， 包括用于 Kubernetes 集群的日志记录、监视、网络策略、可视化和控制的工具。 -* 配置集群如何处理集群事件的日志以及 - 在 Pod 中运行的应用程序。 +* 配置集群如何处理集群事件的日志以及在 Pod 中运行的应用程序。 有关所涉及内容的概述，请参见[日志架构](/zh-cn/docs/concepts/cluster-administration/logging/)。 - ### kubeadm 中的 Kubernetes 版本偏差 {#kubeadm-s-skew-against-the-kubernetes-version} -* 定期[备份 etcd](https://coreos.com/etcd/docs/latest/admin_guide.html)。 +* 定期[备份 etcd](https://etcd.io/docs/v3.5/op-guide/recovery/)。 kubeadm 配置的 etcd 数据目录位于控制平面节点上的 `/var/lib/etcd` 中。 +在低于 Debian 12 和 Ubuntu 22.04 的发行版本中，`/etc/apt/keyrings` 默认不存在。 +如有需要，你可以创建此目录，并将其设置为对所有人可读，但仅对管理员可写。 +{{< /note >}} {{% /tab %}} diff --git a/content/zh-cn/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/zh-cn/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 9c7dfd5e064..3c071badf97 100644 --- a/content/zh-cn/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/zh-cn/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -35,8 +35,8 @@ If your problem is not listed below, please follow the following steps: - 如果没有问题，请 [打开](https://github.com/kubernetes/kubeadm/issues/new) 并遵循问题模板。 - 如果你对 kubeadm 的工作方式有疑问，可以在 [Slack](https://slack.k8s.io/) 上的 `#kubeadm` 频道提问， -或者在 [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) 上提问。 -请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助你。 + 或者在 [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes) 上提问。 + 请加入相关标签，例如 `#kubernetes` 和 `#kubeadm`，这样其他人可以帮助你。 @@ -73,7 +73,6 @@ Apply the following RBAC manually using `kubectl apply -f ...`: 或者，也可以使用 `kubectl apply -f ...` 手动应用以下 RBAC： - ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -105,26 +104,22 @@ subjects: ## `ebtables` or some similar executable not found during installation If you see the following warnings while running `kubeadm init` - -```sh -[preflight] WARNING: ebtables not found in system path -[preflight] WARNING: ethtool not found in system path -``` - -Then you may be missing `ebtables`, `ethtool` or a similar executable on your node. You can install them with the following commands: - -- For Ubuntu/Debian users, run `apt install ebtables ethtool`. -- For CentOS/Fedora users, run `yum install ebtables ethtool`. --> ## 在安装过程中没有找到 `ebtables` 或者其他类似的可执行文件 如果在运行 `kubeadm init` 命令时，遇到以下的警告 -```sh +```console [preflight] WARNING: ebtables not found in system path [preflight] WARNING: ethtool not found in system path ``` + 那么或许在你的节点上缺失 `ebtables`、`ethtool` 或者类似的可执行文件。 你可以使用以下命令安装它们： @@ -135,16 +130,12 @@ Then you may be missing `ebtables`, `ethtool` or a similar executable on your no ## kubeadm blocks waiting for control plane during installation If you notice that `kubeadm init` hangs after printing out the following line: - -```sh -[apiclient] Created API client, waiting for the control plane to become ready -``` --> ## 在安装过程中，kubeadm 一直等待控制平面就绪 如果你注意到 `kubeadm init` 在打印以下行后挂起： -```sh +```console [apiclient] Created API client, waiting for the control plane to become ready ``` @@ -153,17 +144,18 @@ This may be caused by a number of problems. The most common are: - network connection problems. Check that your machine has full network connectivity before continuing. - the cgroup driver of the container runtime differs from that of the kubelet. To understand how to -configure it properly see [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). + configure it properly see [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). - control plane containers are crashlooping or hanging. You can check this by running `docker ps` -and investigating each container by running `docker logs`. For other container runtime see -[Debugging Kubernetes nodes with crictl](/docs/tasks/debug/debug-cluster/crictl/). + and investigating each container by running `docker logs`. For other container runtime see + [Debugging Kubernetes nodes with crictl](/docs/tasks/debug/debug-cluster/crictl/). --> 这可能是由许多问题引起的。最常见的是： - 网络连接问题。在继续之前，请检查你的计算机是否具有全部联通的网络连接。 - 容器运行时的 cgroup 驱动不同于 kubelet 使用的 cgroup 驱动。要了解如何正确配置 cgroup 驱动， 请参阅[配置 cgroup 驱动](/zh-cn/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)。 -- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。你可以运行 `docker ps` 命令来检查以及 `docker logs` 命令来检视每个容器的运行日志。 +- 控制平面上的 Docker 容器持续进入崩溃状态或（因其他原因）挂起。你可以运行 `docker ps` 命令来检查以及 `docker logs` + 命令来检视每个容器的运行日志。 对于其他容器运行时，请参阅[使用 crictl 对 Kubernetes 节点进行调试](/zh-cn/docs/tasks/debug/debug-cluster/crictl/)。 +## 当删除托管容器时 kubeadm 阻塞 + +如果容器运行时停止并且未删除 Kubernetes 所管理的容器，可能发生以下情况： ```shell sudo kubeadm reset @@ -184,26 +180,11 @@ sudo kubeadm reset (block) ``` + -## 当删除托管容器时 kubeadm 阻塞 - -如果容器运行时停止并且未删除 Kubernetes 所管理的容器，可能发生以下情况： - -```shell -sudo kubeadm reset -``` - -```none -[preflight] Running pre-flight checks -[reset] Stopping the kubelet service -[reset] Unmounting mounted directories in "/var/lib/kubelet" -[reset] Removing kubernetes-managed containers -(block) -``` - 一个可行的解决方案是重新启动 Docker 服务，然后重新运行 `kubeadm reset`： 你也可以使用 `crictl` 来调试容器运行时的状态。 参见[使用 CRICTL 调试 Kubernetes 节点](/zh-cn/docs/tasks/debug/debug-cluster/crictl/)。 @@ -246,9 +227,8 @@ before CoreDNS may be deployed fully. Hence the `Pending` state before the netwo --> ## `coredns` 停滞在 `Pending` 状态 -这一行为是 **预期之中** 的，因为系统就是这么设计的。 -kubeadm 的网络供应商是中立的，因此管理员应该选择 -[安装 Pod 的网络插件](/zh-cn/docs/concepts/cluster-administration/addons/)。 +这一行为是 **预期之中** 的，因为系统就是这么设计的。kubeadm 的网络供应商是中立的， +因此管理员应该选择[安装 Pod 的网络插件](/zh-cn/docs/concepts/cluster-administration/addons/)。 你必须完成 Pod 的网络配置，然后才能完全部署 CoreDNS。 在网络被配置好之前，DNS 组件会一直处于 `Pending` 状态。 @@ -307,36 +287,6 @@ services](/docs/concepts/services-networking/service/#type-nodeport) or use `Hos ## TLS certificate errors The following error indicates a possible certificate mismatch. - -```none -# kubectl get pods -Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") -``` - -- Verify that the `$HOME/.kube/config` file contains a valid certificate, and - regenerate a certificate if necessary. The certificates in a kubeconfig file - are base64 encoded. The `base64 --decode` command can be used to decode the certificate - and `openssl x509 -text -noout` can be used for viewing the certificate information. -- Unset the `KUBECONFIG` environment variable using: - - ```sh - unset KUBECONFIG - ``` - - Or set it to the default `KUBECONFIG` location: - - ```sh - export KUBECONFIG=/etc/kubernetes/admin.conf - ``` - -- Another workaround is to overwrite the existing `kubeconfig` for the "admin" user: - - ```sh - mv $HOME/.kube $HOME/.kube.bak - mkdir $HOME/.kube - sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config - sudo chown $(id -u):$(id -g) $HOME/.kube/config - ``` --> ## TLS 证书错误 @@ -347,6 +297,13 @@ Unable to connect to the server: x509: certificate signed by unknown authority ( Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") ``` + - 验证 `$HOME/.kube/config` 文件是否包含有效证书， 并在必要时重新生成证书。在 kubeconfig 文件中的证书是 base64 编码的。 该 `base64 --decode` 命令可以用来解码证书，`openssl x509 -text -noout` @@ -357,12 +314,18 @@ Unable to connect to the server: x509: certificate signed by unknown authority ( unset KUBECONFIG ``` + 或者将其设置为默认的 `KUBECONFIG` 位置： ```shell export KUBECONFIG=/etc/kubernetes/admin.conf ``` + - 另一个方法是覆盖 `kubeconfig` 的现有用户 "管理员"： ```shell @@ -381,17 +344,17 @@ in kube-apiserver logs. To fix the issue you must follow these steps: --> ## Kubelet 客户端证书轮换失败 {#kubelet-client-cert} -默认情况下，kubeadm 使用 `/etc/kubernetes/kubelet.conf` 中指定的 `/var/lib/kubelet/pki/kubelet-client-current.pem` 符号链接 -来配置 kubelet 自动轮换客户端证书。如果此轮换过程失败，你可能会在 kube-apiserver 日志中看到诸如 +默认情况下，kubeadm 使用 `/etc/kubernetes/kubelet.conf` 中指定的 `/var/lib/kubelet/pki/kubelet-client-current.pem` +符号链接来配置 kubelet 自动轮换客户端证书。如果此轮换过程失败，你可能会在 kube-apiserver 日志中看到诸如 `x509: certificate has expired or is not yet valid` 之类的错误。要解决此问题，你必须执行以下步骤： 1. 从故障节点备份和删除 `/etc/kubernetes/kubelet.conf` 和 `/var/lib/kubelet/pki/kubelet-client*`。 2. 在集群中具有 `/etc/kubernetes/pki/ca.key` 的、正常工作的控制平面节点上 @@ -403,13 +366,13 @@ the `ca.key` you must sign the embedded certificates in the `kubelet.conf` exter 3. 将得到的 `kubelet.conf` 文件复制到故障节点上，作为 `/etc/kubernetes/kubelet.conf`。 4. 在故障节点上重启 kubelet（`systemctl restart kubelet`），等待 `/var/lib/kubelet/pki/kubelet-client-current.pem` 重新创建。 5. 手动编辑 `kubelet.conf` 指向轮换的 kubelet 客户端证书，方法是将 `client-certificate-data` 和 `client-key-data` 替换为： @@ -429,77 +392,52 @@ the `ca.key` you must sign the embedded certificates in the `kubelet.conf` exter ## Default NIC When using flannel as the pod network in Vagrant The following error might indicate that something was wrong in the pod network: +--> +## 在 Vagrant 中使用 flannel 作为 Pod 网络时的默认 NIC -```sh +以下错误可能表明 Pod 网络中出现问题： + +```console Error from server (NotFound): the server could not find the requested resource ``` + - -## 在 Vagrant 中使用 flannel 作为 Pod 网络时的默认 NIC - -以下错误可能表明 Pod 网络中出现问题： - -```sh -Error from server (NotFound): the server could not find the requested resource -``` - - 如果你正在 Vagrant 中使用 flannel 作为 Pod 网络，则必须指定 flannel 的默认接口名称。 Vagrant 通常为所有 VM 分配两个接口。第一个为所有主机分配了 IP 地址 `10.0.2.15`，用于获得 NATed 的外部流量。 - 这可能会导致 flannel 出现问题，它默认为主机上的第一个接口。这导致所有主机认为它们具有 - 相同的公共 IP 地址。为防止这种情况，传递 `--iface eth1` 标志给 flannel 以便选择第二个接口。 + 这可能会导致 flannel 出现问题，它默认为主机上的第一个接口。这导致所有主机认为它们具有相同的公共 + IP 地址。为防止这种情况，传递 `--iface eth1` 标志给 flannel 以便选择第二个接口。 ## 容器使用的非公共 IP 在某些情况下 `kubectl logs` 和 `kubectl run` 命令或许会返回以下错误，即便除此之外集群一切功能正常： -```sh +```console Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host ``` + - 这或许是由于 Kubernetes 使用的 IP 无法与看似相同的子网上的其他 IP 进行通信的缘故， -可能是由机器提供商的政策所导致的。 + 可能是由机器提供商的政策所导致的。 - DigitalOcean 既分配一个共有 IP 给 `eth0`，也分配一个私有 IP 在内部用作其浮动 IP 功能的锚点， -然而 `kubelet` 将选择后者作为节点的 `InternalIP` 而不是公共 IP。 + 然而 `kubelet` 将选择后者作为节点的 `InternalIP` 而不是公共 IP。 使用 `ip addr show` 命令代替 `ifconfig` 命令去检查这种情况，因为 `ifconfig` 命令 不会显示有问题的别名 IP 地址。或者指定的 DigitalOcean 的 API 端口允许从 droplet 中 @@ -509,6 +447,16 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6 curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address ``` + 解决方法是通知 `kubelet` 使用哪个 `--node-ip`。当使用 DigitalOcean 时，可以是公网IP（分配给 `eth0` 的）， 或者是私网IP（分配给 `eth1` 的）。私网 IP 是可选的。 [kubadm `NodeRegistrationOptions` 结构](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3/#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions) @@ -531,15 +479,6 @@ where the `coredns` pods are not starting. To solve that you can try one of the - [Disable SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux). - Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`: - -```bash -kubectl -n kube-system get deployment coredns -o yaml | \ - sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \ - kubectl apply -f - -``` - -Another cause for CoreDNS to have `CrashLoopBackOff` is when a CoreDNS Pod deployed in Kubernetes detects a loop. [A number of workarounds](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters) -are available to avoid Kubernetes trying to restart the CoreDNS Pod every time CoreDNS detects the loop and exits. --> ## `coredns` Pod 有 `CrashLoopBackOff` 或者 `Error` 状态 @@ -558,15 +497,19 @@ kubectl -n kube-system get deployment coredns -o yaml | \ kubectl apply -f - ``` -CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部署的 CoreDNS Pod 检测 -到环路时。[有许多解决方法](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters) + +CoreDNS 处于 `CrashLoopBackOff` 时的另一个原因是当 Kubernetes 中部署的 CoreDNS Pod 检测到环路时。 +[有许多解决方法](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters) 可以避免在每次 CoreDNS 监测到循环并退出时，Kubernetes 尝试重启 CoreDNS Pod 的情况。 +{{< warning >}} -{{< warning >}} 禁用 SELinux 或设置 `allowPrivilegeEscalation` 为 `true` 可能会损害集群的安全性。 {{< /warning >}} @@ -574,26 +517,6 @@ the security of your cluster. ## etcd pods restart continually If you encounter the following error: - -``` -rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\"" -``` - -this issue appears if you run CentOS 7 with Docker 1.13.1.84. -This version of Docker can prevent the kubelet from executing into the etcd container. - -To work around the issue, choose one of these options: - -- Roll back to an earlier version of Docker, such as 1.13.1-75 -``` -yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64 -``` - -- Install one of the more recent recommended versions, such as 18.06: -```bash -sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo -yum install docker-ce-18.06.1.ce-3.el7.x86_64 -``` --> ## etcd Pod 持续重启 @@ -603,6 +526,14 @@ yum install docker-ce-18.06.1.ce-3.el7.x86_64 rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\"" ``` + 如果你使用 Docker 1.13.1.84 运行 CentOS 7 就会出现这种问题。 此版本的 Docker 会阻止 kubelet 在 etcd 容器中执行。 @@ -614,6 +545,9 @@ rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:24 yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64 ``` + - 安装较新的推荐版本之一，例如 18.06: ```shell @@ -622,9 +556,9 @@ rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:24 ``` ## 在节点被云控制管理器初始化之前，kube-proxy 就被调度了 @@ -693,6 +614,11 @@ server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: [] proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP ``` + 一种已知的解决方案是修补 kube-proxy DaemonSet，以允许在控制平面节点上调度它， 而不管它们的条件如何，将其与其他节点保持隔离，直到它们的初始保护条件消除： @@ -700,6 +626,9 @@ proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": { "tolerations": [ { "key": "CriticalAddonsOnly", "operator": "Exists" }, { "effect": "NoSchedule", "key": "node-role.kubernetes.io/control-plane" } ] } } } }' ``` + 此问题的跟踪[在这里](https://github.com/kubernetes/kubeadm/issues/1027)。 ## `kubeadm reset` 会卸载 `/var/lib/kubelet` -如果已经挂载了 `/var/lib/kubelet` 目录，执行 `kubeadm reset` +如果已经挂载了 `/var/lib/kubelet` 目录，执行 `kubeadm reset` 操作的时候会将其卸载。 要解决这一问题，可以在执行了 `kubeadm reset` 操作之后重新挂载 diff --git a/content/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer.md index a4156f14b9d..bdc47225fec 100644 --- a/content/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -25,9 +25,9 @@ nodes, _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_. --> -创建 {{< glossary_tooltip text="服务" term_id="service" >}} 时，你可以选择自动创建云网络负载均衡器。 +创建{{< glossary_tooltip text="服务" term_id="service" >}}时，你可以选择自动创建云网络负载均衡器。 负载均衡器提供外部可访问的 IP 地址，可将流量发送到集群节点上的正确端口上 -（ **假设集群在支持的环境中运行，并配置了正确的云负载均衡器驱动包**）。 +（**假设集群在支持的环境中运行，并配置了正确的云负载均衡器驱动包**）。 +## 回收负载均衡器 {#garbage-collecting-load-balancers} {{< feature-state for_k8s_version="v1.17" state="stable" >}} + -## 回收负载均衡器 {#garbage-collecting-load-balancers} - -{{< feature-state for_k8s_version="v1.17" state="stable" >}} - 在通常情况下，应在删除 LoadBalancer 类型 Service 后立即清除云服务供应商中的相关负载均衡器资源。 但是，众所周知，在删除关联的服务后，云资源被孤立的情况很多。 引入了针对服务负载均衡器的终结器保护，以防止这种情况发生。 @@ -321,11 +320,10 @@ Kubernetes 控制平面自动创建外部负载均衡器、健康检查（如果 ## {{% heading "whatsnext" %}} +* 遵循教程[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/) * 阅读[服务](/zh-cn/docs/concepts/services-networking/service/) * 阅读 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) -* 阅读[使用 Service 连接到应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) - diff --git a/content/zh-cn/docs/tasks/administer-cluster/enabling-service-topology.md b/content/zh-cn/docs/tasks/administer-cluster/enabling-service-topology.md deleted file mode 100644 index 102fcc6adb8..00000000000 --- a/content/zh-cn/docs/tasks/administer-cluster/enabling-service-topology.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: 开启服务拓扑 -content_type: task -min-kubernetes-server-version: 1.17 ---- - - - -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - - -这项功能，特别是 Alpha 状态的 `topologyKeys` 字段，在 Kubernetes v1.21 中已经弃用。 -在 Kubernetes v1.21 -加入的[拓扑感知提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints/)提供了类似的功能。 - - -**服务拓扑（Service Topology）** 使 {{< glossary_tooltip term_id="service">}} -能够根据集群中的 Node 拓扑来路由流量。 -比如，服务可以指定将流量优先路由到与客户端位于同一节点或者同一可用区域的端点上。 - -## {{% heading "prerequisites" %}} - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - -需要满足下列先决条件，才能启用拓扑感知的服务路由： - -* Kubernetes 1.17 或更高版本 -* 配置 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 以 iptables 或者 IPVS 模式运行 - - - - -## 启用服务拓扑 {#enable-service-topology} - -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - - -要启用服务拓扑，需要为所有 Kubernetes 组件启用 `ServiceTopology` -[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)： - -``` ---feature-gates="ServiceTopology=true` -``` - -## {{% heading "whatsnext" %}} - - -* 阅读[拓扑感知提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints/)，该技术是用来替换 `topologyKeys` 字段的。 -* 阅读[端点切片](/zh-cn/docs/concepts/services-networking/endpoint-slices) -* 阅读[服务拓扑](/zh-cn/docs/concepts/services-networking/service-topology)概念 -* 阅读[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/) \ No newline at end of file diff --git a/content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md b/content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md index 0eb80172926..533a1481095 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/zh-cn/docs/tasks/administer-cluster/encrypt-data.md @@ -350,11 +350,15 @@ program to retrieve the contents of your Secret. 3. 验证存储的密钥前缀是否为 `k8s:enc:aescbc:v1:`，这表明 `aescbc` provider 已加密结果数据。 + 确认 `etcd` 中显示的密钥名称和上述 `EncryptionConfiguration` 中指定的密钥名称一致。 + 在此例中，你可以看到在 `etcd` 和 `EncryptionConfiguration` 中使用了名为 `key1` 的加密密钥。 4. 通过 API 检索，验证 Secret 是否被正确解密： diff --git a/content/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize.md index cb9833a7082..71d4c4f7999 100644 --- a/content/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize.md +++ b/content/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize.md @@ -90,8 +90,7 @@ secretGenerator: {{% tab name=".env 文件" %}} 你也可以使用 `.env` 文件在 `kustomization.yaml` 中定义 `secretGenerator`。 @@ -141,8 +140,7 @@ the Secret data and appending the hash value to the name. This ensures that a new Secret is generated each time the data is modified. To verify that the Secret was created and to decode the Secret data, refer to -[Managing Secrets using -kubectl](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#verify-the-secret). +[Managing Secrets using kubectl](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#verify-the-secret). --> 生成 Secret 时，Secret 的名称最终是由 `name` 字段和数据的哈希值拼接而成。 这将保证每次修改数据时生成一个新的 Secret。 @@ -158,11 +156,11 @@ kubectl](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#verify-the- --> ## 编辑 Secret {#edit-secret} -1. 在 `kustomization.yaml` 文件中，修改诸如 `password` 等数据。 -1. 应用包含 kustomization 文件的目录： +1. 在 `kustomization.yaml` 文件中，修改诸如 `password` 等数据。 +1. 应用包含 kustomization 文件的目录： ```shell - kubectl apply -k + kubectl apply -k <目录路径> ``` ## {{% heading "whatsnext" %}} - 进一步阅读 [Secret 概念](/zh-cn/docs/concepts/configuration/secret/) -- 了解如何[使用 `kubectl` 命令管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- 了解如何[使用 kubectl 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - 了解如何[使用配置文件管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/static-pod.md b/content/zh-cn/docs/tasks/configure-pod-container/static-pod.md index 6f3a6c5d1c2..6e0f6c07e8f 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/static-pod.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/static-pod.md @@ -67,6 +67,13 @@ The `spec` of a static Pod cannot refer to other API objects {{< glossary_tooltip text="Secret" term_id="secret" >}} 等）。 {{< /note >}} +{{< note >}} + +静态 Pod 不支持[临时容器](/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/)。 +{{< /note >}} + ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} diff --git a/content/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md b/content/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md index b82f95fecde..89ad32dcd28 100644 --- a/content/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md +++ b/content/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md @@ -35,8 +35,8 @@ command. 包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中， 那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。 -[HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) 和 -[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA) +[HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) 和 +[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA) 使用 metrics API 中的数据调整工作负载副本和资源，以满足客户需求。 你也可以通过 [`kubectl top`](/docs/reference/generated/kubectl/kubectl-commands#top) 命令来查看资源指标。 @@ -51,8 +51,9 @@ the simpler Metrics API by deploying a second that uses the _Custom Metrics API_. --> Metrics API 及其启用的指标管道仅提供最少的 CPU 和内存指标，以启用使用 HPA 和/或 VPA 的自动扩展。 -如果你想提供更完整的指标集，你可以通过部署使用 **Custom Metrics API** 的第二个 -[指标管道](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#full-metrics-pipeline)来作为简单的 Metrics API 的补充。 +如果你想提供更完整的指标集，你可以通过部署使用 **Custom Metrics API** +的第二个[指标管道](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/#full-metrics-pipeline)来作为简单的 +Metrics API 的补充。 {{< /note >}} C[kubelet] -E[Container
    runtime] --> D -E1[Container
    runtime] --> D -P[pod data] -.- C +E[容器
    运行时] --> D +E1[容器
    运行时] --> D +P[Pod 数据] -.- C end -L[API
    server] +L[API
    服务器] W[HPA] C ---->|Summary
    API| A -->|metrics
    API| L --> W end @@ -143,9 +144,8 @@ autoscaler components. Here is an example of the Metrics API request for a `minikube` node piped through `jq` for easier reading: - --> -## Metrics API {#the-metrics-api} +## Metrics API {#metrics-api} {{< feature-state for_k8s_version="1.8" state="beta" >}} @@ -194,7 +194,6 @@ Sample response: Here is an example of the Metrics API request for a `kube-scheduler-minikube` pod contained in the `kube-system` namespace and piped through `jq` for easier reading: --> - 下面是一个 `kube-system` 命名空间中的 `kube-scheduler-minikube` Pod 的 Metrics API 请求示例， 通过 `jq` 管道处理以便于阅读： @@ -250,7 +249,6 @@ To learn more about the Metrics API, see [resource metrics API design](https://g the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-server) and the [resource metrics API](https://github.com/kubernetes/metrics#resource-metrics-api). --> - Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics) 代码库中定义。 你必须启用 [API 聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)并为 `metrics.k8s.io` API 注册一个 [APIService](/zh-cn/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)。 @@ -260,11 +258,11 @@ Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics) 代码 [metrics-server 代码库](https://github.com/kubernetes-sigs/metrics-server) 和 [Resource Metrics API](https://github.com/kubernetes/metrics#resource-metrics-api)。 +{{< note >}} -{{< note >}} 你必须部署提供 Metrics API 服务的 metrics-server 或其他适配器才能访问它。 {{< /note >}} @@ -364,6 +362,8 @@ metrics-server 调用 [kubelet](/zh-cn/docs/reference/command-line-tools-referen * 版本 v0.6.0+ 中，使用指标资源端点 `/metrics/resource` * 旧版本中使用 Summary API 端点 `/stats/summary` +## {{% heading "whatsnext" %}} + - 了解更多 metrics-server，参阅 [metrics-server 代码库](https://github.com/kubernetes-sigs/metrics-server)。 你还可以查看以下内容： @@ -385,46 +384,11 @@ You can also check out the following: * [metrics-server FAQ](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md) * [metrics-server known issues](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md) * [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases) -* [Horizontal Pod Autoscaling](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) +* [水平自动扩缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) - -### Summary API 来源 {#summary-api-source} - -[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、Pod 和容器级别收集统计信息， -并在 [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) -中提供它们的统计信息供消费者阅读。 - - - -下面是一个 `minikube` 节点的 Summary API 请求示例： - -```shell -kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary" -``` - - -这是使用 `curl` 来执行的相同 API 调用： - -```shell -curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary -``` - -{{< note >}} - -从 metrics-server 0.6.x 开始，Summary API `/stats/summary` 端点被 `/metrics/resource` 端点替换。 -{{< /note >}} \ No newline at end of file +若要了解 kubelet 如何提供节点指标以及你可以如何通过 Kubernetes API 访问这些指标， +请阅读[节点指标数据](/zh-cn/docs/reference/instrumentation/node-metrics)。 diff --git a/content/zh-cn/docs/tasks/tools/_index.md b/content/zh-cn/docs/tasks/tools/_index.md index f714ec8e3e5..b112852e592 100644 --- a/content/zh-cn/docs/tasks/tools/_index.md +++ b/content/zh-cn/docs/tasks/tools/_index.md @@ -12,18 +12,18 @@ weight: 10 no_list: true --> - + + -## kubectl - -Kubernetes 命令行工具，[kubectl](/zh-cn/docs/reference/kubectl/kubectl/)， +Kubernetes 命令行工具 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/)， 让你可以对 Kubernetes 集群运行命令。 你可以使用 kubectl 来部署应用、监测和管理集群资源以及查看日志。 @@ -44,21 +44,18 @@ kubectl 可安装在各种 Linux 平台、 macOS 和 Windows 上。 - [在 macOS 上安装 kubectl](/zh-cn/docs/tasks/tools/install-kubectl-macos) - [在 Windows 上安装 kubectl](/zh-cn/docs/tasks/tools/install-kubectl-windows) - -## kind - [`kind`](https://kind.sigs.k8s.io/docs/) 让你能够在本地计算机上运行 Kubernetes。 `kind` 要求你安装并配置好 [Docker](https://docs.docker.com/get-docker/)。 @@ -70,11 +67,11 @@ kind [快速入门](https://kind.sigs.k8s.io/docs/user/quick-start/)页面展示 查看 kind 的快速入门指南     - -## minikube - 与 `kind` 类似，[`minikube`](https://minikube.sigs.k8s.io/) 是一个工具， 能让你在本地运行 Kubernetes。 -`minikube` 在你本地的个人计算机（包括 Windows、macOS 和 Linux PC）运行一个单节点的 +`minikube` 在你的个人计算机（包括 Windows、macOS 和 Linux PC）上运行一个一体化（all-in-one）或多节点的本地 Kubernetes 集群，以便你来尝试 Kubernetes 或者开展每天的开发工作。 如果你关注如何安装此工具，可以按官方的 [Get Started!](https://minikube.sigs.k8s.io/docs/start/)指南操作。 -你可以使用 {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} 工具来 -创建和管理 Kubernetes 集群。 +你可以使用 {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} +工具来创建和管理 Kubernetes 集群。 该工具能够执行必要的动作并用一种用户友好的方式启动一个可用的、安全的集群。 [安装 kubeadm](/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) -展示了如何安装 kubeadm 的过程。 -一旦安装了 kubeadm， +展示了如何安装 kubeadm 的过程。一旦安装了 kubeadm， 你就可以使用它来[创建一个集群](/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)。 - + 查看 kubeadm 安装指南 - diff --git a/content/zh-cn/docs/tasks/tools/install-kubectl-linux.md b/content/zh-cn/docs/tasks/tools/install-kubectl-linux.md index ba9de5d763e..43650626ec4 100644 --- a/content/zh-cn/docs/tasks/tools/install-kubectl-linux.md +++ b/content/zh-cn/docs/tasks/tools/install-kubectl-linux.md @@ -197,7 +197,7 @@ Or use this for detailed view of version: 2. 下载 Google Cloud 公开签名秘钥： ```shell - sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg + sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg ``` +在低于 Debian 12 和 Ubuntu 22.04 的发行版本中，`/etc/apt/keyrings` 默认不存在。 +如有需要，你可以创建此目录，并将其设置为对所有人可读，但仅对管理员可写。 +{{< /note >}} {{% /tab %}} diff --git a/content/zh-cn/docs/tutorials/services/source-ip.md b/content/zh-cn/docs/tutorials/services/source-ip.md index fbba0023232..ddd734daab2 100644 --- a/content/zh-cn/docs/tutorials/services/source-ip.md +++ b/content/zh-cn/docs/tutorials/services/source-ip.md @@ -8,7 +8,7 @@ weight: 10 title: Using Source IP content_type: tutorial min-kubernetes-server-version: v1.5 -weight: 10 +weight: 40 --> @@ -134,7 +134,7 @@ The output is similar to this: --> 输出类似于： ``` -NAME STATUS ROLES AGE VERSION +NAME STATUS ROLES AGE VERSION kubernetes-node-6jst Ready 2h v1.13.0 kubernetes-node-cx31 Ready 2h v1.13.0 kubernetes-node-jj1t Ready 2h v1.13.0 @@ -174,7 +174,7 @@ service/clusterip exposed kubectl get svc clusterip ``` 输出类似于： ``` @@ -254,7 +254,6 @@ are source NAT'd by default. You can test this by creating a `NodePort` Service: ```shell kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort ``` - @@ -430,7 +429,7 @@ service/loadbalancer exposed Print out the IP addresses of the Service: --> 打印 Service 的 IP 地址： -```shell +```console kubectl get svc loadbalancer ``` -* 详细了解[通过 Service 连接应用程序](/zh-cn/docs/concepts/services-networking/connect-applications-service/) +* 详细了解[通过 Service 连接应用程序](/zh-cn/docs/tutorials/services/connect-applications-service/) * 阅读如何[创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/data/releases/eol.yaml b/data/releases/eol.yaml index 1a435dcabb9..8e63d1894dd 100644 --- a/data/releases/eol.yaml +++ b/data/releases/eol.yaml @@ -1,4 +1,17 @@ branches: + - release: "1.22" + finalPatchRelease: "1.22.17" + endOfLifeDate: 2022-12-08 + note: >- + 1.22.17 will be released in December 2022 (after the EOL date) to backport registry changes and fix two critical issues. + - release: "1.22" + finalPatchRelease: "1.22.16" + endOfLifeDate: 2022-11-09 + note: >- + 1.22.16 was released in November 2022 (after the EOL date) to fix CVE-2022-3162 and CVE-2022-3294. + - release: "1.22" + finalPatchRelease: "1.22.15" + endOfLifeDate: 2022-10-28 - release: "1.21" finalPatchRelease: "1.21.14" endOfLifeDate: 2022-06-28 diff --git a/data/releases/schedule.yaml b/data/releases/schedule.yaml index 81d1d600109..f1226419ea9 100644 --- a/data/releases/schedule.yaml +++ b/data/releases/schedule.yaml @@ -6,7 +6,7 @@ schedules: next: release: 1.25.5 cherryPickDeadline: 2022-12-02 - targetDate: 2022-12-07 + targetDate: 2022-12-08 previousPatches: - release: 1.25.4 cherryPickDeadline: 2022-11-04 @@ -31,7 +31,7 @@ schedules: next: release: 1.24.9 cherryPickDeadline: 2022-12-02 - targetDate: 2022-12-07 + targetDate: 2022-12-08 previousPatches: - release: 1.24.8 cherryPickDeadline: 2022-11-04 @@ -68,7 +68,7 @@ schedules: next: release: 1.23.15 cherryPickDeadline: 2022-12-02 - targetDate: 2022-12-07 + targetDate: 2022-12-08 previousPatches: - release: 1.23.14 cherryPickDeadline: 2022-11-04 @@ -118,63 +118,3 @@ schedules: - release: 1.23.1 cherryPickDeadline: 2021-12-14 targetDate: 2021-12-16 -- release: 1.22 - releaseDate: 2021-08-04 - maintenanceModeStartDate: 2022-08-28 - endOfLifeDate: 2022-10-28 - next: - release: 1.22.16 - cherryPickDeadline: 2022-10-07 - targetDate: 2022-10-12 - note: >- - The 1.22 release is in maintenance mode. As per the support policy, 1.22.16 will be released **only** if there are critical and/or security issues. - previousPatches: - - release: 1.22.15 - cherryPickDeadline: 2022-09-20 - targetDate: 2022-09-21 - note: >- - [Out-of-Band release to fix the regression introduced in 1.22.14](https://groups.google.com/a/kubernetes.io/g/dev/c/tA6LNOQTR4Q/m/zL73maPTAQAJ) - - release: 1.22.14 - cherryPickDeadline: 2022-09-09 - targetDate: 2022-09-14 - note: >- - [Regression](https://groups.google.com/a/kubernetes.io/g/dev/c/tA6LNOQTR4Q/m/zL73maPTAQAJ) - - release: 1.22.13 - cherryPickDeadline: 2022-08-12 - targetDate: 2022-08-17 - - release: 1.22.12 - cherryPickDeadline: 2022-07-08 - targetDate: 2022-07-13 - - release: 1.22.11 - cherryPickDeadline: 2022-06-10 - targetDate: 2022-06-15 - - release: 1.22.10 - cherryPickDeadline: 2022-05-20 - targetDate: 2022-05-24 - - release: 1.22.9 - cherryPickDeadline: 2022-04-08 - targetDate: 2022-04-13 - - release: 1.22.8 - cherryPickDeadline: 2022-03-11 - targetDate: 2022-03-16 - - release: 1.22.7 - cherryPickDeadline: 2022-02-11 - targetDate: 2022-02-16 - - release: 1.22.6 - cherryPickDeadline: 2022-01-14 - targetDate: 2022-01-19 - - release: 1.22.5 - cherryPickDeadline: 2021-12-10 - targetDate: 2021-12-15 - - release: 1.22.4 - cherryPickDeadline: 2021-11-12 - targetDate: 2021-11-17 - - release: 1.22.3 - cherryPickDeadline: 2021-10-22 - targetDate: 2021-10-27 - - release: 1.22.2 - cherryPickDeadline: 2021-09-10 - targetDate: 2021-09-15 - - release: 1.22.1 - cherryPickDeadline: 2021-08-16 - targetDate: 2021-08-19 diff --git a/static/_redirects b/static/_redirects index 037f64b72cd..4d8e4a51faf 100644 --- a/static/_redirects +++ b/static/_redirects @@ -235,6 +235,8 @@ /docs/reference/kubernetes-api/labels-annotations-taints/ /docs/reference/labels-annotations-taints/ 301 +/docs/reference/ports-and-protocols/ /docs/reference/networking/ports-and-protocols/ 301 + /docs/reporting-security-issues/ /docs/reference/issues-security/security/ 301 /security/ /docs/reference/issues-security/security/ 302