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

merge master to 1.10, with fixes (#7682)

Browse Source
This commit is contained in:
Jennifer Rondeau
2018-03-08 14:03:55 -05:00
committed by zacharysarah
parent 7f40782850
commit 3d79703d23
60 changed files with 26896 additions and 762 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/administer-cluster/pvc-protection.md
+144
View File
@@ -0,0 +1,144 @@
---
reviewers:
- msau42
- jsafrane
title: Persistent Volume Claim Protection
---
{% capture overview %}
{% assign for_k8s_version="v1.9" %}{% include feature-state-alpha.md %}
As of Kubernetes 1.9, persistent volume claims (PVCs) that are in active use by a pod can be protected from pre-mature removal.
{% endcapture %}
{% capture prerequisites %}
- A v1.9 or higher Kubernetes must be installed.
- As PVC Protection is a Kubernetes v1.9 alpha feature it must be enabled:
1. [Admission controller](/docs/admin/admission-controllers/) must be started with the [PVC Protection plugin](/docs/admin/admission-controllers/#persistent-volume-claim-protection-alpha).
2. All Kubernetes components must be started with the `PVCProtection` alpha features enabled.
{% endcapture %}
{% capture steps %}
## PVC Protection Verification
The example below uses a GCE PD `StorageClass`, however, similar steps can be performed for any volume type.
Create a `StorageClass` for convenient storage provisioning:
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
```
There are two scenarios: a PVC deleted by a user is either in active use or not in active use by a pod.
### Scenario 1: The PVC is not in active use by a pod
- Create a PVC:
```yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: slzc
spec:
accessModes:
- ReadWriteOnce
storageClassName: slow
resources:
requests:
storage: 3.7Gi
```
- Check that the PVC has the finalizer `kubernetes.io/pvc-protection` set:
```shell
$ kubectl describe pvc slzc
Name: slzc
Namespace: default
StorageClass: slow
Status: Bound
Volume: pvc-bee8c30a-d6a3-11e7-9af0-42010a800002
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed=yes
pv.kubernetes.io/bound-by-controller=yes
volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 4Gi
Access Modes: RWO
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ProvisioningSucceeded 2m persistentvolume-controller Successfully provisioned volume pvc-bee8c30a-d6a3-11e7-9af0-42010a800002 using kubernetes.io/gce-pd
```
- Delete the PVC and check that the PVC (not in active use by a pod) was removed successfully.
### Scenario 2: The PVC is in active use by a pod
- Again, create the same PVC.
- Create a pod that uses the PVC:
```yaml
kind: Pod
apiVersion: v1
metadata:
name: app1
spec:
containers:
- name: test-pod
image: k8s.gcr.io/busybox:1.24
command:
- "/bin/sh"
args:
- "-c"
- "date > /mnt/app1.txt; sleep 60 && exit 0 || exit 1"
volumeMounts:
- name: path-pvc
mountPath: "/mnt"
restartPolicy: "Never"
volumes:
- name: path-pvc
persistentVolumeClaim:
claimName: slzc
```
- Wait until the pod status is `Running`, i.e. the PVC becomes in active use.
- Delete the PVC that is now in active use by a pod and verify that the PVC is not removed but its status is `Terminating`:
```shell
Name: slzc
Namespace: default
StorageClass: slow
Status: Terminating (since Fri, 01 Dec 2017 14:47:55 +0000)
Volume: pvc-803a1f4d-d6a6-11e7-9af0-42010a800002
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed=yes
pv.kubernetes.io/bound-by-controller=yes
volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/gce-pd
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 4Gi
Access Modes: RWO
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ProvisioningSucceeded 52s persistentvolume-controller Successfully provisioned volume pvc-803a1f4d-d6a6-11e7-9af0-42010a800002 using kubernetes.io/gce-pd
```
- Wait until the pod status is `Terminated` (either delete the pod or wait until it finishes). Afterwards, check that the PVC is removed.
{% endcapture %}
{% capture discussion %}
{% endcapture %}
{% include templates/task.md %}
docs/tasks/administer-cluster/sysctl-cluster.md
+31
View File
@@ -1,4 +1,12 @@
---
<<<<<<< HEAD:docs/tasks/administer-cluster/sysctl-cluster.md
||||||| merged common ancestors
approvers:
- sttts
=======
reviewers:
- sttts
>>>>>>> merge master to 1.10, with fixes (#7682):docs/concepts/cluster-administration/sysctl-cluster.md
title: Using Sysctls in a Kubernetes Cluster
reviewers:
- sttts
@@ -139,6 +147,7 @@ is recommended to use
[_taints and toleration_ feature](/docs/user-guide/kubectl/{{page.version}}/#taint) or
[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
to schedule those pods onto the right nodes.
<<<<<<< HEAD:docs/tasks/administer-cluster/sysctl-cluster.md
## PodSecurityPolicy Annotations
@@ -164,3 +173,25 @@ spec:
{% endcapture %}
{% include templates/task.md %}
||||||| merged common ancestors
=======
## PodSecurityPolicy Annotations
The use of sysctl in pods can be controlled via annotations on the PodSecurityPolicy.
Here is an example, it authorizes binding user creating pod with corresponding
_safe_ and _unsafe_ sysctls.
```yaml
apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: sysctl-psp
annotations:
security.alpha.kubernetes.io/sysctls: 'kernel.shm_rmid_forced'
security.alpha.kubernetes.io/unsafe-sysctls: 'net.ipv4.route.*,kernel.msg*'
spec:
...
```
>>>>>>> merge master to 1.10, with fixes (#7682):docs/concepts/cluster-administration/sysctl-cluster.md
docs/tasks/configure-pod-container/pull-image-private-registry.md
+65
View File
@@ -62,13 +62,34 @@ where:
* `<your-pword>` is your Docker password.
* `<your-email>` is your Docker email.
<<<<<<< HEAD
You have successfully set your Docker credentials in the cluster as a Secret called `regcred`.
## Inspecting the Secret `regcred`
||||||| merged common ancestors
## Understanding your Secret
=======
You have successfully set your Docker credentials in the cluster as a Secret called `regcred`.
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
||||||| merged common ancestors
To understand what's in the Secret you just created, start by viewing the
Secret in YAML format:
=======
## Inspecting the Secret `regcred`
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
kubectl get secret regcred --output=yaml
||||||| merged common ancestors
kubectl get secret regsecret --output=yaml
=======
To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
kubectl get secret regcred --output=yaml
>>>>>>> merge master to 1.10, with fixes (#7682)
The output is similar to this:
@@ -80,21 +101,50 @@ The output is similar to this:
...
name: regcred
...
<<<<<<< HEAD
type: kubernetes.io/dockerconfigjson
The value of the `.dockerconfigjson` field is a base64 representation of your Docker credentials.
||||||| merged common ancestors
type: kubernetes.io/dockercfg
The value of the `.dockercfg` field is a base64 representation of your secret data.
=======
type: kubernetes.io/dockerconfigjson
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
To understand what is in the `.dockerconfigjson` field, convert the secret data to a
||||||| merged common ancestors
Copy the base64 representation of the secret data into a file named `secret64`.
**Important**: Make sure there are no line breaks in your `secret64` file.
To understand what is in the `.dockercfg` field, convert the secret data to a
=======
The value of the `.dockerconfigjson` field is a base64 representation of your Docker credentials.
To understand what is in the `.dockerconfigjson` field, convert the secret data to a
>>>>>>> merge master to 1.10, with fixes (#7682)
readable format:
kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 -d
The output is similar to this:
<<<<<<< HEAD
{"auths":{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
To understand what is in the `auth` field, convert the base64-encoded data to a readable format:
||||||| merged common ancestors
{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}
=======
{"auths":{"yourprivateregistry.com":{"username":"janedoe","password":"xxxxxxxxxxx","email":"jdoe@example.com","auth":"c3R...zE2"}}}
Notice that the Secret data contains the authorization token similar to your local `~/.docker/config.json` file.
>>>>>>> merge master to 1.10, with fixes (#7682)
<<<<<<< HEAD
echo "c3R...zE2" | base64 -d
The output, username and password concatenated with a `:`, is similar to this:
@@ -104,6 +154,12 @@ The output, username and password concatenated with a `:`, is similar to this:
Notice that the Secret data contains the authorization token similar to your local `~/.docker/config.json` file.
You have successfully set your Docker credentials as a Secret called `regcred` in the cluster.
||||||| merged common ancestors
Notice that the secret data contains the authorization token from your
`config.json` file.
=======
You have successfully set your Docker credentials as a Secret called `regcred` in the cluster.
>>>>>>> merge master to 1.10, with fixes (#7682)
## Create a Pod that uses your Secret
@@ -134,8 +190,17 @@ Create a Pod that uses your Secret, and verify that the Pod is running:
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
* See [kubectl create secret docker-registry](/docs/user-guide/kubectl/{{page.version}}/#-em-secret-docker-registry-em-).
<<<<<<< HEAD
* See [Secret](/docs/reference/generated/kubernetes-api/{{page.version}}/#secret-v1-core).
* See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{page.version}}/#podspec-v1-core).
||||||| merged common ancestors
* See [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core)
* See the `imagePullSecrets` field of
[PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core).
=======
* See [Secret](/docs/api-reference/{{page.version}}/#secret-v1-core).
* See the `imagePullSecrets` field of [PodSpec](/docs/api-reference/{{page.version}}/#podspec-v1-core).
>>>>>>> merge master to 1.10, with fixes (#7682)
{% endcapture %}
docs/tasks/debug-application-cluster/events-stackdriver.md
+8
View File
@@ -1,5 +1,13 @@
---
<<<<<<< HEAD
reviewers:
||||||| merged common ancestors
approvers:
- crassirostris
=======
reviewers:
- crassirostris
>>>>>>> merge master to 1.10, with fixes (#7682)
- piosz
- x13n
title: Events in Stackdriver
docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+8
View File
@@ -1,5 +1,13 @@
---
<<<<<<< HEAD
reviewers:
||||||| merged common ancestors
approvers:
- crassirostris
=======
reviewers:
- crassirostris
>>>>>>> merge master to 1.10, with fixes (#7682)
- piosz
- x13n
title: Logging Using Elasticsearch and Kibana
docs/tasks/debug-application-cluster/logging-stackdriver.md
+8
View File
@@ -1,5 +1,13 @@
---
<<<<<<< HEAD
reviewers:
||||||| merged common ancestors
approvers:
- crassirostris
=======
reviewers:
- crassirostris
>>>>>>> merge master to 1.10, with fixes (#7682)
- piosz
- x13n
title: Logging Using Stackdriver
docs/tasks/run-application/update-api-object-kubectl-patch.md
+83
View File
@@ -127,6 +127,7 @@ containers:
### Notes on the strategic merge patch
The patch you did in the preceding exercise is called a *strategic merge patch*.
<<<<<<< HEAD
Notice that the patch did not replace the `containers` list. Instead it added a new
Container to the list. In other words, the list in the patch was merged with the
existing list. This is not always what happens when you use a strategic merge patch on a list.
@@ -202,6 +203,88 @@ type PodSpec struct {
...
Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
```
||||||| merged common ancestors
With a strategic merge patch, you can update a list by specifying only the elements
that you want to add to the list. The existing list elements remain, and the new elements
are merged with the existing elements. In the preceding exercise, the resulting `containers`
list has both the original nginx Container and the new redis Container.
=======
Notice that the patch did not replace the `containers` list. Instead it added a new
Container to the list. In other words, the list in the patch was merged with the
existing list. This is not always what happens when you use a strategic merge patch on a list.
In some cases, the list is replaced, not merged.
With a strategic merge patch, a list is either replaced or merged depending on its
patch strategy. The patch strategy is specified by the value of the `patchStrategy` key
in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec`
struct has a `patchStrategy` of `merge`:
```go
type PodSpec struct {
...
Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`
```
You can also see the patch strategy in the
[OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
```json
"io.k8s.api.core.v1.PodSpec": {
...
"containers": {
"description": "List of containers belonging to the pod. ...
},
"x-kubernetes-patch-merge-key": "name",
"x-kubernetes-patch-strategy": "merge"
},
```
And you can see the patch strategy in the
[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/v1.9/#podspec-v1-core).
Create a file named `patch-file-tolerations.yaml` that has this content:
```yaml
spec:
template:
spec:
tolerations:
- effect: NoSchedule
key: disktype
value: ssd
```
Patch your Deployment:
```shell
kubectl patch deployment patch-demo --patch "$(cat patch-file-tolerations.yaml)"
```
View the patched Deployment:
```shell
kubectl get deployment patch-demo --output yaml
```
The output shows that the PodSpec in the Deployment has only one Toleration:
```shell
tolerations:
- effect: NoSchedule
key: disktype
value: ssd
```
Notice that the `tolerations` list in the PodSpec was replaced, not merged. This is because
the Tolerations field of PodSpec does not have a `patchStrategy` key in its field tag. So the
strategic merge patch uses the default patch strategy, which is `replace`.
```go
type PodSpec struct {
...
Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
```
>>>>>>> merge master to 1.10, with fixes (#7682)
## Use a JSON merge patch to update a Deployment
docs/tasks/tools/install-kubectl.md
+128
View File
@@ -184,6 +184,126 @@ kubectl can be installed as part of the Google Cloud SDK.
{% include tabs.md %}
<<<<<<< HEAD
||||||| merged common ancestors
## Download as part of the Google Cloud SDK
kubectl can be installed as part of the Google Cloud SDK.
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
2. Run the following command to install `kubectl`:
gcloud components install kubectl
3. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with snap on Ubuntu
kubectl is available as a [snap](https://snapcraft.io/) application.
1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
sudo snap install kubectl --classic
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with Homebrew on macOS
1. If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install with:
brew install kubectl
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with Powershell from PSGallery
1. If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update with:
Install-Script -Name install-kubectl -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
If no Downloadlocation is specified, kubectl will be installed in users temp Directory
2. The installer creates $HOME/.kube and instucts to create a config file
3. Updating
re-run Install-Script to update the installer
re-run install-kubectl.ps1 to install latest binaries
## Install with Chocolatey on Windows
1. If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install with:
choco install kubernetes-cli
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
3. Configure kubectl to use a remote Kubernetes cluster:
cd C:\users\yourusername (Or wherever your %HOME% directory is)
mkdir .kube
cd .kube
touch config
Edit the config file with a text editor of your choice, such as Notepad for example.
=======
## Download as part of the Google Cloud SDK
kubectl can be installed as part of the Google Cloud SDK.
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
2. Run the following command to install `kubectl`:
gcloud components install kubectl
3. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with snap on Ubuntu
kubectl is available as a [snap](https://snapcraft.io/) application.
1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
sudo snap install kubectl --classic
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with Homebrew on macOS
1. If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install with:
brew install kubectl
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
## Install with Powershell from PSGallery
1. If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update with:
Install-Script -Name install-kubectl -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
If no Downloadlocation is specified, kubectl will be installed in users temp Directory
2. The installer creates $HOME/.kube and instructs it to create a config file
3. Updating
re-run Install-Script to update the installer
re-run install-kubectl.ps1 to install latest binaries
## Install with Chocolatey on Windows
1. If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install with:
choco install kubernetes-cli
2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
3. Configure kubectl to use a remote Kubernetes cluster:
cd C:\users\yourusername (Or wherever your %HOME% directory is)
mkdir .kube
cd .kube
New-Item config -type file
Edit the config file with a text editor of your choice, such as Notepad for example.
>>>>>>> merge master to 1.10, with fixes (#7682)
## Configure kubectl
In order for kubectl to find and access a Kubernetes cluster, it needs a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), which is created automatically when you create a cluster using kube-up.sh or successfully deploy a Minikube cluster. See the [getting started guides](/docs/setup/) for more about creating clusters. If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
@@ -202,9 +322,17 @@ If you see a message similar to the following, kubectl is not correctly configur
```shell
The connection to the server <server-name:port> was refused - did you specify the right host or port?
```
<<<<<<< HEAD
For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like minikube to be installed first and then re-run the commands stated above.
||||||| merged common ancestors
=======
For example, if you are intending to run a Kubernetes cluster on your laptop (locally), you will need a tool like minikube to be installed first and then re-run the commands stated above.
>>>>>>> merge master to 1.10, with fixes (#7682)
If kubectl cluster-info returns the url response but you can't access your cluster, to check whether it is configured properly, use:
```shell