Juan Diego Palomino
6224377d87
* First draft of the updates to the ReplicaSet Docs To start with, I tried to cleanup the docs to adhere to the style guide https://kubernetes.io/docs/contribute/style/style-guide/. I then added some description of the ReplicaSet-Pod link via the owner reference field and behavior by it. I also made a clarification on the ReplicaSet demo where it was being redundant for the sake of demonstrating the different forms of usage. I consider this draft incomplete as I still lack knowledge of how the pod labels affect the behavior. * Clearing up RC refs & explaining acquisition behavior I'm beginning to address the cr by cleaning up references to the ReplicationController and making it clear that RCs are discouraged/old. I then expanded on the behavior of ReplicaSet in the presence of pods it can acquire but are not created directly by it. * Mismatched link seems to have disappeared from preview "As with all other Kubernetes API objects," etc... is present in the sibling concepts/workloads/controllers/ files, so I am hesitant to change that w/o changing the others, but I did abbreviate it. "The `.spec.template` is the only required field of the `.spec`." is false, we also need the selector Trying to address passive voice Cleaned up Writing a ReplicaSet Manifest section removed How to use a ReplicaSet section as it has redundant info from the examples and Alternatives section Expanded examples a bit Cleared up passive voice * refactoring link to example yaml * adding pod-rs test case * Addressing Steve Perry's comments Capitalize Pod throughout. Link is not rendering correctly. Use () instead of [] for the path. Ending with "for the creation" seems vague to me. Maybe this: "...reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod template." Suggestion: "is via the Pod's metadata.ownerReferences field." That way the reader won't jump to the incorrect conclusion that we're talking about the ReplicaSet's metadata.ownerReferences field. with fields, including a selector that and plans accordingly Our style for headings is sentence case. So this heading would be "How a ReplicaSet works". Several headings in this topic need to be converted to sentence case. cleaned up frontend.yaml example added example checking the Pod's owner reference being set to it's parent ReplicaSet * Previous commit broke Pod example links due to casing * Forgot 1 comment Suggestion: In the ReplicaSet, .spec.template.metadata.labels must match spec.selector, or ... * Addressing grammar/syntax errors
The Kubernetes documentation
Welcome! This repository houses all of the assets required to build the Kubernetes website and documentation. We're very pleased that you want to contribute!
Contributing to the docs
You can click the Fork button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a fork. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer. Also note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one originally assigned to provide you feedback. Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
For more information about contributing to the Kubernetes documentation, see:
- Start contributing
- Staging Your Documentation Changes
- Using Page Templates
- Documentation Style Guide
- Localizing Kubernetes Documentation
README.md's Localizing Kubernetes Documentation
Korean
See translation of README.md and more detail guidance for Korean contributors on the Korean README page.
You can reach the maintainers of Korean localization at:
- June Yi (GitHub - @gochist)
- Slack channel
Running the site locally using Docker
The recommended way to run the Kubernetes website locally is to run a specialized Docker image that includes the Hugo static site generator.
If you are running on Windows, you'll need a few more tools which you can install with Chocolatey.
choco install make
If you'd prefer to run the website locally without Docker, see Running the site locally using Hugo below.
If you have Docker up and running, build the kubernetes-hugo Docker image locally:
make docker-image
Once the image has been built, you can run the site locally:
make docker-serve
Open up your browser to http://localhost:1313 to view the site. As you make changes to the source files, Hugo updates the site and forces a browser refresh.
Running the site locally using Hugo
See the official Hugo documentation for Hugo installation instructions. Make sure to install the Hugo version specified by the HUGO_VERSION environment variable in the netlify.toml file.
To run the site locally when you have Hugo installed:
make serve
This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the site. As you make changes to the source files, Hugo updates the site and forces a browser refresh.
Community, discussion, contribution, and support
Learn how to engage with the Kubernetes community on the community page.
You can reach the maintainers of this project at:
Code of conduct
Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.
Thank you!
Kubernetes thrives on community participation, and we really appreciate your contributions to our site and our documentation!