fix: use yml in markdown
This commit is contained in:
parent
a618a76282
commit
cd728e658e
|
@ -26,7 +26,7 @@ You can reference a secret from a pod, either per env variable or mounting a vol
|
|||
|
||||
Here we mount the secret `mysecret` to the path `/etc/foo` inside the pod:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
@ -48,7 +48,7 @@ spec:
|
|||
Here we bind the value `username` from the secret `mysecret` to the env variable `SECRET_USERNAME`,
|
||||
`password` from the secret `mysecret` to the env variable `SECRET_PASSWORD`:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
|
|
@ -26,7 +26,7 @@ Both liveness and readiness probes have the same configuration. You have three w
|
|||
|
||||
The `exec` probe let you configure a command that Kubernetes will run in your container. If the command exits with a non zero status the probe will be considered unhealthy:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
|
@ -43,7 +43,7 @@ We will see later what `initialDelaySeconds` and `periodSeconds` means.
|
|||
|
||||
The `http` probe let you configure a HTTP endpoint that Kubernetes will call in your container. If this endpoint returns a non 2XX status the probe will be considered unhealthy:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
|
@ -65,7 +65,7 @@ The `http` probe has two mandatory fields `path` and `port` and one optional `ht
|
|||
|
||||
The `tcp` probe let you configure a TCP port that Kubernetes will try to connect to. If it does not manage to establish a connection the probe will be considered unhealthy:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
livenessProbe:
|
||||
tcpSocket:
|
||||
port: 8080
|
||||
|
@ -81,7 +81,7 @@ The `periodSeconds` field specifies that Kubernetes should perform the probe eve
|
|||
|
||||
If we take the example:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
|
|
|
@ -20,7 +20,7 @@ Hinting Kubernetes to run multiple pods on different nodes is a good way to impr
|
|||
|
||||
The `affinity` is specified at the pod level. The configuration for `podAffinity` or `podAntiAffinity` is the same. So let's look at a `podAntiAffinity`.
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
@ -56,7 +56,7 @@ In english words, this configuration means that we want to ensure that pods with
|
|||
|
||||
You also have `preferredDuringSchedulingIgnoredDuringExecution` to not require but only hints the scheduler. Carefull the configuration for this is different:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
@ -115,7 +115,7 @@ Here we add the label `gpu` with value `yes` to the node `node1`.
|
|||
|
||||
You can force a pod to be scheduled on a specific node by adding right `nodeAffinity` to the spec of it. Here we would like to pod to be scheduled on a node with the label `gpu=yes`
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
|
|
|
@ -12,7 +12,7 @@ Defining a “Pod Disruption Budget” helps Kubernetes manage your pods when a
|
|||
|
||||
A `PDB` is configured as this:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodDisruptionBudget
|
||||
metadata:
|
||||
|
|
|
@ -6,7 +6,7 @@ HPA means `Horizontal Pod Autoscaler`. It automatically scales the number of pod
|
|||
|
||||
Let's take an example with CPU usage:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: autoscaling/v1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
|
@ -101,7 +101,7 @@ kubectl apply -f examples/hamster.yaml
|
|||
|
||||
Look at the file [hamster.yaml](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler/examples). It contains the VPA definition:
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: "autoscaling.k8s.io/v1beta2"
|
||||
kind: VerticalPodAutoscaler
|
||||
metadata:
|
||||
|
|
|
@ -20,7 +20,7 @@ Let's create the volume where our mysql data will be stored.
|
|||
|
||||
First we create the `PersistentVolume`. It is a piece of storage in the cluster that has been provisioned by a cluster administrator. It is a resource in the cluster just like a node is a resource of the cluster.
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
|
|
|
@ -53,7 +53,7 @@ Like a `Deployment`, a `StatefulSet` manages Pods that are based on an identical
|
|||
* Ordered, graceful deployment and scaling
|
||||
* Ordered, automated rolling updates, ex: MySQL Master+Slave
|
||||
|
||||
```yaml
|
||||
```yml
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
|
|
Loading…
Reference in New Issue