Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7
* 'master' of https://github.com/kubernetes/kubernetes.github.io: Update links to proper repos # Conflicts: # docs/admin/kubeadm.md # docs/concepts/overview/kubernetes-api.md # docs/reference/api-overview.md # docs/setup/independent/create-cluster-kubeadm.md # docs/tasks/administer-cluster/configure-pod-disruption-budget.md
This commit is contained in:
Andrew Chen
@@ -124,7 +124,7 @@ Kubernetes supports [Go](#go-client) and [Python](#python-client) client librari
|
||||
* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
|
||||
|
||||
The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes/client-go/blob/master/examples/out-of-cluster/main.go):
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster/main.go):
|
||||
|
||||
```golang
|
||||
import (
|
||||
@@ -167,7 +167,7 @@ for i in ret.items:
|
||||
|
||||
#### Other languages
|
||||
|
||||
There are [client libraries](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
|
||||
There are [client libraries](https://git.k8s.io/community/contributors/devel/client-libraries.md) for accessing the API from other languages. See documentation for other libraries for how they authenticate.
|
||||
|
||||
### Accessing the API from a Pod
|
||||
|
||||
@@ -199,7 +199,7 @@ From within a pod the recommended ways to connect to API are:
|
||||
in any container of the pod can access it. See this [example of using kubectl proxy
|
||||
in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
|
||||
- use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
|
||||
They handle locating and authenticating to the apiserver. [example](https://github.com/kubernetes/client-go/blob/master/examples/in-cluster/main.go)
|
||||
They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster/main.go)
|
||||
|
||||
In each case, the credentials of the pod are used to communicate securely with the apiserver.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ To install Kubernetes on a set of machines, consult one of the existing [Getting
|
||||
|
||||
## Upgrading a cluster
|
||||
|
||||
The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md), as well as the version specific upgrade notes prior to upgrading their clusters.
|
||||
The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG.md), as well as the version specific upgrade notes prior to upgrading their clusters.
|
||||
|
||||
* [Upgrading to 1.6](/docs/admin/upgrade-1-6)
|
||||
|
||||
|
||||
@@ -247,7 +247,7 @@ it is enough to start etcd in 2.2.z version, wait until it is healthy, stop it,
|
||||
|
||||
Versions 3.0+ of etcd do not support general rollback. That is,
|
||||
after migrating from M.N to M.N+1, there is no way to go back to M.N.
|
||||
The etcd team has provided a [custom rollback tool](https://github.com/kubernetes/kubernetes/tree/master/cluster/images/etcd/rollback)
|
||||
The etcd team has provided a [custom rollback tool](https://git.k8s.io/kubernetes/cluster/images/etcd/rollback)
|
||||
but the rollback tool has these limitations:
|
||||
|
||||
* This custom rollback tool is not part of the etcd repo and does not receive the same
|
||||
|
||||
@@ -227,7 +227,7 @@ constrain the amount of resource a pod consumes on a node.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
* See [LimitRange design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/admission_control_limit_range.md) for more information.
|
||||
* See [LimitRange design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md) for more information.
|
||||
* See [Resources](/docs/concepts/configuration/manage-compute-resources-container/) for a detailed description of the Kubernetes resource model.
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
@@ -179,7 +179,7 @@ The output is:
|
||||
### Option 3: Delete the kube-dns-autoscaler manifest file from the master node
|
||||
|
||||
This option works if kube-dns-autoscaler is under control of the
|
||||
[Addon Manager](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/README.md)'s
|
||||
[Addon Manager](https://git.k8s.io/kubernetes/cluster/addons/README.md)'s
|
||||
control, and you have write access to the master node.
|
||||
|
||||
Sign in to the master node and delete the corresponding manifest file.
|
||||
|
||||
@@ -34,7 +34,7 @@ the rescheduler tries to free up space for the add-on by evicting some pods; the
|
||||
|
||||
To avoid situation when another pod is scheduled into the space prepared for the critical add-on,
|
||||
the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s)
|
||||
(see [more details](https://github.com/kubernetes/kubernetes/blob/master/docs/design/taint-toleration-dedicated.md)).
|
||||
(see [more details](https://git.k8s.io/community/contributors/design-proposals/taint-toleration-dedicated.md)).
|
||||
Each critical add-on has to tolerate it,
|
||||
while the other pods shouldn't tolerate the taint. The taint is removed once the add-on is successfully scheduled.
|
||||
|
||||
@@ -44,7 +44,7 @@ killed for this purpose.
|
||||
|
||||
## Config
|
||||
|
||||
Rescheduler should be [enabled by default as a static pod](https://github.com/kubernetes/kubernetes/blob/master/cluster/saltbase/salt/rescheduler/rescheduler.manifest).
|
||||
Rescheduler should be [enabled by default as a static pod](https://git.k8s.io/kubernetes/cluster/saltbase/salt/rescheduler/rescheduler.manifest).
|
||||
It doesn't have any user facing configuration (component config) or API and can be disabled:
|
||||
|
||||
* during cluster setup by setting `ENABLE_RESCHEDULER` flag to `false`
|
||||
|
||||
@@ -157,5 +157,5 @@ To make such deployment secure, communication between etcd instances is authoriz
|
||||
|
||||
## Additional reading
|
||||
|
||||
[Automated HA master deployment - design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/ha_master.md)
|
||||
[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/ha_master.md)
|
||||
|
||||
|
||||
@@ -87,14 +87,14 @@ to define *Hard* resource usage limits that a *Namespace* may consume.
|
||||
A limit range defines min/max constraints on the amount of resources a single entity can consume in
|
||||
a *Namespace*.
|
||||
|
||||
See [Admission control: Limit Range](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md)
|
||||
See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md)
|
||||
|
||||
A namespace can be in one of two phases:
|
||||
|
||||
* `Active` the namespace is in use
|
||||
* `Terminating` the namespace is being deleted, and can not be used for new objects
|
||||
|
||||
See the [design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#phases) for more details.
|
||||
See the [design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#phases) for more details.
|
||||
|
||||
## Creating a new namespace
|
||||
|
||||
@@ -117,7 +117,7 @@ Note that the name of your namespace must be a DNS compatible label.
|
||||
|
||||
There's an optional field `finalizers`, which allows observables to purge resources whenever the namespace is deleted. Keep in mind that if you specify a nonexistent finalizer, the namespace will be created but will get stuck in the `Terminating` state if the user tries to delete it.
|
||||
|
||||
More information on `finalizers` can be found in the namespace [design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#finalizers).
|
||||
More information on `finalizers` can be found in the namespace [design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#finalizers).
|
||||
|
||||
|
||||
### Working in namespaces
|
||||
@@ -148,5 +148,5 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
|
||||
|
||||
## Design
|
||||
|
||||
Details of the design of namespaces in Kubernetes, including a [detailed example](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace)
|
||||
can be found in the [namespaces design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/namespaces.md)
|
||||
Details of the design of namespaces in Kubernetes, including a [detailed example](https://git.k8s.io/community/contributors/design-proposals/namespaces.md#example-openshift-origin-managing-a-kubernetes-namespace)
|
||||
can be found in the [namespaces design doc](https://git.k8s.io/community/contributors/design-proposals/namespaces.md)
|
||||
|
||||
@@ -102,7 +102,7 @@ It is recommended that the kubernetes system daemons are placed under a top
|
||||
level control group (`runtime.slice` on systemd machines for example). Each
|
||||
system daemon should ideally run within its own child control group. Refer to
|
||||
[this
|
||||
doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node-allocatable.md#recommended-cgroups-setup)
|
||||
doc](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md#recommended-cgroups-setup)
|
||||
for more details on recommended control group hierarchy.
|
||||
|
||||
Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
|
||||
|
||||
@@ -9,7 +9,7 @@ redirect_from:
|
||||
|
||||
Kubernetes version 1.6 contains a new binary called as `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops in Kubernetes. These cloud-specific control loops were originally in the kube-controller-manager. However, cloud providers move at a different pace and schedule compared to the Kubernetes project, and abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud provider vendors to evolve independently from the core Kubernetes code.
|
||||
|
||||
The `cloud-controller-manager` can be linked to any cloud provider that satisifies the [cloudprovider.Interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go).
|
||||
The `cloud-controller-manager` can be linked to any cloud provider that satisifies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
|
||||
In future Kubernetes releases, cloud vendors should link code that satisfies the above interface to the `cloud-controller-manager` project and compile `cloud-controller-manager` for their own clouds. Cloud providers would also be responsible for maintaining and evolving their code.
|
||||
|
||||
* TOC
|
||||
@@ -19,11 +19,11 @@ In future Kubernetes releases, cloud vendors should link code that satisfies the
|
||||
|
||||
To build cloud-controller-manager for your cloud, follow these steps:
|
||||
|
||||
* Write a cloudprovider that satisfies the [cloudprovider.Interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go).
|
||||
* Write a cloudprovider that satisfies the [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
|
||||
* Link the cloudprovider to cloud-controller-manager
|
||||
|
||||
The methods in [cloudprovider.Interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go) are self-explanatory. All of the
|
||||
[existing providers](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers) satisfy this interface. If your cloud is already a part
|
||||
The methods in [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go) are self-explanatory. All of the
|
||||
[existing providers](https://git.k8s.io/kubernetes/pkg/cloudprovider/providers) satisfy this interface. If your cloud is already a part
|
||||
of the existing providers, you do not need to write a new provider; you can proceed directly with linking your cloud provider to the `cloud-controller-manager`.
|
||||
|
||||
Once your code is ready, you must import that code into `cloud-controller-manager`. See the [rancher cloud sample](https://github.com/rancher/rancher-cloud-controller-manager) for a reference example. The import step in the sample is the only step required to link your cloud provider to the `cloud-controller-manager`.
|
||||
|
||||
Reference in New Issue
Block a user