jiebi/CodeConvo huggingface dataset:
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 Within , add a new and brief page that has an overview of autoscaling. This means adding a new Markdown file. The new page should mention: (aim to make it clear that this is a thing that autoscales nodes, not Pods) (aim to make it clear that this is a thing that autoscales nodes, not Pods) Optionally, also mention: - marked as third party software as it's a separate project from Kubernetes - marked as third party software as it's a separate project from Kubernetes For this issue, all that's needed is a few words about each item. Later PRs could add more detail. Why is this needed our documentation on autoscaling is incomplete readers would like to have their workloads automatically sized to match demand. Comments This helps with /language en /kind feature PS. I didn't mark this as a good first issue. However, if you're looking for something to work on, and haven't already contributed to Kubernetes' docs, there may be some issues available marked as good first issues. See this . If you have already worked on an issue, please leave these for people who are new to contributing.
/triage accepted /priority important-longterm /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 /priority important-longterm /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 would like to work on this issue /assign
Should I Make a new file inside Workloads!!
In 1 PR I will be creating 2 topics like (HorizontalPodAutoscaler, VerticalPodAutoscaler) and will it be sufficient, because It will be taking 2-3 PR's!
For advice on how to contribute to the Kubernetes docs, please ask in #sig-docs on the Kubernetes Slack workspace. If you're not already a member of that workspace, you can visit for an invitation. Anyone is welcome to work on this issue. it's slightly unhelpful to assign an issue to yourself and also to ask questions about how to work on it; ideally, people only assign an issue once they are confident that they know how to resolve it.
Our no cookie-licking policy means that anyone is welcome to open a PR that closes an open issue. It's still friendly to reach out to people who might already be working on the same thing. See for an explanation of the jargon.
Thanks I was just asking it. I can fix this issue!
Hey This has been pending for more than a month. So, May I go ahead and create a PR? I have a basic markdown structure for file is ready and I can add more details as needed after raising a PR.
PRs are welcome, and because this project is open source, nobody needs permission.
In light of our policy on cookie licking: /unassign I think we'll make progress better without any assignee. If anyone wants to share that they have started work, feel free to open a draft pull request that mentions this issue.
The concept of the has not been introduced at this point yet, but is used at multiple locations on this page. It would make sense to briefly explain what that is and link to a page that covers that topic.
/triage accepted /language en /help I would use a here. We should also mention that StatefulSet is just an example. Related, the example manifest is incomplete. We should add a comment in YAML to make it clear that this is an excerpt.
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 /language en /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 would like to fix this /assign
I think is already defined .
My idea is to reference that definition into (see PR )
This is a Bug Report Problem: An explanation in the Pod phase section is misleading. A pod doesn't have a state until it is configured not to be restarted. If the is not set, the pod will still be in the state. Proposed Solution: All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system, and will not be restarted. Page to Update: Kubernetes Version: v1.30.1 I'll be happy to work on it if it's accepted.
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
/language en /sig docs
/sig node
so long as you're confident your understanding is correct, you don't need anyone to tell you it's OK to start work. Kubernetes is open source.
That’s true, thanks. /assign
there is an useless "" character on
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
This is a Feature Request What would you like to be Translate docs/reference/kubernetes-api/service-resources/ingress-class- Comments Link: /language zh /kind feature /assign
/triage accepted
/close This is now tracked in
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
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: Typo in "Feature Gates" page cf. Proposed Solution: In , replace with . Page to Update: ,alpha,-.%20This%20feature%20gate%20will%20never%20graduate%20to%20stable <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
/triage accepted
Hi could you provide an update on the progress of this issue? I'm particularly interested in knowing what the current status is and if I can carry on this issue.
, I will submit a PR today .
/close
Closing this issue. <detailsIn response to : /close </details
This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: I cannot find a list in the documentation of possible values for the API Server flag . Could this be provided, or instructions on how to generate the list documented? "Full list of supported API groups can be seen in .", but the top-level of all reference documentation does not clarify the list of possible strings. Proposed Solution: Document the available values in the Or in the Page to Update: Also here, although this is about the API, not the API Server.
have you been able to find the valid values for ? If you have an idea, I can help documenting it.
thanks for the offer. I have not located current possible values and do not have knowledge of the doc generation to propose a solution that will survive versions :( My short-term need is identifying which, if any, values I need to use with versions 1.4, 1.5, 1.6 to enable features including init-containers. However, the Right Thing is to have all possible values documented for each version.
Put me into the shame cube, I just ran into myself as well. Currently I'm trying to figure out why my 1.8 cluster doesn't have api . I think one of these values will work, I'll try these: - ( because ) -
OK I found it. The syntax works. My understanding: api/legacy: not sure what it does api/all: option to enable disable all APIs but obviously this isn't working for maybe because it's alpha core api groups syntax: expected. named api groups syntax: unexpected, because there's no or  prefix. specifying it or enables it, disables it. the list is comma-separated I can help you incorporate these into the docs if you're interested.
Per : : It sort of works if you treat as a placeholder (so, ). In your case: with and and no optional resource specified. This aligns with other docs, too: Certain resources and API groups are enabled by default. You can enable or disable them by setting on apiserver. accepts comma separated values. For example, to disable batch/v1, set , to enable batch/v2alpha1, set If this is the case, the flag help text and the paragraphs and the api groups pages could be clarified.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale A possible solution is to have the doc generator summarizes the API groups it identified. The generator can put that into a separate section in the API reference doc generated.
/lifecycle frozen
It would be great to have it documented under which API resources lie within a specific version - something like
Is there any default value in --runtime-config? for example,it is all work file when I config '--runtime-, ' or '--runtime-config="" ' in kube-apiserver. so I was confused, how can I know which api support by default?
/kind feature /priority backlog
Another gotcha with the current documentation: it mentions that takes a "A set of key=value pairs" - but what is the syntax for that set? Comma-separated? Space-separated? JSON map? I had to google, which led me to this issue here.
/triage accepted
/sig api-machinery I think
A on is broken and returning 404 page.
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
From the docs.. As of version 2.0, Kata Containers no longer provides an OCI compliant runtime.
Hey do you want the statement to be removed or modify?
/sig security /kind bug
/language en
I'm not sure this issue is valid. For example, states: /priority awaiting-more-evidence /sig node
/triage needs-information
/cc
I have investigated and found that kata version 2 did not support OCI commands or runtime , but from we can clearly see that it has again with the 3rd version of it.
you can look into this thread.
I (still) don't think the website is wrong: Yep, true. As far as I know. Also true. That's fair too. With nothing to actually fix, I propose closing this issue. People who want to see that previous Kata Containers releases dropped OCI compliance should go and look on the Kata Containers website, per
Note that the also states that "Kata Containers 2.5.2 support the OCI Runtime Specification v1.0.0-rc5", although releases prior to 2.5.2 did not. I am a little confused by this claim, as there have been so many issues related to kata =2.0 no longer providing an OCI compliant CLI, thus breaking docker and podman compatibility, so it seemed odd for any doc to claim "Kata Containers is an OCI compliant runtime", which is why I opened this issue. (side note: for a while it looked like kata may re-add the OCI CLI commands via , but a different path to providing an OCI CLI to kata is now being pursued in ) Here's my 2c: The states: So it is possible that kata implements that spec, yet does not implement the . However, according to the docs for : ... where the word "compliance" is a link to the spec that Kata claims to implement. That is saying that for a runtime to be tested for compliance with the runtime spec, it must implement that OCI CLI. It seems reasonable that a runtime can't claim to be OCI compliant, or even compliant with that v1.0.0-rc5 runtime spec, if it does not implement the OCI Command Line Interface which is required to test that very compliance.
I'm guessing that this is why Kata carefully worded their statement in the release notes: Note that it says kata "support the" spec, and it does not say "is compliant with" that spec. The k8s documentation, on the other hand, does state that "Kata Containers is an OCI compliant runtime." That seems incorrect based on the reasoning above.
Thanks for the additional context. If Kata Containers doesn't comply with the OCI runtime command line interface, we can fix the wording. You are welcome to provide evidence of this I would focus on whether the latest version of Kata Containers does or doesn't implement the OCI runtime command line evidence; it's also OK to furnish any other evidence that makes it clear that the Kubernetes website is not worded correctly in this respect.
I think the fact that is still open, for the sole purpose of re-enabling an OCI runtime command line interface for kata, is pretty solid evidence that even the latest version of Kata Containers does not implement the OCI runtime command line. It looks like that issue is actively being worked on, so hopefully an OCI interface will exist again at some point. It just doesn't right now.
/triage accepted /remove-priority awaiting-more-evidence /remove-triage needs-information /retitle incorrectly lists Kata Containers as OCI compliant
The actual issue is I'm working on it. I proposed a solution that restored the command lines in the runtime, but that was rejected, so I'm now working on a wrapper that converts command line to shimv2.
That is correct. Part of the problem (at least in my understanding) is that many members of the team consider that supporting the shimv2 interface is sufficient to claim OCI compatibility.
Bottom line is if Kata does not support the OCI Command line then it is just available to CRI-O and Containerd since they run as daemons and implement the Kata Shim API. Podman, buildah and other tools which exec OCI Command line tools can not and will not work with Kata until kata supports an OCI Complient Command line.
In my ideal world someone would build a C Based library for the shim V2 which could link to crun like we have done for crun-wasm and crun-krun, along with standard support in crun.
/assign
This is a Bug Report Problem: This post comes up in Chinese: This post shows with every character interspersed with "": Proposed Solution: Make the posts readable in English. Page to Update: I imagine this needs to be fixed in transformation; the source looks ok.
Also,
/kind bug Thanks
/priority backlog
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
The first one now seems fixed; second one is still bad.
/remove-lifecycle stale
seems to be working now, but is still corrupted. Note that seems to have been in a wonky state for about 2 years now This is actually a pretty good first issue, for someone patient.
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
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
This is a Bug Report <!--Required Information--Problem: The Feature state of is mentioned as under task, Which is not correct. In k8s v1.24.0 is graduated to . See the of k8s v1.24.0 and Also mention under the . Proposed Solution: Change the Feature State of from Kubernetes v1.20 [alpha] to Kubernetes v1.24 [beta]. Page to Update:
/assign
fixed it here:
As this is a bug report issue, I'm going to change the title to summarize what isn't right. /retitle Incorrect feature state data for kubelet credential provider Also: /language en /triage accepted /sig node
thanks
(text removed; the credit program is long expired)
Hey John, I want to work on these diagrams in Illustrator, when I download a slide as svg and open it in Illustrator it turns out that the icons are just images. This means I can't edit them. Can you provide a complete icon set + the grid as ai, eps or svg?
Ref
Some things we want diagrams for: All types of services: cluster, nodeport, loadbalancer, headless, imported Ingress Every controller: RC, RS, Deployment, DaemonSet, PetSet, Job, ScheduledJob Rolling update Canary deployment pattern with ConfigMap HPA ServiceAccount and Secret PVCs and PVs System architecture cc
Would be useful to provide a way to use them. One would try to copy them but that's really "using" them. For example if the expected source is using Google Draw, having them in draw or something similar. May be having them in SVG for some other SVG editor. Currently there is an option, but it's rather limiting, make a copy of the slides and use Google Slides directly and finally export the current slide. It's an abuse of the tool but there isn't a lot of I/O between Slides and Draw.
any progress on getting the SVGs publicly available somewhere? /
The svgs at the top of the slide deck are all that we have been able to locate. Both and I have done some digging, but haven't been able to find svg's for other assets. We are unsure of the origin of the assets, and I don't know what the original format was. Assuming the svg's do not exist what are the next steps. What are your thoughts on a visual language for our docs and diagrams?
OK, well thank you for satisfying the due diligence of making sure there wasn't a set we should be working from. I like fresh starts! "Symbols / Icons" seems more appropriate than "diagrams" here, since really we're looking for the building blocks of a visual language we can create diagrams with, correct? Microsoft's seems like it could be at least good inspiration for this. Here's a process I could see being effective: an issue capturing what we need to include; seems like it would make sense to start with. do you want to create this? there different possible representations for concepts & post sketches.
basic visual guidelines for designs of different icons to adhere to as we expand the library. The Slides of the Google Cloud Platform visual language seem like a reasonable starting point here. there, I have bandwidth to start designing visually consistent vectors, and anyone else that would like to is of course welcome to contribute. Thoughts?
Thanks for leading this. Your proposal sounds good to me. WDYT? In addition to the MS icon set, pointed me at the . One thing that is been on my mind is that we will be creating diagrams at several different abstraction levels, and our language will need to be consistent across them: Diagraming Concepts themselves (e.g. How do Pods, Services, Ingresses work?) Will need icons to represents the sub-atomic pieces of the Concepts e.g. for Pod: multiple containers, environment variables, ip address, volumes May also want icons to represent processes or configurations of the Concept e.g. for Pod: container restart (and restartPolicy?), liveness / readiness (and livenessChecks?), cpu limits, etc Diagraming Interactions+Relationships between Concepts e.g. for Deployment: Create, Delete Pods Will need icons to represent the actual Concepts themselves Should use imagery consistent with how we diagramed the Concepts themselves Iterations between Concepts and Tools/People/Machines Resources What are your thoughts on using color as part of the visual language? Is this generally discouraged or something useful?
yes! Material icons design principles definitely make sense to incorporate. We may need to increase the 24dp grid size they're based on to accommodate more complex forms, but I think the basic guidance there is great. I'll try to do some research into systems that have to visually represent constituent elements as well as concepts those elements roll up to (e.g. containers / pods / clusters). Anyone have any recommendations around that? It would be nice if they somehow related to each other. Where are the above mentioned diagrams? Interspersed throughout docs? Are they centralized anywhere? as far as color: I think we should intentionally incorporate it, but look to craft visual representations that also stand alone independent from color.
I would also like to be able to get Google UX researchers to review and give us feedback as early as possible. Does this make sense to do as part of step 2, or once we have a few icons post step 2?