whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin' into release-1.4

Browse Source
This commit is contained in:
Devin Donnelly
2016-09-23 16:57:30 -07:00
parent a926c3959e 51add3e397
commit f4457ae677
21 changed files with 155 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/user-guide/accessing-the-cluster.md
+30 -7
View File
@@ -100,13 +100,36 @@ with future high-availability support.
### Programmatic access to the API
There are [client libraries](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/client-libraries.md) for accessing the API
from several languages. The Kubernetes project-supported
[Go](http://releases.k8s.io/{{page.githubbranch}}/pkg/client/)
client library can use the same [kubeconfig file](/docs/user-guide/kubeconfig-file)
as the kubectl CLI does to locate and authenticate to the apiserver.
The Kubernetes project-supported Go client library is at [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go).
See documentation for other libraries for how they authenticate.
To use it,
* To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes` See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
* 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/user-guide/kubeconfig-file)
as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes/client-go/examples/out-of-cluster.go):
```golang
import (
"fmt"
"k8s.io/client-go/1.4/kubernetes"
"k8s.io/client-go/1.4/pkg/api/v1"
"k8s.io/client-go/1.4/tools/clientcmd"
)
...
// uses the current context in kubeconfig
config, _ := clientcmd.BuildConfigFromFlags("", "path to kubeconfig")
// creates the clientset
clientset, _:= kubernetes.NewForConfig(config)
// access the API to list pods
pods, _:= clientset.Core().Pods("").List(v1.ListOptions{})
fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
...
```
If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
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.
### Accessing the API from a Pod
@@ -138,7 +161,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 `client.NewInCluster()` factory.
This handles locating and authenticating to the apiserver.
This handles locating and authenticating to the apiserver. [example](https://github.com/kubernetes/client-go/examples/in-cluster.go)
In each case, the credentials of the pod are used to communicate securely with the apiserver.
docs/user-guide/kubeconfig-file.md
+2 -2
View File
@@ -307,8 +307,8 @@ $ kubectl config use-context federal-context
So, tying this all together, a quick start to creating your own kubeconfig file:
- Take a good look and understand how you're api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication.
- Take a good look and understand how your api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication.
- Replace the snippet above with information for your cluster's api-server endpoint.
- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.
- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.
docs/user-guide/kubectl/kubectl_drain.md
+3 -3
View File
@@ -12,13 +12,13 @@ Drain node in preparation for maintenance
Drain node in preparation for maintenance.
The given node will be marked unschedulable to prevent new pods from arriving.
Then drain deletes all pods except mirror pods (which cannot be deleted through
The `drain` deletes all pods except mirror pods (which cannot be deleted through
the API server). If there are DaemonSet-managed pods, drain will not proceed
without --ignore-daemonsets, and regardless it will not delete any
DaemonSet-managed pods, because those pods would be immediately replaced by the
DaemonSet controller, which ignores unschedulable markings. If there are any
pods that are neither mirror pods nor managed--by ReplicationController,
ReplicaSet, DaemonSet or Job--, then drain will not delete any pods unless you
pods that are neither mirror pods nor managed by ReplicationController,
ReplicaSet, DaemonSet or Job, then drain will not delete any pods unless you
use --force.
When you are ready to put the node back into service, use kubectl uncordon, which
docs/user-guide/kubectl/kubectl_version.md
+1 -1
View File
@@ -49,7 +49,7 @@ kubectl version
### SEE ALSO
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
* [kubectl](../kubectl.md) - kubectl controls the Kubernetes cluster manager
###### Auto generated by spf13/cobra on 2-Sep-2016
docs/user-guide/namespaces.md
+2 -2
View File
@@ -90,7 +90,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
## Not All Objects are in a Namespace
Most kubernetes resources (e.g. pods, services, replication controllers, and others) are
in a some namespace. However namespace resources are not themselves in a namespace.
And, low-level resources, such as [nodes](/docs/admin/node) and
in some namespace. However namespace resources are not themselves in a namespace.
And low-level resources, such as [nodes](/docs/admin/node) and
persistentVolumes, are not in any namespace. Events are an exception: they may or may not
have a namespace, depending on the object the event is about.
docs/user-guide/secrets/index.md
+1 -1
View File
@@ -480,7 +480,7 @@ start until all the pod's volumes are mounted.
Create a secret containing some ssh keys:
```shell
$ kubectl create secret generic my-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
$ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
```
**Security Note:** think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to have accessible to all the users with whom you share the kubernetes cluster, and can revoke if they are compromised.
docs/user-guide/volumes.md
+1 -1
View File
@@ -372,7 +372,7 @@ writers simultaneously.
__Important: You must have your own Ceph server running with the share exported
before you can use it__
See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/cephfs/) for more details.
See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/cephfs/) for more details.
### gitRepo