Skip to content

Commit

Permalink
Assigning Pod and Affinity (#350)
Browse files Browse the repository at this point in the history 
* adding custom resource definition exercise to the workshop

* Fixing typo on title

* Adding Assigning and affinity chapter

* Change weight

* Adding exposing service chapter with ingress controller extra
  • Loading branch information
@mpdominguez @brentley
mpdominguez authored and brentley committed May 28, 2019
1 parent 26b6cfc commit 3ec6e6a
Show file tree
Hide file tree
Showing 13 changed files with 800 additions and 0 deletions.
16 changes: 16 additions & 0 deletions content/assigning_pods/_index.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
---
title: "Assigning Pods to Nodes"
chapter: true
weight: 54
---

# Assigning Pods to Nodes
### Introduction

In this Chapter, we will review how the strategy of assigning Pods works, alternatives and recommended approaches.

You can constrain a pod to only be able to run on particular nodes or to prefer to run on particular nodes.

Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement (e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.) but there are some circumstances where you may want more
control on a node where a pod lands, e.g. to ensure that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different services that communicate a lot into the same availability zone.

104 changes: 104 additions & 0 deletions content/assigning_pods/affinity.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
---
title: "Affinity and anti-affinity"
date: 2019-04-09T00:00:00-03:00
weight: 11
draft: false
---

#### Affinity and anti-affinity
nodeSelector provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity feature, currently in beta, greatly the types of constraints you can express. The key enhancements are:

- The language is more expressive (not just “AND of exact match”)
- You can indicate that the rule is “soft”/“preference” rather than a hard requirement, so if the scheduler can’t satisfy it, the pod will still be scheduled
- You can constrain against labels on other pods running on the node (or other topological domain), rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located

The affinity feature consists of two types of affinity, “node affinity” and “inter-pod affinity/anti-affinity”. Node affinity is like the existing nodeSelector (but with the first two benefits listed above), while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as described in the third item listed above, in addition to having the first and second properties listed above.

#### Node affinity (beta feature)
Node affinity was introduced as alpha in Kubernetes 1.2. Node affinity is conceptually similar to nodeSelector – it allows you to constrain which nodes your pod is eligible to be scheduled on, based on labels on the node.

There are currently two types of node affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and `preferredDuringSchedulingIgnoredDuringExecution`.

You can think of them as “hard” and “soft” respectively, in the sense that the former specifies rules that must be met for a pod to be scheduled onto a node (just like nodeSelector but using a more expressive syntax), while the latter specifies preferences that the scheduler will try to enforce but will not guarantee. The “IgnoredDuringExecution” part of the names means that, similar to how nodeSelector works, if labels on a node change at runtime such that the affinity rules on a pod are no longer met, the pod will still continue to run on the node.

Thus an example of `requiredDuringSchedulingIgnoredDuringExecution` would be “only run the pod on nodes with Intel CPUs” and an example `preferredDuringSchedulingIgnoredDuringExecution` would be “try to run this set of pods in availability zone XYZ, but if it’s not possible, then allow some to run elsewhere”.

Node affinity is specified as field nodeAffinity of field affinity in the PodSpec.


Let's see an example of a pod that uses node affinity:

We are going to create another label in the same node that in the last example:
```
kubectl label nodes ip-192-168-15-64.us-west-2.compute.internal azname=az1
```
And create an affinity:
```
cat <<EoF > ~/environment/pod-with-node-affinity.yaml
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: azname
operator: In
values:
- az1
- 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
EoF
```

This node affinity rule says the pod can only be placed on a node with a label whose key is `azname` and whose value is either `az1` or `az2`. In addition, among nodes that meet that criteria, nodes with a label whose key is another-node-label-key and whose value is another-node-label-value should be preferred.

Let's apply this
```
kubectl apply -f ~/environment/pod-with-node-affinity.yaml
```
And check if it worked with `kubectl get pods -o wide`
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx 1/1 Running 0 35m 192.168.10.13 ip-192-168-15-64.us-west-2.compute.internal <none>
with-node-affinity 1/1 Running 0 29s 192.168.14.121 ip-192-168-15-64.us-west-2.compute.internal <none>
```
Now let's try to put the affinity in another node
We are going to put the label in a different node so first, let's clean the label and delete the Pod.
```
kubectl delete -f ~/environment/pod-with-node-affinity.yaml
kubectl label nodes ip-192-168-15-64.us-west-2.compute.internal azname-
```
We are putting the label to the node ip-192-168-86-147.us-west-2.compute.internal now
```
kubectl label nodes ip-192-168-86-147.us-west-2.compute.internal azname=az1
kubectl apply -f ~/environment/pod-with-node-affinity.yaml
```
And check if it works with `kubectl get pods -o wide`
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx 1/1 Running 0 43m 192.168.10.13 ip-192-168-15-64.us-west-2.compute.internal <none>
with-node-affinity 1/1 Running 0 42s 192.168.68.249 ip-192-168-86-147.us-west-2.compute.internal <none>
```

You can see the operator In being used in the example. The new node affinity syntax supports the following operators: `In, NotIn, Exists, DoesNotExist, Gt, Lt`. You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior.

- If you specify both nodeSelector and nodeAffinity, both must be satisfied for the pod to be scheduled onto a candidate node.
- If you specify multiple nodeSelectorTerms associated with nodeAffinity types, then the pod can be scheduled onto a node if one of the nodeSelectorTerms is satisfied.
- If you specify multiple matchExpressions associated with nodeSelectorTerms, then the pod can be scheduled onto a node only if all matchExpressions can be satisfied.
- If you remove or change the label of the node where the pod is scheduled, the pod won’t be removed. In other words, the affinity selection works only at the time of scheduling the pod.

The weight field in `preferredDuringSchedulingIgnoredDuringExecution` is in the range 1-100. For each node that meets all of the scheduling requirements (resource request, RequiredDuringScheduling affinity expressions, etc.), the scheduler will compute a sum by iterating through the elements of this field and adding “weight” to the sum if the node matches the corresponding MatchExpressions. This score is then combined with the scores of other priority functions for the node. The node(s) with the highest total score are the most preferred.
115 changes: 115 additions & 0 deletions content/assigning_pods/affinity_usecases.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,115 @@
---
title: "More Practical use-cases"
date: 2019-04-09T00:00:00-03:00
weight: 12
draft: false
---

More Practical Use-cases
AntiAffinity can be even more useful when they are used with higher level collections such as ReplicaSets, StatefulSets, Deployments, etc. One can easily configure that a set of workloads should be co-located in the same defined topology, eg., the same node.

### Always co-located in the same node
In a three node cluster, a web application has in-memory cache such as redis. We want the web-servers to be co-located with the cache as much as possible.

Here is the yaml snippet of a simple redis deployment with three replicas and selector label app=store. The deployment has PodAntiAffinity configured to ensure the scheduler does not co-locate replicas on a single node.

```
cat <<EoF > ~/environment/redis-with-node-affinity.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-cache
spec:
selector:
matchLabels:
app: store
replicas: 3
template:
metadata:
labels:
app: store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: redis-server
image: redis:3.2-alpine
EoF
```

The below yaml snippet of the webserver deployment has podAntiAffinity and podAffinity configured. This informs the scheduler that all its replicas are to be co-located with pods that have selector label app=store. This will also ensure that each web-server replica does not co-locate on a single node.

```
cat <<EoF > ~/environment/web-with-node-affinity.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
selector:
matchLabels:
app: web-store
replicas: 3
template:
metadata:
labels:
app: web-store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-store
topologyKey: "kubernetes.io/hostname"
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: web-app
image: nginx:1.12-alpine
EoF
```
Let's apply this Deployments
```
kubectl apply -f ~/environment/redis-with-node-affinity.yaml
kubectl apply -f ~/environment/web-with-node-affinity.yaml
```

If we create the above two deployments, our three node cluster should look like below.

` node-1 - webserver-1 - cache-1 `

` node-2 - webserver-2 - cache-2 `

` node-3 - webserver-3 - cache-3 `

As you can see, all the 3 replicas of the web-server are automatically co-located with the cache as expected.

```
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3
redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1
redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2
web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1
web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3
web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2
```
14 changes: 14 additions & 0 deletions content/assigning_pods/cleaning.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
---
title: "Clean Up"
date: 2019-04-09T00:00:00-03:00
weight: 13
draft: false
---

### Cleaning up
To delete the resources used in this chapter:
```
kubectl delete -f ~/environment/pod-with-node-affinity.yaml
kubectl delete -f ~/environment/redis-with-node-affinity.yaml
kubectl delete -f ~/environment/web-with-node-affinity.yaml
```
92 changes: 92 additions & 0 deletions content/assigning_pods/node_selector.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
---
title: "nodeSelector"
date: 2019-04-09T00:00:00-03:00
weight: 10
draft: false
---

nodeSelector is the simplest recommended form of node selection constraint. nodeSelector is a field of PodSpec. It specifies a map of key-value pairs. For the pod to be eligible to run on a node, the node must have each of the indicated key-value pairs as labels (it can have additional labels as well). The most common usage is one key-value pair.

#### Attach a label to the node

Run kubectl get nodes to get the names of your cluster’s nodes.
```
kubectl get nodes
```
Output will be like
```
NAME STATUS ROLES AGE VERSION
ip-192-168-15-64.us-west-2.compute.internal Ready <none> 8d v1.12.7
ip-192-168-38-150.us-west-2.compute.internal Ready <none> 8d v1.12.7
ip-192-168-86-147.us-west-2.compute.internal Ready <none> 7d23h v1.12.7
ip-192-168-92-222.us-west-2.compute.internal Ready <none> 8d v1.12.7
```
Pick out the one that you want to add a label to, and then run
```
kubectl label nodes <node-name> <label-key>=<label-value>
```
to add a label to the node you’ve chosen.

For example, if my node name is ‘ip-192-168-15-64.us-west-2.compute.internal’ and my desired label is ‘disktype=ssd’, then I can run
```
kubectl label nodes ip-192-168-15-64.us-west-2.compute.internal disktype=ssd
```
You can verify that it worked by re-running kubectl get nodes --show-labels and checking that the node now has a label. You can also use kubectl describe node "nodename" to see the full list of labels of the given node.

```
kubectl get nodes --show-labels
```
Output will be like
```
NAME STATUS ROLES AGE VERSION LABELS
ip-192-168-15-64.us-west-2.compute.internal Ready <none> 8d v1.12.7 alpha.eksctl.io/cluster-name=eksworkshop-eksctl,alpha.eksctl.io/instance-id=i-064fdae0afd3cbe8b,alpha.eksctl.io/nodegroup-name=ng-cd62916d,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m5.large,beta.kubernetes.io/os=linux,disktype=ssd,failure-domain.beta.kubernetes.io/region=us-west-2,failure-domain.beta.kubernetes.io/zone=us-west-2d,kubernetes.io/hostname=ip-192-168-15-64.us-west-2.compute.internal
ip-192-168-38-150.us-west-2.compute.internal Ready <none> 8d v1.12.7 alpha.eksctl.io/cluster-name=eksworkshop-eksctl,alpha.eksctl.io/instance-id=i-0420598c17da0a4b4,alpha.eksctl.io/nodegroup-name=ng-cd62916d,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m5.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-west-2,failure-domain.beta.kubernetes.io/zone=us-west-2c,kubernetes.io/hostname=ip-192-168-38-150.us-west-2.compute.internal
ip-192-168-86-147.us-west-2.compute.internal Ready <none> 7d23h v1.12.7 alpha.eksctl.io/cluster-name=eksworkshop-eksctl,alpha.eksctl.io/instance-id=i-02e33f4429c64e628,alpha.eksctl.io/nodegroup-name=ng-cd62916d,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m5.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-west-2,failure-domain.beta.kubernetes.io/zone=us-west-2b,kubernetes.io/hostname=ip-192-168-86-147.us-west-2.compute.internal
ip-192-168-92-222.us-west-2.compute.internal Ready <none> 8d v1.12.7 alpha.eksctl.io/cluster-name=eksworkshop-eksctl,alpha.eksctl.io/instance-id=i-02eadff5d2af1ce12,alpha.eksctl.io/nodegroup-name=ng-cd62916d,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m5.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-west-2,failure-domain.beta.kubernetes.io/zone=us-west-2b,kubernetes.io/hostname=ip-192-168-92-222.us-west-2.compute.internal
```
#### Add a nodeSelector field to your pod configuration
Take whatever pod config file you want to run, and add a nodeSelector section to it, like this. For example, if this is my pod config:
```
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
```
Then add a nodeSelector like so:
```
cat <<EoF > ~/environment/pod-nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd
EoF
```
Then you run
```
kubectl apply -f ~/environment/pod-nginx.yaml
```
And 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
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx 1/1 Running 0 12s 192.168.10.13 ip-192-168-15-64.us-west-2.compute.internal <none>
```

12 changes: 12 additions & 0 deletions content/exposing_service/_index.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
---
title: "Exposing a Service"
chapter: true
weight: 55
---

# Exposing a Service
### Introduction

In this Chapter, we will review how to configure a Service, Deployment or Pod to be exposed outside our cluster. We will also review the different ways to do so.


Loading

0 comments on commit 3ec6e6a

Please sign in to comment.