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

Consolidate YAML files [part-8] (#9347)

Browse Source 
* Consolidate YAML files [part-8]

This PR exacts the YAML files referenced from the following subdirs:

- docs/concepts/workloads
- docs/concepts/configuration
- docs/concepts/policy

The following problems are fixed:

- docs/concepts/workloads/controllers/ doesnt have a 'cronjob.yaml for
  test
- the exactly same `pod.yaml` was used in both the task/config-pod-container
  topic and the concepts/configuration topics.

* Update examples_test.go

* Add missing yaml file.
This commit is contained in:
Qiming
2018-07-03 08:35:20 +08:00
committed by k8s-ci-robot
parent 1b914f4ac7
commit b5f6df9926
26 changed files with 58 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/configuration/assign-pod-node.md
+8 -5
View File
@@ -68,9 +68,12 @@ spec:
Then add a nodeSelector like so:
{{< code file="pod.yaml" >}}
{{< codenew file="pods/pod-nginx.yaml" >}}
When you then run `kubectl create -f pod.yaml`, the pod will get scheduled on the node that you attached the label to! You can verify that it worked by running `kubectl get pods -o wide` and looking at the "NODE" that the pod was assigned to.
When you then run `kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml`,
the Pod will get scheduled on the node that you attached the label to. You can
verify that it worked by running `kubectl get pods -o wide` and looking at the
"NODE" that the Pod was assigned to.
## Interlude: built-in node labels
@@ -133,7 +136,7 @@ Node affinity is specified as field `nodeAffinity` of field `affinity` in the Po
Here's an example of a pod that uses node affinity:
{{< code file="pod-with-node-affinity.yaml" >}}
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
This node affinity rule says the pod can only be placed on a node with a label whose key is
`kubernetes.io/e2e-az-name` and whose value is either `e2e-az1` or `e2e-az2`. In addition,
@@ -188,7 +191,7 @@ And inter-pod anti-affinity is specified as field `podAntiAffinity` of field `af
#### An example of a pod that uses pod affinity:
{{< code file="pod-with-pod-affinity.yaml" >}}
{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
The affinity on this pod defines one pod affinity rule and one pod anti-affinity rule. In this example, the
`podAffinity` is `requiredDuringSchedulingIgnoredDuringExecution`
@@ -344,4 +347,4 @@ as well, which allow a *node* to *repel* a set of pods.
{{% capture whatsnext %}}
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/configuration/commands.yaml
-13
View File
@@ -1,13 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: command-demo
labels:
purpose: demonstrate-command
spec:
containers:
- name: command-demo-container
image: debian
command: ["printenv"]
args: ["HOSTNAME", "KUBERNETES_PORT"]
restartPolicy: OnFailure
content/en/docs/concepts/configuration/pod-with-node-affinity.yaml
-26
View File
@@ -1,26 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0
content/en/docs/concepts/configuration/pod-with-pod-affinity.yaml
-29
View File
@@ -1,29 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: kubernetes.io/hostname
containers:
- name: with-pod-affinity
image: k8s.gcr.io/pause:2.0
content/en/docs/concepts/configuration/pod.yaml
-13
View File
@@ -1,13 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd
content/en/docs/concepts/policy/example-psp.yaml
-17
View File
@@ -1,17 +0,0 @@
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: example
spec:
privileged: false # Don't allow privileged pods!
# The rest fills in some required fields.
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'
content/en/docs/concepts/policy/pod-security-policy.md
+4 -4
View File
@@ -194,7 +194,7 @@ $ alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -
Define the example PodSecurityPolicy object in a file. This is a policy that
simply prevents the creation of privileged pods.
{{< code file="example-psp.yaml" >}}
{{< codenew file="policy/example-psp.yaml" >}}
And create it with kubectl:
@@ -355,13 +355,13 @@ podsecuritypolicy "example" deleted
This is the least restricted policy you can create, equivalent to not using the
pod security policy admission controller:
{{< code file="privileged-psp.yaml" >}}
{{< codenew file="policy/privileged-psp.yaml" >}}
This is an example of a restrictive policy that requires users to run as an
unprivileged user, blocks possible escalations to root, and requires use of
several security mechanisms.
{{< code file="restricted-psp.yaml" >}}
{{< codenew file="policy/restricted-psp.yaml" >}}
## Policy Reference
@@ -574,4 +574,4 @@ default cannot be changed.
Controlled via annotations on the PodSecurityPolicy. Refer to the [Sysctl documentation](
/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy-annotations).
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/policy/privileged-psp.yaml
-27
View File
@@ -1,27 +0,0 @@
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: privileged
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
privileged: true
allowPrivilegeEscalation: true
allowedCapabilities:
- '*'
volumes:
- '*'
hostNetwork: true
hostPorts:
- min: 0
max: 65535
hostIPC: true
hostPID: true
runAsUser:
rule: 'RunAsAny'
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'RunAsAny'
fsGroup:
rule: 'RunAsAny'
content/en/docs/concepts/policy/restricted-psp.yaml
-48
View File
@@ -1,48 +0,0 @@
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default'
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
# This is redundant with non-root + disallow privilege escalation,
# but we can provide it for defense in depth.
requiredDropCapabilities:
- ALL
# Allow core volume types.
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that persistentVolumes set up by the cluster admin are safe to use.
- 'persistentVolumeClaim'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
seLinux:
# This policy assumes the nodes are using AppArmor rather than SELinux.
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
readOnlyRootFilesystem: false
content/en/docs/concepts/workloads/controllers/daemonset.md
+3 -3
View File
@@ -39,11 +39,11 @@ different flags and/or different memory and cpu requests for different hardware
You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
{{< code file="daemonset.yaml" >}}
{{< codenew file="controllers/daemonset.yaml" >}}
* Create a DaemonSet based on the YAML file:
```
kubectl create -f daemonset.yaml
kubectl create -f https://k8s.io/examples/controllers/daemonset.yaml
```
### Required Fields
@@ -252,4 +252,4 @@ number of replicas and rolling out updates are more important than controlling e
the Pod runs on. Use a DaemonSet when it is important that a copy of a Pod always run on
all or certain hosts, and when it needs to start before other Pods.
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/daemonset.yaml
-42
View File
@@ -1,42 +0,0 @@
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: k8s.gcr.io/fluentd-elasticsearch:1.20
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
content/en/docs/concepts/workloads/controllers/deployment.md
+3 -3
View File
@@ -40,7 +40,7 @@ The following are typical use cases for Deployments:
The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods:
{{< code file="nginx-deployment.yaml" >}}
{{< codenew file="controllers/nginx-deployment.yaml" >}}
In this example:
@@ -71,7 +71,7 @@ The `template` field contains the following instructions:
To create this Deployment, run the following command:
```shell
kubectl create -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/docs/concepts/workloads/controllers/nginx-deployment.yaml
kubectl create -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
{{< note >}}
@@ -417,7 +417,7 @@ First, check the revisions of this deployment:
$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record
1 kubectl create -f https://k8s.io/examples/controllers/nginx-deployment.yaml --record
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91
```
content/en/docs/concepts/workloads/controllers/frontend.yaml
-39
View File
@@ -1,39 +0,0 @@
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# this replicas value is default
# modify it according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
matchExpressions:
- {key: tier, operator: In, values: [frontend]}
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
# If your cluster config does not include a dns service, then to
# instead access environment variables to find service host
# info, comment out the 'value: dns' line above, and uncomment the
# line below.
# value: env
ports:
- containerPort: 80
content/en/docs/concepts/workloads/controllers/garbage-collection.md
+8 -8
View File
@@ -36,17 +36,17 @@ setting the `ownerReference` field.
Here's a configuration file for a ReplicaSet that has three Pods:
{{< code file="my-repset.yaml" >}}
{{< codenew file="controllers/replicaset.yaml" >}}
If you create the ReplicaSet and then view the Pod metadata, you can see
OwnerReferences field:
```shell
kubectl create -f https://k8s.io/docs/concepts/controllers/my-repset.yaml
kubectl create -f https://k8s.io/examples/controllers/replicaset.yaml
kubectl get pods --output=yaml
```
The output shows that the Pod owner is a ReplicaSet named my-repset:
The output shows that the Pod owner is a ReplicaSet named `my-repset`:
```shell
apiVersion: v1
@@ -110,15 +110,15 @@ field on the `deleteOptions` argument when deleting an Object. Possible values i
Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`.
This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and
Deployment. For kinds in the extensions/v1beta1, apps/v1beta1, and apps/v1beta2 group versions, unless you
specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the apps/v1
Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you
specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1`
group version, dependent objects are deleted by default.
Here's an example that deletes dependents in background:
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
```
@@ -127,7 +127,7 @@ Here's an example that deletes dependents in foreground:
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
```
@@ -136,7 +136,7 @@ Here's an example that orphans dependents:
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
```
content/en/docs/concepts/workloads/controllers/hpa-rs.yaml
-11
View File
@@ -1,11 +0,0 @@
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: frontend-scaler
spec:
scaleTargetRef:
kind: ReplicaSet
name: frontend
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 50
content/en/docs/concepts/workloads/controllers/job.yaml
-14
View File
@@ -1,14 +0,0 @@
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md
+3 -3
View File
@@ -31,12 +31,12 @@ A Job can also be used to run multiple pods in parallel.
Here is an example Job config. It computes π to 2000 places and prints it out.
It takes around 10s to complete.
{{< code file="job.yaml" >}}
{{< codenew file="controllers/job.yaml" >}}
Run the example job by downloading the example file and then running this command:
```shell
$ kubectl create -f ./job.yaml
$ kubectl create -f https://k8s.io/examples/controllers/job.yaml
job "pi" created
```
@@ -401,4 +401,4 @@ object, but complete control over what pods are created and how work is assigned
Support for creating Jobs at specified times/dates (i.e. cron) is available in Kubernetes [1.4](https://github.com/kubernetes/kubernetes/pull/11980). More information is available in the [cron job documents](/docs/concepts/workloads/controllers/cron-jobs/)
{{% /capture %}}
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/my-repset.yaml
-17
View File
@@ -1,17 +0,0 @@
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-repset
spec:
replicas: 3
selector:
matchLabels:
pod-is-for: garbage-collection-example
template:
metadata:
labels:
pod-is-for: garbage-collection-example
spec:
containers:
- name: nginx
image: nginx
content/en/docs/concepts/workloads/controllers/nginx-deployment.yaml
-21
View File
@@ -1,21 +0,0 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
content/en/docs/concepts/workloads/controllers/replicaset.md
+4 -4
View File
@@ -51,13 +51,13 @@ use a Deployment instead, and define your application in the spec section.
## Example
{{< code file="frontend.yaml" >}}
{{< codenew file="controllers/frontend.yaml" >}}
Saving this manifest into `frontend.yaml` and submitting it to a Kubernetes cluster should
create the defined ReplicaSet and the pods that it manages.
```shell
$ kubectl create -f frontend.yaml
$ kubectl create -f http://k8s.io/examples/controllers/frontend.yaml
replicaset "frontend" created
$ kubectl describe rs/frontend
Name: frontend
@@ -192,14 +192,14 @@ A ReplicaSet can also be a target for
a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
the ReplicaSet we created in the previous example.
{{< code file="hpa-rs.yaml" >}}
{{< codenew file="controllers/hpa-rs.yaml" >}}
Saving this manifest into `hpa-rs.yaml` and submitting it to a Kubernetes cluster should
create the defined HPA that autoscales the target ReplicaSet depending on the CPU usage
of the replicated pods.
```shell
kubectl create -f hpa-rs.yaml
kubectl create -f https://k8s.io/examples/controllers/hpa-rs.yaml
```
Alternatively, you can use the `kubectl autoscale` command to accomplish the same
content/en/docs/concepts/workloads/controllers/replication.yaml
-19
View File
@@ -1,19 +0,0 @@
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+2 -2
View File
@@ -44,12 +44,12 @@ service, such as web servers.
This example ReplicationController config runs three copies of the nginx web server.
{{< code file="replication.yaml" >}}
{{< codenew file="controllers/replication.yaml" >}}
Run the example job by downloading the example file and then running this command:
```shell
$ kubectl create -f ./replication.yaml
$ kubectl create -f https://k8s.io/examples/controllers/replication.yaml
replicationcontroller "nginx" created
```
content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md
+2 -3
View File
@@ -57,12 +57,12 @@ This pod configuration file describes a pod that has a node selector,
`disktype: ssd`. This means that the pod will get scheduled on a node that has
a `disktype=ssd` label.
{{< code file="pod.yaml" >}}
{{< codenew file="pods/pod-nginx.yaml" >}}
1. Use the configuration file to create a pod that will get scheduled on your
chosen node:
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod.yaml
kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml
1. Verify that the pod is running on your chosen node:
@@ -80,4 +80,3 @@ Learn more about
[labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
{{% /capture %}}
content/en/docs/tasks/configure-pod-container/pod.yaml
-13
View File
@@ -1,13 +0,0 @@
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd