Merge branch 'kubernetes:main' into main
BAKPATINA Vincent de Paul
GitHub
commit
8123979fcd
|
|
@ -32,7 +32,7 @@ aliases:
|
|||
- bradtopol
|
||||
- divya-mohan0209
|
||||
- kbhawkey
|
||||
- krol3
|
||||
- mickeyboxell
|
||||
- natalisucks
|
||||
- nate-double-u
|
||||
- onlydole
|
||||
|
|
|
|||
|
|
@ -81,9 +81,9 @@ Du kannst auch einen Slack-Kanal für deine Lokalisierung im `kubernetes/communi
|
|||
|
||||
### Ändere die Website-Konfiguration
|
||||
|
||||
Die Kubernetes-Website verwendet Hugo als Web-Framework. Die Hugo-Konfiguration der Website befindet sich in der Datei [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml). Um eine neue Lokalisierung zu unterstützen, musst du die Datei `config.toml` modifizieren.
|
||||
Die Kubernetes-Website verwendet Hugo als Web-Framework. Die Hugo-Konfiguration der Website befindet sich in der Datei [`hugo.toml`](https://github.com/kubernetes/website/tree/master/hugo.toml). Um eine neue Lokalisierung zu unterstützen, musst du die Datei `hugo.toml` modifizieren.
|
||||
|
||||
Dazu fügst du einen neuen Block für die neue Sprache unter den bereits existierenden `[languages]` Block in das `config.toml` ein, wie folgendes Beispiel zeigt:
|
||||
Dazu fügst du einen neuen Block für die neue Sprache unter den bereits existierenden `[languages]` Block in das `hugo.toml` ein, wie folgendes Beispiel zeigt:
|
||||
|
||||
```toml
|
||||
[languages.de]
|
||||
|
|
|
|||
|
|
@ -62,7 +62,16 @@ imageRepository: "k8s.gcr.io"
|
|||
|
||||
### Reverting the Registry Name in kubelet
|
||||
|
||||
The image used by kubelet for the pod sandbox (`pause`) can be overridden by setting the `--pod-infra-container-image` flag. For example:
|
||||
The image used by kubelet for the pod sandbox (`pause`) can be overridden
|
||||
by configuring your container runtime or by setting the `--pod-infra-container-image`
|
||||
flag depending on the version of Kubernetes you are using.
|
||||
|
||||
Other runtimes:
|
||||
[containerd](/docs/setup/production-environment/container-runtimes/#override-pause-image-containerd),
|
||||
[CRI-O](/docs/setup/production-environment/container-runtimes/#override-pause-image-cri-o),
|
||||
[cri-dockerd](/docs/setup/production-environment/container-runtimes/#override-pause-image-cri-dockerd-mcr).
|
||||
|
||||
When using dockershim before v1.23:
|
||||
|
||||
```
|
||||
kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5
|
||||
|
|
|
|||
|
|
@ -7,16 +7,21 @@ slug: retroactive-default-storage-class
|
|||
|
||||
**Author:** Roman Bednář (Red Hat)
|
||||
|
||||
The v1.25 release of Kubernetes introduced an alpha feature to change how a default StorageClass was assigned to a PersistentVolumeClaim (PVC).
|
||||
With the feature enabled, you no longer need to create a default StorageClass first and PVC second to assign the class. Additionally, any PVCs without a StorageClass assigned can be updated later.
|
||||
The v1.25 release of Kubernetes introduced an alpha feature to change how a default
|
||||
StorageClass was assigned to a PersistentVolumeClaim (PVC). With the feature enabled,
|
||||
you no longer need to create a default StorageClass first and PVC second to assign the
|
||||
class. Additionally, any PVCs without a StorageClass assigned can be updated later.
|
||||
This feature was graduated to beta in Kubernetes 1.26.
|
||||
|
||||
You can read [retroactive default StorageClass assignment](/docs/concepts/storage/persistent-volumes/#retroactive-default-storageclass-assignment) in the Kubernetes documentation for more details about how to use that,
|
||||
You can read [retroactive default StorageClass assignment](/docs/concepts/storage/persistent-volumes/#retroactive-default-storageclass-assignment)
|
||||
in the Kubernetes documentation for more details about how to use that,
|
||||
or you can read on to learn about why the Kubernetes project is making this change.
|
||||
|
||||
## Why did StorageClass assignment need improvements
|
||||
|
||||
Users might already be familiar with a similar feature that assigns default StorageClasses to **new** PVCs at the time of creation. This is currently handled by the [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass).
|
||||
Users might already be familiar with a similar feature that assigns default StorageClasses
|
||||
to **new** PVCs at the time of creation. This is currently handled by the
|
||||
[admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass).
|
||||
|
||||
But what if there wasn't a default StorageClass defined at the time of PVC creation?
|
||||
Users would end up with a PVC that would never be assigned a class.
|
||||
|
|
@ -29,33 +34,47 @@ Let's take a closer look at each of them.
|
|||
With the alpha feature enabled, there were two options admins had when they wanted to change the default StorageClass:
|
||||
|
||||
1. Creating a new StorageClass as default before removing the old one associated with the PVC.
|
||||
This would result in having two defaults for a short period.
|
||||
At this point, if a user were to create a PersistentVolumeClaim with storageClassName set to <code>null</code> (implying default StorageClass), the newest default StorageClass would be chosen and assigned to this PVC.
|
||||
This would result in having two defaults for a short period.
|
||||
At this point, if a user were to create a PersistentVolumeClaim with storageClassName set to
|
||||
<code>null</code> (implying default StorageClass), the newest default StorageClass would be
|
||||
chosen and assigned to this PVC.
|
||||
|
||||
2. Removing the old default first and creating a new default StorageClass.
|
||||
This would result in having no default for a short time.
|
||||
Subsequently, if a user were to create a PersistentVolumeClaim with storageClassName set to <code>null</code> (implying default StorageClass), the PVC would be in <code>Pending</code> state forever.
|
||||
The user would have to fix this by deleting the PVC and recreating it once the default StorageClass was available.
|
||||
|
||||
This would result in having no default for a short time.
|
||||
Subsequently, if a user were to create a PersistentVolumeClaim with storageClassName
|
||||
set to <code>null</code> (implying default StorageClass), the PVC would be in
|
||||
<code>Pending</code> state forever. The user would have to fix this by deleting
|
||||
the PVC and recreating it once the default StorageClass was available.
|
||||
|
||||
### Resource ordering during cluster installation
|
||||
|
||||
If a cluster installation tool needed to create resources that required storage, for example, an image registry, it was difficult to get the ordering right.
|
||||
This is because any Pods that required storage would rely on the presence of a default StorageClass and would fail to be created if it wasn't defined.
|
||||
If a cluster installation tool needed to create resources that required storage,
|
||||
for example, an image registry, it was difficult to get the ordering right.
|
||||
This is because any Pods that required storage would rely on the presence of
|
||||
a default StorageClass and would fail to be created if it wasn't defined.
|
||||
|
||||
## What changed
|
||||
|
||||
We've changed the PersistentVolume (PV) controller to assign a default StorageClass to any unbound PersistentVolumeClaim that has the storageClassName set to <code>null</code>.
|
||||
We've also modified the PersistentVolumeClaim admission within the API server to allow the change of values from an unset value to an actual StorageClass name.
|
||||
We've changed the PersistentVolume (PV) controller to assign a default StorageClass
|
||||
to any unbound PersistentVolumeClaim that has the storageClassName set to <code>null</code>.
|
||||
We've also modified the PersistentVolumeClaim admission within the API server to allow
|
||||
the change of values from an unset value to an actual StorageClass name.
|
||||
|
||||
### Null `storageClassName` versus `storageClassName: ""` - does it matter? { #null-vs-empty-string }
|
||||
|
||||
Before this feature was introduced, those values were equal in terms of behavior. Any PersistentVolumeClaim with the storageClassName set to <code>null</code> or <code>""</code> would bind to an existing PersistentVolume resource with storageClassName also set to <code>null</code> or <code>""</code>.
|
||||
Before this feature was introduced, those values were equal in terms of behavior.
|
||||
Any PersistentVolumeClaim with the storageClassName set to <code>null</code> or <code>""</code>
|
||||
would bind to an existing PersistentVolume resource with storageClassName also set to
|
||||
<code>null</code> or <code>""</code>.
|
||||
|
||||
With this new feature enabled we wanted to maintain this behavior but also be able to update the StorageClass name.
|
||||
With these constraints in mind, the feature changes the semantics of <code>null</code>. If a default StorageClass is present, <code>null</code> would translate to "Give me a default" and <code>""</code> would mean "Give me PersistentVolume that also has <code>""</code> StorageClass name." In the absence of a StorageClass, the behavior would remain unchanged.
|
||||
With these constraints in mind, the feature changes the semantics of <code>null</code>.
|
||||
If a default StorageClass is present, <code>null</code> would translate to "Give me a default" and
|
||||
<code>""</code> would mean "Give me PersistentVolume that also has <code>""</code> StorageClass name."
|
||||
In the absence of a StorageClass, the behavior would remain unchanged.
|
||||
|
||||
Summarizing the above, we've changed the semantics of <code>null</code> so that its behavior depends on the presence or absence of a definition of default StorageClass.
|
||||
Summarizing the above, we've changed the semantics of <code>null</code> so that
|
||||
its behavior depends on the presence or absence of a definition of default StorageClass.
|
||||
|
||||
The tables below show all these cases to better describe when PVC binds and when its StorageClass gets updated.
|
||||
|
||||
|
|
@ -96,7 +115,9 @@ The tables below show all these cases to better describe when PVC binds and when
|
|||
|
||||
## How to use it
|
||||
|
||||
If you want to test the feature whilst it's alpha, you need to enable the relevant feature gate in the kube-controller-manager and the kube-apiserver. Use the `--feature-gates` command line argument:
|
||||
If you want to test the feature whilst it's alpha, you need to enable the relevant
|
||||
feature gate in the kube-controller-manager and the kube-apiserver.
|
||||
Use the `--feature-gates` command line argument:
|
||||
|
||||
```
|
||||
--feature-gates="...,RetroactiveDefaultStorageClass=true"
|
||||
|
|
@ -121,7 +142,9 @@ If you would like to see the feature in action and verify it works fine in your
|
|||
storage: 1Gi
|
||||
```
|
||||
|
||||
2. Create the PersistentVolumeClaim when there is no default StorageClass. The PVC won't provision or bind (unless there is an existing, suitable PV already present) and will remain in <code>Pending</code> state.
|
||||
2. Create the PersistentVolumeClaim when there is no default StorageClass.
|
||||
The PVC won't provision or bind (unless there is an existing, suitable PV already present)
|
||||
and will remain in <code>Pending</code> state.
|
||||
|
||||
```
|
||||
$ kc get pvc
|
||||
|
|
@ -146,11 +169,15 @@ If you would like to see the feature in action and verify it works fine in your
|
|||
|
||||
### New metrics
|
||||
|
||||
To help you see that the feature is working as expected we also introduced a new <code>retroactive_storageclass_total</code> metric to show how many times that the PV controller attempted to update PersistentVolumeClaim, and <code>retroactive_storageclass_errors_total</code> to show how many of those attempts failed.
|
||||
To help you see that the feature is working as expected we also introduced a new
|
||||
<code>retroactive_storageclass_total</code> metric to show how many times that the
|
||||
PV controller attempted to update PersistentVolumeClaim, and
|
||||
<code>retroactive_storageclass_errors_total</code> to show how many of those attempts failed.
|
||||
|
||||
## Getting involved
|
||||
|
||||
We always welcome new contributors so if you would like to get involved you can join our [Kubernetes Storage Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG).
|
||||
We always welcome new contributors so if you would like to get involved you can
|
||||
join our [Kubernetes Storage Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG).
|
||||
|
||||
If you would like to share feedback, you can do so on our [public Slack channel](https://app.slack.com/client/T09NY5SBT/C09QZFCE5).
|
||||
|
||||
|
|
|
|||
|
|
@ -7,18 +7,35 @@ slug: k8s-gcr-io-freeze-announcement
|
|||
|
||||
**Authors**: Mahamed Ali (Rackspace Technology)
|
||||
|
||||
The Kubernetes project runs a community-owned image registry called `registry.k8s.io` to host its container images. On the 3rd of April 2023, the old registry `k8s.gcr.io` will be frozen and no further images for Kubernetes and related subprojects will be pushed to the old registry.
|
||||
The Kubernetes project runs a community-owned image registry called `registry.k8s.io`
|
||||
to host its container images. On the 3rd of April 2023, the old registry `k8s.gcr.io`
|
||||
will be frozen and no further images for Kubernetes and related subprojects will be
|
||||
pushed to the old registry.
|
||||
|
||||
This registry `registry.k8s.io` replaced the old one and has been generally available for several months. We have published a [blog post](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/) about its benefits to the community and the Kubernetes project. This post also announced that future versions of Kubernetes will not be available in the old registry. Now that time has come.
|
||||
This registry `registry.k8s.io` replaced the old one and has been generally available
|
||||
for several months. We have published a [blog post](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/)
|
||||
about its benefits to the community and the Kubernetes project. This post also
|
||||
announced that future versions of Kubernetes will not be available in the old
|
||||
registry. Now that time has come.
|
||||
|
||||
What does this change mean for contributors:
|
||||
- If you are a maintainer of a subproject, you will need to update your manifests and Helm charts to use the new registry.
|
||||
|
||||
- If you are a maintainer of a subproject, you will need to update your manifests
|
||||
and Helm charts to use the new registry.
|
||||
|
||||
What does this change mean for end users:
|
||||
|
||||
- 1.27 Kubernetes release will not be published to the old registry.
|
||||
- Patch releases for 1.24, 1.25, and 1.26 will no longer be published to the old registry from April. Please read the timelines below for details of the final patch releases in the old registry.
|
||||
- Starting in 1.25, the default image registry has been set to `registry.k8s.io`. This value is overridable in `kubeadm` and `kubelet` but setting it to `k8s.gcr.io` will fail for new releases after April as they won’t be present in the old registry.
|
||||
- If you want to increase the reliability of your cluster and remove dependency on the community-owned registry or you are running Kubernetes in networks where external traffic is restricted, you should consider hosting local image registry mirrors. Some cloud vendors may offer hosted solutions for this.
|
||||
- Patch releases for 1.24, 1.25, and 1.26 will no longer be published to the old
|
||||
registry from April. Please read the timelines below for details of the final
|
||||
patch releases in the old registry.
|
||||
- Starting in 1.25, the default image registry has been set to `registry.k8s.io`.
|
||||
This value is overridable in `kubeadm` and `kubelet` but setting it to `k8s.gcr.io`
|
||||
will fail for new releases after April as they won’t be present in the old registry.
|
||||
- If you want to increase the reliability of your cluster and remove dependency on
|
||||
the community-owned registry or you are running Kubernetes in networks where
|
||||
external traffic is restricted, you should consider hosting local image registry
|
||||
mirrors. Some cloud vendors may offer hosted solutions for this.
|
||||
|
||||
## Timeline of the changes
|
||||
|
||||
|
|
@ -31,8 +48,8 @@ What does this change mean for end users:
|
|||
|
||||
## What's next
|
||||
|
||||
Please make sure your cluster does not have dependencies on old image registry. For example, you can run this command to list the images used by pods:
|
||||
|
||||
Please make sure your cluster does not have dependencies on old image registry.
|
||||
For example, you can run this command to list the images used by pods:
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
|
||||
|
|
@ -41,10 +58,22 @@ sort |\
|
|||
uniq -c
|
||||
```
|
||||
|
||||
There may be other dependencies on the old image registry. Make sure you review any potential dependencies to keep your cluster healthy and up to date.
|
||||
There may be other dependencies on the old image registry. Make sure you review
|
||||
any potential dependencies to keep your cluster healthy and up to date.
|
||||
|
||||
## Acknowledgments
|
||||
|
||||
__Change is hard__, and evolving our image-serving platform is needed to ensure a sustainable future for the project. We strive to make things better for everyone using Kubernetes. Many contributors from all corners of our community have been working long and hard to ensure we are making the best decisions possible, executing plans, and doing our best to communicate those plans.
|
||||
__Change is hard__, and evolving our image-serving platform is needed to ensure
|
||||
a sustainable future for the project. We strive to make things better for everyone
|
||||
using Kubernetes. Many contributors from all corners of our community have been
|
||||
working long and hard to ensure we are making the best decisions possible,
|
||||
executing plans, and doing our best to communicate those plans.
|
||||
|
||||
Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen, and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from the Security Response Committee. Also a big thank you to our friends acting as liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson Jr. from Google.
|
||||
Thanks to Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine,
|
||||
Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen,
|
||||
and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle,
|
||||
Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from
|
||||
SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from
|
||||
the Security Response Committee. Also a big thank you to our friends acting as
|
||||
liaisons with our cloud provider partners: Jay Pipes from Amazon and Jon Johnson
|
||||
Jr. from Google.
|
||||
|
|
|
|||
|
|
@ -205,6 +205,12 @@ The v1.25 release of Kubernetes also stabilised surge support for DaemonSet pods
|
|||
implemented in order to minimize DaemonSet downtime during rollouts.
|
||||
The `DaemonSetUpdateSurge` feature gate will be removed in Kubernetes v1.27.
|
||||
|
||||
### Removal of `--container-runtime` command line argument
|
||||
|
||||
The kubelet accepts a deprecated command line argument, `--container-runtime`, and the only
|
||||
valid value would be `remote` after dockershim code is removed. Kubernetes v1.27 will remove
|
||||
that argument, which has been deprecated since the v1.24 release.
|
||||
|
||||
## Looking ahead
|
||||
|
||||
The official list of
|
||||
|
|
|
|||
|
|
@ -206,24 +206,21 @@ rules:
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
has instructions on running and managing the cloud controller manager.
|
||||
* [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
has instructions on running and managing the cloud controller manager.
|
||||
|
||||
To upgrade a HA control plane to use the cloud controller manager, see
|
||||
[Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
|
||||
* To upgrade a HA control plane to use the cloud controller manager, see
|
||||
[Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
|
||||
|
||||
Want to know how to implement your own cloud controller manager, or extend an existing project?
|
||||
|
||||
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in.
|
||||
Specifically, it uses the `CloudProvider` interface defined in
|
||||
[`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69) from
|
||||
[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
|
||||
|
||||
The implementation of the shared controllers highlighted in this document (Node, Route, and Service),
|
||||
and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core.
|
||||
Implementations specific to cloud providers are outside the core of Kubernetes and implement the
|
||||
`CloudProvider` interface.
|
||||
|
||||
For more information about developing plugins, see
|
||||
[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
* Want to know how to implement your own cloud controller manager, or extend an existing project?
|
||||
|
||||
- The cloud controller manager uses Go interfaces, specifically, `CloudProvider` interface defined in
|
||||
[`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)
|
||||
from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider) to allow
|
||||
implementations from any cloud to be plugged in.
|
||||
- The implementation of the shared controllers highlighted in this document (Node, Route, and Service),
|
||||
and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core.
|
||||
Implementations specific to cloud providers are outside the core of Kubernetes and implement
|
||||
the `CloudProvider` interface.
|
||||
- For more information about developing plugins,
|
||||
see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
|
|
@ -805,7 +805,7 @@ memory limit (and possibly request) for that container.
|
|||
* Get hands-on experience [assigning CPU resources to containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
|
||||
* Read how the API reference defines a [container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)
|
||||
and its [resource requirements](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)
|
||||
* Read about [project quotas](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F) in XFS
|
||||
* Read about [project quotas](https://www.linux.org/docs/man8/xfs_quota.html) in XFS
|
||||
* Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
* Read more about [Quality of Service classes for Pods](/docs/concepts/workloads/pods/pod-qos/)
|
||||
|
||||
|
|
|
|||
|
|
@ -178,14 +178,25 @@ following methods:
|
|||
rotates the token before it expires.
|
||||
* [Service Account Token Secrets](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
|
||||
(not recommended): You can mount service account tokens as Kubernetes
|
||||
Secrets in Pods. These tokens don't expire and don't rotate. This method
|
||||
is not recommended, especially at scale, because of the risks associated
|
||||
Secrets in Pods. These tokens don't expire and don't rotate.
|
||||
This method is not recommended, especially at scale, because of the risks associated
|
||||
with static, long-lived credentials. In Kubernetes v1.24 and later, the
|
||||
[LegacyServiceAccountTokenNoAutoGeneration feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features)
|
||||
prevents Kubernetes from automatically creating these tokens for
|
||||
ServiceAccounts. `LegacyServiceAccountTokenNoAutoGeneration` is enabled
|
||||
by default; in other words, Kubernetes does not create these tokens.
|
||||
|
||||
{{< note >}}
|
||||
For applications running outside your Kubernetes cluster, you might be considering
|
||||
creating a long-lived ServiceAccount token that is stored in a Secret. This allows authentication, but the Kubernetes project recommends you avoid this approach.
|
||||
Long-lived bearer tokens represent a security risk as, once disclosed, the token
|
||||
can be misused. Instead, consider using an alternative. For example, your external
|
||||
application can authenticate using a well-protected private key `and` a certificate,
|
||||
or using a custom mechanism such as an [authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) that you implement yourself.
|
||||
|
||||
You can also use TokenRequest to obtain short-lived tokens for your external application.
|
||||
{{< /note >}}
|
||||
|
||||
## Authenticating service account credentials {#authenticating-credentials}
|
||||
|
||||
ServiceAccounts use signed
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ that Deployment can create and destroy Pods dynamically. From one moment to the
|
|||
you don't know how many of those Pods are working and healthy; you might not even know
|
||||
what those healthy Pods are named.
|
||||
Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed
|
||||
to match the desired state of your cluster. Pods are emphemeral resources (you should not
|
||||
to match the desired state of your cluster. Pods are ephemeral resources (you should not
|
||||
expect that an individual Pod is reliable and durable).
|
||||
|
||||
Each Pod gets its own IP address (Kubernetes expects network plugins to ensure this).
|
||||
|
|
@ -139,6 +139,8 @@ for convenience, the `targetPort` is set to the same value as the `port`
|
|||
field.
|
||||
{{< /note >}}
|
||||
|
||||
### Port definitions {#field-spec-ports}
|
||||
|
||||
Port definitions in Pods have names, and you can reference these names in the
|
||||
`targetPort` attribute of a Service. For example, we can bind the `targetPort`
|
||||
of the Service to the Pod port in the following way:
|
||||
|
|
@ -184,8 +186,8 @@ The default protocol for Services is
|
|||
[TCP](/docs/reference/networking/service-protocols/#protocol-tcp); you can also
|
||||
use any other [supported protocol](/docs/reference/networking/service-protocols/).
|
||||
|
||||
As many Services need to expose more than one port, Kubernetes supports multiple
|
||||
port definitions on a Service object.
|
||||
Because many Services need to expose more than one port, Kubernetes supports
|
||||
[multiple port definitions](#multi-port-services) for a single Service.
|
||||
Each port definition can have the same `protocol`, or a different one.
|
||||
|
||||
### Services without selectors
|
||||
|
|
@ -353,7 +355,7 @@ This field follows standard Kubernetes label syntax. Values should either be
|
|||
[IANA standard service names](https://www.iana.org/assignments/service-names) or
|
||||
domain prefixed names such as `mycompany.com/my-custom-protocol`.
|
||||
|
||||
## Multi-Port Services
|
||||
### Multi-port Services
|
||||
|
||||
For some Services, you need to expose more than one port.
|
||||
Kubernetes lets you configure multiple port definitions on a Service object.
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ the existing Pods based on the
|
|||
[priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)
|
||||
of the new Pod.
|
||||
|
||||
The user can specify a different scheduler for the Pods of the DamonSet, by
|
||||
The user can specify a different scheduler for the Pods of the DaemonSet, by
|
||||
setting the `.spec.template.spec.schedulerName` field of the DaemonSet.
|
||||
|
||||
The original node affinity specified at the
|
||||
|
|
@ -155,7 +155,7 @@ text="tolerations" term_id="toleration" >}} to DaemonSet Pods:
|
|||
|
||||
{{< /table >}}
|
||||
|
||||
You can add your own tolerations to the Pods of a Daemonset as well, by
|
||||
You can add your own tolerations to the Pods of a DaemonSet as well, by
|
||||
defining these in the Pod template of the DaemonSet.
|
||||
|
||||
Because the DaemonSet controller sets the
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ Certain behavior is independent of the QoS class assigned by Kubernetes. For exa
|
|||
* Learn about [resource management for Pods and Containers](/docs/concepts/configuration/manage-resources-containers/).
|
||||
* Learn about [Node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
* Learn about [Pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/).
|
||||
* Learn about [Pod disruptions](/docs/concepts/workload/pods/disruptions/).
|
||||
* Learn about [Pod disruptions](/docs/concepts/workloads/pods/disruptions/).
|
||||
* Learn how to [assign memory resources to containers and pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
|
||||
* Learn how to [assign CPU resources to containers and pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
|
||||
* Learn how to [configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/).
|
||||
|
|
|
|||
|
|
@ -141,6 +141,11 @@ to obtain short-lived API access tokens is recommended instead.
|
|||
|
||||
## Control plane details
|
||||
|
||||
### ServiceAccount controller
|
||||
|
||||
A ServiceAccount controller manages the ServiceAccounts inside namespaces, and
|
||||
ensures a ServiceAccount named "default" exists in every active namespace.
|
||||
|
||||
### Token controller
|
||||
|
||||
The service account token controller runs as part of `kube-controller-manager`.
|
||||
|
|
@ -366,34 +371,6 @@ If you created a namespace `examplens` to experiment with, you can remove it:
|
|||
kubectl delete namespace examplens
|
||||
```
|
||||
|
||||
## Control plane details
|
||||
|
||||
### ServiceAccount controller
|
||||
|
||||
A ServiceAccount controller manages the ServiceAccounts inside namespaces, and
|
||||
ensures a ServiceAccount named "default" exists in every active namespace.
|
||||
|
||||
### Token controller
|
||||
|
||||
The service account token controller runs as part of `kube-controller-manager`.
|
||||
This controller acts asynchronously. It:
|
||||
|
||||
- watches for ServiceAccount creation and creates a corresponding
|
||||
ServiceAccount token Secret to allow API access.
|
||||
- watches for ServiceAccount deletion and deletes all corresponding ServiceAccount
|
||||
token Secrets.
|
||||
- watches for ServiceAccount token Secret addition, and ensures the referenced
|
||||
ServiceAccount exists, and adds a token to the Secret if needed.
|
||||
- watches for Secret deletion and removes a reference from the corresponding
|
||||
ServiceAccount if needed.
|
||||
|
||||
You must pass a service account private key file to the token controller in
|
||||
the `kube-controller-manager` using the `--service-account-private-key-file`
|
||||
flag. The private key is used to sign generated service account tokens.
|
||||
Similarly, you must pass the corresponding public key to the `kube-apiserver`
|
||||
using the `--service-account-key-file` flag. The public key will be used to
|
||||
verify the tokens during authentication.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Read more details about [projected volumes](/docs/concepts/storage/projected-volumes/).
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ id: statefulset
|
|||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/statefulset/
|
||||
short_description: >
|
||||
Manages deployment and scaling of a set of Pods, with durable storage and persistent identifiers for each Pod.
|
||||
A StatefulSet manages deployment and scaling of a set of Pods, with durable storage and persistent identifiers for each Pod.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
|
|
@ -17,6 +17,6 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Like a {{< glossary_tooltip term_id="deployment" >}}, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
|
||||
Like a {{< glossary_tooltip term_id="deployment" >}}, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
|
||||
|
||||
If you want to use storage volumes to provide persistence for your workload, you can use a StatefulSet as part of the solution. Although individual Pods in a StatefulSet are susceptible to failure, the persistent Pod identifiers make it easier to match existing volumes to the new Pods that replace any that have failed.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ A node selector requirement is a selector that contains values, a key, and an op
|
|||
|
||||
- **operator** (string), required
|
||||
|
||||
Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. Gt, and Lt.
|
||||
Represents a key's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist, Gt, and Lt.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -177,8 +177,9 @@ follow [configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/conf
|
|||
|
||||
Your container runtime must support at least v1alpha2 of the container runtime interface.
|
||||
|
||||
Kubernetes {{< skew currentVersion >}} defaults to using v1 of the CRI API.
|
||||
If a container runtime does not support the v1 API, the kubelet falls back to
|
||||
Kubernetes [starting v1.26](/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal)
|
||||
_only works_ with v1 of the CRI API. Earlier versions default
|
||||
to v1 version, however if a container runtime does not support the v1 API, the kubelet falls back to
|
||||
using the (deprecated) v1alpha2 API instead.
|
||||
|
||||
## Container runtimes
|
||||
|
|
@ -189,9 +190,7 @@ using the (deprecated) v1alpha2 API instead.
|
|||
|
||||
This section outlines the necessary steps to use containerd as CRI runtime.
|
||||
|
||||
Use the following commands to install Containerd on your system:
|
||||
|
||||
Follow the instructions for [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). Return to this step once you've created a valid configuration file, `config.toml`.
|
||||
To install containerd on your system, follow the instructions on [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md).Return to this step once you've created a valid `config.toml` configuration file.
|
||||
|
||||
{{< tabs name="Finding your config.toml file" >}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
|
@ -255,6 +254,11 @@ sandbox image by setting the following config:
|
|||
|
||||
You might need to restart `containerd` as well once you've updated the config file: `systemctl restart containerd`.
|
||||
|
||||
Please note, that it is a best practice for kubelet to declare the matching `pod-infra-container-image`.
|
||||
If not configured, kubelet may attempt to garbage collect the `pause` image.
|
||||
There is ongoing work in [containerd to pin the pause image](https://github.com/containerd/containerd/issues/6352)
|
||||
and not require this setting on kubelet any longer.
|
||||
|
||||
### CRI-O
|
||||
|
||||
This section contains the necessary steps to install CRI-O as a container runtime.
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ resources:
|
|||
```
|
||||
|
||||
Each `resources` array item is a separate config and contains a complete configuration. The
|
||||
`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group`
|
||||
`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group`)
|
||||
that should be encrypted like Secrets, ConfigMaps, or other resources.
|
||||
|
||||
If custom resources are added to `EncryptionConfiguration` and the cluster version is 1.26 or newer,
|
||||
|
|
|
|||
|
|
@ -19,10 +19,15 @@ Dockershim was removed from Kubernetes with the release of v1.24.
|
|||
If you use Docker Engine via dockershim as your container runtime and wish to upgrade to v1.24,
|
||||
it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support.
|
||||
Check out the [container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
section to know your options. Make sure to
|
||||
section to know your options.
|
||||
|
||||
The version of Kubernetes with dockershim (1.23) is out of support and the v1.24
|
||||
will run out of support [soon](/releases/#release-v1-24). Make sure to
|
||||
[report issues](https://github.com/kubernetes/kubernetes/issues) you encountered
|
||||
with the migration so the issues can be fixed in a timely manner and your cluster would be
|
||||
ready for dockershim removal.
|
||||
ready for dockershim removal. After v1.24 running out of support, you will need
|
||||
to contact your Kubernetes provider for support or upgrade multiple versions at a time
|
||||
if there are critical issues affecting your cluster.
|
||||
|
||||
Your cluster might have more than one kind of node, although this is not a common
|
||||
configuration.
|
||||
|
|
@ -38,9 +43,6 @@ These tasks will help you to migrate:
|
|||
|
||||
* Check out [container runtimes](/docs/setup/production-environment/container-runtimes/)
|
||||
to understand your options for an alternative.
|
||||
* There is a
|
||||
[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)
|
||||
to track the discussion about the deprecation and removal of dockershim.
|
||||
* If you find 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.
|
||||
|
|
|
|||
|
|
@ -89,6 +89,49 @@ 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.
|
||||
|
||||
## Known issues
|
||||
|
||||
### Some filesystem metrics are missing and the metrics format is different
|
||||
|
||||
The Kubelet `/metrics/cadvisor` endpoint provides Prometheus metrics,
|
||||
as documented in [Metrics for Kubernetes system components](/docs/concepts/cluster-administration/system-metrics/).
|
||||
If you install a metrics collector that depends on that endpoint, you might see the following issues:
|
||||
|
||||
- The metrics format on the Docker node is `k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>`
|
||||
but the format on other runtime is different. For example, on containerd node it is `<container-id>`.
|
||||
- Some filesystem metrics are missing, as follows:
|
||||
```
|
||||
container_fs_inodes_free
|
||||
container_fs_inodes_total
|
||||
container_fs_io_current
|
||||
container_fs_io_time_seconds_total
|
||||
container_fs_io_time_weighted_seconds_total
|
||||
container_fs_limit_bytes
|
||||
container_fs_read_seconds_total
|
||||
container_fs_reads_merged_total
|
||||
container_fs_sector_reads_total
|
||||
container_fs_sector_writes_total
|
||||
container_fs_usage_bytes
|
||||
container_fs_write_seconds_total
|
||||
container_fs_writes_merged_total
|
||||
```
|
||||
|
||||
#### Workaround
|
||||
|
||||
You can mitigate this issue by using [cAdvisor](https://github.com/google/cadvisor) as a standalone daemonset.
|
||||
|
||||
1. Find the latest [cAdvisor release](https://github.com/google/cadvisor/releases)
|
||||
with the name pattern `vX.Y.Z-containerd-cri` (for example, `v0.42.0-containerd-cri`).
|
||||
2. Follow the steps in [cAdvisor Kubernetes Daemonset](https://github.com/google/cadvisor/tree/master/deploy/kubernetes) to create the daemonset.
|
||||
3. Point the installed metrics collector to use the cAdvisor `/metrics` endpoint
|
||||
which provides the full set of
|
||||
[Prometheus container metrics](https://github.com/google/cadvisor/blob/master/docs/storage/prometheus.md).
|
||||
|
||||
Alternatives:
|
||||
|
||||
- Use alternative third party metrics collection solution.
|
||||
- Collect metrics from the Kubelet summary API that is served at `/stats/summary`.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ in future versions of the Linux kernel.
|
|||
- `kernel.sem`,
|
||||
- `fs.mqueue.*`,
|
||||
- The parameters under `net.*` that can be set in container networking
|
||||
namespace. However, there are exceptions (e.g.,
|
||||
namespace. However, there are exceptions (e.g., before Linux 5.12.2,
|
||||
`net.netfilter.nf_conntrack_max` and `net.netfilter.nf_conntrack_expect_max`
|
||||
can be set in container networking namespace but they are unnamespaced).
|
||||
|
||||
|
|
|
|||
|
|
@ -861,22 +861,7 @@ spec:
|
|||
restartPolicy: Never
|
||||
```
|
||||
|
||||
### Mounted ConfigMaps are updated automatically
|
||||
|
||||
When a mounted ConfigMap is updated, the projected content is eventually updated too.
|
||||
This applies in the case where an optionally referenced ConfigMap comes into existence after
|
||||
a pod has started.
|
||||
|
||||
The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it
|
||||
uses its local TTL-based cache for getting the current value of the ConfigMap. As a result,
|
||||
the total delay from the moment when the ConfigMap is updated to the moment when new keys
|
||||
are projected to the pod can be as long as kubelet sync period (1 minute by default) + TTL of
|
||||
ConfigMaps cache (1 minute by default) in kubelet.
|
||||
|
||||
{{< note >}}
|
||||
A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath)
|
||||
volume will not receive ConfigMap updates.
|
||||
{{< /note >}}
|
||||
|
||||
## Restrictions
|
||||
|
||||
|
|
|
|||
|
|
@ -10,17 +10,26 @@ _build:
|
|||
|
||||
### Introduction
|
||||
|
||||
The kubectl completion script for Bash can be generated with the command `kubectl completion bash`. Sourcing the completion script in your shell enables kubectl autocompletion.
|
||||
The kubectl completion script for Bash can be generated with the command `kubectl completion bash`.
|
||||
Sourcing the completion script in your shell enables kubectl autocompletion.
|
||||
|
||||
However, the completion script depends on [**bash-completion**](https://github.com/scop/bash-completion), which means that you have to install this software first (you can test if you have bash-completion already installed by running `type _init_completion`).
|
||||
However, the completion script depends on
|
||||
[**bash-completion**](https://github.com/scop/bash-completion),
|
||||
which means that you have to install this software first
|
||||
(you can test if you have bash-completion already installed by running `type _init_completion`).
|
||||
|
||||
### Install bash-completion
|
||||
|
||||
bash-completion is provided by many package managers (see [here](https://github.com/scop/bash-completion#installation)). You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc.
|
||||
bash-completion is provided by many package managers
|
||||
(see [here](https://github.com/scop/bash-completion#installation)).
|
||||
You can install it with `apt-get install bash-completion` or `yum install bash-completion`, etc.
|
||||
|
||||
The above commands create `/usr/share/bash-completion/bash_completion`, which is the main script of bash-completion. Depending on your package manager, you have to manually source this file in your `~/.bashrc` file.
|
||||
The above commands create `/usr/share/bash-completion/bash_completion`,
|
||||
which is the main script of bash-completion. Depending on your package manager,
|
||||
you have to manually source this file in your `~/.bashrc` file.
|
||||
|
||||
To find out, reload your shell and run `type _init_completion`. If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
|
||||
To find out, reload your shell and run `type _init_completion`.
|
||||
If the command succeeds, you're already set, otherwise add the following to your `~/.bashrc` file:
|
||||
|
||||
```bash
|
||||
source /usr/share/bash-completion/bash_completion
|
||||
|
|
@ -32,7 +41,8 @@ Reload your shell and verify that bash-completion is correctly installed by typi
|
|||
|
||||
#### Bash
|
||||
|
||||
You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
|
||||
You now need to ensure that the kubectl completion script gets sourced in all
|
||||
your shell sessions. There are two ways in which you can do this:
|
||||
|
||||
{{< tabs name="kubectl_bash_autocompletion" >}}
|
||||
{{< tab name="User" codelang="bash" >}}
|
||||
|
|
@ -40,6 +50,7 @@ echo 'source <(kubectl completion bash)' >>~/.bashrc
|
|||
{{< /tab >}}
|
||||
{{< tab name="System" codelang="bash" >}}
|
||||
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
|
||||
sudo chmod a+r /etc/bash_completion.d/kubectl
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
|
@ -56,6 +67,7 @@ bash-completion sources all completion scripts in `/etc/bash_completion.d`.
|
|||
|
||||
Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working.
|
||||
To enable bash autocompletion in current session of shell, source the ~/.bashrc file:
|
||||
|
||||
```bash
|
||||
source ~/.bashrc
|
||||
```
|
||||
|
|
|
|||
|
|
@ -10,12 +10,21 @@ _build:
|
|||
|
||||
### Introduction
|
||||
|
||||
The kubectl completion script for Bash can be generated with `kubectl completion bash`. Sourcing this script in your shell enables kubectl completion.
|
||||
The kubectl completion script for Bash can be generated with `kubectl completion bash`.
|
||||
Sourcing this script in your shell enables kubectl completion.
|
||||
|
||||
However, the kubectl completion script depends on [**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install.
|
||||
However, the kubectl completion script depends on
|
||||
[**bash-completion**](https://github.com/scop/bash-completion) which you thus have to previously install.
|
||||
|
||||
{{< warning>}}
|
||||
There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2 (which is the default on macOS), and v2 is for Bash 4.1+. The kubectl completion script **doesn't work** correctly with bash-completion v1 and Bash 3.2. It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to correctly use kubectl completion on macOS, you have to install and use Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). The following instructions assume that you use Bash 4.1+ (that is, any Bash version of 4.1 or newer).
|
||||
There are two versions of bash-completion, v1 and v2. V1 is for Bash 3.2
|
||||
(which is the default on macOS), and v2 is for Bash 4.1+. The kubectl completion
|
||||
script **doesn't work** correctly with bash-completion v1 and Bash 3.2.
|
||||
It requires **bash-completion v2** and **Bash 4.1+**. Thus, to be able to
|
||||
correctly use kubectl completion on macOS, you have to install and use
|
||||
Bash 4.1+ ([*instructions*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)).
|
||||
The following instructions assume that you use Bash 4.1+
|
||||
(that is, any Bash version of 4.1 or newer).
|
||||
{{< /warning >}}
|
||||
|
||||
### Upgrade Bash
|
||||
|
|
@ -43,10 +52,13 @@ Homebrew usually installs it at `/usr/local/bin/bash`.
|
|||
### Install bash-completion
|
||||
|
||||
{{< note >}}
|
||||
As mentioned, these instructions assume you use Bash 4.1+, which means you will install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1, in which case kubectl completion won't work).
|
||||
As mentioned, these instructions assume you use Bash 4.1+, which means you will
|
||||
install bash-completion v2 (in contrast to Bash 3.2 and bash-completion v1,
|
||||
in which case kubectl completion won't work).
|
||||
{{< /note >}}
|
||||
|
||||
You can test if you have bash-completion v2 already installed with `type _init_completion`. If not, you can install it with Homebrew:
|
||||
You can test if you have bash-completion v2 already installed with `type _init_completion`.
|
||||
If not, you can install it with Homebrew:
|
||||
|
||||
```bash
|
||||
brew install bash-completion@2
|
||||
|
|
@ -62,7 +74,8 @@ Reload your shell and verify that bash-completion v2 is correctly installed with
|
|||
|
||||
### Enable kubectl autocompletion
|
||||
|
||||
You now have to ensure that the kubectl completion script gets sourced in all your shell sessions. There are multiple ways to achieve this:
|
||||
You now have to ensure that the kubectl completion script gets sourced in all
|
||||
your shell sessions. There are multiple ways to achieve this:
|
||||
|
||||
- Source the completion script in your `~/.bash_profile` file:
|
||||
|
||||
|
|
@ -83,10 +96,14 @@ You now have to ensure that the kubectl completion script gets sourced in all yo
|
|||
echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile
|
||||
```
|
||||
|
||||
- If you installed kubectl with Homebrew (as explained [here](/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything.
|
||||
- If you installed kubectl with Homebrew (as explained
|
||||
[here](/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)),
|
||||
then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`.
|
||||
In that case, you don't need to do anything.
|
||||
|
||||
{{< note >}}
|
||||
The Homebrew installation of bash-completion v2 sources all the files in the `BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
|
||||
The Homebrew installation of bash-completion v2 sources all the files in the
|
||||
`BASH_COMPLETION_COMPAT_DIR` directory, that's why the latter two methods work.
|
||||
{{< /note >}}
|
||||
|
||||
In any case, after reloading your shell, kubectl completion should be working.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,10 @@ card:
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew currentVersion >}} client can communicate with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}}, and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
You must use a kubectl version that is within one minor version difference of
|
||||
your cluster. For example, a v{{< skew currentVersion >}} client can communicate
|
||||
with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}},
|
||||
and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
Using the latest compatible version of kubectl helps avoid unforeseen issues.
|
||||
|
||||
## Install kubectl on Linux
|
||||
|
|
@ -32,9 +35,10 @@ The following methods exist for installing kubectl on Linux:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
|
||||
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)`
|
||||
portion of the command with the specific version.
|
||||
|
||||
For example, to download version {{< param "fullversion" >}} on Linux, type:
|
||||
For example, to download version {{< param "fullversion" >}} on Linux, type:
|
||||
|
||||
```bash
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
|
||||
|
|
@ -79,7 +83,8 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory:
|
||||
If you do not have root access on the target system, you can still install
|
||||
kubectl to the `~/.local/bin` directory:
|
||||
|
||||
```bash
|
||||
chmod +x kubectl
|
||||
|
|
@ -95,11 +100,14 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
|
|||
```bash
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
The above command will generate a warning:
|
||||
|
||||
```
|
||||
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.
|
||||
```
|
||||
|
||||
You can ignore this warning. You are only checking the version of `kubectl` that you
|
||||
have installed.
|
||||
|
||||
|
|
@ -122,7 +130,9 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
|
|||
sudo apt-get update
|
||||
sudo apt-get install -y ca-certificates curl
|
||||
```
|
||||
|
||||
If you use Debian 9 (stretch) or earlier you would also need to install `apt-transport-https`:
|
||||
|
||||
```shell
|
||||
sudo apt-get install -y apt-transport-https
|
||||
```
|
||||
|
|
@ -145,6 +155,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
|
|||
sudo apt-get update
|
||||
sudo apt-get install -y kubectl
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
In releases older than Debian 12 and Ubuntu 22.04, `/etc/apt/keyrings` does not exist by default.
|
||||
You can create this directory if you need to, making it world-readable but writeable only by admins.
|
||||
|
|
@ -172,7 +183,9 @@ sudo yum install -y kubectl
|
|||
|
||||
{{< tabs name="other_kubectl_install" >}}
|
||||
{{% tab name="Snap" %}}
|
||||
If you are on Ubuntu or another Linux distribution that supports the [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
|
||||
If you are on Ubuntu or another Linux distribution that supports the
|
||||
[snap](https://snapcraft.io/docs/core/install) package manager, kubectl
|
||||
is available as a [snap](https://snapcraft.io/) application.
|
||||
|
||||
```shell
|
||||
snap install kubectl --classic
|
||||
|
|
@ -182,7 +195,8 @@ kubectl version --client
|
|||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Homebrew" %}}
|
||||
If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install).
|
||||
If you are on Linux and using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)
|
||||
package manager, kubectl is available for [installation](https://docs.brew.sh/Homebrew-on-Linux#install).
|
||||
|
||||
```shell
|
||||
brew install kubectl
|
||||
|
|
@ -201,7 +215,8 @@ kubectl version --client
|
|||
|
||||
### Enable shell autocompletion
|
||||
|
||||
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell, which can save you a lot of typing.
|
||||
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell,
|
||||
which can save you a lot of typing.
|
||||
|
||||
Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,10 @@ card:
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew currentVersion >}} client can communicate with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}}, and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
You must use a kubectl version that is within one minor version difference of
|
||||
your cluster. For example, a v{{< skew currentVersion >}} client can communicate
|
||||
with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}},
|
||||
and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
Using the latest compatible version of kubectl helps avoid unforeseen issues.
|
||||
|
||||
## Install kubectl on macOS
|
||||
|
|
@ -42,7 +45,8 @@ The following methods exist for installing kubectl on macOS:
|
|||
{{< /tabs >}}
|
||||
|
||||
{{< note >}}
|
||||
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version.
|
||||
To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)`
|
||||
portion of the command with the specific version.
|
||||
|
||||
For example, to download version {{< param "fullversion" >}} on Intel macOS, type:
|
||||
|
||||
|
|
@ -119,9 +123,11 @@ The following methods exist for installing kubectl on macOS:
|
|||
|
||||
{{< note >}}
|
||||
The above command will generate a warning:
|
||||
|
||||
```
|
||||
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.
|
||||
```
|
||||
|
||||
You can ignore this warning. You are only checking the version of `kubectl` that you
|
||||
have installed.
|
||||
|
||||
|
|
@ -141,7 +147,8 @@ The following methods exist for installing kubectl on macOS:
|
|||
|
||||
### Install with Homebrew on macOS
|
||||
|
||||
If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew.
|
||||
If you are on macOS and using [Homebrew](https://brew.sh/) package manager,
|
||||
you can install kubectl with Homebrew.
|
||||
|
||||
1. Run the installation command:
|
||||
|
||||
|
|
@ -163,7 +170,8 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
|
|||
|
||||
### Install with Macports on macOS
|
||||
|
||||
If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports.
|
||||
If you are on macOS and using [Macports](https://macports.org/) package manager,
|
||||
you can install kubectl with Macports.
|
||||
|
||||
1. Run the installation command:
|
||||
|
||||
|
|
@ -186,7 +194,8 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
|
|||
|
||||
### Enable shell autocompletion
|
||||
|
||||
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell which can save you a lot of typing.
|
||||
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell
|
||||
which can save you a lot of typing.
|
||||
|
||||
Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,10 @@ card:
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew currentVersion >}} client can communicate with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}}, and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
You must use a kubectl version that is within one minor version difference of
|
||||
your cluster. For example, a v{{< skew currentVersion >}} client can communicate
|
||||
with v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersionAddMinor 0 >}},
|
||||
and v{{< skew currentVersionAddMinor 1 >}} control planes.
|
||||
Using the latest compatible version of kubectl helps avoid unforeseen issues.
|
||||
|
||||
## Install kubectl on Windows
|
||||
|
|
@ -33,7 +36,8 @@ The following methods exist for installing kubectl on Windows:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
To find out the latest stable version (for example, for scripting), take a look at [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).
|
||||
To find out the latest stable version (for example, for scripting), take a look at
|
||||
[https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).
|
||||
{{< /note >}}
|
||||
|
||||
1. Validate the binary (optional)
|
||||
|
|
@ -53,7 +57,8 @@ The following methods exist for installing kubectl on Windows:
|
|||
type kubectl.exe.sha256
|
||||
```
|
||||
|
||||
- Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result:
|
||||
- Using PowerShell to automate the verification using the `-eq` operator to
|
||||
get a `True` or `False` result:
|
||||
|
||||
```powershell
|
||||
$(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256)
|
||||
|
|
@ -66,14 +71,16 @@ The following methods exist for installing kubectl on Windows:
|
|||
```cmd
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
The above command will generate a warning:
|
||||
|
||||
```
|
||||
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.
|
||||
```
|
||||
|
||||
You can ignore this warning. You are only checking the version of `kubectl` that you
|
||||
have installed.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
Or use this for detailed view of version:
|
||||
|
|
@ -89,13 +96,17 @@ The following methods exist for installing kubectl on Windows:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to `PATH`.
|
||||
If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`.
|
||||
[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes)
|
||||
adds its own version of `kubectl` to `PATH`. If you have installed Docker Desktop before,
|
||||
you may need to place your `PATH` entry before the one added by the Docker Desktop
|
||||
installer or remove the Docker Desktop's `kubectl`.
|
||||
{{< /note >}}
|
||||
|
||||
### Install on Windows using Chocolatey, Scoop, or winget {#install-nonstandard-package-tools}
|
||||
|
||||
1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager, [Scoop](https://scoop.sh) command-line installer, or [winget](https://learn.microsoft.com/en-us/windows/package-manager/winget/) package manager.
|
||||
1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org)
|
||||
package manager, [Scoop](https://scoop.sh) command-line installer, or
|
||||
[winget](https://learn.microsoft.com/en-us/windows/package-manager/winget/) package manager.
|
||||
|
||||
{{< tabs name="kubectl_win_install" >}}
|
||||
{{% tab name="choco" %}}
|
||||
|
|
@ -158,7 +169,8 @@ Edit the config file with a text editor of your choice, such as Notepad.
|
|||
|
||||
### Enable shell autocompletion
|
||||
|
||||
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell, which can save you a lot of typing.
|
||||
kubectl provides autocompletion support for Bash, Zsh, Fish, and PowerShell,
|
||||
which can save you a lot of typing.
|
||||
|
||||
Below are the procedures to set up autocompletion for PowerShell.
|
||||
|
||||
|
|
@ -191,7 +203,8 @@ Below are the procedures to set up autocompletion for PowerShell.
|
|||
type kubectl-convert.exe.sha256
|
||||
```
|
||||
|
||||
- Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result:
|
||||
- Using PowerShell to automate the verification using the `-eq` operator to get
|
||||
a `True` or `False` result:
|
||||
|
||||
```powershell
|
||||
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: "Interactive Tutorial - Configuring a Java Microservice"
|
|||
weight: 20
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
|
|
|||
|
|
@ -13,6 +13,8 @@ card:
|
|||
weight: 10
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This tutorial shows you how to run a sample app
|
||||
|
|
|
|||
|
|
@ -9,6 +9,8 @@ card:
|
|||
title: Walkthrough the basics
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
|
@ -44,7 +46,7 @@ card:
|
|||
</div>
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
<div id="basics-modules" class="content__modules">
|
||||
<h2>Kubernetes Basics Modules</h2>
|
||||
<div class="row">
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: Interactive Tutorial - Creating a Cluster
|
|||
weight: 20
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: Interactive Tutorial - Deploying an App
|
|||
weight: 20
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: Interactive Tutorial - Exploring Your App
|
|||
weight: 20
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: Interactive Tutorial - Exposing Your App
|
|||
weight: 20
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: Interactive Tutorial - Scaling Your App
|
|||
weight: 20
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@ title: Interactive Tutorial - Updating Your App
|
|||
weight: 20
|
||||
---
|
||||
|
||||
{{% katacoda-removal %}}
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
<html lang="en">
|
||||
|
|
|
|||
|
|
@ -19,8 +19,7 @@ graceful connection draining.
|
|||
|
||||
There are often cases when you need to terminate a Pod - be it for upgrade or scale down.
|
||||
In order to improve application availability, it may be important to implement
|
||||
a proper active connections draining. This tutorial explains the flow of
|
||||
Pod termination in connection with the corresponding endpoint state and removal.
|
||||
a proper active connections draining.
|
||||
|
||||
This tutorial explains the flow of Pod termination in connection with the
|
||||
corresponding endpoint state and removal by using
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Existen los siguientes métodos para instalar kubectl en Windows:
|
|||
O si tiene `curl` instalado, use este comando:
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
|
||||
curl -LO https://dl.k8s.io/release/{{% param "fullversion" %}}/bin/windows/amd64/kubectl.exe
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -42,7 +42,7 @@ Existen los siguientes métodos para instalar kubectl en Windows:
|
|||
Descargue el archivo de comprobación de kubectl:
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256
|
||||
curl -LO https://dl.k8s.io/{{% param "fullversion" %}}/bin/windows/amd64/kubectl.exe.sha256
|
||||
```
|
||||
|
||||
Valide el binario kubectl con el archivo de comprobación:
|
||||
|
|
@ -148,7 +148,7 @@ A continuación se muestran los procedimientos para configurar el autocompletado
|
|||
1. Descargue la última versión con el comando:
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe
|
||||
curl -LO https://dl.k8s.io/release/{{% param "fullversion" %}}/bin/windows/amd64/kubectl-convert.exe
|
||||
```
|
||||
|
||||
1. Validar el binario (opcional)
|
||||
|
|
@ -156,7 +156,7 @@ A continuación se muestran los procedimientos para configurar el autocompletado
|
|||
Descargue el archivo de comprobación kubectl-convert:
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256
|
||||
curl -LO https://dl.k8s.io/{{% param "fullversion" %}}/bin/windows/amd64/kubectl-convert.exe.sha256
|
||||
```
|
||||
|
||||
Valide el binario kubectl-convert con el archivo de comprobación:
|
||||
|
|
|
|||
|
|
@ -67,10 +67,10 @@ These instructions use the [ISO 639-1](https://www.loc.gov/standards/iso639-2/ph
|
|||
### Modifier la configuration du site
|
||||
|
||||
Le site web de Kubernetes utilise Hugo comme son web framework.
|
||||
La configuration Hugo du site Web se trouve dans le fichier [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml).
|
||||
Pour prendre en charge une nouvelle localisation, vous devrez modifier `config.toml`.
|
||||
La configuration Hugo du site Web se trouve dans le fichier [`hugo.toml`](https://github.com/kubernetes/website/tree/master/hugo.toml).
|
||||
Pour prendre en charge une nouvelle localisation, vous devrez modifier `hugo.toml`.
|
||||
|
||||
Ajoutez un bloc de configuration pour la nouvelle langue dans `config.toml`, sous le bloc `[languages]` existant.
|
||||
Ajoutez un bloc de configuration pour la nouvelle langue dans `hugo.toml`, sous le bloc `[languages]` existant.
|
||||
Le bloc allemand, par exemple, ressemble à :
|
||||
|
||||
```toml
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ Le tableau suivant inclut la liste de tous les types de ressources pris en charg
|
|||
## Options de sortie
|
||||
|
||||
Utilisez les sections suivantes pour savoir comment vous pouvez formater ou ordonner les sorties de certaines commandes.
|
||||
Pour savoir exactgement quelles commandes prennent en charge quelles options de sortie, voir la documentation de référence de [kubectl](/docs/user-guide/kubectl/).
|
||||
Pour savoir exactement quelles commandes prennent en charge quelles options de sortie, voir la documentation de référence de [kubectl](/docs/user-guide/kubectl/).
|
||||
|
||||
### Formater la sortie
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
title: कंट्रोल प्लेन (Control Plane)
|
||||
id: control-plane
|
||||
date: 2019-05-12
|
||||
full_link:
|
||||
short_description: >
|
||||
कंटेनर ऑर्केस्ट्रेशन लेयर जो कंटेनरों के जीवनचक्र को परिभाषित, परिनियोजित और प्रबंधित करने के लिए API और इंटरफेस को उजागर करता है।
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
|
||||
कंटेनर ऑर्केस्ट्रेशन लेयर जो कंटेनरों के जीवनचक्र को परिभाषित, परिनियोजित और प्रबंधित करने के लिए एपीआई और इंटरफेस को उजागर करता है।
|
||||
|
||||
<!--more-->
|
||||
|
||||
यह लेयर कई अलग-अलग घटकों से बना है, जैसे (लेकिन इन तक सीमित नहीं):
|
||||
|
||||
- {{< glossary_tooltip text="etcd" term_id="etcd" >}}
|
||||
- {{< glossary_tooltip text="API सर्वर" term_id="kube-apiserver" >}}
|
||||
- {{< glossary_tooltip text="शेड्यूलर" term_id="kube-scheduler" >}}
|
||||
- {{< glossary_tooltip text="कंट्रोलर मैनेजर" term_id="kube-controller-manager" >}}
|
||||
- {{< glossary_tooltip text="क्लाउड कंट्रोलर मैनेजर" term_id="cloud-controller-manager" >}}
|
||||
|
||||
इन घटकों को पारंपरिक ऑपरेटिंग सिस्टम सेवाओं (डेमॉन) या कंटेनर के रूप में चलाया जा सकता है। इन घटकों को चलाने वाले मेजबानों को ऐतिहासिक रूप से {{< glossary_tooltip text="मास्टर्स" term_id="master" >}} कहा जाता था।
|
||||
|
|
@ -6,7 +6,7 @@ cid: home
|
|||
|
||||
{{< blocks/section id="oceanNodes" >}}
|
||||
{{% blocks/feature image="flower" %}}
|
||||
### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})は、デプロイやスケーリングを自動化したり、コンテナ化されたアプリケーションを管理したりするための、オープンソースのシステムです。
|
||||
### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/" >}})は、デプロイやスケーリングを自動化したり、コンテナ化されたアプリケーションを管理したりするための、オープンソースのシステムです。
|
||||
|
||||
管理や検出を容易にするため、アプリケーションを論理的な単位に分割し、コンテナをグルーピングします。Kubernetesは[Googleでの15年にわたる経験](http://queue.acm.org/detail.cfm?id=2898444)を基に構築されており、コミュニティのアイディアや慣習との最善の組み合わせを取っています。
|
||||
{{% /blocks/feature %}}
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ linkTitle: "dockershimの削除に関するFAQ"
|
|||
date: 2022-02-17
|
||||
slug: dockershim-faq
|
||||
aliases: [ '/ja/dockershim' ]
|
||||
evergreen: true
|
||||
---
|
||||
|
||||
**この記事は2020年の後半に投稿されたオリジナルの記事[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)の更新版です。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,175 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Kubernetesにおけるフォレンジックコンテナチェックポイント処理"
|
||||
date: 2022-12-05
|
||||
slug: forensic-container-checkpointing-alpha
|
||||
---
|
||||
|
||||
**Authors:** Adrian Reber (Red Hat)
|
||||
|
||||
フォレンジックコンテナチェックポイント処理は[Checkpoint/Restore In Userspace](https://criu.org/) (CRIU)に基づいており、コンテナがチェックポイントされていることを認識することなく、実行中のコンテナのステートフルコピーを作成することができます。
|
||||
コンテナのコピーは、元のコンテナに気づかれることなく、サンドボックス環境で複数回の分析やリストアが可能です。
|
||||
フォレンジックコンテナチェックポイント処理はKubernetes v1.25でalpha機能として導入されました。
|
||||
|
||||
## どのように機能しますか？
|
||||
|
||||
CRIUを使用してコンテナのチェックポイントやリストアを行うことが可能です。
|
||||
CRIUはruncやcrun、CRI-O、containerdと統合されており、Kubernetesで実装されているフォレンジックコンテナチェックポイント処理は、既存のCRIU統合を使用します。
|
||||
|
||||
## なぜ重要なのか？
|
||||
|
||||
CRIUと対応する統合機能を使用することで、後でフォレンジック分析を行うために、ディスク上で実行中のコンテナに関する全ての情報と状態を取得することが可能です。
|
||||
フォレンジック分析は、疑わしいコンテナを停止したり影響を与えることなく検査するために重要となる場合があります。
|
||||
コンテナが本当に攻撃を受けている場合、攻撃者はコンテナを検査する処理を検知するかもしれません。
|
||||
チェックポイントを取得しサンドボックス環境でコンテナを分析することは、元のコンテナや、おそらく攻撃者にも検査を認識されることなく、コンテナを検査することができる可能性があります。
|
||||
|
||||
フォレンジックコンテナチェックポイント処理のユースケースに加えて、内部状態を失うことなく、あるノードから他のノードにコンテナを移行することも可能です。
|
||||
特に初期化時間の長いステートフルコンテナの場合、チェックポイントからリストアすることは再起動後の時間が節約されるか、起動時間がより早くなる可能性があります。
|
||||
|
||||
## コンテナチェックポイント処理を利用するには？
|
||||
|
||||
機能は[フィーチャーゲート][container-checkpoint-feature-gate]で制限されているため、新しい機能を使用する前に`ContainerCheckpoint`を有効にしてください。
|
||||
|
||||
ランタイムがコンテナチェックポイント処理をサポートしている必要もあります。
|
||||
|
||||
* containerd: サポートは現在検討中です。詳細はcontainerdプルリクエスト[#6965][containerd-checkpoint-restore-pr]を見てください。
|
||||
* CRI-O: v1.25はフォレンジックコンテナチェックポイント処理をサポートしています。
|
||||
|
||||
[containerd-checkpoint-restore-pr]: https://github.com/containerd/containerd/pull/6965
|
||||
[container-checkpoint-feature-gate]: https://kubernetes.io/ja/docs/reference/command-line-tools-reference/feature-gates/
|
||||
|
||||
### CRI-Oでの使用例
|
||||
|
||||
CRI-Oとの組み合わせでフォレンジックコンテナチェックポイント処理を使用するためには、ランタイムをコマンドラインオプション`--enable-criu-support=true`で起動する必要があります。
|
||||
Kubernetesでは、`ContainerCheckpoint`フィーチャーゲートを有効にしたクラスターを実行する必要があります。
|
||||
チェックポイント処理の機能はCRIUによって提供されているため、CRIUをインストールすることも必要となります。
|
||||
通常、runcやcrunはCRIUに依存しているため、自動的にインストールされます。
|
||||
|
||||
執筆時点ではチェックポイント機能はCRI-OやKubernetesにおいてalpha機能としてみなされており、セキュリティ影響がまだ検討中であることに言及することも重要です。
|
||||
|
||||
コンテナとPodが実行されると、チェックポイントを作成することが可能になります。
|
||||
[チェックポイント処理](https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/)は**kubelet**レベルでのみ公開されています。
|
||||
コンテナをチェックポイントするためには、コンテナが実行されているノード上で`curl`を実行し、チェックポイントをトリガーします。
|
||||
|
||||
```shell
|
||||
curl -X POST "https://localhost:10250/checkpoint/namespace/podId/container"
|
||||
```
|
||||
|
||||
*default*名前空間内の*counters*と呼ばれるPod内の*counter*と呼ばれるコンテナに対し、**kubelet** APIエンドポイントが次の場所で到達可能です。
|
||||
|
||||
```shell
|
||||
curl -X POST "https://localhost:10250/checkpoint/default/counters/counter"
|
||||
```
|
||||
|
||||
厳密には、kubeletの自己署名証明書を許容し、kubeletチェックポイントAPIの使用を認可するために、下記のcurlコマンドのオプションが必要です。
|
||||
|
||||
```shell
|
||||
--insecure --cert /var/run/kubernetes/client-admin.crt --key /var/run/kubernetes/client-admin.key
|
||||
```
|
||||
|
||||
この**kubelet** APIが実行されると、CRI-Oからチェックポイントの作成をリクエストします。
|
||||
CRI-Oは低レベルランタイム(例えば`runc`)からチェックポイントをリクエストします。
|
||||
そのリクエストを確認すると、`runc`は実際のチェックポイントを行うために`criu`ツールを呼び出します。
|
||||
|
||||
チェックポイント処理が終了すると、チェックポイントは`/var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tar`で利用可能になります。
|
||||
|
||||
その後、そのtarアーカイブを使用してコンテナを別の場所にリストアできます。
|
||||
|
||||
### Kubernetesの外部でチェックポイントしたコンテナをリストアする(CRI-Oを使用) {#restore-checkpointed-container-standalone}
|
||||
|
||||
チェックポイントtarアーカイブを使用すると、CRI-Oのサンドボックスインスタンス内のKubernetesの外部にコンテナをリストア可能です。
|
||||
リストア中のより良いユーザエクスペリエンスのために、*main* CRI-O GitHubブランチからCRI-Oのlatestバージョンを使用することを推奨します。
|
||||
CRI-O v1.25を使用している場合、コンテナを開始する前にKubernetesが作成する特定のディレクトリを手動で作成する必要があります。
|
||||
|
||||
Kubernetesの外部にコンテナをリストアするための最初のステップは、*crictl*を使用してPodサンドボックスを作成することです。
|
||||
|
||||
```shell
|
||||
crictl runp pod-config.json
|
||||
```
|
||||
|
||||
次に、さきほどチェックポイントしたコンテナを新しく作成したPodサンドボックスにリストアします。
|
||||
|
||||
```shell
|
||||
crictl create <POD_ID> container-config.json pod-config.json
|
||||
```
|
||||
|
||||
`container-config.json`のレジストリでコンテナイメージを指定する代わりに、前に作成したチェックポイントアーカイブへのパスを指定する必要があります。
|
||||
|
||||
```json
|
||||
{
|
||||
"metadata": {
|
||||
"name": "counter"
|
||||
},
|
||||
"image":{
|
||||
"image": "/var/lib/kubelet/checkpoints/<checkpoint-archive>.tar"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
次に、そのコンテナを開始するために`crictl start <CONTAINER_ID>`を実行すると、さきほどチェックポイントしたコンテナのコピーが実行されているはずです。
|
||||
|
||||
### Kubernetes内でチェックポイントしたコンテナをリストアする {#restore-checkpointed-container-k8s}
|
||||
|
||||
先ほどチェックポイントしたコンテナをKubernetes内で直接リストアするためには、レジストリにプッシュできるイメージにチェックポイントアーカイブを変換する必要があります。
|
||||
|
||||
ローカルのチェックポイントアーカイブを変換するための方法として、[buildah](https://buildah.io/)を使用した下記のステップが考えられます。
|
||||
|
||||
```shell
|
||||
newcontainer=$(buildah from scratch)
|
||||
buildah add $newcontainer /var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tar /
|
||||
buildah config --annotation=io.kubernetes.cri-o.annotations.checkpoint.name=<container-name> $newcontainer
|
||||
buildah commit $newcontainer checkpoint-image:latest
|
||||
buildah rm $newcontainer
|
||||
```
|
||||
|
||||
出来上がったイメージは標準化されておらず、CRI-Oとの組み合わせでのみ動作します。
|
||||
このイメージはalphaにも満たないフォーマットであると考えてください。
|
||||
このようなチェックポイントイメージのフォーマットを標準化するための[議論][image-spec-discussion]が進行中です。
|
||||
これはまだ標準化されたイメージフォーマットではなく、CRI-Oを`--enable-criu-support=true`で起動した場合のみ動作することを忘れないでください。
|
||||
CRIUサポートでCRI-Oを起動することのセキュリティ影響はまだ明確ではなく、そのため、イメージフォーマットだけでなく機能も気を付けて使用するべきです。
|
||||
|
||||
さて、そのイメージをコンテナイメージレジストリにプッシュする必要があります。
|
||||
例えば以下のような感じです。
|
||||
|
||||
```shell
|
||||
buildah push localhost/checkpoint-image:latest container-image-registry.example/user/checkpoint-image:latest
|
||||
```
|
||||
|
||||
このチェックポイントイメージ(`container-image-registry.example/user/checkpoint-image:latest`)をリストアするために、イメージはPodの仕様(Specification)に記載する必要があります。
|
||||
以下はマニフェストの例です。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
namePrefix: example-
|
||||
spec:
|
||||
containers:
|
||||
- name: <container-name>
|
||||
image: container-image-registry.example/user/checkpoint-image:latest
|
||||
nodeName: <destination-node>
|
||||
```
|
||||
|
||||
Kubernetesは新しいPodをノード上にスケジュールします。
|
||||
そのノード上のKubeletは、`registry/user/checkpoint-image:latest`として指定されたイメージをもとに、コンテナを作成し開始するようにコンテナランタイム(この例ではCRI-O)に指示をします。
|
||||
CRI-Oは`registry/user/checkpoint-image:latest`がコンテナイメージでなく、チェックポイントデータへの参照であることを検知します。
|
||||
その時、コンテナを作成し開始する通常のステップの代わりに、CRI-Oはチェックポイントデータをフェッチし、指定されたチェックポイントからコンテナをリストアします。
|
||||
|
||||
Pod内のアプリケーションはチェックポイントを取得しなかったかのように実行し続けます。
|
||||
コンテナ内では、アプリケーションはチェックポイントからリストアされず通常起動したコンテナのような見た目や動作をします。
|
||||
|
||||
これらのステップで、あるノードで動作しているPodを、別のノードで動作している新しい同等のPodに置き換えることができ、そのPod内のコンテナの状態を失うことはないです。
|
||||
|
||||
[image-spec-discussion]: https://github.com/opencontainers/image-spec/issues/962
|
||||
|
||||
## どのように参加すればよいですか？
|
||||
|
||||
SIG Nodeにはいくつかの手段でアクセスすることができます。
|
||||
- Slack: [#sig-node](https://kubernetes.slack.com/messages/sig-node)
|
||||
- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-node)
|
||||
|
||||
## さらなる読み物
|
||||
|
||||
コンテナチェックポイントの分析方法に関する詳細は後続のブログ[Forensic container analysis][forensic-container-analysis]を参照してください。
|
||||
|
||||
[forensic-container-analysis]: /blog/2023/03/10/forensic-container-analysis/
|
||||
|
|
@ -5,7 +5,7 @@ weight: 70
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
ガベージコレクションは、Kubernetesがクラスターリソースをクリーンアップするために使用するさまざまなメカニズムの総称です。これにより、次のようなリソースのクリーンアップが可能になります:
|
||||
{{<glossary_definition term_id="garbage-collection" length="short">}}これにより、次のようなリソースのクリーンアップが可能になります:
|
||||
|
||||
* [終了したPod](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
|
||||
* [完了したJob](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
|
|
|
|||
|
|
@ -1,67 +0,0 @@
|
|||
---
|
||||
title: コンテナイメージのガベージコレクション
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
ガベージコレクションは、未使用の[イメージ](/ja/docs/concepts/containers/#container-images)と未使用の[コンテナ](/ja/docs/concepts/containers/)をクリーンアップするkubeletの便利な機能です。kubeletコンテナのガベージコレクションを1分ごとに行い、イメージのガベージコレクションは5分ごとに行います。
|
||||
|
||||
存在することが期待されているコンテナを削除してkubeletの動作を壊す可能性があるため、外部のガベージコレクションのツールは推奨されません。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## イメージのガベージコレクション
|
||||
|
||||
Kubernetesでは、すべてのイメージのライフサイクルの管理はcadvisorと協調してimageManager経由で行います。
|
||||
|
||||
イメージのガベージコレクションのポリシーについて考えるときは、`HighThresholdPercent`および`LowThresholdPercent`という2つの要因について考慮する必要があります。ディスク使用量がhigh thresholdを超えると、ガベージコレクションがトリガされます。ガベージコレクションは、low
|
||||
thresholdが満たされるまで、最後に使われてから最も時間が経った(least recently used)イメージを削除します。
|
||||
|
||||
## コンテナのガベージコレクション
|
||||
|
||||
コンテナのガベージコレクションのポリシーは、3つのユーザー定義の変数を考慮に入れます。`MinAge`は、ガベージコレクションできるコンテナの最小の年齢です。`MaxPerPodContainer`は、すべての単一のPod(UID、コンテナ名)が保持することを許されているdead状態のコンテナの最大値です。`MaxContainers`はdead状態のコンテナの合計の最大値です。これらの変数は、`MinAge`は0に、`MaxPerPodContainer`と`MaxContainers`は0未満にそれぞれ設定することで個別に無効にできます。
|
||||
|
||||
kubeletは、未指定のコンテナ、削除されたコンテナ、前述のフラグにより設定された境界の外にあるコンテナに対して動作します。一般に、最も古いコンテナが最初に削除されます。`MaxPerPodContainer`と`MaxContainer`は、Podごとの保持するコンテナの最大値(`MaxPerPodContainer`)がグローバルのdead状態のコンテナの許容範囲(`MaxContainers`)外である場合には、互いに競合する可能性があります。このような状況では、`MaxPerPodContainer`が調整されます。最悪のケースのシナリオでは、`MaxPerPodContainer`が1にダウングレードされ、最も古いコンテナが強制退去されます。さらに、`MinAge`より古くなると、削除済みのPodが所有するコンテナが削除されます。
|
||||
|
||||
kubeletによって管理されないコンテナは、コンテナのガベージコレクションの対象にはなりません。
|
||||
|
||||
## ユーザー設定
|
||||
|
||||
イメージのガベージコレクションを調整するために、以下のkubeletのフラグを使用して次のようなしきい値を調整できます。
|
||||
|
||||
1. `image-gc-high-threshold`: イメージのガベージコレクションをトリガするディスク使用量の割合(%)。デフォルトは85%。
|
||||
2. `image-gc-low-threshold`: イメージのガベージコレクションが解放を試みるディスク使用量の割合(%)。デフォルトは80%。
|
||||
|
||||
ガベージコレクションのポリシーは、以下のkubeletのフラグを使用してカスタマイズできます。
|
||||
|
||||
1. `minimum-container-ttl-duration`: 完了したコンテナがガベージコレクションされる前に経過するべき最小期間。デフォルトは0分です。つまり、すべての完了したコンテナはガベージコレクションされます。
|
||||
2. `maximum-dead-containers-per-container`: コンテナごとに保持される古いインスタンスの最大値です。デフォルトは1です。
|
||||
3. `maximum-dead-containers`: グローバルに保持するべき古いコンテナのインスタンスの最大値です。デフォルトは-1です。つまり、グローバルなリミットは存在しません。
|
||||
|
||||
コンテナは役に立たなくなる前にガベージコレクションされる可能性があります。こうしたコンテナには、トラブルシューティングに役立つログや他のデータが含まれるかもしれません。そのため、期待されるコンテナごとに最低でも1つのdead状態のコンテナが許容されるようにするために、`maximum-dead-containers-per-container`には十分大きな値を設定することが強く推奨されます。同様の理由で、`maximum-dead-containers`にも、より大きな値を設定することが推奨されます。詳しくは、[こちらのissue](https://github.com/kubernetes/kubernetes/issues/13287)を読んでください。
|
||||
|
||||
## 廃止
|
||||
|
||||
このドキュメントにあるkubeletの一部のガベージコレクションの機能は、将来kubelet evictionで置換される予定です。
|
||||
|
||||
これには以下のものが含まれます。
|
||||
|
||||
| 既存のフラグ | 新しいフラグ | 理由 |
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard`または`--eviction-soft` | 既存のevictionのシグナルがイメージのガベージコレクションをトリガする可能性がある |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaimが同等の動作を実現する |
|
||||
| `--maximum-dead-containers` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
|
||||
| `--maximum-dead-containers-per-container` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
|
||||
| `--minimum-container-ttl-duration` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | evictionはディスクのしきい値を他のリソースに一般化している |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | evictionはディスクのpressure transitionを他のリソースに一般化している |
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
詳細については、[リソース不足のハンドリング方法を設定する](/docs/tasks/administer-cluster/out-of-resource/)を参照してください。
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ kubeconfigファイルを使用すると、クラスター、ユーザー、名
|
|||
|
||||
## Context
|
||||
|
||||
kubeconfigファイルの*context*要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメータ、cluster、namespace、userを持ちます。デフォルトでは、`kubectl`コマンドラインツールはクラスターとの通信に*current context*のパラメーターを使用します。
|
||||
kubeconfigファイルの*context*要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメーター、cluster、namespace、userを持ちます。デフォルトでは、`kubectl`コマンドラインツールはクラスターとの通信に*current context*のパラメーターを使用します。
|
||||
|
||||
current contextを選択するには、以下のコマンドを使用します。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,95 @@
|
|||
---
|
||||
title: "概要"
|
||||
description: >
|
||||
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
|
||||
content_type: concept
|
||||
weight: 20
|
||||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
no_list: true
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このページでは、Kubernetesの概要について説明します。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
|
||||
|
||||
Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。
|
||||
"K"と"s"の間にある8つの文字を数えることから、K8sが略語として使われています。
|
||||
Googleは2014年にKubernetesプロジェクトをオープンソース化しました。
|
||||
Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。
|
||||
|
||||
## 過去を振り返ってみると
|
||||
|
||||
過去を振り返って、Kubernetesがなぜこんなに便利なのかを見てみましょう。
|
||||
|
||||
|
||||
|
||||
**仮想化ができる前の時代におけるデプロイ (Traditional deployment):** 初期の頃は、組織は物理サーバー上にアプリケーションを実行させていました。物理サーバー上でアプリケーションのリソース制限を設定する方法がなかったため、リソースの割当問題が発生していました。例えば、複数のアプリケーションを実行させた場合、ひとつのアプリケーションがリソースの大半を消費してしまうと、他のアプリケーションのパフォーマンスが低下してしまうことがありました。この解決方法は、それぞれのアプリケーションを別々の物理サーバーで動かすことでした。しかし、リソースが十分に活用できなかったため、拡大しませんでした。また組織にとって多くの物理サーバーを維持することは費用がかかりました。
|
||||
|
||||
**仮想化を使ったデプロイ (Virtualized deployment):** ひとつの解決方法として、仮想化が導入されました。1台の物理サーバーのCPU上で、複数の仮想マシン(VM)を実行させることができるようになりました。仮想化によりアプリケーションをVM毎に隔離する事ができ、ひとつのアプリケーションの情報が他のアプリケーションから自由にアクセスさせないといったセキュリティレベルを提供することができます。
|
||||
|
||||
仮想化により、物理サーバー内のリソース使用率が向上し、アプリケーションの追加や更新が容易になり、ハードウェアコストの削減などスケーラビリティが向上します。仮想化を利用すると、物理リソースのセットを使い捨て可能な仮想マシンのクラスターとして提示することができます。
|
||||
|
||||
各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。
|
||||
|
||||
**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPUの共有、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。
|
||||
|
||||
コンテナは、その他にも次のようなメリットを提供するため、人気が高まっています。
|
||||
|
||||
* アジャイルアプリケーションの作成とデプロイ: VMイメージの利用時と比較して、コンテナイメージ作成の容易さと効率性が向上します。
|
||||
* 継続的な開発、インテグレーションとデプロイ: 信頼できる頻繁なコンテナイメージのビルドと、素早く簡単にロールバックすることが可能なデプロイを提供します。(イメージが不変であれば)
|
||||
* 開発者と運用者の関心を分離: アプリケーションコンテナイメージの作成は、デプロイ時ではなく、ビルド/リリース時に行います。それによって、インフラストラクチャとアプリケーションを分離します。
|
||||
* 可観測性: OSレベルの情報とメトリクスだけではなく、アプリケーションの稼働状態やその他の警告も表示します。
|
||||
* 開発、テスト、本番環境を越えた環境の一貫性: クラウドで実行させるのと同じようにノートPCでも実行させる事ができます。
|
||||
* クラウドとOSディストリビューションの可搬性: Ubuntu、RHEL、CoreOS上でも、オンプレミスも、主要なパブリッククラウドでも、それ以外のどんな環境でも、実行できます。
|
||||
* アプリケーション中心の管理: 仮想マシン上でOSを実行するから、論理リソースを使用してOS上でアプリケーションを実行するへと抽象度のレベルを向上させます。
|
||||
* 疎結合、分散化、拡張性、柔軟性のあるマイクロサービス: アプリケーションを小さく、同時にデプロイと管理が可能な独立した部品に分割されます。1台の大きな単一目的のマシン上に実行するモノリシックなスタックではありません。
|
||||
* リソースの分割: アプリケーションのパフォーマンスが予測可能です。
|
||||
* リソースの効率的な利用: 高い効率性と集約性が可能です。
|
||||
|
||||
## Kubernetesが必要な理由と提供する機能 {#why-you-need-kubernetes-and-what-can-it-do}
|
||||
|
||||
コンテナは、アプリケーションを集約して実行する良い方法です。本番環境では、アプリケーションを実行しダウンタイムが発生しないように、コンテナを管理する必要があります。例えば、コンテナがダウンした場合、他のコンテナを起動する必要があります。このような動作がシステムに組込まれていると、管理が簡単になるのではないでしょうか？
|
||||
|
||||
そこを助けてくれるのがKubernetesです! Kubernetesは分散システムを弾力的に実行するフレームワークを提供してくれます。あなたのアプリケーションのためにスケーリングとフェイルオーバーの面倒を見てくれて、デプロイのパターンなどを提供します。例えば、Kubernetesはシステムにカナリアデプロイを簡単に管理することができます。
|
||||
|
||||
Kubernetesは以下を提供します。
|
||||
|
||||
* **サービスディスカバリーと負荷分散**
|
||||
Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるため、デプロイが安定します。
|
||||
* **ストレージ オーケストレーション**
|
||||
Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。
|
||||
* **自動化されたロールアウトとロールバック**
|
||||
Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。
|
||||
* **自動ビンパッキング**
|
||||
コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。
|
||||
* **自己修復**
|
||||
Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。
|
||||
* **機密情報と構成管理**
|
||||
Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。
|
||||
|
||||
## Kubernetesにないもの
|
||||
|
||||
Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散といったPaaSが提供するのと共通の機能をいくつか提供し、またユーザーはロギングやモニタリング及びアラートを行うソリューションを統合できます。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。
|
||||
|
||||
Kubernetesは...
|
||||
|
||||
* サポートするアプリケーションの種類を制限しません。Kubernetesは、ステートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
|
||||
* ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。
|
||||
* ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。
|
||||
* ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。
|
||||
* 構成言語/システム(例:Jsonnet)の提供も指示もしません。任意の形式の宣言型仕様の対象となる可能性のある宣言型APIを提供します。
|
||||
* 統合的なマシンの構成、メンテナンス、管理、または自己修復を行うシステムは提供も採用も行いません。
|
||||
* さらに、Kubernetesは単なるオーケストレーションシステムではありません。実際には、オーケストレーションの必要性はありません。オーケストレーションの技術的な定義は、「最初にAを実行し、次にB、その次にCを実行」のような定義されたワークフローの実行です。対照的にKubernetesは、現在の状態から提示されたあるべき状態にあわせて継続的に維持するといった、独立していて構成可能な制御プロセスのセットを提供します。AからCへどのように移行するかは問題ではありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、弾力性と拡張性があるシステムが実現します。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Kubernetesのコンポーネント](/ja/docs/concepts/overview/components/)をご覧ください。
|
||||
* [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)をご覧ください。
|
||||
* [クラスターのアーキテクチャ](/ja/docs/concepts/architecture/)をご覧ください。
|
||||
* [はじめる](/ja/docs/setup/)準備はできましたか？
|
||||
|
|
|
|||
|
|
@ -1,92 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
title: Kubernetesとは何か？
|
||||
description: >
|
||||
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
sitemap:
|
||||
priority: 0.9
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このページでは、Kubernetesの概要について説明します。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
|
||||
|
||||
Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。
|
||||
|
||||
## 過去を振り返ってみると
|
||||
|
||||
過去を振り返って、Kubernetesがなぜこんなに便利なのかを見てみましょう。
|
||||
|
||||
|
||||
|
||||
**仮想化ができる前の時代におけるデプロイ (Traditional deployment):** 初期の頃は、組織は物理サーバー上にアプリケーションを実行させていました。物理サーバー上でアプリケーションのリソース制限を設定する方法がなかったため、リソースの割当問題が発生していました。例えば、複数のアプリケーションを実行させた場合、ひとつのアプリケーションがリソースの大半を消費してしまうと、他のアプリケーションのパフォーマンスが低下してしまうことがありました。この解決方法は、それぞれのアプリケーションを別々の物理サーバーで動かすことでした。しかし、リソースが十分に活用できなかったため、拡大しませんでした。また組織にとって多くの物理サーバーを維持することは費用がかかりました。
|
||||
|
||||
**仮想化を使ったデプロイ (Virtualized deployment):** ひとつの解決方法として、仮想化が導入されました。1台の物理サーバーのCPU上で、複数の仮想マシン(VM)を実行させることができるようになりました。仮想化によりアプリケーションをVM毎に隔離する事ができ、ひとつのアプリケーションの情報が他のアプリケーションから自由にアクセスさせないといったセキュリティレベルを提供することができます。
|
||||
|
||||
仮想化により、物理サーバー内のリソース使用率が向上し、アプリケーションの追加や更新が容易になり、ハードウェアコストの削減などスケーラビリティが向上します。仮想化を利用すると、物理リソースのセットを使い捨て可能な仮想マシンのクラスターとして提示することができます。
|
||||
|
||||
各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。
|
||||
|
||||
**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPUの共有、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。
|
||||
|
||||
コンテナは、その他にも次のようなメリットを提供するため、人気が高まっています。
|
||||
|
||||
* アジャイルアプリケーションの作成とデプロイ: VMイメージの利用時と比較して、コンテナイメージ作成の容易さと効率性が向上します。
|
||||
* 継続的な開発、インテグレーションとデプロイ: 信頼できる頻繁なコンテナイメージのビルドと、素早く簡単にロールバックすることが可能なデプロイを提供します。(イメージが不変であれば)
|
||||
* 開発者と運用者の関心を分離: アプリケーションコンテナイメージの作成は、デプロイ時ではなく、ビルド/リリース時に行います。それによって、インフラストラクチャとアプリケーションを分離します。
|
||||
* 可観測性はOSレベルの情報とメトリクスだけではなく、アプリケーションの稼働状態やその他の警告も表示します。
|
||||
* 開発、テスト、本番環境を越えた環境の一貫性: クラウドで実行させるのと同じようにノートPCでも実行させる事ができます。
|
||||
* クラウドとOSディストリビューションの可搬性: Ubuntu、RHEL、CoreOS上でも、オンプレミスも、主要なパブリッククラウドでも、それ以外のどんな環境でも、実行できます。
|
||||
* アプリケーション中心の管理: 仮想マシン上でOSを実行するから、論理リソースを使用してOS上でアプリケーションを実行するへと抽象度のレベルを向上させます。
|
||||
* 疎結合、分散化、拡張性、柔軟性のあるマイクロサービス: アプリケーションを小さく、同時にデプロイと管理が可能な独立した部品に分割されます。1台の大きな単一目的のマシン上に実行するモノリシックなスタックではありません。
|
||||
* リソースの分割: アプリケーションのパフォーマンスが予測可能です。
|
||||
* リソースの効率的な利用: 高い効率性と集約性が可能です。
|
||||
|
||||
## Kubernetesが必要な理由と提供する機能 {#why-you-need-kubernetes-and-what-can-it-do}
|
||||
|
||||
コンテナは、アプリケーションを集約して実行する良い方法です。本番環境では、アプリケーションを実行しダウンタイムが発生しないように、コンテナを管理する必要があります。例えば、コンテナがダウンした場合、他のコンテナを起動する必要があります。このような動作がシステムに組込まれていると、管理が簡単になるのではないでしょうか？
|
||||
|
||||
そこを助けてくれるのがKubernetesです! Kubernetesは分散システムを弾力的に実行するフレームワークを提供してくれます。あなたのアプリケーションのためにスケーリングとフェイルオーバーの面倒を見てくれて、デプロイのパターンなどを提供します。例えば、Kubernetesはシステムにカナリアデプロイを簡単に管理することができます。
|
||||
|
||||
Kubernetesは以下を提供します。
|
||||
|
||||
* **サービスディスカバリーと負荷分散**
|
||||
Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるため、デプロイが安定します。
|
||||
* **ストレージ オーケストレーション**
|
||||
Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。
|
||||
* **自動化されたロールアウトとロールバック**
|
||||
Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。
|
||||
* **自動ビンパッキング**
|
||||
コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。
|
||||
* **自己修復**
|
||||
Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。
|
||||
* **機密情報と構成管理**
|
||||
Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。
|
||||
|
||||
## Kubernetesにないもの
|
||||
|
||||
Kubernetesは、従来型の全部入りなPaaS(Platform as a Service)のシステムではありません。Kubernetesはハードウェアレベルではなく、コンテナレベルで動作するため、デプロイ、スケーリング、負荷分散といったPaaSが提供するのと共通の機能をいくつか提供し、またユーザーはロギングやモニタリング及びアラートを行うソリューションを統合できます。また一方、Kubernetesはモノリシックでなく、標準のソリューションは選択が自由で、追加と削除が容易な構成になっています。Kubernetesは開発プラットフォーム構築のためにビルディングブロックを提供しますが、重要な部分はユーザーの選択と柔軟性を維持しています。
|
||||
|
||||
Kubernetesは...
|
||||
|
||||
* サポートするアプリケーションの種類を制限しません。Kubernetesは、ステートレス、ステートフルやデータ処理のワークロードなど、非常に多様なワークロードをサポートすることを目的としています。アプリケーションがコンテナで実行できるのであれば、Kubernetes上で問題なく実行できるはずです。
|
||||
* ソースコードのデプロイやアプリケーションのビルドは行いません。継続的なインテグレーション、デリバリー、デプロイ(CI/CD)のワークフローは、技術的な要件だけでなく組織の文化や好みで決められます。
|
||||
* ミドルウェア(例:メッセージバス)、データ処理フレームワーク(例:Spark)、データベース(例:MySQL)、キャッシュ、クラスターストレージシステム(例:Ceph)といったアプリケーションレベルの機能を組み込んで提供しません。それらのコンポーネントは、Kubernetes上で実行することもできますし、[Open Service Broker](https://openservicebrokerapi.org/)のようなポータブルメカニズムを経由してKubernetes上で実行されるアプリケーションからアクセスすることも可能です。
|
||||
* ロギング、モニタリングやアラートを行うソリューションは指定しません。PoCとしていくつかのインテグレーションとメトリクスを収集し出力するメカニズムを提供します。
|
||||
* 構成言語/システム(例:Jsonnet)の提供も指示もしません。任意の形式の宣言型仕様の対象となる可能性のある宣言型APIを提供します。
|
||||
* 統合的なマシンの構成、メンテナンス、管理、または自己修復を行うシステムは提供も採用も行いません。
|
||||
* さらに、Kubernetesは単なるオーケストレーションシステムではありません。実際には、オーケストレーションの必要性はありません。オーケストレーションの技術的な定義は、「最初にAを実行し、次にB、その次にCを実行」のような定義されたワークフローの実行です。対照的にKubernetesは、現在の状態から提示されたあるべき状態にあわせて継続的に維持するといった、独立していて構成可能な制御プロセスのセットを提供します。AからCへどのように移行するかは問題ではありません。集中管理も必要ありません。これにより、使いやすく、より強力で、堅牢で、弾力性と拡張性があるシステムが実現します。
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Kubernetesのコンポーネント](/ja/docs/concepts/overview/components/)を御覧ください。
|
||||
* [はじめる](/ja/docs/setup/)準備はできましたか？
|
||||
|
|
@ -167,7 +167,7 @@ partition
|
|||
|
||||
### LISTとWATCHによるフィルタリング
|
||||
|
||||
LISTとWATCHオペレーションは、単一のクエリパラメータを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます。
|
||||
LISTとWATCHオペレーションは、単一のクエリパラメーターを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます。
|
||||
*集合ベース* と*等価ベース* のどちらの要件も許可されています(ここでは、URLクエリストリング内で出現します)。
|
||||
|
||||
* *等価ベース* での要件: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ profiles:
|
|||
`addedAffinity`はエンドユーザーには見えないので、その動作はエンドユーザーにとって予期しないものになる可能性があります。スケジューラープロファイル名と明確な相関関係のあるNodeラベルを使用すべきです。
|
||||
|
||||
{{< note >}}
|
||||
[DaemonSetのPodを作成する](/ja/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)DaemonSetコントローラーは、スケジューリングプロファイルをサポートしていません。DaemonSetコントローラーがPodを作成すると、デフォルトのKubernetesスケジューラーがそれらのPodを配置し、DaemonSetコントローラーの`nodeAffinity`ルールに優先して従います。
|
||||
[DaemonSetのPodを作成する](/ja/docs/concepts/workloads/controllers/daemonset/#how-daemon-pods-are-scheduled)DaemonSetコントローラーは、スケジューリングプロファイルをサポートしていません。DaemonSetコントローラーがPodを作成すると、デフォルトのKubernetesスケジューラーがそれらのPodを配置し、DaemonSetコントローラーの`nodeAffinity`ルールに優先して従います。
|
||||
{{< /note >}}
|
||||
|
||||
### Pod間のアフィニティとアンチアフィニティ {#inter-pod-affinity-and-anti-affinity}
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ PodをNode上で実行する時に、Pod自身は大量のシステムリソー
|
|||
|
||||
<!-- body -->
|
||||
|
||||
Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/ja/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。
|
||||
Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。
|
||||
|
||||
Podのオーバーヘッドを有効にした場合、Podのスケジューリング時にコンテナのリソース要求の合計に加えて、オーバーヘッドも考慮されます。同様に、Kubeletは、Podのcgroupのサイズ決定時およびPodの退役の順位付け時に、Podのオーバーヘッドを含めます。
|
||||
|
||||
|
|
|
|||
|
|
@ -375,7 +375,7 @@ _Pod Security Policy_ はクラスターレベルのリソースで、Pod定義
|
|||
### セキュリティポリシーとセキュリティコンテキストの違いは何ですか?
|
||||
|
||||
[Security Context](/docs/tasks/configure-pod-container/security-context/)は実行時のコンテナやPodを設定するものです。
|
||||
Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメータを示します。
|
||||
Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメーターを示します。
|
||||
|
||||
セキュリティポリシーはコントロールプレーンの機構で、Security Contextとそれ以外も含め、特定の設定を強制するものです。
|
||||
2020年2月時点では、ネイティブにサポートされているポリシー強制の機構は[Pod Security
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ weight: 10
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
{{< glossary_definition term_id="service" length="short" >}}
|
||||
{{< glossary_definition term_id="service" length="short" prepend="KubernetesにおけるServiceとは、" >}}
|
||||
|
||||
Kubernetesでは、なじみのないサービスディスカバリーのメカニズムを使用するためにユーザーがアプリケーションの修正をする必要はありません。
|
||||
KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセットに対する単一のDNS名を提供したり、それらのPodのセットに対する負荷分散が可能です。
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ weight: 50
|
|||
|
||||
## バックグラウンド
|
||||
|
||||
ボリュームの動的プロビジョニングの実装は`storage.k8s.io`というAPIグループ内の`StorageClass`というAPIオブジェクトに基づいています。クラスター管理者は`StorageClass`オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする*Volumeプラグイン* (別名*プロビジョナー*)と、プロビジョンされるときにプロビジョナーに渡されるパラメータを指定します。
|
||||
クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメータのカスタムセットを持ちます。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。
|
||||
ボリュームの動的プロビジョニングの実装は`storage.k8s.io`というAPIグループ内の`StorageClass`というAPIオブジェクトに基づいています。クラスター管理者は`StorageClass`オブジェクトを必要に応じていくつでも定義でき、各オブジェクトはボリュームをプロビジョンする*Volumeプラグイン* (別名*プロビジョナー*)と、プロビジョンされるときにプロビジョナーに渡されるパラメーターを指定します。
|
||||
クラスター管理者はクラスター内で複数の種類のストレージ(同一または異なるストレージシステム)を定義し、さらには公開でき、それらのストレージはパラメーターのカスタムセットを持ちます。この仕組みにおいて、エンドユーザーはストレージがどのようにプロビジョンされるか心配する必要がなく、それでいて複数のストレージオプションから選択できることを保証します。
|
||||
|
||||
StorageClassに関するさらなる情報は[Storage Class](/docs/concepts/storage/storage-classes/)を参照ください。
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Kubernetesは古い容量の情報をもとにノードを選択する場合が
|
|||
|
||||
## ストレージ容量の追跡を有効にする {#enabling-storage-capacity-tracking}
|
||||
|
||||
ストレージ容量の追跡は*アルファ機能*であり、`CSIStorageCapacity`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)と`storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API group" term_id="api-group" >}}を有効にした場合にのみ、有効化されます。詳細については、`--feature-gates`および`--runtime-config` [kube-apiserverパラメータ](/docs/reference/command-line-tools-reference/kube-apiserver/)を参照してください。
|
||||
ストレージ容量の追跡は*アルファ機能*であり、`CSIStorageCapacity`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)と`storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API group" term_id="api-group" >}}を有効にした場合にのみ、有効化されます。詳細については、`--feature-gates`および`--runtime-config` [kube-apiserverパラメーター](/docs/reference/command-line-tools-reference/kube-apiserver/)を参照してください。
|
||||
|
||||
Kubernetesクラスターがこの機能をサポートしているか簡単に確認するには、以下のコマンドを実行して、CSIStorageCapacityオブジェクトを一覧表示します。
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ deletionPolicyが`Delete`の場合、元となるストレージスナップシ
|
|||
|
||||
## Parameters
|
||||
|
||||
VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています。
|
||||
`driver`に応じて様々なパラメータを使用できます。
|
||||
VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメーターを持っています。
|
||||
`driver`に応じて様々なパラメーターを使用できます。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ DaemonSetオブジェクトの名前は、有効な
|
|||
|
||||
`.spec.template`は`.spec`内での必須のフィールドの1つです。
|
||||
|
||||
`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。
|
||||
`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)となります。これはフィールドがネストされていて、`apiVersion`や`kind`をもたないことを除いては、{{< glossary_tooltip text="Pod" term_id="pod" >}}のテンプレートと同じスキーマとなります。
|
||||
|
||||
Podに対する必須のフィールドに加えて、DaemonSet内のPodテンプレートは適切なラベルを指定しなくてはなりません([Podセレクター](#pod-selector)の項目を参照ください)。
|
||||
|
||||
|
|
|
|||
|
|
@ -363,7 +363,7 @@ Deploymentのリビジョンは、Deploymentのロールアウトがトリガー
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
Deploymentコントローラーは、この悪い状態のロールアウトを自動的に停止し、新しいReplicaSetのスケールアップを止めます。これはユーザーが指定したローリングアップデートに関するパラメータ(特に`maxUnavailable`)に依存します。デフォルトではKubernetesがこの値を25%に設定します。
|
||||
Deploymentコントローラーは、この悪い状態のロールアウトを自動的に停止し、新しいReplicaSetのスケールアップを止めます。これはユーザーが指定したローリングアップデートに関するパラメーター(特に`maxUnavailable`)に依存します。デフォルトではKubernetesがこの値を25%に設定します。
|
||||
{{< /note >}}
|
||||
|
||||
* Deploymentの詳細情報を取得します。
|
||||
|
|
@ -803,7 +803,7 @@ echo $?
|
|||
* リソースリミットのレンジ
|
||||
* アプリケーションランタイムの設定の不備
|
||||
|
||||
このような状況を検知する1つの方法として、Deploymentのリソース定義でデッドラインのパラメータを指定します([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds))。`.spec.progressDeadlineSeconds`はDeploymentの更新が停止したことを示す前にDeploymentコントローラーが待つ秒数を示します。
|
||||
このような状況を検知する1つの方法として、Deploymentのリソース定義でデッドラインのパラメーターを指定します([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds))。`.spec.progressDeadlineSeconds`はDeploymentの更新が停止したことを示す前にDeploymentコントローラーが待つ秒数を示します。
|
||||
|
||||
以下の`kubectl`コマンドでリソース定義に`progressDeadlineSeconds`を設定します。これはDeploymentの更新が止まってから10分後に、コントローラーが失敗を通知させるためです。
|
||||
|
||||
|
|
@ -899,7 +899,7 @@ Conditions:
|
|||
Progressing True NewReplicaSetAvailable
|
||||
```
|
||||
|
||||
`Status=True`の`Type=Available`は、Deploymentが最小可用性の状態であることを意味します。最小可用性は、Deploymentの更新戦略において指定されているパラメータにより決定されます。`Status=True`の`Type=Progressing`は、Deploymentのロールアウトの途中で、更新処理が進行中であるか、更新処理が完了し、必要な最小数のレプリカが利用可能であることを意味します(各TypeのReason項目を確認してください。このケースでは、`Reason=NewReplicaSetAvailable`はDeploymentの更新が完了したことを意味します)。
|
||||
`Status=True`の`Type=Available`は、Deploymentが最小可用性の状態であることを意味します。最小可用性は、Deploymentの更新戦略において指定されているパラメーターにより決定されます。`Status=True`の`Type=Progressing`は、Deploymentのロールアウトの途中で、更新処理が進行中であるか、更新処理が完了し、必要な最小数のレプリカが利用可能であることを意味します(各TypeのReason項目を確認してください。このケースでは、`Reason=NewReplicaSetAvailable`はDeploymentの更新が完了したことを意味します)。
|
||||
|
||||
`kubectl rollout status`を実行してDeploymentが更新に失敗したかどうかを確認できます。`kubectl rollout status`はDeploymentが更新処理のデッドラインを超えたときに0以外の終了コードを返します。
|
||||
|
||||
|
|
@ -946,7 +946,7 @@ Deploymentは[`.spec`セクション](https://git.k8s.io/community/contributors/
|
|||
|
||||
`.spec.template`と`.spec.selector`は`.spec`における必須のフィールドです。
|
||||
|
||||
`.spec.template`は[Podテンプレート](/docs/concepts/workloads/pods/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては{{< glossary_tooltip text="Pod" term_id="pod" >}}と同じスキーマとなります。
|
||||
`.spec.template`は[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。これは.spec内でネストされていないことと、`apiVersion`や`kind`を持たないことを除いては{{< glossary_tooltip text="Pod" term_id="pod" >}}と同じスキーマとなります。
|
||||
|
||||
Podの必須フィールドに加えて、Deployment内のPodテンプレートでは適切なラベルと再起動ポリシーを設定しなくてはなりません。ラベルは他のコントローラーと重複しないようにしてください。ラベルについては、[セレクター](#selector)を参照してください。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,147 +0,0 @@
|
|||
---
|
||||
title: ガベージコレクション
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetesのガベージコレクターの役割は、かつてオーナーがいたが、現時点でもはやオーナーがいないようなオブジェクトの削除を行うことです。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## オーナーとその従属オブジェクト {#owners-and-dependents}
|
||||
|
||||
いくつかのKubernetesオブジェクトは他のオブジェクトのオーナーとなります。例えば、ReplicaSetはPodのセットに対するオーナーです。オーナーによって所有されたオブジェクトは、オーナーオブジェクトの*従属オブジェクト(Dependents)* と呼ばれます。全ての従属オブジェクトは、オーナーオブジェクトを指し示す`metadata.ownerReferences`というフィールドを持ちます。
|
||||
|
||||
時々、Kubernetesは`ownerReference`フィールドに値を自動的にセットします。例えば、ユーザーがReplicaSetを作成したとき、KubernetesはReplicaSet内の各Podの`ownerReference`フィールドに自動的に値をセットします。Kubernetes1.8において、KubernetesはReplicaController、ReplicaSet、StatefulSet、DaemonSet、Deployment、Job、CronJobによって作成され、適用されたオブジェクトの`ownerReference`フィールドに自動的にその値をセットします。
|
||||
|
||||
ユーザーはまた`ownerReference`フィールドに手動で値をセットすることにより、オーナーと従属オブジェクト間の関係を指定することができます。
|
||||
|
||||
下記の例は、3つのPodを持つReplicaSetの設定ファイルとなります。
|
||||
|
||||
{{< codenew file="controllers/replicaset.yaml" >}}
|
||||
|
||||
もしユーザーがReplicaSetを作成し、Podのメタデータを見る時、`ownerReference`フィールドの値を確認できます。
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
|
||||
kubectl get pods --output=yaml
|
||||
```
|
||||
|
||||
その出力結果によると、そのPodのオーナーは`my-repset`という名前のReplicaSetです。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
...
|
||||
ownerReferences:
|
||||
- apiVersion: apps/v1
|
||||
controller: true
|
||||
blockOwnerDeletion: true
|
||||
kind: ReplicaSet
|
||||
name: my-repset
|
||||
uid: d9607e19-f88f-11e6-a518-42010a800195
|
||||
...
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
ネームスペースをまたいだownerReferenceは意図的に許可されていません。これは以下のことを意味します。
|
||||
1) ネームスペース内のスコープの従属オブジェクトは、同一のネームスペース内のオーナーと、クラスターのスコープ内のオーナーのみ指定できます。
|
||||
2) クラスターのスコープ内の従属オブジェクトは、クラスターのスコープ内のオーナーオブジェクトのみ指定でき、ネームスペース内のスコープのオーナーオブジェクトは指定できません。
|
||||
{{< /note >}}
|
||||
|
||||
## ガベージコレクターがどのように従属オブジェクトの削除をするかを制御する
|
||||
|
||||
ユーザーがオブジェクトを削除するとき、それに紐づく従属オブジェクトも自動で削除するか指定できます。従属オブジェクトの自動削除は、*カスケード削除(Cascading deletion)* と呼ばれます。*カスケード削除* には2つのモードがあり、*バックグラウンド* と*フォアグラウンド* があります。
|
||||
|
||||
もしユーザーが、従属オブジェクトの自動削除なしにあるオブジェクトを削除する場合、その従属オブジェクトは*みなしご(orphaned)* と呼ばれます。
|
||||
|
||||
### フォアグラウンドのカスケード削除
|
||||
|
||||
*フォアグラウンドのカスケード削除* において、そのルートオブジェクトは最初に"削除処理中"という状態に遷移します。その*削除処理中* 状態において、下記の項目は正となります。
|
||||
|
||||
* そのオブジェクトはREST APIを介して確認可能です。
|
||||
* そのオブジェクトの`deletionTimestamp`がセットされます。
|
||||
* そのオブジェクトの`metadata.finalizers`フィールドは、`foregroundDeletion`という値を含みます。
|
||||
|
||||
一度"削除処理中"状態に遷移すると、そのガベージコレクターはオブジェクトの従属オブジェクトを削除します。一度そのガベージコレクターが全ての”ブロッキングしている”従属オブジェクトを削除すると(`ownerReference.blockOwnerDeletion=true`という値を持つオブジェクト)、それはオーナーのオブジェクトも削除します。
|
||||
|
||||
注意点として、"フォアグラウンドのカスケード削除"において、`ownerReference.blockOwnerDeletion=true`フィールドを持つ従属オブジェクトのみ、そのオーナーオブジェクトの削除をブロックします。
|
||||
Kubernetes1.7では、認証されていない従属オブジェクトがオーナーオブジェクトの削除を遅らせることができないようにするために[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)が追加され、それは、オーナーオブジェクトの削除パーミッションに基づいて`blockOwnerDeletion`の値がtrueに設定してユーザーアクセスをコントロールします。
|
||||
|
||||
もしオブジェクトの`ownerReferences`フィールドがコントローラー(DeploymentやReplicaSetなど)によってセットされている場合、`blockOwnerDeletion`は自動的にセットされ、ユーザーはこのフィールドを手動で修正する必要はありません。
|
||||
|
||||
### バックグラウンドのカスケード削除
|
||||
|
||||
*バックグラウンドのカスケード削除* において、Kubernetesはそのオーナーオブジェクトを即座に削除し、ガベージコレクションはその従属オブジェクトをバックグラウンドで削除します。
|
||||
|
||||
### カスケード削除ポリシーの設定
|
||||
|
||||
カスケード削除ポリシーを制御するためには、オブジェクトをいつ設定するか`deleteOptions`引数上の`propagationPolicy`フィールドに設定してください。設定可能な値は`Orphan`、`Foreground`、もしくは`Background`のどれかです。
|
||||
|
||||
|
||||
下記のコマンドは従属オブジェクトをバックグラウンドで削除する例です。
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
下記のコマンドは従属オブジェクトをフォアグラウンドで削除する例です。
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
下記のコマンドは従属オブジェクトをみなしご状態になった従属オブジェクトの例です。
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
kubectlもまたカスケード削除をサポートしています。
|
||||
kubectlを使って従属オブジェクトを自動的に削除するためには、`--cascade`をtrueにセットしてください。
|
||||
従属オブジェクトを削除せず、みなしご状態にするには`--cascade`をfalseにセットしてください。
|
||||
`--cascade`オプションのデフォルト値はtrueになります。
|
||||
|
||||
下記のコマンドは、ReplicaSetを削除し、その従属オブジェクトをみなしご状態にします。
|
||||
|
||||
```shell
|
||||
kubectl delete replicaset my-repset --cascade=false
|
||||
```
|
||||
|
||||
### Deploymentsに関する追記事項
|
||||
|
||||
Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの*propagationPolicy*が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。
|
||||
さらなる詳細に関しては[kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)を参照してください。
|
||||
|
||||
## 既知の問題について
|
||||
|
||||
[#26120](https://github.com/kubernetes/kubernetes/issues/26120)にてイシューがトラックされています。
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
|
||||
|
||||
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -173,7 +173,7 @@ Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/deve
|
|||
|
||||
`.spec.template`は`.spec`の唯一の必須フィールドです。
|
||||
|
||||
`.spec.template`は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)です。ネストされていることと`apiVersion`や`kind`フィールドが不要になったことを除いて、仕様の定義が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
|
||||
`.spec.template`は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates)です。ネストされていることと`apiVersion`や`kind`フィールドが不要になったことを除いて、仕様の定義が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
|
||||
|
||||
Podの必須フィールドに加えて、Job定義ファイルにあるPodテンプレートでは、適切なラベル([podセレクター](#pod-selector)を参照)と適切な再起動ポリシーを指定する必要があります。
|
||||
|
||||
|
|
|
|||
|
|
@ -193,7 +193,7 @@ ReplicaSetオブジェクトの名前は、有効な
|
|||
|
||||
### Pod テンプレート
|
||||
|
||||
`.spec.template`はラベルを持つことが必要な[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
|
||||
`.spec.template`はラベルを持つことが必要な[Podテンプレート](/ja/docs/concepts/workloads/pods/#pod-templates) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。
|
||||
他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。
|
||||
|
||||
テンプレートの[再起動ポリシー](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ Kubernetes v{{< skew currentVersion >}}では、このフィールドに設定
|
|||
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
|
||||
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
|
||||
|
||||
### Podテンプレート {#pod-template}
|
||||
### Podテンプレート {#pod-templates}
|
||||
|
||||
{{< glossary_tooltip text="workload" term_id="workload" >}}リソース向けのコントローラーは、Podを*Podテンプレート*を元に作成し、あなたの代わりにPodを管理してくれます。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,118 +0,0 @@
|
|||
---
|
||||
title: Podの概観
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このページでは、Kubernetesのオブジェクトモデルにおいて、デプロイ可能な最小単位のオブジェクトである`Pod`に関して説明します。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## Podについて理解する {#understanding-pods}
|
||||
|
||||
*Pod* は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、{{< glossary_tooltip term_id="cluster" >}}で実行されているプロセスを表します。
|
||||
|
||||
Podは、アプリケーションのコンテナ(いくつかの場合においては複数のコンテナ)、ストレージリソース、ユニークなネットワークIP、およびコンテナの実行方法を管理するオプションをカプセル化します。Podはデプロイメントの単位、すなわち*Kubernetesのアプリケーションの単一インスタンス* で、単一の{{< glossary_tooltip term_id="container" >}}または密結合なリソースを共有する少数のコンテナで構成される場合があります。
|
||||
|
||||
[Docker](https://www.docker.com)はKubernetesのPod内で使われる最も一般的なコンテナランタイムですが、Podは他の[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)も同様にサポートしています。
|
||||
|
||||
Kubernetesクラスター内でのPodは2つの主な方法で使うことができます。
|
||||
|
||||
* **単一のコンテナを稼働させるPod** : いわゆる*「1Pod1コンテナ」* 構成のモデルは、最も一般的なKubernetesのユースケースです。
|
||||
このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができ、Kubernetesはコンテナを直接扱うというよりは、Podを管理することになります。
|
||||
* **協調して稼働させる必要がある複数のコンテナを稼働させるPod** : 単一のPodは、リソースを共有する必要があるような、密接に連携した複数の同じ環境にあるコンテナからなるアプリケーションをカプセル化することもできます。 これらの同じ環境にあるコンテナ群は、サービスの結合力の強いユニットを構成することができます。
|
||||
-- 1つのコンテナが、共有されたボリュームからファイルをパブリックな場所に送信し、一方では分割された*サイドカー* コンテナがそれらのファイルを更新します。そのPodはそれらのコンテナとストレージリソースを、単一の管理可能なエンティティとしてまとめます。
|
||||
|
||||
[Kubernetes Blog](https://kubernetes.io/blog)にて、Podのユースケースに関するいくつかの追加情報を見ることができます。さらなる情報を得たい場合は、下記のページを参照ください。
|
||||
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
|
||||
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
|
||||
|
||||
各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。
|
||||
Kubernetesにおいて、これは一般的に _レプリケーション_ と呼ばれます。
|
||||
レプリケーションされたPodは、通常コントローラーと呼ばれる抽象概念によって単一のグループとして作成、管理されます。
|
||||
さらなる情報に関しては[Podとコントローラー](#pods-and-controllers)を参照して下さい。
|
||||
|
||||
### Podがどのように複数のコンテナを管理しているか
|
||||
|
||||
Podは凝集性の高いサービスのユニットを構成するような複数の協調プロセス(コンテナ）をサポートするためにデザインされました。
|
||||
単一のPod内のコンテナ群は、クラスター内において同一の物理マシンもしくは仮想マシン上において自動で同じ環境に配備され、スケジュールされます。コンテナはリソースや依存関係を共有し、お互いにコミュニケートし、それらがいつ、どのように削除されるかを調整できます。
|
||||
|
||||
注意点として、単一のPod内で同じ環境に配備され、同時管理される複数のコンテナをグルーピングするのは、比較的に発展的なユースケースとなります。
|
||||
ユーザーは、コンテナ群が密接に連携するような、特定のインスタンスにおいてのみこのパターンを使用するべきです。
|
||||
例えば、ユーザーが共有ボリューム内にあるファイル用のWebサーバとして稼働するコンテナと、下記のダイアグラムにあるような、リモートのソースからファイルを更新するような分離された*サイドカー* コンテナを持っているような場合です。
|
||||
|
||||
{{< figure src="/images/docs/pod.svg" alt="Podのダイアグラム" width="50%" >}}
|
||||
|
||||
Podは、Podによって構成されたコンテナ群のために2種類の共有リソースを提供します。 *ネットワーキング* と*ストレージ* です。
|
||||
|
||||
#### ネットワーキング
|
||||
|
||||
各Podは固有のIPアドレスを割り当てられます。単一のPod内の各コンテナは、IPアドレスやネットワークポートを含む、そのネットワークの名前空間を共有します。*Pod内の* コンテナは`localhost`を使用してお互いに疎通できます。単一のPod内のコンテナが*Pod外* のエンティティと疎通する場合、共有されたネットワークリソース(ポートなど）をどのように使うかに関して調整しなければなりません。
|
||||
|
||||
#### ストレージ
|
||||
|
||||
単一のPodは共有されたストレージ{{< glossary_tooltip term_id="volume" >}}のセットを指定できます。Pod内の全てのコンテナは、その共有されたボリュームにアクセスでき、コンテナ間でデータを共有することを可能にします。ボリュームもまた、もしPod内のコンテナの1つが再起動が必要になった場合に備えて、データを永続化できます。
|
||||
単一のPod内での共有ストレージをKubernetesがどう実装しているかについてのさらなる情報については、[Volumes](/docs/concepts/storage/volumes/)を参照してください。
|
||||
|
||||
## Podを利用する
|
||||
|
||||
ユーザーはまれに、Kubernetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。
|
||||
これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時(ユーザーによって直接的、またはコントローラーによって間接的に作成された場合)、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。
|
||||
|
||||
{{< note >}}
|
||||
単一のPod内でのコンテナを再起動することと、そのPodを再起動することを混同しないでください。Podはそれ自体は実行されませんが、コンテナが実行される環境であり、削除されるまで存在し続けます。
|
||||
{{< /note >}}
|
||||
|
||||
Podは、Podそれ自体によって自己修復しません。もし、稼働されていないノード上にPodがスケジュールされた場合や、スケジューリング操作自体が失敗した場合、Podが削除されます。同様に、Podはリソースの欠如や、ノードのメンテナンスによる追い出しがあった場合はそこで停止します。Kubernetesは*コントローラー* と呼ばれる高レベルの抽象概念を使用し、それは比較的使い捨て可能なPodインスタンスの管理を行います。
|
||||
このように、Podを直接使うのは可能ですが、コントローラーを使用したPodを管理する方がより一般的です。KubernetesがPodのスケーリングと修復機能を実現するためにコントローラーをどのように使うかに関する情報は[Podとコントローラー](#pods-and-controllers)を参照してください。
|
||||
|
||||
### Podとコントローラー
|
||||
|
||||
単一のコントローラーは、ユーザーのために複数のPodを作成・管理し、レプリケーションやロールアウト、クラスターのスコープ内で自己修復の機能をハンドリングします。例えば、もしノードが故障した場合、コントローラーは異なるノード上にPodを置き換えるようにスケジューリングすることで、自動的にリプレース可能となります。
|
||||
|
||||
1つまたはそれ以上のPodを含むコントローラーの例は下記の通りです。
|
||||
|
||||
* [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)
|
||||
* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
通常は、コントローラーはユーザーが作成したPodテンプレートを使用して、担当するPodを作成します。
|
||||
|
||||
## Podテンプレート
|
||||
|
||||
Podテンプレートは、[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)や、
|
||||
[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)のような他のオブジェクト内で含まれるPodの仕様となります。
|
||||
コントローラーは実際のPodを作成するためにPodテンプレートを使用します。
|
||||
下記のサンプルは、メッセージを表示する単一のコンテナを含んだ、シンプルなPodのマニフェストとなります。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: myapp-pod
|
||||
labels:
|
||||
app: myapp
|
||||
spec:
|
||||
containers:
|
||||
- name: myapp-container
|
||||
image: busybox
|
||||
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
|
||||
```
|
||||
|
||||
全てのレプリカの現在の理想的な状態を指定するというよりも、Podテンプレートはクッキーの抜き型のようなものです。一度クッキーがカットされると、そのクッキーは抜き型から離れて関係が無くなります。そこにはいわゆる”量子もつれ”といったものはありません。テンプレートに対するその後の変更や新しいテンプレートへの切り替えは、すでに作成されたPod上には直接的な影響はありません。
|
||||
同様に、ReplicationControllerによって作成されたPodは、変更後に直接更新されます。これはPodとの意図的な違いとなり、そのPodに属する全てのコンテナの現在の理想的な状態を指定します。このアプローチは根本的にシステムのセマンティクスを単純化し、機能の柔軟性を高めます。
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Pod](/ja/docs/concepts/workloads/pods/pod/)についてさらに学びましょう
|
||||
* Podの振る舞いに関して学ぶには下記を参照してください
|
||||
* [Podの停止](/ja/docs/concepts/workloads/pods/pod/#termination-of-pods)
|
||||
* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
---
|
||||
reviewers:
|
||||
title: Pod Preset
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
|
||||
|
||||
このページではPodPresetについて概観します。PodPresetは、Podの作成時にそのPodに対して、Secret、Volume、VolumeMountや環境変数など、特定の情報を注入するためのオブジェクトです。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## PodPresetを理解する
|
||||
|
||||
`PodPreset`はPodの作成時に追加のランタイム要求を注入するためのAPIリソースです。ユーザーはPodPresetを適用する対象のPodを指定するために、[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)を使用します。
|
||||
|
||||
PodPresetの使用により、Podテンプレートの作者はPodにおいて、全ての情報を明示的に指定する必要がなくなります。この方法により、特定のServiceを使っているPodテンプレートの作者は、そのServiceについて全ての詳細を知る必要がなくなります。
|
||||
|
||||
|
||||
## クラスターでPodPresetを有効にする {#enable-pod-preset}
|
||||
|
||||
ユーザーのクラスター内でPodPresetを使うためには、クラスター内の以下の項目をご確認ください。
|
||||
|
||||
1. `settings.k8s.io/v1alpha1/podpreset`というAPIを有効にします。例えば、これはAPI Serverの `--runtime-config`オプションに`settings.k8s.io/v1alpha1=true`を含むことで可能になります。Minikubeにおいては、クラスターの起動時に`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`をつけることで可能です。
|
||||
1. `PodPreset`に対する管理コントローラーを有効にします。これを行うための1つの方法として、API Serverの`--enable-admission-plugins`オプションの値に`PodPreset`を含む方法があります。例えば、Minikubeにおいては、クラスターの起動時に
|
||||
|
||||
```shell
|
||||
--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
|
||||
```
|
||||
|
||||
を追加することで可能になります。
|
||||
|
||||
## PodPresetはどのように動くか
|
||||
|
||||
|
||||
Kubernetesは`PodPreset`に対する管理用コントローラーを提供し、これが有効になっている時、コントローラーはリクエストされたPod作成要求に対してPodPresetを適用します。Pod作成要求が発生した時、Kubernetesシステムは下記の処理を行います。
|
||||
|
||||
1. 使用可能な全ての`PodPreset`を取得する。
|
||||
1. それらの`PodPreset`のラベルセレクターが、作成されたPod上のラベルと一致するかチェックする。
|
||||
1. `PodPreset`によって定義された様々なリソースを、作成されたPodにマージしようと試みる。
|
||||
1. エラーが起きた時、そのPod上でマージエラーが起きたことを説明するイベントをスローし、`PodPreset`からリソースを1つも注入されていないPodを作成します。
|
||||
1. `PodPreset`によって修正されたことを示すために、マージ後の修正されたPodにアノテーションをつけます。そのアノテーションは`podpreset.admission.kubernetes.io/podpreset-<PodPreset名>: "<リソースのバージョン>"`という形式になります。
|
||||
|
||||
各Podは0以上のPodPresetにマッチすることができます。そして各PodPresetは0以上のPodに適用されます。単一のPodPresetが1以上のPodに適用された時、KubernetesはそのPodのSpecを修正します。`env`、`envFrom`、`volumeMounts`への変更があると、KubernetesはそのPod内の全てのコンテナのSpecを修正します。`volumes`への変更があった場合、KubernetesはそのPodのSpecを修正します。
|
||||
|
||||
{{< note >}}
|
||||
単一のPodPresetは必要に応じてPodのspec内の以下のフィールドを修正することができます。
|
||||
- `.spec.containers`フィールド
|
||||
- `.spec.initContainers`フィールド
|
||||
{{< /note >}}
|
||||
|
||||
### 特定のPodに対するPodPresetを無効にする
|
||||
|
||||
PodPresetによるPodの変更を受け付けたくないようなインスタンスがある場合があります。このようなケースでは、ユーザーはそのPodの`.spec`内に次のような形式のアノテーションを追加できます。
|
||||
`podpreset.admission.kubernetes.io/exclude: "true"`
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[PodPresetを使ったPodへのデータの注入](/docs/tasks/inject-data-application/podpreset/)
|
||||
|
||||
PodPresetの内部についてのさらなる情報は、[PodPresetのデザインプロポーザル](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)を参照してください。
|
||||
|
|
@ -37,7 +37,7 @@ weight: 120
|
|||
### 機能の状態コード
|
||||
|
||||
表示されるKubernetesのバージョンのデフォルトはそのページのデフォルトまたはサイトのデフォルトです。
|
||||
`for_k8s_version`パラメータを渡すことにより、機能の状態バージョンを変更することができます。
|
||||
`for_k8s_version`パラメーターを渡すことにより、機能の状態バージョンを変更することができます。
|
||||
例えば:
|
||||
|
||||
```
|
||||
|
|
@ -283,7 +283,7 @@ Kubernetesの実行にはサードパーティーのソフトウェアが必要
|
|||
## バージョン文字列
|
||||
|
||||
ドキュメント内でバージョン文字列を生成して挿入するために、いくつかのバージョンショートコードから選んで使用することができます。
|
||||
それぞれのバージョンショートコードはサイトの設定ファイル(`config.toml`)から取得したバージョンパラメーターの値を使用してバージョン文字列を表示します。
|
||||
それぞれのバージョンショートコードはサイトの設定ファイル(`hugo.toml`)から取得したバージョンパラメーターの値を使用してバージョン文字列を表示します。
|
||||
最もよく使われる二つのバージョンパラメーターは`latest`と`version`です。
|
||||
|
||||
### `{{</* param "version" */>}}`
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: ガベージコレクション
|
||||
id: garbage-collection
|
||||
date: 2021-07-07
|
||||
full_link: /ja/docs/concepts/architecture/garbage-collection/
|
||||
short_description: >
|
||||
Kubernetesがクラスターリソースをクリーンアップするために使用するさまざまなメカニズムの総称です。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
|
||||
ガベージコレクションは、Kubernetesがクラスターリソースをクリーンアップするために使用するさまざまなメカニズムの総称です。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetesはガベージコレクションを使用して、[未使用のコンテナとイメージ](/ja/docs/concepts/architecture/garbage-collection/#containers-images)、[失敗したPod](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)、[対象リソースが所有するオブジェクト](/ja/docs/concepts/overview/working-with-objects/owners-dependents/)、[完了したJob](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)、期限切れまたは失敗したリソースなどのリソースをクリーンアップします。
|
||||
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
title: Pod
|
||||
id: pod
|
||||
date: 2018-04-12
|
||||
full_link: /ja/docs/concepts/workloads/pods/pod-overview/
|
||||
full_link: /ja/docs/concepts/workloads/pods/
|
||||
short_description: >
|
||||
一番小さく一番シンプルな Kubernetes のオブジェクト。Pod とはクラスターで動作しているいくつかのコンテナのまとまりです。
|
||||
|
||||
|
|
|
|||
|
|
@ -5,16 +5,18 @@ date: 2018-04-12
|
|||
full_link: /ja/docs/concepts/services-networking/service/
|
||||
short_description: >
|
||||
Podの集合で実行されているアプリケーションをネットワークサービスとして公開する方法。
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
{{< glossary_tooltip text="Pod" term_id="pod" >}}の集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法です。
|
||||
クラスター内で1つ以上の{{< glossary_tooltip text="Pod" term_id="pod" >}}として実行されているネットワークアプリケーションを公開する方法です。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Serviceが対象とするPodの集合は、(通常){{< glossary_tooltip text="セレクター" term_id="selector" >}}によって決定されます。
|
||||
Podを追加または削除するとセレクターにマッチしているPodの集合は変更されます。
|
||||
Serviceは、ネットワークトラフィックが現在そのワークロードを処理するPodの集合に向かうことを保証します。
|
||||
|
||||
Kubernetes Serviceは、IPネットワーキング(IPv4、IPv6、またはその両方)を使用するか、ドメインネームシステム(DNS)でExternal Nameを参照します。
|
||||
|
||||
Serviceの抽象化により、IngressやGatewayなどの他のメカニズムを実現することができます。
|
||||
|
|
@ -13,11 +13,11 @@ card:
|
|||
|
||||
このツールの名前は、`kubectl` です。
|
||||
|
||||
`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
|
||||
`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
|
||||
|
||||
この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。
|
||||
|
||||
インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。クイックガイドは、[cheat sheet](/docs/reference/kubectl/cheatsheet/) をご覧ください。`docker`コマンドラインツールに慣れている方は、[`kubectl` for Docker Users](/docs/reference/kubectl/docker-cli-to-kubectl/) でKubernetesの同等のコマンドを説明しています。
|
||||
インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。クイックガイドは、[チートシート](/ja/docs/reference/kubectl/cheatsheet/)をご覧ください。`docker`コマンドラインツールに慣れている方は、[`kubectl` for Docker Users](/docs/reference/kubectl/docker-cli-to-kubectl/)でKubernetesの同等のコマンドを説明しています。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: ネットワーキングのリファレンス
|
||||
content_type: reference
|
||||
weight: 85
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このセクションでは、Kubernetesネットワーキングの詳細を提供します。
|
||||
|
||||
<!-- body -->
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
title: ポートとプロトコル
|
||||
content_type: reference
|
||||
weight: 40
|
||||
---
|
||||
|
||||
パブリッククラウドにおける仮想ネットワークや、物理ネットワークファイアウォールを持つオンプレミスのデータセンターのような、ネットワークの境界が厳格な環境でKubernetesを実行する場合、Kubernetesのコンポーネントが使用するポートやプロトコルを認識しておくと便利です。
|
||||
|
||||
## コントロールプレーン {#control-plane}
|
||||
|
||||
|
||||
| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 |
|
||||
|------------|------------|-------------|-------------------------|---------------------------|
|
||||
| TCP | Inbound | 6443 | Kubernetes API server | 全て |
|
||||
| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd |
|
||||
| TCP | Inbound | 10250 | Kubelet API | 自身, コントロールプレーン |
|
||||
| TCP | Inbound | 10259 | kube-scheduler | 自身 |
|
||||
| TCP | Inbound | 10257 | kube-controller-manager | 自身 |
|
||||
|
||||
etcdポートはコントロールプレーンノードに含まれていますが、独自のetcdクラスターを外部またはカスタムポートでホストすることもできます。
|
||||
|
||||
## ワーカーノード {#node}
|
||||
|
||||
| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 |
|
||||
|------------|------------|-------------|-----------------------|-------------------------|
|
||||
| TCP | Inbound | 10250 | Kubelet API | 自身, コントロールプレーン |
|
||||
| TCP | Inbound | 30000-32767 | NodePort Services† | 全て |
|
||||
|
||||
† [NodePort Services](/ja/docs/concepts/services-networking/service/)のデフォルトのポート範囲。
|
||||
|
||||
|
||||
すべてのデフォルトのポート番号が書き換え可能です。
|
||||
カスタムポートを使用する場合、ここに記載されているデフォルトではなく、それらのポートを開く必要があります。
|
||||
|
||||
よくある例としては、API Serverのポートを443に変更することがあります。
|
||||
または、デフォルトポートをそのままにし、API Serverを443でリッスンしているロードバランサーの後ろに置き、APIサーバのデフォルトポートにリクエストをルーティングする方法もあります。
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: PKI証明書とその要件
|
||||
content_type: concept
|
||||
weight: 40
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: 大規模クラスターの構築
|
||||
weight: 20
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: 複数のゾーンで動かす
|
||||
weight: 10
|
||||
weight: 20
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
title: オンプレミスVM
|
||||
weight: 40
|
||||
---
|
||||
|
|
@ -1,118 +0,0 @@
|
|||
---
|
||||
title: Cloudstack
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
[CloudStack](https://cloudstack.apache.org/) is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
|
||||
|
||||
[CoreOS](https://coreos.com) templates for CloudStack are built [nightly](https://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions.
|
||||
|
||||
This guide uses a single [Ansible playbook](https://github.com/apachecloudstack/k8s), which is completely automated and can deploy Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 前提条件
|
||||
|
||||
```shell
|
||||
sudo apt-get install -y python-pip libssl-dev
|
||||
sudo pip install cs
|
||||
sudo pip install sshpubkeys
|
||||
sudo apt-get install software-properties-common
|
||||
sudo apt-add-repository ppa:ansible/ansible
|
||||
sudo apt-get update
|
||||
sudo apt-get install ansible
|
||||
```
|
||||
|
||||
On CloudStack server you also have to install libselinux-python :
|
||||
|
||||
```shell
|
||||
yum install libselinux-python
|
||||
```
|
||||
|
||||
[_cs_](https://github.com/exoscale/cs) is a python module for the CloudStack API.
|
||||
|
||||
Set your CloudStack endpoint, API keys and HTTP method used.
|
||||
|
||||
You can define them as environment variables: `CLOUDSTACK_ENDPOINT`, `CLOUDSTACK_KEY`, `CLOUDSTACK_SECRET` and `CLOUDSTACK_METHOD`.
|
||||
|
||||
Or create a `~/.cloudstack.ini` file:
|
||||
|
||||
```none
|
||||
[cloudstack]
|
||||
endpoint = <your cloudstack api endpoint>
|
||||
key = <your api access key>
|
||||
secret = <your api secret key>
|
||||
method = post
|
||||
```
|
||||
|
||||
We need to use the http POST method to pass the _large_ userdata to the coreOS instances.
|
||||
|
||||
### playbookのクローン
|
||||
|
||||
```shell
|
||||
git clone https://github.com/apachecloudstack/k8s
|
||||
cd kubernetes-cloudstack
|
||||
```
|
||||
|
||||
### Kubernetesクラスターの作成
|
||||
|
||||
You simply need to run the playbook.
|
||||
|
||||
```shell
|
||||
ansible-playbook k8s.yml
|
||||
```
|
||||
|
||||
Some variables can be edited in the `k8s.yml` file.
|
||||
|
||||
```none
|
||||
vars:
|
||||
ssh_key: k8s
|
||||
k8s_num_nodes: 2
|
||||
k8s_security_group_name: k8s
|
||||
k8s_node_prefix: k8s2
|
||||
k8s_template: <templatename>
|
||||
k8s_instance_type: <serviceofferingname>
|
||||
```
|
||||
|
||||
This will start a Kubernetes master node and a number of compute nodes (by default 2).
|
||||
The `instance_type` and `template` are specific, edit them to specify your CloudStack cloud specific template and instance type (i.e. service offering).
|
||||
|
||||
Check the tasks and templates in `roles/k8s` if you want to modify anything.
|
||||
|
||||
Once the playbook as finished, it will print out the IP of the Kubernetes master:
|
||||
|
||||
```none
|
||||
TASK: [k8s | debug msg='k8s master IP is {{ k8s_master.default_ip }}'] ********
|
||||
```
|
||||
|
||||
SSH to it using the key that was created and using the _core_ user.
|
||||
|
||||
```shell
|
||||
ssh -i ~/.ssh/id_rsa_k8s core@<master IP>
|
||||
```
|
||||
|
||||
And you can list the machines in your cluster:
|
||||
|
||||
```shell
|
||||
fleetctl list-machines
|
||||
```
|
||||
|
||||
```none
|
||||
MACHINE IP METADATA
|
||||
a017c422... <node #1 IP> role=node
|
||||
ad13bf84... <master IP> role=master
|
||||
e9af8293... <node #2 IP> role=node
|
||||
```
|
||||
|
||||
## サポートレベル
|
||||
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
CloudStack | Ansible | CoreOS | flannel | [docs](/docs/setup/production-environment/on-premises-vm/cloudstack/) | | Community ([@Guiques](https://github.com/ltupin/))
|
||||
|
||||
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
title: DC/OS上のKubernetes
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Mesosphereは[DC/OS](https://mesosphere.com/product/)上にKubernetesを構築するための簡単な選択肢を提供します。それは
|
||||
|
||||
* 純粋なアップストリームのKubernetes
|
||||
* シングルクリッククラスター構築
|
||||
* デフォルトで高可用であり安全
|
||||
* Kubernetesが高速なデータプラットフォーム(例えばAkka、Cassandra、Kafka、Spark)と共に稼働
|
||||
|
||||
です。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 公式Mesosphereガイド
|
||||
|
||||
DC/OS入門の正規のソースは[クイックスタートリポジトリ](https://github.com/mesosphere/dcos-kubernetes-quickstart)にあります。
|
||||
|
||||
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
---
|
||||
title: oVirt
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## oVirtクラウドプロバイダーによる構築
|
||||
|
||||
The oVirt cloud provider allows to easily discover and automatically add new VM instances as nodes to your Kubernetes cluster.
|
||||
At the moment there are no community-supported or pre-loaded VM images including Kubernetes but it is possible to [import] or [install] Project Atomic (or Fedora) in a VM to [generate a template]. Any other distribution that includes Kubernetes may work as well.
|
||||
|
||||
It is mandatory to [install the ovirt-guest-agent] in the guests for the VM ip address and hostname to be reported to ovirt-engine and ultimately to Kubernetes.
|
||||
|
||||
Once the Kubernetes template is available it is possible to start instantiating VMs that can be discovered by the cloud provider.
|
||||
|
||||
[import]: https://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html
|
||||
[install]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#create-virtual-machines
|
||||
[generate a template]: https://www.ovirt.org/documentation/quickstart/quickstart-guide/#using-templates
|
||||
[install the ovirt-guest-agent]: https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-agent-in-fedora/
|
||||
|
||||
## oVirtクラウドプロバイダーの使用
|
||||
|
||||
The oVirt Cloud Provider requires access to the oVirt REST-API to gather the proper information, the required credential should be specified in the `ovirt-cloud.conf` file:
|
||||
|
||||
```none
|
||||
[connection]
|
||||
uri = https://localhost:8443/ovirt-engine/api
|
||||
username = admin@internal
|
||||
password = admin
|
||||
```
|
||||
|
||||
In the same file it is possible to specify (using the `filters` section) what search query to use to identify the VMs to be reported to Kubernetes:
|
||||
|
||||
```none
|
||||
[filters]
|
||||
# Search query used to find nodes
|
||||
vms = tag=kubernetes
|
||||
```
|
||||
|
||||
In the above example all the VMs tagged with the `kubernetes` label will be reported as nodes to Kubernetes.
|
||||
|
||||
The `ovirt-cloud.conf` file then must be specified in kube-controller-manager:
|
||||
|
||||
```shell
|
||||
kube-controller-manager ... --cloud-provider=ovirt --cloud-config=/path/to/ovirt-cloud.conf ...
|
||||
```
|
||||
|
||||
## oVirtクラウドプロバイダーのスクリーンキャスト
|
||||
|
||||
This short screencast demonstrates how the oVirt Cloud Provider can be used to dynamically add VMs to your Kubernetes cluster.
|
||||
|
||||
[](https://www.youtube.com/watch?v=JyyST4ZKne8)
|
||||
|
||||
## サポートレベル
|
||||
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
oVirt | | | | [docs](/docs/setup/production-environment/on-premises-vm/ovirt/) | | Community ([@simon3z](https://github.com/simon3z))
|
||||
|
||||
|
||||
|
|
@ -48,48 +48,17 @@ card:
|
|||
|
||||
複数のネットワークアダプターがあり、Kubernetesコンポーネントにデフォルトで到達できない場合、IPルートを追加して、Kubernetesクラスターのアドレスが適切なアダプターを経由するように設定することをお勧めします。
|
||||
|
||||
## iptablesがブリッジを通過するトラフィックを処理できるようにする
|
||||
|
||||
Linuxノードのiptablesがブリッジを通過するトラフィックを正確に処理する要件として、`net.bridge.bridge-nf-call-iptables`を`sysctl`の設定ファイルで1に設定してください。例えば以下のようにします。
|
||||
|
||||
```bash
|
||||
cat <<EOF > /etc/sysctl.d/k8s.conf
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
EOF
|
||||
sysctl --system
|
||||
```
|
||||
|
||||
この手順の前に`br_netfilter`モジュールがロードされていることを確認してください。`lsmod | grep br_netfilter`を実行することで確認できます。明示的にロードするには`modprobe br_netfilter`を実行してください。
|
||||
|
||||
詳細は[ネットワークプラグインの要件](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)を参照してください。
|
||||
|
||||
## 必須ポートの確認
|
||||
|
||||
### コントロールプレーンノード
|
||||
Kubernetesのコンポーネントが互いに通信するためには、これらの[必要なポート](/ja/docs/reference/networking/ports-and-protocols/)が開いている必要があります。
|
||||
netcatなどのツールを使用することで、下記のようにポートが開いているかどうかを確認することが可能です。
|
||||
|
||||
| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 |
|
||||
|-----------|------------|------------|-------------------------|---------------------------|
|
||||
| TCP | Inbound | 6443* | Kubernetes API server | 全て |
|
||||
| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver、etcd |
|
||||
| TCP | Inbound | 10250 | Kubelet API | 自身、コントロールプレーン |
|
||||
| TCP | Inbound | 10259 | kube-scheduler | 自身 |
|
||||
| TCP | Inbound | 10257 | kube-controller-manager | 自身 |
|
||||
```shell
|
||||
nc 127.0.0.1 6443
|
||||
```
|
||||
|
||||
### ワーカーノード
|
||||
|
||||
| プロトコル | 通信の向き | ポート範囲 | 目的 | 使用者 |
|
||||
|-----------|------------|-------------|-------------------------|---------------------------|
|
||||
| TCP | Inbound | 10250 | Kubelet API | 自身、コントロールプレーン |
|
||||
| TCP | Inbound | 30000-32767 | NodePort Service† | 全て |
|
||||
|
||||
† [NodePort Service](/ja/docs/concepts/services-networking/service/)のデフォルトのポートの範囲
|
||||
|
||||
\*の項目は書き換え可能です。そのため、あなたが指定したカスタムポートも開いていることを確認する必要があります。
|
||||
|
||||
etcdポートはコントロールプレーンノードに含まれていますが、独自のetcdクラスターを外部またはカスタムポートでホストすることもできます。
|
||||
|
||||
使用するPodネットワークプラグイン(以下を参照)のポートも開く必要があります。これは各Podネットワークプラグインによって異なるため、必要なポートについてはプラグインのドキュメントを参照してください。
|
||||
使用するPodネットワークプラグインによっては、特定のポートを開く必要がある場合もあります。
|
||||
これらは各Podネットワークプラグインによって異なるため、どのようなポートが必要かについては、プラグインのドキュメントを参照してください。
|
||||
|
||||
## ランタイムのインストール {#installing-runtime}
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub
|
|||
|
||||
### インスタンス固有の設定内容を適用 {#providing-instance-specific-configuration-details}
|
||||
|
||||
いくつかのホストでは、ハードウェア、オペレーティングシステム、ネットワーク、その他ホスト固有のパラメータの違いのため、特定のkubeletの設定を必要とします。以下にいくつかの例を示します。
|
||||
いくつかのホストでは、ハードウェア、オペレーティングシステム、ネットワーク、その他ホスト固有のパラメーターの違いのため、特定のkubeletの設定を必要とします。以下にいくつかの例を示します。
|
||||
|
||||
- DNS解決ファイルへのパスは`--resolv-conf`フラグで指定することができますが、オペレーティングシステムや`systemd-resolved`を使用するかどうかによって異なる場合があります。このパスに誤りがある場合、そのNode上でのDNS解決は失敗します。
|
||||
- クラウドプロバイダーを使用していない場合、Node APIオブジェクト`.metadata.name`はデフォルトでマシンのホスト名に設定されます。異なるNode名を指定する必要がある場合には、`--hostname-override`フラグによってこの挙動を書き換えることができます。
|
||||
|
|
@ -72,7 +72,7 @@ ComponentConfigの詳細については、[このセクション](#configure-kub
|
|||
KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..."
|
||||
```
|
||||
|
||||
kubelet起動時に渡されるフラグに加えて、このファイルはcgroupドライバーや異なるCRIランタイムソケットを使用するかどうか(`--cri-socket`)といった動的なパラメータも含みます。
|
||||
kubelet起動時に渡されるフラグに加えて、このファイルはcgroupドライバーや異なるCRIランタイムソケットを使用するかどうか(`--cri-socket`)といった動的なパラメーターも含みます。
|
||||
|
||||
これら二つのファイルがディスク上に格納されると、systemdを使用している場合、kubeadmは以下の二つのコマンドを実行します。
|
||||
|
||||
|
|
|
|||
|
|
@ -221,7 +221,7 @@ Windowsには厳密な互換性ルールがあり、ホストOSのバージョ
|
|||
|
||||
Windowsには、Linuxのようなメモリ不足のプロセスキラーはありません。Windowsは常に全ユーザーモードのメモリ割り当てを仮想として扱い、ページファイルは必須です。正味の効果は、WindowsはLinuxのようなメモリ不足の状態にはならず、メモリ不足（OOM）終了の影響を受ける代わりにページをディスクに処理します。メモリが過剰にプロビジョニングされ、物理メモリのすべてが使い果たされると、ページングによってパフォーマンスが低下する可能性があります。
|
||||
|
||||
2ステップのプロセスで、メモリ使用量を妥当な範囲内に保つことが可能です。まず、kubeletパラメータ`--kubelet-reserve`や`--system-reserve`を使用して、ノード（コンテナ外）でのメモリ使用量を明確にします。これにより、[NodeAllocatable](/ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable))が削減されます。ワークロードをデプロイするときは、コンテナにリソース制限をかけます（制限のみを設定するか、制限が要求と等しくなければなりません）。これにより、NodeAllocatableも差し引かれ、ノードのリソースがフルな状態になるとSchedulerがPodを追加できなくなります。
|
||||
2ステップのプロセスで、メモリ使用量を妥当な範囲内に保つことが可能です。まず、kubeletパラメーター`--kubelet-reserve`や`--system-reserve`を使用して、ノード（コンテナ外）でのメモリ使用量を明確にします。これにより、[NodeAllocatable](/ja/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable))が削減されます。ワークロードをデプロイするときは、コンテナにリソース制限をかけます（制限のみを設定するか、制限が要求と等しくなければなりません）。これにより、NodeAllocatableも差し引かれ、ノードのリソースがフルな状態になるとSchedulerがPodを追加できなくなります。
|
||||
|
||||
過剰なプロビジョニングを回避するためのベストプラクティスは、Windows、Docker、およびKubernetesのプロセスに対応するために、最低2GBのメモリを予約したシステムでkubeletを構成することです。
|
||||
|
||||
|
|
@ -481,7 +481,7 @@ Kubernetesクラスターのトラブルシューティングの主なヘルプ
|
|||
|
||||
1. コンテナのvNICとHNSエンドポイントが削除されています
|
||||
|
||||
この問題は、`hostname-override`パラメータが[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)に渡されない場合に発生する可能性があります。これを解決するには、ユーザーは次のようにホスト名をkube-proxyに渡す必要があります。:
|
||||
この問題は、`hostname-override`パラメーターが[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)に渡されない場合に発生する可能性があります。これを解決するには、ユーザーは次のようにホスト名をkube-proxyに渡す必要があります。:
|
||||
|
||||
```powershell
|
||||
C:\k\kube-proxy.exe --hostname-override=$(hostname)
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
title: サービスディスカバリーにCoreDNSを使用する
|
||||
min-kubernetes-server-version: v1.9
|
||||
content_type: task
|
||||
weight: 380
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -21,7 +22,6 @@ content_type: task
|
|||
|
||||
既存のデプロイでkube-dnsを置き換えるか、クラスターのデプロイとアップグレードを代行してくれるkubeadmのようなツールを使用することで、クラスターでkube-dnsの代わりにCoreDNSを使用することができます。
|
||||
|
||||
|
||||
## CoreDNSのインストール {#installing-coredns}
|
||||
|
||||
kube-dnsの手動デプロイや置き換えについては、[CoreDNS GitHub project](https://github.com/coredns/deployment/tree/master/kubernetes)のドキュメントを参照してください。
|
||||
|
|
@ -30,53 +30,32 @@ kube-dnsの手動デプロイや置き換えについては、[CoreDNS GitHub pr
|
|||
|
||||
### kubeadmを使用した既存のクラスターのアップグレード {#upgrading-an-existing-cluster-with-kubeadm}
|
||||
|
||||
Kubernetesバージョン1.10以降では、`kube-dns`を使用しているクラスターを`kubeadm`を使用してアップグレードするときに、CoreDNSに移行することもできます。この場合、`kubeadm`は、`kube-dns` ConfigMapをベースにしてCoreDNS設定("Corefile")を生成し、フェデレーション、スタブドメイン、および上流のネームサーバーの設定を保持します。
|
||||
Kubernetesバージョン1.21で`kubeadm`はDNSアプリケーションとしての`kube-dns`に対するサポートを削除しました。
|
||||
`kubeadm` v{{< skew currentVersion >}}に対してサポートされるクラスターDNSアプリケーションは`CoreDNS`のみです。
|
||||
|
||||
kube-dnsからCoreDNSに移行する場合は、アップグレード時に必ず`CoreDNS`フィーチャーゲートを`true`に設定してください。たとえば、`v1.11.0`のアップグレードは次のようになります:
|
||||
```
|
||||
kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
|
||||
```
|
||||
|
||||
Kubernetesバージョン1.13以降では、`CoreDNS`フィーチャーゲートが削除され、CoreDNSがデフォルトで使用されます。アップグレードしたクラスターでkube-dnsを使用する場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)のガイドに従ってください。
|
||||
|
||||
1.11以前のバージョンでは、Corefileはアップグレード中に作成されたものによって**上書き**されます。**カスタマイズしている場合は、既存のConfigMapを保存する必要があります。** 新しいConfigMapが稼働したら、カスタマイズを再適用できます。
|
||||
|
||||
Kubernetesバージョン1.11以降でCoreDNSを実行している場合、アップグレード中、既存のCorefileは保持されます。
|
||||
|
||||
|
||||
### kubeadmを使用してCoreDNSの代わりにkube-dnsをインストールする {#installing-kube-dns-instead-of-coredns-with-kubeadm}
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes 1.11では、CoreDNSは一般利用可能(GA)にアップグレードされ、デフォルトでインストールされます。
|
||||
{{< /note >}}
|
||||
|
||||
{{< warning >}}
|
||||
Kubernetes 1.18では、kubeadmでのkube-dns使用は非推奨となり、将来のバージョンでは削除されます。
|
||||
{{< /warning >}}
|
||||
|
||||
1.13以前のバージョンにkube-dnsをインストールするには、`CoreDNS`フィーチャーゲートの値を`false`に設定します:
|
||||
|
||||
```
|
||||
kubeadm init --feature-gates=CoreDNS=false
|
||||
```
|
||||
|
||||
バージョン1.13以降の場合は、[こちら](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)に記載されているガイドに従ってください。
|
||||
`kube-dns`を使用しているクラスターを`kubeadm`を使用してアップグレードするときに、CoreDNSに移行することができます。
|
||||
この場合、`kubeadm`は、`kube-dns` ConfigMapをベースにして`CoreDNS`設定("Corefile")を生成し、スタブドメインおよび上流のネームサーバーの設定を保持します。
|
||||
|
||||
## CoreDNSのアップグレード {#upgrading-coredns}
|
||||
|
||||
CoreDNSはv1.9以降のKubernetesで使用できます。Kubernetesに同梱されているCoreDNSのバージョンと、CoreDNSに加えられた変更は[こちら](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)で確認できます。
|
||||
Kubernetesのバージョンごとに`kubeadm`がインストールする`CoreDNS`のバージョンは、[KubernetesにおけるCoreDNSのバージョン](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)のページで確認することができます。
|
||||
|
||||
CoreDNSだけをアップグレードしたい場合や、独自のカスタムイメージを使用したい場合は、CoreDNSを手動でアップグレードすることができます。スムーズなアップグレードのために役立つ[ガイドラインとウォークスルー](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)が用意されています。
|
||||
|
||||
`CoreDNS`のみをアップグレードしたい場合や、独自のカスタムイメージを使用したい場合は、`CoreDNS`を手動でアップグレードすることができます。
|
||||
スムーズなアップグレードのために役立つ[ガイドラインとウォークスルー](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)が用意されています。
|
||||
クラスターをアップグレードする際には、既存の`CoreDNS`設定("Corefile")が保持されていることを確認してください。
|
||||
|
||||
`kubeadm`ツールを使用してクラスターをアップグレードしている場合、`kubeadm`は既存のCoreDNSの設定を自動的に保持する処理を行うことができます。
|
||||
|
||||
## CoreDNSのチューニング {#tuning-coredns}
|
||||
|
||||
リソース使用率が問題になる場合は、CoreDNSの設定を調整すると役立つ場合があります。詳細は、[CoreDNSのスケーリングに関するドキュメント](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)を参照してください。
|
||||
|
||||
|
||||
リソース使用率が問題になる場合は、CoreDNSの設定を調整すると役立つ場合があります。
|
||||
詳細は、[CoreDNSのスケーリングに関するドキュメント](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)を参照してください。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[CoreDNS](https://coredns.io)は、`Corefile`を変更することで、kube-dnsよりも多くのユースケースをサポートするように設定することができます。詳細は[CoreDNSサイト](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。
|
||||
[CoreDNS](https://coredns.io)は、設定("Corefile")を変更することで、`kube-dns`よりも多くのユースケースをサポートする構成にすることができます。
|
||||
詳細はKubernetes CoreDNSプラグインの[ドキュメント](https://coredns.io/plugins/kubernetes/)を参照するか、[CoreDNSブログ](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)を参照してください。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実
|
|||
|
||||
```PowerShell
|
||||
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
|
||||
.\PrepareNode.ps1 -KubernetesVersion {{% param "fullversion" %}}
|
||||
```
|
||||
|
||||
1. `kubeadm`を実行してノードに参加します
|
||||
|
|
|
|||
|
|
@ -32,8 +32,8 @@ Windowsノードをアップグレードする前にコントロールプレー
|
|||
1. Windowsノードから、kubeadmをアップグレードします。:
|
||||
|
||||
```powershell
|
||||
# {{< param "fullversion" >}}を目的のバージョンに置き換えます
|
||||
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
|
||||
# {{% param "fullversion" %}}を目的のバージョンに置き換えます
|
||||
curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{% param "fullversion" %}}/bin/windows/amd64/kubeadm.exe
|
||||
```
|
||||
|
||||
### ノードをドレインする
|
||||
|
|
@ -67,7 +67,7 @@ Windowsノードをアップグレードする前にコントロールプレー
|
|||
|
||||
```powershell
|
||||
stop-service kubelet
|
||||
curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
|
||||
curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{% param "fullversion" %}}/bin/windows/amd64/kubelet.exe
|
||||
restart-service kubelet
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ weight: 10
|
|||
<div class="col-md-8">
|
||||
<h3>Kubernetes Serviceの概要</h3>
|
||||
|
||||
<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/pod/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
|
||||
<p>Kubernetes Podの寿命は永続的ではありません。実際、<a href="/ja/docs/concepts/workloads/pods/">Pod</a>には<a href="/ja/docs/concepts/workloads/pods/pod-lifecycle/">ライフサイクル</a>があります。ワーカーのノードが停止すると、そのノードで実行されているPodも失われます。そうなると、<a href="/ja/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a>は、新しいPodを作成してアプリケーションを実行し続けるために、クラスターを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスター内の各Podは、同じノード上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。</p>
|
||||
|
||||
<p>KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML<a href="/ja/docs/concepts/configuration/overview/#general-configuration-tips">(推奨)</a>またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、<i>LabelSelector</i>によって決定されます(なぜ仕様に<code>セレクタ</code>を含めずにServiceが必要になるのかについては下記を参照してください)。</p>
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
title: 送信元IPを使用する
|
||||
content_type: tutorial
|
||||
min-kubernetes-server-version: v1.5
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -76,9 +76,9 @@ cd website
|
|||
|
||||
### Изменение конфигурации сайта
|
||||
|
||||
Сайт Kubernetes использует использует фреймворк Hugo. Конфигурация сайта у Hugo находится в файле [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml). Для поддержки новой локализации вам нужно отредактировать файл `config.toml`.
|
||||
Сайт Kubernetes использует использует фреймворк Hugo. Конфигурация сайта у Hugo находится в файле [`hugo.toml`](https://github.com/kubernetes/website/tree/master/hugo.toml). Для поддержки новой локализации вам нужно отредактировать файл `hugo.toml`.
|
||||
|
||||
Добавьте блок с конфигурацией для нового языка в `config.toml` после существующего блока `[languages]`. Например, конфигурация для немецкой локализации будет выглядить так:
|
||||
Добавьте блок с конфигурацией для нового языка в `hugo.toml` после существующего блока `[languages]`. Например, конфигурация для немецкой локализации будет выглядить так:
|
||||
|
||||
```toml
|
||||
[languages.de]
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ _dynamically_
|
|||
: the cluster's control plane automatically picks a free IP address from within the configured IP range for `type: ClusterIP` Services.
|
||||
-->
|
||||
**动态**
|
||||
：群集的控制平面会自动从配置的 IP 范围内为 `type:ClusterIP` 的 Service 选择一个空闲 IP 地址。
|
||||
：集群的控制平面会自动从配置的 IP 范围内为 `type:ClusterIP` 的 Service 选择一个空闲 IP 地址。
|
||||
|
||||
<!--
|
||||
_statically_
|
||||
|
|
@ -58,7 +58,7 @@ Trying to create a Service with a specific `ClusterIP` that has already
|
|||
been allocated will return an error.
|
||||
-->
|
||||
在整个集群中，每个 Service 的 `ClusterIP` 必须是唯一的。
|
||||
尝试创建一个已经被分配了的 `ClusterIP` 的 Service 将会返回错误。
|
||||
尝试创建一个已经被分配了 `ClusterIP` 的 Service 将会返回错误。
|
||||
|
||||
<!--
|
||||
## Why do you need to reserve Service Cluster IPs?
|
||||
|
|
@ -142,7 +142,7 @@ use the lower range. This will allow users to use static allocations on the lowe
|
|||
risk of collision.
|
||||
-->
|
||||
分配默认使用上半段地址，当上半段地址耗尽后，将使用下半段地址范围。
|
||||
这将允许用户使用下半段地址中静态分配的地址并且降低冲突的风险。
|
||||
这将允许用户在下半段地址中使用静态分配从而降低冲突的风险。
|
||||
|
||||
<!--
|
||||
Examples:
|
||||
|
|
@ -264,5 +264,5 @@ The current SIG-Network [KEPs](https://github.com/orgs/kubernetes/projects/10) a
|
|||
[SIG Network meetings](https://github.com/kubernetes/community/tree/master/sig-network) are a friendly, welcoming venue for you to connect with the community and share your ideas.
|
||||
Looking forward to hearing from you!
|
||||
-->
|
||||
[SIG Network 会议](https://github.com/kubernetes/community/tree/master/sig-network)是一个友好、热情的场所，
|
||||
[SIG Network 会议](https://github.com/kubernetes/community/tree/master/sig-network)是一个友好、热情的地方，
|
||||
你可以与社区联系并分享你的想法。期待你的回音！
|
||||
|
|
|
|||
|
|
@ -308,45 +308,46 @@ rules:
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
has instructions on running and managing the cloud controller manager.
|
||||
* [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
has instructions on running and managing the cloud controller manager.
|
||||
|
||||
To upgrade a HA control plane to use the cloud controller manager, see
|
||||
[Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
|
||||
* To upgrade a HA control plane to use the cloud controller manager, see
|
||||
[Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).
|
||||
|
||||
Want to know how to implement your own cloud controller manager, or extend an existing project?
|
||||
* Want to know how to implement your own cloud controller manager, or extend an existing project?
|
||||
-->
|
||||
[云控制器管理器的管理](/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
* [云控制器管理器的管理](/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
给出了运行和管理云控制器管理器的指南。
|
||||
|
||||
要升级 HA 控制平面以使用云控制器管理器，
|
||||
* 要升级 HA 控制平面以使用云控制器管理器，
|
||||
请参见[将复制的控制平面迁移以使用云控制器管理器](/zh-cn/docs/tasks/administer-cluster/controller-manager-leader-migration/)。
|
||||
|
||||
想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？
|
||||
* 想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？
|
||||
|
||||
<!--
|
||||
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in.
|
||||
Specifically, it uses the `CloudProvider` interface defined in
|
||||
[`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69) from
|
||||
[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
|
||||
-->
|
||||
云控制器管理器使用 Go 语言的接口，从而使得针对各种云平台的具体实现都可以接入。
|
||||
其中使用了在 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)
|
||||
项目中 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69)
|
||||
文件所定义的 `CloudProvider` 接口。
|
||||
<!--
|
||||
- The cloud controller manager uses Go interfaces, specifically, `CloudProvider` interface defined in
|
||||
[`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)
|
||||
from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider) to allow
|
||||
implementations from any cloud to be plugged in.
|
||||
-->
|
||||
- 云控制器管理器使用 Go 语言的接口（具体指在
|
||||
[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)
|
||||
项目中 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69)
|
||||
文件中所定义的 `CloudProvider` 接口），从而使得针对各种云平台的具体实现都可以接入。
|
||||
|
||||
<!--
|
||||
The implementation of the shared controllers highlighted in this document (Node, Route, and Service),
|
||||
and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core.
|
||||
Implementations specific to cloud providers are outside the core of Kubernetes and implement the
|
||||
`CloudProvider` interface.
|
||||
<!--
|
||||
- The implementation of the shared controllers highlighted in this document (Node, Route, and Service),
|
||||
and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core.
|
||||
Implementations specific to cloud providers are outside the core of Kubernetes and implement
|
||||
the `CloudProvider` interface.
|
||||
-->
|
||||
- 本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及其他一些生成具有
|
||||
CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。
|
||||
特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。
|
||||
|
||||
For more information about developing plugins, see
|
||||
[Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
-->
|
||||
本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及其他一些生成具有
|
||||
CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。
|
||||
特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。
|
||||
|
||||
关于如何开发插件的详细信息，
|
||||
可参考[开发云控制器管理器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/)文档。
|
||||
<!--
|
||||
- For more information about developing plugins,
|
||||
see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
-->
|
||||
- 关于如何开发插件的详细信息，
|
||||
可参考[开发云控制器管理器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/)文档。
|
||||
|
|
|
|||
|
|
@ -810,7 +810,7 @@ For example, XFS and ext4fs offer project quotas.
|
|||
项目配额（Project Quota）是一个操作系统层的功能特性，用来管理文件系统中的存储用量。
|
||||
在 Kubernetes 中，你可以启用项目配额以监视存储用量。
|
||||
你需要确保节点上为 `emptyDir` 提供存储的文件系统支持项目配额。
|
||||
例如，XFS 和 ext4fs 文件系统都支持项目配额。
|
||||
例如，XFS 和 ext4fs 文件系统都支持项目配额。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
|
|
@ -1038,7 +1038,7 @@ extender.
|
|||
"apiVersion": "v1",
|
||||
"extenders": [
|
||||
{
|
||||
"urlPrefix":"<extender-endpoint>",
|
||||
"urlPrefix": "<extender-endpoint>",
|
||||
"bindVerb": "bind",
|
||||
"managedResources": [
|
||||
{
|
||||
|
|
@ -1289,10 +1289,10 @@ resource, including a configured ResourceQuota.
|
|||
包括所配置的 ResourceQuota。
|
||||
|
||||
<!--
|
||||
### My Container is terminated
|
||||
### My container is terminated
|
||||
|
||||
Your container might get terminated because it is resource-starved. To check
|
||||
whether a Container is being killed because it is hitting a resource limit, call
|
||||
whether a container is being killed because it is hitting a resource limit, call
|
||||
`kubectl describe pod` on the Pod of interest:
|
||||
-->
|
||||
|
||||
|
|
@ -1384,4 +1384,3 @@ memory limit (and possibly request) for that container.
|
|||
* 阅读 XFS 中[配额](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F)的文档
|
||||
* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
* 进一步阅读 [Pod 的服务质量等级](/zh-cn/docs/concepts/workloads/pods/pod-qos/)
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ page will help you learn about scheduling.
|
|||
## kube-scheduler
|
||||
|
||||
<!--
|
||||
[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
is the default scheduler for Kubernetes and runs as part of the
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
|
||||
kube-scheduler is designed so that, if you want and need to, you can
|
||||
|
|
@ -104,15 +104,15 @@ locality, inter-workload interference, and so on.
|
|||
亲和以及反亲和要求、数据局部性、负载间的干扰等等。
|
||||
|
||||
<!--
|
||||
## Scheduling with kube-scheduler {#kube-scheduler-implementation}
|
||||
### Node selection in kube-scheduler {#kube-scheduler-implementation}
|
||||
-->
|
||||
## kube-scheduler 调度流程 {#kube-scheduler-implementation}
|
||||
### kube-scheduler 中的节点选择 {#kube-scheduler-implementation}
|
||||
|
||||
<!--
|
||||
kube-scheduler selects a node for the pod in a 2-step operation:
|
||||
|
||||
1. Filtering
|
||||
2. Scoring
|
||||
1. Scoring
|
||||
-->
|
||||
kube-scheduler 给一个 Pod 做调度选择时包含两个步骤：
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ content_type: concept
|
|||
weight: 90
|
||||
---
|
||||
|
||||
<!--
|
||||
<!--
|
||||
reviewers:
|
||||
- davidopp
|
||||
- wojtek-t
|
||||
|
|
@ -17,7 +17,7 @@ weight: 90
|
|||
|
||||
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
[Pods](/docs/concepts/workloads/pods/) can have _priority_. Priority indicates the
|
||||
importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
|
||||
scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
|
||||
|
|
@ -31,7 +31,7 @@ pending Pod possible.
|
|||
<!-- body -->
|
||||
|
||||
{{< warning >}}
|
||||
<!--
|
||||
<!--
|
||||
In a cluster where not all users are trusted, a malicious user could create Pods
|
||||
at the highest possible priorities, causing other Pods to be evicted/not get
|
||||
scheduled.
|
||||
|
|
@ -48,7 +48,7 @@ for details.
|
|||
|
||||
{{< /warning >}}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
## How to use priority and preemption
|
||||
|
||||
To use priority and preemption:
|
||||
|
|
@ -75,7 +75,7 @@ Keep reading for more information about these steps.
|
|||
继续阅读以获取有关这些步骤的更多信息。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
<!--
|
||||
Kubernetes already ships with two PriorityClasses:
|
||||
`system-cluster-critical` and `system-node-critical`.
|
||||
These are common classes and are used to [ensure that critical components are always scheduled first](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
|
||||
|
|
@ -85,7 +85,7 @@ Kubernetes 已经提供了 2 个 PriorityClass：
|
|||
这些是常见的类，用于[确保始终优先调度关键组件](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
## PriorityClass
|
||||
|
||||
A PriorityClass is a non-namespaced object that defines a mapping from a
|
||||
|
|
@ -106,10 +106,10 @@ PriorityClass 对象的名称必须是有效的
|
|||
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)，
|
||||
并且它不能以 `system-` 为前缀。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
A PriorityClass object can have any 32-bit integer value smaller than or equal
|
||||
to 1 billion. This means that the range of values for a PriorityClass object is
|
||||
from -2147483648 to 1000000000 inclusive. Larger numbers are reserved for
|
||||
from -2147483648 to 1000000000 inclusive. Larger numbers are reserved for
|
||||
built-in PriorityClasses that represent critical system Pods. A cluster
|
||||
admin should create one PriorityClass object for each such mapping that they want.
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ PriorityClass 还有两个可选字段：`globalDefault` 和 `description`。
|
|||
`description` 字段是一个任意字符串。
|
||||
它用来告诉集群用户何时应该使用此 PriorityClass。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
### Notes about PodPriority and existing clusters
|
||||
|
||||
- If you upgrade an existing cluster without this feature, the priority
|
||||
|
|
@ -153,13 +153,13 @@ PriorityClass 还有两个可选字段：`globalDefault` 和 `description`。
|
|||
-->
|
||||
### 关于 PodPriority 和现有集群的注意事项 {#notes-about-podpriority-and-existing-clusters}
|
||||
|
||||
- 如果你升级一个已经存在的但尚未使用此特性的集群，该集群中已经存在的 Pod 的优先级等效于零。
|
||||
- 如果你升级一个已经存在的但尚未使用此特性的集群，该集群中已经存在的 Pod 的优先级等效于零。
|
||||
|
||||
- 添加一个将 `globalDefault` 设置为 `true` 的 PriorityClass 不会改变现有 Pod 的优先级。
|
||||
此类 PriorityClass 的值仅用于添加 PriorityClass 后创建的 Pod。
|
||||
- 添加一个将 `globalDefault` 设置为 `true` 的 PriorityClass 不会改变现有 Pod 的优先级。
|
||||
此类 PriorityClass 的值仅用于添加 PriorityClass 后创建的 Pod。
|
||||
|
||||
- 如果你删除了某个 PriorityClass 对象，则使用被删除的 PriorityClass 名称的现有 Pod 保持不变，
|
||||
但是你不能再创建使用已删除的 PriorityClass 名称的 Pod。
|
||||
- 如果你删除了某个 PriorityClass 对象，则使用被删除的 PriorityClass 名称的现有 Pod 保持不变，
|
||||
但是你不能再创建使用已删除的 PriorityClass 名称的 Pod。
|
||||
|
||||
<!--
|
||||
### Example PriorityClass
|
||||
|
|
@ -176,7 +176,7 @@ globalDefault: false
|
|||
description: "此优先级类应仅用于 XYZ 服务 Pod。"
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
## Non-preempting PriorityClass {#non-preempting-priority-class}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
|
@ -209,7 +209,7 @@ high-priority pods.
|
|||
|
||||
非抢占式 Pod 仍可能被其他高优先级 Pod 抢占。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
`preemptionPolicy` defaults to `PreemptLowerPriority`,
|
||||
which will allow pods of that PriorityClass to preempt lower-priority pods
|
||||
(as is existing default behavior).
|
||||
|
|
@ -248,7 +248,7 @@ globalDefault: false
|
|||
description: "This priority class will not cause other pods to be preempted."
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
## Pod priority
|
||||
|
||||
After you have one or more PriorityClasses, you can create Pods that specify one
|
||||
|
|
@ -286,7 +286,7 @@ spec:
|
|||
priorityClassName: high-priority
|
||||
```
|
||||
|
||||
<!--
|
||||
<!--
|
||||
### Effect of Pod priority on scheduling order
|
||||
|
||||
When Pod priority is enabled, the scheduler orders pending Pods by
|
||||
|
|
@ -303,7 +303,7 @@ scheduler will continue and tries to schedule other lower priority Pods.
|
|||
因此，如果满足调度要求，较高优先级的 Pod 可能会比具有较低优先级的 Pod 更早调度。
|
||||
如果无法调度此类 Pod，调度程序将继续并尝试调度其他较低优先级的 Pod。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
## Preemption
|
||||
|
||||
When Pods are created, they go to a queue and wait to be scheduled. The
|
||||
|
|
@ -325,7 +325,7 @@ Pod 被创建后会进入队列等待调度。
|
|||
如果找到这样的节点，一个或多个优先级较低的 Pod 会被从节点中驱逐。
|
||||
被驱逐的 Pod 消失后，P 可以被调度到该节点上。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
### User exposed information
|
||||
|
||||
When Pod P preempts one or more Pods on Node N, `nominatedNodeName` field of Pod
|
||||
|
|
@ -361,7 +361,7 @@ Pod P 状态的 `nominatedNodeName` 字段被设置为节点 N 的名称。
|
|||
在这种情况下，调度程序会清除 Pod P 的 `nominatedNodeName`。
|
||||
通过这样做，调度程序使 Pod P 有资格抢占另一个节点上的 Pod。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
### Limitations of preemption
|
||||
|
||||
#### Graceful termination of preemption victims
|
||||
|
|
@ -385,14 +385,14 @@ priority Pods to zero or a small number.
|
|||
当 Pod 被抢占时，牺牲者会得到他们的
|
||||
[体面终止期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
|
||||
它们可以在体面终止期内完成工作并退出。如果它们不这样做就会被杀死。
|
||||
这个体面终止期在调度程序抢占 Pod 的时间点和待处理的 Pod (P)
|
||||
这个体面终止期在调度程序抢占 Pod 的时间点和待处理的 Pod (P)
|
||||
可以在节点 (N) 上调度的时间点之间划分出了一个时间跨度。
|
||||
同时，调度器会继续调度其他待处理的 Pod。当牺牲者退出或被终止时，
|
||||
调度程序会尝试在待处理队列中调度 Pod。
|
||||
因此，调度器抢占牺牲者的时间点与 Pod P 被调度的时间点之间通常存在时间间隔。
|
||||
为了最小化这个差距，可以将低优先级 Pod 的体面终止时间设置为零或一个小数字。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
#### PodDisruptionBudget is supported, but not guaranteed
|
||||
|
||||
A [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)
|
||||
|
|
@ -405,13 +405,13 @@ despite their PDBs being violated.
|
|||
-->
|
||||
#### 支持 PodDisruptionBudget，但不保证
|
||||
|
||||
[PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)
|
||||
[PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)
|
||||
(PDB) 允许多副本应用程序的所有者限制因自愿性质的干扰而同时终止的 Pod 数量。
|
||||
Kubernetes 在抢占 Pod 时支持 PDB，但对 PDB 的支持是基于尽力而为原则的。
|
||||
调度器会尝试寻找不会因被抢占而违反 PDB 的牺牲者，但如果没有找到这样的牺牲者，
|
||||
抢占仍然会发生，并且即使违反了 PDB 约束也会删除优先级较低的 Pod。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
#### Inter-Pod affinity on lower-priority Pods
|
||||
|
||||
A Node is considered for preemption only when the answer to this question is
|
||||
|
|
@ -438,12 +438,12 @@ the Node is not considered for preemption.
|
|||
如果答案是否定的，则不考虑在该节点上执行抢占。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
If a pending Pod has inter-pod {{< glossary_tooltip text="affinity" term_id="affinity" >}}
|
||||
to one or more of the lower-priority Pods on the Node, the inter-Pod affinity
|
||||
rule cannot be satisfied in the absence of those lower-priority Pods. In this case,
|
||||
rule cannot be satisfied in the absence of those lower-priority Pods. In this case,
|
||||
the scheduler does not preempt any Pods on the Node. Instead, it looks for another
|
||||
Node. The scheduler might find a suitable Node or it might not. There is no
|
||||
Node. The scheduler might find a suitable Node or it might not. There is no
|
||||
guarantee that the pending Pod can be scheduled.
|
||||
|
||||
Our recommended solution for this problem is to create inter-Pod affinity only
|
||||
|
|
@ -457,7 +457,7 @@ towards equal or higher priority Pods.
|
|||
|
||||
我们针对此问题推荐的解决方案是仅针对同等或更高优先级的 Pod 设置 Pod 间亲和性。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
#### Cross node preemption
|
||||
|
||||
Suppose a Node N is being considered for preemption so that a pending Pod P can
|
||||
|
|
@ -486,12 +486,12 @@ enough demand and if we find an algorithm with reasonable performance.
|
|||
只有当另一个节点上的 Pod 被抢占时，P 才可能在 N 上变得可行。
|
||||
下面是一个例子：
|
||||
|
||||
* 正在考虑将 Pod P 调度到节点 N 上。
|
||||
* Pod Q 正在与节点 N 位于同一区域的另一个节点上运行。
|
||||
* Pod P 与 Pod Q 具有 Zone 维度的反亲和（`topologyKey:topology.kubernetes.io/zone`）。
|
||||
* Pod P 与 Zone 中的其他 Pod 之间没有其他反亲和性设置。
|
||||
* 为了在节点 N 上调度 Pod P，可以抢占 Pod Q，但调度器不会进行跨节点抢占。
|
||||
因此，Pod P 将被视为在节点 N 上不可调度。
|
||||
* 调度器正在考虑将 Pod P 调度到节点 N 上。
|
||||
* Pod Q 正在与节点 N 位于同一区域的另一个节点上运行。
|
||||
* Pod P 与 Pod Q 具有 Zone 维度的反亲和（`topologyKey:topology.kubernetes.io/zone`）设置。
|
||||
* Pod P 与 Zone 中的其他 Pod 之间没有其他反亲和性设置。
|
||||
* 为了在节点 N 上调度 Pod P，可以抢占 Pod Q，但调度器不会进行跨节点抢占。
|
||||
因此，Pod P 将被视为在节点 N 上不可调度。
|
||||
|
||||
如果将 Pod Q 从所在节点中移除，则不会违反 Pod 间反亲和性约束，
|
||||
并且 Pod P 可能会被调度到节点 N 上。
|
||||
|
|
@ -499,7 +499,7 @@ enough demand and if we find an algorithm with reasonable performance.
|
|||
如果有足够的需求，并且如果我们找到性能合理的算法，
|
||||
我们可能会考虑在未来版本中添加跨节点抢占。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
## Troubleshooting
|
||||
|
||||
Pod priority and pre-emption can have unwanted side effects. Here are some
|
||||
|
|
@ -509,7 +509,7 @@ examples of potential problems and ways to deal with them.
|
|||
|
||||
Pod 优先级和抢占可能会产生不必要的副作用。以下是一些潜在问题的示例以及处理这些问题的方法。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
### Pods are preempted unnecessarily
|
||||
|
||||
Preemption removes existing Pods from a cluster under resource pressure to make
|
||||
|
|
@ -532,7 +532,7 @@ than the victims. If preemption happens in such scenarios, please file an issue.
|
|||
-->
|
||||
### Pod 被不必要地抢占
|
||||
|
||||
抢占在资源压力较大时从集群中删除现有 Pod，为更高优先级的悬决 Pod 腾出空间。
|
||||
抢占在资源压力较大时从集群中删除现有 Pod，为更高优先级的悬决 Pod 腾出空间。
|
||||
如果你错误地为某些 Pod 设置了高优先级，这些无意的高优先级 Pod 可能会导致集群中出现抢占行为。
|
||||
Pod 优先级是通过设置 Pod 规约中的 `priorityClassName` 字段来指定的。
|
||||
优先级的整数值然后被解析并填充到 `podSpec` 的 `priority` 字段。
|
||||
|
|
@ -545,7 +545,7 @@ Pod 优先级是通过设置 Pod 规约中的 `priorityClassName` 字段来指
|
|||
当没有悬决 Pod，或者悬决 Pod 的优先级等于或低于牺牲者时，不得发生抢占。
|
||||
如果在这种情况下发生抢占，请提出问题。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
### Pods are preempted, but the preemptor is not scheduled
|
||||
|
||||
When pods are preempted, they receive their requested graceful termination
|
||||
|
|
@ -571,7 +571,7 @@ of a Pod with a lower priority.
|
|||
|
||||
这是预期的行为：具有较高优先级的 Pod 应该取代具有较低优先级的 Pod。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
### Higher priority Pods are preempted before lower priority pods
|
||||
|
||||
The scheduler tries to find nodes that can run a pending Pod. If no node is
|
||||
|
|
@ -604,7 +604,7 @@ the scheduler chooses a node with the lowest priority.
|
|||
|
||||
当存在多个节点抢占且上述场景均不适用时，调度器会选择优先级最低的节点。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
## Interactions between Pod priority and quality of service {#interactions-of-pod-priority-and-qos}
|
||||
|
||||
Pod priority and {{< glossary_tooltip text="QoS class" term_id="qos-class" >}}
|
||||
|
|
@ -626,14 +626,14 @@ Pod 优先级和 {{<glossary_tooltip text="QoS 类" term_id="qos-class" >}}
|
|||
仅当移除优先级最低的 Pod 不足以让调度程序调度抢占式 Pod，
|
||||
或者最低优先级的 Pod 受 PodDisruptionBudget 保护时，才会考虑优先级较高的 Pod。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The kubelet uses Priority to determine pod order for [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
You can use the QoS class to estimate the order in which pods are most likely
|
||||
to get evicted. The kubelet ranks pods for eviction based on the following factors:
|
||||
|
||||
1. Whether the starved resource usage exceeds requests
|
||||
1. Pod Priority
|
||||
1. Amount of resource usage relative to requests
|
||||
1. Amount of resource usage relative to requests
|
||||
|
||||
See [Pod selection for kubelet eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)
|
||||
for more details.
|
||||
|
|
@ -647,9 +647,9 @@ kubelet 使用优先级来确定
|
|||
[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/) Pod 的顺序。
|
||||
你可以使用 QoS 类来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 进行驱逐排名：
|
||||
|
||||
1. 对紧俏资源的使用是否超过请求值
|
||||
1. Pod 优先级
|
||||
1. 相对于请求的资源使用量
|
||||
1. 对紧俏资源的使用是否超过请求值
|
||||
1. Pod 优先级
|
||||
1. 相对于请求的资源使用量
|
||||
|
||||
有关更多详细信息，请参阅
|
||||
[kubelet 驱逐时 Pod 的选择](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。
|
||||
|
|
@ -660,7 +660,7 @@ kubelet 使用优先级来确定
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
* Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
|
||||
* Learn about [Pod Disruption](/docs/concepts/workloads/pods/disruptions/)
|
||||
* Learn about [API-initiated Eviction](/docs/concepts/scheduling-eviction/api-eviction/)
|
||||
|
|
|
|||
|
|
@ -27,8 +27,10 @@ hard requirement). _Taints_ are the opposite -- they allow a node to repel a set
|
|||
**污点（Taint）** 则相反——它使节点能够排斥一类特定的 Pod。
|
||||
|
||||
<!--
|
||||
|
||||
_Tolerations_ are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also [evaluates other parameters](/docs/concepts/scheduling-eviction/pod-priority-preemption/) as part of its function.
|
||||
_Tolerations_ are applied to pods. Tolerations allow the scheduler to schedule pods with matching
|
||||
taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also
|
||||
[evaluates other parameters](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
|
||||
as part of its function.
|
||||
|
||||
Taints and tolerations work together to ensure that pods are not scheduled
|
||||
onto inappropriate nodes. One or more taints are applied to a node; this
|
||||
|
|
@ -482,7 +484,7 @@ decisions. This ensures that node conditions don't directly affect scheduling.
|
|||
For example, if the `DiskPressure` node condition is active, the control plane
|
||||
adds the `node.kubernetes.io/disk-pressure` taint and does not schedule new pods
|
||||
onto the affected node. If the `MemoryPressure` node condition is active, the
|
||||
control plane adds the `node.kubernetes.io/memory-pressure` taint.
|
||||
control plane adds the `node.kubernetes.io/memory-pressure` taint.
|
||||
-->
|
||||
调度器在进行调度时检查污点，而不是检查节点状况。这确保节点状况不会直接影响调度。
|
||||
例如，如果 `DiskPressure` 节点状况处于活跃状态，则控制平面添加
|
||||
|
|
@ -492,12 +494,12 @@ control plane adds the `node.kubernetes.io/memory-pressure` taint.
|
|||
|
||||
<!--
|
||||
You can ignore node conditions for newly created pods by adding the corresponding
|
||||
Pod tolerations. The control plane also adds the `node.kubernetes.io/memory-pressure`
|
||||
toleration on pods that have a {{< glossary_tooltip text="QoS class" term_id="qos-class" >}}
|
||||
other than `BestEffort`. This is because Kubernetes treats pods in the `Guaranteed`
|
||||
Pod tolerations. The control plane also adds the `node.kubernetes.io/memory-pressure`
|
||||
toleration on pods that have a {{< glossary_tooltip text="QoS class" term_id="qos-class" >}}
|
||||
other than `BestEffort`. This is because Kubernetes treats pods in the `Guaranteed`
|
||||
or `Burstable` QoS classes (even pods with no memory request set) as if they are
|
||||
able to cope with memory pressure, while new `BestEffort` pods are not scheduled
|
||||
onto the affected node.
|
||||
onto the affected node.
|
||||
-->
|
||||
对于新创建的 Pod，可以通过添加相应的 Pod 容忍度来忽略节点状况。
|
||||
控制平面还在具有除 `BestEffort` 之外的
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: EndpointSlice
|
||||
content_type: concept
|
||||
weight: 45
|
||||
weight: 60
|
||||
description: >-
|
||||
EndpointSlice API 是 Kubernetes 用于扩缩 Service
|
||||
以处理大量后端的机制，还允许集群高效更新其健康后端的列表。
|
||||
|
|
@ -12,7 +12,7 @@ reviewers:
|
|||
- freehan
|
||||
title: EndpointSlices
|
||||
content_type: concept
|
||||
weight: 45
|
||||
weight: 60
|
||||
description: >-
|
||||
The EndpointSlice API is the mechanism that Kubernetes uses to let your Service
|
||||
scale to handle large numbers of backends, and allows the cluster to update its
|
||||
|
|
@ -161,18 +161,18 @@ Services will always have the `ready` condition set to `true`.
|
|||
<!--
|
||||
#### Serving
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
|
||||
|
||||
`serving` is identical to the `ready` condition, except it does not account for terminating states.
|
||||
Consumers of the EndpointSlice API should check this condition if they care about pod readiness while
|
||||
The `serving` condition is almost identical to the `ready` condition. The difference is that
|
||||
consumers of the EndpointSlice API should check the `serving` condition if they care about pod readiness while
|
||||
the pod is also terminating.
|
||||
-->
|
||||
#### Serving（服务中）
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
|
||||
|
||||
`serving` 状况与 `ready` 状况相同，不同之处在于它不考虑终止状态。
|
||||
如果 EndpointSlice API 的使用者关心 Pod 终止时的就绪情况，就应检查此状况。
|
||||
`serving` 状况几乎与 `ready` 状况相同，不同之处在于它不考虑终止状态。
|
||||
如果 EndpointSlice API 的使用者关心 Pod 终止时的就绪情况，就应检查 `serving` 状况。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
|
|
@ -191,7 +191,7 @@ for terminating pods independent of the existing semantics for `ready`.
|
|||
的现有语义来跟踪处于终止中的 Pod 的就绪情况。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
<!--
|
||||
#### Terminating
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
|
@ -470,7 +470,6 @@ less noticeable; even then, some use cases of Kubernetes weren't well served.
|
|||
对象可能变得非常巨大。对于保持稳定的服务（长时间使用同一组端点），影响不太明显；
|
||||
即便如此，Kubernetes 的一些使用场景也没有得到很好的服务。
|
||||
|
||||
|
||||
<!--
|
||||
When a Service had a lot of backend endpoints and the workload was either
|
||||
scaling frequently, or rolling out new changes frequently, each update to
|
||||
|
|
@ -507,5 +506,3 @@ EndpointSlices 还支持围绕双栈网络和拓扑感知路由等新功能的
|
|||
* 遵循[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/)教程
|
||||
* 阅读 EndpointSlice API 的 [API 参考](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/)
|
||||
* 阅读 Endpoints API 的 [API 参考](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoints-v1/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ that Deployment can create and destroy Pods dynamically. From one moment to the
|
|||
you don't know how many of those Pods are working and healthy; you might not even know
|
||||
what those healthy Pods are named.
|
||||
Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed
|
||||
to match the desired state of your cluster. Pods are emphemeral resources (you should not
|
||||
to match the desired state of your cluster. Pods are ephemeral resources (you should not
|
||||
expect that an individual Pod is reliable and durable).
|
||||
-->
|
||||
如果你使用 {{< glossary_tooltip term_id="deployment" >}} 来运行你的应用，
|
||||
|
|
@ -233,10 +233,14 @@ field.
|
|||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Port definitions {#field-spec-ports}
|
||||
|
||||
Port definitions in Pods have names, and you can reference these names in the
|
||||
`targetPort` attribute of a Service. For example, we can bind the `targetPort`
|
||||
of the Service to the Pod port in the following way:
|
||||
-->
|
||||
### 端口定义 {#field-spec-ports}
|
||||
|
||||
Pod 中的端口定义是有名字的，你可以在 Service 的 `targetPort` 属性中引用这些名称。
|
||||
例如，我们可以通过以下方式将 Service 的 `targetPort` 绑定到 Pod 端口：
|
||||
|
||||
|
|
@ -286,14 +290,14 @@ The default protocol for Services is
|
|||
[TCP](/docs/reference/networking/service-protocols/#protocol-tcp); you can also
|
||||
use any other [supported protocol](/docs/reference/networking/service-protocols/).
|
||||
|
||||
As many Services need to expose more than one port, Kubernetes supports multiple
|
||||
port definitions on a Service object.
|
||||
Because many Services need to expose more than one port, Kubernetes supports
|
||||
+[multiple port definitions](#multi-port-services) for a single Service.
|
||||
Each port definition can have the same `protocol`, or a different one.
|
||||
-->
|
||||
服务的默认协议是 [TCP](/zh-cn/docs/reference/networking/service-protocols/#protocol-tcp)；
|
||||
你还可以使用任何其他[受支持的协议](/zh-cn/docs/reference/networking/service-protocols/)。
|
||||
|
||||
由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。
|
||||
由于许多服务需要公开多个端口，所以 Kubernetes 针对单个服务支持[多个端口定义](#multi-port-services)。
|
||||
每个端口定义可以具有相同的 `protocol`，也可以具有不同的协议。
|
||||
|
||||
<!--
|
||||
|
|
@ -576,7 +580,7 @@ domain prefixed names such as `mycompany.com/my-custom-protocol`.
|
|||
或以域名为前缀的名称，如 `mycompany.com/my-custom-protocol`。
|
||||
|
||||
<!--
|
||||
## Multi-Port Services
|
||||
### Multi-Port Services
|
||||
|
||||
For some Services, you need to expose more than one port.
|
||||
Kubernetes lets you configure multiple port definitions on a Service object.
|
||||
|
|
@ -584,7 +588,7 @@ When using multiple ports for a Service, you must give all of your ports names
|
|||
so that these are unambiguous.
|
||||
For example:
|
||||
-->
|
||||
## 多端口 Service {#multi-port-services}
|
||||
### 多端口 Service {#multi-port-services}
|
||||
|
||||
对于某些服务，你需要公开多个端口。
|
||||
Kubernetes 允许你在 Service 对象上配置多个端口定义。
|
||||
|
|
|
|||
|
|
@ -224,7 +224,7 @@ Pod 绑定到目标主机。如果新的 Pod 无法放在节点上，则默认
|
|||
（驱逐）某些现存的 Pod。
|
||||
|
||||
<!--
|
||||
The user can specify a different scheduler for the Pods of the DamonSet, by
|
||||
The user can specify a different scheduler for the Pods of the DaemonSet, by
|
||||
setting the `.spec.template.spec.schedulerName` field of the DaemonSet.
|
||||
|
||||
The original node affinity specified at the
|
||||
|
|
@ -307,7 +307,7 @@ Tolerations for DaemonSet pods
|
|||
{{< /table >}}
|
||||
|
||||
<!--
|
||||
You can add your own tolerations to the Pods of a Daemonset as well, by
|
||||
You can add your own tolerations to the Pods of a DaemonSet as well, by
|
||||
defining these in the Pod template of the DaemonSet.
|
||||
|
||||
Because the DaemonSet controller sets the
|
||||
|
|
|
|||
|
|
@ -298,19 +298,19 @@ For an example of adding a label, see the PR for adding the
|
|||
|
||||
The Kubernetes website uses Hugo as its web framework. The website's Hugo
|
||||
configuration resides in the
|
||||
[`config.toml`](https://github.com/kubernetes/website/tree/main/config.toml)
|
||||
file. You'll need to modify `config.toml` to support a new localization.
|
||||
[`hugo.toml`](https://github.com/kubernetes/website/tree/main/hugo.toml)
|
||||
file. You'll need to modify `hugo.toml` to support a new localization.
|
||||
|
||||
Add a configuration block for the new language to `config.toml` under the
|
||||
Add a configuration block for the new language to `hugo.toml` under the
|
||||
existing `[languages]` block. The German block, for example, looks like:
|
||||
-->
|
||||
### 修改站点配置 {#configure-the-workflow}
|
||||
|
||||
Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于
|
||||
[`config.toml`](https://github.com/kubernetes/website/tree/main/config.toml)文件中。
|
||||
为了支持新的本地化，你需要修改 `config.toml`。
|
||||
[`hugo.toml`](https://github.com/kubernetes/website/tree/main/hugo.toml)文件中。
|
||||
为了支持新的本地化，你需要修改 `hugo.toml`。
|
||||
|
||||
在现有的 `[languages]` 下，将新语言的配置添加到 `config.toml` 中。
|
||||
在现有的 `[languages]` 下，将新语言的配置添加到 `hugo.toml` 中。
|
||||
例如，下面是德语的配置示例：
|
||||
|
||||
```toml
|
||||
|
|
|
|||
|
|
@ -582,13 +582,13 @@ before the item, or just below the heading for the specific item.
|
|||
|
||||
To generate a version string for inclusion in the documentation, you can choose from
|
||||
several version shortcodes. Each version shortcode displays a version string derived from
|
||||
the value of a version parameter found in the site configuration file, `config.toml`.
|
||||
the value of a version parameter found in the site configuration file, `hugo.toml`.
|
||||
The two most commonly used version parameters are `latest` and `version`.
|
||||
-->
|
||||
## 版本号信息 {#version-strings}
|
||||
|
||||
要在文档中生成版本号信息，可以从以下几种短代码中选择。每个短代码可以基于站点配置文件
|
||||
`config.toml` 中的版本参数生成一个版本号取值。最常用的参数为 `latest` 和 `version`。
|
||||
`hugo.toml` 中的版本参数生成一个版本号取值。最常用的参数为 `latest` 和 `version`。
|
||||
|
||||
<!--
|
||||
### `{{</* param "version" */>}}`
|
||||
|
|
|
|||
|
|
@ -151,6 +151,7 @@ operator to use or manage a cluster.
|
|||
* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/),
|
||||
[kube-scheduler configuration (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) and
|
||||
[kube-scheduler configuration (v1)](/docs/reference/config-api/kube-scheduler-config.v1/)
|
||||
* [kube-controller-manager configuration (v1alpha1)](/docs/reference/config-api/kube-controller-manager-config.v1alpha1/)
|
||||
* [kube-proxy configuration (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
|
||||
* [Client authentication API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) and
|
||||
|
|
@ -179,6 +180,7 @@ operator to use or manage a cluster.
|
|||
* [kube-scheduler 配置 (v1beta2)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta2/)、
|
||||
[kube-scheduler 配置 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) 和
|
||||
[kube-scheduler 配置 (v1)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1/)
|
||||
* [kube-controller-manager 配置 (v1alpha1)](/docs/reference/config-api/kube-controller-manager-config.v1alpha1/)
|
||||
* [kube-proxy 配置 (v1alpha1)](/zh-cn/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
* [`audit.k8s.io/v1` API](/zh-cn/docs/reference/config-api/apiserver-audit.v1/)
|
||||
* [客户端身份认证 API (v1beta1)](/zh-cn/docs/reference/config-api/client-authentication.v1beta1/) 和
|
||||
|
|
|
|||
|
|
@ -186,7 +186,7 @@ CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultI
|
|||
{{< note >}}
|
||||
<!--
|
||||
The [`ValidatingAdmissionPolicy`](#validatingadmissionpolicy) admission plugin is enabled
|
||||
by default, but is only active if you enable the the `ValidatingAdmissionPolicy`
|
||||
by default, but is only active if you enable the `ValidatingAdmissionPolicy`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) **and**
|
||||
the `admissionregistration.k8s.io/v1alpha1` API.
|
||||
-->
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue