b01e6f68fe
Automatic merge from submit-queue hold namespaces briefly before processing deletion possible fix for #36891 in HA scenarios (either HA apiserver or HA etcd), it is possible for deletion of resources from namespace cleanup to race with creation of objects in the terminating namespace HA master timeline: 1. "delete namespace n" API call goes to apiserver 1, deletion timestamp is set in etcd 2. namespace controller observes namespace deletion, starts cleaning up resources, lists deployments 3. "create deployment d" API call goes to apiserver 2, gets persisted to etcd 4. apiserver 2 observes namespace deletion, stops allowing new objects to be created 5. namespace controller finishes deleting listed deployments, deletes namespace HA etcd timeline: 1. "create deployment d" API call goes to apiserver, gets persisted to etcd 2. "delete namespace n" API call goes to apiserver, deletion timestamp is set in etcd 3. namespace controller observes namespace deletion, starts cleaning up resources, lists deployments 4. list call goes to non-leader etcd member that hasn't observed the new deployment or the deleted namespace yet 5. namespace controller finishes deleting the listed deployments, deletes namespace In both cases, simply waiting to clean up the namespace (either for etcd members to observe objects created at the last second in the namespace, or for other apiservers to observe the namespace move to terminating phase and disallow additional creations) resolves the issue Possible other fixes: * do a second sweep of objects before deleting the namespace * have the namespace controller check for and clean up objects in namespaces that no longer exist * ...? |
||
|---|---|---|
| .github | ||
| api | ||
| build-tools | ||
| cluster | ||
| cmd | ||
| docs | ||
| examples | ||
| federation | ||
| Godeps | ||
| hack | ||
| hooks | ||
| logo | ||
| pkg | ||
| plugin | ||
| staging | ||
| test | ||
| third_party | ||
| vendor | ||
| .generated_docs | ||
| .generated_files | ||
| .gitattributes | ||
| .gitignore | ||
| BUILD | ||
| CHANGELOG.md | ||
| code-of-conduct.md | ||
| CONTRIBUTING.md | ||
| labels.yaml | ||
| LICENSE | ||
| Makefile | ||
| Makefile.generated_files | ||
| OWNERS | ||
| OWNERS_ALIASES | ||
| README.md | ||
| Vagrantfile | ||
| WORKSPACE | ||
Kubernetes
Introduction
Kubernetes is an open source system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications. Kubernetes is hosted by the Cloud Native Computing Foundation (CNCF)
Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale using a system called Borg, combined with best-of-breed ideas and practices from the community.
Are you ...
- Interested in learning more about using Kubernetes?
- See see our documentation on kubernetes.io
- Try our interactive tutorial
- Take a free course on Scalable Microservices with Kubernetes.
- Interested in developing the core Kubernetes code base, developing tools using the Kubernetes API or helping in anyway possible ? Keep reading!
Code of Conduct
The Kubernetes community abides by the CNCF code of conduct. Here is an excerpt:
As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
Community
Do you want to help "shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented? ". If you are a company, you should consider joining the CNCF. For details about who's involved in CNCF and how Kubernetes plays a role, read the announcement. For general information about our community see the website community page.
Join us on social media (Twitter, Google+) and read our blog
Ask questions and help answer them on Slack or Stack Overflow
Attend our key events (kubecon, cloudnativecon, weekly community meeting)
Join a Special Interest Group (SIG)
Contribute
If you're interested in being a contributor and want to get involved in developing Kubernetes, get started with with this reading:
- The community expectations
- The contributor guidelines
- The Kubernetes Developer Guide
You will then most certainly gain a lot from joining a SIG, attending the regular hangouts as well as the community meeting.
If you have an idea for a new feature, see the Kubernetes Features repository for a list of features that are coming in new releases as well as details on how to propose one.
Support
While there are many different channels that you can use to get hold of us (Slack, Stack Overflow, Issues, Forums/Mailing lists), you can help make sure that we are efficient in getting you the help that you need.
If you need support, start with the troubleshooting guide and work your way through the process that we've outlined.
That said, if you have questions, reach out to us one way or another. We don't bite!