mirror of https://github.com/k3s-io/k3s
4363f14e77
This PR changes how we version going forward in the following ways: * mark-new-version.sh is changed to a new policy of just splitting branches, rather than the old backmerge policy, as discussed in vX.Y.0, and a tag for vX.(Y+1).0-alpha.0 back to master. * I eliminated PRs back to master by making the version/base.go gitVersion and gitCommit just be `export-subst`. I testing that this works with GitHub's source export tarballs. There's no reason to bother with forcing the version into `base.go` (especially twice). The tarball versions outside a git tree aren't perfect (master looks like "v0.0.0+hash", and the release branches look more accurate), but our build contract has never allowed that version is perfect in this situation, so I think we can relax this. * That master tag gets picked up by "git describe" on master, so e.g. master would have immediately become v1.1.0-alpha.0 * In order to be more semVer compatible, the gitVersion field for the master branch now looks something like 1.1.0-alpha.0.6+84c76d1142ea4d. This is a tiny translation of the "git describe". I did this because there are a ton of consumers out there of the "gitVersion" field expecting it to be the full version, but it would be nice if this field were actually semver compliant. (1.1.0-alpha.0-6-84c76d1142ea4d is, but it's not *usefully* so.) Fixes #11495 |
||
|---|---|---|
| Godeps | ||
| api/swagger-spec | ||
| 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 | ||
| Makefile | ||
| README.md | ||
| Vagrantfile | ||
| logo.pdf | ||
| logo.png | ||
| logo.svg | ||
| logo_usage_guidelines.md | ||
| shippable.yml | ||
README.md
Kubernetes
Are you ...
- Interested in learning more about using Kubernetes? Please see our user-facing documentation on kubernetes.io
- Interested in hacking on the core Kubernetes code base? Keep reading!
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 ready for Production!
With the 1.0.1 release Kubernetes is ready to serve your production workloads.
Concepts
Kubernetes works with the following concepts:
- Cluster
- A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications. Kubernetes can run anywhere! See the Getting Started Guides for instructions for a variety of services.
- Node
- A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled.
- Pod
- Pods are a colocated group of application 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.
- Replication controller
- 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.
- Service
- Services provide a single, stable name and address for a set of pods. They act as basic load balancers.
- Label
- Labels are used to organize and select groups of objects based on key:value pairs.
Documentation
Kubernetes documentation is organized into several categories.
- Getting started guides
- for people who want to create a Kubernetes cluster
- for people who want to port Kubernetes to a new environment
- User documentation
- for people who want to run programs on an existing Kubernetes cluster
- in the Kubernetes User Guide: Managing Applications
- the Kubectl Command Line Interface is a detailed reference on
the
kubectlCLI - User FAQ
- Cluster administrator documentation
- for people who want to create a Kubernetes cluster and administer it
- in the Kubernetes Cluster Admin Guide
- Developer and API documentation
- for people who want to write programs that access the Kubernetes API, write plugins or extensions, or modify the core Kubernete code
- in the Kubernetes Developer Guide
- see also notes on the API
- see also the API object documentation, a detailed description of all fields found in the core API objects
- Walkthroughs and examples
- hands-on introduction and example config files
- in the user guide
- in the docs/examples directory
- Contributions from the Kubernetes community
- in the docs/contrib directory
- Design documentation and design proposals
- for people who want to understand the design of Kubernetes, and feature proposals
- design docs in the Kubernetes Design Overview and the docs/design directory
- proposals in the docs/proposals directory
- Wiki/FAQ
- in the wiki
- troubleshooting information in the troubleshooting guide
Community, discussion and support
If you have questions or want to start contributing please reach out. We don't bite!
Please see the troubleshooting guide, or how to get more help.
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.