a305269e18
This implements phase 1 of the proposal in #3579, moving the creation of the pods, RCs, and services to the master after the apiserver is available. This is such a wide commit because our existing initial config story is special: * Add kube-addons service and associated salt configuration: ** We configure /etc/kubernetes/addons to be a directory of objects that are appropriately configured for the current cluster. ** "/etc/init.d/kube-addons start" slurps up everything in that dir. (Most of the difficult is the business logic in salt around getting that directory built at all.) ** We cheat and overlay cluster/addons into saltbase/salt/kube-addons as config files for the kube-addons meta-service. * Change .yaml.in files to salt templates * Rename {setup,teardown}-{monitoring,logging} to {setup,teardown}-{monitoring,logging}-firewall to properly reflect their real purpose now (the purpose of these functions is now ONLY to bring up the firewall rules, and possibly to relay the IP to the user). * Rework GCE {setup,teardown}-{monitoring,logging}-firewall: Both functions were improperly configuring global rules, yet used lifecycles tied to the cluster. Use $NODE_INSTANCE_PREFIX with the rule. The logging rule needed a $NETWORK specifier. The monitoring rule tried gcloud describe first, but given the instancing, this feels like a waste of time now. * Plumb ENABLE_CLUSTER_MONITORING, ENABLE_CLUSTER_LOGGING, ELASTICSEARCH_LOGGING_REPLICAS and DNS_REPLICAS down to the master, since these are needed there now. (Desperately want just a yaml or json file we can share between providers that has all this crap. Maybe #3525 is an answer?) Huge caveats: I've gone pretty firm testing on GCE, including twiddling the env variables and making sure the objects I expect to come up, come up. I've tested that it doesn't break GKE bringup somehow. But I haven't had a chance to test the other providers. |
||
|---|---|---|
| Godeps | ||
| api | ||
| build | ||
| cluster | ||
| cmd | ||
| contrib | ||
| docs | ||
| examples | ||
| hack | ||
| hooks | ||
| pkg | ||
| plugin | ||
| test | ||
| third_party | ||
| www | ||
| .gitignore | ||
| .travis.yml | ||
| CHANGELOG.md | ||
| CONTRIB.md | ||
| CONTRIBUTING.md | ||
| DESIGN.md | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| Makefile | ||
| README.md | ||
| Vagrantfile | ||
| logo.pdf | ||
| logo.png | ||
| logo.svg | ||
| logo_usage_guidelines.md | ||
README.md
Kubernetes
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:
- lean: lightweight, simple, accessible
- portable: public, private, hybrid, multi cloud
- extensible: modular, pluggable, hookable, composable
- self-healing: auto-placement, auto-restart, auto-replication
Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale, combined with best-of-breed ideas and practices from the community.
Kubernetes can run anywhere!
However, initial development was done on GCE and so our instructions and scripts are built around that. If you make it work on other infrastructure please let us know and contribute instructions/code.
Kubernetes is in pre-production beta!
While the concepts and architecture in Kubernetes represent years of experience designing and building large scale cluster manager at Google, the Kubernetes project is still under heavy development. Expect bugs, design and API changes as we bring it to a stable, production product over the coming year.
Concepts
Kubernetes works with the following concepts:
Clusters are the compute resources on top of which your containers are built. Kubernetes can run anywhere! See the Getting Started Guides for instructions for a variety of services.
Pods are a colocated group of Docker containers with shared volumes. They're the smallest deployable units that can be created, scheduled, and managed with Kubernetes. Pods can be created individually, but it's recommended that you use a replication controller even if creating a single pod. More about pods.
Replication controllers manage the lifecycle of pods. They ensure that a specified number of pods are running at any given time, by creating or killing pods as required. More about replication controllers.
Services provide a single, stable name and address for a set of pods. They act as basic load balancers. More about services.
Labels are used to organize and select groups of objects based on key:value pairs. More about labels.
Documentation
Kubernetes documentation is organized into several categories.
- Getting Started Guides
- for people who want to create a kubernetes cluster
- in docs/getting-started-guides
- User Documentation
- Developer Documentation
- in docs/devel
- for people who want to contribute code to kubernetes
- covers development conventions
- explains current architecture and project plans
- Design Documentation
- in docs/design
- for people who want to understand the design choices made
- describes tradeoffs, alternative designs
- descriptions of planned features that are too long for a github issue.
- Walkthroughs and Examples
- in examples
- Hands on introduction and example config files
- API documentation
- in the API conventions doc
- and automatically generated API documentation served by the master
- Wiki/FAQ
- in wiki
- includes a number of Kubernetes community-contributed recipes
Community, discussion and support
If you have questions or want to start contributing please reach out. We don't bite!
The Kubernetes team is hanging out on IRC on the #google-containers channel on freenode.net. We also have the google-containers Google Groups mailing list for questions and discussion as well as the kubernetes-announce mailing list for important announcements (low-traffic, no chatter).
If you are a company and are looking for a more formal engagement with Google around Kubernetes and containers at Google as a whole, please fill out this form and we'll be in touch.