<ins> --- title: "Secretの管理" weight: 28 description: Secretを使用した機密設定データの管理 --- </ins>


$($(CertUtil -hashfile .kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .kubectl.exe.sha256) ``` <del> 1. Append or prepend the kubectl binary folder to your `PATH` environment variable. </del> <ins> 1. Append or prepend the `kubectl` binary folder to your `PATH` environment variable. </ins> 1. Test to ensure the version of `kubectl` is the same as downloaded:


以下の理由によりPodは再起動し、Initコンテナの再実行も引き起こす可能性があります。 <del> * ユーザーが、そのPodのInitコンテナのイメージを変更するようにPodの仕様を更新する場合。アプリケーションコンテナのイメージの変更はそのアプリケーションコンテナの再起動のみ行われます。 </del> * そのPodのインフラストラクチャーコンテナが再起動された場合。これはあまり起きるものでなく、Nodeに対するルート権限を持ったユーザーにより行われることがあります。 <del> * `restartPolicy`が`Always`と設定されているPod内の全てのコンテナが停止され、再起動が行われた場合。およびガーベージコレクションによりInitコンテナの完了記録が失われた場合。 </del> <ins> * `restartPolicy`が`Always`と設定されているPod内の全てのコンテナが停止され、強制的に再起動が行われたことで、ガベージコレクションによりInitコンテナの完了記録が失われた場合。 Kubernetes v1.20以降では、initコンテナのイメージが変更されたり、ガベージコレクションによってinitコンテナの完了記録が失われたりした場合でも、Podは再起動されません。以前のバージョンを使用している場合は、対応バージョンのドキュメントを参照してください。 </ins> <del> ## {{% heading "whatsnext" %}} </del> <ins> ## {{% heading "whatsnext" %}} {#what-s-next} </ins> * [Initコンテナを含むPodの作成](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)方法について学ぶ。 * [Initコンテナのデバッグ](/ja/docs/tasks/debug-application-cluster/debug-init-containers/)を行う方法について学ぶ。


{{% 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`             | | ---------------- | ----------------- |


<del> --- title: Bin Packing Sumber Daya untuk Sumber Daya Tambahan content_type: concept weight: 10 --- <!-- overview --> {{< feature-state for_k8s_version="1.16" state="alpha" >}} _Kube-scheduler_ dapat dikonfigurasikan untuk mengaktifkan pembungkusan rapat (_bin packing_) sumber daya bersama dengan sumber daya tambahan melalui fungsi prioritas `RequestedToCapacityRatioResourceAllocation`. Fungsi-fungsi prioritas dapat digunakan untuk menyempurnakan _kube-scheduler_ sesuai dengan kebutuhan. <!-- body --> ## Mengaktifkan _Bin Packing_ menggunakan RequestedToCapacityRatioResourceAllocation Sebelum Kubernetes 1.15, _kube-scheduler_ digunakan untuk memungkinkan mencetak skor berdasarkan rasio permintaan terhadap kapasitas sumber daya utama seperti CPU dan Memori. Kubernetes 1.16 menambahkan parameter baru ke fungsi prioritas yang memungkinkan pengguna untuk menentukan sumber daya beserta dengan bobot untuk setiap sumber daya untuk memberi nilai dari Node berdasarkan rasio permintaan terhadap kapasitas. Hal ini memungkinkan pengguna untuk _bin pack_ sumber daya tambahan dengan menggunakan parameter yang sesuai untuk meningkatkan pemanfaatan sumber daya yang langka dalam klaster yang besar. Perilaku `RequestedToCapacityRatioResourceAllocation` dari fungsi prioritas dapat dikontrol melalui pilihan konfigurasi yang disebut ` RequestToCapacityRatioArguments`. Argumen ini terdiri dari dua parameter yaitu `shape` dan `resources`. Shape memungkinkan pengguna untuk menyempurnakan fungsi menjadi yang paling tidak diminta atau paling banyak diminta berdasarkan nilai `utilization` dan `score`. Sumber daya terdiri dari `name` yang menentukan sumber daya mana yang dipertimbangkan selama penilaian dan `weight` yang menentukan bobot masing-masing sumber daya. Di bawah ini adalah contoh konfigurasi yang menetapkan `requestedToCapacityRatioArguments` pada perilaku _bin packing_ untuk sumber daya tambahan` intel.com/foo` dan `intel.com/bar` ```json { "kind" : "Policy", "apiVersion" : "v1", ... "priorities" : [ ... { "name": "RequestedToCapacityRatioPriority", "weight": 2, "argument": { "requestedToCapacityRatioArguments": { "shape": [ {"utilization": 0, "score": 0}, {"utilization": 100, "score": 10} ], "resources": [ {"name": "intel.com/foo", "weight": 3}, {"name": "intel.com/bar", "weight": 5} ] } } } ], } ``` **Fitur ini dinonaktifkan secara _default_** ### Tuning RequestedToCapacityRatioResourceAllocation Priority Function `shape` digunakan untuk menentukan perilaku dari fungsi `RequestedToCapacityRatioPriority`. ```yaml {"utilization": 0, "score": 0}, {"utilization": 100, "score": 10} ``` Argumen di atas memberikan Node nilai 0 jika utilisasi 0% dan 10 untuk utilisasi 100%, yang kemudian mengaktfikan perilaku _bin packing_. Untuk mengaktifkan dari paling yang tidak diminta, nilainya harus dibalik sebagai berikut. ```yaml {"utilization": 0, "score": 100}, {"utilization": 100, "score": 0} ``` `resources` adalah parameter opsional yang secara _default_ diatur ke: ``` yaml "resources": [ {"name": "CPU", "weight": 1}, {"name": "Memory", "weight": 1} ] ``` Ini dapat digunakan untuk menambahkan sumber daya tambahan sebagai berikut: ```yaml "resources": [ {"name": "intel.com/foo", "weight": 5}, {"name": "CPU", "weight": 3}, {"name": "Memory", "weight": 1} ] ``` Parameter `weight` adalah opsional dan diatur ke 1 jika tidak ditentukan. Selain itu, `weight` tidak dapat diatur ke nilai negatif. ### Bagaimana Fungsi Prioritas RequestedToCapacityRatioResourceAllocation Menilai Node Bagian ini ditujukan bagi kamu yang ingin memahami secara detail internal dari fitur ini. Di bawah ini adalah contoh bagaimana nilai dari Node dihitung untuk satu kumpulan nilai yang diberikan. ``` Sumber daya yang diminta intel.com/foo : 2 Memory: 256MB CPU: 2 Bobot dari sumber daya intel.com/foo : 5 Memory: 1 CPU: 3 FunctionShapePoint {{0, 0}, {100, 10}} Spesifikasi dari Node 1 Tersedia: intel.com/foo : 4 Memory : 1 GB CPU: 8 Digunakan: intel.com/foo: 1 Memory: 256MB CPU: 1 Nilai Node: intel.com/foo  = resourceScoringFunction((2+1),4) =  (100 - ((4-3)*100/4) =  (100 - 25) =  75 =  rawScoringFunction(75) = 7 Memory         = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) = 50 = rawScoringFunction(50) = 5 CPU            = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) = 37.5 = rawScoringFunction(37.5) = 3 NodeScore   =  (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) =  5 Spesifikasi dari Node 2 Tersedia: intel.com/foo: 8 Memory: 1GB CPU: 8 Digunakan: intel.com/foo: 2 Memory: 512MB CPU: 6 Nilai Node: intel.com/foo  = resourceScoringFunction((2+2),8) =  (100 - ((8-4)*100/8) =  (100 - 25) =  50 =  rawScoringFunction(50) = 5 Memory         = resourceScoringFunction((256+512),1024) = (100 -((1024-768)*100/1024)) = 75 = rawScoringFunction(75) = 7 CPU            = resourceScoringFunction((2+6),8) = (100 -((8-8)*100/8)) = 100 = rawScoringFunction(100) = 10 NodeScore   =  (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) =  7 ``` </del>


* [`gcePersistentDisk`](#gcepersistentdisk) * [`vsphereVolume`](#vspherevolume) <del> ### flexVolume (deprecated) </del> <ins> ### flexVolume (deprecated)   {#flexvolume} </ins> {{< feature-state for_k8s_version="v1.23" state="deprecated" >}}


You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization. {{< note >}} <del> In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread` </del> <ins> In versions of Kubernetes before v1.18, you must enable the `EvenPodsSpread` </ins> [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/concepts/overview/components/#kube-apiserver) and the [scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod


However, using the defined and public Secret type (`kubernetes.io/basic-auth`) helps other people to understand the purpose of your Secret, and sets a convention for what key names to expect. <del> The Kubernetes API verifies that the required keys are set for a Secret of this type. </del> ### SSH authentication Secrets


--- assignees: - bboreham <del> title: Weave Net Addon </del> <ins> title: Using Weave Net for NetworkPolicy </ins> --- The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for Kubernetes comes with a Network Policy Controller.


<ins> --- reviewers: - bowei - zihongz title:  Debugging DNS Resolution content_type: task min-kubernetes-server-version: v1.6 --- <!-- overview --> This page provides hints on diagnosing DNS problems. ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} Your cluster must be configured to use the CoreDNS {{< glossary_tooltip text="addon" term_id="addons" >}} or its precursor, kube-dns. {{% version-check %}} <!-- steps --> ### Create a simple Pod to use as a test environment {{< codenew file="admin/dns/dnsutils.yaml" >}} Use that manifest to create a Pod: ```shell kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml ``` ``` pod/dnsutils created ``` …and verify its status: ```shell kubectl get pods dnsutils ``` ``` NAME      READY     STATUS    RESTARTS   AGE dnsutils   1/1       Running   0          <some-time> ``` Once that Pod is running, you can exec `nslookup` in that environment. If you see something like the following, DNS is working correctly. ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 Name:      kubernetes.default Address 1: 10.0.0.1 ``` If the `nslookup` command fails, check the following: ### Check the local DNS configuration first Take a look inside the resolv.conf file. (See [Inheriting DNS from the node](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) and [Known issues](#known-issues) below for more information) ```shell kubectl exec -ti dnsutils -- cat /etc/resolv.conf ``` Verify that the search path and name server are set up like the following (note that search path may vary for different cloud providers): ``` search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal nameserver 10.0.0.10 options ndots:5 ``` Errors such as the following indicate a problem with the CoreDNS (or kube-dns) add-on or with associated Services: ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 nslookup: can't resolve 'kubernetes.default' ``` or ```shell kubectl exec -i -t dnsutils -- nslookup kubernetes.default ``` ``` Server:    10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local nslookup: can't resolve 'kubernetes.default' ``` ### Check if the DNS pod is running Use the `kubectl get pods` command to verify that the DNS pod is running. ```shell kubectl get pods --namespace=kube-system -l k8s-app=kube-dns ``` ``` NAME                       READY     STATUS    RESTARTS   AGE ... coredns-7b96bf9f76-5hsxb   1/1       Running   0           1h coredns-7b96bf9f76-mvmmt   1/1       Running   0           1h ... ``` {{< note >}} The value for label `k8s-app` is `kube-dns` for both CoreDNS and kube-dns deployments. {{< /note >}} If you see that no CoreDNS Pod is running or that the Pod has failed/completed, the DNS add-on may not be deployed by default in your current environment and you will have to deploy it manually. ### Check for errors in the DNS pod Use the `kubectl logs` command to see logs for the DNS containers. For CoreDNS: ```shell kubectl logs --namespace=kube-system -l k8s-app=kube-dns ``` Here is an example of a healthy CoreDNS log: ``` .:53 2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2 2018/08/15 14:37:17 [INFO] linux/amd64, go1.10.3, 2e322f6 CoreDNS-1.2.2 linux/amd64, go1.10.3, 2e322f6 2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c ``` See if there are any suspicious or unexpected messages in the logs. ### Is DNS service up? Verify that the DNS service is up by using the `kubectl get service` command. ```shell kubectl get svc --namespace=kube-system ``` ``` NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE ... kube-dns     ClusterIP   10.0.0.10      <none>        53/UDP,53/TCP        1h ... ``` {{< note >}} The service name is `kube-dns` for both CoreDNS and kube-dns deployments. {{< /note >}} If you have created the Service or in the case it should be created by default but it does not appear, see [debugging Services](/docs/tasks/debug-application-cluster/debug-service/) for more information. ### Are DNS endpoints exposed? You can verify that DNS endpoints are exposed by using the `kubectl get endpoints` command. ```shell kubectl get endpoints kube-dns --namespace=kube-system ``` ``` NAME       ENDPOINTS                       AGE kube-dns   10.180.3.17:53,10.180.3.17:53    1h ``` If you do not see the endpoints, see the endpoints section in the [debugging Services](/docs/tasks/debug-application-cluster/debug-service/) documentation. For additional Kubernetes DNS examples, see the [cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) in the Kubernetes GitHub repository. ### Are DNS queries being received/processed? You can verify if queries are being received by CoreDNS by adding the `log` plugin to the CoreDNS configuration (aka Corefile). The CoreDNS Corefile is held in a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} named `coredns`. To edit it, use the command: ``` kubectl -n kube-system edit configmap coredns ``` Then add `log` in the Corefile section per the example below: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { log errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance } ``` After saving the changes, it may take up to minute or two for Kubernetes to propagate these changes to the CoreDNS pods. Next, make some queries and view the logs per the sections above in this document. If CoreDNS pods are receiving the queries, you should see them in the logs. Here is an example of a query in the log: ``` .:53 2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0 2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6 CoreDNS-1.2.0 linux/amd64, go1.10.3, 2e322f6 2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f 2018/09/07 15:29:04 [INFO] Reloading complete 172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s ``` ## Known issues Some Linux distributions (e.g. Ubuntu) use a local DNS resolver by default (systemd-resolved). Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`). kubeadm automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly. Kubernetes installs do not configure the nodes' `resolv.conf` files to use the cluster DNS by default, because that process is inherently distribution-specific. This should probably be implemented eventually. Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by default. What's more, for the glibc versions which are older than glibc-2.17-222 ([the new versions update see this issue](https://access.redhat.com/solutions/58028)), the allowed number of DNS `search` records has been limited to 6 ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs to consume 1 `nameserver` record and 3 `search` records. This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es while your glibc version is in the affected list, some of those settings will be lost. To work around the DNS `nameserver` records limit, the node can run `dnsmasq`, which will provide more `nameserver` entries. You can also use kubelet's `--resolv-conf` flag. To fix the DNS `search` records limit, consider upgrading your linux distribution or upgrading to an unaffected version of glibc. If you are using Alpine version 3.3 or earlier as your base image, DNS may not work properly due to a known issue with Alpine. Kubernetes [issue 30215](https://github.com/kubernetes/kubernetes/issues/30215) details more information on this. ## {{% heading "whatsnext" %}} - See [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - Read [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/) </ins>


Minikube 在用户计算机上的一个虚拟机内运行单节点 Kubernetes 集群。 你可以使用 Minikube <del> [在学习环境中尝试 Kubernetes](/zh-cn/docs/setup/learning-environment/). </del> <ins> [在学习环境中尝试 Kubernetes](/zh-cn/docs/setup/learning-environment/)。 </ins>


or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. <del> Nodes should be provisioned with the public root certificate for the cluster such that they can </del> <ins> Nodes should be provisioned with the public root {{< glossary_tooltip text="certificate" term_id="certificate" >}} for the cluster such that they can </ins> connect securely to the API server along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. <del> Pods that wish to connect to the API server can do so securely by leveraging a service account so </del> <ins> {{< glossary_tooltip text="Pods" term_id="pod" >}} that wish to connect to the API server can do so securely by leveraging a service account so </ins> that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is <del> redirected (via `kube-proxy`) to the HTTPS endpoint on the API server. </del> <ins> redirected (via `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) to the HTTPS endpoint on the API server. </ins> The control plane components also communicate with the API server over the secure port. <del> As a result, the default operating mode for connections from the nodes and pods running on the </del> <ins> As a result, the default operating mode for connections from the nodes and pod running on the </ins> nodes to the control plane is secured by default and can run over untrusted and/or public networks. ## Control plane to node There are two primary communication paths from the control plane (the API server) to the nodes. <del> The first is from the API server to the kubelet process which runs on each node in the cluster. </del> <ins> The first is from the API server to the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} process which runs on each node in the cluster. </ins> The second is from the API server to any node, pod, or service through the API server's _proxy_ functionality.


other versions of Kubernetes, check the documentation for that release. By default, `spec.loadBalancerClass` is `nil` and a `LoadBalancer` type of Service uses the cloud provider's default load balancer implementation if the cluster is configured with <del> a cloud provider using the `--cloud-provider` component flag. </del> <ins> a cloud provider using the `--cloud-provider` component flag. </ins> If `spec.loadBalancerClass` is specified, it is assumed that a load balancer implementation that matches the specified class is watching for Services. Any default load balancer implementation (for example, the one provided by the cloud provider) will ignore Services that have this field set. `spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only. <del> Once set, it cannot be changed. </del> <ins> Once set, it cannot be changed. </ins> The value of `spec.loadBalancerClass` must be a label-style identifier, with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`". Unprefixed names are reserved for end-users.


This annotation is used to set [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) which allows users to influence ReplicaSet downscaling order. The annotation parses into an `int32` type. <ins> ### cluster-autoscaler.kubernetes.io/enable-ds-eviction Example: `cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"` Used on: Pod This annotation controls whether a DaemonSet pod should be evicted by a ClusterAutoscaler. This annotation needs to be specified on DaemonSet pods in a DaemonSet manifest. When this annotation is set to `"true"`, the ClusterAutoscaler is allowed to evict a DaemonSet Pod, even if other rules would normally prevent that. To disallow the ClusterAutoscaler from evicting DaemonSet pods, you can set this annotation to `"false"` for important DaemonSet pods. If this annotation is not set, then the Cluster Autoscaler follows its overall behaviour (i.e evict the DaemonSets based on its configuration). {{< note >}} This annotation only impacts DaemonSet pods. {{< /note >}} </ins> ### kubernetes.io/ingress-bandwidth {{< note >}}


in that Pod based on the data in the ConfigMap. The Pod and the ConfigMap must be in the same {{< glossary_tooltip text="namespace" term_id="namespace" >}}. <ins> {{< note >}} The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a ConfigMap or any other API objects. {{< /note >}} </ins> Here's an example ConfigMap that has some keys with single values, and other keys where the value looks like a fragment of a configuration format.


common use cases and suggested solutions. 1. Cluster running only non-proprietary (e.g. open-source) images.  No need to hide images. <del> - Use public images on the Docker hub. </del> <ins> - Use public images from a public registry </ins> - No configuration required. - Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images. 1. Cluster running some proprietary images which should be hidden to those outside the company, but visible to all cluster users. <del> - Use a hosted private [Docker registry](https://docs.docker.com/registry/). - It may be hosted on the [Docker Hub](https://hub.docker.com/signup), or elsewhere. - Manually configure .docker/config.json on each node as described above. </del> <ins> - Use a hosted private registry - Manual configuration may be required on the nodes that need to access to private registry </ins> - Or, run an internal private registry behind your firewall with open read access. - No Kubernetes configuration is required. - Use a hosted container image registry service that controls image access


### Stable Storage <del> Kubernetes creates one [PersistentVolume](/docs/concepts/storage/persistent-volumes/) for each VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass </del> <ins> For each VolumeClaimTemplate entry defined in a StatefulSet, each Pod receives one PersistentVolumeClaim. In the nginx example above, each Podreceives a single PersistentVolume with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass </ins> is specified, then the default StorageClass will be used. When a Pod is (re)scheduled onto a node, its `volumeMounts` mount the PersistentVolumes associated with its PersistentVolume Claims. Note that, the PersistentVolumes associated with the


cat <<EOF >./kustomization.yaml configMapGenerator: - name: game-config-4 <del> labels: game-config: config-4 </del> <ins> options: labels: game-config: config-4 </ins> files: - configure-pod-container/configmap/game.properties EOF


Now, re-run the test: ```console <del> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; do </del> <ins> $ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done </ins> client_address=104.132.1.79 ```


```shell kubectl describe -f myapp.yaml ``` <ins> 実行結果は下記のようになります。 </ins> ``` Name:          myapp-pod Namespace:     default [...] <del> Labels:        app=myapp </del> <ins> Labels:        app.kubernetes.io/name=MyApp </ins> Status:        Pending [...] Init Containers:


{{ range .Params.cards }}

{{ .title }}

{{ .description }}


title: Pod 优先级（Pod Priority） id: pod-priority date: 2019-01-31 <del> full_link: /zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority </del> <ins> full_link: /zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority </ins> short_description: > Pod 优先级表示一个 Pod 相对于其他 Pod 的重要性。


<ins> <svg width="580" height="400" xmlns="http://www.w3.org/2000/svg"> <g> <title>background</title> <rect x="-1" y="-1" width="506.34798" height="349.82619" id="canvas_background" fill="#fff" opacity="0"/> <g id="canvasGrid" display="none"> <rect opacity="0" id="svg_4" width="100%" height="100%" x="0" y="0" stroke-width="0" fill="url(#gridpattern)"/> </g> </g> <g> <title>Layer 1</title> <rect fill="#326ce5" stroke="#000" stroke-width="1.5" x="126.27611" y="84.45079" width="336.49766" height="242.99831" id="svg_1"/> <rect fill="#DDDDDD" stroke-width="0.5" x="127.2761" y="261.05662" width="95.3" height="66" id="svg_2" stroke="#000"/> <rect fill="#BBBBBB" stroke-opacity="null" x="222.4421" y="261.28292" width="108.3" height="66" id="svg_3" stroke="#000"/> <rect fill="#ffffff" stroke-width="0.5" stroke-opacity="null" x="330.77469" y="261.28292" width="131" height="66" id="svg_5" stroke="#000"/> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="126.25112" y="28.72775" id="svg_6" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(3.8729541301727295,0,0,0.698510413795276,-358.40104965794853,12.1371268265946) " stroke="#000"/> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="96.33037" y="92.52907" id="svg_9" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.6039765318373469,0,0,0.6213608286284256,43.920523540443796,7.5797796894100635) " stroke="#000">Node Capacity</text> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="146.65172" y="483.69046" id="svg_10" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">kube-reserved</text> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="333.31931" y="486.27149" id="svg_11" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">system-reserved</text> <text fill="#000000" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="559.50522" y="487.562" id="svg_12" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.5187438936507338,0,0,0.5165904901211577,58.14778751529779,47.720737964149194) " stroke="#000">eviction-threshold</text> <text fill="#ffffff" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="246.31519" y="182.62777" id="svg_14" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.8530217831379474,0,0,0.8530217831379474,32.26513711483058,11.272510077186126) " stroke="#000">allocatable</text> <text fill="#ffffff" stroke-width="0" stroke-opacity="null" fill-opacity="null" x="191.56677" y="217.51295" id="svg_15" font-size="24" font-family="Helvetica, Arial, sans-serif" text-anchor="start" xml:space="preserve" transform="matrix(0.6610298739213645,0,0,0.6148439389614191,97.43948566238379,61.05811172356589) " stroke="#000">(available for pods)</text> <line fill="none" stroke="#000" stroke-width="null" stroke-opacity="null" fill-opacity="null" x1="221.6918" y1="348.02537" x2="222.35847" y2="348.02537" id="svg_19" transform="rotate(0.9628710746765137 222.02513122558057,348.0253906249988) "/> <line stroke="#000" stroke-linecap="square" id="svg_8" y2="261.50152" x2="462.85834" y1="261.50152" x1="125.8955" fill-opacity="null" stroke-opacity="null" fill="none"/> <line stroke="#000" stroke-linecap="square" id="svg_13" y2="328.33922" x2="331.2413" y1="261.98921" x1="331.2413" fill-opacity="null" stroke-opacity="null" fill="none"/> <line stroke="#000" stroke-linecap="square" id="svg_17" y2="327.36391" x2="222.00652" y1="261.50155" x1="222.00652" fill-opacity="null" stroke-opacity="null" fill="none"/> </g> </svg> </ins>


--- <del> title: Intro to Windows support in Kubernetes </del> <ins> title: KubernetesのWindowsサポート概要 </ins> content_type: concept weight: 65 --- <!-- overview --> <del> Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system. </del> <ins> Windowsアプリケーションは、多くの組織で実行されているサービスやアプリケーションの大部分を占めています。[Windowsコンテナ](https://aka.ms/windowscontainers)は、プロセスとパッケージの依存関係を一つにまとめる最新の方法を提供し、DevOpsプラクティスの使用とWindowsアプリケーションのクラウドネイティブパターンの追求を容易にします。Kubernetesは事実上、標準的なコンテナオーケストレータになりました。Kubernetes 1.14のリリースでは、Kubernetesクラスター内のWindowsノードでWindowsコンテナをスケジューリングする本番環境サポートが含まれたので、Windowsアプリケーションの広大なエコシステムにおいて、Kubernetesを有効的に活用できます。WindowsベースのアプリケーションとLinuxベースのアプリケーションに投資している組織は、ワークロードを管理する個別のオーケストレーターが不要となるため、オペレーティングシステムに関係なく導入全体の運用効率が向上します。 </ins> <!-- body --> <del> ## Windows containers in Kubernetes </del> <ins> ## KubernetesのWindowsコンテナ </ins> <del> To enable the orchestration of Windows containers in Kubernetes, simply include Windows nodes in your existing Linux cluster. Scheduling Windows containers in [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) on Kubernetes is as simple and easy as scheduling Linux-based containers. </del> <ins> KubernetesでWindowsコンテナのオーケストレーションを有効にするには、既存のLinuxクラスターにWindowsノードを含めるだけです。Kubernetesの[Pod](/ja/docs/concepts/workloads/pods/pod-overview/)でWindowsコンテナをスケジュールすることは、Linuxベースのコンテナをスケジュールするのと同じくらいシンプルで簡単です。 </ins> <del> In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). </del> <ins> Windowsコンテナを実行するには、Kubernetesクラスターに複数のオペレーティングシステムを含める必要があります。コントロールプレーンノードはLinux、ワーカーノードはワークロードのニーズに応じてWindowsまたはLinuxで実行します。Windows Server 2019は、サポートされている唯一のWindowsオペレーティングシステムであり、Windows（kubelet、[コンテナランタイム](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd)、kube-proxyを含む）で[Kubernetesノード](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)を有効にします。Windowsディストリビューションチャンネルの詳細については、[Microsoftのドキュメント](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19)を参照してください。 </ins> {{< note >}} <del> The Kubernetes control plane, including the [master components](/ja/docs/concepts/overview/components/), continues to run on Linux. There are no plans to have a Windows-only Kubernetes cluster. </del> <ins> [マスターコンポーネント](/ja/docs/concepts/overview/components/)を含むKubernetesコントロールプレーンは、Linuxで実行し続けます。WindowsのみのKubernetesクラスターを導入する計画はありません。 </ins> {{< /note >}} {{< note >}} <del> In this document, when we talk about Windows containers we mean Windows containers with process isolation. Windows containers with [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) is planned for a future release. </del> <ins> このドキュメントでは、Windowsコンテナについて説明する場合、プロセス分離のWindowsコンテナを意味します。[Hyper-V分離](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)のWindowsコンテナは、将来リリースが計画されています。 </ins> {{< /note >}} <del> ## Supported Functionality and Limitations </del> <ins> ## サポートされている機能と制限 </ins> <del> ### Supported Functionality </del> <ins> ### サポートされている機能 </ins> <del> #### Compute </del> <ins> #### コンピュート </ins> <del> From an API and kubectl perspective, Windows containers behave in much the same way as Linux-based containers. However, there are some notable differences in key functionality which are outlined in the limitation section. </del> <ins> APIとkubectlの観点から見ると、WindowsコンテナはLinuxベースのコンテナとほとんど同じように動作します。ただし、制限セクションで概説されている主要な機能には、いくつかの顕著な違いがあります。 </ins> <del> Let's start with the operating system version. Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes. </del> <ins> オペレーティングシステムのバージョンから始めましょう。KubernetesのWindowsオペレーティングシステムのサポートについては、次の表を参照してください。単一の異種Kubernetesクラスターは、WindowsとLinuxの両方のワーカーノードを持つことができます。WindowsコンテナはWindowsノードで、LinuxコンテナはLinuxノードでスケジュールする必要があります。 </ins> <del> | Kubernetes version | Host OS version (Kubernetes Node) | | | </del> <ins> | Kubernetes バージョン | ホストOS バージョン (Kubernetes ノード) | | | </ins> | --- | --- | --- | --- | | | *Windows Server 1709* | *Windows Server 1803* | *Windows Server 1809/Windows Server 2019* | <del> | *Kubernetes v1.14* | Not Supported | Not Supported| Supported for Windows Server containers Builds 17763.* with Docker EE-basic 18.09 | </del> <ins> | *Kubernetes v1.14* | サポートされていません | サポートされていません| Windows Server containers Builds 17763.* と Docker EE-basic 18.09 がサポートされています | </ins> {{< note >}} <del> We don't expect all Windows customers to update the operating system for their apps frequently. Upgrading your applications is what dictates and necessitates upgrading or introducing new nodes to the cluster. For the customers that chose to upgrade their operating system for containers running on Kubernetes, we will offer guidance and step-by-step instructions when we add support for a new operating system version. This guidance will include recommended upgrade procedures for upgrading user applications together with cluster nodes. Windows nodes adhere to Kubernetes [version-skew policy](/ja/docs/setup/release/version-skew-policy/) (node to control plane versioning) the same way as Linux nodes do today. </del> <ins> すべてのWindowsユーザーがアプリのオペレーティングシステムを頻繁に更新することは望んでいません。アプリケーションのアップグレードは、クラスターに新しいノードをアップグレードまたは導入することを要求する必要があります。Kubernetesで実行されているコンテナのオペレーティングシステムをアップグレードすることを選択したお客様には、新しいオペレーティングシステムバージョンのサポート追加時に、ガイダンスと段階的な指示を提供します。このガイダンスには、クラスターノードと共にアプリケーションをアップグレードするための推奨アップグレード手順が含まれます。Windowsノードは、現在のLinuxノードと同じように、Kubernetes[バージョンスキューポリシー](/ja/docs/setup/release/version-skew-policy/)（ノードからコントロールプレーンのバージョン管理）に準拠しています。 </ins> {{< /note >}} {{< note >}} <del> The Windows Server Host Operating System is subject to the [Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) licensing. The Windows Container images are subject to the [Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula). </del> <ins> Windows Serverホストオペレーティングシステムには、[Windows Server](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)ライセンスが適用されます。Windowsコンテナイメージには、[Windowsコンテナの追加ライセンス条項](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)ライセンスが提供されます。 </ins> {{< /note >}} {{< note >}} <del> Windows containers with process isolation have strict compatibility rules, [where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility). Once we support Windows containers with Hyper-V isolation in Kubernetes, the limitation and compatibility rules will change. </del> <ins> プロセス分離のWindowsコンテナには、厳格な互換性ルールがあります[ホストOSのバージョンはコンテナのベースイメージのOSバージョンと一致する必要があります](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility)。KubernetesでHyper-V分離のWindowsコンテナをサポートすると、制限と互換性ルールが変更されます。 </ins> {{< /note >}} <del> Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows. </del> <ins> Kubernetesの主要な要素は、WindowsでもLinuxと同じように機能します。このセクションでは、主要なワークロードイネーブラーのいくつかと、それらがWindowsにどのようにマップされるかについて説明します。 </ins> * [Pods](/ja/docs/concepts/workloads/pods/pod-overview/) <del> A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers: </del> <ins> Podは、Kubernetesの基本的なビルディングブロックです。作成またはデプロイするKubernetesオブジェクトモデルの最小かつ最も単純なユニットです。WindowsとLinuxのコンテナを同じPodにデプロイすることはできません。Pod内のすべてのコンテナは、各ノードが特定のプラットフォームとアーキテクチャを表す単一のノードにスケジュールされます。次のPod機能、プロパティ、およびイベントがWindowsコンテナでサポートされています。: </ins> <del> * Single or multiple containers per Pod with process isolation and volume sharing * Pod status fields * Readiness and Liveness probes * postStart & preStop container lifecycle events * ConfigMap, Secrets: as environment variables or volumes </del> <ins> * プロセス分離とボリューム共有を備えたPodごとの単一または複数のコンテナ * Podステータスフィールド * ReadinessとLiveness Probe * postStartとpreStopコンテナのライフサイクルイベント * ConfigMap, Secrets: 環境変数またはボリュームとして </ins> * EmptyDir <del> * Named pipe host mounts * Resource limits </del> <ins> * 名前付きパイプホストマウント * リソース制限 </ins> * [Controllers](/ja/docs/concepts/workloads/controllers/) <del> Kubernetes controllers handle the desired state of Pods. The following workload controllers are supported with Windows containers: </del> <ins> Kubernetesコントローラは、Podの望ましい状態を処理します。次のワークロードコントローラーは、Windowsコンテナでサポートされています。: </ins> * ReplicaSet * ReplicationController


 {{ with site.Home.OutputFormats.Get "rss" -}} <link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" href="{{ .Permalink | safeURL }}" title="{{ site.Title }}">
   RSS Feed

   RSS Feed
   {{ end -}}
  Submit a Post

    @Kubernetesio

   on GitHub

  #kubernetes-users

  Overflow

  Forum

  Submit a Post

    @Kubernetesio

   on GitHub

  #kubernetes-users

  Overflow

  Forum

  Kubernetes


The following examples show some `crictl` commands and example output. <del> {{< warning >}} If you use `crictl` to create pod sandboxes or containers on a running Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a general purpose workflow tool, but a tool that is useful for debugging. {{< /warning >}} </del> ### List pods List all pods:


### SSH tunnels <del> Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this </del> <ins> Kubernetes supports [SSH tunnels](https://www.ssh.com/academy/ssh/tunneling) to protect the control plane to nodes communication paths. In this </ins> configuration, the API server initiates an SSH tunnel to each node in the cluster (connecting to the SSH server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel.


### cgroupfs driver {#cgroupfs-cgroup-driver} <del> The `cgroupfs` driver is the default cgroup driver in the kubelet. When the `cgroupfs` driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups. </del> <ins> The `cgroupfs` driver is the [default cgroup driver in the kubelet](docs/reference/config-api/kubelet-config.v1beta1). When the `cgroupfs` driver is used, the kubelet and the container runtime directly interface with the cgroup filesystem to configure cgroups. </ins> The `cgroupfs` driver is **not** recommended when [systemd](https://www.freedesktop.org/wiki/Software/systemd/) is the init system because systemd expects a single cgroup manager on <del> the system. Additionally, if you use [cgroup v2](/docs/concepts/architecture/cgroups) , use the `systemd` cgroup driver instead of `cgroupfs`. </del> <ins> the system. Additionally, if you use [cgroup v2](/docs/concepts/architecture/cgroups), use the `systemd` cgroup driver instead of `cgroupfs`. </ins> ### systemd cgroup driver {#systemd-cgroup-driver}


- [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ - [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ - [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ <ins> - [SecretのAPIリファレンス](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)を読む </ins>


Example: `node.kubernetes.io/out-of-service:NoExecute` <del> A user can manually add the taint to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach` </del> <ins> A user can manually add the taint to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach` </ins> [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled on <del> `kube-controller-manager`, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node. </del> <ins> `kube-controller-manager`, and a Node is marked out-of-service with this taint, the pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node. </ins> {{< caution >}} Refer to


title: Upgrading Windows nodes min-kubernetes-server-version: 1.17 content_type: task <del> weight: 50 </del> <ins> weight: 110 </ins> --- <!-- overview -->


Internet to download the necessary files, while worker nodes do not. 3. These guide is tested OK on Ubuntu 14.04 LTS 64bit server, but it can not work with Ubuntu 15 which uses systemd instead of upstart. <del> 4. Dependencies of this guide: etcd-2.2.1, flannel-0.5.5, k8s-1.1.4, may work with higher versions. </del> <ins> 4. Dependencies of this guide: etcd-2.2.1, flannel-0.5.5, k8s-1.1.8, may work with higher versions. </ins> 5. All the remote servers can be ssh logged in without a password by using key authentication.


can find each other via `localhost`. They can also communicate with each other using standard inter-process communications like SystemV semaphores or POSIX shared memory.  Containers in different pods have distinct IP addresses <del> and can not communicate by IPC. </del> <ins> and can not communicate by IPC without [special configuration](/docs/concepts/policy/pod-security-policy/). These containers usually communicate with each other via Pod IP addresses. </ins> Applications within a pod also have access to shared volumes, which are defined as part of a pod and are made available to be mounted into each application's


## Node Allocatable <del> ```text Node Capacity --------------------------- |     kube-reserved       | |-------------------------| |     system-reserved     | |-------------------------| |    eviction-threshold   | |-------------------------| |                         | |      allocatable        | |   (available for pods)  | |                         | |                         | --------------------------- ``` </del> <ins> ![node capacity](/images/docs/node-capacity.svg) </ins> `Allocatable` on a Kubernetes node is defined as the amount of compute resources that are available for pods. The scheduler does not over-subscribe


Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI)) ```bash <del> CRICTL_VERSION="v1.17.0" </del> <ins> CRICTL_VERSION="v1.22.0" </ins> ARCH="amd64" curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ```


<ins> --- title: ネットワークポリシー content_type: concept weight: 50 --- <!-- overview --> ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。 NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。 <!-- body --> ## 前提条件 ネットワークポリシーは、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)により実装されます。ネットワークポリシーを使用するには、NetworkPolicyをサポートするネットワークソリューションを使用しなければなりません。ネットワークポリシーを実装したコントローラーを使用せずにNetworkPolicyリソースを作成した場合は、何も効果はありません。 ## 分離されたPodと分離されていないPod デフォルトでは、Podは分離されていない状態(non-isolated)となるため、すべてのソースからのトラフィックを受信します。 Podを選択するNetworkPolicyが存在すると、Podは分離されるようになります。名前空間内に特定のPodを選択するNetworkPolicyが1つでも存在すると、そのPodはいずれかのNetworkPolicyで許可されていないすべての接続を拒否するようになります。(同じ名前空間内のPodでも、どのNetworkPolicyにも選択されなかった他のPodは、引き続きすべてのトラフィックを許可します。) ネットワークポリシーは追加式であるため、競合することはありません。複数のポリシーがPodを選択する場合、そのPodに許可されるトラフィックは、それらのポリシーのingress/egressルールの和集合で制限されます。したがって、評価の順序はポリシーの結果には影響がありません。 ## NetworkPolicyリソース {#networkpolicy-resource} リソースの完全な定義については、リファレンスの[NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io)のセクションを参照してください。 以下は、NetworkPolicyの一例です。 ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: role: db policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.1.0/24 - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978 ``` {{< note >}} 選択したネットワークソリューションがネットワークポリシーをサポートしていない場合には、これをクラスターのAPIサーバーにPOSTしても効果はありません。 {{< /note >}} __必須フィールド__: 他のKubernetesの設定と同様に、NetworkPolicyにも`apiVersion`、`kind`、`metadata`フィールドが必須です。設定ファイルの扱い方に関する一般的な情報については、[ConfigMapを使用してコンテナを構成する](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)と[オブジェクト管理](/ja/docs/concepts/overview/working-with-objects/object-management)を参照してください。 __spec__: NetworkPolicyの[spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を見ると、指定した名前空間内で特定のネットワークポリシーを定義するのに必要なすべての情報が確認できます。 __podSelector__: 各NetworkPolicyには、ポリシーを適用するPodのグループを選択する`podSelector`が含まれます。ポリシーの例では、ラベル"role=db"を持つPodを選択しています。`podSelector`を空にすると、名前空間内のすべてのPodが選択されます。 __policyTypes__: 各NetworkPolicyには、`policyTypes`として、`Ingress`、`Egress`、またはその両方からなるリストが含まれます。`policyTypes`フィールドでは、指定したポリシーがどの種類のトラフィックに適用されるかを定めます。トラフィックの種類としては、選択したPodへの内向きのトラフィック(Ingress)、選択したPodからの外向きのトラフィック(Egress)、またはその両方を指定します。`policyTypes`を指定しなかった場合、デフォルトで常に `Ingress`が指定され、NetworkPolicyにegressルールが1つでもあれば`Egress`も設定されます。 __ingress__: 各NetworkPolicyには、許可する`ingress`ルールのリストを指定できます。各ルールは、`from`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、3つのソースのいずれかから送信された1つのポート上のトラフィックに一致します。1つ目のソースは`ipBlock`で、2つ目のソースは`namespaceSelector`で、3つ目のソースは`podSelector`でそれぞれ定められます。 __egress__: 各NetworkPolicyには、許可する`egress`ルールのリストを指定できます。各ルールは、`to`および`ports`セクションの両方に一致するトラフィックを許可します。ポリシーの例には1つのルールが含まれ、このルールは、1つのポート上で`10.0.0.0/24`の範囲内の任意の送信先へ送られるトラフィックに一致します。 したがって、上のNetworkPolicyの例では、次のようにネットワークポリシーを適用します。 1. "default"名前空間内にある"role=db"のPodを、内向きと外向きのトラフィックに対して分離する(まだ分離されていない場合) 2. (Ingressルール) "default"名前空間内の"role=db"ラベルが付いたすべてのPodのTCPの6379番ポートへの接続のうち、次の送信元からのものを許可する * "default"名前空間内のラベル"role=frontend"が付いたすべてのPod * ラベル"project=myproject"が付いた名前空間内のすべてのPod * 172.17.0.0–172.17.0.255および172.17.2.0–172.17.255.255(言い換えれば、172.17.1.0/24の範囲を除く172.17.0.0/16)の範囲内のすべてのIPアドレス 3. (Egressルール) "role=db"というラベルが付いた"default"名前空間内のすべてのPodからの、TCPの5978番ポート上でのCIDR 10.0.0.0/24への接続を許可する 追加の例については、[ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)の説明を参照してください。 ## `to`と`from`のセレクターの振る舞い `ingress`の`from`セクションまたは`egress`の`to`セクションに指定できるセレクターは4種類あります。 __podSelector__: NetworkPolicyと同じ名前空間内の特定のPodを選択して、ingressの送信元またはegressの送信先を許可します。 __namespaceSelector__: 特定の名前空間を選択して、その名前空間内のすべてのPodについて、ingressの送信元またはegressの送信先を許可します。 __namespaceSelector__ *および* __podSelector__: 1つの`to`または`from`エントリーで`namespaceSelector`と`podSelector`の両方を指定して、特定の名前空間内の特定のPodを選択します。正しいYAMLの構文を使うように気をつけてください。このポリシーの例を以下に示します。 ```yaml ... ingress: - from: - namespaceSelector: matchLabels: user: alice podSelector: matchLabels: role: client ... ``` このポリシーには、1つの`from`要素があり、ラベル`user=alice`の付いた名前空間内にある、ラベル`role=client`の付いたPodからの接続を許可します。しかし、*以下の*ポリシーには注意が必要です。 ```yaml ... ingress: - from: - namespaceSelector: matchLabels: user: alice - podSelector: matchLabels: role: client ... ``` このポリシーには、`from`配列の中に2つの要素があります。そのため、ラベル`role=client`の付いた名前空間内にあるすべてのPodからの接続、*または*、任意の名前空間内にあるラベル`user=alice`の付いたすべてのPodからの接続を許可します。 正しいルールになっているか自信がないときは、`kubectl describe`を使用すると、Kubernetesがどのようにポリシーを解釈したのかを確認できます。 __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元またはegressの送信先を許可します。PodのIPは一時的なもので予測できないため、ここにはクラスター外のIPを指定するべきです。 クラスターのingressとegressの仕組みはパケットの送信元IPや送信先IPの書き換えを必要とすることがよくあります。その場合、NetworkPolicyの処理がIPの書き換えの前後どちらで行われるのかは定義されていません。そのため、ネットワークプラグイン、クラウドプロバイダー、`Service`の実装などの組み合わせによっては、動作が異なる可能性があります。 内向きのトラフィックの場合は、実際のオリジナルの送信元IPに基づいてパケットをフィルタリングできる可能性もあれば、NetworkPolicyが対象とする「送信元IP」が`LoadBalancer`やPodのノードなどのIPになってしまっている可能性もあることになります。 外向きのトラフィックの場合は、クラスター外のIPに書き換えられたPodから`Service`のIPへの接続は、`ipBlock`ベースのポリシーの対象になる場合とならない場合があることになります。 ## デフォルトのポリシー デフォルトでは、名前空間にポリシーが存在しない場合、その名前空間内のPodの内向きと外向きのトラフィックはすべて許可されます。以下の例を利用すると、その名前空間内でのデフォルトの振る舞いを変更できます。 ### デフォルトですべての内向きのトラフィックを拒否する すべてのPodを選択して、そのPodへのすべての内向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の分離ポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも分離されることを保証できます。このポリシーは、デフォルトの外向きの分離の振る舞いを変更しません。 ### デフォルトで内向きのすべてのトラフィックを許可する (たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodへのすべてのトラフィックを許可したい場合には、その名前空間内のすべてのトラフィックを明示的に許可するポリシーを作成できます。 {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} ### デフォルトで外向きのすべてのトラフィックを拒否する すべてのPodを選択して、そのPodからのすべての外向きのトラフィックを許可しないNetworkPolicyを作成すると、その名前空間に対する「デフォルト」の外向きの分離ポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、外向きのトラフィックが許可されないことを保証できます。このポリシーは、デフォルトの内向きの分離の振る舞いを変更しません。 ### デフォルトで外向きのすべてのトラフィックを許可する (たとえPodを「分離されたもの」として扱うポリシーが追加された場合でも)名前空間内のすべてのPodからのすべてのトラフィックを許可したい場合には、その名前空間内のすべての外向きのトラフィックを明示的に許可するポリシーを作成できます。 {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} ### デフォルトで内向きと外向きのすべてのトラフィックを拒否する 名前空間内に以下のNetworkPolicyを作成すると、その名前空間で内向きと外向きのすべてのトラフィックを拒否する「デフォルト」のポリシーを作成できます。 {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} このポリシーを利用すれば、他のいかなるNetworkPolicyにも選択されなかったPodでも、内向きと外向きのトラフィックが許可されないことを保証できます。 ## SCTPのサポート {{< feature-state for_k8s_version="v1.12" state="alpha" >}} この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。 {{< note >}} SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。 {{< /note >}} ## {{% heading "whatsnext" %}} - [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。 - NetworkPolicyリソースで実現できるよくあるシナリオのためのさまざまな[レシピ](https://github.com/ahmetb/kubernetes-network-policy-recipes)を確認する。 </ins>


The `spec` of a Pod has a `restartPolicy` field with possible values Always, OnFailure, and Never. The default value is Always. <del> The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only refers to restarts of the containers by the kubelet on the same node. After containers in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, 40s, …), that is capped at five minutes. Once a container has executed for 10 minutes without any problems, the kubelet resets the restart backoff timer for that container. </del> <ins> The `restartPolicy` for a Pod applies to {{< glossary_tooltip text="app containers" term_id="app-container" >}} in the Pod and to regular [init containers](/docs/concepts/workloads/pods/init-containers/). [Sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/) ignore the Pod-level `restartPolicy` field: in Kubernetes, a sidecar is defined as an entry inside `initContainers` that has its container-level `restartPolicy` set to `Always`. For init containers that exit with an error, the kubelet restarts the init container if the Pod level `restartPolicy` is either `OnFailure` or `Always`. When the kubelet is handling container restarts according to the configured restart policy, that only applies to restarts that make replacement containers inside the same Pod and running on the same node. After containers in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,40s, …), that is capped at five minutes. Once a container has executed for 10 minutes without any problems, the kubelet resets the restart backoff timer for that container. [Sidecar containers and Pod lifecycle](/docs/concepts/workloads/pods/sidecar-containers/#sidecar-containers-and-pod-lifecycle) explains the behaviour of `init containers` when specify `restartpolicy` field on it. </ins> ## Pod conditions


border-radius: 3px; } <ins> .td-documentation .td-content > .highlight { max-width: initial; width: 100%; } </ins> body.td-home #deprecation-warning { max-width: 1000px; margin-top: 2.5rem;


provide the apiserver with a root certificate bundle to use to verify the kubelet's serving certificate. <del> If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) </del> <ins> If that is not possible, use [SSH tunneling](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) </ins> between the apiserver and kubelet if required to avoid connecting over an untrusted or public network.


We also allow users to customize garbage collection policy through the following kubelet flags: 1. `minimum-container-ttl-duration`, minimum age for a finished container before it is <del> garbage collected. Default is 0 minute, which means any finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to retain </del> <ins> garbage collected. Default is 0 minute, which means every finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained </ins> per container. Default is 1. 3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. Default is -1, which means there is no global limit.