Merge pull request #45755 from chanieljdan/merged-main-dev-1.30
Merged main dev 1.30pull/45773/head
Kubernetes Prow Robot
GitHub
commit
a9be0178e6
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: Leases
|
||||
api_metadata:
|
||||
- apiVersion: "coordination.k8s.io/v1"
|
||||
kind: "Lease"
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
|
|
|||
|
|
@ -3,6 +3,9 @@ reviewers:
|
|||
- caesarxuchao
|
||||
- dchen1107
|
||||
title: Nodes
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "Node"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: ConfigMaps
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "ConfigMap"
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
reviewers:
|
||||
- mikedanese
|
||||
title: Secrets
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "Secret"
|
||||
content_type: concept
|
||||
feature:
|
||||
title: Secret and configuration management
|
||||
|
|
|
|||
|
|
@ -3,6 +3,9 @@ title: Custom Resources
|
|||
reviewers:
|
||||
- enisoc
|
||||
- deads2k
|
||||
api_metadata:
|
||||
- apiVersion: "apiextensions.k8s.io/v1"
|
||||
kind: "CustomResourceDefinition"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
|
|
|||
|
|
@ -4,6 +4,9 @@ reviewers:
|
|||
- mikedanese
|
||||
- thockin
|
||||
title: Namespaces
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "Namespace"
|
||||
content_type: concept
|
||||
weight: 45
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
reviewers:
|
||||
- nelvadas
|
||||
title: Limit Ranges
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "LimitRange"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
reviewers:
|
||||
- derekwaynecarr
|
||||
title: Resource Quotas
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "ResourceQuota"
|
||||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
reviewers:
|
||||
- freehan
|
||||
title: EndpointSlices
|
||||
api_metadata:
|
||||
- apiVersion: "discovery.k8s.io/v1"
|
||||
kind: "EndpointSlice"
|
||||
content_type: concept
|
||||
weight: 60
|
||||
description: >-
|
||||
|
|
|
|||
|
|
@ -2,6 +2,11 @@
|
|||
reviewers:
|
||||
- bprashanth
|
||||
title: Ingress
|
||||
api_metadata:
|
||||
- apiVersion: "networking.k8s.io/v1"
|
||||
kind: "Ingress"
|
||||
- apiVersion: "networking.k8s.io/v1"
|
||||
kind: "IngressClass"
|
||||
content_type: concept
|
||||
description: >-
|
||||
Make your HTTP (or HTTPS) network service available using a protocol-aware configuration
|
||||
|
|
|
|||
|
|
@ -5,6 +5,9 @@ reviewers:
|
|||
- danwinship
|
||||
title: Network Policies
|
||||
content_type: concept
|
||||
api_metadata:
|
||||
- apiVersion: "networking.k8s.io/v1"
|
||||
kind: "NetworkPolicy"
|
||||
weight: 70
|
||||
description: >-
|
||||
If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4),
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
reviewers:
|
||||
- bprashanth
|
||||
title: Service
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "Service"
|
||||
feature:
|
||||
title: Service discovery and load balancing
|
||||
description: >
|
||||
|
|
|
|||
|
|
@ -6,6 +6,9 @@ reviewers:
|
|||
- msau42
|
||||
- xing-yang
|
||||
title: Persistent Volumes
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "PersistentVolume"
|
||||
feature:
|
||||
title: Storage orchestration
|
||||
description: >
|
||||
|
|
|
|||
|
|
@ -5,6 +5,9 @@ reviewers:
|
|||
- thockin
|
||||
- msau42
|
||||
title: Volumes
|
||||
api_metadata:
|
||||
- apiVersion: ""
|
||||
kind: "Volume"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
|
@ -313,9 +316,23 @@ third party storage driver instead.
|
|||
### gitRepo (deprecated) {#gitrepo}
|
||||
|
||||
{{< warning >}}
|
||||
The `gitRepo` volume type is deprecated. To provision a container with a git repo, mount an
|
||||
[EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the
|
||||
The `gitRepo` volume type is deprecated.
|
||||
|
||||
To provision a Pod that has a Git repository mounted, you can
|
||||
mount an
|
||||
[`emptyDir`](#emptydir) volume into an [init container](/docs/concepts/workloads/pods/init-containers/) that
|
||||
clones the repo using Git, then mount the
|
||||
[EmptyDir](#emptydir) into the Pod's container.
|
||||
|
||||
---
|
||||
|
||||
You can restrict the use of `gitRepo` volumes in your cluster using
|
||||
[policies](/docs/concepts/policy/) such as
|
||||
[ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy/).
|
||||
You can use the following Common Expression Language (CEL) expression as
|
||||
part of a policy to reject use of `gitRepo` volumes:
|
||||
`!has(object.spec.volumes) || !object.spec.volumes.exists(v, has(v.gitRepo))`.
|
||||
|
||||
{{< /warning >}}
|
||||
|
||||
A `gitRepo` volume is an example of a volume plugin. This plugin
|
||||
|
|
|
|||
|
|
@ -4,6 +4,9 @@ reviewers:
|
|||
- soltysh
|
||||
- janetkuo
|
||||
title: CronJob
|
||||
api_metadata:
|
||||
- apiVersion: "batch/v1"
|
||||
kind: "CronJob"
|
||||
content_type: concept
|
||||
description: >-
|
||||
A CronJob starts one-time Jobs on a repeating schedule.
|
||||
|
|
|
|||
|
|
@ -6,6 +6,9 @@ reviewers:
|
|||
- janetkuo
|
||||
- kow3ns
|
||||
title: DaemonSet
|
||||
api_metadata:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "DaemonSet"
|
||||
description: >-
|
||||
A DaemonSet defines Pods that provide node-local facilities. These might be fundamental to the operation of your cluster, such as a networking helper tool, or be part of an add-on.
|
||||
content_type: concept
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
reviewers:
|
||||
- janetkuo
|
||||
title: Deployments
|
||||
api_metadata:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "Deployment"
|
||||
feature:
|
||||
title: Automated rollouts and rollbacks
|
||||
description: >
|
||||
|
|
|
|||
|
|
@ -4,6 +4,9 @@ reviewers:
|
|||
- erictune
|
||||
- soltysh
|
||||
title: Jobs
|
||||
api_metadata:
|
||||
- apiVersion: "batch/v1"
|
||||
kind: "Job"
|
||||
content_type: concept
|
||||
description: >-
|
||||
Jobs represent one-off tasks that run to completion and then stop.
|
||||
|
|
|
|||
|
|
@ -4,6 +4,9 @@ reviewers:
|
|||
- bprashanth
|
||||
- madhusudancs
|
||||
title: ReplicaSet
|
||||
api_metadata:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "ReplicaSet"
|
||||
feature:
|
||||
title: Self-healing
|
||||
anchor: How a ReplicaSet works
|
||||
|
|
|
|||
|
|
@ -3,6 +3,9 @@ reviewers:
|
|||
- bprashanth
|
||||
- janetkuo
|
||||
title: ReplicationController
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "ReplicationController"
|
||||
content_type: concept
|
||||
weight: 90
|
||||
description: >-
|
||||
|
|
|
|||
|
|
@ -7,6 +7,9 @@ reviewers:
|
|||
- kow3ns
|
||||
- smarterclayton
|
||||
title: StatefulSets
|
||||
api_metadata:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
content_type: concept
|
||||
description: >-
|
||||
A StatefulSet runs a group of Pods, and maintains a sticky identity for each of those Pods. This is useful for managing
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
reviewers:
|
||||
- erictune
|
||||
title: Pods
|
||||
api_metadata:
|
||||
- apiVersion: "v1"
|
||||
kind: "Pod"
|
||||
content_type: concept
|
||||
weight: 10
|
||||
no_list: true
|
||||
|
|
|
|||
|
|
@ -5,6 +5,12 @@ reviewers:
|
|||
- munnerz
|
||||
- enj
|
||||
title: Certificates and Certificate Signing Requests
|
||||
api_metadata:
|
||||
- apiVersion: "certificates.k8s.io/v1"
|
||||
kind: "CertificateSigningRequest"
|
||||
override_link_text: "CSR v1"
|
||||
- apiVersion: "certificates.k8s.io/v1alpha1"
|
||||
kind: "ClusterTrustBundle"
|
||||
content_type: concept
|
||||
weight: 25
|
||||
---
|
||||
|
|
@ -608,3 +614,5 @@ kubectl config use-context myuser
|
|||
* View the source code for the kube-controller-manager built in [approver](https://github.com/kubernetes/kubernetes/blob/32ec6c212ec9415f604ffc1f4c1f29b782968ff1/pkg/controller/certificates/approver/sarapprove.go)
|
||||
* For details of X.509 itself, refer to [RFC 5280](https://tools.ietf.org/html/rfc5280#section-3.1) section 3.1
|
||||
* For information on the syntax of PKCS#10 certificate signing requests, refer to [RFC 2986](https://tools.ietf.org/html/rfc2986)
|
||||
* Read about the ClusterTrustBundle API:
|
||||
* {{< page-api-reference kind="ClusterTrustBundle" >}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: PriorityClass
|
||||
id: priority-class
|
||||
date: 2024-03-19
|
||||
full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass
|
||||
short_description: >
|
||||
A mapping from a class name to the scheduling priority that a Pod should have.
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
---
|
||||
A PriorityClass is a named class for the scheduling priority that should be assigned to a Pod
|
||||
in that class.
|
||||
|
||||
<!--more-->
|
||||
|
||||
A [PriorityClass](/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption)
|
||||
is a non-namespaced object mapping a name to an integer priority, used for a Pod. The name is
|
||||
specified in the `metadata.name` field, and the priority value in the `value` field. Priorities range from
|
||||
-2147483648 to 1000000000 inclusive. Higher values indicate higher priority.
|
||||
|
|
@ -1115,7 +1115,7 @@ that the auto-generated Secret has not been used for a specified duration
|
|||
|
||||
Type: Label
|
||||
|
||||
Example: `endpointslice.kubernetes.io/managed-by: "controller"`
|
||||
Example: `endpointslice.kubernetes.io/managed-by: endpointslice-controller.k8s.io`
|
||||
|
||||
Used on: EndpointSlices
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 480 KiB |
|
|
@ -0,0 +1,96 @@
|
|||
------
|
||||
layout: blog
|
||||
title: "Kubernetesブッククラブを覗く"
|
||||
slug: k8s-book-club
|
||||
date: 2024-02-22
|
||||
---
|
||||
|
||||
**著者**: Frederico Muñoz (SAS Institute)
|
||||
|
||||
Kubernetesとそれを取り巻く技術のエコシステム全体を学ぶことは、課題がないわけではありません。
|
||||
このインタビューでは、[AWSのCarlos Santana](https://www.linkedin.com/in/csantanapr/)さんに、コミュニティベースの学習体験を利用するために、彼がどのようにして[Kubernetesブッククラブ](https://community.cncf.io/kubernetes-virtual-book-club/)を作ったのか、その会がどのような活動をするのか、そしてどのようにして参加するのかについて伺います。
|
||||
|
||||
|
||||
|
||||
**Frederico Muñoz (FSM)**: こんにちはCarlosさん、時間をとってくれてありがとう。
|
||||
まずはじめに、ご自身のことを少し教えていただけますか？
|
||||
|
||||
**Carlos Santana (CS)**: もちろんです。
|
||||
6年前に本番環境でKubernetesをデプロイした経験が、[Knative](https://knative.dev/)に参加するきっかけとなり、その後リリースチームを通じてKubernetesに貢献しました。
|
||||
アップストリームのKubernetesでの作業は、私がオープンソースで得た最高の経験のひとつです。
|
||||
過去2年間、AWSのシニア・スペシャリスト・ソリューション・アーキテクトとしての役割で、私は大企業がKubernetes上に内部開発者プラットフォーム(IDP)を構築することを支援してきました。
|
||||
今後、私のオープンソースへの貢献は、[Argo](https://github.com/argoproj)や[Crossplane](https://www.crossplane.io/)、[Backstage](https://www.cncf.io/projects/backstage/)のようなCNCFのプロジェクトや[CNOE](https://cnoe.io/)を対象にしています。
|
||||
|
||||
## ブッククラブの創設
|
||||
|
||||
**FSM**: それであなたがKubernetesに辿り着いたわけですが、その時点でブッククラブを始めた動機は何だったのでしょうか？
|
||||
|
||||
|
||||
**CS**: Kubernetesブッククラブのアイデアは、[TGIK](https://github.com/vmware-archive/tgik)のライブ配信での何気ない提案から生まれました。
|
||||
私にとって、それは単に本を読むということ以上に、学習コミュニティを作るということでした。
|
||||
このプラットフォームは知識の源であるだけでなく、特にパンデミックの困難な時期にはサポートシステムでもありました。
|
||||
この取り組みが、メンバーたちの対処と成長に役立っていることを目の当たりにして、喜ばしいと思っています。
|
||||
最初の本[Production Kubernetes](https://www.oreilly.com/library/view/production-kubernetes/9781492092292/)は、2021年3月5日に始めて36週間かかりました。
|
||||
現在は、1冊の本をカバーするのにそれほど時間はかからず、1週間に1章か2章です。
|
||||
|
||||
**FSM**: Kubernetesブッククラブの仕組みについて教えてください。どのように本を選び、どのように読み進めるのですか？
|
||||
|
||||
**CS**: 私たちは、グループの関心とニーズに基づいて本を共同で選んでいます。
|
||||
この実践的なアプローチは、メンバー、とくに初心者が複雑な概念をより簡単に理解するのに役立ちます。
|
||||
毎週2つのシリーズがあり、EMEAのタイムゾーンのものと、私がUSで組織しているものです。
|
||||
各オーガナイザーは共同ホストと協力してSlack上で本を選び、各章の議論するために、数週間に渡りホストのラインナップを整えます。
|
||||
|
||||
|
||||
**FSM**: 私の記憶が間違っていなければ、Kubernetesブッククラブは17冊目に突入しています。
|
||||
物事を活発に保つための秘密のレシピがあるのですか？
|
||||
|
||||
**CS**: ブッククラブを活発で魅力的なものに保つ秘訣は、いくつかの重要な要素にあります。
|
||||
|
||||
まず、一貫性が重要です。
|
||||
休みの日やKubeConのような大きなイベントの時だけミーティングをキャンセルして、定期的なスケジュールを維持するよう努力しています。
|
||||
この規則性は、メンバーの参加を維持し、信頼できるコミュニティを築くのに役立っています。
|
||||
|
||||
次に、セッションを面白く、対話式のものにすることが重要です。
|
||||
たとえば、ミートアップ中にポップアップ・クイズを頻繁に導入します。これはメンバーの理解度をテストするだけでなく、楽しみの要素も加えています。
|
||||
このアプローチによって内容の関連性が維持され、理論的な概念が実社会のシナリオでどのように適用されるかをメンバーが理解するのに役立ちます。
|
||||
|
||||
## ブッククラブで扱うトピック
|
||||
|
||||
**FSM**: 書籍の主なトピックは、Kubernetes、GitOps、セキュリティ、SRE、オブザーバビリティになっています。
|
||||
これはとくに人気という観点で、Cloud Native Landscapeの反映でしょうか？
|
||||
|
||||
**CS**: 私たちの旅は『Production Kubernetes』から始まり、実用的な本番環境向けのソリューションに焦点を当てる方向性を設定しました。
|
||||
それ以来、私たちはCNCF Landscapeのさまざまな側面を掘り下げ、異なるテーマに沿って本を揃えています。
|
||||
各テーマは、それがセキュリティであれ、オブザーバビリティであれ、サービスメッシュであれ、コミュニティ内の関連性と需要にもとづいて選択されています。
|
||||
たとえば、Kubernetes認定に関する最近のテーマでは、書籍の著者を積極的なホストとして参加させ、彼らの専門知識で議論を充実させました。
|
||||
|
||||
**FSM**: プロジェクトに最近変化があったことは知っています。[Cloud Native Community Group](https://community.cncf.io/)としてCNCFに統合されたことです。
|
||||
この変更について少しお話いただけますか？
|
||||
|
||||
**CS**: CNCFはブッククラブをCloud Native Community Groupとして快く受け入れてくれました。
|
||||
これは私たちの運営を合理化し、影響範囲を拡大する重要な進展です。
|
||||
この連携はKubernetes Community Days (KCD)のミートアップで使用されているものと同様に、管理機能の強化に役立っています。
|
||||
現在では、メンバーシップ、イベントのスケジューリング、メーリングリスト、Webカンファレンスの開催、セッションの記録など、より強固な体制が整っています。
|
||||
|
||||
**FSM**: CNCFとの関わりは、この半年間のKubernetesブッククラブの成長やエンゲージメントにどのような影響を与えましたか？
|
||||
|
||||
**CS**: 半年前にCNCFコミュニティの一員になって以来、Kubernetesブッククラブでは大きな定量的な変化を目の当たりにしてきました。
|
||||
会員数は600人以上に急増し、この間に40以上のイベントを企画・実施することに成功しました。
|
||||
さらに期待されるのは、1回のイベントに平均30人が参加するという安定した動員数です。
|
||||
この成長とエンゲージメントは、コミュニティにおける影響やKubernetesブッククラブの影響範囲に関して、私たちのCNCF加盟が肯定的な影響である明確な指標です。
|
||||
|
||||
## ブッククラブに参加する
|
||||
|
||||
**FSM**: 参加を希望する人は、どうすればいいのでしょうか？
|
||||
|
||||
**CS**: 参加するためには3つの段階があります。
|
||||
|
||||
- まず、[Kubernetesブッククラブコミュニティ](https://community.cncf.io/kubernetes-virtual-book-club/)に参加します
|
||||
- 次に、コミュニティページ上の[イベント](https://community.cncf.io/kubernetes-virtual-book-club/)に出欠連絡をします
|
||||
- 最後に、CNCFのSlackチャンネル[#kubernetes-book-club](https://cloud-native.slack.com/archives/C05EYA14P37)に参加します
|
||||
|
||||
**FSM**: 素晴らしい、ありがとうございます！最後に何かコメントをお願いします。
|
||||
|
||||
**CS**: Kubernetesブッククラブは、単に本について議論する専門家のグループというだけではなく、それ以上です。
|
||||
それは、[Neependra Khare](https://www.linkedin.com/in/neependra/)さん、[Eric Smalling](https://www.linkedin.com/in/ericsmalling/)さん、[Sevi Karakulak](https://www.linkedin.com/in/sevikarakulak/)さん、[Chad M. Crowell](https://www.linkedin.com/in/chadmcrowell/)さん、そして[Walid (CNJ) Shaari](https://www.linkedin.com/in/walidshaari/)さんの主催と企画を手伝ってくれる素晴らしいボランティアであり、活気のあるコミュニティです。
|
||||
KubeConで私たちを見て、Kubernetesブッククラブのステッカーをゲットしてください！
|
||||
|
|
@ -0,0 +1,270 @@
|
|||
---
|
||||
title: Disruption
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
このガイドは、高可用性アプリケーションを構築したいと考えており、そのために、Podに対してどのような種類のDisruptionが発生する可能性があるか理解する必要がある、アプリケーション所有者を対象としたものです。
|
||||
|
||||
また、クラスターのアップグレードやオートスケーリングなどのクラスターの操作を自動化したいクラスター管理者も対象にしています。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 自発的なDisruptionと非自発的なDisruption
|
||||
|
||||
Podは誰か(人やコントローラー)が破壊するか、避けることができないハードウェアまたはシステムソフトウェアエラーが発生するまで、消えることはありません。
|
||||
|
||||
これらの不可避なケースをアプリケーションに対する*非自発的なDisruption*と呼びます。
|
||||
例えば:
|
||||
|
||||
- ノードのバックエンドの物理マシンのハードウェア障害
|
||||
- クラスター管理者が誤ってVM(インスタンス)を削除した
|
||||
- クラウドプロバイダーまたはハイパーバイザーの障害によってVMが消えた
|
||||
- カーネルパニック
|
||||
- クラスターネットワークパーティションが原因でクラスターからノードが消えた
|
||||
- ノードの[リソース不足](/docs/concepts/scheduling-eviction/node-pressure-eviction/)によるPodの退避
|
||||
|
||||
リソース不足を除いて、これら条件は全て、大半のユーザーにとって馴染みのあるものでしょう。
|
||||
これらはKubernetesに固有のものではありません。
|
||||
|
||||
それ以外のケースのことを*自発的なDisruption*と呼びます。
|
||||
これらはアプリケーションの所有者によって起こされたアクションと、クラスター管理者によって起こされたアクションの両方を含みます。
|
||||
典型的なアプリケーションの所有者によるアクションには次のものがあります:
|
||||
|
||||
- Deploymentやその他のPodを管理するコントローラーの削除
|
||||
- 再起動を伴うDeployment内のPodのテンプレートの更新
|
||||
- Podの直接削除(例:アクシデントによって)
|
||||
|
||||
クラスター管理者のアクションには、次のようなものが含まれます:
|
||||
|
||||
- 修復やアップグレードのための[ノードのドレイン](/docs/tasks/administer-cluster/safely-drain-node/)。
|
||||
- クラスターのスケールダウンのためにクラスターからノードをドレインする([クラスター自動スケーリング](https://github.com/kubernetes/autoscaler/#readme)について学ぶ)。
|
||||
- そのノードに別のものを割り当てることができるように、ノードからPodを削除する。
|
||||
|
||||
これらのアクションはクラスター管理者によって直接実行されるか、クラスター管理者やクラスターをホスティングしているプロバイダーによって自動的に実行される可能性があります。
|
||||
|
||||
クラスターに対して自発的なDisruptionの要因となるものが有効になっているかどうかについては、クラスター管理者に聞くか、クラウドプロバイダーに相談または配布文書を参照してください。
|
||||
有効になっているものが何もなければ、Pod Disruption Budgetの作成はスキップすることができます。
|
||||
|
||||
{{< caution >}}
|
||||
全ての自発的なDisruptionがPod Disruption Budgetによる制約を受けるわけではありません。
|
||||
例えばDeploymentやPodの削除はPod Disruption Budgetをバイパスします。
|
||||
{{< /caution >}}
|
||||
|
||||
## Disruptionへの対応
|
||||
|
||||
非自発的なDisruptionを軽減する方法をいくつか紹介します:
|
||||
|
||||
- Podは必要な[リソースを要求](/ja/docs/tasks/configure-pod-container/assign-memory-resource)するようにする。
|
||||
- 高可用性が必要な場合はアプリケーションをレプリケートする。(レプリケートされた[ステートレス](/ja/docs/tasks/run-application/run-stateless-application-deployment/)および[ステートフル](/ja/docs/tasks/run-application/run-replicated-stateful-application/)アプリケーションの実行について学ぶ。)
|
||||
- レプリケートされたアプリケーションを実行する際にさらに高い可用性を得るには、([アンチアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を使って)ラックを横断して、または([マルチゾーンクラスター](/ja/docs/setup/multiple-zones)を使用している場合には)ゾーンを横断してアプリケーションを分散させる。
|
||||
|
||||
自発的なDisruptionの頻度は様々です。
|
||||
基本的なKubernetesクラスターでは、自動で発生する自発的なDisruptionはありません(ユーザーによってトリガーされたものだけです)。
|
||||
しかし、クラスター管理者やホスティングプロバイダーが何か追加のサービスを実行して自発的なDisruptionが発生する可能性があります。
|
||||
例えば、ノード上のソフトウェアアップデートのロールアウトは自発的なDisruptionの原因となります。
|
||||
また、クラスター(ノード)自動スケーリングの実装の中には、ノードのデフラグとコンパクト化のために自発的なDisruptionを伴うものがあります。
|
||||
クラスタ管理者やホスティングプロバイダーは、自発的なDisruptionがある場合、どの程度のDisruptionが予想されるかを文書化しているはずです。
|
||||
Podのspecの中で[PriorityClassesを使用している](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/)場合など、特定の設定オプションによっても自発的(および非自発的)なDisruptionを引き起こす可能性があります。
|
||||
|
||||
|
||||
## Pod Disruption Budget
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
|
||||
|
||||
Kubernetesは、自発的なDisruptionが頻繁に発生する場合でも、可用性の高いアプリケーションの運用を支援する機能を提供しています。
|
||||
|
||||
アプリケーションの所有者として、各アプリケーションに対してPodDisruptionBudget (PDB)を作成することができます。
|
||||
PDBは、レプリカを持っているアプリケーションのうち、自発的なDisruptionによって同時にダウンするPodの数を制限します。
|
||||
例えば、クォーラムベースのアプリケーションでは、実行中のレプリカの数がクォーラムに必要な数を下回らないようにする必要があります。
|
||||
Webフロントエンドは、負荷に対応するレプリカの数が、全体に対して一定の割合を下回らないようにしたいかもしれません。
|
||||
|
||||
クラスター管理者やホスティングプロバイダーは、直接PodやDeploymentを削除するのではなく、[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api)を呼び出す、PodDisruptionBudgetsに配慮したツールを使用すべきです。
|
||||
|
||||
例えば、`kubectl drain`サブコマンドはノードを休止中とマークします。
|
||||
`kubectl drain`を実行すると、ツールは休止中としたノード上の全てのPodを退避しようとします。
|
||||
`kubectl`があなたの代わりに送信する退避要求は一時的に拒否される可能性があるため、ツールは対象のノード上の全てのPodが終了するか、設定可能なタイムアウト時間に達するまで、全ての失敗した要求を定期的に再試行します。
|
||||
|
||||
PDBはアプリケーションの意図したレプリカ数に対して、許容できるレプリカの数を指定します。
|
||||
例えば`.spec.replicas: 5`を持つDeploymentは常に5つのPodを持つことが想定されます。
|
||||
PDBが同時に4つまでを許容する場合、Eviction APIは1度に(2つではなく)1つのPodの自発的なDisruptionを許可します。
|
||||
|
||||
アプリケーションを構成するPodのグループは、アプリケーションのコントローラー(Deployment、StatefulSetなど)が使用するものと同じラベルセレクターを使用して指定されます。
|
||||
|
||||
"意図した"Podの数は、これらのPodを管理するワークロードリソースの`.spec.replicas`から計算されます。
|
||||
コントロールプレーンはPodの`.metadata.ownerReferences`を調べることで、所有しているワークロードリソースを見つけます。
|
||||
|
||||
[非自発的なDisruption](#voluntary-and-involuntary-disruptions)はPDBによって防ぐことができません;
|
||||
しかし、予算にはカウントされます。
|
||||
|
||||
アプリケーションのローリングアップデートによって削除または利用できなくなったPodはDisruptionの予算にカウントされますが、ローリングアップグレードを実行している時は(DeploymentやStatefulSetなどの)ワークロードリソースはPDBによって制限されません。
|
||||
代わりに、アプリケーションのアップデート中の障害のハンドリングは、個々のワークロードリソースに対するspecで設定されます。
|
||||
|
||||
ノードのドレイン中に動作がおかしくなったアプリケーションの退避をサポートするために、[Unhealthy Pod Eviction Policy](/docs/tasks/run-application/configure-pdb/#unhealthy-pod-eviction-policy)に`AlwaysAllow`を設定することを推奨します。
|
||||
既定の動作は、ドレインを継続する前にアプリケーションPodが[healthy](/docs/tasks/run-application/configure-pdb/#healthiness-of-a-pod)な状態になるまで待機します。
|
||||
|
||||
Eviction APIを使用してPodを退避した場合、[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)で設定した`terminationGracePeriodSeconds`に従って正常に[終了](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)します。
|
||||
|
||||
## PodDisruptionBudgetの例 {#pdb-example}
|
||||
|
||||
`node-1`から`node-3`まで3つのノードがあるクラスターを考えます。
|
||||
クラスターにはいくつかのアプリケーションが動いています。
|
||||
それらのうちの1つは3つのレプリカを持ち、最初は`pod-a`、`pod-b`そして`pod-c`と名前が付いています。
|
||||
もう一つ、これとは独立したPDBなしの`pod-x`と呼ばれるものもあります。
|
||||
初期状態ではPodは次のようにレイアウトされています:
|
||||
|
||||
| node-1 | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *available* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *available* | | |
|
||||
|
||||
3つのPodはすべてDeploymentの一部で、これらはまとめて1つのPDBを持ち、3つのPodのうちの少なくとも2つが常に存在していることを要求します。
|
||||
|
||||
例えばクラスター管理者がカーネルのバグを修正するために、再起動して新しいカーネルバージョンにしたいとします。
|
||||
クラスター管理者はまず、`kubectl drain`コマンドを使って`node-1`をドレインしようとします。
|
||||
ツールは`pod-a`と`pod-x`を退避しようとします。
|
||||
これはすぐに成功します。
|
||||
2つのPodは同時に`terminating`状態になります。
|
||||
これにより、クラスターは次のような状態になります:
|
||||
|
||||
| node-1 *draining* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *terminating* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *terminating* | | |
|
||||
|
||||
DeploymentはPodの1つが終了中であることに気づき、`pod-d`という代わりのPodを作成します。
|
||||
`node-1`はcordonされたため、別のノードに展開されます。
|
||||
また、`pod-x`の代わりとして`pod-y`も作られました。
|
||||
|
||||
(備考: StatefulSetの場合、`pod-a`は`pod-0`のように呼ばれ、代わりのPodが作成される前に完全に終了する必要があります。
|
||||
この代わりのPodは、UIDは異なりますが、同じ`pod-0`という名前になります。
|
||||
それを除けば、本例はStatefulSetにも当てはまります。)
|
||||
|
||||
現在、クラスターは次のような状態になっています:
|
||||
|
||||
| node-1 *draining* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| pod-a *terminating* | pod-b *available* | pod-c *available* |
|
||||
| pod-x *terminating* | pod-d *starting* | pod-y |
|
||||
|
||||
ある時点でPodは終了し、クラスターはこのようになります:
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| | pod-b *available* | pod-c *available* |
|
||||
| | pod-d *starting* | pod-y |
|
||||
|
||||
この時点で、せっかちなクラスター管理者が`node-2`か`node-3`をドレインしようとすると、Deploymentの利用可能なPodは2つしかなく、また、PDBによって最低2つのPodが要求されているため、drainコマンドはブロックされます。
|
||||
しばらくすると、`pod-d`が使用可能になります。
|
||||
|
||||
クラスターの状態はこのようになります:
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 |
|
||||
|:--------------------:|:-------------------:|:------------------:|
|
||||
| | pod-b *available* | pod-c *available* |
|
||||
| | pod-d *available* | pod-y |
|
||||
|
||||
ここでクラスター管理者が`node-2`をドレインしようとします。
|
||||
drainコマンドは2つのPodをなんらかの順番で退避しようとします。
|
||||
例えば最初に`pod-b`、次に`pod-d`とします。
|
||||
`pod-b`については退避に成功します。
|
||||
しかし`pod-d`を退避しようとすると、Deploymentに対して利用可能なPodは1つしか残らないため、退避は拒否されます。
|
||||
|
||||
Deploymentは`pod-b`の代わりとして`pod-e`を作成します。
|
||||
クラスターには`pod-e`をスケジューリングする十分なリソースがないため、ドレインは再びブロックされます。
|
||||
クラスターは次のような状態になります:
|
||||
|
||||
| node-1 *drained* | node-2 | node-3 | *no node* |
|
||||
|:--------------------:|:-------------------:|:------------------:|:------------------:|
|
||||
| | pod-b *terminating* | pod-c *available* | pod-e *pending* |
|
||||
| | pod-d *available* | pod-y | |
|
||||
|
||||
この時点で、クラスター管理者はアップグレードを継続するためにクラスターにノードを追加する必要があります。
|
||||
|
||||
KubernetesがどのようにDisruptionの発生率を変化させているかについては、次のようなものから知ることができます:
|
||||
|
||||
- いくつのレプリカをアプリケーションが必要としているか
|
||||
- インスタンスのグレースフルシャットダウンにどれくらいの時間がかかるか
|
||||
- 新しいインスタンスのスタートアップにどれくらいの時間がかかるか
|
||||
- コントローラーの種類
|
||||
- クラスターリソースのキャパシティ
|
||||
|
||||
## Pod Disruption Condition {#pod-disruption-conditions}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
この機能を使用するためには、クラスターで[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)`PodDisruptionConditions`を有効にする必要があります。
|
||||
{{< /note >}}
|
||||
|
||||
有効にすると、専用のPod `DisruptionTarget` [Condition](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)が追加されます。
|
||||
これはPodが{{<glossary_tooltip term_id="disruption" text="Disruption">}}によって削除されようとしていることを示すものです。
|
||||
Conditionの`reason`フィールドにて、追加で以下のいずれかをPodの終了の理由として示します:
|
||||
|
||||
`PreemptionByScheduler`
|
||||
: Podはより高い優先度を持つ新しいPodを収容するために、スケジューラーによって{{<glossary_tooltip term_id="preemption" text="プリエンプトされる">}}予定です。
|
||||
詳細については[Podの優先度とプリエンプション](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/)を参照してください。
|
||||
|
||||
`DeletionByTaintManager`
|
||||
: Podが許容しない`NoExecute` taintによって、Podは(`kube-controller-manager`の中のノードライフサイクルコントローラーである)Taintマネージャーによって削除される予定です。
|
||||
{{<glossary_tooltip term_id="taint" text="taint">}}ベースの退避を参照してください。
|
||||
|
||||
`EvictionByEvictionAPI`
|
||||
: Podは{{<glossary_tooltip term_id="api-eviction" text="Kubernetes APIを使用して退避するように">}}マークされました。
|
||||
|
||||
`DeletionByPodGC`
|
||||
: すでに存在しないノードに紐づいているPodのため、[Podのガベージコレクション](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)によって削除される予定です。
|
||||
|
||||
`TerminationByKubelet`
|
||||
: {{<glossary_tooltip term_id="node-pressure-eviction" text="node-pressureによる退避">}}または[Graceful Node Shutdown](/ja/docs/concepts/architecture/nodes/#graceful-node-shutdown)のため、Podはkubeletによって終了させられました。
|
||||
|
||||
{{< note >}}
|
||||
PodのDisruptionは一時停止する場合があります。
|
||||
コントロールプレーンは同じPodに対するDisruptionを継続するために再試行するかもしれませんが、保証はされていません。
|
||||
その結果、`DisruptionTarget` ConditionはPodに付与されるかもしれませんが、実際にはPodは削除されていない可能性があります。
|
||||
そのような状況の場合、しばらくすると、Pod Disruption Conditionはクリアされます。
|
||||
{{< /note >}}
|
||||
|
||||
フィーチャーゲート`PodDisruptionConditions`を有効にすると、Podのクリーンアップと共に、Podガベージコレクタ(PodGC)が非終了フェーズにあるPodを失敗とマークします。
|
||||
([Podガベージコレクション](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)も参照してください)。
|
||||
|
||||
Job(またはCronJob)を使用している場合、Jobの[Pod失敗ポリシー](/ja/docs/concepts/workloads/controllers/job#pod-failure-policy)の一部としてこれらのPod Disruption Conditionを使用したいと思うかもしれません。
|
||||
|
||||
## クラスターオーナーとアプリケーションオーナーロールの分離
|
||||
|
||||
多くの場合、クラスター管理者とアプリケーションオーナーは、互いの情報を一部しか持たない別の役割であると考えるのが便利です。
|
||||
このような責任の分離は、次のようなシナリオで意味を持つことがあります:
|
||||
|
||||
- 多くのアプリケーションチームでKubernetesクラスターを共有していて、役割の専門化が自然に行われている場合
|
||||
- クラスター管理を自動化するためにサードパーティのツールやサービスを使用している場合
|
||||
|
||||
Pod Disruption Budgetはロール間のインターフェースを提供することによって、この役割の分離をサポートします。
|
||||
|
||||
もしあなたの組織でこのような責任の分担がなされていない場合は、Pod Disruption Budgetを使用する必要はないかもしれません。
|
||||
|
||||
## クラスターで破壊的なアクションを実行する方法
|
||||
|
||||
あなたがクラスターの管理者で、ノードやシステムソフトウェアのアップグレードなど、クラスター内のすべてのノードに対して破壊的なアクションを実行する必要がある場合、次のような選択肢があります:
|
||||
|
||||
- アップグレードの間のダウンタイムを許容する。
|
||||
- もう一つの完全なレプリカクラスターにフェールオーバーする。
|
||||
- ダウンタイムはありませんが、重複するノードと、切り替えを調整する人的労力の両方のコストがかかる可能性があります。
|
||||
- Disruptionに耐性のあるアプリケーションを書き、PDBを使用する。
|
||||
- ダウンタイムはありません。
|
||||
- リソースの重複は最小限です。
|
||||
- クラスター管理をより自動化できます。
|
||||
- Disruptionに耐えうるアプリケーションを書くことは大変ですが、自発的なDisruptionに耐えうるようにするための作業は、非自発的なDisruptionに耐えうるために必要な作業とほぼ重複しています。
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Pod Disruption Budgeを構成して](/docs/tasks/run-application/configure-pdb/)アプリケーションを保護する手順にしたがってください。
|
||||
|
||||
* [ノードのドレイン](/docs/tasks/administer-cluster/safely-drain-node/)について学んでください。
|
||||
|
||||
* ロールアウト中の可用性を維持するためのステップなど、[Deploymentの更新](/ja/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)について学んでください。
|
||||
|
|
@ -0,0 +1,102 @@
|
|||
---
|
||||
title: Kubectlを用いたKubernetesノードのデバッグ
|
||||
content_type: task
|
||||
min-kubernetes-server-version: 1.20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
このページでは、Kubernetesクラスター上で動作している[ノード](/ja/docs/concepts/architecture/nodes/)を`kubectl debug`コマンドを使用してデバッグする方法について説明します。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
Podを作成し、それらの新しいPodを任意のノードに割り当てる権限が必要です。
|
||||
また、ホストのファイルシステムにアクセスするPodを作成する権限も必要です。
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## `kubectl debug node`を用いてノードをデバッグする
|
||||
|
||||
`kubectl debug node`コマンドを使用して、トラブルシューティングしたいノードにPodをデプロイします。
|
||||
このコマンドは、SSH接続を使用してノードにアクセスできないシナリオで役に立ちます。
|
||||
Podが作成されると、そのPodはノード上で対話型シェルを開きます。
|
||||
mynodeという名前のノード上で対話型シェルを作成するには、次のように実行します。
|
||||
|
||||
```shell
|
||||
kubectl debug node/mynode -it --image=ubuntu
|
||||
```
|
||||
|
||||
```console
|
||||
ノードmynode上に、コンテナデバッガーを持つデバッグ用Pod、node-debugger-mynode-pdx84を作成します。
|
||||
コマンドプロンプトが表示されない場合は、エンターキーを押してみてください。
|
||||
root@mynode:/#
|
||||
```
|
||||
|
||||
デバッグコマンドは、情報を収集し、問題をトラブルシューティングするのに役立ちます。
|
||||
使用する可能性のあるコマンドには、`ip`、`ifconfig`、`nc`、`ping`、`ps`などがあります。
|
||||
また、`mtr`、`tcpdump`、`curl`などの他のツールもそれぞれのパッケージマネージャーからインストールすることができます。
|
||||
|
||||
{{< note >}}
|
||||
|
||||
デバッグコマンドは、デバッグ用のPodが使用しているイメージに基づいて異なる場合があり、これらのコマンドをインストールする必要があるかもしれません。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
デバッグ用のPodは、Pod内の`/host`にマウントされたノードのルートファイルシステムにアクセスできます。
|
||||
kubeletをファイルシステムのネームスペースで実行している場合、デバッグ用のPodはそのネームスペースのルートを見ることになり、ノード全体のルートではありません。
|
||||
典型的なLinuxノードの場合、関連するログを見つけるために以下のパスを確認できます。
|
||||
|
||||
`/host/var/log/kubelet.log`
|
||||
: ノード上でコンテナを実行する責任がある`kubelet`からのログです。
|
||||
|
||||
`/host/var/log/kube-proxy.log`
|
||||
: サービスのエンドポイントへのトラフィックを指示する責任がある`kube-proxy`からのログです。
|
||||
|
||||
`/host/var/log/containerd.log`
|
||||
: ノード上で実行されている`containerd`プロセスからのログです。
|
||||
|
||||
`/host/var/log/syslog`
|
||||
: システムに関する一般的なメッセージや情報です。
|
||||
|
||||
`/host/var/log/kern.log`
|
||||
: カーネルログです。
|
||||
|
||||
ノード上でデバッグセッションを作成する際には、以下の点を考慮してください。
|
||||
|
||||
* `kubectl debug`は、新しいPodの名前をノードの名前に基づいて自動的に生成します。
|
||||
* ノードのルートファイルシステムは`/host`にマウントされます。
|
||||
* コンテナはホストのIPC、ネットワーク、PID Namespaceで実行されますが、Podは特権を持っていません。
|
||||
これは、一部のプロセス情報の読み取りが失敗する可能性があることを意味します。
|
||||
その情報へのアクセスはスーパーユーザーに制限されているためです。
|
||||
例えば、`chroot /host`は失敗します。
|
||||
特権Podが必要な場合は、手動で作成してください。
|
||||
|
||||
## {{% heading "cleanup" %}}
|
||||
|
||||
デバッグ用のPodの使用が終了したら、それを削除してください。
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
node-debugger-mynode-pdx84 0/1 Completed 0 8m1s
|
||||
```
|
||||
|
||||
```shell
|
||||
# Podの名前は適宜変更してください
|
||||
kubectl delete pod node-debugger-mynode-pdx84 --now
|
||||
```
|
||||
|
||||
```none
|
||||
pod "node-debugger-mynode-pdx84" deleted
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
||||
ノードがダウンしている場合(ネットワークから切断されている、kubeletが停止して再起動しないなど)、`kubectl debug node`コマンドは機能しません。
|
||||
その場合は、[ダウンあるいは到達不能なノードのデバッグ](/ja/docs/tasks/debug/debug-cluster/#example-debugging-a-down-unreachable-node)を確認してください。
|
||||
|
||||
{{< /note >}}
|
||||
|
|
@ -17,7 +17,7 @@ weight: 40
|
|||
|
||||
Чтобы работать с Kubernetes, вы используете *объекты API Kubernetes* для описания *желаемого состояния вашего кластера*: какие приложения или другие рабочие нагрузки вы хотите запустить, какие образы контейнеров они используют, количество реплик, какие сетевые и дисковые ресурсы вы хотите использовать и сделать доступными и многое другое. Вы устанавливаете желаемое состояние, создавая объекты с помощью API Kubernetes, обычно через интерфейс командной строки `kubectl`. Вы также можете напрямую использовать API Kubernetes для взаимодействия с кластером и установки или изменения желаемого состояния.
|
||||
|
||||
После того, как вы установили желаемое состояние, *Плоскость управления Kubernetes* заставляет текущее состояние кластера соответствовать желаемому состоянию с помощью генератора событий жизненного цикла подов ([Pod Lifecycle Event Generator, PLEG](https://github.com/kubernetes/design-proposals-archive/blob/main/node/pod-lifecycle-event-generator.md)). Для этого Kubernetes автоматически выполняет множество задач, таких как запуск или перезапуск контейнеров, масштабирование количества реплик данного приложения и многое другое. Плоскость управления Kubernetes состоит из набора процессов, запущенных в вашем кластере:
|
||||
После того, как вы установили желаемое состояние, *Управляющий слой Kubernetes* (control plane) заставляет текущее состояние кластера соответствовать желаемому состоянию с помощью генератора событий жизненного цикла подов ([Pod Lifecycle Event Generator, PLEG](https://github.com/kubernetes/design-proposals-archive/blob/main/node/pod-lifecycle-event-generator.md)). Для этого Kubernetes автоматически выполняет множество задач, таких как запуск или перезапуск контейнеров, масштабирование количества реплик данного приложения и многое другое. Управляющий слой Kubernetes состоит из набора процессов, запущенных в вашем кластере:
|
||||
|
||||
* **Мастер Kubernetes** — это коллекция из трех процессов, которые выполняются на одном узле в вашем кластере, который обозначен как главный узел. Это процессы: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) и [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
* Каждый отдельный неосновной узел в вашем кластере выполняет два процесса:
|
||||
|
|
@ -43,11 +43,11 @@ Kubernetes также содержит абстракции более высо
|
|||
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
|
||||
## Плоскость управления Kubernetes
|
||||
## Управляющий слой Kubernetes
|
||||
|
||||
Различные части панели управления Kubernetes, такие как мастер Kubernetes и процессы kubelet, определяют, как Kubernetes взаимодействует с кластером. Плоскость управления поддерживает запись всех объектов Kubernetes в системе и запускает непрерывные циклы управления для обработки состояния этих объектов. В любое время циклы управления панели управления будут реагировать на изменения в кластере и работать, чтобы фактическое состояние всех объектов в системе соответствовало желаемому состоянию, которое вы указали.
|
||||
Различные части управляющего слоя Kubernetes (control plane), такие как мастер Kubernetes и процессы kubelet, определяют, как Kubernetes взаимодействует с кластером. Управляющий слой поддерживает запись всех объектов Kubernetes в системе и запускает непрерывные циклы управления для обработки состояния этих объектов. В любое время циклы управления управляющего слоя будут реагировать на изменения в кластере и работать, чтобы фактическое состояние всех объектов в системе соответствовало желаемому состоянию, которое вы указали.
|
||||
|
||||
Например, когда вы используете API Kubernetes для создания развертывания, вы предоставляете новое желаемое состояние для системы. Плоскость управления Kubernetes записывает создание этого объекта и выполняет ваши инструкции, запуская необходимые приложения и планируя их на узлы кластера, чтобы фактическое состояние кластера соответствовало желаемому состоянию.
|
||||
Например, когда вы используете API Kubernetes для создания развертывания, вы предоставляете новое желаемое состояние для системы. Управляющий слой Kubernetes записывает создание этого объекта и выполняет ваши инструкции, запуская необходимые приложения и планируя их на узлы кластера, чтобы фактическое состояние кластера соответствовало желаемому состоянию.
|
||||
|
||||
### Мастер Kubernetes
|
||||
|
||||
|
|
|
|||
|
|
@ -22,11 +22,11 @@ weight: 40
|
|||
|
||||
|
||||
|
||||
Диспетчер облачных контроллеров работает в панели управления как реплицированный набор процессов (обычно это контейнер в Pod-ах). Каждый диспетчер облачных контроллеров реализует множество {{< glossary_tooltip text="контроллеров" term_id="controller" >}} в единственном процессе.
|
||||
Диспетчер облачных контроллеров работает в управляющем слое (control plane) как реплицированный набор процессов (обычно это контейнер в Pod-ах). Каждый диспетчер облачных контроллеров реализует множество {{< glossary_tooltip text="контроллеров" term_id="controller" >}} в единственном процессе.
|
||||
|
||||
|
||||
{{< note >}}
|
||||
Вы также можете запустить диспетчер облачных контроллеров как {{< glossary_tooltip text="дополнение" term_id="addons" >}} Kubernetes, а не как часть панели управления.
|
||||
Вы также можете запустить диспетчер облачных контроллеров как {{< glossary_tooltip text="дополнение" term_id="addons" >}} Kubernetes, а не как часть управляющего слоя.
|
||||
{{< /note >}}
|
||||
|
||||
## Функции диспетчера облачных контроллеров {#functions-of-the-ccm}
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
reviewers:
|
||||
- dchen1107
|
||||
- liggitt
|
||||
title: Связь между плоскостью управления и узлом
|
||||
title: Связь между управляющим слоем и узлом
|
||||
content_type: concept
|
||||
weight: 20
|
||||
aliases:
|
||||
|
|
@ -11,13 +11,13 @@ aliases:
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Этот документ описывает связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера).
|
||||
Этот документ описывает связь между API-сервером и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Связь между плоскостью управления и узлом
|
||||
## От узла к управляющему слою
|
||||
|
||||
В Kubernetes имеется API шаблон «ступица и спица» (hub-and-spoke). Все используемые API из узлов (или которые запускают pod-ы) завершает apiserver. Ни один из других компонентов плоскости управления не предназначен для предоставления удаленных сервисов. Apiserver настроен на прослушивание удаленных подключений через безопасный порт HTTPS (обычно 443) с одной или несколькими включенными формами [аутентификации](/docs/reference/access-authn-authz/authentication/) клиента.
|
||||
В Kubernetes имеется API шаблон «ступица и спица» (hub-and-spoke). Все используемые API из узлов (или которые запускают pod-ы) завершает apiserver. Ни один из других компонентов управляющего слоя не предназначен для предоставления удаленных сервисов. Apiserver настроен на прослушивание удаленных подключений через безопасный порт HTTPS (обычно 443) с одной или несколькими включенными формами [аутентификации](/docs/reference/access-authn-authz/authentication/) клиента.
|
||||
|
||||
Должна быть включена одна или несколько форм [авторизации](/docs/reference/access-authn-authz/authorization/), особенно, если разрешены [анонимные запросы](/docs/reference/access-authn-authz/authentication/#anonymous-requests) или [ServiceAccount токены](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
|
||||
|
||||
|
|
@ -28,11 +28,11 @@ Pod-ы, которые хотят подключиться к apiserver, мог
|
|||
|
||||
Компоненты уровня управления также взаимодействуют с кластером apiserver-а через защищенный порт.
|
||||
|
||||
В результате режим работы по умолчанию для соединений от узлов и модулей, работающих на узлах, к плоскости управления по умолчанию защищен и может работать в ненадежных и/или общедоступных сетях.
|
||||
В результате режим работы по умолчанию для соединений от узлов и модулей, работающих на узлах, к управляющему слою по умолчанию защищен и может работать в ненадежных и/или общедоступных сетях.
|
||||
|
||||
## Узел к плоскости управления
|
||||
## От управляющего слоя к узлу
|
||||
|
||||
Существуют два пути связи плоскости управления (apiserver) с узлами. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а.
|
||||
Существуют два пути связи управляющего слоя (API-сервера) с узлами. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а.
|
||||
|
||||
### apiserver в kubelet
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ Pod-ы, которые хотят подключиться к apiserver, мог
|
|||
|
||||
### SSH-туннели
|
||||
|
||||
Kubernetes поддерживает SSH-туннели для защиты плоскости управления узлов от путей связи. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафик предназначенный для kubelet, узлу, pod-у или службе через туннель. Этот туннель гарантирует, что трафик не выводится за пределы сети, в которой работает узел.
|
||||
Kubernetes поддерживает SSH-туннели для защиты путей связи от управляющего слоя к узлам. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафик предназначенный для kubelet, узлу, pod-у или службе через туннель. Этот туннель гарантирует, что трафик не выводится за пределы сети, в которой работает узел.
|
||||
|
||||
SSH-туннели в настоящее время устарели, поэтому вы не должны использовать их, если не знаете, что делаете. Служба подключения является заменой этого канала связи.
|
||||
|
||||
|
|
@ -64,6 +64,6 @@ SSH-туннели в настоящее время устарели, поэто
|
|||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
В качестве замены SSH-туннелям, служба подключения обеспечивает уровень полномочия TCP для плоскости управления кластерной связи. Служба подключения состоит из двух частей: сервер подключения к сети плоскости управления и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с плоскости управления на узлы проходит через эти соединения.
|
||||
В качестве замены SSH-туннелям, служба подключения обеспечивает прокси TCP-уровня для взаимодействия управляющего слоя с кластером. Служба подключения состоит из двух частей: сервер подключения к сети управляющего слоя и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с управляющего слоя на узлы проходит через эти соединения.
|
||||
|
||||
Следуйте инструкциям [Задача службы подключения,](/docs/tasks/extend-kubernetes/setup-konnectivity/) чтобы настроить службу подключения в кластере.
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ weight: 30
|
|||
Когда контроллер задания видит новую задачу, он убеждается что где-то в вашем кластере kubelet-ы на множестве узлов запускают нужное количество Pod-ов для выполнения работы.
|
||||
Контроллер задания сам по себе не запускает никакие Pod-ы или контейнеры. Вместо этого контроллер задания сообщает серверу API о создании или удалении Pod-ов.
|
||||
Другие компоненты в
|
||||
{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}}
|
||||
{{< glossary_tooltip text="управляющем слое" term_id="control-plane" >}}
|
||||
действуют на основе информации (имеются ли новые запланированные Pod-ы для запуска), и в итоге работа завершается.
|
||||
|
||||
После того как вы создадите новое задание, желаемое состояние для этого задания будет завершено. Контроллер задания приближает текущее состояние этой задачи к желаемому состоянию: создает Pod-ы, выполняющие работу, которую вы хотели для этой задачи, чтобы задание было ближе к завершению.
|
||||
|
|
@ -70,7 +70,7 @@ weight: 30
|
|||
|
||||
Важным моментом здесь является то, что контроллер вносит некоторые изменения, чтобы вызвать желаемое состояние, а затем сообщает текущее состояние обратно на сервер API вашего кластера. Другие контуры управления могут наблюдать за этими отчетными данными и предпринимать собственные действия.
|
||||
|
||||
В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes, плоскость управления косвенно работает с инструментами управления IP-адресами, службами хранения данных, API облачных провайдеров и другими службами для реализации
|
||||
В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes управляющий слой косвенно работает с инструментами управления IP-адресами, службами хранения данных, API облачных провайдеров и другими службами для реализации
|
||||
[расширения Kubernetes](/docs/concepts/extend-kubernetes/).
|
||||
|
||||
## Желаемое против текущего состояния {#desired-vs-current}
|
||||
|
|
@ -99,9 +99,9 @@ Kubernetes использует систему вида cloud-native и спос
|
|||
Kubernetes поставляется с набором встроенных контроллеров, которые работают внутри {{< glossary_tooltip term_id="kube-controller-manager" >}}. Эти встроенные контроллеры обеспечивают важные основные функции.
|
||||
|
||||
Контроллер развертывания и контроллер заданий - это примеры контроллеров, которые входят в состав самого Kubernetes («встроенные» контроллеры).
|
||||
Kubernetes позволяет вам запускать устойчивую плоскость управления, так что в случае отказа одного из встроенных контроллеров работу берет на себя другая часть плоскости управления.
|
||||
Kubernetes позволяет вам запускать устойчивый управляющий слой (control plane), так что в случае отказа одного из встроенных контроллеров работу берет на себя другая часть управляющего слоя.
|
||||
|
||||
Вы можете найти контроллеры, которые работают вне плоскости управления, чтобы расширить Kubernetes.
|
||||
Вы можете найти контроллеры, которые работают вне управляющего слоя, чтобы расширить Kubernetes.
|
||||
Или, если вы хотите, можете написать новый контроллер самостоятельно. Вы можете запустить свой собственный контроллер в виде наборов Pod-ов,
|
||||
или внешнее в Kubernetes. Что подойдет лучше всего, будет зависеть от того, что делает этот конкретный контроллер.
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ Kubernetes позволяет вам запускать устойчивую п
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Прочтите о [плоскости управления Kubernetes ](/docs/concepts/overview/components/#control-plane-components)
|
||||
* Откройте для себя некоторые из основных [объектов Kubernetes ](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
* Узнайте больше о [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
|
||||
* Прочтите об [управляющем слое Kubernetes ](/ru/docs/concepts/overview/components/#компоненты-управляющего-слоя)
|
||||
* Откройте для себя некоторые из основных [объектов Kubernetes](/ru/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
* Узнайте больше о [Kubernetes API](/ru/docs/concepts/overview/kubernetes-api/)
|
||||
* Если вы хотите написать собственный контроллер, см [Шаблоны расширения](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) в расширении Kubernetes.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Kubernetes запускает ваши приложения, помещая ко
|
|||
В зависимости от кластера, узел может быть виртуальной или физической машиной. Каждый узел
|
||||
содержит сервисы, необходимые для запуска
|
||||
{{< glossary_tooltip text="Подов" term_id="pod" >}}, управляемых
|
||||
{{< glossary_tooltip text="плоскостью управления" term_id="control-plane" >}}.
|
||||
{{< glossary_tooltip text="control plane (управляющим слоем)" term_id="control-plane" >}}.
|
||||
|
||||
Обычно у вас есть несколько узлов в кластере; однако в среде обучения или среде
|
||||
с ограниченными ресурсами у вас может быть только один.
|
||||
|
|
@ -29,11 +29,11 @@ Kubernetes запускает ваши приложения, помещая ко
|
|||
|
||||
Существует два основных способа добавления Узлов в {{< glossary_tooltip text="API сервер" term_id="kube-apiserver" >}}:
|
||||
|
||||
1. Kubelet на узле саморегистрируется в плоскости управления
|
||||
1. Kubelet на узле саморегистрируется в управляющем слое
|
||||
2. Вы или другой пользователь вручную добавляете объект Узла
|
||||
|
||||
После того как вы создадите объект Узла или kubelet на узле самозарегистируется,
|
||||
плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы
|
||||
управляющий слой проверяет, является ли новый объект Узла валидным (правильным). Например, если вы
|
||||
попробуете создать Узел при помощи следующего JSON манифеста:
|
||||
|
||||
```json
|
||||
|
|
@ -217,7 +217,7 @@ kubectl describe node <insert-node-name-here>
|
|||
### Контроллер узла
|
||||
|
||||
{{< glossary_tooltip text="Контроллер " term_id="controller" >}} узла является компонентом
|
||||
плоскости управления Kubernetes, который управляет различными аспектами узлов.
|
||||
управляющего слоя Kubernetes, который управляет различными аспектами узлов.
|
||||
|
||||
Контроллер узла играет различные роли в жизни узла. Первая - назначение CIDR-блока узлу
|
||||
при его регистрации (если включено назначение CIDR).
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ no_list: true
|
|||
* [Аудит](/docs/tasks/debug-application-cluster/audit/) описывает, как взаимодействовать с журналами аудита Kubernetes.
|
||||
|
||||
### Обеспечение безопасности kubelet
|
||||
* [Связь между плоскостью управления и узлом](/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [Связь между управляющим слоем и узлом](/ru/docs/concepts/architecture/control-plane-node-communication/)
|
||||
* [Загрузка TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Аутентификация/авторизация Kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
|
||||
|
||||
|
|
|
|||
|
|
@ -23,11 +23,11 @@ card:
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## Плоскость управления компонентами
|
||||
## Компоненты управляющего слоя
|
||||
|
||||
Компоненты панели управления отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик).
|
||||
Компоненты управляющего слоя (control plane) отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый {{< glossary_tooltip text="под" term_id="pod">}}, когда поле `replicas` развертывания не соответствует требуемому количеству реплик).
|
||||
|
||||
Компоненты панели управления могут быть запущены на любой машине в кластере. Однако для простоты сценарии настройки обычно запускают все компоненты панели управления на одном компьютере и в то же время не позволяют запускать пользовательские контейнеры на этом компьютере. Смотрите страницу [Создание высоконадёжных кластеров](/docs/admin/high-availability/) для примера настройки нескольких ведущих виртуальных машин.
|
||||
Компоненты управляющего слоя могут быть запущены на любой машине в кластере. Однако для простоты сценарии настройки обычно запускают все компоненты управляющего слоя на одном компьютере и в то же время не позволяют запускать пользовательские контейнеры на этом компьютере. Смотрите страницу [Создание высоконадёжных кластеров](/docs/admin/high-availability/) для примера настройки нескольких ведущих виртуальных машин.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ card:
|
|||
Почти в каждом объекте Kubernetes есть два вложенных поля-объекта, которые управляют конфигурацией объекта: *`spec`* и *`status`*.
|
||||
При создании объекта в поле `spec` указывается _требуемое состояние_ (описание характеристик, которые должны быть у объекта).
|
||||
|
||||
Поле `status` описывает _текущее состояние_ объекта, которое создаётся и обновляется самим Kubernetes и его компонентами. {{< glossary_tooltip text="Плоскость управления" term_id="control-plane" >}} Kubernetes непрерывно управляет фактическим состоянием каждого объекта, чтобы оно соответствовало требуемому состоянию, которое было задано пользователем.
|
||||
Поле `status` описывает _текущее состояние_ объекта, которое создаётся и обновляется самим Kubernetes и его компонентами. {{< glossary_tooltip text="Управляющий слой" term_id="control-plane" >}} Kubernetes непрерывно управляет фактическим состоянием каждого объекта, чтобы оно соответствовало требуемому состоянию, которое было задано пользователем.
|
||||
|
||||
Например: Deployment — это объект Kubernetes, представляющий работающее приложение в кластере. При создании объекта Deployment вы можете указать в его поле `spec`, что хотите иметь три реплики приложения. Система Kubernetes получит спецификацию объекта Deployment и запустит три экземпляра приложения, таким образом обновит статус (состояние) объекта, чтобы он соответствовал заданной спецификации. В случае сбоя одного из экземпляров (это влечет за собой изменение состояние), Kubernetes обнаружит несоответствие между спецификацией и статусом и исправит его, т.е. активирует новый экземпляр вместо того, который вышел из строя.
|
||||
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ PodList — это список Pod. | Pod List — это список подо
|
|||
Можно | Нельзя
|
||||
:--| :-----
|
||||
_Кластер_ — это набор узлов ... | "Кластер" — это набор узлов ...
|
||||
Эти компоненты формируют _плоскость управления_. | Эти компоненты формируют **плоскость управления**.
|
||||
Эти компоненты формируют _управляющий слой_. | Эти компоненты формируют **управляющий слой**.
|
||||
{{< /table >}}
|
||||
|
||||
### Оформляйте как код имена файлов, директории и пути
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ tags:
|
|||
- architecture
|
||||
- operation
|
||||
---
|
||||
Компонент {{< glossary_tooltip text="панель управления" term_id="control-plane" >}} Kubernetes - это встраиваемый в логику управления облочная спецификация. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером.
|
||||
Компонент {{< glossary_tooltip text="управляющего слоя" term_id="control-plane" >}} Kubernetes, встраивающий специфику облака в логику управления. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером.
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
|
|
|||
|
|
@ -27,6 +27,6 @@ tags:
|
|||
Вы также можете найти Kubernetes в качестве управляемого сервиса; иногда его называют
|
||||
Платформа как Услуга (Platform as a Service) или PaaS. С упарвляемым Kubernetes
|
||||
ваш облачный провайдер отвечает за
|
||||
{{< glossary_tooltip term_id="control-plane" text="плоскость управления" >}} Kubernetes, а также за
|
||||
{{< glossary_tooltip term_id="control-plane" text="управляющий слой" >}} Kubernetes, а также за
|
||||
{{< glossary_tooltip term_id="node" text="узлы" >}} и инфраструктуру, на которую они полагаются:
|
||||
сеть, хранилище и, возможно, другие элементы, такие как балансировщики нагрузки.
|
||||
|
|
|
|||
|
|
@ -14,4 +14,4 @@ tags:
|
|||
Набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.
|
||||
|
||||
<!--more-->
|
||||
В рабочих узлах размещены поды, являющиеся компонентами приложения. Плоскость управления управляет рабочими узлами и подами в кластере. В промышленных средах плоскость управления обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
|
||||
В рабочих узлах размещены поды, являющиеся компонентами приложения. Управляющий слой (control plane) управляет рабочими узлами и подами в кластере. В промышленных средах управляющий слой обычно запускается на нескольких компьютерах, а кластер, как правило, развёртывается на нескольких узлах, гарантируя отказоустойчивость и высокую надёжность.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Плоскость управления (Control Plane)
|
||||
title: Управляющий слой (Control Plane)
|
||||
id: control-plane
|
||||
date: 2019-05-12
|
||||
full_link:
|
||||
|
|
|
|||
|
|
@ -14,4 +14,4 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется плоскостью управления. Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}.
|
||||
Рабочий узел может быть как виртуальной, так и физической машиной, в зависимости от кластера. У него есть локальные демоны или сервисы, необходимые для запуска {{< glossary_tooltip text="подов" term_id="pod" >}}, а сам он управляется управляющим слоем (control plane). Демоны на узле включают в себя {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} и среду выполнения контейнера, основанную на {{< glossary_tooltip text="CRI" term_id="cri" >}}, например {{< glossary_tooltip term_id="docker" >}}.
|
||||
|
|
|
|||
|
|
@ -137,7 +137,7 @@ description: |-
|
|||
<p><b><code>export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')</code></b><br />
|
||||
<b><code>echo Name of the Pod: $POD_NAME</code></b></p>
|
||||
<p>Теперь получим доступ к поду через проксированный API, выполнив команду:</p>
|
||||
<p><b><code>curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/</code></b></p>
|
||||
<p><b><code>curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/</code></b></p>
|
||||
<p>Чтобы новый деплоймент был доступен без использования прокси, потребуется сервис (объект Service), о котором будет рассказано в следующих разделах.</p>
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -369,6 +369,20 @@ mutating webhooks, also mutate admitted objects.
|
|||
的用户可以控制能读取任何允许进入集群的对象的 webhook，
|
||||
并且在有变更 webhook 的情况下，还可以变更准入的对象。
|
||||
|
||||
<!--
|
||||
### Namespace modification
|
||||
|
||||
Users who can perform **patch** operations on Namespace objects (through a namespaced RoleBinding to a Role with that access) can modify
|
||||
labels on that namespace. In clusters where Pod Security Admission is used, this may allow a user to configure the namespace
|
||||
for a more permissive policy than intended by the administrators.
|
||||
For clusters where NetworkPolicy is used, users may be set labels that indirectly allow
|
||||
access to services that an administrator did not intend to allow.
|
||||
-->
|
||||
### 命名空间修改 {#namespace-modification}
|
||||
可以对命名空间对象执行 **patch** 操作的用户（通过命名空间内的 RoleBinding 关联到具有该权限的 Role），
|
||||
可以修改该命名空间的标签。在使用 Pod 安全准入的集群中，这可能允许用户将命名空间配置为比管理员预期更宽松的策略。
|
||||
对于使用 NetworkPolicy 的集群，用户所设置的标签可能间接导致对某些本不应被允许访问的服务的访问权限被开放。
|
||||
|
||||
<!--
|
||||
## Kubernetes RBAC - denial of service risks {#denial-of-service-risks}
|
||||
|
||||
|
|
|
|||
|
|
@ -266,20 +266,14 @@ If scaling workloads isn't enough to meet your needs, you can also scale your cl
|
|||
|
||||
<!--
|
||||
Scaling the cluster infrastructure normally means adding or removing {{< glossary_tooltip text="nodes" term_id="node" >}}.
|
||||
This can be done using one of two available autoscalers:
|
||||
-->
|
||||
扩缩集群基础设施通常是指增加或移除{{< glossary_tooltip text="节点" term_id="node" >}}。
|
||||
这可以通过以下两种自动扩缩器中的任意一种实现：
|
||||
|
||||
- [**Cluster Autoscaler**](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)
|
||||
- [**Karpenter**](https://github.com/kubernetes-sigs/karpenter?tab=readme-ov-file)
|
||||
|
||||
<!--
|
||||
Both scalers work by watching for pods marked as _unschedulable_ or _underutilized_ nodes and then adding or
|
||||
removing nodes as needed.
|
||||
Read [cluster autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling/)
|
||||
for more information.
|
||||
-->
|
||||
这两种扩缩器的工作原理都是通过监测节点上被标记为 **unschedulable** 或 **underutilized** 的 Pod 数量，
|
||||
然后根据需要增加或移除节点。
|
||||
阅读[集群自动扩缩](/zh-cn/docs/concepts/cluster-administration/cluster-autoscaling/)了解更多信息。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
@ -289,9 +283,11 @@ removing nodes as needed.
|
|||
- [HorizontalPodAutoscaler Walkthrough](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
|
||||
- [Resize Container Resources In-Place](/docs/tasks/configure-pod-container/resize-container-resources/)
|
||||
- [Autoscale the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
|
||||
- Learn about [cluster autoscaling](/docs/concepts/cluster-administration/cluster-autoscaling/)
|
||||
-->
|
||||
- 了解有关横向扩缩的更多信息
|
||||
- [扩缩 StatefulSet](/zh-cn/docs/tasks/run-application/scale-stateful-set/)
|
||||
- [HorizontalPodAutoscaler 演练](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
|
||||
- [调整分配给容器的 CPU 和内存资源](/zh-cn/docs/tasks/configure-pod-container/resize-container-resources/)
|
||||
- [自动扩缩集群 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
|
||||
- 了解[集群自动扩缩]((/zh-cn/docs/concepts/cluster-administration/cluster-autoscaling/))
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: 容器（Container）
|
||||
id: container
|
||||
date: 2018-04-12
|
||||
full_link: /zh-cn/docs/concepts/overview/what-is-kubernetes/#why-containers
|
||||
full_link: /zh-cn/docs/concepts/containers/
|
||||
short_description: >
|
||||
容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。
|
||||
|
||||
|
|
|
|||
|
|
@ -70,10 +70,10 @@ When present, indicates that modifications should not be persisted. An invalid o
|
|||
## fieldManager {#fieldManager}
|
||||
|
||||
<!--
|
||||
fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://golang.org/pkg/unicode/#IsPrint.
|
||||
fieldManager is a name associated with the actor or entity that is making these changes. The value must be less than or 128 characters long, and only contain printable characters, as defined by https://pkg.go.dev/unicode#IsPrint
|
||||
-->
|
||||
fieldManager 是与进行这些更改的参与者或实体相关联的名称。
|
||||
长度小于或128个字符且仅包含可打印字符，如 https://golang.org/pkg/unicode/#IsPrint 所定义。
|
||||
长度小于或128个字符且仅包含可打印字符，如 https://pkg.go.dev/unicode#IsPrint 所定义。
|
||||
|
||||
<hr>
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,9 @@
|
|||
|
||||
# For "and", see [conjunction_1]
|
||||
|
||||
[api_reference_title]
|
||||
other = "API reference"
|
||||
|
||||
[auto_generated_edit_notice]
|
||||
other = "(auto-generated page)"
|
||||
|
||||
|
|
|
|||
|
|
@ -17,6 +17,8 @@
|
|||
{{ partial "docs/top-section-page" (dict "ctx" $ "page" $ ) }}
|
||||
{{- else -}}
|
||||
{{ partial "docs/content-page" (dict "ctx" $ "page" $ ) }}
|
||||
<!-- Partial "docs/api-reference-links" determines API reference links for 'partial/page-meta-links.html' -->
|
||||
{{ partial "docs/api-reference-links" $ }}
|
||||
{{- end -}}
|
||||
{{ else }}
|
||||
<h1>{{ .Title }}</h1>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
{{ define "main" }}
|
||||
<div class="td-content">
|
||||
{{ partial "docs/content-page" (dict "ctx" . "page" .) }}
|
||||
<!-- Partial "docs/api-reference-links" determines API reference links for 'partial/page-meta-links.html' -->
|
||||
{{ partial "docs/api-reference-links" . }}
|
||||
</div>
|
||||
{{ end }}
|
||||
{{ define "hero-more" }}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,58 @@
|
|||
<!-- Define slice to store API reference links -->
|
||||
{{- $apiReferenceMetaLinks := slice -}}
|
||||
{{- $apiReferenceText := T "api_reference_title" -}}
|
||||
|
||||
<!-- Clear exisiting $.Store values -->
|
||||
{{ $.Store.Delete "apiReferenceMetaLinks" }}
|
||||
{{ $.Store.Delete "pageApiReferenceLinksMap" }}
|
||||
|
||||
<!-- Check if 'api_metadata' is an empty interface slice
|
||||
(Used for excluding auto-generated files and their localized versions) -->
|
||||
{{- $ignoreCondition := (printf "%T" .Page.Params.api_metadata | eq "[]interface {}") -}}
|
||||
|
||||
<!-- Check if 'api-metadata' exists in the front-matter of the file -->
|
||||
{{- if and .Page.Params.api_metadata $ignoreCondition (not .Page.Params.simple_list) -}}
|
||||
|
||||
<!-- Loop through each api_metadata entry -->
|
||||
{{- range $metadata := .Page.Params.api_metadata -}}
|
||||
<!-- Extract API metadata -->
|
||||
{{- $apiVersion := $metadata.apiVersion -}}
|
||||
{{- $kind := $metadata.kind -}}
|
||||
{{- $version := $apiVersion -}}
|
||||
{{- $linkText := $metadata.override_link_text | default $kind -}}
|
||||
|
||||
<!-- Get all sections under the specified directory -->
|
||||
{{- $apiRefBaseDir := "docs/reference/kubernetes-api/" -}}
|
||||
{{- $apiRefSections := site.GetPage "section" $apiRefBaseDir -}}
|
||||
|
||||
<!-- Loop through sections -->
|
||||
{{- range $apiRefSection := $apiRefSections.Sections -}}
|
||||
{{- $apiRefDir := $apiRefSection.RelPermalink -}}
|
||||
{{- $apiReferenceFiles := site.GetPage $apiRefDir -}}
|
||||
|
||||
<!-- Loop through API reference files -->
|
||||
{{- range $apiRefFile := $apiReferenceFiles.RegularPages -}}
|
||||
{{- $apiRefFileDirPath:= printf "/%s" $apiRefFile.File.Dir -}}
|
||||
|
||||
{{- if and (ne $apiRefFile.Section "") (in $apiRefFileDirPath $apiRefDir) -}}
|
||||
<!-- Check if the file's metadata matches -->
|
||||
{{- with $apiRefFile.Params.api_metadata -}}
|
||||
{{- if and (eq .kind $kind) (eq .apiVersion $version) -}}
|
||||
<!-- If the file's metadata matches, add link to variable -->
|
||||
{{- $link := printf "<a class='api-reference-page-link' href='%s'>%s %s</a>" $apiRefFile.Permalink $linkText $apiReferenceText -}}
|
||||
{{- $apiReferenceMetaLinks = $apiReferenceMetaLinks | append $link -}}
|
||||
<!-- Add to the map -->
|
||||
{{- $.Store.SetInMap "pageApiReferenceLinksMap" $kind $link -}}
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
|
||||
{{- if gt (len $apiReferenceMetaLinks) 0 -}}
|
||||
<!-- Store $apiReferenceMetaLinks for meta links in 'partials/page-meta-links.html' -->
|
||||
{{ $.Store.Add "apiReferenceMetaLinks" $apiReferenceMetaLinks }}
|
||||
{{- end -}}
|
||||
|
||||
|
|
@ -23,6 +23,16 @@
|
|||
{{ $newPageQS := querify "value" $newPageStub.Content "filename" "change-me.md" | safeURL }}
|
||||
{{ $newPageURL := printf "%s/new/%s?%s" $gh_repo $gh_repo_path $newPageQS }}
|
||||
|
||||
<!-- Accessing API Reference links from "layouts/api-reference-links.html" -->
|
||||
{{- $apiReferenceMetaLinks := $.Store.Get "apiReferenceMetaLinks" -}}
|
||||
{{- if $apiReferenceMetaLinks -}}
|
||||
<!-- Loop through the API reference links -->
|
||||
{{- range $apiReferenceMetaLinks -}}
|
||||
{{- $apiRefPageLink := . -}}
|
||||
{{- $apiRefPageLink | replaceRE "<a([^>]*)>" "<a$1><i class=\"fa fa-code fa-fw\"></i> " | safeHTML -}}
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
|
||||
{{ if not (.Param "auto_generated") }}
|
||||
<a href="{{ $editURL }}" target="_blank"><i class="fa fa-edit fa-fw"></i> {{ T "post_edit_this" }}</a>
|
||||
{{- if .HasShortcode "thirdparty-content" -}}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,32 @@
|
|||
<!-- This shortcode shows API reference links based on metadata in the page's front matter -->
|
||||
|
||||
<!-- Call the partial template "docs/api-reference-links" to determine the API reference links -->
|
||||
{{ partial "docs/api-reference-links" page }}
|
||||
|
||||
<!-- "noop" (“no operation”) statement to let content render and store sync -->
|
||||
{{ $noop := .Page.Content }}
|
||||
|
||||
<!-- Getting the map from the page's store -->
|
||||
{{- $pageApiReferenceLinksMap := $.Page.Store.Get "pageApiReferenceLinksMap" -}}
|
||||
|
||||
<!-- Checking if "pageApiReferenceLinksMap" is not nil or empty -->
|
||||
{{- if and $pageApiReferenceLinksMap (ne (len $pageApiReferenceLinksMap) 0) -}}
|
||||
|
||||
<!-- Retrieving the "kind" parameter from the shortcode -->
|
||||
{{- $kindParam := .Get "kind" -}}
|
||||
|
||||
<!-- Checking if "kind" parameter is provided -->
|
||||
{{- if $kindParam -}}
|
||||
<!-- Accessing the specific API reference "kind" from the map -->
|
||||
{{ $apiRefPageLink := index $pageApiReferenceLinksMap $kindParam}}
|
||||
{{- printf "%s" $apiRefPageLink | safeHTML -}}
|
||||
|
||||
{{- else -}} <!-- If "kind" parameter is not provided -->
|
||||
<ul class="api-reference-links">
|
||||
{{- range $kind, $apiRefPageLink := $pageApiReferenceLinksMap -}}
|
||||
<li>{{- printf "%s" $apiRefPageLink | safeHTML -}}</li>
|
||||
{{- end -}}
|
||||
</ul>
|
||||
{{- end -}}
|
||||
|
||||
{{- end -}}
|
||||
Loading…
Reference in New Issue