Link replacements for a,b,c
This commit is contained in:
John Mulhausen
parent
908582bf72
commit
ebf5d38024
|
|
@ -27,8 +27,8 @@ By default the Kubernetes APIserver serves HTTP on 2 ports:
|
|||
- default is port 6443, change with `--secure-port` flag.
|
||||
- default IP is first non-localhost network interface, change with `--bind-address` flag.
|
||||
- serves HTTPS. Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
|
||||
- uses token-file or client-certificate based [authentication(/{{page.version}}/docs/admin/authentication).
|
||||
- uses policy-based [authorization(/{{page.version}}/docs/admin/authorization).
|
||||
- uses token-file or client-certificate based [authentication](/{{page.version}}/docs/admin/authentication).
|
||||
- uses policy-based [authorization](/{{page.version}}/docs/admin/authorization).
|
||||
3. Removed: ReadOnly Port
|
||||
- For security reasons, this had to be removed. Use the [service account](/{{page.version}}/docs/user-guide/service-accounts) feature instead.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: "Authorization Plugins"
|
||||
---
|
||||
In Kubernetes, authorization happens as a separate step from authentication.
|
||||
See the [authentication documentation(/{{page.version}}/docs/admin/authentication) for an
|
||||
See the [authentication documentation](/{{page.version}}/docs/admin/authentication) for an
|
||||
overview of authentication.
|
||||
|
||||
Authorization applies to all HTTP accesses on the main (secure) apiserver port.
|
||||
|
|
|
|||
|
|
@ -27,41 +27,41 @@ Before choosing a particular guide, here are some things to consider:
|
|||
- Not all distros are maintained as actively. Prefer ones which are listed as tested on a more recent version of
|
||||
Kubernetes.
|
||||
- If you are configuring kubernetes on-premises, you will need to consider what [networking
|
||||
model](networking) fits best.
|
||||
- If you are designing for very high-availability, you may want [clusters in multiple zones](multi-cluster).
|
||||
model](/{{page.version}}/docs/admin/networking) fits best.
|
||||
- If you are designing for very high-availability, you may want [clusters in multiple zones](/{{page.version}}/docs/admin/multi-cluster).
|
||||
- You may want to familiarize yourself with the various
|
||||
[components](cluster-components) needed to run a cluster.
|
||||
[components](/{{page.version}}/docs/admin/cluster-components) needed to run a cluster.
|
||||
|
||||
## Setting up a cluster
|
||||
|
||||
Pick one of the Getting Started Guides from the [matrix](/{{page.version}}/docs/getting-started-guides/) and follow it.
|
||||
If none of the Getting Started Guides fits, you may want to pull ideas from several of the guides.
|
||||
|
||||
One option for custom networking is *OpenVSwitch GRE/VxLAN networking* ([ovs-networking.md](ovs-networking)), which
|
||||
One option for custom networking is *OpenVSwitch GRE/VxLAN networking* ([ovs-networking.md](/{{page.version}}/docs/admin/ovs-networking)), which
|
||||
uses OpenVSwitch to set up networking between pods across
|
||||
Kubernetes nodes.
|
||||
|
||||
If you are modifying an existing guide which uses Salt, this document explains [how Salt is used in the Kubernetes
|
||||
project](salt).
|
||||
project](/{{page.version}}/docs/admin/salt).
|
||||
|
||||
## Managing a cluster, including upgrades
|
||||
|
||||
[Managing a cluster](cluster-management).
|
||||
[Managing a cluster](/{{page.version}}/docs/admin/cluster-management).
|
||||
|
||||
## Managing nodes
|
||||
|
||||
[Managing nodes](node).
|
||||
[Managing nodes](/{{page.version}}/docs/admin/node).
|
||||
|
||||
## Optional Cluster Services
|
||||
|
||||
* **DNS Integration with SkyDNS** ([dns.md](dns)):
|
||||
* **DNS Integration with SkyDNS** ([dns.md](/{{page.version}}/docs/admin/dns)):
|
||||
Resolving a DNS name directly to a Kubernetes service.
|
||||
|
||||
* **Logging** with [Kibana](/{{page.version}}/docs/user-guide/logging)
|
||||
|
||||
## Multi-tenant support
|
||||
|
||||
* **Resource Quota** ([resource-quota.md](resource-quota))
|
||||
* **Resource Quota** ([resource-quota.md](/{{page.version}}/docs/admin/resource-quota))
|
||||
|
||||
## Security
|
||||
|
||||
|
|
@ -69,10 +69,10 @@ project](salt).
|
|||
Describes the environment for Kubelet managed containers on a Kubernetes
|
||||
node.
|
||||
|
||||
* **Securing access to the API Server** [accessing the api](accessing-the-api)
|
||||
* **Securing access to the API Server** [accessing the api](/{{page.version}}/docs/admin/accessing-the-api)
|
||||
|
||||
* **Authentication** [authentication(/{{page.version}}/docs/admin/authentication)
|
||||
* **Authentication** [authentication](/{{page.version}}/docs/admin/authentication)
|
||||
|
||||
* **Authorization** [authorization(/{{page.version}}/docs/admin/authorization)
|
||||
* **Authorization** [authorization](/{{page.version}}/docs/admin/authorization)
|
||||
|
||||
* **Admission Controllers** [admission_controllers](admission-controllers)
|
||||
* **Admission Controllers** [admission_controllers](/{{page.version}}/docs/admin/admission-controllers)
|
||||
|
|
@ -26,7 +26,7 @@ work like this:
|
|||
of the resources for which quota is enabled, then the POST of the pod will fail with HTTP
|
||||
status code `403 FORBIDDEN`. Hint: Use the LimitRange admission controller to force default
|
||||
values of *limits* (then resource *requests* would be equal to *limits* by default, see
|
||||
[admission controller](admission-controllers)) before the quota is checked to avoid this problem.
|
||||
[admission controller](/{{page.version}}/docs/admin/admission-controllers)) before the quota is checked to avoid this problem.
|
||||
|
||||
Examples of policies that could be created using namespaces and quotas are:
|
||||
|
||||
|
|
@ -73,7 +73,7 @@ are supported:
|
|||
| pods | Total number of pods |
|
||||
| services | Total number of services |
|
||||
| replicationcontrollers | Total number of replication controllers |
|
||||
| resourcequotas | Total number of [resource quotas](admission-controllers/#resourcequota) |
|
||||
| resourcequotas | Total number of [resource quotas](/{{page.version}}/docs/admin/admission-controllers/#resourcequota) |
|
||||
| secrets | Total number of secrets |
|
||||
| persistentvolumeclaims | Total number of [persistent volume claims](/{{page.version}}/docs/user-guide/persistent-volumes/#persistentvolumeclaims) |
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Three separate components cooperate to implement the automation around service a
|
|||
### Service Account Admission Controller
|
||||
|
||||
The modification of pods is implemented via a plugin
|
||||
called an [Admission Controller](admission-controllers). It is part of the apiserver.
|
||||
called an [Admission Controller](/{{page.version}}/docs/admin/admission-controllers). It is part of the apiserver.
|
||||
It acts synchronously to modify pods as they are created or updated. When this plugin is active
|
||||
(and it is by default on most distributions), then it does the following when a pod is created or modified:
|
||||
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ In general, condition values may change back and forth, but some condition trans
|
|||
|
||||
A typical oscillating condition type is `Ready`, which indicates the object was believed to be fully operational at the time it was last probed. A possible monotonic condition could be `Succeeded`. A `False` status for `Succeeded` would imply failure. An object that was still active would not have a `Succeeded` condition, or its status would be `Unknown`.
|
||||
|
||||
Some resources in the v1 API contain fields called **`phase`**, and associated `message`, `reason`, and other status fields. The pattern of using `phase` is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted [system-design principles](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/principles.md#control-logic) and hampered evolution, since [adding new enum values breaks backward compatibility](api_changes). Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See [#7856](http://issues.k8s.io/7856) for more details and discussion.
|
||||
Some resources in the v1 API contain fields called **`phase`**, and associated `message`, `reason`, and other status fields. The pattern of using `phase` is deprecated. Newer API types should use conditions instead. Phase was essentially a state-machine enumeration field, that contradicted [system-design principles](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/principles.md#control-logic) and hampered evolution, since [adding new enum values breaks backward compatibility](/{{page.version}}/docs/devel/api_changes). Rather than encouraging clients to infer implicit properties from phases, we intend to explicitly expose the conditions that clients need to monitor. Conditions also have the benefit that it is possible to create some conditions with uniform meaning across all resource types, while still exposing others that are unique to specific resource types. See [#7856](http://issues.k8s.io/7856) for more details and discussion.
|
||||
|
||||
In condition types, and everywhere else they appear in the API, **`Reason`** is intended to be a one-word, CamelCase representation of the category of cause of the current status, and **`Message`** is intended to be a human-readable phrase or sentence, which may contain specific details of the individual occurrence. `Reason` is intended to be used in concise output, such as one-line `kubectl get` output, and in summarizing occurrences of causes, whereas `Message` is intended to be presented to users in detailed status explanations, such as `kubectl describe` output.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "So you want to change the API?"
|
|||
---
|
||||
Before attempting a change to the API, you should familiarize yourself
|
||||
with a number of existing API types and with the [API
|
||||
conventions](api-conventions). If creating a new API
|
||||
conventions](/{{page.version}}/docs/devel/api-conventions). If creating a new API
|
||||
type/resource, we also recommend that you first send a PR containing
|
||||
just a proposal for the new API types, and that you initially target
|
||||
the extensions API (pkg/apis/extensions).
|
||||
|
|
|
|||
|
|
@ -25,8 +25,8 @@ Code conventions
|
|||
- Importers can use a different name if they need to disambiguate.
|
||||
- Locks should be called `lock` and should never be embedded (always `lock sync.Mutex`). When multiple locks are present, give each lock a distinct name following Go conventions - `stateLock`, `mapLock` etc.
|
||||
- API conventions
|
||||
- [API changes](api_changes)
|
||||
- [API conventions](api-conventions)
|
||||
- [API changes](/{{page.version}}/docs/devel/api_changes)
|
||||
- [API conventions](/{{page.version}}/docs/devel/api-conventions)
|
||||
- [Kubectl conventions](kubectl-conventions)
|
||||
- [Logging conventions](logging)
|
||||
|
||||
|
|
|
|||
|
|
@ -23,10 +23,10 @@ Let's talk about how to avoid this.
|
|||
|
||||
## 0. Familiarize yourself with project conventions
|
||||
|
||||
* [Development guide](development)
|
||||
* [Coding conventions](coding-conventions)
|
||||
* [API conventions](api-conventions)
|
||||
* [Kubectl conventions](kubectl-conventions)
|
||||
* [Development guide](/{{page.version}}/docs/devel/development)
|
||||
* [Coding conventions](/{{page.version}}/docs/devel/coding-conventions)
|
||||
* [API conventions](/{{page.version}}/docs/devel/api-conventions)
|
||||
* [Kubectl conventions](/{{page.version}}/docs/devel/kubectl-conventions)
|
||||
|
||||
## 1. Don't build a cathedral in one PR
|
||||
|
||||
|
|
|
|||
|
|
@ -9,35 +9,35 @@ Guide](/{{page.version}}/docs/admin/).
|
|||
|
||||
## The process of developing and contributing code to the Kubernetes project
|
||||
|
||||
* **On Collaborative Development** ([collab.md](collab)): Info on pull requests and code reviews.
|
||||
* **On Collaborative Development** ([collab.md](/{{page.version}}/docs/devel/collab)): Info on pull requests and code reviews.
|
||||
|
||||
* **GitHub Issues** ([issues.md](issues)): How incoming issues are reviewed and prioritized.
|
||||
* **GitHub Issues** ([issues.md](/{{page.version}}/docs/devel/issues)): How incoming issues are reviewed and prioritized.
|
||||
|
||||
* **Pull Request Process** ([pull-requests.md](pull-requests)): When and why pull requests are closed.
|
||||
* **Pull Request Process** ([pull-requests.md](/{{page.version}}/docs/devel/pull-requests)): When and why pull requests are closed.
|
||||
|
||||
* **Faster PR reviews** ([faster_reviews.md](faster_reviews)): How to get faster PR reviews.
|
||||
* **Faster PR reviews** ([faster_reviews.md](/{{page.version}}/docs/devel/faster_reviews)): How to get faster PR reviews.
|
||||
|
||||
* **Getting Recent Builds** ([getting-builds.md](getting-builds)): How to get recent builds including the latest builds that pass CI.
|
||||
* **Getting Recent Builds** ([getting-builds.md](/{{page.version}}/docs/devel/getting-builds)): How to get recent builds including the latest builds that pass CI.
|
||||
|
||||
* **Automated Tools** ([automation.md](automation)): Descriptions of the automation that is running on our github repository.
|
||||
* **Automated Tools** ([automation.md](/{{page.version}}/docs/devel/automation)): Descriptions of the automation that is running on our github repository.
|
||||
|
||||
|
||||
## Setting up your dev environment, coding, and debugging
|
||||
|
||||
* **Development Guide** ([development.md](development)): Setting up your development environment.
|
||||
* **Development Guide** ([development.md](/{{page.version}}/docs/devel/development)): Setting up your development environment.
|
||||
|
||||
* **Hunting flaky tests** ([flaky-tests.md](flaky-tests)): We have a goal of 99.9% flake free tests.
|
||||
* **Hunting flaky tests** ([flaky-tests.md](/{{page.version}}/docs/devel/flaky-tests)): We have a goal of 99.9% flake free tests.
|
||||
Here's how to run your tests many times.
|
||||
|
||||
* **Logging Conventions** ([logging.md](logging)]: Glog levels.
|
||||
* **Logging Conventions** ([logging.md](/{{page.version}}/docs/devel/logging)]: Glog levels.
|
||||
|
||||
* **Profiling Kubernetes** ([profiling.md](profiling)): How to plug in go pprof profiler to Kubernetes.
|
||||
* **Profiling Kubernetes** ([profiling.md](/{{page.version}}/docs/devel/profiling)): How to plug in go pprof profiler to Kubernetes.
|
||||
|
||||
* **Instrumenting Kubernetes with a new metric**
|
||||
([instrumentation.md](instrumentation)): How to add a new metrics to the
|
||||
([instrumentation.md](/{{page.version}}/docs/devel/instrumentation)): How to add a new metrics to the
|
||||
Kubernetes code base.
|
||||
|
||||
* **Coding Conventions** ([coding-conventions.md](coding-conventions)):
|
||||
* **Coding Conventions** ([coding-conventions.md](/{{page.version}}/docs/devel/coding-conventions)):
|
||||
Coding style advice for contributors.
|
||||
|
||||
|
||||
|
|
@ -48,10 +48,10 @@ Guide](/{{page.version}}/docs/admin/).
|
|||
* **Annotations** ([docs/user-guide/annotations.md](/{{page.version}}/docs/user-guide/annotations)): are for attaching arbitrary non-identifying metadata to objects.
|
||||
Programs that automate Kubernetes objects may use annotations to store small amounts of their state.
|
||||
|
||||
* **API Conventions** ([api-conventions.md](api-conventions)):
|
||||
* **API Conventions** ([api-conventions.md](/{{page.version}}/docs/devel/api-conventions)):
|
||||
Defining the verbs and resources used in the Kubernetes API.
|
||||
|
||||
* **API Client Libraries** ([client-libraries.md](client-libraries)):
|
||||
* **API Client Libraries** ([client-libraries.md](/{{page.version}}/docs/devel/client-libraries)):
|
||||
A list of existing client libraries, both supported and user-contributed.
|
||||
|
||||
|
||||
|
|
@ -69,9 +69,9 @@ Guide](/{{page.version}}/docs/admin/).
|
|||
|
||||
## Building releases
|
||||
|
||||
* **Making release notes** ([making-release-notes.md](making-release-notes)): Generating release nodes for a new release.
|
||||
* **Making release notes** ([making-release-notes.md](/{{page.version}}/docs/devel/making-release-notes)): Generating release nodes for a new release.
|
||||
|
||||
* **Releasing Kubernetes** ([releasing.md](releasing)): How to create a Kubernetes release (as in version)
|
||||
* **Releasing Kubernetes** ([releasing.md](/{{page.version}}/docs/devel/releasing)): How to create a Kubernetes release (as in version)
|
||||
and how the version information gets embedded into the built binaries.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Additionally, for infrequent or new contributors, we require the on call to appl
|
|||
## Automation
|
||||
|
||||
We use a variety of automation to manage pull requests. This automation is described in detail
|
||||
[elsewhere.](automation)
|
||||
[elsewhere.](/{{page.version}}/docs/devel/automation)
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ In your git repo (you still have `${VER}` set from above right?):
|
|||
|
||||
#### Writing Release Notes
|
||||
|
||||
[This helpful guide](making-release-notes) describes how to write release
|
||||
[This helpful guide](/{{page.version}}/docs/devel/making-release-notes) describes how to write release
|
||||
notes for a major/minor release. In the release template on GitHub, leave the
|
||||
last PR number that the tool finds for the `.0` release, so the next releaser
|
||||
doesn't have to hunt.
|
||||
|
|
@ -99,7 +99,7 @@ doesn't have to hunt.
|
|||
We cut `vX.Y.Z` releases from the `release-vX.Y` branch after all cherry picks
|
||||
to the branch have been resolved. You should ensure all outstanding cherry picks
|
||||
have been reviewed and merged and the branch validated on Jenkins (validation
|
||||
TBD). See the [Cherry Picks](cherry-picks) for more information on how to
|
||||
TBD). See the [Cherry Picks](/{{page.version}}/docs/devel/cherry-picks) for more information on how to
|
||||
manage cherry picks prior to cutting the release.
|
||||
|
||||
#### Tagging and Merging
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ Now for the good stuff!
|
|||
|
||||
The following config files are tailored for the OFFLINE version of a Kubernetes deployment.
|
||||
|
||||
These are based on the work found here: [master.yml](cloud-configs/master.yaml), [node.yml](cloud-configs/node.yaml)
|
||||
These are based on the work found here: [master.yml](/{{page.version}}/docs/getting-started-guides/coreos/cloud-configs/master.yaml), [node.yml](/{{page.version}}/docs/getting-started-guides/coreos/cloud-configs/node.yaml)
|
||||
|
||||
To make the setup work, you need to replace a few placeholders:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "CoreOS Multinode Cluster"
|
||||
---
|
||||
Use the [master.yaml](cloud-configs/master.yaml) and [node.yaml](cloud-configs/node.yaml) cloud-configs to provision a multi-node Kubernetes cluster.
|
||||
Use the [master.yaml](/{{page.version}}/docs/getting-started-guides/coreos/cloud-configs/master.yaml) and [node.yaml](/{{page.version}}/docs/getting-started-guides/coreos/cloud-configs/node.yaml) cloud-configs to provision a multi-node Kubernetes cluster.
|
||||
|
||||
> **Attention**: This requires at least CoreOS version **[695.0.0][coreos695]**, which includes `etcd2`.
|
||||
|
||||
|
|
|
|||
|
|
@ -46,8 +46,8 @@ clusters.
|
|||
These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a
|
||||
few commands, and have active community support.
|
||||
|
||||
- [GCE](gce)
|
||||
- [AWS](aws)
|
||||
- [GCE](/{{page.version}}/docs/getting-started-guides/gce)
|
||||
- [AWS](/{{page.version}}/docs/getting-started-guides/aws)
|
||||
- [Azure](/{{page.version}}/docs/getting-started-guides/coreos/azure/)
|
||||
|
||||
### Custom Solutions
|
||||
|
|
@ -67,21 +67,21 @@ writing a new solution](/{{page.version}}/docs/devel/writing-a-getting-started-g
|
|||
|
||||
These solutions are combinations of cloud provider and OS not covered by the above solutions.
|
||||
|
||||
- [AWS + coreos](coreos)
|
||||
- [GCE + CoreOS](coreos)
|
||||
- [AWS + Ubuntu](juju)
|
||||
- [Joyent + Ubuntu](juju)
|
||||
- [Rackspace + CoreOS](rackspace)
|
||||
- [AWS + coreos](/{{page.version}}/docs/getting-started-guides/coreos)
|
||||
- [GCE + CoreOS](/{{page.version}}/docs/getting-started-guides/coreos)
|
||||
- [AWS + Ubuntu](/{{page.version}}/docs/getting-started-guides/juju)
|
||||
- [Joyent + Ubuntu](/{{page.version}}/docs/getting-started-guides/juju)
|
||||
- [Rackspace + CoreOS](/{{page.version}}/docs/getting-started-guides/rackspace)
|
||||
|
||||
#### On-Premises VMs
|
||||
|
||||
- [Vagrant](coreos) (uses CoreOS and flannel)
|
||||
- [CloudStack](cloudstack) (uses Ansible, CoreOS and flannel)
|
||||
- [Vmware](vsphere) (uses Debian)
|
||||
- [juju.md](juju) (uses Juju, Ubuntu and flannel)
|
||||
- [Vmware](coreos) (uses CoreOS and flannel)
|
||||
- [libvirt-coreos.md](libvirt-coreos) (uses CoreOS)
|
||||
- [oVirt](ovirt)
|
||||
- [Vagrant](/{{page.version}}/docs/getting-started-guides/coreos) (uses CoreOS and flannel)
|
||||
- [CloudStack](/{{page.version}}/docs/getting-started-guides/cloudstack) (uses Ansible, CoreOS and flannel)
|
||||
- [Vmware](/{{page.version}}/docs/getting-started-guides/vsphere) (uses Debian)
|
||||
- [juju.md](/{{page.version}}/docs/getting-started-guides/juju) (uses Juju, Ubuntu and flannel)
|
||||
- [Vmware](/{{page.version}}/docs/getting-started-guides/coreos) (uses CoreOS and flannel)
|
||||
- [libvirt-coreos.md](/{{page.version}}/docs/getting-started-guides/libvirt-coreos) (uses CoreOS)
|
||||
- [oVirt](/{{page.version}}/docs/getting-started-guides/ovirt)
|
||||
- [libvirt](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) (uses Fedora and flannel)
|
||||
- [KVM](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) (uses Fedora and flannel)
|
||||
|
||||
|
|
@ -92,16 +92,16 @@ These solutions are combinations of cloud provider and OS not covered by the abo
|
|||
- [Fedora single node](/{{page.version}}/docs/getting-started-guides/fedora/fedora_manual_config)
|
||||
- [Fedora multi node](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster)
|
||||
- [Centos](/{{page.version}}/docs/getting-started-guides/centos/centos_manual_config)
|
||||
- [Ubuntu](ubuntu)
|
||||
- [Docker Multi Node](docker-multinode)
|
||||
- [Ubuntu](/{{page.version}}/docs/getting-started-guides/ubuntu)
|
||||
- [Docker Multi Node](/{{page.version}}/docs/getting-started-guides/docker-multinode)
|
||||
|
||||
#### Integrations
|
||||
|
||||
These solutions provide integration with 3rd party schedulers, resource managers, and/or lower level platforms.
|
||||
|
||||
- [Kubernetes on Mesos](mesos)
|
||||
- [Kubernetes on Mesos](/{{page.version}}/docs/getting-started-guides/mesos)
|
||||
- Instructions specify GCE, but are generic enough to be adapted to most existing Mesos clusters
|
||||
- [Kubernetes on DCOS](dcos)
|
||||
- [Kubernetes on DCOS](/{{page.version}}/docs/getting-started-guides/dcos)
|
||||
- Community Edition DCOS uses AWS
|
||||
- Enterprise Edition DCOS supports cloud hosting, on-premise VMs, and bare metal
|
||||
|
||||
|
|
@ -112,39 +112,39 @@ Here are all the solutions mentioned above in table form.
|
|||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | ['œ“][3] | Commercial
|
||||
Vagrant | Saltstack | Fedora | flannel | [docs](vagrant) | ['œ“][2] | Project
|
||||
GCE | Saltstack | Debian | GCE | [docs](gce) | ['œ“][1] | Project
|
||||
Vagrant | Saltstack | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/vagrant) | ['œ“][2] | Project
|
||||
GCE | Saltstack | Debian | GCE | [docs](/{{page.version}}/docs/getting-started-guides/gce) | ['œ“][1] | Project
|
||||
Azure | CoreOS | CoreOS | Weave | [docs](/{{page.version}}/docs/getting-started-guides/coreos/azure/) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin))
|
||||
Docker Single Node | custom | N/A | local | [docs](docker) | | Project ([@brendandburns](https://github.com/brendandburns))
|
||||
Docker Multi Node | Flannel | N/A | local | [docs](docker-multinode) | | Project ([@brendandburns](https://github.com/brendandburns))
|
||||
Docker Single Node | custom | N/A | local | [docs](/{{page.version}}/docs/getting-started-guides/docker) | | Project ([@brendandburns](https://github.com/brendandburns))
|
||||
Docker Multi Node | Flannel | N/A | local | [docs](/{{page.version}}/docs/getting-started-guides/docker-multinode) | | Project ([@brendandburns](https://github.com/brendandburns))
|
||||
Bare-metal | Ansible | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/fedora_ansible_config) | | Project
|
||||
Digital Ocean | custom | Fedora | Calico | [docs](/{{page.version}}/docs/getting-started-guides/fedora/fedora-calico) | | Community (@djosborne)
|
||||
Bare-metal | custom | Fedora | _none_ | [docs](/{{page.version}}/docs/getting-started-guides/fedora/fedora_manual_config) | | Project
|
||||
Bare-metal | custom | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
libvirt | custom | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
KVM | custom | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
Mesos/Docker | custom | Ubuntu | Docker | [docs](mesos-docker) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
Mesos/GCE | | | | [docs](mesos) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
DCOS | Marathon | CoreOS/Alpine | custom | [docs](dcos) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
AWS | CoreOS | CoreOS | flannel | [docs](coreos) | | Community
|
||||
GCE | CoreOS | CoreOS | flannel | [docs](coreos) | | Community ([@pires](https://github.com/pires))
|
||||
Vagrant | CoreOS | CoreOS | flannel | [docs](coreos) | | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
|
||||
Mesos/Docker | custom | Ubuntu | Docker | [docs](/{{page.version}}/docs/getting-started-guides/mesos-docker) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
Mesos/GCE | | | | [docs](/{{page.version}}/docs/getting-started-guides/mesos) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
DCOS | Marathon | CoreOS/Alpine | custom | [docs](/{{page.version}}/docs/getting-started-guides/dcos) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
AWS | CoreOS | CoreOS | flannel | [docs](/{{page.version}}/docs/getting-started-guides/coreos) | | Community
|
||||
GCE | CoreOS | CoreOS | flannel | [docs](/{{page.version}}/docs/getting-started-guides/coreos) | | Community ([@pires](https://github.com/pires))
|
||||
Vagrant | CoreOS | CoreOS | flannel | [docs](/{{page.version}}/docs/getting-started-guides/coreos) | | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
|
||||
Bare-metal (Offline) | CoreOS | CoreOS | flannel | [docs](/{{page.version}}/docs/getting-started-guides/coreos/bare_metal_offline) | | Community ([@jeffbean](https://github.com/jeffbean))
|
||||
Bare-metal | CoreOS | CoreOS | Calico | [docs](/{{page.version}}/docs/getting-started-guides/coreos/bare_metal_calico) | | Community ([@caseydavenport](https://github.com/caseydavenport))
|
||||
CloudStack | Ansible | CoreOS | flannel | [docs](cloudstack) | | Community ([@runseb](https://github.com/runseb))
|
||||
Vmware | | Debian | OVS | [docs](vsphere) | | Community ([@pietern](https://github.com/pietern))
|
||||
CloudStack | Ansible | CoreOS | flannel | [docs](/{{page.version}}/docs/getting-started-guides/cloudstack) | | Community ([@runseb](https://github.com/runseb))
|
||||
Vmware | | Debian | OVS | [docs](/{{page.version}}/docs/getting-started-guides/vsphere) | | Community ([@pietern](https://github.com/pietern))
|
||||
Bare-metal | custom | CentOS | _none_ | [docs](/{{page.version}}/docs/getting-started-guides/centos/centos_manual_config) | | Community ([@coolsvap](https://github.com/coolsvap))
|
||||
AWS | Juju | Ubuntu | flannel | [docs](juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
OpenStack/HPCloud | Juju | Ubuntu | flannel | [docs](juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
Joyent | Juju | Ubuntu | flannel | [docs](juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
AWS | Saltstack | Ubuntu | OVS | [docs](aws) | | Community ([@justinsb](https://github.com/justinsb))
|
||||
Bare-metal | custom | Ubuntu | Calico | [docs](ubuntu-calico) | | Community ([@djosborne](https://github.com/djosborne))
|
||||
Bare-metal | custom | Ubuntu | flannel | [docs](ubuntu) | | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY))
|
||||
Local | | | _none_ | [docs](locally) | | Community ([@preillyme](https://github.com/preillyme))
|
||||
libvirt/KVM | CoreOS | CoreOS | libvirt/KVM | [docs](libvirt-coreos) | | Community ([@lhuard1A](https://github.com/lhuard1A))
|
||||
oVirt | | | | [docs](ovirt) | | Community ([@simon3z](https://github.com/simon3z))
|
||||
Rackspace | CoreOS | CoreOS | flannel | [docs](rackspace) | | Community ([@doublerr](https://github.com/doublerr))
|
||||
any | any | any | any | [docs](scratch) | | Community ([@erictune](https://github.com/erictune))
|
||||
AWS | Juju | Ubuntu | flannel | [docs](/{{page.version}}/docs/getting-started-guides/juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
OpenStack/HPCloud | Juju | Ubuntu | flannel | [docs](/{{page.version}}/docs/getting-started-guides/juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
Joyent | Juju | Ubuntu | flannel | [docs](/{{page.version}}/docs/getting-started-guides/juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
AWS | Saltstack | Ubuntu | OVS | [docs](/{{page.version}}/docs/getting-started-guides/aws) | | Community ([@justinsb](https://github.com/justinsb))
|
||||
Bare-metal | custom | Ubuntu | Calico | [docs](/{{page.version}}/docs/getting-started-guides/ubuntu-calico) | | Community ([@djosborne](https://github.com/djosborne))
|
||||
Bare-metal | custom | Ubuntu | flannel | [docs](/{{page.version}}/docs/getting-started-guides/ubuntu) | | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY))
|
||||
Local | | | _none_ | [docs](/{{page.version}}/docs/getting-started-guides/locally) | | Community ([@preillyme](https://github.com/preillyme))
|
||||
libvirt/KVM | CoreOS | CoreOS | libvirt/KVM | [docs](/{{page.version}}/docs/getting-started-guides/libvirt-coreos) | | Community ([@lhuard1A](https://github.com/lhuard1A))
|
||||
oVirt | | | | [docs](/{{page.version}}/docs/getting-started-guides/ovirt) | | Community ([@simon3z](https://github.com/simon3z))
|
||||
Rackspace | CoreOS | CoreOS | flannel | [docs](/{{page.version}}/docs/getting-started-guides/rackspace) | | Community ([@doublerr](https://github.com/doublerr))
|
||||
any | any | any | any | [docs](/{{page.version}}/docs/getting-started-guides/scratch) | | Community ([@erictune](https://github.com/erictune))
|
||||
|
||||
|
||||
*Note*: The above table is ordered by version test/used in notes followed by support level.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ accomplished in two ways:
|
|||
|
||||
- Configure network to route Pod IPs
|
||||
- Harder to setup from scratch.
|
||||
- Google Compute Engine ([GCE](gce)) and [AWS](aws) guides use this approach.
|
||||
- Google Compute Engine ([GCE](gce)) and [AWS](/{{page.version}}/docs/getting-started-guides/aws) guides use this approach.
|
||||
- Need to make the Pod IPs routable by programming routers, switches, etc.
|
||||
- Can be configured external to Kubernetes, or can implement in the "Routes" interface of a Cloud Provider module.
|
||||
- Generally highest performance.
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ export GOPATH=$HOME/src/go
|
|||
go get github.com/vmware/govmomi/govc
|
||||
```
|
||||
|
||||
5. Get or build a [binary release](binary_release)
|
||||
5. Get or build a [binary release](/{{page.version}}/docs/getting-started-guides/binary_release)
|
||||
|
||||
### Setup
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ there are insufficient resources of one type or another that prevent scheduling.
|
|||
your pod. Reasons include:
|
||||
|
||||
* **You don't have enough resources**: You may have exhausted the supply of CPU or Memory in your cluster, in this case
|
||||
you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) for more information.
|
||||
you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](/{{page.version}}/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) for more information.
|
||||
|
||||
* **You are using `hostPort`**: When you bind a Pod to a `hostPort` there are a limited number of places that pod can be
|
||||
scheduled. In most cases, `hostPort` is unnecessary, try using a Service object to expose your Pod. If you do require
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ This document is meant to highlight and consolidate in one place configuration b
|
|||
1. Group related objects together in a single file. This is often better than separate files.
|
||||
1. Use `kubectl create -f <directory>` where possible. This looks for config objects in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes them to create.
|
||||
1. Create a service before corresponding replication controllers so that the scheduler can spread the pods comprising the service. You can also create the replication controller without specifying replicas, create the service, then scale up the replication controller, which may work better in an example using progressive disclosure and may have benefits in real scenarios also, such as ensuring one replica works before creating lots of them)
|
||||
1. Don't use `hostPort` unless absolutely necessary (e.g., for a node daemon) as it will prevent certain scheduling configurations due to port conflicts. Use the apiserver proxying or port forwarding for debug/admin access, or a service for external service access. If you need to expose a pod's port on the host machine, consider using a [NodePort](services/#type--loadbalancer) service before resorting to `hostPort`. If you only need access to the port for debugging purposes, you can also use the [kubectl proxy and apiserver proxy](connecting-to-applications-proxy) or [kubectl port-forward](connecting-to-applications-port-forward).
|
||||
1. Don't use `hostPort` unless absolutely necessary (e.g., for a node daemon) as it will prevent certain scheduling configurations due to port conflicts. Use the apiserver proxying or port forwarding for debug/admin access, or a service for external service access. If you need to expose a pod's port on the host machine, consider using a [NodePort](services/#type--loadbalancer) service before resorting to `hostPort`. If you only need access to the port for debugging purposes, you can also use the [kubectl proxy and apiserver proxy](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy) or [kubectl port-forward](/{{page.version}}/docs/user-guide/connecting-to-applications-port-forward).
|
||||
1. Don't use `hostNetwork` for the same reasons as `hostPort`.
|
||||
1. Don't specify default values unnecessarily, to simplify and minimize configs. For example, omit the selector and labels in ReplicationController if you want them to be the same as the labels in its podTemplate, since those fields are populated from the podTemplate labels by default.
|
||||
1. Instead of attaching one label to a set of pods to represent a service (e.g., `service: myservice`) and another to represent the replication controller managing the pods (e.g., `controller: mycontroller`), attach labels that identify semantic attributes of your application or deployment and select the appropriate subsets in your service and replication controller, such as `{ app: myapp, tier: frontend, deployment: v3 }`. A service can be made to span multiple deployments, such as across rolling updates, by simply omitting release-specific labels from its selector, rather than updating a service's selector to match the replication controller's selector fully.
|
||||
|
|
|
|||
|
|
@ -6,13 +6,13 @@ title: "Kubernetes User Guide: Managing Applications: Configuring and launching
|
|||
|
||||
## Configuration in Kubernetes
|
||||
|
||||
In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](quick-start), Kubernetes supports declarative configuration. Often times, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
|
||||
In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](/{{page.version}}/docs/user-guide/quick-start), Kubernetes supports declarative configuration. Often times, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
|
||||
|
||||
In the declarative style, all configuration is stored in YAML or JSON configuration files using Kubernetes's API resource schemas as the configuration schemas. `kubectl` can create, update, delete, and get API resources. The `apiVersion` (currently 'v1'?), resource `kind`, and resource `name` are used by `kubectl` to construct the appropriate API path to invoke for the specified operation.
|
||||
|
||||
## Launching a container using a configuration file
|
||||
|
||||
Kubernetes executes containers in [*Pods*](pods). A pod containing a simple Hello World container can be specified in YAML as follows:
|
||||
Kubernetes executes containers in [*Pods*](/{{page.version}}/docs/user-guide/pods). A pod containing a simple Hello World container can be specified in YAML as follows:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -31,7 +31,7 @@ The value of `metadata.name`, `hello-world`, will be the name of the pod resourc
|
|||
|
||||
`restartPolicy: Never` indicates that we just want to run the container once and then terminate the pod.
|
||||
|
||||
The [`command`](containers/#containers-and-commands) overrides the Docker container's `Entrypoint`. Command arguments (corresponding to Docker's `Cmd`) may be specified using `args`, as follows:
|
||||
The [`command`](/{{page.version}}/docs/user-guide/containers/#containers-and-commands) overrides the Docker container's `Entrypoint`. Command arguments (corresponding to Docker's `Cmd`) may be specified using `args`, as follows:
|
||||
|
||||
```yaml
|
||||
command: ["/bin/echo"]
|
||||
|
|
@ -161,4 +161,4 @@ On the other hand, containers and their logs are eventually deleted automaticall
|
|||
|
||||
## What's next?
|
||||
|
||||
[Learn about deploying continuously running applications.](deploying-applications)
|
||||
[Learn about deploying continuously running applications.](/{{page.version}}/docs/user-guide/deploying-applications)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Connecting to applications: kubectl port-forward"
|
||||
---
|
||||
kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](kubectl/kubectl_port-forward). Compared to [kubectl proxy](accessing-the-cluster/#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging.
|
||||
kubectl port-forward forwards connections to a local port to a port on a pod. Its man page is available [here](kubectl/kubectl_port-forward). Compared to [kubectl proxy](/{{page.version}}/docs/user-guide/accessing-the-cluster/#using-kubectl-proxy), `kubectl port-forward` is more generic as it can forward TCP traffic while `kubectl proxy` can only forward HTTP traffic. This guide demonstrates how to use `kubectl port-forward` to connect to a Redis database, which may be useful for database debugging.
|
||||
|
||||
## Creating a Redis master
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Connecting to applications: kubectl proxy and apiserver proxy"
|
||||
---
|
||||
You have seen the [basics](accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](ui)) running on the Kubernetes cluster from your workstation.
|
||||
You have seen the [basics](/{{page.version}}/docs/user-guide/accessing-the-cluster) about `kubectl proxy` and `apiserver proxy`. This guide shows how to use them together to access a service([kube-ui](ui)) running on the Kubernetes cluster from your workstation.
|
||||
|
||||
|
||||
## Getting the apiserver proxy URL of kube-ui
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Kubernetes User Guide: Managing Applications: Deploying continuously running applications"
|
||||
---
|
||||
You previously read about how to quickly deploy a simple replicated application using [`kubectl run`](quick-start) and how to configure and launch single-run containers using pods ([Configuring containers](configuring-containers)). Here you'll use the configuration-based approach to deploy a continuously running, replicated application.
|
||||
You previously read about how to quickly deploy a simple replicated application using [`kubectl run`](quick-start) and how to configure and launch single-run containers using pods ([Configuring containers](/{{page.version}}/docs/user-guide/configuring-containers)). Here you'll use the configuration-based approach to deploy a continuously running, replicated application.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
|
@ -111,4 +111,4 @@ You could also specify the `selector` explicitly, such as if you wanted to speci
|
|||
|
||||
## What's next?
|
||||
|
||||
[Learn about exposing applications to users and clients, and connecting tiers of your application together.](connecting-applications)
|
||||
[Learn about exposing applications to users and clients, and connecting tiers of your application together.](/{{page.version}}/docs/user-guide/connecting-applications)
|
||||
|
|
@ -250,7 +250,7 @@ before changing course.
|
|||
|
||||
As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and
|
||||
`metadata` fields. For general information about working with config files,
|
||||
see [here](deploying-applications), [here](configuring-containers), and [here](working-with-resources).
|
||||
see [here](deploying-applications), [here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).
|
||||
|
||||
A Deployment also needs a [`.spec` section](/{{page.version}}/docs/devel/api-conventions/#spec-and-status).
|
||||
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ Using a similar syntax it's possible to expose pod information to containers usi
|
|||
Downward API are dumped to a mounted volume. This is achieved using a `downwardAPI`
|
||||
volume type and the different items represent the files to be created. `fieldPath` references the field to be exposed.
|
||||
|
||||
Downward API volume permits to store more complex data like [`metadata.labels`](labels) and [`metadata.annotations`](annotations). Currently key/value pair set fields are saved using `key="value"` format:
|
||||
Downward API volume permits to store more complex data like [`metadata.labels`](labels) and [`metadata.annotations`](/{{page.version}}/docs/user-guide/annotations). Currently key/value pair set fields are saved using `key="value"` format:
|
||||
|
||||
```conf
|
||||
key1="value1"
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ for your platform.
|
|||
## Optional: Build your own containers
|
||||
|
||||
The code for the containers is under
|
||||
[containers/](containers/)
|
||||
[containers/](/{{page.version}}/docs/user-guide/environment-guide/containers/)
|
||||
|
||||
## Get everything running
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ First the frontend pod's information is printed. The pod name and
|
|||
[namespace](https://github.com/kubernetes/kubernetes/blob/{{ page.githubbranch }}/docs/design/namespaces.md) are retrieved from the
|
||||
[Downward API](/{{page.version}}/docs/user-guide/downward-api). Next, `USER_VAR` is the name of
|
||||
an environment variable set in the [pod
|
||||
definition](show-rc.yaml). Then, the dynamic Kubernetes environment
|
||||
definition](/{{page.version}}/docs/user-guide/environment-guide/show-rc.yaml). Then, the dynamic Kubernetes environment
|
||||
variables are scanned and printed. These are used to find the backend
|
||||
service, named `backend-srv`. Finally, the frontend pod queries the
|
||||
backend service and prints the information returned. Again the backend
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "Identifiers"
|
|||
---
|
||||
All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID.
|
||||
|
||||
For non-unique user-provided attributes, Kubernetes provides [labels](labels) and [annotations](annotations).
|
||||
For non-unique user-provided attributes, Kubernetes provides [labels](labels) and [annotations](/{{page.version}}/docs/user-guide/annotations).
|
||||
|
||||
## Names
|
||||
|
||||
|
|
|
|||
|
|
@ -6,34 +6,34 @@ title: "Kubernetes User Guide: Managing Applications"
|
|||
|
||||
The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/). The [Developer Guide](/{{page.version}}/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.
|
||||
|
||||
Please ensure you have completed the [prerequisites for running examples from the user guide](prereqs).
|
||||
Please ensure you have completed the [prerequisites for running examples from the user guide](/{{page.version}}/docs/user-guide/prereqs).
|
||||
|
||||
## Quick walkthrough
|
||||
|
||||
1. [Kubernetes 101](walkthrough/)
|
||||
1. [Kubernetes 201](walkthrough/k8s201)
|
||||
1. [Kubernetes 101](/{{page.version}}/docs/user-guide/walkthrough/)
|
||||
1. [Kubernetes 201](/{{page.version}}/docs/user-guide/walkthrough/k8s201)
|
||||
|
||||
## Thorough walkthrough
|
||||
|
||||
If you don't have much familiarity with Kubernetes, we recommend you read the following sections in order:
|
||||
|
||||
1. [Quick start: launch and expose an application](quick-start)
|
||||
1. [Configuring and launching containers: configuring common container parameters](configuring-containers)
|
||||
1. [Deploying continuously running applications](deploying-applications)
|
||||
1. [Connecting applications: exposing applications to clients and users](connecting-applications)
|
||||
1. [Working with containers in production](production-pods)
|
||||
1. [Managing deployments](managing-deployments)
|
||||
1. [Application introspection and debugging](introspection-and-debugging)
|
||||
1. [Using the Kubernetes web user interface](ui)
|
||||
1. [Logging](logging)
|
||||
1. [Monitoring](monitoring)
|
||||
1. [Getting into containers via `exec`](getting-into-containers)
|
||||
1. [Connecting to containers via proxies](connecting-to-applications-proxy)
|
||||
1. [Connecting to containers via port forwarding](connecting-to-applications-port-forward)
|
||||
1. [Quick start: launch and expose an application](/{{page.version}}/docs/user-guide/quick-start)
|
||||
1. [Configuring and launching containers: configuring common container parameters](/{{page.version}}/docs/user-guide/configuring-containers)
|
||||
1. [Deploying continuously running applications](/{{page.version}}/docs/user-guide/deploying-applications)
|
||||
1. [Connecting applications: exposing applications to clients and users](/{{page.version}}/docs/user-guide/connecting-applications)
|
||||
1. [Working with containers in production](/{{page.version}}/docs/user-guide/production-pods)
|
||||
1. [Managing deployments](/{{page.version}}/docs/user-guide/managing-deployments)
|
||||
1. [Application introspection and debugging](/{{page.version}}/docs/user-guide/introspection-and-debugging)
|
||||
1. [Using the Kubernetes web user interface](/{{page.version}}/docs/user-guide/ui)
|
||||
1. [Logging](/{{page.version}}/docs/user-guide/logging)
|
||||
1. [Monitoring](/{{page.version}}/docs/user-guide/monitoring)
|
||||
1. [Getting into containers via `exec`](/{{page.version}}/docs/user-guide/getting-into-containers)
|
||||
1. [Connecting to containers via proxies](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy)
|
||||
1. [Connecting to containers via port forwarding](/{{page.version}}/docs/user-guide/connecting-to-applications-port-forward)
|
||||
|
||||
## Concept guide
|
||||
|
||||
[**Overview**](overview)
|
||||
[**Overview**](/{{page.version}}/docs/user-guide/overview)
|
||||
: A brief overview of Kubernetes concepts.
|
||||
|
||||
[**Cluster**](/{{page.version}}/docs/admin/)
|
||||
|
|
@ -42,52 +42,49 @@ If you don't have much familiarity with Kubernetes, we recommend you read the fo
|
|||
[**Node**](/{{page.version}}/docs/admin/node)
|
||||
: A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled.
|
||||
|
||||
[**Pod**](pods)
|
||||
[**Pod**](/{{page.version}}/docs/user-guide/pods)
|
||||
: A pod is a co-located group of containers and volumes.
|
||||
|
||||
[**Label**](labels)
|
||||
[**Label**](/{{page.version}}/docs/user-guide/labels)
|
||||
: A label is a key/value pair that is attached to a resource, such as a pod, to convey a user-defined identifying attribute. Labels can be used to organize and to select subsets of resources.
|
||||
|
||||
[**Selector**](labels/#label-selectors)
|
||||
[**Selector**](/{{page.version}}/docs/user-guide/labels/#label-selectors)
|
||||
: A selector is an expression that matches labels in order to identify related resources, such as which pods are targeted by a load-balanced service.
|
||||
|
||||
[**Replication Controller**](replication-controller)
|
||||
[**Replication Controller**](/{{page.version}}/docs/user-guide/replication-controller)
|
||||
: A replication controller ensures that a specified number of pod replicas are running at any one time. It both allows for easy scaling of replicated systems and handles re-creation of a pod when the machine it is on reboots or otherwise fails.
|
||||
|
||||
[**Service**](services)
|
||||
[**Service**](/{{page.version}}/docs/user-guide/services)
|
||||
: A service defines a set of pods and a means by which to access them, such as single stable IP address and corresponding DNS name.
|
||||
|
||||
[**Volume**](volumes)
|
||||
[**Volume**](/{{page.version}}/docs/user-guide/volumes)
|
||||
: A volume is a directory, possibly with some data in it, which is accessible to a Container as part of its filesystem. Kubernetes volumes build upon [Docker Volumes](https://docs.docker.com/userguide/dockervolumes/), adding provisioning of the volume directory and/or device.
|
||||
|
||||
[**Secret**](secrets)
|
||||
[**Secret**](/{{page.version}}/docs/user-guide/secrets)
|
||||
: A secret stores sensitive data, such as authentication tokens, which can be made available to containers upon request.
|
||||
|
||||
[**Name**](identifiers)
|
||||
[**Name**](/{{page.version}}/docs/user-guide/identifiers)
|
||||
: A user- or client-provided name for a resource.
|
||||
|
||||
[**Namespace**](namespaces)
|
||||
[**Namespace**](/{{page.version}}/docs/user-guide/namespaces)
|
||||
: A namespace is like a prefix to the name of a resource. Namespaces help different projects, teams, or customers to share a cluster, such as by preventing name collisions between unrelated teams.
|
||||
|
||||
[**Annotation**](annotations)
|
||||
[**Annotation**](/{{page.version}}/docs/user-guide/annotations)
|
||||
: A key/value pair that can hold larger (compared to a label), and possibly not human-readable, data, intended to store non-identifying auxiliary data, especially data manipulated by tools and system extensions. Efficient filtering by annotation values is not supported.
|
||||
|
||||
## Further reading
|
||||
|
||||
* API resources
|
||||
* [Working with resources](working-with-resources)
|
||||
* [Working with resources](/{{page.version}}/docs/user-guide/working-with-resources)
|
||||
|
||||
* Pods and containers
|
||||
* [Pod lifecycle and restart policies](pod-states)
|
||||
* [Lifecycle hooks](container-environment)
|
||||
* [Compute resources, such as cpu and memory](compute-resources)
|
||||
* [Specifying commands and requesting capabilities](containers)
|
||||
* [Downward API: accessing system configuration from a pod](downward-api)
|
||||
* [Images and registries](images)
|
||||
* [Migrating from docker-cli to kubectl](docker-cli-to-kubectl)
|
||||
* [Tips and tricks when working with config](config-best-practices)
|
||||
* [Assign pods to selected nodes](node-selection/)
|
||||
* [Perform a rolling update on a running group of pods](update-demo/)
|
||||
|
||||
|
||||
|
||||
* [Pod lifecycle and restart policies](/{{page.version}}/docs/user-guide/pod-states)
|
||||
* [Lifecycle hooks](/{{page.version}}/docs/user-guide/container-environment)
|
||||
* [Compute resources, such as cpu and memory](/{{page.version}}/docs/user-guide/compute-resources)
|
||||
* [Specifying commands and requesting capabilities](/{{page.version}}/docs/user-guide/containers)
|
||||
* [Downward API: accessing system configuration from a pod](/{{page.version}}/docs/user-guide/downward-api)
|
||||
* [Images and registries](/{{page.version}}/docs/user-guide/images)
|
||||
* [Migrating from docker-cli to kubectl](/{{page.version}}/docs/user-guide/docker-cli-to-kubectl)
|
||||
* [Tips and tricks when working with config](/{{page.version}}/docs/user-guide/config-best-practices)
|
||||
* [Assign pods to selected nodes](/{{page.version}}/docs/user-guide/node-selection/)
|
||||
* [Perform a rolling update on a running group of pods](/{{page.version}}/docs/user-guide/update-demo/)
|
||||
|
|
@ -67,7 +67,7 @@ rules:
|
|||
|
||||
*POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*
|
||||
|
||||
__Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [here](simple-yaml), [here](configuring-containers), and [here](working-with-resources).
|
||||
__Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [here](simple-yaml), [here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).
|
||||
|
||||
__Lines 5-7__: Ingress [spec](/{{page.version}}/docs/devel/api-conventions/#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
|
||||
|
||||
|
|
|
|||
|
|
@ -311,6 +311,6 @@ Learn about additional debugging tools, including:
|
|||
* [Logging](logging)
|
||||
* [Monitoring](monitoring)
|
||||
* [Getting into containers via `exec`](getting-into-containers)
|
||||
* [Connecting to containers via proxies](connecting-to-applications-proxy)
|
||||
* [Connecting to containers via port forwarding](connecting-to-applications-port-forward)
|
||||
* [Connecting to containers via proxies](/{{page.version}}/docs/user-guide/connecting-to-applications-proxy)
|
||||
* [Connecting to containers via port forwarding](/{{page.version}}/docs/user-guide/connecting-to-applications-port-forward)
|
||||
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ $ kubectl logs pi-aiw0a
|
|||
|
||||
As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields. For
|
||||
general information about working with config files, see [here](simple-yaml),
|
||||
[here](configuring-containers), and [here](working-with-resources).
|
||||
[here](/{{page.version}}/docs/user-guide/configuring-containers), and [here](working-with-resources).
|
||||
|
||||
A Job also needs a [`.spec` section](/{{page.version}}/docs/devel/api-conventions/#spec-and-status).
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ When performing an operation on multiple resources, you can specify each resourc
|
|||
* To specify multiple resource types individually: `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`<br/>
|
||||
Example: `$ kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
* To specify resources with one or more files: `-f file1 -f file2 -f file<#>`
|
||||
[Use YAML rather than JSON](config-best-practices) since YAML tends to be more user-friendly, especially for configuration files.<br/>
|
||||
[Use YAML rather than JSON](/{{page.version}}/docs/user-guide/config-best-practices) since YAML tends to be more user-friendly, especially for configuration files.<br/>
|
||||
Example: `$ kubectl get pod -f ./pod.yaml`
|
||||
* `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Each object can have a set of key/value labels defined. Each Key must be unique
|
|||
}
|
||||
```
|
||||
|
||||
We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](annotations).
|
||||
We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](/{{page.version}}/docs/user-guide/annotations).
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Kubernetes User Guide: Managing Applications: Managing deployments"
|
||||
---
|
||||
You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we'll discuss in more depth are [configuration files](configuring-containers/#configuration-in-kubernetes) and [labels](deploying-applications/#labels).
|
||||
You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features we'll discuss in more depth are [configuration files](/{{page.version}}/docs/user-guide/configuring-containers/#configuration-in-kubernetes) and [labels](deploying-applications/#labels).
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
|
@ -365,7 +365,7 @@ You can also run the [update demo](update-demo/) to see a visual representation
|
|||
|
||||
## In-place updates of resources
|
||||
|
||||
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created. For instance, you might want to add an [annotation](annotations) with a description of your object. That's easiest to do with `kubectl patch`:
|
||||
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created. For instance, you might want to add an [annotation](/{{page.version}}/docs/user-guide/annotations) with a description of your object. That's easiest to do with `kubectl patch`:
|
||||
|
||||
```shell
|
||||
$ kubectl patch rc my-nginx-v4 -p '{"metadata": {"annotations": {"description": "my frontend running nginx"}}}'
|
||||
|
|
@ -406,4 +406,4 @@ replicationcontrollers/my-nginx-v4
|
|||
## What's next?
|
||||
|
||||
- [Learn about how to use `kubectl` for application introspection and debugging.](introspection-and-debugging)
|
||||
- [Tips and tricks when working with config](config-best-practices
|
||||
- [Tips and tricks when working with config](/{{page.version}}/docs/user-guide/config-best-practices
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ In Kubernetes, all containers run inside [pods](pods). A pod can host a single c
|
|||
|
||||
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](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](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](annotations).
|
||||
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](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](/{{page.version}}/docs/user-guide/annotations).
|
||||
|
||||
Kubernetes supports a unique [networking model](/{{page.version}}/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.
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ An example flow:
|
|||
2. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" along with the grace period.
|
||||
3. Pod shows up as "Terminating" when listed in client commands
|
||||
4. (simultaneous with 3) When the Kubelet sees that a Pod has been marked as terminating because the time in 2 has been set, it begins the pod shutdown process.
|
||||
1. If the pod has defined a [preStop hook](container-environment/#hook-details), it is invoked inside of the pod. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
|
||||
1. If the pod has defined a [preStop hook](/{{page.version}}/docs/user-guide/container-environment/#hook-details), it is invoked inside of the pod. If the `preStop` hook is still running after the grace period expires, step 2 is then invoked with a small (2 second) extended grace period.
|
||||
2. The processes in the Pod are sent the TERM signal.
|
||||
5. (simultaneous with 3), Pod is removed from endpoints list for service, and are no longer considered part of the set of running pods for replication controllers. Pods that shutdown slowly can continue to serve traffic as load balancers (like the service proxy) remove them from their rotations.
|
||||
6. When the grace period expires, any processes still running in the Pod are killed with SIGKILL.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "Kubernetes User Guide: Managing Applications: Working with pods and containers in production"
|
||||
---
|
||||
You've seen [how to configure and deploy pods and containers](configuring-containers), using some of the most common configuration parameters. This section dives into additional features that are especially useful for running applications in production.
|
||||
You've seen [how to configure and deploy pods and containers](/{{page.version}}/docs/user-guide/configuring-containers), using some of the most common configuration parameters. This section dives into additional features that are especially useful for running applications in production.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
|
@ -200,7 +200,7 @@ More examples can be found in our [blog article](http://blog.kubernetes.io/2015/
|
|||
|
||||
## Resource management
|
||||
|
||||
Kubernetes's scheduler will place applications only where they have adequate CPU and memory, but it can only do so if it knows how much [resources they require](compute-resources). The consequence of specifying too little CPU is that the containers could be starved of CPU if too many other containers were scheduled onto the same node. Similarly, containers could die unpredictably due to running out of memory if no memory were requested, which can be especially likely for large-memory applications.
|
||||
Kubernetes's scheduler will place applications only where they have adequate CPU and memory, but it can only do so if it knows how much [resources they require](/{{page.version}}/docs/user-guide/compute-resources). The consequence of specifying too little CPU is that the containers could be starved of CPU if too many other containers were scheduled onto the same node. Similarly, containers could die unpredictably due to running out of memory if no memory were requested, which can be especially likely for large-memory applications.
|
||||
|
||||
If no resource requirements are specified, a nominal amount of resources is assumed. (This default is applied via a [LimitRange](/{{page.version}}/docs/admin/limitrange/) for the default [Namespace](namespaces). It can be viewed with `kubectl describe limitrange limits`.) You may explicitly specify the amount of resources required as follows:
|
||||
|
||||
|
|
@ -270,7 +270,7 @@ spec:
|
|||
timeoutSeconds: 1
|
||||
```
|
||||
|
||||
Other times, applications are only temporarily unable to serve, and will recover on their own. Typically in such cases you'd prefer not to kill the application, but don't want to send it requests, either, since the application won't respond correctly or at all. A common such scenario is loading large data or configuration files during application startup. Kubernetes provides *readiness probes* to detect and mitigate such situations. Readiness probes are configured similarly to liveness probes, just using the `readinessProbe` field. A pod with containers reporting that they are not ready will not receive traffic through Kubernetes [services](connecting-applications).
|
||||
Other times, applications are only temporarily unable to serve, and will recover on their own. Typically in such cases you'd prefer not to kill the application, but don't want to send it requests, either, since the application won't respond correctly or at all. A common such scenario is loading large data or configuration files during application startup. Kubernetes provides *readiness probes* to detect and mitigate such situations. Readiness probes are configured similarly to liveness probes, just using the `readinessProbe` field. A pod with containers reporting that they are not ready will not receive traffic through Kubernetes [services](/{{page.version}}/docs/user-guide/connecting-applications).
|
||||
|
||||
For more details (e.g., how to specify command-based probes), see the [example in the walkthrough](walkthrough/k8s201/#health-checking), the [standalone example](liveness/), and the [documentation](pod-states/#container-probes).
|
||||
|
||||
|
|
@ -279,7 +279,7 @@ For more details (e.g., how to specify command-based probes), see the [example i
|
|||
Of course, nodes and applications may fail at any time, but many applications benefit from clean shutdown, such as to complete in-flight requests, when the termination of the application is deliberate. To support such cases, Kubernetes supports two kinds of notifications:
|
||||
|
||||
* Kubernetes will send SIGTERM to applications, which can be handled in order to effect graceful termination. SIGKILL is sent a configurable number of seconds later if the application does not terminate sooner (defaults to 30 seconds, controlled by `spec.terminationGracePeriodSeconds`).
|
||||
* Kubernetes supports the (optional) specification of a [*pre-stop lifecycle hook*](container-environment/#container-hooks), which will execute prior to sending SIGTERM.
|
||||
* Kubernetes supports the (optional) specification of a [*pre-stop lifecycle hook*](/{{page.version}}/docs/user-guide/container-environment/#container-hooks), which will execute prior to sending SIGTERM.
|
||||
|
||||
The specification of a pre-stop hook is similar to that of probes, but without the timing-related parameters. For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -63,4 +63,4 @@ services/my-nginx
|
|||
|
||||
## What's next?
|
||||
|
||||
[Learn about how to configure common container parameters, such as commands and environment variables.](configuring-containers)
|
||||
[Learn about how to configure common container parameters, such as commands and environment variables.](/{{page.version}}/docs/user-guide/configuring-containers)
|
||||
|
|
@ -27,7 +27,7 @@ pods/podname -o yaml`), you can see the `spec.serviceAccount` field has been
|
|||
[automatically set](working-with-resources/#resources-are-automatically-modified).
|
||||
|
||||
You can access the API using a proxy or with a client library, as described in
|
||||
[Accessing the Cluster](accessing-the-cluster/#accessing-the-api-from-a-pod).
|
||||
[Accessing the Cluster](/{{page.version}}/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
|
||||
|
||||
## Using Multiple Service Accounts.
|
||||
|
||||
|
|
|
|||
|
|
@ -373,6 +373,6 @@ medium of the filesystem holding the kubelet root dir (typically
|
|||
pods.
|
||||
|
||||
In the future, we expect that `emptyDir` and `hostPath` volumes will be able to
|
||||
request a certain amount of space using a [resource](compute-resources)
|
||||
request a certain amount of space using a [resource](/{{page.version}}/docs/user-guide/compute-resources)
|
||||
specification, and to select the type of media to use, for clusters that have
|
||||
several media types.
|
||||
Loading…
Reference in New Issue