Skip to content

Commit

Permalink
fix: use yml in markdown (#27)
Browse files Browse the repository at this point in the history
  • Loading branch information
ElPicador committed May 21, 2019
1 parent a618a76 commit cfa5d4e
Show file tree
Hide file tree
Showing 7 changed files with 14 additions and 14 deletions.
4 changes: 2 additions & 2 deletions 10-secrets/README.md
Expand Up @@ -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:
Expand All @@ -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:
Expand Down
8 changes: 4 additions & 4 deletions 11-probes/README.md
Expand Up @@ -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:
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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
Expand Down
6 changes: 3 additions & 3 deletions 13-affinity-anti-affinity/README.md
Expand Up @@ -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:
Expand Down Expand Up @@ -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:
Expand Down Expand Up @@ -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:
Expand Down
2 changes: 1 addition & 1 deletion 14-pdb/README.md
Expand Up @@ -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:
Expand Down
4 changes: 2 additions & 2 deletions 15-hpa-vpa/README.md
Expand Up @@ -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:
Expand Down Expand Up @@ -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:
Expand Down
2 changes: 1 addition & 1 deletion 17-volumes/README.md
Expand Up @@ -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:
Expand Down
2 changes: 1 addition & 1 deletion 18-stateful-set/README.md
Expand Up @@ -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:
Expand Down

0 comments on commit cfa5d4e

Please sign in to comment.