The second element specifies that the value of the Pod's `annotations` field should be stored in a file named `annotations`. --> <del> 在配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器中的 `/etc` 目录。 </del> <ins> 在配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器中的 `/etc/podinfo` 目录。 </ins> 查看 `downwardAPI` 下面的 `items` 数组。 每个数组元素都是一个


在该 Shell中，查看 `labels` 文件： ```shell <del> /# cat /etc/labels </del> <ins> /# cat /etc/podinfo/labels </ins> ``` <!--


同样，查看`annotations`文件： ```shell <del> /# cat /etc/annotations </del> <ins> /# cat /etc/podinfo/annotations </ins> ``` <!--


lrwxrwxrwx  ... Feb 6 21:47 annotations -> ..data/annotations lrwxrwxrwx  ... Feb 6 21:47 labels -> ..data/labels <del> /etc/..2982_06_02_21_47_53.299460680: </del> <ins> /etc/podinfo/..2982_06_02_21_47_53.299460680: </ins> total 8 -rw-r--r--  ... Feb  6 21:47 annotations -rw-r--r--  ... Feb  6 21:47 labels


Create the Pod: --> <del> 在这个配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器的 `/etc/podinfo` 目录。 </del> <ins> 在这个配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器的 `/etc/podinfo` 目录。 </ins> 查看 `downwardAPI` 下面的 `items` 数组。每个数组元素都是一个 DownwardAPIVolumeFile。


在 Shell 中，查看 `cpu_limit` 文件： ```shell <del> /# cat /etc/cpu_limit </del> <ins> /# cat /etc/podinfo/cpu_limit </ins> ``` <!--


You can modify Node objects regardless of the setting of `--register-node`. For example, you can set labels on an existing Node, or mark it unschedulable. --> <del> #### 手动节点管理 </del> <ins> ### 手动节点管理 </ins> 你可以使用 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 来创建和修改 Node 对象。


| `MemoryPressure`    | `True` if pressure exists on the node memory - that is, if the node memory is low; otherwise `False` | | `PIDPressure`    | `True` if pressure exists on the processes - that is, if there are too many processes on the node; otherwise `False` | | `NetworkUnavailable`    | `True` if the network for the node is not correctly configured, otherwise `False` | <ins> {{< /table >}} </ins> --> {{< table caption = "节点状况及每种状况适用场景的描述" >}} | 节点状况       | 描述        |


| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` | | `PIDPressure` | `True` 表示节点存在进程压力，即节点上进程过多；否则为 `False` | | `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | <ins> {{< /table >}} </ins> <!-- If you use command-line tools to print details of a cordoned Node, the Condition includes


Kubernetes 节点发送的心跳（Heartbeats）有助于确定节点的可用性。 心跳有两种形式：`NodeStatus` 和 [`Lease` 对象] <del> (/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io)。 </del> <ins> (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。 </ins> 每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="名字空间">}} 中都有一个与之关联的 `Lease` 对象。 `Lease` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。


参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/) 了解详细信息。 <ins> <!-- ## Graceful Node Shutdown {#graceful-node-shutdown} --> ## 节点体面关闭 {#graceful-node-shutdown} {{< feature-state state="alpha" for_k8s_version="v1.20" >}} <!-- If you have enabled the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet attempts to detect the node system shutdown and terminates pods running on the node. Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown. --> 如果你启用了 `GracefulNodeShutdown` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， 那么 kubelet 尝试检测节点的系统关闭事件并终止在节点上运行的 Pod。 在节点终止期间，kubelet 保证 Pod 遵从常规的 [Pod 终止流程](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 <!-- When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown kubelet terminates pods in two phases: --> 当启用了 `GracefulNodeShutdown` 特性门控时， kubelet 使用 [systemd 抑制器锁](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) 在给定的期限内延迟节点关闭。在关闭过程中，kubelet 分两个阶段终止 Pod： <!-- 1. Terminate regular pods running on the node. 2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node. --> 1. 终止在节点上运行的常规 Pod。 2. 终止在节点上运行的[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 <!-- Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options: * `ShutdownGracePeriod`: * Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). * `ShutdownGracePeriodCriticalPods`: * Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This should be less than `ShutdownGracePeriod`. --> 节点体面关闭的特性对应两个 [`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项： * `ShutdownGracePeriod`： * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod 还是 [关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 * `ShutdownGracePeriodCriticalPods`： * 在节点关闭期间指定用于终止 [关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) 的持续时间。该值应小于 `ShutdownGracePeriod`。 <!-- For example, if `ShutdownGracePeriod=30s`, and `ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by 30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). --> 例如，如果设置了 `ShutdownGracePeriod=30s` 和 `ShutdownGracePeriodCriticalPods=10s`，则 kubelet 将延迟 30 秒关闭节点。 在关闭期间，将保留前 20（30 - 10）秒用于体面终止常规 Pod，而保留最后 10 秒用于终止 [关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 </ins> ## {{% heading "whatsnext" %}} <!--


<del> ### Exposed Persistent volumes {#Exposed Persistent volumes} </del> <ins> ### Exposed Persistent volumes {#Exposed-Persistent-volumes} </ins> - **persistentVolumeClaim** (PersistentVolumeClaimVolumeSource)


ExpirationSeconds is the requested duration of validity of the service account token. As the token approaches expiration, the kubelet volume plugin will proactively rotate the service account token. The kubelet will start trying to rotate the token if the token is older than 80 percent of its time to live or if the token is older than 24 hours.Defaults to 1 hour and must be at least 10 minutes. <del> ### Local / Temporary Directory {#Local / Temporary Directory} </del> <ins> ### Local / Temporary Directory {#Local-Temporary-Directory} </ins> - **emptyDir** (EmptyDirVolumeSource)


Type for HostPath Volume Defaults to "" More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath <del> ### Persistent volumes {#Persistent volumes} </del> <ins> ### Persistent volumes {#Persistent-volumes} </ins> - **awsElasticBlockStore** (AWSElasticBlockStoreVolumeSource)


Storage Policy Based Management (SPBM) profile name. <del> ### Beta level {#Beta level} </del> <ins> ### Beta level {#Beta-level} </ins> - **csi** (CSIVolumeSource)


VolumeAttributes stores driver-specific properties that are passed to the CSI driver. Consult your driver's documentation for supported values. <del> ### Alpha level {#Alpha level} </del> <ins> ### Alpha level {#Alpha-level} </ins> - **ephemeral** (EphemeralVolumeSource)


Container's working directory. If not specified, the container runtime's default will be used, which might be configured in the container image. Cannot be updated. <del> ### Environment variables {#Environment variables} </del> <ins> ### Environment variables {#Environment-variables} </ins> - **env** ([]EnvVar)


Whether this container should allocate a TTY for itself, also requires 'stdin' to be true. Default is false. <del> ### Not allowed {#Not allowed} </del> <ins> ### Not allowed {#Not-allowed} </ins> - **ports** ([]ContainerPort)


### MutatingAdmissionWebhook {#mutatingadmissionwebhook} <del> {{< feature-state for_k8s_version="v1.13" state="beta" >}} </del> This admission controller calls any mutating webhooks which match the request. Matching webhooks are called in serial; each one may modify the object if it desires.


webhooks or validating admission controllers will permit the request to finish. If you disable the MutatingAdmissionWebhook, you must also disable the <del> `MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1` </del> <ins> `MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1` </ins> group/version via the `--runtime-config` flag (both are on by default in versions >= 1.9).


different when read back. * Setting originally unset fields is less likely to cause problems than overwriting fields set in the original request. Avoid doing the latter. <del> * This is a beta feature. Future versions of Kubernetes may restrict the types of mutations these webhooks can make. </del> * Future changes to control loops for built-in resources or third-party resources may break webhooks that work well today. Even when the webhook installation API is finalized, not all possible webhook behaviors will be guaranteed to be supported


### ValidatingAdmissionWebhook {#validatingadmissionwebhook} <del> {{< feature-state for_k8s_version="v1.13" state="beta" >}} </del> This admission controller calls any validating webhooks which match the request. Matching webhooks are called in parallel; if any of them rejects the request, the request fails. This admission controller only runs in the validation phase; the webhooks it calls may not


webhooks or other validating admission controllers will permit the request to finish. If you disable the ValidatingAdmissionWebhook, you must also disable the <del> `ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1` </del> <ins> `ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1` </ins> group/version via the `--runtime-config` flag (both are on by default in versions 1.9 and later).


| ---------------------------------------- | ---------- | ------- | ----------- | | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | <del> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | | </del> <ins> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | DaemonSet pods tolerate disk-pressure attributes by default scheduler. | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | DaemonSet pods tolerate memory-pressure attributes by default scheduler. | </ins> | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet pods tolerate unschedulable attributes by default scheduler. | | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |


Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`: <ins> {% include code.html language="yaml" file="bad-nginx-deployment.yaml" ghlink="/docs/user-guide/bad-nginx-deployment.yaml" %} </ins> ```shell $ kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml deployment "nginx-deployment" configured


{{< note >}} While any plugin can access the list of "waiting" Pods and approve them <del> (see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit </del> <ins> (see [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)), we expect only the permit </ins> plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod is approved, it is sent to the [PreBind](#pre-bind) phase. {{< /note >}}


} ``` <del> If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](#accessing-the-api-from-within-a-pod). </del> <ins> If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod). </ins> #### Python client


* Пробуете или начинаете работу с Kubernetes * Локально разрабатываете и тестируете кластер <del> Выбрать [решение для запуска на локальной машине](/docs/setup/pick-right-solution/#local-machine-solutions). </del> <ins> Выбрать [решение для запуска на локальной машине](/docs/setup/learning-environment/). </ins> ## Управляемые решения


all: build ## Build site with production settings and put deliverables in ./public <del> build: module-check ## Build site with production settings and put deliverables in ./public hugo --minify </del> <ins> build: module-check ## Build site with non-production settings and put deliverables in ./public hugo --minify --environment development </ins> build-preview: module-check ## Build site with drafts and future posts enabled <del> hugo --buildDrafts --buildFuture </del> <ins> hugo --buildDrafts --buildFuture --environment preview </ins> deploy-preview: ## Deploy preview site via netlify <del> hugo --enableGitInfo --buildFuture -b $(DEPLOY_PRIME_URL) </del> <ins> hugo --enableGitInfo --buildFuture --environment preview -b $(DEPLOY_PRIME_URL) </ins> functions-build: $(NETLIFY_FUNC) build functions-src


check-headers-file: scripts/check-headers-file.sh <del> production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added </del> <ins> production-build: module-check ## Build the production site and ensure that noindex headers aren't added hugo --minify --environment production HUGO_ENV=production $(MAKE) check-headers-file </ins> <del> non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo </del> <ins> non-production-build: module-check ## Build the non-production site, which adds noindex headers to prevent indexing hugo --enableGitInfo --environment nonprod </ins> serve: module-check ## Boot the development server. <del> hugo server --buildFuture </del> <ins> hugo server --buildFuture --environment development </ins> docker-image: @echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"


--build-arg HUGO_VERSION=$(HUGO_VERSION) container-build: module-check <del> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" </del> <ins> $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development" </ins> container-serve: module-check ## Boot the development server using container. Run `make container-image` before this. <del> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </del> <ins> $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir </ins> test-examples: scripts/test_examples.sh install


$(MAKE) container-internal-linkcheck container-internal-linkcheck: link-checker-image-pull <del> $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture </del> <ins> $(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture --environment test </ins> $(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest clean-api-reference: ## Clean all directories in API reference directory, preserve _index.md


<!doctype html> <html lang="{{ .Site.Language.Lang }}" class="{{.Params.class}} no-js"> <del> <head> </del> <ins> {{- if eq hugo.Environment "preview" -}} <!-- deploy preview --> {{- end -}} <head {{- if hugo.IsProduction -}}class="live-site"{{- end -}}> </ins> {{ partial "head.html" . }} </head> <body class="td-{{ .Kind }}{{- if ne (lower .Params.cid) "" -}}{{- printf " cid-%s" (lower .Params.cid) -}}{{- end -}}">


<del> {{- if eq (getenv "HUGO_ENV") "production" }} </del> <ins> {{- if eq hugo.Environment "production" }} </ins> {{- $cssFilesFromConfig := site.Params.pushAssets.css -}} {{- $jsFilesFromConfig := site.Params.pushAssets.js -}} {{- $pages := site.RegularPages -}}


{{- $isBlogPost := eq .Section "blog" }} {{- $ogType := cond (.IsHome) "website" "article" }} <ins> <!-- per-page robot indexing controls --> {{- if hugo.IsProduction -}} <meta name="ROBOTS" content="INDEX, FOLLOW"> {{- else -}} <meta name="ROBOTS" content="NOINDEX, NOFOLLOW"> {{- end -}} </ins> <!-- Global site tag (gtag.js) - Google Analytics --> <script async src="https://www.googletagmanager.com/gtag/js?id=UA-36037335-10"></script> <script>


<meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> {{ hugo.Generator }} <del> {{ if eq (getenv "HUGO_ENV") "production" }} <META NAME="ROBOTS" CONTENT="INDEX, FOLLOW"> {{ else }} <META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW"> {{ end }} </del> {{ range .AlternativeOutputFormats -}} <link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" href="{{ .Permalink | safeURL }}"> {{ end -}}


{{- template "_internal/google_news.html" . -}} {{- template "_internal/schema.html" . -}} {{- template "_internal/twitter_cards.html" . -}} <del> {{ if eq (getenv "HUGO_ENV") "production" }} </del> <ins> {{- if hugo.IsProduction -}} </ins> {{ template "_internal/google_analytics_async.html" . }} {{ end }} {{ partialCached "head-css.html" . "asdf" }}


command = "git submodule update --init --recursive --depth 1 && make deploy-preview" [context.branch-deploy] <del> command = "git submodule update --init --recursive --depth 1 && make deploy-preview" </del> <ins> command = "git submodule update --init --recursive --depth 1 && make non-production-build" </ins> <del> [context.master] # This context is triggered by the `master` branch and allows search indexing </del> <ins> [context.main] # This context is triggered by the `main` branch and allows search indexing </ins> # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) publish = "public" command = "git submodule update --init --recursive --depth 1 && make production-build" <del> # adding in headers to prevent clickjacking [[headers]] for = "/*" [headers.values] X-Frame-Options = "DENY" X-XSS-Protection = "1; mode=block" </del>


### Migrating to the `systemd` driver in kubeadm managed clusters <del> Follow this [Migration guide](docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </del> <ins> Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </ins> if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters. ## Container runtimes


<ins> --- title: "Kubernetesオブジェクトの管理" description: Kubernetes APIと対話するための宣言型および命令型のパラダイム。 weight: 25 --- </ins>


<ins> --- title: CronJobを使用して自動化タスクを実行する min-kubernetes-server-version: v1.21 content_type: task weight: 10 --- <!-- overview --> CronJobは、Kubernetes v1.21で一般利用(GA)に昇格しました。古いバージョンのKubernetesを使用している場合、正確な情報を参照できるように、使用しているバージョンのKubernetesのドキュメントを参照してください。古いKubernetesのバージョンでは、`batch/v1` CronJob APIはサポートされていません。 {{< glossary_tooltip text="CronJob" term_id="cronjob" >}}を使用すると、{{< glossary_tooltip text="Job" term_id="job" >}}を時間ベースのスケジュールで実行できるようになります。この自動化されたJobは、LinuxまたはUNIXシステム上の[Cron](https://ja.wikipedia.org/wiki/Cron)のように実行されます。 CronJobは、バックアップやメールの送信など、定期的なタスクや繰り返しのタスクを作成する時に便利です。CronJobはそれぞれのタスクを、たとえばアクティビティが少ない期間など、特定の時間にスケジューリングすることもできます。 CronJobには制限と特性があります。たとえば、特定の状況下では、1つのCronJobが複数のJobを作成する可能性があるため、Jobは冪等性を持つようにしなければいけません。 制限に関する詳しい情報については、[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。 ## {{% heading "prerequisites" %}} * {{< include "task-tutorial-prereqs.md" >}} <!-- steps --> ## CronJobを作成する CronJobには設定ファイルが必要です。次の例のCronJobの`.spec`は、現在の時刻とhelloというメッセージを1分ごとに表示します。 {{< codenew file="application/job/cronjob.yaml" >}} 次のコマンドで例のCronJobを実行します。 ```shell kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml ``` 出力は次のようになります。 ``` cronjob.batch/hello created ``` CronJobを作成したら、次のコマンドで状態を取得します。 ```shell kubectl get cronjob hello ``` 出力は次のようになります。 ``` NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE hello   */1 * * * *   False     0        <none>          10s ``` コマンドの結果からわかるように、CronJobはまだスケジュールされておらず、まだ何のJobも実行していません。約1分以内にJobが作成されるのを見てみましょう。 ```shell kubectl get jobs --watch ``` 出力は次のようになります。 ``` NAME               COMPLETIONS   DURATION   AGE hello-4111706356   0/1                      0s hello-4111706356   0/1           0s         0s hello-4111706356   1/1           5s         5s ``` "hello"CronJobによってスケジュールされたJobが1つ実行中になっていることがわかります。Jobを見るのをやめて、再度CronJobを表示して、Jobがスケジュールされたことを確認してみます。 ```shell kubectl get cronjob hello ``` 出力は次のようになります。 ``` NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE hello   */1 * * * *   False     0        50s             75s ``` CronJob`hello`が、`LAST SCHEDULE`で指定された時間にJobを正しくスケジュールしたことが確認できるはずです。現在、activeなJobの数は0です。つまり、Jobは完了または失敗したことがわかります。 それでは、最後にスケジュールされたJobの作成と、Podの1つの標準出力を表示してみましょう。 {{< note >}} Jobの名前とPodの名前は異なります。 {{< /note >}} ```shell # "hello-4111706356" の部分は、あなたのシステム上のJobの名前に置き換えてください。 pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name}) ``` Podのログを表示します。 ```shell kubectl logs $pods ``` 出力は次のようになります。 ``` Fri Feb 22 11:02:09 UTC 2019 Hello from the Kubernetes cluster ``` ## CronJobの削除 CronJobが必要なくなったときは、`kubectl delete cronjob <cronjob name>`で削除します。 ```shell kubectl delete cronjob hello ``` CronJobを削除すると、すべてのJobと、そのJobが作成したPodが削除され、追加のJobの作成が停止されます。Jobの削除について詳しく知りたい場合は、[ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)を読んでください。 ## CronJobのspecを書く {#writing-a-cron-job-spec} すべてのKubernetesの設定と同じように、CronJobにも`apiVersion`、`kind`、`metadata`のフィールドが必要です。設定ファイルの扱い方についての一般的な情報については、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)と[kubectlを使用してリソースを管理する](/ja/docs/concepts/overview/working-with-objects/object-management/)を読んでください。 CronJobの設定には、[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 {{< note >}} CronJobの特に`spec`へのすべての修正は、それ以降の実行にのみ適用されます。 {{< /note >}} ### Schedule `.spec.schedule`は、`.spec`には必須のフィールドです。`0 * * * *`や`@hourly`などの[Cron](https://ja.wikipedia.org/wiki/Cron)形式の文字列を取り、Jobの作成と実行のスケジュール時間を指定します。 フォーマットにはVixie cronのステップ値(step value)も指定できます。[FreeBSDのマニュアル](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)では次のように説明されています。 > ステップ値は範囲指定と組み合わせて使用できます。範囲の後ろに`/<number>`を付けると、範囲全体で指定したnumberの値ごとにスキップすることを意味します。たとえば、`0-23/2`をhoursフィールドに指定すると、2時間毎にコマンド実行を指定することになります(V7標準では代わりに`0,2,4,6,8,10,12,14,16,18,20,22`と指定する必要があります)。ステップはアスタリスクの後ろにつけることもできます。そのため、「2時間毎に実行」したい場合は、単純に`*/2`と指定できます。 {{< note >}} スケジュール内の疑問符`?`はアスタリスク`*`と同じ意味を持ちます。つまり、与えられたフィールドには任意の値が使えるという意味になります。 {{< /note >}} ### Job Template `.spec.jobTemplate`はJobのテンプレートであり、必須です。[Job](/docs/concepts/workloads/controllers/job/)と完全に同一のスキーマを持ちますが、フィールドがネストされている点と、`apiVersion`と`kind`が存在しない点だけが異なります。Jobの`.spec`を書くための情報については、[JobのSpecを書く](/docs/concepts/workloads/controllers/job/#writing-a-job-spec)を参照してください。 ### Starting Deadline `.spec.startingDeadlineSeconds`フィールドはオプションです。何かの理由でスケジュールに間に合わなかった場合に適用される、Jobの開始のデッドライン(締め切り)を秒数で指定します。デッドラインを過ぎると、CronJobはJobを開始しません。この場合にデッドラインに間に合わなかったJobは、失敗したJobとしてカウントされます。もしこのフィールドが指定されなかった場合、Jobはデッドラインを持ちません。 `.spec.startingDeadlineSeconds`フィールドがnull以外に設定された場合、CronJobコントローラーはJobの作成が期待される時間と現在時刻との間の時間を計測します。もしその差が制限よりも大きかった場合、その実行はスキップされます。 たとえば、この値が`200`に設定された場合、実際のスケジュールの最大200秒後までに作成されるJobだけが許可されます。 ### Concurrency Policy `.spec.concurrencyPolicy`フィールドもオプションです。このフィールドは、このCronJobで作成されたJobの並列実行をどのように扱うかを指定します。specには以下のconcurrency policyのいずれかを指定します。 * `Allow` (デフォルト): CronJobがJobを並列に実行することを許可します。 * `Forbid`: CronJobの並列実行を禁止します。もし新しいJobの実行時に過去のJobがまだ完了していなかった場合、CronJobは新しいJobの実行をスキップします。 * `Replace`: もし新しいJobの実行の時間になっても過去のJobの実行が完了していなかった場合、CronJobは現在の実行中のJobを新しいJobで置換します。 concurrency policyは、同じCronJobが作成したJobにのみ適用されます。もし複数のCronJobがある場合、それぞれのJobの並列実行は常に許可されます。 ### Suspend `.spec.suspend`フィールドもオプションです。このフィールドを`true`に設定すると、すべての後続の実行がサスペンド(一時停止)されます。この設定はすでに実行開始したJobには適用されません。デフォルトはfalseです。 {{< caution >}} スケジュールされた時間中にサスペンドされた実行は、見逃されたJob(missed job)としてカウントされます。[starting deadline](#starting-deadline)が設定されていない既存のCronJob`.spec.suspend`が`true`から`false`に変更されると、見逃されたJobは即座にスケジュールされます。 {{< /caution >}} ### Job History Limit `.spec.successfulJobsHistoryLimit`と`.spec.failedJobsHistoryLimit`フィールドはオプションです。これらのフィールドには、完了したJobと失敗したJobをいくつ保持するかを指定します。デフォルトでは、それぞれ3と1に設定されます。リミットを`0`に設定すると、対応する種類のJobを実行完了後に何も保持しなくなります。 </ins>


<ins> --- title: approverとreviewer向けのレビュー linktitle: approverとreviewer向け slug: for-approvers content_type: concept weight: 20 --- <!-- overview --> SIG Docsの[Reviewer(レビュアー)](/docs/contribute/participate/#reviewers)と[Approver(承認者)](/docs/contribute/participate/#approvers)は、変更をレビューする時にいくつか追加の作業を行います。 毎週、docsのメンバーの特定のapproverのボランティアは、pull requestのトリアージとレビューを担当します。この担当者は、その週の「PR Wrangler(PRの世話人)」と呼ばれます。詳しい情報は、[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)を参照してください。PR Wranglerになるには、週次のSIG Docsミーティングに参加し、ボランティアをします。もしその週にスケジュールされていなくても、活発なレビューが行われていないpull request(PR)をレビューすることは問題ありません。 このローテーションに加えて、変更されたファイルのオーナーに基づいて、botがPRにreviewerとapproverを割り当てます。 <!-- body --> ## PRをレビューする Kubernetesのドキュメントは[Kubernetesコードレビュープロセス](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)に従います。 [pull requestのレビュー](/ja/docs/contribute/review/reviewing-prs/)に書かれているすべてのことが適用されますが、ReviewerとApproverはそれに加えて次のことも行います。 - 必要に応じて、`/assign`Prowコマンドを使用して、特定のreviewerにPRを割り当てる。これは、コードのコントリビューターからの技術的なレビューが必要な場合には特に重要です。 {{< note >}} 技術的なレビューを行える人物を知るには、Markdownファイル上部にあるfront-matterの`reviewers`フィールドを確認してください。 {{< /note >}} - PRが[コンテンツ](/ja/docs/contribute/style/content-guide/)および[スタイル](/docs/contribute/style/style-guide/)のガイドに従っていることを確認してください。ガイドに従っていない場合は、ガイドの関連する部分にリンクを作者に示してください。 - PRの作者に変更を提案できるときは、GitHubの**Request Changes**(変更をリクエスト)オプションを利用してください。 - 提案したことが反映されたら、`/approve`や`/lgtm`コマンドを使用して、GitHubのレビューステータスを変更してください。 ## 他の作者のPRにコミットを追加する PRにコメントを残すのは助けになりますが、まれに他の作者のPRに代わりにコミットを追加する必要がある場合があります。 あなたが明示的に作者から頼まれたり、長い間放置されたPRを蘇らせるような場合でない限り、他の作者のPRを「乗っ取る」ようなことはしないでください。短期的に見ればそのほうが短時間で終わるかもしれませんが、そのようなことをするとその人が貢献するチャンスを奪ってしまうことになります。 あなたが取る方法は、編集する必要のあるファイルがすでにPRのスコープに入っているか、あるいはPRがまだ触れていないファイルであるかによって変わります。 以下のいずれかが当てはまる場合、他の作者のPRにあなたがコミットを追加することはできません。 - PRの作者が自分のブランチを直接[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)リポジトリにpushした場合。この場合、pushアクセス権限を持つreviewerしか他のユーザーのPRにコミットを追加することはできません。 {{< note >}} 次回PRを作成するとき、自分のブランチを自分のforkに対してpushするように作者に促してください。 {{< /note >}} - PRの作者が明示的にapproverからの編集を禁止している場合。 ## レビュー向けのProwコマンド [Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)は、pull request(PR)に対してジョブを実行するKubernetesベースのCI/CDシステムです。Prowは、Kubernetes organization全体でchatbotスタイルのコマンドを利用してGitHub actionsを扱えるようにします。たとえば、[ラベルの追加と削除](#adding-and-removing-issue-labels)、issueのclose、approverの割り当てなどが行なえます。Prowコマンドは、GitHubのコメントに`/<command-name>`という形式で入力します。 reviewerとapproverが最もよく使うprowコマンドには、以下のようなものがあります。 {{< table caption="Prow commands for reviewing" >}} Prowコマンド | Roleの制限 | 説明 :------------|:------------------|:----------- `/lgtm` | 誰でも。ただし、オートメーションがトリガされるのはReviewerまたはApproverが使用したときのみ。 | PRのレビューが完了し、変更に納得したことを知らせる。 `/approve` | Approver | PRをマージすることを承認する。 `/assign` | ReviewerまたはApprover | PRのレビューまたは承認するひとを割り当てる。 `/close` | ReviewerまたはApprover | issueまたはPRをクローンする。 `/hold` | 誰でも | `do-not-merge/hold`ラベルを追加して、自動的にマージできないPRであることを示す。 `/hold cancel` | 誰でも | `do-not-merge/hold`ラベルを削除する。 {{< /table >}} PRで利用できるすべてのコマンド一覧を確認するには、[Prowコマンドリファレンス](https://prow.k8s.io/command-help)を参照してください。 ## issueのトリアージとカテゴリー分類 一般に、SIG Docsは[Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md)のプロセスに従い、同じラベルを使用しています。 このGitHub issueの[フィルター](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)は、トリアージが必要な可能性があるissueを表示します。 ### issueをトリアージする 1. issueを検証する - issueがドキュメントのウェブサイトに関係するものであることを確かめる。質問に答えたりリソースの場所を報告者に教えることですぐに閉じられるissueもあります。詳しくは、[サポートリクエストまたはコードのバグレポート](#support-requests-or-code-bug-reports)のセクションを読んでください。 - issueにメリットがあるかどうか評価する。 - issueに行動を取るのに十分な詳細情報がない場合や、テンプレートが十分埋められていない場合は、`triage/needs-information`ラベルを追加する。 - `lifecycle/stale`と`triage/needs-information`の両方のラベルがあるときは、issueをcloseする。 2. 優先度(priority)ラベルを追加する([issueトリアージガイドライン](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)は、priorityラベルについて詳しく定義しています。) {{< table caption="issueのラベル" >}} ラベル | 説明 :------------|:------------------ `priority/critical-urgent` | 今すぐに作業する。 `priority/important-soon` | 3ヶ月以内に取り組む。 `priority/important-longterm` | 6ヶ月以内に取り組む。 `priority/backlog` | 無期限に延期可能。リソースに余裕がある時に取り組む。 `priority/awaiting-more-evidence` | よいissueの可能性があるissueを見失わないようにするためのプレースホルダー。 `help`または`good first issue` | KubernetesまたはSIG Docsでほとんど経験がない人に適したissue。より詳しい情報は、[Help WantedとGood First Issueラベル](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)を読んでください。 {{< /table >}} あなたの裁量で、issueのオーナーシップを取り、issueに対するPRを提出してください(簡単なissueや、自分がすでに行った作業に関連するissueである場合は特に)。 issueのトリアージについて質問があるときは、Slackの`#sig-docs`か[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)で質問してください。 ## issueラベルの追加と削除 {#adding-and-removing-issue-labels} ラベルを追加するには、以下のいずれかの形式でコメントします。 - `/<label-to-add>`(たとえば、`/good-first-issue`) - `/<label-category> <label-to-add>`(たとえば、`/triage needs-information`や`/language ja`) ラベルを削除するには、以下のいずれかの形式でコメントします。 - `/remove-<label-to-remove>`(たとえば、`/remove-help`) - `/remove-<label-category> <label-to-remove>`(たとえば、`/remove-triage needs-information`) いずれの場合でも、ラベルは既存のものでなければなりません。存在しないラベルを追加しようとした場合、コマンドは無視されます。 すべてのラベル一覧は、[websiteリポジトリーのラベルセクション](https://github.com/kubernetes/website/labels)で確認できます。SIG Docsですべてのラベルが使われているわけではありません。 ### issueのライフサイクルに関するラベル issueは一般にopen後に短期間でcloseされます。しかし、issueがopenされた後にアクティブでなくなったり、issueが90日以上openのままである場合もあります。 {{< table caption="issueのライブラリに関するラベル" >}} ラベル | 説明 :------------|:------------------ `lifecycle/stale` | 90日間活動がない場合、issueは自動的にstaleとラベル付けされます。`/remove-lifecycle stale`コマンドを使って手動でlifecycleをリバートしない限り、issueは自動的にcloseされます。 `lifecycle/frozen` | このラベルが付けられたissueは、90日間活動がなくてもstaleになりません。`priority/important-longterm`ラベルを付けたissueなど、90日以上openにしておく必要があるissueには、このラベルを手動で追加します。 {{< /table >}} ## 特別な種類のissueに対処する SIG Docsでは、対処方法をドキュメントに書いても良いくらい頻繁に、以下のような種類のissueに出会います。 ### 重服したissue 1つの問題に対して1つ以上のissueがopenしている場合、1つのissueに統合します。あなたはどちらのissueをopenにしておくか(あるいは新しいissueを作成するか)を決断して、すべての関連する情報を移動し、関連するすべてのissueにリンクしなければなりません。最後に、同じ問題について書かれたすべての他のissueに`triage/duplicate`ラベルを付けて、それらをcloseします。作業対象のissueを1つだけにすることで、混乱を晒し、同じ問題に対して作業が重複することを避けられます。 ### リンク切れに関するissue リンク切れのissueがAPIまたは`kubectl`のドキュメントにあるものは、問題が完全に理解されるまでは`/priority critical-urgent`を割り当ててください。その他のすべてのリンク切れに関するissueには、手動で修正が必要であるため、`/priority important-longterm`を付けます。 ### Blogに関するissue [Kubernetes Blog](https://kubernetes.io/blog/)のエントリーは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリーは1年以内のものだけをメンテナンスします。1年以上前のブログエントリーに関するissueは修正せずにcloseします。 ### サポートリクエストまたはコードのバグレポート {#support-requests-or-code-bug-reports} 一部のドキュメントのissueは、実際には元になっているコードの問題や、何か(たとえば、チュートリアル)がうまく動かないときにサポートをリクエストするものです。ドキュメントに関係のない問題は、`kind/support`ラベルを付け、サポートチャンネル(SlackやStack Overflowなど)へ報告者を導くコメントをして、もし関連があれば機能のバグに対するissueを報告するリポジトリ(`kubernetes/kubernetes`は始めるのに最適な場所です)を教えて、closeします。 サポートリクエストに対する返答の例を示します。(リクエストを行う際は英語で行うことが想定されるため、英文とその日本語訳を記載しています) ```none This issue sounds more like a request for support and less like an issue specifically for docs. I encourage you to bring your question to the `#kubernetes-users` channel in [Kubernetes slack](https://slack.k8s.io/). You can also search resources like [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) for answers to similar questions. You can also open issues for Kubernetes functionality in https://github.com/kubernetes/kubernetes. If this is a documentation issue, please re-open this issue. ``` ```none このissueは特定のドキュメントに関するissueではなく、サポートリクエストのようです。 Kubernetesに関する質問については、[Kubernetes slack](https://slack.k8s.io/)の `#kubernetes-users`チャンネルに投稿することをおすすめします。同様の質問に対する回答を [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)などの リソースで検索することもできます。 Kubernetesの機能に関するissueについては、https://github.com/kubernetes/kubernetes でissueを作成できます。 もしこれがドキュメントに関するissueの場合、このissueを再びopenしてください。 ``` コードのバグに対する返答の例を示します。 ```none This sounds more like an issue with the code than an issue with the documentation. Please open an issue at https://github.com/kubernetes/kubernetes/issues. If this is a documentation issue, please re-open this issue. ``` ```none こちらのissueは、ドキュメントではなくコードに関係するissueのようです。 https://github.com/kubernetes/kubernetes/issues でissueを作成してください。 もしこれがドキュメントに関するissueの場合、このissueを再びopenしてください。 ``` </ins>


kubernetesVersion: v1.16.0 scheduler: extraArgs: <del> bind-address: 0.0.0.0 config: /home/johndoe/schedconfig.yaml kubeconfig: /home/johndoe/kubeconfig.yaml </del> <ins> config: /etc/kubernetes/scheduler-config.yaml extraVolumes: - name: schedulerconfig hostPath: /home/johndoe/schedconfig.yaml mountPath: /etc/kubernetes/scheduler-config.yaml readOnly: true pathType: "File" </ins> ```


<ins> --- title: システムログ content_type: concept weight: 60 --- <!-- overview --> システムコンポーネントのログは、クラスター内で起こったイベントを記録します。このログはデバッグのために非常に役立ちます。ログのverbosityを設定すると、ログをどの程度詳細に見るのかを変更できます。ログはコンポーネント内のエラーを表示する程度の荒い粒度にすることも、イベントのステップバイステップのトレース(HTTPのアクセスログ、Podの状態の変更、コントローラーの動作、スケジューラーの決定など)を表示するような細かい粒度に設定することもできます。 <!-- body --> ## klog klogは、Kubernetesのログライブラリです。[klog](https://github.com/kubernetes/klog)は、Kubernetesのシステムコンポーネント向けのログメッセージを生成します。 klogの設定に関する詳しい情報については、[コマンドラインツールのリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 klogネイティブ形式の例: ``` I1025 00:15:15.525108       1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] ``` ### 構造化ログ {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< warning >}} 構造化ログへのマイグレーションは現在進行中の作業です。このバージョンでは、すべてのログメッセージが構造化されているわけではありません。ログファイルをパースする場合、JSONではないログの行にも対処しなければなりません。 ログの形式と値のシリアライズは変更される可能性があります。 {{< /warning>}} 構造化ログは、ログメッセージに単一の構造を導入し、プログラムで情報の抽出ができるようにするものです。構造化ログは、僅かな労力とコストで保存・処理できます。新しいメッセージ形式は後方互換性があり、デフォルトで有効化されます。 構造化ログの形式: ```ini <klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ... ``` 例: ```ini I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" ``` ### JSONログ形式 {{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{<warning >}} JSONの出力は多数の標準のklogフラグをサポートしていません。非対応のklogフラグの一覧については、[コマンドラインツールリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 すべてのログがJSON形式で書き込むことに対応しているわけではありません(たとえば、プロセスの開始時など)。ログのパースを行おうとしている場合、JSONではないログの行に対処できるようにしてください。 フィールド名とJSONのシリアライズは変更される可能性があります。 {{< /warning >}} `--logging-format=json`フラグは、ログの形式をネイティブ形式klogからJSON形式に変更します。以下は、JSONログ形式の例(pretty printしたもの)です。 ```json { "ts": 1580306777.04728, "v": 4, "msg": "Pod status updated", "pod":{ "name": "nginx-1", "namespace": "default" }, "status": "ready" } ``` 特別な意味を持つキー: * `ts` - Unix時間のタイムスタンプ(必須、float) * `v` - verbosity (必須、int、デフォルトは0) * `err` - エラー文字列 (オプション、string) * `msg` - メッセージ (必須、string) 現在サポートされているJSONフォーマットの一覧: * {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} * {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} ### ログのサニタイズ {{< feature-state for_k8s_version="v1.20" state="alpha" >}} {{<warning >}} ログのサニタイズ大きな計算のオーバーヘッドを引き起こす可能性があるため、本番環境では有効にするべきではありません。 {{< /warning >}} `--experimental-logging-sanitization`フラグはklogのサニタイズフィルタを有効にします。有効にすると、すべてのログの引数が機密データ(パスワード、キー、トークンなど)としてタグ付けされたフィールドについて検査され、これらのフィールドのログの記録は防止されます。 現在ログのサニタイズをサポートしているコンポーネント一覧: * kube-controller-manager * kube-apiserver * kube-scheduler * kubelet {{< note >}} ログのサニタイズフィルターは、ユーザーのワークロードのログが機密データを漏洩するのを防げるわけではありません。 {{< /note >}} ### ログのverbosityレベル `-v`フラグはログのverbosityを制御します。値を増やすとログに記録されるイベントの数が増えます。値を減らすとログに記録されるイベントの数が減ります。verbosityの設定を増やすと、ますます多くの深刻度の低いイベントをログに記録するようになります。verbosityの設定を0にすると、クリティカルなイベントだけをログに記録します。 ### ログの場所 システムコンポーネントには2種類あります。コンテナ内で実行されるコンポーネントと、コンテナ内で実行されないコンポーネントです。たとえば、次のようなコンポーネントがあります。 * Kubernetesのスケジューラーやkube-proxyはコンテナ内で実行されます。 * kubeletやDockerのようなコンテナランタイムはコンテナ内で実行されません。 systemdを使用しているマシンでは、kubeletとコンテナランタイムはjournaldに書き込みを行います。それ以外のマシンでは、`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナ内部のシステムコンポーネントは、デフォルトのログ機構をバイパスするため、常に`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナのログと同様に、`/var/log`ディレクトリ内のシステムコンポーネントのログはローテートする必要があります。`kube-up.sh`スクリプトによって作成されたKubernetesクラスターでは、ログローテーションは`logrotate`ツールで設定されます。`logrotate`ツールはログを1日ごとまたはログのサイズが100MBを超えたときにローテートします。 ## {{% heading "whatsnext" %}} * [Kubernetesのログのアーキテクチャ](/docs/concepts/cluster-administration/logging/)について読む。 * [構造化ログ](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)について読む。 * [ログの深刻度の慣習](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)について読む。 </ins>


--- title: Service Accounts description: > <del> Learn about the Kubernetes ServiceAccount object. </del> <ins> Learn about ServiceAccount objects in Kubernetes. </ins> content_type: concept weight: 10 ---


the configurations portable. Service accounts are different from user accounts, which are authenticated <del> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </del> <ins> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </ins> data. You can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom extension APIs to represent user accounts in the API server.


object named `default` for every namespace in your cluster. The `default` service accounts in each namespace get no permissions by default other than the [default API discovery permissions](/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) <del> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{<glossary_tooltip text="control plane" term_id="control-plane">}} </del> <ins> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} </ins> replaces it with a new one. If you deploy a Pod in a namespace, and you don't


following methods: * [TokenRequest API](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) <del> (recommended): Request a short-lived service account token using your *application code*. The token expires automatically and can rotate upon expiration. </del> <ins> (recommended): Request a short-lived service account token from within your own *application code*. The token expires automatically and can rotate upon expiration. If you have a legacy application that is not aware of Kubernetes, you could use a sidecar container within the same pod to fetch these tokens and make them available to the application workload. </ins> * [Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) <del> (recommended): In Kubernetes v1.20 and later, use the Pod specification to </del> <ins> (also recommended): In Kubernetes v1.20 and later, use the Pod specification to </ins> tell the kubelet to add the service account token to the Pod as a *projected volume*. Projected tokens expire automatically, and the kubelet rotates the token before it expires.


with static, long-lived credentials. In Kubernetes v1.24 and later, the [LegacyServiceAccountTokenNoAutoGeneration feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) prevents Kubernetes from automatically creating these tokens for <del> ServiceAccounts. </del> <ins> ServiceAccounts. `LegacyServiceAccountTokenNoAutoGeneration` is enabled by default; in other words, Kubernetes does not create these tokens. </ins> ## Authenticating service account credentials {#authenticating-credentials}


trust relationship exists. Depending on how the token was issued (either time-limited using a `TokenRequest` or using a legacy mechanism with a Secret), a ServiceAccount token might also have an expiry time, an audience, <del> and a time after which the token *starts* being valid. When a process running in a Pod attempts to communicate with the Kubernetes API server, it adds an `Authorization: Bearer <token>` header to the HTTP request. The API server checks the validity of the bearer token as follows: </del> <ins> and a time after which the token *starts* being valid. When a client that is acting as a ServiceAccount tries to communicate with the Kubernetes API server, the client includes an `Authorization: Bearer <token>` header with the HTTP request. The API server checks the validity of that bearer token as follows: </ins> 1. Check the token signature. 1. Check whether the token has expired. <del> 1. Checks whether object references in the token claims are currently valid </del> <ins> 1. Check whether object references in the token claims are currently valid. </ins> 1. Check whether the token is currently valid. 1. Check the audience claims. <ins> The TokenRequest API produces _bound tokens_ for a ServiceAccount. This binding is linked to the lifetime of the client, such as a Pod, that is acting as that ServiceAccount. </ins> For tokens issued using the `TokenRequest` API, the API server also checks that the specific object reference that is using the ServiceAccount still exists, matching by the {{< glossary_tooltip term_id="uid" text="unique ID" >}} of that


For more information about the authentication process, refer to [Authentication](/docs/reference/access-authn-authz/authentication/#service-account-tokens). <del> ### Authenticating service account credentials in your own code {authenticating-in-code} </del> <ins> ### Authenticating service account credentials in your own code {#authenticating-in-code} </ins> If you have services of your own that need to validate Kubernetes service account credentials, you can use the following methods:


The Kubernetes project recommends that you use the TokenReview API, because this method invalidates tokens that are bound to API objects such as Secrets, ServiceAccounts, and Pods when those objects are deleted. For example, if you <del> delete the Pod that contains a projected ServiceAccount token, the TokenReview API invalidates that token immediately. If you use OIDC validation instead, your clients continue to treat the token as valid until the token reaches its expiration timestamp. </del> <ins> delete the Pod that contains a projected ServiceAccount token, the cluster invalidates that token immediately and a TokenReview immediately fails. If you use OIDC validation instead, your clients continue to treat the token as valid until the token reaches its expiration timestamp. </ins> Your application should always define the audience that it accepts, and should check that the token's audiences match the audiences that the application expects. This helps to minimize the scope of the token so that it can only be <del> used in your appplication and nowhere else. </del> <ins> used in your application and nowhere else. </ins> ## Alternatives


{{% tab name="Linux" %}} <!-- <del> 1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at [Install Docker Engine](https://docs.docker.com/engine/install/#server). </del> <ins> 1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at [Install Docker Engine](https://docs.docker.com/engine/install/#server). </ins> --> 1. 从官方Docker仓库安装 `containerd.io` 软件包。可以在 [安装 Docker 引擎](https://docs.docker.com/engine/install/#server)


{{% tab name="Windows (PowerShell)" %}} <!-- <del> Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands: </del> <ins> Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands: </ins> --> <del> 启动 Powershell 会话，将 `$Version` 设置为所需的版本（例如：`$ Version=1.4.3`）， </del> <ins> 启动 Powershell 会话，将 `$Version` 设置为所需的版本（例如：`$Version=1.4.3`）， </ins> 然后运行以下命令： <!--


{{% tab name="Ubuntu" %}} <!-- <del> To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: </del> <ins> To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: </ins> | Operating system | `$OS`             | | ---------------- | ----------------- |


{{% tab name="CentOS" %}} <!-- <del> To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: </del> <ins> To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: </ins> | Operating system | `$OS`             | | ---------------- | ----------------- |


```shell sudo systemctl daemon-reload <del> sudo systemctl enable crio --no </del> <ins> sudo systemctl enable crio --now </ins> ``` <!--


### Docker <!-- <del> 1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file. </del> <ins> 1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file. </ins> --> 1. 在每个节点上，根据[安装 Docker 引擎](https://docs.docker.com/engine/install/#server) 为你的 Linux 发行版安装 Docker。


{{< note >}} <!-- <del> `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. </del> <ins> `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. </ins> --> 对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL 或 CentOS 的系统，`overlay2`是首选的存储驱动程序。


| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | | | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | 1.20 | | `BoundServiceAccountTokenVolume` | `true` | Beta | 1.21 | | <ins> | `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | | </ins> | `CPUManager` | `false` | Alpha | 1.8 | 1.9 | | `CPUManager` | `true` | Beta | 1.10 | | | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |


extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`. Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md) for more details. <ins> - `ControllerManagerLeaderMigration`: Enables Leader Migration for [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration) and [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager) which allows a cluster operator to live migrate controllers from the kube-controller-manager into an external controller-manager (e.g. the cloud-controller-manager) in an HA cluster without downtime. </ins> - `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/). - `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime. The default max size of a log file is 10MB and the


title: Create a Cluster weight: 10 --- <ins> Learn about Kubernetes {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}} and create a simple cluster using Minikube. </ins>


No resources found in default namespace. ``` <del> To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=false option for `kubectl delete` to delete an object and orphan its children. </del> <ins> To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=orphan option for `kubectl delete` to delete an object and orphan its children. </ins> <del> In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=false, the parent is deleted but the child still exists: </del> <ins> In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=orphan, the parent is deleted but the child still exists: </ins> ``` kubectl get configmap


mymap-child    0      13m8s mymap-parent   0      13m8s <del> kubectl delete --cascade=false configmap/mymap-parent </del> <ins> kubectl delete --cascade=orphan configmap/mymap-parent </ins> configmap "mymap-parent" deleted kubectl get configmap


fields to be updated.  Also, the DaemonSet controller will use the original template the next time a node (even with the same name) is created. <del> You can delete a DaemonSet.  If you specify `--cascade=false` with `kubectl`, then the Pods </del> <ins> You can delete a DaemonSet.  If you specify `--cascade=orphan` with `kubectl`, then the Pods </ins> will be left on the nodes.  If you subsequently create a new DaemonSet with the same selector, the new DaemonSet adopts the existing Pods. If any Pods need replacing the DaemonSet replaces them according to its `updateStrategy`.


to use a different pod template and for the Job to have a new name. You cannot update the Job because these fields are not updatable. Therefore, you delete Job `old` but _leave its pods <del> running_, using `kubectl delete jobs/old --cascade=false`. </del> <ins> running_, using `kubectl delete jobs/old --cascade=orphan`. </ins> Before deleting it, you make a note of what selector it uses: ```shell


You can delete a ReplicationController without affecting any of its pods. <del> Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). </del> <ins> Using kubectl, specify the `--cascade=orphan` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). </ins> When using the REST API or Go client library, you can delete the ReplicationController object.


Run the following command: ```shell <del> kubectl delete deployment nginx-deployment --cascade=false </del> <ins> kubectl delete deployment nginx-deployment --cascade=orphan </ins> ``` **Using the Kubernetes API**


--- <!-- overview --> <del> Kubernetes contains several built-in tools to help you work with the Kubernetes system. </del> <ins> Kubernetes contains several built-in tools and external tools that are commonly used or relevant that may as well be seen as required for Kubernetes to function. </ins> <!-- body -->


Kubernetes Service 总览

 Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。

 Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个唯一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。

 Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么您可能想要一个 spec 中不包含selector的服务)来标记。


### Restricting profiles with the PodSecurityPolicy <ins> {{< note >}} PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25. See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information. {{< /note >}} </ins> If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:


to the REST api. For further documentation refer to the authorization.v1beta1 API objects and <del> [webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). </del> <ins> [webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). </ins>


Use `activeDeadlineSeconds` on the Pod to prevent init containers from failing forever. The active deadline includes init containers. <del> However it is recommended to use `activeDeadlineSeconds` if user deploy their application </del> <ins> However it is recommended to use `activeDeadlineSeconds` only if teams deploy their application </ins> as a Job, because `activeDeadlineSeconds` has an effect even after initContainer finished. The Pod which is already running correctly would be killed by `activeDeadlineSeconds` if you set.


힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨. {{< /note >}} <del> 자세한 사항은 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다. </del> <ins> 자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다. </ins> 오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다. 스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.


[params.ui] # Enable to show the side bar menu in its compact state. sidebar_menu_compact = false <ins> # https://github.com/gohugoio/hugo/issues/8918#issuecomment-903314696 sidebar_cache_limit = 1 </ins> #  Set to true to disable breadcrumb navigation. breadcrumb_disable = false #  Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled)


[build.environment] NODE_VERSION = "10.20.0" <del> HUGO_VERSION = "0.82.0" </del> <ins> HUGO_VERSION = "0.87.0" </ins> RUBY_VERSION = "3.0.1" [context.production.environment]


<del> Subproject commit 0f9c38b8daae932518bee269de2768395d2a2dc2 </del> <ins> Subproject commit f6a1870918520c83872fc07943a67a1d9d2a998c </ins>


All of this is best illustrated by examples.  Imagine a Kubernetes release, version X, which introduces a new API group.  A new Kubernetes release is made <del> every approximately 3 months (4 per year).  The following table describes which </del> <ins> every approximately 4 months (3 per year).  The following table describes which </ins> API versions are supported in a series of subsequent releases. <table>


{{ range . }} {{ with (where $.section.Translations ".Lang" . ) -}} {{ $p := index . 0 -}} <del> {{ $pages =  $pages | lang.Merge (union $p.Pages $p.Sections) -}} </del> <ins> {{ $pages = where ( $pages | lang.Merge (union $p.Pages $p.Sections)) ".Params.toc_hide" "!=" true -}} </ins> {{ end -}} {{ end -}} {{ end -}}


See the [webhook response](#response) section for the data expected from webhooks. The example admission webhook server leaves the `ClientAuth` field <del> [empty](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48), </del> <ins> [empty](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/images/agnhost/webhook/config.go#L38-L39), </ins> which defaults to `NoClientCert`. This means that the webhook server does not authenticate the identity of the clients, supposedly apiservers. If you need mutual TLS or other ways to authenticate the clients, see


<!-- This page covers how to customize the components that kubeadm deploys. For control plane components <del> you can use flags in the `ClusteConfiguration` structure or patches per-node. For the kubelet </del> <ins> you can use flags in the `ClusterConfiguration` structure or patches per-node. For the kubelet </ins> and kube-proxy you can use `KubeletConfiguration` and `KubeProxyConfiguration`, accordingly. All of these options are possible via the kubeadm configuration API. For more details on each field in the configuration you can navigate to our <del> [API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3). </del> <ins> [API reference pages](/docs/reference/config-api/kubeadm-config.v1beta3/). </ins> --> 本页面介绍了如何自定义 kubeadm 部署的组件。 <del> 你可以使用 `ClusteConfiguration` 结构中定义的参数，或者在每个节点上应用补丁来定制控制平面组件。 </del> <ins> 你可以使用 `ClusterConfiguration` 结构中定义的参数，或者在每个节点上应用补丁来定制控制平面组件。 </ins> 你可以使用 `KubeletConfiguration` 和 `KubeProxyConfiguration` 结构分别定制 kubelet 和 kube-proxy 组件。 所有这些选项都可以通过 kubeadm 配置 API 实现。


To customize kube-proxy you can pass a `KubeProxyConfiguration` next your `ClusterConfiguration` or `InitConfiguration` to `kubeadm init` separated by `---`. <del> For more details you can navigate to our [API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3). </del> <ins> For more details you can navigate to our [API reference pages](/docs/reference/config-api/kubeadm-config.v1beta3/). </ins> --> ## 自定义 kube-proxy   {#customizing-kube-proxy}


To make a report, submit your vulnerability to the [Kubernetes bug bounty program](https://hackerone.com/kubernetes). This allows triage and handling of the vulnerability with standardized response times. <del> You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md). </del> <ins> You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml). </ins> You may encrypt your email to this list using the GPG keys of the [Security Response Committee members](https://git.k8s.io/security/README.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure.