kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Assigning remaining topics to TOC. Some deletions, combinations, and relegations to READMEs. Deactivating AnswerDash for now.

This commit is contained in:
John Mulhausen 2016-03-06 02:24:03 -08:00
parent 87d0befa87
commit 9a5aab72df
21 changed files with 155 additions and 271 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
_data/guides.yml
View File

@ -8,6 +8,8 @@ toc:
section:
- title: What is Kubernetes?
path: /docs/whatisk8s/
- title: Downloading Kubernetes
path: /docs/getting-started-guides/binary_release/
- title: Hello World Walkthrough
path: /docs/hellonode/
- title: Kubernetes 101
@ -15,6 +17,12 @@ toc:
- title: Kubernetes 201
path: /docs/user-guide/walkthrough/k8s201/
- title: User Guide
path: /docs/user-guide/
- title: Admin Guide
path: /docs/admin/
- title: Running Kubernetes
section:
- title: Picking the Right Solution
@ -59,12 +67,24 @@ toc:
path: /docs/getting-started-guides/vsphere/
- title: Juju
path: /docs/getting-started-guides/juju/
- title: DCOS
path: /docs/getting-started-guides/dcos/
- title: libvirt on CoreOS
path: /docs/getting-started-guides/libvirt-coreos/
- title: oVirt
path: /docs/getting-started-guides/ovirt/
- title: libvirt or KVM
path: /docs/getting-started-guides/fedora/flannel_multi_node_cluster/
- title: Multinode Cluster on CoreOS
path: /docs/getting-started-guides/coreos/coreos_multinode_cluster/
- title: Fedora With Calico Networking
path: /docs/getting-started-guides/fedora/fedora-calico/
- title: rkt
path: /docs/getting-started-guides/rkt/
- title: Kubernetes on Mesos
path: /docs/getting-started-guides/mesos/
- title: Kubernetes on Mesos on Docker
path: /docs/getting-started-guides/mesos-docker/
- title: Bare Metal
section:
- title: Offline
@ -79,13 +99,19 @@ toc:
path: /docs/getting-started-guides/centos/centos_manual_config/
- title: Ubuntu
path: /docs/getting-started-guides/ubuntu/
- title: Docker (Multi Node)
- title: Docker (Multi-Node)
path: /docs/getting-started-guides/docker-multinode/
- title: CoreOS with Calico
path: /docs/getting-started-guides/coreos/bare_metal_calico/
- title: Ubuntu Nodes with Calico
path: /docs/getting-started-guides/ubuntu-calico/
- title: Administering Clusters
section:
- title: Kubernetes Cluster Admin Guide
path: /docs/admin/
- title: Cluster Management Guide
path: /docs/admin/cluster-management/
- title: Anatomy of a Cluster
path: /docs/admin/cluster-components/
- title: Using Multiple Clusters
path: /docs/admin/multi-cluster/
- title: Using Large Clusters
@ -105,44 +131,66 @@ toc:
- title: Using Nodes, Pods, and Containers
section:
- title: Assigning Pods to Nodes
path: /docs/user-guide/node-selection/
- title: The Container Environment
path: /docs/user-guide/container-environment/
- title: Running Your First Containers
path: /docs/user-guide/simple-nginx/
- title: Working with Containers
path: /docs/user-guide/production-pods/
- title: Overriding Default Container Behavior
path: /docs/user-guide/containers/
- title: Running Commands in a Container with kubectl exec
path: /docs/user-guide/getting-into-containers/
- title: The Lifecycle of a Pod
path: /docs/user-guide/pod-states/
- title: Assigning Pods to Nodes
path: /docs/user-guide/node-selection/
- title: Creating Pods with the Downward API
path: /docs/user-guide/downward-api/
- title: Updating Live Pods
path: /docs/user-guide/update-demo/
- title: Running Commands in a Container with kubectl exec
path: /docs/user-guide/getting-into-containers/
- title: Installing a Kubernetes Master Node via Docker
path: /docs/getting-started-guides/docker-multinode/master/
- title: Adding a Kubernetes Worker Node via Docker
path: /docs/getting-started-guides/docker-multinode/worker/
- title: Networking
section:
- title: Networking in Kubernetes
path: /docs/admin/networking/
- title: Using DNS Pods and Services
path: /docs/admin/dns/
- title: Setting Up and Configuring DNS
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/cluster-dns
- title: Deploying DNS
path: /docs/getting-started-guides/docker-multinode/deployDNS/
- title: Connecting Applications
path: /docs/user-guide/connecting-applications/
- title: Creating Servers with External IPs
path: https://github.com/kubernetes/kubernetes/blob/release-1.1/examples/simple-nginx.md
- title: Using DNS Pods and Services
path: /docs/admin/dns/
- title: Connect with Proxies
path: /docs/user-guide/connecting-to-applications-proxy/
- title: Connect with Port Forwarding
path: /docs/user-guide/connecting-to-applications-port-forward/
- title: Configuring Your Cloud Provider's Firewalls
path: /docs/user-guide/services-firewalls/
- title: Configuring Kubernetes
section:
- title: Using Configuration Files
path: /docs/user-guide/simple-yaml/
- title: Best Practices for Configuration
path: /docs/user-guide/config-best-practices/
- title: Configuring Containers
path: /docs/user-guide/configuring-containers/
- title: Sharing Cluster Access with kubeconfig
path: /docs/user-guide/sharing-clusters/
- title: Using Environment Variables
path: /docs/user-guide/environment-guide/
- title: Managing Compute Resources
path: /docs/user-guide/compute-resources/
- title: Using kubectl to Manage Resources
path: /docs/user-guide/working-with-resources/
- title: Applying Resource Quotas and Limits
path: /docs/admin/resourcequota/
- title: Setting Pod CPU and Memory Limits
@ -151,8 +199,8 @@ toc:
path: /docs/admin/garbage-collection/
- title: Configuring Kubernetes with Salt
path: /docs/admin/salt/
- title: Best Practices for Configuration
path: /docs/user-guide/config-best-practices/
- title: Configuring Kubernetes Use of etcd
path: /docs/admin/etcd/
- title: Application Management and Deployment
section:
@ -167,6 +215,8 @@ toc:
- title: Testing and Monitoring
section:
- title: Testing a Kubernetes Cluster
path: /docs/getting-started-guides/docker-multinode/testing/
- title: Simulating Large Test Loads
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/k8petstore
- title: Checking Pod Health
@ -176,4 +226,6 @@ toc:
- title: Resource Usage Monitoring
path: /docs/user-guide/monitoring/
- title: Logging
path: /docs/user-guide/logging/
path: /docs/getting-started-guides/logging/
- title: Logging with Elasticsearch and Kibana
path: /docs/getting-started-guides/logging-elasticsearch/

60
_data/reference.yml
View File

@ -20,30 +20,14 @@ toc:
- title: Extensions API Definitions
path: /docs/api-reference/extensions/v1beta1/definitions/
- title: kube-apiserver
section:
- title: Overview
path: /docs/admin/kube-apiserver/
- title: Authorization Plugins
path: /docs/admin/authorization/
- title: Authentication
path: /docs/admin/authentication/
- title: Accessing the API
path: /docs/admin/accessing-the-api/
- title: Admission Controllers
path: /docs/admin/admission-controllers/
- title: Managing Service Accounts
path: /docs/admin/service-accounts-admin/
- title: etcd
path: /docs/admin/etcd/
- title: kubectl
- title: kubectl CLI
section:
- title: kubectl Overview
path: /docs/user-guide/kubectl-overview/
- title: kubectl for Docker Users
path: /docs/user-guide/docker-cli-to-kubectl/
- title: JSONpath Support
path: /docs/user-guide/jsonpath/
- title: kubectl Commands
section:
- title: kubectl
@ -108,27 +92,43 @@ toc:
path: /docs/user-guide/kubectl/kubectl_run/
- title: kubectl scale
path: /docs/user-guide/kubectl/kubectl_scale/
- title: kubectl stop
path: /docs/user-guide/kubectl/kubectl_stop/
- title: kubectl version
path: /docs/user-guide/kubectl/kubectl_version/
- title: Superseded and Deprecated Commands
section:
- title: kubectl namespace
path: /docs/user-guide/kubectl/kubectl_namespace/
- title: kubectl stop
path: /docs/user-guide/kubectl/kubectl_stop/
- title: JSONpath
path: /docs/user-guide/jsonpath/
- title: kube-proxy
- title: kube-apiserver CLI
section:
- title: Overview
path: /docs/admin/kube-apiserver/
- title: Authorization Plugins
path: /docs/admin/authorization/
- title: Authentication
path: /docs/admin/authentication/
- title: Accessing the API
path: /docs/admin/accessing-the-api/
- title: Admission Controllers
path: /docs/admin/admission-controllers/
- title: Managing Service Accounts
path: /docs/admin/service-accounts-admin/
- title: kube-proxy CLI
path: /docs/admin/kube-proxy/
- title: kub-scheduler
- title: kub-scheduler CLI
path: /docs/admin/kube-scheduler/
- title: kubelet
- title: kubelet CLI
path: /docs/admin/kubelet/
- title: kube-controller-manager CLI
path: /docs/admin/kube-controller-manager/
- title: Glossary
section:
- title: Container Environment
path: /docs/user-guide/container-environment/
- title: Images
path: /docs/user-guide/images/
- title: Pods
@ -151,6 +151,8 @@ toc:
path: /docs/user-guide/namespaces/
- title: Nodes
path: /docs/admin/node/
- title: Security Context
path: /docs/user-guide/security-context/
- title: Service Accounts
path: /docs/user-guide/service-accounts/
- title: Annotations

4
_data/samples.yml
View File

@ -43,6 +43,8 @@ toc:
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/iscsi/
- title: NFS
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/nfs/
- title: Downward API Volumes
path: /docs/user-guide/downward-api/volume/
- title: Multi-tier Application Samples
section:
@ -52,3 +54,5 @@ toc:
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/guestbook/
- title: MySQL - Phabricator Server
path: https://github.com/kubernetes/kubernetes/tree/release-1.1/examples/phabricator/
- title: Elasticsearch/Kibana Logging Demo
path: https://github.com/kubernetes/kubernetes.github.io/tree/master/docs/user-guide/logging-demo

8
_data/support.yml
View File

@ -8,10 +8,16 @@ toc:
section:
- title: Web Interface
path: /docs/user-guide/ui/
- title: Application Introspection and Debugging
path: /docs/user-guide/introspection-and-debugging/
- title: Retrieving Logs
path: /docs/user-guide/logging/
- title: Troubleshooting Applications
path: /docs/user-guide/application-troubleshooting/
- title: Troubleshooting Clusters
path: /docs/admin/cluster-troubleshooting/
- title: Debugging Services
path: /docs/user-guide/debugging-services/
- title: Frequently Asked Questions
section:
@ -36,5 +42,3 @@ toc:
path: /docs/roadmap/
- title: Contributing to Kubernetes Documentation
path: /docs/editdocs/
- title: Sitemap for v1.1
path: /docs/pagelist/

4
_layouts/docwithnav.html
View File

@ -70,6 +70,8 @@
ga('create', 'UA-36037335-10', 'auto');
ga('send', 'pageview');
</script>
<!-- Start of AnswerDash script --> <script>var AnswerDash;!function(e,t,n,s,a){if(!t.getElementById(s)){var i,r=t.createElement(n),c=t.getElementsByTagName(n)[0];e[a]||(i=e[a]=function(){i.__oninit.push(arguments)},i.__oninit=[]),r.type="text/javascript",r.async=!0,r.src="https://p1.answerdash.com/answerdash.min.js?siteid=756",r.setAttribute("id",s),c.parentNode.insertBefore(r,c)}}(window,document,"script","answerdash-script","AnswerDash");</script> <!-- End of AnswerDash script -->
<!-- Commenting out AnswerDash for now; we need to work on our list of questions/answers/design first
<!-- Start of AnswerDash script <script>var AnswerDash;!function(e,t,n,s,a){if(!t.getElementById(s)){var i,r=t.createElement(n),c=t.getElementsByTagName(n)[0];e[a]||(i=e[a]=function(){i.__oninit.push(arguments)},i.__oninit=[]),r.type="text/javascript",r.async=!0,r.src="https://p1.answerdash.com/answerdash.min.js?siteid=756",r.setAttribute("id",s),c.parentNode.insertBefore(r,c)}}(window,document,"script","answerdash-script","AnswerDash");</script> <!-- End of AnswerDash script -->
-->
</body>
</html>

8
docs/admin/daemons.md
View File

@ -137,14 +137,6 @@ a Daemon Set replaces pods that are deleted or terminated for any reason, such a
node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, you should
use a Daemon Set rather than creating individual pods.
### Static Pods
It is possible to create pods by writing a file to a certain directory watched by Kubelet. These
are called [static pods](/docs/admin/static-pods).
Unlike DaemonSet, static pods cannot be managed with kubectl
or other Kubernetes API clients. Static pods do not depend on the apiserver, making them useful
in cluster bootstrapping cases. Also, static pods may be deprecated in the future.
### Replication Controller
Daemon Set are similar to [Replication Controllers](/docs/user-guide/replication-controller) in that

2
docs/admin/etcd.md
View File

@ -22,7 +22,7 @@ to reduce downtime in case of corruption.
## Default configuration
The default setup scripts use kubelet's file-based static pods feature to run etcd in a
The default setup scripts run etcd in a
[pod](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/etcd/etcd.manifest). This manifest should only
be run on master VMs. The default location that kubelet scans for manifests is
`/etc/kubernetes/manifests/`.

2
docs/admin/namespaces/index.md
View File

@ -51,7 +51,7 @@ Let's create two new namespaces to hold our work.
Use the file [`namespace-dev.json`](/docs/admin/namespacesnamespace-dev.json) which describes a development namespace:
{% include code.html language="json" file="namespace-dev.json" ghlink="https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/admin/namespaces/namespace-dev.json" %}
{% include code.html language="json" file="namespace-dev.json" ghlink="/docs/admin/namespaces/namespace-dev.json" %}
Create the development namespace using kubectl.

123
docs/admin/static-pods.md
View File

@ -1,123 +0,0 @@
---
---
**Static pods are to be deprecated and can be removed in any future Kubernetes release!**
*Static pod* are managed directly by kubelet daemon on a specific node, without API server observing it. It does not have associated any replication controller, kubelet daemon itself watches it and restarts it when it crashes. There is no health check though. Static pods are always bound to one kubelet daemon and always run on the same node with it.
Kubelet automatically creates so-called *mirror pod* on Kubernetes API server for each static pod, so the pods are visible there, but they cannot be controlled from the API server.
## Static pod creation
Static pod can be created in two ways: either by using configuration file(s) or by HTTP.
### Configuration files
The configuration files are just standard pod definition in json or yaml format in specific directory. Use `kubelet --config=<the directory>` to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
For example, this is how to start a simple web server as a static pod:
1. Choose a node where we want to run the static pod. In this example, it's `my-minion1`.
```shell
[joe@host ~] $ ssh my-minion1
```
2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubernetes.d/static-web.yaml`:
```shell
[root@my-minion1 ~] $ mkdir /etc/kubernetes.d/
[root@my-minion1 ~] $ cat <<EOF >/etc/kubernetes.d/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: tcp
EOF
```
2. Configure your kubelet daemon on the node to use this directory by running it with `--config=/etc/kubelet.d/` argument. On Fedora Fedora 21 with Kubernetes 0.17 edit `/etc/kubernetes/kubelet` to include this line:
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --config=/etc/kubelet.d/"
```
Instructions for other distributions or Kubernetes installations may vary.
3. Restart kubelet. On Fedora 21, this is:
```shell
[root@my-minion1 ~] $ systemctl restart kubelet
```
## Pods created via HTTP
Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--config=<directory>`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below).
## Behavior of static pods
When kubelet starts, it automatically starts all pods defined in directory specified in `--config=` or `--manifest-url=` arguments, i.e. our static-web. (It may take some time to pull nginx image, be patient'|):
```shell
[joe@my-minion1 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-minion1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
```
If we look at our Kubernetes API server (running on host `my-master`), we see that a new mirror-pod was created there too:
```shell
[joe@host ~] $ ssh my-master
[joe@my-master ~] $ kubectl get pods
POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE
static-web-my-minion1 172.17.0.3 my-minion1/192.168.100.71 role=myrole Running 11 minutes
web nginx Running 11 minutes
```
Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering.
Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/kubectl) command), kubelet simply won't remove it.
```shell
[joe@my-master ~] $ kubectl delete pod static-web-my-minion1
pods/static-web-my-minion1
[joe@my-master ~] $ kubectl get pods
POD IP CONTAINER(S) IMAGE(S) HOST ...
static-web-my-minion1 172.17.0.3 my-minion1/192.168.100.71 ...
```
Back to our `my-minion1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while:
```shell
[joe@host ~] $ ssh my-minion1
[joe@my-minion1 ~] $ docker stop f6d05272b57e
[joe@my-minion1 ~] $ sleep 20
[joe@my-minion1 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
```
## Dynamic addition and removal of static pods
Running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes pods as files appear/disappear in this directory.
```shell
[joe@my-minion1 ~] $ mv /etc/kubernetes.d/static-web.yaml /tmp
[joe@my-minion1 ~] $ sleep 20
[joe@my-minion1 ~] $ docker ps
// no nginx container is running
[joe@my-minion1 ~] $ mv /tmp/static-web.yaml /etc/kubernetes.d/
[joe@my-minion1 ~] $ sleep 20
[joe@my-minion1 ~] $ docker ps
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
```

10
docs/getting-started-guides/azure.md
View File

@ -1,10 +0,0 @@
---
---
## Getting started on Microsoft Azure
Checkout the [coreos azure getting started guide](/docs/getting-started-guides/coreos/azure/)

20
docs/pagelist.md
View File

@ -1,20 +0,0 @@
---
---
The following is a list of all pages for this site. We also have a [`sitemap.xml`](/sitemap.xml) file.
{% for page in site.pages %}
{% assign foundTOC=false %}
{% assign pageTOC=false %}
{% for thistoc in site.data.globals.tocs %}
{% if foundTOC %}
{% break %}
{% else %}
{% assign tree = site.data[thistoc].toc %}
{% include tocsearch.html %}
{% if foundTOC %}
{% assign pageTOC = thistoc %}
{% endif %}
{% endif %}
{% endfor %}
* {% if pageTOC %}**[{{ pageTOC | capitalize }}](/{%if pageTOC != "guides"%}{{pageTOC}}/{%endif%})**: {% endif %}[{% if page.title %}{{page.title}}{% else %}{{ page.url }}{% endif %}]({{ page.url }})
{% endfor %}

7
docs/reference.md
View File

@ -5,15 +5,14 @@ In the reference section, you can find reference documentation for Kubernetes AP
## API References
* [Kubernetes API](/docs/api/) - The core API for Kubernetes.
* [Extensions API](/docs/api-reference/extensions/v1beta1/operations/) - Manages extensions resources such as Jobs, Ingress and HorizontalPodAutoscalers.
* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API that validates and configures data for API objects such as pods, services, replication controllers.
* [etcd](/docs/admin/etcd/) - Highly-available key value store which Kubernetes uses for persistent storage of all of its REST API objects.
* [Extensions API](/docs/api-reference/extensions/v1beta1/operations/) - Manages extensions resources such as Jobs, Ingress and HorizontalPodAutoscalers.
## CLI References
* [kubectl](/docs/user-guide/kubectl-overview/) - Runs commands against Kubernetes clusters.
* [JSONPath](/docs/user-guide/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
* [JSONPath](/docs/user-guide/jsonpath/) - Syntax guide for using [JSONPath expressions](http://goessner.net/articles/JsonPath/) with kubectl.
* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API that validates and configures data for API objects such as pods, services, replication controllers.
* [kube-proxy](/docs/admin/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of backends.
* [kube-scheduler](/docs/admin/kube-scheduler/) - A policy-rich, topology-aware, workload-specific function that significantly impacts availability, performance, and capacity.
* [kubelet](/docs/admin/kubelet/) - The primary "node agent" that runs on each node. The kubelet takes a set of PodSpecs and ensures that the described containers are running and healthy.

4
docs/user-guide/environment-guide/containers/index.md → docs/user-guide/environment-guide/containers/README.md
View File

@ -1,7 +1,3 @@
---
---
## Building
For each container, the build steps are the same. The examples below

2
docs/user-guide/environment-guide/index.md
View File

@ -23,7 +23,7 @@ for your platform.
## Optional: Build your own containers
The code for the containers is under
[containers/](/docs/user-guide/environment-guide/containers/)
[containers/](https://github.com/kubernetes/kubernetes.github.io/tree/master/docs/user-guide/environment-guide/containers/)
## Get everything running

25
docs/user-guide/index.md
View File

@ -31,10 +31,29 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo
1. [Connecting to containers via proxies](/docs/user-guide/connecting-to-applications-proxy)
1. [Connecting to containers via port forwarding](/docs/user-guide/connecting-to-applications-port-forward)
## Concept guide
## Overview
[**Overview**](/docs/user-guide/overview)
: A brief overview of Kubernetes concepts.
Kubernetes is an open-source system for managing containerized applications across multiple hosts in a cluster. Kubernetes is intended to make deploying containerized/microservice-based applications easy but powerful.
Kubernetes provides mechanisms for application deployment, scheduling, updating, maintenance, and scaling. A key feature of Kubernetes is that it actively manages the containers to ensure that the state of the cluster continually matches the user's intentions. An operations user should be able to launch a micro-service, letting the scheduler find the right placement. We also want to improve the tools and experience for how users can roll-out applications through patterns like canary deployments.
Kubernetes supports [Docker](http://www.docker.io) and [Rocket](https://coreos.com/blog/rocket/) containers, and other container image formats and container runtimes will be supported in the future.
While Kubernetes currently focuses on continuously-running stateless (e.g. web server or in-memory object cache) and "cloud native" stateful applications (e.g. NoSQL datastores), in the near future it will support all the other workload types commonly found in production cluster environments, such as batch, stream processing, and traditional databases.
In Kubernetes, all containers run inside [pods](/docs/user-guide/pods). A pod can host a single container, or multiple cooperating containers; in the latter case, the containers in the pod are guaranteed to be co-located on the same machine and can share resources. A pod can also contain zero or more [volumes](/docs/user-guide/volumes), which are directories that are private to a container or shared across containers in a pod. For each pod the user creates, the system finds a machine that is healthy and that has sufficient available capacity, and starts up the corresponding container(s) there. If a container fails it can be automatically restarted by Kubernetes' node agent, called the Kubelet. But if the pod or its machine fails, it is not automatically moved or restarted unless the user also defines a [replication controller](/docs/user-guide/replication-controller), which we discuss next.
Users can create and manage pods themselves, but Kubernetes drastically simplifies system management by allowing users to delegate two common pod-related activities: deploying multiple pod replicas based on the same pod configuration, and creating replacement pods when a pod or its machine fails. The Kubernetes API object that manages these behaviors is called a [replication controller](/docs/user-guide/replication-controller). It defines a pod in terms of a template, that the system then instantiates as some number of pods (specified by the user). The replicated set of pods might constitute an entire application, a micro-service, or one layer in a multi-tier application. Once the pods are created, the system continually monitors their health and that of the machines they are running on; if a pod fails due to a software problem or machine failure, the replication controller automatically creates a new pod on a healthy machine, to maintain the set of pods at the desired replication level. Multiple pods from the same or different applications can share the same machine. Note that a replication controller is needed even in the case of a single non-replicated pod if the user wants it to be re-created when it or its machine fails.
Frequently it is useful to refer to a set of pods, for example to limit the set of pods on which a mutating operation should be performed, or that should be queried for status. As a general mechanism, users can attach to most Kubernetes API objects arbitrary key-value pairs called [labels](/docs/user-guide/labels), and then use a set of label selectors (key-value queries over labels) to constrain the target of API operations. Each resource also has a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object, called [annotations](/docs/user-guide/annotations).
Kubernetes supports a unique [networking model](/docs/admin/networking). Kubernetes encourages a flat address space and does not dynamically allocate ports, instead allowing users to select whichever ports are convenient for them. To achieve this, it allocates an IP address for each pod.
Modern Internet applications are commonly built by layering micro-services, for example a set of web front-ends talking to a distributed in-memory key-value store talking to a replicated storage service. To facilitate this architecture, Kubernetes offers the [service](/docs/user-guide/services) abstraction, which provides a stable IP address and [DNS name](/docs/admin/dns) that corresponds to a dynamic set of pods such as the set of pods constituting a micro-service. The set is defined using a label selector and thus can refer to any set of pods. When a container running in a Kubernetes pod connects to this address, the connection is forwarded by a local agent (called the kube proxy) running on the source machine, to one of the corresponding back-end containers. The exact back-end is chosen using a round-robin policy to balance load. The kube proxy takes care of tracking the dynamic set of back-ends as pods are replaced by new pods on new hosts, so that the service IP address (and DNS name) never changes.
Every resource in Kubernetes, such as a pod, is identified by a URI and has a UID. Important components of the URI are the kind of object (e.g. pod), the object's name, and the object's [namespace](/docs/user-guide/namespaces). For a certain object kind, every name is unique within its namespace. In contexts where an object name is provided without a namespace, it is assumed to be in the default namespace. UID is unique across time and space.
## Concept guide
[**Cluster**](/docs/admin/)
: A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications.

15
docs/user-guide/logging-demo/README.md Normal file
View File

@ -0,0 +1,15 @@
This directory contains two [pod](/docs/user-guide/pods) specifications which can be used as synthetic
logging sources. The pod specification in [synthetic_0_25lps.yaml](synthetic_0_25lps.yaml)
describes a pod that just emits a log message once every 4 seconds. The pod specification in
[synthetic_10lps.yaml](synthetic_10lps.yaml)
describes a pod that just emits 10 log lines per second.
See [logging document](https://kubernetes.io/docs/user-guide/logging/) for more details about logging. To observe the ingested log lines when using Google Cloud Logging please see the getting
started instructions
at [Cluster Level Logging to Google Cloud Logging](https://kubernetes.io/docs/getting-started-guides/logging).
To observe the ingested log lines when using Elasticsearch and Kibana please see the getting
started instructions
at [Cluster Level Logging with Elasticsearch and Kibana](https://kubernetes.io/docs/getting-started-guides/logging-elasticsearch).

18
docs/user-guide/logging-demo/index.md
View File

@ -1,18 +0,0 @@
---
---
This directory contains two [pod](/docs/user-guide/pods) specifications which can be used as synthetic
logging sources. The pod specification in [synthetic_0_25lps.yaml](/docs/user-guide/logging-demo/synthetic_0_25lps.yaml)
describes a pod that just emits a log message once every 4 seconds. The pod specification in
[synthetic_10lps.yaml](/docs/user-guide/logging-demo/synthetic_10lps.yaml)
describes a pod that just emits 10 log lines per second.
See [logging document](/docs/user-guide/logging/) for more details about logging. To observe the ingested log lines when using Google Cloud Logging please see the getting
started instructions
at [Cluster Level Logging to Google Cloud Logging](/docs/getting-started-guides/logging).
To observe the ingested log lines when using Elasticsearch and Kibana please see the getting
started instructions
at [Cluster Level Logging with Elasticsearch and Kibana](/docs/getting-started-guides/logging-elasticsearch).

2
docs/user-guide/logging.md
View File

@ -11,7 +11,7 @@ Kubernetes components, such as kubelet and apiserver, use the [glog](https://god
The logs of a running container may be fetched using the command `kubectl logs`. For example, given
this pod specification [counter-pod.yaml](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/blog-logging/counter-pod.yaml), which has a container which writes out some text to standard
output every second. (You can find different pod specifications [here](/docs/user-guide/logging-demo/).)
output every second. (You can find different pod specifications [here](https://github.com/kubernetes/kubernetes.github.io/tree/master/docs/user-guide/logging-demo).)
{% include code.html language="yaml" file="counter-pod.yaml" k8slink="/examples/blog-logging/counter-pod.yaml" %}

25
docs/user-guide/overview.md
View File

@ -1,25 +0,0 @@
---
---
Kubernetes is an open-source system for managing containerized applications across multiple hosts in a cluster. Kubernetes is intended to make deploying containerized/microservice-based applications easy but powerful.
Kubernetes provides mechanisms for application deployment, scheduling, updating, maintenance, and scaling. A key feature of Kubernetes is that it actively manages the containers to ensure that the state of the cluster continually matches the user's intentions. An operations user should be able to launch a micro-service, letting the scheduler find the right placement. We also want to improve the tools and experience for how users can roll-out applications through patterns like canary deployments.
Kubernetes supports [Docker](http://www.docker.io) and [Rocket](https://coreos.com/blog/rocket/) containers, and other container image formats and container runtimes will be supported in the future.
While Kubernetes currently focuses on continuously-running stateless (e.g. web server or in-memory object cache) and "cloud native" stateful applications (e.g. NoSQL datastores), in the near future it will support all the other workload types commonly found in production cluster environments, such as batch, stream processing, and traditional databases.
In Kubernetes, all containers run inside [pods](/docs/user-guide/pods). A pod can host a single container, or multiple cooperating containers; in the latter case, the containers in the pod are guaranteed to be co-located on the same machine and can share resources. A pod can also contain zero or more [volumes](/docs/user-guide/volumes), which are directories that are private to a container or shared across containers in a pod. For each pod the user creates, the system finds a machine that is healthy and that has sufficient available capacity, and starts up the corresponding container(s) there. If a container fails it can be automatically restarted by Kubernetes' node agent, called the Kubelet. But if the pod or its machine fails, it is not automatically moved or restarted unless the user also defines a [replication controller](/docs/user-guide/replication-controller), which we discuss next.
Users can create and manage pods themselves, but Kubernetes drastically simplifies system management by allowing users to delegate two common pod-related activities: deploying multiple pod replicas based on the same pod configuration, and creating replacement pods when a pod or its machine fails. The Kubernetes API object that manages these behaviors is called a [replication controller](/docs/user-guide/replication-controller). It defines a pod in terms of a template, that the system then instantiates as some number of pods (specified by the user). The replicated set of pods might constitute an entire application, a micro-service, or one layer in a multi-tier application. Once the pods are created, the system continually monitors their health and that of the machines they are running on; if a pod fails due to a software problem or machine failure, the replication controller automatically creates a new pod on a healthy machine, to maintain the set of pods at the desired replication level. Multiple pods from the same or different applications can share the same machine. Note that a replication controller is needed even in the case of a single non-replicated pod if the user wants it to be re-created when it or its machine fails.
Frequently it is useful to refer to a set of pods, for example to limit the set of pods on which a mutating operation should be performed, or that should be queried for status. As a general mechanism, users can attach to most Kubernetes API objects arbitrary key-value pairs called [labels](/docs/user-guide/labels), and then use a set of label selectors (key-value queries over labels) to constrain the target of API operations. Each resource also has a map of string keys and values that can be used by external tooling to store and retrieve arbitrary metadata about this object, called [annotations](/docs/user-guide/annotations).
Kubernetes supports a unique [networking model](/docs/admin/networking). Kubernetes encourages a flat address space and does not dynamically allocate ports, instead allowing users to select whichever ports are convenient for them. To achieve this, it allocates an IP address for each pod.
Modern Internet applications are commonly built by layering micro-services, for example a set of web front-ends talking to a distributed in-memory key-value store talking to a replicated storage service. To facilitate this architecture, Kubernetes offers the [service](/docs/user-guide/services) abstraction, which provides a stable IP address and [DNS name](/docs/admin/dns) that corresponds to a dynamic set of pods such as the set of pods constituting a micro-service. The set is defined using a label selector and thus can refer to any set of pods. When a container running in a Kubernetes pod connects to this address, the connection is forwarded by a local agent (called the kube proxy) running on the source machine, to one of the corresponding back-end containers. The exact back-end is chosen using a round-robin policy to balance load. The kube proxy takes care of tracking the dynamic set of back-ends as pods are replaced by new pods on new hosts, so that the service IP address (and DNS name) never changes.
Every resource in Kubernetes, such as a pod, is identified by a URI and has a UID. Important components of the URI are the kind of object (e.g. pod), the object's name, and the object's [namespace](/docs/user-guide/namespaces). For a certain object kind, every name is unique within its namespace. In contexts where an object name is provided without a namespace, it is assumed to be in the default namespace. UID is unique across time and space.

6
docs/user-guide/resourcequota/index.md
View File

@ -1,6 +0,0 @@
---
---
This page has been moved to [here](/docs/admin/resourcequota/)

5
index.html
View File

@ -178,8 +178,9 @@ title: Accelerate Your Delivery
ga('create', 'UA-36037335-10', 'auto');
ga('send', 'pageview');
</script>
<!-- Start of AnswerDash script --> <script>var AnswerDash;!function(e,t,n,s,a){if(!t.getElementById(s)){var i,r=t.createElement(n),c=t.getElementsByTagName(n)[0];e[a]||(i=e[a]=function(){i.__oninit.push(arguments)},i.__oninit=[]),r.type="text/javascript",r.async=!0,r.src="https://p1.answerdash.com/answerdash.min.js?siteid=756",r.setAttribute("id",s),c.parentNode.insertBefore(r,c)}}(window,document,"script","answerdash-script","AnswerDash");</script> <!-- End of AnswerDash script -->
<!-- Start of AnswerDash script
<script>var AnswerDash;!function(e,t,n,s,a){if(!t.getElementById(s)){var i,r=t.createElement(n),c=t.getElementsByTagName(n)[0];e[a]||(i=e[a]=function(){i.__oninit.push(arguments)},i.__oninit=[]),r.type="text/javascript",r.async=!0,r.src="https://p1.answerdash.com/answerdash.min.js?siteid=756",r.setAttribute("id",s),c.parentNode.insertBefore(r,c)}}(window,document,"script","answerdash-script","AnswerDash");</script>
<!-- End of AnswerDash script -->
</body>
</html>