kubectl get statefulset web ``` ``` <del> NAME      DESIRED   CURRENT   AGE web       2         1         20s </del> <ins> NAME   READY   AGE web    2/2     37s </ins> ``` ### Ordered Pod creation


image again: ```shell <del> kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' </del> <ins> kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.8"}]' </ins> ``` ``` statefulset.apps/web patched


used in this tutorial. Follow the necessary steps, based on your environment, storage configuration, and provisioning method, to ensure that all storage is reclaimed. <del> {{< /note >}} </del>  No newline at end of file <ins> {{< /note >}} </ins>


spec: containers: - name: nginx <del> image: registry.k8s.io/nginx-slim:0.8 </del> <ins> image: registry.k8s.io/nginx-slim:0.7 </ins> ports: - containerPort: 80 name: web


(backward-compatible) changes to the way the Kubernetes cluster DNS server processes DNS queries, to facilitate the lookup of federated services (which span multiple Kubernetes clusters). <del> See the [Cluster Federation Administrators' Guide](/docs/admin/federation/index.md) for more </del> <ins> See the [Cluster Federation Administrators' Guide](/docs/admin/federation) for more </ins> details on Cluster Federation and multi-site support. ## References


<ins> # *Stop.  This guide has been superseded by [Minikube](../minikube/). The link below is present only for historical purposes* The document has been moved to [here](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/local-cluster/docker.md) </ins>


### SEE ALSO <del> * [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager </del> <ins> * [kubectl](../kubectl.md)	 - kubectl controls the Kubernetes cluster manager </ins> ###### Auto generated by spf13/cobra on 12-Aug-2016


__Important: You must have your own Ceph server running with the share exported before you can use it__ <del> See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/cephfs/) for more details. </del> <ins> See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/cephfs/) for more details. </ins> ### gitRepo


path: /docs/getting-started-guides/ovirt/ - title: OpenStack Heat path: /docs/getting-started-guides/openstack-heat/ <del> - title: CoreOS on Multinode Cluster path: /docs/getting-started-guides/coreos/coreos_multinode_cluster/ </del> - title: rkt section: - title: Running Kubernetes with rkt


[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates.html) this template in their cloud before proceeding with these Kubernetes deployment instructions. This guide uses an [Ansible playbook](https://github.com/runseb/ansible-kubernetes). <del> This is a completely automated, a single playbook deploys Kubernetes based on the coreOS [instructions](/docs/getting-started-guides/coreos/coreos_multinode_cluster). </del> <ins> This is completely automated, a single playbook deploys Kubernetes. </ins> This [Ansible](http://ansibleworks.com) playbook deploys Kubernetes on a CloudStack based Cloud using CoreOS images. The playbook, creates an ssh key pair, creates a security group and associated rules and finally starts coreOS instances configured via cloud-init.


<del> --- assignees: - dchen1107 --- Use the [master.yaml](/docs/getting-started-guides/coreos/cloud-configs/master.yaml) and [node.yaml](/docs/getting-started-guides/coreos/cloud-configs/node.yaml) cloud-configs to provision a multi-node Kubernetes cluster. > **Attention**: This requires at least CoreOS version **[695.0.0][coreos695]**, which includes `etcd2`. [coreos695]: https://coreos.com/releases/#695.0.0 * TOC {:toc} ### AWS *Attention:* Replace `<ami_image_id>` below for a [suitable version of CoreOS image for AWS](https://coreos.com/docs/running-coreos/cloud-providers/ec2/). #### Provision the Master ```shell aws ec2 create-security-group --group-name kubernetes --description "Kubernetes Security Group" aws ec2 authorize-security-group-ingress --group-name kubernetes --protocol tcp --port 22 --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress --group-name kubernetes --protocol tcp --port 80 --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress --group-name kubernetes --source-security-group-name kubernetes ``` ```shell aws ec2 run-instances  --image-id <ami_image_id>  --key-name <keypair>  --region us-west-2  --security-groups kubernetes  --instance-type m3.medium  --user-data file://master.yaml ``` #### Capture the private IP address ```shell aws ec2 describe-instances --instance-id <master-instance-id> ``` #### Edit node.yaml Edit `node.yaml` and replace all instances of `<master-private-ip>` with the private IP address of the master node. #### Provision worker nodes ```shell aws ec2 run-instances  --count 1  --image-id <ami_image_id>  --key-name <keypair>  --region us-west-2  --security-groups kubernetes  --instance-type m3.medium  --user-data file://node.yaml ``` ### Google Compute Engine (GCE) *Attention:* Replace `<gce_image_id>` below for a [suitable version of CoreOS image for Google Compute Engine](https://coreos.com/docs/running-coreos/cloud-providers/google-compute-engine/). #### Provision the Master ```shell gcloud compute instances create master  --image-project coreos-cloud  --image <gce_image_id>  --boot-disk-size 200GB  --machine-type n1-standard-1  --zone us-central1-a  --metadata-from-file user-data=master.yaml ``` #### Capture the private IP address ```shell gcloud compute instances list ``` #### Edit node.yaml Edit `node.yaml` and replace all instances of `<master-private-ip>` with the private IP address of the master node. #### Provision worker nodes ```shell gcloud compute instances create node1  --image-project coreos-cloud  --image <gce_image_id>  --boot-disk-size 200GB  --machine-type n1-standard-1  --zone us-central1-a  --metadata-from-file user-data=node.yaml ``` #### Establish network connectivity Next, setup an ssh tunnel to the master so you can run kubectl from your local host. In one terminal, run `gcloud compute ssh master --ssh-flag="-L 8080:127.0.0.1:8080"` and in a second run `gcloud compute ssh master --ssh-flag="-R 8080:127.0.0.1:8080"`. ### OpenStack These instructions are for running on the command line.  Most of this you can also do through the Horizon dashboard. These instructions were tested on the Ice House release on a Metacloud distribution of OpenStack but should be similar if not the same across other versions/distributions of OpenStack. #### Make sure you can connect with OpenStack Make sure the environment variables are set for OpenStack such as: ```shell OS_TENANT_ID OS_PASSWORD OS_AUTH_URL OS_USERNAME OS_TENANT_NAME ``` Test this works with something like: ```shell nova list ``` #### Get a Suitable CoreOS Image You'll need a [suitable version of CoreOS image for OpenStack](https://coreos.com/os/docs/latest/booting-on-openstack.html) Once you download that, upload it to glance.  An example is shown below: ```shell glance image-create --name CoreOS723  --container-format bare --disk-format qcow2  --file coreos_production_openstack_image.img  --is-public True ``` #### Create security group ```shell nova secgroup-create kubernetes "Kubernetes Security Group" nova secgroup-add-rule kubernetes tcp 22 22   0.0.0.0/0 nova secgroup-add-rule kubernetes tcp 80 80   0.0.0.0/0 ``` #### Provision the Master ```shell nova boot  --image <image_name>  --key-name <my_key>  --flavor <flavor id>  --security-group kubernetes  --user-data files/master.yaml  kube-master ``` `<image_name>` is the CoreOS image name. In our example we can use the image we created in the previous step and put in 'CoreOS723' `<my_key>` is the keypair name that you already generated to access the instance. `<flavor_id>` is the flavor ID you use to size the instance.  Run `nova flavor-list` to get the IDs.  3 on the system this was tested with gives the m1.large size. The important part is to ensure you have the files/master.yml as this is what will do all the post boot configuration. This path is relevant so we are assuming in this example that you are running the nova command in a directory where there is a subdirectory called files that has the master.yml file in it.  Absolute paths also work. Next, assign it a public IP address: ```shell nova floating-ip-list ``` Get an IP address that's free and run: ```shell nova floating-ip-associate kube-master <ip address> ``` where `<ip address>` is the IP address that was available from the `nova floating-ip-list` command. #### Provision Worker Nodes Edit `node.yaml` and replace all instances of `<master-private-ip>` with the private IP address of the master node.  You can get this by running `nova show kube-master` assuming you named your instance kube master.  This is not the floating IP address you just assigned it. ```shell nova boot  --image <image_name>  --key-name <my_key>  --flavor <flavor id>  --security-group kubernetes  --user-data files/node.yaml  minion01 ``` This is basically the same as the master nodes but with the node.yaml post-boot script instead of the master. </del>  No newline at end of file


These guides are maintained by community members, cover specific platforms and use cases, and experiment with different ways of configuring Kubernetes on CoreOS. <del> [**Multi-node Cluster**](/docs/getting-started-guides/coreos/coreos_multinode_cluster) Set up a single master, multi-worker cluster on your choice of platform: AWS, GCE, or VMware Fusion. <hr/> </del> [**Easy Multi-node Cluster on Google Compute Engine**](https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md) Scripted installation of a single master, multi-worker cluster on GCE. Kubernetes components are managed by [fleet](https://github.com/coreos/fleet).


$ kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case) $ kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell $ kubectl attach my-pod -i                            # Attach to Running Container <del> $ kubectl port-forward my-pod 5000:6000               # Forward port 6000 of Pod to your to 5000 on your local machine </del> <ins> $ kubectl port-forward my-pod 5000:6000               # Listen on port 5000 on the local machine and forward to port 6000 on my-pod </ins> $ kubectl exec my-pod -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec my-pod -c my-container -- ls /         # Run command in existing pod (multi-container case) $ kubectl top pod POD_NAME --containers               # Show metrics for a given pod and its containers


* GCEPersistentDisk * AWSElasticBlockStore <ins> * AzureFile * FC (Fibre Channel) </ins> * NFS * iSCSI * RBD (Ceph Block Device) <ins> * CephFS * Cinder (OpenStack block storage) </ins> * Glusterfs <ins> * VsphereVolume </ins> * HostPath (single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)


### Access Modes <del> A `PersistentVolume` can be mounted on a host in any way supported by the resource provider.  Providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only.  Each PV gets its own set of access modes describing that specific PV's capabilities. </del> <ins> A `PersistentVolume` can be mounted on a host in any way supported by the resource provider.  As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only.  Each PV gets its own set of access modes describing that specific PV's capabilities. </ins> The access modes are:


> __Important!__ A volume can only be mounted using one access mode at a time, even if it supports many.  For example, a GCEPersistentDisk can be mounted as ReadWriteOnce by a single node or ReadOnlyMany by many nodes, but not at the same time. <ins> | Volume Plugin        | ReadWriteOnce| ReadOnlyMany| ReadWriteMany| | :---                 |     :---:    |    :---:    |    :---:     | | AWSElasticBlockStore | x            | -           | -            | | AzureFile            | x            | x           | x            | | CephFS               | x            | x           | x            | | Cinder               | x            | -           | -            | | FC                   | x            | x           | -            | | FlexVolume           | x            | x           | -            | | GCEPersistentDisk    | x            | x           | -            | | Glusterfs            | x            | x           | x            | | HostPath             | x            | -           | -            | | iSCSI                | x            | x           | -            | | NFS                  | x            | x           | x            | | RDB                  | x            | x           | -            | | VsphereVolume        | x            | -           | -            | </ins> ### Recycling Policy Current recycling policies are:


This page shows how to create an External Load Balancer. When creating a service, you have the option of automatically creating a <del> cloud network load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_. </del> <ins> cloud network load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_. For information on provisioning and using an Ingress resource that can give services externally-reachable URLs, load balance the traffic, terminate SSL etc., please check the [Ingress](/docs/concepts/services-networking/ingress/) documentation. </ins> {% endcapture %}


1. Create the Pod: <del> kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml </del> <ins> kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml </ins> 1. Verify that the Pod's Container is running, and then watch for changes to the Pod: <del> kubectl get --watch pod redis </del> <ins> kubectl get --watch pod redis </ins> The output looks like this: <del> NAME      READY     STATUS    RESTARTS   AGE redis     1/1       Running   0          13s </del> <ins> NAME      READY     STATUS    RESTARTS   AGE redis     1/1       Running   0          13s </ins> 1. In another terminal, get a shell to the running Container: <del> kubectl exec -it redis -- /bin/bash </del> <ins> kubectl exec -it redis -- /bin/bash </ins> 1. In your shell, go to `/data/redis`, and create a file: <del> root@redis:/data/redis# echo Hello > test-file </del> <ins> root@redis:/data/redis# echo Hello > test-file </ins> 1. In your shell, list the running processes: <del> root@redis:/data/redis# ps aux </del> <ins> root@redis:/data/redis# ps aux </ins> The output is similar to this: <del> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379 root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux </del> <ins> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379 root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux </ins> 1. In your shell, kill the redis process: <del> root@redis:/data/redis# kill <pid> </del> <ins> root@redis:/data/redis# kill <pid> </ins> where `<pid>` is the redis process ID (PID). 1. In your original terminal, watch for changes to the redis Pod. Eventually, you will see something like this: <del> NAME      READY     STATUS     RESTARTS   AGE redis     1/1       Running    0          13s redis     0/1       Completed  0         6m redis     1/1       Running    1         6m </del> <ins> NAME      READY     STATUS     RESTARTS   AGE redis     1/1       Running    0          13s redis     0/1       Completed  0         6m redis     1/1       Running    1         6m </ins> At this point, the Container has terminated and restarted. This is because the redis Pod has a


1. Get a shell into the restarted Container: <del> kubectl exec -it redis -- /bin/bash </del> <ins> kubectl exec -it redis -- /bin/bash </ins> 1. In your shell, goto `/data/redis`, and verify that `test-file` is still there.


<!-- overview --> Many applications rely on configuration which is used during either application initialization or runtime. Most of the times there is a requirement to adjust values assigned to configuration parameters. <del> ConfigMaps is the kubernetes way to inject application pods with configuration data. </del> <ins> ConfigMaps are the Kubernetes way to inject application pods with configuration data. </ins> ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.


You can project keys to specific paths and specific permissions on a per-file basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax. <del> ### Optional References A ConfigMap reference may be marked "optional".  If the ConfigMap is non-existent, the mounted volume will be empty. If the ConfigMap exists, but the referenced key is non-existent the path will be absent beneath the mount point. ### Mounted ConfigMaps are updated automatically When a mounted ConfigMap is updated, the projected content is eventually updated too.  This applies in the case where an optionally referenced ConfigMap comes into existence after a pod has started. Kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. {{< note >}} A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. {{< /note >}} </del> <!-- discussion -->


### Restrictions <del> - You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. </del> <ins> - You must create a ConfigMap before referencing it in a Pod specification, or mark the ConfigMap as "optional" (see [Optional ConfigMaps](#optional-configmaps)). If you reference a ConfigMap that doesn't exist, or hasn't been marked as "optional" the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. </ins> - If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:


- You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this. <ins> ### Optional ConfigMaps In a Pod, or pod template, you can mark a reference to a ConfigMap as _optional_. If the ConfigMap is non-existent, the configuration for which it provides data in the Pod (e.g. environment variable, mounted volume) will be empty. If the ConfigMap exists, but the referenced key is non-existent the data is also empty. #### Optional ConfigMap in environment variables There might be situations where environment variables are not always required. You can mark an environment variables for a container as optional, like this: ```yaml apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: gcr.io/google_containers/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: a-config key: akey optional: true # mark the variable as optional restartPolicy: Never ``` If you run this pod, and there is no ConfigMap named `a-config`, the output is empty. If you run this pod, and there is a ConfigMap named `a-config` but that ConfigMap doesn't have a key named `akey`, the output is also empty. If you do set a value for `akey` in the `a-config` ConfigMap, this pod prints that value and then terminates. #### Optional ConfigMap via volume plugin Volumes and files provided by a ConfigMap can be also be marked as optional. The ConfigMap or the key specified does not have to exist. The mount path for such items will always be created. ```yaml apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: gcr.io/google_containers/busybox command: [ "/bin/sh", "-c", "ls /etc/config" ] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: no-config optional: true # mark the source ConfigMap as optional restartPolicy: Never ``` If you run this pod, and there is no ConfigMap named `no-config`, the mounted volume will be empty. ### Mounted ConfigMaps are updated automatically When a mounted ConfigMap is updated, the projected content is eventually updated too.  This applies in the case where an optionally referenced ConfigMap comes into existence after a pod has started. The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. {{< note >}} A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. {{< /note >}} </ins> ## {{% heading "whatsnext" %}}


- title: kube-proxy CLI path: /docs/admin/kube-proxy/ <del> - title: kub-scheduler CLI </del> <ins> - title: kube-scheduler CLI </ins> path: /docs/admin/kube-scheduler/ - title: kubelet CLI


date: 2018-04-12 full_link: /docs/tasks/administer-cluster/running-cloud-controller/ short_description: > <del> Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. </del> <ins> Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic. </ins> aka: tags:


- architecture - operation --- <del> Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. </del> <ins> Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic. </ins> <!--more--> <del> Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code. </del> <ins> Originally part of the kube-controller-manager, the cloud-controller-manager is responsible to decoupling the interoperability logic between Kubernetes and the underlying cloud infrastructure, enabling cloud providers to release features at a different pace compared to the main project. </ins>


title: HostAliases id: HostAliases date: 2019-01-31 <del> full_link: /docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-core </del> <ins> full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core </ins> short_description: > A HostAliases is a mapping between the IP address and hostname to be injected into a Pod's hosts file.


<!--more--> <del> [HostAliases](/docs/reference/generated/kubernetes-api/v1.13/#hostalias-v1-corev) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. </del> <ins> [HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) is an optional list of hostnames and IP addresses that will be injected into the Pod's hosts file if specified. This is only valid for non-hostNetwork Pods. </ins>


### Submitting Documentation Pull Requests If you're fixing an issue in the existing documentation, you should submit a PR against the master branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/). <ins> For more information, see [contributing to Kubernetes docs](https://kubernetes.io/docs/contribute/). </ins>


## Metric lifecycle <del> Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deletion </del> <ins> Alpha metric →  Stable metric →  Deprecated metric →  Hidden metric → Deleted metric </ins> <del> Alpha metrics have no stability guarantees; as such they can be modified or deleted at any time. </del> <ins> Alpha metrics have no stability guarantees. These metrics can be modified or deleted at any time. </ins> <del> Stable metrics can be guaranteed to not change; Specifically, stability means: </del> <ins> Stable metrics are guaranteed to not change. This means: * A stable metric without a deprecated signature will not be deleted or renamed * A stable metric's type will not be modified </ins> <del> * the metric itself will not be deleted (or renamed) * the type of metric will not be modified </del> <ins> Deprecated metrics are slated for deletion, but are still available for use. These metrics include an annotation about the version in which they became deprecated. </ins> <del> Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated. </del> <ins> For example: </ins> <del> Before deprecation: </del> <ins> * Before deprecation </ins> <del> ``` # HELP some_counter this counts things # TYPE some_counter counter some_counter 0 ``` </del> <ins> ``` # HELP some_counter this counts things # TYPE some_counter counter some_counter 0 ``` </ins> <del> After deprecation: </del> <ins> * After deprecation </ins> <del> ``` # HELP some_counter (Deprecated since 1.15.0) this counts things # TYPE some_counter counter some_counter 0 ``` </del> <ins> ``` # HELP some_counter (Deprecated since 1.15.0) this counts things # TYPE some_counter counter some_counter 0 ``` </ins> <del> Once a metric is hidden then by default the metrics is not published for scraping. To use a hidden metric, you need to override the configuration for the relevant cluster component. </del> <ins> Hidden metrics are no longer published for scraping, but are still available for use. To use a hidden metric, please refer to the [Show hidden metrics](#show-hidden-metrics) section. </ins> <del> Once a metric is deleted, the metric is not published. You cannot change this using an override. </del> <ins> Deleted metrics are no longer published and cannot be used. </ins> <del> ## Show Hidden Metrics </del> <ins> ## Show hidden metrics </ins> As described above, admins can enable hidden metrics through a command-line flag on a specific binary. This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.


## IBM Cloud Kubernetes Service ### Compute nodes <del> By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). </del> <ins> By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes). </ins> The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.


title: 클러스터(Cluster) id: cluster date: 2019-06-15 <del> full_link: </del> <ins> full_link: </ins> short_description: > <del> 컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </del> <ins> 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </ins> aka: tags: - fundamental - operation --- <del> 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </del> <ins> 컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </ins> <del> <!--more--> </del> <ins> <!--more--> </ins> 워커 노드는 애플리케이션의 구성요소인 {{< glossary_tooltip text="파드" term_id="pod" >}}를 호스트한다. {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 워커 노드와


String	API Object

"pods"	Pod

"services	Service

"services"	Service

"replicationcontrollers"	ReplicationController

"resourcequotas"	ResourceQuota

"secrets"	Secret


<ins> --- title: Container Lifecycle Hooks content_type: concept weight: 30 --- <!-- overview --> Questa pagina descrive come i Container gestiti con kubelet possono utilizzare il lifecycle hook framework dei Container per l'esecuzione di codice eseguito in corrispondenza di alcuni eventi durante il loro ciclo di vita. <!-- body --> ## Overview Analogamente a molti framework di linguaggi di programmazione che hanno degli hooks legati al ciclo di vita dei componenti, come ad esempio Angular, Kubernetes fornisce ai Container degli hook legati al loro ciclo di vita dei Container. Gli hook consentono ai Container di essere consapevoli degli eventi durante il loro ciclo di gestione ed eseguire del codice implementato in un handler quando il corrispondente hook viene eseguito. ## Container hooks Esistono due tipi di hook che vengono esposti ai Container: `PostStart` Questo hook viene eseguito successivamente alla creazione del container. Tuttavia, non vi è garanzia che questo hook venga eseguito prima dell'ENTRYPOINT del container. Non vengono passati parametri all'handler. `PreStop` Questo hook viene eseguito prima della terminazione di un container a causa di una richiesta API o di un evento di gestione, come ad esempio un fallimento delle sonde di liveness/startup, preemption, risorse contese e altro. Una chiamata all'hook di `PreStop` fallisce se il container è in stato terminated o completed e l'hook deve finire prima che possa essere inviato il segnale di TERM per fermare il container. Il conto alla rovescia per la terminazione del Pod (grace period) inizia prima dell'esecuzione dell'hook `PreStop`, quindi indipendentemente dall'esito dell'handler, il container terminerà entro il grace period impostato. Non vengono passati parametri all'handler. Una descrizione più dettagliata riguardante al processo di terminazione dei Pod può essere trovata in [Terminazione dei Pod](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). ### Implementazione degli hook handler I Container possono accedere a un hook implementando e registrando un handler per tale hook. Ci sono due tipi di handler che possono essere implementati per i Container: * Exec - Esegue un comando specifico, tipo `pre-stop.sh`, all'interno dei cgroup e namespace del Container. Le risorse consumate dal comando vengono contate sul Container. * HTTP - Esegue una richiesta HTTP verso un endpoint specifico del Container. ### Esecuzione dell'hook handler Quando viene richiamato l'hook legato al lifecycle del Container, il sistema di gestione di Kubernetes esegue l'handler secondo l'azione dell'hook, `httpGet` e `tcpSocket` vengono eseguiti dal processo kubelet, mentre `exec` è eseguito nel Container. Le chiamate agli handler degli hook sono sincrone rispetto al contesto del Pod che contiene il Container. Questo significa che per un hook `PostStart`, l'ENTRYPOINT e l'hook si attivano in modo asincrono. Tuttavia, se l'hook impiega troppo tempo per essere eseguito o si blocca, il container non può raggiungere lo stato di `running`. Gli hook di `PreStop` non vengono eseguiti in modo asincrono dall'evento di stop del container; l'hook deve completare la sua esecuzione prima che l'evento TERM possa essere inviato. Se un hook di `PreStop` si blocca durante la sua esecuzione, la fase del Pod rimarrà `Terminating` finchè il Pod non sarà rimosso forzatamente dopo la scadenza del suo `terminationGracePeriodSeconds`. Questo grace period si applica al tempo totale necessario per effettuare sia l'esecuzione dell'hook di `PreStop` che per l'arresto normale del container. Se, per esempio, il `terminationGracePeriodSeconds` è di 60, e l'hook impiega 55 secondi per essere completato, e il container impiega 10 secondi per fermarsi normalmente dopo aver ricevuto il segnale, allora il container verrà terminato prima di poter completare il suo arresto, poiché `terminationGracePeriodSeconds` è inferiore al tempo totale (55+10) necessario perché queste due cose accadano. Se un hook `PostStart` o `PreStop` fallisce, allora il container viene terminato. Gli utenti dovrebbero mantenere i loro handler degli hook i più leggeri possibili. Ci sono casi, tuttavia, in cui i comandi di lunga durata hanno senso, come il salvataggio dello stato del container prima della sua fine. ### Garanzia della chiamata dell'hook La chiamata degli hook avviene *almeno una volta*, il che significa che un hook può essere chiamato più volte da un dato evento, come per `PostStart` o `PreStop`. Sta all'implementazione dell'hook gestire correttamente questo aspetto. Generalmente, vengono effettuate singole chiamate agli hook. Se, per esempio, la destinazione di hook HTTP non è momentaneamente in grado di ricevere traffico, non c'è alcun tentativo di re invio. In alcuni rari casi, tuttavia, può verificarsi una doppia chiamata. Per esempio, se un kubelet si riavvia nel mentre dell'invio di un hook, questo potrebbe essere chiamato per una seconda volta dopo che il kubelet è tornato in funzione. ### Debugging Hook handlers I log di un handler di hook non sono esposti negli eventi del Pod. Se un handler fallisce per qualche ragione, trasmette un evento. Per il `PostStart`, questo è l'evento di `FailedPostStartHook`, e per il `PreStop`, questo è l'evento di `FailedPreStopHook`. Puoi vedere questi eventi eseguendo `kubectl describe pod <pod_name>`. Ecco alcuni esempi di output di eventi dall'esecuzione di questo comando: ``` Events: FirstSeen  LastSeen  Count  From                                                   SubObjectPath          Type      Reason               Message ---------  --------  -----  ----                                                   -------------          --------  ------               ------- 1m         1m        1      {default-scheduler }                                                          Normal    Scheduled            Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd 1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulling              pulling image "test:1.0" 1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Created              Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] 1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulled               Successfully pulled image "test:1.0" 1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Started              Started container with docker id 5c6a256a2567 38s        38s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 37s        37s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 38s        37s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                         Warning   FailedSync           Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" 1m         22s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Warning   FailedPostStartHook ``` ## {{% heading "whatsnext" %}} * Approfondisci [Container environment](/docs/concepts/containers/container-environment/). * Esegui un tutorial su come [definire degli handlers per i Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). </ins>


{{- $prepend := .Get "prepend" }} {{- $glossaryBundle := site.GetPage "page" "docs/reference/glossary" -}} {{- $glossaryItems :=  $glossaryBundle.Resources.ByType "page" -}} <del> {{- $term_info := $glossaryItems.GetMatch (printf "%s*" $id ) -}} </del> <ins> {{- $term_info := $glossaryItems.GetMatch (printf "%s.md" $id ) -}} </ins> {{- if not $term_info -}} {{- errorf "[%s] %q: %q is not a valid glossary term_id, see ./docs/reference/glossary/* for a full list" site.Language.Lang .Page.Path $id -}} {{- end -}}


- Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - Assign `/lgtm` and `/approve` labels to PRs that can be merged. - Merge PRs when they are ready, or close PRs that shouldn’t be accepted. <ins> - Consider accepting accurate technical content even if the content meets only some of the docs' [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. </ins> - Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. ### Helpful GitHub queries for wranglers


* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: <del> ```shell kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1 ``` </del> <ins> ```shell kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1 ``` </ins> * `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`.


hello world ``` <del> ``` </del> <ins> ```shell </ins> # we can "uninstall" a plugin, by simply removing it from our PATH sudo rm /usr/local/bin/kubectl-hello ```


/usr/local/bin/kubectl-foo /usr/local/bin/kubectl-bar ``` <del> ``` </del> <ins> ```shell </ins> # this command can also warn us about plugins that are # not executable, or that are overshadowed by other # plugins, for example


abstract: "自動化されたコンテナのデプロイ・スケール・管理" cid: home --- <del> {{< announcement >}} {{< deprecationwarning >}} </del> {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}}


abstract: "자동화된 컨테이너 배포, 스케일링과 관리" cid: home --- <del> {{< announcement >}} {{< deprecationwarning >}} </del> {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}}


I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379 ``` <ins> {{< note >}} `kubectl port-forward` does not return. To continue with the exercises, you will need to open another terminal. {{< /note >}} </ins> 2.  Start the Redis command line interface: ```shell


## {{% heading "whatsnext" %}} <del> [Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format) </del> <ins> [Cron expression format](https://en.wikipedia.org/wiki/Cron) </ins> documents the format of CronJob `schedule` fields. For instructions on creating and working with cron jobs, and for an example of CronJob


## {{% heading "whatsnext" %}} <del> [크론 표현 포맷](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)은 </del> <ins> [크론 표현 포맷](https://ko.wikipedia.org/wiki/Cron)은 </ins> 크론잡 `schedule` 필드의 포맷을 문서화 한다. 크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의


If you would like to write a concept page, see <del> [Page Content Types](/docs/home/contribute/style/page-content-types/#concept) </del> <ins> [Page Content Types](/docs/contribute/style/page-content-types/#concept) </ins> for information about the concept page types.


If you would like to write a tutorial, see <del> [Content Page Types](/docs/home/contribute/style/page-content-types/) </del> <ins> [Content Page Types](/docs/contribute/style/page-content-types/) </ins> for information about the tutorial page type.


Creation and deletion of namespaces are described in the [Admin Guide documentation for namespaces](/docs/admin/namespaces). <ins> {{< note >}} Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. {{< /note >}} </ins> ### Viewing namespaces You can list the current namespaces in a cluster using:


## Creating a new namespace <ins> {{< note >}} Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. {{< /note >}} </ins> 1. Create a new YAML file called `my-namespace.yaml` with the contents: ```yaml


priority: 1.0 --- <ins> {{< site-searchbar >}} </ins> {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} [Kubernetes]({{< relref "/docs/concepts/overview/" >}}), also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.


<ins> <div class="col-sm-6 col-md-6 col-lg-6 mx-auto py-3"> {{partial "search-input" .}} </div> </ins>  No newline at end of file


<!-- body --> <del> ## Be the PR Wrangler for a week SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository. The PR wrangler’s duties include: - Review [open pull requests](https://github.com/kubernetes/website/pulls) daily for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides. - Review the smallest PRs (`size/XS`) first, then iterate towards the largest (`size/XXL`). - Review as many PRs as you can. - Ensure that the CLA is signed by each contributor. - Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA. - Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs. - Provide inline suggestions on the PR for the proposed content changes. - If you need to verify content, comment on the PR and request more details. - Assign relevant `sig/` label(s). - If needed, assign reviewers from the `reviewers:` block in the file's front matter. - Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status. - Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed. - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - Assign `/lgtm` and `/approve` labels to PRs that can be merged. - Merge PRs when they are ready, or close PRs that shouldn’t be accepted. - Consider accepting accurate technical content even if the content meets only some of the docs' [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. - Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. ### Helpful GitHub queries for wranglers The following queries are helpful when wrangling. After working through these queries, the remaining list of PRs to be reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one). - [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): Remind the contributor to sign the CLA. If they have already been reminded by both the bot and a human, close the PR and remind them that they can open it after signing the CLA. **Do not review PRs whose authors have not signed the CLA!** - [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): If it needs technical review, loop in one of the reviewers suggested by the bot. If it needs docs review or copy-editing, either suggest changes or add a copyedit commit to the PR to move it along. - [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`. - [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): If it’s a small PR against master with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]). - [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @<meister's_github-username>`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch. ### When to close Pull Requests Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. - Close any PR where the CLA hasn’t been signed for two weeks. PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA. - Close any PR where the author has not responded to comments or feedback in 2 or more weeks. Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution. To close a pull request, leave a `/close` comment on the PR. {{< note >}} An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity. {{< /note >}} </del> ## Propose improvements SIG Docs [members](/docs/contribute/participating/#members) can propose improvements.


When you’re ready to stop recording, click Stop. <del> The video uploads automatically to YouTube. </del> <ins> The video uploads automatically to YouTube. </ins>  No newline at end of file


<ins> --- title: PR wranglers content_type: concept weight: 20 --- <!-- overview --> SIG Docs [approvers](/docs/contribute/participating/roles-and-responsibilites/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository. This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/). <!-- body --> ## Duties Each day in a week-long shift as PR Wrangler: - Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata. - Review [open pull requests](https://github.com/kubernetes/website/pulls) for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides. - Start with the smallest PRs (`size/XS`) first, and end with the largest (`size/XXL`). Review as many PRs as you can. - Make sure PR contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md). - Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to remind contributors that haven’t signed the CLA to do so. - Provide feedback on changes and ask for technical reviews from members of other SIGs. - Provide inline suggestions on the PR for the proposed content changes. - If you need to verify content, comment on the PR and request more details. - Assign relevant `sig/` label(s). - If needed, assign reviewers from the `reviewers:` block in the file's front matter. - Use the `/approve` comment to approve a PR for merging. Merge the PR when ready. - PRs should have a `/lgtm` comment from another member before merging. - Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns. ### Helpful GitHub queries for wranglers The following queries are helpful when wrangling. After working through these queries, the remaining list of PRs to review is usually small. These queries exclude localization PRs. All queries are against the main branch except the last one. - [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close the PR and remind them that they can open it after signing the CLA. **Do not review PRs whose authors have not signed the CLA!** - [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line. - [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): Lists PRs that need an `/approve` comment to merge. - [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]). - [Not against the main branch](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @<manager's_github-username>`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch. ### When to close Pull Requests Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure. Close PRs where: - The author hasn't signed the CLA for two weeks. Authors can reopen the PR after signing the CLA. This is a low-risk way to make sure nothing gets merged without a signed CLA. - The author has not responded to comments or feedback in 2 or more weeks. Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Often a closure notice is what spurs an author to resume and finish their contribution. To close a pull request, leave a `/close` comment on the PR. {{< note >}} The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them.  PR wranglers should close issues after 14-30 days of inactivity. {{< /note >}} </ins>  No newline at end of file


- Visit the Netlify page preview for a PR to make sure things look good before approving. - Participate in the [PR Wrangler rotation schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for weekly rotations. SIG Docs expects all approvers to participate in this <del> rotation. See [Be the PR Wrangler for a week](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) </del> <ins> rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/). </ins> for more details. ### Becoming an approver


2. Assign the PR to one or more current SIG Docs approvers. <del> If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. </del>  No newline at end of file <ins> If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests. ## {{% heading "whatsnext" %}} - Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation. </ins>  No newline at end of file


--- <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


* CronJob * [Services](/ja/docs/concepts/services-networking/service/) <del> A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. You can use services for cross-operating system connectivity. In Windows, services can utilize the following types, properties and capabilities: </del> <ins> Kubernetes Serviceは、Podの論理セットとPodにアクセスするためのポリシーを定義する抽象概念です。マイクロサービスと呼ばれることもあります。オペレーティングシステム間の接続にServiceを使用できます。WindowsでのServiceは、次のタイプ、プロパティと機能を利用できます。: </ins> <del> * Service Environment variables </del> <ins> * サービス環境変数 </ins> * NodePort * ClusterIP * LoadBalancer * ExternalName * Headless services <del> Pods, Controllers and Services are critical elements to managing Windows workloads on Kubernetes. However, on their own they are not enough to enable the proper lifecycle management of Windows workloads in a dynamic cloud native environment. We added support for the following features: </del> <ins> Pod、Controller、Serviceは、KubernetesでWindowsワークロードを管理するための重要な要素です。ただし、それだけでは、動的なクラウドネイティブ環境でWindowsワークロードの適切なライフサイクル管理を可能にするのに十分ではありません。次の機能のサポートを追加しました： </ins> <del> * Pod and container metrics * Horizontal Pod Autoscaler support </del> <ins> * Podとコンテナのメトリクス * Horizontal Pod Autoscalerサポート </ins> * kubectl Exec <del> * Resource Quotas * Scheduler preemption </del> <ins> * リソースクウォータ * Schedulerのプリエンプション </ins> <del> #### Container Runtime </del> <ins> #### コンテナランタイム </ins> <del> Docker EE-basic 18.09 is required on Windows Server 2019 / 1809 nodes for Kubernetes. This works with the dockershim code included in the kubelet. Additional runtimes such as CRI-ContainerD may be supported in later Kubernetes versions. </del> <ins> KubernetesのWindows Server 2019/1809ノードでは、Docker EE-basic 18.09が必要です。これは、kubeletに含まれているdockershimコードで動作します。CRI-ContainerDなどの追加のランタイムは、Kubernetesの以降のバージョンでサポートされる可能性があります。 </ins> <del> #### Persistent Storage </del> <ins> #### 永続化ストレージ </ins> <del> Kubernetes [volumes](/docs/concepts/storage/volumes/) enable complex applications, with data persistence and Pod volume sharing requirements, to be deployed on Kubernetes. Management of persistent volumes associated with a specific storage back-end or protocol includes actions such as: provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod that needs to persist data. The code implementing these volume management actions for a specific storage back-end or protocol is shipped in the form of a Kubernetes volume [plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: </del> <ins> Kubernetes[ボリューム](/docs/concepts/storage/volumes/)を使用すると、データの永続性とPodボリュームの共有要件を備えた複雑なアプリケーションをKubernetesにデプロイできます。特定のストレージバックエンドまたはプロトコルに関連付けられた永続化ボリュームの管理には、ボリュームのプロビジョニング/プロビジョニング解除/サイズ変更、Kubernetesノードへのボリュームのアタッチ/デタッチ、およびデータを永続化する必要があるPod内の個別のコンテナへのボリュームのマウント/マウント解除などのアクションが含まれます。特定のストレージバックエンドまたはプロトコルに対してこれらのボリューム管理アクションを実装するコードは、Kubernetesボリューム[プラグイン](/docs/concepts/storage/volumes/#types-of-volumes)の形式で出荷されます。次の幅広いクラスのKubernetesボリュームプラグインがWindowsでサポートされています。: </ins> <del> ##### In-tree Volume Plugins Code associated with in-tree volume plugins ship as part of the core Kubernetes code base. Deployment of in-tree volume plugins do not require installation of additional scripts or deployment of separate containerized plugin components. These plugins can handle: provisioning/de-provisioning and resizing of volumes in the storage backend, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. The following in-tree plugins support Windows nodes: </del> <ins> ##### In-treeボリュームプラグイン In-treeボリュームプラグインに関連付けられたコードは、コアKubernetesコードベースの一部として提供されます。In-treeボリュームプラグインのデプロイでは、追加のスクリプトをインストールしたり、個別のコンテナ化されたプラグインコンポーネントをデプロイしたりする必要はありません。これらのプラグインは、ストレージバックエンドでのボリュームのプロビジョニング/プロビジョニング解除とサイズ変更、Kubernetesノードへのボリュームのアタッチ/アタッチ解除、Pod内の個々のコンテナーへのボリュームのマウント/マウント解除を処理できます。次のIn-treeプラグインは、Windowsノードをサポートしています。: </ins> * [awsElasticBlockStore](/docs/concepts/storage/volumes/#awselasticblockstore) * [azureDisk](/docs/concepts/storage/volumes/#azuredisk)