kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'kubernetes:main' into ptbr/share

pull/35145/head
DonatoHorn 2023-03-29 12:57:47 +13:00 committed by GitHub
parent a3a336d01f cdd66beda2
commit ea2d724aa5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
256 changed files with 4601 additions and 2320 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
OWNERS_ALIASES
View File

@ -32,7 +32,7 @@ aliases:
- bradtopol
- divya-mohan0209
- kbhawkey
- krol3
- mickeyboxell
- natalisucks
- nate-double-u
- onlydole

2
content/de/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -154,7 +154,7 @@ Standardmäßig ruft der HorizontalPodAutoscaler Controller Metriken aus einer R
Es kann als Cluster-Addon gestartet werden.
* Für benutzerdefinierte Metriken ist dies die API `custom.metrics.k8s.io`. Diese wird vom "Adapter" API Servern bereitgestellt, welches von Anbietern von Metrik Lösungen beliefert wird.
Überprüfe dies mit deiner Metrik Pipeline oder der [Liste bekannter Lösungen](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
Überprüfe dies mit deiner Metrik Pipeline.
Falls du deinen eigenen schreiben möchtest hilft dir folgender [boilerplate](https://github.com/kubernetes-incubator/custom-metrics-apiserver) um zu starten.
* Für externe Metriken ist dies die `external.metrics.k8s.io` API. Es kann sein, dass dies durch den benutzerdefinierten Metrik Adapter bereitgestellt wird.

139
content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md
View File

@ -7,71 +7,156 @@ slug: podsecuritypolicy-deprecation-past-present-and-future
**Author:** Tabitha Sable (Kubernetes SIG Security)
{{% pageinfo color="primary" %}}
**Update:** *With the release of Kubernetes v1.25, PodSecurityPolicy has been removed.* *You can read more information about the removal of PodSecurityPolicy in the [Kubernetes 1.25 release notes](/blog/2022/08/23/kubernetes-v1-25-release/#pod-security-changes).*
**Update:** *With the release of Kubernetes v1.25, PodSecurityPolicy has been removed.*
*You can read more information about the removal of PodSecurityPolicy in the
[Kubernetes 1.25 release notes](/blog/2022/08/23/kubernetes-v1-25-release/#pod-security-changes).*
{{% /pageinfo %}}
PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, to be released later this week. This starts the countdown to its removal, but doesn’t change anything else. PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely. In the meantime, we are developing a replacement for PSP that covers key use cases more easily and sustainably.
PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, to be released later this week.
This starts the countdown to its removal, but doesn’t change anything else.
PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely.
In the meantime, we are developing a replacement for PSP that covers key use cases more easily and sustainably.
What are Pod Security Policies? Why did we need them? Why are they going away, and what’s next? How does this affect you? These key questions come to mind as we prepare to say goodbye to PSP, so let’s walk through them together. We’ll start with an overview of how features get removed from Kubernetes.
What are Pod Security Policies? Why did we need them? Why are they going away, and what’s next?
How does this affect you? These key questions come to mind as we prepare to say goodbye to PSP,
so let’s walk through them together. We’ll start with an overview of how features get removed from Kubernetes.
## What does deprecation mean in Kubernetes?
Whenever a Kubernetes feature is set to go away, our [deprecation policy](/docs/reference/using-api/deprecation-policy/) is our guide. First the feature is marked as deprecated, then after enough time has passed, it can finally be removed.
Whenever a Kubernetes feature is set to go away, our [deprecation policy](/docs/reference/using-api/deprecation-policy/)
is our guide. First the feature is marked as deprecated, then after enough time has passed, it can finally be removed.
Kubernetes 1.21 starts the deprecation process for PodSecurityPolicy. As with all feature deprecations, PodSecurityPolicy will continue to be fully functional for several more releases. The current plan is to remove PSP from Kubernetes in the 1.25 release.
Kubernetes 1.21 starts the deprecation process for PodSecurityPolicy. As with all feature deprecations,
PodSecurityPolicy will continue to be fully functional for several more releases.
The current plan is to remove PSP from Kubernetes in the 1.25 release.
Until then, PSP is still PSP. There will be at least a year during which the newest Kubernetes releases will still support PSP, and nearly two years until PSP will pass fully out of all supported Kubernetes versions.
Until then, PSP is still PSP. There will be at least a year during which the newest Kubernetes releases will
still support PSP, and nearly two years until PSP will pass fully out of all supported Kubernetes versions.
## What is PodSecurityPolicy?
[PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) is a built-in [admission controller](/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/) that allows a cluster administrator to control security-sensitive aspects of the Pod specification.
[PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) is
a built-in [admission controller](/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/)
that allows a cluster administrator to control security-sensitive aspects of the Pod specification.
First, one or more PodSecurityPolicy resources are created in a cluster to define the requirements Pods must meet. Then, RBAC rules are created to control which PodSecurityPolicy applies to a given pod. If a pod meets the requirements of its PSP, it will be admitted to the cluster as usual. In some cases, PSP can also modify Pod fields, effectively creating new defaults for those fields. If a Pod does not meet the PSP requirements, it is rejected, and cannot run.
First, one or more PodSecurityPolicy resources are created in a cluster to define the requirements Pods must meet.
Then, RBAC rules are created to control which PodSecurityPolicy applies to a given pod.
If a pod meets the requirements of its PSP, it will be admitted to the cluster as usual.
In some cases, PSP can also modify Pod fields, effectively creating new defaults for those fields.
If a Pod does not meet the PSP requirements, it is rejected, and cannot run.
One more important thing to know about PodSecurityPolicy: it’s not the same as [PodSecurityContext](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context).
One more important thing to know about PodSecurityPolicy: it’s not the same as
[PodSecurityContext](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context).
A part of the Pod specification, PodSecurityContext (and its per-container counterpart `SecurityContext`) is the collection of fields that specify many of the security-relevant settings for a Pod. The security context dictates to the kubelet and container runtime how the Pod should actually be run. In contrast, the PodSecurityPolicy only constrains (or defaults) the values that may be set on the security context.
A part of the Pod specification, PodSecurityContext (and its per-container counterpart `SecurityContext`)
is the collection of fields that specify many of the security-relevant settings for a Pod.
The security context dictates to the kubelet and container runtime how the Pod should actually be run.
In contrast, the PodSecurityPolicy only constrains (or defaults) the values that may be set on the security context.
The deprecation of PSP does not affect PodSecurityContext in any way.
## Why did we need PodSecurityPolicy?
In Kubernetes, we define resources such as Deployments, StatefulSets, and Services that represent the building blocks of software applications. The various controllers inside a Kubernetes cluster react to these resources, creating further Kubernetes resources or configuring some software or hardware to accomplish our goals.
In Kubernetes, we define resources such as Deployments, StatefulSets, and Services that
represent the building blocks of software applications. The various controllers inside
a Kubernetes cluster react to these resources, creating further Kubernetes resources or
configuring some software or hardware to accomplish our goals.
In most Kubernetes clusters, RBAC (Role-Based Access Control) [rules](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) control access to these resources. `list`, `get`, `create`, `edit`, and `delete` are the sorts of API operations that RBAC cares about, but _RBAC does not consider what settings are being put into the resources it controls_. For example, a Pod can be almost anything from a simple webserver to a privileged command prompt offering full access to the underlying server node and all the data. It’s all the same to RBAC: a Pod is a Pod is a Pod.
In most Kubernetes clusters,
RBAC (Role-Based Access Control) [rules](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)
control access to these resources. `list`, `get`, `create`, `edit`, and `delete` are
the sorts of API operations that RBAC cares about,
but _RBAC does not consider what settings are being put into the resources it controls_.
For example, a Pod can be almost anything from a simple webserver to
a privileged command prompt offering full access to the underlying server node and all the data.
It’s all the same to RBAC: a Pod is a Pod is a Pod.
To control what sorts of settings are allowed in the resources defined in your cluster, you need Admission Control in addition to RBAC. Since Kubernetes 1.3, PodSecurityPolicy has been the built-in way to do that for security-related Pod fields. Using PodSecurityPolicy, you can prevent “create Pod” from automatically meaning “root on every cluster node,” without needing to deploy additional external admission controllers.
To control what sorts of settings are allowed in the resources defined in your cluster,
you need Admission Control in addition to RBAC. Since Kubernetes 1.3,
PodSecurityPolicy has been the built-in way to do that for security-related Pod fields.
Using PodSecurityPolicy, you can prevent “create Pod” from automatically meaning “root on every cluster node,”
without needing to deploy additional external admission controllers.
## Why is PodSecurityPolicy going away?
In the years since PodSecurityPolicy was first introduced, we have realized that PSP has some serious usability problems that can’t be addressed without making breaking changes.
In the years since PodSecurityPolicy was first introduced, we have realized that
PSP has some serious usability problems that can’t be addressed without making breaking changes.
The way PSPs are applied to Pods has proven confusing to nearly everyone that has attempted to use them. It is easy to accidentally grant broader permissions than intended, and difficult to inspect which PSP(s) apply in a given situation. The “changing Pod defaults” feature can be handy, but is only supported for certain Pod settings and it’s not obvious when they will or will not apply to your Pod. Without a “dry run” or audit mode, it’s impractical to retrofit PSP to existing clusters safely, and it’s impossible for PSP to ever be enabled by default.
The way PSPs are applied to Pods has proven confusing to nearly everyone that has attempted to use them.
It is easy to accidentally grant broader permissions than intended,
and difficult to inspect which PSP(s) apply in a given situation. The “changing Pod defaults” feature can be handy,
but is only supported for certain Pod settings and it’s not obvious when they will or will not apply to your Pod.
Without a “dry run” or audit mode, it’s impractical to retrofit PSP to existing clusters safely,
and it’s impossible for PSP to ever be enabled by default.
For more information about these and other PSP difficulties, check out SIG Auth’s KubeCon NA 2019 Maintainer Track session video: {{< youtube "SFtHRmPuhEw?start=953" youtube-quote-sm >}}
For more information about these and other PSP difficulties, check out
SIG Auth’s KubeCon NA 2019 Maintainer Track session video:{{< youtube "SFtHRmPuhEw?start=953" youtube-quote-sm >}}
Today, you’re not limited only to deploying PSP or writing your own custom admission controller. Several external admission controllers are available that incorporate lessons learned from PSP to provide a better user experience. [K-Rail](https://github.com/cruise-automation/k-rail), [Kyverno](https://github.com/kyverno/kyverno/), and [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper/) are all well-known, and each has its fans.
Today, you’re not limited only to deploying PSP or writing your own custom admission controller.
Several external admission controllers are available that incorporate lessons learned from PSP to
provide a better user experience. [K-Rail](https://github.com/cruise-automation/k-rail),
[Kyverno](https://github.com/kyverno/kyverno/), and
[OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper/) are all well-known, and each has its fans.
Although there are other good options available now, we believe there is still value in having a built-in admission controller available as a choice for users. With this in mind, we turn toward building what’s next, inspired by the lessons learned from PSP.
Although there are other good options available now, we believe there is still value in
having a built-in admission controller available as a choice for users. With this in mind,
we turn toward building what’s next, inspired by the lessons learned from PSP.
## What’s next?
Kubernetes SIG Security, SIG Auth, and a diverse collection of other community members have been working together for months to ensure that what’s coming next is going to be awesome. We have developed a Kubernetes Enhancement Proposal ([KEP 2579](https://github.com/kubernetes/enhancements/issues/2579)) and a prototype for a new feature, currently being called by the temporary name "PSP Replacement Policy." We are targeting an Alpha release in Kubernetes 1.22.
Kubernetes SIG Security, SIG Auth, and a diverse collection of other community members
have been working together for months to ensure that what’s coming next is going to be awesome.
We have developed a Kubernetes Enhancement Proposal ([KEP 2579](https://github.com/kubernetes/enhancements/issues/2579))
and a prototype for a new feature, currently being called by the temporary name "PSP Replacement Policy."
We are targeting an Alpha release in Kubernetes 1.22.
PSP Replacement Policy starts with the realization that since there is a robust ecosystem of external admission controllers already available, PSP’s replacement doesn’t need to be all things to all people. Simplicity of deployment and adoption is the key advantage a built-in admission controller has compared to an external webhook, so we have focused on how to best utilize that advantage.
PSP Replacement Policy starts with the realization that
since there is a robust ecosystem of external admission controllers already available,
PSP’s replacement doesn’t need to be all things to all people.
Simplicity of deployment and adoption is the key advantage a built-in admission controller has
compared to an external webhook, so we have focused on how to best utilize that advantage.
PSP Replacement Policy is designed to be as simple as practically possible while providing enough flexibility to really be useful in production at scale. It has soft rollout features to enable retrofitting it to existing clusters, and is configurable enough that it can eventually be active by default. It can be deactivated partially or entirely, to coexist with external admission controllers for advanced use cases.
PSP Replacement Policy is designed to be as simple as practically possible
while providing enough flexibility to really be useful in production at scale.
It has soft rollout features to enable retrofitting it to existing clusters,
and is configurable enough that it can eventually be active by default.
It can be deactivated partially or entirely, to coexist with external admission controllers for advanced use cases.
## What does this mean for you?
What this all means for you depends on your current PSP situation. If you’re already using PSP, there’s plenty of time to plan your next move. Please review the PSP Replacement Policy KEP and think about how well it will suit your use case.
What this all means for you depends on your current PSP situation.
If you’re already using PSP, there’s plenty of time to plan your next move.
Please review the PSP Replacement Policy KEP and think about how well it will suit your use case.
If you’re making extensive use of the flexibility of PSP with numerous PSPs and complex binding rules, you will likely find the simplicity of PSP Replacement Policy too limiting. Use the next year to evaluate the other admission controller choices in the ecosystem. There are resources available to ease this transition, such as the [Gatekeeper Policy Library](https://github.com/open-policy-agent/gatekeeper-library).
If you’re making extensive use of the flexibility of PSP with numerous PSPs and complex binding rules,
you will likely find the simplicity of PSP Replacement Policy too limiting.
Use the next year to evaluate the other admission controller choices in the ecosystem.
There are resources available to ease this transition,
such as the [Gatekeeper Policy Library](https://github.com/open-policy-agent/gatekeeper-library).
If your use of PSP is relatively simple, with a few policies and straightforward binding to service accounts in each namespace, you will likely find PSP Replacement Policy to be a good match for your needs. Evaluate your PSPs compared to the Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/) to get a feel for where you’ll be able to use the Restricted, Baseline, and Privileged policies. Please follow along with or contribute to the KEP and subsequent development, and try out the Alpha release of PSP Replacement Policy when it becomes available.
If your use of PSP is relatively simple, with a few policies and straightforward binding to
service accounts in each namespace, you will likely find PSP Replacement Policy to be a good match for your needs.
Evaluate your PSPs compared to the Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
to get a feel for where you’ll be able to use the Restricted, Baseline, and Privileged policies.
Please follow along with or contribute to the KEP and subsequent development,
and try out the Alpha release of PSP Replacement Policy when it becomes available.
If you’re just beginning your PSP journey, you will save time and effort by keeping it simple. You can approximate the functionality of PSP Replacement Policy today by using the Pod Security Standards’ PSPs. If you set the cluster default by binding a Baseline or Restricted policy to the `system:serviceaccounts` group, and then make a more-permissive policy available as needed in certain Namespaces [using ServiceAccount bindings](/docs/concepts/policy/pod-security-policy/#run-another-pod), you will avoid many of the PSP pitfalls and have an easy migration to PSP Replacement Policy. If your needs are much more complex than this, your effort is probably better spent adopting one of the more fully-featured external admission controllers mentioned above.
If you’re just beginning your PSP journey, you will save time and effort by keeping it simple.
You can approximate the functionality of PSP Replacement Policy today by using the Pod Security Standards’ PSPs.
If you set the cluster default by binding a Baseline or Restricted policy to the `system:serviceaccounts` group,
and then make a more-permissive policy available as needed in certain
Namespaces [using ServiceAccount bindings](/docs/concepts/policy/pod-security-policy/#run-another-pod),
you will avoid many of the PSP pitfalls and have an easy migration to PSP Replacement Policy.
If your needs are much more complex than this, your effort is probably better spent adopting
one of the more fully-featured external admission controllers mentioned above.
We’re dedicated to making Kubernetes the best container orchestration tool we can, and sometimes that means we need to remove longstanding features to make space for better things to come. When that happens, the Kubernetes deprecation policy ensures you have plenty of time to plan your next move. In the case of PodSecurityPolicy, several options are available to suit a range of needs and use cases. Start planning ahead now for PSP’s eventual removal, and please consider contributing to its replacement! Happy securing!
We’re dedicated to making Kubernetes the best container orchestration tool we can,
and sometimes that means we need to remove longstanding features to make space for better things to come.
When that happens, the Kubernetes deprecation policy ensures you have plenty of time to plan your next move.
In the case of PodSecurityPolicy, several options are available to suit a range of needs and use cases.
Start planning ahead now for PSP’s eventual removal, and please consider contributing to its replacement! Happy securing!
**Acknowledgment:** It takes a wonderful group to make wonderful software. Thanks are due to everyone who has contributed to the PSP replacement effort, especially (in alphabetical order) Tim Allclair, Ian Coldwater, and Jordan Liggitt. It’s been a joy to work with y’all on this.
**Acknowledgment:** It takes a wonderful group to make wonderful software.
Thanks are due to everyone who has contributed to the PSP replacement effort,
especially (in alphabetical order) Tim Allclair, Ian Coldwater, and Jordan Liggitt.
It’s been a joy to work with y’all on this.

11
content/en/blog/_posts/2022-11-28-registry-k8s-io-change.md
View File

@ -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

69
content/en/blog/_posts/2023-01-05-retroactive-default-storage-class.md
View File

@ -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).

51
content/en/blog/_posts/2023-02-06-k8s-gcr-io-freeze-announcement.md
View File

@ -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.

2
content/en/docs/concepts/cluster-administration/flow-control.md
View File

@ -522,6 +522,8 @@ poorly-behaved workloads that may be harming system health.
queue excess requests, or
* `time-out`, indicating that the request was still in the queue
when its queuing time limit expired.
* `cancelled`, indicating that the request is not purge locked
and has been ejected from the queue.
* `apiserver_flowcontrol_dispatched_requests_total` is a counter
vector (cumulative since server start) of requests that began

2
content/en/docs/concepts/configuration/manage-resources-containers.md
View File

@ -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/)

10
content/en/docs/concepts/services-networking/service.md
View File

@ -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.

4
content/en/docs/concepts/workloads/controllers/daemonset.md
View File

@ -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

2
content/en/docs/concepts/workloads/pods/pod-qos.md
View File

@ -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/).

108
content/en/docs/contribute/review/for-approvers.md
View File

@ -12,11 +12,12 @@ SIG Docs [Reviewers](/docs/contribute/participate/#reviewers) and
[Approvers](/docs/contribute/participate/#approvers) do a few extra things
when reviewing a change.
Every week a specific docs approver volunteers to triage
and review pull requests. This
person is the "PR Wrangler" for the week. See the
[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers) for more information. To become a PR Wrangler, attend the weekly SIG Docs meeting and volunteer. Even if you are not on the schedule for the current week, you can still review pull
requests (PRs) that are not already under active review.
Every week a specific docs approver volunteers to triage and review pull requests.
This person is the "PR Wrangler" for the week. See the
[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)
for more information. To become a PR Wrangler, attend the weekly SIG Docs meeting
and volunteer. Even if you are not on the schedule for the current week, you can
still review pull requests (PRs) that are not already under active review.
In addition to the rotation, a bot assigns reviewers and approvers
for the PR based on the owners for the affected files.
@ -25,21 +26,26 @@ for the PR based on the owners for the affected files.
## Reviewing a PR
Kubernetes documentation follows the [Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process).
Kubernetes documentation follows the
[Kubernetes code review process](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process).
Everything described in [Reviewing a pull request](/docs/contribute/review/reviewing-prs) applies, but Reviewers and Approvers should also do the following:
Everything described in [Reviewing a pull request](/docs/contribute/review/reviewing-prs)
applies, but Reviewers and Approvers should also do the following:
- Using the `/assign` Prow command to assign a specific reviewer to a PR as needed. This is extra important
when it comes to requesting technical review from code contributors.
- Using the `/assign` Prow command to assign a specific reviewer to a PR as needed.
This is extra important when it comes to requesting technical review from code contributors.
{{< note >}}
Look at the `reviewers` field in the front-matter at the top of a Markdown file to see who can
provide technical review.
{{< /note >}}
- Making sure the PR follows the [Content](/docs/contribute/style/content-guide/) and [Style](/docs/contribute/style/style-guide/) guides; link the author to the relevant part of the guide(s) if it doesn't.
- Making sure the PR follows the [Content](/docs/contribute/style/content-guide/)
and [Style](/docs/contribute/style/style-guide/) guides; link the author to the
relevant part of the guide(s) if it doesn't.
- Using the GitHub **Request Changes** option when applicable to suggest changes to the PR author.
- Changing your review status in GitHub using the `/approve` or `/lgtm` Prow commands, if your suggestions are implemented.
- Changing your review status in GitHub using the `/approve` or `/lgtm` Prow commands,
if your suggestions are implemented.
## Commit into another person's PR
@ -72,7 +78,9 @@ true:
[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is
the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow
enables chatbot-style commands to handle GitHub actions across the Kubernetes
organization, like [adding and removing labels](#adding-and-removing-issue-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/<command-name>` format.
organization, like [adding and removing labels](#adding-and-removing-issue-labels),
closing issues, and assigning an approver. Enter Prow commands as GitHub comments
using the `/<command-name>` format.
The most common prow commands reviewers and approvers use are:
@ -92,9 +100,9 @@ To view the commands that you can use in a PR, see the
## Triage and categorize issues
In general, SIG Docs follows the [Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) process and uses the same labels.
In general, SIG Docs follows the
[Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md)
process and uses the same labels.
This GitHub Issue [filter](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)
finds issues that might need triage.
@ -102,16 +110,18 @@ finds issues that might need triage.
### Triaging an issue
1. Validate the issue
- Make sure the issue is about website documentation. Some issues can be closed quickly by
answering a question or pointing the reporter to a resource. See the
[Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details.
- Assess whether the issue has merit.
- Add the `triage/needs-information` label if the issue doesn't have enough
detail to be actionable or the template is not filled out adequately.
- Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels.
- Make sure the issue is about website documentation. Some issues can be closed quickly by
answering a question or pointing the reporter to a resource. See the
[Support requests or code bug reports](#support-requests-or-code-bug-reports) section for details.
- Assess whether the issue has merit.
- Add the `triage/needs-information` label if the issue doesn't have enough
detail to be actionable or the template is not filled out adequately.
- Close the issue if it has both the `lifecycle/stale` and `triage/needs-information` labels.
2. Add a priority label (the
[Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority) define priority labels in detail)
[Issue Triage Guidelines](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)
define priority labels in detail)
{{< table caption="Issue labels" >}}
Label | Description
@ -146,7 +156,8 @@ To remove a label, leave a comment in one of the following formats:
In both cases, the label must already exist. If you try to add a label that does not exist, the command is
silently ignored.
For a list of all labels, see the [website repository's Labels section](https://github.com/kubernetes/website/labels). Not all labels are used by SIG Docs.
For a list of all labels, see the [website repository's Labels section](https://github.com/kubernetes/website/labels).
Not all labels are used by SIG Docs.
### Issue lifecycle labels
@ -177,7 +188,9 @@ and avoids duplicate work on the same problem.
### Dead link issues
If the dead link issue is in the API or `kubectl` documentation, assign them `/priority critical-urgent` until the problem is fully understood. Assign all other dead link issues `/priority important-longterm`, as they must be manually fixed.
If the dead link issue is in the API or `kubectl` documentation, assign them
`/priority critical-urgent` until the problem is fully understood. Assign all
other dead link issues `/priority important-longterm`, as they must be manually fixed.
### Blog issues
@ -222,4 +235,49 @@ https://github.com/kubernetes/kubernetes/issues.
If this is a documentation issue, please re-open this issue.
```
### Squashing
As an approver, when you review pull requests (PRs), there are various cases
where you might do the following:
- Advise the contributor to squash their commits.
- Squash the commits for the contributor.
- Advise the contributor not to squash yet.
- Prevent squashing.
**Advising contributors to squash**: A new contributor might not know that they
should squash commits in their pull requests (PRs). If this is the case, advise
them to do so, provide links to useful information, and offer to arrange help if
they need it. Some useful links:
- [Opening pull requests and squashing your commits](/docs/contribute/new-content/open-a-pr#squashing-commits)
for documentation contributors.
- [GitHub Workflow](https://www.k8s.dev/docs/guide/github-workflow/), including diagrams, for developers.
**Squashing commits for contributors**: If a contributor might have difficulty
squashing commits or there is time pressure to merge a PR, you can perform the
squash for them:
- The kubernetes/website repo is
[configured to allow squashing for pull request merges](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests).
Simply select the *Squash commits* button.
- In the PR, if the contributor enables maintainers to manage the PR, you can
squash their commits and update their fork with the result. Before you squash,
advise them to save and push their latest changes to the PR. After you squash,
advise them to pull the squashed commit to their local clone.
- You can get GitHub to squash the commits by using a label so that Tide / GitHub
performs the squash or by clicking the *Squash commits* button when you merge the PR.
**Advise contributors to avoid squashing**
- If one commit does something broken or unwise, and the last commit reverts this
error, don't squash the commits. Even though the "Files changed" tab in the PR
on GitHub and the Netlify preview will both look OK, merging this PR might create
rebase or merge conflicts for other folks. Intervene as you see fit to avoid that
risk to other contributors.
**Never squash**
- If you're launching a localization or releasing the docs for a new version,
you are merging in a branch that's not from a user's fork, _never squash the commits_.
Not squashing is essential because you must maintain the commit history for those files.

1
content/en/docs/reference/_index.md
View File

@ -77,6 +77,7 @@ operator to use or manage a cluster.
* [kubeconfig (v1)](/docs/reference/config-api/kubeconfig.v1/)
* [kube-apiserver admission (v1)](/docs/reference/config-api/apiserver-admission.v1/)
* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) and
* [kube-apiserver configuration (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/) and
[kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/)
* [kube-apiserver encryption (v1)](/docs/reference/config-api/apiserver-encryption.v1/)
* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)

33
content/en/docs/reference/access-authn-authz/service-accounts-admin.md
View File

@ -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/).

268
content/en/docs/reference/config-api/apiserver-config.v1beta1.md Normal file
View File

@ -0,0 +1,268 @@
---
title: kube-apiserver Configuration (v1beta1)
content_type: tool-reference
package: apiserver.k8s.io/v1beta1
auto_generated: true
---
<p>Package v1beta1 is the v1beta1 version of the API.</p>
## Resource Types
- [EgressSelectorConfiguration](#apiserver-k8s-io-v1beta1-EgressSelectorConfiguration)
## `EgressSelectorConfiguration` {#apiserver-k8s-io-v1beta1-EgressSelectorConfiguration}
<p>EgressSelectorConfiguration provides versioned configuration for egress selector clients.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.k8s.io/v1beta1</code></td></tr>
<tr><td><code>kind</code><br/>string</td><td><code>EgressSelectorConfiguration</code></td></tr>
<tr><td><code>egressSelections</code> <B>[Required]</B><br/>
<a href="#apiserver-k8s-io-v1beta1-EgressSelection"><code>[]EgressSelection</code></a>
</td>
<td>
<p>connectionServices contains a list of egress selection client configurations</p>
</td>
</tr>
</tbody>
</table>
## `Connection` {#apiserver-k8s-io-v1beta1-Connection}
**Appears in:**
- [EgressSelection](#apiserver-k8s-io-v1beta1-EgressSelection)
<p>Connection provides the configuration for a single egress selection client.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>proxyProtocol</code> <B>[Required]</B><br/>
<a href="#apiserver-k8s-io-v1beta1-ProtocolType"><code>ProtocolType</code></a>
</td>
<td>
<p>Protocol is the protocol used to connect from client to the konnectivity server.</p>
</td>
</tr>
<tr><td><code>transport</code><br/>
<a href="#apiserver-k8s-io-v1beta1-Transport"><code>Transport</code></a>
</td>
<td>
<p>Transport defines the transport configurations we use to dial to the konnectivity server.
This is required if ProxyProtocol is HTTPConnect or GRPC.</p>
</td>
</tr>
</tbody>
</table>
## `EgressSelection` {#apiserver-k8s-io-v1beta1-EgressSelection}
**Appears in:**
- [EgressSelectorConfiguration](#apiserver-k8s-io-v1beta1-EgressSelectorConfiguration)
<p>EgressSelection provides the configuration for a single egress selection client.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>name</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>name is the name of the egress selection.
Currently supported values are &quot;controlplane&quot;, &quot;master&quot;, &quot;etcd&quot; and &quot;cluster&quot;
The &quot;master&quot; egress selector is deprecated in favor of &quot;controlplane&quot;</p>
</td>
</tr>
<tr><td><code>connection</code> <B>[Required]</B><br/>
<a href="#apiserver-k8s-io-v1beta1-Connection"><code>Connection</code></a>
</td>
<td>
<p>connection is the exact information used to configure the egress selection</p>
</td>
</tr>
</tbody>
</table>
## `ProtocolType` {#apiserver-k8s-io-v1beta1-ProtocolType}
(Alias of `string`)
**Appears in:**
- [Connection](#apiserver-k8s-io-v1beta1-Connection)
<p>ProtocolType is a set of valid values for Connection.ProtocolType</p>
## `TCPTransport` {#apiserver-k8s-io-v1beta1-TCPTransport}
**Appears in:**
- [Transport](#apiserver-k8s-io-v1beta1-Transport)
<p>TCPTransport provides the information to connect to konnectivity server via TCP</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>url</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>URL is the location of the konnectivity server to connect to.
As an example it might be &quot;https://127.0.0.1:8131&quot;</p>
</td>
</tr>
<tr><td><code>tlsConfig</code><br/>
<a href="#apiserver-k8s-io-v1beta1-TLSConfig"><code>TLSConfig</code></a>
</td>
<td>
<p>TLSConfig is the config needed to use TLS when connecting to konnectivity server</p>
</td>
</tr>
</tbody>
</table>
## `TLSConfig` {#apiserver-k8s-io-v1beta1-TLSConfig}
**Appears in:**
- [TCPTransport](#apiserver-k8s-io-v1beta1-TCPTransport)
<p>TLSConfig provides the authentication information to connect to konnectivity server
Only used with TCPTransport</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>caBundle</code><br/>
<code>string</code>
</td>
<td>
<p>caBundle is the file location of the CA to be used to determine trust with the konnectivity server.
Must be absent/empty if TCPTransport.URL is prefixed with http://
If absent while TCPTransport.URL is prefixed with https://, default to system trust roots.</p>
</td>
</tr>
<tr><td><code>clientKey</code><br/>
<code>string</code>
</td>
<td>
<p>clientKey is the file location of the client key to be used in mtls handshakes with the konnectivity server.
Must be absent/empty if TCPTransport.URL is prefixed with http://
Must be configured if TCPTransport.URL is prefixed with https://</p>
</td>
</tr>
<tr><td><code>clientCert</code><br/>
<code>string</code>
</td>
<td>
<p>clientCert is the file location of the client certificate to be used in mtls handshakes with the konnectivity server.
Must be absent/empty if TCPTransport.URL is prefixed with http://
Must be configured if TCPTransport.URL is prefixed with https://</p>
</td>
</tr>
</tbody>
</table>
## `Transport` {#apiserver-k8s-io-v1beta1-Transport}
**Appears in:**
- [Connection](#apiserver-k8s-io-v1beta1-Connection)
<p>Transport defines the transport configurations we use to dial to the konnectivity server</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>tcp</code><br/>
<a href="#apiserver-k8s-io-v1beta1-TCPTransport"><code>TCPTransport</code></a>
</td>
<td>
<p>TCP is the TCP configuration for communicating with the konnectivity server via TCP
ProxyProtocol of GRPC is not supported with TCP transport at the moment
Requires at least one of TCP or UDS to be set</p>
</td>
</tr>
<tr><td><code>uds</code><br/>
<a href="#apiserver-k8s-io-v1beta1-UDSTransport"><code>UDSTransport</code></a>
</td>
<td>
<p>UDS is the UDS configuration for communicating with the konnectivity server via UDS
Requires at least one of TCP or UDS to be set</p>
</td>
</tr>
</tbody>
</table>
## `UDSTransport` {#apiserver-k8s-io-v1beta1-UDSTransport}
**Appears in:**
- [Transport](#apiserver-k8s-io-v1beta1-Transport)
<p>UDSTransport provides the information to connect to konnectivity server via UDS</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>udsName</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>UDSName is the name of the unix domain socket to connect to konnectivity server
This does not use a unix:// prefix. (Eg: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)</p>
</td>
</tr>
</tbody>
</table>

2
content/en/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md
View File

@ -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.

47
content/en/docs/reference/labels-annotations-taints/_index.md
View File

@ -104,6 +104,53 @@ The cluster autoscaler never evicts Pods that have this annotation explicitly se
`"false"`; you could set that on an important Pod that you want to keep running.
If this annotation is not set then the cluster autoscaler follows its Pod-level behavior.
### config.kubernetes.io/local-config
Example: `config.kubernetes.io/local-config: "true"`
Used on: All objects
This annotation is used in manifests to mark an object as local configuration that should not be submitted to the Kubernetes API.
A value of "true" for this annotation declares that the object is only consumed by client-side tooling and should not be submitted to the API server.
A value of "false" can be used to declare that the object should be submitted to the API server even when it would otherwise be assumed to be local.
This annotation is part of the Kubernetes Resource Model (KRM) Functions Specification, which is used by Kustomize and similar third-party tools. For example, Kustomize removes objects with this annotation from its final build output.
### internal.config.kubernetes.io/* (reserved prefix) {#internal.config.kubernetes.io-reserved-wildcard}
Used on: All objects
This prefix is reserved for internal use by tools that act as orchestrators in accordance with the Kubernetes Resource Model (KRM) Functions Specification. Annotations with this prefix are internal to the orchestration process and are not persisted to the manifests on the filesystem. In other words, the orchestrator tool should set these annotations when reading files from the local filesystem and remove them when writing the output of functions back to the filesystem.
A KRM function **must not** modify annotations with this prefix, unless otherwise specified for a given annotation. This enables orchestrator tools to add additional internal annotations, without requiring changes to existing functions.
### internal.config.kubernetes.io/path
Example: `internal.config.kubernetes.io/path: "relative/file/path.yaml"`
Used on: All objects
This annotation records the slash-delimited, OS-agnostic, relative path to the manifest file the object was loaded from. The path is relative to a fixed location on the filesystem, determined by the orchestrator tool.
This annotation is part of the Kubernetes Resource Model (KRM) Functions Specification, which is used by Kustomize and similar third-party tools.
A KRM Function **should not** modify this annotation on input objects unless it is modifying the referenced files. A KRM Function **may** include this annotation on objects it generates.
### internal.config.kubernetes.io/index
Example: `internal.config.kubernetes.io/index: "2"`
Used on: All objects
This annotation records the zero-indexed position of the YAML document that contains the object within the manifest file the object was loaded from. Note that YAML documents are separated by three dashes (`---`) and can each contain one object. When this annotation is not specified, a value of 0 is implied.
This annotation is part of the Kubernetes Resource Model (KRM) Functions Specification, which is used by Kustomize and similar third-party tools.
A KRM Function **should not** modify this annotation on input objects unless it is modifying the referenced files. A KRM Function **may** include this annotation on objects it generates.
### kubernetes.io/arch
Example: `kubernetes.io/arch: "amd64"`

14
content/en/docs/setup/production-environment/container-runtimes.md
View File

@ -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.

2
content/en/docs/setup/production-environment/tools/kubespray.md
View File

@ -52,7 +52,7 @@ Kubespray provides the following utilities to help provision your environment:
* [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
* [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
* [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/metal)
* [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/equinix)
### (2/5) Compose an inventory file

2
content/en/docs/tasks/administer-cluster/encrypt-data.md
View File

@ -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,

12
content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md
View File

@ -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.

43
content/en/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you.md
View File

@ -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

2
content/en/docs/tasks/administer-cluster/sysctl-cluster.md
View File

@ -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).

15
content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md
View File

@ -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

24
content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
View File

@ -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
```

33
content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md
View File

@ -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.

29
content/en/docs/tasks/tools/install-kubectl-linux.md
View File

@ -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.

19
content/en/docs/tasks/tools/install-kubectl-macos.md
View File

@ -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.

31
content/en/docs/tasks/tools/install-kubectl-windows.md
View File

@ -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)

2
content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html
View File

@ -3,6 +3,8 @@ title: "Interactive Tutorial - Configuring a Java Microservice"
weight: 20
---
{{% katacoda-removal %}}
<!DOCTYPE html>
<html lang="en">

2
content/en/docs/tutorials/hello-minikube.md
View File

@ -13,6 +13,8 @@ card:
weight: 10
---
{{% katacoda-removal %}}
<!-- overview -->
This tutorial shows you how to run a sample app

4
content/en/docs/tutorials/kubernetes-basics/_index.html
View File

@ -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">

2
content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
View File

@ -3,6 +3,8 @@ title: Interactive Tutorial - Creating a Cluster
weight: 20
---
{{% katacoda-removal %}}
<!DOCTYPE html>
<html lang="en">

2
content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
View File

@ -3,6 +3,8 @@ title: Interactive Tutorial - Deploying an App
weight: 20
---
{{% katacoda-removal %}}
<!DOCTYPE html>
<html lang="en">

2
content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html
View File

@ -3,6 +3,8 @@ title: Interactive Tutorial - Exploring Your App
weight: 20
---
{{% katacoda-removal %}}
<!DOCTYPE html>
<html lang="en">

2
content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html
View File

@ -3,6 +3,8 @@ title: Interactive Tutorial - Exposing Your App
weight: 20
---
{{% katacoda-removal %}}
<!DOCTYPE html>
<html lang="en">

2
content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html
View File

@ -3,6 +3,8 @@ title: Interactive Tutorial - Scaling Your App
weight: 20
---
{{% katacoda-removal %}}
<!DOCTYPE html>
<html lang="en">

2
content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html
View File

@ -3,6 +3,8 @@ title: Interactive Tutorial - Updating Your App
weight: 20
---
{{% katacoda-removal %}}
<!DOCTYPE html>
<html lang="en">

6
content/fr/docs/contribute/localization.md
View File

@ -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

4
content/fr/docs/getting-started-guides/_index.md
View File

@ -1,4 +0,0 @@
---
title: Solutions indépendantes
weight: 50
---

4
content/fr/docs/getting-started-guides/fedora/_index.md
View File

@ -1,4 +0,0 @@
---
title: Serveurs physiques
weight: 60
---

2
content/fr/docs/reference/kubectl/overview.md
View File

@ -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

26
content/hi/docs/reference/glossary/control-plane.md Normal file
View File

@ -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" >}} कहा जाता था।

2
content/hi/docs/reference/glossary/istio.md
View File

@ -2,7 +2,7 @@
title: Istio
id: istio
date: 2018-04-12
full_link: https://istio.io/docs/concepts/what-is-istio/
full_link: https://istio.io/latest/about/service-mesh/#what-is-istio
short_description: >
एक ओपन प्लैटफ़ॉर्म (कुबेरनेट्स-विशिष्ट नहीं) जो माइक्रोसर्विसेज को एकीकृत करने, ट्रैफ़िक प्रवाह को प्रबंधित करने, नीतियों को लागू करने और टेलीमेट्री डेटा को एकत्र करने का एक समान तरीका प्रदान करता हैं।
aka:

2
content/ja/_index.html
View File

@ -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 %}}

1
content/ja/blog/_posts/2022-02-17-updated-dockershim-faq.md
View File

@ -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/)の更新版です。

175
content/ja/blog/_posts/2022-12-05-forensic-container-checkpointing/index.md Normal file
View File

@ -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/

2
content/ja/docs/concepts/architecture/garbage-collection.md
View File

@ -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/)

67
content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md
View File

@ -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/)を参照してください。

2
content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
View File

@ -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を選択するには、以下のコマンドを使用します。

91
content/ja/docs/concepts/overview/_index.md
View File

@ -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がなぜこんなに便利なのかを見てみましょう。
![Deployment evolution](/images/docs/Container_Evolution.svg)
**仮想化ができる前の時代におけるデプロイ (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/)準備はできましたか？

92
content/ja/docs/concepts/overview/what-is-kubernetes.md
View File

@ -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がなぜこんなに便利なのかを見てみましょう。
![Deployment evolution](/images/docs/Container_Evolution.svg)
**仮想化ができる前の時代におけるデプロイ (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/)準備はできましたか？

2
content/ja/docs/concepts/overview/working-with-objects/labels.md
View File

@ -167,7 +167,7 @@ partition
### LISTとWATCHによるフィルタリング
LISTとWATCHオペレーションは、単一のクエリパラメータを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます。
LISTとWATCHオペレーションは、単一のクエリパラメーターを使うことによって返されるオブジェクトのセットをフィルターするためのラベルセレクターを指定できます。
*集合ベース* と*等価ベース* のどちらの要件も許可されています(ここでは、URLクエリストリング内で出現します)。
* *等価ベース* での要件: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`

2
content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -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}

2
content/ja/docs/concepts/scheduling-eviction/pod-overhead.md
View File

@ -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のオーバーヘッドを含めます。

2
content/ja/docs/concepts/security/pod-security-standards.md
View File

@ -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

2
content/ja/docs/concepts/services-networking/service.md
View File

@ -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のセットに対する負荷分散が可能です。

4
content/ja/docs/concepts/storage/dynamic-provisioning.md
View File

@ -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/)を参照ください。

2
content/ja/docs/concepts/storage/storage-capacity.md
View File

@ -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オブジェクトを一覧表示します。

4
content/ja/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -49,7 +49,7 @@ deletionPolicyが`Delete`の場合、元となるストレージスナップシ
## Parameters
VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメータを持っています。
`driver`に応じて様々なパラメータを使用できます。
VolumeSnapshotClassは、そのクラスに属するVolumeSnapshotを指定するパラメーターを持っています。
`driver`に応じて様々なパラメーターを使用できます。

4
content/ja/docs/concepts/workloads/controllers/daemonset.md
View File

@ -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)の項目を参照ください)。
@ -69,7 +69,7 @@ DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts
上記の2つが指定された場合は、2つの条件をANDでどちらも満たすものを結果として返します。
もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。
`spec.selector`は`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。
### 選択したNode上でPodを稼働させる {#running-pods-on-select-nodes}

8
content/ja/docs/concepts/workloads/controllers/deployment.md
View File

@ -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)を参照してください。

147
content/ja/docs/concepts/workloads/controllers/garbage-collection.md
View File

@ -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)

2
content/ja/docs/concepts/workloads/controllers/job.md
View File

@ -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)を参照)と適切な再起動ポリシーを指定する必要があります。

2
content/ja/docs/concepts/workloads/controllers/replicaset.md
View File

@ -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`のみ許可されていて、そしてそれがデフォルト値です。

2
content/ja/docs/concepts/workloads/pods/_index.md
View File

@ -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を管理してくれます。

118
content/ja/docs/concepts/workloads/pods/pod-overview.md
View File

@ -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/)

64
content/ja/docs/concepts/workloads/pods/podpreset.md
View File

@ -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)を参照してください。

63
content/ja/docs/contribute/review/reviewing-prs.md
View File

@ -22,22 +22,55 @@ weight: 10
レビューを始める前に、以下のことを心に留めてください。
- [CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)を読み、いかなる時にも行動規範にしたがって行動するようにする。
- [CNCFの行動規範](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)を読み、いかなる時にも行動規範にしたがって行動するようにする。
- 礼儀正しく、思いやりを持ち、助け合う気持ちを持つ。
- 変更点だけでなく、PRのポジティブな側面についてもコメントする。
- 相手の気持ちに共感して、自分のレビューが相手にどのように受け取られるのかをよく意識する。
- 相手の善意を前提として、疑問点を明確にする質問をする。
- 経験を積んだコントリビューターの場合、コンテンツに大幅な変更が必要な新規のコントリビューターとペアを組んで作業に取り組むことを考える。
- 経験を積んだコントリビューターの場合、コンテンツに大幅な変更が必要な作業を行う新規のコントリビューターとペアを組んで取り組むことを考える。
## レビューのプロセス
一般に、コンテンツや文体に対するプルリクエストは、英語でレビューを行います。
一般に、コンテンツや文体に対するプルリクエストは、英語でレビューを行います。図1は、レビュープロセスについて手順の概要を示しています。 各ステップの詳細は次のとおりです。
**(訳注:SIG Docs jaでは、日本語でも対応しています。日本語の翻訳に対するレビューは、日本語でも構いません。ただし、プルリクエストの作成者や他のコントリビューターが必ずしも日本語を理解できるとは限りませんので、注意して発言してください。)**
<!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
<!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
{{< mermaid >}}
flowchart LR
subgraph fourth[レビューの開始]
direction TB
S[ ] -.-
M[コメントを追加] --> N[変更の確認]
N --> O[Commentを選択]
end
subgraph third[PRの選択]
direction TB
T[ ] -.-
J[説明とコメントを読む]--> K[Netlifyプレビューで<br>変更点を表示]
end
A[オープン状態の<br>PR一覧を確認]--> B[オープン状態のPRを<br>ラベルで絞り込む]
B --> third --> fourth
classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class A,B,J,K,M,N,O grey
class S,T spacewhite
class third,fourth white
{{</ mermaid >}}
図1. レビュープロセスの手順
1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)に移動します。Kubernetesのウェブサイトとドキュメントに対するopen状態のプルリクエスト一覧が表示されます。
2. open状態のPRに、以下に示すラベルを1つ以上使って絞り込みます。
- `cncf-cla: yes` (推奨): CLAにサインしていないコントリビューターが提出したPRはマージできません。詳しい情報は、[CLAの署名](/docs/contribute/new-content/overview/#sign-the-cla)を読んでください。
- `cncf-cla: yes` (推奨): CLAにサインしていないコントリビューターが提出したPRはマージできません。詳しい情報は、[CLAの署名](/docs/contribute/new-content/#sign-the-cla)を読んでください。
- `language/en` (推奨): 英語のPRだけに絞り込みます。
- `size/<size>`: 特定の大きさのPRだけに絞り込みます。レビューを始めたばかりの人は、小さなPRから始めてください。
@ -47,12 +80,17 @@ weight: 10
- PRの説明を読み、行われた変更について理解し、関連するissueがあればそれも読みます。
- 他のレビュアのコメントがあれば読みます。
- **Files changed**タブをクリックし、変更されたファイルと行を確認します。
- **Conversation**タブの下にあるPRのbuild checkセクションまでスクロールし、**deploy/netlify**の行の**Details**リンクをクリックして、Netlifyのプレビュービルドで変更点をプレビューします。
- **Conversation**タブの下にあるPRのbuild checkセクションまでスクロールし、Netlifyのプレビュービルドで変更点をプレビューします。これはスクリーンショットです(これは、GitHubのデスクトップサイトを見せています。タブレットやスマートフォンデバイスでレビューしている場合は、GitHubウェブのUIは少し異なります):
{{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="GitHub pull request details including link to Netlify preview" >}}
プレビューを開くには、チェックリストの**deploy/netlify**行の**Details**リンクをクリックします。
4. **Files changed**タブに移動してレビューを始めます。
1. コメントしたい場合は行の横の`+`マークをクリックします。
2. その行に関するコメントを書き、**Add single comment**(1つのコメントだけを残したい場合)または**Start a review**(複数のコメントを行いたい場合)のいずれかをクリックします。
3. コメントをすべて書いたら、ページ上部の**Review changes**をクリックします。ここでは、レビューの要約を追加できます(コントリビューターにポジティブなコメントも書きましょう！)。必要に応じて、PRを承認したり、コメントしたり、変更をリクエストします。新しいコントリビューターの場合は**Comment**だけが行えます。
3. コメントをすべて書いたら、ページ上部の**Review changes**をクリックします。ここでは、レビューの要約を追加できます(コントリビューターにポジティブなコメントも書きましょう！)。常に「Comment」を使用してください。
- レビューの終了時、「Request changes」ボタンをクリックしないでください。さらに変更される前にマージされるのをブロックしたい場合、「/hold」コメントを残すことができます。Holdを設定する理由を説明し、必要に応じて、自分や他のレビューアがHoldを解除できる条件を指定してください。
- レビューの終了時、「Approve」ボタンをクリックしないでください。大抵の場合、「/approve」コメントを残すことが推奨されます。
## レビューのチェックリスト
@ -61,6 +99,9 @@ weight: 10
### 言語と文法
- 言語や文法に明らかな間違いはないですか？ もっとよい言い方はないですか？
- 作成者が変更している箇所の用語や文法に注目してください。作成者がページ全体の変更を目的として明確にしていない限り、そのページのすべての問題を修正する義務はありません。
- 既存のページを変更するPRである場合、変更されている箇所に注目してレビューしてください。その変更されたコンテンツは、技術的および編集の正確性についてレビューしてください。PRの作成者が対処しようとしている内容と直接関係のない間違いを見つけた場合、それは別のIssueとして扱うべきです(既存のIssueが無いことを確認してください)。
- コンテンツを*移動*するPull Requestに注意してください。作成者がページの名前を変更したり、2つのページを結合したりする場合、通常、私たち(Kubernetes SIG Docs)は、その移動されたコンテンツ内で見つけられるすべての文法やスペルの間違いを修正することを作成者に要求することを避けています。
- もっと簡単な単語に置き換えられる複雑な単語や古い単語はありませんか？
- 使われている単語や専門用語や言い回しで差別的ではない別の言葉に置き換えられるものはありませんか？
- 言葉選びや大文字の使い方は[style guide](/docs/contribute/style/style-guide/)に従っていますか？
@ -77,10 +118,16 @@ weight: 10
- PRはページ名、slug/alias、アンカーリンクの変更や削除をしていますか？ その場合、このPRの変更の結果、リンク切れは発生しませんか？ ページ名を変更してslugはそのままにするなど、他の選択肢はありませんか？
- PRは新しいページを作成するものですか？ その場合、次の点に注意してください。
- ページは正しい[page content type](/docs/contribute/style/page-content-types/)と関係するHugoのshortcodeを使用していますか？
- セクションの横のナビゲーション(または全体)にページは正しく表示されますか？
- セクションの横のナビゲーションにページは正しく表示されますか(または表示されませんか)？
- ページは[Docs Home](/docs/home/)に一覧されますか？
- Netlifyのプレビューで変更は確認できますか？ 特にリスト、コードブロック、テーブル、備考、画像などに注意してください。
### その他
PRに関して誤字や空白などの小さな問題を指摘する場合は、コメントの前に`nit:`と書いてください。こうすることで、PRの作者は問題が深刻なものではないことが分かります。
- [些細な編集](https://www.kubernetes.dev/docs/guide/pull-requests/#trivial-edits)に注意してください。些細な編集だと思われる変更を見つけた場合は、そのポリシーを指摘してください (それが本当に改善である場合は、変更を受け入れても問題ありません)。
- 空白の修正を行っている作成者には、PRの最初のコミットでそれを行い、その後に他の変更を加えるよう促してください。これにより、マージとレビューの両方が容易になります。特に、大量の空白文字の整理と共に1回のコミットで発生する些細な変更に注意してください(もしそれを見つけたら、作成者に修正を促してください)。
レビュアーが誤字や不適切な空白など、PRの本質でない小さな問題を発見した場合は、コメントの先頭に`nit:`を付けてください。これにより、作成者はこのフィードバックが重要でないことを知ることができます。
Pull Requestの承認を検討する際、残りのすべてのフィードバックがnitとしてマークされていれば、残っていたとしてもPRをマージできます。その場合、残っているnitに関するIssueをオープンすると役立つことがよくあります。その新しいIssueを[Good First Issue](https://www.kubernetes.dev/docs/guide/help-wanted/#good-first-issue)としてマークするための条件を満たすことができるかどうか検討してください。それができたら、これらは良い情報源になります。

4
content/ja/docs/contribute/style/hugo-shortcodes/index.md
View File

@ -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" */>}}`

2
content/ja/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -49,6 +49,7 @@ content_type: concept
| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | 1.23 |
| `AnyVolumeDataSource` | `true` | Beta | 1.24 | |
| `AppArmor` | `true` | Beta | 1.4 | |
| `CheckpointContainer` | `false` | Alpha | 1.25 | |
| `CPUManagerPolicyAlphaOptions` | `false` | Alpha | 1.23 | |
| `CPUManagerPolicyBetaOptions` | `true` | Beta | 1.23 | |
| `CPUManagerPolicyOptions` | `false` | Alpha | 1.22 | 1.22 |
@ -354,6 +355,7 @@ GAになってからさらなる変更を加えることは現実的ではない
`APIPriorityAndFairness`: 各サーバーで優先順位付けと公平性を備えた要求の並行性を管理できるようにします(`RequestManagement`から名前が変更されました)。
- `APIResponseCompression`:`LIST`や`GET`リクエストのAPIレスポンスを圧縮します。
- `AppArmor`: Dockerを使用する場合にLinuxノードでAppArmorによる強制アクセスコントロールを有効にします。詳細は[AppArmorチュートリアル](/ja/docs/tutorials/clusters/apparmor/)で確認できます。
- `ContainerCheckpoint`: kubeletチェックポイントAPIを有効にします。詳細は[KubeletチェックポイントAPI](/ja/docs/reference/node/kubelet-checkpoint-api/)で確認できます。
- `AttachVolumeLimit`: ボリュームプラグインを有効にすることでノードにアタッチできるボリューム数の制限を設定できます。
- `BalanceAttachedNodeVolumes`: スケジューリング中にバランスのとれたリソース割り当てを考慮するノードのボリュームカウントを含めます。判断を行う際に、CPU、メモリー使用率、およびボリュームカウントが近いノードがスケジューラーによって優先されます。
- `BlockVolume`: PodでRawブロックデバイスの定義と使用を有効にします。詳細は[Rawブロックボリュームのサポート](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)で確認できます。

20
content/ja/docs/reference/glossary/garbage-collection.md Normal file
View File

@ -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
content/ja/docs/reference/glossary/pod.md
View File

@ -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 とはクラスターで動作しているいくつかのコンテナのまとまりです。

6
content/ja/docs/reference/glossary/service-catalog.md
View File

@ -4,13 +4,13 @@ id: service-catalog
date: 2018-04-12
full_link:
short_description: >
Kubernetesクラスターで稼働するアプリケーションが、クラウドプロバイダーによって提供されるデータストアサービスのように、外部のマネージドソフトウェアを容易に使えるようにするための拡張APIです。
Kubernetesクラスターで稼働するアプリケーションが、クラウドプロバイダーによって提供されるデータストアサービスのように、外部のマネージドソフトウェアを容易に使えるようにするための古い拡張APIです。
aka:
tags:
- extension
---
Kubernetesクラスターで稼働するアプリケーションが、クラウドプロバイダーによって提供されるデータストアサービスのように、外部のマネージドソフトウェアを容易に使えるようにするための拡張APIです。
Kubernetesクラスターで稼働するアプリケーションが、クラウドプロバイダーによって提供されるデータストアサービスのように、外部のマネージドソフトウェアを容易に使えるようにするための古い拡張APIです。
<!--more-->
サービスカタログを使用することで、提供されている{{< glossary_tooltip text="マネージドサービス" term_id="managed-service" >}}を、それらのサービスがどのように作成されるか、また管理されるかについての知識を無しに、一覧表示したり、プロビジョニングや使用をすることができます。
サービスカタログを使用することで、提供されている{{< glossary_tooltip text="マネージドサービス" term_id="managed-service" >}}を、それらのサービスがどのように作成されるか、また管理されるかについての知識無しに、一覧表示したり、プロビジョニングやバインドが可能でした。

8
content/ja/docs/reference/glossary/service.md
View File

@ -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などの他のメカニズムを実現することができます。

140
content/ja/docs/reference/kubectl/_index.md
View File

@ -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 -->
@ -66,6 +66,32 @@ kubectl [command] [TYPE] [NAME] [flags]
ヘルプが必要な場合は、ターミナルウィンドウから`kubectl help`を実行してください。
## クラスター内認証と名前空間のオーバーライド {#in-cluster-authentication-and-namespace-overrides}
デフォルトでは、`kubectl`は最初にPod内で動作しているか、つまりクラスター内で動作しているかどうかを判断します。まず、`KUBERNETES_SERVICE_HOST`と`KUBERNETES_SERVICE_PORT`の環境変数を確認し、サービスアカウントのトークンファイルが`/var/run/secrets/kubernetes.io/serviceaccount/token`に存在するかどうかを確認します。3つともクラスター内で見つかった場合、クラスター内認証とみなされます。
後方互換性を保つため、クラスター内認証時に`POD_NAMESPACE`環境変数が設定されている場合には、サービスアカウントトークンのデフォルトの名前空間が上書きされます。名前空間のデフォルトに依存しているすべてのマニフェストやツールは、この影響を受けます。
**`POD_NAMESPACE`環境変数**
`POD_NAMESPACE`環境変数が設定されている場合、名前空間に属するリソースのCLI操作は、デフォルトで環境変数の値になります。例えば、変数に`seattle`が設定されている場合、`kubectl get pods`は、`seattle`名前空間のPodを返します。これは、Podが名前空間に属するリソースであり、コマンドで名前空間が指定されていないためです。`kubectl api-resources`の出力を見て、リソースが名前空間に属するかどうかを判断してください。
明示的に`--namespace <value>`を使用すると、この動作は上書きされます。
**kubectlによるServiceAccountトークンの処理方法**
以下の条件がすべて成立した場合、
* `/var/run/secrets/kubernetes.io/serviceaccount/token`にマウントされたKubernetesサービスアカウントのトークンファイルがある
* `KUBERNETES_SERVICE_HOST`環境変数が設定されている
* `KUBERNETES_SERVICE_PORT`環境変数が設定されている
* kubectlコマンドラインで名前空間を明示的に指定しない
kubectlはクラスター内で実行されているとみなして、そのServiceAccountの名前空間(これはPodの名前空間と同じです)を検索し、その名前空間に対して機能します。これは、クラスターの外の動作とは異なります。kubectlがクラスターの外で実行され、名前空間を指定しない場合、kubectlコマンドは、クライアント構成の現在のコンテキストに設定されている名前空間に対して動作します。kubectlのデフォルトの名前空間を変更するには、次のコマンドを使用できます。
```shell
kubectl config set-context --current --namespace=<namespace-name>
```
## 操作
以下の表に、`kubectl`のすべての操作の簡単な説明と一般的な構文を示します。
@ -93,6 +119,7 @@ kubectl [command] [TYPE] [NAME] [flags]
`diff` | `kubectl diff -f FILENAME [flags]`| ファイルまたは標準出力と、現在の設定との差分を表示します。
`drain` | `kubectl drain NODE [options]` | メンテナンスの準備のためにNodeをdrainします。
`edit` | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。
`events` | `kubectl events` | イベントを一覧表示します。
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Pod内のコンテナに対して、コマンドを実行します。
`explain` | `kubectl explain [--recursive=false] [flags]` | 様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。
`expose` | <code>kubectl expose (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--port=port] [--protocol=TCP&#124;UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。
@ -122,59 +149,66 @@ kubectl [command] [TYPE] [NAME] [flags]
以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。
(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。)
(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.25.0時点で正確でした。)
| リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 |
| リソース名 | 短縮名 | APIバージョン | 名前空間に属するか | リソースの種類 |
|---|---|---|---|---|
| `bindings` | | | true | Binding|
| `componentstatuses` | `cs` | | false | ComponentStatus |
| `configmaps` | `cm` | | true | ConfigMap |
| `endpoints` | `ep` | | true | Endpoints |
| `limitranges` | `limits` | | true | LimitRange |
| `namespaces` | `ns` | | false | Namespace |
| `nodes` | `no` | | false | Node |
| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
| `persistentvolumes` | `pv` | | false | PersistentVolume |
| `pods` | `po` | | true | Pod |
| `podtemplates` | | | true | PodTemplate |
| `replicationcontrollers` | `rc` | | true| ReplicationController |
| `resourcequotas` | `quota` | | true | ResourceQuota |
| `secrets` | | | true | Secret |
| `serviceaccounts` | `sa` | | true | ServiceAccount |
| `services` | `svc` | | true | Service |
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
| `apiservices` | | apiregistration.k8s.io | false | APIService |
| `controllerrevisions` | | apps | true | ControllerRevision |
| `daemonsets` | `ds` | apps | true | DaemonSet |
| `deployments` | `deploy` | apps | true | Deployment |
| `replicasets` | `rs` | apps | true | ReplicaSet |
| `statefulsets` | `sts` | apps | true | StatefulSet |
| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
| `cronjobs` | `cj` | batch | true | CronJob |
| `jobs` | | batch | true | Job |
| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
| `leases` | | coordination.k8s.io | true | Lease |
| `events` | `ev` | events.k8s.io | true | Event |
| `ingresses` | `ing` | extensions | true | Ingress |
| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
| `roles` | | rbac.authorization.k8s.io | true | Role |
| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
| `csidrivers` | | storage.k8s.io | false | CSIDriver |
| `csinodes` | | storage.k8s.io | false | CSINode |
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
| `bindings` | | v1 | true | Binding |
| `componentstatuses` | `cs` | v1 | false | ComponentStatus |
| `configmaps` | `cm` | v1 | true | ConfigMap |
| `endpoints` | `ep` | v1 | true | Endpoints |
| `events` | `ev` | v1 | true | Event |
| `limitranges` | `limits` | v1 | true | LimitRange |
| `namespaces` | `ns` | v1 | false | Namespace |
| `nodes` | `no` | v1 | false | Node |
| `persistentvolumeclaims` | `pvc` | v1 | true | PersistentVolumeClaim |
| `persistentvolumes` | `pv` | v1 | false | PersistentVolume |
| `pods` | `po` | v1 | true | Pod |
| `podtemplates` | | v1 | true | PodTemplate |
| `replicationcontrollers` | `rc` | v1 | true | ReplicationController |
| `resourcequotas` | `quota` | v1 | true | ResourceQuota |
| `secrets` | | v1 | true | Secret |
| `serviceaccounts` | `sa` | v1 | true | ServiceAccount |
| `services` | `svc` | v1 | true | Service |
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io/v1 | false | MutatingWebhookConfiguration |
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io/v1 | false | ValidatingWebhookConfiguration |
| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io/v1 | false | CustomResourceDefinition |
| `apiservices` | | apiregistration.k8s.io/v1 | false | APIService |
| `controllerrevisions` | | apps/v1 | true | ControllerRevision |
| `daemonsets` | `ds` | apps/v1 | true | DaemonSet |
| `deployments` | `deploy` | apps/v1 | true | Deployment |
| `replicasets` | `rs` | apps/v1 | true | ReplicaSet |
| `statefulsets` | `sts` | apps/v1 | true | StatefulSet |
| `tokenreviews` | | authentication.k8s.io/v1 | false | TokenReview |
| `localsubjectaccessreviews` | | authorization.k8s.io/v1 | true | LocalSubjectAccessReview |
| `selfsubjectaccessreviews` | | authorization.k8s.io/v1 | false | SelfSubjectAccessReview |
| `selfsubjectrulesreviews` | | authorization.k8s.io/v1 | false | SelfSubjectRulesReview |
| `subjectaccessreviews` | | authorization.k8s.io/v1 | false | SubjectAccessReview |
| `horizontalpodautoscalers` | `hpa` | autoscaling/v2 | true | HorizontalPodAutoscaler |
| `cronjobs` | `cj` | batch/v1 | true | CronJob |
| `jobs` | | batch/v1 | true | Job |
| `certificatesigningrequests` | `csr` | certificates.k8s.io/v1 | false | CertificateSigningRequest |
| `leases` | | coordination.k8s.io/v1 | true | Lease |
| `endpointslices` | | discovery.k8s.io/v1 | true | EndpointSlice |
| `events` | `ev` | events.k8s.io/v1 | true | Event |
| `flowschemas` | | flowcontrol.apiserver.k8s.io/v1beta2 | false | FlowSchema |
| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io/v1beta2 | false | PriorityLevelConfiguration |
| `ingressclasses` | | networking.k8s.io/v1 | false | IngressClass |
| `ingresses` | `ing` | networking.k8s.io/v1 | true | Ingress |
| `networkpolicies` | `netpol` | networking.k8s.io/v1 | true | NetworkPolicy |
| `runtimeclasses` | | node.k8s.io/v1 | false | RuntimeClass |
| `poddisruptionbudgets` | `pdb` | policy/v1 | true | PodDisruptionBudget |
| `podsecuritypolicies` | `psp` | policy/v1beta1 | false | PodSecurityPolicy |
| `clusterrolebindings` | | rbac.authorization.k8s.io/v1 | false | ClusterRoleBinding |
| `clusterroles` | | rbac.authorization.k8s.io/v1 | false | ClusterRole |
| `rolebindings` | | rbac.authorization.k8s.io/v1 | true | RoleBinding |
| `roles` | | rbac.authorization.k8s.io/v1 | true | Role |
| `priorityclasses` | `pc` | scheduling.k8s.io/v1 | false | PriorityClass |
| `csidrivers` | | storage.k8s.io/v1 | false | CSIDriver |
| `csinodes` | | storage.k8s.io/v1 | false | CSINode |
| `csistoragecapacities` | | storage.k8s.io/v1 | true | CSIStorageCapacity |
| `storageclasses` | `sc` | storage.k8s.io/v1 | false | StorageClass |
| `volumeattachments` | | storage.k8s.io/v1 | false | VolumeAttachment |
## 出力オプション

10
content/ja/docs/reference/networking/_index.md Normal file
View File

@ -0,0 +1,10 @@
---
title: ネットワーキングのリファレンス
content_type: reference
weight: 85
---
<!-- overview -->
このセクションでは、Kubernetesネットワーキングの詳細を提供します。
<!-- body -->

36
content/ja/docs/reference/networking/ports-and-protocols.md Normal file
View File

@ -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サーバのデフォルトポートにリクエストをルーティングする方法もあります。

82
content/ja/docs/reference/node/kubelet-checkpoint-api.md Normal file
View File

@ -0,0 +1,82 @@
---
content_type: "reference"
title: KubeletチェックポイントAPI
weight: 10
---
{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
コンテナのチェックポイントは実行中のコンテナのステートフルコピーを作成するための機能です。
コンテナのステートフルコピーがあると、デバックや類似の目的のために別のコンピューターに移動させることができます。
チェックポイントコンテナデータを復元可能なコンピューターに移動させる場合、その復元したコンテナは、チェックポイントが作成された正確に同じ地点で実行が再開されます。
保存したデータを検査することも可能です。
ただし、検査を行うための適したツールを保持している必要があります。
コンテナのチェックポイントを作成することで、セキュリティ影響が発生する場合があります。
通常、チェックポイントはチェックポイントされたコンテナ内のすべてのプロセスのすべてのメモリーページを含んでいます。
メモリー内で使用された全てがローカルディスク上で利用できるようになることを意味しています。
これはすべてのプライベートデータを含んでおり、もしかしたら暗号化に使用した鍵も含まれているかもしれません。
基礎となるCRI実装(そのノード上のコンテナランタイム)は、`root`ユーザーのみがアクセス可能なチェックポイントアーカイブを作成するべきです。
チェックポイントアーカイブが他のシステムに転送された場合、全てのメモリーページがチェックポイントアーカイブのオーナーによって読み取れるようになることを覚えておくことが重要です。
## 操作方法 {#operations}
### `post` 指定したコンテナのチェックポイント {#post-checkpoint}
指定したPodから指定したコンテナのチェックポイントを作成するようにkubeletに指示します。
kubeletチェックポイントインターフェイスへのアクセスの制御方法についての詳細な情報は、[Kubelet authentication/authorization reference](/docs/reference/access-authn-authz/kubelet-authn-authz)を参照してください。
kubeletは基礎となる{{<glossary_tooltip term_id="cri" text="CRI">}}実装にチェックポイントをリクエストします。
チェックポイントリクエストでは、kubeletが`checkpoint-<podFullName>-<containerName>-<timestamp>.tar`のようなチェックポイントアーカイブの名前を指定します。
併せて、(`--root-dir`で定義される)rootディレクトリ配下の`checkpoints`ディレクトリに、チェックポイントアーカイブを保存することをリクエストします。
デフォルトは`/var/lib/kubelet/checkpoints`です。
チェックポイントアーカイブは _tar_ フォーマットであり、[`tar`](https://pubs.opengroup.org/onlinepubs/7908799/xcu/tar.html)の実装を使用して一覧表示できます。
アーカイブの内容は、基礎となるCRI実装(ノード上のコンテナランタイム)に依存します。
#### HTTPリクエスト {#post-checkpoint-request}
POST /checkpoint/{namespace}/{pod}/{container}
#### パラメーター {#post-checkpoint-params}
- **namespace** (*パス内*): string, 必須項目
{{< glossary_tooltip term_id="namespace" >}}
- **pod** (*パス内*): string, 必須項目
{{< glossary_tooltip term_id="pod" >}}
- **container** (*パス内*): string, 必須項目
{{< glossary_tooltip term_id="container" >}}
- **timeout** (*クエリ内*): integer
チェックポイントの作成が終了するまで待機する秒単位のタイムアウト。
ゼロまたはタイムアウトが指定されていない場合、デフォルトは{{<glossary_tooltip term_id="cri" text="CRI">}}タイムアウトの値が使用されます。
チェックポイント作成時間はコンテナの使用メモリーに直接依存します。
コンテナの使用メモリーが多いほど、対応するチェックポイントを作成するために必要な時間が長くなります。
#### レスポンス {#post-checkpoint-response}
200: OK
401: Unauthorized
404: Not Found (`ContainerCheckpoint`フィーチャーゲートが無効の場合)
404: Not Found (指定した`namespace`や`pod`、`container`が見つからない場合)
500: Internal Server Error (CRI実装でチェックポイント中にエラーが発生した場合(詳細はエラーメッセージを参照))
500: Internal Server Error (CRI実装がチェックポイントCRI APIを実装していない場合(詳細はエラーメッセージを参照))
{{< comment >}}
TODO: CRI実装がチェックポイントや復元の機能を持つ場合のリターンコードについてさらなる情報を追加すること。
このTODOは、CRI実装が新しいContainerCheckpoint CRI APIコールを実装するために、Kubernetesの変更をマージすることを必要とするため、リリース前には修正できません。
これを修正するためには1.25リリースの後を待つ必要があります。
{{< /comment >}}

2
content/ja/docs/setup/best-practices/certificates.md
View File

@ -1,7 +1,7 @@
---
title: PKI証明書とその要件
content_type: concept
weight: 40
weight: 50
---
<!-- overview -->

2
content/ja/docs/setup/best-practices/cluster-large.md
View File

@ -1,6 +1,6 @@
---
title: 大規模クラスターの構築
weight: 20
weight: 10
---

2
content/ja/docs/setup/best-practices/multiple-zones.md
View File

@ -1,6 +1,6 @@
---
title: 複数のゾーンで動かす
weight: 10
weight: 20
content_type: concept
---

4
content/ja/docs/setup/production-environment/on-premises-vm/_index.md
View File

@ -1,4 +0,0 @@
---
title: オンプレミスVM
weight: 40
---

118
content/ja/docs/setup/production-environment/on-premises-vm/cloudstack.md
View File

@ -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/))

25
content/ja/docs/setup/production-environment/on-premises-vm/dcos.md
View File

@ -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)にあります。

68
content/ja/docs/setup/production-environment/on-premises-vm/ovirt.md
View File

@ -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.
[![Screencast](https://img.youtube.com/vi/JyyST4ZKne8/0.jpg)](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))

45
content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -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}

4
content/ja/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
View File

@ -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は以下の二つのコマンドを実行します。

4
content/ja/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
View File

@ -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)

53
content/ja/docs/tasks/administer-cluster/coredns.md
View File

@ -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/)を参照してください。

2
content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
View File

@ -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`を実行してノードに参加します

6
content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
View File

@ -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
```

6
content/ja/docs/tasks/service-catalog/_index.md
View File

@ -1,6 +0,0 @@
---
title: "サービスカタログ"
description: サービスカタログ拡張APIをインストールする
weight: 150
---

118
content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md
View File

@ -1,118 +0,0 @@
---
title: Helmを使用したサービスカタログのインストール
content_type: task
---
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="サービスカタログは" >}}
[Helm](https://helm.sh/)を使用してKubernetesクラスターにサービスカタログをインストールします。手順の最新情報は[kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md)リポジトリーを参照してください。
## {{% heading "prerequisites" %}}
* [サービスカタログ](/docs/concepts/extend-kubernetes/service-catalog/)の基本概念を理解してください。
* サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。
* KubernetesクラスターのクラスターDNSを有効化する必要があります。
* クラウド上のKubernetesクラスター、または{{< glossary_tooltip text="Minikube" term_id="minikube" >}}を使用している場合、クラスターDNSはすでに有効化されています。
* `hack/local-up-cluster.sh`を使用している場合は、環境変数`KUBE_ENABLE_CLUSTER_DNS`が設定されていることを確認し、インストールスクリプトを実行してください。
* [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。
* v2.7.0以降の[Helm](https://helm.sh/)をインストールしてください。
* [Helm install instructions](https://helm.sh/docs/intro/install/)を参考にしてください。
* 上記のバージョンのHelmをすでにインストールしている場合は、`helm init`を実行し、HelmのサーバーサイドコンポーネントであるTillerをインストールしてください。
<!-- steps -->
## Helmリポジトリーにサービスカタログを追加
Helmをインストールし、以下のコマンドを実行することでローカルマシンに*service-catalog*のHelmリポジトリーを追加します。
```shell
helm repo add svc-cat https://kubernetes-sigs.github.io/service-catalog
```
以下のコマンドを実行し、インストールに成功していることを確認します。
```shell
helm search service-catalog
```
インストールが成功していれば、出力は以下のようになります:
```
NAME CHART VERSION APP VERSION DESCRIPTION
svc-cat/catalog 0.2.1 service-catalog API server and controller-manager helm chart
svc-cat/catalog-v0.2 0.2.2 service-catalog API server and controller-manager helm chart
```
## RBACの有効化
KubernetesクラスターのRBACを有効化することで、Tiller Podに`cluster-admin`アクセスを持たせます。
v0.25以前のMinikubeを使用している場合は、明示的にRBACを有効化して起動する必要があります:
```shell
minikube start --extra-config=apiserver.Authorization.Mode=RBAC
```
v0.26以降のMinikubeを使用している場合は、以下のコマンドを実行してください。
```shell
minikube start
```
v0.26以降のMinikubeを使用している場合、`--extra-config`を指定しないでください。
このフラグは--extra-config=apiserver.authorization-modeを指定するものに変更されており、現在MinikubeではデフォルトでRBACが有効化されています。
古いフラグを指定すると、スタートコマンドが応答しなくなることがあります。
`hack/local-up-cluster.sh`を使用している場合、環境変数`AUTHORIZATION_MODE`を以下の値に設定してください:
```
AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
```
`helm init`は、デフォルトで`kube-system`のnamespaceにTiller Podをインストールし、Tillerは`default`のServiceAccountを使用するように設定されています。
{{< note >}}
`helm init`を実行する際に`--tiller-namespace`または`--service-account`のフラグを使用する場合、以下のコマンドの`--serviceaccount`フラグには適切なnamespaceとServiceAccountを指定する必要があります。
{{< /note >}}
Tillerに`cluster-admin`アクセスを設定する場合:
```shell
kubectl create clusterrolebinding tiller-cluster-admin \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:default
```
## Kubernetesクラスターにサービスカタログをインストール
以下のコマンドを使用して、Helmリポジトリーのrootからサービスカタログをインストールします:
{{< tabs name="helm-versions" >}}
{{% tab name="Helm バージョン3" %}}
```shell
helm install catalog svc-cat/catalog --namespace catalog
```
{{% /tab %}}
{{% tab name="Helm バージョン2" %}}
```shell
helm install svc-cat/catalog --name catalog --namespace catalog
```
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
* [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog)

68
content/ja/docs/tasks/service-catalog/install-service-catalog-using-sc.md
View File

@ -1,68 +0,0 @@
---
title: SCを使用したサービスカタログのインストール
content_type: task
---
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="サービスカタログは" >}}
GCPの[Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)ツールを使うと、Kubernetesクラスター上にサービスカタログを簡単にインストール・アンインストールして、Google Cloudのプロジェクトに紐付けることもできます。
サービスカタログ自体は、Google Cloudだけではなく、どのような種類のマネージドサービスでも動作します。
## {{% heading "prerequisites" %}}
* [サービスカタログ](/docs/concepts/extend-kubernetes/service-catalog/)の基本概念を理解してください。
* [Go 1.6+](https://golang.org/dl/)をインストールして、`GOPATH`を設定してください。
* SSLに関するファイルを生成するために必要な[cfssl](https://github.com/cloudflare/cfssl)ツールをインストールしてください。
* サービスカタログを使用するには、Kubernetesクラスターのバージョンが1.7以降である必要があります。
* [kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)を参考に、v1.7以降のkubectlをインストールし、設定を行ってください。
* サービスカタログをインストールするためには、kubectlのユーザーが*cluster-admin*ロールにバインドされている必要があります。正しくバインドされていることを確認するには、次のコマンドを実行します。
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
<!-- steps -->
## ローカル環境に`sc`をインストールする
インストーラーは、ローカルのコンピューター上で`sc`と呼ばれるCLIツールとして実行します。
`go get`を使用してインストールします。
```shell
go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
```
これで、`sc`が`GOPATH/bin`ディレクトリー内にインストールされたはずです。
## Kubernetesクラスターにサービスカタログをインストールする
まず、すべての依存関係がインストールされていることを確認します。次のコマンドを実行してください。
```shell
sc check
```
チェックが成功したら、次のように表示されるはずです。
```
Dependency check passed. You are good to go.
```
次に、バックアップに使用したい`storageclass`を指定して、installコマンドを実行します。
```shell
sc install --etcd-backup-storageclass "standard"
```
## サービスカタログのアンインストール
Kubernetesクラスターからサービスカタログをアンインストールしたい場合は、`sc`ツールを使って次のコマンドを実行します。
```shell
sc uninstall
```
## {{% heading "whatsnext" %}}
* [サービスブローカーのサンプル](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)を読む。
* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog)プロジェクトを探索する。

2
content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html
View File

@ -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>

205
content/ja/docs/tutorials/services/pods-and-endpoint-termination-flow.md Normal file
View File

@ -0,0 +1,205 @@
---
title: Podとそのエンドポイントの終了動作を探る
content_type: tutorial
weight: 60
---
<!-- overview -->
[アプリケーションをServiceに接続する](/docs/tutorials/services/connect-applications-service/)で概略を示したステップに従ってアプリケーションをServiceに接続すると、ネットワーク上で公開され、継続的に実行されて、複製されたアプリケーションが得られます。
このチュートリアルでは、Podを終了する流れを見て、gracefulな(猶予のある)接続ドレインを実装する手法を模索するための手助けをします。
<!-- body -->
## Podの終了手続きとそのエンドポイント
アップグレードやスケールダウンのために、Podを終了しなければならない場面はままあります。
アプリケーションの可用性を高めるために、適切なアクティブ接続ドレインを実装することは重要でしょう。
このチュートリアルでは概念のデモンストレーションのために、シンプルなnginx Webサーバーを例として、対応するエンドポイントの状態に関連したPodの終了および削除の流れを説明します。
<!-- body -->
## エンドポイント終了の流れの例
以下は、[Podの終了](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)ドキュメントに記載されている流れの例です。
1つの`nginx`レプリカを含むDeployment(純粋にデモンストレーション目的です)とServiceがあるとします:
{{< codenew file="service/pod-with-graceful-termination.yaml" >}}
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 120 # 非常に長い猶予期間
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
lifecycle:
preStop:
exec:
# 実際の活動終了はterminationGracePeriodSecondsまでかかる可能性がある。
# この例においては、少なくともterminationGracePeriodSecondsの間は待機し、
# 120秒経過すると、コンテナは強制終了される。
# この間ずっとnginxはリクエストを処理し続けていることに注意。
command: [
"/bin/sh", "-c", "sleep 180"
]
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
```
PodとServiceが実行中になったら、関連付けられたEndpointSliceの名前を得られます:
```shell
kubectl get endpointslice
```
この出力は以下のようなものになります:
```none
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
nginx-service-6tjbr IPv4 80 10.12.1.199,10.12.1.201 22m
```
状態からわかるように、1つのエンドポイントが登録されていることが確認できます:
```shell
kubectl get endpointslices -o json -l kubernetes.io/service-name=nginx-service
```
この出力は以下のようなものになります:
```none
{
"addressType": "IPv4",
"apiVersion": "discovery.k8s.io/v1",
"endpoints": [
{
"addresses": [
"10.12.1.201"
],
"conditions": {
"ready": true,
"serving": true,
"terminating": false
```
では、Podを終了し、そのPodがgracefulな終了期間設定を守って終了されていることを確認してみましょう:
```shell
kubectl delete pod nginx-deployment-7768647bf9-b4b9s
```
全Podについて調べます:
```shell
kubectl get pods
```
この出力は以下のようなものになります:
```none
NAME READY STATUS RESTARTS AGE
nginx-deployment-7768647bf9-b4b9s 1/1 Terminating 0 4m1s
nginx-deployment-7768647bf9-rkxlw 1/1 Running 0 8s
```
新しいPodがスケジュールされたことを見てとれます。
新しいPodのために新しいエンドポイントが作成される間、古いエンドポイントは終了中の状態のまま残っています:
```shell
kubectl get endpointslice -o json nginx-service-6tjbr
```
この出力は以下のようなものになります:
```none
{
"addressType": "IPv4",
"apiVersion": "discovery.k8s.io/v1",
"endpoints": [
{
"addresses": [
"10.12.1.201"
],
"conditions": {
"ready": false,
"serving": true,
"terminating": true
},
"nodeName": "gke-main-default-pool-dca1511c-d17b",
"targetRef": {
"kind": "Pod",
"name": "nginx-deployment-7768647bf9-b4b9s",
"namespace": "default",
"uid": "66fa831c-7eb2-407f-bd2c-f96dfe841478"
},
"zone": "us-central1-c"
},
{
"addresses": [
"10.12.1.202"
],
"conditions": {
"ready": true,
"serving": true,
"terminating": false
},
"nodeName": "gke-main-default-pool-dca1511c-d17b",
"targetRef": {
"kind": "Pod",
"name": "nginx-deployment-7768647bf9-rkxlw",
"namespace": "default",
"uid": "722b1cbe-dcd7-4ed4-8928-4a4d0e2bbe35"
},
"zone": "us-central1-c"
```
これを使うと、終了中のアプリケーションがその状態について、接続ドレイン機能の実装目的でクライアント(ロードバランサーなど)と通信する、ということが可能です。
これらのクライアントではエンドポイントの終了を検出し、そのための特別なロジックを実装できます。
Kubernetesでは、終了中のエンドポイントの`ready`状態は全て`false`にセットされます。
これは後方互換性のために必要な措置で、既存のロードバランサーは通常のトラフィックにはそれを使用しません。
Podの終了時にトラフィックのドレインが必要な場合、実際に準備できているかは`serving`状態として調べられます。
Podが削除される時には、古いエンドポイントも削除されます。
## {{% heading "whatsnext" %}}
* [アプリケーションをServiceに接続する](/docs/tutorials/services/connect-applications-service/)方法を学びます。
* [Serviceを利用したクラスター内のアプリケーションへのアクセス](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)を学びます。
* [Serviceを使用してフロントエンドをバックエンドに接続する](/ja/docs/tasks/access-application-cluster/connecting-frontend-backend/)を学びます。
* [外部ロードバランサーの作成](/docs/tasks/access-application-cluster/create-external-load-balancer/)を学びます。

1
content/ja/docs/tutorials/services/source-ip.md
View File

@ -2,6 +2,7 @@
title: 送信元IPを使用する
content_type: tutorial
min-kubernetes-server-version: v1.5
weight: 40
---
<!-- overview -->

32
content/ja/examples/service/pod-with-graceful-termination.yaml Normal file
View File

@ -0,0 +1,32 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 120 # 非常に長い猶予期間
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
lifecycle:
preStop:
exec:
# 実際の活動終了はterminationGracePeriodSecondsまでかかる可能性がある。
# この例においては、少なくともterminationGracePeriodSecondsの間は待機し、
# 120秒経過すると、コンテナは強制的に終了される。
# この間ずっとnginxはリクエストを処理し続けていることに注意。
command: [
"/bin/sh", "-c", "sleep 180"
]

139
content/pt-br/docs/tasks/configure-pod-container/extended-resource.md Normal file
View File

@ -0,0 +1,139 @@
---
title: Atribuindo Recursos Estendidos a um Contêiner
content_type: task
weight: 40
---
<!-- overview -->
{{< feature-state state="stable" >}}
Esta página mostra como atribuir recursos estendidos a um Contêiner.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Antes de fazer este exercício, faça o exercício em
[Anunciar recursos estendidos para um Nó](/docs/tasks/administer-cluster/extended-resource-node/).
Isso configurará um de seus nós para anunciar um recurso de *dongle*.
<!-- steps -->
## Atribua um recurso estendido a um Pod
Para solicitar um recurso estendido, inclua o campo `resources:requests` no seu
manifesto do contêiner. Recursos estendidos são totalmente qualificados
com qualquer domínio fora do `*.kubernetes.io/`. Nomes de recursos estendidos válidos
tem a forma de `example.com/foo`, onde `example.com` é substituído pelo domínio
da sua organização e `foo` é um nome descritivo de recurso.
Aqui está o arquivo de configuração para um pod que possui um contêiner:
{{< codenew file="pods/resource/extended-resource-pod.yaml" >}}
No arquivo de configuração, você pode ver que o contêiner solicita 3 *dongles*.
Crie um Pod:
```shell
kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml
```
Verifique se o pod está em execução:
```shell
kubectl get pod extended-resource-demo
```
Descreva o pod:
```shell
kubectl describe pod extended-resource-demo
```
A saída mostra as solicitações de *dongle*:
```yaml
Limits:
example.com/dongle: 3
Requests:
example.com/dongle: 3
```
## Tente criar um segundo Pod
Aqui está o arquivo de configuração para um pod que possui um contêiner.
O contêiner solicita dois *dongles*.
{{< codenew file="pods/resource/extended-resource-pod-2.yaml" >}}
O Kubernetes não poderá satisfazer o pedido de dois *dongles*, porque o primeiro pod
usou três dos quatro *dongles* disponíveis.
Tente criar um pod:
```shell
kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml
```
Descreva o pod:
```shell
kubectl describe pod extended-resource-demo-2
```
A saída mostra que o pod não pode ser agendado, porque não há nó que tenha
2 *dongles* disponíveis:
```
Conditions:
Type Status
PodScheduled False
...
Events:
...
... Warning FailedScheduling pod (extended-resource-demo-2) failed to fit in any node
fit failure summary on nodes : Insufficient example.com/dongle (1)
```
Veja o status do pod:
```shell
kubectl get pod extended-resource-demo-2
```
A saída mostra que o Pod foi criado, mas não está programado para ser executado em um nó.
Tem um status de pendente:
```yaml
NAME READY STATUS RESTARTS AGE
extended-resource-demo-2 0/1 Pending 0 6m
```
## Limpeza
Exclua os Pods que você criou para este exercício:
```shell
kubectl delete pod extended-resource-demo
kubectl delete pod extended-resource-demo-2
```
## {{% heading "whatsnext" %}}
### Para desenvolvedores de aplicativos
* [Atribuir recursos de memória a contêineres e Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Atribuir recursos de CPU a contêineres e Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
### Para administradores de cluster
* [Anunciar recursos estendidos para um nó](/docs/tasks/administer-cluster/extended-resource-node/)

Some files were not shown because too many files have changed in this diff Show More