Question:
I wish /docs/getting-started-guides/ listed both Ubuntu guides in the Bare Metal section, noting the networking for each (the listed one uses Flannel, the omitted one (but it is in the navigation panel on the left) uses Calico).
Ubuntu is getting a big rewrite as well.

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


Question:
I wish /docs/getting-started-guides/ listed both Ubuntu guides in the Bare Metal section, noting the networking for each (the listed one uses Flannel, the omitted one (but it is in the navigation panel on the left) uses Calico).
Ubuntu is getting a big rewrite as well.

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


Question:
I wish /docs/getting-started-guides/ listed both Ubuntu guides in the Bare Metal section, noting the networking for each (the listed one uses Flannel, the omitted one (but it is in the navigation panel on the left) uses Calico).
Ubuntu is getting a big rewrite as well.

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>


Question:
I wish /docs/getting-started-guides/ listed both Ubuntu guides in the Bare Metal section, noting the networking for each (the listed one uses Flannel, the omitted one (but it is in the navigation panel on the left) uses Calico).
Ubuntu is getting a big rewrite as well.

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


Question: I wish /docs/getting-started-guides/docker/ I wish this page existed

(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


Question: I wish /docs/getting-started-guides/docker/ I wish this page existed

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


Question: I wish /docs/getting-started-guides/docker/ I wish this page existed

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


Question:
Cites looking at a cephfs example, that promptly 404's once clicked
It appears this should actually point to: not

__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


Question:
A user linked to this guide from an issue: I believe that guide is unmaintained. It still specifies k8s 1.1.2. can we delete?
Thank you. Yes, this guide was unmaintained and community contributed. I am OK with this change. devin-donnelly wrote:

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


Question:
A user linked to this guide from an issue: I believe that guide is unmaintained. It still specifies k8s 1.1.2. can we delete?
Thank you. Yes, this guide was unmaintained and community contributed. I am OK with this change. devin-donnelly wrote:

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


Question:
A user linked to this guide from an issue: I believe that guide is unmaintained. It still specifies k8s 1.1.2. can we delete?
Thank you. Yes, this guide was unmaintained and community contributed. I am OK with this change. devin-donnelly wrote:

<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


Question:
A user linked to this guide from an issue: I believe that guide is unmaintained. It still specifies k8s 1.1.2. can we delete?
Thank you. Yes, this guide was unmaintained and community contributed. I am OK with this change. devin-donnelly wrote:

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


Question:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: The port-forward command description is misleading. As a user I would expect the command to forward the complete traffic from port 6000 to 5000 locally, not only the data from both ports like the explanation in the detailed command page mentions. Proposed Solution: You could change the description to something like in the detail command description () or change the command to the version it describes. (kubectl port-forward my-pod 5000:6000 -with colon) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale

$ 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


Question:
This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: The command to create the sock-shop application error out (it's also not necessary to create the namespace beforehand as that is already define in ): Proposed Solution: Change the command to: Page to Update: Kubernetes Version: 1.6.1
I think this is an issue that needs to be fixed in socks shop.
This merged PR should resolve the issue

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


Question:
This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: The command to create the sock-shop application error out (it's also not necessary to create the namespace beforehand as that is already define in ): Proposed Solution: Change the command to: Page to Update: Kubernetes Version: 1.6.1
I think this is an issue that needs to be fixed in socks shop.
This merged PR should resolve the issue

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


Question:
This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: The command to create the sock-shop application error out (it's also not necessary to create the namespace beforehand as that is already define in ): Proposed Solution: Change the command to: Page to Update: Kubernetes Version: 1.6.1
I think this is an issue that needs to be fixed in socks shop.
This merged PR should resolve the issue

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


Question:
Problem: this page should mention concept as a way to create an external LB to an application. Page to Update:
There are some offhanded mentions of Ingress in samples, but they're likely to be more confusing than not. Agreed: more/better docs needed.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign

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


Question:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This page has extra spaces before the commands: I am not sure it's a more systemic problem, but this causes commands to not to show up on the bash history (undesirable). Proposed Solution: Page to Update: /assign
A cursory look through the rest of the docs under Configure Pods and Containers showed that one out of four docs also had this issue. I'll make this change as I update the callouts.

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


Question:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This page has extra spaces before the commands: I am not sure it's a more systemic problem, but this causes commands to not to show up on the bash history (undesirable). Proposed Solution: Page to Update: /assign
A cursory look through the rest of the docs under Configure Pods and Containers showed that one out of four docs also had this issue. I'll make this change as I update the callouts.

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.


Question:
This is a... [x] Bug Report Problem: The documentation mentions "optional" in the restrictions for configmap, but doesn't explain how to use it anywhere else in the documentation. 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. Please see for the feature. It appears it got lost in the 1.5-1.6 upgrade. Proposed Solution: Restore the copy from that wrote. Page to Update:
For clarity, the copy from got removed here:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/language en /remove-lifecycle stale /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/priority backlog
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle stale
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Relevant to /remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This awesome feature is still missing in the documentation, Can someone please add it ?
were you thinking of opening a pull request? We'd be happy to help you with that.
/remove-lifecycle stale
/lifecycle frozen
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it. Thank you! /unassign
/assign

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


Question:
This is a... [x] Bug Report Problem: The documentation mentions "optional" in the restrictions for configmap, but doesn't explain how to use it anywhere else in the documentation. 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. Please see for the feature. It appears it got lost in the 1.5-1.6 upgrade. Proposed Solution: Restore the copy from that wrote. Page to Update:
For clarity, the copy from got removed here:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/language en /remove-lifecycle stale /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/priority backlog
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle stale
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Relevant to /remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This awesome feature is still missing in the documentation, Can someone please add it ?
were you thinking of opening a pull request? We'd be happy to help you with that.
/remove-lifecycle stale
/lifecycle frozen
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it. Thank you! /unassign
/assign

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


Question:
This is a... [x] Bug Report Problem: The documentation mentions "optional" in the restrictions for configmap, but doesn't explain how to use it anywhere else in the documentation. 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. Please see for the feature. It appears it got lost in the 1.5-1.6 upgrade. Proposed Solution: Restore the copy from that wrote. Page to Update:
For clarity, the copy from got removed here:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/language en /remove-lifecycle stale /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/priority backlog
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle stale
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Relevant to /remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This awesome feature is still missing in the documentation, Can someone please add it ?
were you thinking of opening a pull request? We'd be happy to help you with that.
/remove-lifecycle stale
/lifecycle frozen
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it. Thank you! /unassign
/assign

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


Question:
This is a... [x] Bug Report Problem: The documentation mentions "optional" in the restrictions for configmap, but doesn't explain how to use it anywhere else in the documentation. 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. Please see for the feature. It appears it got lost in the 1.5-1.6 upgrade. Proposed Solution: Restore the copy from that wrote. Page to Update:
For clarity, the copy from got removed here:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/language en /remove-lifecycle stale /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/priority backlog
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle stale
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Relevant to /remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This awesome feature is still missing in the documentation, Can someone please add it ?
were you thinking of opening a pull request? We'd be happy to help you with that.
/remove-lifecycle stale
/lifecycle frozen
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it. Thank you! /unassign
/assign

- 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" %}}


Question:
This is a Bug Report This issue appeared recently within kubernetes/website. Links in follow the next pattern , see a square bracket inside of the . I tried to follow in order to find a source of the issue, but wasn't able to do so. my best guesses: Source for generation for 1_17 branch was corrupted. Backend was replaced by something else but not commited (i don't believe in this). This can be temporary content (on ein PR) as toolset for kubernetes-sigs/reference-docs .
/kind bug /priority backlog
ping
I am looking now
, you are referring to a link problem in the reference? I don't immediately see a problem. Can you provide an example of a command that has a link issue? Thanks! I see a link that appears incorrectly formatted, such as the flag in the command, Though, the link does work for me.
I plan on updating the build instructions and README.
any link that follow pattern . If we ware talking about from the root of the kubernetes-sigs/reference-docs, it would be any link in usage block. Almost all of them are anchor links, so problem isn't visible at first. search for or , last symbol of the link is clearly not suppose to be a link (at least its not a link in source yaml) P.S. Is it worth time to update build instructions now? Isn't going to change generator backend to htmlwriter?
, I have a feeling there is a miscommunication. I am not sure what you are referring to. I thought you are logging an issue specifically to the kubectl reference. Please provide a specific example.
ok. for on link to for on link yourself why is in link. diff for kubernetes/website (kubectl-) and see how links are formed. -become right bracket in the href attribute. P.S. just updated one of the search links as i forgot to copy/paste last element of the link (). P.P.S. looks like regular expression issue.
I see. I think we are referring to the same problem -- the right bracket.
Should I close issue or you prefer to have it opened untill kubernetes-sigs/reference-docs is opened?
, I would leave this issue open as a reminder for next release. Thanks! NOTE: The links were manually fixed for the 1.17 release (search/replace).
got it!

- 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


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is out of date; it talks about Kubernetes releases v1.6 and v1.8 Proposed Solution: At a minimum, remove the reference to releases v1.6 and v1.8 from the glossary entry. It's OK to revise further as well. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /kind cleanup /help /language en /priority important-longterm Also see issue
I'll work on that! /remove-help /assign

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:


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is out of date; it talks about Kubernetes releases v1.6 and v1.8 Proposed Solution: At a minimum, remove the reference to releases v1.6 and v1.8 from the glossary entry. It's OK to revise further as well. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /kind cleanup /help /language en /priority important-longterm Also see issue
I'll work on that! /remove-help /assign

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


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is out of date; it talks about Kubernetes releases v1.6 and v1.8 Proposed Solution: At a minimum, remove the reference to releases v1.6 and v1.8 from the glossary entry. It's OK to revise further as well. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /kind cleanup /help /language en /priority important-longterm Also see issue
I'll work on that! /remove-help /assign

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.


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is out of date; it talks about Kubernetes releases v1.6 and v1.8 Proposed Solution: At a minimum, remove the reference to releases v1.6 and v1.8 from the glossary entry. It's OK to revise further as well. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /kind cleanup /help /language en /priority important-longterm Also see issue
I'll work on that! /remove-help /assign

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


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Revise to signpost new contributors to Why is this needed If someone arrives at (possible from ) and has not already contributed to the website, then it's good to let them know that there is a whole section of documentation aimed at exactly that target audience. Comments /language en /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Revise to signpost new contributors to If someone arrives at (possible from ) and has not already contributed to the website, then it's good to let them know that there is a whole section of documentation aimed at exactly that target audience. /language en /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/assign

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


Question:
This is a Bug Report Problem: The text unclearly says: "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." (Note the problems, such as "Deprecated metric signal ...," "to check annotation," unclear references to versions (when metric will be gone, when declared deprecated, other?), etc.) Proposed Solution: Have a fluent English speaker (who knows Kubernetes) edit that. Page to Update:
/language en /sig instrumentation
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/triage accepted
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
I'd like to try a pass at this. /assign
Not sure if I'm able to do this, but let's try: /remove-lifecycle rotten

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


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: At Line 398, The link for "Planning your cluster and worker node setup" might seems to be changed from Proposed Solution: The link has to be changed as "". Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /assign

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


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Glossary tooltip code for "node" shouldn't be in the short_description section. It doesn't display it correctly. Proposed Solution: Change it like original document. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--Page to check:
/language ko /assign

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" >}}은 워커 노드와


Question: This is a Bug Report Problem: missing double quote (") after the word services in the last table Proposed Solution: Add the missing double quote (") Page to Update:

String	API Object

"pods"	Pod

"services	Service

"services"	Service

"replicationcontrollers"	ReplicationController

"resourcequotas"	ResourceQuota

"secrets"	Secret


Question:
I would like to have the "Container Lifecycle Hooks" page to be translated into Italian page /language it /priority important-soon
/remove-priority important-soon /priority important-longterm
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Hi I am taking this issue! :smile: /assign /lifecycle active
this can help (you can find specific instructions for the web-site) Ping me if you need help
Hi I have finished my issue! PR ! Let me know!

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


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: This line includes glossary. However, the displayed content is glossary. ! Proposed Solution: The contents should be glossary, but I don't know how. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language ja
/kind bug /priority backlog
/assign

{{- $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 -}}


Question:
At the quarterly planning meeting we agreed that we should update the PR wrangler document to be more relaxed about contributed PRs that are solid content but don't exactly meet to the style guide requirements. This was requested to help keep contributions flowing in since we are short staffed. I plan on making this update to the document.
/assign
/cc
/kind cleanup /priority important-soon

- 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


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: line 35~39, there are extra spaces(more than 4 spaces) in front of shell box. line 427~430, it should be a shell box. So, we need shell code. line 445~451, it should be a shell box. So, we need shell code. Proposed Solution: [1] : Specifies the . Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: [2] [3] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign

* `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`.


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: line 35~39, there are extra spaces(more than 4 spaces) in front of shell box. line 427~430, it should be a shell box. So, we need shell code. line 445~451, it should be a shell box. So, we need shell code. Proposed Solution: [1] : Specifies the . Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: [2] [3] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign

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


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: line 35~39, there are extra spaces(more than 4 spaces) in front of shell box. line 427~430, it should be a shell box. So, we need shell code. line 445~451, it should be a shell box. So, we need shell code. Proposed Solution: [1] : Specifies the . Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: [2] [3] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign

/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


Question:
Umbrella issue: Remove the following from L6-8:
/assign inductor
/kind cleanup
On it!
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

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


Question:
Umbrella issue: Remove the following from L6-8:
/kind cleanup
/language ko
/assign
This issue is included in also.

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


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--On the page: Under the section: Forward a local port to a port on the Pod This page suggests using kubectl port-forward to forward ports to your pod. However, kubectl port-forward does not return, it is not daemonized by default. The page does not note this fact Proposed Solution: Either: modify the page to indicate that kubectl port-forward will not return, and that the user needs to open another terminal window to continue with the exercises; OR modify the kubectl port-forward commands to include a & (ampersand) at the end of the line, so that the job will run in the background and return to the terminal prompt. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en
/assign
Maybe adding a flag to is a better way to solve this problem, such as ?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale

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


Question:
Problem: The 5 fields of the cronJob schedule format are not described on the page - there is only a link to some external documetation (). This documentation however is for a 6 field format which include an extra seconds field at the start. Also the use of in the examples isn't required because `` already means every minute. Proposed Solution: Linking to a page which describes the 5 field version of the cron format e.g. the Wikipedia page: Page to Update:
/kind bug /priority important-longterm /language en

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


Question:
Problem: The 5 fields of the cronJob schedule format are not described on the page - there is only a link to some external documetation (). This documentation however is for a 6 field format which include an extra seconds field at the start. Also the use of in the examples isn't required because `` already means every minute. Proposed Solution: Linking to a page which describes the 5 field version of the cron format e.g. the Wikipedia page: Page to Update:
/kind bug /priority important-longterm /language en

## {{% 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` 필드의 포맷을 문서화 한다. 크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의


Question:
This is a Bug Report Problem: The link (/docs/home/contribute/style/page-content-types/#concept) from the Concept page is not correct. Proposed Solution: Page to Update:
Thanks for spotting this. /kind bug /priority backlog /language en

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.


Question:
This is a Bug Report Problem: The link (/docs/home/contribute/style/page-content-types/#concept) from the Concept page is not correct. Proposed Solution: Page to Update:
Thanks for spotting this. /kind bug /priority backlog /language en

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.


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update to document that namespaces starting are reserved. Why is this needed According to all namespaces with names that start with are reserved. Comments /kind feature /language en /sig architecture /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Update to document that namespaces starting are reserved. According to all namespaces with names that start with are reserved. /kind feature /language en /sig architecture /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign me
GitHub didn't allow me to assign the following users: me. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign me </details
/assign

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:


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update to document that namespaces starting are reserved. Why is this needed According to all namespaces with names that start with are reserved. Comments /kind feature /language en /sig architecture /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Update to document that namespaces starting are reserved. According to all namespaces with names that start with are reserved. /kind feature /language en /sig architecture /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign me
GitHub didn't allow me to assign the following users: me. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign me </details
/assign

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


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Add a facility to search the website to the main page, Why is this needed Let's say someone arrives at and wants to find the download page. Well, the top 3 results on look pretty relevant. The trouble is there's no form on to do that search, and it's not obvious that navigating round the site will reveal that search. Comments Consider both desktop and mobile browser use cases. The main page is some readers' first impression of Kubernetes, so it's important to make a good one. Most people known how to use Google (other search products exist) so fixing this need not be a priority.
I think this dovetails with as well. From an implementation perspective (from what I can tell) the site uses a custom google search engine. First step would be identifying who the admin(s) of that are. Second step would be identifying what directories are scanned Third step would be including the pages we now want to include. Fourth step is fairly easy – add to the layout template you want to see a search box on. The third step requires some thought, however. If we put a search box on the homepage, is the expectation that it searches the entire_ site or just the docs+blog? From a UX perspective, if I see a search box on the homepage I kind of expect it to search everything.
The site search already covers the whole site, so this is really about adding a form to the front page.
For an example of where to put a site search on the main page, see (I'm not proposing to move the search UI there across for the whole site; that would be a separate issue).
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Also relevant: issue
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/remove-lifecycle rotten /lifecycle frozen
/triage accepted
/area web-development (ish)
/priority backlog
I'm more than happy to work on it and get this moving forward. /assign
/assign

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.


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Add a facility to search the website to the main page, Why is this needed Let's say someone arrives at and wants to find the download page. Well, the top 3 results on look pretty relevant. The trouble is there's no form on to do that search, and it's not obvious that navigating round the site will reveal that search. Comments Consider both desktop and mobile browser use cases. The main page is some readers' first impression of Kubernetes, so it's important to make a good one. Most people known how to use Google (other search products exist) so fixing this need not be a priority.
I think this dovetails with as well. From an implementation perspective (from what I can tell) the site uses a custom google search engine. First step would be identifying who the admin(s) of that are. Second step would be identifying what directories are scanned Third step would be including the pages we now want to include. Fourth step is fairly easy – add to the layout template you want to see a search box on. The third step requires some thought, however. If we put a search box on the homepage, is the expectation that it searches the entire_ site or just the docs+blog? From a UX perspective, if I see a search box on the homepage I kind of expect it to search everything.
The site search already covers the whole site, so this is really about adding a form to the front page.
For an example of where to put a site search on the main page, see (I'm not proposing to move the search UI there across for the whole site; that would be a separate issue).
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Also relevant: issue
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/remove-lifecycle rotten /lifecycle frozen
/triage accepted
/area web-development (ish)
/priority backlog
I'm more than happy to work on it and get this moving forward. /assign
/assign

<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


Question:
Umbrella issue: Take Advanced Contributing Be a PR Wrangler for a week topic and create a new page, Participating in SIG Docs PR Wranglers.
/assign /kind cleanup
/language en

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


Question:
Umbrella issue: Take Advanced Contributing Be a PR Wrangler for a week topic and create a new page, Participating in SIG Docs PR Wranglers.
/assign /kind cleanup
/language en

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