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

Merge branch 'master' into release-1.8

Browse Source
This commit is contained in:
steveperry-53
2017-08-02 21:30:33 -07:00
parent dfbc33b8fb c1ecce52fe
commit 3a01832d84
38 changed files with 1151 additions and 109 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md
+26 -19
View File
@@ -1,10 +1,8 @@
---
assignees:
- mikedanese
- thockin
title: Authenticate Across Clusters with kubeconfig
title: Authenticate across clusters with kubeconfig
---
{% capture overview %}
Authentication in Kubernetes can differ for different individuals.
- A running kubelet might have one way of authenticating (i.e. certificates).
@@ -17,11 +15,13 @@ So in order to easily switch between multiple clusters, for multiple users, a ku
This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname.
Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging-rules) below).
{% endcapture %}
## Related discussion
[http://issue.k8s.io/1755](http://issue.k8s.io/1755)
{% capture prerequisites %}
* {% include task-tutorial-prereqs.md %}
{% endcapture %}
{% capture steps %}
## Components of a kubeconfig file
### Example kubeconfig file
@@ -164,25 +164,24 @@ the settings relevant to the `current-context` by passing `--minify`. See
## Building your own kubeconfig file
NOTE, that if you are deploying k8s via kube-up.sh, you do not need to create your own kubeconfig files, the script will do it for you.
You can use the [sample kubeconfig file](#example-kubeconfig-file) above as a template for your own kubeconfig files.
In any case, you can easily use this file as a template to create your own kubeconfig files.
**Note:** If you're deploying Kubernetes with `kube-up.sh`, you don't need to create your own kubeconfig files—the script does it for you.
{: .note}
So, lets do a quick walk through the basics of the above file so you can easily modify it as needed...
The above file would likely correspond to an api-server which was launched using the `--token-auth-file=tokens.csv` option, where the tokens.csv file looked something like this:
The sample file corresponds to an [API server](https://kubernetes.io/docs/admin/kube-apiserver/) launched using the `--token-auth-file=tokens.csv` option, where the `tokens.csv` file contains:
```conf
blue-user,blue-user,1
mister-red,mister-red,2
```
Also, since we have other users who validate using **other** mechanisms, the api-server would have probably been launched with other authentication options (there are many such options, make sure you understand which ones YOU care about before crafting a kubeconfig file, as nobody needs to implement all the different permutations of possible authentication schemes).
**Note:** There are many [options available](https://kubernetes.io/docs/admin/kube-apiserver/) for launching an API server. Make sure you understand the options you include.
{: .note}
- Since the user for the current context is "green-user", any client of the api-server using this kubeconfig file would naturally be able to log in successfully, because we are providing the green-user's client credentials.
- Similarly, we can operate as the "blue-user" if we choose to change the value of current-context.
The sample kubeconfig file provides client credentials for the user `green-user`. Because the user for `current-context` is `green-user`, any client of the API server using the sample kubeconfig file could log in successfully. Similarly, we can operate as `blue-user` by changing the value of `current-context`.
In the above scenario, green-user would have to log in by providing certificates, whereas blue-user would just provide the token. All this information would be handled for us by the
In the example provided, `green-user` logs in by providing certificates, and `blue-user` provides a token. Login information is specified with the `kubectl config set-credentials` command. For more information, see "[Commands for the example file](#commands-for-the-example-file)".
## Loading and merging rules
@@ -198,7 +197,7 @@ The rules for loading and merging the kubeconfig files are straightforward, but
Merge files together based on the following rules.
Empty filenames are ignored. Files with non-deserializable content produced errors.
The first file to set a particular value or map key wins and the value or map key is never changed.
This means that the first file to set `CurrentContext` will have its context preserved. It also means that if two files specify a "red-user", only values from the first file's red-user are used. Even non-conflicting entries from the second file's "red-user" are discarded.
This means that the first file to set `CurrentContext` will have its context preserved. It also means that if two files specify a `red-user`, only values from the first file's `red-user` are used. Even non-conflicting entries from the second file's `red-user` are discarded.
Otherwise, use HomeDirectoryLocation (`~/.kube/config`) with no merging.
@@ -302,8 +301,10 @@ $ kubectl config set-context queen-anne-context --cluster=pig-cluster --user=bla
$ kubectl config set-context federal-context --cluster=horse-cluster --user=green-user --namespace=chisel-ns
$ kubectl config use-context federal-context
```
{% endcapture %}
### Final notes for tying it all together
{% capture discussion %}
## Final notes for tying it all together
So, tying this all together, a quick start to create your own kubeconfig file:
@@ -311,4 +312,10 @@ So, tying this all together, a quick start to create your own kubeconfig file:
- 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 provides at least one set of credentials (for example, `green-user`) when launched. 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.
## Related discussion
[http://issue.k8s.io/1755](http://issue.k8s.io/1755)
{% endcapture %}
{% include templates/task.md %}
docs/tasks/administer-federation/ingress.md
+1 -5
View File
@@ -22,7 +22,7 @@ unresponsive clusters).
Federated Ingress is released as an alpha feature, and supports Google Cloud Platform (GKE,
GCE and hybrid scenarios involving both) in Kubernetes v1.4. Work is under way to support other cloud
providers such as AWS, and other hybrid cloud scenarios (e.g. services
spanning private on-premise as well as public cloud Kubernetes
spanning private on-premises as well as public cloud Kubernetes
clusters).
You create Federated Ingresses in much that same way as traditional
@@ -303,7 +303,3 @@ Check that:
[Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md).
{% endcapture %}
{% include templates/task.md %}
docs/tasks/configure-pod-container/pull-image-private-registry.md
+2 -1
View File
@@ -43,7 +43,8 @@ The output contains a section similar to this:
}
}
NOTE: If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
**Note:** If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
{: .note}
## Create a Secret that holds your authorization token
docs/tasks/federation/policy.rego
+2 -2
View File
@@ -35,13 +35,13 @@ annotations["federation.kubernetes.io/replica-set-preferences"] = preferences {
#
# In English, the policy asserts that resources in the "production" namespace
# that are not annotated with "criticality=low" MUST be placed on clusters
# labelled with "on-premise=true".
# labelled with "on-premises=true".
annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector {
input.metadata.namespace = "production"
not input.metadata.annotations.criticality = "low"
json.marshal([{
"operator": "=",
"key": "on-premise",
"key": "on-premises",
"values": "[true]",
}], selector)
}
docs/tasks/manage-gpus/scheduling-gpus.md
+12 -8
View File
@@ -29,18 +29,22 @@ Nvidia GPUs can be consumed via container level resource requirements using the
```yaml
apiVersion: v1
kind: pod
spec:
containers:
-
kind: Pod
metadata:
name: gpu-pod
spec:
containers:
-
name: gpu-container-1
resources:
limits:
image: gcr.io/google_containers/pause:2.0
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 2 # requesting 2 GPUs
-
name: gpu-container-2
resources:
limits:
image: gcr.io/google_containers/pause:2.0
resources:
limits:
alpha.kubernetes.io/nvidia-gpu: 3 # requesting 3 GPUs
```