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

fix space problems which ide results in

Browse Source 
Signed-off-by: tim-zju <21651152@zju.edu.cn>
This commit is contained in:
tim-zju
2016-12-22 20:01:22 +08:00
parent 1f7b3148f2
commit df7eb8128d
5 changed files with 42 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/getting-started-guides/windows/index.md
+3 -3
View File
@@ -38,13 +38,13 @@ To run Windows Server Containers on Kubernetes, you'll need to set up both your
1. Windows Server container host running Windows Server 2016 and Docker v1.12. Follow the setup instructions outlined by this blog post: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_server 1. Windows Server container host running Windows Server 2016 and Docker v1.12. Follow the setup instructions outlined by this blog post: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_server
2. DNS support for Windows recently got merged to docker master and is currently not supported in a stable docker release. To use DNS build docker from master or download the binary from [Docker master](https://master.dockerproject.org/) 2. DNS support for Windows recently got merged to docker master and is currently not supported in a stable docker release. To use DNS build docker from master or download the binary from [Docker master](https://master.dockerproject.org/)
3. Pull the `apprenda/pause` image from `https://hub.docker.com/r/apprenda/pause` 3. Pull the `apprenda/pause` image from `https://hub.docker.com/r/apprenda/pause`
4. RRAS (Routing) Windows feature enabled 4. RRAS (Routing) Windows feature enabled
5. Install a VMSwitch of type `Internal`, by running `New-VMSwitch -Name KubeProxySwitch -SwitchType Internal` command in *PowerShell* window. This will create a new Network Interface with name `vEthernet (KubeProxySwitch)`. This interface will be used by kube-proxy to add Service IPs. 5. Install a VMSwitch of type `Internal`, by running `New-VMSwitch -Name KubeProxySwitch -SwitchType Internal` command in *PowerShell* window. This will create a new Network Interface with name `vEthernet (KubeProxySwitch)`. This interface will be used by kube-proxy to add Service IPs.
**Linux Host Setup** **Linux Host Setup**
1. Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using. 1. Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using.
2. CNI network plugin installed. 2. CNI network plugin installed.
### Component Setup ### Component Setup
@@ -111,7 +111,7 @@ route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 if <Interface Id of the Rou
``` ```
## Starting the Cluster ## Starting the Cluster
To start your cluster, you'll need to start both the Linux-based Kubernetes control plane, and the Windows Server-based Kubernetes node components. To start your cluster, you'll need to start both the Linux-based Kubernetes control plane, and the Windows Server-based Kubernetes node components.
## Starting the Linux-based Control Plane ## Starting the Linux-based Control Plane
Use your preferred method to start Kubernetes cluster on Linux. Please note that Cluster CIDR might need to be updated. Use your preferred method to start Kubernetes cluster on Linux. Please note that Cluster CIDR might need to be updated.
## Starting the Windows Node Components ## Starting the Windows Node Components
docs/user-guide/managing-deployments.md
+17 -17
View File
@@ -102,7 +102,7 @@ project/k8s/development
└── my-pvc.yaml └── my-pvc.yaml
``` ```
By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we tried to create the resources in this directory using the following command, we'd encounter an error: By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we tried to create the resources in this directory using the following command, we'd encounter an error:
```shell ```shell
$ kubectl create -f project/k8s/development $ kubectl create -f project/k8s/development
@@ -131,7 +131,7 @@ deployment "my-deployment" created
persistentvolumeclaim "my-pvc" created persistentvolumeclaim "my-pvc" created
``` ```
If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/user-guide/kubectl-overview). If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/user-guide/kubectl-overview).
## Using labels effectively ## Using labels effectively
@@ -185,9 +185,9 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
## Canary deployments ## Canary deployments
Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out. Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out.
For instance, you can use a `track` label to differentiate different releases. For instance, you can use a `track` label to differentiate different releases.
The primary, stable release would have a `track` label with value as `stable`: The primary, stable release would have a `track` label with value as `stable`:
@@ -227,13 +227,13 @@ The frontend service would span both sets of replicas by selecting the common su
``` ```
You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1). You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1).
Once you're confident, you can update the stable track to the new application release and remove the canary one. Once you're confident, you can update the stable track to the new application release and remove the canary one.
For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary). For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary).
## Updating labels ## Updating labels
Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`. Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`.
For example, if you want to label all your nginx pods as frontend tier, simply run: For example, if you want to label all your nginx pods as frontend tier, simply run:
```shell ```shell
@@ -243,8 +243,8 @@ pod "my-nginx-2035384211-u2c7e" labeled
pod "my-nginx-2035384211-u3t6x" labeled pod "my-nginx-2035384211-u3t6x" labeled
``` ```
This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe". This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe".
To see the pods you just labeled, run: To see the pods you just labeled, run:
```shell ```shell
$ kubectl get pods -l app=nginx -L tier $ kubectl get pods -l app=nginx -L tier
@@ -284,7 +284,7 @@ $ kubectl scale deployment/my-nginx --replicas=1
deployment "my-nginx" scaled deployment "my-nginx" scaled
``` ```
Now you only have one pod managed by the deployment. Now you only have one pod managed by the deployment.
```shell ```shell
$ kubectl get pods -l app=nginx $ kubectl get pods -l app=nginx
@@ -294,25 +294,25 @@ my-nginx-2035384211-j5fhi 1/1 Running 0 30m
To have the system automatically choose the number of nginx replicas as needed, ranging from 1 to 3, do: To have the system automatically choose the number of nginx replicas as needed, ranging from 1 to 3, do:
```shell ```shell
$ kubectl autoscale deployment/my-nginx --min=1 --max=3 $ kubectl autoscale deployment/my-nginx --min=1 --max=3
deployment "my-nginx" autoscaled deployment "my-nginx" autoscaled
``` ```
Now your nginx replicas will be scaled up and down as needed, automatically. Now your nginx replicas will be scaled up and down as needed, automatically.
For more information, please see [kubectl scale](/docs/user-guide/kubectl/kubectl_scale/), [kubectl autoscale](/docs/user-guide/kubectl/kubectl_autoscale/) and [horizontal pod autoscaler](/docs/user-guide/horizontal-pod-autoscaler/) document. For more information, please see [kubectl scale](/docs/user-guide/kubectl/kubectl_scale/), [kubectl autoscale](/docs/user-guide/kubectl/kubectl_autoscale/) and [horizontal pod autoscaler](/docs/user-guide/horizontal-pod-autoscaler/) document.
## In-place updates of resources ## In-place updates of resources
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created. Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created.
### kubectl apply ### kubectl apply
It is suggested to maintain a set of configuration files in source control (see [configuration as code](http://martinfowler.com/bliki/InfrastructureAsCode.html)), It is suggested to maintain a set of configuration files in source control (see [configuration as code](http://martinfowler.com/bliki/InfrastructureAsCode.html)),
so that they can be maintained and versioned along with the code for the resources they configure. so that they can be maintained and versioned along with the code for the resources they configure.
Then, you can use [`kubectl apply`](/docs/user-guide/kubectl/kubectl_apply/) to push your configuration changes to the cluster. Then, you can use [`kubectl apply`](/docs/user-guide/kubectl/kubectl_apply/) to push your configuration changes to the cluster.
This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified. This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified.
@@ -357,7 +357,7 @@ For more information, please see [kubectl edit](/docs/user-guide/kubectl/kubectl
Suppose you want to fix a typo of the container's image of a Deployment. One way to do that is with `kubectl patch`: Suppose you want to fix a typo of the container's image of a Deployment. One way to do that is with `kubectl patch`:
```shell ```shell
# Suppose you have a Deployment with a container named "nginx" and its image "nignx" (typo), # Suppose you have a Deployment with a container named "nginx" and its image "nignx" (typo),
# use container name "nginx" as a key to update the image from "nignx" (typo) to "nginx" # use container name "nginx" as a key to update the image from "nignx" (typo) to "nginx"
$ kubectl get deployment my-nginx -o yaml $ kubectl get deployment my-nginx -o yaml
``` ```
@@ -414,8 +414,8 @@ deployment "my-nginx" replaced
At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios. At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios.
We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers, We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers,
you should read [how to use `kubectl rolling-update`](/docs/user-guide/rolling-updates/) instead. you should read [how to use `kubectl rolling-update`](/docs/user-guide/rolling-updates/) instead.
Let's say you were running version 1.7.9 of nginx: Let's say you were running version 1.7.9 of nginx:
@@ -424,7 +424,7 @@ $ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3
deployment "my-nginx" created deployment "my-nginx" created
``` ```
To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above. To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above.
```shell ```shell
$ kubectl edit deployment/my-nginx $ kubectl edit deployment/my-nginx
docs/user-guide/pod-security-policy/index.md
+18 -18
View File
@@ -4,8 +4,8 @@ assignees:
title: Pod Security Policies title: Pod Security Policies
--- ---
Objects of type `podsecuritypolicy` govern the ability Objects of type `podsecuritypolicy` govern the ability
to make requests on a pod that affect the `SecurityContext` that will be to make requests on a pod that affect the `SecurityContext` that will be
applied to a pod and container. applied to a pod and container.
See [PodSecurityPolicy proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/security-context-constraints.md) for more information. See [PodSecurityPolicy proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/security-context-constraints.md) for more information.
@@ -15,10 +15,10 @@ See [PodSecurityPolicy proposal](https://github.com/kubernetes/kubernetes/blob/{
## What is a Pod Security Policy? ## What is a Pod Security Policy?
A _Pod Security Policy_ is a cluster-level resource that controls the A _Pod Security Policy_ is a cluster-level resource that controls the
actions that a pod can perform and what it has the ability to access. The actions that a pod can perform and what it has the ability to access. The
`PodSecurityPolicy` objects define a set of conditions that a pod must `PodSecurityPolicy` objects define a set of conditions that a pod must
run with in order to be accepted into the system. They allow an run with in order to be accepted into the system. They allow an
administrator to control the following: administrator to control the following:
1. Running of privileged containers. 1. Running of privileged containers.
@@ -31,16 +31,16 @@ administrator to control the following:
1. Requiring the use of a read only root file system 1. Requiring the use of a read only root file system
1. Controlling the usage of volume types 1. Controlling the usage of volume types
_Pod Security Policies_ are comprised of settings and strategies that _Pod Security Policies_ are comprised of settings and strategies that
control the security features a pod has access to. These settings fall control the security features a pod has access to. These settings fall
into three categories: into three categories:
- *Controlled by a boolean*: Fields of this type default to the most - *Controlled by a boolean*: Fields of this type default to the most
restrictive value. restrictive value.
- *Controlled by an allowable set*: Fields of this type are checked - *Controlled by an allowable set*: Fields of this type are checked
against the set to ensure their value is allowed. against the set to ensure their value is allowed.
- *Controlled by a strategy*: Items that have a strategy to generate a value provide - *Controlled by a strategy*: Items that have a strategy to generate a value provide
a mechanism to generate the value and a mechanism to ensure that a a mechanism to generate the value and a mechanism to ensure that a
specified value falls into the set of allowable values. specified value falls into the set of allowable values.
@@ -65,22 +65,22 @@ specified.
### SupplementalGroups ### SupplementalGroups
- *MustRunAs* - Requires at least one range to be specified. Uses the - *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against all ranges. minimum value of the first range as the default. Validates against all ranges.
- *RunAsAny* - No default provided. Allows any `*supplementalGroups*` to be - *RunAsAny* - No default provided. Allows any `*supplementalGroups*` to be
specified. specified.
### FSGroup ### FSGroup
- *MustRunAs* - Requires at least one range to be specified. Uses the - *MustRunAs* - Requires at least one range to be specified. Uses the
minimum value of the first range as the default. Validates against the minimum value of the first range as the default. Validates against the
first ID in the first range. first ID in the first range.
- *RunAsAny* - No default provided. Allows any `*fsGroup*` ID to be specified. - *RunAsAny* - No default provided. Allows any `*fsGroup*` ID to be specified.
### Controlling Volumes ### Controlling Volumes
The usage of specific volume types can be controlled by setting the The usage of specific volume types can be controlled by setting the
volumes field of the PSP. The allowable values of this field correspond volumes field of the PSP. The allowable values of this field correspond
to the volume sources that are defined when creating a volume: to the volume sources that are defined when creating a volume:
1. azureFile 1. azureFile
@@ -104,7 +104,7 @@ to the volume sources that are defined when creating a volume:
1. configMap 1. configMap
1. \* (allow all volumes) 1. \* (allow all volumes)
The recommended minimum set of allowed volumes for new PSPs are The recommended minimum set of allowed volumes for new PSPs are
configMap, downwardAPI, emptyDir, persistentVolumeClaim, and secret. configMap, downwardAPI, emptyDir, persistentVolumeClaim, and secret.
## Admission ## Admission
@@ -150,7 +150,7 @@ podsecuritypolicy "permissive" deleted
## Enabling Pod Security Policies ## Enabling Pod Security Policies
In order to use Pod Security Policies in your cluster you must ensure the In order to use Pod Security Policies in your cluster you must ensure the
following following
1. You have enabled the api type `extensions/v1beta1/podsecuritypolicy` 1. You have enabled the api type `extensions/v1beta1/podsecuritypolicy`
docs/user-guide/replication-controller/index.md
+2 -2
View File
@@ -194,7 +194,7 @@ Ideally, the rolling update controller would take application readiness into acc
The two replication controllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates. The two replication controllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.
Rolling update is implemented in the client tool Rolling update is implemented in the client tool
[`kubectl rolling-update`](/docs/user-guide/kubectl/kubectl_rolling-update). Visit [`kubectl rolling-update` tutorial](/docs/user-guide/rolling-updates/) for more concrete examples. [`kubectl rolling-update`](/docs/user-guide/kubectl/kubectl_rolling-update). Visit [`kubectl rolling-update` tutorial](/docs/user-guide/rolling-updates/) for more concrete examples.
### Multiple release tracks ### Multiple release tracks
@@ -239,7 +239,7 @@ Note that we recommend using Deployments instead of directly using Replica Sets,
### Deployment (Recommended) ### Deployment (Recommended)
[`Deployment`](/docs/user-guide/deployments/) is a higher-level API object that updates its underlying Replica Sets and their Pods [`Deployment`](/docs/user-guide/deployments/) is a higher-level API object that updates its underlying Replica Sets and their Pods
in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality, in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality,
because unlike `kubectl rolling-update`, they are declarative, server-side, and have additional features. because unlike `kubectl rolling-update`, they are declarative, server-side, and have additional features.
### Bare Pods ### Bare Pods
docs/user-guide/security-context.md
+2 -2
View File
@@ -11,7 +11,7 @@ A security context defines the operating system security settings (uid, gid, cap
There are two levels of security context: pod level security context, and container level security context. There are two levels of security context: pod level security context, and container level security context.
## Pod Level Security Context ## Pod Level Security Context
Setting security context at the pod applies those settings to all containers in the pod Setting security context at the pod applies those settings to all containers in the pod
```yaml ```yaml
apiVersion: v1 apiVersion: v1
@@ -82,6 +82,6 @@ spec:
``` ```
Please refer to the Please refer to the
[API documentation](/docs/api-reference/v1/definitions/#_v1_securitycontext) [API documentation](/docs/api-reference/v1/definitions/#_v1_securitycontext)
for a detailed listing and description of all the fields available for a detailed listing and description of all the fields available
within the container security context. within the container security context.