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

Merge pull request #47986 from chanieljdan/merged-main-dev-1.32 

Merge main branch into dev 1.32
pull/48008/head
Kubernetes Prow Robot 2024-09-19 09:38:45 +01:00 committed by GitHub
parent 831e8a9e8d f005d8cd8b
commit f9610cd94d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
981 changed files with 95596 additions and 17737 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
.github/workflows/update-schedule.yml vendored Normal file
View File

@ -0,0 +1,52 @@
name: Update schedule.yaml
on:
workflow_dispatch:
schedule:
- cron: '0 0 * * *' # daily
jobs:
create-pull-request:
name: Create PR (if required)
permissions:
contents: write
pull-requests: write
if: github.repository == 'kubernetes/website'
runs-on: ubuntu-latest
steps:
- name: Check out repository code
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0
- uses: actions/setup-go@0c52d547c9bc32b1aa3301fd7a9cb496313a4491 # v5.0.0
with:
go-version: '1.22'
check-latest: true
- name: Install schedule-builder
run: go install k8s.io/release/cmd/schedule-builder@v0.16.9
- name: Update schedule.yaml
run: schedule-builder -uc data/releases/schedule.yaml -e data/releases/eol.yaml
- name: Check workspace
id: create_pr
run: |
if [[ $(git diff --stat) != '' ]]; then
echo "create_pr=true" >> "$GITHUB_OUTPUT"
fi
- name: Create Pull Request
uses: peter-evans/create-pull-request@70a41aba780001da0a30141984ae2a0c95d8704e # v6.0.2
if: ${{ steps.create_pr.outputs.create_pr == 'true' }}
with:
token: ${{ secrets.GITHUB_TOKEN }}
commit-message: Update schedule.yaml
title: Update release schedule.yaml
body: |
Update release schedule.yaml
/cc @kubernetes/release-managers
labels: area/release-eng, sig/release, sig/docs
branch: update-schedule
delete-branch: true
signoff: true

4
Dockerfile
View File

@ -4,7 +4,7 @@
# change is that the Hugo version is now an overridable argument rather than a fixed
# environment variable.
FROM docker.io/library/golang:1.20-alpine
FROM docker.io/library/golang:1.23.0-alpine3.20
LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"
@ -24,7 +24,7 @@ RUN mkdir $HOME/src && \
cd "hugo-${HUGO_VERSION}" && \
go install --tags extended
FROM docker.io/library/golang:1.20-alpine
FROM docker.io/library/golang:1.23.0-alpine3.20
RUN apk add --no-cache \
runuser \

2
Makefile
View File

@ -81,7 +81,7 @@ container-push: container-image ## Push container image for the preview of the w
PLATFORMS ?= linux/arm64,linux/amd64
docker-push: ## Build a multi-architecture image and push that into the registry
docker run --rm --privileged tonistiigi/binfmt:qemu-v6.2.0-26@sha256:5bf63a53ad6222538112b5ced0f1afb8509132773ea6dd3991a197464962854e --install all
docker run --rm --privileged tonistiigi/binfmt:qemu-v8.1.5-43@sha256:46c5a036f13b8ad845d6703d38f8cce6dd7c0a1e4d42ac80792279cabaeff7fb --install all
docker version
$(DOCKER_BUILDX) version
$(DOCKER_BUILDX) inspect image-builder > /dev/null 2>&1 || $(DOCKER_BUILDX) create --name image-builder --use

1
OWNERS_ALIASES
View File

@ -108,6 +108,7 @@ aliases:
- bishal7679
- dipesh-rawat
- divya-mohan0209
- niranjandarshann
sig-docs-id-owners: # Admins for Indonesian content
- ariscahyadi
- danninov

2
README-bn.md
View File

@ -186,7 +186,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
| Name | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
| Sreeram Venkitesh | @sreeram.venkitesh | @sreeram-venkitesh |
## Localization READMEs

1
README-es.md
View File

@ -36,7 +36,6 @@ El sitio web de Kubernetes utiliza Docsy Hugo theme. Se sugiere que se instale s
```bash
# pull de los submódulos del repositorio
git submodule update --init --recursive --depth 1
```
Si identifica que `git` reconoce una cantidad innumerable de cambios nuevos en el proyecto, la forma más simple de solucionarlo es cerrando y volviendo a abrir el proyecto en el editor. Los submódulos son automáticamente detectados por `git`, pero los plugins usados por los editores pueden tener dificultades para ser cargados.

7
README-ja.md
View File

@ -64,16 +64,19 @@ make container-serve
ローカルで依存関係をインストールし、サイトを構築してテストするには、次のコマンドを実行します。
- For macOS and Linux
```bash
npm ci
make serve
```
- For Windows (PowerShell)
```powershell
npm ci
hugo.exe server --buildFuture --environment development
```
これで、Hugoのサーバーが1313番ポートを使って起動します。使用しているブラウザで<http://localhost:1313>にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
## API reference pagesをビルドする
@ -196,7 +199,7 @@ Kubernetesのドキュメントへの貢献に関する詳細については以
| 名前 | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
| Sreeram Venkitesh | @sreeram.venkitesh | @sreeram-venkitesh |
## 翻訳された`README.md`一覧 {#localization-readmemds}

2
README-ko.md
View File

@ -173,7 +173,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
| Name | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
| Sreeram Venkitesh | @sreeram.venkitesh | @sreeram-venkitesh |
# `README.md`에 대한 쿠버네티스 문서 현지화(localization) {#localization-readmemds}

2
README-pt.md
View File

@ -187,7 +187,7 @@ Caso você precise de ajuda em algum momento ao contribuir, os [Embaixadores par
| Nome | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
| Sreeram Venkitesh | @sreeram.venkitesh | @sreeram-venkitesh |
## Traduções do `README.md`

2
README-uk.md
View File

@ -186,7 +186,7 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
| Імʼя | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
| Sreeram Venkitesh | @sreeram.venkitesh | @sreeram-venkitesh |
## Локалізовані файли README

2
README-vi.md
View File

@ -194,7 +194,7 @@ Nếu bạn cần trợ giúp bất kỳ lúc nào khi đóng góp, [Đại sứ
| Name | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
| Sreeram Venkitesh | @sreeram.venkitesh | @sreeram-venkitesh |
## Các tệp README đa ngôn ngữ

7
README-zh.md
View File

@ -429,13 +429,14 @@ If you need help at any point when contributing, the [New Contributor Ambassador
SIG Docs 的当前新贡献者大使：
<!--
| Name | Slack | GitHub |
| Name | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
| Sreeram Venkitesh | @sreeram.venkitesh | @sreeram-venkitesh |
-->
| 姓名 | Slack | GitHub |
| -------------------------- | -------------------------- | -------------------------- |
| Arsh Sharma | @arsh | @RinkiyaKeDad |
| Sreeram Venkitesh | @sreeram.venkitesh | @sreeram-venkitesh |
<!--
## Localization READMEs

5
README.md
View File

@ -33,12 +33,14 @@ cd website
The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following:
### Windows
```powershell
# fetch submodule dependencies
git submodule update --init --recursive --depth 1
```
### Linux / other Unix
```bash
# fetch submodule dependencies
make module-init
@ -62,11 +64,14 @@ Open up your browser to <http://localhost:1313> to view the website. As you make
To install dependencies, deploy and test the site locally, run:
- For macOS and Linux
```bash
npm ci
make serve
```
- For Windows (PowerShell)
```powershell
npm ci
hugo.exe server --buildFuture --environment development

11201
api-ref-assets/api/swagger.json
View File

File diff suppressed because it is too large Load Diff

83
api-ref-assets/config/fields.yaml
View File

@ -63,14 +63,16 @@
- definition: io.k8s.api.core.v1.PodSecurityContext
field_categories:
- fields:
- appArmorProfile
- fsGroup
- fsGroupChangePolicy
- runAsUser
- runAsNonRoot
- runAsGroup
- supplementalGroups
- fsGroup
- fsGroupChangePolicy
- seccompProfile
- seLinuxOptions
- supplementalGroups
- supplementalGroupsPolicy
- sysctls
- windowsOptions
@ -166,30 +168,36 @@
- definition: io.k8s.api.core.v1.SecurityContext
field_categories:
- fields:
- allowPrivilegeEscalation
- appArmorProfile
- capabilities
- procMount
- privileged
- readOnlyRootFilesystem
- runAsUser
- runAsNonRoot
- runAsGroup
- readOnlyRootFilesystem
- procMount
- privileged
- allowPrivilegeEscalation
- capabilities
- seccompProfile
- seLinuxOptions
- seccompProfile
- windowsOptions
- definition: io.k8s.api.core.v1.ContainerStatus
field_categories:
- fields:
- name
- allocatedResources
- allocatedResourcesStatus
- containerID
- image
- imageID
- containerID
- state
- lastState
- name
- ready
- resources
- restartCount
- started
- state
- user
- volumeMounts
- definition: io.k8s.api.core.v1.ContainerStateTerminated
field_categories:
@ -400,9 +408,11 @@
- name: Beta level
fields:
- podFailurePolicy
- successPolicy
- name: Alpha level
fields:
- backoffLimitPerIndex
- managedBy
- maxFailedIndexes
- podReplacementPolicy
@ -491,6 +501,7 @@
- publishNotReadyAddresses
- sessionAffinityConfig
- allocateLoadBalancerNodePorts
- trafficDistribution
- definition: io.k8s.api.core.v1.ServicePort
field_categories:
@ -557,6 +568,7 @@
- gcePersistentDisk
- glusterfs
- iscsi
- image
- nfs
- photonPersistentDisk
- portworxVolume
@ -618,6 +630,7 @@
fields:
- dataSource
- dataSourceRef
- volumeAttributesClassName
- definition: io.k8s.api.core.v1.PersistentVolumeSpec
field_categories:
@ -629,6 +642,7 @@
- nodeAffinity
- persistentVolumeReclaimPolicy
- storageClassName
- volumeAttributesClassName
- volumeMode
- name: Local
fields:
@ -666,6 +680,11 @@
- resourceNames
- nonResourceURLs
- definition: io.k8s.api.networking.v1beta1.IPAddressSpec
field_categories:
- fields:
- parentRef
- definition: io.k8s.api.networking.v1.NetworkPolicySpec
field_categories:
- fields:
@ -687,6 +706,11 @@
- endPort
- protocol
- definition: io.k8s.api.networking.v1beta1.ServiceCIDRSpec
field_categories:
- fields:
- cidrs
- definition: io.k8s.api.policy.v1beta1.PodSecurityPolicySpec
field_categories:
- fields:
@ -737,3 +761,38 @@
- resourceVersion
- selfLink
- uid
- definition: io.k8s.api.storagemigration.v1alpha1.StorageVersionMigrationSpec
field_categories:
- fields:
- continueToken
- resource
- definition: io.k8s.api.storagemigration.v1alpha1.StorageVersionMigrationSpec
field_categories:
- fields:
- driverName
- parameters
- definition: io.k8s.api.resource.v1alpha3.DeviceClassSpec
field_categories:
- fields:
- config
- selectors
- suitableNodes
- definition: io.k8s.api.flowcontrol.v1.FlowSchemaSpec
field_categories:
- fields:
- distinguisherMethod
- matchingPrecedence
- priorityLevelConfiguration
- rules
- definition: io.k8s.api.flowcontrol.v1.PriorityLevelConfigurationSpec
field_categories:
- fields:
- exempt
- limited
- type

120
api-ref-assets/config/toc.yaml
View File

@ -30,6 +30,9 @@ parts:
- Probe
- PodStatus
- PodList
- name: Binding
group: ""
version: v1
- name: PodTemplate
group: ""
version: v1
@ -68,16 +71,16 @@ parts:
version: v1
- name: PodSchedulingContext
group: resource.k8s.io
version: v1alpha2
version: v1alpha3
- name: ResourceClaim
group: resource.k8s.io
version: v1alpha2
version: v1alpha3
- name: ResourceClaimTemplate
group: resource.k8s.io
version: v1alpha2
- name: ResourceClass
version: v1alpha3
- name: ResourceSlice
group: resource.k8s.io
version: v1alpha2
version: v1alpha3
- name: Service Resources
chapters:
- name: Service
@ -108,23 +111,6 @@ parts:
- name: Secret
group: ""
version: v1
- name: Volume
key: io.k8s.api.core.v1.Volume
otherDefinitions:
- DownwardAPIVolumeFile
- KeyToPath
- name: PersistentVolumeClaim
group: ""
version: v1
- name: PersistentVolume
group: ""
version: v1
- name: StorageClass
group: storage.k8s.io
version: v1
- name: VolumeAttachment
group: storage.k8s.io
version: v1
- name: CSIDriver
group: storage.k8s.io
version: v1
@ -134,6 +120,29 @@ parts:
- name: CSIStorageCapacity
group: storage.k8s.io
version: v1
- name: PersistentVolumeClaim
group: ""
version: v1
- name: PersistentVolume
group: ""
version: v1
- name: StorageClass
group: storage.k8s.io
version: v1
- name: StorageVersionMigration
group: storagemigration.k8s.io
version: v1alpha1
- name: Volume
key: io.k8s.api.core.v1.Volume
otherDefinitions:
- DownwardAPIVolumeFile
- KeyToPath
- name: VolumeAttachment
group: storage.k8s.io
version: v1
- name: VolumeAttributesClass
group: storage.k8s.io
version: v1beta1
- name: Authentication Resources
chapters:
- name: ServiceAccount
@ -182,6 +191,9 @@ parts:
version: v1
- name: Policy Resources
chapters:
- name: FlowSchema
group: flowcontrol.apiserver.k8s.io
version: v1
- name: LimitRange
group: ""
version: v1
@ -194,9 +206,21 @@ parts:
- name: PodDisruptionBudget
group: policy
version: v1
- name: IPAddress
group: networking.k8s.io
version: v1alpha1
- name: PriorityLevelConfiguration
group: flowcontrol.apiserver.k8s.io
version: v1
- name: ValidatingAdmissionPolicy
group: admissionregistration.k8s.io
version: v1
otherDefinitions:
- ValidatingAdmissionPolicyList
- ValidatingAdmissionPolicyBinding
- name: ValidatingAdmissionPolicyBinding
group: admissionregistration.k8s.io
version: v1
otherDefinitions:
- ValidatingAdmissionPolicy
- ValidatingAdmissionPolicyBindingList
- name: Extend Resources
chapters:
- name: CustomResourceDefinition
@ -207,53 +231,49 @@ parts:
- JSONSchemaProps
- CustomResourceDefinitionStatus
- CustomResourceDefinitionList
- name: DeviceClass
group: resource.k8s.io
version: v1alpha3
- name: MutatingWebhookConfiguration
group: admissionregistration.k8s.io
version: v1
- name: ValidatingWebhookConfiguration
group: admissionregistration.k8s.io
version: v1
- name: ValidatingAdmissionPolicy
group: admissionregistration.k8s.io
version: v1beta1
otherDefinitions:
- ValidatingAdmissionPolicyList
- ValidatingAdmissionPolicyBinding
- ValidatingWebhookConfigurationList
- name: Cluster Resources
chapters:
- name: Node
group: ""
- name: APIService
group: apiregistration.k8s.io
version: v1
- name: Namespace
- name: ComponentStatus
group: ""
version: v1
- name: Event
group: events.k8s.io
version: v1
- name: APIService
group: apiregistration.k8s.io
version: v1
- name: IPAddress
group: networking.k8s.io
version: v1beta1
- name: Lease
group: coordination.k8s.io
version: v1
- name: LeaseCandidate
group: coordination.k8s.io
version: v1alpha1
- name: Namespace
group: ""
version: v1
- name: Node
group: ""
version: v1
- name: RuntimeClass
group: node.k8s.io
version: v1
- name: FlowSchema
group: flowcontrol.apiserver.k8s.io
version: v1beta3
- name: PriorityLevelConfiguration
group: flowcontrol.apiserver.k8s.io
version: v1beta3
- name: Binding
group: ""
version: v1
- name: ComponentStatus
group: ""
version: v1
- name: ClusterCIDR
- name: ServiceCIDR
group: networking.k8s.io
version: v1alpha1
version: v1beta1
- name: Common Definitions
chapters:
- name: DeleteOptions

2
api-ref-generator

@ -1 +1 @@
Subproject commit 55bce686224caba37f93e1e1eb53c0c9fc104ed4
Subproject commit 096a94d6e7d0d04e41356f21233498c3c4e31699

60
assets/css/glossary.css
View File

@ -1,60 +0,0 @@
.preview-text p {
display: inline;
}
.permalink {
background-image: url(../images/link.png);
background-repeat: no-repeat;
display: inline-block;
vertical-align: middle;
font-size: 0;
color: transparent;
width: 17px;
height: 17px;
margin-left: 10px;
}
.term-anchor {
display: block;
position: relative;
top: -90px;
visibility: hidden;
}
.tag-option {
padding: 5px;
margin: 10px;
float:left;
}
.canonical-tag {
color: white;
background-color: #b7c8e8;
}
.canonical-tag a {
color: inherit;
text-decoration: none !important;
}
.active-tag {
background-color: #326ce5;
}
.invisible {
visibility: hidden;
}
#tag-container {
float: left;
width: 100%;
border-top: 1px solid #8c8c8c;
border-bottom: 1px solid #8c8c8c;
padding: 7px 0px;
margin: 25px 0px;
}
.tag-description {
text-align: center;
margin: 5px 0px;
}

10
assets/js/glossary.js
View File

@ -149,16 +149,6 @@ $( document ).ready(function() {
}
});
});
// Shows permalink when term name is hovered over
$(".term-name").each(function() {
var permalink = $($(this).parent().find(".permalink")[0]);
$(this).mouseenter(function(){
permalink.removeClass("hide");
}).mouseleave(function(){
permalink.addClass("hide");
});
});
};
function initActiveTags() {

0
static/js/mermaid-10.6.1.min.js → assets/js/mermaid-10.6.1.min.js vendored
View File

0
static/js/sweetalert-2.1.2.min.js → assets/js/sweetalert-2.1.2.min.js vendored
View File

2
assets/scss/_base.scss
View File

@ -94,7 +94,7 @@ footer {
}
main {
.button {
.button, .portal-button {
display: inline-block;
border-radius: 6px;
padding: 6px 20px;

149
assets/scss/_custom.scss
View File

@ -626,6 +626,155 @@ body.td-home #deprecation-warning {
margin-right: auto;
}
body.glossary {
main {
ul.glossary-terms > li {
list-style-type: none;
padding: 0.5em;
padding-bottom: calc(min(0.5em, 0.25em + 0.15vh ));
margin: 0;
margin-top: calc(min(1.0em, 0.25em + 0.15vh ));
}
ul.glossary-terms > li.hide {
display: none;
}
ul.glossary-terms > li:has(.term-anchor:target) {
border-left: 0.3em solid $blue;
background: rgba(#999999, 0.2);
}
#tag-container {
float: left;
max-width: calc(max(80%, 100em));
border-top: 1px solid #999999;
border-bottom: 1px solid #999999;
padding-top: 0.5em 0;
margin: 2em 0;
> p {
display: inline-block;
padding-top: 0.2em;
}
.hide {
display: none;
}
.tag-option {
border-radius: 0.33em;
padding: 0.5em;
padding-left: 0.6em;
padding-right: 0.75em;
margin: 0.75em;
margin-top: 0.1em;
float: left;
font-weight: bold;
font-size: 0.925em;
}
.tag-option:not(.canonical-tag):hover {
outline: 1.5px solid $blue;
}
.tag-description {
margin-left: auto;
margin-right: auto;
padding: 0.2em;
padding-bottom: 0.8em;
text-align: center;
}
.canonical-tag {
color: white;
background-color: #999999;
}
.canonical-tag a {
color: inherit;
background: transparent;
text-decoration: none !important;
}
.active-tag {
color: $white;
background-color: $blue;
}
// darken on hover
.canonical-tag:hover {
background: darken(#999999, 15%)
}
.canonical-tag.active-tag:hover {
background: darken($blue, 15%)
}
}
.term-anchor:target + .term-name > span {
color: $blue;
}
.term-anchor:target {
visibility: initial;
}
.glossary-term-name {
font-weight: bold;
display: inline-block;
padding-left: 0.25em;
padding-right: 0.25em;
}
.glossary-aka {
display: inline-block;
padding-left: 0.25em;
padding-right: 0.25em;
padding-bottom: 0.25em;
}
#glossary-details-before {
margin-top: 3em;
font-style: italic;
clear: both;
}
.preview-text {
display: inline-block;
margin-bottom: 0.2em;
}
.preview-text + * {
margin-top: 0.2em;
}
.term-definition {
margin-left: calc(min(2em, 0.5em + 0.75vw));
.hide {
display: none;
}
}
.glossary-aka {
font-style: italic;
}
.preview-text p {
display: inline;
}
.permalink {
display: inline-block;
background-image: url(../images/link.png);
background-repeat: no-repeat;
background-size: contain;
width: 1em;
height: 1em;
padding-left: 0.1em;
}
.term-name:hover {
color: $blue;
}
.term-name:not(:hover) > .permalink {
visibility: hidden;
}
.term-anchor {
display: block;
position: relative;
top: -4rem; // adjust scrolling to target
visibility: hidden;
}
.invisible {
visibility: hidden;
}
}
}
body.cid-community {
section.linkbox {
max-width: clamp(50%, calc(100em + 2vw), 100vw);
margin-left: auto;
margin-right: auto;
}
}
#caseStudies body > #deprecation-warning, body.cid-casestudies > #deprecation-warning, body.cid-community > #deprecation-warning {
display: inline-block;
vertical-align: top;

26
content/bn/blog/_posts/2024-05-09-gateway-api-v1.1/gateway-api-logo.svg Normal file
View File

@ -0,0 +1,26 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="900px" height="250px" style="shape-rendering:geometricPrecision; text-rendering:geometricPrecision; image-rendering:optimizeQuality; fill-rule:evenodd; clip-rule:evenodd" xmlns:xlink="http://www.w3.org/1999/xlink">
<g><path style="opacity:0.908" fill="#fbfcfe" d="M 134.5,17.5 C 137.85,17.335 141.183,17.5017 144.5,18C 170.5,30.3333 196.5,42.6667 222.5,55C 226.894,58.0684 229.728,62.235 231,67.5C 236.872,93.8622 242.872,120.196 249,146.5C 249.61,150.236 249.277,153.903 248,157.5C 230.333,179.833 212.667,202.167 195,224.5C 192.441,227.531 189.274,229.698 185.5,231C 154.5,231.667 123.5,231.667 92.5,231C 88.7257,229.698 85.559,227.531 83,224.5C 66.9068,203.984 50.5734,183.651 34,163.5C 27.7798,155.497 26.7798,146.83 31,137.5C 36.6667,113.167 42.3333,88.8333 48,64.5C 49.7735,59.7271 52.9402,56.2271 57.5,54C 83.2576,41.7854 108.924,29.6188 134.5,17.5 Z"/></g>
<g><path style="opacity:1" fill="#346de5" d="M 134.5,24.5 C 139.08,24.1134 143.414,24.9468 147.5,27C 171.045,38.606 194.712,49.9393 218.5,61C 222.491,63.7785 224.658,67.6119 225,72.5C 229.528,94.2768 234.528,115.943 240,137.5C 241.168,142.482 241.835,147.482 242,152.5C 241.439,154.725 240.439,156.725 239,158.5C 222.427,178.651 206.093,198.984 190,219.5C 188.269,221.617 186.102,223.117 183.5,224C 153.5,224.667 123.5,224.667 93.5,224C 73.0249,201.215 53.8582,177.382 36,152.5C 41.3608,123.356 47.6941,94.3556 55,65.5C 56.5,64 58,62.5 59.5,61C 84.8363,49.3308 109.836,37.1641 134.5,24.5 Z"/></g>
<g><path style="opacity:1" fill="#fafbfe" d="M 133.5,45.5 C 137.167,45.5 140.833,45.5 144.5,45.5C 144.5,52.8333 144.5,60.1667 144.5,67.5C 158.146,68.9079 169.979,74.2412 180,83.5C 186.083,79.5376 191.917,75.2043 197.5,70.5C 199.493,72.6655 201.327,74.9989 203,77.5C 203.749,78.635 203.583,79.635 202.5,80.5C 197.179,84.489 192.179,88.8223 187.5,93.5C 194.894,105.411 198.061,118.411 197,132.5C 198.785,133.24 200.618,133.907 202.5,134.5C 203.471,131.879 204.804,129.546 206.5,127.5C 212.363,132.529 217.697,138.029 222.5,144C 222.355,144.772 222.022,145.439 221.5,146C 214.573,148.476 207.573,150.643 200.5,152.5C 200.5,149.833 200.5,147.167 200.5,144.5C 198.208,144.756 196.041,144.423 194,143.5C 188.976,155.86 180.976,165.86 170,173.5C 170.384,176.309 171.384,178.975 173,181.5C 174.897,179.984 177.064,179.317 179.5,179.5C 178.903,187.153 178.403,194.82 178,202.5C 177.439,203.022 176.772,203.355 176,203.5C 169.677,199.182 163.344,194.848 157,190.5C 156.312,189.668 156.479,189.002 157.5,188.5C 159.332,187.752 160.999,186.752 162.5,185.5C 161.42,183.004 160.086,180.67 158.5,178.5C 145.627,183.814 132.794,183.814 120,178.5C 118.833,180.833 117.667,183.167 116.5,185.5C 117.912,186.806 119.579,187.64 121.5,188C 122.451,188.718 122.617,189.551 122,190.5C 115.505,195.521 108.671,199.854 101.5,203.5C 100.745,195.178 100.078,186.845 99.5,178.5C 101.816,179.36 104.149,179.86 106.5,180C 107.627,178.247 108.627,176.413 109.5,174.5C 97.8509,166.691 89.3509,156.358 84,143.5C 81.9592,144.423 79.7925,144.756 77.5,144.5C 77.8333,147.167 78.1667,149.833 78.5,152.5C 71.0621,150.856 63.7288,148.689 56.5,146C 55.9781,145.439 55.6448,144.772 55.5,144C 60.3409,138.232 65.6742,132.899 71.5,128C 72.3317,127.312 72.9984,127.479 73.5,128.5C 74.3094,130.071 74.6427,131.738 74.5,133.5C 76.7925,133.756 78.9592,133.423 81,132.5C 80.115,118.45 83.2817,105.45 90.5,93.5C 85.5084,88.6769 80.3418,84.0102 75,79.5C 75.7298,75.4517 77.8965,72.6183 81.5,71C 87.0109,75.1809 92.5109,79.3475 98,83.5C 108.046,74.2274 119.879,68.8941 133.5,67.5C 133.5,60.1667 133.5,52.8333 133.5,45.5 Z"/></g>
<g><path style="opacity:0.882" fill="#000000" d="M 858.5,74.5 C 867.424,74.3534 871.257,78.6868 870,87.5C 867.185,93.1691 862.685,95.0024 856.5,93C 850.261,88.7034 849.261,83.3701 853.5,77C 855.315,76.2432 856.981,75.4098 858.5,74.5 Z"/></g>
<g><path style="opacity:1" fill="#356ee5" d="M 127.5,79.5 C 129.5,79.5 131.5,79.5 133.5,79.5C 133.666,89.1724 133.5,98.8391 133,108.5C 132.275,109.059 131.442,109.392 130.5,109.5C 122.292,104.225 114.625,98.2248 107.5,91.5C 113.265,85.9526 119.932,81.9526 127.5,79.5 Z"/></g>
<g><path style="opacity:1" fill="#356de5" d="M 144.5,79.5 C 154.716,80.2764 163.382,84.2764 170.5,91.5C 163.172,97.9916 155.672,104.325 148,110.5C 147,109.833 146,109.167 145,108.5C 144.5,98.8391 144.334,89.1724 144.5,79.5 Z"/></g>
<g><path style="opacity:0.928" fill="#000000" d="M 423.5,83.5 C 424.833,83.5 426.167,83.5 427.5,83.5C 427.5,88.8333 427.5,94.1667 427.5,99.5C 433.833,99.5 440.167,99.5 446.5,99.5C 446.5,104.167 446.5,108.833 446.5,113.5C 440.167,113.5 433.833,113.5 427.5,113.5C 427.13,121.903 427.63,130.236 429,138.5C 430.779,140.764 433.113,142.097 436,142.5C 439.478,141.671 442.978,141.004 446.5,140.5C 446.896,144.375 447.562,148.208 448.5,152C 448.095,152.945 447.428,153.612 446.5,154C 438.116,156.922 429.782,156.922 421.5,154C 415.996,151.16 412.829,146.66 412,140.5C 411.5,122.17 411.333,103.836 411.5,85.5C 415.733,85.4613 419.733,84.7947 423.5,83.5 Z"/></g>
<g><path style="opacity:0.918" fill="#000000" d="M 311.5,98.5 C 321.347,97.9802 331.014,98.9802 340.5,101.5C 341.921,120.529 341.754,139.529 340,158.5C 337.742,166.389 332.575,171.222 324.5,173C 314.057,175.006 303.724,174.506 293.5,171.5C 294.111,166.892 295.111,162.392 296.5,158C 303.028,159.529 309.694,160.196 316.5,160C 322.554,158.957 325.054,155.457 324,149.5C 303.472,154.648 292.305,146.648 290.5,125.5C 291.084,111.263 298.084,102.263 311.5,98.5 Z M 316.5,111.5 C 319.119,111.232 321.619,111.565 324,112.5C 324.167,116.5 324.333,120.5 324.5,124.5C 327.333,136.731 323,140.564 311.5,136C 307.355,130.681 306.522,124.848 309,118.5C 310.767,115.228 313.267,112.895 316.5,111.5 Z"/></g>
<g><path style="opacity:0.94" fill="#000000" d="M 364.5,98.5 C 371.175,98.3337 377.842,98.5004 384.5,99C 391.702,100.869 396.202,105.369 398,112.5C 398.5,126.163 398.667,139.829 398.5,153.5C 387.249,155.423 375.916,155.923 364.5,155C 353.152,151.144 348.985,143.31 352,131.5C 354.443,125.394 358.943,121.894 365.5,121C 371.528,120.83 377.528,120.33 383.5,119.5C 382.625,115.126 379.958,112.626 375.5,112C 369.805,111.623 364.305,112.456 359,114.5C 357.414,109.983 356.58,105.316 356.5,100.5C 359.373,100.198 362.039,99.531 364.5,98.5 Z M 372.5,131.5 C 376.167,131.5 379.833,131.5 383.5,131.5C 383.5,135.167 383.5,138.833 383.5,142.5C 378.728,143.929 374.061,143.595 369.5,141.5C 366.482,136.899 367.482,133.565 372.5,131.5 Z"/></g>
<g><path style="opacity:0.928" fill="#000000" d="M 472.5,98.5 C 497.203,96.5548 507.87,107.888 504.5,132.5C 493.167,132.5 481.833,132.5 470.5,132.5C 470.79,136.961 473.123,139.795 477.5,141C 479.847,141.436 482.181,141.936 484.5,142.5C 489.581,141.61 494.581,140.776 499.5,140C 500.861,144.362 501.528,148.862 501.5,153.5C 491.612,156.456 481.612,156.956 471.5,155C 458.543,150.518 452.543,141.352 453.5,127.5C 453.103,113.266 459.436,103.599 472.5,98.5 Z M 477.5,111.5 C 483.988,111.484 487.988,114.651 489.5,121C 483.175,121.5 476.842,121.666 470.5,121.5C 470.873,116.742 473.206,113.409 477.5,111.5 Z"/></g>
<g><path style="opacity:0.926" fill="#000000" d="M 605.5,98.5 C 612.175,98.3337 618.842,98.5004 625.5,99C 635.288,101.791 640.122,108.291 640,118.5C 640.5,130.162 640.667,141.829 640.5,153.5C 628.91,155.397 617.243,155.897 605.5,155C 594.473,151.455 590.306,143.955 593,132.5C 595.154,125.994 599.654,122.161 606.5,121C 612.491,120.501 618.491,120.334 624.5,120.5C 624.064,115.564 621.397,112.731 616.5,112C 610.805,111.623 605.305,112.456 600,114.5C 598.627,109.928 597.794,105.261 597.5,100.5C 600.373,100.198 603.039,99.531 605.5,98.5 Z M 613.5,131.5 C 617.167,131.5 620.833,131.5 624.5,131.5C 624.5,135.167 624.5,138.833 624.5,142.5C 619.728,143.929 615.061,143.595 610.5,141.5C 607.462,136.989 608.462,133.656 613.5,131.5 Z"/></g>
<g><path style="opacity:0.925" fill="#000000" d="M 742.5,98.5 C 749.175,98.3337 755.842,98.5004 762.5,99C 771.815,101.649 776.649,107.816 777,117.5C 777.5,129.495 777.667,141.495 777.5,153.5C 766.244,155.386 754.911,155.886 743.5,155C 731.751,152.02 727.251,144.52 730,132.5C 732.154,125.994 736.654,122.161 743.5,121C 749.491,120.501 755.491,120.334 761.5,120.5C 761.064,115.564 758.397,112.731 753.5,112C 747.826,111.696 742.326,112.529 737,114.5C 735.627,109.928 734.794,105.261 734.5,100.5C 737.373,100.198 740.039,99.531 742.5,98.5 Z M 750.5,131.5 C 754.167,131.5 757.833,131.5 761.5,131.5C 761.5,135.167 761.5,138.833 761.5,142.5C 757.128,143.885 752.795,143.718 748.5,142C 744.299,137.629 744.966,134.129 750.5,131.5 Z"/></g>
<g><path style="opacity:0.945" fill="#000000" d="M 802.5,98.5 C 832.848,95.8694 845.348,109.536 840,139.5C 837.5,147.333 832.333,152.5 824.5,155C 818.472,155.641 812.472,155.474 806.5,154.5C 806.5,160.833 806.5,167.167 806.5,173.5C 801.167,173.5 795.833,173.5 790.5,173.5C 790.333,149.498 790.5,125.498 791,101.5C 794.917,100.439 798.751,99.4392 802.5,98.5 Z M 806.5,112.5 C 818.841,110.485 824.841,115.652 824.5,128C 824.34,140.262 818.34,144.429 806.5,140.5C 806.5,131.167 806.5,121.833 806.5,112.5 Z"/></g>
<g><path style="opacity:0.919" fill="#000000" d="M 509.5,99.5 C 515.5,99.5 521.5,99.5 527.5,99.5C 529.363,110.955 531.863,122.288 535,133.5C 538.352,122.28 541.186,110.947 543.5,99.5C 547.833,99.5 552.167,99.5 556.5,99.5C 558.225,110.401 560.892,121.068 564.5,131.5C 567.793,120.994 570.46,110.328 572.5,99.5C 578.167,99.5 583.833,99.5 589.5,99.5C 584.799,118.104 578.799,136.271 571.5,154C 567.129,154.828 562.795,154.661 558.5,153.5C 555.493,144.813 552.493,136.146 549.5,127.5C 546.671,136.14 543.838,144.806 541,153.5C 536.55,154.8 532.05,154.8 527.5,153.5C 520.497,135.824 514.497,117.824 509.5,99.5 Z"/></g>
<g><path style="opacity:0.917" fill="#000000" d="M 645.5,99.5 C 651.425,99.1918 657.259,99.5251 663,100.5C 665.869,111.773 669.536,122.773 674,133.5C 677.886,122.345 681.053,111.011 683.5,99.5C 689.167,99.5 694.833,99.5 700.5,99.5C 694.611,121.996 686.445,143.663 676,164.5C 669.118,173.048 660.284,175.881 649.5,173C 647.616,172.784 645.949,172.117 644.5,171C 645.942,166.959 646.942,162.792 647.5,158.5C 651.796,159.463 656.129,159.629 660.5,159C 662.958,157.213 664.624,154.879 665.5,152C 657.154,135.128 650.488,117.628 645.5,99.5 Z"/></g>
<g><path style="opacity:0.95" fill="#000000" d="M 852.5,99.5 C 857.833,99.5 863.167,99.5 868.5,99.5C 868.5,117.833 868.5,136.167 868.5,154.5C 863.167,154.5 857.833,154.5 852.5,154.5C 852.5,136.167 852.5,117.833 852.5,99.5 Z"/></g>
<g><path style="opacity:1" fill="#386ee5" d="M 99.5,100.5 C 107.134,105.665 114.468,111.332 121.5,117.5C 122.833,119.167 122.833,120.833 121.5,122.5C 112.581,125.153 103.581,127.486 94.5,129.5C 92.1812,119.117 93.8478,109.45 99.5,100.5 Z"/></g>
<g><path style="opacity:1" fill="#386fe5" d="M 177.5,100.5 C 184.058,109.086 186.058,118.752 183.5,129.5C 174.476,127.494 165.476,125.328 156.5,123C 155.24,121.186 155.24,119.353 156.5,117.5C 163.753,112.054 170.753,106.387 177.5,100.5 Z"/></g>
<g><path style="opacity:1" fill="#4173e6" d="M 135.5,116.5 C 141.755,115.261 145.422,117.761 146.5,124C 144.602,131.278 140.269,133.111 133.5,129.5C 130.544,124.611 131.211,120.278 135.5,116.5 Z"/></g>
<g><path style="opacity:1" fill="#386fe5" d="M 120.5,134.5 C 122.5,134.5 124.5,134.5 126.5,134.5C 123.684,144.464 119.517,153.797 114,162.5C 105.956,157.595 100.123,150.762 96.5,142C 96.9054,141.055 97.572,140.388 98.5,140C 105.962,138.134 113.295,136.301 120.5,134.5 Z"/></g>
<g><path style="opacity:1" fill="#386ee5" d="M 152.5,133.5 C 161.379,136.092 170.379,138.259 179.5,140C 180.428,140.388 181.095,141.055 181.5,142C 178.209,150.792 172.542,157.626 164.5,162.5C 159.86,154.421 155.693,146.087 152,137.5C 151.421,136.072 151.588,134.738 152.5,133.5 Z"/></g>
<g><path style="opacity:1" fill="#376ee5" d="M 136.5,141.5 C 138.604,141.201 140.604,141.534 142.5,142.5C 146.737,150.968 150.403,159.635 153.5,168.5C 148.384,169.489 143.218,170.156 138,170.5C 133.215,170.678 128.715,169.678 124.5,167.5C 129.059,159.051 133.059,150.384 136.5,141.5 Z"/></g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

255
content/bn/blog/_posts/2024-05-09-gateway-api-v1.1/index.md Normal file
View File

@ -0,0 +1,255 @@
---
layout: blog
title: "গেটওয়ে API v1.1: সার্ভিস মেশ, GRPCRoute, এবং আরো অনেক কিছু"
date: 2024-05-09T09:00:00-08:00
slug: gateway-api-v1-1
author: >
[Richard Belleville](https://github.com/gnossen) (Google),
[Frank Budinsky](https://github.com/frankbu) (IBM),
[Arko Dasgupta](https://github.com/arkodg) (Tetrate),
[Flynn](https://github.com/kflynn) (Buoyant),
[Candace Holman](https://github.com/candita) (Red Hat),
[John Howard](https://github.com/howardjohn) (Solo.io),
[Christine Kim](https://github.com/xtineskim) (Isovalent),
[Mattia Lavacca](https://github.com/mlavacca) (Kong),
[Keith Mattix](https://github.com/keithmattix) (Microsoft),
[Mike Morris](https://github.com/mikemorris) (Microsoft),
[Rob Scott](https://github.com/robscott) (Google),
[Grant Spence](https://github.com/gcs278) (Red Hat),
[Shane Utt](https://github.com/shaneutt) (Kong),
[Gina Yeh](https://github.com/ginayeh) (Google),
and other review and release note contributors
---
![গেটওয়ে API লোগো](gateway-api-logo.svg)
গত অক্টোবরে গেটওয়ে API-এর
GA রিলিজের পর, কুবারনেটিস SIG নেটওয়ার্ক [গেটওয়ে API](https://gateway-api.sigs.k8s.io/)-এর v1.1
রিলিজ ঘোষণা করতে পেরে আনন্দিত। এই রিলিজে, বেশ কিছু ফিচার
_Standard Channel_ (GA)-তে গ্র্যাজুয়েট হচ্ছে, বিশেষত সার্ভিস মেশ এবং GRPCRoute-এর জন্য
সাপোর্ট সহ। আমরা কিছু নতুন এক্সপেরিমেন্টাল ফিচারও প্রবর্তন করছি, যার মধ্যে
সেশনের স্থিরতা এবং ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন।
## নতুন কি
### স্ট্যান্ডার্ড থেকে গ্র্যাজুয়েট
এই রিলিজে চারটি অধীর আগ্রহে প্রতীক্ষিত ফিচার স্ট্যান্ডার্ডে গ্র্যাজুয়েট অন্তর্ভুক্ত রয়েছে।
এর মানে এগুলো আর পরীক্ষামূলক ধারণা নয়; স্ট্যান্ডার্ড রিলিজ
চ্যানেলে অন্তর্ভুক্তি API সারফেসের উপর হাই লেভেলের আস্থা নির্দেশ করে এবং
ব্যাকওয়ার্ড কম্প্যাটিবিলিটির গ্যারান্টি প্রদান করে। অবশ্যই, অন্য যেকোন
কুবারনেটিস API-এর মতো, স্ট্যান্ডার্ড চ্যানেল ফিচারগুলি সময়ের সাথে সাথে
ব্যাকওয়ার্ড-কম্প্যাটিবিলিটির সংযোজনের সাথে বিকশিত হতে পারে এবং আমরা অবশ্যই ভবিষ্যতে
এই নতুন ফিচারগুলিতে আরও রিফাইনমেন্ট এবং উন্নতি আশা করি।
এই সবগুলি কীভাবে কাজ করে সে সম্পর্কে আরও তথ্যের জন্য,
[গেটওয়ে API ভার্শনিং পলিসি](https://gateway-api.sigs.k8s.io/concepts/versioning/) দেখুন।
#### [সার্ভিস মেশ সাপোর্ট](https://gateway-api.sigs.k8s.io/mesh/)
সার্ভিস মেশ সাপোর্ট গেটওয়ে APIতে সার্ভিস মেশ ব্যবহারকারীদের ইনগ্রেস ট্র্যাফিক এবং মেশ ট্র্যাফিক
পরিচালনা করতে, একই পলিসি এবং রাউটিং ইন্টারফেসগুলি পুনরায় ব্যবহার করতে একই API
ব্যবহার করতে দেয়। গেটওয়ে API v1.1-এ, রুটগুলিতে (যেমন HTTPRoute) এখন 'parentRef' হিসাবে
একটি সার্ভিস থাকতে পারে, নির্দিষ্ট সার্ভিসগুলিতে ট্র্যাফিক কীভাবে আচরণ করে তা নিয়ন্ত্রণ করতে।
আরও তথ্যের জন্য,
[গেটওয়ে API সার্ভিস মেশ ডকুমেন্টেশন] (https://gateway-api.sigs.k8s.io/mesh/)
পড়ুন বা
[গেটওয়ে API বাস্তবায়নের তালিকা] (https://gateway-api.sigs.k8s.io/implementations/#service-mesh-implementation-status) দেখুন।
উদাহরণস্বরূপ, কেউ একটি HTTPRoute দিয়ে একটি অ্যাপ্লিকেশনের কল গ্রাফের গভীরে
একটি ওয়ার্কলোডের একটি canary স্থাপনার কাজ করতে পারে:
```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: color-canary
namespace: faces
spec:
parentRefs:
- name: color
kind: Service
group: ""
port: 80
rules:
- backendRefs:
- name: color
port: 80
weight: 50
- name: color2
port: 80
weight: 50
```
এটি মূল `color` সার্ভিস এবং `color2` সার্ভিসটির মধ্যে `faces` নেমস্পেস এর
`color` সার্ভিসটিতে প্রেরিত ট্র্যাফিককে 50/50 বিভক্ত করবে, একটি পোর্টেবল
কনফিগারেশন ব্যবহার করে যা এক মেশ থেকে অন্য মেশে সরানো সহজ।
#### [GRPCRoute](https://gateway-api.sigs.k8s.io/guides/grpc-routing/)
আপনি যদি ইতিমধ্যে GRPCRoute এর পরীক্ষামূলক ভার্সনটি ব্যবহার করে থাকেন তবে আমরা
GRPCRoute স্ট্যান্ডার্ড চ্যানেল ভার্সনে আপগ্রেড করা বন্ধ রাখার পরামর্শ দিচ্ছি যতক্ষণ না আপনি যে কন্ট্রোলারগুলি
ব্যবহার করছেন তা GRPCRoute v1 সমর্থন করার জন্য আপডেট করা হয়। ততক্ষণ পর্যন্ত,
GRPCRoute-এর v1.1-এ পরীক্ষামূলক চ্যানেল ভার্সনে আপগ্রেড করা নিরাপদ
যা v1alpha2 এবং v1 API ভার্সন উভয়ই অন্তর্ভুক্ত করে।
#### [ParentReference Port](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.ParentReference)
`port` ফিল্ডটি ParentReference এ যুক্ত করা হয়েছিল, আপনাকে গেটওয়ে লিসেনার,
সার্ভিস বা অন্যান্য প্যারেন্ট রিসোর্সগুলিতে রিসোর্সগুলি সংযুক্ত করার অনুমতি দেয়
(বাস্তবায়নের উপর নির্ভর করে)। একটি পোর্টের সাথে বাইন্ডিং আপনাকে
একবারে একাধিক লিসেনার্সের সাথে অ্যাটাচ করতে দেয়।
উদাহরণস্বরূপ, আপনি লিসেনারের `name` ফিল্ডের পরিবর্তে লিসেনার `port` দ্বারা নির্দিষ্ট হিসাবে
গেটওয়ের এক বা একাধিক নির্দিষ্ট লিসেনারের সাথে একটি HTTPRoute সংযুক্ত করতে পারেন।
আরও তথ্যের জন্য, দেখুন
[গেটওয়েতে সংযুক্ত করা হচ্ছে](https://gateway-api.sigs.k8s.io/api-types/httproute/#attaching-to-gateways).
#### [কনফর্মেন্স প্রোফাইল এবং রিপোর্ট](https://gateway-api.sigs.k8s.io/concepts/conformance/#conformance-profiles)
কনফর্মেন্স রিপোর্ট API `mode` ফিল্ড (ইমপ্লিমেন্টেশনের কাজের মোড নির্দিষ্ট করার
উদ্দেশ্যে) এবং `gatewayAPIChannel` (স্ট্যান্ডার্ড বা এক্সপেরিমেন্টাল)
দিয়ে প্রসারিত করা হয়েছে। `gatewayAPIVersion` এবং `gatewayAPIChannel`
এখন টেস্টিং ফলাফলের সংক্ষিপ্ত বিবরণ সহ স্যুট মেশিনারি দ্বারা
স্বয়ংক্রিয়ভাবে পূরণ করা হয়। প্রতিবেদনগুলি আরও স্ট্রাকচারড উপায়ে পুনর্গঠিত হয়েছে এবং
ইমপ্লিমেন্টেশনগুলিতে এখন টেস্টগুলি কীভাবে চালানো হবে সে সম্পর্কে তথ্য যুক্ত করতে পারে এবং
রিপ্রোডাকশন পদক্ষেপগুলি সরবরাহ করতে পারে।
### এক্সপেরিমেন্টাল চ্যানেলে নতুন সংযোজন
#### [গেটওয়ে ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন](https://gateway-api.sigs.k8s.io/geps/gep-91/)
গেটওয়েগুলি এখন `tls` এর মধ্যে একটি নতুন `frontendValidation` ফিল্ড প্রবর্তন করে প্রতিটি
গেটওয়ে লিস্টেনারের জন্য ক্লায়েন্ট সার্টিফিকেট ভেরিফিকেশন কনফিগার করতে পারে।
এই ফিল্ডটি CA সার্টিফিকেটগুলির একটি তালিকা কনফিগার করা সমর্থন করে যা ক্লায়েন্ট দ্বারা উপস্থাপিত
সার্টিফিকেটগুলি যাচাই করার জন্য ট্রাস্ট অ্যাঙ্কর হিসাবে ব্যবহার করা যেতে পারে।
নিম্নলিখিত উদাহরণটি দেখায় যে কীভাবে `foo-example-com-ca-cert`
ConfigMap-এ সঞ্চিত CACertificate-টি `foo-https` গেটওয়ে লিস্টেনারের সাথে সংযুক্ত ক্লায়েন্টদের
দ্বারা উপস্থাপিত সার্টিফিকেটগুলি যাচাই করতে ব্যবহার করা যেতে পারে।
```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: client-validation-basic
spec:
gatewayClassName: acme-lb
listeners:
name: foo-https
protocol: HTTPS
port: 443
hostname: foo.example.com
tls:
certificateRefs:
kind: Secret
group: ""
name: foo-example-com-cert
frontendValidation:
caCertificateRefs:
kind: ConfigMap
group: ""
name: foo-example-com-ca-cert
```
#### [সেশন পার্সিস্টেন্স এবং BackendLBPolicy (Session Persistence and BackendLBPolicy)](https://gateway-api.sigs.k8s.io/geps/gep-1619/)
সার্ভিস-লেভেলের কনফিগারেশনের জন্য একটি নতুন পলিসি
([BackendLBPolicy](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.BackendLBPolicy))
এবং রুট-লেভেলের কনফিগারেশনের জন্য HTTPRoute এবং GRPCRoute এর মধ্যে ফিল্ড হিসাবে গেটওয়ে API-তে
[সেশন পার্সিস্টেন্স](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.SessionPersistence)
ইন্ট্রোডিউসড করা হচ্ছে। BackendLBPolicy এবং রুট-লেভেলের
API-গুলি সেশন টাইমআউট, সেশনের নাম, সেশনের ধরণ এবং কুকি লাইফটাইম টাইপ সহ
একই সেশন পার্সিস্টেন্স কনফিগারেশন সরবরাহ করে।
নীচে `BackendLBPolicy` এর একটি উদাহরণ কনফিগারেশন রয়েছে যা `foo` সার্ভিসের জন্য কুকি-বেসড
সেশন পার্সিস্টেন্স এনাবল করে। এটি সেশনের নামটি `foo-session` এ সেট করে,
অ্যাবসুলুট এবং আইডিএল টাইমআউটসগুলি ডিফাইন করে এবং কুকিটিকে সেশন
কুকি হিসাবে কনফিগার করে:
```yaml
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
name: lb-policy
namespace: foo-ns
spec:
targetRefs:
- group: core
kind: service
name: foo
sessionPersistence:
sessionName: foo-session
absoluteTimeout: 1h
idleTimeout: 30m
type: Cookie
cookieConfig:
lifetimeType: Session
```
### বাকি সব
#### [TLS টার্মিনোলজি ক্ল্যারিফিকেশন](https://gateway-api.sigs.k8s.io/geps/gep-2907/)
API জুড়ে আমাদের TLS টার্মিনোলজিকে আরও সামঞ্জস্যপূর্ণ করার বিস্তৃত লক্ষ্যের
অংশ হিসাবে, আমরা BackendTLSPolicy-তে কিছু ব্রেকিং পরিবর্তন ইন্ট্রোডিউসড করেছি।
এর ফলে একটি নতুন API ভার্সন (v1alpha3) তৈরি হয়েছে এবং ভার্সন আপগ্রেড সঠিকভাবে পরিচালনা
করার জন্য এই নীতির যে কোনও এক্সিস্টিং ইমপ্লিমেন্টেশনের প্রয়োজন হবে, যেমন
ডেটা ব্যাক আপ করে এবং এই নতুন ভার্সনটি ইনস্টল করার আগে v1alpha2
ভার্সনটি আনইনস্টল করতে হবে।
v1alpha2 BackendTLSPolicy ফিল্ড-ত্রর যে কোনও রেফারেন্স v1alpha3 এ আপডেট করতে হবে।
ফিল্ডগুলিতে নির্দিষ্ট পরিবর্তনগুলির মধ্যে রয়েছে:
- `targetRef` BackendTLSPolicy-কে একাধিক লক্ষ্যবস্তুর সাথে সংযুক্ত করার অনুমতি দেওয়ার
জন্য `targetRefs` হয়ে যায়
- `tls` হয়ে যায় `validation`
- `tls.caCertRefs` হয়ে যায় `validation.caCertificateRefs`
- `tls.wellKnownCACerts` হয়ে যায় `validation.wellKnownCACertificates`
এই রিলিজে অন্তর্ভুক্ত পরিবর্তনগুলির সম্পূর্ণ তালিকার জন্য, দয়া করে
[v1.1.0 রিলিজ নোটগুলি](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.1.0) দেখুন।
## গেটওয়ে API ব্যাকগ্রাউন্ড
গেটওয়ে API-এর ধারণাটি প্রাথমিকভাবে 2019 KubeCon San Diego-তে
Ingress API-এর পরবর্তী প্রজন্ম হিসাবে [প্রপোজড](https://youtu.be/Ne9UJL6irXY?si=wgtC9w8PMB5ZHil2)
করা হয়েছিল। তার পর থেকে,
[কুবারনেটিস ইতিহাসের সবচেয়ে সহযোগী API](https://www.youtube.com/watch?v=V3Vu_FWb4l4)
হয়ে ওঠার জন্য একটি অবিশ্বাস্য কমিউনিটি গঠিত হয়েছে।
এখন পর্যন্ত 200 জনেরও বেশি লোক এই API-তে অবদান রেখেছে এবং এই সংখ্যাটি বাড়ছে।
রক্ষণাবেক্ষণকারীরা গেটওয়ে API তে অবদান রেখেছেন রিপোসিটোরি তে কমিট,
ডিসকাশন, আইডিয়া বা সাধারণ সহায়তার আকারে এমন প্রত্যেককে ধন্যবাদ জানাতে চান।
আমরা সত্যিকার অর্থেই এই নিবেদিত ও সক্রিয় কমিউনিটির সাপোর্ট ছাড়া এতদূর
আসতে পারতাম না।
## চেষ্টা করে দেখুন
অন্যান্য কুবারনেটিস API-গুলির বিপরীতে, গেটওয়ে API-এর সর্বশেষ ভার্সন পেতে আপনাকে
কুবারনেটিসের সর্বশেষ ভার্সনে আপগ্রেড করতে হবে না। যতক্ষণ না আপনি কুবারনেটিস 1.26
বা তার পরের টা চালাচ্ছেন, আপনি গেটওয়ে API-এর এই ভার্সনটি দিয়ে উঠতে এবং
চালাতে সক্ষম হবেন।
API ব্যবহার করতে, আমাদের [শুরু করার গাইড](https://gateway-api.sigs.k8s.io/guides/) অনুসরণ করুন।
## যুক্ত হোন
ইনগ্রেস এবং সার্ভিস মেশ উভয়ের জন্য কুবারনেটিস রাউটিং API-গুলির ভবিষ্যতকে সংজ্ঞায়িত করতে
এবং সহায়তা করার প্রচুর সুযোগ রয়েছে।
* কোন ইউজ-কেস সম্বোধন করা যেতে পারে তা দেখতে [ব্যবহারকারী গাইডগুলি](https://gateway-api.sigs.k8s.io/guides) দেখুন।
* [বিদ্যমান গেটওয়ে কন্ট্রোলারগুলির](https://gateway-api.sigs.k8s.io/implementations/) মধ্যে একটি ব্যবহার করে দেখুন।
* অথবা [কমিউনিটিতে আমাদের সাথে যোগ দিন](https://gateway-api.sigs.k8s.io/contributing/)
এবং একসাথে গেটওয়ে API-এর ভবিষ্যত গড়ে তুলতে আমাদের সহায়তা করুন!
## রিলেটেড কুবারনেটিস ব্লগ আর্টিকেলস
* [গেটওয়ে API v1.0 এ নতুন এক্সপেরিমেন্টাল ফিচারস](/blog/2023/11/28/gateway-api-ga/)
11/2023
* [গেটওয়ে API v1.0: GA রিলিজ](/blog/2023/10/31/gateway-api-ga/)
10/2023
* [ingress2gateway ইন্ট্রোডিউসিং করা; গেটওয়ে API-তে আপগ্রেড সিম্পলিফাই করা হচ্ছে](/blog/2023/10/25/introducing-ingress2gateway/)
10/2023
* [গেটওয়ে API v0.8.0: ইন্ট্রোডিউসিং সার্ভিস মেশ সাপোর্ট](/blog/2023/08/29/gateway-api-v0-8/)
08/2023

2
content/bn/docs/concepts/extend-kubernetes/compute-storage-net/_index.md
View File

@ -35,7 +35,7 @@ no_list: true
* [নেটওয়ার্ক প্লাগইন](/bn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
একটি নেটওয়ার্ক প্লাগইন কুবারনেটিসকে বিভিন্ন নেটওয়ার্কিং টপোলজি এবং প্রযুক্তির সাথে কাজ করার অনুমতি দেয়।
নেটওয়ার্ক প্লাগইন কুবারনেটিসকে বিভিন্ন নেটওয়ার্কিং টপোলজি এবং প্রযুক্তির সাথে কাজ করার অনুমতি দেয়।
আপনার কুবারনেটিস ক্লাস্টারের একটি _নেটওয়ার্ক প্লাগইন_ প্রয়োজন যাতে একটি কার্যকরী পড নেটওয়ার্ক থাকে
এবং কুবারনেটিস নেটওয়ার্ক মডেলের অন্যান্য দিকগুলোকে সাপোর্ট করতে পারে ৷

131
content/bn/docs/concepts/overview/_index.md
View File

@ -1,4 +1,7 @@
---
# reviewers:
# - bgrant0607
# - mikedanese ( The list of approvers is not necessary for the localized version. However, it is included because it helps maintain a certain line break, which further aids in updating a file.That's why it's kept in comment form. )
title: "ওভারভিউ"
description: >
কুবারনেটিস হল একটি পোর্টেবল, এক্সটেনসিবল, ওপেন সোর্স প্ল্যাটফর্ম যা কন্টেইনারাইজড ওয়ার্কলোড এবং সার্ভিসগুলি পরিচালনা করার জন্য, ঘোষণামূলক কনফিগারেশন এবং অটোমেশন উভয়কেই সহজতর করে। এটির একটি বড়, দ্রুত বর্ধনশীল ইকোসিস্টেম রয়েছে। কুবারনেটিস সার্ভিসগুলি, সাপোর্ট, এবং টুলস ব্যাপকভাবে সহজলভ্য।
@ -19,75 +22,12 @@ no_list: true
<!-- body -->
কুবারনেটিস হল একটি পোর্টেবল, বর্ধনশীল, ওপেন সোর্স প্ল্যাটফর্ম যা কনটেইনারাইজড
ওয়ার্কলোড এবং পরিষেবাগুলি পরিচালনা করার জন্য, ঘোষণামূলক কনফিগারেশন এবং অটোমেশন উভয়কেই সহজতর করে।
এটির একটি বড়, দ্রুত বর্ধনশীল ইকোসিস্টেম রয়েছে। কুবারনেটিস পরিষেবাগুলি, সমর্থন, এবং সরঞ্জাম ব্যাপকভাবে সহজলভ্য।
কুবারনেটিস নামটি গ্রীক থেকে এসেছে, যার অর্থ হেলমসম্যান বা পাইলট।
"K" এবং "s" এর মধ্যে আটটি অক্ষর গণনা করার ফলে একটি সংক্ষিপ্ত রূপ K8s। গুগল ২০১৪ সালে
কুবারনেটিস প্রজেক্টটি ওপেন সোর্স করেছে। কুবারনেটিস
[15 বছরেরও বেশি সময় ধরে Google-এর অভিজ্ঞতাকে](/blog/2015/04/borg-predecessor-to-kubernetes/) একত্রিত করেছে
যা কমিউনিটির সেরা আইডিয়া এবং অনুশীলনের সাথে স্কেলে উৎপাদন কাজের চাপ চালানোর।
## অতিতে যাই
চলুন অতিতে যেয়ে এক নজরে দেখে নেওয়া যাক কেন কুবারনেটিস এতটা কাজে লাগে।
![ডিপ্লয়মেন্টের বিবর্তন](/images/docs/Container_Evolution.svg)
**ঐতিহ্যবাহী ডিপ্লয়মেন্টের যুগ:**
প্রথম দিকে, সংস্থাগুলি ফিজিক্যাল সার্ভারগুলিতে অ্যাপ্লিকেশন চালাত।
একটি ফিজিক্যাল সার্ভারে অ্যাপ্লিকেশনের জন্য রিসোর্স সীমানা নির্ধারণ করার কোন উপায় ছিল না,
এবং এর ফলে রিসোর্স বরাদ্দ সমস্যা হয়েছে। উদাহরণস্বরূপ, যদি একটি ফিজিক্যাল সার্ভারে একাধিক অ্যাপ্লিকেশান চালিত হয়,
এমন উদাহরণ হতে পারে যেখানে একটি অ্যাপ্লিকেশন বেশিরভাগ সংস্থান গ্রহণ করবে, এবং ফলস্বরূপ, অন্যান্য অ্যাপ্লিকেশনগুলি কম পারফর্ম করবে।
এই জন্য একটি সমাধান একটি ভিন্ন ফিজিক্যাল সার্ভারে প্রতিটি অ্যাপ্লিকেশন চালানো হবে।
কিন্তু সম্পদের অব্যবহৃত হওয়ার কারণে এটির মাপকাঠিি ঠিক করা যায়নি এবং
অনেকগুলি ফিজিক্যাল সার্ভার বজায় রাখা সংস্থাগুলির জন্য ব্যয়বহুল ছিল।
**ভার্চুয়ালাইজড ডিপ্লয়মেন্টর যুগ:** একটি সমাধান হিসাবে, ভার্চুয়ালাইজেশন চালু করা হয়েছিল। এটি আপনাকে
একটি একক ফিজিক্যাল সার্ভারের CPU-তে একাধিক ভার্চুয়াল মেশিন (VMs) চালানো যায়। ভার্চুয়ালাইজেশন
অ্যাপ্লিকেশনগুলিকে VM-এর মধ্যে বিচ্ছিন্ন করার অনুমতি দেয় এবং একটি স্তরের নিরাপত্তা প্রদান করে
কারণ একটি অ্যাপ্লিকেশনের তথ্য অন্য অ্যাপ্লিকেশন দ্বারা অবাধে অ্যাক্সেস করা যায় না।
ভার্চুয়ালাইজেশন একটি ফিজিক্যাল সার্ভারে রিসোর্সগুলির আরও ভালো ব্যবহারের অনুমতি দেয় এবং
আরও ভাল স্কেলেবিলিটির অনুমতি দেয় কারণ একটি অ্যাপ্লিকেশন সহজে যোগ বা আপডেট করা যায়, হার্ডওয়্যার খরচ কমায়
এবং আরও অনেক কিছু। ভার্চুয়ালাইজেশনের মাধ্যমে আপনি ডিসপোজেবল ভার্চুয়াল মেশিনের
একটি ক্লাস্টার হিসাবে ফিজিক্যাল সম্পদের একটি সেট উপস্থাপন করতে পারেন।
প্রতিটি VM হল একটি সম্পূর্ণ মেশিন যা ভার্চুয়ালাইজড হার্ডওয়্যারের উপরে নিজস্ব অপারেটিং সিস্টেম
সহ সমস্ত উপাদান চালায়।
**কন্টেইনার স্থাপনের যুগ:** কনটেইনারগুলি VM-এর মতোই, তবে অ্যাপ্লিকেশনগুলির
মধ্যে অপারেটিং সিস্টেম (OS) ভাগ করার জন্য তাদের শিথিল বিচ্ছিন্নতা বৈশিষ্ট্য রয়েছে৷
অতএব, কন্টেইনারগুলোকে হালকা বলে মনে করা হয়। একটি VM-এর মতো, একটি কনটেইনারের
নিজস্ব ফাইল সিস্টেম, CPU ভাগ, মেমরি, প্রক্রিয়া স্থান এবং আরও অনেক কিছু রয়েছে। যেহেতু এগুলি
অন্তর্নিহিত অবকাঠামো থেকে আলাদা করা হয়েছে, তারা ক্লাউড এবং
OS ডিস্ট্রিবিউশন জুড়ে বহনযোগ্য।
কন্টেইনারগুলো জনপ্রিয় হয়ে উঠেছে কারণ তারা অতিরিক্ত সুবিধা প্রদান করে, যেমন:
* এজাইল (Agile) অ্যাপ্লিকেশন তৈরি এবং ডিপ্লয়মেন্টয়: ভিএম ইমেজ (VM Image) ব্যবহারের তুলনায় কন্টেইনার ইমেজ (Container Image)
তৈরির সহজতা এবং দক্ষতা বেশি।
* ক্রমাগত বিকাশ, একীকরণ এবং ডিপ্লয়মেন্ট: নির্ভরযোগ্য এবং ঘন ঘন
কন্টেইনার ইমেজ তৈরি এবং ডিপ্লয়মেন্টের জন্য প্রদান করে দ্রুত এবং
দক্ষ রোলব্যাকের (ইমেজ অপরিবর্তনীয়তার কারণে) সাথে ।
* ডেভ (Dev) এবং অপস (Ops) উদ্বেগের বিচ্ছেদ: বিল্ড/রিলিজের সময়ে
অ্যাপ্লিকেশন কন্টেইনার ইমেজ তৈরি করে ডিপ্লয়মেন্টের সময়ের তুলনায়,
ফলস্বরূপ অ্যাপ্লিকেশনগুলি অবকাঠামো থেকে বিচ্ছিন্ন হয়।
* পর্যবেক্ষণযোগ্যতা: শুধুমাত্র OS-স্তরের তথ্য এবং মেট্রিক্সই নয়,
প্রয়োগের স্বাস্থ্য এবং অন্যান্য সংকেতও।
* ডেভেলপমেন্ট, টেস্টিং এবং প্রোডাকশন জুড়ে পরিবেশগত সামঞ্জস্য: একটি
ল্যাপটপে ক্লাউডের মতোই চলে।
* ক্লাউড এবং ওএস ডিস্ট্রিবিউশন পোর্টেবিলিটি: উবুন্টু (Ubuntu), রেল (RHEL), কোরওস (CoreOS), অন-প্রিমিসেস (on-premises),
প্রধান পাবলিক ক্লাউডসর উপর, এবং অন্য কোথাও চলে।
* অ্যাপ্লিকেশন-কেন্দ্রিক ব্যবস্থাপনা: ভার্চুয়াল হার্ডওয়্যারে একটি OS চালানো থেকে
লজিক্যাল রিসোর্স ব্যবহার করে একটি OS-এ একটি অ্যাপ্লিকেশন চালানো পর্যন্ত বিমূর্ততার স্তর বাড়ায়।
* ঢিলেঢালাভাবে সংযুক্ত, বিতরণ করা, স্থিতিস্থাপক, মুক্ত মাইক্রো-পরিষেবা: অ্যাপ্লিকেশনগুলিকে
ছোট, স্বাধীন টুকরোগুলিতে বিভক্ত করা হয় এবং গতিশীলভাবে স্থাপন ও পরিচালনা করা যায় –
একটি বড় একক-উদ্দেশ্য মেশিনে চলমান একটি মনোলিথিক স্ট্যাক নয়।.
* রিসোর্স আইসোলেশন: অনুমানযোগ্য অ্যাপ্লিকেশন কর্মক্ষমতা।
* রিসোর্স ব্যবহার: উচ্চ দক্ষতা এবং ঘনত্ব।
## আপনার কেন কুবারনেটিস দরকার এবং এটি কী করতে পারে {#why-you-need-kubernetes-and-what-can-it-do}
কন্টেইনারসমূহ অ্যাপ্লিকেশন একত্রকরণ এবং চালানোর একটি ভালো উপায়৷ একটি উৎপাদন
@ -171,6 +111,71 @@ OS ডিস্ট্রিবিউশন জুড়ে বহনযোগ্
আপনি A থেকে C পর্যন্ত কিভাবে যাবেন তা বিবেচ্য নয়। কেন্দ্রীভূত নিয়ন্ত্রণেরও প্রয়োজন নেই। এই
সিস্টেমের ফলাফল যা ব্যবহার করা সহজ এবং আরও শক্তিশালী, মজবুত, স্থিতিস্থাপক এবং এক্সটেনসিবল।
## কুবারনেটিসের জন্য ঐতিহাসিক প্রেক্ষাপট {#অতিতে-যাই}
চলুন অতিতে যেয়ে এক নজরে দেখে নেওয়া যাক কেন কুবারনেটিস এতটা কাজে লাগে।
![ডিপ্লয়মেন্টের বিবর্তন](/images/docs/Container_Evolution.svg)
**ঐতিহ্যবাহী ডিপ্লয়মেন্টের যুগ:**
প্রথম দিকে, সংস্থাগুলি ফিজিক্যাল সার্ভারগুলিতে অ্যাপ্লিকেশন চালাত।
একটি ফিজিক্যাল সার্ভারে অ্যাপ্লিকেশনের জন্য রিসোর্স সীমানা নির্ধারণ করার কোন উপায় ছিল না,
এবং এর ফলে রিসোর্স বরাদ্দ সমস্যা হয়েছে। উদাহরণস্বরূপ, যদি একটি ফিজিক্যাল সার্ভারে একাধিক অ্যাপ্লিকেশান চালিত হয়,
এমন উদাহরণ হতে পারে যেখানে একটি অ্যাপ্লিকেশন বেশিরভাগ সংস্থান গ্রহণ করবে, এবং ফলস্বরূপ, অন্যান্য অ্যাপ্লিকেশনগুলি কম পারফর্ম করবে।
এই জন্য একটি সমাধান একটি ভিন্ন ফিজিক্যাল সার্ভারে প্রতিটি অ্যাপ্লিকেশন চালানো হবে।
কিন্তু সম্পদের অব্যবহৃত হওয়ার কারণে এটির মাপকাঠিি ঠিক করা যায়নি এবং
অনেকগুলি ফিজিক্যাল সার্ভার বজায় রাখা সংস্থাগুলির জন্য ব্যয়বহুল ছিল।
**ভার্চুয়ালাইজড ডিপ্লয়মেন্টর যুগ:**
একটি সমাধান হিসাবে, ভার্চুয়ালাইজেশন চালু করা হয়েছিল। এটি আপনাকে
একটি একক ফিজিক্যাল সার্ভারের CPU-তে একাধিক ভার্চুয়াল মেশিন (VMs) চালানো যায়। ভার্চুয়ালাইজেশন
অ্যাপ্লিকেশনগুলিকে VM-এর মধ্যে বিচ্ছিন্ন করার অনুমতি দেয় এবং একটি স্তরের নিরাপত্তা প্রদান করে
কারণ একটি অ্যাপ্লিকেশনের তথ্য অন্য অ্যাপ্লিকেশন দ্বারা অবাধে অ্যাক্সেস করা যায় না।
ভার্চুয়ালাইজেশন একটি ফিজিক্যাল সার্ভারে রিসোর্সগুলির আরও ভালো ব্যবহারের অনুমতি দেয় এবং
আরও ভাল স্কেলেবিলিটির অনুমতি দেয় কারণ একটি অ্যাপ্লিকেশন সহজে যোগ বা আপডেট করা যায়, হার্ডওয়্যার খরচ কমায়
এবং আরও অনেক কিছু। ভার্চুয়ালাইজেশনের মাধ্যমে আপনি ডিসপোজেবল ভার্চুয়াল মেশিনের
একটি ক্লাস্টার হিসাবে ফিজিক্যাল সম্পদের একটি সেট উপস্থাপন করতে পারেন।
প্রতিটি VM হল একটি সম্পূর্ণ মেশিন যা ভার্চুয়ালাইজড হার্ডওয়্যারের উপরে নিজস্ব অপারেটিং সিস্টেম
সহ সমস্ত উপাদান চালায়।
**কন্টেইনার স্থাপনের যুগ:**
কনটেইনারগুলি VM-এর মতোই, তবে অ্যাপ্লিকেশনগুলির
মধ্যে অপারেটিং সিস্টেম (OS) ভাগ করার জন্য তাদের শিথিল বিচ্ছিন্নতা বৈশিষ্ট্য রয়েছে৷
অতএব, কন্টেইনারগুলোকে হালকা বলে মনে করা হয়। একটি VM-এর মতো, একটি কনটেইনারের
নিজস্ব ফাইল সিস্টেম, CPU ভাগ, মেমরি, প্রক্রিয়া স্থান এবং আরও অনেক কিছু রয়েছে। যেহেতু এগুলি
অন্তর্নিহিত অবকাঠামো থেকে আলাদা করা হয়েছে, তারা ক্লাউড এবং
OS ডিস্ট্রিবিউশন জুড়ে বহনযোগ্য।
কন্টেইনারগুলো জনপ্রিয় হয়ে উঠেছে কারণ তারা অতিরিক্ত সুবিধা প্রদান করে, যেমন:
* এজাইল (Agile) অ্যাপ্লিকেশন তৈরি এবং ডিপ্লয়মেন্টয়: ভিএম ইমেজ (VM Image) ব্যবহারের তুলনায় কন্টেইনার ইমেজ (Container Image)
তৈরির সহজতা এবং দক্ষতা বেশি।
* ক্রমাগত বিকাশ, একীকরণ এবং ডিপ্লয়মেন্ট: নির্ভরযোগ্য এবং ঘন ঘন
কন্টেইনার ইমেজ তৈরি এবং ডিপ্লয়মেন্টের জন্য প্রদান করে দ্রুত এবং
দক্ষ রোলব্যাকের (ইমেজ অপরিবর্তনীয়তার কারণে) সাথে ।
* ডেভ (Dev) এবং অপস (Ops) উদ্বেগের বিচ্ছেদ: বিল্ড/রিলিজের সময়ে
অ্যাপ্লিকেশন কন্টেইনার ইমেজ তৈরি করে ডিপ্লয়মেন্টের সময়ের তুলনায়,
ফলস্বরূপ অ্যাপ্লিকেশনগুলি অবকাঠামো থেকে বিচ্ছিন্ন হয়।
* পর্যবেক্ষণযোগ্যতা: শুধুমাত্র OS-স্তরের তথ্য এবং মেট্রিক্সই নয়,
প্রয়োগের স্বাস্থ্য এবং অন্যান্য সংকেতও।
* ডেভেলপমেন্ট, টেস্টিং এবং প্রোডাকশন জুড়ে পরিবেশগত সামঞ্জস্য: একটি
ল্যাপটপে ক্লাউডের মতোই চলে।
* ক্লাউড এবং ওএস ডিস্ট্রিবিউশন পোর্টেবিলিটি: উবুন্টু (Ubuntu), রেল (RHEL), কোরওস (CoreOS), অন-প্রিমিসেস (on-premises),
প্রধান পাবলিক ক্লাউডসর উপর, এবং অন্য কোথাও চলে।
* অ্যাপ্লিকেশন-কেন্দ্রিক ব্যবস্থাপনা: ভার্চুয়াল হার্ডওয়্যারে একটি OS চালানো থেকে
লজিক্যাল রিসোর্স ব্যবহার করে একটি OS-এ একটি অ্যাপ্লিকেশন চালানো পর্যন্ত বিমূর্ততার স্তর বাড়ায়।
* ঢিলেঢালাভাবে সংযুক্ত, বিতরণ করা, স্থিতিস্থাপক, মুক্ত মাইক্রো-পরিষেবা: অ্যাপ্লিকেশনগুলিকে
ছোট, স্বাধীন টুকরোগুলিতে বিভক্ত করা হয় এবং গতিশীলভাবে স্থাপন ও পরিচালনা করা যায় –
একটি বড় একক-উদ্দেশ্য মেশিনে চলমান একটি মনোলিথিক স্ট্যাক নয়।.
* রিসোর্স আইসোলেশন: অনুমানযোগ্য অ্যাপ্লিকেশন কর্মক্ষমতা।
* রিসোর্স ব্যবহার: উচ্চ দক্ষতা এবং ঘনত্ব।
## {{% heading "whatsnext" %}}
* [কুবারনেটিস উপাদান](/bn/docs/concepts/overview/components/) একবার দেখুন

6
content/bn/docs/concepts/overview/working-with-objects/_index.md
View File

@ -1,7 +1,7 @@
---
title: কুবারনেটিসে অবজেক্ট
content_type: concept
weight: 10
weight: 30
description: >
কুবারনেটিস অবজেক্ট হল কুবারনেটিস সিস্টেমে স্থায়ী সত্তা।
কুবারনেটিস আপনার ক্লাস্টারের অবস্থার প্রতিনিধিত্ব করতে এই সত্তাগুলি ব্যবহার করে।
@ -73,7 +73,7 @@ card:
কিছু মৌলিক তথ্য (যেমন নাম) প্রদান করতে হবে। যখন আপনি অবজেক্ট তৈরি
করতে কুবারনেটিস API ব্যবহার করেন (এটা সরাসরি বা `kubectl` এর মাধ্যমে),
তখন ঐ API অনুরোধটি এই তথ্যকে একটি JSON রিকোয়েস্ট বডি হিসেবে অন্তর্ভুক্ত করতে হবে।
সাধারণত, আপনি একটি manifest নামে পরিচিত ফাইলে kubectl কে তথ্য প্রদান করেন। নিয়ম অনুসারে, ম্যানিফেস্ট হল YAML (আপনি JSON
সাধারণত, আপনি একটি manifest নামে পরিচিত ফাইলে `kubectl` কে তথ্য প্রদান করেন। নিয়ম অনুসারে, ম্যানিফেস্ট হল YAML (আপনি JSON
ফরম্যাটও ব্যবহার করতে পারেন)। HTTP-এর মাধ্যমে API অনুরোধ করার সময় টুল যেমন kubectl একটি ম্যানিফেস্ট থেকে তথ্যকে JSON বা অন্য
সমর্থিত সিরিয়ালাইজেশন ফরম্যাটে রূপান্তর করে।
@ -172,4 +172,4 @@ YAML কনফিগারেশন ফাইল লেখার অতিরি
* [Kubernetes API overview](/bn/docs/reference/using-api/)
কুবারনেটিসে অবজেক্টগুলির বিস্তারিত জানতে, এই বিভাগে অন্যান্য পৃষ্ঠাগুলি পড়ুন:
<!-- Docsy automatically includes a list of pages in the section -->
<!-- Docsy automatically includes a list of pages in the section -->

9
content/bn/docs/concepts/services-networking/_index.md
View File

@ -7,7 +7,8 @@ description: >
## কুবারনেটিস নেটওয়ার্ক মডেল
একটি ক্লাস্টারের প্রতিটি [`পড`](/bn/docs/concepts/workloads/pods/) তার নিজস্ব ক্লাস্টার-ওয়াইড আইপি ঠিকানা পায়।
একটি ক্লাস্টারের প্রতিটি [`পড`](/bn/docs/concepts/workloads/pods/) তার নিজস্ব ক্লাস্টার-ওয়াইড আইপি ঠিকানা পায়
(প্রতি আইপি এড্রেস ফ্যামিলিতে একটি আইপি এড্রেস)।
এর অর্থ হলো আপনাকে `পডের` মধ্যে স্পষ্টভাবে লিঙ্ক তৈরি করার দরকার নেই
এবং পোর্টগুলো হোস্ট করার জন্য আপনাকে ম্যাপিং কন্টেইনার পোর্টগুলোর সাথে মোকাবিলা করতে হবে না।
এটি একটি পরিষ্কার, পিছনের-সামঞ্জস্যপূর্ণ মডেল (backwards-compatible model) তৈরি করে
@ -23,9 +24,9 @@ description: >
* একটি নোডের এজেন্ট (যেমন system daemons, kubelet) সেই নোডের সমস্ত
পডের সাথে যোগাযোগ করতে পারে
দ্রষ্টব্য: হোস্ট নেটওয়ার্কে (যেমন লিনাক্স) চলমান `পডগুলোকে` সমর্থন করে এমন প্ল্যাটফর্মগুলোর জন্য,
যখন পডগুলো একটি নোডের হোস্ট নেটওয়ার্কের সাথে সংযুক্ত থাকে তখনও
তারা সমস্ত নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে NAT ছাড়া ৷
{{< note >}}
হোস্ট নেটওয়ার্কে (যেমন লিনাক্স) চলমান `পডগুলোকে` সমর্থন করে এমন প্ল্যাটফর্মগুলোর জন্য, যখন পডগুলো একটি নোডের হোস্ট নেটওয়ার্কের সাথে সংযুক্ত থাকে তখনও তারা সমস্ত নোডের সমস্ত পডের সাথে যোগাযোগ করতে পারে NAT ছাড়া ৷
{{< /note >}}
এই মডেলটি শুধুমাত্র সামগ্রিকভাবে কম জটিল নয়,
এটি প্রধানত কুবারনেটিসের ইচ্ছার সাথে সামঞ্জস্যপূর্ণ যাতে ভিএম থেকে কন্টেইনারে

22
content/bn/docs/reference/glossary/container-runtime-interface.md Normal file
View File

@ -0,0 +1,22 @@
---
title: কন্টেইনার রানটাইম ইন্টারফেস (Container Runtime Interface)
id: container-runtime-interface
date: 2021-11-24
full_link: /docs/concepts/architecture/cri
short_description: >
kubelet এবং কন্টেইনার রানটাইমের মধ্যে যোগাযোগের জন্য প্রধান প্রোটোকল।
aka:
tags:
- cri
---
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} এবং কন্টেইনার রানটাইমের এর মধ্যে যোগাযোগের জন্য প্রধান প্রোটোকল।
<!--more-->
কুবারনেটিস কন্টেইনার রানটাইম ইন্টারফেস (CRI)
[নোড কম্পোনেন্ট](/docs/concepts/architecture/#node-components)
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} এবং
{{< glossary_tooltip text="কন্টেইনার রানটাইমের" term_id="container-runtime" >}}
মধ্যে যোগাযোগের জন্য প্রধান [gRPC](https://grpc.io) প্রোটোকলকে সংজ্ঞায়িত করে।

2
content/bn/docs/reference/glossary/kube-apiserver.md
View File

@ -2,7 +2,7 @@
title: API সার্ভার
id: kube-apiserver
date: 2018-04-12
full_link: /bn/docs/concepts/overview/components/#kube-apiserver
full_link: /docs/concepts/architecture/#kube-apiserver
short_description: >
কন্ট্রোল প্লেন উপাদান যা কুবারনেটিস API পরিবেশন করে।

92
content/bn/docs/setup/production-environment/_index.md
View File

@ -45,11 +45,11 @@ no_list: true
অ্যাডমিন সুবিধা রয়েছে। কিন্তু গুরুত্বপূর্ণ ওয়ার্কলোড সহ ভাগ করা ক্লাস্টার, এবং
এক বা দুইজনের বেশি ব্যবহারকারীর জন্য কে এবং কি ক্লাস্টার রিসোর্স অ্যাক্সেস করতে পারে তার
জন্য আরও পরিমার্জিত পদ্ধতির প্রয়োজন। আপনি রোল-বেসড অ্যাক্সেস কন্ট্রোল
([RBAC](/bn/docs/reference/access-authn-authz/rbac/)) এবং অন্যান্য
([RBAC](/docs/reference/access-authn-authz/rbac/)) এবং অন্যান্য
নিরাপত্তা ব্যবস্থা ব্যবহার করতে পারেন যাতে ব্যবহারকারী এবং ওয়ার্কলোড তাদের প্রয়োজনীয়
রিসোর্সগুলিতে অ্যাক্সেস পেতে পারে ওয়ার্কলোড, এবং ক্লাস্টার নিজেই নিরাপদ।
[পলিসি](/bn/docs/concepts/policy/) এবং
[কন্টেইনার রিসোর্স](/bn/docs/concepts/configuration/manage-resources-containers/) পরিচালনার মাধ্যমে
[কন্টেইনার রিসোর্স](/docs/concepts/configuration/manage-resources-containers/) পরিচালনার মাধ্যমে
ব্যবহারকারী এবং ওয়ার্কলোড যে রিসোর্সগুলি অ্যাক্সেস করতে পারে তার উপর আপনি সীমা নির্ধারণ করতে পারেন।
কুবারনেটিস প্রোডাকশন এনভায়রনমেন্ট নিজে থেকে তৈরি করার আগে, এই
@ -86,7 +86,7 @@ no_list: true
সহজতম কুবারনেটিস ক্লাস্টারে একই মেশিনে পুরো কন্ট্রোল প্লেন এবং ওয়ার্কার
নোড সার্ভিসগুলি চলে। আপনি ওয়ার্কার নোডগুলি যোগ করে সেই এনভায়রনমেন্ট
বাড়াতে পারেন, যেমনটি [কুবারনেটিস কম্পোনেন্ট](/bn/docs/concepts/overview/components/) এ
বাড়াতে পারেন, যেমনটি [কুবারনেটিস কম্পোনেন্ট](/docs/concepts/overview/components/) এ
চিত্রিত চিত্রে প্রতিফলিত হয়েছে।
যদি ক্লাস্টারটি অল্প সময়ের জন্য পাওয়া যায় বা কিছু গুরুতর ভুল হয়ে গেলে তা
বাতিল করা যেতে পারে, তাহলে এটি আপনার প্রয়োজন মেটাতে পারে।
@ -107,10 +107,10 @@ no_list: true
- *সার্টিফিকেট পরিচালনা করুন*: কন্ট্রোল প্লেন সার্ভিসগুলির মধ্যে সুরক্ষিত যোগাযোগ সার্টিফিকেট
ব্যবহার করে প্রয়োগ করা হয়। সার্টিফিকেটগুলি স্থাপনের সময় স্বয়ংক্রিয়ভাবে তৈরি হয় বা
আপনি আপনার নিজের সার্টিফিকেট কর্তৃপক্ষ ব্যবহার করে সেগুলি তৈরি করতে পারেন৷
বিস্তারিত জানার জন্য [PKI সার্টিফিকেট এবং প্রয়োজনীয়তা](/bn/docs/setup/best-practices/certificates/) দেখুন।
বিস্তারিত জানার জন্য [PKI সার্টিফিকেট এবং প্রয়োজনীয়তা](/docs/setup/best-practices/certificates/) দেখুন।
- *apiserver এর জন্য লোড ব্যালেন্সার কনফিগার করুন*: বিভিন্ন নোডে চলমান apiserver
সার্ভিস দৃষ্টান্তগুলিতে বহিরাগত API অনুরোধগুলি বিতরণ করতে একটি লোড ব্যালেন্সার কনফিগার করুন। দেখুন
[একটি বাহ্যিক লোড ব্যালেন্সার তৈরি করুন](/bn/docs/tasks/access-application-cluster/create-external-load-balancer/)
[একটি বাহ্যিক লোড ব্যালেন্সার তৈরি করুন](/docs/tasks/access-application-cluster/create-external-load-balancer/)
বিস্তারিত জানার জন্য.
- *পৃথক এবং ব্যাকআপ etcd সার্ভিস*: etcd সার্ভিসগুলি হয় অন্যান্য কন্ট্রোল প্লেন
সার্ভিসগুলির মতো একই মেশিনে চলতে পারে বা অতিরিক্ত নিরাপত্তা এবং প্রাপ্যতার জন্য
@ -118,8 +118,8 @@ no_list: true
তাই etcd ডাটাবেসের ব্যাকআপ নিয়মিত করা উচিত যাতে আপনি প্রয়োজনে
সেই ডাটাবেসটি মেরামত করতে পারেন।
etcd কনফিগার করা এবং ব্যবহার করার বিষয়ে বিস্তারিত জানার জন্য [etcd FAQ](https://etcd.io/docs/v3.5/faq/) দেখুন।
[কুবারনেটিস-এর জন্য অপারেটিং etcd ক্লাস্টার](/bn/docs/tasks/administer-cluster/configure-upgrade-etcd/)
দেখুন এবং [kubeadm-এর সাথে একটি উচ্চ প্রাপ্যতা etcd ক্লাস্টার সেট আপ করুন](/bn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
[কুবারনেটিস-এর জন্য অপারেটিং etcd ক্লাস্টার](/docs/tasks/administer-cluster/configure-upgrade-etcd/)
দেখুন এবং [kubeadm-এর সাথে একটি উচ্চ প্রাপ্যতা etcd ক্লাস্টার সেট আপ করুন](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
বিস্তারিত জানার জন্য।
- *মাল্টিপল কন্ট্রোল প্লেন সিস্টেম তৈরি করুন*: উচ্চ প্রাপ্যতা জন্য,
কন্ট্রোল প্লেন একটি একক মেশিনে সীমাবদ্ধ করা উচিত নয়। যদি কন্ট্রোল প্লেন
@ -137,25 +137,25 @@ no_list: true
একই রিজিওনে মাল্টিপল জোনে
একটি ক্লাস্টার ছড়িয়ে দেওয়ার মাধ্যমে, এটি একটি জোন অপ্রাপ্য হয়ে গেলেও
আপনার ক্লাস্টারটি কাজ করা চালিয়ে যাওয়ার সম্ভাবনাকে উন্নত করতে পারে।
বিস্তারিত জানার জন্য [মাল্টিপল জোনে চলমান](/bn/docs/setup/best-practices/multiple-zones/) দেখুন।
বিস্তারিত জানার জন্য [মাল্টিপল জোনে চলমান](/docs/setup/best-practices/multiple-zones/) দেখুন।
- *চলমান ফিচারগুলি পরিচালনা করুন*: আপনি যদি সময়ের সাথে সাথে আপনার ক্লাস্টার রাখার পরিকল্পনা করেন
তবে এর স্বাস্থ্য এবং নিরাপত্তা বজায় রাখার জন্য আপনাকে কিছু কাজ করতে হবে। উদাহরণস্বরূপ,
আপনি যদি kubeadm-এর সাথে ইনস্টল করেন, তাহলে আপনাকে
[সার্টিফিকেট ম্যানেজমেন্ট](/bn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)
এবং [kubeadm ক্লাস্টার আপগ্রেড করা](/bn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) সাহায্য করার জন্য নির্দেশাবলী রয়েছে।
[সার্টিফিকেট ম্যানেজমেন্ট](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)
এবং [kubeadm ক্লাস্টার আপগ্রেড করা](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) সাহায্য করার জন্য নির্দেশাবলী রয়েছে।
কুবারনেটিস অ্যাডমিনিস্ট্রেটিভ কাজগুলির একটি দীর্ঘ তালিকার জন্য
[একটি ক্লাস্টার পরিচালনা](/bn/docs/tasks/administer-cluster/) দেখুন।
[একটি ক্লাস্টার পরিচালনা](/docs/tasks/administer-cluster/) দেখুন।
আপনি যখন কন্ট্রোল প্লেন সার্ভিসগুলি চালান তখন এভেইল্যাবল বিকল্পগুলি সম্পর্কে জানতে,
[kube-apiserver](/bn/docs/reference/command-line-tools-reference/kube-apiserver/),
[kube-controller-manager](/bn/docs/reference/command-line-tools-reference/kube-controller-manager/) দেখুন,
এবং [kube-scheduler](/bn/docs/reference/command-line-tools-reference/kube-scheduler/)
[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) দেখুন,
এবং [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)
কম্পোনেন্ট পৃষ্ঠা। হাইলি এভেইল্যাবল কন্ট্রোল প্লেন উদাহরণের জন্য,
[হাইলি এভেইল্যাবল টপোলজির বিকল্পগুলি](/bn/docs/setup/production-environment/tools/kubeadm/ha-topology/),
[kubeadm-এর সাহায্যে হাইলি এভেইল্যাবল ক্লাস্টার তৈরি করা](/bn/docs/setup/production-environment/tools/kubeadm/high-availability/) দেখুন,
এবং [অপারেটিং etcd ক্লাস্টার-এর জন্য কুবারনেটিস](/bn/docs/tasks/administer-cluster/configure-upgrade-etcd/)।
[হাইলি এভেইল্যাবল টপোলজির বিকল্পগুলি](/docs/setup/production-environment/tools/kubeadm/ha-topology/),
[kubeadm-এর সাহায্যে হাইলি এভেইল্যাবল ক্লাস্টার তৈরি করা](/docs/setup/production-environment/tools/kubeadm/high-availability/) দেখুন,
এবং [অপারেটিং etcd ক্লাস্টার-এর জন্য কুবারনেটিস](/docs/tasks/administer-cluster/configure-upgrade-etcd/)।
একটি etcd ব্যাকআপ প্ল্যান তৈরির তথ্যের জন্য
[একটি etcd ক্লাস্টার ব্যাক আপ করা](/bn/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) দেখুন।
[একটি etcd ক্লাস্টার ব্যাক আপ করা](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) দেখুন।
### প্রোডাকশন ওয়ার্কার নোড
@ -167,13 +167,13 @@ no_list: true
- *নোডগুলি কনফিগার করুন*: নোডগুলি ফিজিক্যাল বা ভার্চুয়াল মেশিন হতে পারে। আপনি যদি
নিজের নোডগুলি তৈরি করতে এবং পরিচালনা করতে চান তবে আপনি একটি সমর্থিত অপারেটিং সিস্টেম ইনস্টল করতে পারেন,
তারপরে উপযুক্ত [নোড সার্ভিসগুলি](/bn/docs/concepts/overview/components/#node-components)
তারপরে উপযুক্ত [নোড সার্ভিসগুলি](/docs/concepts/architecture/#node-components)
যোগ করুন এবং চালান। বিবেচনা করুন:
- উপযুক্ত মেমরি, সিপি উ, এবং ডিস্কের গতি এবং স্টোরেজ ক্ষমতা এভেইল্যাবল থাকার মাধ্যমে আপনি যখন নোড সেট আপ করেন তখন আপনার ওয়ার্কলোডের চাহিদা।
- জেনেরিক কম্পিউটার সিস্টেমগুলি করবে কিনা বা আপনার কাছে এমন ওয়ার্কলোড আছে যেগুলির জন্য জিপিউ প্রসেসর, উইন্ডোজ নোড, বা ভিএম আইসোলেশন প্রয়োজন।
- *ভ্যালিডেট নোড*: কিভাবে একটি নোড একটি কুবারনেটিস ক্লাস্টারে
যোগদানের প্রয়োজনীয়তা পূরণ করে তা নিশ্চিত করার তথ্যের জন্য
[ভ্যালিড নোড সেটআপ](/bn/docs/setup/best-practices/node-conformance/) দেখুন।
[ভ্যালিড নোড সেটআপ](/docs/setup/best-practices/node-conformance/) দেখুন।
- *ক্লাস্টারে নোড যোগ করুন*: আপনি যদি নিজের ক্লাস্টার পরিচালনা করেন তাহলে আপনি
আপনার নিজস্ব মেশিন সেট আপ করে নোড যোগ করতে পারেন এবং হয় সেগুলিকে ম্যানুয়ালি যোগ করে অথবা
ক্লাস্টারের apiserver এ নিজেদের নিবন্ধন করতে পারেন। এই উপায়ে
@ -181,14 +181,14 @@ no_list: true
- *নোড স্কেল করুন*: আপনার ক্লাস্টারের শেষ পর্যন্ত যে ক্ষমতা প্রয়োজন তা প্রসারিত করার জন্য একটি
পরিকল্পনা করুন। আপনার চালানোর জন্য কতগুলি পড এবং কন্টেইনার প্রয়োজন
তার উপর ভিত্তি করে আপনার কতগুলি নোড প্রয়োজন তা নির্ধারণ করতে সাহায্য করতে
[বড় ক্লাস্টারগুলির জন্য বিবেচনা](/bn/docs/setup/best-practices/cluster-large/) দেখুন। আপনি যদি নিজে নোড পরিচালনা করেন, তাহলে এর অর্থ
[বড় ক্লাস্টারগুলির জন্য বিবেচনা](/docs/setup/best-practices/cluster-large/) দেখুন। আপনি যদি নিজে নোড পরিচালনা করেন, তাহলে এর অর্থ
হতে পারে আপনার নিজের ফিজিক্যাল টুল কেনা এবং ইনস্টল করা।
- *নোড অটোস্কেল করুন*: আপনার নোডগুলি স্বয়ংক্রিয়ভাবে পরিচালনা করার জন্য উপলব্ধ সরঞ্জামগুলি এবং
তাদের সরবরাহ করা ক্ষমতা সম্পর্কে জানতে
[Cluster Autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling) পড়ুন।
[ক্লাস্টার অটোস্কেলিং](/docs/concepts/cluster-administration/cluster-autoscaling) পড়ুন।
- *নোড স্বাস্থ্য পরীক্ষা সেট আপ করুন*: গুরুত্বপূর্ণ ওয়ার্কলোডের জন্য, আপনি নিশ্চিত করতে চান যে
সেই নোডগুলিতে চলমান নোড এবং পডগুলি স্বাস্থ্যকর।
[নোড প্রবলেম ডিটেক্টর](/bn/docs/tasks/debug-application-cluster/monitor-node-health/)
[নোড প্রবলেম ডিটেক্টর](/docs/tasks/debug-application-cluster/monitor-node-health/)
daemon ব্যবহার করে, আপনি নিশ্চিত করতে পারেন আপনার নোডগুলি সুস্থ।
## প্রোডাকশন ব্যবহারকারী ব্যবস্থাপনা
@ -210,45 +210,45 @@ no_list: true
আপনি কোন অথেনটিকেশন পদ্ধতি ব্যবহার করতে চান তা নির্বাচন করতে পারেন।
প্লাগইন ব্যবহার করে, apiserver আপনার প্রতিষ্ঠানের বিদ্যমান সুবিধা নিতে পারে
অথেনটিকেশন পদ্ধতি, যেমন LDAP বা Kerberos। দেখা
[অথেনটিকেশন](/bn/docs/reference/access-authn-authz/authentication/)
[অথেনটিকেশন](/docs/reference/access-authn-authz/authentication/)
কুবারনেটিস ব্যবহারকারীদের অথেনটিকেশনের এই বিভিন্ন পদ্ধতির বর্ণনার জন্য।
- *অথোরাইজেশন*: আপনি যখন আপনার নিয়মিত ব্যবহারকারীদের অথোরাইজেশন করার জন্য প্রস্তুত হন, আপনি সম্ভবত
RBAC এবং ABAC অথোরাইজেশনের মধ্যে বেছে নেবেন। ব্যবহারকারীর অ্যাকাউন্ট অথোরাইজেশনের জন্য বিভিন্ন মোড পর্যালোচনা করতে
[অথোরাইজেশন ওভারভিউ](/bn/docs/reference/access-authn-authz/authorization/) দেখুন (সেইসাথে আপনার ক্লাস্টারে সার্ভিস
[অথোরাইজেশন ওভারভিউ](/docs/reference/access-authn-authz/authorization/) দেখুন (সেইসাথে আপনার ক্লাস্টারে সার্ভিস
অ্যাকাউন্ট অ্যাক্সেস):
- *রোল-বেসড অ্যাক্সেস কন্ট্রোল* ([RBAC](/bn/docs/reference/access-authn-authz/rbac/)):
- *রোল-বেসড অ্যাক্সেস কন্ট্রোল* ([RBAC](/docs/reference/access-authn-authz/rbac/)):
অথেন্টিকেটেড ব্যবহারকারীদের নির্দিষ্ট সেটের অনুমতি প্রদান করে আপনাকে আপনার ক্লাস্টারে অ্যাক্সেস বরাদ্দ করতে দেয়।
একটি নির্দিষ্ট নেমস্পেস (Role) বা সমগ্র ক্লাস্টার জুড়ে (ClusterRole) অনুমতিগুলি বরাদ্দ
করা যেতে পারে। তারপর RoleBindings এবং ClusterRoleBindings ব্যবহার করে, সেই অনুমতিগুলি নির্দিষ্ট ব্যবহারকারীদের সাথে
সংযুক্ত করা যেতে পারে।
- *অ্যাট্রিবিউট-বেসড অ্যাক্সেস কন্ট্রোল* ([ABAC](/bn/docs/reference/access-authn-authz/abac/)):
- *অ্যাট্রিবিউট-বেসড অ্যাক্সেস কন্ট্রোল* ([ABAC](/docs/reference/access-authn-authz/abac/)):
আপনাকে ক্লাস্টারে রিসোর্স অ্যাট্রিবিউটের উপর ভিত্তি করে পলিসি তৈরি করতে দেয় এবং সেই অ্যাট্রিবিউটগুলির উপর ভিত্তি করে অ্যাক্সেসের
অনুমতি দেয় বা অস্বীকার করে। একটি পলিসি ফাইলের প্রতিটি লাইন ভার্শনিং বৈশিষ্ট্য (apiVersion
এবং kind) এবং বিষয় (ব্যবহারকারী বা গ্রুপ), রিসোর্স বৈশিষ্ট্য,
নন-রিসোর্সে বৈশিষ্ট্য (/version বা /apis) এবং শুধুমাত্র পঠনযোগ্য বৈশিষ্ট্যের সাথে মেলে বিশেষ বৈশিষ্ট্যগুলির একটি মানচিত্র সনাক্ত করে।
বিস্তারিত জানার জন্য [উদাহরণ](/bn/docs/reference/access-authn-authz/abac/#examples) দেখুন.
বিস্তারিত জানার জন্য [উদাহরণ](/docs/reference/access-authn-authz/abac/#examples) দেখুন.
যেহেতু কেউ আপনার প্রোডাকশন কুবারনেটস ক্লাস্টারে অথেনটিকেশন এবং অথোরাইজেশন সেট আপ করছে, এখানে কিছু বিষয় বিবেচনা করার আছেঃ
- *অথোরাইজেশন মোড সেট করুন*: যখন Kubernetes API সার্ভার
([kube-apiserver](/bn/docs/reference/command-line-tools-reference/kube-apiserver/)) শুরু হয়,
([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) শুরু হয়,
তখন সমর্থিত অথেনটিকেশন মোডগুলি *--authorization-mode* ফ্ল্যাগ ব্যবহার করে সেট করতে হবে।
উদাহরণস্বরূপ, *kube-adminserver.yaml* ফাইলে (*/etc/kubernetes/manifests*-এ) সেই ফ্ল্যাগটি
Node,RBAC-তে সেট করা যেতে পারে। এটি অথেন্টিকেটেড অনুরোধের জন্য নোড এবং RBAC অথোরাইজেশনের অনুমতি দেবে।
- *ব্যবহারকারী সার্টিফিকেট এবং রোল বাইন্ডিং (RBAC)ভর্তি নিয়ন্ত্রক বিবেচনা করুন*: আপনি যদি RBAC অথোরাইজেশন ব্যবহার করেন,
ব্যবহারকারীরা একটি CertificateSigningRequest (CSR) তৈরি করতে পারে যা ক্লাস্টার
CA দ্বারা স্বাক্ষরিত হতে পারে। তারপর আপনি প্রতিটি ব্যবহারকারীর রোল এবং ক্লাস্টার রোল বাইন্ড করতে পারেন।
বিস্তারিত জানার জন্য [সার্টিফিকেট স্বাক্ষরের অনুরোধ](/bn/docs/reference/access-authn-authz/certificate-signing-requests/)
বিস্তারিত জানার জন্য [সার্টিফিকেট স্বাক্ষরের অনুরোধ](/docs/reference/access-authn-authz/certificate-signing-requests/)
দেখুন।
- *অ্যাট্রিবিউটগুলিকে একত্রিত করে এমন পলিসি তৈরি করুন (ABAC)*: আপনি যদি ABAC অথোরাইজেশন ব্যবহার করেন,
আপনি নির্দিষ্ট রিসোর্সগুলি (যেমন একটি পড), নেমস্পেস, বা apiGroup অ্যাক্সেস করার জন্য নির্বাচিত
ব্যবহারকারী বা গ্রুপগুলিকে অথোরাইজেশন করার জন্য পলিসিগুলি গঠনের জন্য অ্যাট্রিবিউটগুলিকে সংমিশ্রণ
বরাদ্দ করতে পারেন। আরও তথ্যের জন্য,
[উদাহরণ](/bn/docs/reference/access-authn-authz/abac/#examples) দেখুন।
[উদাহরণ](/docs/reference/access-authn-authz/abac/#examples) দেখুন।
- *অ্যাডমিশন কন্ট্রোলারদের বিবেচনা করুন*: API সার্ভারের মাধ্যমে যে অনুরোধগুলি
আসতে পারে তার অথোরাইজেশনের অতিরিক্ত ফর্মগুলির মধ্যে রয়েছে
[ওয়েবহুক টোকেন অথেনটিকেশন](/bn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)।
API সার্ভারে [অ্যাডমিশন কন্ট্রোলার](/bn/docs/reference/access-authn-authz/admission-controllers/)
[ওয়েবহুক টোকেন অথেনটিকেশন](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)।
API সার্ভারে [অ্যাডমিশন কন্ট্রোলার](/docs/reference/access-authn-authz/admission-controllers/)
যোগ করে ওয়েবহুক এবং অন্যান্য বিশেষ অথোরাইজেশনের ধরন
সক্ষম করতে হবে।
@ -259,23 +259,23 @@ no_list: true
এই আইটেমগুলি বিবেচনা করুনঃ
- *নেমস্পেস সীমা সেট করুন*: মেমরি এবং সিপিইউ এর মত জিনিসগুলিতে প্রতি-নেমস্পেস কোটা সেট করুন। বিস্তারিত
জানার জন্য [Manage Memory, CPU, and API Resources](/bn/docs/tasks/administer-cluster/manage-resources/)
জানার জন্য [Manage Memory, CPU, and API Resources](/docs/tasks/administer-cluster/manage-resources/)
দেখুন। এছাড়াও আপনি উত্তরাধিকার
সীমার জন্য [হায়ারার্কিক্যাল নেমস্পেস](/blog/2020/08/14/introducing-hierarchical-namespaces/)
সেট করতে পারেন।
- *ডিএনএস চাহিদার জন্য প্রস্তুত করুন*: আপনি যদি আশা করেন যে ওয়ার্কলোড ব্যাপকভাবে বৃদ্ধি পাবে,
আপনার DNS সার্ভিসটিও স্কেল বাড়াতে প্রস্তুত থাকতে হবে। দেখুন
[একটি ক্লাস্টারে DNS সার্ভিসটি অটোস্কেল করুন](/bn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)।
[একটি ক্লাস্টারে DNS সার্ভিসটি অটোস্কেল করুন](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)।
- *অতিরিক্ত সার্ভিস অ্যাকাউন্ট তৈরি করুন*: ব্যবহারকারীর অ্যাকাউন্টগুলি নির্ধারণ করে যে ব্যবহারকারীরা
একটি ক্লাস্টারে কী করতে পারে, যখন একটি সার্ভিস অ্যাকাউন্ট একটি নির্দিষ্ট নেমস্পেসের মধ্যে পড
অ্যাক্সেসকে সংজ্ঞায়িত করে। ডিফল্টরূপে, একটি পড তার নেমস্পেস থেকে ডিফল্ট সার্ভিস অ্যাকাউন্টে নেয়।
একটি নতুন সার্ভিস অ্যাকাউন্ট তৈরি করার তথ্যের জন্য [সার্ভিস অ্যাকাউন্ট পরিচালনা করা](/bn/docs/reference/access-authn-authz/service-accounts-admin/)
একটি নতুন সার্ভিস অ্যাকাউন্ট তৈরি করার তথ্যের জন্য [সার্ভিস অ্যাকাউন্ট পরিচালনা করা](/docs/reference/access-authn-authz/service-accounts-admin/)
দেখুন। উদাহরণস্বরূপ, আপনি চাইতে পারেন:
- সিক্রেট যোগ করুন যা একটি পড একটি নির্দিষ্ট কন্টেইনার রেজিস্ট্রি থেকে ইমেজ পুল করতে ব্যবহার করতে পারে।
উদাহরণের জন্য [পডের জন্য সার্ভিস অ্যাকাউন্ট কনফিগার করুন](/bn/docs/tasks/configure-pod-container/configure-service-account/)
উদাহরণের জন্য [পডের জন্য সার্ভিস অ্যাকাউন্ট কনফিগার করুন](/docs/tasks/configure-pod-container/configure-service-account/)
দেখুন।
- একটি সার্ভিস অ্যাকাউন্টে RBAC অনুমতিগুলি বরাদ্দ করুন৷ বিস্তারিত জানার জন্য
[সার্ভিস অ্যাকাউন্ট অনুমতি](/bn/docs/reference/access-authn-authz/rbac/#service-account-permissions)
[সার্ভিস অ্যাকাউন্ট অনুমতি](/docs/reference/access-authn-authz/rbac/#service-account-permissions)
দেখুন।
## {{% heading "whatsnext" %}}
@ -285,17 +285,17 @@ no_list: true
অথবা [কুবারনেটিস অংশীদার](/bn/partners/) থেকে একটি পেতে চান।
- আপনি যদি নিজের ক্লাস্টার তৈরি করতে চান,
তাহলে পরিকল্পনা করুন আপনি কীভাবে
[সার্টিফিকেট](/bn/docs/setup/best-practices/certificates/) পরিচালনা করতে চান এবং
[etcd](/bn/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
[সার্টিফিকেট](/docs/setup/best-practices/certificates/) পরিচালনা করতে চান এবং
[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
এর মতো ফিচারগুলির জন্য উচ্চ প্রাপ্যতা সেট আপ করুন)
এবং [API সার্ভার](/bn/docs/setup/production-environment/tools/kubeadm/ha-topology/)।
এবং [API সার্ভার](/docs/setup/production-environment/tools/kubeadm/ha-topology/)।
- [kubeadm](/bn/docs/setup/production-environment/tools/kubeadm/) থেকে ডিপ্লয়মেন্ট পদ্ধতি বেছে নিন,
[kops](https://kops.sigs.k8s.io/) অথবা
[Kubespray](https://kubespray.io/)।
- আপনার [অথেনটিকেশন](/bn/docs/reference/access-authn-authz/authentication/)
এবং [অথোরাইজেশন](/bn/docs/reference/access-authn-authz/authorization/)
- আপনার [অথেনটিকেশন](/docs/reference/access-authn-authz/authentication/)
এবং [অথোরাইজেশন](/docs/reference/access-authn-authz/authorization/)
পদ্ধতি নির্ধারণ করে ব্যবহারকারী ব্যবস্থাপনা কনফিগার করুন।
- [রিসোর্স লিমিট](/bn/docs/tasks/administer-cluster/manage-resources/),
[DNS autoscaling](/bn/docs/tasks/administer-cluster/dns-horizontal-autoscaling)
- [রিসোর্স লিমিট](/docs/tasks/administer-cluster/manage-resources/),
[DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling)
সেট আপ করে অ্যাপ্লিকেশন ওয়ার্কলোডের জন্য প্রস্তুত করুন /) এবং
[সার্ভিস অ্যাকাউন্ট](/bn/docs/reference/access-authn-authz/service-accounts-admin/)।
[সার্ভিস অ্যাকাউন্ট](/docs/reference/access-authn-authz/service-accounts-admin/)।

5
content/bn/examples/admin/dns/dnsutils.yaml
View File

@ -6,9 +6,6 @@ metadata:
spec:
containers:
- name: dnsutils
image: registry.k8s.io/e2e-test-images/jessie-dnsutils:1.3
command:
- sleep
- "infinity"
image: registry.k8s.io/e2e-test-images/agnhost:2.39
imagePullPolicy: IfNotPresent
restartPolicy: Always

2
content/de/docs/contribute/participate/_index.md
View File

@ -51,7 +51,7 @@ Automatisierung die Informationen aus den `OWNERS`-Dateien.
### OWNERS Dateien und Front-Matter
Das Kubernetes-Projekt verwendet ein Automatisierungstool namens prow für die Automatisierung im Zusammenhang mit GitHub-Issues und Pull-Requests.
Das [Kubernetes-Website-Repository](https://github.com/kubernetes/website) verwendet zwei [prow-Plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins):
Das [Kubernetes-Website-Repository](https://github.com/kubernetes/website) verwendet zwei [prow-Plugins](https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins):
- blunderbuss
- approve

0
content/en/blog/_posts/2021-08-16-support-for-hostprocess-containers/hostprocess-architecture.png Executable file → Normal file
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 71 KiB

After

Width:  |  Height:  |  Size: 71 KiB

2
content/en/blog/_posts/2023-08-31-legacy-package-repository-deprecation/index.md
View File

@ -51,7 +51,7 @@ generally using their own Kubernetes distributions and therefore they don't use
packages provided by the Kubernetes project; more importantly, if someone else is
managing Kubernetes for you, then they would usually take responsibility for that check.
If you have a managed [control plane](/docs/concepts/overview/components/#control-plane-components)
If you have a managed [control plane](/docs/concepts/architecture/#control-plane-components)
but you are responsible for **managing the nodes yourself**, and any of those nodes run Linux,
you should [check](#check-if-affected) whether you are affected.

2
content/en/blog/_posts/2023-09-26-happy-7th-birthday-kubeadm.md
View File

@ -31,7 +31,7 @@ To keep kubeadm lean, focused, and vendor/infrastructure agnostic, the following
Infrastructure provisioning, for example, is left to other SIG Cluster Lifecycle projects, such as the
[Cluster API](https://cluster-api.sigs.k8s.io/). Instead, kubeadm covers only the common denominator
in every Kubernetes cluster: the
[control plane](/docs/concepts/overview/components/#control-plane-components).
[control plane](/docs/concepts/architecture/#control-plane-components).
The user may install their preferred networking solution and other add-ons on top of Kubernetes
*after* cluster creation.

2
content/en/blog/_posts/2023-11-07-introducing-sig-etcd.md
View File

@ -16,7 +16,7 @@ Special Interest Groups (SIGs) are a fundamental part of the Kubernetes project,
## The critical role of etcd
If we look inside the control plane of a Kubernetes cluster, we will find [etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd), a consistent and highly-available key value store used as Kubernetes' backing store for all cluster data -- this description alone highlights the critical role that etcd plays, and the importance of it within the Kubernetes ecosystem.
If we look inside the control plane of a Kubernetes cluster, we will find [etcd](https://kubernetes.io/docs/concepts/architecture/#etcd), a consistent and highly-available key value store used as Kubernetes' backing store for all cluster data -- this description alone highlights the critical role that etcd plays, and the importance of it within the Kubernetes ecosystem.
This critical role makes the health of the etcd project and community an important consideration, and [concerns about the state of the project](https://groups.google.com/a/kubernetes.io/g/steering/c/e-O-tVSCJOk/m/N9IkiWLEAgAJ) in early 2022 did not go unnoticed. The changes in the maintainer team, amongst other factors, contributed to a situation that needed to be addressed.

2
content/en/blog/_posts/2024-05-21-sig-node-spotlight/index.md
View File

@ -62,7 +62,7 @@ with cheap hardware to large AI/ML-optimized GPU-enabled nodes. Nodes may stay o
maybe be short-lived and be preempted at any moment as they are running on excess compute of a cloud
provider.
[`kubelet`](/docs/concepts/overview/components/#kubelet) — the
[`kubelet`](/docs/concepts/architecture/#kubelet) — the
Kubernetes agent on a node — must work in all these environments reliably. As for the performance
of kubelet operations, this is becoming increasingly important today. On one hand, as Kubernetes is
being used on extra small nodes more and more often in telecom and retail environments, it needs to

100
content/en/blog/_posts/2024-08-15-volume-attributes-class.md Normal file
View File

@ -0,0 +1,100 @@
---
layout: blog
title: "Kubernetes 1.31: VolumeAttributesClass for Volume Modification Beta"
date: 2024-08-15
slug: kubernetes-1-31-volume-attributes-class
author: >
Sunny Song (Google)
Matthew Cary (Google)
---
Volumes in Kubernetes have been described by two attributes: their storage class, and
their capacity. The storage class is an immutable property of the volume, while the
capacity can be changed dynamically with [volume
resize](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims).
This complicates vertical scaling of workloads with volumes. While cloud providers and
storage vendors often offer volumes which allow specifying IO quality of service
(Performance) parameters like IOPS or throughput and tuning them as workloads operate,
Kubernetes has no API which allows changing them.
We are pleased to announce that the [VolumeAttributesClass
KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/3751-volume-attributes-class/README.md),
alpha since Kubernetes 1.29, will be beta in 1.31. This provides a generic,
Kubernetes-native API for modifying volume parameters like provisioned IO.
Like all new volume features in Kubernetes, this API is implemented via the [container
storage interface (CSI)](https://kubernetes-csi.github.io/docs/). In addition to the
VolumeAttributesClass feature gate, your provisioner-specific CSI driver must support the
new ModifyVolume API which is the CSI side of this feature.
See the [full
documentation](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/)
for all details. Here we show the common workflow.
### Dynamically modifying volume attributes.
A `VolumeAttributesClass` is a cluster-scoped resource that specifies provisioner-specific
attributes. These are created by the cluster administrator in the same way as storage
classes. For example, a series of gold, silver and bronze volume attribute classes can be
created for volumes with greater or lessor amounts of provisioned IO.
```yaml
apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
name: silver
driverName: your-csi-driver
parameters:
provisioned-iops: "500"
provisioned-throughput: "50MiB/s"
---
apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
name: gold
driverName: your-csi-driver
parameters:
provisioned-iops: "10000"
provisioned-throughput: "500MiB/s"
```
An attribute class is added to a PVC in much the same way as a storage class.
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pv-claim
spec:
storageClassName: any-storage-class
volumeAttributesClassName: silver
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 64Gi
```
Unlike a storage class, the volume attributes class can be changed:
```
kubectl patch pvc test-pv-claim -p '{"spec": "volumeAttributesClassName": "gold"}'
```
Kubernetes will work with the CSI driver to update the attributes of the
volume. The status of the PVC will track the current and desired attributes
class. The PV resource will also be updated with the new volume attributes class
which will be set to the currently active attributes of the PV.
### Limitations with the beta
As a beta feature, there are still some features which are planned for GA but not yet
present. The largest is quota support, see the
[KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/3751-volume-attributes-class/README.md)
and discussion in
[sig-storage](https://github.com/kubernetes/community/tree/master/sig-storage) for details.
See the [Kubernetes CSI driver
list](https://kubernetes-csi.github.io/docs/drivers.html) for up-to-date
information of support for this feature in CSI drivers.

60
content/en/blog/_posts/2024-08-16-matchlabelkeys-podaffinity.md
View File

@ -7,25 +7,25 @@ author: >
Kensei Nakada (Tetrate)
---
Kubernetes 1.29 introduced new fields `MatchLabelKeys` and `MismatchLabelKeys` in PodAffinity and PodAntiAffinity.
Kubernetes 1.29 introduced new fields `matchLabelKeys` and `mismatchLabelKeys` in `podAffinity` and `podAntiAffinity`.
In Kubernetes 1.31, this feature moves to beta and the corresponding feature gate (`MatchLabelKeysInPodAffinity`) gets enabled by default.
## `MatchLabelKeys` - Enhanced scheduling for versatile rolling updates
## `matchLabelKeys` - Enhanced scheduling for versatile rolling updates
During a workload's (e.g., Deployment) rolling update, a cluster may have Pods from multiple versions at the same time.
However, the scheduler cannot distinguish between old and new versions based on the `LabelSelector` specified in PodAffinity or PodAntiAffinity. As a result, it will co-locate or disperse Pods regardless of their versions.
During a workload's (e.g., Deployment) rolling update, a cluster may have Pods from multiple versions at the same time.
However, the scheduler cannot distinguish between old and new versions based on the `labelSelector` specified in `podAffinity` or `podAntiAffinity`. As a result, it will co-locate or disperse Pods regardless of their versions.
This can lead to sub-optimal scheduling outcome, for example:
- New version Pods are co-located with old version Pods (PodAffinity), which will eventually be removed after rolling updates.
- Old version Pods are distributed across all available topologies, preventing new version Pods from finding nodes due to PodAntiAffinity.
- New version Pods are co-located with old version Pods (`podAffinity`), which will eventually be removed after rolling updates.
- Old version Pods are distributed across all available topologies, preventing new version Pods from finding nodes due to `podAntiAffinity`.
`MatchLabelKeys` is a set of Pod label keys and addresses this problem.
The scheduler looks up the values of these keys from the new Pod's labels and combines them with `LabelSelector`
so that PodAffinity matches Pods that have the same key-value in labels.
`matchLabelKeys` is a set of Pod label keys and addresses this problem.
The scheduler looks up the values of these keys from the new Pod's labels and combines them with `labelSelector`
so that podAffinity matches Pods that have the same key-value in labels.
By using label [pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label) in `MatchLabelKeys`,
you can ensure that only Pods of the same version are evaluated for PodAffinity or PodAntiAffinity.
By using label [pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label) in `matchLabelKeys`,
you can ensure that only Pods of the same version are evaluated for `podAffinity` or `podAntiAffinity`.
```yaml
apiVersion: apps/v1
@ -43,11 +43,11 @@ metadata:
values:
- database
topologyKey: topology.kubernetes.io/zone
matchLabelKeys:
matchLabelKeys:
- pod-template-hash
```
The above matchLabelKeys will be translated in Pods like:
The above `matchLabelKeys` will be translated in Pods like:
```yaml
kind: Pod
@ -68,26 +68,26 @@ metadata:
- key: pod-template-hash # Added from matchLabelKeys; Only Pods from the same replicaset will match this affinity.
operator: In
values:
- xyz
- xyz
topologyKey: topology.kubernetes.io/zone
matchLabelKeys:
matchLabelKeys:
- pod-template-hash
```
## `MismatchLabelKeys` - Service isolation
## `mismatchLabelKeys` - Service isolation
`MismatchLabelKeys` is a set of Pod label keys, like `MatchLabelKeys`,
which looks up the values of these keys from the new Pod's labels, and merge them with `LabelSelector` as `key notin (value)`
so that PodAffinity does _not_ match Pods that have the same key-value in labels.
`mismatchLabelKeys` is a set of Pod label keys, like `matchLabelKeys`,
which looks up the values of these keys from the new Pod's labels, and merge them with `labelSelector` as `key notin (value)`
so that `podAffinity` does _not_ match Pods that have the same key-value in labels.
Suppose all Pods for each tenant get `tenant` label via a controller or a manifest management tool like Helm.
Suppose all Pods for each tenant get `tenant` label via a controller or a manifest management tool like Helm.
Although the value of `tenant` label is unknown when composing each workload's manifest,
Although the value of `tenant` label is unknown when composing each workload's manifest,
the cluster admin wants to achieve exclusive 1:1 tenant to domain placement for a tenant isolation.
`MismatchLabelKeys` works for this usecase;
By applying the following affinity globally using a mutating webhook,
the cluster admin can ensure that the Pods from the same tenant will land on the same domain exclusively,
`mismatchLabelKeys` works for this usecase;
By applying the following affinity globally using a mutating webhook,
the cluster admin can ensure that the Pods from the same tenant will land on the same domain exclusively,
meaning Pods from other tenants won't land on the same domain.
```yaml
@ -108,7 +108,7 @@ affinity:
topologyKey: node-pool
```
The above matchLabelKeys and mismatchLabelKeys will be translated to like:
The above `matchLabelKeys` and `mismatchLabelKeys` will be translated to like:
```yaml
kind: Pod
@ -140,17 +140,17 @@ spec:
- key: tenant
operator: NotIn
values:
- service-a
- service-a
topologyKey: node-pool
```
## Getting involved
## Getting involved
These features are managed by Kubernetes [SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling).
Please join us and share your feedback. We look forward to hearing from you!
## How can I learn more?
## How can I learn more?
- [The official document of PodAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
- [KEP-3633: Introduce MatchLabelKeys and MismatchLabelKeys to PodAffinity and PodAntiAffinity](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3633-matchlabelkeys-to-podaffinity/README.md#story-2)
- [The official document of podAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
- [KEP-3633: Introduce matchLabelKeys and mismatchLabelKeys to podAffinity and podAntiAffinity](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3633-matchlabelkeys-to-podaffinity/README.md#story-2)

115
content/en/blog/_posts/2024-08-20-websocket-transition.md Normal file
View File

@ -0,0 +1,115 @@
---
layout: blog
title: 'Kubernetes 1.31: Streaming Transitions from SPDY to WebSockets'
date: 2024-08-20
slug: websockets-transition
author: >
[Sean Sullivan](https://github.com/seans3) (Google)
[Shannon Kularathna](https://github.com/shannonxtreme) (Google)
---
In Kubernetes 1.31, by default kubectl now uses the WebSocket protocol
instead of SPDY for streaming.
This post describes what these changes mean for you and why these streaming APIs
matter.
## Streaming APIs in Kubernetes
In Kubernetes, specific endpoints that are exposed as an HTTP or RESTful
interface are upgraded to streaming connections, which require a streaming
protocol. Unlike HTTP, which is a request-response protocol, a streaming
protocol provides a persistent connection that's bi-directional, low-latency,
and lets you interact in real-time. Streaming protocols support reading and
writing data between your client and the server, in both directions, over the
same connection. This type of connection is useful, for example, when you create
a shell in a running container from your local workstation and run commands in
the container.
## Why change the streaming protocol?
Before the v1.31 release, Kubernetes used the SPDY/3.1 protocol by default when
upgrading streaming connections. SPDY/3.1 has been deprecated for eight years,
and it was never standardized. Many modern proxies, gateways, and load balancers
no longer support the protocol. As a result, you might notice that commands like
`kubectl cp`, `kubectl attach`, `kubectl exec`, and `kubectl port-forward`
stop working when you try to access your cluster through a proxy or gateway.
As of Kubernetes v1.31, SIG API Machinery has modified the streaming
protocol that a Kubernetes client (such as `kubectl`) uses for these commands
to the more modern [WebSocket streaming protocol](https://datatracker.ietf.org/doc/html/rfc6455).
The WebSocket protocol is a currently supported standardized streaming protocol
that guarantees compatibility and interoperability with different components and
programming languages. The WebSocket protocol is more widely supported by modern
proxies and gateways than SPDY.
## How streaming APIs work
Kubernetes upgrades HTTP connections to streaming connections by adding
specific upgrade headers to the originating HTTP request. For example, an HTTP
upgrade request for running the `date` command on an `nginx` container within
a cluster is similar to the following:
```console
$ kubectl exec -v=8 nginx -- date
GET https://127.0.0.1:43251/api/v1/namespaces/default/pods/nginx/exec?command=date…
Request Headers:
Connection: Upgrade
Upgrade: websocket
Sec-Websocket-Protocol: v5.channel.k8s.io
User-Agent: kubectl/v1.31.0 (linux/amd64) kubernetes/6911225
```
If the container runtime supports the WebSocket streaming protocol and at least
one of the subprotocol versions (e.g. `v5.channel.k8s.io`), the server responds
with a successful `101 Switching Protocols` status, along with the negotiated
subprotocol version:
```console
Response Status: 101 Switching Protocols in 3 milliseconds
Response Headers:
Upgrade: websocket
Connection: Upgrade
Sec-Websocket-Accept: j0/jHW9RpaUoGsUAv97EcKw8jFM=
Sec-Websocket-Protocol: v5.channel.k8s.io
```
At this point the TCP connection used for the HTTP protocol has changed to a
streaming connection. Subsequent STDIN, STDOUT, and STDERR data (as well as
terminal resizing data and process exit code data) for this shell interaction is
then streamed over this upgraded connection.
## How to use the new WebSocket streaming protocol
If your cluster and kubectl are on version 1.29 or later, there are two
control plane feature gates and two kubectl environment variables that
govern the use of the WebSockets rather than SPDY. In Kubernetes 1.31,
all of the following feature gates are in beta and are enabled by
default:
- [Feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
- `TranslateStreamCloseWebsocketRequests`
- `.../exec`
- `.../attach`
- `PortForwardWebsockets`
- `.../port-forward`
- kubectl feature control environment variables
- `KUBECTL_REMOTE_COMMAND_WEBSOCKETS`
- `kubectl exec`
- `kubectl cp`
- `kubectl attach`
- `KUBECTL_PORT_FORWARD_WEBSOCKETS`
- `kubectl port-forward`
If you're connecting to an older cluster but can manage the feature gate
settings, turn on both `TranslateStreamCloseWebsocketRequests` (added in
Kubernetes v1.29) and `PortForwardWebsockets` (added in Kubernetes
v1.30) to try this new behavior. Version 1.31 of `kubectl` can automatically use
the new behavior, but you do need to connect to a cluster where the server-side
features are explicitly enabled.
## Learn more about streaming APIs
- [KEP 4006 - Transitioning from SPDY to WebSockets](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/4006-transition-spdy-to-websockets)
- [RFC 6455 - The WebSockets Protocol](https://datatracker.ietf.org/doc/html/rfc6455)
- [Container Runtime Interface streaming explained](https://kubernetes.io/blog/2024/05/01/cri-streaming-explained/)

38
content/en/blog/_posts/2024-08-21-cgroup-driver-from-cri.md Normal file
View File

@ -0,0 +1,38 @@
---
layout: blog
title: "Kubernetes 1.31: Autoconfiguration For Node Cgroup Driver (beta)"
date: 2024-08-21
slug: cri-cgroup-driver-lookup-now-beta
author: >
Peter Hunt (Red Hat)
---
Historically, configuring the correct cgroup driver has been a pain point for users running new
Kubernetes clusters. On Linux systems, there are two different cgroup drivers:
`cgroupfs` and `systemd`. In the past, both the [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
and CRI implementation (like CRI-O or containerd) needed to be configured to use
the same cgroup driver, or else the kubelet would exit with an error. This was a
source of headaches for many cluster admins. However, there is light at the end of the tunnel!
## Automated cgroup driver detection
In v1.28.0, the SIG Node community introduced the feature gate
`KubeletCgroupDriverFromCRI`, which instructs the kubelet to ask the CRI
implementation which cgroup driver to use. A few minor releases of Kubernetes
happened whilst we waited for support to land in the major two CRI implementations
(containerd and CRI-O), but as of v1.31.0, this feature is now beta!
In addition to setting the feature gate, a cluster admin needs to ensure their
CRI implementation is new enough:
- containerd: Support was added in v2.0.0
- CRI-O: Support was added in v1.28.0
Then, they should ensure their CRI implementation is configured to the
cgroup_driver they would like to use.
## Future work
Eventually, support for the kubelet's `cgroupDriver` configuration field will be
dropped, and the kubelet will fail to start if the CRI implementation isn't new
enough to have support for this feature.

7
content/en/blog/_posts/2024-08-22-Fine-grained-SupplementalGroups-control/index.md
View File

@ -57,7 +57,7 @@ Thus, the group membership defined in `/etc/group` in the container image for th
The _implicitly_ merged group information from `/etc/group` in the container image may cause some concerns particularly in accessing volumes (see [kubernetes/kubernetes#112879](https://issue.k8s.io/112879) for details) because file permission is controlled by uid/gid in Linux. Even worse, the implicit gids from `/etc/group` can not be detected/validated by any policy engines because there is no clue for the implicit group information in the manifest. This can also be a concern for Kubernetes security.
## Fine-grined SupplementalGroups control in a Pod: `SupplementaryGroupsPolicy`
## Fine-grained SupplementalGroups control in a Pod: `SupplementaryGroupsPolicy`
To tackle the above problem, Kubernetes 1.31 introduces new field `supplementalGroupsPolicy` in Pod's `.spec.securityContext`.
@ -153,8 +153,9 @@ the feature gate manually.
## How can I learn more?
<!-- https://github.com/kubernetes/website/pull/46920 -->
Please check out the [documentation](/docs/tasks/configure-pod-container/security-context/)
for the further details of `supplementalGroupsPolicy`.
- [Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
for the further details of `supplementalGroupsPolicy`
- [KEP-3619: Fine-grained SupplementalGroups control](https://github.com/kubernetes/enhancements/issues/3619)
## How to get involved?

BIN
content/en/blog/_posts/2024-08-22-cpumanager-static-policy-distributed-cpu-across-cores/cpu-cache-architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 287 KiB

BIN
content/en/blog/_posts/2024-08-22-cpumanager-static-policy-distributed-cpu-across-cores/cpu-ordering.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 110 KiB

54
content/en/blog/_posts/2024-08-22-cpumanager-static-policy-distributed-cpu-across-cores/index.md Normal file
View File

@ -0,0 +1,54 @@
---
layout: blog
title: 'Kubernetes v1.31: New Kubernetes CPUManager Static Policy: Distribute CPUs Across Cores'
date: 2024-08-22
slug: cpumanager-static-policy-distributed-cpu-across-cores
author: >
[Jiaxin Shan](https://github.com/Jeffwan) (Bytedance)
---
In Kubernetes v1.31, we are excited to introduce a significant enhancement to CPU management capabilities: the `distribute-cpus-across-cores` option for the [CPUManager static policy](/docs/tasks/administer-cluster/cpu-management-policies/#static-policy-options). This feature is currently in alpha and hidden by default, marking a strategic shift aimed at optimizing CPU utilization and improving system performance across multi-core processors.
## Understanding the feature
Traditionally, Kubernetes' CPUManager tends to allocate CPUs as compactly as possible, typically packing them onto the fewest number of physical cores. However, allocation strategy matters, CPUs on the same physical host still share some resources of the physical core, such as the cache and execution units, etc.
{{< figure src="cpu-cache-architecture.png" alt="cpu-cache-architecture" >}}
While default approach minimizes inter-core communication and can be beneficial under certain scenarios, it also poses a challenge. CPUs sharing a physical core can lead to resource contention, which in turn may cause performance bottlenecks, particularly noticeable in CPU-intensive applications.
The new `distribute-cpus-across-cores` feature addresses this issue by modifying the allocation strategy. When enabled, this policy option instructs the CPUManager to spread out the CPUs (hardware threads) across as many physical cores as possible. This distribution is designed to minimize contention among CPUs sharing the same physical core, potentially enhancing the performance of applications by providing them dedicated core resources.
Technically, within this static policy, the free CPU list is reordered in the manner depicted in the diagram, aiming to allocate CPUs from separate physical cores.
{{< figure src="cpu-ordering.png" alt="cpu-ordering" >}}
## Enabling the feature
To enable this feature, users firstly need to add `--cpu-manager-policy=static` kubelet flag or the `cpuManagerPolicy: static` field in KubeletConfiuration. Then user can add `--cpu-manager-policy-options distribute-cpus-across-cores=true` or `distribute-cpus-across-cores=true` to their CPUManager policy options in the Kubernetes configuration or. This setting directs the CPUManager to adopt the new distribution strategy. It is important to note that this policy option cannot currently be used in conjunction with `full-pcpus-only` or `distribute-cpus-across-numa` options.
## Current limitations and future directions
As with any new feature, especially one in alpha, there are limitations and areas for future improvement. One significant current limitation is that `distribute-cpus-across-cores` cannot be combined with other policy options that might conflict in terms of CPU allocation strategies. This restriction can affect compatibility with certain workloads and deployment scenarios that rely on more specialized resource management.
Looking forward, we are committed to enhancing the compatibility and functionality of the `distribute-cpus-across-cores` option. Future updates will focus on resolving these compatibility issues, allowing this policy to be combined with other CPUManager policies seamlessly. Our goal is to provide a more flexible and robust CPU allocation framework that can adapt to a variety of workloads and performance demands.
## Conclusion
The introduction of the `distribute-cpus-across-cores` policy in Kubernetes CPUManager is a step forward in our ongoing efforts to refine resource management and improve application performance. By reducing the contention on physical cores, this feature offers a more balanced approach to CPU resource allocation, particularly beneficial for environments running heterogeneous workloads. We encourage Kubernetes users to test this new feature and provide feedback, which will be invaluable in shaping its future development.
This draft aims to clearly explain the new feature while setting expectations for its current stage and future improvements.
## Further reading
Please check out the [Control CPU Management Policies on the Node](/docs/tasks/administer-cluster/cpu-management-policies/)
task page to learn more about the CPU Manager, and how it fits in relation to the other node-level resource managers.
## Getting involved
This feature is driven by the [SIG Node](https://github.com/Kubernetes/community/blob/master/sig-node/README.md). If you are interested in helping develop this feature, sharing feedback, or participating in any other ongoing SIG Node projects, please attend the SIG Node meeting for more details.

2
content/en/blog/_posts/2024-08-23-kubeadm-v1beta4.md
View File

@ -19,7 +19,7 @@ I'll explain about the kubeadm v1beta4 configuration format,
and how to migrate from v1beta3 to v1beta4.
You can read the reference for the v1beta4 configuration format:
[kubeadm Configuration (v1beta4)]((/docs/reference/config-api/kubeadm-config.v1beta4/)).
[kubeadm Configuration (v1beta4)](/docs/reference/config-api/kubeadm-config.v1beta4/).
### A list of changes since v1beta3

199
content/en/docs/concepts/architecture/_index.md
View File

@ -5,4 +5,201 @@ description: >
The architectural concepts behind Kubernetes.
---
{{< figure src="/images/docs/kubernetes-cluster-architecture.svg" alt="Components of Kubernetes" caption="Kubernetes cluster architecture" class="diagram-large" >}}
A Kubernetes cluster consists of a control plane plus a set of worker machines, called nodes,
that run containerized applications. Every cluster needs at least one worker node in order to run Pods.
The worker node(s) host the Pods that are the components of the application workload.
The control plane manages the worker nodes and the Pods in the cluster. In production
environments, the control plane usually runs across multiple computers and a cluster
usually runs multiple nodes, providing fault-tolerance and high availability.
This document outlines the various components you need to have for a complete and working Kubernetes cluster.
{{< figure src="/images/docs/kubernetes-cluster-architecture.svg" alt="The control plane (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) and several nodes. Each node is running a kubelet and kube-proxy."
title="Kubernetes cluster components"
caption="**Note:** This diagram presents an example reference architecture for a Kubernetes cluster. The actual distribution of components can vary based on specific cluster setups and requirements." class="diagram-large" >}}
## Control plane components
The control plane's components make global decisions about the cluster (for example, scheduling),
as well as detecting and responding to cluster events (for example, starting up a new
{{< glossary_tooltip text="pod" term_id="pod">}} when a Deployment's
`{{< glossary_tooltip text="replicas" term_id="replica" >}}` field is unsatisfied).
Control plane components can be run on any machine in the cluster. However, for simplicity, setup scripts
typically start all control plane components on the same machine, and do not run user containers on this machine.
See [Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
for an example control plane setup that runs across multiple machines.
### kube-apiserver
{{< glossary_definition term_id="kube-apiserver" length="all" >}}
### etcd
{{< glossary_definition term_id="etcd" length="all" >}}
### kube-scheduler
{{< glossary_definition term_id="kube-scheduler" length="all" >}}
### kube-controller-manager
{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
There are many different types of controllers. Some examples of them are:
- Node controller: Responsible for noticing and responding when nodes go down.
- Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion.
- EndpointSlice controller: Populates EndpointSlice objects (to provide a link between Services and Pods).
- ServiceAccount controller: Create default ServiceAccounts for new namespaces.
The above is not an exhaustive list.
### cloud-controller-manager
{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
The cloud-controller-manager only runs controllers that are specific to your cloud provider.
If you are running Kubernetes on your own premises, or in a learning environment inside your
own PC, the cluster does not have a cloud controller manager.
As with the kube-controller-manager, the cloud-controller-manager combines several logically
independent control loops into a single binary that you run as a single process. You can scale
horizontally (run more than one copy) to improve performance or to help tolerate failures.
The following controllers can have cloud provider dependencies:
- Node controller: For checking the cloud provider to determine if a node has been
deleted in the cloud after it stops responding
- Route controller: For setting up routes in the underlying cloud infrastructure
- Service controller: For creating, updating and deleting cloud provider load balancers
## Node components
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
### kubelet
{{< glossary_definition term_id="kubelet" length="all" >}}
### kube-proxy (optional) {#kube-proxy}
{{< glossary_definition term_id="kube-proxy" length="all" >}}
If you use a [network plugin](#network-plugins) that implements packet forwarding for Services
by itself, and providing equivalent behavior to kube-proxy, then you do not need to run
kube-proxy on the nodes in your cluster.
### Container runtime
{{< glossary_definition term_id="container-runtime" length="all" >}}
## Addons
Addons use Kubernetes resources ({{< glossary_tooltip term_id="daemonset" >}},
{{< glossary_tooltip term_id="deployment" >}}, etc) to implement cluster features.
Because these are providing cluster-level features, namespaced resources for
addons belong within the `kube-system` namespace.
Selected addons are described below; for an extended list of available addons,
please see [Addons](/docs/concepts/cluster-administration/addons/).
### DNS
While the other addons are not strictly required, all Kubernetes clusters should have
[cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it.
Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment,
which serves DNS records for Kubernetes services.
Containers started by Kubernetes automatically include this DNS server in their DNS searches.
### Web UI (Dashboard)
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose,
web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications
running in the cluster, as well as the cluster itself.
### Container resource monitoring
[Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
records generic time-series metrics about containers in a central database, and provides a UI for browsing that data.
### Cluster-level Logging
A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible
for saving container logs to a central log store with a search/browsing interface.
### Network plugins
[Network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins)
are software components that implement the container network interface (CNI) specification.
They are responsible for allocating IP addresses to pods and enabling them to communicate
with each other within the cluster.
## Architecture variations
While the core components of Kubernetes remain consistent, the way they are deployed and
managed can vary. Understanding these variations is crucial for designing and maintaining
Kubernetes clusters that meet specific operational needs.
### Control plane deployment options
The control plane components can be deployed in several ways:
Traditional deployment
: Control plane components run directly on dedicated machines or VMs, often managed as systemd services.
Static Pods
: Control plane components are deployed as static Pods, managed by the kubelet on specific nodes.
This is a common approach used by tools like kubeadm.
Self-hosted
: The control plane runs as Pods within the Kubernetes cluster itself, managed by Deployments
and StatefulSets or other Kubernetes primitives.
Managed Kubernetes services
: Cloud providers often abstract away the control plane, managing its components as part of their service offering.
### Workload placement considerations
The placement of workloads, including the control plane components, can vary based on cluster size,
performance requirements, and operational policies:
- In smaller or development clusters, control plane components and user workloads might run on the same nodes.
- Larger production clusters often dedicate specific nodes to control plane components,
separating them from user workloads.
- Some organizations run critical add-ons or monitoring tools on control plane nodes.
### Cluster management tools
Tools like kubeadm, kops, and Kubespray offer different approaches to deploying and managing clusters,
each with its own method of component layout and management.
The flexibility of Kubernetes architecture allows organizations to tailor their clusters to specific needs,
balancing factors such as operational complexity, performance, and management overhead.
### Customization and extensibility
Kubernetes architecture allows for significant customization:
- Custom schedulers can be deployed to work alongside the default Kubernetes scheduler or to replace it entirely.
- API servers can be extended with CustomResourceDefinitions and API Aggregation.
- Cloud providers can integrate deeply with Kubernetes using the cloud-controller-manager.
The flexibility of Kubernetes architecture allows organizations to tailor their clusters to specific needs,
balancing factors such as operational complexity, performance, and management overhead.
## {{% heading "whatsnext" %}}
Learn more about the following:
- [Nodes](/docs/concepts/architecture/nodes/) and
[their communication](/docs/concepts/architecture/control-plane-node-communication/)
with the control plane.
- Kubernetes [controllers](/docs/concepts/architecture/controller/).
- [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) which is the default scheduler for Kubernetes.
- Etcd's official [documentation](https://etcd.io/docs/).
- Several [container runtimes](/docs/setup/production-environment/container-runtimes/) in Kubernetes.
- Integrating with cloud providers using [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/).
- [kubectl](/docs/reference/generated/kubectl/kubectl-commands) commands.

2
content/en/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -120,7 +120,7 @@ up the Konnectivity service in your cluster.
## {{% heading "whatsnext" %}}
* Read about the [Kubernetes control plane components](/docs/concepts/overview/components/#control-plane-components)
* Read about the [Kubernetes control plane components](/docs/concepts/architecture/#control-plane-components)
* Learn more about [Hubs and Spoke model](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors)
* Learn how to [Secure a Cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)

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

@ -161,7 +161,7 @@ controller does.
## {{% heading "whatsnext" %}}
* Read about the [Kubernetes control plane](/docs/concepts/overview/components/#control-plane-components)
* Read about the [Kubernetes control plane](/docs/concepts/architecture/#control-plane-components)
* Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/)
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
* If you want to write your own controller, see

5
content/en/docs/concepts/architecture/garbage-collection.md
View File

@ -144,9 +144,8 @@ until disk usage reaches the `LowThresholdPercent` value.
As a beta feature, you can specify the maximum time a local image can be unused for,
regardless of disk usage. This is a kubelet setting that you configure for each node.
To configure the setting, enable the `ImageMaximumGCAge`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kubelet,
and also set a value for the `imageMaximumGCAge` field in the kubelet configuration file.
To configure the setting, you need to set a value for the `imageMaximumGCAge`
field in the kubelet configuration file.
The value is specified as a Kubernetes _duration_;
Valid time units for the `imageMaximumGCAge` field in the kubelet configuration file are:

4
content/en/docs/concepts/architecture/nodes.md
View File

@ -23,7 +23,7 @@ and contains the services necessary to run
Typically you have several nodes in a cluster; in a learning or resource-limited
environment, you might have only one node.
The [components](/docs/concepts/overview/components/#node-components) on a node include the
The [components](/docs/concepts/architecture/#node-components) on a node include the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, a
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the
{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
@ -352,7 +352,7 @@ see the blog-post about [Kubernetes 1.28: NodeSwap graduates to Beta1](/blog/202
Learn more about the following:
* [Components](/docs/concepts/overview/components/#node-components) that make up a node.
* [Components](/docs/concepts/architecture/#node-components) that make up a node.
* [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
* [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node)
section of the architecture design document.

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

@ -96,8 +96,6 @@ installation instructions. The list does not try to be exhaustive.
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard)
is a dashboard web interface for Kubernetes.
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a
tool for visualizing your containers, Pods, Services and more.
## Infrastructure

54
content/en/docs/concepts/configuration/configmap.md
View File

@ -221,6 +221,54 @@ in a Pod:
in the specified environment variables.
This is an example of defining a ConfigMap as a pod environment variable:
The following ConfigMap (myconfigmap.yaml) stores two properties: username and access_level:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: myconfigmap
data:
username: k8s-admin
access_level: "1"
```
The following command will create the ConfigMap object:
```shell
kubectl apply -f myconfigmap.yaml
```
The following Pod consumes the content of the ConfigMap as environment variables:
{{% code_sample file="configmap/env-configmap.yaml" %}}
The `envFrom` field instructs Kubernetes to create environment variables from the sources nested within it.
The inner `configMapRef` refers to a ConfigMap by its name and selects all its key-value pairs.
Add the Pod to your cluster, then retrieve its logs to see the output from the printenv command.
This should confirm that the two key-value pairs from the ConfigMap have been set as environment variables:
```shell
kubectl apply -f env-configmap.yaml
```
```shell
kubectl logs pod/ env-configmap
```
The output is similar to this:
```console
...
username: "k8s-admin"
access_level: "1"
...
```
Sometimes a Pod won't require access to all the values in a ConfigMap.
For example, you could have another Pod which only uses the username value from the ConfigMap.
For this use case, you can use the `env.valueFrom` syntax instead, which lets you select individual keys in
a ConfigMap. The name of the environment variable can also be different from the key within the ConfigMap.
For example:
```yaml
apiVersion: v1
kind: Pod
@ -236,9 +284,13 @@ spec:
configMapKeyRef:
name: myconfigmap
key: username
```
In the Pod created from this manifest, you will see that the environment variable
`CONFIGMAP_USERNAME` is set to the value of the `username` value from the ConfigMap.
Other keys from the ConfigMap data are not copied into the environment.
It's important to note that the range of characters allowed for environment
variable names in pods is [restricted](/docs/tasks/inject-data-application/define-environment-variable-container/#using-environment-variables-inside-of-your-config).
If any keys do not meet the rules, those keys are not made available to your container, though

4
content/en/docs/concepts/configuration/liveness-readiness-startup-probes.md
View File

@ -40,6 +40,6 @@ A startup probe verifies whether the application within a container is started.
If such a probe is configured, it disables liveness and readiness checks until it succeeds.
This type of probe is only executed at startup, unlike readiness probes, which are run periodically.
This type of probe is only executed at startup, unlike liveness and readiness probes, which are run periodically.
* Read more about the [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes).
* Read more about the [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes).

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

@ -276,7 +276,7 @@ If you are administering a cluster or namespace, you can also set
you may also want to define a [LimitRange](/docs/concepts/policy/limit-range/)
for additional enforcement.
If you specify a `spec.containers[].resources.limits.memory` for each Pod,
then the muximum size of an `emptyDir` volume will be the pod's memory limit.
then the maximum size of an `emptyDir` volume will be the pod's memory limit.
As an alternative, a cluster administrator can enforce size limits for
`emptyDir` volumes in new Pods using a policy mechanism such as

2
content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
View File

@ -16,7 +16,7 @@ The additional APIs can either be ready-made solutions such as a
[metrics server](https://github.com/kubernetes-sigs/metrics-server), or APIs that you develop yourself.
The aggregation layer is different from
[Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/),
[Custom Resource Definitions](/docs/concepts/extend-kubernetes/api-extension/custom-resources/),
which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}}
recognise new kinds of object.

2
content/en/docs/concepts/extend-kubernetes/compute-storage-net/_index.md
View File

@ -35,7 +35,7 @@ fabric that links Pods together.
* [Network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
A network plugin allow Kubernetes to work with different networking topologies and technologies.
Network plugins allow Kubernetes to work with different networking topologies and technologies.
Your Kubernetes cluster needs a _network plugin_ in order to have a working Pod network
and to support other aspects of the Kubernetes network model.

128
content/en/docs/concepts/overview/_index.md
View File

@ -22,75 +22,12 @@ This page is an overview of Kubernetes.
<!-- body -->
Kubernetes is a portable, extensible, open source platform for managing containerized
workloads and services, that facilitates both declarative configuration and automation.
It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation
results from counting the eight letters between the "K" and the "s". Google open-sourced the
Kubernetes project in 2014. Kubernetes combines
[over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running
production workloads at scale with best-of-breed ideas and practices from the community.
## Going back in time
Let's take a look at why Kubernetes is so useful by going back in time.
![Deployment evolution](/images/docs/Container_Evolution.svg)
**Traditional deployment era:**
Early on, organizations ran applications on physical servers. There was no way to define
resource boundaries for applications in a physical server, and this caused resource
allocation issues. For example, if multiple applications run on a physical server, there
can be instances where one application would take up most of the resources, and as a result,
the other applications would underperform. A solution for this would be to run each application
on a different physical server. But this did not scale as resources were underutilized, and it
was expensive for organizations to maintain many physical servers.
**Virtualized deployment era:** As a solution, virtualization was introduced. It allows you
to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization
allows applications to be isolated between VMs and provides a level of security as the
information of one application cannot be freely accessed by another application.
Virtualization allows better utilization of resources in a physical server and allows
better scalability because an application can be added or updated easily, reduces
hardware costs, and much more. With virtualization you can present a set of physical
resources as a cluster of disposable virtual machines.
Each VM is a full machine running all the components, including its own operating
system, on top of the virtualized hardware.
**Container deployment era:** Containers are similar to VMs, but they have relaxed
isolation properties to share the Operating System (OS) among the applications.
Therefore, containers are considered lightweight. Similar to a VM, a container
has its own filesystem, share of CPU, memory, process space, and more. As they
are decoupled from the underlying infrastructure, they are portable across clouds
and OS distributions.
Containers have become popular because they provide extra benefits, such as:
* Agile application creation and deployment: increased ease and efficiency of
container image creation compared to VM image use.
* Continuous development, integration, and deployment: provides for reliable
and frequent container image build and deployment with quick and efficient
rollbacks (due to image immutability).
* Dev and Ops separation of concerns: create application container images at
build/release time rather than deployment time, thereby decoupling
applications from infrastructure.
* Observability: not only surfaces OS-level information and metrics, but also
application health and other signals.
* Environmental consistency across development, testing, and production: runs
the same on a laptop as it does in the cloud.
* Cloud and OS distribution portability: runs on Ubuntu, RHEL, CoreOS, on-premises,
on major public clouds, and anywhere else.
* Application-centric management: raises the level of abstraction from running an
OS on virtual hardware to running an application on an OS using logical resources.
* Loosely coupled, distributed, elastic, liberated micro-services: applications are
broken into smaller, independent pieces and can be deployed and managed dynamically –
not a monolithic stack running on one big single-purpose machine.
* Resource isolation: predictable application performance.
* Resource utilization: high efficiency and density.
## Why you need Kubernetes and what it can do {#why-you-need-kubernetes-and-what-can-it-do}
Containers are a good way to bundle and run your applications. In a production
@ -174,6 +111,71 @@ Kubernetes:
It shouldn't matter how you get from A to C. Centralized control is also not required. This
results in a system that is easier to use and more powerful, robust, resilient, and extensible.
## Historical context for Kubernetes {#going-back-in-time}
Let's take a look at why Kubernetes is so useful by going back in time.
![Deployment evolution](/images/docs/Container_Evolution.svg)
**Traditional deployment era:**
Early on, organizations ran applications on physical servers. There was no way to define
resource boundaries for applications in a physical server, and this caused resource
allocation issues. For example, if multiple applications run on a physical server, there
can be instances where one application would take up most of the resources, and as a result,
the other applications would underperform. A solution for this would be to run each application
on a different physical server. But this did not scale as resources were underutilized, and it
was expensive for organizations to maintain many physical servers.
**Virtualized deployment era:**
As a solution, virtualization was introduced. It allows you
to run multiple Virtual Machines (VMs) on a single physical server's CPU. Virtualization
allows applications to be isolated between VMs and provides a level of security as the
information of one application cannot be freely accessed by another application.
Virtualization allows better utilization of resources in a physical server and allows
better scalability because an application can be added or updated easily, reduces
hardware costs, and much more. With virtualization you can present a set of physical
resources as a cluster of disposable virtual machines.
Each VM is a full machine running all the components, including its own operating
system, on top of the virtualized hardware.
**Container deployment era:**
Containers are similar to VMs, but they have relaxed
isolation properties to share the Operating System (OS) among the applications.
Therefore, containers are considered lightweight. Similar to a VM, a container
has its own filesystem, share of CPU, memory, process space, and more. As they
are decoupled from the underlying infrastructure, they are portable across clouds
and OS distributions.
Containers have become popular because they provide extra benefits, such as:
* Agile application creation and deployment: increased ease and efficiency of
container image creation compared to VM image use.
* Continuous development, integration, and deployment: provides for reliable
and frequent container image build and deployment with quick and efficient
rollbacks (due to image immutability).
* Dev and Ops separation of concerns: create application container images at
build/release time rather than deployment time, thereby decoupling
applications from infrastructure.
* Observability: not only surfaces OS-level information and metrics, but also
application health and other signals.
* Environmental consistency across development, testing, and production: runs
the same on a laptop as it does in the cloud.
* Cloud and OS distribution portability: runs on Ubuntu, RHEL, CoreOS, on-premises,
on major public clouds, and anywhere else.
* Application-centric management: raises the level of abstraction from running an
OS on virtual hardware to running an application on an OS using logical resources.
* Loosely coupled, distributed, elastic, liberated micro-services: applications are
broken into smaller, independent pieces and can be deployed and managed dynamically –
not a monolithic stack running on one big single-purpose machine.
* Resource isolation: predictable application performance.
* Resource utilization: high efficiency and density.
## {{% heading "whatsnext" %}}
* Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)

156
content/en/docs/concepts/overview/components.md
View File

@ -4,150 +4,86 @@ reviewers:
title: Kubernetes Components
content_type: concept
description: >
A Kubernetes cluster consists of the components that are a part of the control
plane and a set of machines called nodes.
weight: 30
card:
An overview of the key components that make up a Kubernetes cluster.
weight: 10
card:
title: Components of a cluster
name: concepts
weight: 20
---
<!-- overview -->
When you deploy Kubernetes, you get a cluster.
{{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}}
This document outlines the various components you need to have for
a complete and working Kubernetes cluster.
This page provides a high-level overview of the essential components that make up a Kubernetes cluster.
{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Components of Kubernetes" caption="The components of a Kubernetes cluster" class="diagram-large" clicktozoom="true" >}}
<!-- body -->
## Control Plane Components
The control plane's components make global decisions about the cluster (for example, scheduling),
as well as detecting and responding to cluster events (for example, starting up a new
{{< glossary_tooltip text="pod" term_id="pod">}} when a Deployment's
`{{< glossary_tooltip text="replicas" term_id="replica" >}}` field is unsatisfied).
## Core Components
Control plane components can be run on any machine in the cluster. However,
for simplicity, setup scripts typically start all control plane components on
the same machine, and do not run user containers on this machine. See
[Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
for an example control plane setup that runs across multiple machines.
A Kubernetes cluster consists of a control plane and one or more worker nodes.
Here's a brief overview of the main components:
### kube-apiserver
### Control Plane Components
{{< glossary_definition term_id="kube-apiserver" length="all" >}}
Manage the overall state of the cluster:
### etcd
[kube-apiserver](/docs/concepts/architecture/#kube-apiserver)
: The core component server that exposes the Kubernetes HTTP API
{{< glossary_definition term_id="etcd" length="all" >}}
[etcd](/docs/concepts/architecture/#etcd)
: Consistent and highly-available key value store for all API server data
### kube-scheduler
[kube-scheduler](/docs/concepts/architecture/#kube-scheduler)
: Looks for Pods not yet bound to a node, and assigns each Pod to a suitable node.
{{< glossary_definition term_id="kube-scheduler" length="all" >}}
[kube-controller-manager](/docs/concepts/architecture/#kube-controller-manager)
: Runs {{< glossary_tooltip text="controllers" term_id="controller" >}} to implement Kubernetes API behavior.
### kube-controller-manager
[cloud-controller-manager](/docs/concepts/architecture/#cloud-controller-manager) (optional)
: Integrates with underlying cloud provider(s).
{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
### Node Components
There are many different types of controllers. Some examples of them are:
Run on every node, maintaining running pods and providing the Kubernetes runtime environment:
* Node controller: Responsible for noticing and responding when nodes go down.
* Job controller: Watches for Job objects that represent one-off tasks, then creates
Pods to run those tasks to completion.
* EndpointSlice controller: Populates EndpointSlice objects (to provide a link between Services and Pods).
* ServiceAccount controller: Create default ServiceAccounts for new namespaces.
[kubelet](/docs/concepts/architecture/#kubelet)
: Ensures that Pods are running, including their containers.
The above is not an exhaustive list.
[kube-proxy](/docs/concepts/architecture/#kube-proxy) (optional)
: Maintains network rules on nodes to implement {{< glossary_tooltip text="Services" term_id="service" >}}.
### cloud-controller-manager
[Container runtime](/docs/concepts/architecture/#container-runtime)
: Software responsible for running containers. Read
[Container Runtimes](/docs/setup/production-environment/container-runtimes/) to learn more.
{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
{{% thirdparty-content single="true" %}}
The cloud-controller-manager only runs controllers that are specific to your cloud provider.
If you are running Kubernetes on your own premises, or in a learning environment inside your
own PC, the cluster does not have a cloud controller manager.
As with the kube-controller-manager, the cloud-controller-manager combines several logically
independent control loops into a single binary that you run as a single process. You can
scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
The following controllers can have cloud provider dependencies:
* Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
* Route controller: For setting up routes in the underlying cloud infrastructure
* Service controller: For creating, updating and deleting cloud provider load balancers
## Node Components
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
### kubelet
{{< glossary_definition term_id="kubelet" length="all" >}}
### kube-proxy
{{< glossary_definition term_id="kube-proxy" length="all" >}}
### Container runtime
{{< glossary_definition term_id="container-runtime" length="all" >}}
Your cluster may require additional software on each node; for example, you might also
run [systemd](https://systemd.io/) on a Linux node to supervise local components.
## Addons
Addons use Kubernetes resources ({{< glossary_tooltip term_id="daemonset" >}},
{{< glossary_tooltip term_id="deployment" >}}, etc)
to implement cluster features. Because these are providing cluster-level features, namespaced resources
for addons belong within the `kube-system` namespace.
Addons extend the functionality of Kubernetes. A few important examples include:
Selected addons are described below; for an extended list of available addons, please
see [Addons](/docs/concepts/cluster-administration/addons/).
[DNS](/docs/concepts/architecture/#dns)
: For cluster-wide DNS resolution
### DNS
[Web UI](/docs/concepts/architecture/#web-ui-dashboard) (Dashboard)
: For cluster management via a web interface
While the other addons are not strictly required, all Kubernetes clusters should have
[cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it.
[Container Resource Monitoring](/docs/concepts/architecture/#container-resource-monitoring)
: For collecting and storing container metrics
Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment,
which serves DNS records for Kubernetes services.
[Cluster-level Logging](/docs/concepts/architecture/#cluster-level-logging)
: For saving container logs to a central log store
Containers started by Kubernetes automatically include this DNS server in their DNS searches.
## Flexibility in Architecture
### Web UI (Dashboard)
Kubernetes allows for flexibility in how these components are deployed and managed.
The architecture can be adapted to various needs, from small development environments
to large-scale production deployments.
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose,
web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications
running in the cluster, as well as the cluster itself.
### Container Resource Monitoring
[Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
records generic time-series metrics
about containers in a central database, and provides a UI for browsing that data.
### Cluster-level Logging
A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for
saving container logs to a central log store with search/browsing interface.
### Network Plugins
[Network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins) are software
components that implement the container network interface (CNI) specification. They are responsible for
allocating IP addresses to pods and enabling them to communicate with each other within the cluster.
## {{% heading "whatsnext" %}}
Learn more about the following:
* [Nodes](/docs/concepts/architecture/nodes/) and [their communication](/docs/concepts/architecture/control-plane-node-communication/)
with the control plane.
* Kubernetes [controllers](/docs/concepts/architecture/controller/).
* [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) which is the default scheduler for Kubernetes.
* Etcd's official [documentation](https://etcd.io/docs/).
* Several [container runtimes](/docs/setup/production-environment/container-runtimes/) in Kubernetes.
* Integrating with cloud providers using [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/).
* [kubectl](/docs/reference/generated/kubectl/kubectl-commands) commands.
For more detailed information about each component and various ways to configure your
cluster architecture, see the [Cluster Architecture](/docs/concepts/architecture/) page.

4
content/en/docs/concepts/overview/kubernetes-api.md
View File

@ -65,8 +65,8 @@ the Discovery API. This includes the following for each resource:
- Alternative names
- Group, version, kind
The API is available both aggregated and unaggregated form. The aggregated
discovery serves two endpoints while the unaggregated discovery serves a
The API is available in both aggregated and unaggregated form. The aggregated
discovery serves two endpoints, while the unaggregated discovery serves a
separate endpoint for each group version.
### Aggregated discovery

2
content/en/docs/concepts/overview/working-with-objects/_index.md
View File

@ -1,7 +1,7 @@
---
title: Objects In Kubernetes
content_type: concept
weight: 10
weight: 30
description: >
Kubernetes objects are persistent entities in the Kubernetes system.
Kubernetes uses these entities to represent the state of your cluster.

7
content/en/docs/concepts/overview/working-with-objects/labels.md
View File

@ -201,8 +201,11 @@ For example: `partition in (customerA, customerB),environment!=qa`.
### LIST and WATCH filtering
LIST and WATCH operations may specify label selectors to filter the sets of objects
returned using a query parameter. Both requirements are permitted
For **list** and **watch** operations, you can specify label selectors to filter the sets of objects
returned; you specify the filter using a query parameter.
(To learn in detail about watches in Kubernetes, read
[efficient detection of changes](/docs/reference/using-api/api-concepts/#efficient-detection-of-changes)).
Both requirements are permitted
(presented here as they would appear in a URL query string):
* _equality-based_ requirements: `?labelSelector=environment%3Dproduction,tier%3Dfrontend`

2
content/en/docs/concepts/overview/working-with-objects/namespaces.md
View File

@ -61,7 +61,7 @@ Creation and deletion of namespaces are described in the
[Admin Guide documentation for namespaces](/docs/tasks/administer-cluster/namespaces).
{{< note >}}
Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces.
Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces.
{{< /note >}}
### Viewing namespaces

33
content/en/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md
View File

@ -34,18 +34,17 @@ handles allocation in cooperation with the Kubernetes scheduler.
## {{% heading "prerequisites" %}}
Kubernetes v{{< skew currentVersion >}} includes cluster-level API support for
dynamic resource allocation, but it [needs to be
enabled](#enabling-dynamic-resource-allocation) explicitly. You also must
install a resource driver for specific resources that are meant to be managed
using this API. If you are not running Kubernetes v{{< skew currentVersion>}},
check the documentation for that version of Kubernetes.
dynamic resource allocation, but it [needs to be enabled](#enabling-dynamic-resource-allocation)
explicitly. You also must install a resource driver for specific resources that
are meant to be managed using this API. If you are not running Kubernetes
v{{< skew currentVersion>}}, check the documentation for that version of Kubernetes.
<!-- body -->
## API
The `resource.k8s.io/v1alpha3` {{< glossary_tooltip text="API group"
term_id="api-group" >}} provides these types:
The `resource.k8s.io/v1alpha3`
{{< glossary_tooltip text="API group" term_id="api-group" >}} provides these types:
ResourceClaim
: Describes a request for access to resources in the cluster,
@ -268,12 +267,10 @@ the `.spec.nodeName` field and to use a node selector instead.
## Enabling dynamic resource allocation
Dynamic resource allocation is an *alpha feature* and only enabled when the
`DynamicResourceAllocation` [feature
gate](/docs/reference/command-line-tools-reference/feature-gates/) and the
`resource.k8s.io/v1alpha3` {{< glossary_tooltip text="API group"
term_id="api-group" >}} are enabled. For details on that, see the
`--feature-gates` and `--runtime-config` [kube-apiserver
parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
`DynamicResourceAllocation` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
and the `resource.k8s.io/v1alpha3` {{< glossary_tooltip text="API group" term_id="api-group" >}}
are enabled. For details on that, see the `--feature-gates` and `--runtime-config`
[kube-apiserver parameters](/docs/reference/command-line-tools-reference/kube-apiserver/).
kube-scheduler, kube-controller-manager and kubelet also need the feature gate.
When a resource driver uses a control plane controller, then the
@ -281,7 +278,7 @@ When a resource driver uses a control plane controller, then the
`DynamicResourceAllocation`.
A quick check whether a Kubernetes cluster supports the feature is to list
ResourceClass objects with:
DeviceClass objects with:
```shell
kubectl get deviceclasses
@ -315,7 +312,7 @@ be installed. Please refer to the driver's documentation for details.
## {{% heading "whatsnext" %}}
- For more information on the design, see the
[Structured Parameters with Structured Parameters](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/4381-dra-structured-parameters)
and the
[Dynamic Resource Allocation with Control Plane Controller](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md) KEPs.
- For more information on the design, see the
[Dynamic Resource Allocation with Structured Parameters](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/4381-dra-structured-parameters)
and the
[Dynamic Resource Allocation with Control Plane Controller](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md) KEPs.

3
content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
View File

@ -85,8 +85,7 @@ A toleration "matches" a taint if the keys are the same and the effects are the
There are two special cases:
An empty `key` with operator `Exists` matches all keys, values and effects which means this
will tolerate everything.
If the `key` is empty, then the `operator` must be `Exists`, which matches all keys and values. Note that the `effect` still needs to be matched at the same time.
An empty `effect` matches all effects with key `key1`.

4
content/en/docs/concepts/security/cloud-native-security.md
View File

@ -24,7 +24,7 @@ There are localized versions available of this whitepaper; if you can link to on
when localizing, that's even better.
{{< /comment >}}
The CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper)
The CNCF [white paper](https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
on cloud native security defines security controls and practices that are
appropriate to different _lifecycle phases_.
@ -204,7 +204,7 @@ logs are both tamper-proof and confidential.
### Cloud native security {#further-reading-cloud-native}
* CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper)
* CNCF [white paper](https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
on cloud native security.
* CNCF [white paper](https://github.com/cncf/tag-security/blob/f80844baaea22a358f5b20dca52cd6f72a32b066/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)
on good practices for securing a software supply chain.

0
content/en/docs/concepts/security/multi-tenancy.md Executable file → Normal file
View File

133
content/en/docs/concepts/services-networking/_index.md
View File

@ -7,58 +7,103 @@ description: >
## The Kubernetes network model
Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address
(one address per IP address family).
This means you do not need to explicitly create links between `Pods` and you
almost never need to deal with mapping container ports to host ports.
This creates a clean, backwards-compatible model where `Pods` can be treated
much like VMs or physical hosts from the perspectives of port allocation,
naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing),
application configuration, and migration.
The Kubernetes network model is built out of several pieces:
Kubernetes imposes the following fundamental requirements on any networking
implementation (barring any intentional network segmentation policies):
* Each [Pod](/docs/concepts/workloads/pods/) in a cluster gets its
own unique cluster-wide IP address.
* pods can communicate with all other pods on any other [node](/docs/concepts/architecture/nodes/)
without NAT
* agents on a node (e.g. system daemons, kubelet) can communicate with all
pods on that node
* A pod has its own private network namespace which is shared by
all of the containers within the pod. Processes running in
different containers in the same pod can communicate with each
other over `localhost`.
{{< note >}}
For those platforms that support `Pods` running in the host network (such as Linux), when pods are attached to the host network of a node they can still communicate with all pods on all nodes without NAT.
{{< /note >}}
* The _pod network_ (also called a cluster network) handles communication
between pods. It ensures that (barring intentional network
segmentation):
This model is not only less complex overall, but it is principally compatible
with the desire for Kubernetes to enable low-friction porting of apps from VMs
to containers. If your job previously ran in a VM, your VM had an IP and could
talk to other VMs in your project. This is the same basic model.
* All pods can communicate with all other pods, whether they are
on the same [node](/docs/concepts/architecture/nodes/) or on
different nodes. Pods can communicate with each other
directly, without the use of proxies or address translation
(NAT).
Kubernetes IP addresses exist at the `Pod` scope - containers within a `Pod`
share their network namespaces - including their IP address and MAC address.
This means that containers within a `Pod` can all reach each other's ports on
`localhost`. This also means that containers within a `Pod` must coordinate port
usage, but this is no different from processes in a VM. This is called the
"IP-per-pod" model.
* (On Windows, this rule does not apply to host-network pods.)
How this is implemented is a detail of the particular container runtime in use.
* Agents on a node (such as system daemons, or kubelet) can
communicate with all pods on that node.
It is possible to request ports on the `Node` itself which forward to your `Pod`
(called host ports), but this is a very niche operation. How that forwarding is
implemented is also a detail of the container runtime. The `Pod` itself is
blind to the existence or non-existence of host ports.
* The [Service](/docs/concepts/services-networking/service/) API
lets you provide a stable (long lived) IP address or hostname for a service implemented
by one or more backend pods, where the individual pods making up
the service can change over time.
Kubernetes networking addresses four concerns:
- Containers within a Pod [use networking to communicate](/docs/concepts/services-networking/dns-pod-service/) via loopback.
- Cluster networking provides communication between different Pods.
- The [Service](/docs/concepts/services-networking/service/) API lets you
[expose an application running in Pods](/docs/tutorials/services/connect-applications-service/)
to be reachable from outside your cluster.
- [Ingress](/docs/concepts/services-networking/ingress/) provides extra functionality
specifically for exposing HTTP applications, websites and APIs.
- [Gateway API](/docs/concepts/services-networking/gateway/) is an {{<glossary_tooltip text="add-on" term_id="addons">}}
that provides an expressive, extensible, and role-oriented family of API kinds for modeling service networking.
- You can also use Services to
[publish services only for consumption inside your cluster](/docs/concepts/services-networking/service-traffic-policy/).
* Kubernetes automatically manages
[EndpointSlice](/docs/concepts/services-networking/endpoint-slices/)
objects to provide information about the pods currently
backing a Service.
* A service proxy implementation monitors the `Service` and
`EndpointSlice` objects, and programs the data plane to route
service traffic to its backends, by using operating system or
cloud provider APIs to intercept or rewrite packets.
* The [Gateway](/docs/concepts/services-networking/gateway/) API
(or its predecessor,
[Ingress](/docs/concepts/services-networking/ingress/)) allows
you to make Services accessible to clients that are outside the cluster.
* A simpler, but less-configurable, mechanism for cluster
ingress is available via the Service API's [`type:
LoadBalancer`](/docs/concepts/services-networking/service/#loadbalancer),
when using a supported {{< glossary_tooltip term_id="cloud-provider">}}.
* [NetworkPolicy](/docs/concepts/services-networking/network-policies) is a built-in
Kubernetes API that
allows you to control traffic between pods, or between pods and
the outside world.
In older container systems, there was no automatic connectivity
between containers on different hosts, and so it was often necessary
to explicitly create links between containers, or to map container
ports to host ports to make them reachable by containers on other
hosts. This is not needed in Kubernetes; Kubernetes's model is that
pods can be treated much like VMs or physical hosts from the
perspectives of port allocation, naming, service discovery, load
balancing, application configuration, and migration.
Only a few parts of this model are implemented by Kubernetes itself.
For the other parts, Kubernetes defines the APIs, but the
corresponding functionality is provided by external components, some
of which are optional:
* Pod network namespace setup is handled by system-level software
implementing the [Container Runtime
Interface](/docs/concepts/architecture/cri.md).
* The pod network itself is managed by a [pod network
implementation](/docs/concepts/cluster-administration/addons/#networking-and-network-policy).
On Linux, most container runtimes use the
{{< glossary_tooltip text="Container Networking Interface (CNI)" term_id="cni" >}}
to interact with the pod network implementation, so these
implementations are often called _CNI plugins_.
* Kubernetes provides a default implementation of service proxying,
called {{< glossary_tooltip term_id="kube-proxy">}}, but some pod
network implementations instead use their own service proxy that
is more tightly integrated with the rest of the implementation.
* NetworkPolicy is generally also implemented by the pod network
implementation. (Some simpler pod network implementations don't
implement NetworkPolicy, or an administrator may choose to
configure the pod network without NetworkPolicy support. In these
cases, the API will still be present, but it will have no effect.)
* There are many [implementations of the Gateway
API](https://gateway-api.sigs.k8s.io/implementations/), some of
which are specific to particular cloud environments, some more
focused on "bare metal" environments, and others more generic.
## {{% heading "whatsnext" %}}
The [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) tutorial lets you learn about Services and Kubernetes networking with a hands-on example.

3
content/en/docs/concepts/services-networking/dns-pod-service.md
View File

@ -191,8 +191,7 @@ An {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}} can spec
the DNS hostname for any endpoint addresses, along with its IP.
{{< note >}}
Because A and AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA
record to be created. A Pod with no `hostname` but with `subdomain` will only create the
A and AAAA records are not created for Pod names since `hostname` is missing for the Pod. A Pod with no `hostname` but with `subdomain` will only create the
A or AAAA record for the headless Service (`busybox-subdomain.my-namespace.svc.cluster-domain.example`),
pointing to the Pods' IP addresses. Also, the Pod needs to be ready in order to have a
record unless `publishNotReadyAddresses=True` is set on the Service.

5
content/en/docs/concepts/services-networking/ingress.md
View File

@ -87,7 +87,10 @@ A minimal Ingress resource example:
An Ingress needs `apiVersion`, `kind`, `metadata` and `spec` fields.
The name of an Ingress object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
For general information about working with config files, see
[deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/),
[configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/),
[managing resources](/docs/concepts/workloads/management/).
Ingress frequently uses annotations to configure some options depending on the Ingress controller, an example of which
is the [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/main/docs/examples/rewrite/README.md).
Different [Ingress controllers](/docs/concepts/services-networking/ingress-controllers) support different annotations.

3
content/en/docs/concepts/storage/ephemeral-volumes.md
View File

@ -46,12 +46,15 @@ different purposes:
[downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
[secret](/docs/concepts/storage/volumes/#secret): inject different
kinds of Kubernetes data into a Pod
- [image](/docs/concepts/storage/volumes/#image): allows mounting container image files or artifacts,
directly to a Pod.
- [CSI ephemeral volumes](#csi-ephemeral-volumes):
similar to the previous volume kinds, but provided by special {{< glossary_tooltip text="CSI" term_id="csi" >}} drivers
which specifically [support this feature](https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html)
- [generic ephemeral volumes](#generic-ephemeral-volumes), which
can be provided by all storage drivers that also support persistent volumes
`emptyDir`, `configMap`, `downwardAPI`, `secret` are provided as
[local ephemeral
storage](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage).

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

@ -296,6 +296,27 @@ allowedTopologies:
values:
- us-east-2c
```
### 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).
```yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: efs-sc
provisioner: efs.csi.aws.com
parameters:
provisioningMode: efs-ap
fileSystemId: fs-92107410
directoryPerms: "700"
```
- `provisioningMode`: The type of volume to be provisioned by Amazon EFS. Currently, only access point based provisioning is supported (`efs-ap`).
- `fileSystemId`: The file system under which the access point is created.
- `directoryPerms`: The directory permissions of the root directory created by the access point.
For more details, refer to the [AWS_EFS_CSI_Driver Dynamic Provisioning](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) documentation.
### NFS

37
content/en/docs/concepts/storage/volume-attributes-classes.md
View File

@ -23,13 +23,16 @@ Kubernetes itself is un-opinionated about what these classes represent.
This is a beta feature and disabled by default.
If you want to test the feature whilst it's beta, you need to enable the `VolumeAttributesClass`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kube-controller-manager and the kube-apiserver. You use the `--feature-gates` command line argument:
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kube-controller-manager, kube-scheduler,
and the kube-apiserver. You use the `--feature-gates` command line argument:
```
--feature-gates="...,VolumeAttributesClass=true"
```
You will also have to enable the `storage.k8s.io/v1beta1` API group through the `kube-apiserver` [runtime-config](https://kubernetes.io/docs/tasks/administer-cluster/enable-disable-api/). You use the following command line argument:
You will also have to enable the `storage.k8s.io/v1beta1` API group through the
`kube-apiserver` [runtime-config](https://kubernetes.io/docs/tasks/administer-cluster/enable-disable-api/).
You use the following command line argument:
```
--runtime-config=storage.k8s.io/v1beta1=true
@ -49,7 +52,6 @@ The name of a VolumeAttributesClass object is significant and is how users can r
Administrators set the name and other parameters of a class when first creating VolumeAttributesClass objects.
While the name of a VolumeAttributesClass object in a `PersistentVolumeClaim` is mutable, the parameters in an existing class are immutable.
```yaml
apiVersion: storage.k8s.io/v1beta1
kind: VolumeAttributesClass
@ -61,24 +63,27 @@ parameters:
provisioned-throughput: "50"
```
### Provisioner
Each VolumeAttributesClass has a provisioner that determines what volume plugin is used for provisioning PVs. The field `driverName` must be specified.
Each VolumeAttributesClass has a provisioner that determines what volume plugin is used for
provisioning PVs. The field `driverName` must be specified.
The feature support for VolumeAttributesClass is implemented in [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner).
The feature support for VolumeAttributesClass is implemented in
[kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner).
You are not restricted to specifying the [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner). You can also run and specify external provisioners,
You are not restricted to specifying the [kubernetes-csi/external-provisioner](https://github.com/kubernetes-csi/external-provisioner).
You can also run and specify external provisioners,
which are independent programs that follow a specification defined by Kubernetes.
Authors of external provisioners have full discretion over where their code lives, how
the provisioner is shipped, how it needs to be run, what volume plugin it uses, etc.
the provisioner is shipped, how it needs to be run, what volume plugin it uses, etc.
### Resizer
Each VolumeAttributesClass has a resizer that determines what volume plugin is used for modifying PVs. The field `driverName` must be specified.
Each VolumeAttributesClass has a resizer that determines what volume plugin is used
for modifying PVs. The field `driverName` must be specified.
The modifying volume feature support for VolumeAttributesClass is implemented in [kubernetes-csi/external-resizer](https://github.com/kubernetes-csi/external-resizer).
The modifying volume feature support for VolumeAttributesClass is implemented in
[kubernetes-csi/external-resizer](https://github.com/kubernetes-csi/external-resizer).
For example, an existing PersistentVolumeClaim is using a VolumeAttributesClass named silver:
@ -95,7 +100,6 @@ spec:
A new VolumeAttributesClass gold is available in the cluster:
```yaml
apiVersion: storage.k8s.io/v1beta1
kind: VolumeAttributesClass
@ -107,10 +111,8 @@ parameters:
throughput: "60"
```
The end user can update the PVC with the new VolumeAttributesClass gold and apply:
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
@ -122,15 +124,14 @@ spec:
…
```
## Parameters
VolumeAttributeClasses have parameters that describe volumes belonging to them. Different parameters may be accepted
depending on the provisioner or the resizer. For example, the value `4000`, for the parameter `iops`,
and the parameter `throughput` are specific to GCE PD.
and the parameter `throughput` are specific to GCE PD.
When a parameter is omitted, the default is used at volume provisioning.
If a user apply the PVC with a different VolumeAttributesClass with omitted parameters, the default value of
the parameters may be used depends on the CSI driver implementation.
If a user applies the PVC with a different VolumeAttributesClass with omitted parameters, the default value of
the parameters may be used depending on the CSI driver implementation.
Please refer to the related CSI driver documentation for more details.
There can be at most 512 parameters defined for a VolumeAttributesClass.

9
content/en/docs/concepts/storage/volumes.md
View File

@ -865,7 +865,7 @@ are redirected to the `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" t
[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)
must be installed on the cluster. You can find additional advice on how to migrate in-tree `vsphereVolume` in VMware's documentation page
[Migrating In-Tree vSphere Volumes to vSphere Container Storage lug-in](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html).
[Migrating In-Tree vSphere Volumes to vSphere Container Storage Plug-in](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html).
If vSphere CSI Driver is not installed volume operations can not be performed on the PV created with the in-tree `vsphereVolume` type.
You must run vSphere 7.0u2 or later in order to migrate to the vSphere CSI driver.
@ -1197,6 +1197,13 @@ Users of FlexVolume should move their workloads to use the equivalent CSI Driver
## Mount propagation
{{< caution >}}
Mount propagation is a low-level feature that does not work consistently on all
volume types. It is recommended to use only with `hostPath` or in-memory `emptyDir`
volumes. See [this discussion](https://github.com/kubernetes/kubernetes/issues/95049)
for more context.
{{< /caution >}}
Mount propagation allows for sharing volumes mounted by a container to
other containers in the same pod, or even to other pods on the same node.

4
content/en/docs/concepts/windows/intro.md
View File

@ -368,7 +368,7 @@ Depending on the requirements for your workload these values may need to be adju
Refer to
[Hardware requirements for Windows Server Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/get-started/hardware-requirements)
for the most up-to-date information on minimum hardware requirements. For guidance on deciding on resources for
production worker nodes refer to [Production worker nodes Kubernetes documentation](https://kubernetes.io/docs/setup/production-environment/#production-worker-nodes).
production worker nodes refer to [Production worker nodes Kubernetes documentation](/docs/setup/production-environment/#production-worker-nodes).
To optimize system resources, if a graphical user interface is not required,
it may be preferable to use a Windows Server OS installation that excludes
@ -432,4 +432,4 @@ For a detailed explanation of Windows distribution channels see the
Information on the different Windows Server servicing channels
including their support models can be found at
[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison).
[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison).

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

@ -65,7 +65,7 @@ The `.spec.schedule` field is required. The value of that field follows the [Cro
# * * * * *
```
For example, `0 0 13 * 5` states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight.
For example, `0 3 * * 1` means this task is scheduled to run weekly on a Monday at 3 AM.
The format also includes extended "Vixie cron" step values. As explained in the
[FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):

6
content/en/docs/concepts/workloads/controllers/deployment.md
View File

@ -813,9 +813,9 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
```
deployment.apps/nginx-deployment resumed
```
* Watch the status of the rollout until it's done.
* {{< glossary_tooltip text="Watch" term_id="watch" >}} the status of the rollout until it's done.
```shell
kubectl get rs -w
kubectl get rs --watch
```
The output is similar to this:
@ -1083,7 +1083,7 @@ thus that Deployment will not be able to roll back.
If you want to roll out releases to a subset of users or servers using the Deployment, you
can create multiple Deployments, one for each release, following the canary pattern described in
[managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
[managing resources](/docs/concepts/workloads/management/#canary-deployments).
## Writing a Deployment Spec

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

@ -1078,7 +1078,7 @@ and `.spec.completions` together such that `.spec.parallelism == .spec.completio
When scaling down, Kubernetes removes the Pods with higher indexes.
Use cases for elastic Indexed Jobs include batch workloads which require
scaling an indexed Job, such as MPI, Horovord, Ray, and PyTorch training jobs.
scaling an indexed Job, such as MPI, Horovod, Ray, and PyTorch training jobs.
### Delayed creation of replacement pods {#pod-replacement-policy}

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

@ -316,7 +316,7 @@ Pods, the kubelet directly supervises each static Pod (and restarts it if it fai
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
The main use for static Pods is to run a self-hosted control plane: in other words,
using the kubelet to supervise the individual [control plane components](/docs/concepts/overview/components/#control-plane-components).
using the kubelet to supervise the individual [control plane components](/docs/concepts/architecture/#control-plane-components).
The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}}
on the Kubernetes API server for each static Pod.

16
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -111,8 +111,20 @@ Value | Description
`Unknown` | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.
{{< note >}}
When a Pod is being deleted, it is shown as `Terminating` by some kubectl commands.
This `Terminating` status is not one of the Pod phases.
When a pod is failing to start repeatedly, `CrashLoopBackOff` may appear in the `Status` field of some kubectl commands. Similarly, when a pod is being deleted, `Terminating` may appear in the `Status` field of some kubectl commands.
Make sure not to confuse _Status_, a kubectl display field for user intuition, with the pod's `phase`.
Pod phase is an explicit part of the Kubernetes data model and of the
[Pod API](/docs/reference/kubernetes-api/workload-resources/pod-v1/).
```
NAMESPACE NAME READY STATUS RESTARTS AGE
alessandras-namespace alessandras-pod 0/1 CrashLoopBackOff 200 2d9h
```
---
A Pod is granted a term to terminate gracefully, which defaults to 30 seconds.
You can use the flag `--force` to [terminate a Pod by force](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced).
{{< /note >}}

1
content/en/docs/concepts/workloads/pods/sidecar-containers.md
View File

@ -143,6 +143,7 @@ request and limit, the same as the scheduler.
## {{% heading "whatsnext" %}}
* Learn how to [Adopt Sidecar Containers](/docs/tutorials/configuration/pod-sidecar-containers/)
* Read a blog post on [native sidecar containers](/blog/2023/08/25/native-sidecar-containers/).
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container).
* Learn about the [types of probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe): liveness, readiness, startup probe.

6
content/en/docs/contribute/new-content/blogs-case-studies.md
View File

@ -157,6 +157,10 @@ To submit a blog post follow these directions:
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
author: >
Author-1 (Affiliation),
Author-2 (Affiliation),
Author-3 (Affiliation)
---
```
@ -195,7 +199,7 @@ To mirror a blog post from the [Kubernetes contributor blog](https://www.kuberne
- Keep the blog content the same. If there are changes, they should be made to the original article first, and then to the mirrored article.
- The mirrored blog should have a `canonicalUrl`, that is, essentially the url of the original blog after it has been published.
- [Kubernetes contributor blogs](https://kubernetes.dev/blog) have their authors mentioned in the YAML header, while the Kubernetes blog posts mention authors in the blog content itself. This should be changed when mirroring the content.
- Same as [Kubernetes contributor blogs](https://kubernetes.dev/blog), Kubernetes blog posts also mention authors in the YAML header as per the new guidelines. This should be ensured.
- Publication dates stay the same as the original blog.
All of the other guidelines and expectations detailed above apply as well.

2
content/en/docs/contribute/new-content/open-a-pr.md
View File

@ -213,7 +213,7 @@ Figure 2. Working from a local fork to make your changes.
### Create a branch
1. Decide which branch base to your work on:
1. Decide which branch to base your work on:
- For improvements to existing content, use `upstream/main`.
- For new content about existing features, use `upstream/main`.

4
content/en/docs/contribute/participate/pr-wranglers.md
View File

@ -130,10 +130,6 @@ The program was introduced to help new contributors understand the PR wrangling
[PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers)
to see the PR wrangling schedule for this year and sign up.
- Kubernetes org members can edit the
[PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers)
and sign up to shadow an existing PR Wrangler for a week.
- Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs)
for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to
Brad Topol (`@bradtopol`) or one of the

2
content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
View File

@ -116,7 +116,7 @@ authenticate to the API server as a bearer token.
The `expiration` field controls the expiry of the token. Expired tokens are
rejected when used for authentication and ignored during ConfigMap signing.
The expiry value is encoded as an absolute UTC time using RFC3339. Enable the
The expiry value is encoded as an absolute UTC time using [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339). Enable the
`tokencleaner` controller to automatically delete expired tokens.
## Token Management with kubeadm

3
content/en/docs/reference/command-line-tools-reference/feature-gates/remove-self-link.md → content/en/docs/reference/command-line-tools-reference/feature-gates/RemoveSelfLink.md
View File

@ -1,5 +1,4 @@
---
removed: true
title: RemoveSelfLink
content_type: feature_gate
_build:
@ -19,6 +18,8 @@ stages:
defaultValue: true
fromVersion: "1.24"
toVersion: "1.29"
removed: true
---
Sets the `.metadata.selfLink` field to blank (empty string) for all
objects and collections. This field has been deprecated since the Kubernetes v1.16

38
content/en/docs/reference/command-line-tools-reference/kube-apiserver.md
View File

File diff suppressed because one or more lines are too long

18
content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md
View File

File diff suppressed because one or more lines are too long

12
content/en/docs/reference/command-line-tools-reference/kube-proxy.md
View File

File diff suppressed because one or more lines are too long

18
content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
View File

File diff suppressed because one or more lines are too long

4
content/en/docs/reference/config-api/apiserver-admission.v1.md
View File

@ -152,7 +152,7 @@ requested. e.g. a patch can result in either a CREATE or UPDATE Operation.</p>
</td>
</tr>
<tr><td><code>userInfo</code> <B>[Required]</B><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
</td>
<td>
<p>UserInfo is information about the requesting user</p>
@ -226,7 +226,7 @@ This must be copied over from the corresponding AdmissionRequest.</p>
</td>
</tr>
<tr><td><code>status</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#status-v1-meta"><code>meta/v1.Status</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#status-v1-meta"><code>meta/v1.Status</code></a>
</td>
<td>
<p>Result contains extra details into why an admission request was denied.

16
content/en/docs/reference/config-api/apiserver-audit.v1.md
View File

@ -71,14 +71,14 @@ For non-resource requests, this is the lower-cased HTTP method.</p>
</td>
</tr>
<tr><td><code>user</code> <B>[Required]</B><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
</td>
<td>
<p>Authenticated user information.</p>
</td>
</tr>
<tr><td><code>impersonatedUser</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a>
</td>
<td>
<p>Impersonated user information.</p>
@ -116,7 +116,7 @@ Does not apply for List-type requests, or non-resource requests.</p>
</td>
</tr>
<tr><td><code>responseStatus</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#status-v1-meta"><code>meta/v1.Status</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#status-v1-meta"><code>meta/v1.Status</code></a>
</td>
<td>
<p>The response status, populated even when the ResponseObject is not a Status type.
@ -144,14 +144,14 @@ at Response Level.</p>
</td>
</tr>
<tr><td><code>requestReceivedTimestamp</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
</td>
<td>
<p>Time the request reached the apiserver.</p>
</td>
</tr>
<tr><td><code>stageTimestamp</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#microtime-v1-meta"><code>meta/v1.MicroTime</code></a>
</td>
<td>
<p>Time the request reached current audit stage.</p>
@ -188,7 +188,7 @@ should be short. Annotations are included in the Metadata level.</p>
<tr><td><code>metadata</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
</td>
<td>
<span class="text-muted">No description provided.</span></td>
@ -223,7 +223,7 @@ categories are logged.</p>
<tr><td><code>metadata</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
</td>
<td>
<p>ObjectMeta is included for interoperability with API infrastructure.</p>
@ -278,7 +278,7 @@ in a rule will override the global default.</p>
<tr><td><code>metadata</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#listmeta-v1-meta"><code>meta/v1.ListMeta</code></a>
</td>
<td>
<span class="text-muted">No description provided.</span></td>

77
content/en/docs/reference/config-api/apiserver-config.v1alpha1.md
View File

@ -119,10 +119,17 @@ JWT authenticator will attempt to cryptographically validate the token.</p>
&quot;iss&quot;: &quot;https://issuer.example.com&quot;,
&quot;aud&quot;: [&quot;audience&quot;],
&quot;exp&quot;: 1234567890,
&quot;&lt;username claim&gt;&quot;: &quot;username&quot;
&quot;<!-- raw HTML omitted -->&quot;: &quot;username&quot;
}</p>
</td>
</tr>
<tr><td><code>anonymous</code> <B>[Required]</B><br/>
<a href="#apiserver-k8s-io-v1alpha1-AnonymousAuthConfig"><code>AnonymousAuthConfig</code></a>
</td>
<td>
<p>If present --anonymous-auth must not be set</p>
</td>
</tr>
</tbody>
</table>
@ -245,6 +252,66 @@ configuration. If present, it will be used instead of the path to the configurat
</tbody>
</table>
## `AnonymousAuthCondition` {#apiserver-k8s-io-v1alpha1-AnonymousAuthCondition}
**Appears in:**
- [AnonymousAuthConfig](#apiserver-k8s-io-v1alpha1-AnonymousAuthConfig)
<p>AnonymousAuthCondition describes the condition under which anonymous auth
should be enabled.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>path</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>Path for which anonymous auth is enabled.</p>
</td>
</tr>
</tbody>
</table>
## `AnonymousAuthConfig` {#apiserver-k8s-io-v1alpha1-AnonymousAuthConfig}
**Appears in:**
- [AuthenticationConfiguration](#apiserver-k8s-io-v1alpha1-AuthenticationConfiguration)
<p>AnonymousAuthConfig provides the configuration for the anonymous authenticator.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>enabled</code> <B>[Required]</B><br/>
<code>bool</code>
</td>
<td>
<span class="text-muted">No description provided.</span></td>
</tr>
<tr><td><code>conditions</code> <B>[Required]</B><br/>
<a href="#apiserver-k8s-io-v1alpha1-AnonymousAuthCondition"><code>[]AnonymousAuthCondition</code></a>
</td>
<td>
<p>If set, anonymous auth is only allowed if the request meets one of the
conditions.</p>
</td>
</tr>
</tbody>
</table>
## `AudienceMatchPolicyType` {#apiserver-k8s-io-v1alpha1-AudienceMatchPolicyType}
(Alias of `string`)
@ -331,7 +398,7 @@ The claim's value must be a singular string.
Same as the --oidc-username-claim and --oidc-username-prefix flags.
If username.expression is set, the expression must produce a string value.
If username.expression uses 'claims.email', then 'claims.email_verified' must be used in
username.expression or extra[&ast;].valueExpression or claimValidationRules[&ast;].expression.
username.expression or extra[<em>].valueExpression or claimValidationRules[</em>].expression.
An example claim validation rule expression that matches the validation automatically
applied when username.claim is set to 'email' is 'claims.?email_verified.orValue(true)'.</p>
<p>In the flag based approach, the --oidc-username-claim and --oidc-username-prefix are optional. If --oidc-username-claim is not set,
@ -341,8 +408,8 @@ For prefix:
(1) --oidc-username-prefix=&quot;-&quot;, no prefix was added to the username. For the same behavior using authentication config,
set username.prefix=&quot;&quot;
(2) --oidc-username-prefix=&quot;&quot; and --oidc-username-claim != &quot;email&quot;, prefix was &quot;&lt;value of --oidc-issuer-url&gt;#&quot;. For the same
behavior using authentication config, set username.prefix=&quot;&lt;value of issuer.url&gt;#&quot;
(3) --oidc-username-prefix=&quot;&lt;value&gt;&quot;. For the same behavior using authentication config, set username.prefix=&quot;&lt;value&gt;&quot;</p>
behavior using authentication config, set username.prefix=&quot;<!-- raw HTML omitted -->#&quot;
(3) --oidc-username-prefix=&quot;<!-- raw HTML omitted -->&quot;. For the same behavior using authentication config, set username.prefix=&quot;<!-- raw HTML omitted -->&quot;</p>
</td>
</tr>
<tr><td><code>groups</code><br/>
@ -1202,4 +1269,4 @@ the contents would be converted to the v1 version before evaluating the CEL expr
</tr>
</tbody>
</table>

77
content/en/docs/reference/config-api/apiserver-config.v1beta1.md
View File

@ -95,10 +95,17 @@ JWT authenticator will attempt to cryptographically validate the token.</p>
&quot;iss&quot;: &quot;https://issuer.example.com&quot;,
&quot;aud&quot;: [&quot;audience&quot;],
&quot;exp&quot;: 1234567890,
&quot;&lt;username claim&gt;&quot;: &quot;username&quot;
&quot;<!-- raw HTML omitted -->&quot;: &quot;username&quot;
}</p>
</td>
</tr>
<tr><td><code>anonymous</code> <B>[Required]</B><br/>
<a href="#apiserver-k8s-io-v1beta1-AnonymousAuthConfig"><code>AnonymousAuthConfig</code></a>
</td>
<td>
<p>If present --anonymous-auth must not be set</p>
</td>
</tr>
</tbody>
</table>
@ -178,6 +185,66 @@ Must be at least one.</p>
</tbody>
</table>
## `AnonymousAuthCondition` {#apiserver-k8s-io-v1beta1-AnonymousAuthCondition}
**Appears in:**
- [AnonymousAuthConfig](#apiserver-k8s-io-v1beta1-AnonymousAuthConfig)
<p>AnonymousAuthCondition describes the condition under which anonymous auth
should be enabled.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>path</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<p>Path for which anonymous auth is enabled.</p>
</td>
</tr>
</tbody>
</table>
## `AnonymousAuthConfig` {#apiserver-k8s-io-v1beta1-AnonymousAuthConfig}
**Appears in:**
- [AuthenticationConfiguration](#apiserver-k8s-io-v1beta1-AuthenticationConfiguration)
<p>AnonymousAuthConfig provides the configuration for the anonymous authenticator.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>enabled</code> <B>[Required]</B><br/>
<code>bool</code>
</td>
<td>
<span class="text-muted">No description provided.</span></td>
</tr>
<tr><td><code>conditions</code> <B>[Required]</B><br/>
<a href="#apiserver-k8s-io-v1beta1-AnonymousAuthCondition"><code>[]AnonymousAuthCondition</code></a>
</td>
<td>
<p>If set, anonymous auth is only allowed if the request meets one of the
conditions.</p>
</td>
</tr>
</tbody>
</table>
## `AudienceMatchPolicyType` {#apiserver-k8s-io-v1beta1-AudienceMatchPolicyType}
(Alias of `string`)
@ -264,7 +331,7 @@ The claim's value must be a singular string.
Same as the --oidc-username-claim and --oidc-username-prefix flags.
If username.expression is set, the expression must produce a string value.
If username.expression uses 'claims.email', then 'claims.email_verified' must be used in
username.expression or extra[&ast;].valueExpression or claimValidationRules[&ast;].expression.
username.expression or extra[<em>].valueExpression or claimValidationRules[</em>].expression.
An example claim validation rule expression that matches the validation automatically
applied when username.claim is set to 'email' is 'claims.?email_verified.orValue(true)'.</p>
<p>In the flag based approach, the --oidc-username-claim and --oidc-username-prefix are optional. If --oidc-username-claim is not set,
@ -274,8 +341,8 @@ For prefix:
(1) --oidc-username-prefix=&quot;-&quot;, no prefix was added to the username. For the same behavior using authentication config,
set username.prefix=&quot;&quot;
(2) --oidc-username-prefix=&quot;&quot; and --oidc-username-claim != &quot;email&quot;, prefix was &quot;&lt;value of --oidc-issuer-url&gt;#&quot;. For the same
behavior using authentication config, set username.prefix=&quot;&lt;value of issuer.url&gt;#&quot;
(3) --oidc-username-prefix=&quot;&lt;value&gt;&quot;. For the same behavior using authentication config, set username.prefix=&quot;&lt;value&gt;&quot;</p>
behavior using authentication config, set username.prefix=&quot;<!-- raw HTML omitted -->#&quot;
(3) --oidc-username-prefix=&quot;<!-- raw HTML omitted -->&quot;. For the same behavior using authentication config, set username.prefix=&quot;<!-- raw HTML omitted -->&quot;</p>
</td>
</tr>
<tr><td><code>groups</code><br/>
@ -1135,4 +1202,4 @@ the contents would be converted to the v1 version before evaluating the CEL expr
</tr>
</tbody>
</table>

2
content/en/docs/reference/config-api/client-authentication.v1.md
View File

@ -205,7 +205,7 @@ itself should at least be protected via file permissions.</p>
<tr><td><code>expirationTimestamp</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#time-v1-meta"><code>meta/v1.Time</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#time-v1-meta"><code>meta/v1.Time</code></a>
</td>
<td>
<p>ExpirationTimestamp indicates a time when the provided credentials expire.</p>

2
content/en/docs/reference/config-api/client-authentication.v1beta1.md
View File

@ -205,7 +205,7 @@ itself should at least be protected via file permissions.</p>
<tr><td><code>expirationTimestamp</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#time-v1-meta"><code>meta/v1.Time</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#time-v1-meta"><code>meta/v1.Time</code></a>
</td>
<td>
<p>ExpirationTimestamp indicates a time when the provided credentials expire.</p>

2
content/en/docs/reference/config-api/imagepolicy.v1alpha1.md
View File

@ -28,7 +28,7 @@ auto_generated: true
<tr><td><code>metadata</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.30/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#objectmeta-v1-meta"><code>meta/v1.ObjectMeta</code></a>
</td>
<td>
<p>Standard object's metadata.

30
content/en/docs/reference/config-api/kube-controller-manager-config.v1alpha1.md
View File

@ -1256,13 +1256,6 @@ Larger number = more responsive HPA processing, but more CPU (and network) load.
pods in horizontal pod autoscaler.</p>
</td>
</tr>
<tr><td><code>HorizontalPodAutoscalerUpscaleForbiddenWindow</code> <B>[Required]</B><br/>
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
</td>
<td>
<p>HorizontalPodAutoscalerUpscaleForbiddenWindow is a period after which next upscale allowed.</p>
</td>
</tr>
<tr><td><code>HorizontalPodAutoscalerDownscaleStabilizationWindow</code> <B>[Required]</B><br/>
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
</td>
@ -1271,13 +1264,6 @@ pods in horizontal pod autoscaler.</p>
backwards and not scale down below any recommendation it made during that period.</p>
</td>
</tr>
<tr><td><code>HorizontalPodAutoscalerDownscaleForbiddenWindow</code> <B>[Required]</B><br/>
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
</td>
<td>
<p>HorizontalPodAutoscalerDownscaleForbiddenWindow is a period after which next downscale allowed.</p>
</td>
</tr>
<tr><td><code>HorizontalPodAutoscalerTolerance</code> <B>[Required]</B><br/>
<code>float64</code>
</td>
@ -1556,22 +1542,6 @@ and persistent volume claims.</p>
<p>volumeConfiguration holds configuration for volume related features.</p>
</td>
</tr>
<tr><td><code>VolumeHostCIDRDenylist</code> <B>[Required]</B><br/>
<code>[]string</code>
</td>
<td>
<p>DEPRECATED: VolumeHostCIDRDenylist is a list of CIDRs that should not be reachable by the
controller from plugins.</p>
</td>
</tr>
<tr><td><code>VolumeHostAllowLocalLoopback</code> <B>[Required]</B><br/>
<code>bool</code>
</td>
<td>
<p>DEPRECATED: VolumeHostAllowLocalLoopback indicates if local loopback hosts (127.0.0.1, etc)
should be allowed from plugins.</p>
</td>
</tr>
</tbody>
</table>

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