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

Merge pull request #48938 from hacktivist123/merged-main-dev-1.32 

Merge main branch into dev-1.32
pull/48987/head
Kubernetes Prow Robot 2024-12-07 06:14:00 +00:00 committed by GitHub
parent 3f720f47a5 9a29b3790b
commit a69f81d6af
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
84 changed files with 1571 additions and 319 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Makefile
View File

@ -56,7 +56,7 @@ non-production-build: module-check ## Build the non-production site, which adds
GOMAXPROCS=1 hugo --cleanDestinationDir --enableGitInfo --environment nonprod
serve: module-check ## Boot the development server.
hugo server --buildFuture --environment development
hugo server --buildDrafts --buildFuture --environment development
docker-image:
@echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"
@ -107,7 +107,7 @@ container-build: module-check
container-serve: module-check ## Boot the development server using container.
$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only \
--mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) \
hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/public --cleanDestinationDir --noBuildLock
hugo server --buildDrafts --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/public --cleanDestinationDir --noBuildLock
test-examples:
scripts/test_examples.sh install

3
OWNERS_ALIASES
View File

@ -133,8 +133,11 @@ aliases:
- Okabe-Junya
sig-docs-ja-reviews: # PR reviews for Japanese content
- atoato88
- b1gb4by
- bells17
- inductor
- kakts
- nasa9084
- Okabe-Junya
- t-inu
sig-docs-ko-owners: # Admins for Korean content

72
content/en/blog/_posts/2024-11-11-memory-manager-moves-to-ga/index.md Normal file
View File

@ -0,0 +1,72 @@
---
layout: blog
title: "Kubernetes v1.32: Memory Manager Goes GA"
date: 2024-11-11
slug: memory-manager-goes-ga
author: >
[Talor Itzhak](https://github.com/Tal-or) (Red Hat)
draft: true
---
With Kubernetes 1.32, the memory manager has officially graduated to General Availability (GA),
marking a significant milestone in the journey toward efficient and predictable memory allocation for containerized applications.
Since Kubernetes v1.22, where it graduated to beta, the memory manager has proved itself reliable, stable and a good complementary feature for the
[CPU Manager](/docs/tasks/administer-cluster/cpu-management-policies/).
As part of kubelet's workload admission process,
the memory manager provides topology hints
to optimize memory allocation and alignment.
This enables users to allocate exclusive
memory for Pods in the [Guaranteed](/docs/concepts/workloads/pods/pod-qos/#guaranteed) QoS class.
More details about the process can be found in the memory manager goes to beta [blog](/blog/2021/08/11/kubernetes-1-22-feature-memory-manager-moves-to-beta/).
Most of the changes introduced since the Beta are bug fixes, internal refactoring and
observability improvements, such as metrics and better logging.
## Observability improvements
As part of the effort
to increase the observability of memory manager, new metrics have been added
to provide some statistics on memory allocation patterns.
* **memory_manager_pinning_requests_total** -
tracks the number of times the pod spec required the memory manager to pin memory pages.
* **memory_manager_pinning_errors_total** -
tracks the number of times the pod spec required the memory manager
to pin memory pages, but the allocation failed.
## Improving memory manager reliability and consistency
The kubelet does not guarantee pod ordering
when admitting pods after a restart or reboot.
In certain edge cases, this behavior could cause
the memory manager to reject some pods,
and in more extreme cases, it may cause kubelet to fail upon restart.
Previously, the beta implementation lacked certain checks and logic to prevent
these issues.
To stabilize the memory manager for general availability (GA) readiness,
small but critical refinements have been
made to the algorithm, improving its robustness and handling of edge cases.
## Future development
There is more to come for the future of Topology Manager in general,
and memory manager in particular.
Notably, ongoing efforts are underway
to extend [memory manager support to Windows](https://github.com/kubernetes/kubernetes/pull/128560),
enabling CPU and memory affinity on a Windows operating system.
## Getting involved
This feature is driven by the [SIG Node](https://github.com/Kubernetes/community/blob/master/sig-node/README.md) community.
Please join us to connect with the community
and share your ideas and feedback around the above feature and
beyond.
We look forward to hearing from you!

93
content/en/blog/_posts/2024-12-11-api-streaming/index.md Normal file
View File

@ -0,0 +1,93 @@
---
layout: blog
title: 'Enhancing Kubernetes API Server Efficiency with API Streaming'
date: 2024-12-11
draft: true
slug: kube-apiserver-api-streaming
author: >
Stefan Schimanski (Upbound),
Wojciech Tyczynski (Google),
Lukasz Szaszkiewicz (Red Hat)
---
Managing Kubernetes clusters efficiently is critical, especially as their size is growing.
A significant challenge with large clusters is the memory overhead caused by **list** requests.
In the existing implementation, the kube-apiserver processes **list** requests by assembling the entire response in-memory before transmitting any data to the client.
But what if the response body is substantial, say hundreds of megabytes? Additionally, imagine a scenario where multiple **list** requests flood in simultaneously, perhaps after a brief network outage.
While [API Priority and Fairness](/docs/concepts/cluster-administration/flow-control) has proven to reasonably protect kube-apiserver from CPU overload, its impact is visibly smaller for memory protection.
This can be explained by the differing nature of resource consumption by a single API request - the CPU usage at any given time is capped by a constant, whereas memory, being uncompressible, can grow proportionally with the number of processed objects and is unbounded.
This situation poses a genuine risk, potentially overwhelming and crashing any kube-apiserver within seconds due to out-of-memory (OOM) conditions. To better visualize the issue, let's consider the below graph.
{{< figure src="kube-apiserver-memory_usage.png" alt="Monitoring graph showing kube-apiserver memory usage" >}}
The graph shows the memory usage of a kube-apiserver during a synthetic test.
(see the [synthetic test](#the-synthetic-test) section for more details).
The results clearly show that increasing the number of informers significantly boosts the server's memory consumption.
Notably, at approximately 16:40, the server crashed when serving only 16 informers.
## Why does kube-apiserver allocate so much memory for list requests?
Our investigation revealed that this substantial memory allocation occurs because the server before sending the first byte to the client must:
* fetch data from the database,
* deserialize the data from its stored format,
* and finally construct the final response by converting and serializing the data into a client requested format
This sequence results in significant temporary memory consumption.
The actual usage depends on many factors like the page size, applied filters (e.g. label selectors), query parameters, and sizes of individual objects.
Unfortunately, neither [API Priority and Fairness](/docs/concepts/cluster-administration/flow-control) nor Golang's garbage collection or Golang memory limits can prevent the system from exhausting memory under these conditions.
The memory is allocated suddenly and rapidly, and just a few requests can quickly deplete the available memory, leading to resource exhaustion.
Depending on how the API server is run on the node, it might either be killed through OOM by the kernel when exceeding the configured memory limits during these uncontrolled spikes, or if limits are not configured it might have even worse impact on the control plane node.
And worst, after the first API server failure, the same requests will likely hit another control plane node in an HA setup with probably the same impact.
Potentially a situation that is hard to diagnose and hard to recover from.
## Streaming list requests
Today, we're excited to announce a major improvement.
With the graduation of the _watch list_ feature to beta in Kubernetes 1.32, client-go users can opt-in (after explicitly enabling `WatchListClient` feature gate)
to streaming lists by switching from **list** to (a special kind of) **watch** requests.
**Watch** requests are served from the _watch cache_, an in-memory cache designed to improve scalability of read operations.
By streaming each item individually instead of returning the entire collection, the new method maintains constant memory overhead.
The API server is bound by the maximum allowed size of an object in etcd plus a few additional allocations.
This approach drastically reduces the temporary memory usage compared to traditional **list** requests, ensuring a more efficient and stable system,
especially in clusters with a large number of objects of a given type or large average object sizes where despite paging memory consumption used to be high.
Building on the insight gained from the synthetic test (see the [synthetic test](#the-synthetic-test), we developed an automated performance test to systematically evaluate the impact of the _watch list_ feature.
This test replicates the same scenario, generating a large number of Secrets with a large payload, and scaling the number of informers to simulate heavy **list** request patterns.
The automated test is executed periodically to monitor memory usage of the server with the feature enabled and disabled.
The results showed significant improvements with the _watch list_ feature enabled.
With the feature turned on, the kube-apiserver’s memory consumption stabilized at approximately **2 GB**.
By contrast, with the feature disabled, memory usage increased to approximately **20GB**, a **10x** increase!
These results confirm the effectiveness of the new streaming API, which reduces the temporary memory footprint.
## Enabling API Streaming for your component
Upgrade to Kubernetes 1.32. Make sure your cluster uses etcd in version 3.4.31+ or 3.5.13+.
Change your client software to use watch lists. If your client code is written in Golang, you'll want to enable `WatchListClient` for client-go.
For details on enabling that feature, read [Introducing Feature Gates to Client-Go: Enhancing Flexibility and Control](/blog/2024/08/12/feature-gates-in-client-go).
## What's next?
In Kubernetes 1.32, the feature is enabled in kube-controller-manager by default despite its beta state.
This will eventually be expanded to other core components like kube-scheduler or kubelet; once the feature becomes generally available, if not earlier.
Other 3rd-party components are encouraged to opt-in to the feature during the beta phase, especially when they are at risk of accessing a large number of resources or kinds with potentially large object sizes.
For the time being, [API Priority and Fairness](/docs/concepts/cluster-administration/flow-control) assigns a reasonable small cost to **list** requests.
This is necessary to allow enough parallelism for the average case where **list** requests are cheap enough.
But it does not match the spiky exceptional situation of many and large objects.
Once the majority of the Kubernetes ecosystem has switched to _watch list_, the **list** cost estimation can be changed to larger values without risking degraded performance in the average case,
and with that increasing the protection against this kind of requests that can still hit the API server in the future.
## The synthetic test
In order to reproduce the issue, we conducted a manual test to understand the impact of **list** requests on kube-apiserver memory usage.
In the test, we created 400 Secrets, each containing 1 MB of data, and used informers to retrieve all Secrets.
The results were alarming, only 16 informers were needed to cause the test server to run out of memory and crash, demonstrating how quickly memory consumption can grow under such conditions.
Special shout out to [@deads2k](https://github.com/deads2k) for his help in shaping this feature.

BIN
content/en/blog/_posts/2024-12-11-api-streaming/kube-apiserver-memory_usage.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 75 KiB

382
content/en/blog/_posts/2024-12-11-volume-group-snapshot-beta.md Normal file
View File

@ -0,0 +1,382 @@
---
layout: blog
title: "Kubernetes 1.32: Moving Volume Group Snapshots to Beta"
date: 2024-12-11
slug: kubernetes-1-32-volume-group-snapshot-beta
draft: true
author: >
Xing Yang (VMware by Broadcom)
---
Volume group snapshots were [introduced](/blog/2023/05/08/kubernetes-1-27-volume-group-snapshot-alpha/)
as an Alpha feature with the Kubernetes 1.27 release.
The recent release of Kubernetes v1.32 moved that support to **beta**.
The support for volume group snapshots relies on a set of
[extension APIs for group snapshots](https://kubernetes-csi.github.io/docs/group-snapshot-restore-feature.html#volume-group-snapshot-apis).
These APIs allow users to take crash consistent snapshots for a set of volumes.
Behind the scenes, Kubernetes uses a label selector to group multiple PersistentVolumeClaims
for snapshotting.
A key aim is to allow you restore that set of snapshots to new volumes and
recover your workload based on a crash consistent recovery point.
This new feature is only supported for [CSI](https://kubernetes-csi.github.io/docs/) volume drivers.
## An overview of volume group snapshots
Some storage systems provide the ability to create a crash consistent snapshot of
multiple volumes. A group snapshot represents _copies_ made from multiple volumes, that
are taken at the same point-in-time. A group snapshot can be used either to rehydrate
new volumes (pre-populated with the snapshot data) or to restore existing volumes to
a previous state (represented by the snapshots).
## Why add volume group snapshots to Kubernetes?
The Kubernetes volume plugin system already provides a powerful abstraction that
automates the provisioning, attaching, mounting, resizing, and snapshotting of block
and file storage.
Underpinning all these features is the Kubernetes goal of workload portability:
Kubernetes aims to create an abstraction layer between distributed applications and
underlying clusters so that applications can be agnostic to the specifics of the
cluster they run on and application deployment requires no cluster specific knowledge.
There was already a [VolumeSnapshot](/docs/concepts/storage/volume-snapshots/) API
that provides the ability to take a snapshot of a persistent volume to protect against
data loss or data corruption. However, there are other snapshotting functionalities
not covered by the VolumeSnapshot API.
Some storage systems support consistent group snapshots that allow a snapshot to be
taken from multiple volumes at the same point-in-time to achieve write order consistency.
This can be useful for applications that contain multiple volumes. For example,
an application may have data stored in one volume and logs stored in another volume.
If snapshots for the data volume and the logs volume are taken at different times,
the application will not be consistent and will not function properly if it is restored
from those snapshots when a disaster strikes.
It is true that you can quiesce the application first, take an individual snapshot from
each volume that is part of the application one after the other, and then unquiesce the
application after all the individual snapshots are taken. This way, you would get
application consistent snapshots.
However, sometimes the application quiesce can be so time consuming that you want to do it less frequently,
or it may not be possible to quiesce an application at all.
For example, a user may want to run weekly backups with application quiesce
and nightly backups without application quiesce but with consistent group support which
provides crash consistency across all volumes in the group.
## Kubernetes APIs for volume group snapshots
Kubernetes' support for _volume group snapshots_ relies on three API kinds that
are used
for managing snapshots:
VolumeGroupSnapshot
: Created by a Kubernetes user (or perhaps by your own automation) to request
creation of a volume group snapshot for multiple persistent volume claims.
It contains information about the volume group snapshot operation such as the
timestamp when the volume group snapshot was taken and whether it is ready to use.
The creation and deletion of this object represents a desire to create or delete a
cluster resource (a group snapshot).
VolumeGroupSnapshotContent
: Created by the snapshot controller for a dynamically created VolumeGroupSnapshot.
It contains information about the volume group snapshot including the volume group
snapshot ID.
This object represents a provisioned resource on the cluster (a group snapshot).
The VolumeGroupSnapshotContent object binds to the VolumeGroupSnapshot for which it
was created with a one-to-one mapping.
VolumeGroupSnapshotClass
: Created by cluster administrators to describe how volume group snapshots should be
created, including the driver information, the deletion policy, etc.
These three API kinds are defined as
[CustomResourceDefinitions](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
(CRDs).
These CRDs must be installed in a Kubernetes cluster for a CSI Driver to support
volume group snapshots.
## What components are needed to support volume group snapshots
Volume group snapshots are implemented in the
[external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter) repository.
Implementing volume group snapshots meant adding or changing several components:
* Added new CustomResourceDefinitions for VolumeGroupSnapshot and two supporting APIs.
* Volume group snapshot controller logic is added to the common snapshot controller.
* Adding logic to make CSI calls into the snapshotter sidecar controller.
The volume snapshot controller and CRDs are deployed once per
cluster, while the sidecar is bundled with each CSI driver.
Therefore, it makes sense to deploy the volume snapshot controller and CRDs as a cluster addon.
The Kubernetes project recommends that Kubernetes distributors
bundle and deploy the volume snapshot controller and CRDs as part
of their Kubernetes cluster management process (independent of any CSI Driver).
## What's new in Beta?
* The VolumeGroupSnapshot feature in CSI spec moved to GA in the [v1.11.0 release](https://github.com/container-storage-interface/spec/releases/tag/v1.11.0).
* The snapshot validation webhook was deprecated in external-snapshotter v8.0.0 and it is now removed.
Most of the validation webhook logic was added as validation rules into the CRDs.
Minimum required Kubernetes version is 1.25 for these validation rules.
One thing in the validation webhook not moved to CRDs is the prevention of creating
multiple default volume snapshot classes and multiple default volume group snapshot classes
for the same CSI driver.
With the removal of the validation webhook, an error will still be raised when dynamically
provisioning a VolumeSnapshot or VolumeGroupSnapshot when multiple default volume snapshot
classes or multiple default volume group snapshot classes for the same CSI driver exist.
* The `enable-volumegroup-snapshot` flag in the snapshot-controller and the CSI snapshotter
sidecar has been replaced by a feature gate.
Since VolumeGroupSnapshot is a new API, the feature moves to Beta but the feature gate is
disabled by default.
To use this feature, enable the feature gate by adding the flag `--feature-gates=CSIVolumeGroupSnapshot=true`
when starting the snapshot-controller and the CSI snapshotter sidecar.
* The logic to dynamically create the VolumeGroupSnapshot and its corresponding individual
VolumeSnapshot and VolumeSnapshotContent objects are moved from the CSI snapshotter to the common
snapshot-controller.
New RBAC rules are added to the common snapshot-controller and some RBAC rules are removed from
the CSI snapshotter sidecar accordingly.
## How do I use Kubernetes volume group snapshots
### Creating a new group snapshot with Kubernetes
Once a VolumeGroupSnapshotClass object is defined and you have volumes you want to
snapshot together, you may request a new group snapshot by creating a VolumeGroupSnapshot
object.
The source of the group snapshot specifies whether the underlying group snapshot
should be dynamically created or if a pre-existing VolumeGroupSnapshotContent
should be used.
A pre-existing VolumeGroupSnapshotContent is created by a cluster administrator.
It contains the details of the real volume group snapshot on the storage system which
is available for use by cluster users.
One of the following members in the source of the group snapshot must be set.
* `selector` - a label query over PersistentVolumeClaims that are to be grouped
together for snapshotting. This selector will be used to match the label
added to a PVC.
* `volumeGroupSnapshotContentName` - specifies the name of a pre-existing
VolumeGroupSnapshotContent object representing an existing volume group snapshot.
#### Dynamically provision a group snapshot
In the following example, there are two PVCs.
```console
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
pvc-0 Bound pvc-6e1f7d34-a5c5-4548-b104-01e72c72b9f2 100Mi RWO csi-hostpath-sc <unset> 2m15s
pvc-1 Bound pvc-abc640b3-2cc1-4c56-ad0c-4f0f0e636efa 100Mi RWO csi-hostpath-sc <unset> 2m7s
```
Label the PVCs.
```console
% kubectl label pvc pvc-0 group=myGroup
persistentvolumeclaim/pvc-0 labeled
% kubectl label pvc pvc-1 group=myGroup
persistentvolumeclaim/pvc-1 labeled
```
For dynamic provisioning, a selector must be set so that the snapshot controller can find PVCs
with the matching labels to be snapshotted together.
```yaml
apiVersion: groupsnapshot.storage.k8s.io/v1beta1
kind: VolumeGroupSnapshot
metadata:
name: snapshot-daily-20241217
namespace: demo-namespace
spec:
volumeGroupSnapshotClassName: csi-groupSnapclass
source:
selector:
matchLabels:
group: myGroup
```
In the VolumeGroupSnapshot spec, a user can specify the VolumeGroupSnapshotClass which
has the information about which CSI driver should be used for creating the group snapshot.
A VolumGroupSnapshotClass is required for dynamic provisioning.
```yaml
apiVersion: groupsnapshot.storage.k8s.io/v1beta1
kind: VolumeGroupSnapshotClass
metadata:
name: csi-groupSnapclass
annotations:
kubernetes.io/description: "Example group snapshot class"
driver: example.csi.k8s.io
deletionPolicy: Delete
```
As a result of the volume group snapshot creation, a corresponding VolumeGroupSnapshotContent
object will be created with a volumeGroupSnapshotHandle pointing to a resource on the storage
system.
Two individual volume snapshots will be created as part of the volume group snapshot creation.
```console
NAME READYTOUSE SOURCEPVC RESTORESIZE SNAPSHOTCONTENT AGE
snapshot-0962a745b2bf930bb385b7b50c9b08af471f1a16780726de19429dd9c94eaca0 true pvc-0 100Mi snapcontent-0962a745b2bf930bb385b7b50c9b08af471f1a16780726de19429dd9c94eaca0 16m
snapshot-da577d76bd2106c410616b346b2e72440f6ec7b12a75156263b989192b78caff true pvc-1 100Mi snapcontent-da577d76bd2106c410616b346b2e72440f6ec7b12a75156263b989192b78caff 16m
```
#### Importing an existing group snapshot with Kubernetes
To import a pre-existing volume group snapshot into Kubernetes, you must also import
the corresponding individual volume snapshots.
Identify the individual volume snapshot handles, manually construct a
VolumeSnapshotContent object first, then create a VolumeSnapshot object pointing to
the VolumeSnapshotContent object. Repeat this for every individual volume snapshot.
Then manually create a VolumeGroupSnapshotContent object, specifying the
volumeGroupSnapshotHandle and individual volumeSnapshotHandles already existing
on the storage system.
```yaml
apiVersion: groupsnapshot.storage.k8s.io/v1beta1
kind: VolumeGroupSnapshotContent
metadata:
name: static-group-content
spec:
deletionPolicy: Delete
driver: hostpath.csi.k8s.io
source:
groupSnapshotHandles:
volumeGroupSnapshotHandle: e8779136-a93e-11ef-9549-66940726f2fd
volumeSnapshotHandles:
- e8779147-a93e-11ef-9549-66940726f2fd
- e8783cd0-a93e-11ef-9549-66940726f2fd
volumeGroupSnapshotRef:
name: static-group-snapshot
namespace: demo-namespace
```
After that create a VolumeGroupSnapshot object pointing to the VolumeGroupSnapshotContent
object.
```yaml
apiVersion: groupsnapshot.storage.k8s.io/v1beta1
kind: VolumeGroupSnapshot
metadata:
name: static-group-snapshot
namespace: demo-namespace
spec:
source:
volumeGroupSnapshotContentName: static-group-content
```
### How to use group snapshot for restore in Kubernetes
At restore time, the user can request a new PersistentVolumeClaim to be created from
a VolumeSnapshot object that is part of a VolumeGroupSnapshot. This will trigger
provisioning of a new volume that is pre-populated with data from the specified
snapshot. The user should repeat this until all volumes are created from all the
snapshots that are part of a group snapshot.
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: examplepvc-restored-2024-12-17
namespace: demo-namespace
spec:
storageClassName: example-foo-nearline
dataSource:
name: snapshot-0962a745b2bf930bb385b7b50c9b08af471f1a16780726de19429dd9c94eaca0
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOncePod
resources:
requests:
storage: 100Mi # must be enough storage to fit the existing snapshot
```
## As a storage vendor, how do I add support for group snapshots to my CSI driver?
To implement the volume group snapshot feature, a CSI driver **must**:
* Implement a new group controller service.
* Implement group controller RPCs: `CreateVolumeGroupSnapshot`, `DeleteVolumeGroupSnapshot`, and `GetVolumeGroupSnapshot`.
* Add group controller capability `CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT`.
See the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md)
and the [Kubernetes-CSI Driver Developer Guide](https://kubernetes-csi.github.io/docs/)
for more details.
As mentioned earlier, it is strongly recommended that Kubernetes distributors
bundle and deploy the volume snapshot controller and CRDs as part
of their Kubernetes cluster management process (independent of any CSI Driver).
As part of this recommended deployment process, the Kubernetes team provides a number of
sidecar (helper) containers, including the
[external-snapshotter sidecar container](https://kubernetes-csi.github.io/docs/external-snapshotter.html)
which has been updated to support volume group snapshot.
The external-snapshotter watches the Kubernetes API server for
VolumeGroupSnapshotContent objects, and triggers `CreateVolumeGroupSnapshot` and
`DeleteVolumeGroupSnapshot` operations against a CSI endpoint.
## What are the limitations?
The beta implementation of volume group snapshots for Kubernetes has the following limitations:
* Does not support reverting an existing PVC to an earlier state represented by
a snapshot (only supports provisioning a new volume from a snapshot).
* No application consistency guarantees beyond any guarantees provided by the storage system
(e.g. crash consistency). See this [doc](https://github.com/kubernetes/community/blob/30d06f49fba22273f31b3c616b74cf8745c19b3d/wg-data-protection/data-protection-workflows-white-paper.md#quiesce-and-unquiesce-hooks)
for more discussions on application consistency.
## What’s next?
Depending on feedback and adoption, the Kubernetes project plans to push the volume
group snapshot implementation to general availability (GA) in a future release.
## How can I learn more?
- The [design spec](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/3476-volume-group-snapshot)
for the volume group snapshot feature.
- The [code repository](https://github.com/kubernetes-csi/external-snapshotter) for volume group
snapshot APIs and controller.
- CSI [documentation](https://kubernetes-csi.github.io/docs/) on the group snapshot feature.
## How do I get involved?
This project, like all of Kubernetes, is the result of hard work by many contributors
from diverse backgrounds working together. On behalf of SIG Storage, I would like to
offer a huge thank you to the contributors who stepped up these last few quarters
to help the project reach beta:
* Ben Swartzlander ([bswartz](https://github.com/bswartz))
* Cici Huang ([cici37](https://github.com/cici37))
* Hemant Kumar ([gnufied](https://github.com/gnufied))
* James Defelice ([jdef](https://github.com/jdef))
* Jan Šafránek ([jsafrane](https://github.com/jsafrane))
* Madhu Rajanna ([Madhu-1](https://github.com/Madhu-1))
* Manish M Yathnalli ([manishym](https://github.com/manishym))
* Michelle Au ([msau42](https://github.com/msau42))
* Niels de Vos ([nixpanic](https://github.com/nixpanic))
* Leonardo Cecchi ([leonardoce](https://github.com/leonardoce))
* Rakshith R ([Rakshith-R](https://github.com/Rakshith-R))
* Raunak Shah ([RaunakShah](https://github.com/RaunakShah))
* Saad Ali ([saad-ali](https://github.com/saad-ali))
* Xing Yang ([xing-yang](https://github.com/xing-yang))
* Yati Padia ([yati1998](https://github.com/yati1998))
For those interested in getting involved with the design and development of CSI or
any part of the Kubernetes Storage system, join the
[Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG).
We always welcome new contributors.
We also hold regular [Data Protection Working Group meetings](https://github.com/kubernetes/community/tree/master/wg-data-protection).
New attendees are welcome to join our discussions.

2
content/en/docs/concepts/architecture/cri.md
View File

@ -15,7 +15,7 @@ each Node in your cluster, so that the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} can launch
{{< glossary_tooltip text="Pods" term_id="pod" >}} and their containers.
{{< glossary_definition prepend="The Container Runtime Interface (CRI) is" term_id="container-runtime-interface" length="all" >}}
{{< glossary_definition prepend="The Container Runtime Interface (CRI) is" term_id="cri" length="all" >}}
<!-- body -->

82
content/en/docs/concepts/policy/limit-range.md
View File

@ -11,27 +11,32 @@ weight: 10
<!-- overview -->
By default, containers run with unbounded [compute resources](/docs/concepts/configuration/manage-resources-containers/) on a Kubernetes cluster.
By default, containers run with unbounded
[compute resources](/docs/concepts/configuration/manage-resources-containers/) on a Kubernetes cluster.
Using Kubernetes [resource quotas](/docs/concepts/policy/resource-quotas/),
administrators (also termed _cluster operators_) can restrict consumption and creation
of cluster resources (such as CPU time, memory, and persistent storage) within a specified
{{< glossary_tooltip text="namespace" term_id="namespace" >}}.
Within a namespace, a {{< glossary_tooltip text="Pod" term_id="Pod" >}} can consume as much CPU and memory as is allowed by the ResourceQuotas that apply to that namespace. As a cluster operator, or as a namespace-level administrator, you might also be concerned about making sure that a single object cannot monopolize all available resources within a namespace.
Within a namespace, a {{< glossary_tooltip text="Pod" term_id="Pod" >}} can consume as much CPU and memory as is allowed by the ResourceQuotas that apply to that namespace.
As a cluster operator, or as a namespace-level administrator, you might also be concerned
about making sure that a single object cannot monopolize all available resources within a namespace.
A LimitRange is a policy to constrain the resource allocations (limits and requests) that you can specify for each applicable object kind (such as Pod or {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}) in a namespace.
A LimitRange is a policy to constrain the resource allocations (limits and requests) that you can specify for
each applicable object kind (such as Pod or {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}) in a namespace.
<!-- body -->
A _LimitRange_ provides constraints that can:
- Enforce minimum and maximum compute resources usage per Pod or Container in a namespace.
- Enforce minimum and maximum storage request per {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} in a namespace.
- Enforce minimum and maximum storage request per
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} in a namespace.
- Enforce a ratio between request and limit for a resource in a namespace.
- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.
- Set default request/limit for compute resources in a namespace and automatically
inject them to Containers at runtime.
A LimitRange is enforced in a particular namespace when there is a
LimitRange object in that namespace.
Kubernetes constrains resource allocations to Pods in a particular namespace
whenever there is at least one LimitRange object in that namespace.
The name of a LimitRange object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@ -39,50 +44,69 @@ The name of a LimitRange object must be a valid
## Constraints on resource limits and requests
- The administrator creates a LimitRange in a namespace.
- Users create (or try to create) objects in that namespace, such as Pods or PersistentVolumeClaims.
- First, the `LimitRange` admission controller applies default request and limit values for all Pods (and their containers) that do not set compute resource requirements.
- Second, the `LimitRange` tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any `LimitRange` present in the namespace.
- If you attempt to create or update an object (Pod or PersistentVolumeClaim) that violates a `LimitRange` constraint, your request to the API server will fail with an HTTP status code `403 Forbidden` and a message explaining the constraint that has been violated.
- If you add a `LimitRange` in a namespace that applies to compute-related resources such as
`cpu` and `memory`, you must specify
requests or limits for those values. Otherwise, the system may reject Pod creation.
- `LimitRange` validations occur only at Pod admission stage, not on running Pods.
- Users create (or try to create) objects in that namespace, such as Pods or
PersistentVolumeClaims.
- First, the LimitRange admission controller applies default request and limit values
for all Pods (and their containers) that do not set compute resource requirements.
- Second, the LimitRange tracks usage to ensure it does not exceed resource minimum,
maximum and ratio defined in any LimitRange present in the namespace.
- If you attempt to create or update an object (Pod or PersistentVolumeClaim) that violates
a LimitRange constraint, your request to the API server will fail with anHTTP status
code `403 Forbidden` and a message explaining the constraint that has been violated.
- If you add a LimitRange in a namespace that applies to compute-related resources
such as `cpu` and `memory`, you must specify requests or limits for those values.
Otherwise, the system may reject Pod creation.
- LimitRange validations occur only at Pod admission stage, not on running Pods.
If you add or modify a LimitRange, the Pods that already exist in that namespace
continue unchanged.
- If two or more `LimitRange` objects exist in the namespace, it is not deterministic which default value will be applied.
- If two or more LimitRange objects exist in the namespace, it is not deterministic
which default value will be applied.
## LimitRange and admission checks for Pods
A `LimitRange` does **not** check the consistency of the default values it applies. This means that a default value for the _limit_ that is set by `LimitRange` may be less than the _request_ value specified for the container in the spec that a client submits to the API server. If that happens, the final Pod will not be schedulable.
A LimitRange does **not** check the consistency of the default values it applies.
This means that a default value for the _limit_ that is set by LimitRange may be
less than the _request_ value specified for the container in the spec that a client
submits to the API server. If that happens, the final Pod will not be schedulable.
For example, you define a `LimitRange` with this manifest:
For example, you define a LimitRange with below manifest:
{{< note >}}
The following examples operate within the default namespace of your cluster, as the namespace
parameter is undefined and the LimitRange scope is limited to the namespace level.
This implies that any references or operations within these examples will interact
with elements within the default namespace of your cluster. You can override the
operating namespace by configuring namespace in the `metadata.namespace` field.
{{< /note >}}
{{% code_sample file="concepts/policy/limit-range/problematic-limit-range.yaml" %}}
along with a Pod that declares a CPU resource request of `700m`, but not a limit:
{{% code_sample file="concepts/policy/limit-range/example-conflict-with-limitrange-cpu.yaml" %}}
then that Pod will not be scheduled, failing with an error similar to:
```
Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit
```
If you set both `request` and `limit`, then that new Pod will be scheduled successfully even with the same `LimitRange` in place:
If you set both `request` and `limit`, then that new Pod will be scheduled successfully
even with the same LimitRange in place:
{{% code_sample file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" %}}
## Example resource constraints
Examples of policies that could be created using `LimitRange` are:
Examples of policies that could be created using LimitRange are:
- In a 2 node cluster with a capacity of 8 GiB RAM and 16 cores, constrain Pods in a namespace to request 100m of CPU with a max limit of 500m for CPU and request 200Mi for Memory with a max limit of 600Mi for Memory.
- Define default CPU limit and request to 150m and memory default request to 300Mi for Containers started with no cpu and memory requests in their specs.
- In a 2 node cluster with a capacity of 8 GiB RAM and 16 cores, constrain Pods in a
namespace to request 100m of CPU with a max limit of 500m for CPU and request 200Mi
for Memory with a max limit of 600Mi for Memory.
- Define default CPU limit and request to 150m and memory default request to 300Mi for
Containers started with no cpu and memory requests in their specs.
In the case where the total limits of the namespace is less than the sum of the limits of the Pods/Containers,
there may be contention for resources. In this case, the Containers or Pods will not be created.
In the case where the total limits of the namespace is less than the sum of the limits
of the Pods/Containers, there may be contention for resources. In this case, the
Containers or Pods will not be created.
Neither contention nor changes to a LimitRange will affect already created resources.
@ -97,5 +121,5 @@ For examples on using limits, see:
- [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
- a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) for context and historical information.
Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)
for context and historical information.

2
content/en/docs/concepts/storage/storage-classes.md
View File

@ -248,6 +248,8 @@ Here is an example StorageClass for the AWS EBS CSI driver:
{{% code_sample language="yaml" file="storage/storageclass/storageclass-aws-ebs.yaml" %}}
`tagSpecification`: Tags with this prefix are applied to dynamically provisioned EBS volumes.
### AWS EFS
To configure AWS EFS storage, you can use the out-of-tree [AWS_EFS_CSI_DRIVER](https://github.com/kubernetes-sigs/aws-efs-csi-driver).

2
content/en/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md
View File

@ -13,7 +13,7 @@ stages:
- stage: beta
defaultValue: true
fromVersion: "1.29"
toVersion": "1.30"
toVersion: "1.30"
- stage: stable
defaultValue: true
fromVersion: "1.31"

8
content/en/docs/reference/command-line-tools-reference/feature-gates/new-volume-manager-reconstruction.md
View File

@ -6,13 +6,13 @@ _build:
render: false
stages:
- stage: beta
- stage: alpha
defaultValue: false
fromVersion: "1.27"
toVersion: "1.27"
fromVersion: "1.25"
toVersion: "1.26"
- stage: beta
defaultValue: true
fromVersion: "1.28"
fromVersion: "1.27"
toVersion: "1.29"
- stage: stable
defaultValue: true

4
content/en/docs/reference/command-line-tools-reference/feature-gates/translate-stream-close-websocket-requests.md
View File

@ -6,6 +6,10 @@ _build:
render: false
stages:
- stage: alpha
defaultValue: false
fromVersion: "1.29"
toVersion: "1.29"
- stage: beta
defaultValue: true
fromVersion: "1.30"

5
content/en/docs/reference/config-api/kubeadm-config.v1beta4.md
View File

@ -278,7 +278,7 @@ configuration types to be used during a <code>kubeadm init</code> run.</p>
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">dns</span>:<span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">disabled</span>:<span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">true</span><span style="color:#bbb"> </span><span style="color:#998;font-style:italic"># disable CoreDNS</span><span style="color:#bbb">
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">proxy</span>:<span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">diabled</span>:<span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">true</span><span style="color:#bbb"> </span><span style="color:#998;font-style:italic"># disable kube-proxy</span><span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">disabled</span>:<span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">true</span><span style="color:#bbb"> </span><span style="color:#998;font-style:italic"># disable kube-proxy</span><span style="color:#bbb">
</span><span style="color:#bbb">
</span><span style="color:#bbb"></span>---<span style="color:#bbb">
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">apiVersion</span>:<span style="color:#bbb"> </span>kubelet.config.k8s.io/v1beta1<span style="color:#bbb">
@ -576,8 +576,7 @@ and for kube-proxy, while <code>registry.k8s.io</code> will be used for all the
</td>
<td>
<p><code>encryptionAlgorithm</code> holds the type of asymmetric encryption algorithm used for keys and
certificates. Can be <code>&quot;RSA&quot;</code> (default algorithm, key size is 2048) or <code>&quot;ECDSA&quot;</code> (uses the
P-256 elliptic curve).</p>
certificates. Can be one of <code>&quot;RSA-2048&quot;</code> (default), <code>&quot;RSA-3072&quot;</code>, <code>&quot;RSA-4096&quot;</code> or <code>&quot;ECDSA-P256&quot;</code>.</p>
</td>
</tr>
<tr><td><code>certificateValidityPeriod</code><br/>

22
content/en/docs/reference/glossary/container-runtime-interface.md
View File

@ -1,22 +0,0 @@
---
title: Container Runtime Interface
id: container-runtime-interface
date: 2021-11-24
full_link: /docs/concepts/architecture/cri
short_description: >
The main protocol for the communication between the kubelet and Container Runtime.
aka:
tags:
- cri
---
The main protocol for the communication between the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and Container Runtime.
<!--more-->
The Kubernetes Container Runtime Interface (CRI) defines the main
[gRPC](https://grpc.io) protocol for the communication between the
[node components](/docs/concepts/architecture/#node-components)
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.

22
content/en/docs/reference/glossary/cri.md
View File

@ -1,18 +1,22 @@
---
title: Container runtime interface (CRI)
title: Container Runtime Interface (CRI)
id: cri
date: 2019-03-07
full_link: /docs/concepts/architecture/#container-runtime
date: 2021-11-24
full_link: /docs/concepts/architecture/cri
short_description: >
An API for container runtimes to integrate with kubelet
Protocol for communication between the kubelet and the local container runtime.
aka:
tags:
- fundamental
- fundamental
---
The container runtime interface (CRI) is an API for container runtimes
to integrate with the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} on a node.
The main protocol for the communication between the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and Container Runtime.
<!--more-->
For more information, see the [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) API and specifications.
The Kubernetes Container Runtime Interface (CRI) defines the main
[gRPC](https://grpc.io) protocol for the communication between the
[node components](/docs/concepts/architecture/#node-components)
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.

4
content/en/docs/reference/instrumentation/cri-pod-container-metrics.md
View File

@ -14,7 +14,7 @@ description: >-
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) collects pod and
container metrics via [cAdvisor](https://github.com/google/cadvisor). As an alpha feature,
Kubernetes lets you configure the collection of pod and container
metrics via the {{< glossary_tooltip term_id="container-runtime-interface" text="Container Runtime Interface">}} (CRI). You
metrics via the {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI). You
must enable the `PodAndContainerStatsFromCRI` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and
use a compatible CRI implementation (containerd >= 1.6.0, CRI-O >= 1.23.0) to
use the CRI based collection mechanism.
@ -35,4 +35,4 @@ collection with cAdvisor include:
- It further decouples the kubelet and the container runtime allowing collection of metrics for
container runtimes that don't run processes directly on the host with kubelet where they are
observable by cAdvisor (for example: container runtimes that use virtualization).

2
content/en/docs/reference/instrumentation/node-metrics.md
View File

@ -40,7 +40,7 @@ By default, Kubernetes fetches node summary metrics data using an embedded
[cAdvisor](https://github.com/google/cadvisor) that runs within the kubelet. If you
enable the `PodAndContainerStatsFromCRI` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
in your cluster, and you use a container runtime that supports statistics access via
{{< glossary_tooltip term_id="container-runtime-interface" text="Container Runtime Interface">}} (CRI), then
{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI), then
the kubelet [fetches Pod- and container-level metric data using CRI](/docs/reference/instrumentation/cri-pod-container-metrics), and not via cAdvisor.
## {{% heading "whatsnext" %}}

18
content/en/docs/tasks/manage-kubernetes-objects/storage-version-migration.md
View File

@ -50,9 +50,9 @@ read [enable or disable a Kubernetes API](/docs/tasks/administer-cluster/enable-
- secrets
providers:
- aescbc:
keys:
- name: key1
secret: c2VjcmV0IGlzIHNlY3VyZQ==
keys:
- name: key1
secret: c2VjcmV0IGlzIHNlY3VyZQ==
```
Make sure to enable automatic reload of encryption
@ -77,13 +77,13 @@ read [enable or disable a Kubernetes API](/docs/tasks/administer-cluster/enable-
- secrets
providers:
- aescbc:
keys:
- name: key2
secret: c2VjcmV0IGlzIHNlY3VyZSwgaXMgaXQ/
keys:
- name: key2
secret: c2VjcmV0IGlzIHNlY3VyZSwgaXMgaXQ/
- aescbc:
keys:
- name: key1
secret: c2VjcmV0IGlzIHNlY3VyZQ==
keys:
- name: key1
secret: c2VjcmV0IGlzIHNlY3VyZQ==
```
- To ensure that previously created secret `my-secret` is re-encrypted

9
content/en/docs/tasks/network/extend-service-ip-ranges.md
View File

@ -24,8 +24,9 @@ This document shares how to extend the existing Service IP range assigned to a c
## API
Kubernetes clusters with kube-apiservers that have enabled the `MultiCIDRServiceAllocator`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and the `networking.k8s.io/v1alpha1` API,
will create a new ServiceCIDR object that takes the well-known name `kubernetes`, and that uses an IP address range
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and have the `networking.k8s.io/v1beta1`
API group active,
will create a ServiceCIDR object that takes the well-known name `kubernetes`, and that specifies an IP address range
based on the value of the `--service-cluster-ip-range` command line argument to kube-apiserver.
```sh
@ -94,7 +95,7 @@ that extends or adds new IP address ranges.
```sh
cat <EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1alpha1
apiVersion: networking.k8s.io/v1beta1
kind: ServiceCIDR
metadata:
name: newcidr1
@ -136,7 +137,7 @@ Kubernetes uses a finalizer on the ServiceCIDR to track this dependent relations
kubectl get servicecidr newcidr1 -o yaml
```
```
apiVersion: networking.k8s.io/v1alpha1
apiVersion: networking.k8s.io/v1beta1
kind: ServiceCIDR
metadata:
creationTimestamp: "2023-10-12T15:11:07Z"

2
content/en/examples/storage/storageclass/storageclass-aws-ebs.yaml
View File

@ -16,5 +16,3 @@ allowedTopologies:
- key: topology.ebs.csi.aws.com/zone
values:
- us-east-2c
# `tagSpecification`: Tags with this prefix are applied to dynamically provisioned EBS volumes.

2
content/fr/_index.html
View File

@ -12,7 +12,7 @@ sitemap:
{{% blocks/feature image="flower" %}}
### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/" >}}) est un système open-source permettant d'automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées.
Les conteneurs qui composent une application sont regroupés dans des unités logiques pour en faciliter la gestion et la découverte. Kubernetes s’appuie sur [15 années d’expérience dans la gestion de charges de travail de production (workloads) chez Google](http://queue.acm.org/detail.cfm?id=2898444), associé aux meilleures idées et pratiques de la communauté.
Les conteneurs qui composent une application sont regroupés dans des unités logiques pour en faciliter la gestion et la découverte. Kubernetes s’appuie sur [15 années d’expérience dans la gestion de charges de travail de production (workloads) chez Google](https://queue.acm.org/detail.cfm?id=2898444), associé aux meilleures idées et pratiques de la communauté.
{{% /blocks/feature %}}
{{% blocks/feature image="scalable" %}}

2
content/hi/_index.html
View File

@ -10,7 +10,7 @@ sitemap:
{{% blocks/feature image="flower" %}}
[कुबेरनेट्स]({{< relref "/docs/concepts/overview/_index.md" >}}), जो K8s के रूप में भी जाना जाता है, कंटेनरीकृत एप्लीकेशन के डिप्लॉयमेंट, स्केलिंग और प्रबंधन को स्वचालित करने के लिए एक ओपन-सोर्स सिस्टम है।
यह आसान प्रबंधन और खोज के लिए लॉजिकल इकाइयों में एक एप्लीकेशन बनाने वाले कंटेनरों को समूहित करता है। कुबेरनेट्स [Google में उत्पादन कार्यभार चलाने के 15 वर्षों के अनुभव](http://queue.acm.org/detail.cfm?id=2898444) पर निर्माणित है, जो समुदाय के सर्वोत्तम-नस्लीय विचारों और प्रथाओं के साथ संयुक्त है।
यह आसान प्रबंधन और खोज के लिए लॉजिकल इकाइयों में एक एप्लीकेशन बनाने वाले कंटेनरों को समूहित करता है। कुबेरनेट्स [Google में उत्पादन कार्यभार चलाने के 15 वर्षों के अनुभव](https://queue.acm.org/detail.cfm?id=2898444) पर निर्माणित है, जो समुदाय के सर्वोत्तम-नस्लीय विचारों और प्रथाओं के साथ संयुक्त है।
{{% /blocks/feature %}}
{{% blocks/feature image="scalable" %}}

2
content/id/community/static/cncf-code-of-conduct.md
View File

@ -23,7 +23,7 @@ Kode etik ini berlaku baik di dalam ruang proyek maupun di ruang publik ketika s
Contoh perilaku kasar, melecehkan, atau tidak dapat diterima di Kubernetes dapat dilaporkan dengan menghubungi [Komite Kode Etik Kubernetes](https://git.k8s.io/community/committee-code-of-conduct) melalui <conduct@kubernetes.io>. Untuk proyek lain, silakan hubungi pengelola proyek CNCF atau mediator kami, Mishi Choudhary <mishi@linux.com>.
Kode Etik ini diadaptasi dari Covenant Contributor
<http://contributor-covenant.org>, versi 1.2.0, tersedia di
<https://contributor-covenant.org>, versi 1.2.0, tersedia di
<https://contributor-covenant.org/version/1/2/0/>
### Pedoman Perilaku Acara CNCF

1
content/id/docs/concepts/cluster-administration/addons.md
View File

@ -42,7 +42,6 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk
## Visualisasi &amp; Kontrol
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) merupakan antarmuka web dasbor untuk Kubernetes.
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) merupakan perangkat untuk visualisasi grafis dari kontainer, pod, *service* dll milikmu. Gunakan bersama dengan [akun Weave Cloud](https://cloud.weave.works/) atau *host* UI-mu sendiri.
## *Add-ons* Terdeprekasi

2
content/it/_index.html
View File

@ -10,7 +10,7 @@ cid: home
{{% blocks/feature image="flower" %}}
### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) è un software open-source per l'automazione del deployment, scalabilità, e gestione di applicativi in containers.
K8s raggruppa i containers che compongono gli applicativi in unità logiche per semplificare la gestione e la visibilità. Kubernetes si basa su [15 anni di esperienza di esecuzione di workload in produzione presso Google](http://queue.acm.org/detail.cfm?id=2898444), combinata con le migliori idee e pratiche dalla community.
K8s raggruppa i containers che compongono gli applicativi in unità logiche per semplificare la gestione e la visibilità. Kubernetes si basa su [15 anni di esperienza di esecuzione di workload in produzione presso Google](https://queue.acm.org/detail.cfm?id=2898444), combinata con le migliori idee e pratiche dalla community.
{{% /blocks/feature %}}
{{% blocks/feature image="scalable" %}}

1
content/it/docs/concepts/cluster-administration/addons.md
View File

@ -41,7 +41,6 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine
## Visualization & Control
[Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) è un'interfaccia web dashboard per Kubernetes.
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) è uno strumento per la visualizzazione grafica di contenitori, pod, servizi, ecc. Utilizzalo in combinazione con un [Weave Cloud account](https://cloud.weave.works/) o ospitali tu stesso.
## Legacy Add-ons

8
content/ja/blog/_posts/2024-10-28-k8s-upstream-training-japan-spotlight/index.md
View File

@ -90,11 +90,11 @@ PipeCDのKubernetesサポートに関する新機能の開発の他に、コミ
**Junya:** なぜKubernetes Upstream Trainingに参加しようと思いましたか？
**Yoshiki**: 参加した当時はまだ学生時代でした。その時はEKSを軽く触っていただけでしたが、なんか難しいけどかっこいいな！とk8s自体に興味をふんわりと持っている状態でした。当時は本当にOSSは雲の上の存在で、ましてやk8sのupstreamの開発なんてすごすぎて手の届かない存在だと思ってました。OSSにはもともと興味があったのですが、何から始めればいいのかわからなかったです。そんな時にkubernetes upstream trainingの存在を知って、k8sへのコントリビューションに挑戦してみようと思いました。
**Yoshiki:** 参加した当時はまだ学生時代でした。その時はEKSを軽く触っていただけでしたが、なんか難しいけどかっこいいな！とk8s自体に興味をふんわりと持っている状態でした。当時は本当にOSSは雲の上の存在で、ましてやk8sのupstreamの開発なんてすごすぎて手の届かない存在だと思ってました。OSSにはもともと興味があったのですが、何から始めればいいのかわからなかったです。そんな時にkubernetes upstream trainingの存在を知って、k8sへのコントリビューションに挑戦してみようと思いました。
**Junya:**参加してみて、どのような感想を持ちましたか？
**Junya:** 参加してみて、どのような感想を持ちましたか？
**Yoshiki:**OSSに関わるコミュニティがどんなものかを知るキッカケとしてとてもありがたいなと感じました。当時は英語力もそこまで高くなく、一次情報を見に行くことは自分にとって大きなハードルでした。
**Yoshiki:** OSSに関わるコミュニティがどんなものかを知るキッカケとしてとてもありがたいなと感じました。当時は英語力もそこまで高くなく、一次情報を見に行くことは自分にとって大きなハードルでした。
k8sは非常に大きなプロジェクトなので、コントリビューションに必要なことだけでなく、全体像があまりわかっていない状態でした。upstream trainingでは、コミュニティの構造を日本語で説明していただいたうえで、コントリビューションを実際に行うところまで一通り経験することができました。そこで、一次情報に関する情報を共有してくださったおかげで、その後自分なりにエントリーポイントとして利用しつつ追加で調査するキッカケづくりになって非常にありがたかったです。この経験から、一次情報を整理しつつ見る習慣を身につける必要があるなと思い、気になったものはGitHubのissueやdocsを漁りに見に行くようになりました。結果として、今はk8sのコントリビューション自体は行っていませんが、ここでの経験が別プロジェクトにコントリビューションするための素地となって役立っています。
**Junya:** 現在はどのような領域でコントリビューションを行っていますか？別のプロジェクトとはどのようなものでしょうか？
@ -103,7 +103,7 @@ k8sは非常に大きなプロジェクトなので、コントリビューシ
**Junya:** PipeCDチームの中ではどのような役割ですか？
**Yoshiki**: 私はチーム内ではk8s周りの機能改善、開発をフルタイムの仕事として行っています。社内向けにPipeCDをSaaSとして提供しているため、そのサポートの一環として、新規機能の追加や既存機能の改善などを行うことが主な目的です。さらに、コード以外のコントリビューションとしては、PipeCD自体のコミュニティ拡大に向けて各種登壇であったり、コミュニティミーティングの運営を行っているところです。
**Yoshiki:** 私はチーム内ではk8s周りの機能改善、開発をフルタイムの仕事として行っています。社内向けにPipeCDをSaaSとして提供しているため、そのサポートの一環として、新規機能の追加や既存機能の改善などを行うことが主な目的です。さらに、コード以外のコントリビューションとしては、PipeCD自体のコミュニティ拡大に向けて各種登壇であったり、コミュニティミーティングの運営を行っているところです。
**Junya:** Kubernetes周りの機能改善や開発とは具体的にどのようなものですか？

23
content/ja/docs/reference/glossary/network-policy.md Normal file
View File

@ -0,0 +1,23 @@
---
title: ネットワークポリシー
id: network-policy
date: 2018-04-12
full_link: /ja/docs/concepts/services-networking/network-policies/
short_description: >
一連のPodがPod同士やその他のネットワークエンドポイントとどのように通信することを許可されるかを定める規定。
aka:
tags:
- networking
- architecture
- extension
- core-object
---
一連のPodがPod同士やその他のネットワークエンドポイントとどのように通信することを許可されるかを定める規定。
<!--more-->
ネットワークポリシーは、どのPodが互いに接続を許可されるか、どのNamespaceが通信を許可されるか、そしてより具体的には各ポリシーを適用するポート番号を宣言的に設定することができます。
`NetworkPolicy`リソースはラベルを使用してPodを選択し、選択されたPodに対して許可するトラフィックを指定するルールを定義します。
ネットワークポリシーはネットワークプロバイダーが提供するネットワークプラグインによって実装されます。
ネットワークポリシーを実装するためのコントローラーを使用せずにネットワークリソースを作成しても効果がないことに注意してください。

18
content/ja/docs/reference/glossary/probe.md Normal file
View File

@ -0,0 +1,18 @@
---
title: Probe
id: probe
date: 2023-03-21
full_link: /ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
short_description: >
Pod内のコンテナに対して、kubeletが定期的に実行するチェック。
tags:
- tool
---
Pod内で実行中のコンテナに対して、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}が定期的に実行するチェック。
コンテナの状態と正常性を定義し、コンテナのライフサイクルを通知します。
<!--more-->
さらなる情報は[コンテナのProbe](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照して下さい。

18
content/ja/docs/reference/glossary/rbac.md Normal file
View File

@ -0,0 +1,18 @@
---
title: RBAC (Role-Based Access Control)
id: rbac
date: 2018-04-12
full_link: /ja/docs/reference/access-authn-authz/rbac/
short_description: >
管理者がKubernetes APIを通じてアクセスポリシーを動的に設定できるようにし、認可の判断を管理します。
aka:
tags:
- security
- fundamental
---
管理者が{{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}}を通じてアクセスポリシーを動的に設定できるようにし、認可の判断を管理します。
<!--more-->
RBACは、権限を含む*Role*と、Roleで定義された権限を一連のユーザーに付与する*RoleBinding*を使用します。

22
content/ja/docs/reference/glossary/replica.md Normal file
View File

@ -0,0 +1,22 @@
---
title: Replica
id: replica
date: 2023-06-11
full_link:
short_description: >
ReplicaはPodのコピーであり、同一インスタンスを維持することで、可用性、スケーラビリティ、耐障害性を保証します。
aka:
tags:
- fundamental
- workload
---
{{< glossary_tooltip text="Pod" term_id="pod" >}}のコピーまたは複製、または一連のPodです。
Replicaは複数Podの同一インスタンスを維持することで、高い可用性、スケーラビリティ、耐障害性を保証します。
<!--more-->
Replicaは望まれるアプリケーションの状態と信頼性を達成するために、Kubernetesで広く使われています。
これにより、クラスター内の複数ノード間に渡るワークロードのスケーリングと分散を可能にしています。
DeploymentやReplicaSetでReplicaの数を定義することで、Kubernetesは指定の数のインスタンスが実行されていることを保証し、必要に応じて自動的にその数を調整します。
Replicaを管理することで、Kubernetesクラスター内での効率的なロードバランスやローリングアップデート、自己修復を可能にしています。

20
content/ja/docs/reference/glossary/security-context.md Normal file
View File

@ -0,0 +1,20 @@
---
title: Security Context
id: security-context
date: 2018-04-12
full_link: /ja/docs/tasks/configure-pod-container/security-context/
short_description: >
`securityContext`フィールドは、Podまたはコンテナの権限とアクセス制御の設定を定義します。
aka:
tags:
- security
---
`securityContext`フィールドは、{{< glossary_tooltip text="Pod" term_id="pod" >}}または{{< glossary_tooltip text="コンテナ" term_id="container" >}}の権限とアクセス制御の設定を定義します。
<!--more-->
`securityContext`では、プロセスを実行するユーザー、プロセスを実行するグループ、および権限の設定を定義できます。
また、セキュリティポリシー(例：SELinux、AppArmor、seccomp)も設定できます。
`PodSpec.securityContext`の設定内容は、Pod内のすべてのコンテナに適用されます。

9
content/pl/_index.html
View File

@ -12,7 +12,7 @@ sitemap:
{{% blocks/feature image="flower" %}}
[Kubernetes]({{< relref "/docs/concepts/overview/" >}}), znany też jako K8s, to otwarte oprogramowanie służące do automatyzacji procesów uruchamiania, skalowania i zarządzania aplikacjami w kontenerach.
Kubernetes grupuje kontenery, które są częścią jednej aplikacji, w logicznie grupy, ułatwiając ich odnajdywanie i zarządzanie nimi. Korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](http://queue.acm.org/detail.cfm?id=2898444) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.
Kubernetes grupuje kontenery, które są częścią jednej aplikacji, w logicznie grupy, ułatwiając ich odnajdywanie i zarządzanie nimi. Korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](https://queue.acm.org/detail.cfm?id=2898444) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.
{{% /blocks/feature %}}
{{% blocks/feature image="scalable" %}}
@ -47,12 +47,15 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Obejrzyj wideo</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/" button id="desktopKCButton">Weź udział w KubeCon + CloudNativeCon Europe 19-22.03.2024</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">Weź udział w KubeCon + CloudNativeCon North America 12-15.11.2024</a>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-india/" button id="desktopKCButton">Weź udział w KubeCon + CloudNativeCon India 11-12.12.2024</a>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america-2024/" button id="desktopKCButton">Weź udział w KubeCon + CloudNativeCon North America 12-15.11.2024</a>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/" button id="desktopKCButton">Weź udział w KubeCon + CloudNativeCon Europe 1-4.4.2025</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

2
content/ru/docs/concepts/containers/_index.md
View File

@ -30,4 +30,4 @@ no_list: true
## {{% heading "whatsnext" %}}
* Раздел об [образах контейнеров](/docs/concepts/containers/images/).
* Раздел о [Pod'ах](/docs/concepts/workloads/pods/).
* Раздел о [Подах](/ru/docs/concepts/workloads/pods/).

2
content/ru/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -222,7 +222,7 @@ CronJob отвечает только за создание заданий (Jobs
## {{% heading "whatsnext" %}}
* Ознакомьтесь с [Подами](/docs/concepts/workloads/pods/) и
* Ознакомьтесь с [Подами](/ru/docs/concepts/workloads/pods/) и
[Заданиями](/docs/concepts/workloads/controllers/job/) — двумя концепциями, на которые опираются CronJobs.
* Ознакомьтесь с подробным [форматом](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)
полей CronJob `.spec.schedule`.

397
content/ru/docs/concepts/workloads/pods/_index.md Normal file
View File

@ -0,0 +1,397 @@
---
title: "Поды"
api_metadata:
- apiVersion: "v1"
kind: "Под"
content_type: concept
weight: 10
no_list: true
---
<!-- overview -->
_Поды_ (_Pods_) — это самые маленькие развертываемые вычислительные единицы, которые можно создавать и которыми
можно управлять в Kubernetes.
_Под_ (от англ. «pod», что означает стаю китов или гороховый стручок) — это группа из одного или нескольких
{{< glossary_tooltip text="контейнеров" term_id="container" >}} с общими хранилищами и сетевыми ресурсами,
а также спецификация для запуска контейнеров.
Содержимое Пода всегда находится в одном месте, имеет совместное расписание и выполняется в общем
контексте. Под по своей сути представляется специфическим для приложения "логическим хостом": он содержит
один или несколько контейнеров приложений, которые относительно тесно связаны между собой.
Приложения вне облачной инфраструктуры, выполняемые на одной физической или виртуальной машине,
аналогичны облачным приложениям, выполняемым на одном логическом хосте.
Помимо контейнеров приложений Под может содержать
{{< glossary_tooltip text="init-контейнеры" term_id="init-container" >}}, которые запускаются при
старте Пода. Вы также можете внедрить
{{< glossary_tooltip text="эфемерные контейнеры" term_id="ephemeral-container" >}}
для отладки запущенного Пода.
<!-- body -->
## Что такое Под? {#what-is-a-pod}
{{< note >}}
Вам нужно установить [исполняемую среду контейнеров](/docs/setup/production-environment/container-runtimes/)
на каждый узел кластера, чтобы Поды могли там работать.
{{< /note >}}
Общий контекст Пода - это набор пространств имен Linux, cgroups и, возможно, других аспектов изоляции -
всего того, что изолирует и {{< glossary_tooltip text="контейнер" term_id="container" >}}. Внутри контекста Пода
отдельные приложения могут иметь дополнительные субизоляции.
Под похож на набор контейнеров с общими пространствами имен и общими томами файловой системы.
Поды в кластере Kubernetes используются двумя основными способами:
* **Поды, которые запускают один контейнер**. Модель "один контейнер на Под" является наиболее
распространенным вариантом использования Kubernetes; в этом случае вы можете рассматривать Под как
обертку вокруг одного контейнера; Kubernetes управляет Подами, а не непосредственно контейнерами.
* **Поды, которые запускают несколько контейнеров, обязанных работать вместе**. Под может инкапсулировать
приложение, состоящее из [нескольких расположенных рядом контейнеров](#how-pods-manage-multiple-containers),
которые тесно связаны между собой и нуждаются в совместном использовании ресурсов. Эти расположенные
рядом контейнеры образуют единое целое.
Группировка нескольких совместно расположенных и совместно управляемых контейнеров в одном Поде - это
довольно сложный кейс. Этот паттерн следует использовать только в особых случаях, когда
ваши контейнеры тесно связаны между собой.
Запускать несколько контейнеров для обеспечения репликации (устойчивости
или производительности) не требуется. Если вам нужно несколько реплик, смотрите раздел
[Ресурсы рабочей нагрузки](/ru/docs/concepts/workloads/controllers/).
## Использование Подов {#using-pods}
Ниже приведен пример Пода, состоящего из контейнера, в котором запущен образ `nginx:1.14.2`.
{{% code_sample file="pods/simple-pod.yaml" %}}
Чтобы создать описанный выше Под, выполните следующую команду:
```shell
kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
```
Поды обычно создаются не напрямую, а при создании ресурсов рабочей нагрузки.
Дополнительные сведения о том, как использовать Поды с ресурсами рабочей нагрузки, см. в разделе
[Работа с Подами](#working-with-pods).
### Ресурсы рабочей нагрузки для управления подами {#workload-resources-for-managing-pods}
Обычно не нужно создавать Поды напрямую, даже если это одиночный Под. Вместо этого они создаются
с помощью ресурсов рабочей нагрузки, таких как
{{< glossary_tooltip text="Deployment" term_id="deployment" >}} или
{{< glossary_tooltip text="Job" term_id="job" >}}. Если для Подов важно хранить состояние (т.е. они stateful),
рассмотрите ресурс {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}.
Каждый Под предназначен для запуска одного экземпляра приложения. Если вы хотите горизонтально
масштабировать приложение (обеспечить больше ресурсов за счет запуска большего количества экземпляров),
следует использовать несколько Подов, по одному для каждого экземпляра. В Kubernetes это обычно называется
_репликацией_. Реплицированные Поды обычно создаются и управляются как группа ресурсом рабочей нагрузки и его
{{< glossary_tooltip text="контроллером" term_id="controller" >}}.
Подробнее о том, как Kubernetes использует ресурсы рабочей нагрузки и их контроллеры для масштабирования и
автовосстановления приложений, читайте в разделе [Поды и контроллеры](#pods-and-controllers).
Поды изначально предоставляют два вида общих ресурсов для входящих в них контейнеров: [сеть](#pod-networking)
и [хранилище](#pod-storage).
## Работа с Подами {#working-with-pods}
Создание отдельных Подов в Kubernetes — даже одиночных Подов — случается редко. Это связано
с тем, что Поды разработаны как относительно эфемерные, одноразовые сущности. Когда Под создается
(непосредственно вами или косвенно {{< glossary_tooltip text="контроллером" term_id="controller" >}}),
новый Под планируется к запуску на одном из {{< glossary_tooltip text="узлов" term_id="node" >}} кластера.
Под остается на этом узле до тех пор, пока Под не завершит выполнение, объект Пода не будет удален,
Под не будет вытеснен из-за нехватки ресурсов, или узел не выйдет из строя.
{{< note >}}
Не следует путать перезапуск контейнера в Поде с перезапуском Пода. Под - это не процесс, а среда для
запуска контейнера(ов). Под существует до тех пор, пока не будет удален.
{{< /note >}}
Имя Пода должно быть действительным значением
[имени поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), но это
может привести к неожиданным результатам для имени хоста Пода. Для лучшей совместимости имя должно
соответствовать более строгим правилам для
[имен меток DNS](/ru/docs/concepts/overview/working-with-objects/names#dns-label-names).
### ОС Пода {#pod-os}
{{< feature-state state="stable" for_k8s_version="v1.25" >}}
В поле `.spec.os.name` следует установить значение `windows` или `linux`, чтобы указать ОС, на которой
будет работать под. На данный момент Kubernetes поддерживает только эти две операционные системы.
В будущем этот список может быть расширен.
В Kubernetes v{{< skew currentVersion >}} значение `.spec.os.name` не влияет на то, как
{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} выбирает узел для запуска
Пода. В любом кластере, где на работающих узлах используются разные операционные системы, необходимо
установить правильный лейбл [kubernetes.io/os](/docs/reference/labels-annotations-taints/#kubernetes-io-os)
для каждого узла и определить поды с `nodeSelector`, указывающим на лейбл операционной системы.
Планировщик kube-scheduler распределяет поды по узлам, основываясь ещё и на других критериях,
поэтому выбор подходящего узла с ОС, которая нужна контейнерам данного пода, не всегда будет
успешным. [Pod Security Standards](/docs/concepts/security/pod-security-standards/) также используют
это поле, чтобы избежать применения политик, которые не относятся к данной операционной системе.
### Поды и контроллеры {#pods-and-controllers}
Вы можете использовать ресурсы рабочей нагрузки для создания и управления несколькими Подами. Контроллер
ресурса управляет репликацией и развертыванием, а также автоматическим восстановлением в случае отказа
Подов. Например, если узел выходит из строя, контроллер замечает, что Поды на этом узле перестали работать,
и создает замену Подов. Планировщик размещает заменяющий Под на здоровый узел.
Вот несколько примеров ресурсов рабочей нагрузки, которые управляют одним или несколькими Подами:
* {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
### Шаблоны Подов {#pod-templates}
Контроллеры {{< glossary_tooltip text="ресурсов рабочей нагрузки" term_id="workload" >}} создают Поды
из _шаблонов Подов_ и управляют этими Подами в соответствии с вашими потребностями.
PodTemplates - это спецификации для создания Подов, которые включаются в ресурсы рабочей нагрузки,
такие как [Deployments](/docs/concepts/workloads/controllers/deployment/),
[Jobs](/docs/concepts/workloads/controllers/job/) и
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/).
Каждый контроллер для ресурса рабочей нагрузки использует шаблон `PodTemplate` внутри объекта рабочей
нагрузки для создания реальных Подов. `PodTemplate` является частью желаемого состояния того ресурса
рабочей нагрузки, который вы использовали для запуска своего приложения.
При создании Пода вы можете включить в шаблон Пода
[переменные окружения](/docs/tasks/inject-data-application/define-environment-variable-container/)
для контейнеров, запускаемых в Поде.
Приведенный ниже пример представляет собой манифест для простого Job с `template`, который запускает
один контейнер. Контейнер в этом Поде печатает сообщение, затем приостанавливается.
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: hello
spec:
template:
# Это шаблон Пода
spec:
containers:
- name: hello
image: busybox:1.28
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
restartPolicy: OnFailure
# Здесь шаблон Пода заканчивается
```
Изменение шаблона пода или переход на новый шаблон пода не оказывает прямого влияния на уже существующие
Поды. Если вы измените pod template для ресурса рабочей нагрузки, этот ресурс должен будет создать замену
Подам, использующим обновленный шаблон.
Например, контроллер StatefulSet следит за тем, чтобы запущенные Поды соответствовали текущему pod template
для каждого объекта StatefulSet. Если вы отредактируете StatefulSet, чтобы изменить его pod template,
StatefulSet начнет создавать новые Поды на основе обновленного шаблона. В конце концов, все старые
Поды заменяются новыми, и обновление завершается.
Каждый ресурс рабочей нагрузки реализует свои собственные правила обработки изменений в шаблонах Подов.
Если вы хотите узнать больше о StatefulSet, ознакомьтесь с
[Updating StatefulSets](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets)
в учебном пособии "StatefulSet Basics".
На Узлах {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} не знает про шаблоны Подов и связанные с ними обновления Подов,
никак не управляет ими; эти подробности для него абстрагированы. Такая абстракция и
разделение интересов упрощает семантику системы и делает возможным расширение поведения кластера без
изменения существующего кода.
## Обновление и замена Пода {#pod-update-and-replacement}
Как уже говорилось в предыдущем разделе, при изменении шаблона Пода для ресурса рабочей нагрузки
контроллер создает новые Поды на основе обновленного шаблона вместо того, чтобы обновлять или
патчить существующие Поды.
Kubernetes не мешает управлять Подами напрямую. Можно обновить некоторые поля уже работающего Пода
прямо «на месте». Однако операции обновления Пода, такие как
[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) и
[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core),
имеют некоторые ограничения:
- Большинство метаданных о Поде неизменяемы. Например, вы не можете изменить поля `namespace`, `name`,
`uid` или `creationTimestamp`; поле `generation` уникально. Оно принимает только те обновления,
которые увеличивают текущее значение поля.
- Если установлено значение `metadata.deletionTimestamp`, то в список `metadata.finalizers` не может
быть добавлена новая запись.
- Обновления Пода не могут изменять поля, кроме `spec.containers[*].image`,
`spec.initContainers[*].image`, `spec.activeDeadlineSeconds` или `spec.tolerations`.
Для `spec.tolerations` можно только добавлять новые записи.
- При обновлении поля `spec.activeDeadlineSeconds` допускается два типа обновлений:
1. установка положительного значения для неназначенного поля;
2. обновление поля с положительного числа на меньшее неотрицательное число.
## Совместное использование ресурсов и коммуникация {#resource-sharing-and-communication}
Поды позволяют обмениваться данными и взаимодействовать между входящими в них контейнерами.
### Хранение в Подах {#pod-storage}
Под может определять набор общих {{< glossary_tooltip text="томов" term_id="volume" >}} хранения.
Все контейнеры в Поде могут получить доступ к общим томам, что позволяет им обмениваться данными.
Тома также позволяют сохранять данные в Поде в случае необходимости перезапуска одного из контейнеров.
Дополнительные сведения о том, как Kubernetes реализует общее хранилище и делает его доступным для
Подов, см. в разделе [Storage](/docs/concepts/storage/).
### Сеть в Подах {#pod-networking}
Каждому Поду назначается уникальный IP-адрес для каждого семейства адресов. Каждый контейнер в Поде
разделяет сетевое пространство имен, включая IP-адрес и сетевые порты. Внутри Пода (и **только** в нем)
контейнеры, входящие в Под, могут взаимодействовать друг с другом, используя `localhost`. Когда
контейнеры в Поде общаются с сущностями *за пределами Пода*, они должны координировать использование
общих сетевых ресурсов (например, портов). Внутри Пода контейнеры имеют общий IP-адрес и порт, и могут
найти друг друга через localhost. Контейнеры в Поде также могут взаимодействовать друг с другом,
используя стандартные межпроцессные взаимодействия, такие как семафоры SystemV или общая память POSIX.
Контейнеры в разных Подах имеют разные IP-адреса и не могут взаимодействовать по IPC на уровне ОС без
специальной настройки. Контейнеры, которые хотят взаимодействовать с контейнером, запущенным в другом
Поде, могут использовать IP-сети для коммуникации.
Контейнеры в Поде воспринимают системное имя хоста как то же самое, что и сконфигурированный `name`
для Пода. Подробнее об этом в разделе
[Сеть в кластере](/ru/docs/concepts/cluster-administration/networking/).
## Привилегированный режим для контейнеров {#privileged-mode-for-containers}
{{< note >}}
Для того чтобы эта настройка была актуальной, ваша
{{< glossary_tooltip text="иcполняемая среда контейнеров" term_id="container-runtime" >}} должна
поддерживать концепцию привилегированного контейнера.
{{< /note >}}
Любой контейнер в поде может работать в привилегированном режиме, чтобы использовать
административные возможности операционной системы, которые иначе были бы недоступны. Это доступно
как для Windows, так и для Linux.
### Привилегированные контейнеры в Linux {#linux-privileged-containers}
В Linux любой контейнер в Поде может включить привилегированный режим с помощью флага `privileged`
(Linux) в [контексте безопасности](/docs/tasks/configure-pod-container/security-context/)
спецификации контейнера. Это полезно для контейнеров, которые хотят использовать возможности
администрирования операционной системы, такие как работа с сетевым стеком или доступ к аппаратным
устройствам.
### Привилегированные контейнеры в Windows {#windows-privileged-containers}
{{< feature-state for_k8s_version="v1.26" state="stable" >}}
В Windows вы можете создать
[Windows HostProcess pod](/docs/tasks/configure-pod-container/create-hostprocess-pod), установив
флаг `windowsOptions.hostProcess` в контексте безопасности спецификации пода. Все контейнеры в этих
подах должны работать как контейнеры Windows HostProcess. HostProcess-поды запускаются
непосредственно на хосте и могут использоваться для выполнения административных задач, как это
делается с привилегированными контейнерами Linux.
## Статические Поды {#static-pods}
_Статические Поды_ управляются непосредственно демоном kubelet на определенном узле, без наблюдения
со стороны {{< glossary_tooltip text="API-сервера" term_id="kube-apiserver" >}}. В то время как
большинство Подов управляются управляющим слоем (Control Plane) (например,
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}), для статических Подов kubelet
непосредственно контролирует каждый статический Под (и перезапускает его в случае сбоя).
Статические Поды всегда привязаны к одному {{< glossary_tooltip term_id="kubelet" >}} на определенном
узле. Основное применение статических Подов - запуск самодостаточного управляющего слоя (Control Plane):
другими словами, использование kubelet для контроля отдельных
[компонентов управляющего слоя](/ru/docs/concepts/overview/components/#control-plane-components).
Kubelet автоматически пытается создать {{< glossary_tooltip text="зеркальный Под" term_id="mirror-pod" >}}
на API-сервере Kubernetes для каждого статического Пода. Это означает, что запущенные на узле Поды
видны на API-сервере, но управлять ими оттуда нельзя. Дополнительную информацию см. в руководстве
[Create static Pods](/docs/tasks/configure-pod-container/static-pod).
{{< note >}}
В `spec` статического Пода нельзя ссылаться на другие объекты API (например,
{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}},
{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}},
{{< glossary_tooltip text="Secret" term_id="secret" >}} и т.д.).
{{< /note >}}
## Поды с несколькими контейнерами {#how-pods-manage-multiple-containers}
Поды предназначены для поддержки нескольких взаимодействующих процессов (в виде контейнеров), которые
образуют единое целое. Контейнеры в Поде автоматически размещаются и планируются на одной и той же
физической или виртуальной машине в кластере. Контейнеры могут совместно использовать ресурсы и
зависимости, взаимодействовать друг с другом и координировать, когда и как они завершаются.
<!--intentionally repeats some text from earlier in the page, with more detail -->
Поды в кластере Kubernetes используются двумя основными способами:
* **Поды, которые запускают один контейнер**. Модель "один контейнер на Под" является наиболее
распространенным вариантом использования Kubernetes; в этом случае вы можете рассматривать Под как
обертку вокруг одного контейнера; Kubernetes управляет Подами, а не непосредственно контейнерами.
* **Поды, которые запускают несколько контейнеров, обязанных работать вместе**. Под может инкапсулировать
приложение, состоящее из нескольких расположенных рядом контейнеров, которые тесно связаны между
собой и нуждаются в совместном использовании ресурсов. Эти совместно расположенные контейнеры образуют
единую целостную единицу обслуживания - например, один контейнер обслуживает данные, хранящиеся в
общем томе, а отдельный {{< glossary_tooltip text="sidecar-контейнер" term_id="sidecar-container" >}}
обновляет эти файлы. Под объединяет эти контейнеры, ресурсы хранения и эфемерный сетевой идентификатор
в единое целое.
Например, у вас может быть контейнер, выполняющий роль веб-сервера для файлов на общем томе, и
отдельный [sidecar-контейнер](/docs/concepts/workloads/pods/sidecar-containers/), который обновляет эти
файлы из удаленного источника, как показано на следующей схеме:
{{< figure src="/images/docs/pod.svg" alt="Pod creation diagram" class="diagram-medium" >}}
В некоторых Подах есть {{< glossary_tooltip text="init-контейнеры" term_id="init-container" >}},
а также {{< glossary_tooltip text="app-контейнеры" term_id="app-container" >}}. По умолчанию
init-контейнеры запускаются и завершаются до запуска app-контейнеров.
У вас также могут быть [sidecar-контейнеры](/docs/concepts/workloads/pods/sidecar-containers/),
которые реализуют вспомогательные сервисы для основного приложения Пода (например, service mesh).
{{< feature-state for_k8s_version="v1.29" state="beta" >}}
[Feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SidecarContainers` включен по умолчанию и
позволяет указать
`restartPolicy: Always` для init-контейнеров. Установка политики перезапуска `Always` гарантирует,
что контейнеры, для которых вы ее задали, будут рассматриваться как _sidecar-контейнеры_, которые
будут работать в течение всего времени существования Пода. Контейнеры, которые вы явно определили как
sidecar-контейнеры, запускаются раньше Пода основного приложения и остаются запущенными до тех пор,
пока Под не будет выключен.
## Probes контейнера {#container-probes}
_Probe_ - это диагностика, периодически выполняемая kubelet для контейнера. Для проведения диагностики
kubelet может вызывать различные действия:
- `ExecAction` (выполняется с помощью иcполняемой среды контейнеров)
- `TCPSocketAction` (проверку производит kubelet)
- `HTTPGetAction` (проверку производит kubelet)
Подробнее о [probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) вы можете прочитать
в документации Pod Lifecycle.
## {{% heading "whatsnext" %}}
* Ознакомьтесь с [жизненным циклом Пода](/docs/concepts/workloads/pods/pod-lifecycle/).
* Ознакомьтесь с [RuntimeClass](/docs/concepts/containers/runtime-class/) и с тем, как его
использовать для настройки различных Подов с различными конфигурациями исполняемой среды контейнеров.
* Ознакомьтесь с [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) и с тем, как с его
помощью можно управлять доступностью приложений во время сбоев.
* Под - это ресурс верхнего уровня в Kubernetes REST API. Определение объекта
{{< api-reference page="workload-resources/pod-v1" >}} подробно описывает данный ресурс.
* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/)
объясняет общие компоновки для Подов с более чем одним контейнером.
* Ознакомьтесь с
[Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
Чтобы понять, почему Kubernetes оборачивает общий API Пода в другие ресурсы (такие как
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} или
{{< glossary_tooltip text="Deployments" term_id="deployment" >}}), вы можете прочитать о
технологиях, предшествовавших Kubernetes, включая:
* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
* [Borg](https://research.google.com/pubs/pub43438.html)
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
* [Omega](https://research.google/pubs/pub41684/)
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).

14
content/ru/docs/reference/glossary/api-eviction.md
View File

@ -5,20 +5,20 @@ date: 2021-04-27
full_link: /docs/concepts/scheduling-eviction/api-eviction/
short_description: >
Вытеснение, инициированное через API — процесс, при котором с помощью Eviction API создается объект Eviction,
который запускает корректное завершение работы Pod'а.
который запускает корректное завершение работы пода.
aka:
tags:
- operation
---
Вытеснение, инициированное через API — процесс, при котором с помощью [Eviction API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
создается объект `Eviction`, который запускает корректное завершение работы Pod'а.
Вытеснение, инициированное через API, — процесс, при котором с помощью [Eviction API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
создается объект `Eviction`, который запускает корректное завершение работы пода.
<!--more-->
Вытеснение можно запросить через Eviction API, обратившись к нему напрямую, либо программно (через клиент API-сервера — например, с помощью команды `kubectl drain`). При этом будет создан объект `Eviction`, на основании которого API-сервер завершит работу Pod'а.
Вытеснение можно запросить через Eviction API, обратившись к нему напрямую, либо программно (через клиент API-сервера — например, с помощью команды `kubectl drain`). При этом будет создан объект `Eviction`, на основании которого API-сервер завершит работу пода.
Вытеснения, инициированные через API, учитывают заданные параметры [`PodDisruptionBudget`](/docs/tasks/run-application/configure-pdb/) (минимальное количество реплик, которые должны быть доступны для данного развертывания в любой момент времени) и [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) (период ожидания корректного завершения работы Pod'а).
Вытеснения, инициированные через API, учитывают заданные параметры [`PodDisruptionBudget`](/docs/tasks/run-application/configure-pdb/) и [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination).
Обратите внимание: вытеснение, инициированное через API — не то же самое, что вытеснение из-за [дефицита ресурсов на узле](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
Вытеснение, инициированное через API, — не то же самое, что вытеснение из-за [дефицита ресурсов на узле](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
* Дополнительная информация доступна в разделе ["Вытеснение, инициированное API"](/docs/concepts/scheduling-eviction/api-eviction/).
* Дополнительная информация доступна в разделе ["Вытеснение, инициированное API"](/ru/docs/concepts/scheduling-eviction/api-eviction/).

14
content/ru/docs/reference/glossary/cloud-controller-manager.md
View File

@ -1,5 +1,5 @@
---
title: Диспетчер облачных контроллеров
title: Cloud Controller Manager
id: cloud-controller-manager
date: 2018-04-12
full_link: /docs/concepts/architecture/cloud-controller/
@ -11,9 +11,15 @@ tags:
- architecture
- operation
---
Компонент {{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}} Kubernetes, встраивающий специфику облака в логику управления. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером.
Диспетчер облачных контроллеров (Cloud Controller Manager, CCM) — компонент
{{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}}
Kubernetes, встраивающий специфику облака в логику управления. Он позволяет
связать кластер с API поставщика облачных услуг и отделить компоненты,
взаимодействующие с этой облачной платформой, от компонентов,
взаимодействующих только с вашим кластером.
<!--more-->
Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой, компонент cloud-controller-manager позволяет поставщикам облачных услуг выпускать функции в другом темпе по сравнению с основным проектом Kubernetes.
Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой,
компонент cloud-controller-manager позволяет поставщикам облачных услуг
выпускать функции, не привязываясь к релизам основного проекта Kubernetes.

16
content/ru/docs/reference/glossary/cloud-provider.md
View File

@ -1,5 +1,5 @@
---
title: Облачный Провайдер (Cloud Provider)
title: Облачный провайдер
id: cloud-provider
date: 2018-04-12
full_link: /docs/concepts/cluster-administration/cloud-providers
@ -7,7 +7,7 @@ short_description: >
Организация, которая предлагает платформу облачных вычислений.
aka:
- Поставщик Облачных Услуг (Cloud Service Provider)
- Поставщик облачных услуг (Cloud Service Provider)
tags:
- community
---
@ -15,17 +15,17 @@ tags:
<!--more-->
Облачные Провайдеры, иногда называемые Поставщиками Облачных Услуг (Cloud Service Provider, CSPs),
Облачные провайдеры (Cloud Providers), иногда называемые Поставщиками облачных услуг (Cloud Service Provider, CSPs),
предлагают облачные вычислительные платформы или услуги.
Многие облачные провайдеры предлагают управляемую инфраструктуру (также называемую
Инфраструктура как Услуга (Infrastructure as a Service) или IaaS).
Многие облачные провайдеры предлагают управляемую (managed) инфраструктуру, также называемую
Инфраструктура как Услуга (Infrastructure as a Service, IaaS).
С управляемой инфраструктурой облачный провайдер отвечает за
сервера, хранилище и сеть, в то время как вы управляете слоями поверх этого,
серверы, хранилище и сеть, в то время как вы управляете слоями поверх этого,
такими как запуск Kubernetes кластера.
Вы также можете найти Kubernetes в качестве управляемого сервиса; иногда его называют
Платформа как Услуга (Platform as a Service) или PaaS. С упарвляемым Kubernetes
Вы также можете найти Kubernetes как управляемый сервис; иногда его называют
Платформа как Услуга (Platform as a Service, PaaS). С managed Kubernetes
ваш облачный провайдер отвечает за
{{< glossary_tooltip term_id="control-plane" text="управляющий слой" >}} Kubernetes, а также за
{{< glossary_tooltip term_id="node" text="узлы" >}} и инфраструктуру, на которую они полагаются:

6
content/ru/docs/reference/glossary/cluster.md
View File

@ -4,14 +4,14 @@ id: cluster
date: 2019-06-15
full_link:
short_description: >
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
Набор рабочих машин, называемых узлами, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
aka:
tags:
- fundamental
- operation
---
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
Набор рабочих машин, называемых узлами, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
<!--more-->
В рабочих узлах размещены поды, являющиеся компонентами приложения. Управляющий слой (control plane) управляет рабочими узлами и подами в кластере. В промышленных средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
В рабочих узлах размещены поды, которые являются компонентами приложения. {{< glossary_tooltip text="Управляющий слой" term_id="control-plane" >}} управляет рабочими узлами и подами в кластере. В production-средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую доступность.

11
content/ru/docs/reference/glossary/container-runtime.md
View File

@ -1,21 +1,20 @@
---
title: Иcполняемая среда контейнеров
title: Container Runtime
id: container-runtime
date: 2019-06-05
full_link: /docs/setup/production-environment/container-runtimes
short_description: >
Иcполняемая среда контейнеров — это программа, предназначенная для запуска контейнеров.
Иcполняемая среда контейнеров — это программное обеспечение, предназначенное для запуска контейнеров.
aka:
tags:
- fundamental
- workload
---
Иcполняемая среда контейнера — это программа, предназначенная для запуска контейнера в Kubernetes.
Фундаментальный компонент, который позволяет Kubernetes эффективно запускать контейнеры. Он отвечает за управление исполнением и жизненным циклом контейнеров в рамках Kubernetes.
<!--more-->
Kubernetes поддерживает различные среды для запуска контейнеров: {{< glossary_tooltip term_id="docker">}},
{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}},
и любые реализации [Kubernetes CRI (Container Runtime
Kubernetes поддерживает различные среды для запуска контейнеров: {{< glossary_tooltip term_id="containerd" >}},
{{< glossary_tooltip term_id="cri-o" >}} и любые реализации [Kubernetes CRI (Container Runtime
Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).

7
content/ru/docs/reference/glossary/container.md
View File

@ -4,15 +4,16 @@ id: container
date: 2018-04-12
full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
short_description: >
Переносимый и не требовательный к ресурсам исполняемый экземпляр образа, содержащий приложение вместе со всеми его зависимостями.
Легковесный и переносимый исполняемый образ, содержащий программное обеспечение вместе со всеми его зависимостями.
aka:
tags:
- fundamental
- workload
---
Переносимый и не требовательный к ресурсам исполняемый экземпляр образа, содержащий приложение вместе со всеми его зависимостями.
Легковесный и переносимый исполняемый образ, содержащий программное обеспечение вместе со всеми его зависимостями.
<!--more-->
Контейнеры изолирует приложения от инфраструктуры хост-машины, чтобы обеспечить простое масштабирование и упростить развёртывание в различных средах облачных платформ или операционных систем.
Контейнеры изолируют приложения от инфраструктуры хост-машины, чтобы обеспечить простое развёртывание в различных средах облачных платформ и операционных систем, а также упростить масштабирование.
Приложения, запускаемые внутри контейнеров, называются контейнеризированными приложениями. Процесс упаковки этих приложений и их зависимостей в образ контейнера называется контейнеризацией.

6
content/ru/docs/reference/glossary/containerd.md
View File

@ -4,14 +4,14 @@ id: containerd
date: 2019-05-14
full_link: https://containerd.io/docs/
short_description: >
Среда выполнения контейнера с упором на простоту, надежность и переносимость
Исполняемая среда для контейнеров с фокусом на простоту, надежность и переносимость
aka:
tags:
- tool
---
Среда выполнения контейнера с упором на простоту, надежность и переносимость
Исполняемая среда для контейнеров с фокусом на простоту, надежность и переносимость.
<!--more-->
containerd — среда выполнения {{< glossary_tooltip text="контейнера" term_id="container" >}}, который представляет собой демон для Linux или Windows. containerd заботится о получении и хранении образов контейнеров, запуске контейнеров, осуществлять доступ по сети и т.д.
containerd — исполяемая среда для {{< glossary_tooltip text="контейнеров" term_id="container" >}}, который запускается как демон в Linux или Windows. containerd заботится о получении и хранении образов контейнеров, запуске контейнеров, предоставлении сетевого доступа и т.д.

4
content/ru/docs/reference/glossary/control-plane.md
View File

@ -4,10 +4,10 @@ id: control-plane
date: 2019-05-12
full_link:
short_description: >
Уровень оркестрации контейнеров с API и интерфейсами для определения, развёртывания и управления жизненным циклом контейнеров.
Уровень оркестрации контейнеров, предоставляющий API и интерфейсы для определения, развёртывания и управления жизненным циклом контейнеров.
aka:
tags:
- fundamental
---
Уровень оркестрации контейнеров с API и интерфейсами для определения, развёртывания и управления жизненным циклом контейнеров.
Уровень оркестрации контейнеров, предоставляющий API и интерфейсы для определения, развёртывания и управления жизненным циклом контейнеров.

13
content/ru/docs/reference/glossary/controller.md
View File

@ -4,14 +4,14 @@ id: controller
date: 2018-04-12
full_link: /docs/concepts/architecture/controller/
short_description: >
Управляющий цикл который отслеживает общее состояние кластера через API-сервер и вносит изменения пытаясь приветси текушее состояние к желаемому состоянию.
Управляющий цикл, который отслеживает общее состояние кластера через API-сервер и вносит изменения, пытаясь привести текущее состояние к желаемому.
aka:
tags:
- architecture
- fundamental
---
Контроллеры в Kubernetes - управляющие циклы, которые отслеживают состояние вашего
Контроллеры в Kubernetes — управляющие циклы (control loops), которые отслеживают состояние вашего
{{< glossary_tooltip term_id="cluster" text="кластера">}}, затем вносят или запрашивают
изменения там, где это необходимо.
Каждый контроллер пытается привести текущее состояние кластера ближе к желаемому состоянию.
@ -22,8 +22,7 @@ tags:
{{< glossary_tooltip text="API-сервер" term_id="kube-apiserver" >}} (часть
{{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}}).
Некоторые контроллеры также работают внутри управляющего слоя (control plane),
обеспечивая управляющие циклы, которые являются ядром для операций Kubernetes. Например:
контроллер развертывания (deployment controller), контроллер daemonset (daemonset controller),
контроллер пространства имен (namespace controller) и контроллер постоянных томов (persistent volume
controller) (и другие) работают с {{< glossary_tooltip term_id="kube-controller-manager" >}}.
Некоторые контроллеры также работают внутри управляющего слоя, реализуя управляющие циклы,
которые являются основой для операций Kubernetes. Например:
контроллер деплоймента, контроллер DaemonSet'а, контроллер пространства имен
и контроллер постоянных томов (и другие) работают с {{< glossary_tooltip term_id="kube-controller-manager" >}}.

8
content/ru/docs/reference/glossary/cri-o.md
View File

@ -4,16 +4,16 @@ id: cri-o
date: 2019-05-14
full_link: https://cri-o.io/#what-is-cri-o
short_description: >
Оптимизированная среда выполнения контейнеров, разработанная специально для Kubernetes
Легковесная исполняемая среда для контейнеров, разработанная специально для Kubernetes
aka:
tags:
- tool
---
Инструмент, позволяющий использовать среды выполнения контейнеров формата OCI с помощью технологии Kubernetes CRI.
Инструмент, позволяющий использовать исполняемые среды для контейнеров стандарта OCI с помощью технологии Kubernetes CRI.
<!--more-->
CRI-O — это реализация {{< glossary_tooltip term_id="cri" >}}, позволяющая использовать среды выполнения {{< glossary_tooltip text="контейнеров" term_id="container" >}}, совместимые со [спецификацией исполняемой среды контейнеров](http://www.github.com/opencontainers/runtime-spec) Open Container Initiative (OCI).
CRI-O — это реализация {{< glossary_tooltip term_id="cri" >}}, позволяющая использовать исполняемые среды для {{< glossary_tooltip text="контейнеров" term_id="container" >}}, совместимые со [спецификацией runtime](http://www.github.com/opencontainers/runtime-spec) Open Container Initiative (OCI).
Развертывание CRI-O позволяет Kubernetes использовать любую OCI-совместимую среду выполнения в качестве контейнерной среды выполнения для выполнения {{< glossary_tooltip text="подов" term_id="pod" >}} и загружать образы OCI-контейнера из удаленных реестров.
Развертывание CRI-O позволяет Kubernetes использовать любую OCI-совместимую исполняемую среду в качестве среды выполнения для {{< glossary_tooltip text="подов" term_id="pod" >}} и загружать контейнерные образы OCI из удаленных реестров.

8
content/ru/docs/reference/glossary/cri.md
View File

@ -2,16 +2,16 @@
title: Container runtime interface (CRI)
id: cri
date: 2019-03-07
full_link: /docs/concepts/overview/components/#container-runtime
full_link: /ru/docs/concepts/overview/components/#container-runtime
short_description: >
API сред выполнения контейнеров для интеграции с kubelet
API для исполняемых сред контейнеров для интеграции с kubelet
aka:
tags:
- fundamental
---
Интерфейс среды выполнения контейнера (Container Runtime Interface, CRI) — это API сред выполнения контейнера, которая интегрируется с kubelet на узле.
Container Runtime Interface (CRI) — это интерфейс API для исполняемых сред контейнеров, который интегрирует их с kubelet на узле.
<!--more-->
Для получения дополнительной информации смотрите API и спефикации [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
Для получения дополнительной информации смотрите API и спецификации [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).

6
content/ru/docs/reference/glossary/daemonset.md
View File

@ -4,7 +4,7 @@ id: daemonset
date: 2018-04-12
full_link: /docs/concepts/workloads/controllers/daemonset
short_description: >
Гарантирует, что копия Pod выполняется в наборе узлов кластера.
Гарантирует, что копия пода выполняется на множестве узлов кластера.
aka:
tags:
@ -12,8 +12,8 @@ tags:
- core-object
- workload
---
Гарантирует, что копия {{< glossary_tooltip text="Pod" term_id="pod" >}} выполняется в наборе узлов {{< glossary_tooltip text="кластера" term_id="cluster" >}}.
Гарантирует, что копия {{< glossary_tooltip text="пода" term_id="pod" >}} выполняется на множестве узлов {{< glossary_tooltip text="кластера" term_id="cluster" >}}.
<!--more-->
Используется для развертывания системных демонов, таких как сборщики логов и агенты мониторинга, которые, как правило, должны работать на каждом {{< glossary_tooltip text="узла" term_id="node" >}}.
Используется для развертывания системных демонов, таких как сборщики логов и агенты мониторинга, которые, как правило, должны работать на каждом {{< glossary_tooltip text="узле" term_id="node" >}}.

11
content/ru/docs/reference/glossary/deployment.md
View File

@ -1,10 +1,10 @@
---
title: Deployment
title: Деплоймент (Deployment)
id: deployment
date: 2018-04-12
full_link: /docs/concepts/workloads/controllers/deployment/
short_description: >
API-объект, управляющий реплицированным приложением.
Управляет реплицированным приложением в кластере.
aka:
tags:
@ -12,9 +12,10 @@ tags:
- core-object
- workload
---
API-объект, управляющий реплицированным приложением.
Объект API, который управляет реплицированным (т.е. имеющим копии) приложением, обычно путём запуска подов без локального хранения данных (т.е. stateless).
<!--more-->
Каждая реплика представляет {{< glossary_tooltip term_id="pod" >}}, а все Pod-объекты распределяются по узлам кластера.
Каждая реплика представлена {{< glossary_tooltip text="подом" term_id="pod" >}},
а все поды распределяются по {{< glossary_tooltip text="узлам" term_id="node" >}} кластера.
Для рабочих нагрузок, требующих локальное хранение данных, стоит обратить внимание на {{< glossary_tooltip term_id="StatefulSet" >}}.

6
content/ru/docs/reference/glossary/docker.md
View File

@ -4,14 +4,14 @@ id: docker
date: 2018-04-12
full_link: https://docs.docker.com/engine/
short_description: >
Docker — это программное обеспечение для виртуализации на уровне операционной системы, которая известна как контейнеризация.
Docker — это программное обеспечение, реализующее виртуализацию на уровне операционной системы, которая известна как контейнеризация.
aka:
tags:
- fundamental
---
Docker (в частности, Docker Engine) — это программное обеспечение для виртуализации на уровне операционной системы, которая также известна как {{< glossary_tooltip text="контейнеризация" term_id="container" >}}.
Docker (в частности, Docker Engine) — это программное обеспечение, реализующее виртуализацию на уровне операционной системы, которая также известна как {{< glossary_tooltip text="контейнеризация" term_id="container" >}}.
<!--more-->
Docker использует возможности изоляции ресурсов ядра Linux, такие как cgroups и пространства имен ядра, а также каскадно-объединённую файловую систему, например, OverlayFS и другие, чтобы независимые друг от друга контейнеры могли работать в одном экземпляре Linux без накладных расходов на запуск и поддержку работы виртуальных машин (VM).
Docker использует возможности изоляции ресурсов ядра Linux, такие как cgroups и пространства имен ядра, а также каскадную файловую систему (например, OverlayFS или другие), чтобы независимые контейнеры могли работать в одном экземпляре Linux без накладных расходов на запуск и поддержку работы виртуальных машин (VM).

4
content/ru/docs/reference/glossary/etcd.md
View File

@ -4,14 +4,14 @@ id: etcd
date: 2018-04-12
full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
short_description: >
Распределённое и высоконадёжное хранилище данных в формате "ключ-значение", которое используется как основное хранилище всех данных кластера в Kubernetes.
Консистентное и высокодоступное хранилище данных в формате «ключ-значение», которое используется как основное хранилище всех данных кластера Kubernetes.
aka:
tags:
- architecture
- storage
---
Распределённое и высоконадёжное хранилище данных в формате "ключ-значение", которое используется как основное хранилище всех данных кластера в Kubernetes.
Консистентное и высокодоступное хранилище данных в формате «ключ-значение», которое используется как основное хранилище всех данных кластера Kubernetes.
<!--more-->

14
content/ru/docs/reference/glossary/garbage-collection.md
View File

@ -1,23 +1,23 @@
---
title: Сборшик мусора
title: Сбор мусора
id: garbage-collection
date: 2021-07-07
full_link: /docs/concepts/workloads/controllers/garbage-collection/
short_description: >
A collective term for the various mechanisms Kubernetes uses to clean up cluster
resources.
Сбор мусора — это собирательный термин для различных механизмов,
используемых Kubernetes для очистки ресурсов кластера.
aka:
tags:
- fundamental
- operation
---
Сборщик мусора - это собирательный термин для различных механизмов? используемых Kubernetes для очистки ресурсов кластера.
Сбор мусора — это собирательный термин для различных механизмов, используемых Kubernetes для очистки ресурсов кластера.
<!--more-->
Kubernetes использует сборку мусора для очистки таких ресурсов, как [неиспользуемые контейнеры и образы](/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
[неудачные Pod-ы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
[неисправные поды](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
[объекты, принадлежащие целевому ресурсу](/docs/concepts/overview/working-with-objects/owners-dependents/),
[завершенные задачи](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources
that have expired or failed.
[завершенные задачи](/docs/concepts/workloads/controllers/ttlafterfinished/) и ресурсы,
время работы которых истекло или которые завершились ошибкой.

11
content/ru/docs/reference/glossary/kube-apiserver.md
View File

@ -4,7 +4,7 @@ id: kube-apiserver
date: 2018-04-12
full_link: /docs/reference/generated/kube-apiserver/
short_description: >
Компонент панели управления, обслуживающий API Kubernetes.
Компонент управляющего слоя, предоставляющий Kubernetes API.
aka:
- kube-apiserver
@ -12,12 +12,11 @@ tags:
- architecture
- fundamental
---
Сервер API — компонент Kubernetes
{{< glossary_tooltip text="панели управления" term_id="control-plane" >}}, который представляет API Kubernetes.
API-сервер — это клиентская часть панели управления Kubernetes
API-сервер — компонент {{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}} Kubernetes,
который делаает доступным Kubernetes API. API-сервер — это фронтенд управляющего слоя Kubernetes.
<!--more-->
Основной реализацией API-сервера Kubernetes является [kube-apiserver](/docs/reference/generated/kube-apiserver/).
kube-apiserver предназначен для горизонтального масштабирования, то есть развёртывание на несколько экземпляров.
Вы можете запустить несколько экземпляров kube-apiserver и сбалансировать трафик между этими экземплярами.
kube-apiserver предназначен для горизонтального масштабирования, то есть он масштабируется при развёртывании
на множестве экземплярах. Вы можете запускать множество экземпляров kube-apiserver и балансировать трафик между ними.

6
content/ru/docs/reference/glossary/kube-controller-manager.md
View File

@ -4,15 +4,15 @@ id: kube-controller-manager
date: 2018-04-12
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
short_description: >
Компонент Control Plane запускает процессы контроллера.
Компонент управляющего слоя, который запускает процессы контроллера.
aka:
tags:
- architecture
- fundamental
---
Компонент Control Plane запускает процессы {{< glossary_tooltip text="контроллера" term_id="controller" >}}.
Компонент управляющего слоя, который запускает процессы {{< glossary_tooltip text="контроллера" term_id="controller" >}}.
<!--more-->
Вполне логично, что каждый {{< glossary_tooltip text="контроллер" term_id="controller" >}} в свою очередь представляет собой отдельный процесс, и для упрощения все такие процессы скомпилированы в один двоичный файл и выполняются в одном процессе.
С логической точки зрения каждый {{< glossary_tooltip text="контроллер" term_id="controller" >}} представляет собой отдельный процесс. Но для упрощения все они скомпилированы в один бинарный файл и выполняются в одном процессе.

6
content/ru/docs/reference/glossary/kube-proxy.md
View File

@ -11,10 +11,10 @@ tags:
- fundamental
- networking
---
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) — сетевой прокси, работающий на каждом узле в кластере, и реализующий часть концепции {{< glossary_tooltip text="сервис" term_id="service">}}.
kube-proxy — сетевой прокси, работающий на каждом {{< glossary_tooltip text="узле" term_id="node">}} в кластере и реализующий часть концепции {{< glossary_tooltip text="сервиса" term_id="service">}} Kubernetes.
<!--more-->
kube-proxy конфигурирует правила сети на узлах. При помощи них разрешаются сетевые подключения к вашими подам изнутри и снаружи кластера.
[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) поддерживает сетевые правила на узлах. Эти правила разрешают сетевое взаимодействие с вашимии подами из сетевых сессий внутри и снаружи кластера.
kube-proxy использует уровень фильтрации пакетов в операционной системы, если он доступен. В противном случае, kube-proxy сам обрабатывает передачу сетевого трафика.
kube-proxy использует уровень фильтрации пакетов операционной системы, если он доступен. В ином случае kube-proxy сам перенаправляет трафик.

12
content/ru/docs/reference/glossary/kube-scheduler.md
View File

@ -4,16 +4,18 @@ id: kube-scheduler
date: 2018-04-12
full_link: /docs/reference/generated/kube-scheduler/
short_description: >
Компонент управляющего слоя, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать.
Компонент управляющего слоя, который отслеживает недавно созданные поды без назначенного для них узла и выбирает узел, на котором они должны работать.
aka:
tags:
- architecture
---
Компонент управляющего слоя (control plane), который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать.
Компонент управляющего слоя (control plane), который отслеживает недавно созданные поды без назначенного для них узла и выбирает узел, на котором они должны работать.
<!--more-->
<!-- Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference? and deadlines. -->
При планировании развёртывания подов на узлах учитываются множество факторов, включая требования к ресурсам, ограничения, связанные с аппаратными/программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) узлов/подов, местонахождения данных, предельных сроков.
При планировании учитываются множество факторов, включая индивидуальные
и общие требования к ресурсам, ограничения по железу/программному обеспечению/политикам,
конфигурация принадлежности (affinity) и непринадлежности (anti-affinity)
узлов/подов, местонахождение данных, взаимодействие между рабочими
нагрузками и дедлайны.

2
content/ru/docs/reference/glossary/kubelet.md
View File

@ -15,4 +15,4 @@ tags:
<!--more-->
Утилита kubelet принимает набор PodSpecs, и гарантирует работоспособность и исправность определённых в них контейнеров. Агент kubelet не отвечает за контейнеры, не созданные Kubernetes.
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) принимает набор PodSpecs, которые определяются разными способами и гарантируют работоспособность и исправность определённых в них контейнеров. Kubelet не отвечает за контейнеры, не созданные Kubernetes.

8
content/ru/docs/reference/glossary/label.md
View File

@ -1,17 +1,17 @@
---
title: Метка
title: Лейбл
id: label
date: 2018-04-12
full_link: /docs/concepts/overview/working-with-objects/labels
short_description: >
Группирует объекты на основе произвольных критериев, по которым пользователи могут их идентифицировать.
Тегирует объекты произвольными метками, которые идентифицируют их и имеют смысл для пользователей.
aka:
tags:
- fundamental
---
Группирует объекты на основе произвольных критериев, по которым пользователи могут их идентифицировать.
Тегирует объекты произвольными метками, которые идентифицируют их и имеют смысл для пользователей.
<!--more-->
Метки — это пары "ключ-значение", которые прикрепляются к таким объектам, как {{< glossary_tooltip text="Pod" term_id="pod" >}}. Они используются для организации и получения подмножеств объектов.
Лейблы — это пары «ключ-значение», которые прикрепляются к таким объектам, как {{< glossary_tooltip text="под" term_id="pod" >}}. Они используются для организации и получения подмножеств объектов.

2
content/ru/docs/reference/glossary/name.md
View File

@ -14,4 +14,4 @@ tags:
<!--more-->
Указанное имя может иметь только один объект определённого типа. Но если вы удалите этот объект, вы можете создать новый с таким же именем
Указанное имя может иметь только один объект определённого типа. Но если вы удалите этот объект, вы можете создать новый с таким же именем.

8
content/ru/docs/reference/glossary/node.md
View File

@ -1,5 +1,5 @@
---
title: Node
title: Узел
id: node
date: 2018-04-12
full_link: /docs/concepts/architecture/nodes/
@ -10,8 +10,10 @@ aka:
tags:
- fundamental
---
Узел — рабочая машина в Kubernetes.
Узел (node) — рабочая машина в Kubernetes.
<!--more-->
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется управляющим слоем (control plane). Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}.
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется управляющим слоем (control plane). Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и исполняемую среду для контейнеров, реализующую {{< glossary_tooltip text="CRI" term_id="cri" >}} (например, {{< glossary_tooltip term_id="docker" >}}).
В ранних версиях Kubernetes узлы назывались «миньонами» (Minions).

2
content/ru/docs/reference/glossary/object.md
View File

@ -12,7 +12,7 @@ tags:
Сущность в системе Kubernetes. Kubernetes использует их для представления состояния кластера.
<!--more-->
Объект Kubernetes обычно представляет собой «запись о намерениях»: как только объект создан,
{{< glossary_tooltip text="слой управления" term_id="control-plane" >}} Kubernetes обеспечивает гарантию того,
{{< glossary_tooltip text="управляющий слой" term_id="control-plane" >}} Kubernetes обеспечивает гарантию того,
что элемент, который этот объект представляет, действительно существует.
Создавая объект, вы фактически указываете системе Kubernetes, как должна
выглядеть эта часть рабочей нагрузки кластера; это желаемое состояние вашего кластера.

12
content/ru/docs/reference/glossary/pod-disruption.md
View File

@ -1,10 +1,10 @@
---
id: pod-disruption
title: Нарушение работы Pod'ов
title: Нарушение работы подов
full_link: /docs/concepts/workloads/pods/disruptions/
date: 2021-05-12
short_description: >
Процесс, в ходе которого происходит плановое или принудительное завершение работы Pod'ов на узлах.
Процесс, в ходе которого происходит плановое или принудительное завершение работы подов на узлах.
aka:
related:
@ -14,11 +14,11 @@ tags:
- operation
---
[Нарушение работы Pod'ов (Pod disruption)](/docs/concepts/workloads/pods/disruptions/) — процесс,
в ходе которого происходит плановое или внеплановое (принудительное) завершение работы Pod'ов на узлах.
[Нарушение работы подов (Pod disruption)](/docs/concepts/workloads/pods/disruptions/) — процесс,
в ходе которого происходит плановое или внеплановое (принудительное) завершение работы подов на узлах.
<!--more-->
Плановое завершение работы Pod'ов инициируется владельцами приложений или администраторами
Плановое завершение работы подов инициируется владельцами приложений или администраторами
кластера. Внеплановое завершение работы обычно вызвано непредвиденными обстоятельствами различной природы,
например, с недостатком ресурсов на узлах или случайными удалениями.
например, недостатком ресурсов на узлах или случайными удалениями.

2
content/ru/docs/reference/glossary/pod.md
View File

@ -15,4 +15,4 @@ tags:
<!--more-->
Как правило, один под предназначен для выполнения одного основного контейнера. Он также может запускать дополнительные "прицепные" (sidecar) контейнеры, добавляющие новые функциональные возможности, например, логирование. Контейнеры обычно управляются {{< glossary_tooltip term_id="deployment" >}}.
Как правило, один под предназначен для выполнения одного основного контейнера. Он также может запускать вспомогательные («прицепные») sidecar-контейнеры, добавляющие новые функциональные возможности, например, логирование. Поды обычно управляются {{< glossary_tooltip text="деплойментом" term_id="deployment" >}}.

10
content/ru/docs/reference/glossary/secret.md
View File

@ -1,18 +1,20 @@
---
title: Secret
title: Секрет (Secret)
id: secret
date: 2018-04-12
full_link: /docs/concepts/configuration/secret/
short_description: >
Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи ssh.
Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи SSH.
aka:
tags:
- core-object
- security
---
Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи ssh.
Хранит конфиденциальную информацию, такую как пароли, токены OAuth и ключи SSH.
<!--more-->
Позволяет повысить контроль над использованием конфиденциальной информации и снизить риск ее случайного раскрытия. Секретные значения кодируются в формат base64 и по умолчанию хранятся в незашифрованном виде, но могут быть настроены на шифрование "at rest" (при записи в хранилище). {{< glossary_tooltip text="Pod" term_id="pod" >}} ссылается на Secret как на файл при монтировании тома. Secret также используется kubelet'ом при извлечении образов для Pod'а. Secret'ы отлично подходят для хранения конфиденциальных данных, [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) – для неконфиденциальных.
Позволяет повысить контроль над использованием конфиденциальной информации и снизить риск ее случайного раскрытия. Секретные значения кодируются в формат base64 и по умолчанию хранятся в незашифрованном виде, но могут быть настроены на [шифрование "at rest"](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) (при записи в хранилище).
{{< glossary_tooltip text="Под" term_id="pod" >}} ссылается на секрет разными способами — например, при монтировании тома или как переменную окружения. Секреты предназначены для конфиденциальных данных, а для неконфиденциальных данных предусмотрены [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).

6
content/ru/docs/reference/glossary/selector.md
View File

@ -4,15 +4,15 @@ id: selector
date: 2018-04-12
full_link: /docs/concepts/overview/working-with-objects/labels/
short_description: >
Позволяет пользователям фильтровать список ресурсов по меткам.
Позволяет пользователям фильтровать список ресурсов по лейблам.
aka:
tags:
- fundamental
---
Позволяет пользователям фильтровать список ресурсов по меткам.
Позволяет пользователям фильтровать список ресурсов по лейблам.
<!--more-->
Селекторы применяются при создании запросов для фильтрации списков ресурсов по {{< glossary_tooltip text="меткам" term_id="label" >}}.
Селекторы применяются при создании запросов для фильтрации списков ресурсов по {{< glossary_tooltip text="лейблам" term_id="label" >}}.

6
content/ru/docs/reference/glossary/service-account.md
View File

@ -4,15 +4,15 @@ id: service-account
date: 2018-04-12
full_link: /docs/tasks/configure-pod-container/configure-service-account/
short_description: >
Отвечает за идентификацию процессов, выполняющихся в Pod'е.
Отвечает за идентификацию процессов, выполняющихся в поде.
aka:
tags:
- fundamental
- core-object
---
Отвечает за идентификацию процессов, выполняющихся в {{< glossary_tooltip text="Pod'е" term_id="pod" >}}.
Отвечает за идентификацию процессов, выполняющихся в {{< glossary_tooltip text="поде" term_id="pod" >}}.
<!--more-->
Процессы внутри Pod'а аутентифицируются сервером API и относятся к определенной учетной записи (service account) (например, к `default`) для доступа к кластеру. Если при создании Pod'а служебная учетная запись не указана, ему автоматически присваивается service account по умолчанию в том же {{< glossary_tooltip text="пространстве имен" term_id="namespace" >}}.
Процессы внутри пода аутентифицируются сервером API и относятся к определенной учетной записи (service account) (например, к `default`) для доступа к кластеру. Если при создании пода служебная учетная запись не указана, ему автоматически присваивается service account по умолчанию в том же {{< glossary_tooltip text="пространстве имен" term_id="namespace" >}}.

6
content/ru/docs/reference/glossary/service.md
View File

@ -15,4 +15,8 @@ tags:
<!--more-->
Набор подов, из которых состоит сервис, определяется (как правило) {{< glossary_tooltip text="селектором" term_id="selector" >}}. При добавлении или удалении подов, набор подов, соответствующий селектору, изменится. Сервис обеспечивает, что сетевой трафик может быть направлен на текущий набор подов для планирования рабочей нагрузки.
Набор подов, из которых состоит сервис, определяется (как правило) {{< glossary_tooltip text="селектором" term_id="selector" >}}. Если поды добавляются или удаляются, набор подов, соответствующий селектору, изменится. Сервис гарантирует, что сетевой трафик может быть направлен на текущий набор подов у рабочей нагрузки.
Сервисы Kubernetes используют либо IP-сеть (IPv4, IPv6 или оба), либо ссылаются на внешнее имя в системе DNS (Domain Name System).
Абстракция сервиса позволяет работать другим механизмам, такие как Ingress и Gateway.

2
content/ru/docs/reference/glossary/uid.md
View File

@ -14,4 +14,4 @@ tags:
<!--more-->
У каждого объекта, созданного в течение всего периода работы кластера Kubernetes, есть собственный уникальный идентификатор (UID). Он предназначен для выяснения различий между событиями похожих сущностей.
У каждого объекта, созданного в течение всего периода работы кластера Kubernetes, есть собственный уникальный идентификатор (UID). Он предназначен для различения схожих сущностей, существовавших в кластере в разное время.

109
content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
View File

@ -33,8 +33,8 @@ limits so that the running container is not allowed to use more of that resource
than the limit you set. The kubelet also reserves at least the _request_ amount of
that system resource specifically for that container to use.
-->
当你定义 {{< glossary_tooltip text="Pod" term_id="pod" >}} 时可以选择性地为每个
{{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。
当你定义 {{< glossary_tooltip text="Pod" term_id="pod" >}}
时可以选择性地为每个{{< glossary_tooltip text="容器" term_id="container" >}}设定所需要的资源数量。
最常见的可设定资源是 CPU 和内存（RAM）大小；此外还有其他类型的资源。
当你为 Pod 中的 Container 指定了资源 **request（请求）** 时，
@ -51,7 +51,6 @@ kubelet 还会为容器预留所 **request（请求）** 数量的系统资源
If the node where a Pod is running has enough of a resource available, it's possible (and
allowed) for a container to use more resource than its `request` for that resource specifies.
However, a container is not allowed to use more than its resource `limit`.
For example, if you set a `memory` request of 256 MiB for a container, and that container is in
a Pod scheduled to a Node with 8GiB of memory and no other Pods, then the container can try to use
@ -60,33 +59,63 @@ more RAM.
## 请求和限制 {#requests-and-limits}
如果 Pod 运行所在的节点具有足够的可用资源，容器可能（且可以）使用超出对应资源
`request` 属性所设置的资源量。不过，容器不可以使用超出其资源 `limit`
属性所设置的资源量。
`request` 属性所设置的资源量。
例如，如果你将容器的 `memory` 的请求量设置为 256 MiB，而该容器所处的 Pod
被调度到一个具有 8 GiB 内存的节点上，并且该节点上没有其他 Pod
运行，那么该容器就可以尝试使用更多的内存。
<!--
If you set a `memory` limit of 4GiB for that container, the kubelet (and
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}) enforce the limit.
The runtime prevents the container from using more than the configured resource limit. For example:
when a process in the container tries to consume more than the allowed amount of memory,
the system kernel terminates the process that attempted the allocation, with an out of memory
(OOM) error.
Limits can be implemented either reactively (the system intervenes once it sees a violation)
or by enforcement (the system prevents the container from ever exceeding the limit). Different
runtimes can have different ways to implement the same restrictions.
Limits are a different story. Both `cpu` and `memory` limits are applied by the kubelet (and
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}),
and are ultimately enforced by the kernel. On Linux nodes, the Linux kernel
enforces limits with
{{< glossary_tooltip text="cgroups" term_id="cgroup" >}}.
The behavior of `cpu` and `memory` limit enforcement is slightly different.
-->
如果你将某容器的 `memory` 限制设置为 4 GiB，kubelet
（和{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}）就会确保该限制生效。
容器运行时会禁止容器使用超出所设置资源限制的资源。
例如：当容器中进程尝试使用超出所允许内存量的资源时，系统内核会将尝试申请内存的进程终止，
并引发内存不足（OOM）错误。
限制是另一个话题。`cpu` 限制和 `memory` 限制都由 kubelet
（以及 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}）来应用，
最终由内核强制执行。在 Linux 节点上，Linux 内核通过
{{< glossary_tooltip text="CGroup" term_id="cgroup" >}} 来强制执行限制。
`cpu` 限制和 `memory` 限制的执行行为略有不同。
限制可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现
（系统会避免容器用量超出限制）。不同的容器运行时采用不同方式来实现相同的限制。
<!--
`cpu` limits are enforced by CPU throttling. When a container approaches
its `cpu` limit, the kernel will restrict access to the CPU corresponding to the
container's limit. Thus, a `cpu` limit is a hard limit the kernel enforces.
Containers may not use more CPU than is specified in their `cpu` limit.
-->
`cpu` 限制通过 CPU 节流机制来强制执行。
当某容器接近其 `cpu` 限制值时，内核会基于容器的限制值来限制其对 CPU 的访问。
因此，`cpu` 限制是内核强制执行的一个硬性限制。容器不得使用超出其 `cpu` 限制所指定的 CPU 核数。
<!--
`memory` limits are enforced by the kernel with out of memory (OOM) kills. When
a container uses more than its `memory` limit, the kernel may terminate it. However,
terminations only happen when the kernel detects memory pressure. Thus, a
container that over allocates memory may not be immediately killed. This means
`memory` limits are enforced reactively. A container may use more memory than
its `memory` limit, but if it does, it may get killed.
-->
`memory` 限制由内核使用 OOM（内存溢出）终止机制来强制执行。
当某容器使用的内存超过其 `memory` 限制时，内核可以终止此容器。
然而，终止只会在内核检测到内存压力时才会发生。
因此，超配内存的容器可能不会被立即终止。
这意味着 `memory` 限制是被动执行的。
某容器可以使用超过其 `memory` 限制的内存，但如果这样做，此容器可能会被终止。
{{< note >}}
<!--
There is an alpha feature `MemoryQoS` which attempts to add more preemptive
limit enforcement for memory (as opposed to reactive enforcement by the OOM
killer). However, this effort is
[stalled](https://github.com/kubernetes/enhancements/tree/a47155b340/keps/sig-node/2570-memory-qos#latest-update-stalled)
due to a potential livelock situation a memory hungry can cause.
-->
你可以使用一个 Alpha 特性 `MemoryQoS` 来尝试为内存添加执行更多的抢占限制
（这与 OOM Killer 的被动执行相反）。然而，由于可能会因内存饥饿造成活锁情形，
所以这种尝试操作会被[卡滞](https://github.com/kubernetes/enhancements/tree/a47155b340/keps/sig-node/2570-memory-qos#latest-update-stalled)。
{{< /note >}}
{{< note >}}
<!--
@ -153,7 +182,7 @@ Kubernetes API 服务器读取和修改的对象。
For each container, you can specify resource limits and requests,
including the following:
-->
## Pod 和 容器的资源请求和限制 {#resource-requests-and-limits-of-pod-and-container}
## Pod 和容器的资源请求和限制 {#resource-requests-and-limits-of-pod-and-container}
针对每个容器，你都可以指定其资源限制和请求，包括如下选项：
@ -171,7 +200,7 @@ a Pod.
For a particular resource, a *Pod resource request/limit* is the sum of the
resource requests/limits of that type for each container in the Pod.
-->
尽管你只能逐个容器地指定请求和限制值，考虑 Pod 的总体资源请求和限制也是有用的。
尽管你只能逐个容器地指定请求和限制值，但考虑 Pod 的总体资源请求和限制也是有用的。
对特定资源而言，**Pod 的资源请求/限制** 是 Pod 中各容器对该类型资源的请求/限制的总和。
<!--
@ -188,7 +217,7 @@ or a virtual machine running inside a physical machine.
### CPU 资源单位 {#meaning-of-cpu}
CPU 资源的限制和请求以 “cpu” 为单位。
CPU 资源的限制和请求以 **cpu** 为单位。
在 Kubernetes 中，一个 CPU 等于 **1 个物理 CPU 核** 或者 **1 个虚拟核**，
取决于节点是一台物理主机还是运行在某物理主机上的虚拟机。
@ -201,10 +230,10 @@ expression `100m`, which can be read as "one hundred millicpu". Some people say
"one hundred millicores", and this is understood to mean the same thing.
-->
你也可以表达带小数 CPU 的请求。
当你定义一个容器，将其 `spec.containers[].resources.requests.cpu` 设置为 0.5 时，
你所请求的 CPU 是你请求 `1.0` CPU 时的一半。
对于 CPU 资源单位，[数量](/zh-cn/docs/reference/kubernetes-api/common-definitions/quantity/)
表达式 `0.1` 等价于表达式 `100m`，可以看作 “100 millicpu”。
当你定义一个容器，将其 `spec.containers[].resources.requests.cpu` 设置为 `0.5` 时，
你所请求的 CPU 是你请求 `1.0` CPU 时的一半。对于 CPU 资源单位，
[数量](/zh-cn/docs/reference/kubernetes-api/common-definitions/quantity/)表达式 `0.1`
等价于表达式 `100m`，可以看作 “100 millicpu”。
有些人说成是“一百毫核”，其实说的是同样的事情。
<!--
@ -213,7 +242,7 @@ CPU resource is always specified as an absolute amount of resource, never as a r
runs on a single-core, dual-core, or 48-core machine.
-->
CPU 资源总是设置为资源的绝对数量而非相对数量值。
例如，无论容器运行在单核、双核或者 48-核的机器上，`500m` CPU 表示的是大约相同的计算能力。
例如，无论容器运行在单核、双核或者 48 核的机器上，`500m` CPU 表示的是大约相同的算力。
{{< note >}}
<!--
@ -347,7 +376,7 @@ limits you defined.
当 kubelet 将容器作为 Pod 的一部分启动时，它会将容器的 CPU 和内存请求与限制信息传递给容器运行时。
在 Linux 系统上，容器运行时通常会配置内核
{{< glossary_tooltip text="CGroups" term_id="cgroup" >}}，负责应用并实施所定义的请求。
{{< glossary_tooltip text="CGroup" term_id="cgroup" >}}，负责应用并实施所定义的请求。
<!--
- The CPU limit defines a hard ceiling on how much CPU time the container can use.
@ -356,13 +385,13 @@ limits you defined.
-->
- CPU 限制定义的是容器可使用的 CPU 时间的硬性上限。
在每个调度周期（时间片）期间，Linux 内核检查是否已经超出该限制；
内核会在允许该 cgroup 恢复执行之前会等待。
内核会在允许该 CGroup 恢复执行之前会等待。
<!--
- The CPU request typically defines a weighting. If several different containers (cgroups)
want to run on a contended system, workloads with larger CPU requests are allocated more
CPU time than workloads with small requests.
-->
- CPU 请求值定义的是一个权重值。如果若干不同的容器（CGroups）需要在一个共享的系统上竞争运行，
- CPU 请求值定义的是一个权重值。如果若干不同的容器（CGroup）需要在一个共享的系统上竞争运行，
CPU 请求值大的负载会获得比请求值小的负载更多的 CPU 时间。
<!--
- The memory request is mainly used during (Kubernetes) Pod scheduling. On a node that uses
@ -378,7 +407,7 @@ limits you defined.
to allocate memory. If that process is the container's PID 1, and the container is marked
as restartable, Kubernetes restarts the container.
-->
- 内存限制定义的是 cgroup 的内存限制。如果容器尝试分配的内存量超出限制，
- 内存限制定义的是 CGroup 的内存限制。如果容器尝试分配的内存量超出限制，
则 Linux 内核的内存不足处理子系统会被激活，并停止尝试分配内存的容器中的某个进程。
如果该进程在容器中 PID 为 1，而容器被标记为可重新启动，则 Kubernetes
会重新启动该容器。
@ -499,9 +528,11 @@ for additional enforcement.
If you specify a `spec.containers[].resources.limits.memory` for each Pod,
then the maximum size of an `emptyDir` volume will be the pod's memory limit.
-->
如果你在管理集群或命名空间，还可以设置限制内存使用的 [ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)；
你可能还希望定义一个 [LimitRange](/zh-cn/docs/concepts/policy/limit-range/) 以施加额外的限制。如果为每个 Pod
指定 `spec.containers[].resources.limits.memory`，那么 `emptyDir` 卷的最大尺寸将是该 Pod 的内存限制。
如果你在管理集群或命名空间，还可以设置限制内存使用的
[ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)；
你可能还希望定义一个 [LimitRange](/zh-cn/docs/concepts/policy/limit-range/)
以施加额外的限制。如果为每个 Pod 指定 `spec.containers[].resources.limits.memory`，
那么 `emptyDir` 卷的最大尺寸将是 Pod 的内存限制。
<!--
As an alternative, a cluster administrator can enforce size limits for
@ -568,9 +599,9 @@ the resource quota is not enforced on ephemeral-storage.
为了使临时性存储的资源配额生效，需要完成以下两个步骤：
* 管理员在命名空间中设置临时性存储的资源配额。
* 用户需要在 Pod spec 中指定临时性存储资源的限制。
* 用户需要在 Pod 规约中指定临时性存储资源的限制。
如果用户在 Pod spec 中未指定临时性存储资源的限制，
如果用户在 Pod 规约中未指定临时性存储资源的限制，
则临时性存储的资源配额不会生效。
{{< /note >}}

4
content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -681,12 +681,12 @@ null `namespaceSelector` matches the namespace of the Pod where the rule is defi
{{< note >}}
<!-- UPDATE THIS WHEN PROMOTING TO STABLE -->
<!--
The `matchLabelKeys` field is an beta-level field and is disabled by default in
The `matchLabelKeys` field is a beta-level field and is enabled by default in
Kubernetes {{< skew currentVersion >}}.
When you want to disable it, you have to disable it explicitly via the
`MatchLabelKeysInPodAffinity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
-->
`matchLabelKeys` 字段是一个 Beta 级别的字段，在 Kubernetes {{< skew currentVersion >}} 中默认被禁用。
`matchLabelKeys` 字段是一个 Beta 级别的字段，在 Kubernetes {{< skew currentVersion >}} 中默认被启用。
当你想要禁用此字段时，你必须通过 `MatchLabelKeysInPodAffinity`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)禁用它。
{{< /note >}}

5
content/zh-cn/docs/concepts/storage/storage-classes.md
View File

@ -403,6 +403,11 @@ supported plugins.
{{% code_sample language="yaml" file="storage/storageclass/storageclass-topology.yaml" %}}
<!--
`tagSpecification`: Tags with this prefix are applied to dynamically provisioned EBS volumes.
-->
`tagSpecification`：具有此前缀的标签适用于动态配置的 EBS 卷。
<!--
## Parameters

145
content/zh-cn/docs/concepts/storage/volumes.md
View File

@ -497,7 +497,7 @@ to mount in a Pod. You can specify single or multiple target world wide names (W
using the parameter `targetWWNs` in your Volume configuration. If multiple WWNs are specified,
targetWWNs expect that those WWNs are from multi-path connections.
-->
### fc (光纤通道) {#fc}
### fc（光纤通道） {#fc}
`fc` 卷类型允许将现有的光纤通道块存储卷挂载到 Pod 中。
可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN（World Wide Names）。
@ -580,7 +580,7 @@ clones the repo using Git, then mount the
`gitRepo` 卷类型已经被弃用。
如果需要制备已挂载 Git 仓库的 Pod，你可以将
[EmptyDir](#emptydir) 卷挂载到 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/) 中，
[EmptyDir](#emptydir) 卷挂载到 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)中，
使用 Git 命令完成仓库的克隆操作，然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。
---
@ -591,12 +591,12 @@ You can restrict the use of `gitRepo` volumes in your cluster using
[ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy/).
You can use the following Common Expression Language (CEL) expression as
part of a policy to reject use of `gitRepo` volumes:
`has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo))`.
`!has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo))`.
-->
你可以使用 [ValidatingAdmissionPolicy](/zh-cn/docs/reference/access-authn-authz/validating-admission-policy/)
这类[策略](/zh-cn/docs/concepts/policy/)来限制在你的集群中使用 `gitRepo` 卷。
你可以使用以下通用表达语言（CEL）表达式作为策略的一部分，以拒绝使用 `gitRepo` 卷：
`has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo))`。
`!has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo))`。
{{< /warning >}}
<!--
@ -788,19 +788,38 @@ root 身份运行进程，或者修改主机上的文件权限，以便能够从
-->
#### hostPath 配置示例
{{< tabs name="hostpath_examples" >}}
<!--
Linux node
---
# This manifest mounts /data/foo on the host as /foo inside the
# single container that runs within the hostpath-example-linux Pod.
#
# The mount into the container is read-only.
# mount /data/foo, but only if that directory already exists
# directory location on host
# this field is optional
apiVersion: v1
kind: Pod
metadata:
name: hostpath-example-linux
spec:
os: { name: linux }
nodeSelector:
kubernetes.io/os: linux
containers:
- name: example-container
image: registry.k8s.io/test-webserver
volumeMounts:
- mountPath: /foo
name: example-volume
readOnly: true
volumes:
- name: example-volume
# mount /data/foo, but only if that directory already exists
hostPath:
path: /data/foo # directory location on host
type: Directory # this field is optional
-->
{{< tabs name="hostpath_examples" >}}
{{< tab name="Linux 节点" codelang="yaml" >}}
---
# 此清单将主机上的 /data/foo 挂载为 hostpath-example-linux Pod 中运行的单个容器内的 /foo
@ -831,15 +850,32 @@ spec:
<!--
Windows node
---
# This manifest mounts C:\Data\foo on the host as C:\foo, inside the
# single container that runs within the hostpath-example-windows Pod.
#
# The mount into the container is read-only.
# mount C:\Data\foo from the host, but only if that directory already exists
# directory location on host
# this field is optional
apiVersion: v1
kind: Pod
metadata:
name: hostpath-example-windows
spec:
os: { name: windows }
nodeSelector:
kubernetes.io/os: windows
containers:
- name: example-container
image: microsoft/windowsservercore:1709
volumeMounts:
- name: example-volume
mountPath: "C:\\foo"
readOnly: true
volumes:
# mount C:\Data\foo from the host, but only if that directory already exists
- name: example-volume
hostPath:
path: "C:\\Data\\foo" # directory location on host
type: Directory # this field is optional
-->
{{< tab name="Windows 节点" codelang="yaml" >}}
---
@ -899,7 +935,34 @@ Here's the example manifest:
以下是清单示例：
<!--
# Ensure the file directory is created.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: test-webserver
spec:
os: { name: linux }
nodeSelector:
kubernetes.io/os: linux
containers:
- name: test-webserver
image: registry.k8s.io/test-webserver:latest
volumeMounts:
- mountPath: /var/local/aaa
name: mydir
- mountPath: /var/local/aaa/1.txt
name: myfile
volumes:
- name: mydir
hostPath:
# Ensure the file directory is created.
path: /var/local/aaa
type: DirectoryOrCreate
- name: myfile
hostPath:
path: /var/local/aaa/1.txt
type: FileOrCreate
```
-->
```yaml
apiVersion: v1
@ -1307,7 +1370,25 @@ Here is an example Pod referencing a pre-provisioned Portworx volume:
下面是一个引用预先配备的 Portworx 卷的示例 Pod：
<!--
# This Portworx volume must already exist.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: test-portworx-volume-pod
spec:
containers:
- image: registry.k8s.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /mnt
name: pxvol
volumes:
- name: pxvol
# This Portworx volume must already exist.
portworxVolume:
volumeID: "pxvol"
fsType: "<fs-type>"
```
-->
```yaml
apiVersion: v1
@ -1432,7 +1513,7 @@ receive Secret updates.
<!--
For more details, see [Configuring Secrets](/docs/concepts/configuration/secret/).
-->
更多详情请参考[配置 Secrets](/zh-cn/docs/concepts/configuration/secret/)。
更多详情请参考[配置 Secret](/zh-cn/docs/concepts/configuration/secret/)。
<!--
### vsphereVolume (deprecated) {#vspherevolume}
@ -1612,7 +1693,33 @@ The host directory `/var/log/pods/pod1` is mounted at `/logs` in the container.
宿主机目录 `/var/log/pods/pod1` 被挂载到容器的 `/logs` 中。
<!--
# The variable expansion uses round brackets (not curly brackets).
```yaml
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
containers:
- name: container1
env:
- name: POD_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
image: busybox:1.28
command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
volumeMounts:
- name: workdir1
mountPath: /logs
# The variable expansion uses round brackets (not curly brackets).
subPathExpr: $(POD_NAME)
restartPolicy: Never
volumes:
- name: workdir1
hostPath:
path: /var/log/pods
```
-->
```yaml
apiVersion: v1

4
content/zh-cn/docs/contribute/participate/issue-wrangler.md
View File

@ -64,7 +64,7 @@ Each day in a week-long shift the Issue Wrangler will be responsible for:
Below are some commonly used commands for Issue Wranglers:
-->
## 对管理者有帮助的 Prow 命令
## 对管理者有帮助的 Prow 命令 {#helpful-prow-commands-for-wranglers}
以下是 Issue 管理者的一些常用命令：
@ -135,7 +135,7 @@ Below are some commonly used commands for Issue Wranglers:
# 接受某个 Issue 的归类
/triage accepted
# 关闭还未处理且未修复的 Issue
# 关闭将不会处理且尚未修复的 Issue
/close not-planned
```

2
content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md
View File

@ -13,7 +13,7 @@ stages:
- stage: beta
defaultValue: true
fromVersion: "1.29"
toVersion": "1.30"
toVersion: "1.30"
- stage: stable
defaultValue: true
fromVersion: "1.31"

2
content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/dynamic-resource-allocation.md
View File

@ -8,7 +8,7 @@ _build:
stages:
- stage: alpha
defaultValue: false
fromVersion: "1.30"
fromVersion: "1.26"
---
<!--
Enables support for resources with custom parameters and a lifecycle

8
content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/new-volume-manager-reconstruction.md
View File

@ -6,13 +6,13 @@ _build:
render: false
stages:
- stage: beta
- stage: alpha
defaultValue: false
fromVersion: "1.27"
toVersion: "1.27"
fromVersion: "1.25"
toVersion: "1.26"
- stage: beta
defaultValue: true
fromVersion: "1.28"
fromVersion: "1.27"
toVersion: "1.29"
- stage: stable
defaultValue: true

2
content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md
View File

@ -1684,7 +1684,7 @@ Default: nil
<p>maxParallelImagePulls 设置并行拉取镜像的最大数量。
如果 serializeImagePulls 为 true，则无法设置此字段。
把它设置为 nil 意味着没有限制。</p>
<p>默认值：true</p>
<p>默认值：nil</p>
</td>
</tr>
<tr><td><code>evictionHard</code><br/>

5
content/zh-cn/docs/reference/kubectl/_index.md
View File

@ -200,6 +200,7 @@ of `kubectl api-resources` to determine if a resource is namespaced.
如果设置了 `POD_NAMESPACE` 环境变量，对命名空间资源的 CLI 操作对象将使用该变量值作为默认值。
例如，如果该变量设置为 `seattle`，`kubectl get pods` 将返回 `seattle` 命名空间中的 Pod。
这是因为 Pod 是一个命名空间资源，且命令中没有提供命名空间。
请查看 `kubectl api-resources` 的输出，以确定某个资源是否是命名空间资源。
<!--
Explicit use of `--namespace <value>` overrides this behavior.
@ -255,7 +256,7 @@ kubectl config set-context --current --namespace=<namespace-name>
<!--
The following table includes short descriptions and the general syntax for all of the `kubectl` operations:
-->
下表包含所有 kubectl 操作的简短描述和普通语法：
下表包含所有 `kubectl` 操作的简短描述和普通语法：
<!--
Operation | Syntax | Description
@ -664,7 +665,7 @@ kubectl get pods --sort-by=.metadata.name
<!--
Use the following set of examples to help you familiarize yourself with running the commonly used `kubectl` operations:
-->
使用以下示例集来帮助你熟悉运行常用 kubectl 操作：
使用以下示例集来帮助你熟悉运行常用 `kubectl` 操作：
<!--
`kubectl apply` - Apply or Update a resource from a file or stdin.

5
content/zh-cn/docs/reference/kubectl/generated/kubectl_apply/_index.md
View File

@ -24,6 +24,11 @@ Apply a configuration to a resource by file name or stdin. The resource name mus
基于文件名或标准输入将配置应用于资源。必须指定资源名称。如果资源尚不存在，则资源会被创建。
若要使用 `apply` 命令，最初创建资源时应始终使用 `apply` 或 `create --save-config`。
支持 JSON 和 YAML 格式。
Alpha 免责声明：--prune 功能尚不完整。除非你了解当前的状态，否则请勿使用此功能。
参见 https://issues.k8s.io/34274
```shell
kubectl apply (-f FILENAME | -k DIRECTORY)
```

50
content/zh-cn/docs/reference/kubernetes-api/common-definitions/quantity.md
View File

@ -36,34 +36,42 @@ The serialization format is:
序列化格式如下：
<!--
\<quantity> ::= \<signedNumber>\<suffix>
```
\<quantity> ::= \<signedNumber>\<suffix>
(Note that \<suffix> may be empty, from the "" case in \<decimalSI>.)
\<digit> ::= 0 | 1 | ... | 9
\<digits> ::= \<digit> | \<digit>\<digits>
\<number> ::= \<digits> | \<digits>.\<digits> | \<digits>. | .\<digits>
\<sign> ::= "+" | "-"
\<signedNumber> ::= \<number> | \<sign>\<number>
\<suffix> ::= \<binarySI> | \<decimalExponent> | \<decimalSI>
\<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei
\<digit> ::= 0 | 1 | ... | 9 \<digits> ::= \<digit> | \<digit>\<digits> \<number> ::= \<digits> | \<digits>.\<digits> | \<digits>. | .\<digits> \<sign> ::= "+" | "-" \<signedNumber> ::= \<number> | \<sign>\<number> \<suffix> ::= \<binarySI> | \<decimalExponent> | \<decimalSI> \<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei
(International System of units; See: http://physics.nist.gov/cuu/Units/binary.html)
\<decimalSI> ::= m | "" | k | M | G | T | P | E
(Note that 1024 = 1Ki but 1000 = 1k; I didn't choose the capitalization.)
\<decimalExponent> ::= "e" \<signedNumber> | "E" \<signedNumber>
\<decimalExponent> ::= "e" \<signedNumber> | "E" \<signedNumber>
```
-->
```
<quantity> ::= <signedNumber><suffix>
(注意 <suffix> 可能为空，例如 <decimalSI> 的 "" 情形。) </br>
<digit> ::= 0 | 1 | ... | 9 </br>
<digits> ::= <digit> | <digit><digits> </br>
<number> ::= <digits> | <digits>.<digits> | <digits>. | .<digits> </br>
<sign> ::= "+" | "-" </br>
<signedNumber> ::= <number> | <sign><number> </br>
<suffix> ::= <binarySI> | <decimalExponent> | <decimalSI> </br>
<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei
(国际单位制度；查阅： http://physics.nist.gov/cuu/Units/binary.html)</br>
<decimalSI> ::= m | "" | k | M | G | T | P | E
(注意，1024 = 1ki 但 1000 = 1k；我没有选择大写。) </br>
<decimalExponent> ::= "e" <signedNumber> | "E" <signedNumber> </br>
（注意 <suffix> 可能为空，例如 <decimalSI> 的 "" 情形。）
<digit> ::= 0 | 1 | ... | 9
<digits> ::= <digit> | <digit><digits>
<number> ::= <digits> | <digits>.<digits> | <digits>. | .<digits>
<sign> ::= "+" | "-"
<signedNumber> ::= <number> | <sign><number>
<suffix> ::= <binarySI> | <decimalExponent> | <decimalSI>
<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei
（国际单位制度；查阅： http://physics.nist.gov/cuu/Units/binary.html）
<decimalSI> ::= m | "" | k | M | G | T | P | E
（注意，1024 = 1ki 但 1000 = 1k；我没有选择大写。）
<decimalExponent> ::= "e" <signedNumber> | "E" <signedNumber>
```
<!--

13
content/zh-cn/docs/tasks/network/extend-service-ip-ranges.md
View File

@ -36,13 +36,14 @@ This document shares how to extend the existing Service IP range assigned to a c
<!--
Kubernetes clusters with kube-apiservers that have enabled the `MultiCIDRServiceAllocator`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and the `networking.k8s.io/v1alpha1` API,
will create a new ServiceCIDR object that takes the well-known name `kubernetes`, and that uses an IP address range
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and have the `networking.k8s.io/v1beta1`
API group active,
will create a ServiceCIDR object that takes the well-known name `kubernetes`, and that specifies an IP address range
based on the value of the `--service-cluster-ip-range` command line argument to kube-apiserver.
-->
如果 Kubernetes 集群的 kube-apiserver 启用了 `MultiCIDRServiceAllocator`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)和
`networking.k8s.io/v1alpha1` API，集群将创建一个新的 ServiceCIDR 对象，
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)且激活了
`networking.k8s.io/v1beta1` API 组，集群将创建一个新的 ServiceCIDR 对象，
该对象采用 `kubernetes` 这个众所周知的名称并基于 kube-apiserver 的 `--service-cluster-ip-range`
命令行参数的值来使用 IP 地址范围。
@ -144,7 +145,7 @@ that extends or adds new IP address ranges.
```sh
cat <EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1alpha1
apiVersion: networking.k8s.io/v1beta1
kind: ServiceCIDR
metadata:
name: newcidr1
@ -201,7 +202,7 @@ kubectl get servicecidr newcidr1 -o yaml
```
```yaml
apiVersion: networking.k8s.io/v1alpha1
apiVersion: networking.k8s.io/v1beta1
kind: ServiceCIDR
metadata:
creationTimestamp: "2023-10-12T15:11:07Z"

15
data/announcements/scheduled.yaml
View File

@ -262,3 +262,18 @@ announcements:
<a href= "https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/register/?utm_source=kubernetes&utm_medium=homepage&utm_campaign=KubeCon-NA-2024&utm_content=top-banner">
Buy your ticket now! 12 - 15 November | Salt Lake City
</a>
- name: KubeCon 2024 India
startTime: 2024-11-26T00:00:00 #Added in https://github.com/kubernetes/website/pull/48862
endTime: 2024-12-12T18:00:00
style: >-
background: linear-gradient(90deg, rgba(217,54,73,1) 35%, rgba(81,0,116,1) 100%);
color: #fffff;
title: |
<img src ="/images/announcements/kccnc-india-2024-white.svg" style="float: right; height: 100px;" />
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-india/">KubeCon + CloudNativeCon 2024</a>
message: |
Join us for two days of incredible opportunities to collaborate, learn and share with the cloud native community.<br/>
<a href= "https://events.linuxfoundation.org/kubecon-cloudnativecon-india/register/?utm_source=kubernetes&utm_medium=homepage&utm_campaign=KubeCon-India-2024&utm_content=top-banner">
Buy your ticket now! 11 - 12 December | Delhi, India
</a>

4
static/css/gridpage.css
View File

@ -39,6 +39,10 @@
font-weight: 300 !important;
}
.gridPage .case-study .quote{
color: rgb(26,26,26);
}
.gridPage #mainContent {
padding: 0;
}

1
static/images/announcements/kccnc-india-2024-white.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB