Question: There are several different proxies you may encounter when using Kubernetes: <del> 1. The [kubectl proxy](#directly-accessing-the-rest-api): </del> <ins> 1. The [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api): </ins> - runs on a user's desktop or in a pod - proxies from a localhost address to the Kubernetes apiserver - client to proxy uses HTTP - proxy to apiserver uses HTTPS - locates apiserver - adds authentication headers <del> 1. The [apiserver proxy](#discovering-builtin-services): </del> <ins> 1. The [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): </ins> - is a bastion built into the apiserver - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable - runs in the apiserver processes

<!-- 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: The bullet points nested under numbered list aren't rendered as bulleted list: <img width="869" alt="screen shot 2017-06-10 at 2 15 49 pm" src="https://user-"Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
The sub-link isn't correct either. For example, kubectl proxy links to but should instead link to I guess it's because is split from () /assign


Question: <!-- body --> ## {{% heading "prerequisites" %}} <del> {{% thirdparty-content single="true" %}} <!-- if adding another runtime in the future, omit the single setting --> </del> <ins> {{% thirdparty-content %}} <!-- When merging this with the dev-1.27 branch conflicts will arise. The text as it is in the dev-1.27 branch should be used. --> </ins> This is a Linux only feature. In addition, support is needed in the {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} to use this feature with Kubernetes stateless pods: <del> * CRI-O: v1.25 has support for user namespaces. </del> <ins> * CRI-O: version 1.25 (and later) supports user namespaces for containers. </ins> <del> * containerd: support is planned for the 1.7 release. See containerd issue [#7063][containerd-userns-issue] for more details. </del> <ins> * containerd: version 1.7 supports user namespaces for containers, compatible with Kubernetes v1.25 and v1.26, but not with later releases. If you are running a different version of Kubernetes, check the documentation for that Kubernetes release. </ins> Support for this in [cri-dockerd is not planned][CRI-dockerd-issue] yet. [CRI-dockerd-issue]: https://github.com/Mirantis/cri-dockerd/issues/74 <del> [containerd-userns-issue]: https://github.com/containerd/containerd/issues/7063 </del> ## Introduction

CONDITION was running with UserNamespacesStatelessPodsSupport=true -apiserver was running with UserNamespacesStatelessPodsSupport=true busybox-user configured hostUsers: false deployed successfully: file created: containerd log, no UserNameSpace Option in spec.Spec struct (I modified the log to highlight NamespaceOptions part): SYMPTOM No Pod user namespace created:container was running as root:no id mapping set in uid_map: Pod user namespace created with command was running as non-root user feature gate for kubelet and apiserver Pod configuration and apply it user namespace with I have tested directly with and to confirm runc support user namespace. Here is part of feature output, so I think containerd and runc part is OK: It seems kubelet did not provide the correct user namespace options in request of RunPodSandbox. <details</details<detailsno </details<details</details<details</details<details</details<detailsNot relavent </details
/sig node
can you please attach the for this. First, it will confirm that kubelet picked up the configuration and second it may have some failures that can give a clue what is happening /cc /triage needs-information
any chance you can try the same set up on an OS with newer kernel version? Just to confirm if this is OS specific or not
Am I reading the report correctly and you are using containerd 1.6? I mean, it says wrongly formatted this: In that case, this is completely expected. It is documented here too, see the end of this section in bold letter: https://v1- What this means is: support for userns was in containerd 1.7. Older versions of containerd, for backwards compatibility, just ignore the request of userns from the kubelet.
Also, in the original report, you pasted twice the api-server in the output of :)
if confirms this is running containerd 1.6, I think we can close this :)
1.7 supports it, correct?

Can you send an update for https://v1-
/remove-kind bug /kind documentation /triage accepted /retitle "document that containerd 1.6 does not support userns feature (KEP 127)"
/triage accepted
/retitle "document that containerd 1.7 is needed to use the userns feature (KEP 127)"
In which case, I think the place to explain that is /remove-triage needs-information
/transfer website
/language en /sig docs
thanks, done! Please note, though, that the link I pasted (https://v1-) mentions also that support is needed from the container runtime (if you don't have support what was reported here happens) and the only runtime supported is CRIO. I think maybe that was not so clear, and now containerd 1.7 was released a few days ago, so I opened a PR to mention containerd 1.7 and hopefully clarify the runtime support
Thank you for kind reply. containerd version is 1.6.8 in my env. I'll try to update it to 1.7.0 and deploy the rootless pod again. Besides, I have already tried to debug run the kubelet from src with dlv and confirmed that the API request contained userns options(idmapping). So the problem likely exists on containerd side.
Additionally, the information provided by kubelet's log is so limited. That makes me hard to locate the problem.
Here is the update after I upgrade containerd 1.6.8 -1.7.0 After I deploy the rootless pod: userns created: is running as the rootless user: mapping is correct: Thank you for the great help!
And what about OCI runtime version (eg. runc)? I think it is helpful to clarify its version requisition.
cool, great that it is working now! Regarding the OCI runtime, each containerd version mandates that at least runc version X should be used, so we should be safe with that. I think distros honor it too, but if you know some example where it is not honored, let us know!


Question:
Kubernetes Basics

This tutorial provides a walkthrough of the basics of the Kubernetes cluster orchestration system. Each module contains some background information on major Kubernetes features and concepts, and includes an interactive online tutorial. These interactive tutorials let you manage a simple cluster and its containerized applications for yourself.

This tutorial provides a walkthrough of the basics of the Kubernetes cluster orchestration system. Each module contains some background information on major Kubernetes features and concepts, and includes an interactive online tutorial. These interactive tutorials let you manage a simple cluster and its containerized applications for yourself.

Using the interactive tutorials, you can learn to:

Deploy a containerized application on a cluster

This is a... [ x] Feature Request Problem: I am missing a definition of "containerized applications". Proposed Solution: It would be nice if this term ("containerized applications") would be a hyperlink to a place where I can find more details about what this term means in the context of kubernetes. Page to Update:


Question: This page contains a list of commonly used `kubectl` commands and flags. <ins> {{< note >}} These instructions are for Kubernetes v{{< skew currentVersion >}}. To check the version, use the `kubectl version` command. {{< /note >}} </ins> <!-- body --> ## Kubectl autocomplete

Feedback a confusing point about kubectl command on page: <img width="1107" alt="image" src="https://user-""kubectl events " command seems just available in k8s-v1.26 release version, while below v1.26 not work yet. so a brief tip or comment on the page will be easy to understand. FYI.
Page: /language en /kind suggestion
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Page: /language en /kind suggestion 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
In my opinion, the cheat sheet is accurate for Kubernetes v1.26. However, if someone needs to refer to older documentation, they can access it by using the version selector option in the navigation bar. To improve clarity, the cheat sheet could integrate details from and provide explicit links within the content body to the other available versions. This approach would be more effective than simply relying on the version selector in the top navigation. Would folks consider this suggestion beneficial?
/retitle Improve clarity of kubectl Cheat Sheet with version information
I'd like to see a shortcode that renders as helper text to steer people to the right documentation, and a link to available versions. See for an example where I'd use this: we could replace that text with an even more helpful shortcode.
We could add a comment that this is accurate for this version of the docs. /priority backlog
I recommend the simple comment approach. We can still use version shortcodes, eg in the comment. /triage accepted
/assign
FYI


Question:
 KubeCon + CloudNativeCon NA 2022 Detroit, Michigan + Virtual. message: |  5 days of incredible opportunites to collaborate, learn + share with the entire community!
   5 days of incredible opportunities to collaborate, learn + share with the entire community!
  October 24 - 28, 2022.

Problem: The text opportunites is mistyped on the announcement section of . For the problem, check the page . File to Update: /good-first-issue /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text opportunites is mistyped on the announcement section of . For the problem, check the page . /kind document /assign /language en 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-good-first-issue Banner changes are actually a bit weird.
/language en
/triage accepted


Question: automatically assigned the `default` service account of the same namespace.  If you get the raw json or yaml for a pod you have created (e.g. `kubectl get pods/podname -o yaml`), you can see the `spec.serviceAccount` field has been <del> [automatically set](working-with-resources/#resources-are-automatically-modified). </del> <ins> [automatically set](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). </ins> You can access the API using a proxy or with a client library, as described in [Accessing the Cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).

I wish /docs/admin/cluster-components/dns/ page existed It's linked from


Hi! I would like to add diagram for command. It is already done (you can find it ). But I found that page is auto-generated from the code, so I have several questions: 1) What is a proper place for images for such pages and how can I insert it? 2) What is your opinion about this diagram and about similar diagrams in general?
cc
Nice diagram! In general, we would like more diagrams. How did you create it? If someone needs to update it, how would they do that? Yes, that page is generated from kubectl help. While we figure out something better, we could link to the diagram from the help description. cc
Thanks! I have one more ;) for I used online service. It is free and I do not see any ad there (maybe because of adblock :D ). It supports import/export mechanism via xml(an example of and for kubectl_drain diagram). So it is possible to put xml source file somewhere near the image. So I need to make two PR: first one to and second one with description update. Am I right?
Also, the service I used supports export to svg, so it should be not a hard task to extend diagram with other tools.
Any suggestions?


Question:
 --- title: Linux kernel security constraints for Pods and containers description: > Overview of Linux kernel security modules and constraints that you can use to harden your Pods and containers. content_type: concept weight: 100 ---  This page describes some of the security features that are built into the Linux kernel that you can use in your Kubernetes workloads. To learn how to apply these features to your Pods and containers, refer to [Configure a SecurityContext for a Pod or Container](/docs/tasks/configure-pod-container/security-context/). You should already be familiar with Linux and with the basics of Kubernetes workloads.  ## Run workloads without root privileges {#run-without-root} When you deploy a workload in Kubernetes, use the Pod specification to restrict that workload from running as the root user on the node. You can use the Pod `securityContext` to define the specific Linux user and group for the processes in the Pod, and explicitly restrict containers from running as root users. Setting these values in the Pod manifest takes precedence over similar values in the container image, which is especially useful if you're running images that you don't own. {{< caution >}} Ensure that the user or group that you assign to the workload has the permissions required for the application to function correctly. Changing the user or group to one that doesn't have the correct permissions could lead to file access issues or failed operations. {{< /caution >}} Configuring the kernel security features on this page provides fine-grained control over the actions that processes in your cluster can take, but managing these configurations can be challenging at scale. Running containers as non-root, or in user namespaces if you need root privileges, helps to reduce the chance that you'll need to enforce your configured kernel security capabilities. ## Security features in the Linux kernel {#linux-security-features} Kubernetes lets you configure and use Linux kernel features to improve isolation and harden your containerized workloads. Common features include the following: * **Secure computing mode (seccomp)**: Filter which system calls a process can make * **AppArmor**: Restrict the access privileges of individual programs * **Security Enhanced Linux (SELinux)**: Assign security labels to objects for more manageable security policy enforcement To configure settings for one of these features, the operating system that you choose for your nodes must enable the feature in the kernel. For example, Ubuntu 7.10 and later enable AppArmor by default. To learn whether your OS enables a specific feature, consult the OS documentation. You use the `securityContext` field in your Pod specification to define the constraints that apply to those processes. The `securityContext` field also supports other security settings, such as specific Linux capabilities or file access permissions using UIDs and GIDs. To learn more, refer to [Configure a SecurityContext for a Pod or Container](/docs/tasks/configure-pod-container/security-context/). ### seccomp Some of your workloads might need privileges to perform specific actions as the root user on your node's host machine. Linux uses *capabilities* to divide the available privileges into categories, so that processes can get the privileges required to perform specific actions without being granted all privileges. Each capability has a set of system calls (syscalls) that a process can make. seccomp lets you restrict these individual syscalls.  It can be used to sandbox the privileges of a process, restricting the calls it is able to make from userspace into the kernel. In Kubernetes, you use a *container runtime* on each node to run your containers. Example runtimes include CRI-O, Docker, or containerd. Each runtime allows only a subset of Linux capabilities by default. You can further limit the allowed syscalls individually by using a seccomp profile. Container runtimes usually include a default seccomp profile.  Kubernetes lets you automatically apply seccomp profiles loaded onto a node to your Pods and containers. {{<note>}} Kubernetes also has the `allowPrivilegeEscalation` setting for Pods and containers. When set to `false`, this prevents processes from gaining new capabilities and restricts unprivileged users from changing the applied seccomp profile to a more permissive profile. {{</note>}} To learn how to implement seccomp in Kubernetes, refer to [Restrict a Container's Syscalls with seccomp](/docs/tutorials/security/seccomp/). To learn more about seccomp, see [Seccomp BPF](https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html) in the Linux kernel documentation. #### Considerations for seccomp {#seccomp-considerations} seccomp is a low-level security configuration that you should only configure yourself if you require fine-grained control over Linux syscalls. Using seccomp, especially at scale, has the following risks: * Configurations might break during application updates * Attackers can still use allowed syscalls to exploit vulnerabilities * Profile management for individual applications becomes challenging at scale **Recommendation**: Use the default seccomp profile that's bundled with your container runtime. If you need a more isolated environment, consider using a sandbox, such as gVisor. Sandboxes solve the preceding risks with custom seccomp profiles, but require more compute resources on your nodes and might have compatibility issues with GPUs and other specialized hardware. ### AppArmor and SELinux: policy-based mandatory access control {#policy-based-mac} You can use Linux policy-based mandatory access control (MAC) mechanisms, such as AppArmor and SELinux, to harden your Kubernetes workloads. #### AppArmor  [AppArmor](https://apparmor.net/) 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, and file permissions. 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. The container runtime that you use might ship with a default AppArmor profile, or you can use a custom profile. To learn how to use AppArmor in Kubernetes, refer to [Restrict a Container's Access to Resources with AppArmor](/docs/tutorials/security/apparmor/). #### SELinux SELinux is a Linux kernel security module that lets you restrict the access that a specific *subject*, such as a process, has to the files on your system. You define security policies that apply to subjects that have specific SELinux labels. When a process that has an SELinux label attempts to access a file, the SELinux server checks whether that process' security policy allows the access and makes an authorization decision. In Kubernetes, you can set an SELinux label in the `securityContext` field of your manifest. The specified labels are assigned to those processes. If you have configured security policies that affect those labels, the host OS kernel enforces these policies. To learn how to use SELinux in Kubernetes, refer to [Assign SELinux labels to a container](/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container). #### Differences between AppArmor and SELinux {#apparmor-selinux-diff} The operating system on your Linux nodes usually includes one of either AppArmor or SELinux. Both mechanisms provide similar types of protection, but have differences such as the following: * **Configuration**: AppArmor uses profiles to define access to resources. SELinux uses policies that apply to specific labels. * **Policy application**: In AppArmor, you define resources using file paths. SELinux uses the index node (inode) of a resource to identify the resource. ### Summary of features {#summary} The following table describes the use cases and scope of each security control. You can use all of these controls together to build a more hardened system.

Summary of Linux kernel security features

 Security feature	 Description	 How to use	 Example

 seccomp	 Restrict individual kernel calls in the userspace. Reduces the likelihood that a vulnerability that uses a restricted syscall would compromise the system.	 Specify a loaded seccomp profile in the Pod or container specification to apply its constraints to the processes in the Pod.	 Reject the unshare syscall, which was used in CVE-2022-0185.

 AppArmor	 Restrict program access to specific resources. Reduces the attack surface of the program. Improves audit logging.	 Specify a loaded AppArmor profile in the container specification.	 Restrict a read-only program from writing to any file path in the system.

 SELinux	 Restrict access to resources such as files, applications, ports, and processes using labels and security policies.	 Specify access restrictions for specific labels. Tag processes with those labels to enforce the access restrictions related to the label.	 Restrict a container from accessing files outside its own filesystem.

 {{< note >}} Mechanisms like AppArmor and SELinux can provide protection that extends beyond the container. For example, you can use SELinux to help mitigate [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736). {{< /note >}} ### Considerations for managing custom configurations {#considerations-custom-configurations} seccomp, AppArmor, and SELinux usually have a default configuration that offers basic protections.  You can also create custom profiles and policies that meet the requirements of your workloads. Managing and distributing these custom configurations at scale might be challenging, especially if you use all three features together. To help you to manage these configurations at scale, use a tool like the [Kubernetes Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator). ## Kernel-level security features and privileged containers {#kernel-security-features-privileged-containers} Kubernetes lets you specify that some trusted containers can run in *privileged* mode. Any container in a Pod can run in privileged mode to use operating system administrative capabilities that would otherwise be inaccessible. This is available for both Windows and Linux. Privileged containers explicitly override some of the Linux kernel constraints that you might use in your workloads, as follows: * **seccomp**: Privileged containers run as the `Unconfined` seccomp profile, overriding any seccomp profile that you specified in your manifest. * **AppArmor**: Privileged containers ignore any applied AppArmor profiles. * **SELinux**: Privileged containers run as the `unconfined_t` domain. ### Privileged containers {#privileged-containers}  Any container in a Pod can enable *Privileged mode* if you set the `privileged: true` field in the [`securityContext`](/docs/tasks/configure-pod-container/security-context/) field for the container. Privileged containers override or undo many other hardening settings such as the applied seccomp profile, AppArmor profile, or SELinux constraints. Privileged containers are given all Linux capabilities, including capabilities that they don't require. For example, a root user in a privileged container might be able to use the `CAP_SYS_ADMIN` and `CAP_NET_ADMIN` capabilities on the node, bypassing the runtime seccomp configuration and other restrictions. In most cases, you should avoid using privileged containers, and instead grant the specific capabilities required by your container using the `capabilities` field in the `securityContext` field. Only use privileged mode if you have a capability that you can't grant with the securityContext. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. In Kubernetes version 1.26 and later, you can also run Windows containers in a similarly privileged mode by setting the `windowsOptions.hostProcess` flag on the security context of the Pod spec. For details and instructions, see [Create a Windows HostProcess Pod](/docs/tasks/configure-pod-container/create-hostprocess-pod/). ## Recommendations and best practices {#recommendations-best-practices} * Before configuring kernel-level security capabilities, you should consider implementing network-level isolation. For more information, read the [Security Checklist](/docs/concepts/security/security-checklist/#network-security). * Unless necessary, run Linux workloads as non-root by setting specific user and group IDs in your Pod manifest and by specifying `runAsNonRoot: true`. Additionally, you can run workloads in user namespaces by setting `hostUsers: false` in your Pod manifest. This lets you run containers as root users in the user namespace, but as non-root users in the host namespace on the node. This is still in early stages of development and might not have the level of support that you need. For instructions, refer to [Use a User Namespace With a Pod](/docs/tasks/configure-pod-container/user-namespaces/). ## {{% heading "whatsnext" %}} * [Learn how to use AppArmor](/docs/tutorials/security/apparmor/) * [Learn how to use seccomp](/docs/tutorials/security/seccomp/) * [Learn how to use SELinux](/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container)

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 The doesn't mention that you can run Pods with AppArmor / seccomp / whatever to constrain the container. Why is this needed Although we have tutorials that explain the concepts in the manner of a walkthough, having a concept guide is important too. It's OK if the mention within is more like a signpost: a hyperlink to another page such as (which doesn't exist). Comments /sig security Relevant to Relevant to
This should be a fun time Since we already talk about privileged mode on the Pods page I agree that it's important to talk about the security constraints that you can place on containers. I also agree that a standalone page that discusses container isolation strategies and kernel-level security measures would be a good addition to our docs. /triage accepted /assign
As a first step, I'll find out if this information exists across our current docs (it definitely does) and draft up a plan for changes.
The framing here should be: small simple soon
Thanks If you're willing to focus first on the minimum viable change that can allow seccomp and AppArmor to graduate with docs in place, that'll help. It does mean more overall work if you then revisit things to make a larger improvement. Sorry about that.
Going through the current content it feels disconnected talking about Privileged mode, without not mentioning isolation levels. For someone starting their learning journey it may be hard to understand what that really means. In my opinion, the existing section could become a higher level section about Security Context (or a brief point on isolation levels), and within there we could talk about the ways of constraining (or enforcing isolation of) the container execution via AppArmor, Seccomp, SELinux and Privileged containers. We probably should use this opportunity to highlight the impact of privileged mode on those constraints. wdyt?
Agreed that it's a bit out of place there.

We already have so I wonder how that fits... Regardless for the mvp for this issue I'll focus on a smaller scope to meet the requirements here and then we can fiddle and improve
Planned here: I'd appreciate reviews on the scope so that I can do a draft and get that reviewed
I drafted the MVP of that page: It's missing some info that I am not sure about
I'd be happy to see a PR anyway.
Still working on this, will send a PR soon
would you like any help here?
I'll open a draft PR in the coming days. One final ish question: The content in (the seccomp and Apparmor/SELinux sections) are a summary basically of the content in this new page. Think it's a good idea to remove that bulk from the checklist page and link to the new page to learn more?
I'd really like to hear your thoughts on Shannon's question in
Security has been one of the top concerns for a few years when people start evaluating k8s. What I'd like to see is a single concept page clearly outlining all relevant topics as links to more detailed references. In this concept page, we may want to articulate the shared-responsibility model where security topics are organized based on users' persona. In other words, as an application developer, what are the things I need to pay attention to? As a cluster operator, what are the best practices I need to check. As someone who prepares the underlying infrastructure, is there a checklist for me?
If merges first, we could build on that. Thoughts there?
I agree - we can expand that page or work it into a more use case based signposting topic. Some considerations though: We should think about how to organize it. There's the CNCF white paper phases, yes, but there's also the opportunity to organize by pillar, like authn/z, encryption, monitoring and logging, etc. Maybe a sensible combination of the two? The links we provide should be associated with specific jobs to be done. For example, in the Authorization pillar, we could have "Authorize actions in clusters" and list the learning journey (About authorization RBAC RBAC good practices RBAC how-to) Maybe we can create a follow-up issue for this and discuss the actual presentation of that information there?
Maybe we can draft a toc for this on google docs for discussion?

sounds good to me, we should probably also create a backlog issue for tracking purposes (I can do it later today I'm away from my computer still waking up )
Relevant to
We can now link from the Pod concept to


Question: main_menu: true weight: 20 content_type: concept <ins> no_list: true </ins> card: name: setup weight: 20

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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Update Japanese translation sync to original English version Wed Nov 23 15:06:08 2022 +0530. Why is this needed outdated doc Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /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
/assign


Question: driver of the kubelet. {{< note >}} <del> In v1.22, if the user is not setting the `cgroupDriver` field under `KubeletConfiguration`, `kubeadm` will default it to `systemd`. </del> <ins> In v1.22 and later, if the user does not set the `cgroupDriver` field under `KubeletConfiguration`, kubeadm defaults it to `systemd`. </ins> {{< /note >}} A minimal example of configuring the field explicitly:

says the default value for is . says: The latter does not say, that prior to 1.23 (thus 1.22, 1.21, 1.20) the default was and was later changed to . It says, that in the nearly end-of-life 1.22 the default is . Later contains: In the above text, it is nowhere stated, that there is a plan to switch the default value of KubeletConfiguration.cgroupDriver from cgroupfs to systemd. The last citation suggests, that will perform implicit switch from to . This is strengthened by the fact about 1.22, where the implicit (default) value seems to be . All in all, the above information stipulates, that in 1.22 the default value was , not it is and in the future will use as implicit (default) value again . In the lack of discussion in the documentation why the defauls change back and forth, this does not make sense,
the kubelet default is cgroupfs and it's not clear if the kubelet graduates cgroupv2 support to GA the value will change. afaik, cgroupfs does not support v2. in any case this can be a disruptive change. kubeadm changed its default to systemd because the kubelet in kubeadm setups is managed by systemd. the reason is explained here long term, the cgroup driver detail should not be exposed to users, but that is blocked on some cri work. /kind support
Ah, so the default cgroup driver for kubelet is cgroupfs, while for kubeadm the default is systemd. This shall be spelled explicitly, as it is counter-intuitive. My understanding so far is, that the systemd-driver supports kernel’s cgroup v2, while kubernetes’ cgroup-driver does not support kernel’s cgroup v2. This shall also be spelled explicitly, as it is confusing.
It sounds like the thing to call out is that, in the kubeadm docs, we should explicitly say that the setting that kubeadm applies by default is an override to the built-in kubelet default. Does that sound right?
Yes. Ideally kubeadm and kubelet shall explicitly state, that their default is distinct from the default of the other tool.

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 /help
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 : /remove-lifecycle stale /help </details
/triage accepted
/assign


Question: ### Suggest changes Create or update your chosen localized page based on the English original. See <del> [translating content](#translating-content) for more details. </del> <ins> [localize content](#localize-content) for more details. </ins> If you notice a technical inaccuracy or other problem with the upstream (English) documentation, you should fix the upstream documentation first and

This is a Bug Report Problem: The link available for is broken. The has whose value is which is "broken". Proposed Solution: changes to Page to Update: Additional Information: I am willing to submit the PR.
/kind documentation
/assign
/retitle Broken hyperlink for "Translating content" in "Localizing Kubernetes documentation" page /language en
/triage accepted /priority backlog


Question:
echo "NODE_PORT=$NODE_PORT"

Now we can test that the app is exposed outside of the cluster using curl, the IP address of the Node and the externally exposed port:

curl http://"$(minikube ip):$NODE_PORT"
  {{< note >}}
If Docker is the container runtime, a minikube tunnel is needed. This is because Docker Desktop does not support ports.
   {{< note >}}
If you're running minikube with Docker Desktop as the container driver, a minikube tunnel is needed. This is because containers inside Docker Desktop are isolated from your host computer.

In a separate terminal window, execute:
  $ minikube service kubernetes-bootcamp --url
   minikube service kubernetes-bootcamp --url

The output looks like this:
http://127.0.0.1:51082
!  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

Then use the given URL to access the app:
  $ curl 127.0.0.1:51082
   curl 127.0.0.1:51082
  {{< /note >}}
And we get a response from the server. The Service is exposed.

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: had some on to pending Proposed Solution: Update to incorporate the feedback from Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog /help Kubernetes documentation .
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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: had some on to pending Update to incorporate the feedback from <!--Kubernetes Version:--/language en /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
/triage accepted
I want to help with this. /assign
Submitted pull request please review.


Question: {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <ins> The `InPlacePodVerticalScaling` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled for your control plane and for all nodes in your cluster. </ins> ## Container Resize Policies

Not able to find which alpha feature gates for
/kind feature /triage accepted // +featureGate=InPlacePodVerticalScaling // +optional ResizePolicy []ContainerResizePolicy This field is controlled by the feature gate . It looks like we need to add a feature gate description. Does anyone want to help? /help
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 : /kind feature /triage accepted /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
There is a blog under review. I do concur that some docs are needed for such an important feature.
We should mention within didn't cover this detail.
InPlacePodVerticalScaling in also missing in
Fix coming in
Hi , as I am unable see the changes can I add it to the page?
The feature gate issue has been fixed but the feature description needs some more formal documentation. Please feel free to provide some inputs.
sure so we need to add the featureGate thing? here
It is not limited to the feature gate. It is about the feature. We are supposed to provide some brief introduction to this feature. Currently we have some texts on it, but those texts are provided as a blog (see ). Some of the blogs could have been part of the docs task page ().
thanks for clarifying
Note that this is the same issue as


Question: <ins> --- title: ファイナライザー id: finalizer date: 2021-07-07 full_link: /ja/docs/concepts/overview/working-with-objects/finalizers/ short_description: > 削除対象としてマークされたオブジェクトを完全に削除する前に、特定の条件が満たされるまでKubernetesを待機させるための名前空間付きのキーです。 aka: tags: - fundamental - operation --- ファイナライザーは、削除対象としてマークされたリソースを完全に削除する前に、特定の条件が満たされるまでKubernetesを待機させるための名前空間付きのキーです。 ファイナライザーは、削除されたオブジェクトが所有していたリソースをクリーンアップするように{{<glossary_tooltip text="コントローラー" term_id="controller">}}に警告します。 <!--more--> Kubernetesにファイナライザーが指定されたオブジェクトを削除するように指示すると、Kubernetes APIはそのオブジェクトに`.metadata.deletionTimestamp`を追加し削除対象としてマークして、ステータスコード`202`(HTTP "Accepted")を返します。 コントロールプレーンやその他のコンポーネントがファイナライザーによって定義されたアクションを実行している間、対象のオブジェクトは終了中の状態のまま残っています。 それらのアクションが完了したら、そのコントローラーは関係しているファイナライザーを対象のオブジェクトから削除します。 `metadata.finalizers`フィールドが空になったら、Kubernetesは削除が完了したと判断しオブジェクトを削除します。 ファイナライザーはリソースの{{<glossary_tooltip text="ガベージコレクション" term_id="garbage-collection">}}を管理するために使うことができます。 例えば、コントローラーが対象のリソースを削除する前に関連するリソースやインフラをクリーンアップするためにファイナライザーを定義することができます。 </ins>

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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /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: ExecStart= # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs". # Replace the value of "--container-runtime-endpoint" for a different container runtime if needed. <del> ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --container-runtime=remote --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock </del> <ins> ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock </ins> Restart=always EOF

Documentation for external etcd cluster for kubernetes 1.27 is not up to date That the documentation doesn't take into consideration the fact that was removed in version 1.27 of kubelet: Restart=always Just try to install kubernetes with an external etcd cluster (which right now doesn't work anyway also for other reasons related to this ) with version 1.27.2 and you'll get: No response <details27.2 </details<detailsself-hosted </details<details</details<detailskubeadm </details<detailscontainerd </details<detailscalico </details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. 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
/transfer website /assign
removed the comment in v1.27. is not re-generated. I opened to fix it.
/retitle flag still in the documentation for external etcd in version 1.27 despite removal /language en /triage accepted


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

Problem: Google search for "kubernetes secrets v2" returns: ! (notice the URL subdomains) Proposed Solution: I need to do some more research but a few things come to mind: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" That is assuming robots tag is the culprit. What's also strange is that the above robot config is set in but doesn't appear in the search results I also think looking at might help. It's possible this problem has been solved and phased out with future releases. /priority important-soon /triage accepted /help /cc
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 : Problem: is in and set in the couple repos I checked. is set in . I believe this is for non-prod sites that are running, however I believe even the old released sites are considered "production" /triage accepted /help /cc </details
https://v1- does look wrong. We could override this file explicitly for the older releases (perhaps just as an interim measure?)
In the v1.19 docs, appears in the page head. That's wrong.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle frozen
/retitle Search engines indexing old releases Also, the upcoming release is also being indexed and we don't actually want that. Same cause I think.
Hi and I would like to work on this issue. I can see the proposed solution has already been implemented.

May I know, what new things we need to work on for this issue? Now, Google search for "kubernetes secrets v2" returns: ! /assign
I've proposed a PR to fix this. :crossed_fingers:
/reopen We also need to merge 4 backport PRs.
Reopened this issue. <detailsIn response to : /reopen 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
[Backport PRs]
It's fixed. I checked. /close
Closing this issue. <detailsIn response to : It's fixed. I checked. /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: <del> --- title: 新しいコンテンツの貢献の概要 linktitle: 概要 content_type: concept main_menu: true weight: 5 --- <!-- overview --> このセクションでは、新しいコンテンツの貢献を行う前に知っておくべき情報を説明します。 <!-- body --> ## 貢献の基本 - KubernetesのドキュメントはMarkdownで書き、Kubernetesのウェブサイトは[Hugo](https://gohugo.io/)を使ってビルドします。 - ソースは[GitHub](https://github.com/kubernetes/website)にあります。Kubernetesのドキュメントは`/content/en/docs/`にあります。リファレンスドキュメントの一部は、`update-imported-docs/`ディレクトリ内のスクリプトから自動的に生成されます。 - [Page content types](/docs/contribute/style/page-content-types/)にHugoによるドキュメントのコンテンツの見え方を記述しています。 - 標準のHugoのshortcodeに加えて、多数の[カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)を使用してコンテンツの見え方をコントロールしています。 - ドキュメントのソースは`/content/`内にある複数の言語で利用できます。各言語はそれぞれ[ISO 639-1標準](https://www.loc.gov/standards/iso639-2/php/code_list.php)で定義された2文字のコードの名前のフォルダを持ちます。たとえば、英語のドキュメントのソースは`/content/en/docs/`内に置かれています。 - 複数言語でのドキュメントへの貢献や新しい翻訳の開始に関する情報については、[Kubernetesのドキュメントを翻訳する](/docs/contribute/localization)を参照してください。 ## 始める前に {#before-you-begin} ### CNCF CLAに署名する {#sign-the-cla} すべてのKubernetesのコントリビューターは、[コントリビューターガイド](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)を読み、[Contributor License Agreement(コントリビューターライセンス契約、CLA)への署名](https://github.com/kubernetes/community/blob/master/CLA.md)を**必ず行わなければなりません**。 CLAへの署名が完了していないコントリビューターからのpull requestは、自動化されたテストで失敗します。名前とメールアドレスは`git config`コマンドで表示されるものに一致し、gitの名前とメールアドレスはCNCF CLAで使われたものに一致しなければなりません。 ### どのGitブランチを使用するかを選ぶ pull requestをオープンするときは、どのブランチをベースにして作業するかをあらかじめ知っておく必要があります。 シナリオ | ブランチ :---------|:------------ 現在のリリースに対する既存または新しい英語のコンテンツ | `master` 機能変更のリリースに対するコンテンツ | 機能変更が含まれるメジャーおよびマイナーバージョンに対応する、`dev-<version>`というパターンのブランチを使います。たとえば、機能変更が`v{{< skew nextMinorVersion >}}`に含まれる場合、ドキュメントの変更は``dev-{{< skew nextMinorVersion >}}``ブランチに追加します。 他の言語内のコンテンツ(翻訳) | 各翻訳対象の言語のルールに従います。詳しい情報は、[翻訳のブランチ戦略](/docs/contribute/localization/#branching-strategy)を読んでください。 それでも選ぶべきブランチがわからないときは、Slack上の`#sig-docs`チャンネルで質問してください。 {{< note >}} すでにpull requestを作成していて、ベースブランチが間違っていたことに気づいた場合は、作成者であるあなただけがベースブランチを変更できます。 {{< /note >}} ### 言語ごとのPR pull requestはPRごとに1つの言語に限定してください。複数の言語に同一の変更を行う必要がある場合は、言語ごとに別々のPRを作成してください。 ## コントリビューターのためのツール `kubernetes/website`リポジトリ内の[doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools)ディレクトリには、コントリビューターとしての旅を楽にしてくれるツールがあります。 </del>

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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --- Update Japanese translation of Remove (this page is merged into new-content index in English page) Why is this needed outdated page Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question: ### TopologyKeys Deprecation The Service field `topologyKeys` is now deprecated; all the component features that used this field were previously alpha, and are now also deprecated. <del> We've replaced `topologyKeys` with a way to implement topology-aware routing, called topology-aware hints.  Topology-aware hints are an alpha feature in Kubernetes 1.21. You can read more details about the replacement feature in [Topology Aware Hints](/docs/concepts/services-networking/service-topology/); the related [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/2433-topology-aware-hints/README.md) explains the context for why we switched. </del> <ins> We've replaced `topologyKeys` with a way to implement topology-aware routing, called topology-aware hints.  Topology-aware hints are an alpha feature in Kubernetes 1.21. You can read more details about the replacement feature in [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/); the related [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/2433-topology-aware-hints/README.md) explains the context for why we switched. </ins> ## Other Updates

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: Topology-aware traffic routing with topology keys is deprecated since 1.21 Confirm if it's removed and remove the related documentation if feature is removed Proposed Solution: Remove Service Topology page Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Deprecated since 1.21 <!--Additional Information:--
/kind cleanup /language en
I can look into this. /assign
/sign network /triage accepted /priority important-longterm
Thanks


Question: app.kubernetes.io/name: wordpress app.kubernetes.io/instance: wordpress-abcxzy app.kubernetes.io/version: "4.9.4" <del> app.kubernetes.io/managed-by: helm </del> <ins> app.kubernetes.io/managed-by: Helm </ins> app.kubernetes.io/component: server app.kubernetes.io/part-of: wordpress ...

There is a suggested annotation of: But Helm actually : Which will insert a value of "Helm", with a first character in uppercase. According to , labels are case-sensitive, except for the prefix. (You can notice this discrepancy if you are using the plug-in, as your chart with a lower-case word will always be replaced with upper-case, so a three-way-merge diff shows this as changing every time. I also imagine you could find this if you tried to use the label as a selector) Therefore I recommend that the suggested annotation in this document be replaced with: Caveat: I have no idea if the case changed between helm v2 and v3, but v2 is defunct now, so should be safe to make this change.
This is just an example of what could go in, but I think it might be a good first issue. If you want to work on this, assign yourself to this issue. Update all instances of to , including in the table. You should be able to complete this in GitHub without needing to work on a local clone. For instructions, read .
/language en
Let me help with this. /assign
/triage accepted /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 : /triage accepted /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


Question: outline: none; padding: .5em 0 .5em 0; } <ins> /* CSS for 'figure' full-screen display */ /* Define styles for full-screen overlay */ .figure-fullscreen-overlay { position: fixed; inset: 0; z-index: 9999; background-color: rgba(255, 255, 255, 0.95); /* White background with some transparency */ display: flex; justify-content: center; align-items: center; padding: calc(5% + 20px); box-sizing: border-box; } /* CSS class to scale the image when zoomed */ .figure-zoomed { transform: scale(1.2); } /* Define styles for full-screen image */ .figure-fullscreen-img { max-width: 100%; max-height: 100%; object-fit: contain; /* Maintain aspect ratio and fit within the container */ } /* Define styles for close button */ .figure-close-button { position: absolute; top: 1%; right: 2%; cursor: pointer; font-size: calc(5vw + 10px); color: #333; } </ins>  No newline at end of file

This is a Feature Request Some images in concepts sections are quite detailed but in normal scope the texts inside of them look small and unreadable. Can we add feature for the images to pop up on clicking? It will add to the user experience as well as ease the pain of zooming out the page in whole. What would you like to be Feature to Pop up images on click Why is this needed The texts and details seem too small to read. Comments Reference of some of the pages where the issue arises: Example to the pop-up view for image:
/area web-development /kind feature
/area web-development Something similar to https://medium- ?
/retitle Enable click-to-zoom for some diagrams and other images
/triage accepted /priority backlog /lifecycle frozen
Thanks , I investigated on hugo's documents regarding any shortcode or feature that provide this functionality. but till now haven't found any.
For now I'll investigate more and try to find out what can work so assigning it to myself /assign
A couple of hints:
There is one more way like the above reference link mentioned, If we put full-resolution images in other paths and do this : It is in case we want minimal change in the code. I'm going to add ways here as I find so the community can vote or suggest which will be better for a clean code
one is a good reference for same functionality with example. I'll try both and raise a PR after that.
We using vector images.
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted
My apologies,Due to bandwidth issue couldn't work on this, It's open for other people to self-assign.
This could be a positive and beneficial addition to the website. Worth doing (re-triaging as accepted). /triage accepted /lifecycle frozen
Let me see if I can assist with this. Edit: I request review and feedback on pull request


Question: Let's now recreate the Service to use a cloud load balancer, just change the `Type` of `my-nginx` Service from `NodePort` to `LoadBalancer`: --> <del> 让我们重新创建一个 Service，使用一个云负载均衡器，只需要将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`。 </del> <ins> 让我们重新创建一个 Service，使用一个云负载均衡器，只需要将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`。 </ins> ```shell kubectl edit svc my-nginx

Nginx https 404
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
Hi It sounds like you wanted to provide feedback about a web page. Which web page was that? /triage needs-information


Question: * The rollout gets stuck. You can verify it by checking the rollout status: ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this:

I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /triage accepted /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 : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /triage accepted /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
/retitle Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign


Question: What constitutes a compatible change and how to change the API are detailed by the [API change document](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api_changes.md). <del> ## API Swagger definitions </del> <ins> ## OpenAPI and Swagger definitions </ins> <del> Complete API details are documented using [Swagger v1.2](http://swagger.io/). The Kubernetes apiserver (aka "master") exposes an API that can be used to retrieve the Swagger Kubernetes API spec located at `/swaggerapi`. You can also enable a UI to browse the API documentation at `/swagger-ui` by passing the `--enable-swagger-ui=true` flag to apiserver. </del> <ins> Complete API details are documented using [Swagger v1.2](http://swagger.io/) and [OpenAPI](https://www.openapis.org/). The Kubernetes apiserver (aka "master") exposes an API that can be used to retrieve the Swagger v1.2 Kubernetes API spec located at `/swaggerapi`. You can also enable a UI to browse the API documentation at `/swagger-ui` by passing the `--enable-swagger-ui=true` flag to apiserver. </ins> <del> We also host a version of the [latest API documentation](http://kubernetes.io/docs/api-reference/README/). This is updated with the latest release, so if you are using a different version of Kubernetes you will want to use the spec from your apiserver. </del> <ins> We also host a version of the [latest v1.2 API documentation UI](http://kubernetes.io/kubernetes/third_party/swagger-ui/). This is updated with the latest release, so if you are using a different version of Kubernetes you will want to use the spec from your apiserver. Staring kubernetes 1.4, OpenAPI spec is also available at `/swagger.json`. While we are transitioning from Swagger v1.2 to OpenAPI (aka Swagger v2.0), some of the tools such as kubectl and swagger-ui are still using v1.2 spec. OpenAPI spec is in Beta as of Kubernetes 1.5. </ins> Kubernetes implements an alternative Protobuf based serialization format for the API that is primarily intended for intra-cluster communication, documented in the [design proposal](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/proposals/protobuf.md) and the IDL files for each schema are located in the Go packages that define the API objects.

In we mentioned swagger 1.2 however as of 1.5 we will support OpenAPI (swagger 2.0) spec. We should update docs to reflect that.
I believe this is pending with the 1.5 changes that are coming out.
Excellent, is there any staging area with that change I can look at?
I don't see any doc changes for OpenAPI. Please link to the change if I am wrong, otherwise we should at lets mention OpenAPI in the docs and later on (1.6 maybe) remove swagger 1.2 references completely.


Question: baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch enabled=1 gpgcheck=1 <del> repo_gpgcheck=1 </del> gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF sudo yum install -y kubectl

, Red Hat-based distributions: we are facing an issue when installing kubectl on Redhat/centos7 VM, and when applying:
I'm going to take the liberty of reformatting the issue description so that it is more readable.
I'm not sure if you're reporting a fault or if you're asking for advice. If there's a fault, please explain how we can replicate it and how the outcome differs from what you expected. If you want advice, GitHub is not the right place for support requests. You could instead check and ask there if your question has not yet been answered. You can also post your question on the or to the forum. /triage needs-information /language en
I'm reporting an issue, when installing kubectl, using the following: yum install -y kubectl The following failure occurs: if I'm setting and to False and trying to again it is installed successfully. I assume that the following are not valid anymore and needs to be updated:
/sig release
Setting in fixes the issue. ( is still enabled, it's just that must be disabled).
It looks as if the Linux advice for is out of date. Ideally, the Linux Foundation / CNCF / Kubernetes project would publish its own artifacts and not rely on Google here. I'm not sure what the fix would be. My guess is that we do prefer to have all signatures valid and not to recommend that people bypass some of the checks. /sig security is this a duplicate of an existing issue? If so, let's make that link.
/remove-triage needs-information
any update on this issue? Looks like the issue is only with x86_64 rpms
I googled and found some related issues: And here is a from So my suggestion for K8s Docs is: In and ,
At a minimum, we should explain in a comment why this setting is OK. Otherwise folks are bound to ask / file issues / etc. Better would be to migrate away from recommending Google-made packages. It'd be better to be wholly neutral of vendors here (publish our own packages); failing that, we can provide links to packages from Linux distributions: Fedora Ubuntu Debian etc.
As far as I digged: [Fedora] It seems that in the official Fedora packages repo (), the package exists: there is no package; see but there exists a .

I am not sure whether this package contains or not. there is no package; see but we might check these: [Ubuntu] It seems that in the official Ubuntu packages repo, the packages (, , ) does not exist. Instead, provides those packages. [Debian] It seems that in the official Debian packages repo, the packages (, , ) does not exist.
To be clear: the packaging sources are in k/release despite being built on my workstation often (needlessly! there's no real reason this can't be part of the Kubernetes release cloud build, we just block changes to the packaging ...), the packages themselves are defined by the project. The google specific part is the package hosting and signing, which piggybacks on the GCP package host. It would be most excellent to move to community packages, but there are none. There are no other deb/rpm packages for Kubernetes. There are more details about the recommendation in the link quoted above. I think we should be linking there.
Based on , I'm persuaded that we can and should omit mention of from the docs. This will apply the YUM default setting which is not to check the signature on repo metadata. Because that metadata is always accessed over TLS, and the webservers are run by an organization with a reputation for doing TLS well, I think it's absolutely fine.
/triage accepted /priority important-soon
/assign
one word - thank u


Question: padding-top: 2rem !important; } } <ins> .ui-widget { font-family: inherit; font-size: inherit; } .ui-widget-content a { color: $blue; } </ins> } section {

This is a Bug Report Links within the tab component are not displaying using the site link color. Problem: The color of links within tab components is defaulting to . The link is inheriting the color value from jquery-ui- Proposed Solution: Update the style for ui-widget-content -a Page to Update: Start by looking at . Examples: See link in Flatcar Container Linux tab in Look as the "vSphere" tab at the bottom of the page.
Related to PR .
/kind bug /priority backlog /area web-development Feel free to reprioritize
/assign


Question: 这些都是正在运行 Hello World 应用程序的 pod 的内部地址。 要验证这些是 pod 地址，请输入以下命令： <del> kubectl get pods --output=wide </del> <ins> ```shell kubectl get pods --output=wide ``` </ins> <del> <!-- </del> <ins> <!-- </ins> The output is similar to this: <del> --> </del> <ins> --> </ins> 输出类似于： <del> NAME                         ...  IP         NODE hello-world-2895499144-1jaz9 ...  10.0.1.6   gke-cluster-1-default-pool-e0b8d269-1afc hello-world-2895499144-2e5uh ...  10.0.1.8   gke-cluster-1-default-pool-e0b8d269-1afc hello-world-2895499144-9m4h1 ...  10.0.0.6   gke-cluster-1-default-pool-e0b8d269-5v7a hello-world-2895499144-o4z13 ...  10.0.1.7   gke-cluster-1-default-pool-e0b8d269-1afc hello-world-2895499144-segjf ...  10.0.2.5   gke-cluster-1-default-pool-e0b8d269-cpuc </del> <ins> ``` NAME                         ...  IP         NODE hello-world-2895499144-1jaz9 ...  10.0.1.6   gke-cluster-1-default-pool-e0b8d269-1afc hello-world-2895499144-2e5uh ...  10.0.1.8   gke-cluster-1-default-pool-e0b8d269-1afc hello-world-2895499144-9m4h1 ...  10.0.0.6   gke-cluster-1-default-pool-e0b8d269-5v7a hello-world-2895499144-o4z13 ...  10.0.1.7   gke-cluster-1-default-pool-e0b8d269-1afc hello-world-2895499144-segjf ...  10.0.2.5   gke-cluster-1-default-pool-e0b8d269-cpuc ``` </ins> <!-- 1. Use the external IP address (`LoadBalancer Ingress`) to access the Hello World application: --> 8. 使用外部 IP 地址（`LoadBalancer Ingress`）访问 Hello World 应用程序: <del> curl http://<external-ip>:<port> </del> <ins> ```shell curl http://<external-ip>:<port> ``` </ins> <del> <!-- </del> <ins> <!-- </ins> where `<external-ip>` is the external IP address (`LoadBalancer Ingress`) of your Service, and `<port>` is the value of `Port` in your Service description. If you are using minikube, typing `minikube service my-service` will automatically open the Hello World application in a browser. <del> --> </del> <ins> --> </ins> 其中 `<external-ip>` 是您的服务的外部 IP 地址（`LoadBalancer Ingress`）， `<port>` 是您的服务描述中的 `port` 的值。 如果您正在使用 minikube，输入 `minikube service my-service` 将在浏览器中自动打开 Hello World 应用程序。 <del> <!-- </del> <ins> <!-- </ins> The response to a successful request is a hello message: <del> --> </del> <ins> --> </ins> 成功请求的响应是一条问候消息： <del> Hello Kubernetes! </del> <ins> ``` Hello Kubernetes! ``` </ins> ## {{% heading "cleanup" %}} <!-- To delete the Service, enter this command: --> 要删除服务，请输入以下命令： <del> kubectl delete services my-service </del> <ins> ```shell kubectl delete services my-service ``` </ins> <!-- To delete the Deployment, the ReplicaSet, and the Pods that are running

This is a Bug Report Chinese page contentzhdocstutorialsstateless-applicationexpose-external-ip- outdated <!-- 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: Chinese page contentzhdocstutorialsstateless-applicationexpose-external-ip- is different with English version page. Proposed Solution: Update Chinese page Page to Update: contentzhdocstutorialsstateless-applicationexpose-external-ip- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language zh
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
/assign


Question: clear: both; padding: 0px; margin-bottom: 2em; <ins> width: 100%; </ins> } <del> .col { </del> <ins> section.call-to-action { color: #ffffff; background-color: #3371e3; } section.call-to-action .main-section { max-width: initial; } section.call-to-action .main-section > div.call-to-action { display: flex; flex-direction: row; flex-wrap: wrap; flex-basis: auto; justify-content: center; align-items: center; margin: initial; padding-top: 5rem; padding-bottom: 5rem; } section.call-to-action .main-section > div.call-to-action > div { order: 1; padding: 20px; } section.call-to-action .main-section .cta-text { text-align: center; flex: 1 1 auto; max-width: 50vw; } /* if max() and min() are available, use them */ section.call-to-action .main-section .cta-text { min-width: min(20em, 50vw); max-width: min(1000px, 50vw); } section.call-to-action .main-section .cta-image.cta-image-before { order: 0 } section.call-to-action .main-section .cta-image.cta-image-after { order: 2 } section.call-to-action .main-section .cta-image > img { </ins> display: block; <del> float:left; </del> <ins> width: 150px; margin: auto; } .col { display: flex; flex-direction: row; float: left; </ins> margin: 1% 0 1% 1.6%; <del> background-color: #f9f9f9; </del> } .col:first-child { margin-left: 0; } .col-container { <del> display: table; /* Make the container element behave like a table */ </del> <ins> display: flex; /* Make the container element behave like a table */ flex-direction: row; </ins> width: 100%; /* Set full-width to expand the whole page */ padding-bottom: 30px; } .col-nav { <del> display: table-cell; /* Make elements inside the container behave like table cells */ </del> <ins> display: flex; flex-grow: 1; </ins> width: 18%; background-color: #f9f9f9; padding: 20px;

This is feedback by email from within the CNCF/Linux Foundation: add the CKA/CKAD logos from to the page.
I'll take care of this, so assign it to me :)
/assign


Question: > यदि आप विंडोज पर हैं, तो आपको कुछ और टूल्स की आवश्यकता होगी जिन्हें आप [Chocolatey](https://chocolatey.org) के साथ इंस्टॉल कर सकते हैं। <del> > यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे Hugo का उपयोग करके स्थानीय रूप से साइट चलाना देखें। </del> यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे दिए गए Hugo का उपयोग करके स्थानीय रूप से [साइट को चलाने](#hugo-का-उपयोग-करते-हुए-स्थानीय-रूप-से-साइट-चलाना) का तरीका देखें। यदि आप [डॉकर](https://www.docker.com/get-started) चला रहे हैं, तो स्थानीय रूप से `कुबेरनेट्स-ह्यूगो` Docker image बनाएँ:

This is a Bug Report Problem: This line present is same as यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे दिए गए Hugo का उपयोग करके स्थानीय रूप से का तरीका देखें। which is also present in the same place  Page to Update:
/retitle [hi] Duplicate instruction in Hindi README- /language hi
/triage accepted


Question: ## Installation <del> A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). The CRI manages its own CNI plugins. There are two Kubelet command line parameters to keep in mind when using plugins: </del> <ins> A Container Runtime, in the networking context, is a daemon on a node configured to provide CRI Services for kubelet. In particular, the Container Runtime must be configured to load the CNI plugins required to implement the Kubernetes network model. </ins> <del> * `cni-bin-dir`: Kubelet probes this directory for plugins on startup * `network-plugin`: The network plugin to use from `cni-bin-dir`.  It must match the name reported by a plugin probed from the plugin directory.  For CNI plugins, this is `cni`. </del> <ins> {{< note >}} Prior to Kubernetes 1.24, the CNI plugins could also be managed by the Kubelet using the `cni-bin-dir` and `network-plugin` command-line parameters. These command line parameters were removed in Kubernetes 1.24, with management of the CNI no longer in scope for Kubelet. </ins> <del> ## Network Plugin Requirements </del> <ins> See [Troubleshooting CNI plugin-related errors](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/) if you are facing issues following the removal of dockershim. {{< /note >}} </ins> <del> Besides providing the [`NetworkPlugin` interface](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) to configure and clean up pod networking, the plugin may also need specific support for kube-proxy.  The iptables proxy obviously depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables.  For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly.  If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy. </del> <ins> For specific information about how a Container Runtime manages the CNI plugins, see the documentation for that Container Runtime, for example: - [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni) - [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md) </ins> <del> By default if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy. </del> <ins> For specific information about how to install and manage a CNI plugin, see the documentation for that plugin or [networking provider](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model). </ins> <del> ### CNI </del> <ins> ## Network Plugin Requirements The plugin may also need specific support for kube-proxy.  The iptables proxy obviously depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables.  For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly.  If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy. </ins> <del> The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option.  Kubelet reads a file from `--cni-conf-dir` (default `/etc/cni/net.d`) and uses the CNI configuration from that file to set up each pod's network.  The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration), and any required CNI plugins referenced by the configuration must be present in `--cni-bin-dir` (default `/opt/cni/bin`). </del> <ins> By default if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy. </ins> <del> If there are multiple CNI configuration files in the directory, the kubelet uses the configuration file that comes first by name in lexicographic order. </del> <ins> ### Loopback CNI </ins> <del> In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0 </del> <ins> In addition to the CNI plugin installed on the nodes, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0 </ins> <del> #### Support hostPort </del> <ins> ### Support hostPort </ins> The CNI networking plugin supports `hostPort`. You can use the official [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) plugin offered by the CNI plugin team or use your own plugin with portMapping functionality.

! 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: Verify the snapshot: <del> ```shell ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshot.db ``` </del> <ins> {{< tabs name="etcd_verify_snapshot" >}} {{% tab name="Use etcdutl" %}} The below example depicts the usage of the `etcdutl` tool for verifying a snapshot: </ins> <del> ```console +----------+----------+------------+------------+ |   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE | +----------+----------+------------+------------+ | fe01cf57 |       10 |          7 | 2.1 MB     | +----------+----------+------------+------------+ ``` </del> <ins> ```shell etcdutl --write-out=table snapshot status snapshot.db ``` This should generate an output resembling the example provided below: ```console +----------+----------+------------+------------+ |   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE | +----------+----------+------------+------------+ | fe01cf57 |       10 |          7 | 2.1 MB     | +----------+----------+------------+------------+ ``` {{% /tab %}} {{% tab name="Use etcdctl (Deprecated)" %}} {{< note >}} The usage of `etcdctl snapshot status` has been **deprecated** since etcd v3.5.x and is slated for removal from etcd v3.6. It is recommended to utilize [`etcdutl`](https://github.com/etcd-io/etcd/blob/main/etcdutl/README.md) instead. {{< /note >}} The below example depicts the usage of the `etcdctl` tool for verifying a snapshot: ```shell export ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshot.db ``` This should generate an output resembling the example provided below: ```console Deprecated: Use `etcdutl snapshot status` instead. +----------+----------+------------+------------+ |   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE | +----------+----------+------------+------------+ | fe01cf57 |       10 |          7 | 2.1 MB     | +----------+----------+------------+------------+ ``` {{% /tab %}} {{< /tabs >}} </ins> ### Volume snapshot

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: mentions ~(which is deprecated)~ quite a lot before the first mention of . Proposed Solution: Mention early on that there are two tools Where a use of is deprecated in favor of , repeat the equivalent change from Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig etcd
/triage accepted /help
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 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'd love to take this one if no one else has started already
/assign
Help is very welcome. Would you like any advice ?
Thank you Any general advice would be greatly appreciated. I have a Minikube multi-node cluster up and running, and I am executing the etcdutl commands within the first container. Hopefully, this setup will suffice for validation. Regarding documentation, I'll follow the provided related issues/documentation, which seem comprehensive enough to get started. However, I'll ensure to ask in the Slack group or on this issue if I encounter any difficulties. As I understand it, only the snapshot commands are deprecated and need updating to their etcdutl counterparts. If there's any inaccuracy in my understanding, please feel free to correct me. Thanks again! :)
I think you're right. General guidance: I'll edit the issue description.

Thank you for the guidance, I have opened a pull request to add a section clarifying the difference between etcdctl and etcdutl. Please feel free to review it and suggest any changes.


Question: コントロールプレーンコンポーネントは、クラスターに関する全体的な決定(スケジューリングなど)を行います。また、クラスターイベントの検出および応答を行います(たとえば、deploymentの`replicas`フィールドが満たされていない場合に、新しい {{< glossary_tooltip text="Pod" term_id="pod">}} を起動する等)。 コントロールプレーンコンポーネントはクラスター内のどのマシンでも実行できますが、シンプルにするため、セットアップスクリプトは通常、すべてのコントロールプレーンコンポーネントを同じマシンで起動し、そのマシンではユーザーコンテナを実行しません。 <del> マルチマスター VMセットアップの例については、[高可用性クラスターの構築](/docs/admin/high-availability/) を参照してください。 </del> <ins> 複数のマシンにまたがって実行されるコントロールプレーンのセットアップ例については、[kubeadmを使用した高可用性クラスターの構築](/ja/docs/setup/production-environment/tools/kubeadm/high-availability/) を参照してください。 </ins> ### kube-apiserver

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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /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: The supported version skew between components has implications on the order in which components must be upgraded. This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew currentVersionAddMinor -1 >}}** to version **{{< skew currentVersion >}}**. <ins> Optionally, when preparing to upgrade, the Kubernetes project recommends that you do the following to benefit from as many regression and bug fixes as possible during your upgrade: *  Ensure that components are on the most recent patch version of your current minor version. *  Upgrade components to the most recent patch version of the target minor version. For example, if you're running version {{<skew currentVersionAddMinor -1>}}, ensure that you're on the most recent patch version. Then, upgrade to the most recent patch version of {{<skew currentVersion>}}. </ins> ### kube-apiserver Pre-requisites:

Follow up from , tracked in Tested/supported upgrade process for patch releases and minor releases is not clear in user-facing documentation: [ ] should we add requirements (or at least a strong recommendation) to be at latest patch version of prior to upgrades, and upgrade to latest patch version of (since that is what we test, and what we can fix if broken)? Page to Update:
+1 for adding strong raccomdation to be at latest patch version of 1.x prior to upgrades, and upgrade to latest patch version of 1.x+1
/assign sig-cluster-lifecycle: hello, we need feedback and approval for the proposals in this ticket from chairs with respect to LTS.
I think a strong recommendation is ok; I don't think there should be a requirement. In some cases a provider may want to jump consumers between specific versions for upgrades that have been well tested, and if we make it a requirement to pick the latest patch version that may actually make it more difficult to qualify and upgrade clusters (because the qualification would reset each time a patch was cut).
/wg lts
Should this be based on the existing upgrade tests we have? /assign
/language en
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
/kind feature /priority backlog
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
/reopen /remove-lifecycle rotten /lifecycle frozen
Reopened this issue. <detailsIn response to : /reopen /remove-lifecycle rotten /lifecycle frozen 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


Question: ガベージコレクションは、最後に使用された時間に基づいて、最も古いものから順にイメージを削除します。 kubeletは、ディスク使用量が`LowThresholdPercent`値に達するまでイメージを削除します。 <del> ### コンテナイメージのガベージコレクション {#container-image-garbage-collection} </del> <ins> ### コンテナのガベージコレクション {#container-image-garbage-collection} </ins> kubeletは、次の変数に基づいて未使用のコンテナをガベージコレクションします。

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. A link text to this page from other pages have already been fixed. The current page is still "" and it should be fixed "". Comments /language ja /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: * [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/) * [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services) * [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) <del> * [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) </del> <ins> * [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) </ins> * [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) * [kubectl CLI](/zh/docs/user-guide/kubectl/)

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
Link: /retitle [zh] Issue with /zh/docs/tutorials/stateful-application/basic-stateful-set
/assign


Question: Descargue el archivo de comprobación kubectl-convert: ```powershell <del> curl -LO https://dl.k8s.io/{{% param "fullversion" %}}/bin/windows/amd64/kubectl-convert.exe.sha256 </del> <ins> curl -LO https://dl.k8s.io/v{{% skew currentPatchVersion %}}/bin/windows/amd64/kubectl-convert.exe.sha256 </ins> ``` Valide el binario kubectl-convert con el archivo de comprobación:

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 param is deprecated. Proposed Solution: Replace the shortcode (Spanish pages), for example with or something close. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--Part of /language es
/triage accepted /area localization /priority backlog