diff --git a/Makefile b/Makefile index b97e9a45b3..2f9a0612ee 100644 --- a/Makefile +++ b/Makefile @@ -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 diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 3f4b45db39..d5deda7cd1 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -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 diff --git a/content/en/blog/_posts/2024-11-11-memory-manager-moves-to-ga/index.md b/content/en/blog/_posts/2024-11-11-memory-manager-moves-to-ga/index.md new file mode 100644 index 0000000000..6b3bbb13ec --- /dev/null +++ b/content/en/blog/_posts/2024-11-11-memory-manager-moves-to-ga/index.md @@ -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! + diff --git a/content/en/blog/_posts/2024-12-11-api-streaming/index.md b/content/en/blog/_posts/2024-12-11-api-streaming/index.md new file mode 100644 index 0000000000..ad36102dfa --- /dev/null +++ b/content/en/blog/_posts/2024-12-11-api-streaming/index.md @@ -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. diff --git a/content/en/blog/_posts/2024-12-11-api-streaming/kube-apiserver-memory_usage.png b/content/en/blog/_posts/2024-12-11-api-streaming/kube-apiserver-memory_usage.png new file mode 100644 index 0000000000..31dcbdc724 Binary files /dev/null and b/content/en/blog/_posts/2024-12-11-api-streaming/kube-apiserver-memory_usage.png differ diff --git a/content/en/blog/_posts/2024-12-11-volume-group-snapshot-beta.md b/content/en/blog/_posts/2024-12-11-volume-group-snapshot-beta.md new file mode 100644 index 0000000000..d72640eb0c --- /dev/null +++ b/content/en/blog/_posts/2024-12-11-volume-group-snapshot-beta.md @@ -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 2m15s +pvc-1 Bound pvc-abc640b3-2cc1-4c56-ad0c-4f0f0e636efa 100Mi RWO csi-hostpath-sc 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. diff --git a/content/en/docs/concepts/architecture/cri.md b/content/en/docs/concepts/architecture/cri.md index 055df28b4f..c12ee19e78 100644 --- a/content/en/docs/concepts/architecture/cri.md +++ b/content/en/docs/concepts/architecture/cri.md @@ -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" >}} diff --git a/content/en/docs/concepts/policy/limit-range.md b/content/en/docs/concepts/policy/limit-range.md index b9a2a5ebc5..9da1160e89 100644 --- a/content/en/docs/concepts/policy/limit-range.md +++ b/content/en/docs/concepts/policy/limit-range.md @@ -11,27 +11,32 @@ weight: 10 -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. 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. \ No newline at end of file diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index ec02819f7d..6e4b09c9da 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -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). diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md index fc4b14a6fe..eac74658ee 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md @@ -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" diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/new-volume-manager-reconstruction.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/new-volume-manager-reconstruction.md index fb4d283753..ff2a4a1d5f 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates/new-volume-manager-reconstruction.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/new-volume-manager-reconstruction.md @@ -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 diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/translate-stream-close-websocket-requests.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/translate-stream-close-websocket-requests.md index 95928403cb..2739c0e9a6 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates/translate-stream-close-websocket-requests.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates/translate-stream-close-websocket-requests.md @@ -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" diff --git a/content/en/docs/reference/config-api/kubeadm-config.v1beta4.md b/content/en/docs/reference/config-api/kubeadm-config.v1beta4.md index f809828d85..147bdb75bd 100644 --- a/content/en/docs/reference/config-api/kubeadm-config.v1beta4.md +++ b/content/en/docs/reference/config-api/kubeadm-config.v1beta4.md @@ -278,7 +278,7 @@ configuration types to be used during a kubeadm init run.

dns: disabled: true # disable CoreDNS proxy: - diabled: true # disable kube-proxy + disabled: true # disable kube-proxy --- apiVersion: kubelet.config.k8s.io/v1beta1 @@ -576,8 +576,7 @@ and for kube-proxy, while registry.k8s.io will be used for all the

encryptionAlgorithm holds the type of asymmetric encryption algorithm used for keys and -certificates. Can be "RSA" (default algorithm, key size is 2048) or "ECDSA" (uses the -P-256 elliptic curve).

+certificates. Can be one of "RSA-2048" (default), "RSA-3072", "RSA-4096" or "ECDSA-P256".

certificateValidityPeriod
diff --git a/content/en/docs/reference/glossary/container-runtime-interface.md b/content/en/docs/reference/glossary/container-runtime-interface.md deleted file mode 100644 index f0f8cba9be..0000000000 --- a/content/en/docs/reference/glossary/container-runtime-interface.md +++ /dev/null @@ -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. - - - -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" >}}. diff --git a/content/en/docs/reference/glossary/cri.md b/content/en/docs/reference/glossary/cri.md index c690bcb18d..82044c1166 100644 --- a/content/en/docs/reference/glossary/cri.md +++ b/content/en/docs/reference/glossary/cri.md @@ -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. + -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" >}}. diff --git a/content/en/docs/reference/instrumentation/cri-pod-container-metrics.md b/content/en/docs/reference/instrumentation/cri-pod-container-metrics.md index 80488452bf..72c5e0aa0b 100644 --- a/content/en/docs/reference/instrumentation/cri-pod-container-metrics.md +++ b/content/en/docs/reference/instrumentation/cri-pod-container-metrics.md @@ -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). - \ No newline at end of file + diff --git a/content/en/docs/reference/instrumentation/node-metrics.md b/content/en/docs/reference/instrumentation/node-metrics.md index df264fc844..32eab955bd 100644 --- a/content/en/docs/reference/instrumentation/node-metrics.md +++ b/content/en/docs/reference/instrumentation/node-metrics.md @@ -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" %}} diff --git a/content/en/docs/tasks/manage-kubernetes-objects/storage-version-migration.md b/content/en/docs/tasks/manage-kubernetes-objects/storage-version-migration.md index 0580ee463b..2588efe738 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/storage-version-migration.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/storage-version-migration.md @@ -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 diff --git a/content/en/docs/tasks/network/extend-service-ip-ranges.md b/content/en/docs/tasks/network/extend-service-ip-ranges.md index 3b381158d7..de62cb7378 100644 --- a/content/en/docs/tasks/network/extend-service-ip-ranges.md +++ b/content/en/docs/tasks/network/extend-service-ip-ranges.md @@ -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 }}) 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" %}} diff --git a/content/hi/_index.html b/content/hi/_index.html index b1faf30bcc..5da2e269e4 100644 --- a/content/hi/_index.html +++ b/content/hi/_index.html @@ -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" %}} diff --git a/content/id/community/static/cncf-code-of-conduct.md b/content/id/community/static/cncf-code-of-conduct.md index 9ec35edc3d..3ab9529687 100644 --- a/content/id/community/static/cncf-code-of-conduct.md +++ b/content/id/community/static/cncf-code-of-conduct.md @@ -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 . Untuk proyek lain, silakan hubungi pengelola proyek CNCF atau mediator kami, Mishi Choudhary . Kode Etik ini diadaptasi dari Covenant Contributor -, versi 1.2.0, tersedia di +, versi 1.2.0, tersedia di ### Pedoman Perilaku Acara CNCF diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md index 79876d0efa..47f73fc283 100644 --- a/content/id/docs/concepts/cluster-administration/addons.md +++ b/content/id/docs/concepts/cluster-administration/addons.md @@ -42,7 +42,6 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk ## Visualisasi & 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 diff --git a/content/it/_index.html b/content/it/_index.html index 52400fea99..edf35c2ad6 100644 --- a/content/it/_index.html +++ b/content/it/_index.html @@ -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" %}} diff --git a/content/it/docs/concepts/cluster-administration/addons.md b/content/it/docs/concepts/cluster-administration/addons.md index 782ce4ecfa..a8bdc95478 100644 --- a/content/it/docs/concepts/cluster-administration/addons.md +++ b/content/it/docs/concepts/cluster-administration/addons.md @@ -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 diff --git a/content/ja/blog/_posts/2024-10-28-k8s-upstream-training-japan-spotlight/index.md b/content/ja/blog/_posts/2024-10-28-k8s-upstream-training-japan-spotlight/index.md index c333e2190e..82b3cddbbc 100644 --- a/content/ja/blog/_posts/2024-10-28-k8s-upstream-training-japan-spotlight/index.md +++ b/content/ja/blog/_posts/2024-10-28-k8s-upstream-training-japan-spotlight/index.md @@ -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周りの機能改善や開発とは具体的にどのようなものですか？ diff --git a/content/ja/docs/reference/glossary/network-policy.md b/content/ja/docs/reference/glossary/network-policy.md new file mode 100644 index 0000000000..acdf5d7228 --- /dev/null +++ b/content/ja/docs/reference/glossary/network-policy.md @@ -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同士やその他のネットワークエンドポイントとどのように通信することを許可されるかを定める規定。 + + + +ネットワークポリシーは、どのPodが互いに接続を許可されるか、どのNamespaceが通信を許可されるか、そしてより具体的には各ポリシーを適用するポート番号を宣言的に設定することができます。 +`NetworkPolicy`リソースはラベルを使用してPodを選択し、選択されたPodに対して許可するトラフィックを指定するルールを定義します。 +ネットワークポリシーはネットワークプロバイダーが提供するネットワークプラグインによって実装されます。 +ネットワークポリシーを実装するためのコントローラーを使用せずにネットワークリソースを作成しても効果がないことに注意してください。 diff --git a/content/ja/docs/reference/glossary/probe.md b/content/ja/docs/reference/glossary/probe.md new file mode 100644 index 0000000000..1b078e2728 --- /dev/null +++ b/content/ja/docs/reference/glossary/probe.md @@ -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" >}}が定期的に実行するチェック。 +コンテナの状態と正常性を定義し、コンテナのライフサイクルを通知します。 + + + +さらなる情報は[コンテナのProbe](/ja/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)を参照して下さい。 diff --git a/content/ja/docs/reference/glossary/rbac.md b/content/ja/docs/reference/glossary/rbac.md new file mode 100644 index 0000000000..06a73461ef --- /dev/null +++ b/content/ja/docs/reference/glossary/rbac.md @@ -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" >}}を通じてアクセスポリシーを動的に設定できるようにし、認可の判断を管理します。 + + + +RBACは、権限を含む*Role*と、Roleで定義された権限を一連のユーザーに付与する*RoleBinding*を使用します。 diff --git a/content/ja/docs/reference/glossary/replica.md b/content/ja/docs/reference/glossary/replica.md new file mode 100644 index 0000000000..ed64cb27b4 --- /dev/null +++ b/content/ja/docs/reference/glossary/replica.md @@ -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の同一インスタンスを維持することで、高い可用性、スケーラビリティ、耐障害性を保証します。 + + +Replicaは望まれるアプリケーションの状態と信頼性を達成するために、Kubernetesで広く使われています。 +これにより、クラスター内の複数ノード間に渡るワークロードのスケーリングと分散を可能にしています。 + +DeploymentやReplicaSetでReplicaの数を定義することで、Kubernetesは指定の数のインスタンスが実行されていることを保証し、必要に応じて自動的にその数を調整します。 + +Replicaを管理することで、Kubernetesクラスター内での効率的なロードバランスやローリングアップデート、自己修復を可能にしています。 diff --git a/content/ja/docs/reference/glossary/security-context.md b/content/ja/docs/reference/glossary/security-context.md new file mode 100644 index 0000000000..bc4b3ee107 --- /dev/null +++ b/content/ja/docs/reference/glossary/security-context.md @@ -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" >}}の権限とアクセス制御の設定を定義します。 + + + +`securityContext`では、プロセスを実行するユーザー、プロセスを実行するグループ、および権限の設定を定義できます。 +また、セキュリティポリシー(例：SELinux、AppArmor、seccomp)も設定できます。 + +`PodSpec.securityContext`の設定内容は、Pod内のすべてのコンテナに適用されます。 diff --git a/content/pl/_index.html b/content/pl/_index.html index f1982741a8..fe1a1a8a45 100644 --- a/content/pl/_index.html +++ b/content/pl/_index.html @@ -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

- Weź udział w KubeCon + CloudNativeCon Europe 19-22.03.2024 + Weź udział w KubeCon + CloudNativeCon North America 12-15.11.2024


+ Weź udział w KubeCon + CloudNativeCon India 11-12.12.2024
- Weź udział w KubeCon + CloudNativeCon North America 12-15.11.2024 +
+
+ Weź udział w KubeCon + CloudNativeCon Europe 1-4.4.2025
diff --git a/content/ru/docs/concepts/containers/_index.md b/content/ru/docs/concepts/containers/_index.md index e04cb3cdb1..0debadea70 100644 --- a/content/ru/docs/concepts/containers/_index.md +++ b/content/ru/docs/concepts/containers/_index.md @@ -30,4 +30,4 @@ no_list: true ## {{% heading "whatsnext" %}} * Раздел об [образах контейнеров](/docs/concepts/containers/images/). -* Раздел о [Pod'ах](/docs/concepts/workloads/pods/). +* Раздел о [Подах](/ru/docs/concepts/workloads/pods/). diff --git a/content/ru/docs/concepts/workloads/controllers/cron-jobs.md b/content/ru/docs/concepts/workloads/controllers/cron-jobs.md index 346cf6c7ce..526c072c9f 100644 --- a/content/ru/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ru/docs/concepts/workloads/controllers/cron-jobs.md @@ -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`. diff --git a/content/ru/docs/concepts/workloads/pods/_index.md b/content/ru/docs/concepts/workloads/pods/_index.md new file mode 100644 index 0000000000..80b7d2d50f --- /dev/null +++ b/content/ru/docs/concepts/workloads/pods/_index.md @@ -0,0 +1,397 @@ +--- +title: "Поды" +api_metadata: +- apiVersion: "v1" + kind: "Под" +content_type: concept +weight: 10 +no_list: true +--- + + + +_Поды_ (_Pods_) — это самые маленькие развертываемые вычислительные единицы, которые можно создавать и которыми +можно управлять в Kubernetes. + +_Под_ (от англ. «pod», что означает стаю китов или гороховый стручок) — это группа из одного или нескольких +{{< glossary_tooltip text="контейнеров" term_id="container" >}} с общими хранилищами и сетевыми ресурсами, +а также спецификация для запуска контейнеров. +Содержимое Пода всегда находится в одном месте, имеет совместное расписание и выполняется в общем +контексте. Под по своей сути представляется специфическим для приложения "логическим хостом": он содержит +один или несколько контейнеров приложений, которые относительно тесно связаны между собой. +Приложения вне облачной инфраструктуры, выполняемые на одной физической или виртуальной машине, +аналогичны облачным приложениям, выполняемым на одном логическом хосте. + +Помимо контейнеров приложений Под может содержать +{{< glossary_tooltip text="init-контейнеры" term_id="init-container" >}}, которые запускаются при +старте Пода. Вы также можете внедрить +{{< glossary_tooltip text="эфемерные контейнеры" term_id="ephemeral-container" >}} +для отладки запущенного Пода. + + + +## Что такое Под? {#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} + +Поды предназначены для поддержки нескольких взаимодействующих процессов (в виде контейнеров), которые +образуют единое целое. Контейнеры в Поде автоматически размещаются и планируются на одной и той же +физической или виртуальной машине в кластере. Контейнеры могут совместно использовать ресурсы и +зависимости, взаимодействовать друг с другом и координировать, когда и как они завершаются. + + + +Поды в кластере 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/). diff --git a/content/ru/docs/reference/glossary/api-eviction.md b/content/ru/docs/reference/glossary/api-eviction.md index 0ab35ae3fc..2a1df89ec9 100644 --- a/content/ru/docs/reference/glossary/api-eviction.md +++ b/content/ru/docs/reference/glossary/api-eviction.md @@ -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/{{}}/#create-eviction-pod-v1-core) -создается объект `Eviction`, который запускает корректное завершение работы Pod'а. + Вытеснение, инициированное через API, — процесс, при котором с помощью [Eviction API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) +создается объект `Eviction`, который запускает корректное завершение работы пода. -Вытеснение можно запросить через 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/). diff --git a/content/ru/docs/reference/glossary/cloud-controller-manager.md b/content/ru/docs/reference/glossary/cloud-controller-manager.md index 6910f5551a..f9a4af432c 100644 --- a/content/ru/docs/reference/glossary/cloud-controller-manager.md +++ b/content/ru/docs/reference/glossary/cloud-controller-manager.md @@ -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 поставщика облачных услуг и отделить компоненты, +взаимодействующие с этой облачной платформой, от компонентов, +взаимодействующих только с вашим кластером. -Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой, компонент cloud-controller-manager позволяет поставщикам облачных услуг выпускать функции в другом темпе по сравнению с основным проектом Kubernetes. - +Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой, +компонент cloud-controller-manager позволяет поставщикам облачных услуг +выпускать функции, не привязываясь к релизам основного проекта Kubernetes. diff --git a/content/ru/docs/reference/glossary/cloud-provider.md b/content/ru/docs/reference/glossary/cloud-provider.md index 696c9116b7..ecd6fe27cb 100644 --- a/content/ru/docs/reference/glossary/cloud-provider.md +++ b/content/ru/docs/reference/glossary/cloud-provider.md @@ -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: -Облачные Провайдеры, иногда называемые Поставщиками Облачных Услуг (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="узлы" >}} и инфраструктуру, на которую они полагаются: diff --git a/content/ru/docs/reference/glossary/cluster.md b/content/ru/docs/reference/glossary/cluster.md index 365ceb277b..ddbbc94a51 100644 --- a/content/ru/docs/reference/glossary/cluster.md +++ b/content/ru/docs/reference/glossary/cluster.md @@ -4,14 +4,14 @@ id: cluster date: 2019-06-15 full_link: short_description: > - Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел. + Набор рабочих машин, называемых узлами, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел. aka: tags: - fundamental - operation --- -Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел. +Набор рабочих машин, называемых узлами, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел. -В рабочих узлах размещены поды, являющиеся компонентами приложения. Управляющий слой (control plane) управляет рабочими узлами и подами в кластере. В промышленных средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность. +В рабочих узлах размещены поды, которые являются компонентами приложения. {{< glossary_tooltip text="Управляющий слой" term_id="control-plane" >}} управляет рабочими узлами и подами в кластере. В production-средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую доступность. diff --git a/content/ru/docs/reference/glossary/container-runtime.md b/content/ru/docs/reference/glossary/container-runtime.md index 8c6b54cbd5..b6075865df 100644 --- a/content/ru/docs/reference/glossary/container-runtime.md +++ b/content/ru/docs/reference/glossary/container-runtime.md @@ -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. -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). diff --git a/content/ru/docs/reference/glossary/container.md b/content/ru/docs/reference/glossary/container.md index 7c2e66e4d1..416f1edea7 100644 --- a/content/ru/docs/reference/glossary/container.md +++ b/content/ru/docs/reference/glossary/container.md @@ -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 --- - Переносимый и не требовательный к ресурсам исполняемый экземпляр образа, содержащий приложение вместе со всеми его зависимостями. + Легковесный и переносимый исполняемый образ, содержащий программное обеспечение вместе со всеми его зависимостями. -Контейнеры изолирует приложения от инфраструктуры хост-машины, чтобы обеспечить простое масштабирование и упростить развёртывание в различных средах облачных платформ или операционных систем. +Контейнеры изолируют приложения от инфраструктуры хост-машины, чтобы обеспечить простое развёртывание в различных средах облачных платформ и операционных систем, а также упростить масштабирование. +Приложения, запускаемые внутри контейнеров, называются контейнеризированными приложениями. Процесс упаковки этих приложений и их зависимостей в образ контейнера называется контейнеризацией. diff --git a/content/ru/docs/reference/glossary/containerd.md b/content/ru/docs/reference/glossary/containerd.md index 251bebcd20..8d7a279c81 100644 --- a/content/ru/docs/reference/glossary/containerd.md +++ b/content/ru/docs/reference/glossary/containerd.md @@ -4,14 +4,14 @@ id: containerd date: 2019-05-14 full_link: https://containerd.io/docs/ short_description: > - Среда выполнения контейнера с упором на простоту, надежность и переносимость + Исполняемая среда для контейнеров с фокусом на простоту, надежность и переносимость aka: tags: - tool --- - Среда выполнения контейнера с упором на простоту, надежность и переносимость + Исполняемая среда для контейнеров с фокусом на простоту, надежность и переносимость. -containerd — среда выполнения {{< glossary_tooltip text="контейнера" term_id="container" >}}, который представляет собой демон для Linux или Windows. containerd заботится о получении и хранении образов контейнеров, запуске контейнеров, осуществлять доступ по сети и т.д. +containerd — исполяемая среда для {{< glossary_tooltip text="контейнеров" term_id="container" >}}, который запускается как демон в Linux или Windows. containerd заботится о получении и хранении образов контейнеров, запуске контейнеров, предоставлении сетевого доступа и т.д. diff --git a/content/ru/docs/reference/glossary/control-plane.md b/content/ru/docs/reference/glossary/control-plane.md index 98653864c3..865bfe015d 100644 --- a/content/ru/docs/reference/glossary/control-plane.md +++ b/content/ru/docs/reference/glossary/control-plane.md @@ -4,10 +4,10 @@ id: control-plane date: 2019-05-12 full_link: short_description: > - Уровень оркестрации контейнеров с API и интерфейсами для определения, развёртывания и управления жизненным циклом контейнеров. + Уровень оркестрации контейнеров, предоставляющий API и интерфейсы для определения, развёртывания и управления жизненным циклом контейнеров. aka: tags: - fundamental --- - Уровень оркестрации контейнеров с API и интерфейсами для определения, развёртывания и управления жизненным циклом контейнеров. + Уровень оркестрации контейнеров, предоставляющий API и интерфейсы для определения, развёртывания и управления жизненным циклом контейнеров. diff --git a/content/ru/docs/reference/glossary/controller.md b/content/ru/docs/reference/glossary/controller.md index 9d5f71cc0e..dc4e0bccb3 100644 --- a/content/ru/docs/reference/glossary/controller.md +++ b/content/ru/docs/reference/glossary/controller.md @@ -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" >}}. diff --git a/content/ru/docs/reference/glossary/cri-o.md b/content/ru/docs/reference/glossary/cri-o.md index 1b99ac947c..362f14df14 100644 --- a/content/ru/docs/reference/glossary/cri-o.md +++ b/content/ru/docs/reference/glossary/cri-o.md @@ -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. -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 из удаленных реестров. diff --git a/content/ru/docs/reference/glossary/cri.md b/content/ru/docs/reference/glossary/cri.md index 2f47ddc915..d90546f8d8 100644 --- a/content/ru/docs/reference/glossary/cri.md +++ b/content/ru/docs/reference/glossary/cri.md @@ -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 на узле. -Для получения дополнительной информации смотрите 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). diff --git a/content/ru/docs/reference/glossary/daemonset.md b/content/ru/docs/reference/glossary/daemonset.md index b0e4ca6195..6f03c161e1 100644 --- a/content/ru/docs/reference/glossary/daemonset.md +++ b/content/ru/docs/reference/glossary/daemonset.md @@ -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" >}}. -Используется для развертывания системных демонов, таких как сборщики логов и агенты мониторинга, которые, как правило, должны работать на каждом {{< glossary_tooltip text="узла" term_id="node" >}}. +Используется для развертывания системных демонов, таких как сборщики логов и агенты мониторинга, которые, как правило, должны работать на каждом {{< glossary_tooltip text="узле" term_id="node" >}}. diff --git a/content/ru/docs/reference/glossary/deployment.md b/content/ru/docs/reference/glossary/deployment.md index 26c9aedcd8..56feec154e 100644 --- a/content/ru/docs/reference/glossary/deployment.md +++ b/content/ru/docs/reference/glossary/deployment.md @@ -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). -Каждая реплика представляет {{< glossary_tooltip term_id="pod" >}}, а все Pod-объекты распределяются по узлам кластера. - +Каждая реплика представлена {{< glossary_tooltip text="подом" term_id="pod" >}}, +а все поды распределяются по {{< glossary_tooltip text="узлам" term_id="node" >}} кластера. +Для рабочих нагрузок, требующих локальное хранение данных, стоит обратить внимание на {{< glossary_tooltip term_id="StatefulSet" >}}. diff --git a/content/ru/docs/reference/glossary/docker.md b/content/ru/docs/reference/glossary/docker.md index 290b6d3c60..ba6a8afa97 100644 --- a/content/ru/docs/reference/glossary/docker.md +++ b/content/ru/docs/reference/glossary/docker.md @@ -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" >}}. -Docker использует возможности изоляции ресурсов ядра Linux, такие как cgroups и пространства имен ядра, а также каскадно-объединённую файловую систему, например, OverlayFS и другие, чтобы независимые друг от друга контейнеры могли работать в одном экземпляре Linux без накладных расходов на запуск и поддержку работы виртуальных машин (VM). +Docker использует возможности изоляции ресурсов ядра Linux, такие как cgroups и пространства имен ядра, а также каскадную файловую систему (например, OverlayFS или другие), чтобы независимые контейнеры могли работать в одном экземпляре Linux без накладных расходов на запуск и поддержку работы виртуальных машин (VM). diff --git a/content/ru/docs/reference/glossary/etcd.md b/content/ru/docs/reference/glossary/etcd.md index cb3ac286d7..db090bb411 100644 --- a/content/ru/docs/reference/glossary/etcd.md +++ b/content/ru/docs/reference/glossary/etcd.md @@ -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. diff --git a/content/ru/docs/reference/glossary/garbage-collection.md b/content/ru/docs/reference/glossary/garbage-collection.md index defcd10476..8e2994c8cf 100644 --- a/content/ru/docs/reference/glossary/garbage-collection.md +++ b/content/ru/docs/reference/glossary/garbage-collection.md @@ -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 для очистки ресурсов кластера. 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. \ No newline at end of file +[завершенные задачи](/docs/concepts/workloads/controllers/ttlafterfinished/) и ресурсы, +время работы которых истекло или которые завершились ошибкой. diff --git a/content/ru/docs/reference/glossary/kube-apiserver.md b/content/ru/docs/reference/glossary/kube-apiserver.md index 24d3a33587..1dcb1f6897 100644 --- a/content/ru/docs/reference/glossary/kube-apiserver.md +++ b/content/ru/docs/reference/glossary/kube-apiserver.md @@ -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. Основной реализацией API-сервера Kubernetes является [kube-apiserver](/docs/reference/generated/kube-apiserver/). -kube-apiserver предназначен для горизонтального масштабирования, то есть развёртывание на несколько экземпляров. -Вы можете запустить несколько экземпляров kube-apiserver и сбалансировать трафик между этими экземплярами. +kube-apiserver предназначен для горизонтального масштабирования, то есть он масштабируется при развёртывании +на множестве экземплярах. Вы можете запускать множество экземпляров kube-apiserver и балансировать трафик между ними. diff --git a/content/ru/docs/reference/glossary/kube-controller-manager.md b/content/ru/docs/reference/glossary/kube-controller-manager.md index d1cb711164..41897bbfb5 100644 --- a/content/ru/docs/reference/glossary/kube-controller-manager.md +++ b/content/ru/docs/reference/glossary/kube-controller-manager.md @@ -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" >}}. -Вполне логично, что каждый {{< glossary_tooltip text="контроллер" term_id="controller" >}} в свою очередь представляет собой отдельный процесс, и для упрощения все такие процессы скомпилированы в один двоичный файл и выполняются в одном процессе. +С логической точки зрения каждый {{< glossary_tooltip text="контроллер" term_id="controller" >}} представляет собой отдельный процесс. Но для упрощения все они скомпилированы в один бинарный файл и выполняются в одном процессе. diff --git a/content/ru/docs/reference/glossary/kube-proxy.md b/content/ru/docs/reference/glossary/kube-proxy.md index 2858f60403..1b278dd67b 100644 --- a/content/ru/docs/reference/glossary/kube-proxy.md +++ b/content/ru/docs/reference/glossary/kube-proxy.md @@ -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. -kube-proxy конфигурирует правила сети на узлах. При помощи них разрешаются сетевые подключения к вашими подам изнутри и снаружи кластера. +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) поддерживает сетевые правила на узлах. Эти правила разрешают сетевое взаимодействие с вашимии подами из сетевых сессий внутри и снаружи кластера. -kube-proxy использует уровень фильтрации пакетов в операционной системы, если он доступен. В противном случае, kube-proxy сам обрабатывает передачу сетевого трафика. \ No newline at end of file +kube-proxy использует уровень фильтрации пакетов операционной системы, если он доступен. В ином случае kube-proxy сам перенаправляет трафик. diff --git a/content/ru/docs/reference/glossary/kube-scheduler.md b/content/ru/docs/reference/glossary/kube-scheduler.md index 0f9c7c42e8..4743cff30f 100644 --- a/content/ru/docs/reference/glossary/kube-scheduler.md +++ b/content/ru/docs/reference/glossary/kube-scheduler.md @@ -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), который отслеживает недавно созданные поды без назначенного для них узла и выбирает узел, на котором они должны работать. - - -При планировании развёртывания подов на узлах учитываются множество факторов, включая требования к ресурсам, ограничения, связанные с аппаратными/программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) узлов/подов, местонахождения данных, предельных сроков. +При планировании учитываются множество факторов, включая индивидуальные +и общие требования к ресурсам, ограничения по железу/программному обеспечению/политикам, +конфигурация принадлежности (affinity) и непринадлежности (anti-affinity) +узлов/подов, местонахождение данных, взаимодействие между рабочими +нагрузками и дедлайны. diff --git a/content/ru/docs/reference/glossary/kubelet.md b/content/ru/docs/reference/glossary/kubelet.md index 0aadf8ed29..522e6c2053 100644 --- a/content/ru/docs/reference/glossary/kubelet.md +++ b/content/ru/docs/reference/glossary/kubelet.md @@ -15,4 +15,4 @@ tags: -Утилита kubelet принимает набор PodSpecs, и гарантирует работоспособность и исправность определённых в них контейнеров. Агент kubelet не отвечает за контейнеры, не созданные Kubernetes. +[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) принимает набор PodSpecs, которые определяются разными способами и гарантируют работоспособность и исправность определённых в них контейнеров. Kubelet не отвечает за контейнеры, не созданные Kubernetes. diff --git a/content/ru/docs/reference/glossary/label.md b/content/ru/docs/reference/glossary/label.md index 287fd32528..d2b0251df8 100644 --- a/content/ru/docs/reference/glossary/label.md +++ b/content/ru/docs/reference/glossary/label.md @@ -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 --- - Группирует объекты на основе произвольных критериев, по которым пользователи могут их идентифицировать. + Тегирует объекты произвольными метками, которые идентифицируют их и имеют смысл для пользователей. -Метки — это пары "ключ-значение", которые прикрепляются к таким объектам, как {{< glossary_tooltip text="Pod" term_id="pod" >}}. Они используются для организации и получения подмножеств объектов. +Лейблы — это пары «ключ-значение», которые прикрепляются к таким объектам, как {{< glossary_tooltip text="под" term_id="pod" >}}. Они используются для организации и получения подмножеств объектов. diff --git a/content/ru/docs/reference/glossary/name.md b/content/ru/docs/reference/glossary/name.md index 97d9873b82..536e39a830 100644 --- a/content/ru/docs/reference/glossary/name.md +++ b/content/ru/docs/reference/glossary/name.md @@ -14,4 +14,4 @@ tags: -Указанное имя может иметь только один объект определённого типа. Но если вы удалите этот объект, вы можете создать новый с таким же именем +Указанное имя может иметь только один объект определённого типа. Но если вы удалите этот объект, вы можете создать новый с таким же именем. diff --git a/content/ru/docs/reference/glossary/node.md b/content/ru/docs/reference/glossary/node.md index f359bc4227..11d0b5c139 100644 --- a/content/ru/docs/reference/glossary/node.md +++ b/content/ru/docs/reference/glossary/node.md @@ -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. -Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< 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). diff --git a/content/ru/docs/reference/glossary/object.md b/content/ru/docs/reference/glossary/object.md index 8308412290..0bb572d172 100644 --- a/content/ru/docs/reference/glossary/object.md +++ b/content/ru/docs/reference/glossary/object.md @@ -12,7 +12,7 @@ tags: Сущность в системе Kubernetes. Kubernetes использует их для представления состояния кластера. Объект Kubernetes обычно представляет собой «запись о намерениях»: как только объект создан, -{{< glossary_tooltip text="слой управления" term_id="control-plane" >}} Kubernetes обеспечивает гарантию того, +{{< glossary_tooltip text="управляющий слой" term_id="control-plane" >}} Kubernetes обеспечивает гарантию того, что элемент, который этот объект представляет, действительно существует. Создавая объект, вы фактически указываете системе Kubernetes, как должна выглядеть эта часть рабочей нагрузки кластера; это желаемое состояние вашего кластера. diff --git a/content/ru/docs/reference/glossary/pod-disruption.md b/content/ru/docs/reference/glossary/pod-disruption.md index e2a0a0f3db..1ad72af84b 100644 --- a/content/ru/docs/reference/glossary/pod-disruption.md +++ b/content/ru/docs/reference/glossary/pod-disruption.md @@ -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/) — процесс, +в ходе которого происходит плановое или внеплановое (принудительное) завершение работы подов на узлах. -Плановое завершение работы Pod'ов инициируется владельцами приложений или администраторами +Плановое завершение работы подов инициируется владельцами приложений или администраторами кластера. Внеплановое завершение работы обычно вызвано непредвиденными обстоятельствами различной природы, -например, с недостатком ресурсов на узлах или случайными удалениями. +например, недостатком ресурсов на узлах или случайными удалениями. diff --git a/content/ru/docs/reference/glossary/pod.md b/content/ru/docs/reference/glossary/pod.md index d00f3225a4..53a42f75a4 100644 --- a/content/ru/docs/reference/glossary/pod.md +++ b/content/ru/docs/reference/glossary/pod.md @@ -15,4 +15,4 @@ tags: -Как правило, один под предназначен для выполнения одного основного контейнера. Он также может запускать дополнительные "прицепные" (sidecar) контейнеры, добавляющие новые функциональные возможности, например, логирование. Контейнеры обычно управляются {{< glossary_tooltip term_id="deployment" >}}. +Как правило, один под предназначен для выполнения одного основного контейнера. Он также может запускать вспомогательные («прицепные») sidecar-контейнеры, добавляющие новые функциональные возможности, например, логирование. Поды обычно управляются {{< glossary_tooltip text="деплойментом" term_id="deployment" >}}. diff --git a/content/ru/docs/reference/glossary/secret.md b/content/ru/docs/reference/glossary/secret.md index 4abf91292d..c4e7b7b1f7 100644 --- a/content/ru/docs/reference/glossary/secret.md +++ b/content/ru/docs/reference/glossary/secret.md @@ -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. -Позволяет повысить контроль над использованием конфиденциальной информации и снизить риск ее случайного раскрытия. Секретные значения кодируются в формат 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/). diff --git a/content/ru/docs/reference/glossary/selector.md b/content/ru/docs/reference/glossary/selector.md index 4eef4299f0..f4a57cca96 100644 --- a/content/ru/docs/reference/glossary/selector.md +++ b/content/ru/docs/reference/glossary/selector.md @@ -4,15 +4,15 @@ id: selector date: 2018-04-12 full_link: /docs/concepts/overview/working-with-objects/labels/ short_description: > - Позволяет пользователям фильтровать список ресурсов по меткам. + Позволяет пользователям фильтровать список ресурсов по лейблам. aka: tags: - fundamental --- - Позволяет пользователям фильтровать список ресурсов по меткам. + Позволяет пользователям фильтровать список ресурсов по лейблам. -Селекторы применяются при создании запросов для фильтрации списков ресурсов по {{< glossary_tooltip text="меткам" term_id="label" >}}. +Селекторы применяются при создании запросов для фильтрации списков ресурсов по {{< glossary_tooltip text="лейблам" term_id="label" >}}. diff --git a/content/ru/docs/reference/glossary/service-account.md b/content/ru/docs/reference/glossary/service-account.md index 87abd6a193..055d3f41cd 100644 --- a/content/ru/docs/reference/glossary/service-account.md +++ b/content/ru/docs/reference/glossary/service-account.md @@ -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" >}}. -Процессы внутри 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" >}}. diff --git a/content/ru/docs/reference/glossary/service.md b/content/ru/docs/reference/glossary/service.md index 1f4d4736c1..222a38a720 100644 --- a/content/ru/docs/reference/glossary/service.md +++ b/content/ru/docs/reference/glossary/service.md @@ -15,4 +15,8 @@ tags: -Набор подов, из которых состоит сервис, определяется (как правило) {{< glossary_tooltip text="селектором" term_id="selector" >}}. При добавлении или удалении подов, набор подов, соответствующий селектору, изменится. Сервис обеспечивает, что сетевой трафик может быть направлен на текущий набор подов для планирования рабочей нагрузки. +Набор подов, из которых состоит сервис, определяется (как правило) {{< glossary_tooltip text="селектором" term_id="selector" >}}. Если поды добавляются или удаляются, набор подов, соответствующий селектору, изменится. Сервис гарантирует, что сетевой трафик может быть направлен на текущий набор подов у рабочей нагрузки. + +Сервисы Kubernetes используют либо IP-сеть (IPv4, IPv6 или оба), либо ссылаются на внешнее имя в системе DNS (Domain Name System). + +Абстракция сервиса позволяет работать другим механизмам, такие как Ingress и Gateway. diff --git a/content/ru/docs/reference/glossary/uid.md b/content/ru/docs/reference/glossary/uid.md index fe050683ba..421166cdf2 100644 --- a/content/ru/docs/reference/glossary/uid.md +++ b/content/ru/docs/reference/glossary/uid.md @@ -14,4 +14,4 @@ tags: -У каждого объекта, созданного в течение всего периода работы кластера Kubernetes, есть собственный уникальный идентификатор (UID). Он предназначен для выяснения различий между событиями похожих сущностей. \ No newline at end of file +У каждого объекта, созданного в течение всего периода работы кластера Kubernetes, есть собственный уникальный идентификатор (UID). Он предназначен для различения схожих сущностей, существовавших в кластере в разное время. diff --git a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md index 7a638efe30..911fe23ed7 100644 --- a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md +++ b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md @@ -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 运行，那么该容器就可以尝试使用更多的内存。 -如果你将某容器的 `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` 限制通过 CPU 节流机制来强制执行。 +当某容器接近其 `cpu` 限制值时，内核会基于容器的限制值来限制其对 CPU 的访问。 +因此，`cpu` 限制是内核强制执行的一个硬性限制。容器不得使用超出其 `cpu` 限制所指定的 CPU 核数。 + + +`memory` 限制由内核使用 OOM（内存溢出）终止机制来强制执行。 +当某容器使用的内存超过其 `memory` 限制时，内核可以终止此容器。 +然而，终止只会在内核检测到内存压力时才会发生。 +因此，超配内存的容器可能不会被立即终止。 +这意味着 `memory` 限制是被动执行的。 +某容器可以使用超过其 `memory` 限制的内存，但如果这样做，此容器可能会被终止。 + +{{< note >}} + +你可以使用一个 Alpha 特性 `MemoryQoS` 来尝试为内存添加执行更多的抢占限制 +（这与 OOM Killer 的被动执行相反）。然而，由于可能会因内存饥饿造成活锁情形， +所以这种尝试操作会被[卡滞](https://github.com/kubernetes/enhancements/tree/a47155b340/keps/sig-node/2570-memory-qos#latest-update-stalled)。 +{{< /note >}} {{< note >}} -## 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 中各容器对该类型资源的请求/限制的总和。 你也可以表达带小数 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”。 有些人说成是“一百毫核”，其实说的是同样的事情。 CPU 资源总是设置为资源的绝对数量而非相对数量值。 -例如，无论容器运行在单核、双核或者 48-核的机器上，`500m` CPU 表示的是大约相同的计算能力。 +例如，无论容器运行在单核、双核或者 48 核的机器上，`500m` CPU 表示的是大约相同的算力。 {{< note >}} - CPU 限制定义的是容器可使用的 CPU 时间的硬性上限。 在每个调度周期（时间片）期间，Linux 内核检查是否已经超出该限制； - 内核会在允许该 cgroup 恢复执行之前会等待。 + 内核会在允许该 CGroup 恢复执行之前会等待。 -- CPU 请求值定义的是一个权重值。如果若干不同的容器（CGroups）需要在一个共享的系统上竞争运行， +- CPU 请求值定义的是一个权重值。如果若干不同的容器（CGroup）需要在一个共享的系统上竞争运行， CPU 请求值大的负载会获得比请求值小的负载更多的 CPU 时间。 -- 内存限制定义的是 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 的内存限制。 -`matchLabelKeys` 字段是一个 Beta 级别的字段，在 Kubernetes {{< skew currentVersion >}} 中默认被禁用。 +`matchLabelKeys` 字段是一个 Beta 级别的字段，在 Kubernetes {{< skew currentVersion >}} 中默认被启用。 当你想要禁用此字段时，你必须通过 `MatchLabelKeysInPodAffinity` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)禁用它。 {{< /note >}} diff --git a/content/zh-cn/docs/concepts/storage/storage-classes.md b/content/zh-cn/docs/concepts/storage/storage-classes.md index 00774b02b0..a70da93e23 100644 --- a/content/zh-cn/docs/concepts/storage/storage-classes.md +++ b/content/zh-cn/docs/concepts/storage/storage-classes.md @@ -403,6 +403,11 @@ supported plugins. {{% code_sample language="yaml" file="storage/storageclass/storageclass-topology.yaml" %}} + +`tagSpecification`：具有此前缀的标签适用于动态配置的 EBS 卷。 + -### 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 >}} #### hostPath 配置示例 +{{< tabs name="hostpath_examples" >}} + -{{< tabs name="hostpath_examples" >}} + {{< tab name="Linux 节点" codelang="yaml" >}} --- # 此清单将主机上的 /data/foo 挂载为 hostpath-example-linux Pod 中运行的单个容器内的 /foo @@ -831,15 +850,32 @@ spec: {{< tab name="Windows 节点" codelang="yaml" >}} --- @@ -899,7 +935,34 @@ Here's the example manifest: 以下是清单示例： ```yaml apiVersion: v1 @@ -1307,7 +1370,25 @@ Here is an example Pod referencing a pre-provisioned Portworx volume: 下面是一个引用预先配备的 Portworx 卷的示例 Pod： ```yaml apiVersion: v1 @@ -1432,7 +1513,7 @@ receive Secret updates. -更多详情请参考[配置 Secrets](/zh-cn/docs/concepts/configuration/secret/)。 +更多详情请参考[配置 Secret](/zh-cn/docs/concepts/configuration/secret/)。 ```yaml apiVersion: v1 diff --git a/content/zh-cn/docs/contribute/participate/issue-wrangler.md b/content/zh-cn/docs/contribute/participate/issue-wrangler.md index 3a5328c31d..88cebcbc4d 100644 --- a/content/zh-cn/docs/contribute/participate/issue-wrangler.md +++ b/content/zh-cn/docs/contribute/participate/issue-wrangler.md @@ -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 ``` diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md index 07d8349f47..088e7277d4 100644 --- a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md +++ b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/disable-cloud-providers.md @@ -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" diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/dynamic-resource-allocation.md b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/dynamic-resource-allocation.md index 5588aff34a..c0f74c7046 100644 --- a/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/dynamic-resource-allocation.md +++ b/content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/dynamic-resource-allocation.md @@ -8,7 +8,7 @@ _build: stages: - stage: alpha defaultValue: false - fromVersion: "1.30" + fromVersion: "1.26" --- -下表包含所有 kubectl 操作的简短描述和普通语法： +下表包含所有 `kubectl` 操作的简短描述和普通语法： -使用以下示例集来帮助你熟悉运行常用 kubectl 操作： +使用以下示例集来帮助你熟悉运行常用 `kubectl` 操作： ``` ::= - (注意 可能为空，例如 的 "" 情形。)
- ::= 0 | 1 | ... | 9
- ::= |
- ::= | . | . | .
- ::= "+" | "-"
- ::= |
- ::= | |
- ::= Ki | Mi | Gi | Ti | Pi | Ei - (国际单位制度；查阅： http://physics.nist.gov/cuu/Units/binary.html)
- ::= m | "" | k | M | G | T | P | E - (注意，1024 = 1ki 但 1000 = 1k；我没有选择大写。)
- ::= "e" | "E"
+ +（注意 可能为空，例如 的 "" 情形。） + + ::= 0 | 1 | ... | 9 + ::= | + ::= | . | . | . + ::= "+" | "-" + ::= | + ::= | | + ::= Ki | Mi | Gi | Ti | Pi | Ei + +（国际单位制度；查阅： http://physics.nist.gov/cuu/Units/binary.html） + + ::= m | "" | k | M | G | T | P | E + +（注意，1024 = 1ki 但 1000 = 1k；我没有选择大写。） + + ::= "e" | "E" ``` 如果 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 Buy your ticket now! 12 - 15 November | Salt Lake City + +- 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: | + + KubeCon + CloudNativeCon 2024 + message: | + Join us for two days of incredible opportunities to collaborate, learn and share with the cloud native community.
+ + Buy your ticket now! 11 - 12 December | Delhi, India + diff --git a/static/css/gridpage.css b/static/css/gridpage.css index 8972039543..50d15fd671 100644 --- a/static/css/gridpage.css +++ b/static/css/gridpage.css @@ -39,6 +39,10 @@ font-weight: 300 !important; } +.gridPage .case-study .quote{ + color: rgb(26,26,26); + } + .gridPage #mainContent { padding: 0; } diff --git a/static/images/announcements/kccnc-india-2024-white.svg b/static/images/announcements/kccnc-india-2024-white.svg new file mode 100644 index 0000000000..f7e43617fd --- /dev/null +++ b/static/images/announcements/kccnc-india-2024-white.svg @@ -0,0 +1 @@ + \ No newline at end of file