standardize on - instead of _ in file names
This commit is contained in:
Daniel Smith
parent
2c333e4bc2
commit
b1555956e9
@ -110,7 +110,7 @@ certificate.
|
||||
|
||||
On some clusters, the apiserver does not require authentication; it may serve
|
||||
on localhost, or be protected by a firewall. There is not a standard
|
||||
for this. [Configuring Access to the API](accessing_the_api.md)
|
||||
for this. [Configuring Access to the API](admin/accessing-the-api.md)
|
||||
describes how a cluster admin can configure this. Such approaches may conflict
|
||||
with future high-availability support.
|
||||
|
||||
@ -134,7 +134,7 @@ the `kubernetes` DNS name, which resolves to a Service IP which in turn
|
||||
will be routed to an apiserver.
|
||||
|
||||
The recommended way to authenticate to the apiserver is with a
|
||||
[service account](service_accounts.md) credential. By default, a pod
|
||||
[service account](service-accounts.md) credential. By default, a pod
|
||||
is associated with a service account, and a credential (token) for that
|
||||
service account is placed into the filesystem tree of each container in that pod,
|
||||
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
|
||||
@ -153,7 +153,7 @@ In each case, the credentials of the pod are used to communicate securely with t
|
||||
## Accessing services running on the cluster
|
||||
The previous section was about connecting the Kubernetes API server. This section is about
|
||||
connecting to other services running on Kubernetes cluster. In kubernetes, the
|
||||
[nodes](node.md), [pods](pods.md) and [services](services.md) all have
|
||||
[nodes](admin/node.md), [pods](pods.md) and [services](services.md) all have
|
||||
their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
|
||||
routable, so they will not be reachable from a machine outside the cluster,
|
||||
such as your desktop machine.
|
||||
|
||||
@ -15,12 +15,12 @@ certainly want the docs that go with that version.</h1>
|
||||
# Kubernetes Cluster Admin Guide
|
||||
|
||||
The cluster admin guide is for anyone creating or administering a Kubernetes cluster.
|
||||
It assumes some familiarity with concepts in the [User Guide](user-guide.md).
|
||||
It assumes some familiarity with concepts in the [User Guide](../user-guide.md).
|
||||
|
||||
## Planning a cluster
|
||||
|
||||
There are many different examples of how to setup a kubernetes cluster. Many of them are listed in this
|
||||
[matrix](getting-started-guides/README.md). We call each of the combinations in this matrix a *distro*.
|
||||
[matrix](../getting-started-guides/README.md). We call each of the combinations in this matrix a *distro*.
|
||||
|
||||
Before choosing a particular guide, here are some things to consider:
|
||||
- Are you just looking to try out Kubernetes on your laptop, or build a high-availability many-node cluster? Both
|
||||
@ -41,7 +41,7 @@ Before choosing a particular guide, here are some things to consider:
|
||||
|
||||
## Setting up a cluster
|
||||
|
||||
Pick one of the Getting Started Guides from the [matrix](getting-started-guides/README.md) and follow it.
|
||||
Pick one of the Getting Started Guides from the [matrix](../getting-started-guides/README.md) 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.md)), which
|
||||
@ -52,7 +52,7 @@ If you are modifying an existing guide which uses Salt, this document explains [
|
||||
project.](salt.md).
|
||||
|
||||
## Upgrading a cluster
|
||||
[Upgrading a cluster](cluster_management.md).
|
||||
[Upgrading a cluster](cluster-management.md).
|
||||
|
||||
## Managing nodes
|
||||
|
||||
@ -63,30 +63,30 @@ project.](salt.md).
|
||||
* **DNS Integration with SkyDNS** ([dns.md](dns.md)):
|
||||
Resolving a DNS name directly to a Kubernetes service.
|
||||
|
||||
* **Logging** with [Kibana](logging.md)
|
||||
* **Logging** with [Kibana](../logging.md)
|
||||
|
||||
## Multi-tenant support
|
||||
|
||||
* **Namespaces** ([namespaces.md](namespaces.md)): Namespaces help different
|
||||
projects, teams, or customers to share a kubernetes cluster.
|
||||
|
||||
* **Resource Quota** ([resource_quota_admin.md](resource_quota_admin.md))
|
||||
* **Resource Quota** ([resource-quota.md](resource-quota.md))
|
||||
|
||||
## Security
|
||||
|
||||
* **Kubernetes Container Environment** ([container-environment.md](container-environment.md)):
|
||||
* **Kubernetes Container Environment** ([docs/container-environment.md](../container-environment.md)):
|
||||
Describes the environment for Kubelet managed containers on a Kubernetes
|
||||
node.
|
||||
|
||||
* **Securing access to the API Server** [accessing the api](accessing_the_api.md)
|
||||
* **Securing access to the API Server** [accessing the api](accessing-the-api.md)
|
||||
|
||||
* **Authentication** [authentication](authentication.md)
|
||||
|
||||
* **Authorization** [authorization](authorization.md)
|
||||
|
||||
* **Admission Controllers** [admission_controllers](admission_controllers.md)
|
||||
* **Admission Controllers** [admission_controllers](admission-controllers.md)
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -20,7 +20,7 @@ cluster administrators who want to customize their cluster
|
||||
or understand the details.
|
||||
|
||||
Most questions about accessing the cluster are covered
|
||||
in [Accessing the cluster](accessing-the-cluster.md).
|
||||
in [Accessing the cluster](../accessing-the-cluster.md).
|
||||
|
||||
|
||||
## Ports and IPs Served On
|
||||
@ -90,5 +90,5 @@ variety of uses cases:
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -81,12 +81,12 @@ commands in those containers, we strongly encourage enabling this plug-in.
|
||||
|
||||
### ServiceAccount
|
||||
|
||||
This plug-in implements automation for [serviceAccounts](service_accounts.md).
|
||||
This plug-in implements automation for [serviceAccounts](../service-accounts.md).
|
||||
We strongly recommend using this plug-in if you intend to make use of Kubernetes ```ServiceAccount``` objects.
|
||||
|
||||
### SecurityContextDeny
|
||||
|
||||
This plug-in will deny any pod with a [SecurityContext](security_context.md) that defines options that were not available on the ```Container```.
|
||||
This plug-in will deny any pod with a [SecurityContext](../security-context.md) that defines options that were not available on the ```Container```.
|
||||
|
||||
### ResourceQuota
|
||||
|
||||
@ -94,7 +94,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
|
||||
enumerated in the ```ResourceQuota``` object in a ```Namespace```. If you are using ```ResourceQuota```
|
||||
objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.
|
||||
|
||||
See the [resourceQuota design doc](design/admission_control_resource_quota.md).
|
||||
See the [resourceQuota design doc](../design/admission_control_resource_quota.md).
|
||||
|
||||
It is strongly encouraged that this plug-in is configured last in the sequence of admission control plug-ins. This is
|
||||
so that quota is not prematurely incremented only for the request to be rejected later in admission control.
|
||||
@ -105,7 +105,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
|
||||
enumerated in the ```LimitRange``` object in a ```Namespace```. If you are using ```LimitRange``` objects in
|
||||
your Kubernetes deployment, you MUST use this plug-in to enforce those constraints.
|
||||
|
||||
See the [limitRange design doc](design/admission_control_limit_range.md).
|
||||
See the [limitRange design doc](../design/admission_control_limit_range.md).
|
||||
|
||||
### NamespaceExists
|
||||
|
||||
@ -142,5 +142,5 @@ For Kubernetes 1.0, we strongly recommend running the following set of admission
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -55,5 +55,5 @@ github.com, google.com, enterprise directory, kerberos, etc.)
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -94,7 +94,7 @@ To permit an action Policy with an unset namespace applies regardless of namespa
|
||||
3. Kubelet can read and write events: `{"user":"kubelet", "resource": "events"}`
|
||||
4. Bob can just read pods in namespace "projectCaribou": `{"user":"bob", "resource": "pods", "readonly": true, "ns": "projectCaribou"}`
|
||||
|
||||
[Complete file example](../pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
[Complete file example](../../pkg/auth/authorizer/abac/example_policy_file.jsonl)
|
||||
|
||||
## Plugin Development
|
||||
|
||||
@ -118,5 +118,5 @@ caching and revocation of permissions.
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -134,7 +134,7 @@ you need `R + U` clusters. If it is not (e.g you want to ensure low latency for
|
||||
cluster failure), then you need to have `R * U` clusters (`U` in each of `R` regions). In any case, try to put each cluster in a different zone.
|
||||
|
||||
Finally, if any of your clusters would need more than the maximum recommended number of nodes for a Kubernetes cluster, then
|
||||
you may need even more clusters. Our [roadmap](roadmap.md)
|
||||
you may need even more clusters. Our [roadmap](../roadmap.md)
|
||||
calls for maximum 100 node clusters at v1.0 and maximum 1000 node clusters in the middle of 2015.
|
||||
|
||||
## Working with multiple clusters
|
||||
@ -145,5 +145,5 @@ failures of a single cluster are not visible to end users.
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -74,5 +74,5 @@ If you want more control over the upgrading process, you may use the following w
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -14,7 +14,7 @@ certainly want the docs that go with that version.</h1>
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# DNS Integration with Kubernetes
|
||||
|
||||
As of kubernetes 0.8, DNS is offered as a [cluster add-on](../cluster/addons/README.md).
|
||||
As of kubernetes 0.8, DNS is offered as a [cluster add-on](../../cluster/addons/README.md).
|
||||
If enabled, a DNS Pod and Service will be scheduled on the cluster, and the kubelets will be
|
||||
configured to tell individual containers to use the DNS Service's IP.
|
||||
|
||||
@ -49,9 +49,9 @@ time.
|
||||
|
||||
## For more information
|
||||
|
||||
See [the docs for the DNS cluster addon](../cluster/addons/dns/README.md).
|
||||
See [the docs for the DNS cluster addon](../../cluster/addons/dns/README.md).
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -1,3 +1,17 @@
|
||||
<!-- BEGIN MUNGE: UNVERSIONED_WARNING -->
|
||||
|
||||
<!-- BEGIN STRIP_FOR_RELEASE -->
|
||||
|
||||
<h1>*** PLEASE NOTE: This document applies to the HEAD of the source
|
||||
tree only. If you are using a released version of Kubernetes, you almost
|
||||
certainly want the docs that go with that version.</h1>
|
||||
|
||||
<strong>Documentation for specific releases can be found at
|
||||
[releases.k8s.io](http://releases.k8s.io).</strong>
|
||||
|
||||
<!-- END STRIP_FOR_RELEASE -->
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Namespaces
|
||||
|
||||
Namespaces help different projects, teams, or customers to share a kubernetes cluster. First, they provide a scope for [Names](../identifiers.md). Second, as our access control code develops, it is expected that it will be convenient to attach authorization and other policy to namespaces.
|
||||
@ -12,4 +26,6 @@ policy creation, interaction with network.
|
||||
Namespaces are still under development. For now, the best documentation is the [Namespaces Design Document](../design/namespaces.md). The user documentation can be found at [Namespaces](../../docs/namespaces.md)
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -34,10 +34,10 @@ certainly want the docs that go with that version.</h1>
|
||||
Kubernetes approaches networking somewhat differently than Docker does by
|
||||
default. There are 4 distinct networking problems to solve:
|
||||
1. Highly-coupled container-to-container communications: this is solved by
|
||||
[pods](pods.md) and `localhost` communications.
|
||||
[pods](../pods.md) and `localhost` communications.
|
||||
2. Pod-to-Pod communications: this is the primary focus of this document.
|
||||
3. Pod-to-Service communications: this is covered by [services](services.md).
|
||||
4. External-to-Service communications: this is covered by [services](services.md).
|
||||
3. Pod-to-Service communications: this is covered by [services](../services.md).
|
||||
4. External-to-Service communications: this is covered by [services](../services.md).
|
||||
|
||||
## Summary
|
||||
|
||||
@ -204,9 +204,9 @@ IPs.
|
||||
|
||||
The early design of the networking model and its rationale, and some future
|
||||
plans are described in more detail in the [networking design
|
||||
document](design/networking.md).
|
||||
document](../design/networking.md).
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -36,9 +36,9 @@ certainly want the docs that go with that version.</h1>
|
||||
|
||||
`Node` is a worker machine in Kubernetes, previously known as `Minion`. Node
|
||||
may be a VM or physical machine, depending on the cluster. Each node has
|
||||
the services necessary to run [Pods](pods.md) and be managed from the master
|
||||
the services necessary to run [Pods](../pods.md) and be managed from the master
|
||||
systems. The services include docker, kubelet and network proxy. See
|
||||
[The Kubernetes Node](design/architecture.md#the-kubernetes-node) section in design
|
||||
[The Kubernetes Node](../design/architecture.md#the-kubernetes-node) section in design
|
||||
doc for more details.
|
||||
|
||||
## Node Status
|
||||
@ -101,7 +101,7 @@ The information is gathered by Kubernetes from the node.
|
||||
|
||||
## Node Management
|
||||
|
||||
Unlike [Pods](pods.md) and [Services](services.md), a Node is not inherently
|
||||
Unlike [Pods](../pods.md) and [Services](../services.md), a Node is not inherently
|
||||
created by Kubernetes: it is either created from cloud providers like Google Compute Engine,
|
||||
or from your physical or virtual machines. What this means is that when
|
||||
Kubernetes creates a node, it only creates a representation for the node.
|
||||
@ -216,5 +216,5 @@ on each kubelet where you want to reserve resources.
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -29,5 +29,5 @@ Routing rules enable any 10.244.0.0/16 target to become reachable via the OVS br
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -116,5 +116,5 @@ hard limits of each namespace.
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -109,9 +109,9 @@ We should define a grains.conf key that captures more specifically what network
|
||||
|
||||
## Further reading
|
||||
|
||||
The [cluster/saltbase](../cluster/saltbase/) tree has more details on the current SaltStack configuration.
|
||||
The [cluster/saltbase](../../cluster/saltbase/) tree has more details on the current SaltStack configuration.
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -15,7 +15,7 @@ certainly want the docs that go with that version.</h1>
|
||||
# Cluster Admin Guide to Service Accounts
|
||||
|
||||
*This is a Cluster Administrator guide to service accounts. It assumes knowledge of
|
||||
the [User Guide to Service Accounts](service_accounts.md).*
|
||||
the [User Guide to Service Accounts](../service-accounts.md).*
|
||||
|
||||
*Support for authorization and user accounts is planned but incomplete. Sometimes
|
||||
incomplete features are referred to in order to better describe service accounts.*
|
||||
@ -49,7 +49,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](admin/admission-controllers.md). It is part of the apiserver.
|
||||
called an [Admission Controller](admission-controllers.md). 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:
|
||||
1. If the pod does not have a `ServiceAccount` set, it sets the `ServiceAccount` to `default`.
|
||||
@ -97,5 +97,5 @@ kubectl delete secret mysecretname
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
@ -58,7 +58,7 @@ Changes to services are the most significant difference between v1beta3 and v1.
|
||||
|
||||
Some other difference between v1beta3 and v1:
|
||||
|
||||
* The `pod.spec.containers[*].privileged` and `pod.spec.containers[*].capabilities` properties are now nested under the `pod.spec.containers[*].securityContext` property. See [Security Contexts](security_context.md).
|
||||
* The `pod.spec.containers[*].privileged` and `pod.spec.containers[*].capabilities` properties are now nested under the `pod.spec.containers[*].securityContext` property. See [Security Contexts](security-context.md).
|
||||
* The `pod.spec.host` property is renamed to `pod.spec.nodeName`.
|
||||
* The `endpoints.subsets[*].addresses.IP` property is renamed to `endpoints.subsets[*].addresses.ip`.
|
||||
* The `pod.status.containerStatuses[*].state.termination` and `pod.status.containerStatuses[*].lastState.termination` properties are renamed to `pod.status.containerStatuses[*].state.terminated` and `pod.status.containerStatuses[*].lastState.terminated` respectively.
|
||||
@ -79,7 +79,7 @@ Some important differences between v1beta1/2 and v1beta3:
|
||||
* The `labels` query parameter has been renamed to `labelSelector`.
|
||||
* The `fields` query parameter has been renamed to `fieldSelector`.
|
||||
* The container `entrypoint` has been renamed to `command`, and `command` has been renamed to `args`.
|
||||
* Container, volume, and node resources are expressed as nested maps (e.g., `resources{cpu:1}`) rather than as individual fields, and resource values support [scaling suffixes](compute_resources.md#specifying-resource-quantities) rather than fixed scales (e.g., milli-cores).
|
||||
* Container, volume, and node resources are expressed as nested maps (e.g., `resources{cpu:1}`) rather than as individual fields, and resource values support [scaling suffixes](compute-resources.md#specifying-resource-quantities) rather than fixed scales (e.g., milli-cores).
|
||||
* Restart policy is represented simply as a string (e.g., `"Always"`) rather than as a nested map (`always{}`).
|
||||
* Pull policies changed from `PullAlways`, `PullNever`, and `PullIfNotPresent` to `Always`, `Never`, and `IfNotPresent`.
|
||||
* The volume `source` is inlined into `volume` rather than nested.
|
||||
|
||||
@ -68,7 +68,7 @@ To avoid running into cluster addon resource issues, when creating a cluster wit
|
||||
* [FluentD with ElasticSearch Plugin](../cluster/saltbase/salt/fluentd-es/fluentd-es.yaml)
|
||||
* [FluentD with GCP Plugin](../cluster/saltbase/salt/fluentd-gcp/fluentd-gcp.yaml)
|
||||
|
||||
For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](compute_resources.md#troubleshooting).
|
||||
For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](compute-resources.md#troubleshooting).
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -34,7 +34,7 @@ in units of cores. Memory is specified in units of bytes.
|
||||
|
||||
CPU and RAM are collectively referred to as *compute resources*, or just *resources*. Compute
|
||||
resources are measureable quantities which can be requested, allocated, and consumed. They are
|
||||
distinct from [API resources](working_with_resources.md). API resources, such as pods and
|
||||
distinct from [API resources](working-with-resources.md). API resources, such as pods and
|
||||
[services](services.md) are objects that can be written to and retrieved from the Kubernetes API
|
||||
server.
|
||||
|
||||
@ -223,5 +223,5 @@ across providers and platforms.
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
@ -13,7 +13,7 @@ certainly want the docs that go with that version.</h1>
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
**Note: this is a design doc, which describes features that have not been completely implemented.
|
||||
User documentation of the current state is [here](../compute_resources.md). The tracking issue for
|
||||
User documentation of the current state is [here](../compute-resources.md). The tracking issue for
|
||||
implementation of this model is
|
||||
[#168](https://github.com/GoogleCloudPlatform/kubernetes/issues/168). Currently, only memory and
|
||||
cpu limits on containers (not pods) are supported. "memory" is in bytes and "cpu" is in
|
||||
|
||||
@ -89,5 +89,5 @@ Some more thorough examples:
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
@ -25,7 +25,7 @@ You need two machines with CentOS installed on them.
|
||||
## Starting a cluster
|
||||
This is a getting started guide for CentOS. It is a manual configuration so you understand all the underlying packages / services / ports, etc...
|
||||
|
||||
This guide will only get ONE node working. Multiple nodes requires a functional [networking configuration](../../networking.md) done outside of kubernetes. Although the additional kubernetes configuration requirements should be obvious.
|
||||
This guide will only get ONE node working. Multiple nodes requires a functional [networking configuration](../../admin/networking.md) done outside of kubernetes. Although the additional kubernetes configuration requirements should be obvious.
|
||||
|
||||
The kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, centos-master, will be the kubernetes master. This host will run the kube-apiserver, kube-controller-manager, and kube-scheduler. In addition, the master will also run _etcd_. The remaining host, centos-minion will be the node and run kubelet, proxy, cadvisor and docker.
|
||||
|
||||
|
||||
@ -663,7 +663,7 @@ Flags to consider using with controller manager.
|
||||
- `--allocate-node-cidrs=`
|
||||
- *TODO*: explain when you want controller to do this and when you wanna do it another way.
|
||||
- `--cloud-provider=` and `--cloud-config` as described in apiserver section.
|
||||
- `--service-account-private-key-file=/srv/kubernetes/server.key`, used by [service account](../service_accounts.md) feature.
|
||||
- `--service-account-private-key-file=/srv/kubernetes/server.key`, used by [service account](../service-accounts.md) feature.
|
||||
- `--master=127.0.0.1:8080`
|
||||
|
||||
Template for controller manager pod:
|
||||
|
||||
@ -47,7 +47,7 @@ can be created/destroyed together. See [pods](pods.md).
|
||||
for easy scaling of replicated systems, and handles restarting of a Pod when the machine it is on reboots or otherwise fails.
|
||||
|
||||
**Resource**
|
||||
: CPU, memory, and other things that a pod can request. See [compute resources](compute_resources.md).
|
||||
: CPU, memory, and other things that a pod can request. See [compute resources](compute-resources.md).
|
||||
|
||||
**Secret**
|
||||
: An object containing sensitive information, such as authentication tokens, which can be made available to containers upon request. See [secrets](secrets.md).
|
||||
|
||||
@ -215,7 +215,7 @@ spec:
|
||||
```
|
||||
This needs to be done for each pod that is using a private registry.
|
||||
However, setting of this field can be automated by setting the imagePullSecrets
|
||||
in a [serviceAccount](service_accounts.md) resource.
|
||||
in a [serviceAccount](service-accounts.md) resource.
|
||||
|
||||
Currently, all pods will potentially have read access to any images which were
|
||||
pulled using imagePullSecrets. That is, imagePullSecrets does *NOT* protect your
|
||||
|
||||
@ -66,7 +66,7 @@ The automatic creation and use of API credentials can be disabled or overridden
|
||||
if desired. However, if all you need to do is securely access the apiserver,
|
||||
this is the recommended workflow.
|
||||
|
||||
See the [Service Account](service_accounts.md) documentation for more
|
||||
See the [Service Account](service-accounts.md) documentation for more
|
||||
information on how Service Accounts work.
|
||||
|
||||
### Creating a Secret Manually
|
||||
@ -92,7 +92,7 @@ are `value-1` and `value-2`, respectively, with carriage return and newline char
|
||||
Create the secret using [`kubectl create`](user-guide/kubectl/kubectl_create.md).
|
||||
|
||||
Once the secret is created, you can:
|
||||
- create pods that automatically use it via a [Service Account](service_accounts.md).
|
||||
- create pods that automatically use it via a [Service Account](service-accounts.md).
|
||||
- modify your pod specification to use the secret
|
||||
|
||||
### Manually specifying a Secret to be Mounted on a Pod
|
||||
@ -141,7 +141,7 @@ Use of imagePullSecrets is desribed in the [images documentation](images.md#spec
|
||||
*This feature is planned but not implemented. See [issue
|
||||
9902](https://github.com/GoogleCloudPlatform/kubernetes/issues/9902).*
|
||||
|
||||
You can reference manually created secrets from a [service account](service_accounts.md).
|
||||
You can reference manually created secrets from a [service account](service-accounts.md).
|
||||
Then, pods which use that service account will have
|
||||
`volumeMounts` and/or `imagePullSecrets` added to them.
|
||||
The secrets will be mounted at **TBD**.
|
||||
|
||||
@ -18,5 +18,5 @@ A security context defines the operating system security settings (uid, gid, cap
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
@ -17,7 +17,7 @@ certainly want the docs that go with that version.</h1>
|
||||
A service account provides an identity for processes that run in a Pod.
|
||||
|
||||
*This is a user introduction to Service Accounts. See also the
|
||||
[Cluster Admin Guide to Service Accounts](service_accounts_admin.md).*
|
||||
[Cluster Admin Guide to Service Accounts](admin/service-accounts-admin.md).*
|
||||
|
||||
*Note: This document describes how service accounts behave in a cluster set up
|
||||
as recommended by the Kubernetes project. Your cluster administrator may have
|
||||
@ -37,7 +37,7 @@ When you create a pod, you do not need to specify a service account. It is
|
||||
automatically assigned the `default` service account of the same namespace. If
|
||||
you get the raw json or yaml for a pod you have created (e.g. `kubectl get
|
||||
pods/podname -o yaml`), you can see the `spec.serviceAccount` field has been
|
||||
[automatically set](working_with_resources.md#resources-are-automatically-modified).
|
||||
[automatically set](working-with-resources.md#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.md#accessing-the-api-from-a-pod).
|
||||
@ -105,5 +105,5 @@ TODO explain:
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
Before Width: | Height: | Size: 67 KiB After Width: | Height: | Size: 67 KiB |
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
@ -193,7 +193,7 @@ The net result is that any traffic bound for the `Service` is proxied to an
|
||||
appropriate backend without the clients knowing anything about Kubernetes or
|
||||
`Services` or `Pods`.
|
||||
|
||||
|
||||
|
||||
|
||||
By default, the choice of backend is random. Client-IP based session affinity
|
||||
can be selected by setting `service.spec.sessionAffinity` to `"ClientIP"` (the
|
||||
@ -504,7 +504,7 @@ This means that `Service` owners can choose any port they want without risk of
|
||||
collision. Clients can simply connect to an IP and port, without being aware
|
||||
of which `Pods` they are actually accessing.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@ -81,13 +81,13 @@ for i in *.md; do grep -r $i . | grep -v "^\./$i" > /dev/null; rv=$?; if [[ $rv
|
||||
* **Annotations** ([annotations.md](annotations.md)): Attaching
|
||||
arbitrary non-identifying metadata.
|
||||
|
||||
* **Downward API** ([downward_api.md](downward_api.md)): Accessing system
|
||||
* **Downward API** ([downward-api.md](downward-api.md)): Accessing system
|
||||
configuration from a pod without accessing Kubernetes API (see also
|
||||
[container-environment.md](container-environment.md)).
|
||||
|
||||
* **Kubernetes Container Environment** ([container-environment.md](container-environment.md)):
|
||||
Describes the environment for Kubelet managed containers on a Kubernetes
|
||||
node (see also [downward_api.md](downward_api.md)).
|
||||
node (see also [downward-api.md](downward-api.md)).
|
||||
|
||||
* **DNS Integration with SkyDNS** ([admin/dns.md](admin/dns.md)):
|
||||
Resolving a DNS name directly to a Kubernetes service.
|
||||
@ -108,7 +108,7 @@ for i in *.md; do grep -r $i . | grep -v "^\./$i" > /dev/null; rv=$?; if [[ $rv
|
||||
* **Services and firewalls** ([services-firewalls.md](services-firewalls.md)): How
|
||||
to use firewalls.
|
||||
|
||||
* **Compute Resources** ([compute_resources.md](compute_resources.md)):
|
||||
* **Compute Resources** ([compute-resources.md](compute-resources.md)):
|
||||
Provides resource information such as size, type, and quantity to assist in
|
||||
assigning Kubernetes resources appropriately.
|
||||
|
||||
|
||||
@ -72,7 +72,7 @@ $ kubectl get pods -l app=nginx -o json | grep podIP
|
||||
```
|
||||
You should be able to ssh into any node in your cluster and curl both ips. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using ip. Like Docker, ports can still be published to the host node's interface(s), but the need for this is radically diminished because of the networking model.
|
||||
|
||||
You can read more about [how we achieve this](../networking.md#how-to-achieve-this) if you’re curious.
|
||||
You can read more about [how we achieve this](../admin/networking.md#how-to-achieve-this) if you’re curious.
|
||||
|
||||
## Creating a Service for the pods
|
||||
|
||||
|
||||
@ -370,7 +370,7 @@ 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.md)
|
||||
request a certain amount of space using a [resource](compute-resources.md)
|
||||
specification, and to select the type of media to use, for clusters that have
|
||||
several media types.
|
||||
|
||||
|
||||
@ -72,5 +72,5 @@ Once there:
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
@ -82,7 +82,7 @@ Backend Namespace: default
|
||||
|
||||
First the frontend pod's information is printed. The pod name and
|
||||
[namespace](../../docs/design/namespaces.md) are retreived from the
|
||||
[Downward API](../../docs/downward_api.md). Next, `USER_VAR` is the name of
|
||||
[Downward API](../../docs/downward-api.md). Next, `USER_VAR` is the name of
|
||||
an environment variable set in the [pod
|
||||
definition](show-rc.yaml). Then, the dynamic kubernetes environment
|
||||
variables are scanned and printed. These are used to find the backend
|
||||
|
||||
Loading…
Reference in New Issue
Block a user