Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
Nate W
commit
0135d3642b
|
|
@ -1,6 +1,7 @@
|
|||
[submodule "themes/docsy"]
|
||||
path = themes/docsy
|
||||
url = https://github.com/google/docsy.git
|
||||
branch = v0.2.0
|
||||
[submodule "api-ref-generator"]
|
||||
path = api-ref-generator
|
||||
url = https://github.com/kubernetes-sigs/reference-docs
|
||||
|
|
|
|||
|
|
@ -27,16 +27,18 @@ RUN mkdir $HOME/src && \
|
|||
FROM golang:1.16-alpine
|
||||
|
||||
RUN apk add --no-cache \
|
||||
runuser \
|
||||
git \
|
||||
openssh-client \
|
||||
rsync \
|
||||
npm && \
|
||||
npm install -D autoprefixer postcss-cli
|
||||
|
||||
RUN mkdir -p /usr/local/src && \
|
||||
cd /usr/local/src && \
|
||||
RUN mkdir -p /var/hugo && \
|
||||
addgroup -Sg 1000 hugo && \
|
||||
adduser -Sg hugo -u 1000 -h /src hugo
|
||||
adduser -Sg hugo -u 1000 -h /var/hugo hugo && \
|
||||
chown -R hugo: /var/hugo && \
|
||||
runuser -u hugo -- git config --global --add safe.directory /src
|
||||
|
||||
COPY --from=0 /go/bin/hugo /usr/local/bin/hugo
|
||||
|
||||
|
|
|
|||
|
|
@ -131,7 +131,7 @@ Hugo is shipped in two set of binaries for technical reasons. The current websit
|
|||
If you run `make serve` on macOS and receive the following error:
|
||||
|
||||
-->
|
||||
### 对 macOs 上打开太多文件的故障排除
|
||||
### 对 macOS 上打开太多文件的故障排除
|
||||
|
||||
如果在 macOS 上运行 `make serve` 收到以下错误：
|
||||
|
||||
|
|
|
|||
|
|
@ -24,14 +24,14 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf
|
|||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) vereint Flannel und Calico um Networking- und Network-Policies bereitzustellen.
|
||||
* [Cilium](https://github.com/cilium/cilium) ist ein L3 Network- and Network-Policy-Plugin welches das transparent HTTP/API/L7-Policies durchsetzen kann. Sowohl Routing- als auch Overlay/Encapsulation-Modes werden uterstützt. Außerdem kann Cilium auf andere CNI-Plugins aufsetzen.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave.
|
||||
* [Contiv](http://contiv.github.io) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
|
||||
* [Contiv](https://contivpp.io/) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
|
||||
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht.
|
||||
* Multus ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) ist eine SDN-Plattform die Policy-Basiertes Networking zwischen Kubernetes Pods und nicht-Kubernetes Umgebungen inklusive Sichtbarkeit und Security-Monitoring bereitstellt.
|
||||
* [Romana](http://romana.io) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar.
|
||||
* [Romana](https://github.com/romana/romana) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar.
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) bietet Networking and Network-Policies und arbeitet auf beiden Seiten der Network-Partition ohne auf eine externe Datenbank angwiesen zu sein.
|
||||
|
||||
## Service-Discovery
|
||||
|
|
@ -52,5 +52,3 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf
|
|||
Es gibt einige weitere Add-Ons die in dem abgekündigten [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)-Verzeichnis dokumentiert sind.
|
||||
|
||||
Add-Ons die ordentlich gewartet werden dürfen gerne hier aufgezählt werden. Wir freuen uns auf PRs!
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -248,7 +248,7 @@ einige Einschränkungen:
|
|||
Eintrag zur Liste `metadata.finalizers` hinzugefügt werden.
|
||||
- Pod-Updates dürfen keine Felder ändern, die Ausnahmen sind
|
||||
`spec.containers[*].image`,
|
||||
`spec.initContainers[*].image`,` spec.activeDeadlineSeconds` oder
|
||||
`spec.initContainers[*].image`, `spec.activeDeadlineSeconds` oder
|
||||
`spec.tolerations`. Für `spec.tolerations` kannnst du nur neue Einträge
|
||||
hinzufügen.
|
||||
- Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt:
|
||||
|
|
|
|||
|
|
@ -322,7 +322,7 @@ Ausgabeformat | Beschreibung
|
|||
|
||||
### Kubectl Ausgabe Ausführlichkeit und Debugging
|
||||
|
||||
Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v ` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) beschrieben.
|
||||
Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) beschrieben.
|
||||
|
||||
Ausführlichkeit | Beschreibung
|
||||
--------------| -----------
|
||||
|
|
|
|||
|
|
@ -4,7 +4,12 @@ date: 2017-11-02
|
|||
slug: containerd-container-runtime-options-kubernetes
|
||||
url: /blog/2017/11/Containerd-Container-Runtime-Options-Kubernetes
|
||||
---
|
||||
**_Editor's note: Today's post is by Lantao Liu, Software Engineer at Google, and Mike Brown, Open Source Developer Advocate at IBM._**
|
||||
|
||||
**Authors:** Lantao Liu (Google), and Mike Brown (IBM)
|
||||
|
||||
_Update: Kubernetes support for Docker via `dockershim` is now deprecated.
|
||||
For more information, read the [deprecation notice](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation).
|
||||
You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
|
||||
|
||||
A _container runtime_ is software that executes containers and manages container images on a node. Today, the most widely known container runtime is [Docker](https://www.docker.com/), but there are other container runtimes in the ecosystem, such as [rkt](https://coreos.com/rkt/), [containerd](https://containerd.io/), and [lxd](https://linuxcontainers.org/lxd/). Docker is by far the most common container runtime used in production Kubernetes environments, but Docker’s smaller offspring, containerd, may prove to be a better option. This post describes using containerd with Kubernetes.
|
||||
|
||||
|
|
|
|||
|
|
@ -360,7 +360,7 @@ So let's fix the issue by installing the missing package:
|
|||
sudo apt install -y conntrack
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
Let's try to launch it again:
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,10 @@ slug: dont-panic-kubernetes-and-docker
|
|||
|
||||
**Authors:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
|
||||
|
||||
_Update: Kubernetes support for Docker via `dockershim` is now deprecated.
|
||||
For more information, read the [deprecation notice](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation).
|
||||
You can also discuss the deprecation via a dedicated [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
|
||||
|
||||
Kubernetes is [deprecating
|
||||
Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)
|
||||
as a container runtime after v1.20.
|
||||
|
|
|
|||
|
|
@ -5,13 +5,20 @@ date: 2021-11-12
|
|||
slug: are-you-ready-for-dockershim-removal
|
||||
---
|
||||
|
||||
**Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
|
||||
**Authors:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
|
||||
|
||||
{{% alert color="info" title="Poll closed" %}}
|
||||
This poll closed on January 7, 2022.
|
||||
{{% /alert %}}
|
||||
|
||||
Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/).
|
||||
Last year we [announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
|
||||
that Kubernetes' dockershim component (which provides a built-in integration for
|
||||
Docker Engine) is deprecated.
|
||||
|
||||
_Update: There's a [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)
|
||||
with more information, and you can also discuss the deprecation via a dedicated
|
||||
[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)._
|
||||
|
||||
Our current plan is to remove dockershim from the Kubernetes codebase soon.
|
||||
We are looking for feedback from you whether you are ready for dockershim
|
||||
removal and to ensure that you are ready when the time comes.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Updated: Dockershim Removal FAQ"
|
||||
linkTitle: "Dockershim Removal FAQ"
|
||||
date: 2022-02-17
|
||||
slug: dockershim-faq
|
||||
aliases: [ '/dockershim' ]
|
||||
|
|
@ -184,7 +185,7 @@ options are available as you migrate things over.
|
|||
[documentation]: https://github.com/containerd/cri/blob/master/docs/registry.md
|
||||
|
||||
For instructions on how to use containerd and CRI-O with Kubernetes, see the
|
||||
Kubernetes documentation on [Container Runtimes]
|
||||
Kubernetes documentation on [Container Runtimes].
|
||||
|
||||
[Container Runtimes]: /docs/setup/production-environment/container-runtimes/
|
||||
|
||||
|
|
@ -192,7 +193,10 @@ Kubernetes documentation on [Container Runtimes]
|
|||
|
||||
If you use a vendor-supported Kubernetes distribution, you can ask them about
|
||||
upgrade plans for their products. For end-user questions, please post them
|
||||
to our end user community forum: https://discuss.kubernetes.io/.
|
||||
to our end user community forum: https://discuss.kubernetes.io/.
|
||||
|
||||
You can discuss the decision to remove dockershim via a dedicated
|
||||
[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917).
|
||||
|
||||
You can also check out the excellent blog post
|
||||
[Wait, Docker is deprecated in Kubernetes now?][dep] a more in-depth technical
|
||||
|
|
@ -200,6 +204,15 @@ discussion of the changes.
|
|||
|
||||
[dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
|
||||
|
||||
### Is there any tooling that can help me find dockershim in use
|
||||
|
||||
Yes! The [Detector for Docker Socket (DDS)][dds] is a kubectl plugin that you can
|
||||
install and then use to check your cluster. DDS can detect if active Kubernetes workloads
|
||||
are mounting the Docker Engine socket (`docker.sock`) as a volume.
|
||||
Find more details and usage patterns in the DDS project's [README][dds].
|
||||
|
||||
[dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket
|
||||
|
||||
### Can I have a hug?
|
||||
|
||||
Yes, we're still giving hugs as requested. 🤗🤗🤗
|
||||
|
|
|
|||
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Dockershim: The Historical Context"
|
||||
date: 2022-05-03
|
||||
slug: dockershim-historical-context
|
||||
---
|
||||
|
||||
**Author:** Kat Cosgrove
|
||||
|
||||
|
||||
Dockershim has been removed as of Kubernetes v1.24, and this is a positive move for the project. However, context is important for fully understanding something, be it socially or in software development, and this deserves a more in-depth review. Alongside the dockershim removal in Kubernetes v1.24, we’ve seen some confusion (sometimes at a panic level) and dissatisfaction with this decision in the community, largely due to a lack of context around this removal. The decision to deprecate and eventually remove dockershim from Kubernetes was not made quickly or lightly. Still, it’s been in the works for so long that many of today’s users are newer than that decision, and certainly newer than the choices that led to the dockershim being necessary in the first place.
|
||||
|
||||
So what is the dockershim, and why is it going away?
|
||||
|
||||
In the early days of Kubernetes, we only supported one container runtime. That runtime was Docker Engine. Back then, there weren’t really a lot of other options out there and Docker was the dominant tool for working with containers, so this was not a controversial choice. Eventually, we started adding more container runtimes, like rkt and hypernetes, and it became clear that Kubernetes users want a choice of runtimes working best for them. So Kubernetes needed a way to allow cluster operators the flexibility to use whatever runtime they choose.
|
||||
|
||||
The [Container Runtime Interface](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) (CRI) was released to allow that flexibility. The introduction of CRI was great for the project and users alike, but it did introduce a problem: Docker Engine’s use as a container runtime predates CRI, and Docker Engine is not CRI-compatible. To solve this issue, a small software shim (dockershim) was introduced as part of the kubelet component specifically to fill in the gaps between Docker Engine and CRI, allowing cluster operators to continue using Docker Engine as their container runtime largely uninterrupted.
|
||||
|
||||
However, this little software shim was never intended to be a permanent solution. Over the course of years, its existence has introduced a lot of unnecessary complexity to the kubelet itself. Some integrations are inconsistently implemented for Docker because of this shim, resulting in an increased burden on maintainers, and maintaining vendor-specific code is not in line with our open source philosophy. To reduce this maintenance burden and move towards a more collaborative community in support of open standards, [KEP-2221 was introduced](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim), proposing the removal of the dockershim. With the release of Kubernetes v1.20, the deprecation was official.
|
||||
|
||||
We didn’t do a great job communicating this, and unfortunately, the deprecation announcement led to some panic within the community. Confusion around what this meant for Docker as a company, if container images built by Docker would still run, and what Docker Engine actually is led to a conflagration on social media. This was our fault; we should have more clearly communicated what was happening and why at the time. To combat this, we released [a blog](/blog/2020/12/02/dont-panic-kubernetes-and-docker/) and [accompanying FAQ](/blog/2020/12/02/dockershim-faq/) to allay the community’s fears and correct some misconceptions about what Docker is and how containers work within Kubernetes. As a result of the community’s concerns, Docker and Mirantis jointly agreed to continue supporting the dockershim code in the form of [cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/), allowing you to continue using Docker Engine as your container runtime if need be. For the interest of users who want to try other runtimes, like containerd or cri-o, [migration documentation was written](docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/).
|
||||
|
||||
We later [surveyed the community](https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/) and [discovered that there are still many users with questions and concerns](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim). In response, Kubernetes maintainers and the CNCF committed to addressing these concerns by extending documentation and other programs. In fact, this blog post is a part of this program. With so many end users successfully migrated to other runtimes, and improved documentation, we believe that everyone has a paved way to migration now.
|
||||
|
||||
Docker is not going away, either as a tool or as a company. It’s an important part of the cloud native community and the history of the Kubernetes project. We wouldn’t be where we are without them. That said, removing dockershim from kubelet is ultimately good for the community, the ecosystem, the project, and open source at large. This is an opportunity for all of us to come together to support open standards, and we’re glad to be doing so with the help of Docker and the community.
|
||||
|
|
@ -21,6 +21,7 @@ This page lists some of the available add-ons and links to their respective inst
|
|||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
|
||||
* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
|
||||
* [Contiv](https://contivpp.io/) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
|
||||
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ your Pod spec.
|
|||
|
||||
For example, consider the following Pod spec:
|
||||
|
||||
{{<codenew file="pods/pod-with-node-affinity.yaml">}}
|
||||
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
|
||||
|
||||
In this example, the following rules apply:
|
||||
|
||||
|
|
@ -167,7 +167,7 @@ scheduling decision for the Pod.
|
|||
|
||||
For example, consider the following Pod spec:
|
||||
|
||||
{{<codenew file="pods/pod-with-affinity-anti-affinity.yaml">}}
|
||||
{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
|
||||
|
||||
If there are two possible nodes that match the
|
||||
`requiredDuringSchedulingIgnoredDuringExecution` rule, one with the
|
||||
|
|
|
|||
|
|
@ -478,7 +478,7 @@ in the Pod manifest, and represent parameters to the container runtime.
|
|||
|
||||
Security profiles are control plane mechanisms to enforce specific settings in the Security Context,
|
||||
as well as other related parameters outside the Security Context. As of July 2021,
|
||||
[Pod Security Policies](/docs/concepts/profile/pod-security-profile/) are deprecated in favor of the
|
||||
[Pod Security Policies](/docs/concepts/security/pod-security-policy/) are deprecated in favor of the
|
||||
built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/).
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
|
|
|||
|
|
@ -323,17 +323,6 @@ If the feature gate `ExpandedDNSConfig` is enabled for the kube-apiserver and
|
|||
the kubelet, it is allowed for Kubernetes to have at most 32 search domains and
|
||||
a list of search domains of up to 2048 characters.
|
||||
|
||||
### Feature availability
|
||||
|
||||
The availability of Pod DNS Config and DNS Policy "`None`" is shown as below.
|
||||
|
||||
| k8s version | Feature support |
|
||||
| :---------: |:-----------:|
|
||||
| 1.14 | Stable |
|
||||
| 1.10 | Beta (on by default)|
|
||||
| 1.9 | Alpha |
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -45,42 +45,7 @@ See the [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "vers
|
|||
|
||||
An example NetworkPolicy might look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: test-network-policy
|
||||
namespace: default
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
role: db
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
ingress:
|
||||
- from:
|
||||
- ipBlock:
|
||||
cidr: 172.17.0.0/16
|
||||
except:
|
||||
- 172.17.1.0/24
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
project: myproject
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
role: frontend
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 6379
|
||||
egress:
|
||||
- to:
|
||||
- ipBlock:
|
||||
cidr: 10.0.0.0/24
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 5978
|
||||
```
|
||||
{{< codenew file="service/networking/networkpolicy.yaml" >}}
|
||||
|
||||
{{< note >}}
|
||||
POSTing this to the API server for your cluster will have no effect unless your chosen networking solution supports network policy.
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl wi
|
|||
for it to delete each pod before deleting the ReplicationController itself. If this kubectl
|
||||
command is interrupted, it can be restarted.
|
||||
|
||||
When using the REST API or Go client library, you need to do the steps explicitly (scale replicas to
|
||||
When using the REST API or [client library](/docs/reference/using-api/client-libraries), you need to do the steps explicitly (scale replicas to
|
||||
0, wait for pod deletions, then delete the ReplicationController).
|
||||
|
||||
### Deleting only a ReplicationController
|
||||
|
|
@ -194,7 +194,7 @@ You can delete a ReplicationController without affecting any of its pods.
|
|||
|
||||
Using kubectl, specify the `--cascade=orphan` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
|
||||
|
||||
When using the REST API or Go client library, you can delete the ReplicationController object.
|
||||
When using the REST API or [client library](/docs/reference/using-api/client-libraries), you can delete the ReplicationController object.
|
||||
|
||||
Once the original is deleted, you can create a new ReplicationController to replace it. As long
|
||||
as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
|
||||
|
|
|
|||
|
|
@ -87,3 +87,17 @@ To close a pull request, leave a `/close` comment on the PR.
|
|||
The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
## PR Wrangler shadow program
|
||||
|
||||
In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program was introduced to help new contributors understand the PR wrangling process.
|
||||
|
||||
### Become a shadow
|
||||
|
||||
- If you are interested in shadowing as a PR wrangler, please visit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) to see the PR wrangling schedule for this year and sign up.
|
||||
|
||||
- Kubernetes org members can edit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) and sign up to shadow an existing PR Wrangler for a week.
|
||||
|
||||
- Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to Brad Topol (`@bradtopol`) or one of the [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership).
|
||||
|
||||
- Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](slack.k8s.io).
|
||||
|
|
@ -31,7 +31,7 @@ kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
|
|||
The RBAC API declares four kinds of Kubernetes object: _Role_, _ClusterRole_,
|
||||
_RoleBinding_ and _ClusterRoleBinding_. You can
|
||||
[describe objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects),
|
||||
or amend them, using tools such as `kubectl,` just like any other Kubernetes object.
|
||||
or amend them, using tools such as `kubectl`, just like any other Kubernetes object.
|
||||
|
||||
{{< caution >}}
|
||||
These objects, by design, impose access restrictions. If you are making changes
|
||||
|
|
|
|||
|
|
@ -19,4 +19,9 @@ You can request eviction either by directly calling the Eviction API
|
|||
using a client of the kube-apiserver, like the `kubectl drain` command.
|
||||
When an `Eviction` object is created, the API server terminates the Pod.
|
||||
|
||||
API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)
|
||||
and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination).
|
||||
|
||||
API-initiated eviction is not the same as [node-pressure eviction](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction).
|
||||
|
||||
* See [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) for more information.
|
||||
|
|
|
|||
|
|
@ -15,6 +15,76 @@ This document serves both as a reference to the values and as a coordination poi
|
|||
|
||||
## Labels, annotations and taints used on API objects
|
||||
|
||||
### app.kubernetes.io/component
|
||||
|
||||
Example: `app.kubernetes.io/component=database`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The component within the architecture.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/created-by
|
||||
|
||||
Example: `app.kubernetes.io/created-by=controller-manager`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The controller/user who created this resource.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/instance
|
||||
|
||||
Example: `app.kubernetes.io/instance=mysql-abcxzy`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
A unique name identifying the instance of an application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/managed-by
|
||||
|
||||
Example: `app.kubernetes.io/managed-by=helm`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The tool being used to manage the operation of an application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/name
|
||||
|
||||
Example: `app.kubernetes.io/name=mysql`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The name of the application.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/part-of
|
||||
|
||||
Example: `app.kubernetes.io/part-of=wordpress`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The name of a higher level application this one is part of.
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### app.kubernetes.io/version
|
||||
|
||||
Example: `app.kubernetes.io/version="5.7.21"`
|
||||
|
||||
Used on: All Objects
|
||||
|
||||
The current version of the application (e.g., a semantic version, revision hash, etc.).
|
||||
|
||||
One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels).
|
||||
|
||||
### kubernetes.io/arch
|
||||
|
||||
Example: `kubernetes.io/arch=amd64`
|
||||
|
|
|
|||
|
|
@ -2,27 +2,27 @@
|
|||
reviewers:
|
||||
- vincepri
|
||||
- bart0sh
|
||||
title: Container runtimes
|
||||
title: Container Runtimes
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
<!-- overview -->
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
You need to install a
|
||||
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
|
||||
into each node in the cluster so that Pods can run there. This page outlines
|
||||
what is involved and describes related tasks for setting up nodes.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
Kubernetes {{< skew currentVersion >}} requires that you use a runtime that
|
||||
conforms with the
|
||||
conforms with the
|
||||
{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI).
|
||||
|
||||
See [CRI version support](#cri-versions) for more information.
|
||||
|
||||
This page lists details for using several common container runtimes with
|
||||
Kubernetes, on Linux:
|
||||
This page provides an outline of how to use several common container runtimes with
|
||||
Kubernetes.
|
||||
|
||||
- [containerd](#containerd)
|
||||
- [CRI-O](#cri-o)
|
||||
|
|
@ -30,12 +30,27 @@ Kubernetes, on Linux:
|
|||
- [Mirantis Container Runtime](#mcr)
|
||||
|
||||
{{< note >}}
|
||||
For other operating systems, look for documentation specific to your platform.
|
||||
Kubernetes releases before v1.24 included a direct integration with Docker Engine,
|
||||
using a component named _dockershim_. That special direct integration is no longer
|
||||
part of Kubernetes (this removal was
|
||||
[announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
|
||||
as part of the v1.20 release).
|
||||
You can read
|
||||
[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to understand how this removal might
|
||||
affect you. To learn about migrating from using dockershim, see
|
||||
[Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/).
|
||||
|
||||
If you are running a version of Kubernetes other than v{{< skew currentVersion >}},
|
||||
check the documentation for that version.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Cgroup drivers
|
||||
|
||||
Control groups are used to constrain resources that are allocated to processes.
|
||||
On Linux, {{< glossary_tooltip text="control groups" term_id="cgroup" >}}
|
||||
are used to constrain resources that are allocated to processes.
|
||||
|
||||
When [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is chosen as the init
|
||||
system for a Linux distribution, the init process generates and consumes a root control group
|
||||
|
|
@ -64,7 +79,7 @@ If you have automation that makes it feasible, replace the node with another usi
|
|||
configuration, or reinstall it using automation.
|
||||
{{< /caution >}}
|
||||
|
||||
## Cgroup v2
|
||||
### Cgroup version 2 {#cgroup-v2}
|
||||
|
||||
Cgroup v2 is the next version of the cgroup Linux API. Differently than cgroup v1, there is a single
|
||||
hierarchy instead of a different one for each controller.
|
||||
|
|
@ -102,8 +117,8 @@ In order to use it, cgroup v2 must be supported by the CRI runtime as well.
|
|||
|
||||
### Migrating to the `systemd` driver in kubeadm managed clusters
|
||||
|
||||
Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
|
||||
if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters.
|
||||
If you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters,
|
||||
follow [configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/).
|
||||
|
||||
## CRI version support {#cri-versions}
|
||||
|
||||
|
|
@ -120,95 +135,51 @@ using the (deprecated) v1alpha2 API instead.
|
|||
|
||||
### containerd
|
||||
|
||||
This section contains the necessary steps to use containerd as CRI runtime.
|
||||
This section outlines the necessary steps to use containerd as CRI runtime.
|
||||
|
||||
Use the following commands to install Containerd on your system:
|
||||
|
||||
Install and configure prerequisites:
|
||||
1. Install and configure prerequisites:
|
||||
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# Setup required sysctl params, these persist across reboots.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
# Apply sysctl params without reboot
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
Install containerd:
|
||||
|
||||
{{< tabs name="tab-cri-containerd-installation" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
1. Install the `containerd.io` package from the official Docker repositories.
|
||||
Instructions for setting up the Docker repository for your respective Linux distribution and
|
||||
installing the `containerd.io` package can be found at
|
||||
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
|
||||
|
||||
2. Configure containerd:
|
||||
(these instructions apply to Linux nodes only)
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /etc/containerd
|
||||
containerd config default | sudo tee /etc/containerd/config.toml
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# Setup required sysctl params, these persist across reboots.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
# Apply sysctl params without reboot
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
3. Restart containerd:
|
||||
1. Install containerd:
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Windows (PowerShell)" %}}
|
||||
|
||||
Start a Powershell session, set `$Version` to the desired version (ex: `$Version="1.4.3"`),
|
||||
and then run the following commands:
|
||||
|
||||
1. Download containerd:
|
||||
Visit
|
||||
[Getting started with containerd](https://containerd.io/docs/getting-started/#starting-containerd)
|
||||
and follow the instructions there, up to the point where you have a valid
|
||||
configuration file (on Linux: `/etc/containerd/config.toml`).
|
||||
|
||||
If you are running Windows, you might want to exclude containerd from Windows Defender Scans
|
||||
```powershell
|
||||
curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
|
||||
tar.exe xvf .\containerd-windows-amd64.tar.gz
|
||||
```
|
||||
|
||||
2. Extract and configure:
|
||||
|
||||
```powershell
|
||||
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
|
||||
cd $Env:ProgramFiles\containerd\
|
||||
.\containerd.exe config default | Out-File config.toml -Encoding ascii
|
||||
|
||||
# Review the configuration. Depending on setup you may want to adjust:
|
||||
# - the sandbox_image (Kubernetes pause image)
|
||||
# - cni bin_dir and conf_dir locations
|
||||
Get-Content config.toml
|
||||
|
||||
# (Optional - but highly recommended) Exclude containerd from Windows Defender Scans
|
||||
# If excluding containerd from Windows Defender scans, consider how else
|
||||
# you will make sure that the executable is genuine.
|
||||
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
|
||||
```
|
||||
|
||||
3. Start containerd:
|
||||
For containerd, the CRI socket is `/run/containerd/containerd.sock` by default.
|
||||
|
||||
```powershell
|
||||
.\containerd.exe --register-service
|
||||
Start-Service containerd
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
#### Using the `systemd` cgroup driver {#containerd-systemd}
|
||||
#### Configuring the `systemd` cgroup driver {#containerd-systemd}
|
||||
|
||||
To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set
|
||||
|
||||
|
|
@ -219,7 +190,7 @@ To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`,
|
|||
SystemdCgroup = true
|
||||
```
|
||||
|
||||
If you apply this change make sure to restart containerd again:
|
||||
If you apply this change, make sure to restart containerd:
|
||||
|
||||
```shell
|
||||
sudo systemctl restart containerd
|
||||
|
|
@ -232,176 +203,14 @@ When using kubeadm, manually configure the
|
|||
|
||||
This section contains the necessary steps to install CRI-O as a container runtime.
|
||||
|
||||
Use the following commands to install CRI-O on your system:
|
||||
|
||||
{{< note >}}
|
||||
The CRI-O major and minor versions must match the Kubernetes major and minor versions.
|
||||
For more information, see the [CRI-O compatibility matrix](https://github.com/cri-o/cri-o#compatibility-matrix-cri-o--kubernetes).
|
||||
{{< /note >}}
|
||||
|
||||
Install and configure prerequisites:
|
||||
|
||||
```shell
|
||||
# Create the .conf file to load the modules at bootup
|
||||
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
sudo modprobe overlay
|
||||
sudo modprobe br_netfilter
|
||||
|
||||
# Set up required sysctl params, these persist across reboots.
|
||||
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
EOF
|
||||
|
||||
sudo sysctl --system
|
||||
```
|
||||
|
||||
{{< tabs name="tab-cri-cri-o-installation" >}}
|
||||
{{% tab name="Debian" %}}
|
||||
|
||||
To install CRI-O on the following operating systems, set the environment variable `OS`
|
||||
to the appropriate value from the following table:
|
||||
|
||||
| Operating system | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Debian Unstable | `Debian_Unstable` |
|
||||
| Debian Testing | `Debian_Testing` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
|
||||
EOF
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Ubuntu" %}}
|
||||
|
||||
To install on the following operating systems, set the environment variable `OS`
|
||||
to the appropriate field in the following table:
|
||||
|
||||
| Operating system | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Ubuntu 20.04 | `xUbuntu_20.04` |
|
||||
| Ubuntu 19.10 | `xUbuntu_19.10` |
|
||||
| Ubuntu 19.04 | `xUbuntu_19.04` |
|
||||
| Ubuntu 18.04 | `xUbuntu_18.04` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
|
||||
EOF
|
||||
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
|
||||
EOF
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -
|
||||
|
||||
sudo apt-get update
|
||||
sudo apt-get install cri-o cri-o-runc
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="CentOS" %}}
|
||||
|
||||
To install on the following operating systems, set the environment variable `OS`
|
||||
to the appropriate field in the following table:
|
||||
|
||||
| Operating system | `$OS` |
|
||||
| ---------------- | ----------------- |
|
||||
| Centos 8 | `CentOS_8` |
|
||||
| Centos 8 Stream | `CentOS_8_Stream` |
|
||||
| Centos 7 | `CentOS_7` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.20, set `VERSION=1.20`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.20.0, set `VERSION=1.20:1.20.0`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
|
||||
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
|
||||
sudo yum install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="openSUSE Tumbleweed" %}}
|
||||
|
||||
```shell
|
||||
sudo zypper install cri-o
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Fedora" %}}
|
||||
|
||||
Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.20, `VERSION=1.20`.
|
||||
|
||||
You can find available versions with:
|
||||
```shell
|
||||
sudo dnf module list cri-o
|
||||
```
|
||||
CRI-O does not support pinning to specific releases on Fedora.
|
||||
|
||||
Then run
|
||||
```shell
|
||||
sudo dnf module enable cri-o:$VERSION
|
||||
sudo dnf install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
Start CRI-O:
|
||||
|
||||
```shell
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable crio --now
|
||||
```
|
||||
|
||||
Refer to the [CRI-O installation guide](https://github.com/cri-o/cri-o/blob/master/install.md)
|
||||
for more information.
|
||||
|
||||
To install CRI-O, follow [CRI-O Install Instructions](https://github.com/cri-o/cri-o/blob/main/install.md#readme).
|
||||
|
||||
#### cgroup driver
|
||||
|
||||
CRI-O uses the systemd cgroup driver per default. To switch to the `cgroupfs`
|
||||
cgroup driver, either edit `/etc/crio/crio.conf` or place a drop-in
|
||||
configuration in `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
|
||||
CRI-O uses the systemd cgroup driver per default, which is likely to work fine
|
||||
for you. To switch to the `cgroupfs` cgroup driver, either edit
|
||||
`/etc/crio/crio.conf` or place a drop-in configuration in
|
||||
`/etc/crio/crio.conf.d/02-cgroup-manager.conf`, for example:
|
||||
|
||||
```toml
|
||||
[crio.runtime]
|
||||
|
|
@ -409,28 +218,28 @@ conmon_cgroup = "pod"
|
|||
cgroup_manager = "cgroupfs"
|
||||
```
|
||||
|
||||
Please also note the changed `conmon_cgroup`, which has to be set to the value
|
||||
You should also note the changed `conmon_cgroup`, which has to be set to the value
|
||||
`pod` when using CRI-O with `cgroupfs`. It is generally necessary to keep the
|
||||
cgroup driver configuration of the kubelet (usually done via kubeadm) and CRI-O
|
||||
in sync.
|
||||
|
||||
For CRI-O, the CRI socket is `/var/run/crio/crio.sock` by default.
|
||||
|
||||
### Docker Engine {#docker}
|
||||
|
||||
Docker Engine is the container runtime that started it all. Formerly known just as Docker,
|
||||
this container runtime is available in various forms.
|
||||
[Install Docker Engine](https://docs.docker.com/engine/install/) explains your options
|
||||
for installing this runtime.
|
||||
{{< note >}}
|
||||
These instructions assume that you are using the
|
||||
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) adapter to integrate
|
||||
Docker Engine with Kubernetes.
|
||||
{{< /note >}}
|
||||
|
||||
Docker Engine is directly compatible with Kubernetes {{< skew currentVersion >}}, using the deprecated `dockershim` component. For more information
|
||||
and context, see the [Dockershim deprecation FAQ](/dockershim).
|
||||
1. On each of your nodes, install Docker for your Linux distribution as per
|
||||
[Install Docker Engine](https://docs.docker.com/engine/install/#server).
|
||||
|
||||
You can also find third-party adapters that let you use Docker Engine with Kubernetes
|
||||
through the supported {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}}
|
||||
(CRI).
|
||||
2. Install [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd), following
|
||||
the instructions in that source code repository.
|
||||
|
||||
The following CRI adaptors are designed to work with Docker Engine:
|
||||
|
||||
- [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) from Mirantis
|
||||
For `cri-dockerd`, the CRI socket is `/run/cri-dockerd.sock` by default.
|
||||
|
||||
### Mirantis Container Runtime {#mcr}
|
||||
|
||||
|
|
@ -439,3 +248,14 @@ available container runtime that was formerly known as Docker Enterprise Edition
|
|||
|
||||
You can use Mirantis Container Runtime with Kubernetes using the open source
|
||||
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) component, included with MCR.
|
||||
|
||||
To learn more about how to install Mirantis Container Runtime,
|
||||
visit [MCR Deployment Guide](https://docs.mirantis.com/mcr/20.10/install.html).
|
||||
|
||||
Check the systemd unit named `cri-docker.socket` to find out the path to the CRI
|
||||
socket.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
As well as a container runtime, your cluster will need a working
|
||||
[network plugin](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
|
||||
|
|
|
|||
|
|
@ -70,9 +70,10 @@ Any commands under `kubeadm alpha` are, by definition, supported on an alpha lev
|
|||
|
||||
## Instructions
|
||||
|
||||
### Installing kubeadm on your hosts
|
||||
### Preparing the hosts
|
||||
|
||||
See ["Installing kubeadm"](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
Install a {{< glossary_tooltip term_id="container-runtime" text="container runtime" >}} and kubeadm on all the hosts.
|
||||
For detailed instructions and other prerequisites, see [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
|
||||
|
||||
{{< note >}}
|
||||
If you have already installed kubeadm, run `apt-get update &&
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ card:
|
|||
This page shows how to install the `kubeadm` toolbox.
|
||||
For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
|
@ -69,10 +69,10 @@ For more details please see the [Network Plugin Requirements](/docs/concepts/ext
|
|||
## Check required ports
|
||||
These
|
||||
[required ports](/docs/reference/ports-and-protocols/)
|
||||
need to be open in order for Kubernetes components to communicate with each other. You can use telnet to check if a port is open. For example:
|
||||
need to be open in order for Kubernetes components to communicate with each other. You can use tools like netcat to check if a port is open. For example:
|
||||
|
||||
```shell
|
||||
telnet 127.0.0.1 6443
|
||||
nc 127.0.0.1 6443
|
||||
```
|
||||
|
||||
The pod network plugin you use (see below) may also require certain ports to be
|
||||
|
|
|
|||
|
|
@ -8,6 +8,8 @@ weight: 80
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
The lifecycle of the kubeadm CLI tool is decoupled from the
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
|
||||
on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is
|
||||
|
|
|
|||
|
|
@ -16,8 +16,7 @@ weight: 30
|
|||
|
||||
You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster.
|
||||
|
||||
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
{{< version-check >}}
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: "Migrating from dockershim"
|
||||
weight: 10
|
||||
content_type: task
|
||||
content_type: task
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -22,3 +23,25 @@ section to know your options. Make sure to
|
|||
[report issues](https://github.com/kubernetes/kubernetes/issues) you encountered
|
||||
with the migration. So the issue can be fixed in a timely manner and your cluster would be
|
||||
ready for dockershim removal.
|
||||
|
||||
Your cluster might have more than one kind of node, although this is not a common
|
||||
configuration.
|
||||
|
||||
These tasks will help you to migrate:
|
||||
|
||||
* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
|
||||
* [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
|
||||
* [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
to understand your options for a container runtime.
|
||||
* There is a
|
||||
[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)
|
||||
to track discussion about the deprecation and removal of dockershim.
|
||||
* If you found a defect or other technical concern relating to migrating away from dockershim,
|
||||
you can [report an issue](https://github.com/kubernetes/kubernetes/issues/new/choose)
|
||||
to the Kubernetes project.
|
||||
|
||||
|
|
|
|||
|
|
@ -88,3 +88,8 @@ You can still pull images or build them using `docker build` command. But images
|
|||
built or pulled by Docker would not be visible to container runtime and
|
||||
Kubernetes. They needed to be pushed to some registry to allow them to be used
|
||||
by Kubernetes.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps
|
||||
- Read the [dockershim deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article for more information.
|
||||
|
|
|
|||
|
|
@ -32,16 +32,22 @@ kubectl get nodes -o wide
|
|||
The output is similar to the following. The column `CONTAINER-RUNTIME` outputs
|
||||
the runtime and its version.
|
||||
|
||||
For Docker Engine, the output is similar to this:
|
||||
|
||||
```none
|
||||
# For dockershim
|
||||
NAME STATUS VERSION CONTAINER-RUNTIME
|
||||
node-1 Ready v1.16.15 docker://19.3.1
|
||||
node-2 Ready v1.16.15 docker://19.3.1
|
||||
node-3 Ready v1.16.15 docker://19.3.1
|
||||
```
|
||||
If your runtime shows as Docker Engine, you still might not be affected by the
|
||||
removal of dockershim in Kubernetes 1.24. [Check the runtime
|
||||
endpoint](#which-endpoint) to see if you use dockershim. If you don't use
|
||||
dockershim, you aren't affected.
|
||||
|
||||
For containerd, the output is similar to this:
|
||||
|
||||
```none
|
||||
# For containerd
|
||||
NAME STATUS VERSION CONTAINER-RUNTIME
|
||||
node-1 Ready v1.19.6 containerd://1.4.1
|
||||
node-2 Ready v1.19.6 containerd://1.4.1
|
||||
|
|
@ -49,4 +55,44 @@ node-3 Ready v1.19.6 containerd://1.4.1
|
|||
```
|
||||
|
||||
Find out more information about container runtimes
|
||||
on [Container Runtimes](/docs/setup/production-environment/container-runtimes/) page.
|
||||
on [Container Runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
page.
|
||||
|
||||
## Find out what container runtime endpoint you use {#which-endpoint}
|
||||
|
||||
The container runtime talks to the kubelet over a Unix socket using the [CRI
|
||||
protocol](/docs/concepts/architecture/cri/), which is based on the gRPC
|
||||
framework. The kubelet acts as a client, and the runtime acts as the server.
|
||||
In some cases, you might find it useful to know which socket your nodes use. For
|
||||
example, with the removal of dockershim in Kubernetes 1.24 and later, you might
|
||||
want to know whether you use Docker Engine with dockershim.
|
||||
|
||||
{{<note>}}
|
||||
If you currently use Docker Engine in your nodes with `cri-dockerd`, you aren't
|
||||
affected by the dockershim removal.
|
||||
{{</note>}}
|
||||
|
||||
You can check which socket you use by checking the kubelet configuration on your
|
||||
nodes.
|
||||
|
||||
1. Read the starting commands for the kubelet process:
|
||||
|
||||
```
|
||||
tr \\0 ' ' < /proc/"$(pgrep kubelet)"/cmdline
|
||||
```
|
||||
If you don't have `tr` or `pgrep`, check the command line for the kubelet
|
||||
process manually.
|
||||
|
||||
1. In the output, look for the `--container-runtime` flag and the
|
||||
`--container-runtime-endpoint` flag.
|
||||
|
||||
* If your nodes use Kubernetes v1.23 and earlier and these flags aren't
|
||||
present or if the `--container-runtime` flag is not `remote`,
|
||||
you use the dockershim socket with Docker Engine.
|
||||
* If the `--container-runtime-endpoint` flag is present, check the socket
|
||||
name to find out which runtime you use. For example,
|
||||
`unix:///run/containerd/containerd.sock` is the containerd endpoint.
|
||||
|
||||
If you use Docker Engine with the dockershim, [migrate to a different runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/),
|
||||
or, if you want to continue using Docker Engine in v1.24 and later, migrate to a
|
||||
CRI-compatible adapter like [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
|
||||
|
|
@ -233,7 +233,7 @@ in order to configure checks that rely on gRPC.
|
|||
|
||||
Here is an example manifest:
|
||||
|
||||
{{< codenew file="pods/probe/grpc-liveness.yaml">}}
|
||||
{{< codenew file="pods/probe/grpc-liveness.yaml" >}}
|
||||
|
||||
To use a gRPC probe, `port` must be configured. If the health endpoint is configured
|
||||
on a non-default service, you must also specify the `service`.
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ kubectl delete pod qos-demo --namespace=qos-example
|
|||
A Pod is given a QoS class of Burstable if:
|
||||
|
||||
* The Pod does not meet the criteria for QoS class Guaranteed.
|
||||
* At least one Container in the Pod has a memory or CPU request.
|
||||
* At least one Container in the Pod has a memory or CPU request or limit.
|
||||
|
||||
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
|
||||
and a memory request of 100 MiB.
|
||||
|
|
|
|||
|
|
@ -194,7 +194,7 @@ both Linux and Windows kernels). The time window used to calculate CPU is shown
|
|||
in Metrics API.
|
||||
|
||||
To learn more about how Kubernetes allocates and measures CPU resources, see
|
||||
[meaning of CPU](/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu).
|
||||
[meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu).
|
||||
|
||||
### Memory
|
||||
|
||||
|
|
@ -209,7 +209,7 @@ anonymous memory associated with the container in question. The working set metr
|
|||
includes some cached (file-backed) memory, because the host OS cannot always reclaim pages.
|
||||
|
||||
To learn more about how Kubernetes allocates and measures memory resources, see
|
||||
[meaning of memory](/docs/concepts/configuration/manage-resources-container/#meaning-of-memory).
|
||||
[meaning of memory](/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory).
|
||||
|
||||
## Metrics Server
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,9 @@ min-kubernetes-server-version: 1.7
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{% dockershim-removal %}}
|
||||
|
||||
|
||||
Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec.
|
||||
|
||||
Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart.
|
||||
|
|
|
|||
|
|
@ -9,8 +9,10 @@ data:
|
|||
# Apply this config only on the primary.
|
||||
[mysqld]
|
||||
log-bin
|
||||
datadir=/var/lib/mysql/mysql
|
||||
replica.cnf: |
|
||||
# Apply this config only on replicas.
|
||||
[mysqld]
|
||||
super-read-only
|
||||
datadir=/var/lib/mysql/mysql
|
||||
|
||||
|
|
|
|||
|
|
@ -647,6 +647,7 @@ func TestExampleObjectSchemas(t *testing.T) {
|
|||
"service/networking": {
|
||||
"curlpod": {&apps.Deployment{}},
|
||||
"custom-dns": {&api.Pod{}},
|
||||
"default-ingressclass": {&networking.IngressClass{}},
|
||||
"dual-stack-default-svc": {&api.Service{}},
|
||||
"dual-stack-ipfamilies-ipv6": {&api.Service{}},
|
||||
"dual-stack-ipv6-svc": {&api.Service{}},
|
||||
|
|
@ -662,6 +663,7 @@ func TestExampleObjectSchemas(t *testing.T) {
|
|||
"name-virtual-host-ingress": {&networking.Ingress{}},
|
||||
"name-virtual-host-ingress-no-third-host": {&networking.Ingress{}},
|
||||
"namespaced-params": {&networking.IngressClass{}},
|
||||
"networkpolicy": {&networking.NetworkPolicy{}},
|
||||
"network-policy-allow-all-egress": {&networking.NetworkPolicy{}},
|
||||
"network-policy-allow-all-ingress": {&networking.NetworkPolicy{}},
|
||||
"network-policy-default-deny-egress": {&networking.NetworkPolicy{}},
|
||||
|
|
|
|||
|
|
@ -0,0 +1,35 @@
|
|||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: test-network-policy
|
||||
namespace: default
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
role: db
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
ingress:
|
||||
- from:
|
||||
- ipBlock:
|
||||
cidr: 172.17.0.0/16
|
||||
except:
|
||||
- 172.17.1.0/24
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
project: myproject
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
role: frontend
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 6379
|
||||
egress:
|
||||
- to:
|
||||
- ipBlock:
|
||||
cidr: 10.0.0.0/24
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 5978
|
||||
|
||||
|
|
@ -564,8 +564,8 @@ El {{< glossary_tooltip text="planificador" term_id="kube-scheduler" >}} se enca
|
|||
la cantidad disponible sea asignada simultáneamente a los Pods.
|
||||
|
||||
El servidor de API restringe las cantidades de recursos extendidos a números enteros.
|
||||
Ejemplos de cantidades _validas_ son `3`,` 3000m` y `3Ki`. Ejemplos de
|
||||
_cantidades no válidas_ son `0.5` y` 1500m`.
|
||||
Ejemplos de cantidades _validas_ son `3`, `3000m` y `3Ki`. Ejemplos de
|
||||
_cantidades no válidas_ son `0.5` y `1500m`.
|
||||
|
||||
{{< note >}}
|
||||
Los recursos extendidos reemplazan los Recursos Integrales Opacos.
|
||||
|
|
@ -630,7 +630,7 @@ está pendiente con un mensaje de este tipo, hay varias cosas para probar:
|
|||
- Añadir más nodos al clúster.
|
||||
- Terminar Pods innecesarios para hacer hueco a los Pods en estado pendiente.
|
||||
- Compruebe que el Pod no sea más grande que todos los nodos. Por ejemplo, si todos los
|
||||
los nodos tienen una capacidad de `cpu: 1`, entonces un Pod con una solicitud de` cpu: 1.1`
|
||||
los nodos tienen una capacidad de `cpu: 1`, entonces un Pod con una solicitud de `cpu: 1.1`
|
||||
nunca se programará.
|
||||
|
||||
Puedes comprobar las capacidades del nodo y cantidad utilizada con el comando
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ el contenedor no puede alcanzar el estado de `running` (en ejecución).
|
|||
El comportamiento es similar para un hook `PreStop`.
|
||||
Si el hook se cuelga durante la ejecución,
|
||||
la fase del Pod permanece en un estado de `terminating` (finalizando) y se cancela después del `terminationGracePeriodSeconds` (finalización después del periodo de gracia) del pod en cuestión.
|
||||
Si un hook `PostStart` o` PreStop` falla, se mata el contenedor.
|
||||
Si un hook `PostStart` o `PreStop` falla, se mata el contenedor.
|
||||
|
||||
Los usuarios deben hacer que sus controladores de hooks sean lo más livianos posible.
|
||||
Hay casos, sin embargo, que los comandos de larga ejecución tienen sentido,
|
||||
|
|
@ -74,7 +74,7 @@ como cuando se guarda el estado antes de detener un contenedor.
|
|||
|
||||
La entrega de un hook está destinada a ser enviada *al menos una vez*,
|
||||
lo que significa que un hook puede ser llamado varias veces para cualquier evento dado,
|
||||
tanto para `PostStart` como para ` PreStop`.
|
||||
tanto para `PostStart` como para `PreStop`.
|
||||
Depende de la implementación del hook manejar esto correctamente.
|
||||
|
||||
En general, solo se realizan entregas individuales.
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ Un ejemplo del ciclo de terminación de un Pod:
|
|||
1. El Kubelet terminará de eliminar el Pod en el servidor API configurando el período de gracia 0 (eliminación inmediata). El Pod desaparece de la API y ya no es visible desde el cliente.
|
||||
|
||||
Por defecto, todas las eliminaciones se realizan correctamente en 30 segundos. El comando `kubectl delete` admite la opción` --grace-period = <seconds> `que permite al usuario anular el valor predeterminado y especificar su propio valor. El valor `0` [forzar eliminación](/es/docs/concepts/workloads/pods/pod/#forzar-destrucción-de-pods) del Pod.
|
||||
Debe especificar un indicador adicional `--force` junto con` --grace-period = 0` para realizar eliminaciones forzadas.
|
||||
Debe especificar un indicador adicional `--force` junto con `--grace-period = 0` para realizar eliminaciones forzadas.
|
||||
|
||||
### Forzar destrucción de Pods
|
||||
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ Dans la plupart des cas, le contrôleur de noeud limite le taux d’expulsion à
|
|||
|
||||
Le comportement d'éviction de noeud change lorsqu'un noeud d'une zone de disponibilité donnée devient défaillant.
|
||||
Le contrôleur de nœud vérifie quel pourcentage de nœuds de la zone est défaillant (la condition NodeReady est ConditionUnknown ou ConditionFalse) en même temps.
|
||||
Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à ` --large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde.
|
||||
Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à `--large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde.
|
||||
|
||||
Ces stratégies sont implémentées par zone de disponibilité car une zone de disponibilité peut être partitionnée à partir du master, tandis que les autres restent connectées.
|
||||
Si votre cluster ne s'étend pas sur plusieurs zones de disponibilité de fournisseur de cloud, il n'existe qu'une seule zone de disponibilité (la totalité du cluster).
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ spec:
|
|||
number: 80
|
||||
```
|
||||
|
||||
Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a besoin des champs `apiVersion`,` kind` et `metadata`.
|
||||
Comme pour toutes les autres ressources Kubernetes, un Ingress (une entrée) a besoin des champs `apiVersion`, `kind` et `metadata`.
|
||||
Pour des informations générales sur l'utilisation des fichiers de configuration, voir [déployer des applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configurer des conteneurs](/docs/tasks/configure-pod-container/configure-pod-configmap/), [gestion des ressources](/docs/concepts/cluster-administration/manage-deployment/).
|
||||
Ingress utilise fréquemment des annotations pour configurer certaines options en fonction du contrôleur Ingress, dont un exemple
|
||||
est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
|
||||
|
|
@ -223,7 +223,7 @@ Events:
|
|||
Normal ADD 22s loadbalancer-controller default/test
|
||||
```
|
||||
|
||||
Le contrôleur d’Ingress fournit une implémentation spécifique aux load-balancers qui satisfait l'Ingress, tant que les services (`s1`,` s2`) existent.
|
||||
Le contrôleur d’Ingress fournit une implémentation spécifique aux load-balancers qui satisfait l'Ingress, tant que les services (`s1`, `s2`) existent.
|
||||
Lorsque cela est fait, vous pouvez voir l’adresse du load-balancer sur le champ d'adresse.
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -272,7 +272,7 @@ spec:
|
|||
number: 80
|
||||
```
|
||||
|
||||
Si vous créez une ressource Ingress sans aucun hôte défini dans les règles, tout trafic Web à destination de l'adresse IP de votre contrôleur d'Ingress peut être mis en correspondance sans qu'un hôte virtuel basé sur le nom ne soit requis. Par exemple, la ressource Ingress suivante acheminera le trafic demandé pour `first.bar.com` au `service1` `second.foo.com` au `service2`, et à tout trafic à l'adresse IP sans nom d'hôte défini dans la demande (c'est-à-dire sans en-tête de requête présenté) au `service3`.
|
||||
Si vous créez une ressource Ingress sans aucun hôte défini dans les règles, tout trafic Web à destination de l'adresse IP de votre contrôleur d'Ingress peut être mis en correspondance sans qu'un hôte virtuel basé sur le nom ne soit requis. Par exemple, la ressource Ingress suivante acheminera le trafic demandé pour `first.bar.com` au `service1`, `second.foo.com` au `service2`, et à tout trafic à l'adresse IP sans nom d'hôte défini dans la demande (c'est-à-dire sans en-tête de requête présenté) au `service3`.
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ Cela signifie que vous évitez d'envoyer du trafic via kube-proxy vers un pod co
|
|||
|
||||
{{< feature-state for_k8s_version="v1.11" state="stable" >}}
|
||||
|
||||
En mode `ipvs`, kube-proxy surveille les Services et Endpoints Kubernetes. kube-proxy appelle l'interface` netlink` pour créer les règles IPVS en conséquence et synchronise périodiquement les règles IPVS avec les Services et Endpoints Kubernetes.
|
||||
En mode `ipvs`, kube-proxy surveille les Services et Endpoints Kubernetes. kube-proxy appelle l'interface `netlink` pour créer les règles IPVS en conséquence et synchronise périodiquement les règles IPVS avec les Services et Endpoints Kubernetes.
|
||||
Cette boucle de contrôle garantit que l'état IPVS correspond à l'état souhaité.
|
||||
Lors de l'accès à un service, IPVS dirige le trafic vers l'un des pods backend.
|
||||
|
||||
|
|
@ -364,11 +364,11 @@ Les valeurs de `Type` et leurs comportements sont:
|
|||
Le choix de cette valeur rend le service uniquement accessible à partir du cluster.
|
||||
Il s'agit du `ServiceType` par défaut.
|
||||
* [`NodePort`](#type-nodeport): Expose le service sur l'IP de chaque nœud sur un port statique (le `NodePort`).
|
||||
Un service `ClusterIP`, vers lequel le service` NodePort` est automatiquement créé.
|
||||
Un service `ClusterIP`, vers lequel le service `NodePort` est automatiquement créé.
|
||||
Vous pourrez contacter le service `NodePort`, depuis l'extérieur du cluster, en demandant `<NodeIP>: <NodePort>`.
|
||||
* [`LoadBalancer`](#loadbalancer): Expose le service en externe à l'aide de l'équilibreur de charge d'un fournisseur de cloud.
|
||||
Les services `NodePort` et `ClusterIP`, vers lesquels les itinéraires de l'équilibreur de charge externe, sont automatiquement créés.
|
||||
* [`ExternalName`](#externalname): Mappe le service au contenu du champ `externalName` (par exemple` foo.bar.example.com`), en renvoyant un enregistrement `CNAME` avec sa valeur.
|
||||
* [`ExternalName`](#externalname): Mappe le service au contenu du champ `externalName` (par exemple `foo.bar.example.com`), en renvoyant un enregistrement `CNAME` avec sa valeur.
|
||||
Aucun proxy d'aucune sorte n'est mis en place.
|
||||
{{< note >}}
|
||||
Vous avez besoin de CoreDNS version 1.7 ou supérieure pour utiliser le type `ExternalName`.
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ On branch master
|
|||
|
||||
### Valider votre fichier édité
|
||||
|
||||
Exécutez `git add` et ` git commit` pour valider les modifications que vous avez apportées jusqu'à présent.
|
||||
Exécutez `git add` et `git commit` pour valider les modifications que vous avez apportées jusqu'à présent.
|
||||
Dans l'étape suivante, vous ferez un deuxième commit.
|
||||
Il est important de séparer vos modifications en deux commits.
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ Voir le contenu de `api/openapi-spec/swagger.json` pour vous assurer que la faut
|
|||
Par exemple, vous pouvez exécuter `git diff -a api/openapi-spec/swagger.json`.
|
||||
Ceci est important, car `swagger.json` sera l’entrée de la seconde étape du processus de génération de doc.
|
||||
|
||||
Exécutez `git add` et ` git commit` pour valider vos modifications.
|
||||
Exécutez `git add` et `git commit` pour valider vos modifications.
|
||||
Vous avez maintenant deux validations: une avec le fichier `types.go` édité et une avec les spécifications OpenAPI générées et les fichiers associés.
|
||||
Gardez ces deux commits séparés.
|
||||
C'est-à-dire, ne faites pas un squash de vos commits.
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ mais aussi `dev.example.com` ou même `example.com`. kops fonctionne avec n'impo
|
|||
Supposons que vous utilisiez `dev.example.com` comme zone hébergée. Vous créeriez cette zone hébergée en utilisant la [méthode normal](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), ou avec une ligne de commande telle que `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
|
||||
|
||||
Vous devrez ensuite configurer vos enregistrements NS dans le domaine parent afin que vous puissiez résoudre dans ce domaine.
|
||||
Vous créeriez donc des enregistrements NS dans le domaine `example.com` pour` dev`.
|
||||
Vous créeriez donc des enregistrements NS dans le domaine `example.com` pour `dev`.
|
||||
S'il s'agit d'un nom de domaine racine, vous devrez configurer les enregistrements NS chez votre hébergeur de nom de domaine (là où vous avez acheté votre nom de domaine `example.com`).
|
||||
|
||||
Cette étape est délicate, soyez vigilants (c’est la première cause de problèmes !). Vous pouvez vérifier que
|
||||
|
|
@ -195,7 +195,7 @@ Il applique les modifications que vous avez apportées à la configuration sur v
|
|||
|
||||
Par exemple, après un `kops edit ig nodes`, puis un `kops update cluster --yes` pour appliquer votre configuration, parfois, vous devrez également exécuter un `kops rolling-update cluster` pour déployer la configuration immédiatement.
|
||||
|
||||
Sans l'argument `--yes`,` kops update cluster` vous montrera un aperçu de ce qu’il va faire. C'est pratique
|
||||
Sans l'argument `--yes`, `kops update cluster` vous montrera un aperçu de ce qu’il va faire. C'est pratique
|
||||
pour les clusters de production !
|
||||
|
||||
### Explorer d'autres composants additionnels (add-ons)
|
||||
|
|
|
|||
|
|
@ -243,7 +243,7 @@ Alternativement, si vous êtes `root`, vous pouvez exécuter:
|
|||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
Faites un enregistrement du retour de la commande `kubeadm join` que` kubeadm init` génère. Vous avez
|
||||
Faites un enregistrement du retour de la commande `kubeadm join` que `kubeadm init` génère. Vous avez
|
||||
besoin de cette commande pour [joindre des noeuds à votre cluster](#join-nodes).
|
||||
|
||||
Le jeton est utilisé pour l'authentification mutuelle entre le master et les nœuds qui veulent le rejoindre.
|
||||
|
|
@ -284,7 +284,7 @@ car cela pourrait entraîner des problèmes.
|
|||
Si vous constatez une collision entre le réseau de pod de votre plug-in de réseau et certains
|
||||
de vos réseaux hôtes,
|
||||
vous devriez penser à un remplacement de CIDR approprié et l'utiliser lors de `kubeadm init` avec
|
||||
` --pod-network-cidr` et en remplacement du YAML de votre plugin réseau.
|
||||
`--pod-network-cidr` et en remplacement du YAML de votre plugin réseau.
|
||||
Vous pouvez installer un add-on réseau de pod avec la commande suivante:
|
||||
|
||||
```bash
|
||||
|
|
@ -304,8 +304,8 @@ Pour plus d'informations sur l'utilisation de Calico, voir
|
|||
[Installation de Calico pour les netpols ( network policies ) et le réseau](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), ainsi que d'autres resources liées à ce sujet.
|
||||
|
||||
Pour que Calico fonctionne correctement, vous devez passer `--pod-network-cidr = 192.168.0.0 / 16`
|
||||
à` kubeadm init` ou mettre à jour le fichier `calico.yml` pour qu'il corresponde à votre réseau de Pod.
|
||||
Notez que Calico fonctionne uniquement sur `amd64`,` arm64`, `ppc64le` et` s390x`.
|
||||
à `kubeadm init` ou mettre à jour le fichier `calico.yml` pour qu'il corresponde à votre réseau de Pod.
|
||||
Notez que Calico fonctionne uniquement sur `amd64`, `arm64`, `ppc64le` et `s390x`.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
|
||||
|
|
@ -317,7 +317,7 @@ Canal utilise Calico pour les netpols et Flannel pour la mise en réseau. Report
|
|||
documentation Calico pour obtenir le [guide de démarrage officiel](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/flannel).
|
||||
|
||||
Pour que Canal fonctionne correctement, `--pod-network-cidr = 10.244.0.0 / 16` doit être passé à
|
||||
` kubeadm init`. Notez que Canal ne fonctionne que sur `amd64`.
|
||||
`kubeadm init`. Notez que Canal ne fonctionne que sur `amd64`.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
|
||||
|
|
@ -353,14 +353,14 @@ cilium-drxkl 1/1 Running 0 18m
|
|||
{{% /tab %}}
|
||||
{{% tab name="Flannel" %}}
|
||||
|
||||
Pour que `flannel` fonctionne correctement, vous devez passer` --pod-network-cidr = 10.244.0.0 / 16` à `kubeadm init`.
|
||||
Pour que `flannel` fonctionne correctement, vous devez passer `--pod-network-cidr = 10.244.0.0 / 16` à `kubeadm init`.
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant
|
||||
` sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
`sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
passez le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI
|
||||
fonctionnent, pour plus d'informations
|
||||
allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Notez que `flannel` fonctionne sur` amd64`, `arm`,` arm64`, `ppc64le` et` s390x` sous Linux.
|
||||
Notez que `flannel` fonctionne sur `amd64`, `arm`, `arm64`, `ppc64le` et `s390x` sous Linux.
|
||||
Windows (`amd64`) est annoncé comme supporté dans la v0.11.0 mais son utilisation n’est pas
|
||||
documentée.
|
||||
|
||||
|
|
@ -378,7 +378,7 @@ Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'inf
|
|||
s'il vous plaît allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Kube-router s'appuie sur kube-controller-manager pour allouer le pod CIDR aux nœuds. Par conséquent,
|
||||
utilisez `kubeadm init` avec l'option` --pod-network-cidr`.
|
||||
utilisez `kubeadm init` avec l'option `--pod-network-cidr`.
|
||||
|
||||
Kube-router fournit un réseau de pod, une stratégie réseau et un proxy de service basé sur un
|
||||
IP Virtual Server (IPVS) / Linux Virtual Server (LVS) hautement performant.
|
||||
|
|
@ -388,7 +388,7 @@ veuillez consulter le [guide d'installation](https://github.com/cloudnativelabs/
|
|||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Romana" %}}
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à` 1` en exécutant
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à `1` en exécutant
|
||||
`sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent,
|
||||
pour plus d'informations
|
||||
|
|
@ -404,13 +404,13 @@ kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containe
|
|||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Weave Net" %}}
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant` sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
Paramétrez `/proc/sys/net/bridge/bridge-nf-call-iptables` à «1» en exécutant `sysctl net.bridge.bridge-nf-call-iptables = 1`
|
||||
Cette commande indiquera de passer le trafic IPv4 bridged à iptables. Ceci est nécessaire pour que certains plugins CNI fonctionnent, pour plus d'informations
|
||||
s'il vous plaît allez voir [ici](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Le guide de configuration officiel de Weave Net est [ici](https://www.weave.works/docs/net/latest/kube-addon/).
|
||||
|
||||
Weave Net fonctionne sur `amd64`,` arm`, `arm64` et` ppc64le` sans aucune action supplémentaire requise.
|
||||
Weave Net fonctionne sur `amd64`, `arm`, `arm64` et `ppc64le` sans aucune action supplémentaire requise.
|
||||
Weave Net paramètre le mode hairpin par défaut. Cela permet aux pods de se connecter via leur adresse IP de service
|
||||
s'ils ne connaissent pas leur Pod IP.
|
||||
|
||||
|
|
@ -597,7 +597,7 @@ Si vous souhaitez réinitialiser les tables IPVS, vous devez exécuter la comman
|
|||
ipvsadm -C
|
||||
```
|
||||
|
||||
Si vous souhaitez recommencer Il suffit de lancer `kubeadm init` ou` kubeadm join` avec les
|
||||
Si vous souhaitez recommencer Il suffit de lancer `kubeadm init` ou `kubeadm join` avec les
|
||||
arguments appropriés.
|
||||
Plus d'options et d'informations sur la
|
||||
[`commande de réinitialisation de kubeadm`](/docs/reference/setup-tools/kubeadm/kubeadm-reset/).
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Un cluster HA empilé est une [topologie réseau](https://fr.wikipedia.org/wiki/
|
|||
où le cluster de stockage de données distribuées est fourni par etcd et est superposé au
|
||||
cluster formé par les noeuds gérés par kubeadm qui exécute les composants du control plane.
|
||||
|
||||
Chaque nœud du control plane exécute une instance de `kube-apiserver`,` kube-scheduler` et
|
||||
Chaque nœud du control plane exécute une instance de `kube-apiserver`, `kube-scheduler` et
|
||||
`kube-controller-manager`.
|
||||
Le `kube-apiserver` est exposé aux nœuds à l'aide d'un loadbalancer.
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ Par conséquent, vous devez exécuter au moins trois nœuds de control plane emp
|
|||
en haute disponibilité.
|
||||
|
||||
C'est la topologie par défaut dans kubeadm. Un membre etcd local est créé automatiquement
|
||||
sur les noeuds du control plane en utilisant `kubeadm init` et` kubeadm join --experimental-control-plane`.
|
||||
sur les noeuds du control plane en utilisant `kubeadm init` et `kubeadm join --experimental-control-plane`.
|
||||
|
||||
Schéma de la [Topologie etcd empilée](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg)
|
||||
|
||||
|
|
@ -59,7 +59,7 @@ distribuées fourni par etcd est externe au cluster formé par les nœuds qui ex
|
|||
du control plane.
|
||||
|
||||
Comme la topologie etcd empilée, chaque nœud du control plane d'une topologie etcd externe exécute
|
||||
une instance de `kube-apiserver`,` kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver`
|
||||
une instance de `kube-apiserver`, `kube-scheduler` et `kube-controller-manager`. Et le `kube-apiserver`
|
||||
est exposé aux nœuds workers à l’aide d’un load-balancer. Cependant, les membres etcd s'exécutent sur
|
||||
des hôtes distincts et chaque hôte etcd communique avec le `kube-apiserver` de chaque nœud du control plane.
|
||||
|
||||
|
|
|
|||
|
|
@ -250,7 +250,7 @@ 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
|
||||
```
|
||||
|
||||
Installez `kubeadm`,` kubelet`, `kubectl` et ajoutez un service systemd` kubelet`:
|
||||
Installez `kubeadm`, `kubelet`, `kubectl` et ajoutez un service systemd `kubelet`:
|
||||
|
||||
RELEASE_VERSION="v0.6.0"
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ utilisant kubeadm, plutôt que de gérer manuellement la configuration des kubel
|
|||
### Propagation de la configuration niveau cluster à chaque kubelet {#propagating-cluster-level-configuration-to-each-kubelet}
|
||||
|
||||
Vous pouvez fournir à la kubelet les valeurs par défaut à utiliser par les commandes `kubeadm init` et
|
||||
` kubeadm join`. Des exemples intéressants incluent l’utilisation d’un runtime CRI différent ou la
|
||||
`kubeadm join`. Des exemples intéressants incluent l’utilisation d’un runtime CRI différent ou la
|
||||
définition du sous-réseau par défaut utilisé par les services.
|
||||
|
||||
Si vous souhaitez que vos services utilisent le sous-réseau `10.96.0.0 / 12` par défaut pour les
|
||||
|
|
|
|||
|
|
@ -102,26 +102,26 @@ L'inspection des journaux de Docker peut également être utile:
|
|||
journalctl -ul docker
|
||||
```
|
||||
|
||||
## Pods dans l'état `RunContainerError`,` CrashLoopBackOff` ou `Error`
|
||||
## Pods dans l'état `RunContainerError`, `CrashLoopBackOff` ou `Error`
|
||||
|
||||
Juste après `kubeadm init`, il ne devrait pas y avoir de pods dans ces états.
|
||||
|
||||
- S'il existe des pods dans l'un de ces états _juste après_ `kubeadm init`, veuillez ouvrir un
|
||||
issue dans le dépôt de Kubeadm. `coredns` (ou` kube-dns`) devrait être dans l'état `Pending`
|
||||
jusqu'à ce que vous ayez déployé la solution réseau.
|
||||
- Si vous voyez des pods dans les états `RunContainerError`,` CrashLoopBackOff` ou `Error`
|
||||
- Si vous voyez des pods dans les états `RunContainerError`, `CrashLoopBackOff` ou `Error`
|
||||
après le déploiement de la solution réseau et que rien ne se passe pour `coredns` (ou` kube-dns`),
|
||||
il est très probable que la solution Pod Network que vous avez installée est en quelque sorte
|
||||
endommagée. Vous devrez peut-être lui accorder plus de privilèges RBAC ou utiliser une version
|
||||
plus récente. S'il vous plaît créez une issue dans le dépôt du fournisseur de réseau de Pod.
|
||||
- Si vous installez une version de Docker antérieure à 1.12.1, supprimez l'option `MountFlags = slave`
|
||||
lors du démarrage de `dockerd` avec` systemd` et redémarrez `docker`. Vous pouvez voir les options
|
||||
lors du démarrage de `dockerd` avec `systemd` et redémarrez `docker`. Vous pouvez voir les options
|
||||
de montage dans `/usr/lib/systemd/system/docker.service`.
|
||||
Les options de montage peuvent interférer avec les volumes montés par Kubernetes et mettre les
|
||||
pods dans l'état`CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers
|
||||
pods dans l'état `CrashLoopBackOff`. L'erreur se produit lorsque Kubernetes ne trouve pas les fichiers
|
||||
`var/run/secrets/kubernetes.io/serviceaccount`.
|
||||
|
||||
## `coredns` (ou` kube-dns`) est bloqué dans l'état `Pending`
|
||||
## `coredns` (ou `kube-dns`) est bloqué dans l'état `Pending`
|
||||
|
||||
Ceci est **prévu** et fait partie du design. kubeadm est agnostique vis-à-vis du fournisseur
|
||||
de réseau, ainsi l'administrateur devrait [installer la solution réseau pod](/docs/concepts/cluster-administration/addons/)
|
||||
|
|
@ -132,7 +132,7 @@ D'où l' état `Pending` avant la mise en place du réseau.
|
|||
|
||||
Les fonctionnalités `HostPort` et `HostIP` sont disponibles en fonction de votre fournisseur
|
||||
de réseau de pod. Veuillez contacter l’auteur de la solution de réseau de Pod pour savoir si
|
||||
Les fonctionnalités `HostPort` et` HostIP` sont disponibles.
|
||||
Les fonctionnalités `HostPort` et `HostIP` sont disponibles.
|
||||
|
||||
Les fournisseurs de CNI Calico, Canal, et Flannel supportent HostPort.
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ Si votre fournisseur de réseau ne prend pas en charge le plug-in portmap CNI, v
|
|||
|
||||
- Si vous utilisez VirtualBox (directement ou via Vagrant), vous devrez vous assurez que
|
||||
`hostname -i` renvoie une adresse IP routable. Par défaut la première interface est connectée
|
||||
à un réseau d’`hôte uniquement` non routable. En contournement vous pouvez modifier`/etc/hosts`,
|
||||
à un réseau d’ `hôte uniquement` non routable. En contournement vous pouvez modifier `/etc/hosts`,
|
||||
jetez un œil à ce [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11) par exemple.
|
||||
|
||||
## Erreurs de certificats TLS
|
||||
|
|
@ -198,7 +198,7 @@ pour que la deuxième interface soit choisie.
|
|||
|
||||
## IP non publique utilisée pour les conteneurs
|
||||
|
||||
Dans certaines situations, les commandes `kubectl logs` et` kubectl run` peuvent
|
||||
Dans certaines situations, les commandes `kubectl logs` et `kubectl run` peuvent
|
||||
renvoyer les erreurs suivantes dans un cluster par ailleurs fonctionnel:
|
||||
|
||||
```sh
|
||||
|
|
@ -211,9 +211,9 @@ avec d’autres adresses IP même sous-réseau, éventuellement à cause d'une p
|
|||
par le fournisseur de la machine.
|
||||
- Digital Ocean attribue une adresse IP publique à `eth0` ainsi qu’une adresse privée à
|
||||
utiliser en interne comme IP d'ancrage pour leur fonction IP flottante, mais `kubelet` choisira cette
|
||||
dernière comme` InternalIP` du noeud au lieu du public.
|
||||
dernière comme `InternalIP` du noeud au lieu du public.
|
||||
|
||||
Utilisez `ip addr show` pour verifier ce scénario au lieu de` ifconfig` car `ifconfig` n'affichera pas
|
||||
Utilisez `ip addr show` pour verifier ce scénario au lieu de `ifconfig` car `ifconfig` n'affichera pas
|
||||
l'alias de l'adresse IP incriminée. Sinon, une API spécifique à Digital Ocean
|
||||
permet de rechercher l'adresse IP d'ancrage à partir du droplet:
|
||||
|
||||
|
|
@ -253,7 +253,7 @@ Pod de CoreDNS déployé dans Kubernetes détecte une boucle. [Un certain nombre
|
|||
sont disponibles pour éviter que Kubernetes ne tente de redémarrer le pod CoreDNS chaque fois que CoreDNS détecte une boucle et s'arrête.
|
||||
|
||||
{{< warning >}}
|
||||
Désactiver SELinux ou paramètrer `allowPrivilegeEscalation` sur` true` peut compromettre
|
||||
Désactiver SELinux ou paramètrer `allowPrivilegeEscalation` sur `true` peut compromettre
|
||||
la sécurité de votre cluster.
|
||||
{{< /warning >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`.
|
|||
1. Hasilkan sertifikat dan kunci _server_.
|
||||
Argumen `--subject-alt-name` digunakan untuk mengatur alamat IP dan nama DNS yang dapat diakses
|
||||
oleh _server_ API. `MASTER_CLUSTER_IP` biasanya merupakan IP pertama dari CIDR _service cluster_
|
||||
yang diset dengan argumen` --service-cluster-ip-range` untuk _server_ API dan
|
||||
yang diset dengan argumen `--service-cluster-ip-range` untuk _server_ API dan
|
||||
komponen manajer pengontrol. Argumen `--days` digunakan untuk mengatur jumlah hari
|
||||
masa berlaku sertifikat.
|
||||
Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama
|
||||
|
|
|
|||
|
|
@ -263,7 +263,7 @@ perlu memastikan bahwa tidak ada dua FlowSchema yang memiliki `matchingPrecedenc
|
|||
|
||||
Sebuah FlowSchema dianggap cocok dengan sebuah permintaan yang diberikan jika setidaknya salah satu dari `rules` nya
|
||||
ada yang cocok. Sebuah aturan (_rule_) cocok jika setidaknya satu dari `subject` *dan*
|
||||
ada salah satu dari `resourceRules` atau` nonResourceRules` (tergantung dari apakah permintaan
|
||||
ada salah satu dari `resourceRules` atau `nonResourceRules` (tergantung dari apakah permintaan
|
||||
yang masuk adalah untuk URL sumber daya atau non-sumber daya) yang cocok dengan permintaan tersebut.
|
||||
|
||||
Untuk bagian `name` dalam subjek, dan bagian `verbs`, `apiGroups`, `resources`,
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
|||
|
||||
Jembatan ini dibuat oleh Kubelet (dikontrol oleh _flag_ `--network-plugin=kubenet`) sesuai dengan `.spec.podCIDR` yang dimiliki oleh Node.
|
||||
|
||||
Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan` cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE.
|
||||
Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan `cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE.
|
||||
|
||||
GCE sendiri tidak tahu apa-apa tentang IP ini, jadi tidak akan NAT untuk lalu lintas internet keluar. Untuk mencapai itu aturan iptables digunakan untuk menyamar (alias SNAT - untuk membuatnya seolah-olah paket berasal dari lalu lintas `Node` itu sendiri) yang terikat untuk IP di luar jaringan proyek GCE (10.0.0.0/8).
|
||||
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ Opsi `show-hidden-metrics-for-version` menerima input versi yang kamu inginkan u
|
|||
|
||||
Opsi tersebut hanya dapat menerima input versi minor sebelumnya sebagai nilai. Semua metrik yang disembunyikan di versi sebelumnya akan dikeluarkan jika admin mengatur versi sebelumnya ke `show-hidden-metrics-for-version`. Versi yang terlalu lama tidak diperbolehkan karena melanggar kebijakan untuk metrik usang.
|
||||
|
||||
Ambil metrik `A` sebagai contoh, di sini diasumsikan bahwa` A` sudah menjadi usang di versi 1.n. Berdasarkan kebijakan metrik usang, kita dapat mencapai kesimpulan berikut:
|
||||
Ambil metrik `A` sebagai contoh, di sini diasumsikan bahwa `A` sudah menjadi usang di versi 1.n. Berdasarkan kebijakan metrik usang, kita dapat mencapai kesimpulan berikut:
|
||||
|
||||
* Pada rilis `1.n`, metrik menjadi usang, dan dapat dikeluarkan secara bawaan.
|
||||
* Pada rilis `1.n+1`, metrik disembunyikan secara bawaan dan dapat dikeluarkan dengan baris perintah `show-hidden-metrics-for-version=1.n`.
|
||||
|
|
@ -155,7 +155,7 @@ kube-scheduler mengidentifikasi [permintaan dan limit](/docs/concepts/configurat
|
|||
- nama dari sumber daya (misalnya, `cpu`)
|
||||
- satuan dari sumber daya jika diketahui (misalnya, `cores`)
|
||||
|
||||
Setelah pod selesai (memiliki `restartPolicy` `Never` atau `OnFailure` dan berada dalam fase pod `Succeeded` atau `Failed`, atau telah dihapus dan semua kontainer dalam keadaan Terminated) deret metrik tidak lagi dilaporkan karena penjadwal sekarang sudah dibebaskan untuk menjadwalkan pod lain untuk dijalankan. Metrik yang dibahas pada bagian ini dikenal sebagai `kube_pod_resource_request` dan` kube_pod_resource_limit`.
|
||||
Setelah pod selesai (memiliki `restartPolicy` `Never` atau `OnFailure` dan berada dalam fase pod `Succeeded` atau `Failed`, atau telah dihapus dan semua kontainer dalam keadaan Terminated) deret metrik tidak lagi dilaporkan karena penjadwal sekarang sudah dibebaskan untuk menjadwalkan pod lain untuk dijalankan. Metrik yang dibahas pada bagian ini dikenal sebagai `kube_pod_resource_request` dan `kube_pod_resource_limit`.
|
||||
|
||||
Metrik diekspos melalui _endpoint_ HTTP `/metrics/resources` dan memerlukan otorisasi yang sama seperti endpoint `/metrics`
|
||||
pada penjadwal. Kamu harus menggunakan opsi `--show-hidden-metrics-for-version=1.20` untuk mengekspos metrik-metrik stabilitas alfa ini.
|
||||
|
|
|
|||
|
|
@ -46,25 +46,25 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
|
|||
FOO_SERVICE_PORT=<the port the Service is running on>
|
||||
```
|
||||
|
||||
*Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
|
||||
*Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh `Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
|
||||
|
||||
- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS.
|
||||
Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis.
|
||||
|
||||
- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`.
|
||||
- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <`hostIP`, `hostPort`, `protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan `protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai `hostIP` dan `TCP` sebagai default `protokol`.
|
||||
|
||||
Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
|
||||
|
||||
Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
|
||||
|
||||
- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`.
|
||||
- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti `hostPort`.
|
||||
|
||||
- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless-
|
||||
services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
|
||||
services) (yang memiliki `ClusterIP` dari `None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
|
||||
|
||||
## Menggunakan label
|
||||
|
||||
- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
|
||||
- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen `phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
|
||||
|
||||
|
||||
Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
|
||||
|
|
@ -103,11 +103,11 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul
|
|||
## Menggunakan kubectl
|
||||
|
||||
|
||||
- Gunakan `kubectl apply -f <directory>`. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` <directory> `dan meneruskannya ke` apply`.
|
||||
- Gunakan `kubectl apply -f <directory>`. Ini mencari konfigurasi Kubernetes di semua file `.yaml`, `.yml`, dan `.json` di `<directory>` dan meneruskannya ke `apply`.
|
||||
|
||||
- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
- Gunakan label selector untuk operasi `get` dan `delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
|
||||
- Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
|
||||
- Gunakan `kubectl run` dan `kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Kubelet memiliki _plugin_ jaringan bawaan tunggal, dan jaringan bawaan umum untu
|
|||
|
||||
## Persyaratan _Plugin_ Jaringan
|
||||
|
||||
Selain menyediakan [antarmuka `NetworkPlugin`](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) untuk mengonfigurasi dan membersihkan jaringan Pod, _plugin_ ini mungkin juga memerlukan dukungan khusus untuk kube-proxy. Proksi _iptables_ jelas tergantung pada _iptables_, dan _plugin_ ini mungkin perlu memastikan bahwa lalu lintas kontainer tersedia untuk _iptables_. Misalnya, jika plugin menghubungkan kontainer ke _bridge_ Linux, _plugin_ harus mengatur nilai sysctl `net/bridge/bridge-nf-call-iptables` menjadi ` 1` untuk memastikan bahwa proksi _iptables_ berfungsi dengan benar. Jika _plugin_ ini tidak menggunakan _bridge_ Linux (melainkan sesuatu seperti Open vSwitch atau mekanisme lainnya), _plugin_ ini harus memastikan lalu lintas kontainer dialihkan secara tepat untuk proksi.
|
||||
Selain menyediakan [antarmuka `NetworkPlugin`](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) untuk mengonfigurasi dan membersihkan jaringan Pod, _plugin_ ini mungkin juga memerlukan dukungan khusus untuk kube-proxy. Proksi _iptables_ jelas tergantung pada _iptables_, dan _plugin_ ini mungkin perlu memastikan bahwa lalu lintas kontainer tersedia untuk _iptables_. Misalnya, jika plugin menghubungkan kontainer ke _bridge_ Linux, _plugin_ harus mengatur nilai sysctl `net/bridge/bridge-nf-call-iptables` menjadi `1` untuk memastikan bahwa proksi _iptables_ berfungsi dengan benar. Jika _plugin_ ini tidak menggunakan _bridge_ Linux (melainkan sesuatu seperti Open vSwitch atau mekanisme lainnya), _plugin_ ini harus memastikan lalu lintas kontainer dialihkan secara tepat untuk proksi.
|
||||
|
||||
Secara bawaan jika tidak ada _plugin_ jaringan Kubelet yang ditentukan, _plugin_ `noop` digunakan, yang menetapkan `net/bridge/bridge-nf-call-iptables=1` untuk memastikan konfigurasi sederhana (seperti Docker dengan sebuah _bridge_) bekerja dengan benar dengan proksi _iptables_.
|
||||
|
||||
|
|
@ -148,7 +148,7 @@ Opsi ini disediakan untuk _plugin_ jaringan; Saat ini **hanya kubenet yang mendu
|
|||
## Ringkasan Penggunaan
|
||||
|
||||
* `--network-plugin=cni` menetapkan bahwa kita menggunakan _plugin_ jaringan `cni` dengan _binary-binary plugin_ CNI aktual yang terletak di `--cni-bin-dir` (nilai bawaannya `/opt/cni/bin`) dan konfigurasi _plugin_ CNI yang terletak di `--cni-conf-dir` (nilai bawaannya `/etc/cni/net.d`).
|
||||
* `--network-plugin=kubenet` menentukan bahwa kita menggunakan _plugin_ jaringan` kubenet` dengan `bridge` CNI dan _plugin-plugin_ `host-local` yang terletak di `/opt/cni/bin` atau `cni-bin-dir`.
|
||||
* `--network-plugin=kubenet` menentukan bahwa kita menggunakan _plugin_ jaringan `kubenet` dengan `bridge` CNI dan _plugin-plugin_ `host-local` yang terletak di `/opt/cni/bin` atau `cni-bin-dir`.
|
||||
* `--network-plugin-mtu=9001` menentukan MTU yang akan digunakan, saat ini hanya digunakan oleh _plugin_ jaringan `kubenet`.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -279,7 +279,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3
|
|||
##### Tidak akan pernah ditempatkan bersamaan dalam node yang sama
|
||||
|
||||
|
||||
Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy klaster redis sehingga tidak ada dua instance terletak pada hos yang sama.
|
||||
Contoh di atas menggunakan aturan `PodAntiAffinity` dengan `topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy klaster redis sehingga tidak ada dua instance terletak pada hos yang sama.
|
||||
Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama.
|
||||
|
||||
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ permintaan terhadap kapasitas. Hal ini memungkinkan pengguna untuk _bin pack_
|
|||
sumber daya tambahan dengan menggunakan parameter yang sesuai untuk meningkatkan
|
||||
pemanfaatan sumber daya yang langka dalam klaster yang besar. Perilaku
|
||||
`RequestedToCapacityRatioResourceAllocation` dari fungsi prioritas dapat
|
||||
dikontrol melalui pilihan konfigurasi yang disebut ` RequestToCapacityRatioArguments`.
|
||||
dikontrol melalui pilihan konfigurasi yang disebut `RequestToCapacityRatioArguments`.
|
||||
Argumen ini terdiri dari dua parameter yaitu `shape` dan `resources`. Shape
|
||||
memungkinkan pengguna untuk menyempurnakan fungsi menjadi yang paling tidak
|
||||
diminta atau paling banyak diminta berdasarkan nilai `utilization` dan `score`.
|
||||
|
|
@ -36,7 +36,7 @@ Sumber daya terdiri dari `name` yang menentukan sumber daya mana yang dipertimba
|
|||
selama penilaian dan `weight` yang menentukan bobot masing-masing sumber daya.
|
||||
|
||||
Di bawah ini adalah contoh konfigurasi yang menetapkan `requestedToCapacityRatioArguments`
|
||||
pada perilaku _bin packing_ untuk sumber daya tambahan` intel.com/foo` dan `intel.com/bar`
|
||||
pada perilaku _bin packing_ untuk sumber daya tambahan `intel.com/foo` dan `intel.com/bar`
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ yang dikonfigurasi untuk Service ini.
|
|||
### Tipe _LoadBalancer_
|
||||
|
||||
Penyedia layanan _cloud_ yang mendukung IPv6 untuk pengaturan beban eksternal,
|
||||
Mengatur bagian `type` menjadi` LoadBalancer` sebagai tambahan terhadap mengatur bagian
|
||||
Mengatur bagian `type` menjadi `LoadBalancer` sebagai tambahan terhadap mengatur bagian
|
||||
`ipFamily` menjadi `IPv6` menyediakan sebuah _cloud load balancer_ untuk Service kamu.
|
||||
|
||||
## Lalu lintas _egress_
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ _availability zone_ yang sama.
|
|||
|
||||
## Pengantar
|
||||
|
||||
Secara bawaan lalu lintas jaringan yang dikirim ke `ClusterIP` atau` NodePort` dari Service
|
||||
Secara bawaan lalu lintas jaringan yang dikirim ke `ClusterIP` atau `NodePort` dari Service
|
||||
dapat dialihkan ke alamat _backend_ untuk Service tersebut. Sejak Kubernetes 1.7
|
||||
dimungkinkan untuk merutekan lalu lintas jaringan "eksternal" ke Pod yang berjalan di
|
||||
Node yang menerima lalu lintas jaringan, tetapi fitur ini tidak didukung untuk `ClusterIP` dari
|
||||
|
|
|
|||
|
|
@ -198,8 +198,8 @@ allowedTopologies:
|
|||
- matchLabelExpressions:
|
||||
- key: failure-domain.beta.kubernetes.io/zone
|
||||
values:
|
||||
- us-central1-a
|
||||
- us-central1-b
|
||||
- us-central-1a
|
||||
- us-central-1b
|
||||
```
|
||||
|
||||
## Parameter-Parameter
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ membuat Pod pada semua Node.
|
|||
|
||||
### Dijadwalkan oleh _default scheduler_
|
||||
|
||||
{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
|
||||
{{< feature-state for_kubernetes_version="1.17" state="stable" >}}
|
||||
|
||||
DaemonSet memastikan bahwa semua Node yang memenuhi syarat menjalankan salinan
|
||||
Pod. Normalnya, Node yang menjalankan Pod dipilih oleh _scheduler_ Kubernetes.
|
||||
|
|
|
|||
|
|
@ -248,7 +248,7 @@ rules:
|
|||
|
||||
Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar `resourceNames`.
|
||||
Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya.
|
||||
Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau` update` pada sebuah
|
||||
Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau `update` pada sebuah
|
||||
{{< glossary_tooltip term_id="ConfigMap" >}} bernama `my-configmap`:
|
||||
|
||||
```yaml
|
||||
|
|
@ -268,7 +268,7 @@ rules:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan nama sumber daya. Untuk `create`,
|
||||
Kamu tidak dapat membatasi permintaan `create` atau `deletecollection` dengan nama sumber daya. Untuk `create`,
|
||||
keterbatasan ini dikarenakan nama objek tidak diketahui pada waktu otorisasi.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI
|
|||
|
||||
Kuantitas adalah representasi dari bilangan kecil atau besar menggunakan notasi bilangan bulat kompak dengan sufiks SI. Bilangan pecahan direpresentasikan dengan satuan mili, sedangkan bilangan besar direpresentasikan dengan satuan kilo, mega, atau giga.
|
||||
|
||||
Misalnya, angka `1,5` direpresentasikan sebagai` 1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai `1k`, dan `1000000` sebagai `1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat ditulis sebagai `2Ki`.
|
||||
Misalnya, angka `1,5` direpresentasikan sebagai `1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai `1k`, dan `1000000` sebagai `1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat ditulis sebagai `2Ki`.
|
||||
|
||||
Satuan desimal yang diterima (pangkat 10) adalah `m` (mili), `k` (kilo, sengaja huruf kecil), `M` (mega), `G` (giga), `T` (tera), `P` (peta), `E` (exa).
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ card:
|
|||
weight: 40
|
||||
---
|
||||
|
||||
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm adalah fitur yang dibuat untuk menyediakan `kubeadm init` dan` kubeadm join` sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes.
|
||||
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm adalah fitur yang dibuat untuk menyediakan `kubeadm init` dan `kubeadm join` sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes.
|
||||
|
||||
kubeadm melakukan tindakan yang diperlukan untuk membuat klaster minimum yang layak untuk aktif dan berjalan. Secara desain, ini hanya memperdulikan tentang *bootstrap*, bukan tentang mesin *provisioning*. Demikian pula, dengan instalasi berbagai *addon* atau tambahan yang bagus untuk dimiliki, seperti Dasbor Kubernetes, solusi pemantauan, dan tambahan khusus cloud, tidak termasuk dalam cakupan.
|
||||
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ Dalam banyak kasus, IP Node, IP Pod, dan beberapa IP Service pada sebuah klaster
|
|||
Kamu memiliki beberapa opsi untuk menghubungi Node, Pod, dan Service dari luar klaster:
|
||||
|
||||
- Mengakses Service melalui IP publik.
|
||||
- Gunakan Service dengan tipe `NodePort` atau` LoadBalancer` untuk membuat Service dapat dijangkau di luar klaster. Lihat dokumentasi [Service](/docs/user-guide/services) dan perintah [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose).
|
||||
- Gunakan Service dengan tipe `NodePort` atau `LoadBalancer` untuk membuat Service dapat dijangkau di luar klaster. Lihat dokumentasi [Service](/docs/user-guide/services) dan perintah [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose).
|
||||
- Bergantung pada lingkungan klaster kamu, hal ini mungkin hanya mengekspos Service ke jaringan perusahaan kamu, atau mungkin mengeksposnya ke internet. Pikirkan apakah Service yang diekspos aman atau tidak. Apakah layanan di balik Service tersebut melakukan autentikasinya sendiri?
|
||||
- Tempatkan Pod di belakang Service. Untuk mengakses satu Pod tertentu dari sekumpulan replika, misalnya untuk pengawakutuan (_debugging_), letakkan label unik di Pod dan buat Service baru yang memilih label ini.
|
||||
- Pada kebanyakan kasus, pengembang aplikasi tidak perlu langsung mengakses Node melalui IP Node mereka.
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ Ini dilakukan dengan menspesifikasikan _parent_ cgroup sebagai nilai dari _flag_
|
|||
Kami merekomendasikan _daemon_ sistem Kubernetes untuk ditempatkan pada
|
||||
tingkatan cgroup yang tertinggi (contohnya, `runtime.slice` pada mesin systemd).
|
||||
Secara ideal, setiap _daemon_ sistem sebaiknya dijalankan pada _child_ cgroup
|
||||
di bawah _parent_ ini. Lihat [dokumentasi](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
|
||||
di bawah _parent_ ini. Lihat [dokumentasi](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md#recommended-cgroups-setup)
|
||||
untuk mengetahui rekomendasi hierarki cgroup secara detail.
|
||||
|
||||
Catatan: kubelet **tidak membuat** `--kube-reserved-cgroup` jika cgroup
|
||||
|
|
|
|||
|
|
@ -268,7 +268,7 @@ status:
|
|||
|
||||
## Contoh: Men-_debug_ Node yang mati/tidak terjangkau (_down/unreachable_)
|
||||
|
||||
Terkadang saat men-_debug_ melihat status sebuah Node akan sangat berguna - misalnya, karena kamu telah melihat perilaku aneh dari sebuah Pod yang sedang berjalan pada Node tersebut, atau untuk mencari tahu mengapa sebuah Pod tidak dapat dijadwalkan ke dalam Node tersebut. Seperti pada Pod, kamu dapat menggunakan perintah `kubectl description node` dan` kubectl get node -o yaml` untuk mengambil informasi mendetil tentang Node. Misalnya, disini kamu akan melihat jika sebuah Node sedang mati (terputus dari jaringan, atau kubelet mati dan tidak mau restart, dll.). Perhatikan peristiwa yang menunjukkan Node tersebut NotReady, dan juga perhatikan bahwa Pod tidak lagi berjalan (mereka akan dikeluarkan setelah lima menit berstatus NotReady).
|
||||
Terkadang saat men-_debug_ melihat status sebuah Node akan sangat berguna - misalnya, karena kamu telah melihat perilaku aneh dari sebuah Pod yang sedang berjalan pada Node tersebut, atau untuk mencari tahu mengapa sebuah Pod tidak dapat dijadwalkan ke dalam Node tersebut. Seperti pada Pod, kamu dapat menggunakan perintah `kubectl description node` dan `kubectl get node -o yaml` untuk mengambil informasi mendetil tentang Node. Misalnya, disini kamu akan melihat jika sebuah Node sedang mati (terputus dari jaringan, atau kubelet mati dan tidak mau restart, dll.). Perhatikan peristiwa yang menunjukkan Node tersebut NotReady, dan juga perhatikan bahwa Pod tidak lagi berjalan (mereka akan dikeluarkan setelah lima menit berstatus NotReady).
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
|
|
|
|||
|
|
@ -426,7 +426,7 @@ pengambilan metrik. Terakhir, kondisi terakhir, `ScalingLimited`, menunjukkan ba
|
|||
|
||||
## Lampiran: Kuantitas
|
||||
|
||||
Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="quantity" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti kamu mungkin melihat nilai metrik berfluktuasi antara `1` dan `1500m`, atau `1` dan` 1,5` ketika ditulis dalam notasi desimal.
|
||||
Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="quantity" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti kamu mungkin melihat nilai metrik berfluktuasi antara `1` dan `1500m`, atau `1` dan `1,5` ketika ditulis dalam notasi desimal.
|
||||
|
||||
## Lampiran: Skenario lain yang memungkinkan
|
||||
|
||||
|
|
|
|||
|
|
@ -41,13 +41,13 @@ L'utilizzo di questi campi varia a seconda del provider cloud o della configuraz
|
|||
|
||||
### Condition
|
||||
|
||||
l campo `conditions` descrive lo stato di tutti i nodi` Running`.
|
||||
l campo `conditions` descrive lo stato di tutti i nodi `Running`.
|
||||
|
||||
|
||||
| Condizione del nodo | Descrizione |
|
||||
| ---------------- | ------------- |
|
||||
| `OutOfDisk` | `True` se lo spazio disponibile sul nodo non è sufficiente per aggiungere nuovi pod, altrimenti` False` |
|
||||
| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod,` False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
|
||||
| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod, `False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
|
||||
| `MemoryPressure` | `Vero` se la pressione esiste sulla memoria del nodo, ovvero se la memoria del nodo è bassa; altrimenti `False` |
|
||||
| `PIDPressure` | `True` se la pressione esiste sui processi, ovvero se ci sono troppi processi sul nodo; altrimenti `False` |
|
||||
| `DiskPressure` | `True` se esiste una pressione sulla dimensione del disco, ovvero se la capacità del disco è bassa; altrimenti `False` |
|
||||
|
|
@ -64,12 +64,12 @@ La condizione del nodo è rappresentata come un oggetto JSON. Ad esempio, la seg
|
|||
]
|
||||
```
|
||||
|
||||
Se lo stato della condizione Ready rimane `Unknown` o` False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller](/docs/admin/kube-controller-manager/) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
|
||||
Se lo stato della condizione Ready rimane `Unknown` o `False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller](/docs/admin/kube-controller-manager/) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
|
||||
|
||||
Nelle versioni di Kubernetes precedenti alla 1.5, il controllore del nodo [forzerebbe la cancellazione](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
|
||||
questi pod non raggiungibili dall'apiserver. Tuttavia, in 1.5 e versioni successive, il controller del nodo non impone l'eliminazione dei pod finché non lo è
|
||||
confermato che hanno smesso di funzionare nel cluster. Puoi vedere i pod che potrebbero essere in esecuzione su un nodo irraggiungibile
|
||||
lo stato `Terminating` o` Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
|
||||
lo stato `Terminating` o `Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
|
||||
lasciato permanentemente un cluster, potrebbe essere necessario che l'amministratore del cluster elimini manualmente l'oggetto nodo. Cancellare l'oggetto nodo da
|
||||
Kubernetes fa sì che tutti gli oggetti Pod in esecuzione sul nodo vengano eliminati dal server apis e libera i loro nomi.
|
||||
|
||||
|
|
@ -227,7 +227,7 @@ Per l'autoregistrazione, il kubelet viene avviato con le seguenti opzioni:
|
|||
- `--kubeconfig` - Percorso delle credenziali per autenticarsi sull'apiserver.
|
||||
- `--cloud-provider` - Come parlare con un provider cloud per leggere i metadati su se stesso.
|
||||
- `--register-node` - Si registra automaticamente con il server API.
|
||||
- `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola` <chiave> = <valore>: <effetto> `). No-op se `register-node` è falso.
|
||||
- `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola `<chiave> = <valore>: <effetto>`). No-op se `register-node` è falso.
|
||||
- `--node-ip` - Indirizzo IP del nodo.
|
||||
- `--node-labels` - Etichette da aggiungere quando si registra il nodo nel cluster (vedere le restrizioni dell'etichetta applicate dal [plugin di accesso NodeRestriction](/docs/reference/access-authn-authz/admission-controller/#noderestriction) in 1.13+).
|
||||
- `--node-status-update-frequency` - Specifica la frequenza con cui kubelet invia lo stato del nodo al master
|
||||
|
|
|
|||
|
|
@ -25,13 +25,13 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine
|
|||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unisce Flannel e Calico, fornendo i criteri di rete e di rete.
|
||||
* [Cilium](https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave.
|
||||
* [Contiv](http://contiv.github.io) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm.
|
||||
* [Contiv](https://contivpp.io/) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes.
|
||||
* Multus è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1/docs/kubernetes-1-installation.rst) è una piattaforma SDN che fornisce una rete basata su policy tra i pod di Kubernetes e non Kubernetes con visibilità e monitoraggio della sicurezza.
|
||||
* [Romana](http://romana.io) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Romana](https://github.com/romana/romana) è una soluzione di rete Layer 3 per pod network che supporta anche [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Dettagli di installazione del componente aggiuntivo di Kubeadm disponibili [qui](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornisce i criteri di rete e di rete, continuerà a funzionare su entrambi i lati di una partizione di rete e non richiede un database esterno.
|
||||
|
||||
## Service Discovery
|
||||
|
|
@ -48,5 +48,3 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine
|
|||
qui ci sono molti altri componenti aggiuntivi documentati nella directory deprecata [cluster / addons](https://git.k8s.io/kubernetes/cluster/addons).
|
||||
|
||||
Quelli ben mantenuti dovrebbero essere collegati qui.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 20
|
|||
<!-- overview -->
|
||||
|
||||
Quando si utilizza l'autenticazione del certificato client, è possibile generare certificati
|
||||
manualmente tramite `easyrsa`,` openssl` o `cfssl`.
|
||||
manualmente tramite `easyrsa`, `openssl` o `cfssl`.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ controllerManager:
|
|||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
```
|
||||
|
||||
I provider cloud in-tree in genere richiedono sia `--cloud-provider` e` --cloud-config` specificati nelle righe di
|
||||
I provider cloud in-tree in genere richiedono sia `--cloud-provider` e `--cloud-config` specificati nelle righe di
|
||||
comando per [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/)
|
||||
e il [Kubelet](/docs/admin/kubelet/). Anche il contenuto del file specificato in `--cloud-config` per ciascun provider
|
||||
è documentato di seguito.
|
||||
|
|
@ -91,8 +91,8 @@ spec:
|
|||
* `service.beta.kubernetes.io / aws-load-balancer-access-log-enabled`: utilizzato sul servizio per abilitare o disabilitare i log di accesso.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-name`: usato per specificare il nome del bucket di log degli accessi s3.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-prefix`: utilizzato per specificare il prefisso del bucket del registro di accesso s3.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: "Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2" `.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o` https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o` tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e` aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: `"Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2"`.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o `https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o `tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e `aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-ssl-cert`: utilizzato nel servizio per richiedere un listener sicuro. Il valore è un certificato ARN valido. Per ulteriori informazioni, vedere [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN è un ARN certificato IAM o CM, ad es. `ARN: AWS: ACM: US-est-1: 123456789012: certificato / 12345678-1234-1234-1234-123456789012`.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-enabled`: utilizzato sul servizio per abilitare o disabilitare il drenaggio della connessione.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-timeout`: utilizzato sul servizio per specificare un timeout di drenaggio della connessione.
|
||||
|
|
@ -125,7 +125,7 @@ corrispondere al nome VM di CloudStack.
|
|||
Il provider cloud GCE utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
|
||||
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il primo segmento del nome del nodo
|
||||
Kubernetes deve corrispondere al nome dell'istanza GCE (ad esempio, un nodo denominato `kubernetes-node-2.c.my-proj.internal`
|
||||
deve corrispondere a un'istanza denominata` kubernetes-node-2`) .
|
||||
deve corrispondere a un'istanza denominata `kubernetes-node-2`) .
|
||||
|
||||
## OpenStack
|
||||
Questa sezione descrive tutte le possibili configurazioni che possono
|
||||
|
|
@ -243,7 +243,7 @@ file:
|
|||
il bilanciamento del carico.
|
||||
* `lb-method` (Opzionale): utilizzato per specificare l'algoritmo in base al quale verrà caricato il carico
|
||||
distribuito tra i membri del pool di bilanciamento del carico. Il valore può essere
|
||||
`ROUND_ROBIN`,` LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
|
||||
`ROUND_ROBIN`, `LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
|
||||
nessuno è specificato è `ROUND_ROBIN`.
|
||||
* `lb-provider` (Opzionale): utilizzato per specificare il provider del servizio di bilanciamento del carico.
|
||||
Se non specificato, sarà il servizio provider predefinito configurato in neutron
|
||||
|
|
@ -272,7 +272,7 @@ Queste opzioni di configurazione per il provider OpenStack riguardano lo storage
|
|||
e dovrebbe apparire nella sezione `[BlockStorage]` del file `cloud.conf`:
|
||||
|
||||
* `bs-version` (Opzionale): usato per sovrascrivere il rilevamento automatico delle versioni. Valido
|
||||
i valori sono `v1`,` v2`, `v3` e` auto`. Quando `auto` è specificato automatico
|
||||
i valori sono `v1`, `v2`, `v3` e `auto`. Quando `auto` è specificato automatico
|
||||
il rilevamento selezionerà la versione supportata più alta esposta dal sottostante
|
||||
Cloud OpenStack. Il valore predefinito se nessuno è fornito è `auto`.
|
||||
* `trust-device-path` (Opzionale): Nella maggior parte degli scenari i nomi dei dispositivi a blocchi
|
||||
|
|
|
|||
|
|
@ -162,9 +162,9 @@ In secondo luogo, decidi quanti cluster dovrebbero essere disponibili allo stess
|
|||
il numero che può essere non disponibile `U`. Se non sei sicuro, allora 1 è una buona scelta.
|
||||
|
||||
Se è possibile bilanciare il carico per indirizzare il traffico verso qualsiasi regione in caso di guasto di un cluster, allora
|
||||
avete bisogno almeno dei grossi `R` o` U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
|
||||
avete bisogno almeno dei grossi `R` o `U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
|
||||
utenti in caso di guasto di un cluster), quindi è necessario disporre di cluster `R * (U + 1)`
|
||||
(`U + 1` in ciascuna delle regioni` R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
|
||||
(`U + 1` in ciascuna delle regioni `R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
|
||||
|
||||
Infine, se uno qualsiasi dei tuoi cluster richiederebbe più del numero massimo consigliato di nodi per un cluster Kubernetes, allora
|
||||
potresti aver bisogno di più cluster. Kubernetes v1.3 supporta cluster di dimensioni fino a 1000 nodi. Supporta Kubernetes v1.8
|
||||
|
|
|
|||
|
|
@ -23,12 +23,12 @@ Kubernetes gestisce il ciclo di vita di tutte le immagini tramite imageManager,
|
|||
di consulente.
|
||||
|
||||
La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori:
|
||||
`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
|
||||
`HighThresholdPercent` e `LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
|
||||
attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo
|
||||
soglia è stata soddisfatta.
|
||||
|
||||
La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori:
|
||||
`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
|
||||
`HighThresholdPercent` e `LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
|
||||
attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo
|
||||
soglia è stata soddisfatta.
|
||||
|
||||
|
|
@ -44,8 +44,8 @@ Kubelet agirà su contenitori non identificati, cancellati o al di fuori dei lim
|
|||
precedentemente menzionate. I contenitori più vecchi saranno generalmente rimossi per primi. `MaxPerPodContainer`
|
||||
e `MaxContainer` possono potenzialmente entrare in conflitto l'uno con l'altro in situazioni in cui il mantenimento del
|
||||
numero massimo di contenitori per pod (`MaxPerPodContainer`) non rientra nell'intervallo consentito di contenitori morti
|
||||
globali (` MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe
|
||||
quello di eseguire il downgrade di` MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i
|
||||
globali (`MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe
|
||||
quello di eseguire il downgrade di `MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i
|
||||
contenitori di proprietà dei pod che sono stati cancellati vengono rimossi una volta che sono più vecchi di "MinAge".
|
||||
|
||||
I contenitori che non sono gestiti da Kubelet non sono soggetti alla garbage collection del contenitore.
|
||||
|
|
@ -83,12 +83,12 @@ Compreso:
|
|||
|
||||
| Bandiera esistente | Nuova bandiera | Motivazione
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` o` --eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` o `--eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | i reclami di sfratto ottengono lo stesso comportamento |
|
||||
| `--maximum-dead-containers` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
|
||||
| `--maximum-dead-containers-per-container` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
|
||||
| `--minimum-container-ttl-duration` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` o` eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` o `eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | lo sfratto generalizza la transizione della pressione del disco verso altre risorse |
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ $ kubectl logs counter
|
|||
...
|
||||
```
|
||||
|
||||
You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag` --previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag `--previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
|
||||
## Logging at the node level
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ bypassando il meccanismo di registrazione predefinito. Usano il [klog] [klog]
|
|||
biblioteca di registrazione. È possibile trovare le convenzioni per la gravità della registrazione per quelli
|
||||
componenti nel [documento di sviluppo sulla registrazione](https://git.k8s.io/community/contributors/devel/logging.md).
|
||||
|
||||
Analogamente ai log del contenitore, i log dei componenti di sistema sono in /var/log`
|
||||
Analogamente ai log del contenitore, i log dei componenti di sistema sono in `/var/log`
|
||||
la directory dovrebbe essere ruotata. Nei cluster di Kubernetes allevati da
|
||||
lo script `kube-up.sh`, quei log sono configurati per essere ruotati da
|
||||
lo strumento `logrotate` al giorno o una volta che la dimensione supera i 100 MB.
|
||||
|
|
@ -143,7 +143,7 @@ Puoi utilizzare un contenitore sidecar in uno dei seguenti modi:
|
|||
|
||||
|
||||
|
||||
Facendo scorrere i propri contenitori sidecar sul proprio `stdout` e` stderr`
|
||||
Facendo scorrere i propri contenitori sidecar sul proprio `stdout` e `stderr`
|
||||
flussi, è possibile sfruttare il kubelet e l'agente di registrazione che
|
||||
già eseguito su ciascun nodo. I contenitori del sidecar leggono i log da un file, un socket,
|
||||
o il diario. Ogni singolo contenitore sidecar stampa il log nel proprio `stdout`
|
||||
|
|
@ -151,16 +151,16 @@ o flusso `stderr`.
|
|||
|
||||
Questo approccio consente di separare diversi flussi di log da diversi
|
||||
parti della tua applicazione, alcune delle quali possono mancare di supporto
|
||||
per scrivere su `stdout` o` stderr`. La logica dietro il reindirizzamento dei registri
|
||||
per scrivere su `stdout` o `stderr`. La logica dietro il reindirizzamento dei registri
|
||||
è minimo, quindi non è un sovraccarico significativo. Inoltre, perché
|
||||
`stdout` e` stderr` sono gestiti da kubelet, puoi usare gli strumenti integrati
|
||||
`stdout` e `stderr` sono gestiti da kubelet, puoi usare gli strumenti integrati
|
||||
come `log di kubectl`.
|
||||
|
||||
Considera il seguente esempio. Un pod esegue un singolo contenitore e il contenitore
|
||||
scrive su due file di registro diversi, utilizzando due formati diversi. Ecco un
|
||||
file di configurazione per il pod:
|
||||
|
||||
{{<codenew file = "admin/logging/two-files-counter-pod.yaml">}}
|
||||
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
|
||||
|
||||
Sarebbe un disastro avere voci di registro di diversi formati nello stesso registro
|
||||
stream, anche se si è riusciti a reindirizzare entrambi i componenti al flusso `stdout` di
|
||||
|
|
@ -170,7 +170,7 @@ i registri al proprio flusso `stdout`.
|
|||
|
||||
Ecco un file di configurazione per un pod con due contenitori sidecar:
|
||||
|
||||
{{<codenew file = "admin/logging/two-files-counter-pod-streaming-sidecar.yaml">}}
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
|
||||
|
||||
Ora quando si esegue questo pod, è possibile accedere separatamente a ciascun flusso di log
|
||||
eseguendo i seguenti comandi:
|
||||
|
|
@ -205,7 +205,7 @@ approccio contenitore.
|
|||
I contenitori del sidecar possono anche essere usati per ruotare i file di log che non possono essere
|
||||
ruotato dall'applicazione stessa. [Un esempio](https://github.com/samsung-cnct/logrotate)
|
||||
di questo approccio è un piccolo contenitore che esegue periodicamente logrotate.
|
||||
Tuttavia, si raccomanda di usare `stdout` e` stderr` direttamente e lasciare la rotazione
|
||||
Tuttavia, si raccomanda di usare `stdout` e `stderr` direttamente e lasciare la rotazione
|
||||
e politiche di conservazione al kubelet.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s
|
|||
```
|
||||
|
||||
Con i suddetti comandi, prima creiamo le risorse sotto `examples/application/nginx/` e stampiamo le risorse create con il formato di output `-o name`
|
||||
(stampa ogni risorsa come risorsa / nome). Quindi `grep` solo il" servizio ", e poi lo stampiamo con` kubectl get`.
|
||||
(stampa ogni risorsa come risorsa / nome). Quindi `grep` solo il" servizio ", e poi lo stampiamo con `kubectl get`.
|
||||
|
||||
Se si organizzano le risorse su più sottodirectory all'interno di una particolare directory, è possibile eseguire ricorsivamente anche le operazioni nelle sottodirectory, specificando `--recursive` o` -R` accanto al flag `--filename, -f`.
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ $ kubectl create -f project/k8s/development
|
|||
error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)
|
||||
```
|
||||
|
||||
Invece, specifica il flag `--recursive` o` -R` con il flag `--filename, -f` come tale:
|
||||
Invece, specifica il flag `--recursive` o `-R` con il flag `--filename, -f` come tale:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f project/k8s/development --recursive
|
||||
|
|
@ -121,7 +121,7 @@ deployment.apps/my-deployment created
|
|||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
Il flag `--recursive` funziona con qualsiasi operazione che accetta il flag` --filename, -f` come: `kubectl {crea, ottieni, cancella, descrivi, implementa} ecc .`
|
||||
Il flag `--recursive` funziona con qualsiasi operazione che accetta il flag `--filename, -f` come: `kubectl {crea, ottieni, cancella, descrivi, implementa} ecc .`
|
||||
|
||||
Il flag `--recursive` funziona anche quando sono forniti più argomenti` -f`:
|
||||
|
||||
|
|
@ -195,7 +195,7 @@ modo che la nuova versione possa ricevere il traffico di produzione in tempo rea
|
|||
|
||||
Ad esempio, puoi usare un'etichetta `track` per differenziare le diverse versioni.
|
||||
|
||||
La versione stabile e primaria avrebbe un'etichetta `track` con valore come` stable`:
|
||||
La versione stabile e primaria avrebbe un'etichetta `track` con valore come `stable`:
|
||||
|
||||
```yaml
|
||||
name: frontend
|
||||
|
|
@ -210,7 +210,7 @@ La versione stabile e primaria avrebbe un'etichetta `track` con valore come` sta
|
|||
```
|
||||
|
||||
e quindi puoi creare una nuova versione del frontend del guestbook che porta l'etichetta `track` con un valore diverso
|
||||
(ad esempio` canary`), in modo che due gruppi di pod non si sovrappongano:
|
||||
(ad esempio `canary`), in modo che due gruppi di pod non si sovrappongano:
|
||||
|
||||
```yaml
|
||||
name: frontend-canary
|
||||
|
|
@ -266,7 +266,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
|
|||
```
|
||||
|
||||
questo produce tutti i pod "app = nginx", con un'ulteriore colonna di etichette del livello dei pod (specificata
|
||||
con `-L` o` --label-columns`).
|
||||
con `-L` o `--label-columns`).
|
||||
|
||||
Per ulteriori informazioni, consultare [labels](/docs/concepts/overview/working-with-objects/labels/) e
|
||||
[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
|
||||
|
|
@ -353,7 +353,7 @@ non è in grado di rilevare l'eliminazione delle proprietà impostate al momento
|
|||
motivo, non li rimuoverà.
|
||||
|
||||
Tutte le chiamate successive a `kubectl apply`, e altri comandi che modificano la configurazione, come `kubectl replace`
|
||||
e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a` kubectl apply` per rilevare ed
|
||||
e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a `kubectl apply` per rilevare ed
|
||||
eseguire cancellazioni usando un tre via diff.
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -368,7 +368,7 @@ In alternativa, puoi anche aggiornare le risorse con `kubectl edit`:
|
|||
$ kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la
|
||||
Questo equivale a prima `get` la risorsa, modificarla nell'editor di testo e quindi `apply` la risorsa con la
|
||||
versione aggiornata:
|
||||
|
||||
```shell
|
||||
|
|
@ -381,7 +381,7 @@ $ rm /tmp/nginx.yaml
|
|||
```
|
||||
|
||||
Questo ti permette di fare più cambiamenti significativi più facilmente. Nota che puoi specificare l'editor con le
|
||||
variabili di ambiente `EDITOR` o` KUBE_EDITOR`.
|
||||
variabili di ambiente `EDITOR` o `KUBE_EDITOR`.
|
||||
|
||||
Per ulteriori informazioni, consultare il documento [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit).
|
||||
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ parla con altre macchine virtuali nel tuo progetto. Questo è lo stesso modello
|
|||
|
||||
Gli indirizzi IP di Kubernetes esistono nello scope `Pod` - contenitori all'interno di un 'Pod`
|
||||
condividere i loro spazi dei nomi di rete, compreso il loro indirizzo IP. Ciò significa che
|
||||
i contenitori all'interno di un `Pod` possono raggiungere tutti gli altri porti su` localhost`. Questo
|
||||
i contenitori all'interno di un `Pod` possono raggiungere tutti gli altri porti su `localhost`. Questo
|
||||
significa anche che i contenitori all'interno di un 'Pod` devono coordinare l'utilizzo della porta, ma questo
|
||||
non è diverso dai processi in una VM. Questo è chiamato il modello "IP-per-pod".
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ di [avere simultaneamente accesso a diverse implementazioni](https://github.com/
|
|||
del [modello di rete Kubernetes](https://git.k8s.io/website/docs/concepts/cluster-administration/networking.md#kubernetes-model) in runtime.
|
||||
Ciò include qualsiasi implementazione che funziona come un [plugin CNI](https://github.com/containernetworking/cni#3rd-party-plugins),
|
||||
come [Flannel](https://github.com/coreos/flannel#flanella), [Calico](http://docs.projectcalico.org/),
|
||||
[Romana](http://romana.io), [Weave-net](https://www.weave.works/products/tessere-net/).
|
||||
[Romana](https://github.com/romana/romana), [Weave-net](https://www.weave.works/products/tessere-net/).
|
||||
|
||||
CNI-Genie supporta anche [assegnando più indirizzi IP a un pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-indirizzi-per-pod), ciascuno da un diverso plugin CNI.
|
||||
|
||||
|
|
@ -153,7 +153,7 @@ complessità della rete richiesta per implementare Kubernetes su larga scala all
|
|||
|
||||
226/5000
|
||||
[Contiv](https://github.com/contiv/netplugin) fornisce un networking configurabile (nativo l3 usando BGP,
|
||||
overlay usando vxlan, classic l2 o Cisco-SDN / ACI) per vari casi d'uso. [Contiv](http://contiv.io) è tutto aperto.
|
||||
overlay usando vxlan, classic l2 o Cisco-SDN / ACI) per vari casi d'uso. [Contiv](https://contivpp.io/) è tutto aperto.
|
||||
|
||||
### Contrail / Tungsten Fabric
|
||||
|
||||
|
|
@ -195,10 +195,10 @@ Docker è avviato con:
|
|||
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
||||
```
|
||||
|
||||
Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` flag) in base al `Nodo` .spec.podCIDR`.
|
||||
Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` flag) in base al Nodo `.spec.podCIDR`.
|
||||
|
||||
Docker ora assegna gli IP dal blocco `cbr-cidr`. I contenitori possono raggiungere l'un l'altro e `Nodi` sul
|
||||
ponte` cbr0`. Questi IP sono tutti instradabili all'interno della rete del progetto GCE.
|
||||
ponte `cbr0`. Questi IP sono tutti instradabili all'interno della rete del progetto GCE.
|
||||
|
||||
GCE non sa nulla di questi IP, quindi non lo farà loro per il traffico internet in uscita. Per ottenere ciò viene
|
||||
utilizzata una regola iptables masquerade (aka SNAT - per far sembrare che i pacchetti provengano dal `Node` stesso)
|
||||
|
|
@ -255,7 +255,7 @@ Lars Kellogg-Stedman.
|
|||
|
||||
### Multus (a Multi Network plugin)
|
||||
|
||||
[Multus](https://github.com/Intel-Corp/multus-cni) è un plugin Multi CNI per supportare la funzionalità Multi
|
||||
[Multus](https://github.com/k8snetworkplumbingwg/multus-cni) è un plugin Multi CNI per supportare la funzionalità Multi
|
||||
Networking in Kubernetes utilizzando oggetti di rete basati su CRD in Kubernetes.
|
||||
|
||||
Multus supporta tutti i [plug-in di riferimento](https://github.com/containernetworking/plugins)
|
||||
|
|
@ -316,7 +316,7 @@ Flannel, alias [canal](https://github.com/tigera/canal) o native GCE, AWS o netw
|
|||
|
||||
### Romana
|
||||
|
||||
[Romana](http://romana.io) è una soluzione di automazione della sicurezza e della rete open source che consente di
|
||||
[Romana](https://github.com/romana/romana) è una soluzione di automazione della sicurezza e della rete open source che consente di
|
||||
distribuire Kubernetes senza una rete di overlay. Romana supporta Kubernetes
|
||||
[Politica di rete](/docs/concepts/services-networking/network-policies/) per fornire isolamento tra gli spazi dei nomi
|
||||
di rete.
|
||||
|
|
@ -335,5 +335,3 @@ entrambi i casi, la rete fornisce un indirizzo IP per pod, come è standard per
|
|||
|
||||
Il progetto iniziale del modello di rete e la sua logica, e un po 'di futuro i piani sono descritti in maggior
|
||||
dettaglio nella [progettazione della rete documento](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -137,7 +137,7 @@ kubectl describe node <ノード名をここに挿入>
|
|||
`SchedulingDisabled`はKubernetesのAPIにおけるConditionではありません;その代わり、cordonされたノードはUnschedulableとしてマークされます。
|
||||
{{< /note >}}
|
||||
|
||||
ノードのConditionはJSONオブジェクトで表現されます。例えば、正常なノードの場合は以下のような構造体が表示されます。
|
||||
Nodeの状態は、Nodeリソースの`.status`の一部として表現されます。例えば、正常なノードの場合は以下のようなjson構造が表示されます。
|
||||
|
||||
```json
|
||||
"conditions": [
|
||||
|
|
@ -173,36 +173,25 @@ CapacityとAllocatableについて深く知りたい場合は、ノード上で
|
|||
### Info {#info}
|
||||
|
||||
カーネルのバージョン、Kubernetesのバージョン（kubeletおよびkube-proxyのバージョン）、（使用されている場合）Dockerのバージョン、OS名など、ノードに関する一般的な情報です。
|
||||
この情報はノードからkubeletを通じて取得されます。
|
||||
この情報はノードからkubeletを通じて取得され、Kubernetes APIに公開されます。
|
||||
|
||||
## 管理 {#management}
|
||||
|
||||
[Pod](/ja/docs/concepts/workloads/pods/pod/)や[Service](/ja/docs/concepts/services-networking/service/)と違い、ノードは本質的にはKubernetesによって作成されません。GCPのようなクラウドプロバイダーによって外的に作成されるか、VMや物理マシンのプールに存在するものです。そのため、Kubernetesがノードを作成すると、そのノードを表すオブジェクトが作成されます。作成後、Kubernetesはそのノードが有効かどうかを確認します。 たとえば、次の内容からノードを作成しようとしたとします:
|
||||
## ハートビート
|
||||
ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
|
||||
以下の２つのハートビートがあります：
|
||||
* Nodeの`.status`の更新
|
||||
* [Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
|
||||
各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
|
||||
Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
|
||||
|
||||
```json
|
||||
{
|
||||
"kind": "Node",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "10.240.79.157",
|
||||
"labels": {
|
||||
"name": "my-first-k8s-node"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。
|
||||
|
||||
Kubernetesは内部的にNodeオブジェクトを作成し、 `metadata.name`フィールドに基づくヘルスチェックによってノードを検証します。ノードが有効な場合、つまり必要なサービスがすべて実行されている場合は、Podを実行する資格があります。それ以外の場合、該当ノードが有効になるまではいかなるクラスターの活動に対しても無視されます。
|
||||
Nodeオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。
|
||||
- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。(到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです)
|
||||
- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。
|
||||
|
||||
{{< note >}}
|
||||
Kubernetesは無効なノードのためにオブジェクトを保存し、それをチェックし続けます。
|
||||
このプロセスを停止するには、Nodeオブジェクトを明示的に削除する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
現在、Kubernetesのノードインターフェースと相互作用する3つのコンポーネントがあります。ノードコントローラー、kubelet、およびkubectlです。
|
||||
|
||||
### ノードコントローラー
|
||||
## ノードコントローラー
|
||||
|
||||
ノード{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、ノードのさまざまな側面を管理するKubernetesのコントロールプレーンコンポーネントです。
|
||||
|
||||
|
|
@ -216,16 +205,6 @@ Kubernetesは無効なノードのためにオブジェクトを保存し、そ
|
|||
ノードが到達不能(例えば、ノードがダウンしているなどので理由で、ノードコントローラーがハートビートの受信を停止した場合)になると、ノードコントローラーは、NodeStatusのNodeReady conditionをConditionUnknownに変更する役割があります。その後も該当ノードが到達不能のままであった場合、Graceful Terminationを使って全てのPodを退役させます。デフォルトのタイムアウトは、ConditionUnknownの報告を開始するまで40秒、その後Podの追い出しを開始するまで5分に設定されています。
|
||||
ノードコントローラーは、`--node-monitor-period`に設定された秒数ごとに各ノードの状態をチェックします。
|
||||
|
||||
#### ハートビート
|
||||
ハートビートは、Kubernetesノードから送信され、ノードが利用可能か判断するのに役立ちます。
|
||||
２つのハートビートがあります：`NodeStatus`の更新と[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}#lease-v1-coordination-k8s-io)です。
|
||||
各ノードは`kube-node-lease`という{{< glossary_tooltip term_id="namespace" text="namespace">}}に関連したLeaseオブジェクトを持ちます。
|
||||
Leaseは軽量なリソースで、クラスターのスケールに応じてノードのハートビートにおけるパフォーマンスを改善します。
|
||||
|
||||
kubeletが`NodeStatus`とLeaseオブジェクトの作成および更新を担当します。
|
||||
|
||||
- kubeletは、ステータスに変化があったり、設定した間隔の間に更新がない時に`NodeStatus`を更新します。`NodeStatus`更新のデフォルト間隔は５分です。（到達不能の場合のデフォルトタイムアウトである40秒よりもはるかに長いです）
|
||||
- kubeletは10秒間隔(デフォルトの更新間隔)でLeaseオブジェクトの生成と更新を実施します。Leaseの更新は`NodeStatus`の更新とは独立されて行われます。Leaseの更新が失敗した場合、kubeletは200ミリ秒から始まり7秒を上限とした指数バックオフでリトライします。
|
||||
|
||||
#### 信頼性
|
||||
|
||||
|
|
@ -269,6 +248,88 @@ Pod以外のプロセス用にリソースを明示的に予約したい場合
|
|||
kubeletはリソースの割当を決定する際にトポロジーのヒントを利用できます。
|
||||
詳細は、[ノードのトポロジー管理ポリシーを制御する](/ja/docs/tasks/administer-cluster/topology-manager/)を参照してください。
|
||||
|
||||
## ノードの正常終了 {#graceful-node-shutdown}
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="v1.21" >}}
|
||||
|
||||
kubeletは、ノードのシステムシャットダウンを検出すると、ノード上で動作しているPodを終了させます。
|
||||
|
||||
Kubelet は、ノードのシャットダウン時に、ポッドが通常の[通常のポッド終了プロセス](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)に従うようにします。
|
||||
|
||||
Graceful Node Shutdownはsystemdに依存しているため、[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)を
|
||||
利用してノードのシャットダウンを一定時間遅らせることができます。
|
||||
|
||||
Graceful Node Shutdownは、v1.21でデフォルトで有効になっている`GracefulNodeShutdown` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)で制御されます。
|
||||
|
||||
なお、デフォルトでは、後述の設定オプション`ShutdownGracePeriod`および`ShutdownGracePeriodCriticalPods`の両方がゼロに設定されているため、Graceful node shutdownは有効になりません。この機能を有効にするには、この2つのkubeletの設定を適切に設定し、ゼロ以外の値を設定する必要があります。
|
||||
|
||||
Graceful shutdownでは、kubeletは以下の2段階でPodを終了させます。
|
||||
|
||||
1. そのノード上で動作している通常のPodを終了させます。
|
||||
2. そのノード上で動作している[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)を終了させます。
|
||||
|
||||
Graceful Node Shutdownには、2つの[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/)オプションを設定します。:
|
||||
* `ShutdownGracePeriod`:
|
||||
* ノードがシャットダウンを遅らせるべき合計期間を指定します。これは、通常のPodと[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)の両方のPod終了の合計猶予期間です。
|
||||
* `ShutdownGracePeriodCriticalPods`:
|
||||
* ノードのシャットダウン時に[critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)を終了させるために使用する期間を指定します。この値は、ShutdownGracePeriodよりも小さくする必要があります。
|
||||
|
||||
例えば、`ShutdownGracePeriod=30s`、`ShutdownGracePeriodCriticalPods=10s`とすると、
|
||||
kubeletはノードのシャットダウンを30秒遅らせます。シャットダウンの間、最初の20(30-10)秒は通常のポッドを優雅に終了させるために確保され、
|
||||
残りの10秒は重要なポッドを終了させるために確保されることになります。
|
||||
|
||||
{{< note >}}
|
||||
Graceful Node Shutdown中にPodが退避された場合、それらのPodの`.status`は`Failed`になります。
|
||||
`kubectl get pods`を実行すると、退避させられたPodのステータスが `Shutdown` と表示されます。
|
||||
また、`kubectl describe pod`を実行すると、ノードのシャットダウンのためにPodが退避されたことがわかります。
|
||||
|
||||
```
|
||||
Status: Failed
|
||||
Reason: Shutdown
|
||||
Message: Node is shutting, evicting pods
|
||||
```
|
||||
|
||||
失敗したポッドオブジェクトは、明示的に削除されるか、[GCによってクリーンアップ](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)されるまで保存されます。
|
||||
これは、ノードが突然終了した場合とは異なった振る舞いです。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
## スワップメモリの管理 {#swap-memory}
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
|
||||
|
||||
Kubernetes 1.22以前では、ノードはスワップメモリの使用をサポートしておらず、ノード上でスワップが検出された場合、
|
||||
kubeletはデフォルトで起動に失敗していました。1.22以降では、スワップメモリのサポートをノードごとに有効にすることができます。
|
||||
|
||||
|
||||
|
||||
ノードでスワップを有効にするには、kubeletの `NodeSwap` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にし、
|
||||
`--fail-swap-on`コマンドラインフラグまたは`failSwapOn`[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)を false に設定する必要があります。
|
||||
|
||||
|
||||
ユーザーはオプションで、ノードがスワップメモリをどのように使用するかを指定するために、`memorySwap.swapBehavior`を設定することもできます。ノードがスワップメモリをどのように使用するかを指定します。例えば、以下のようになります。
|
||||
|
||||
```yaml
|
||||
memorySwap:
|
||||
swapBehavior: LimitedSwap
|
||||
```
|
||||
|
||||
swapBehaviorで使用できる設定オプションは以下の通りです。:
|
||||
- `LimitedSwap`: Kubernetesのワークロードが、使用できるスワップ量に制限を設けます。Kubernetesが管理していないノード上のワークロードは、依然としてスワップを使用できます。
|
||||
- `UnlimitedSwap`: Kubernetesのワークロードが使用できるスワップ量に制限を設けません。システムの限界まで、要求されただけのスワップメモリを使用することができます。
|
||||
|
||||
`memorySwap`の設定が指定されておらず、[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、デフォルトのkubeletは`LimitedSwap`の設定と同じ動作を適用します。
|
||||
|
||||
`LimitedSwap`設定の動作は、ノードがコントロールグループ(「cgroups」とも呼ばれる)のv1とv2のどちらで動作しているかによって異なります。
|
||||
|
||||
Kubernetesのワークロードでは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。
|
||||
- **cgroupsv1:** Kubernetesのワークロードは、メモリとスワップを組み合わせて使用することができ、ポッドのメモリ制限が設定されている場合はその制限まで使用できます。
|
||||
- **cgroupsv2:** Kubernetesのワークロードは、スワップメモリを使用できません。
|
||||
|
||||
詳しくは、[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400)と
|
||||
[design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)をご覧いただき、テストにご協力、ご意見をお聞かせください。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [ノードコンポーネント](/ja/docs/concepts/overview/components/#node-components)について学習する。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,204 @@
|
|||
---
|
||||
title: ロギングのアーキテクチャ
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
アプリケーションログは、アプリケーション内で何が起こっているかを理解するのに役立ちます。ログは、問題のデバッグとクラスターアクティビティの監視に特に役立ちます。最近のほとんどのアプリケーションには、何らかのロギングメカニズムがあります。同様に、コンテナエンジンはロギングをサポートするように設計されています。コンテナ化されたアプリケーションで、最も簡単で最も採用されているロギング方法は、標準出力と標準エラーストリームへの書き込みです。
|
||||
|
||||
ただし、コンテナエンジンまたはランタイムによって提供されるネイティブ機能は、たいていの場合、完全なロギングソリューションには十分ではありません。
|
||||
|
||||
たとえば、コンテナがクラッシュした場合やPodが削除された場合、またはノードが停止した場合に、アプリケーションのログにアクセスしたい場合があります。
|
||||
|
||||
クラスターでは、ノードやPod、またはコンテナに関係なく、ノードに個別のストレージとライフサイクルが必要です。この概念は、_クラスターレベルロギング_ と呼ばれます。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
クラスターレベルロギングのアーキテクチャでは、ログを保存、分析、およびクエリするための個別のバックエンドが必要です。Kubernetesは、ログデータ用のネイティブストレージソリューションを提供していません。代わりに、Kubernetesに統合される多くのロギングソリューションがあります。次のセクションでは、ノードでログを処理および保存する方法について説明します。
|
||||
|
||||
## Kubernetesでの基本的なロギング {#basic-logging-in-kubernetes}
|
||||
|
||||
この例では、1秒に1回標準出力ストリームにテキストを書き込むコンテナを利用する、`Pod` specificationを使います。
|
||||
|
||||
{{< codenew file="debug/counter-pod.yaml" >}}
|
||||
|
||||
このPodを実行するには、次のコマンドを使用します:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```console
|
||||
pod/counter created
|
||||
```
|
||||
|
||||
ログを取得するには、以下のように`kubectl logs`コマンドを使用します:
|
||||
|
||||
```shell
|
||||
kubectl logs counter
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```console
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
...
|
||||
```
|
||||
|
||||
コンテナの以前のインスタンスからログを取得するために、`kubectl logs --previous`を使用できます。Podに複数のコンテナがある場合は、次のように-cフラグでコマンドにコンテナ名を追加することで、アクセスするコンテナのログを指定します。
|
||||
|
||||
```console
|
||||
kubectl logs counter -c count
|
||||
```
|
||||
|
||||
詳細については、[`kubectl logs`ドキュメント](/docs/reference/generated/kubectl/kubectl-commands#logs)を参照してください。
|
||||
|
||||
## ノードレベルでのロギング {#logging-at-the-node-level}
|
||||
|
||||
|
||||
|
||||
コンテナエンジンは、生成された出力を処理して、コンテナ化されたアプリケーションの`stdout`と`stderr`ストリームにリダイレクトします。たとえば、Dockerコンテナエンジンは、これら2つのストリームを[ロギングドライバー](https://docs.docker.com/engine/admin/logging/overview)にリダイレクトします。ロギングドライバーは、JSON形式でファイルに書き込むようにKubernetesで設定されています。
|
||||
|
||||
{{< note >}}
|
||||
Docker JSONロギングドライバーは、各行を個別のメッセージとして扱います。Dockerロギングドライバーを使用する場合、複数行メッセージを直接サポートすることはできません。ロギングエージェントレベルあるいはそれ以上のレベルで、複数行のメッセージを処理する必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
デフォルトでは、コンテナが再起動すると、kubeletは1つの終了したコンテナをログとともに保持します。Podがノードから削除されると、対応する全てのコンテナが、ログとともに削除されます。
|
||||
|
||||
ノードレベルロギングでの重要な考慮事項は、ノードで使用可能な全てのストレージをログが消費しないように、ログローテーションを実装することです。Kubernetesはログのローテーションを担当しませんが、デプロイツールでそれに対処するソリューションを構築する必要があります。たとえば、`kube-up.sh`スクリプトによってデプロイされたKubernetesクラスターには、1時間ごとに実行するように構成された[`logrotate`](https://linux.die.net/man/8/logrotate)ツールがあります。アプリケーションのログを自動的にローテーションするようにコンテナランタイムを構築することもできます。
|
||||
|
||||
例として、[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)に対応するスクリプトである`kube-up.sh`が、どのようにGCPでCOSイメージのロギングを構築しているかについて、詳細な情報を見つけることができます。
|
||||
|
||||
**CRIコンテナランタイム**を使用する場合、kubeletはログのローテーションとログディレクトリ構造の管理を担当します。kubeletはこの情報をCRIコンテナランタイムに送信し、ランタイムはコンテナログを指定された場所に書き込みます。2つのkubeletパラメーター、[`container-log-max-size`と`container-log-max-files`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)を[kubelet設定ファイル](/docs/tasks/administer-cluster/kubelet-config-file/)で使うことで、各ログファイルの最大サイズと各コンテナで許可されるファイルの最大数をそれぞれ設定できます。
|
||||
|
||||
基本的なロギングの例のように、[`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)を実行すると、ノード上のkubeletがリクエストを処理し、ログファイルから直接読み取ります。kubeletはログファイルの内容を返します。
|
||||
|
||||
{{< note >}}
|
||||
外部システムがローテーションを実行した場合、またはCRIコンテナランタイムが使用されている場合は、最新のログファイルの内容のみが`kubectl logs`で利用可能になります。例えば、10MBのファイルがある場合、`logrotate`によるローテーションが実行されると、2つのファイルが存在することになります: 1つはサイズが10MBのファイルで、もう1つは空のファイルです。この例では、`kubectl logs`は最新のログファイルの内容、つまり空のレスポンスを返します。
|
||||
{{< /note >}}
|
||||
|
||||
### システムコンポーネントログ {#system-component-logs}
|
||||
|
||||
システムコンポーネントには、コンテナ内で実行されるものとコンテナ内で実行されないものの2種類があります。例えば以下のとおりです。
|
||||
|
||||
* Kubernetesスケジューラーとkube-proxyはコンテナ内で実行されます。
|
||||
* kubeletとコンテナランタイムはコンテナ内で実行されません。
|
||||
|
||||
systemdを搭載したマシンでは、kubeletとコンテナランタイムがjournaldに書き込みます。systemdが存在しない場合、kubeletとコンテナランタイムは`var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナ内のシステムコンポーネントは、デフォルトのロギングメカニズムを迂回して、常に`/var/log`ディレクトリに書き込みます。それらは[`klog`](https://github.com/kubernetes/klog)というロギングライブラリを使用します。これらのコンポーネントのロギングの重大性に関する規則は、[development docs on logging](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)に記載されています。
|
||||
|
||||
コンテナログと同様に、`/var/log`ディレクトリ内のシステムコンポーネントログはローテーションする必要があります。`kube-up.sh`スクリプトによって生成されたKubernetesクラスターでは、これらのログは、`logrotate`ツールによって毎日、またはサイズが100MBを超えた時にローテーションされるように設定されています。
|
||||
|
||||
## クラスターレベルロギングのアーキテクチャ {#cluster-level-logging-architectures}
|
||||
|
||||
Kubernetesはクラスターレベルロギングのネイティブソリューションを提供していませんが、検討可能な一般的なアプローチがいくつかあります。ここにいくつかのオプションを示します:
|
||||
|
||||
* 全てのノードで実行されるノードレベルのロギングエージェントを使用します。
|
||||
* アプリケーションのPodにログインするための専用のサイドカーコンテナを含めます。
|
||||
* アプリケーション内からバックエンドに直接ログを送信します。
|
||||
|
||||
### ノードロギングエージェントの使用 {#using-a-node-logging-agent}
|
||||
|
||||
|
||||
|
||||
各ノードに _ノードレベルのロギングエージェント_ を含めることで、クラスターレベルロギングを実装できます。ロギングエージェントは、ログを公開したり、ログをバックエンドに送信したりする専用のツールです。通常、ロギングエージェントは、そのノード上の全てのアプリケーションコンテナからのログファイルを含むディレクトリにアクセスできるコンテナです。
|
||||
|
||||
ロギングエージェントは全てのノードで実行する必要があるため、エージェントを`DaemonSet`として実行することをおすすめします。
|
||||
|
||||
ノードレベルのロギングは、ノードごとに1つのエージェントのみを作成し、ノードで実行されているアプリケーションに変更を加える必要はありません。
|
||||
|
||||
コンテナはstdoutとstderrに書き込みますが、合意された形式はありません。ノードレベルのエージェントはこれらのログを収集し、集約のために転送します。
|
||||
|
||||
### ロギングエージェントでサイドカーコンテナを使用する {#sidecar-container-with-logging-agent}
|
||||
|
||||
サイドカーコンテナは、次のいずれかの方法で使用できます:
|
||||
|
||||
* サイドカーコンテナは、アプリケーションログを自身の`stdout`にストリーミングします。
|
||||
* サイドカーコンテナは、アプリケーションコンテナからログを取得するように設定されたロギングエージェントを実行します。
|
||||
|
||||
#### ストリーミングサイドカーコンテナ {#streaming-sidecar-container}
|
||||
|
||||
|
||||
|
||||
サイドカーコンテナに自身の`stdout`や`stderr`ストリームへの書き込みを行わせることで、各ノードですでに実行されているkubeletとロギングエージェントを利用できます。サイドカーコンテナは、ファイル、ソケット、またはjournaldからログを読み取ります。各サイドカーコンテナは、ログを自身の`stdout`または`stderr`ストリームに出力します。
|
||||
|
||||
このアプローチにより、`stdout`または`stderr`への書き込みのサポートが不足している場合も含め、アプリケーションのさまざまな部分からいくつかのログストリームを分離できます。ログのリダイレクトの背後にあるロジックは最小限であるため、大きなオーバーヘッドにはなりません。さらに、`stdout`と`stderr`はkubeletによって処理されるため、`kubectl logs`のような組み込みツールを使用できます。
|
||||
|
||||
たとえば、Podは単一のコンテナを実行し、コンテナは2つの異なる形式を使用して2つの異なるログファイルに書き込みます。Podの構成ファイルは次のとおりです:
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
|
||||
|
||||
両方のコンポーネントをコンテナの`stdout`ストリームにリダイレクトできたとしても、異なる形式のログエントリを同じログストリームに書き込むことはおすすめしません。代わりに、2つのサイドカーコンテナを作成できます。各サイドカーコンテナは、共有ボリュームから特定のログファイルを追跡し、ログを自身の`stdout`ストリームにリダイレクトできます。
|
||||
|
||||
2つのサイドカーコンテナを持つPodの構成ファイルは次のとおりです:
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
|
||||
|
||||
これで、このPodを実行するときに、次のコマンドを実行して、各ログストリームに個別にアクセスできます:
|
||||
|
||||
```shell
|
||||
kubectl logs counter count-log-1
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```console
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
...
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl logs counter count-log-2
|
||||
```
|
||||
|
||||
出力は次のようになります:
|
||||
|
||||
```console
|
||||
Mon Jan 1 00:00:00 UTC 2001 INFO 0
|
||||
Mon Jan 1 00:00:01 UTC 2001 INFO 1
|
||||
Mon Jan 1 00:00:02 UTC 2001 INFO 2
|
||||
...
|
||||
```
|
||||
|
||||
クラスターにインストールされているノードレベルのエージェントは、それ以上の設定を行わなくても、これらのログストリームを自動的に取得します。必要があれば、ソースコンテナに応じてログをパースするようにエージェントを構成できます。
|
||||
|
||||
CPUとメモリーの使用量が少ない(CPUの場合は数ミリコアのオーダー、メモリーの場合は数メガバイトのオーダー)にも関わらず、ログをファイルに書き込んでから`stdout`にストリーミングすると、ディスクの使用量が2倍になる可能性があることに注意してください。単一のファイルに書き込むアプリケーションがある場合は、ストリーミングサイドカーコンテナアプローチを実装するのではなく、`/dev/stdout`を宛先として設定することをおすすめします。
|
||||
|
||||
サイドカーコンテナを使用して、アプリケーション自体ではローテーションできないログファイルをローテーションすることもできます。このアプローチの例は、`logrotate`を定期的に実行する小さなコンテナです。しかし、`stdout`と`stderr`を直接使い、ローテーションと保持のポリシーをkubeletに任せることをおすすめします。
|
||||
|
||||
#### ロギングエージェントを使用したサイドカーコンテナ {#sidecar-container-with-a-logging-agent}
|
||||
|
||||
|
||||
|
||||
ノードレベルロギングのエージェントが、あなたの状況に必要なだけの柔軟性を備えていない場合は、アプリケーションで実行するように特別に構成した別のロギングエージェントを使用してサイドカーコンテナを作成できます。
|
||||
|
||||
{{< note >}}
|
||||
サイドカーコンテナでロギングエージェントを使用すると、大量のリソースが消費される可能性があります。さらに、これらのログはkubeletによって制御されていないため、`kubectl logs`を使用してこれらのログにアクセスすることができません。
|
||||
{{< /note >}}
|
||||
|
||||
ロギングエージェントを使用したサイドカーコンテナを実装するために使用できる、2つの構成ファイルを次に示します。最初のファイルには、fluentdを設定するための[`ConfigMap`](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)が含まれています。
|
||||
|
||||
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
|
||||
|
||||
{{< note >}}
|
||||
fluentdの構成については、[fluentd documentation](https://docs.fluentd.org/)を参照してください。
|
||||
{{< /note >}}
|
||||
|
||||
2番目のファイルは、fluentdを実行しているサイドカーコンテナを持つPodを示しています。Podは、fluentdが構成データを取得できるボリュームをマウントします。
|
||||
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-agent-sidecar.yaml" >}}
|
||||
|
||||
サンプル構成では、fluentdを任意のロギングエージェントに置き換えて、アプリケーションコンテナ内の任意のソースから読み取ることができます。
|
||||
|
||||
### アプリケーションから直接ログを公開する {#exposing-logs-directly-from-the-application}
|
||||
|
||||
|
||||
|
||||
すべてのアプリケーションから直接ログを公開または送信するクラスターロギングは、Kubernetesのスコープ外です。
|
||||
|
|
@ -10,14 +10,29 @@ weight: 30
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
KubernetesのSecretはパスワード、OAuthトークン、SSHキーのような機密情報を保存し、管理できるようにします。
|
||||
Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。
|
||||
詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。
|
||||
|
||||
Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。
|
||||
他の方法としては、そのような情報はPodの定義やイメージに含めることができます。
|
||||
ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。
|
||||
Secretとは、パスワードやトークン、キーなどの少量の機密データを含むオブジェクトのことです。
|
||||
このような情報は、Secretを用いないと{{< glossary_tooltip term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載することになってしまうかもしれません。
|
||||
Secretを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。
|
||||
|
||||
なぜなら、Secretは、それを使用するPodとは独立して作成することができ、
|
||||
Podの作成、閲覧、編集といったワークフローの中でSecret(およびそのデータ)が漏洩する危険性が低くなるためです。
|
||||
また、Kubernetesやクラスター内で動作するアプリケーションは、不揮発性ストレージに機密データを書き込まないようにするなど、Secretで追加の予防措置を取ることができます。
|
||||
|
||||
Secretsは、{{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}に似ていますが、機密データを保持するために用います。
|
||||
|
||||
|
||||
{{< caution >}}
|
||||
KubernetesのSecretは、デフォルトでは、APIサーバーの基礎となるデータストア(etcd)に暗号化されずに保存されます。APIにアクセスできる人は誰でもSecretを取得または変更でき、etcdにアクセスできる人も同様です。
|
||||
さらに、名前空間でPodを作成する権限を持つ人は、そのアクセスを使用して、その名前空間のあらゆるSecretを読むことができます。これには、Deploymentを作成する能力などの間接的なアクセスも含まれます。
|
||||
|
||||
Secretsを安全に使用するには、以下の手順を推奨します。
|
||||
|
||||
1. Secretsを[安全に暗号化する](/docs/tasks/administer-cluster/encrypt-data/)
|
||||
2. Secretsのデータの読み取りを制限する[RBACルール](/docs/reference/access-authn-authz/authorization/)の有効化または設定
|
||||
3. 適切な場合には、RBACなどのメカニズムを使用して、どの原則が新しいSecretの作成や既存のSecretの置き換えを許可されるかを制限します。
|
||||
|
||||
{{< /caution >}}
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
@ -30,6 +45,7 @@ PodがSecretを使う方法は3種類あります。
|
|||
- [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する
|
||||
- Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する
|
||||
|
||||
KubernetesのコントロールプレーンでもSecretsは使われています。例えば、[bootstrap token Secrets](#bootstrap-token-secrets)は、ノード登録を自動化するための仕組みです。
|
||||
|
||||
Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
|
||||
シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。
|
||||
|
|
@ -145,7 +161,8 @@ Docker configファイルがない場合、または`kubectl`を使用してDock
|
|||
kubectl create secret docker-registry secret-tiger-docker \
|
||||
--docker-username=tiger \
|
||||
--docker-password=pass113 \
|
||||
--docker-email=tiger@acme.com
|
||||
--docker-email=tiger@acme.com \
|
||||
--docker-server=my-registry.example:5000
|
||||
```
|
||||
|
||||
このコマンドは、`kubernetes.io/dockerconfigjson`型のSecretを作成します。
|
||||
|
|
@ -153,15 +170,21 @@ kubectl create secret docker-registry secret-tiger-docker \
|
|||
|
||||
```json
|
||||
{
|
||||
"auths": {
|
||||
"https://index.docker.io/v1/": {
|
||||
"username": "tiger",
|
||||
"password": "pass113",
|
||||
"email": "tiger@acme.com",
|
||||
"auth": "dGlnZXI6cGFzczExMw=="
|
||||
}
|
||||
}
|
||||
"apiVersion": "v1",
|
||||
"data": {
|
||||
".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ=="
|
||||
},
|
||||
"kind": "Secret",
|
||||
"metadata": {
|
||||
"creationTimestamp": "2021-07-01T07:30:59Z",
|
||||
"name": "secret-tiger-docker",
|
||||
"namespace": "default",
|
||||
"resourceVersion": "566718",
|
||||
"uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca"
|
||||
},
|
||||
"type": "kubernetes.io/dockerconfigjson"
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Basic authentication Secret
|
||||
|
|
@ -1062,3 +1085,4 @@ Podに複数のコンテナが含まれることもあります。しかし、Po
|
|||
- [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ
|
||||
- [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ
|
||||
- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ
|
||||
- [SecretのAPIリファレンス](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)を読む
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Kubernetesのスケジューラー
|
||||
content_type: concept
|
||||
weight: 60
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -62,9 +62,9 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適
|
|||
* [Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を参照してください。
|
||||
* kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。
|
||||
* [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。
|
||||
* [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。
|
||||
* [Podのオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。
|
||||
* [トポロジーの管理ポリシー](/ja/docs/tasks/administer-cluster/topology-manager/)について学んでください。
|
||||
* [Podのオーバーヘッド](/ja/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。
|
||||
* ボリュームを使用するPodのスケジューリングについて以下で学んでください。
|
||||
* [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode)
|
||||
* [ストレージ容量の追跡](/ja//ja/docs/concepts/storage/storage-capacity/)
|
||||
* [ストレージ容量の追跡](/ja/docs/concepts/storage/storage-capacity/)
|
||||
* [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,197 @@
|
|||
---
|
||||
title: 拡張リソースのリソースビンパッキング
|
||||
content_type: concept
|
||||
weight: 80
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
|
||||
|
||||
kube-schedulerでは、優先度関数`RequestedToCapacityRatioResourceAllocation`を使用した、
|
||||
拡張リソースを含むリソースのビンパッキングを有効化できます。優先度関数はそれぞれのニーズに応じて、kube-schedulerを微調整するために使用できます。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## `RequestedToCapacityRatioResourceAllocation`を使用したビンパッキングの有効化
|
||||
|
||||
Kubernetesでは、キャパシティー比率への要求に基づいたNodeのスコアリングをするために、各リソースの重みと共にリソースを指定することができます。これにより、ユーザーは適切なパラメーターを使用することで拡張リソースをビンパックすることができ、大規模クラスターにおける希少なリソースを有効活用できるようになります。優先度関数`RequestedToCapacityRatioResourceAllocation`の動作は`RequestedToCapacityRatioArgs`と呼ばれる設定オプションによって変わります。この引数は`shape`と`resources`パラメーターによって構成されます。`shape`パラメーターは`utilization`と`score`の値に基づいて、最も要求が多い場合か最も要求が少ない場合の関数をチューニングできます。`resources`パラメーターは、スコアリングの際に考慮されるリソース名の`name`と、各リソースの重みを指定する`weight`で構成されます。
|
||||
|
||||
以下は、拡張リソース`intel.com/foo`と`intel.com/bar`のビンパッキングに`requestedToCapacityRatioArguments`を設定する例になります。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta1
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
# ...
|
||||
pluginConfig:
|
||||
- name: RequestedToCapacityRatio
|
||||
args:
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 10
|
||||
- utilization: 100
|
||||
score: 0
|
||||
resources:
|
||||
- name: intel.com/foo
|
||||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 5
|
||||
```
|
||||
スケジューラーには、kube-schedulerフラグ`--config=/path/to/config/file`を使用して`KubeSchedulerConfiguration`のファイルを指定することで渡すことができます。
|
||||
|
||||
**この機能はデフォルトで無効化されています**
|
||||
|
||||
### 優先度関数のチューニング
|
||||
|
||||
`shape`は`RequestedToCapacityRatioPriority`関数の動作を指定するために使用されます。
|
||||
|
||||
```yaml
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 0
|
||||
- utilization: 100
|
||||
score: 10
|
||||
```
|
||||
|
||||
上記の引数は、`utilization`が0%の場合は0、`utilization`が100%の場合は10という`score`をNodeに与え、ビンパッキングの動作を有効にしています。最小要求を有効にするには、次のようにスコアを反転させる必要があります。
|
||||
|
||||
```yaml
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 10
|
||||
- utilization: 100
|
||||
score: 0
|
||||
```
|
||||
|
||||
`resources`はオプションパラメーターで、デフォルトでは以下の通りです。
|
||||
|
||||
``` yaml
|
||||
resources:
|
||||
- name: cpu
|
||||
weight: 1
|
||||
- name: memory
|
||||
weight: 1
|
||||
```
|
||||
|
||||
|
||||
以下のように拡張リソースの追加に利用できます。
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
- name: intel.com/foo
|
||||
weight: 5
|
||||
- name: cpu
|
||||
weight: 3
|
||||
- name: memory
|
||||
weight: 1
|
||||
```
|
||||
|
||||
`weight`はオプションパラメーターで、指定されてない場合1が設定されます。また、マイナスの値は設定できません。
|
||||
|
||||
### キャパシティ割り当てのためのNodeスコアリング
|
||||
|
||||
このセクションは、本機能の内部詳細について理解したい方を対象としています。以下は、与えられた値に対してNodeのスコアがどのように計算されるかの例です。
|
||||
|
||||
要求されたリソース:
|
||||
|
||||
```
|
||||
intel.com/foo : 2
|
||||
memory: 256MB
|
||||
cpu: 2
|
||||
```
|
||||
|
||||
リソースの重み:
|
||||
|
||||
```
|
||||
intel.com/foo : 5
|
||||
memory: 1
|
||||
cpu: 3
|
||||
```
|
||||
|
||||
`shape`の値 {{0, 0}, {100, 10}}
|
||||
|
||||
Node1のスペック:
|
||||
|
||||
```
|
||||
Available:
|
||||
intel.com/foo: 4
|
||||
memory: 1 GB
|
||||
cpu: 8
|
||||
|
||||
Used:
|
||||
intel.com/foo: 1
|
||||
memory: 256MB
|
||||
cpu: 1
|
||||
```
|
||||
|
||||
Nodeのスコア:
|
||||
|
||||
```
|
||||
intel.com/foo = resourceScoringFunction((2+1),4)
|
||||
= (100 - ((4-3)*100/4)
|
||||
= (100 - 25)
|
||||
= 75 # requested + used = 75% * available
|
||||
= rawScoringFunction(75)
|
||||
= 7 # floor(75/10)
|
||||
|
||||
memory = resourceScoringFunction((256+256),1024)
|
||||
= (100 -((1024-512)*100/1024))
|
||||
= 50 # requested + used = 50% * available
|
||||
= rawScoringFunction(50)
|
||||
= 5 # floor(50/10)
|
||||
|
||||
cpu = resourceScoringFunction((2+1),8)
|
||||
= (100 -((8-3)*100/8))
|
||||
= 37.5 # requested + used = 37.5% * available
|
||||
= rawScoringFunction(37.5)
|
||||
= 3 # floor(37.5/10)
|
||||
|
||||
NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
|
||||
= 5
|
||||
```
|
||||
|
||||
Node2のスペック:
|
||||
|
||||
```
|
||||
Available:
|
||||
intel.com/foo: 8
|
||||
memory: 1GB
|
||||
cpu: 8
|
||||
Used:
|
||||
intel.com/foo: 2
|
||||
memory: 512MB
|
||||
cpu: 6
|
||||
```
|
||||
|
||||
Nodeのスコア:
|
||||
|
||||
```
|
||||
intel.com/foo = resourceScoringFunction((2+2),8)
|
||||
= (100 - ((8-4)*100/8)
|
||||
= (100 - 50)
|
||||
= 50
|
||||
= rawScoringFunction(50)
|
||||
= 5
|
||||
|
||||
memory = resourceScoringFunction((256+512),1024)
|
||||
= (100 -((1024-768)*100/1024))
|
||||
= 75
|
||||
= rawScoringFunction(75)
|
||||
= 7
|
||||
|
||||
cpu = resourceScoringFunction((2+6),8)
|
||||
= (100 -((8-8)*100/8))
|
||||
= 100
|
||||
= rawScoringFunction(100)
|
||||
= 10
|
||||
|
||||
NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
|
||||
= 7
|
||||
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [スケジューリングフレームワーク](/ja/docs/concepts/scheduling-eviction/scheduling-framework/)について更に読む
|
||||
- [スケジューラーの設定](/docs/reference/scheduling/config/)について更に読む
|
||||
|
|
@ -49,6 +49,25 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
<td><strong>項目</strong></td>
|
||||
<td><strong>ポリシー</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ホストのプロセス</td>
|
||||
<td>
|
||||
<p>Windows Podは、Windowsノードへの特権的なアクセスを可能にする<a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">HostProcess</a>コンテナ</a>を実行する機能を提供します。ベースラインポリシーでは、ホストへの特権的なアクセスは禁止されています。HostProcess Podは、Kubernetes v1.22時点ではアルファ版の機能です。
|
||||
ホストのネームスペースの共有は無効化すべきです。</p>
|
||||
<p><strong>制限されるフィールド</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.securityContext.windowsOptions.hostProcess</code></li>
|
||||
<li><code>spec.containers[*].securityContext.windowsOptions.hostProcess</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.windowsOptions.hostProcess</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess</code></li>
|
||||
</ul>
|
||||
<p><strong>認められる値</strong></p>
|
||||
<ul>
|
||||
<li>Undefined/nil</li>
|
||||
<li><code>false</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ホストのネームスペース</td>
|
||||
<td>
|
||||
|
|
@ -57,7 +76,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
spec.hostNetwork<br>
|
||||
spec.hostPID<br>
|
||||
spec.hostIPC<br>
|
||||
<br><b>認められる値:</b> false<br>
|
||||
<br><b>認められる値:</b> false, Undefined/nil<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -67,6 +86,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
<br><b>制限されるフィールド:</b><br>
|
||||
spec.containers[*].securityContext.privileged<br>
|
||||
spec.initContainers[*].securityContext.privileged<br>
|
||||
spec.ephemeralContainers[*].securityContext.privileged<br>
|
||||
<br><b>認められる値:</b> false, undefined/nil<br>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -77,7 +97,22 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
<br><b>制限されるフィールド:</b><br>
|
||||
spec.containers[*].securityContext.capabilities.add<br>
|
||||
spec.initContainers[*].securityContext.capabilities.add<br>
|
||||
<br><b>認められる値:</b> 空 (または既知のリストに限定)<br>
|
||||
spec.ephemeralContainers[*].securityContext.capabilities.add<br>
|
||||
<br><b>認められる値:</b>
|
||||
Undefined/nil<br>
|
||||
AUDIT_WRITE<br>
|
||||
CHOWN<br>
|
||||
DAC_OVERRIDE<br>
|
||||
FOWNER<br>
|
||||
FSETID<br>
|
||||
KILL<br>
|
||||
MKNOD<br>
|
||||
NET_BIND_SERVICE<br>
|
||||
SETFCAP<br>
|
||||
SETGID<br>
|
||||
SETPCAP<br>
|
||||
SETUID<br>
|
||||
SYS_CHROOT<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -96,16 +131,17 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
<br><b>制限されるフィールド:</b><br>
|
||||
spec.containers[*].ports[*].hostPort<br>
|
||||
spec.initContainers[*].ports[*].hostPort<br>
|
||||
spec.ephemeralContainers[*].ports[*].hostPort<br>
|
||||
<br><b>認められる値:</b> 0, undefined (または既知のリストに限定)<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>AppArmor <em>(任意)</em></td>
|
||||
<td>AppArmor<em>(任意)</em></td>
|
||||
<td>
|
||||
サポートされるホストでは、AppArmorの'runtime/default'プロファイルがデフォルトで適用されます。デフォルトのポリシーはポリシーの上書きや無効化を防ぎ、許可されたポリシーのセットを上書きできないよう制限すべきです。<br>
|
||||
<br><b>制限されるフィールド:</b><br>
|
||||
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
|
||||
<br><b>認められる値:</b> 'runtime/default', undefined<br>
|
||||
<br><b>認められる値:</b> 'runtime/default', undefined, localhost/*<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -116,7 +152,24 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
spec.securityContext.seLinuxOptions<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions<br>
|
||||
<br><b>認められる値:</b> undefined/nil<br>
|
||||
spec.ephemeralContainers[*].securityContext.seLinuxOptions.type<br>
|
||||
<br><b>認められる値:</b>undefined/nil<br>
|
||||
Undefined/""<br>
|
||||
container_t<br>
|
||||
container_init_t<br>
|
||||
container_kvm_t<br>
|
||||
<hr />
|
||||
<br><b>制限されるフィールド:</b><br>
|
||||
spec.securityContext.seLinuxOptions.user<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions.user<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions.user<br>
|
||||
spec.ephemeralContainers[*].securityContext.seLinuxOptions.user<br>
|
||||
spec.securityContext.seLinuxOptions.role<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions.role<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions.role<br>
|
||||
spec.ephemeralContainers[*].securityContext.seLinuxOptions.role<br>
|
||||
<br><b>認められる値:</b>undefined/nil<br>
|
||||
Undefined/""
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -126,9 +179,29 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
<br><b>制限されるフィールド:</b><br>
|
||||
spec.containers[*].securityContext.procMount<br>
|
||||
spec.initContainers[*].securityContext.procMount<br>
|
||||
<br><b>認められる値:</b> undefined/nil, 'Default'<br>
|
||||
spec.ephemeralContainers[*].securityContext.procMount<br>
|
||||
<br><b>認められる値:</b>undefined/nil, 'Default'<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Seccomp</td>
|
||||
<td>
|
||||
<p>Seccompプロファイルを明示的に<code>Unconfined</code>に設定することはできません。</p>
|
||||
<p><strong>Restricted Fields</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.securityContext.seccompProfile.type</code></li>
|
||||
<li><code>spec.containers[*].securityContext.seccompProfile.type</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.seccompProfile.type</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.seccompProfile.type</code></li>
|
||||
</ul>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li>Undefined/nil</li>
|
||||
<li><code>RuntimeDefault</code></li>
|
||||
<li><code>Localhost</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Sysctl</td>
|
||||
<td>
|
||||
|
|
@ -169,27 +242,27 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
<td>
|
||||
HostPathボリュームの制限に加え、制限プロファイルではコアでない種類のボリュームの利用をPersistentVolumeにより定義されたものに限定します。<br>
|
||||
<br><b>制限されるフィールド:</b><br>
|
||||
spec.volumes[*].hostPath<br>
|
||||
spec.volumes[*].gcePersistentDisk<br>
|
||||
spec.volumes[*].awsElasticBlockStore<br>
|
||||
spec.volumes[*].gitRepo<br>
|
||||
spec.volumes[*].nfs<br>
|
||||
spec.volumes[*].iscsi<br>
|
||||
spec.volumes[*].glusterfs<br>
|
||||
spec.volumes[*].rbd<br>
|
||||
spec.volumes[*].flexVolume<br>
|
||||
spec.volumes[*].cinder<br>
|
||||
spec.volumes[*].cephFS<br>
|
||||
spec.volumes[*].flocker<br>
|
||||
spec.volumes[*].fc<br>
|
||||
spec.volumes[*].azureFile<br>
|
||||
spec.volumes[*].vsphereVolume<br>
|
||||
spec.volumes[*].quobyte<br>
|
||||
spec.volumes[*].azureDisk<br>
|
||||
spec.volumes[*].portworxVolume<br>
|
||||
spec.volumes[*].scaleIO<br>
|
||||
spec.volumes[*].storageos<br>
|
||||
spec.volumes[*].csi<br>
|
||||
spec.volumes[*].hostPath<br>
|
||||
spec.volumes[*].gcePersistentDisk<br>
|
||||
spec.volumes[*].awsElasticBlockStore<br>
|
||||
spec.volumes[*].gitRepo<br>
|
||||
spec.volumes[*].nfs<br>
|
||||
spec.volumes[*].iscsi<br>
|
||||
spec.volumes[*].glusterfs<br>
|
||||
spec.volumes[*].rbd<br>
|
||||
spec.volumes[*].flexVolume<br>
|
||||
spec.volumes[*].cinder<br>
|
||||
spec.volumes[*].cephfs<br>
|
||||
spec.volumes[*].flocker<br>
|
||||
spec.volumes[*].fc<br>
|
||||
spec.volumes[*].azureFile<br>
|
||||
spec.volumes[*].vsphereVolume<br>
|
||||
spec.volumes[*].quobyte<br>
|
||||
spec.volumes[*].azureDisk<br>
|
||||
spec.volumes[*].portworxVolume<br>
|
||||
spec.volumes[*].scaleIO<br>
|
||||
spec.volumes[*].storageos<br>
|
||||
spec.volumes[*].photonPersistentDisk<br>
|
||||
<br><b>認められる値:</b> undefined/nil<br>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -200,6 +273,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
<br><b>制限されるフィールド:</b><br>
|
||||
spec.containers[*].securityContext.allowPrivilegeEscalation<br>
|
||||
spec.initContainers[*].securityContext.allowPrivilegeEscalation<br>
|
||||
spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation<br>
|
||||
<br><b>認められる値:</b> false<br>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -211,6 +285,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
spec.securityContext.runAsNonRoot<br>
|
||||
spec.containers[*].securityContext.runAsNonRoot<br>
|
||||
spec.initContainers[*].securityContext.runAsNonRoot<br>
|
||||
spec.ephemeralContainers[*].securityContext.runAsNonRoot<br>
|
||||
<br><b>認められる値:</b> true<br>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -242,6 +317,36 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
undefined / nil<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="white-space: nowrap">Capabilities (v1.22+)</td>
|
||||
<td>
|
||||
<p>
|
||||
コンテナはすべてのケイパビリティを削除する必要があり、<code>NET_BIND_SERVICE</code>ケイパビリティを追加することだけが許可されています。
|
||||
</p>
|
||||
<p><strong>Restricted Fields</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.containers[*].securityContext.capabilities.drop</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.capabilities.drop</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.capabilities.drop</code></li>
|
||||
</ul>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li>Any list of capabilities that includes <code>ALL</code></li>
|
||||
</ul>
|
||||
<hr />
|
||||
<p><strong>Restricted Fields</strong></p>
|
||||
<ul>
|
||||
<li><code>spec.containers[*].securityContext.capabilities.add</code></li>
|
||||
<li><code>spec.initContainers[*].securityContext.capabilities.add</code></li>
|
||||
<li><code>spec.ephemeralContainers[*].securityContext.capabilities.add</code></li>
|
||||
</ul>
|
||||
<p><strong>Allowed Values</strong></p>
|
||||
<ul>
|
||||
<li>Undefined/nil</li>
|
||||
<li><code>NET_BIND_SERVICE</code></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
|
@ -284,6 +389,14 @@ Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使
|
|||
特に、PodのSecurityContextフィールドは[Windows環境では効果がありません](/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext)。
|
||||
したがって、現段階では標準化されたセキュリティポリシーは存在しません。
|
||||
|
||||
Windows Podに制限付きプロファイルを適用すると、実行時にPodに影響が出る場合があります。
|
||||
制限付きプロファイルでは、Linux固有の制限(seccompプロファイルや特権昇格の不許可など)を適用する必要があります。
|
||||
kubeletおよび/またはそのコンテナランタイムがこれらのLinux固有の値を無視した場合、Windows Podは制限付きプロファイル内で正常に動作します。
|
||||
ただし、強制力がないため、Windows コンテナを使用するPodについては、ベースラインプロファイルと比較して追加の制限はありません。
|
||||
|
||||
HostProcess Podを作成するためのHostProcessフラグの使用は、特権的なポリシーに沿ってのみ行われるべきです。
|
||||
Windows HostProcess Podの作成は、ベースラインおよび制限されたポリシーの下でブロックされているため、いかなるHostProcess Podも特権的であるとみなされるべきです。
|
||||
|
||||
### サンドボックス化されたPodはどのように扱えばよいでしょうか?
|
||||
|
||||
現在のところ、Podがサンドボックス化されていると見なされるかどうかを制御できるAPI標準はありません。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,101 @@
|
|||
---
|
||||
title: トポロジーを意識したヒント
|
||||
content_type: concept
|
||||
weight: 45
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
|
||||
|
||||
*Topology Aware Hint*は、クライアントがendpointをどのように使用するかについての提案を含めることにより、トポロジーを考慮したルーティングを可能にします。このアプローチでは、EndpointSliceおよび/またはEndpointオブジェクトの消費者が、これらのネットワークエンドポイントへのトラフィックを、それが発生した場所の近くにルーティングできるように、メタデータを追加します。
|
||||
|
||||
たとえば、局所的にトラフィックをルーティングすることで、コストを削減したり、ネットワークパフォーマンスを向上させたりできます。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 動機
|
||||
|
||||
Kubernetesクラスターは、マルチゾーン環境で展開されることが多くなっています。
|
||||
*Topology Aware Hint*は、トラフィックを発信元のゾーン内に留めておくのに役立つメカニズムを提供します。このコンセプトは、一般に「Topology Aware Routing」と呼ばれています。EndpointSliceコントローラーは{{< glossary_tooltip term_id="Service" >}}のendpointを計算する際に、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに値を入力します。
|
||||
EndpointSliceコントローラーは、各endpointのトポロジー(リージョンとゾーン)を考慮し、ゾーンに割り当てるためのヒントフィールドに入力します。
|
||||
{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}のようなクラスターコンポーネントは、次にこれらのヒントを消費し、それらを使用してトラフィックがルーティングされる方法に影響を与えることが可能です(トポロジー的に近いendpointを優先します)。
|
||||
|
||||
|
||||
## Topology Aware Hintを使う
|
||||
|
||||
`service.kubernetes.io/topology-aware-hints`アノテーションを`auto`に設定すると、サービスに対してTopology Aware Hintを有効にすることができます。これはEndpointSliceコントローラーが安全と判断した場合に、トポロジーヒントを設定するように指示します。
|
||||
重要なのは、これはヒントが常に設定されることを保証するものではないことです。
|
||||
|
||||
## 使い方 {#implementation}
|
||||
|
||||
この機能を有効にする機能は、EndpointSliceコントローラーとkube-proxyの2つのコンポーネントに分かれています。このセクションでは、各コンポーネントがこの機能をどのように実装しているか、高レベルの概要を説明します。
|
||||
|
||||
### EndpointSliceコントローラー {#implementation-control-plane}
|
||||
|
||||
この機能が有効な場合、EndpointSliceコントローラーはEndpointSliceにヒントを設定する役割を担います。
|
||||
コントローラーは、各ゾーンに比例した量のendpointを割り当てます。
|
||||
この割合は、そのゾーンで実行されているノードの[割り当て可能な](/ja/docs/task/administer-cluster/reserve-compute-resources/#node-allocatable)CPUコアを基に決定されます。
|
||||
|
||||
たとえば、あるゾーンに2つのCPUコアがあり、別のゾーンに1つのCPUコアしかない場合、コントローラーは2つのCPUコアを持つゾーンに2倍のendpointを割り当てます。
|
||||
|
||||
次の例は、ヒントが入力されたときのEndpointSliceの様子を示しています。
|
||||
|
||||
```yaml
|
||||
apiVersion: discovery.k8s.io/v1
|
||||
kind: EndpointSlice
|
||||
metadata:
|
||||
name: example-hints
|
||||
labels:
|
||||
kubernetes.io/service-name: example-svc
|
||||
addressType: IPv4
|
||||
ports:
|
||||
- name: http
|
||||
protocol: TCP
|
||||
port: 80
|
||||
endpoints:
|
||||
- addresses:
|
||||
- "10.1.2.3"
|
||||
conditions:
|
||||
ready: true
|
||||
hostname: pod-1
|
||||
zone: zone-a
|
||||
hints:
|
||||
forZones:
|
||||
- name: "zone-a"
|
||||
```
|
||||
|
||||
### kube-proxy {#implementation-kube-proxy}
|
||||
|
||||
kube-proxyは、EndpointSliceコントローラーによって設定されたヒントに基づいて、ルーティング先のendpointをフィルター処理します。ほとんどの場合、これはkube-proxyが同じゾーン内のendpointにトラフィックをルーティングできることを意味します。コントローラーが別のゾーンからendpointを割り当てて、ゾーン間でendpointがより均等に分散されるようにする場合があります。これにより、一部のトラフィックが他のゾーンにルーティングされます。
|
||||
|
||||
## セーフガード
|
||||
|
||||
各ノードのKubernetesコントロールプレーンとkube-proxyは、Topology Aware Hintを使用する前に、いくつかのセーフガードルールを適用します。これらがチェックアウトされない場合、kube-proxyは、ゾーンに関係なく、クラスター内のどこからでもendpointを選択します。
|
||||
|
||||
1. **endpointの数が不十分です:** クラスター内のゾーンよりもendpointが少ない場合、コントローラーはヒントを割り当てません。
|
||||
|
||||
2. **バランスの取れた割り当てを実現できません:** 場合によっては、ゾーン間でendpointのバランスの取れた割り当てを実現できないことがあります。たとえば、ゾーンaがゾーンbの2倍の大きさであるが、endpointが2つしかない場合、ゾーンaに割り当てられたendpointはゾーンbの2倍のトラフィックを受信する可能性があります。この「予想される過負荷」値が各ゾーンの許容しきい値を下回ることができない場合、コントローラーはヒントを割り当てません。重要なことに、これはリアルタイムのフィードバックに基づいていません。それでも、個々のendpointが過負荷になる可能性があります。
|
||||
|
||||
3. **1つ以上のノードの情報が不十分です:** ノードに`topology.kubernetes.io/zone`ラベルがないか、割り当て可能なCPUの値を報告していない場合、コントロールプレーンはtopology-aware endpoint hintsを設定しないため、kube-proxyはendpointをゾーンでフィルタリングしません。
|
||||
|
||||
4. **1つ以上のendpointにゾーンヒントが存在しません:** これが発生すると、kube-proxyはTopology Aware Hintから、またはTopology Aware Hintへの移行が進行中であると見なします。この状態のサービスに対してendpointをフィルタリングすることは危険であるため、kube-proxyはすべてのendpointを使用するようにフォールバックします。
|
||||
|
||||
5. **ゾーンはヒントで表されません:** kube-proxyが、実行中のゾーンをターゲットとするヒントを持つendpointを1つも見つけることができない場合、すべてのゾーンのendpointを使用することになります。これは既存のクラスターに新しいゾーンを追加するときに発生する可能性が最も高くなります。
|
||||
|
||||
## 制約事項
|
||||
|
||||
* Serviceで`externalTrafficPolicy`または`internalTrafficPolicy`が`Local`に設定されている場合、Topology Aware Hintは使用されません。同じServiceではなく、異なるServiceの同じクラスターで両方の機能を使用することができます。
|
||||
|
||||
* このアプローチは、ゾーンのサブセットから発信されるトラフィックの割合が高いサービスではうまく機能しません。代わりに、これは着信トラフィックが各ゾーンのノードの容量にほぼ比例することを前提としています。
|
||||
|
||||
* EndpointSliceコントローラーは、各ゾーンの比率を計算するときに、準備ができていないノードを無視します。ノードの大部分の準備ができていない場合、これは意図しない結果をもたらす可能性があります。
|
||||
|
||||
* EndpointSliceコントローラーは、各ゾーンの比率を計算するデプロイ時に{{< glossary_tooltip text="toleration" term_id="toleration" >}}を考慮しません。サービスをバックアップするPodがクラスター内のノードのサブセットに制限されている場合、これは考慮されません。
|
||||
|
||||
* これはオートスケーリングと相性が悪いかもしれません。例えば、多くのトラフィックが1つのゾーンから発信されている場合、そのゾーンに割り当てられたendpointのみがそのトラフィックを処理することになります。その結果、{{< glossary_tooltip text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}}がこのイベントを拾えなくなったり、新しく追加されたPodが別のゾーンで開始されたりする可能性があります。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む。
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: ReplicaSet
|
||||
id: replica-set
|
||||
date: 2018-04-12
|
||||
full_link: /ja/docs/concepts/workloads/controllers/replicaset/
|
||||
short_description: >
|
||||
ReplicaSetは、指定された数のPodレプリカが一度に動作するように保証します。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
- workload
|
||||
---
|
||||
ReplicaSetは、任意の時点で動作しているレプリカPodの集合を保持します。(保持することを目指します。)
|
||||
|
||||
<!--more-->
|
||||
{{< glossary_tooltip term_id="deployment" >}}などのワークロードオブジェクトは、ReplicaSetの仕様に基づいて、
|
||||
設定された数の{{< glossary_tooltip term_id="pod" text="Pods" >}}がクラスターで稼働することを保証するために、
|
||||
ReplicaSetを使用します。
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Scheduling
|
||||
weight: 70
|
||||
toc-hide: true
|
||||
---
|
||||
|
|
@ -0,0 +1,387 @@
|
|||
---
|
||||
title: スケジューラーの設定
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
|
||||
|
||||
設定ファイルを作成し、そのパスをコマンドライン引数として渡すことで`kube-scheduler`の振る舞いをカスタマイズすることができます。
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!-- body -->
|
||||
|
||||
スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの異なるステージを設定することができます。
|
||||
各ステージは、拡張点に公開されています。プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
|
||||
|
||||
KubeSchedulerConfiguration([`v1beta2`](/docs/reference/config-api/kube-scheduler-config.v1beta2/)か[`v1beta3`](/docs/reference/config-api/kube-scheduler-config.v1beta3/))構造体を使用して、`kube-scheduler --config <filename>`を実行することで、スケジューリングプロファイルを指定することができます。
|
||||
|
||||
最小限の設定は次の通りです。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta2
|
||||
kind: KubeSchedulerConfiguration
|
||||
clientConnection:
|
||||
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
|
||||
```
|
||||
|
||||
## プロファイル
|
||||
|
||||
スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの異なるステージを設定することができます。
|
||||
各ステージは[拡張点](#extension-points)に公開されています。
|
||||
[プラグイン](#scheduling-plugins)をそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。
|
||||
|
||||
単一の`kube-scheduler`インスタンスで[複数のプロファイル](#multiple-profiles)を実行するように設定することも可能です。
|
||||
|
||||
### 拡張点 {#extension-points}
|
||||
|
||||
スケジューリングは一連のステージで行われ、以下の拡張点に公開されています。
|
||||
|
||||
1. `queueSort`: これらのプラグインは、スケジューリングキューにある`pending`状態のPodをソートするための順序付け関数を提供します。同時に有効化できるプラグインは1つだけです。
|
||||
1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。
|
||||
1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、Podの実行不可能なNodeをフィルターするために使用されます。もし全てのNodeがフィルターされてしまった場合、Podはunschedulableとしてマークされます。
|
||||
1. `postFilter`:これらのプラグインは、Podの実行可能なNodeが見つからなかった場合、設定された順序で呼び出されます。もし`postFilter`プラグインのいずれかが、Podを __スケジュール可能__ とマークした場合、残りの`postFilter`プラグインは呼び出されません。
|
||||
1. `preScore`: これは、スコアリング前の作業を行う際に使用できる情報提供のための拡張点です。
|
||||
1. `score`: これらのプラグインはフィルタリングフェーズを通過してきたそれぞれのNodeに対してスコア付けを行います。その後スケジューラーは、最も高い重み付きスコアの合計を持つノードを選択します。
|
||||
1. `reserve`: これは、指定されたPodのためにリソースが予約された際に、プラグインに通知する、情報提供のための拡張点です。また、プラグインは`Reserve`中に失敗した際、または`Reserve`の後に呼び出される`Unreserve`も実装しています。
|
||||
1. `permit`: これらのプラグインではPodのバインディングを拒む、または遅延させることができます。
|
||||
1. `preBind`: これらのプラグインは、Podがバインドされる前に必要な処理を実行できます。
|
||||
1. `bind`: これらのプラグインはPodをNodeにバインドします。`bind`プラグインは順番に呼び出され、1つのプラグインがバインドを完了すると、残りのプラグインはスキップされます。`bind`プラグインは少なくとも1つは必要です。
|
||||
1. `postBind`: これは、Podがバインドされた後に呼び出される情報提供のための拡張点です。
|
||||
1. `multiPoint`: このフィールドは設定のみ可能で、プラグインが適用されるすべての拡張点に対して同時に有効化または無効化することができます。
|
||||
|
||||
次の例のように、それぞれの拡張点に対して、特定の[デフォルトプラグイン](#scheduling-plugins)を無効化、または自作のプラグインを有効化することができます。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta2
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- plugins:
|
||||
score:
|
||||
disabled:
|
||||
- name: PodTopologySpread
|
||||
enabled:
|
||||
- name: MyCustomPluginA
|
||||
weight: 2
|
||||
- name: MyCustomPluginB
|
||||
weight: 1
|
||||
```
|
||||
|
||||
`disabled`配列の`name`フィールドに`*`を使用することで、その拡張点の全てのデフォルトプラグインを無効化できます。また、必要に応じてプラグインの順序を入れ替える場合にも使用されます。
|
||||
|
||||
### Scheduling plugins {#scheduling-plugins}
|
||||
|
||||
以下のプラグインはデフォルトで有効化されており、1つ以上の拡張点に実装されています。
|
||||
|
||||
- `ImageLocality`:Podが実行するコンテナイメージを既に持っているNodeを優先します。
|
||||
拡張点:`score`
|
||||
- `TaintToleration`:[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を実行します。
|
||||
実装する拡張点:`filter`、`preScore`、`score`
|
||||
- `NodeName`: PodのSpecのNode名が、現在のNodeと一致するかをチェックします。
|
||||
拡張点:`filter`
|
||||
- `NodePorts`:要求されたPodのポートに対して、Nodeが空きポートを持っているかチェックします。
|
||||
拡張点:`preFilter`、`filter`
|
||||
- `NodeAffinity`:[nodeselectors](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)と[Nodeアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)を実行します。
|
||||
拡張点:`filter`、`score`
|
||||
- `PodTopologySpread`:[Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を実行します。
|
||||
拡張点:`preFilter`、`filter`、`preScore`、`score`
|
||||
- `NodeUnschedulable`:`.spec.unschedulable`がtrueに設定されているNodeをフィルタリングします。
|
||||
拡張点:`filter`.
|
||||
- `NodeResourcesFit`:Podが要求しているすべてのリソースがNodeにあるかをチェックします。スコアは3つのストラテジのうちの1つを使用します:`LeastAllocated`(デフォルト)、`MostAllocated`、 と`RequestedToCapacityRatio`
|
||||
拡張点:`preFilter`、`filter`、`score`
|
||||
- `NodeResourcesBalancedAllocation`:Podがスケジュールされた場合に、よりバランスの取れたリソース使用量となるNodeを優先します。
|
||||
拡張点:`score`
|
||||
- `VolumeBinding`:Nodeが、要求された{{< glossary_tooltip text="ボリューム" term_id="volume" >}}を持っている、もしくはバインドしているかチェックします。
|
||||
拡張点:`preFilter`、`filter`、`reserve`、`preBind`、`score`
|
||||
{{< note >}}
|
||||
`score`拡張点は、`VolumeCapacityPriority`機能が有効になっている時に有効化されます。
|
||||
要求されたボリュームに適合する最小のPVを優先的に使用します。
|
||||
{{< /note >}}
|
||||
- `VolumeRestrictions`:Nodeにマウントされたボリュームが、ボリュームプロバイダ固有の制限を満たしているかを確認します。
|
||||
拡張点:`filter`
|
||||
- `VolumeZone`:要求されたボリュームがゾーン要件を満たしているかどうかを確認します。
|
||||
拡張点:`filter`
|
||||
- `NodeVolumeLimits`:NodeのCSIボリューム制限を満たすかどうかをチェックします。
|
||||
拡張点:`filter`
|
||||
- `EBSLimits`:NodeのAWSのEBSボリューム制限を満たすかどうかをチェックします。
|
||||
拡張点:`filter`
|
||||
- `GCEPDLimits`:NodeのGCP-PDボリューム制限を満たすかどうかをチェックします。
|
||||
拡張点:`filter`
|
||||
- `AzureDiskLimits`:NodeのAzureディスクボリューム制限を満たすかどうかをチェックします。
|
||||
拡張点:`filter`
|
||||
- `InterPodAffinity`:[Pod間のaffinityとanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)を実行します。
|
||||
拡張点:`preFilter`、`filter`、`preScore`、`score`
|
||||
- `PrioritySort`:デフォルトの優先順位に基づくソートを提供します。
|
||||
拡張点:`queueSort`.
|
||||
- `DefaultBinder`:デフォルトのバインディングメカニズムを提供します。
|
||||
拡張点:`bind`
|
||||
- `DefaultPreemption`:デフォルトのプリエンプションメカニズムを提供します。
|
||||
拡張点:`postFilter`
|
||||
|
||||
また、コンポーネント設定のAPIにより、以下のプラグインを有効にすることができます。
|
||||
デフォルトでは有効になっていません。
|
||||
|
||||
- `SelectorSpread`:{{< glossary_tooltip text="サービス" term_id="service" >}}と{{< glossary_tooltip text="レプリカセット" term_id="replica-set" >}}、{{< glossary_tooltip text="ステートフルセット" term_id="statefulset" >}}、に属するPodのNode間の拡散を優先します。
|
||||
拡張点:`preScore`、`score`
|
||||
- `CinderLimits`:Nodeが[`OpenStack Cinder`](https://docs.openstack.org/cinder/)ボリューム制限を満たせるかチェックします。
|
||||
拡張点:`filter`
|
||||
|
||||
### 複数のプロファイル {#multiple-profiles}
|
||||
|
||||
`kube-scheduler`は複数のプロファイルを実行するように設定することができます。
|
||||
各プロファイルは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを設定することが可能です。
|
||||
|
||||
以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、もう1つはすべてのスコアリングプラグインを無効にしたものです。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta2
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: default-scheduler
|
||||
- schedulerName: no-scoring-scheduler
|
||||
plugins:
|
||||
preScore:
|
||||
disabled:
|
||||
- name: '*'
|
||||
score:
|
||||
disabled:
|
||||
- name: '*'
|
||||
```
|
||||
|
||||
特定のプロファイルに従ってスケジュールさせたいPodは、その`.spec.schedulerName`に、対応するスケジューラー名を含めることができます。
|
||||
|
||||
デフォルトでは、スケジューラー名`default-scheduler`としてプロファイルが生成されます。
|
||||
このプロファイルは、上記のデフォルトプラグインを含みます。複数のプロファイルを宣言する場合は、それぞれユニークなスケジューラー名にする必要があります。
|
||||
|
||||
もしPodがスケジューラー名を指定しない場合、kube-apiserverは`default-scheduler`を設定します。
|
||||
従って、これらのPodをスケジュールするために、このスケジューラー名を持つプロファイルが存在する必要があります。
|
||||
|
||||
{{< note >}}
|
||||
Podのスケジューリングイベントには、ReportingControllerとして`.spec.schedulerName`が設定されています。
|
||||
リーダー選出のイベントには、リスト先頭のプロファイルのスケジューラー名が使用されます。
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
すべてのプロファイルは、`queueSort`拡張点で同じプラグインを使用し、同じ設定パラメーターを持つ必要があります (該当する場合)。これは、pending状態のPodキューがスケジューラーに1つしかないためです。
|
||||
{{< /note >}}
|
||||
|
||||
### 複数の拡張点に適用されるプラグイン {#multipoint}
|
||||
|
||||
`kubescheduler.config.k8s.io/v1beta3`からは、プロファイル設定に`multiPoint`というフィールドが追加され、複数の拡張点でプラグインを簡単に有効・無効化できるようになりました。
|
||||
`multiPoint`設定の目的は、カスタムプロファイルを使用する際に、ユーザーや管理者が必要とする設定を簡素化することです。
|
||||
|
||||
`MyPlugin`というプラグインがあり、`preScore`、`score`、`preFilter`、`filter`拡張点を実装しているとします。
|
||||
すべての利用可能な拡張点で`MyPlugin`を有効化するためには、プロファイル設定は次のようにします。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: multipoint-scheduler
|
||||
plugins:
|
||||
multiPoint:
|
||||
enabled:
|
||||
- name: MyPlugin
|
||||
```
|
||||
|
||||
これは以下のように、`MyPlugin`を手動ですべての拡張ポイントに対して有効にすることと同じです。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: non-multipoint-scheduler
|
||||
plugins:
|
||||
preScore:
|
||||
enabled:
|
||||
- name: MyPlugin
|
||||
score:
|
||||
enabled:
|
||||
- name: MyPlugin
|
||||
preFilter:
|
||||
enabled:
|
||||
- name: MyPlugin
|
||||
filter:
|
||||
enabled:
|
||||
- name: MyPlugin
|
||||
```
|
||||
|
||||
`multiPoint`を使用する利点の一つは、将来的に`MyPlugin`が別の拡張点を実装した場合に、`multiPoint`設定が自動的に新しい拡張点に対しても有効化されることです。
|
||||
|
||||
特定の拡張点は、その拡張点の`disabled`フィールドを使用して、`MultiPoint`の展開から除外することができます。
|
||||
これは、デフォルトのプラグインを無効にしたり、デフォルト以外のプラグインを無効にしたり、ワイルドカード(`'*'`)を使ってすべてのプラグインを無効にしたりする場合に有効です。
|
||||
`Score`と`PreScore`を無効にするためには、次の例のようにします。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: non-multipoint-scheduler
|
||||
plugins:
|
||||
multiPoint:
|
||||
enabled:
|
||||
- name: 'MyPlugin'
|
||||
preScore:
|
||||
disabled:
|
||||
- name: '*'
|
||||
score:
|
||||
disabled:
|
||||
- name: '*'
|
||||
```
|
||||
|
||||
`v1beta3`では、`MultiPoint`を通じて、内部的に全ての[デフォルトプラグイン](#scheduling-plugins)が有効化されています。
|
||||
しかしながら、デフォルト値(並び順やスコアの重みなど)を柔軟に設定し直せるように、個別の拡張点は用意されています。
|
||||
例えば、2つのスコアプラグイン`DefaultScore1`と`DefaultScore2`に、重み1が設定されているとします。
|
||||
その場合、次のように重さを変更し、並べ替えることができます。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: multipoint-scheduler
|
||||
plugins:
|
||||
score:
|
||||
enabled:
|
||||
- name: 'DefaultScore2'
|
||||
weight: 5
|
||||
```
|
||||
|
||||
この例では、`MultiPoint`はデフォルトプラグインであるため、明示的にプラグイン名を指定する必要はありません。
|
||||
そして、`Score`に指定されているプラグインは`DefaultScore2`のみです。
|
||||
これは、特定の拡張点を通じて設定されたプラグインは、常に`MultiPoint`プラグインよりも優先されるためです。つまり、この設定例では、結果的に2つのプラグインを両方指定することなく、並び替えが行えます。
|
||||
|
||||
`MultiPoint`プラグインを設定する際の一般的な優先順位は、以下の通りです。
|
||||
1. 特定の拡張点が最初に実行され、その設定は他の場所で設定されたものよりも優先される
|
||||
2. `MultiPoint`を使用して、手動で設定したプラグインとその設定内容
|
||||
3. デフォルトプラグインとそのデフォルト設定
|
||||
|
||||
上記の優先順位を示すために、次の例はこれらのプラグインをベースにします。
|
||||
|
||||
|プラグイン|拡張点|
|
||||
|---|---|
|
||||
|`DefaultQueueSort`|`QueueSort`|
|
||||
|`CustomQueueSort`|`QueueSort`|
|
||||
|`DefaultPlugin1`|`Score`, `Filter`|
|
||||
|`DefaultPlugin2`|`Score`|
|
||||
|`CustomPlugin1`|`Score`, `Filter`|
|
||||
|`CustomPlugin2`|`Score`, `Filter`|
|
||||
|
||||
これらのプラグインの有効な設定例は次の通りです。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: multipoint-scheduler
|
||||
plugins:
|
||||
multiPoint:
|
||||
enabled:
|
||||
- name: 'CustomQueueSort'
|
||||
- name: 'CustomPlugin1'
|
||||
weight: 3
|
||||
- name: 'CustomPlugin2'
|
||||
disabled:
|
||||
- name: 'DefaultQueueSort'
|
||||
filter:
|
||||
disabled:
|
||||
- name: 'DefaultPlugin1'
|
||||
score:
|
||||
enabled:
|
||||
- name: 'DefaultPlugin2'
|
||||
```
|
||||
|
||||
なお、特定の拡張点に`MultiPoint`プラグインを再宣言しても、エラーにはなりません。
|
||||
特定の拡張点が優先されるため、再宣言は無視されます(ログは記録されます)。
|
||||
|
||||
|
||||
このサンプルは、ほとんどのコンフィグを一箇所にまとめるだけでなく、いくつかの工夫をしています。
|
||||
* カスタムの`queueSort`プラグインを有効にし、デフォルトのプラグインを無効にする。
|
||||
* `CustomPlugin1`と`CustomPlugin2`を有効にし、この拡張点のプラグイン内で、最初に実行されるようにする。
|
||||
* `filter`拡張点でのみ、`DefaultPlugin1`を無効にする。
|
||||
* `score`拡張点で`DefaultPlugin2`が最初に実行されるように並べ替える(カスタムプラグインより先に)。
|
||||
|
||||
`v1beta3`以前のバージョンで、`multiPoint`がない場合、上記の設定例は、次のものと同等になります。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta2
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: multipoint-scheduler
|
||||
plugins:
|
||||
|
||||
# デフォルトQueueSortプラグインを無効化
|
||||
queueSort:
|
||||
enabled:
|
||||
- name: 'CustomQueueSort'
|
||||
disabled:
|
||||
- name: 'DefaultQueueSort'
|
||||
|
||||
# カスタムFilterプラグインを有効化
|
||||
filter:
|
||||
enabled:
|
||||
- name: 'CustomPlugin1'
|
||||
- name: 'CustomPlugin2'
|
||||
- name: 'DefaultPlugin2'
|
||||
disabled:
|
||||
- name: 'DefaultPlugin1'
|
||||
|
||||
# カスタムScoreプラグインを有効化し、実行順を並べ替える
|
||||
score:
|
||||
enabled:
|
||||
- name: 'DefaultPlugin2'
|
||||
weight: 1
|
||||
- name: 'DefaultPlugin1'
|
||||
weight: 3
|
||||
```
|
||||
|
||||
これは複雑な例ですが、`MultiPoint`設定の柔軟性と、拡張点を設定する既存の方法とのシームレスな統合を実証しています。
|
||||
|
||||
## スケジューラー設定の移行
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="v1beta1 → v1beta2" %}}
|
||||
* v1beta2`のバージョン`の設定では、新しい`NodeResourcesFit`プラグインをスコア拡張点で使用できます。
|
||||
この新しい拡張機能は、`NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated`、 `RequestedToCapacityRatio`プラグインの機能を組み合わせたものです。
|
||||
例えば、以前は`NodeResourcesMostAllocated`プラグインを使っていたなら、代わりに`NodeResourcesFitプラグインを使用し(デフォルトで有効)、`pluginConfig`に次のような`scoreStrategy`を追加することになるでしょう。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta2
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- pluginConfig:
|
||||
- args:
|
||||
scoringStrategy:
|
||||
resources:
|
||||
- name: cpu
|
||||
weight: 1
|
||||
type: MostAllocated
|
||||
name: NodeResourcesFit
|
||||
```
|
||||
|
||||
* スケジューラープラグインの`NodeLabel`は廃止されました。代わりに[`NodeAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。
|
||||
|
||||
* スケジューラープラグインの`ServiceAffinity`は廃止されました。代わりに[`InterPodAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。
|
||||
|
||||
* スケジューラープラグインの`NodePreferAvoidPods`は廃止されました。代わりに[Node taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使用することで同様の振る舞いを実現できます。
|
||||
|
||||
* v1beta2で有効化されたプラグインは、そのプラグインのデフォルトの設定より優先されます。
|
||||
|
||||
* スケジューラーのヘルスとメトリクスのバインドアドレスに設定されている`host`や`port`が無効な場合、バリデーションに失敗します。
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="v1beta2 → v1beta3" %}}
|
||||
* デフォルトで3つのプラグインの重みが増加しました。
|
||||
* `InterPodAffinity`:1から2
|
||||
* `NodeAffinity`:1から2
|
||||
* `TaintToleration`:1から3
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kube-schedulerリファレンス](/docs/reference/command-line-tools-reference/kube-scheduler/)を読む
|
||||
* [scheduling](/ja/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/)のリファレンスを読む
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: スケジューリングポリシー
|
||||
content_type: concept
|
||||
sitemap:
|
||||
priority: 0.2 # スケジューリングポリシーは廃止されました。
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
バージョンv1.23より前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file <filename>`または`kube-scheduler --policy-configmap <ConfigMap>`を実行すると、スケジューリングポリシーを設定することが可能です。
|
||||
|
||||
このスケジューリングポリシーは、バージョンv1.23以降のKubernetesではサポートされていません。関連するフラグである、`policy-config-file`、`policy-configmap`、`policy-configmap-namespace`、`use-legacy-policy-config`も同様にサポートされていません。
|
||||
代わりに、[スケジューラー設定](/ja/docs/reference/scheduling/config/)を使用してください。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [スケジューリング](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ
|
||||
* [kube-scheduler設定](/ja/docs/reference/scheduling/config/)について学ぶ
|
||||
* [kube-scheduler設定リファレンス(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)について読む
|
||||
|
|
@ -522,4 +522,4 @@ Minikubeの詳細については、[proposal](https://git.k8s.io/community/contr
|
|||
|
||||
## コミュニティ
|
||||
|
||||
コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の`#minikube`チャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
|
||||
コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の`#minikube`チャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[dev@kubernetes Google Groupsメーリングリスト](https://groups.google.com/a/kubernetes.io/g/dev/)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。
|
||||
|
|
|
|||
|
|
@ -5,12 +5,14 @@ metadata:
|
|||
labels:
|
||||
app: mysql
|
||||
data:
|
||||
master.cnf: |
|
||||
# Apply this config only on the master.
|
||||
primary.cnf: |
|
||||
# Apply this config only on the primary.
|
||||
[mysqld]
|
||||
log-bin
|
||||
slave.cnf: |
|
||||
# Apply this config only on slaves.
|
||||
datadir=/var/lib/mysql/mysql
|
||||
replica.cnf: |
|
||||
# Apply this config only on replicas.
|
||||
[mysqld]
|
||||
super-read-only
|
||||
datadir=/var/lib/mysql/mysql
|
||||
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ content_type: concept
|
|||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
|
||||
* [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/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와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
|
||||
|
|
@ -29,7 +30,7 @@ content_type: concept
|
|||
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
|
||||
* [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
|
||||
* [Romana](https://github.com/romana/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
|
||||
|
||||
## 서비스 검색
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 15
|
|||
|
||||
<!-- overview -->
|
||||
`kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
|
||||
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
|
||||
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요를
|
||||
제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은
|
||||
[Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ Por fim, adicione os mesmos parâmetros nos parâmetros iniciais do Servidor de
|
|||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
1. Gere a chave CA (`ca-key.pem`) e o certificado (` ca.pem`):
|
||||
1. Gere a chave CA (`ca-key.pem`) e o certificado (`ca.pem`):
|
||||
|
||||
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
|
||||
1. Crie um arquivo de configuração JSON para gerar chaves e certificados para o Servidor de API, por exemplo, `server-csr.json`. Certifique-se de substituir os valores entre colchetes angulares por valores reais que você deseja usar. O `MASTER_CLUSTER_IP` é o IP do serviço do cluster para o servidor da API, conforme descrito na subseção anterior. O exemplo abaixo também assume que você está usando `cluster.local` como DNS de domínio padrão
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ Essa abordagem é adequada se você puder controlar a configuração do nó.
|
|||
|
||||
{{< note >}}
|
||||
O Kubernetes padrão é compatível apenas com as seções `auths` e` HttpHeaders` na configuração do Docker.
|
||||
Auxiliares de credencial do Docker (`credHelpers` ou` credsStore`) não são suportados.
|
||||
Auxiliares de credencial do Docker (`credHelpers` ou `credsStore`) não são suportados.
|
||||
{{< /note >}}
|
||||
|
||||
Docker armazena chaves de registros privados no arquivo `$HOME/.dockercfg` ou `$HOME/.docker/config.json`. Se você colocar o mesmo arquivo na lista de caminhos de pesquisa abaixo, o kubelet o usa como provedor de credenciais ao obter imagens.
|
||||
|
|
|
|||
|
|
@ -8,3 +8,13 @@ menu:
|
|||
post: >
|
||||
<p>阅读关于 kubernetes 和容器规范的最新信息,以及获取最新的技术。</p>
|
||||
---
|
||||
|
||||
{{< comment >}}
|
||||
|
||||
<!-- For information about contributing to the blog, see
|
||||
https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post -->
|
||||
|
||||
有关为博客提供内容的信息，请参见
|
||||
https://kubernetes.io/zh/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post
|
||||
|
||||
{{< /comment >}}
|
||||
|
|
@ -0,0 +1,180 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "关注 SIG Node"
|
||||
date: 2021-09-27
|
||||
slug: sig-node-spotlight-2021
|
||||
---
|
||||
<!--
|
||||
---
|
||||
layout: blog
|
||||
title: "Spotlight on SIG Node"
|
||||
date: 2021-09-27
|
||||
slug: sig-node-spotlight-2021
|
||||
---
|
||||
-->
|
||||
**Author:** Dewan Ahmed, Red Hat
|
||||
<!--
|
||||
**Author:** Dewan Ahmed, Red Hat
|
||||
-->
|
||||
|
||||
<!--
|
||||
## Introduction
|
||||
|
||||
In Kubernetes, a _Node_ is a representation of a single machine in your cluster. [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) owns that very important Node component and supports various subprojects such as Kubelet, Container Runtime Interface (CRI) and more to support how the pods and host resources interact. In this blog, we have summarized our conversation with [Elana Hashman (EH)](https://twitter.com/ehashdn) & [Sergey Kanzhelev (SK)](https://twitter.com/SergeyKanzhelev), who walk us through the various aspects of being a part of the SIG and share some insights about how others can get involved.
|
||||
-->
|
||||
|
||||
## 介绍
|
||||
|
||||
在 Kubernetes 中，一个 _Node_ 是你集群中的某台机器。
|
||||
[SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) 负责这一非常重要的 Node 组件并支持各种子项目，
|
||||
如 Kubelet, Container Runtime Interface (CRI) 以及其他支持 Pod 和主机资源间交互的子项目。
|
||||
在这篇文章中，我们总结了和 [Elana Hashman (EH)](https://twitter.com/ehashdn) & [Sergey Kanzhelev (SK)](https://twitter.com/SergeyKanzhelev) 的对话，是他们带领我们了解作为此 SIG 一份子的各个方面，并分享一些关于其他人如何参与的见解。
|
||||
|
||||
<!--
|
||||
## A summary of our conversation
|
||||
|
||||
### Could you tell us a little about what SIG Node does?
|
||||
|
||||
SK: SIG Node is a vertical SIG responsible for the components that support the controlled interactions between the pods and host resources. We manage the lifecycle of pods that are scheduled to a node. This SIG's focus is to enable a broad set of workload types, including workloads with hardware specific or performance sensitive requirements. All while maintaining isolation boundaries between pods on a node, as well as the pod and the host. This SIG maintains quite a few components and has many external dependencies (like container runtimes or operating system features), which makes the complexity we deal with huge. We tame the complexity and aim to continuously improve node reliability.
|
||||
-->
|
||||
## 我们的对话总结
|
||||
|
||||
### 你能告诉我们一些关于 SIG Node 的工作吗？
|
||||
|
||||
SK：SIG Node 是一个垂直 SIG，负责支持 Pod 和主机资源之间受控互动的组件。我们管理被调度到节点上的 Pod 的生命周期。
|
||||
这个 SIG 的重点是支持广泛的工作负载类型，包括具有硬件特性或性能敏感要求的工作负载。同时保持节点上 Pod 之间的隔离边界，以及 Pod 和主机的隔离边界。
|
||||
这个 SIG 维护了相当多的组件，并有许多外部依赖（如容器运行时间或操作系统功能），这使得我们处理起来十分复杂。但我们战胜了这种复杂度，旨在不断提高节点的可靠性。
|
||||
|
||||
<!--
|
||||
### "SIG Node is a vertical SIG" could you explain a bit more?
|
||||
|
||||
EH: There are two kinds of SIGs: horizontal and vertical. Horizontal SIGs are concerned with a particular function of every component in Kubernetes: for example, SIG Security considers security aspects of every component in Kubernetes, or SIG Instrumentation looks at the logs, metrics, traces and events of every component in Kubernetes. Such SIGs don't tend to own a lot of code.
|
||||
|
||||
Vertical SIGs, on the other hand, own a single component, and are responsible for approving and merging patches to that code base. SIG Node owns the "Node" vertical, pertaining to the kubelet and its lifecycle. This includes the code for the kubelet itself, as well as the node controller, the container runtime interface, and related subprojects like the node problem detector.
|
||||
-->
|
||||
### 你能再解释一下 “SIG Node 是一种垂直 SIG” 的含义吗？
|
||||
|
||||
EH：有两种 SIG：横向和垂直。横向 SIG 关注 Kubernetes 中每个组件的特定功能：例如，SIG Security 考虑 Kubernetes 中每个组件的安全方面，或者 SIG Instrumentation 关注 Kubernetes 中每个组件的日志、度量、跟踪和事件。
|
||||
这样的 SIG 并不太会拥有大量的代码。
|
||||
|
||||
相反，垂直 SIG 拥有一个单一的组件，并负责批准和合并该代码库的补丁。
|
||||
SIG Node 拥有 "Node" 的垂直性，与 kubelet 和它的生命周期有关。这包括 kubelet 本身的代码，以及节点控制器、容器运行时接口和相关的子项目，比如节点问题检测器。
|
||||
|
||||
<!--
|
||||
### How did the CI subproject start? Is this specific to SIG Node and how does it help the SIG?
|
||||
|
||||
SK: The subproject started as a follow up after one of the releases was blocked by numerous test failures of critical tests. These tests haven’t started falling all at once, rather continuous lack of attention led to slow degradation of tests quality. SIG Node was always prioritizing quality and reliability, and forming of the subproject was a way to highlight this priority.
|
||||
-->
|
||||
### CI 子项目是如何开始的？这是专门针对 SIG Node 的吗？它对 SIG 有什么帮助？
|
||||
|
||||
SK：该子项目是在其中一个版本因关键测试的大量测试失败而受阻后开始跟进的。
|
||||
这些测试并不是一下子就开始下降的，而是持续的缺乏关注导致了测试质量的缓慢下降。
|
||||
SIG Node 一直将质量和可靠性放在首位，组建这个子项目是强调这一优先事项的一种方式。
|
||||
|
||||
<!--
|
||||
### As the 3rd largest SIG in terms of number of issues and PRs, how does your SIG juggle so much work?
|
||||
|
||||
EH: It helps to be organized. When I increased my contributions to the SIG in January of 2021, I found myself overwhelmed by the volume of pull requests and issues and wasn't sure where to start. We were already tracking test-related issues and pull requests on the CI subproject board, but that was missing a lot of our bugfixes and feature work. So I began putting together a triage board for the rest of our pull requests, which allowed me to sort each one by status and what actions to take, and documented its use for other contributors. We closed or merged over 500 issues and pull requests tracked by our two boards in each of the past two releases. The Kubernetes devstats showed that we have significantly increased our velocity as a result.
|
||||
|
||||
In June, we ran our first bug scrub event to work through the backlog of issues filed against SIG Node, ensuring they were properly categorized. We closed over 130 issues over the course of this 48 hour global event, but as of writing we still have 333 open issues.
|
||||
-->
|
||||
### 作为 issue 和 PR 数量第三大的 SIG，你们 SIG 是如何兼顾这么多工作的？
|
||||
|
||||
EH：这归功于有组织性。当我在 2021 年 1 月增加对 SIG 的贡献时，我发现自己被大量的 PR 和 issue 淹没了，不知道该从哪里开始。
|
||||
我们已经在 CI 子项目板上跟踪与测试有关的 issue 和 PR 请求，但这缺少了很多 bug 修复和功能工作。
|
||||
因此，我开始为我们剩余的 PR 建立一个分流板，这使我能够根据状态和采取的行动对其进行分类，并为其他贡献者记录它的用途。
|
||||
在过去的两个版本中，我们关闭或合并了超过 500 个 issue 和 PR。Kubernetes devstats 显示，我们的速度因此而大大提升。
|
||||
|
||||
6月，我们进行了第一次 bug 清除活动，以解决针对 SIG Node 的积压问题，确保它们被正确归类。
|
||||
在这次 48 小时的全球活动中，我们关闭了 130 多个问题，但截至发稿时，我们仍有 333 个问题没有解决。
|
||||
<!--
|
||||
### Why should new and existing contributors consider joining SIG Node?
|
||||
|
||||
SK: Being a SIG Node contributor gives you skills and recognition that are rewarding and useful. Understanding under the hood of a kubelet helps architecting better apps, tune and optimize those apps, and gives leg up in issues troubleshooting. If you are a new contributor, SIG Node gives you the foundational knowledge that is key to understanding why other Kubernetes components are designed the way they are. Existing contributors may benefit as many features will require SIG Node changes one way or another. So being a SIG Node contributor helps building features in other SIGs faster.
|
||||
|
||||
SIG Node maintains numerous components, many of which have dependency on external projects or OS features. This makes the onboarding process quite lengthy and demanding. But if you are up for a challenge, there is always a place for you, and a group of people to support.
|
||||
-->
|
||||
### 为什么新的和现有的贡献者应该考虑加入 Node 兴趣小组呢？
|
||||
|
||||
SK：作为 SIG Node 的贡献者会带给你有意义且有用的技能和认可度。
|
||||
了解 Kubelet 的内部结构有助于构建更好的应用程序，调整和优化这些应用程序，并在 issue 排查上获得优势。
|
||||
如果你是一个新手贡献者，SIG Node 为你提供了基础知识，这是理解其他 Kubernetes 组件的设计方式的关键。
|
||||
现在的贡献者可能会受益于许多功能都需要 SIG Node 的这种或那种变化。所以成为 SIG Node 的贡献者有助于更快地建立其他 SIG 的功能。
|
||||
|
||||
SIG Node 维护着许多组件，其中许多组件都依赖于外部项目或操作系统功能。这使得入职过程相当冗长和苛刻。
|
||||
但如果你愿意接受挑战，总有一个地方适合你，也有一群人支持你。
|
||||
<!--
|
||||
### What do you do to help new contributors get started?
|
||||
|
||||
EH: Getting started in SIG Node can be intimidating, since there is so much work to be done, our SIG meetings are very large, and it can be hard to find a place to start.
|
||||
|
||||
I always encourage new contributors to work on things that they have some investment in already. In SIG Node, that might mean volunteering to help fix a bug that you have personally been affected by, or helping to triage bugs you care about by priority.
|
||||
|
||||
To come up to speed on any open source code base, there are two strategies you can take: start by exploring a particular issue deeply, and follow that to expand the edges of your knowledge as needed, or briefly review as many issues and change requests as you possibly can to get a higher level picture of how the component works. Ultimately, you will need to do both if you want to become a Node reviewer or approver.
|
||||
|
||||
[Davanum Srinivas](https://twitter.com/dims) and I each ran a cohort of group mentoring to help teach new contributors the skills to become Node reviewers, and if there's interest we can work to find a mentor to run another session. I also encourage new contributors to attend our Node CI Subproject meeting: it's a smaller audience and we don't record the triage sessions, so it can be a less intimidating way to get started with the SIG.
|
||||
-->
|
||||
### 你是如何帮助新手贡献者开始工作的？
|
||||
|
||||
EH：在 SIG Node 的起步工作可能是令人生畏的，因为有太多的工作要做，我们的 SIG 会议非常大，而且很难找到一个开始的地方。
|
||||
|
||||
我总是鼓励新手贡献者在他们已经有一些投入的方向上更进一步。
|
||||
在 SIG Node 中，这可能意味着自愿帮助修复一个只影响到你个人的 bug，或者按优先级去分流你关心的 bug。
|
||||
|
||||
为了尽快了解任何开源代码库，你可以采取两种策略：从深入探索一个特定的问题开始，然后根据需要扩展你的知识边缘，或者单纯地尽可能多的审查 issues 和变更请求，以了解更高层次的组件工作方式。
|
||||
最终，如果你想成为一名 Node reviewer 或 approver，两件事是不可避免的。
|
||||
|
||||
[Davanum Srinivas](https://twitter.com/dims) 和我各自举办了一次小组辅导，以帮助教导新手贡献者成为 Node reviewer 的技能，如果有兴趣，我们可以努力寻找一个导师来举办另一次会议。
|
||||
我也鼓励新手贡献者参加我们的 Node CI 子项目会议：它的听众较少，而且我们不记录分流会议，所以它可以是一个比较温和的方式来开始 SIG 之旅。
|
||||
<!--
|
||||
### Are there any particular skills you’d like to recruit for? What skills are contributors to SIG Usability likely to learn?
|
||||
|
||||
SK: SIG Node works on many workstreams in very different areas. All of these areas are on system level. For the typical code contributions you need to have a passion for building and utilizing low level APIs and writing performant and reliable components. Being a contributor you will learn how to debug and troubleshoot, profile, and monitor these components, as well as user workload that is run by these components. Often, with the limited to no access to Nodes, as they are running production workloads.
|
||||
|
||||
The other way of contribution is to help document SIG node features. This type of contribution requires a deep understanding of features, and ability to explain them in simple terms.
|
||||
|
||||
Finally, we are always looking for feedback on how best to run your workload. Come and explain specifics of it, and what features in SIG Node components may help to run it better.
|
||||
-->
|
||||
### 有什么特别的技能者是你想招募的吗？对 SIG 可用性的贡献者可能会学到什么技能？
|
||||
|
||||
SK：SIG Node 在大相径庭的领域从事许多工作流。所有这些领域都是系统级的。
|
||||
对于典型的代码贡献，你需要对建立和善用低级别的 API 以及编写高性能和可靠的组件有热情。
|
||||
作为一个贡献者，你将学习如何调试和排除故障，剖析和监控这些组件，以及由这些组件运行的用户工作负载。
|
||||
通常情况下，由于节点正在运行生产工作负载，所以对节点的访问是有限的，甚至是没有的。
|
||||
|
||||
另一种贡献方式是帮助记录 SIG Node 的功能。这种类型的贡献需要对功能有深刻的理解，并有能力用简单的术语解释它们。
|
||||
|
||||
最后，我们一直在寻找关于如何最好地运行你的工作负载的反馈。来解释一下它的具体情况，以及 SIG Node 组件中的哪些功能可能有助于更好地运行它。
|
||||
<!--
|
||||
### What are you getting positive feedback on, and what’s coming up next for SIG Node?
|
||||
|
||||
EH: Over the past year SIG Node has adopted some new processes to help manage our feature development and Kubernetes enhancement proposals, and other SIGs have looked to us for inspiration in managing large workloads. I hope that this is an area we can continue to provide leadership in and further iterate on.
|
||||
|
||||
We have a great balance of new features and deprecations in flight right now. Deprecations of unused or difficult to maintain features help us keep technical debt and maintenance load under control, and examples include the dockershim and DynamicKubeletConfiguration deprecations. New features will unlock additional functionality in end users' clusters, and include exciting features like support for cgroups v2, swap memory, graceful node shutdowns, and device management policies.
|
||||
-->
|
||||
### 你在哪些方面得到了积极的反馈，以及 SIG Node 的下一步计划是什么？
|
||||
|
||||
EH：在过去的一年里，SIG Node 采用了一些新的流程来帮助管理我们的功能开发和 Kubernetes 增强提议，其他 SIG 也向我们寻求在管理大型工作负载方面的灵感。
|
||||
我希望这是一个我们可以继续领导并进一步迭代的领域。
|
||||
|
||||
现在，我们在新功能和废弃功能之间保持了很好的平衡。
|
||||
废弃未使用或难以维护的功能有助于我们控制技术债务和维护负荷，例子包括 dockershim 和 DynamicKubeletConfiguration 的废弃。
|
||||
新功能将在终端用户的集群中释放更多的功能，包括令人兴奋的功能，如支持 cgroups v2、交换内存、优雅的节点关闭和设备管理策略。
|
||||
<!--
|
||||
### Any closing thoughts/resources you’d like to share?
|
||||
|
||||
SK/EH: It takes time and effort to get to any open source community. SIG Node may overwhelm you at first with the number of participants, volume of work, and project scope. But it is totally worth it. Join our welcoming community! [SIG Node GitHub Repo](https://github.com/kubernetes/community/tree/master/sig-node) contains many useful resources including Slack, mailing list and other contact info.
|
||||
-->
|
||||
### 最后你有什么想法/资源要分享吗？
|
||||
|
||||
SK/EH：进入任何开源社区都需要时间和努力。一开始 SIG Node 可能会因为参与者的数量、工作量和项目范围而让你不知所措。但这是完全值得的。
|
||||
请加入我们这个热情的社区! [SIG Node GitHub Repo]（https://github.com/kubernetes/community/tree/master/sig-node）包含许多有用的资源，包括 Slack、邮件列表和其他联系信息。
|
||||
<!--
|
||||
## Wrap Up
|
||||
|
||||
SIG Node hosted a [KubeCon + CloudNativeCon Europe 2021 talk](https://www.youtube.com/watch?v=z5aY4e2RENA) with an intro and deep dive to their awesome SIG. Join the SIG's meetings to find out about the most recent research results, what the plans are for the forthcoming year, and how to get involved in the upstream Node team as a contributor!
|
||||
-->
|
||||
## 总结
|
||||
|
||||
SIG Node 举办了一场 [KubeCon + CloudNativeCon Europe 2021 talk](https://www.youtube.com/watch?v=z5aY4e2RENA)，对他们强大的 SIG 进行了介绍和深入探讨。
|
||||
加入 SIG 的会议，了解最新的研究成果，未来一年的计划是什么，以及如何作为贡献者参与到上游的 Node 团队中!
|
||||
|
|
@ -0,0 +1,197 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "认识我们的贡献者 - 亚太地区（印度地区）"
|
||||
date: 2022-01-10T12:00:00+0000
|
||||
slug: meet-our-contributors-india-ep-01
|
||||
canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/
|
||||
---
|
||||
<!--
|
||||
layout: blog
|
||||
title: "Meet Our Contributors - APAC (India region)"
|
||||
date: 2022-01-10T12:00:00+0000
|
||||
slug: meet-our-contributors-india-ep-01
|
||||
canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Pritish Samal](https://github.com/CIPHERTron), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
|
||||
-->
|
||||
**作者和采访者：** [Anubhav Vardhan](https://github.com/anubha-v-ardhan) ， [Atharva Shinde](https://github.com/Atharva-Shinde) ， [Avinesh Tripathi](https://github.com/AvineshTripathi) ， [Debabrata Panigrahi](https://github.com/Debanitrkl) ， [Kunal Verma](https://github.com/verma-kunal) ， [Pranshu Srivastava](https://github.com/PranshuSrivastava) ， [Pritish Samal](https://github.com/CIPHERTron) ， [Purneswar Prasad](https://github.com/PurneswarPrasad) ， [Vedant Kakde](https://github.com/vedant-kakde)
|
||||
|
||||
<!--
|
||||
**Editor:** [Priyanka Saggu](https://psaggu.com)
|
||||
-->
|
||||
**编辑：** [Priyanka Saggu](https://psaggu.com)
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
Good day, everyone 👋
|
||||
-->
|
||||
大家好 👋
|
||||
|
||||
<!--
|
||||
Welcome to the first episode of the APAC edition of the "Meet Our Contributors" blog post series.
|
||||
-->
|
||||
欢迎来到亚太地区的“认识我们的贡献者”博文系列第一期。
|
||||
|
||||
|
||||
<!--
|
||||
In this post, we'll introduce you to five amazing folks from the India region who have been actively contributing to the upstream Kubernetes projects in a variety of ways, as well as being the leaders or maintainers of numerous community initiatives.
|
||||
-->
|
||||
在这篇文章中，我们将向您介绍来自印度地区的五位优秀贡献者，他们一直在以各种方式积极地为上游 Kubernetes 项目做贡献，同时也是众多社区倡议的领导者和维护者。
|
||||
|
||||
<!--
|
||||
💫 *Let's get started, so without further ado…*
|
||||
-->
|
||||
💫 *闲话少说，我们开始吧。*
|
||||
|
||||
|
||||
## [Arsh Sharma](https://github.com/RinkiyaKeDad)
|
||||
|
||||
<!--
|
||||
Arsh is currently employed with Okteto as a Developer Experience engineer. As a new contributor, he realised that 1:1 mentorship opportunities were quite beneficial in getting him started with the upstream project.
|
||||
-->
|
||||
Arsh 目前在 Okteto 公司中担任开发者体验工程师职务。作为一名新的贡献者，他意识到一对一的指导机会让他在开始上游项目中受益匪浅。
|
||||
|
||||
<!--
|
||||
He is presently a CI Signal shadow on the Kubernetes 1.23 release team. He is also contributing to the SIG Testing and SIG Docs projects, as well as to the [cert-manager](https://github.com/cert-manager/infrastructure) tools development work that is being done under the aegis of SIG Architecture.
|
||||
-->
|
||||
他目前是 Kubernetes 1.23 版本团队的 CI Signal 经理。他还致力于为 SIG Testing 和 SIG Docs 项目提供贡献，并且在 SIG Architecture 项目中负责 [证书管理器](https://github.com/cert-manager/infrastructure) 工具的开发工作。
|
||||
|
||||
<!--
|
||||
To the newcomers, Arsh helps plan their early contributions sustainably.
|
||||
-->
|
||||
对于新人来说，Arsh 帮助他们可持续地计划早期贡献。
|
||||
|
||||
<!--
|
||||
> _I would encourage folks to contribute in a way that's sustainable. What I mean by that
|
||||
> is that it's easy to be very enthusiastic early on and take up more stuff than one can
|
||||
> actually handle. This can often lead to burnout in later stages. It's much more sustainable
|
||||
> to work on things iteratively._
|
||||
-->
|
||||
> _我鼓励大家以可持续的方式为社区做贡献。我的意思是，一个人很容易在早期的时候非常有热情，并且承担了很多超出个人实际能力的事情。这通常会导致后期的倦怠。迭代地处理事情会让大家对社区的贡献变得可持续。_
|
||||
|
||||
## [Kunal Kushwaha](https://github.com/kunal-kushwaha)
|
||||
|
||||
<!--
|
||||
Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also a CNCF ambassador and one of the founders of the [CNCF Students Program](https://community.cncf.io/cloud-native-students/).. He also served as a Communications role shadow during the 1.22 release cycle.
|
||||
-->
|
||||
Kunal Kushwaha 是 Kubernetes 营销委员会的核心成员。他同时也是 [CNCF 学生计划](https://community.cncf.io/cloud-native-students/) 的创始人之一。他还在 1.22 版本周期中担任通信经理一职。
|
||||
|
||||
<!--
|
||||
At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in.
|
||||
-->
|
||||
在他的第一年结束时，Kunal 开始为 [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) 项目做贡献。然后，他被推选从事同一项目，此项目是 Google Summer of Code 的一部分。Kunal 在 Google Summer of Code、Google Code-in 等项目中指导过很多人。
|
||||
|
||||
<!--
|
||||
As an open-source enthusiast, he believes that diverse participation in the community is beneficial since it introduces new perspectives and opinions and respect for one's peers. He has worked on various open-source projects, and his participation in communities has considerably assisted his development as a developer.
|
||||
-->
|
||||
作为一名开源爱好者，他坚信，社区的多元化参与是非常有益的，因为他引入了新的观念和观点，并尊重自己的伙伴。它曾参与过各种开源项目，他在这些社区中的参与对他作为开发者的发展有很大帮助。
|
||||
|
||||
|
||||
<!--
|
||||
> _I believe if you find yourself in a place where you do not know much about the
|
||||
> project, that's a good thing because now you can learn while contributing and the
|
||||
> community is there to help you. It has helped me a lot in gaining skills, meeting
|
||||
> people from around the world and also helping them. You can learn on the go,
|
||||
> you don't have to be an expert. Make sure to also check out no code contributions
|
||||
> because being a beginner is a skill and you can bring new perspectives to the
|
||||
> organisation._
|
||||
-->
|
||||
> _我相信，如果你发现自己在一个了解不多的项目当中，那是件好事，因为现在你可以一边贡献一边学习，社区也会帮助你。它帮助我获得了很多技能，认识了来自世界各地的人，也帮助了他们。你可以在这个过程中学习，自己不一定必须是专家。请重视非代码贡献，因为作为初学者这是一项技能，你可以为组织带来新的视角。_
|
||||
|
||||
## [Madhav Jivarajani](https://github.com/MadhavJivrajani)
|
||||
|
||||
|
||||
<!--
|
||||
Madhav Jivarajani works on the VMware Upstream Kubernetes stability team. He began contributing to the Kubernetes project in January 2021 and has since made significant contributions to several areas of work under SIG Architecture, SIG API Machinery, and SIG ContribEx (contributor experience).
|
||||
-->
|
||||
Madhav Jivarajani 在 VMware 上游 Kubernetes 稳定性团队工作。他于 2021 年 1 月开始为 Kubernetes 项目做贡献，此后在 SIG Architecture、SIG API Machinery 和 SIG ContribEx（贡献者经验）等项目的几个工作领域做出了重大贡献。
|
||||
|
||||
<!--
|
||||
Among several significant contributions are his recent efforts toward the Archival of [design proposals](https://github.com/kubernetes/community/issues/6055), refactoring the ["groups" codebase](https://github.com/kubernetes/k8s.io/pull/2713) under k8s-infra repository to make it mockable and testable, and improving the functionality of the [GitHub k8s bot](https://github.com/kubernetes/test-infra/issues/23129).
|
||||
-->
|
||||
在这几个重要项目中，他最近致力于 [设计方案](https://github.com/kubernetes/community/issues/6055) 的存档工作，重构 k8s-infra 存储库下的 ["组"代码库](https://github.com/kubernetes/k8s.io/pull/2713) ，使其具有可模拟性和可测试性，以及改进 [GitHub k8s 机器人](https://github.com/kubernetes/test-infra/issues/23129) 的功能。
|
||||
|
||||
<!--
|
||||
In addition to his technical efforts, Madhav oversees many projects aimed at assisting new contributors. He organises bi-weekly "KEP reading club" sessions to help newcomers understand the process of adding new features, deprecating old ones, and making other key changes to the upstream project. He has also worked on developing [Katacoda scenarios](https://github.com/kubernetes-sigs/contributor-katacoda) to assist new contributors to become acquainted with the process of contributing to k/k. In addition to his current efforts to meet with community members every week, he has organised several [new contributors workshops (NCW)](https://www.youtube.com/watch?v=FgsXbHBRYIc).
|
||||
-->
|
||||
除了在技术方面的贡献，Madhav 还监督许多旨在帮助新贡献者的项目。他每两周组织一次的“KEP 阅读俱乐部”会议，帮助新人了解添加新功能、摒弃旧功能以及对上游项目进行其他关键更改的过程。他还致力于开发 [Katacoda 场景](https://github.com/kubernetes-sigs/contributor-katacoda) ，以帮助新的贡献者在为 k/k 做贡献的过程更加熟练。目前除了每周与社区成员会面外，他还组织了几个 [新贡献者讲习班（NCW）](https://www.youtube.com/watch?v=FgsXbHBRYIc) 。
|
||||
|
||||
<!--
|
||||
> _I initially did not know much about Kubernetes. I joined because the community was
|
||||
> super friendly. But what made me stay was not just the people, but the project itself.
|
||||
> My solution to not feeling overwhelmed in the community was to gain as much context
|
||||
> and knowledge into the topics that I was interested in and were being discussed. And
|
||||
> as a result I continued to dig deeper into Kubernetes and the design of it.
|
||||
> I am a systems nut & thus Kubernetes was an absolute goldmine for me._
|
||||
-->
|
||||
> _一开始我对 Kubernetes 了解并不多。我加入社区是因为社区超级友好。但让我留下来的不仅仅是人，还有项目本身。我在社区中不会感到不知所措，这是因为我能够在感兴趣的和正在讨论的主题中获得尽可能多的背景和知识。因此，我将继续深入探讨 Kubernetes 及其设计。我是一个系统迷，kubernetes 对我来说绝对是一个金矿。_
|
||||
|
||||
|
||||
## [Rajas Kakodkar](https://github.com/rajaskakodkar)
|
||||
|
||||
<!--
|
||||
Rajas Kakodkar currently works at VMware as a Member of Technical Staff. He has been engaged in many aspects of the upstream Kubernetes project since 2019.
|
||||
-->
|
||||
Rajas Kakodkar 目前在 VMware 担任技术人员。自 2019 年以来，他一直多方面地从事上游 kubernetes 项目。
|
||||
|
||||
<!--
|
||||
He is now a key contributor to the Testing special interest group. He is also active in the SIG Network community. Lately, Rajas has contributed significantly to the [NetworkPolicy++](https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/) and [`kpng`](https://github.com/kubernetes-sigs/kpng) sub-projects.
|
||||
-->
|
||||
他现在是 Testing 特别兴趣小组的关键贡献者。他还活跃在 SIG Network 社区。最近，Rajas 为 [NetworkPolicy++](https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/) 和 [`kpng`](https://github.com/kubernetes-sigs/kpng) 子项目做出了重大贡献。
|
||||
|
||||
<!--
|
||||
One of the first challenges he ran across was that he was in a different time zone than the upstream project's regular meeting hours. However, async interactions on community forums progressively corrected that problem.
|
||||
-->
|
||||
他遇到的第一个挑战是，他所处的时区与上游项目的日常会议时间不同。不过，社区论坛上的异步交互逐渐解决了这个问题。
|
||||
|
||||
<!--
|
||||
> _I enjoy contributing to Kubernetes not just because I get to work on
|
||||
> cutting edge tech but more importantly because I get to work with
|
||||
> awesome people and help in solving real world problems._
|
||||
-->
|
||||
> _我喜欢为 kubernetes 做出贡献，不仅因为我可以从事尖端技术工作，更重要的是，我可以和优秀的人一起工作，并帮助解决现实问题。_
|
||||
|
||||
## [Rajula Vineet Reddy](https://github.com/rajula96reddy)
|
||||
|
||||
<!--
|
||||
Rajula Vineet Reddy, a Junior Engineer at CERN, is a member of the Marketing Council team under SIG ContribEx . He also served as a release shadow for SIG Release during the 1.22 and 1.23 Kubernetes release cycles.
|
||||
-->
|
||||
Rajula Vineet Reddy，CERN 的初级工程师，是 SIG ContribEx 项目下营销委员会的成员。在 Kubernetes 1.22 和 1.23 版本周期中，他还担任 SIG Release 的版本经理。
|
||||
|
||||
<!--
|
||||
He started looking at the Kubernetes project as part of a university project with the help of one of his professors. Over time, he spent a significant amount of time reading the project's documentation, Slack discussions, GitHub issues, and blogs, which helped him better grasp the Kubernetes project and piqued his interest in contributing upstream. One of his key contributions was his assistance with automation in the SIG ContribEx Upstream Marketing subproject.
|
||||
-->
|
||||
在他的一位教授的帮助下，他开始将 kubernetes 项目作为大学项目的一部分。慢慢地，他花费了大量的时间阅读项目的文档、Slack 讨论、GitHub issues 和博客，这有助于他更好地掌握 kubernetes 项目，并激发了他对上游项目做贡献的兴趣。他的主要贡献之一是他在SIG ContribEx上游营销子项目中协助实现了自动化。
|
||||
|
||||
<!--
|
||||
According to Rajula, attending project meetings and shadowing various project roles are vital for learning about the community.
|
||||
-->
|
||||
Rajas 说，参与项目会议和跟踪各种项目角色对于了解社区至关重要。
|
||||
|
||||
<!--
|
||||
> _I find the community very helpful and it's always_
|
||||
> “you get back as much as you contribute”.
|
||||
> _The more involved you are, the more you will understand, get to learn and
|
||||
> contribute new things._
|
||||
>
|
||||
> _The first step to_ “come forward and start” _is hard. But it's all gonna be
|
||||
> smooth after that. Just take that jump._
|
||||
-->
|
||||
> _我发现社区非常有帮助，而且总是“你得到的回报和你贡献的一样多”。你参与得越多，你就越会了解、学习和贡献新东西。_
|
||||
> _“挺身而出”的第一步是艰难的。但在那之后一切都会顺利的。勇敢地参与进来吧。_
|
||||
---
|
||||
|
||||
<!--
|
||||
If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. We're thrilled to have other folks assisting us in reaching out to even more wonderful individuals of the community. Your suggestions would be much appreciated.
|
||||
-->
|
||||
如果您对我们下一步应该采访谁有任何意见/建议，请在 #sig-contribex 中告知我们。我们很高兴有其他人帮助我们接触社区中更优秀的人。我们将不胜感激。
|
||||
|
||||
|
||||
<!--
|
||||
We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
|
||||
-->
|
||||
我们下期见。最后，祝大家都能快乐地为社区做贡献！👋
|
||||
|
||||
|
|
@ -0,0 +1,301 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Kubernetes 1.24 的删除和弃用"
|
||||
date: 2022-04-07
|
||||
slug: upcoming-changes-in-kubernetes-1-24
|
||||
---
|
||||
|
||||
<!--
|
||||
layout: blog
|
||||
title: "Kubernetes Removals and Deprecations In 1.24"
|
||||
date: 2022-04-07
|
||||
slug: upcoming-changes-in-kubernetes-1-24
|
||||
-->
|
||||
|
||||
<!--
|
||||
**Author**: Mickey Boxell (Oracle)
|
||||
|
||||
As Kubernetes evolves, features and APIs are regularly revisited and removed. New features may offer
|
||||
an alternative or improved approach to solving existing problems, motivating the team to remove the
|
||||
old approach.
|
||||
-->
|
||||
**作者**： Mickey Boxell (Oracle)
|
||||
|
||||
随着 Kubernetes 的发展，特性和 API 会定期被重新访问和删除。
|
||||
新特性可能会提供替代或改进的方法，来解决现有的问题，从而激励团队移除旧的方法。
|
||||
|
||||
<!--
|
||||
We want to make sure you are aware of the changes coming in the Kubernetes 1.24 release. The release will
|
||||
**deprecate** several (beta) APIs in favor of stable versions of the same APIs. The major change coming
|
||||
in the Kubernetes 1.24 release is the
|
||||
[removal of Dockershim](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim).
|
||||
This is discussed below and will be explored in more depth at release time. For an early look at the
|
||||
changes coming in Kubernetes 1.24, take a look at the in-progress
|
||||
[CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md).
|
||||
-->
|
||||
我们希望确保你了解 Kubernetes 1.24 版本的变化。 该版本将 **弃用** 一些（测试版/beta）API，
|
||||
转而支持相同 API 的稳定版本。 Kubernetes 1.24 版本的主要变化是
|
||||
[移除 Dockershim](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim)。
|
||||
这将在下面讨论，并将在发布时更深入地探讨。
|
||||
要提前了解 Kubernetes 1.24 中的更改，请查看正在更新中的
|
||||
[CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md)。
|
||||
|
||||
<!--
|
||||
## A note about Dockershim
|
||||
|
||||
It's safe to say that the removal receiving the most attention with the release of Kubernetes 1.24
|
||||
is Dockershim. Dockershim was deprecated in v1.20. As noted in the [Kubernetes 1.20 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation):
|
||||
"Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet
|
||||
uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance
|
||||
issues in the Kubernetes community." With the upcoming release of Kubernetes 1.24, the Dockershim will
|
||||
finally be removed.
|
||||
-->
|
||||
## 关于 Dockershim {#a-note-about-dockershim}
|
||||
|
||||
可以肯定地说，随着 Kubernetes 1.24 的发布，最受关注的删除是 Dockershim。
|
||||
Dockershim 在 1.20 版本中已被弃用。 如
|
||||
[Kubernetes 1.20 变更日志](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)中所述：
|
||||
"Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet
|
||||
uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance
|
||||
issues in the Kubernetes community."
|
||||
随着即将发布的 Kubernetes 1.24，Dockershim 将最终被删除。
|
||||
|
||||
<!--
|
||||
In the article [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/),
|
||||
the authors succinctly captured the change's impact and encouraged users to remain calm:
|
||||
> Docker as an underlying runtime is being deprecated in favor of runtimes that use the
|
||||
> Container Runtime Interface (CRI) created for Kubernetes. Docker-produced images
|
||||
> will continue to work in your cluster with all runtimes, as they always have.
|
||||
-->
|
||||
在文章[别慌: Kubernetes 和 Docker](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/) 中，
|
||||
作者简洁地记述了变化的影响，并鼓励用户保持冷静：
|
||||
>弃用 Docker 这个底层运行时，转而支持符合为 Kubernetes 创建的容器运行接口
|
||||
>Container Runtime Interface (CRI) 的运行时。
|
||||
>Docker 构建的镜像，将在你的集群的所有运行时中继续工作，一如既往。
|
||||
|
||||
<!--
|
||||
Several guides have been created with helpful information about migrating from dockershim
|
||||
to container runtimes that are directly compatible with Kubernetes. You can find them on the
|
||||
[Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/)
|
||||
page in the Kubernetes documentation.
|
||||
-->
|
||||
已经有一些文档指南，提供了关于从 dockershim 迁移到与 Kubernetes 直接兼容的容器运行时的有用信息。
|
||||
你可以在 Kubernetes 文档中的[从 dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)
|
||||
页面上找到它们。
|
||||
|
||||
<!--
|
||||
For more information about why Kubernetes is moving away from dockershim, check out the aptly
|
||||
named: [Kubernetes is Moving on From Dockershim](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)
|
||||
and the [updated dockershim removal FAQ](/blog/2022/02/17/dockershim-faq/).
|
||||
|
||||
Take a look at the [Is Your Cluster Ready for v1.24?](/blog/2022/03/31/ready-for-dockershim-removal/) post to learn about how to ensure your cluster continues to work after upgrading from v1.23 to v1.24.
|
||||
-->
|
||||
有关 Kubernetes 为何不再使用 dockershim 的更多信息，
|
||||
请参见：[Kubernetes 正在离开 Dockershim](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)
|
||||
和[最新的弃用 Dockershim 的常见问题](/zh/blog/2022/02/17/dockershim-faq/)。
|
||||
|
||||
查看[你的集群准备好使用 v1.24 了吗？](/blog/2022/03/31/ready-for-dockershim-removal/) 一文，
|
||||
了解如何确保你的集群在从 1.23 版本升级到 1.24 版本后继续工作。
|
||||
|
||||
<!--
|
||||
## The Kubernetes API removal and deprecation process
|
||||
|
||||
Kubernetes contains a large number of components that evolve over time. In some cases, this
|
||||
evolution results in APIs, flags, or entire features, being removed. To prevent users from facing
|
||||
breaking changes, Kubernetes contributors adopted a feature [deprecation policy](/docs/reference/using-api/deprecation-policy/).
|
||||
This policy ensures 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 as indicated by the following stability levels:
|
||||
|
||||
* 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.
|
||||
* Alpha or experimental API versions may be removed in any release without prior deprecation notice.
|
||||
-->
|
||||
## Kubernetes API 删除和弃用流程 {#the-Kubernetes-api-removal-and-deprecation-process}
|
||||
|
||||
Kubernetes 包含大量随时间演变的组件。在某些情况下，这种演变会导致 API、标志或整个特性被删除。
|
||||
为了防止用户面对重大变化，Kubernetes 贡献者采用了一项特性[弃用策略](/zh/docs/reference/using-api/deprecation-policy/)。
|
||||
此策略确保仅当同一 API 的较新稳定版本可用并且
|
||||
API 具有以下稳定性级别所指示的最短生命周期时，才可能弃用稳定版本 API：
|
||||
|
||||
* 正式发布 (GA) 或稳定的 API 版本可能被标记为已弃用，但不得在 Kubernetes 的主版本中删除。
|
||||
* 测试版（beta）或预发布 API 版本在弃用后必须支持 3 个版本。
|
||||
* Alpha 或实验性 API 版本可能会在任何版本中被删除，恕不另行通知。
|
||||
|
||||
<!--
|
||||
Removals follow the same deprecation policy regardless of whether an API is removed due to a beta feature
|
||||
graduating to stable or because that API was not proven to be successful. Kubernetes will continue to make
|
||||
sure migration options are documented whenever APIs are removed.
|
||||
-->
|
||||
删除遵循相同的弃用政策，无论 API 是由于 测试版（beta）功能逐渐稳定还是因为该
|
||||
API 未被证明是成功的而被删除。
|
||||
Kubernetes 将继续确保在删除 API 时提供用来迁移的文档。
|
||||
|
||||
<!--
|
||||
**Deprecated** APIs are those that have been marked for removal in a future Kubernetes release. **Removed**
|
||||
APIs are those that are no longer available for use in current, supported Kubernetes versions after having
|
||||
been deprecated. These removals have been superseded by newer, stable/generally available (GA) APIs.
|
||||
-->
|
||||
**弃用的** API 是指那些已标记为在未来 Kubernetes 版本中被删除的 API。
|
||||
**删除的** API 是指那些在被弃用后不再可用于当前受支持的 Kubernetes 版本的 API。
|
||||
这些删除已被更新的、稳定的/普遍可用的 (GA) API 所取代。
|
||||
|
||||
<!--
|
||||
## API removals, deprecations, and other changes for Kubernetes 1.24
|
||||
|
||||
* [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/). Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information.
|
||||
-->
|
||||
## Kubernetes 1.24 的 API 删除、弃用和其他更改 {#api-removals-deprecations-and-other-changes-for-kubernetes-1.24}
|
||||
|
||||
* [动态 kubelet 配置](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig`
|
||||
用于启用 kubelet 的动态配置。Kubernetes 1.22 中弃用 `DynamicKubeletConfig` 标志。
|
||||
在 1.24 版本中，此特性门控将从 kubelet 中移除。请参阅[重新配置 kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/)。
|
||||
更多详细信息，请参阅[“删除动态 kubelet 配置” 的 KEP](https://github.com/kubernetes/enhancements/issues/281)。
|
||||
<!--
|
||||
* [Dynamic log sanitization](https://github.com/kubernetes/kubernetes/pull/107207): The experimental dynamic log sanitization feature is deprecated and will be removed in v1.24. This feature introduced a logging filter that could be applied to all Kubernetes system components logs to prevent various types of sensitive information from leaking via logs. Refer to [KEP-1753: Kubernetes system components logs sanitization](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation) for more information and an [alternative approach](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#alternatives=).
|
||||
-->
|
||||
* [动态日志清洗](https://github.com/kubernetes/kubernetes/pull/107207)：实验性的动态日志清洗功能已被弃用，
|
||||
将在 1.24 版本中被删除。该功能引入了一个日志过滤器，可以应用于所有 Kubernetes 系统组件的日志，
|
||||
以防止各种类型的敏感信息通过日志泄漏。有关更多信息和替代方法，请参阅
|
||||
[KEP-1753: Kubernetes 系统组件日志清洗](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation)。
|
||||
<!--
|
||||
* In-tree provisioner to CSI driver migration: This applies to a number of in-tree plugins, including [Portworx](https://github.com/kubernetes/enhancements/issues/2589). Refer to the [In-tree Storage Plugin to CSI Migration Design Doc](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/csi-migration.md#background-and-motivations) for more information.
|
||||
-->
|
||||
* 树内驱动（In-tree provisioner）向 CSI 卷迁移：这适用于许多树内插件，
|
||||
包括 [Portworx](https://github.com/kubernetes/enhancements/issues/2589)。
|
||||
参见[树内存储插件向 CSI 卷迁移的设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/csi-migration.md#background-and-motivations)
|
||||
了解更多信息。
|
||||
<!--
|
||||
* [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/).
|
||||
-->
|
||||
* [从 kubelet 中移除 Dockershim](https://github.com/kubernetes/enhancements/issues/2221)：Docker
|
||||
的容器运行时接口(CRI)（即 Dockershim）目前是 kubelet 代码中内置的容器运行时。 它在 1.20 版本中已被弃用。
|
||||
从 1.24 版本开始，kubelet 已经移除 dockershim。 查看这篇博客，
|
||||
[了解你需要为 1.24 版本做些什么](/blog/2022/03/31/ready-for-dockershim-removal/)。
|
||||
<!--
|
||||
* [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information.
|
||||
-->
|
||||
* [pod 调度的存储容量追踪](https://github.com/kubernetes/enhancements/issues/1472)：CSIStorageCapacity API
|
||||
支持通过 CSIStorageCapacity 对象暴露当前可用的存储容量，并增强了使用带有延迟绑定的 CSI 卷的 Pod 的调度。
|
||||
CSIStorageCapacity API 自 1.24 版本起提供稳定版本。升级到稳定版的 API 将弃用 v1beta1 CSIStorageCapacity API。
|
||||
更多信息请参见 [Pod 调度存储容量约束 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking)。
|
||||
<!--
|
||||
* [The `master` label is no longer present on kubeadm control plane nodes](https://github.com/kubernetes/kubernetes/pull/107533). For new clusters, the label 'node-role.kubernetes.io/master' will no longer be added to control plane nodes, only the label 'node-role.kubernetes.io/control-plane' will be added. For more information, refer to [KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint).
|
||||
-->
|
||||
* [kubeadm 控制面节点上不再存在 `master` 标签](https://github.com/kubernetes/kubernetes/pull/107533)。
|
||||
对于新集群，控制平面节点将不再添加 'node-role.kubernetes.io/master' 标签，
|
||||
只会添加 'node-role.kubernetes.io/control-plane' 标签。更多信息请参考
|
||||
[KEP-2067：重命名 kubeadm “master” 标签和污点](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067)。
|
||||
<!--
|
||||
* [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, entered beta in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.21 and is now unsupported. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and [kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0) for more information.
|
||||
-->
|
||||
* [VolumeSnapshot v1beta1 CRD 在 1.24 版本中将被移除](https://github.com/kubernetes/enhancements/issues/177)。
|
||||
Kubernetes 和 [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI)
|
||||
的卷快照和恢复功能，在 1.20 版本中进入测试版。该功能提供标准化 API 设计 (CRD ) 并为 CSI 卷驱动程序添加了 PV 快照/恢复支持，
|
||||
VolumeSnapshot v1beta1 在 1.21 版本中已被弃用，现在不受支持。更多信息请参考
|
||||
[KEP-177：CSI 快照](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot)和
|
||||
[kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0)。
|
||||
<!--
|
||||
## What to do
|
||||
|
||||
### Dockershim removal
|
||||
|
||||
As stated earlier, there are several guides about
|
||||
[Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/).
|
||||
You can start with [Finding what container runtime are on your nodes](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
|
||||
If your nodes are using dockershim, there are other possible Docker Engine dependencies such as
|
||||
Pods or third-party tools executing Docker commands or private registries in the Docker configuration file. You can follow the
|
||||
[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) guide to review possible
|
||||
Docker Engine dependencies. Before upgrading to v1.24, you decide to either remain using Docker Engine and
|
||||
[Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) or migrate to a CRI-compatible runtime. Here's a guide to
|
||||
[change the container runtime on a node from Docker Engine to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/).
|
||||
-->
|
||||
## 需要做什么 {#what-to-do}
|
||||
|
||||
### 删除 Dockershim {#dockershim-removal}
|
||||
如前所述，有一些关于从 [dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。
|
||||
你可以[从查明节点上所使用的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)开始。
|
||||
如果你的节点使用 dockershim，则还有其他可能的 Docker Engine 依赖项，
|
||||
例如 Pod 或执行 Docker 命令的第三方工具或 Docker 配置文件中的私有注册表。
|
||||
你可以按照[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
|
||||
的指南来查看可能的 Docker 引擎依赖项。在升级到 1.24 版本之前， 你决定要么继续使用 Docker Engine 并
|
||||
[将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)，
|
||||
要么迁移到与 CRI 兼容的运行时。这是[将节点上的容器运行时从 Docker Engine 更改为 containerd](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/) 的指南。
|
||||
|
||||
<!--
|
||||
### `kubectl convert`
|
||||
|
||||
The [`kubectl convert`](/docs/tasks/tools/included/kubectl-convert-overview/) plugin for `kubectl`
|
||||
can be helpful to address migrating off deprecated APIs. The plugin facilitates the conversion of
|
||||
manifests between different API versions, for example, from a deprecated to a non-deprecated API
|
||||
version. More general information about the API migration process can be found in the [Deprecated API Migration Guide](/docs/reference/using-api/deprecation-guide/).
|
||||
Follow the [install `kubectl convert` plugin](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-convert-plugin)
|
||||
documentation to download and install the `kubectl-convert` binary.
|
||||
-->
|
||||
### `kubectl convert` {#kubectl-convert}
|
||||
|
||||
kubectl 的 [`kubectl convert`](/zh/docs/tasks/tools/included/kubectl-convert-overview/)
|
||||
插件有助于解决弃用 API 的迁移问题。该插件方便了不同 API 版本之间清单的转换，
|
||||
例如，从弃用的 API 版本到非弃用的 API 版本。关于 API 迁移过程的更多信息可以在
|
||||
[已弃用 API 的迁移指南](/docs/reference/using-api/deprecation-guide/)中找到。按照
|
||||
[安装 `kubectl convert` 插件](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-convert-plugin)
|
||||
文档下载并安装 `kubectl-convert` 二进制文件。
|
||||
|
||||
<!--
|
||||
### Looking ahead
|
||||
|
||||
The Kubernetes 1.25 and 1.26 releases planned for later this year will stop serving beta versions
|
||||
of several currently stable Kubernetes APIs. The v1.25 release will also remove PodSecurityPolicy,
|
||||
which was deprecated with Kubernetes 1.21 and will not graduate to stable. See [PodSecurityPolicy
|
||||
Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) for more information.
|
||||
-->
|
||||
### 展望未来 {#looking-ahead}
|
||||
|
||||
计划在今年晚些时候发布的 Kubernetes 1.25 和 1.26 版本，将停止提供一些
|
||||
Kubernetes API 的 beta 版本，这些 API 当前为稳定版。1.25 版本还将删除 PodSecurityPolicy，
|
||||
它已在 Kubernetes 1.21 版本中被弃用，并且不会升级到稳定版。有关详细信息，请参阅
|
||||
[PodSecurityPolicy 弃用：过去、现在和未来](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
|
||||
|
||||
<!--
|
||||
The official [list of API removals planned for Kubernetes 1.25](/docs/reference/using-api/deprecation-guide/#v1-25) is:
|
||||
-->
|
||||
[Kubernetes 1.25 计划移除的 API 的官方列表](/zh/docs/reference/using-api/deprecation-guide/#v1-25)是：
|
||||
|
||||
* The beta CronJob API (batch/v1beta1)
|
||||
* The beta EndpointSlice API (discovery.k8s.io/v1beta1)
|
||||
* The beta Event API (events.k8s.io/v1beta1)
|
||||
* The beta HorizontalPodAutoscaler API (autoscaling/v2beta1)
|
||||
* The beta PodDisruptionBudget API (policy/v1beta1)
|
||||
* The beta PodSecurityPolicy API (policy/v1beta1)
|
||||
* The beta RuntimeClass API (node.k8s.io/v1beta1)
|
||||
|
||||
<!--
|
||||
The official [list of API removals planned for Kubernetes 1.26](/docs/reference/using-api/deprecation-guide/#v1-26) is:
|
||||
|
||||
* The beta FlowSchema and PriorityLevelConfiguration APIs (flowcontrol.apiserver.k8s.io/v1beta1)
|
||||
* The beta HorizontalPodAutoscaler API (autoscaling/v2beta2)
|
||||
-->
|
||||
[Kubernetes 1.25 计划移除的 API 的官方列表](/zh/docs/reference/using-api/deprecation-guide/#v1-25)是：
|
||||
|
||||
* The beta FlowSchema 和 PriorityLevelConfiguration API (flowcontrol.apiserver.k8s.io/v1beta1)
|
||||
* The beta HorizontalPodAutoscaler API (autoscaling/v2beta2)
|
||||
|
||||
<!--
|
||||
### Want to know more?
|
||||
Deprecations are announced in the Kubernetes release notes. You can see the announcements of pending deprecations in the release notes for:
|
||||
* [Kubernetes 1.21](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#deprecation)
|
||||
* [Kubernetes 1.22](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#deprecation)
|
||||
* [Kubernetes 1.23](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#deprecation)
|
||||
* We will formally announce the deprecations that come with [Kubernetes 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) as part of the CHANGELOG for that release.
|
||||
|
||||
For information on the process of deprecation and removal, check out the official Kubernetes [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) document.
|
||||
-->
|
||||
### 了解更多 {#want-to-know-more}
|
||||
Kubernetes 发行说明中宣告了弃用信息。你可以在以下版本的发行说明中看到待弃用的公告：
|
||||
* [Kubernetes 1.21](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#deprecation)
|
||||
* [Kubernetes 1.22](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#deprecation)
|
||||
* [Kubernetes 1.23](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#deprecation)
|
||||
* 我们将正式宣布 [Kubernetes 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) 的弃用信息，
|
||||
作为该版本 CHANGELOG 的一部分。
|
||||
|
||||
有关弃用和删除过程的信息，请查看 Kubernetes 官方[弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) 文档。
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue