Question: <ins> --- reviewers: - stclair title: Restrict a Container's Access to Resources with AppArmor content_type: tutorial weight: 10 --- <!-- overview --> {{< feature-state for_k8s_version="v1.4" state="beta" >}} AppArmor is a Linux kernel security module that supplements the standard Linux user and group based permissions to confine programs to a limited set of resources. AppArmor can be configured for any application to reduce its potential attack surface and provide greater in-depth defense. It is configured through profiles tuned to allow the access needed by a specific program or container, such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either *enforcing* mode, which blocks access to disallowed resources, or *complain* mode, which only reports violations. AppArmor can help you to run a more secure deployment by restricting what containers are allowed to do, and/or provide better auditing through system logs. However, it is important to keep in mind that AppArmor is not a silver bullet and can only do so much to protect against exploits in your application code. It is important to provide good, restrictive profiles, and harden your applications and cluster from other angles as well. ## {{% heading "objectives" %}} * See an example of how to load a profile on a node * Learn how to enforce the profile on a Pod * Learn how to check that the profile is loaded * See what happens when a profile is violated * See what happens when a profile cannot be loaded ## {{% heading "prerequisites" %}} Make sure: 1. Kubernetes version is at least v1.4 -- Kubernetes support for AppArmor was added in v1.4. Kubernetes components older than v1.4 are not aware of the new AppArmor annotations, and will **silently ignore** any AppArmor settings that are provided. To ensure that your Pods are receiving the expected protections, it is important to verify the Kubelet version of your nodes: ```shell kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}n{end}' ``` ``` gke-test-default-pool-239f5d02-gyn2: v1.4.0 gke-test-default-pool-239f5d02-x1kf: v1.4.0 gke-test-default-pool-239f5d02-xwux: v1.4.0 ``` 2. AppArmor kernel module is enabled -- For the Linux kernel to enforce an AppArmor profile, the AppArmor kernel module must be installed and enabled. Several distributions enable the module by default, such as Ubuntu and SUSE, and many others provide optional support. To check whether the module is enabled, check the `/sys/module/apparmor/parameters/enabled` file: ```shell cat /sys/module/apparmor/parameters/enabled Y ``` If the Kubelet contains AppArmor support (>= v1.4), it will refuse to run a Pod with AppArmor options if the kernel module is not enabled. {{< note >}} Ubuntu carries many AppArmor patches that have not been merged into the upstream Linux kernel, including patches that add additional hooks and features. Kubernetes has only been tested with the upstream version, and does not promise support for other features. {{< /note >}} 3. Container runtime supports AppArmor -- Currently all common Kubernetes-supported container runtimes should support AppArmor, like {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="cri-o" >}} or {{< glossary_tooltip term_id="containerd" >}}. Please refer to the corresponding runtime documentation and verify that the cluster fulfills the requirements to use AppArmor. 4. Profile is loaded -- AppArmor is applied to a Pod by specifying an AppArmor profile that each container should be run with. If any of the specified profiles is not already loaded in the kernel, the Kubelet (>= v1.4) will reject the Pod. You can view which profiles are loaded on a node by checking the `/sys/kernel/security/apparmor/profiles` file. For example: ```shell ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort" ``` ``` apparmor-test-deny-write (enforce) apparmor-test-audit-write (enforce) docker-default (enforce) k8s-nginx (enforce) ``` For more details on loading profiles on nodes, see [Setting up nodes with profiles](#setting-up-nodes-with-profiles). As long as the Kubelet version includes AppArmor support (>= v1.4), the Kubelet will reject a Pod with AppArmor options if any of the prerequisites are not met. You can also verify AppArmor support on nodes by checking the node ready condition message (though this is likely to be removed in a later release): ```shell kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}n{end}' ``` ``` gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled ``` <!-- lessoncontent --> ## Securing a Pod {{< note >}} AppArmor is currently in beta, so options are specified as annotations. Once support graduates to general availability, the annotations will be replaced with first-class fields (more details in [Upgrade path to GA](#upgrade-path-to-general-availability)). {{< /note >}} AppArmor profiles are specified *per-container*. To specify the AppArmor profile to run a Pod container with, add an annotation to the Pod's metadata: ```yaml container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref> ``` Where `<container_name>` is the name of the container to apply the profile to, and `<profile_ref>` specifies the profile to apply. The `profile_ref` can be one of: * `runtime/default` to apply the runtime's default profile * `localhost/<profile_name>` to apply the profile loaded on the host with the name `<profile_name>` * `unconfined` to indicate that no profiles will be loaded See the [API Reference](#api-reference) for the full details on the annotation and profile name formats. Kubernetes AppArmor enforcement works by first checking that all the prerequisites have been met, and then forwarding the profile selection to the container runtime for enforcement. If the prerequisites have not been met, the Pod will be rejected, and will not run. To verify that the profile was applied, you can look for the AppArmor security option listed in the container created event: ```shell kubectl get events | grep Created ``` ``` 22s        22s         1         hello-apparmor     Pod       spec.containers{hello}   Normal    Created     {kubelet e2e-test-stclair-node-pool-31nt}   Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] ``` You can also verify directly that the container's root process is running with the correct profile by checking its proc attr: ```shell kubectl exec <pod_name> cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) ``` ## Example *This example assumes you have already set up a cluster with AppArmor support.* First, we need to load the profile we want to use onto our nodes. This profile denies all file writes: ```shell #include <tunables/global> profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, } ``` Since we don't know where the Pod will be scheduled, we'll need to load the profile on all our nodes. For this example we'll use SSH to install the profiles, but other approaches are discussed in [Setting up nodes with profiles](#setting-up-nodes-with-profiles). ```shell NODES=( # The SSH-accessible domain names of your nodes gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s) for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF #include <tunables/global> profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, } EOF' done ``` Next, we'll run a simple "Hello AppArmor" pod with the deny-write profile: {{< codenew file="pods/security/hello-apparmor.yaml" >}} ```shell kubectl create -f ./hello-apparmor.yaml ``` If we look at the pod events, we can see that the Pod container was created with the AppArmor profile "k8s-apparmor-example-deny-write": ```shell kubectl get events | grep hello-apparmor ``` ``` 14s        14s         1         hello-apparmor   Pod                                Normal    Scheduled   {default-scheduler }                           Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2 14s        14s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulling     {kubelet gke-test-default-pool-239f5d02-gyn2}   pulling image "busybox" 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulled      {kubelet gke-test-default-pool-239f5d02-gyn2}   Successfully pulled image "busybox" 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Created     {kubelet gke-test-default-pool-239f5d02-gyn2}   Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] 13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Started     {kubelet gke-test-default-pool-239f5d02-gyn2}   Started container with docker id 06b6cd1c0989 ``` We can verify that the container is actually running with that profile by checking its proc attr: ```shell kubectl exec hello-apparmor -- cat /proc/1/attr/current ``` ``` k8s-apparmor-example-deny-write (enforce) ``` Finally, we can see what happens if we try to violate the profile by writing to a file: ```shell kubectl exec hello-apparmor -- touch /tmp/test ``` ``` touch: /tmp/test: Permission denied error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1 ``` To wrap up, let's look at what happens if we try to specify a profile that hasn't been loaded: ```shell kubectl create -f /dev/stdin <<EOF ``` ```yaml apiVersion: v1 kind: Pod metadata: name: hello-apparmor-2 annotations: container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write spec: containers: - name: hello image: busybox command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ] EOF pod/hello-apparmor-2 created ``` ```shell kubectl describe pod hello-apparmor-2 ``` ``` Name:          hello-apparmor-2 Namespace:     default Node:          gke-test-default-pool-239f5d02-x1kf/ Start Time:    Tue, 30 Aug 2016 17:58:56 -0700 Labels:        <none> Annotations:   container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write Status:        Pending Reason:        AppArmor Message:       Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded IP: Controllers:   <none> Containers: hello: Container ID: Image:     busybox Image ID: Port: Command: sh -c echo 'Hello AppArmor!' && sleep 1h State:              Waiting Reason:           Blocked Ready:              False Restart Count:      0 Environment:        <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro) Conditions: Type          Status Initialized   True Ready         False PodScheduled  True Volumes: default-token-dnz7v: Type:    Secret (a volume populated by a Secret) SecretName:    default-token-dnz7v Optional:   false QoS Class:      BestEffort Node-Selectors: <none> Tolerations:    <none> Events: FirstSeen    LastSeen    Count    From                        SubobjectPath    Type        Reason        Message ---------    --------    -----    ----                        -------------    --------    ------        ------- 23s          23s         1        {default-scheduler }                         Normal      Scheduled     Successfully assigned hello-apparmor-2 to e2e-test-stclair-node-pool-t1f5 23s          23s         1        {kubelet e2e-test-stclair-node-pool-t1f5}             Warning        AppArmor    Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded ``` Note the pod status is Pending, with a helpful error message: `Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded`. An event was also recorded with the same message. ## Administration ### Setting up nodes with profiles Kubernetes does not currently provide any native mechanisms for loading AppArmor profiles onto nodes. There are lots of ways to setup the profiles though, such as: * Through a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) that runs a Pod on each node to ensure the correct profiles are loaded. An example implementation can be found [here](https://git.k8s.io/kubernetes/test/images/apparmor-loader). * At node initialization time, using your node initialization scripts (e.g. Salt, Ansible, etc.) or image. * By copying the profiles to each node and loading them through SSH, as demonstrated in the [Example](#example). The scheduler is not aware of which profiles are loaded onto which node, so the full set of profiles must be loaded onto every node.  An alternative approach is to add a node label for each profile (or class of profiles) on the node, and use a [node selector](/docs/concepts/scheduling-eviction/assign-pod-node/) to ensure the Pod is run on a node with the required profile. ### Restricting profiles with the PodSecurityPolicy {{< note >}} PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25. See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information. {{< /note >}} If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To enable the PodSecurityPolicy, the following flag must be set on the `apiserver`: ``` --enable-admission-plugins=PodSecurityPolicy[,others...] ``` The AppArmor options can be specified as annotations on the PodSecurityPolicy: ```yaml apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref> apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...] ``` The default profile name option specifies the profile to apply to containers by default when none is specified. The allowed profile names option specifies a list of profiles that Pod containers are allowed to be run with. If both options are provided, the default must be allowed. The profiles are specified in the same format as on containers. See the [API Reference](#api-reference) for the full specification. ### Disabling AppArmor If you do not want AppArmor to be available on your cluster, it can be disabled by a command-line flag: ``` --feature-gates=AppArmor=false ``` When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden" error. Note that by default docker always enables the "docker-default" profile on non-privileged pods (if the AppArmor kernel module is enabled), and will continue to do so even if the feature-gate is disabled. The option to disable AppArmor will be removed when AppArmor graduates to general availability (GA). ### Upgrading to Kubernetes v1.4 with AppArmor No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any existing pods had an AppArmor annotation, they will not go through validation (or PodSecurityPolicy admission). If permissive profiles are loaded on the nodes, a malicious user could pre-apply a permissive profile to escalate the pod privileges above the docker-default. If this is a concern, it is recommended to scrub the cluster of any pods containing an annotation with `apparmor.security.beta.kubernetes.io`. ### Upgrade path to General Availability When AppArmor is ready to be graduated to general availability (GA), the options currently specified through annotations will be converted to fields. Supporting all the upgrade and downgrade paths through the transition is very nuanced, and will be explained in detail when the transition occurs. We will commit to supporting both fields and annotations for at least 2 releases, and will explicitly reject the annotations for at least 2 releases after that. ## Authoring Profiles Getting AppArmor profiles specified correctly can be a tricky business. Fortunately there are some tools to help with that: * `aa-genprof` and `aa-logprof` generate profile rules by monitoring an application's activity and logs, and admitting the actions it takes. Further instructions are provided by the [AppArmor documentation](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools). * [bane](https://github.com/jfrazelle/bane) is an AppArmor profile generator for Docker that uses a simplified profile language. It is recommended to run your application through Docker on a development workstation to generate the profiles, but there is nothing preventing running the tools on the Kubernetes node where your Pod is running. To debug problems with AppArmor, you can check the system logs to see what, specifically, was denied. AppArmor logs verbose messages to `dmesg`, and errors can usually be found in the system logs or through `journalctl`. More information is provided in [AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures). ## API Reference ### Pod Annotation Specifying the profile a container will run with: - **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>` Where `<container_name>` matches the name of a container in the Pod. A separate profile can be specified for each container in the Pod. - **value**: a profile reference, described below ### Profile Reference - `runtime/default`: Refers to the default runtime profile. - Equivalent to not specifying a profile (without a PodSecurityPolicy default), except it still requires AppArmor to be enabled. - For Docker, this resolves to the [`docker-default`](https://docs.docker.com/engine/security/apparmor/) profile for non-privileged containers, and unconfined (no profile) for privileged containers. - `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name. - The possible profile names are detailed in the [core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications). - `unconfined`: This effectively disables AppArmor on the container. Any other profile reference format is invalid. ### PodSecurityPolicy Annotations Specifying the default profile to apply to containers when none is provided: * **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName` * **value**: a profile reference, described above Specifying the list of profiles Pod containers is allowed to specify: * **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames` * **value**: a comma-separated list of profile references (described above) - Although an escaped comma is a legal character in a profile name, it cannot be explicitly allowed here. ## {{% heading "whatsnext" %}} Additional resources: * [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) * [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) </ins>

This is a Feature Request What would you like to be Post-merge of , move the tutorials under into Merge clusters section into security section here: Why is this needed Issue description is a slight modification from original request in the comment Comments /hold for /cc /sig docs security
this might be a good first issue for new contributors in sig-security-docs /triage accepted
Hi, I would like to work on this issue. /assign
/kind cleanup
Hi , I a query: moving the tutorials from the cluster sub-directory into the security sub-directory, the cluster sub-directory will only have its file so do I need to do something regarding it ( file)? Thanks
Whenever you are free can you please help me with the above mentioned query. Thanks


Question: ## Run and expose php-apache server <del> To demonstrate a HorizontalPodAutoscaler, you will first make a custom container image that uses the `php-apache` image from Docker Hub as its starting point. The `Dockerfile` is ready-made for you, and has the following content: ```dockerfile FROM php:5-apache COPY index.php /var/www/html/index.php RUN chmod a+rx index.php ``` This code defines a simple `index.php` page that performs some CPU intensive computations, in order to simulate load in your cluster. ```php <?php $x = 0.0001; for ($i = 0; $i <= 1000000; $i++) { $x += sqrt($x); } echo "OK!"; ?> ``` Once you have made that container image, start a Deployment that runs a container using the image you made, and expose it as a {{< glossary_tooltip term_id="service">}} </del> <ins> To demonstrate a HorizontalPodAutoscaler, you will first start a Deployment that runs a container using the `hpa-example` image, and expose it as a {{< glossary_tooltip term_id="service">}} </ins> using the following manifest: {{< codenew file="application/php-apache.yaml" >}}

If we are using as our custom image, why do the documentation starts by telling the user to build an image from Dockerfile provided and the code?
Page:
/retitle HorizontalPodAutoscaler walkthrough page recommends unnecessary container image build /kind bug /language en /triage accepted Thanks for reporting this.
I could take this up /assign


Question: Kubernetes {{< skew currentVersion >}} supports [Container Network Interface](https://github.com/containernetworking/cni) (CNI) plugins for cluster networking. You must use a CNI plugin that is compatible with your cluster and that suits your needs. Different plugins are available (both open- and closed- source) in the wider Kubernetes ecosystem. <ins> A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). </ins> You must use a CNI plugin that is compatible with the [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) or later releases of the CNI specification. The Kubernetes project recommends using a plugin that is

! ref:
/sig node /kind cleanup If any flag found which was removed in , Kindly remove them too.
/triage accepted
/language en
For anyone facing this issue and Kubernetes is not starting, I removed the flag from file and restarted kubelet service. ().
/priority important-longterm
I have run into the same problem and removing it from does not work. Basically this breaks the system
Hi Seems like you are using . If not ,kindly share kubelet version and log. Thanks !!
The version i used was 1.24.0 from the debian repo, downgrading to 1.23.6 solved my issue and got everything running again Let me know if more information is needed?
How you have bootstrapped the cluster? Using kubeadm or different tools
I was using 1.23 and I came up with this issue upon performing updates to the nodes of the cluster (apt-get upgrade). Then, 1.24 was installed and the issue came up and I managed to resolve it as I mentioned above as the logs of the kubelet service were indicating error with the --network-plugin flag.
Behaviour is expected. since remove in v1.24 Please share and the output of ?
: Logs:
Folks, this is an accepted issue. We should update that page to remove mentions of the command line argument. Pull requests are welcome - see for tips on how to contribute.
my cluster is down after doing an apt upgrade. From what I can understand it looks like I have this issue, running version 1.24.0 as well. Is here any instructions on how to downgrade my cluster so that I can get it up and running again? Update: I’ve managed to get my cluster up and running again. Whilst I agree that this comment is off-topic for the exact problem at hand, this may help someone with the problem that I had. The problem is that my K8S install was running on docker, and now dockershim has been removed, which is what stopped my cluster working. I used a couple of posts to get the problem I was having solved. Here’s one of the link (I can’t remember the other) On the workers, I streamlined the changes to this…. The first line should prevent the problem that I had - auto upgrading k8s during an apt upgrade.

Updating to 1.24 had the breaking change that caused my cluster to become unavailable. sudo apt-mark hold kubelet kubeadm kubectl sudo systemctl enable --now kubelet sudo su - mkdir -p /etc/containerd containerd config exit sudo nano /var/lib/kubelet/kubeadm- Remove --network-plugin=cni Add --container-runtime=remote --container-runtime- Save Sudo reboot At this point the node should come up. Not 100% sure if this will solve the problem on the control plain, I got that working before streamlining the commands, anything else should be able to be taken from the link I posted above.
I got mine up by simply downgrading the kubelet to latest 1.23.x
I've marked some off-topic comments as hidden. They're not deleted (you can click Show comment to reveal them). Please, folks, do focus on the topic here: fixing the Kubernetes documentation about setting up cluster networking
If anyone has questions about how to propose a fix for , you're very welcome to ask. You can reply here or, if you use the Kubernetes workspace for Slack, ask there in the channel.
I've created a SO page to redirect all the "how to fix my cluster now" questions there: . Should I update the OP to reflect this link and state that this is not a request to fix the cluster's setup?
Duplicated by issue
We should edit so that it is no longer incorrect, and then close this issue.
Anyone who wants to edit that page is welcome to.
/assign
is reviewing PR
remove " --network-plugin"flag work fine.
This resulted in my case just in another error:
same error for me.
same here EDIT: fixed it by "migrating" from docker to containerd by simply: now connect kubelet to containerd directly by editing /etc/systemd/system/kubelet.service.d/10- add after "ExecStart=/usr/bin/kubelet" which looks like: for me. finally restart kubelet.service:
As this bug is resolved, I'm going to lock it to ensure that the record remains on-topic.


Question: Edit the yaml files in `/_data/` for the Guides, Reference, Samples, or Support areas. <ins> You may have to exit and `jekyll clean` before restarting the `jekyll serve` to get changes to files in `/_data/` to show up. </ins> ### Add Images Put the new image in `/images/docs/` if it's for the documentation, and just `/images/` if it's for the website.

[X] Feature Request Problem: When upstream master removed an API that the docs tests check, all travis builds started failing. The immediate issue is fixed in two ways, with : changed the API checks that failed changed the upstream version from master to latest stable release This is an excellent interim solution, but we need to do a few more things to ensure that such breaks don't happen again. Proposed Solution: document for docs release meister that when release is cut, tests should be updated to run against the latest release versiondocument for docs release meister or shadow or other that we should check for any API changes that could break the tests. We can check the release notes manually for now, and devise an automated solution if the manual approach proves inadequate or someone wants to get clever. (Note that checking the API refdocs is not a reliable solution here. example: the 1.10 refdocs are wrong for exactly the offending API in the test break.) Page to Update:
Thank you for this--I'll take it on for my playbook update in
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


Question: [community_youtube_name] other = "YouTube"  # Tránh sử dụng conjunction_1. # Phải phù hợp với ngữ cảnh trong layouts/shortcodes/release-data.html # Xuất hiện trên https://kubernetes.io/releases/ # Ví dụ như "and" trong "Complete 1.25 Schedule and Changelog" [conjunction_1] other = "và" [cve_id] other = "ID CVE" [cve_issue_url] other = "URL Vấn đề GitHub CVE" [cve_summary] other = "Tóm tắt Vấn đề" [cve_table] other = "Danh sách CVE chính thức của Kubernetes" [cve_table_date_format] other = "02 Th01 2006 15:04:05 MST" [cve_table_date_format_string] other = "(cập nhật lần cuối: %s)" [deprecation_title] other = "Bạn đang xem tài liệu cho phiên bản Kubernetes:"  [deprecation_warning]  other = " tài liệu này không còn được duy trì. Phiên bản đang xem hiện tại là một snapshot tĩnh. Để rõ hơn về tài liệu bản cập nhật, xem "   other = " tài liệu này không còn được duy trì tích cực. Phiên bản bạn đang xem hiện là một bản chụp tĩnh. Để biết thông tin cập nhật, hãy xem "  [deprecation_file_warning]  other = "Không dùng nữa"   other = "Đã lạc thú" [outdated_content_title] other = "Thông tin trong tài liệu này có thể đã lạc thú" [outdated_content_message] other = "Tài liệu này có ngày cập nhật cũ hơn so với bản gốc, vì vậy thông tin mà nó chứa có thể đã lạc thú. Nếu bạn có thể đọc tiếng Anh, hãy xem phiên bản tiếng Anh để có thông tin mới nhất: " [dockershim_message] other = """Dockershim đã được loại bỏ khỏi dự án Kubernetes kể từ phiên bản 1.24. Đọc Dockershim Removal FAQ để biết thêm chi tiết."""  [docs_label_browse]  other = "Duyệt tài liệu"   other = "Duyệt Tài liệu"  [docs_label_contributors]  other = "Người đóng góp"   other = "Những Người đóng góp"  [docs_label_i_am] other = "TÔI LÀ..." [docs_label_users]  other = "Users"   other = "Người dùng" [docs_page_versions] other = "Trang %s này dành cho Kubernetes %s. Nếu bạn muốn sử dụng phiên bản Kubernetes khác, vui lòng tham khảo các trang sau đây thay vì:" [docs_version_current] other = "(tài liệu này)" [docs_version_latest_heading] other = "Phiên bản mới nhất" [docs_version_other_heading] other = "Phiên bản cũ" [end_of_life] other = "Kết thúc vòng đời:" [envvars_heading] other = "Biến môi trường" [error_404_were_you_looking_for] other = "Bạn có đang tìm kiếm:" [examples_heading] other = "Ví dụ" [feature_gate_stage_alpha] other = "Alpha" [feature_gate_stage_beta] other = "Beta" [feature_gate_stage_stable] other = "GA" [feature_gate_stage_deprecated] other = "Đã lạc thú" [feature_gate_table_header_default] other = "Mặc định" [feature_gate_table_header_feature] other = "Tính năng" [feature_gate_table_header_from] other = "Từ" [feature_gate_table_header_since] other = "Từ" [feature_gate_table_header_stage] other = "Giai đoạn" [feature_gate_table_header_to] other = "Đến" [feature_gate_table_header_until] other = "Đến" [feature_state] other = "TRẠNG THÁI TÍNH NĂNG:" [feature_state_kubernetes_label] other = "Kubernetes" [feature_state_feature_gate_tooltip] other = "Feature Gate:"  [feedback_heading] other = "Phản hồi"

Đề nghị thay thế "lạc thú" bằng "lỗi thời" !
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
Please raise the issue in english putting the language code before the issue in [] example [vi] Issue title here It will be good practice to write the description and title of the issue in English only.
Thank you! BTW i'd commited about this change, waiting for review.
Fixed in


Question: kind: Service metadata: name: my-service <ins> labels: app: MyApp </ins> spec: selector: app: MyApp ports: - protocol: TCP port: 80 <del> targetPort: 9376 </del>  No newline at end of file

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/triage accepted


Question: your backups using a well reviewed backup and encryption solution, and consider using full disk encryption where possible. <del> Kubernetes supports optional [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) for information in the Kubernetes API. </del> <ins> Kubernetes supports optional [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) for information in the Kubernetes API. </ins> This lets you ensure that when Kubernetes stores data for objects (for example, `Secret` or `ConfigMap` objects), the API server writes an encrypted representation of the object. That encryption means that even someone who has access to etcd backup data is unable

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --We have two pages with similar aims: We should ensure that the advice in the two documents is aligned, and also make sure that the two documents link to each other. Why is this needed It's a bad idea to document multiple ways to make sure that your cluster is secure, unless those are well aligned. Comments /sig security /sig docs /language en
Relevant to
Regarding this: We can use a reference section/note/what's next section in the end of stating: -
/triage accepted
Hey I would like to work on this.
/assign


Question: min-height: 30vh; } <del> #fp-announcement main { </del> <ins> #fp-announcement aside { </ins> padding-top: 125px; padding-bottom: 35px; }

The announcement banner text (merged in ) is being used as the Google search snippet for docs pages. This may not have been your intention. !
SIG Docs doesn't have a good way to improve Google's indexing algorithm. The text is in an HTML element which should mark it as an aside: content only indirectly related to the main content. I'd characterize this as a Google bug. There are a lot of Google people in the Kubernetes ecosystem but probably not from the web search side. Do you agree with that characterization? /triage awaiting-more-evidence
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : SIG Docs doesn't have a good way to improve Google's indexing algorithm. The text is in an HTML element which should mark it as an aside: content only indirectly related to the main content. /triage awaiting-more-evidence 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
/priority awaiting-more-evidence
I can't find anything suggesting Google has ever ignored elements, and I can find a comment from someone at Google saying they explicitly ignore them ( via ). The supported way to mark something not to go in a snippet is the attribute: , . I can raise a feature request with the search team to ask them to treat like but from a Kubernetes users perspective, changing the site will get to a better outcome quicker.
It sounds useful to add to the announcements.
I would adjust to "fix now"
Yikes, sorry guys! I would also mark as fix now
/priority fix-now
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /priority fix-now 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
/remove-priority awaiting-more-evidence /priority critical-urgent

This is a Feature Request The HTML partials, and frontpage-, contain a element which duplicates the element found in the body of the page. This became an issue as the docsy theme updates page anchors in the script . This script depends upon the element and failed to find the H1 - H6 level headings on the page to udpate. What would you like to be Investigate how to include the announcement banner on the docs pages (front page, docs, blog, and so on) without the element. Investigate changes to the corresponding stylesheet. Why is this needed Clean up or adjust the preexisting, related code as well as the current templates and stylesheet. Provide a flexible way to add and remove content such as announcement or banners on the pages. Comments For additional information, see PR .
/assign
/kind cleanup /priority important-soon
/reopen There might be more to do here.
Reopened this issue. <detailsIn response to : /reopen There might be more to do here. 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
I don't think there's any more work that needs doing here! you can close this off :)
Good. The only thing noted is some different styling per main section (docs vs case studies). /close
Closing this issue. <detailsIn response to : Good. The only thing noted is some different styling per main section (docs vs case studies). /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


Question: <ins> --- title: ロールと責任 content_type: concept weight: 10 --- <!-- overview --> 誰もがKubernetesに貢献することができます。 SIG Docs へのコントリビューションが増えると、コミュニティ内で異なるレベルのメンバーシップに申請することができます。 これらの役割により、コミュニティ内でより多くの責任を担うことができます。 各役割にはより多くの時間とコミットメントが必要です。 役割は以下の通りです: - Anyone: Kubernetesドキュメントへの定期的なコントリビューター - Member: Issueの割り当てとトリアージができ、Pull Requestに対する非公式なレビューができる - Reviewer: ドキュメントのPull Requestのレビューをリードし、変更の品質を保証する - Approver: ドキュメントのレビューをリードし、変更をマージできる <!-- body --> ## Anyone {#anyone} GitHubのアカウントを持っている人なら誰もがKubernetesに貢献することができます。 SIG Docs はすべての新たなコントリビューターを歓迎します。 誰もが以下のことをできます: - [`kubernetes/website`](https://github.com/kubernetes/website)を含む、どの[Kubernetes](https://github.com/kubernetes/)リポジトリでもIssueを作成する - Pull Requestに非公式なフィードバックを提供する - ローカライゼーションに貢献する - [Slack](https://slack.k8s.io/)や[SIG Docsのメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)で改善の提案をする [CLA に署名](https://github.com/kubernetes/community/blob/master/CLA.md)した後は、誰もが以下のことをできます: - 既存のコンテンツを改善するためのPull Requestを開く、新しいコンテンツを追加する、ブログ記事やケーススタディを書く - 図表やグラフィックアセット、埋め込み可能なスクリーンキャストやビデオを作成する 詳細については、[新しいコンテンツの貢献](/ja/docs/contribute/new-content/)を参照してください。 ## Member {#members} Memberは、`kubernetes/website`に複数のPull Requestを作成した人です。 Memberは[Kubernetes GitHub organization](https://github.com/kubernetes)の一員です。 Memberは以下のことをできます: - [Anyone](#anyone)に列挙されているすべてのことを行う - `/lgtm`コメントを使用して、Pull RequestにLGTM (looks good to me)ラベルを追加する {{< note >}} `/lgtm`を使用すると、自動化がトリガーされます。 非公式に承認したい場合は、"LGTM"とコメントするだけでも大丈夫です！ {{< /note >}} - `/hold`コメントを使用して、Pull Requestのマージをブロックする - `/assign`コメントを使用して、Pull RequestにReviewerを割り当てる - Pull Requestに非公式なレビューを提供する - 自動化を使用してIssueをトリアージし、分類する - 新機能をドキュメント化する ### Memberになる {#becoming-a-member} 少なくとも5つの実質的なPull Requestを作成し、その他の[要件](https://github.com/kubernetes/community/blob/master/community-membership.md#member)を満たした後に以下のようにしてMemberになることができます: 1. 2人の[Reviewer](#reviewers)または[Approver](#approvers)にあなたのメンバーシップを[スポンサー](/docs/contribute/advanced#sponsor-a-new-contributor)してもらいます。 [Slackの#sig-docsチャンネル](https://kubernetes.slack.com)や[SIG Docsのメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)でスポンサーを依頼してください。 {{< note >}} 個別のSIG Docsメンバーに直接メールやSlackのダイレクトメッセージを送らないでください。 また申請する前にスポンサーを依頼する必要があります。 {{< /note >}} 2. [`kubernetes/org`](https://github.com/kubernetes/org/)リポジトリにIssueを作成します。**Organization Membership Request**のissueテンプレートを使用してください。 3. スポンサーにGitHub Issueのことを知らせます。以下の方法があります: - Issue内でGitHubユーザー名に言及する（`@<GitHub-username>`） - Slackやメールを使ってIssueのリンクを送る スポンサーは`+1`の投票でリクエストを承認します。 スポンサーがリクエストを承認すると、Kubernetes GitHubの管理者があなたをメンバーとして追加します。 おめでとうございます！ メンバーシップリクエストが承認されない場合はフィードバックを受け取ります。 フィードバックに対応した後、再度申請してください。 4. メールアカウントでKubernetes GitHub organizationの招待を受け入れます。 {{< note >}} GitHubはアカウントのデフォルトメールアドレスに招待を送信します。 {{< /note >}} ## Reviewer {#reviewers} ReviewerはオープンなPull Requestのレビューを担当します。 Memberのフィードバックとは異なり、PRを作成した人はReviewerのフィードバックに対応する必要があります。 Reviewerは[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs) GitHubチームのメンバーです。 Reviewerは以下のことをできます: - [Anyone](#anyone)および[Member](#members)に列挙されているすべてのことを行う - Pull Requestをレビューし、拘束力のあるフィードバックを提供する {{< note >}} 拘束力のないフィードバックを提供する場合、コメントの前に"Optionally: "などのフレーズを付けてください。 {{< /note >}} - コード内のユーザー向けの文字列を編集する - コードコメントを改善する SIG DocsのReviewer、あるいは特定の領域に関するドキュメントのReviewerになることができます。 ### Pull RequestへのReviewerの割り当て 自動化により、すべてのPull RequestにReviewerが割り当てられます。 特定の人物にレビューを依頼するには、`/assign [@_github_handle]`とコメントします。 割り当てられたReviewerがPRにコメントしていない場合、他のReviewerが代わりにレビューできます。 また、必要に応じて技術的なReviewerを割り当てることもできます。 ### `/lgtm`の使用 LGTMは"Looks good to me"の略で、Pull Requestが技術的に正確でマージの準備が整っていることを示します。 すべてのPRには、マージするためにReviewerからの`/lgtm`コメントとApproverからの`/approve`コメントが必要です。 Reviewerからの`/lgtm`コメントは拘束力があり、自動化により`lgtm`ラベルが追加されます。 ### Reviewerになる [要件](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)を満たすと、SIG DocsのReviewerになることができます。他のSIGのReviewerは、SIG DocsでのReviewerステータスを別途申請する必要があります。 申請方法は以下の通りです: 1. `kubernetes/website`リポジトリの[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)ファイルのセクションに、GitHubユーザー名を追加するPull Requestを開きます。 {{< note >}} どこに追加すればよいかわからない場合は、`sig-docs-en-reviews`に追加してください。 訳注: `sig-docs-en-reviews`は英語版のReviewerチームです。日本語ローカライゼーションのReviewerチームに参加する場合は、`sig-docs-ja-reviews`に追加してください。 {{< /note >}} 2. PRを1人以上のSIG Docs Approverに割り当てます(ユーザー名は`sig-docs-{language}-owners`に記載されています)。 承認されると、SIG Docsのリードが適切なGitHubチームに追加します。 追加されると、[k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)が新しいPull RequestのReviewerとしてあなたを割り当て、提案します。 ## Approver {#approvers} ApproverはPull Requestをレビューし、マージするために承認します。 Approverは[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs) GitHubチームのメンバーです。 Approverは以下のことをできます: - [Anyone](#anyone)、[Member](#members)、および[Reviewer](#reviewers)に列挙されているすべてのことを行う - `/approve`コメントを使用してPull Requestを承認およびマージすることで、コントリビューターのコンテンツを公開する - スタイルガイドの改善を提案する - ドキュメントテストの改善を提案する - Kubernetesのウェブサイトや他のツールの改善を提案する PRに既に`/lgtm`が付いている場合、またはApprover自身が`/lgtm`コメントを付けた場合、PRは自動的にマージされます。 SIG DocsのApproverは、追加の技術的なレビューが不要な変更にのみ`/lgtm`を付けるべきです。 ### Pull Requestの承認 ApproverとSIG DocsのリードだけがPull Requestをwebsiteリポジトリにマージすることができます。 これには一定の責任が伴います。 - Approverは`/approve`コマンドを使用して、PRをリポジトリにマージできます。 {{< warning >}} 不注意なマージはサイトを壊す可能性があるため、マージする際には慎重に行ってください。 {{< /warning >}} - 提案された変更が[ドキュメントコンテンツガイド](/docs/contribute/style/content-guide/)に準拠していることを確認してください。 もし疑問がある場合や何か不明な点がある場合は、遠慮なく追加のレビューを依頼してください。 - PRを`/approve`する前に、Netlifyのテストに通っていることを確認してください。 <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlifyテストは承認する前に通っている必要があります" /> - 承認する前に、PRのNetlifyのページプレビューをクリックして内容が正しいことを確認してください。 - 週ごとのローテーションである[PR Wranglerローテーションスケジュール](https://github.com/kubernetes/website/wiki/PR-Wranglers)に参加してください。SIG DocsはすべてのApproverにこのローテーションへの参加を期待しています。詳細については[PR wranglers](/docs/contribute/participate/pr-wranglers/)を参照してください。 ### Approverになる [要件](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)を満たすと、SIG DocsのApproverになることができます。 他のSIGのApproverは、SIG DocsでのApproverステータスを別途申請する必要があります。 申請方法は以下の通りです: 1. `kubernetes/website`リポジトリの[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)ファイルのセクションに、自分自身を追加するPull Requestを開きます。 {{< note >}} どこに追加すればよいかわからない場合は、`sig-docs-en-owners`に追加してください。 訳注: `sig-docs-en-owners`は英語版のApproverチームです。 日本語ローカライゼーションのApproverチームに参加する場合は、`sig-docs-ja-owners`に追加してください。 {{< /note >}} 2. PRを1人以上の現在のSIG Docs Approversに割り当てます。 承認されると、SIG Docsのリードが適切なGitHubチームに追加します。 追加されると、[k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)が新しいPull RequestのReviewerとしてあなたを割り当て、提案します。 ## {{% heading "whatsnext" %}} - すべてのApproverがローテーションで担当する役割である[PR wrangling](/docs/contribute/participate/pr-wranglers/)について読む。 </ins>

This is a Feature Request What would you like to be Translate into Japanese Why is this needed There is no Japanese translation for this page Comments File to translate: Original:
/language ja /area localization /assign /triage accepted


Question: {{< include "included/optional-kubectl-configs-zsh.md" >}} <ins> ### Install `kubectl convert` plugin {{< include "included/kubectl-convert-overview.md" >}} 1. Download the latest release with the command: ```powershell curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe ``` 1. Validate the binary (optional) Download the kubectl-convert checksum file: ```powershell curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256 ``` Validate the kubectl-convert binary against the checksum file: - Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded: ```cmd CertUtil -hashfile kubectl-convert.exe SHA256 type kubectl-convert.exe.sha256 ``` - Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result: ```powershell $($(CertUtil -hashfile .kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .kubectl-convert.exe.sha256) ``` 1. Add the binary in to your `PATH`. 1. Verify plugin is successfully installed ```shell kubectl convert --help ``` If you do not see an error, it means the plugin is successfully installed. </ins> ## {{% heading "whatsnext" %}} {{< include "included/kubectl-whats-next.md" >}}

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 (really, the 3 pages that it links to) to let readers know how to install Why is this needed is now delivered as a plugin, not part of the main binary. v1.22 includes lots of and release v1.22 is the first time lots of readers will really notice the deprecations. However, there has been no API removal release since was moved to be a plugin. Comments /sig cli /kind feature /priority important-soon (IMO)
ref:
<details<summary<emIt's there for the installing</em</summary<pre$ curl -L -I HTTP/2 302 server: nginx date: Wed, 30 Jun 2021 23:06:44 GMT content-type: text/html content-length: 154 location: via: 1.1 google alt-svc: clear </pre</detailsWhere current docs say to fetch (eg) , let's tell them to install as well.
Since kubectl-convert is a separate binary, should reference of the command from page also be removed?
/help I'm willing to revise this issue description if it's not clear how to make these changes.
This request has been marked as needing help from a contributor. 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 : /help 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
/triage accepted
what you're asking sounds like a separate issue.
I would like to work on this issue. From what I understand, a new command to download has to be under the first point titled for all the three operating systems something like this. Does verifying checksum step also have to for kubectl-convert?
Yes, we should let readers know how to check that the software they download is genuine.
We should also briefly explain what does (a hyperlink is OK)
/assign
the command line reference page still lists -
How do you install kubectl convert for windows? I don't seem to have it installed.

I'm going to mark as off-topic; the original issue is resolved.
How is this issue resolved/closed? I didn't found anywhere on the docs how to install the plugin/binary, only found this info on a third-party site: This really should be better documented, and there is still a mention of this command on this page without any word about it being deprecated and transformed into a plugin/binary:
Try this link: For me, the top search result is to a page with a section “Install plugin”. I think this issue was OK to close.
Truly, didn't have found this section, thanks But i also didn't expected a deprecated command installation instructions would be directly on the page that teaches how to install the command itself, thought it would be in a or section. Can we at least add the link about on the page that teaches how to ? That what people trying to migrate from 1.22 to 1.23 would find it easier. Opened a PR for this here
I'm on a macbook pro Ventura 13, M1 chip. I followed the instructions using ARM64 version. Step 3 didn't work, so I used this instead: Which worked, but then, ran and got: "Error: exec format error" Am I doing something wrong or does this plugin not work on Mac with M1?
You should try asking in


Question: Print the live configuration using `kubectl get`: ```shell <del> kubectl get -f http://k8s.io/docs/concepts/tools/kubectl/simple_deployment.yaml -o yaml </del> <ins> kubectl get -f http://k8s.io/docs/tutorials/object-management-kubectl/simple_deployment.yaml -o yaml </ins> ``` The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation

<!-- 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: 404 on Proposed Solution: Update location of Page to Update:


Question: It is populated when adding `--record` to a `kubectl` command that may change an object. <ins> ## kubernetes.io/description {#description} Example: `kubernetes.io/description: "Description of K8s object."` Used on: All Objects This annotation is used for describing specific behaviour of given object. </ins> ## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} Example: `controller.kubernetes.io/pod-deletion-cost=10`

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: Kubernetes an annotation, , that is not registered or documented. Proposed Solution: Register and document this annotation. Page to Update: Also consider whether to mention that annotation in Additional Information: /sig auth /language en
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
I would like to work on this.
/assign


Question:
 Um pod é a unidade de execução básica de um aplicativo Kubernetes. Cada pod representa uma parte de uma carga de trabalho em execução no cluster.  Saiba mais sobre pods.

 Para interagir com o Terminal, use a versão desktop/tablet

 Continue para o Módulo 3›

 Conteúdo indisponível

 O tutorial interativo de como implantar um aplicativo no seu cluster não está disponível. Para mais informações, veja o  anúncio de encerramento do Katacoda.

The terminal to use the interactive tutorials is using Katacoda, however, it was purchased by O'Reilly and is outside the domain that the terminal is using to run.
Hi You can ask support queries in channels.
Page related to issue: /language pt
/retitle [pt-br] Remove the obsolete online interactive tutorial from the page
For anyone willing to assist on this, please refer to PR for information regarding the implementation of similar changes carried out on the main website (i.e. English pages).
/good-first-isssue
/triage accepted /assign
/retitle [pt-br] Obsolete online interactive tutorial in the Using Minikube to Create a Cluster page /kind bug


Question:
{{- with $currentStage -}}
 {{ T "feature_state" }} {{T "feature_state_kubernetes_label" }} v{{ .fromVersion }} [{{ .stage }}]

 {{ T "feature_state" }} {{T "feature_state_kubernetes_label" }} v{{ .fromVersion }} [{{ .stage }}]
  {{- $featureGateFound = true -}} {{- end -}}

This is a Bug Report <!--Required Information--Problem: Documentation layout issue in page under IngressClass scope Namespaced section, see following screenshot: <img width="912" alt="image" src=""Proposed Solution: I would like to create a PR to fix it, the solution is to remove and outside of template Page to Update: Documentation layout issue in Ingress.


Question: <ins> --- title: Kubernetes API 健康端点 content_type: concept weight: 50 --- <!-- title: Kubernetes API health endpoints reviewers: - logicalhan content_type: concept weight: 50 --> <!-- overview --> <!-- The Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} provides API endpoints to indicate the current status of the API server. This page describes these API endpoints and explains how you can use them. --> Kubernetes {{< glossary_tooltip term_id="kube-apiserver" text="API 服务器" >}} 提供 API 端点以指示 API 服务器的当前状态。 本文描述了这些 API 端点，并说明如何使用。 <!-- body --> <!-- ## API endpoints for health --> ## API 健康端点  {#api-endpoints-for-health} <!-- The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `readyz`) to indicate the current status of the API server. The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead. The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration. For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint. Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code. A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint. The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server. --> Kubernetes API 服务器提供 3 个 API 端点（`healthz`、`livez` 和 `readyz`）来表明 API 服务器的当前状态。 `healthz` 端点已被弃用（自 Kubernetes v1.16 起），你应该使用更为明确的 `livez` 和 `readyz` 端点。 `livez` 端点可与 `--livez-grace-period` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)一起使用，来指定启动持续时间。 为了正常关机，你可以使用 `/readyz` 端点并指定 `--shutdown-delay-duration` [标志](/zh/docs/reference/command-line-tools-reference/kube-apiserver)。 检查 API 服务器的 `health`/`livez`/`readyz` 端点的机器应依赖于 HTTP 状态代码。 状态码 `200` 表示 API 服务器是 `healthy`、`live` 还是 `ready`，具体取决于所调用的端点。 以下更详细的选项供操作人员使用，用来调试其集群或专门调试 API 服务器的状态。 <!-- The following examples will show how you can interact with the health API endpoints. --> 以下示例将显示如何与运行状况 API 端点进行交互。 <!-- For all endpoints you can use the `verbose` parameter to print out the checks and their status. This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine: --> 对于所有端点，都可以使用 `verbose` 参数来打印检查项以及检查状态。 这对于操作人员调试 API 服务器的当前状态很有用，这些不打算给机器使用： ```shell curl -k https://localhost:6443/livez?verbose ``` <!-- or from a remote host with authentication: --> 或从具有身份验证的远程主机： ```shell kubectl get --raw='/readyz?verbose' ``` <!-- The output will look like this: --> 输出将如下所示： ```shell [+]ping ok [+]log ok [+]etcd ok [+]poststarthook/start-kube-apiserver-admission-initializer ok [+]poststarthook/generic-apiserver-start-informers ok [+]poststarthook/start-apiextensions-informers ok [+]poststarthook/start-apiextensions-controllers ok [+]poststarthook/crd-informer-synced ok [+]poststarthook/bootstrap-controller ok [+]poststarthook/rbac/bootstrap-roles ok [+]poststarthook/scheduling/bootstrap-system-priority-classes ok [+]poststarthook/start-cluster-authentication-info-controller ok [+]poststarthook/start-kube-aggregator-informers ok [+]poststarthook/apiservice-registration-controller ok [+]poststarthook/apiservice-status-available-controller ok [+]poststarthook/kube-apiserver-autoregistration ok [+]autoregister-completion ok [+]poststarthook/apiservice-openapi-controller ok healthz check passed ``` <!-- The Kubernetes API server also supports to exclude specific checks. The query parameters can also be combined like in this example: --> Kubernetes API 服务器也支持排除特定的检查项。 查询参数也可以像以下示例一样进行组合： ```shell curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' ``` <!-- The output show that the `etcd` check is excluded: --> 输出显示排除了 `etcd` 检查： ```shell [+]ping ok [+]log ok [+]etcd excluded: ok [+]poststarthook/start-kube-apiserver-admission-initializer ok [+]poststarthook/generic-apiserver-start-informers ok [+]poststarthook/start-apiextensions-informers ok [+]poststarthook/start-apiextensions-controllers ok [+]poststarthook/crd-informer-synced ok [+]poststarthook/bootstrap-controller ok [+]poststarthook/rbac/bootstrap-roles ok [+]poststarthook/scheduling/bootstrap-system-priority-classes ok [+]poststarthook/start-cluster-authentication-info-controller ok [+]poststarthook/start-kube-aggregator-informers ok [+]poststarthook/apiservice-registration-controller ok [+]poststarthook/apiservice-status-available-controller ok [+]poststarthook/kube-apiserver-autoregistration ok [+]autoregister-completion ok [+]poststarthook/apiservice-openapi-controller ok [+]shutdown ok healthz check passed ``` <!-- ## Individual health checks --> ## 独立健康检查  {#individual-health-check} {{< feature-state state="alpha" >}} <!-- Each individual health check exposes an http endpoint and could can be checked individually. The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server. The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`. These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system: --> 每个单独的健康检查都会公开一个 http 端点，并且可以单独检查。 单个运行状况检查的模式为 `/livez/<healthcheck-name>`，其中 `livez` 和 `readyz` 表明你要检查的是 API 服务器是否存活或就绪。 `<healthcheck-name>` 的路径可以通过上面的 `verbose` 参数发现 ，并采用 `[+]` 和 `ok` 之间的路径。 这些单独的健康检查不应由机器使用，但对于操作人员调试系统而言，是有帮助的： ```shell curl -k https://localhost:6443/livez/etcd ``` </ins>

/language zh /help
This request has been marked as needing help from a contributor. 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 : /language zh /help 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
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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


Question: <del> ## `ResourceChangeDetectionStrategy`     {#kubelet-config-k8s-io-v1beta1-ResourceChangeDetectionStrategy} (Alias of `string`) **Appears in:** - [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) ResourceChangeDetectionStrategy denotes a mode in which internal managers (secret, configmap) are discovering object changes. ## `LoggingConfiguration`     {#LoggingConfiguration} </del> <ins> ## `MemoryReservation`     {#kubelet-config-k8s-io-v1beta1-MemoryReservation} </ins>

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: Visiting provides inaccurate default values for shutdownGracePeriod (30s rather than 0s) and shutdownGracePeriodCriticalPods (10s rather than 0s). Proposed Solution: Correct the documentation to match the actual default values. Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
I would like to take up this ticket.


Question:
レビューを始める前に、以下のことを心に留めてください。  - [CNCFの行動規範](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)を読み、いかなる時にも行動規範にしたがって行動するようにする。   - [CNCFの行動規範](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)を読み、いかなる時にも行動規範にしたがって行動するようにする。  - 礼儀正しく、思いやりを持ち、助け合う気持ちを持つ。 - 変更点だけでなく、PRのポジティブな側面についてもコメントする。 - 相手の気持ちに共感して、自分のレビューが相手にどのように受け取られるのかをよく意識する。 - 相手の善意を前提として、疑問点を明確にする質問をする。  - 経験を積んだコントリビューターの場合、コンテンツに大幅な変更が必要な新規のコントリビューターとペアを組んで作業に取り組むことを考える。   - 経験を積んだコントリビューターの場合、コンテンツに大幅な変更が必要な作業を行う新規のコントリビューターとペアを組んで取り組むことを考える。  ## レビューのプロセス  一般に、コンテンツや文体に対するプルリクエストは、英語でレビューを行います。   一般に、コンテンツや文体に対するプルリクエストは、英語でレビューを行います。図1は、レビュープロセスについて手順の概要を示しています。 各ステップの詳細は次のとおりです。 **(訳注:SIG Docs jaでは、日本語でも対応しています。日本語の翻訳に対するレビューは、日本語でも構いません。ただし、プルリクエストの作成者や他のコントリビューターが必ずしも日本語を理解できるとは限りませんので、注意して発言してください。)**   {{< mermaid >}} flowchart LR subgraph fourth[レビューの開始] direction TB S[ ] -.- M[コメントを追加] --> N[変更の確認] N --> O[Commentを選択] end subgraph third[PRの選択] direction TB T[ ] -.- J[説明とコメントを読む]--> K[Netlifyプレビューで
変更点を表示] end A[オープン状態の
PR一覧を確認]--> B[オープン状態のPRを
ラベルで絞り込む] B --> third --> fourth classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,J,K,M,N,O grey class S,T spacewhite class third,fourth white {{</ mermaid >}} 図1. レビュープロセスの手順  1.  [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)に移動します。Kubernetesのウェブサイトとドキュメントに対するopen状態のプルリクエスト一覧が表示されます。 2.  open状態のPRに、以下に示すラベルを1つ以上使って絞り込みます。  - `cncf-cla: yes` (推奨): CLAにサインしていないコントリビューターが提出したPRはマージできません。詳しい情報は、[CLAの署名](/docs/contribute/new-content/overview/#sign-the-cla)を読んでください。   - `cncf-cla: yes` (推奨): CLAにサインしていないコントリビューターが提出したPRはマージできません。詳しい情報は、[CLAの署名](/docs/contribute/new-content/#sign-the-cla)を読んでください。  - `language/en` (推奨): 英語のPRだけに絞り込みます。 - `size/<size>`: 特定の大きさのPRだけに絞り込みます。レビューを始めたばかりの人は、小さなPRから始めてください。

This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/architecture/garbage- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/architecture/garbage- is outdated. It contains important information for contributors. Comments /language ja /assign
/triage accepted


Question: ## API removals, deprecations, and other changes for Kubernetes 1.24 <del> * [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/). Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information. </del> <ins> * [Dynamic kubelet configuration](https://github.com/kubernetes/enhancements/issues/281): `DynamicKubeletConfig` is used to enable the dynamic configuration of the kubelet. The `DynamicKubeletConfig` flag was deprecated in Kubernetes 1.22. In v1.24, this feature gate will be removed from the kubelet. Refer to the ["Dynamic kubelet config is removed" KEP](https://github.com/kubernetes/enhancements/issues/281) for more information. </ins> * [Dynamic log sanitization](https://github.com/kubernetes/kubernetes/pull/107207): The experimental dynamic log sanitization feature is deprecated and will be removed in v1.24. This feature introduced a logging filter that could be applied to all Kubernetes system components logs to prevent various types of sensitive information from leaking via logs. Refer to [KEP-1753: Kubernetes system components logs sanitization](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#deprecation) for more information and an [alternative approach](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1753-logs-sanitization#alternatives=). * [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/). * [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information.

This is a Cleanup 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 removed Remove Why is this needed v1.24 of Kubernetes will remove the dynamic kubelet config feature (deprecated since Kubernetes v1.22) Comments /sig node /language en /milestone 1.24
/triage accepted
See
/assign
~BTW Any PR for this should target the branch dev-1.24~ That advice is now stale. Kubernetes v1.24 has shipped.
Okay... But I want to clear that you want me to remove the entire page from "Administer a Cluster" . Am I Right ?
/assign
This won't be in 1.24's docs, clearing the milestone. This can be to subsequent milestones if needed. (or closed if I'm missing a PR somewhere) /milestone clear
We should have updated the page to state when the removal is due, or to remove the commitment if we're no longer sure.
/label good-first-issue All you need to do is remove from the docs.
The label(s) /label good-first-issue api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactorlabels -additionallabelslabels -? <detailsIn response to : /label 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
/good-first-issue states that the feature was removed. why did we take this change out of the v1.24 milestone?
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command.

<detailsIn response to : /good-first-issue states that the feature was removed. 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
should I also remove all the links that lead to ? for example, here:
/remove-milestone 1.24
Not required, but much better if you do.
hey, I have made the required changes in the PR, could you please review it?
can i work on this issue as well?
You're welcome to. The next step on contributing is to review
will do !
hey , this is my contribution and i would be glad to help and have an insight. can you tell me what to do? im new, just trying to get familiar with all of this
How to work on this: Please open a PR that removes If there are any other English pages that link to then please turn the links into plain text, or otherwise fix them up.
/assign
The issue has been resolved. all are removed or commented out. still there are some mention of this like but they there only to point out that the dynamic kubelet config is removed from v1.24.
I don't see any updates from your side; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on /unassign
i think this issue is resolved.
If is addressed somewhere in the PR then can you please share a link of the respective PR? Thanks!
Can I work on this issue is this still open ?
heyyo can you please confirm what branch this issue fix needs to be targeted on? Thanks in advance:)
To remove that page, make the change to the main branch. Ideally, also find any English pages - just English - that link to and edit them so that they don't.
/assign
Hi This is my first contribution to open source, I have deleted the requested page. Should I proceed to open a pull request?
heyyo if you don't mind I was already working on the issue and have made the changes three days ago just haven't pushed them yet
of course! I noticed you did not claim the issue with the bot so I thought I was good to go :)
/assign
update : will create a PR tomorrow.

/assign
is this issue still open ??
Hi, I want to work on this. Is this stll open ?
/assign
Hi. There's a white-on-green “Open” marker at the left of the top navigation, at least in the default desktop view. That indicates that the issue is open. Anyone is welcome to suggest a fix, or to propose closing the issue if the fix has already happened. I can see that the page is still there at the time of writing.
hi I can fix this issue u can assign me it.
/assign
where are the html file of this page in the repo


Question:
 Para interagir com o Terminal, por favor, use a versão para desktop ou table.

 Continue para o Módulo 4›

 Conteúdo indisponível

 O tutorial interativo de como explorar seu aplicativo não está disponível. Para mais informações, veja o  anúncio de encerramento do Katacoda.

The terminal to use the interactive tutorials is using Katacoda, however, it was purchased by O'Reilly and is outside the domain that the terminal is using to run.
Hi You can ask support queries in channels.
Page related to issue: /language pt
/retitle [pt-br] Remove the obsolete online interactive tutorial from the page
For anyone willing to assist on this, please refer to PR for information regarding the implementation of similar changes carried out on the main website (i.e. English pages).
/good-first-isssue
/triage accepted /assign
/retitle [pt-br] Obsolete online interactive tutorial in the Using Minikube to Create a Cluster page /kind bug


Question: Labels:  app=nginx Containers: nginx: <del> Image:        nginx:1.91 </del> <ins> Image:        nginx:1.161 </ins> Port:         80/TCP Host Port:    0/TCP Environment:  <none>

There are some bugs: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" "image updated to 1.9.1" should be changed to "image updated to 1.16.1" The content of this article has many "", it could be changed to "deployment". For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
/language zh
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted 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
looks like docs is already updated to nginx:1.16.1. Do you mind closing this issue?
There should still be a few places left unfinished.
Could you please edit the issue which needs to be still updated?
Bug1: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" Bug2: ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" Bug3: "image updated to 1.9.1" should be changed to "image updated to 1.16.1" Bug4: The content of this article has many "", it could be changed to "deployment".

For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
Thanks for clarifying. /assign
/retitle [zh] Localization bugs / work required for Deployment concept
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/triage accepted


Question: `annotate`    | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Add or update the annotations of one or more resources. `api-resources`    | `kubectl api-resources [flags]` | List the API resources that are available. `api-versions`    | `kubectl api-versions [flags]` | List the API versions that are available.  --> 操作             | 语法      |       描述 -------------------- | -------------------- | -------------------- `alpha`    | `kubectl alpha SUBCOMMAND [flags]` | 列出与 alpha 特性对应的可用命令，这些特性在 Kubernetes 集群中默认情况下是不启用的。 `annotate`    | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的注解。 `api-resources`    | `kubectl api-resources [flags]` | 列出可用的 API 资源。 `api-versions`    | `kubectl api-versions [flags]` | 列出可用的 API 版本。

web
/retitle [zh-cn] Fix table formatting errors on the kubectl page
/triage accepted


Question: margin-left: 5%; } .contributor { float: left; width: 100%;

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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26


Question: 1. Download the latest release: ```bash <del> curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" </del> <ins> curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" </ins> ``` <del> To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version. </del> <ins> {{< note >}} To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. </ins> For example, to download version {{< param "fullversion" >}} on macOS, type: ```bash <del> curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` {{< /note >}} 1. Validate the binary (optional) Download the kubectl checksum file: ```bash curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" </ins> ``` <del> Make the kubectl binary executable. </del> <ins> Validate the kubectl binary against the checksum file: ```bash echo "$(<kubectl.sha256)  kubectl" | shasum -a 256 --check ``` If valid, the output is: ```bash kubectl: OK ``` If the check fails, `shasum` exits with nonzero status and prints output similar to: ```bash kubectl: FAILED shasum: WARNING: 1 computed checksum did NOT match ``` {{< note >}} Download the same version of the binary and checksum. {{< /note >}} 1. Make the kubectl binary executable. </ins> ```bash chmod +x ./kubectl ``` <del> 3. Move the binary in to your PATH. </del> <ins> 1. Move the kubectl binary to a file location on your system `PATH`. </ins> ```bash <del> sudo mv ./kubectl /usr/local/bin/kubectl </del> <ins> sudo mv ./kubectl /usr/local/bin/kubectl &&  sudo chown root: /usr/local/bin/kubectl </ins> ``` <del> 4. Test to ensure the version you installed is up-to-date: </del> <ins> 1. Test to ensure the version you installed is up-to-date: </ins> ```bash kubectl version --client

There are no details or instructions on how to validate the binary downloaded from this page via some form of checksum, sha256 or otherwise. For automation purposes, eg. ansible playbook, being able to validate any binary downloads is a requirement of project stakeholders.
The site doesn't allow browsing, but the file is there as kubectl.sha256 afterall. Might be worth mentioning this in the document?
/retitle Document how to validate kubectl binary against checksum / signature /language en /kind feature /triage accepted The page in question is
To fix this: update to use download links from for example also explain to readers that checksum files are available that they can use to compare binaries obtained from elsewhere for example The and shortcodes are useful for automatically filling in the current Kubernetes version. /help /sig cli
This request has been marked as needing help from a contributor. 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 : To fix this: update to use download links from explain to readers that checksum files are available that they can use to compare binaries obtained from elsewhere /sig cli 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
I may be able to help with this /assign


Question: All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Administrator) on the Windows worker node. --> <del> ### 加入 Windows 工作节点   {joining-a-windows-worker-node} </del> <ins> ### 加入 Windows 工作节点   {#joining-a-windows-worker-node} </ins> 你必须安装 `Containers` 功能特性并安装 Docker 工具。相关的指令可以在 [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)

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: ! (One can find this error with regexp: ) Proposed Solution: The custom heading ID should include . () As-is: To-be: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language zh /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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


Question: ``` to list pods that match this selector.  Verify that the list matches the Pods that you expect to provide your Service. <del> If the list of pods matches expectations, but your endpoints are still empty, it's possible that you don't have the right ports exposed.  If your service has a `containerPort` specified, but the Pods that are selected don't have that port listed, then they won't be added to the endpoints list. </del> Verify that the pod's `containerPort` matches up with the Service's `targetPort` #### Network traffic is not forwarded <del> If you can connect to the service, but the connection is immediately dropped, and there are endpoints in the endpoints list, it's likely that the proxy can't contact your pods. There are three things to check: * Are your pods working correctly?  Look for restart count, and [debug pods](#debugging-pods). * Can you connect to your pods directly?  Get the IP address for the Pod, and try to connect directly to that IP. * Is your application serving on the port that you configured?  Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080. </del> <ins> Please see [debugging service](/docs/tasks/debug-application-cluster/debug-service.md) for more information. </ins> ## {{% heading "whatsnext" %}}

In the 'My Service Missing Endpoints' sub-chapter containerPort is mentioned as Service parameter but in fact this should be changed to targetPort: "If your service has a containerPort specified, but the Pods that are selected don't have that port listed, then they won't be to the endpoints list. Verify that the pod's containerPort matches up with the Service's targetPort" Since Service object does not have containerPort, this should be fixed to targetPort.
As I understand it, this issue is about /kind bug /language en /triage accepted
/priority backlog /help
This request has been marked as needing help from a contributor. 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 : /priority backlog /help 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


Question: Used on: ServiceAccount The value for this annotation must be **true** to take effect. <del> This annotation indicates that Pods running as this ServiceAccount may only reference Secret API objects specified in the ServiceAccount's `secrets` field. </del> <ins> When you set this annotation  to "true", Kubernetes enforces the following rules for Pods running as this ServiceAccount: 1. Secrets mounted as volumes must be listed in the ServiceAccount's `secrets` field. 1. Secrets referenced in `envFrom` for containers (including sidecar containers and init containers) must also be listed in the ServiceAccount's secrets field. If any container in a Pod references a Secret not listed in the ServiceAccount's `secrets` field (and even if the reference is marked as `optional`), then the Pod will fail to start, and an error indicating the non-compliant secret reference will be generated. 1. Secrets referenced in a Pod's `imagePullSecrets` must be present in the ServiceAccount's `imagePullSecrets` field, the Pod will fail to start, and an error indicating the non-compliant image pull secret reference will be generated. When you create or update a Pod, these rules are checked. If a Pod doesn't follow them, it won't start and you'll see an error message. If a Pod is already running and you change the `kubernetes.io/enforce-mountable-secrets` annotation to true, or you edit the associated ServiceAccount to remove the reference to a Secret that the Pod is already using, the Pod continues to run. </ins> ### node.kubernetes.io/exclude-from-external-load-balancers

The documentation for the annotation on consists of : This leaves unclear the details of the actual effect of the annotation. By checking I was able to determine that setting this annotation to causes the following enforcements: (1) s mounted as must appear in the 's (2) s referenced in in or must appear in the 's (3) s referenced in of s must appear in the 's (1) is implied by the name of the annotation, but the lack of any mention of (2) or (3) in the documentation forced me to check the code to ensure that it wasn't only enforcing mounting of s as the name implies. The documentation also mentions only the field of the , yet the enforcement also takes into account the 's field (which the 's are checked against). The documentation would be improved by describing the actual enforcement behaviour that this feature implements. This feature may also benefit from being mentioned in the document.
/triage accepted /help /kind feature
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /help /kind feature </details
I see , can come up with something like: I'll take this up?
/assign


Question: ### kube-proxyをアップグレード 1. Kubernetes APIにアクセスできるマシンから、次を実行します、 <del> もう一度{{< param "fullversion" >}}を目的のバージョンに置き換えます: </del> <ins> もう一度{{< skew currentPatchVersion >}}を目的のバージョンに置き換えます: </ins> ```shell <del> curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f - </del> <ins> curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/v{{< skew currentPatchVersion >}}/g' | kubectl apply -f - </ins> ```

Problem: Based on , I have created this issue/task to help update the [ja] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/ja" /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/containers/container- 46: IPDNS /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- 146: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- 283: )Service /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- 220: {{< param "fullversion" }}: 223: minikube start --kubernetes-version {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- 34: Linux{{< param "fullversion" }}: 37: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 116: macOS{{< param "fullversion" }}: 119: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 181: {{< 181: "fullversion" }}){{< param "fullversion" }} 186: curl -LO {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- 107: Kubernetes{{< param "fullversion" }} 111: releases/latest/download/kube- kubectl apply -f - 150: .PrepareNode.

ps1 -KubernetesVersion {{% param "fullversion" %}} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- 35: # {{% param "fullversion" %}} 36: -Lo C:k {{% param "fullversion" %}} 70: -Lo C:k {{% param "fullversion" %}} 86: {{< param "fullversion" }}: 89: releases/latest/download/kube- kubectl apply -f - /sig docs /sig localization /language ja cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: Page to Update: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- /sig localization /language ja cc: 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
cc:
/triage accepted /area localization /priority backlog


Question: ### Cài đặt kubectl binary với curl trên Windows <del> 1. Tải về phiên bản mới nhất {{< param "fullversion" >}} từ [đường dẫn này](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). </del> <ins> 1. Tải về phiên bản mới nhất {{< skew currentPatchVersion >}} từ [đường dẫn này](https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe). </ins> Hoặc nếu bạn đã cài đặt `curl`, hãy sử dụng câu lệnh sau: ``` <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe </ins> ``` Để tìm ra phiên bản ổn định mới nhất, hãy xem [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).

Problem: Based on , I have created this issue/task to help update the [vi] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/vi" /home/rdlugyhe/kubernetes/k8s-website/content/vi/docs/tasks/tools/install- 36: Ví dụ như, để tải về phiên bản {{< param "fullversion" }} trên Linux, hãy nhập như sau: 39: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 111: Ví dụ, để tải về phiên bản {{< param "fullversion" }} trên macOS, gõ: 114: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 176: 1. Tải về phiên bản mới nhất {{< param "fullversion" }} từ đường dẫn nàyg


Question: Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. <del> Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. </del> <ins> Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. </ins> Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The `kubernetes` service (in all namespaces) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver.

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: Content references "GKE" which is a Google product. Proposed Solution: Rewrite the sentence to pertain to Kubernetes, not Google. Page to Update:
/kind bug /priority important-longterm /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 : /kind bug /priority important-longterm /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
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /kind bug /priority important-longterm /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
Also if this is the I think it is... hi! long time no see! :)
/assign
Hi I think you're talking about the following sentence: Should we change it to "On a Kubernetes deployment, the client credentials provided to the kubelet are in the form of a client certificate." ? Any better suggestions to rephrase it? Thank you.
- As long as that statement is technically accurate for Kubernetes.


Question: title: "verify kubectl install" description: "How to verify kubectl." headless: true <ins> _build: list: never render: never publishResources: false </ins> --- In order for kubectl to find and access a Kubernetes cluster, it needs a

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: The source Markdown needs to exist for pages such as but we don't need to make those turn into actual web pages. Proposed Solution: Edit every file within : Page to Update: and its contents /area web-development /help /priority backlog /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The source Markdown needs to exist for pages such as but we don't need to make those turn into actual web pages. Edit every file within : Page to Update: and its contents /help /priority backlog /good-first-issue </details
/retitle Include files for install are rendered and served /triage accepted
/assign
/unassign
Thanks !