kubernetes簡(jiǎn)介
kubernetes，簡(jiǎn)稱(chēng)K8s，是用8代替8個(gè)字符“ubernete”而成的縮寫(xiě)。是一個(gè)開(kāi)源的，用于管理云平臺(tái)中多個(gè)主機(jī)上的容器化的應(yīng)用，Kubernetes的目標(biāo)是讓部署容器化的應(yīng)用簡(jiǎn)單并且高效（powerful）,Kubernetes提供了應(yīng)用部署，規(guī)劃，更新，維護(hù)的一種機(jī)制。
Pod簡(jiǎn)介
Pod是Kubernetes創(chuàng)建或部署的最小/最簡(jiǎn)單的基本單位，一個(gè)Pod代表集群上正在運(yùn)行的一個(gè)進(jìn)程。
一個(gè)Pod封裝一個(gè)應(yīng)用容器（也可以有多個(gè)容器），存儲(chǔ)資源、一個(gè)獨(dú)立的網(wǎng)絡(luò)IP以及管理控制容器運(yùn)行方式的策略選項(xiàng)。Pod代表部署的一個(gè)單位：Kubernetes中單個(gè)應(yīng)用的實(shí)例，它可能由單個(gè)容器或多個(gè)容器共享組成的資源。
通常情況下，使用的都是k8s默認(rèn)的調(diào)度調(diào)度方式，但是在有些情況下，我們需要將pod運(yùn)行在具有特點(diǎn)的標(biāo)簽的node上才能都運(yùn)行，這個(gè)時(shí)候，pod的調(diào)度策略就不能使用k8s默認(rèn)的調(diào)度策略了，這個(gè)時(shí)候，就需要指定調(diào)度策略，告訴k8s需要將pod調(diào)度到那些node（節(jié)點(diǎn)）上。
nodeSelector
常規(guī)情況下，會(huì)直接使用nodeSelector這種調(diào)度策略。labels（標(biāo)簽） 是k8s里面用來(lái)編標(biāo)記資源的一種常用的方式，我們可以給node標(biāo)記特殊的標(biāo)簽，然后nodeSelector會(huì)將pod調(diào)度到帶有指定labels的node上的。
下面看個(gè)示例：
首先，查看node的label信息，通過(guò)下面的命令查看的 node 的 label：
重慶分公司
重慶分公司
$ kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 147d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=
node02 Ready 67d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,course=k8s,kubernetes.io/hostname=node02
node03 Ready 127d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,jnlp=haimaxy,kubernetes.io/hostname=node03 然后，可以給node02節(jié)點(diǎn)新增一個(gè)label：
$ kubectl label nodes node02 com=yijiadashuju
node "node02" labeled然后通過(guò)上面的--show-labels參數(shù)可以查看上述標(biāo)簽是否生效。當(dāng) node 被打上了相關(guān)標(biāo)簽后，在調(diào)度的時(shí)候就可以使用這些標(biāo)簽了，只需要在 Pod 的spec字段中添加nodeSelector字段，里面是我們需要被調(diào)度的節(jié)點(diǎn)的 label 即可。比如，要將 Pod 我們要強(qiáng)制調(diào)度到 node02 這個(gè)節(jié)點(diǎn)上去，可以使用 nodeSelector 來(lái)表示了：(pod-selector-demo.yaml)
apiVersion: v1
kind: Pod
metadata:
labels:
app: busybox-pod
name: test-busybox
spec:
containers:
- command:
- sleep
- "3600"
image: busybox
imagePullPolicy: Always
name: test-busybox
nodeSelector:
com: yijiadashuju然后，執(zhí)行pod-selector-demo.yaml文件后，可以通過(guò)下面的命令查看pod運(yùn)行的節(jié)點(diǎn)信息
kubectl get pod -o wide -n default也可以使用description命令查看pod被調(diào)度到哪個(gè)節(jié)點(diǎn)上：
$ kubectl create -f pod-selector-demo.yaml
pod "test-busybox" created
$ kubectl describe pod test-busybox
Name: test-busybox
Namespace: default
Node: node02/10.151.30.63
......
QoS Class: BestEffort
Node-Selectors: com=youdianzhishi
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulMountVolume 55s kubelet, node02 MountVolume.SetUp succeeded for volume "default-token-n9w2d"
Normal Scheduled 54s default-scheduler Successfully assigned test-busybox to node02
Normal Pulling 54s kubelet, node02 pulling image "busybox"
Normal Pulled 40s kubelet, node02 Successfully pulled image "busybox"
Normal Created 40s kubelet, node02 Created container
Normal Started 40s kubelet, node02 Started container從上面的執(zhí)行結(jié)果可以看出，pod 通過(guò)默認(rèn)的 default-scheduler 調(diào)度器到了node02節(jié)點(diǎn)上。不過(guò)，這種調(diào)度方式屬于強(qiáng)制性的。如果node02上的資源不足，那么pod的狀態(tài)將會(huì)一直是pending狀態(tài)。這就是nodeselector的用法了。
通過(guò)上面的介紹，可以看出nodeselector使用起來(lái)非常方便，但是還有很多的不足，那就是不夠靈活，控制粒度偏大，在實(shí)際使用中還是有許多的不便。接下來(lái)一起看先親和性和反親和性調(diào)度。
k8s的默認(rèn)調(diào)度流程實(shí)際上是經(jīng)過(guò)了兩個(gè)階段：predicates 和 priorities 。使用默認(rèn)的調(diào)度流程的話(huà)，k8s會(huì)將pod調(diào)度到資源充裕的節(jié)點(diǎn)上，使用nodeselector的調(diào)度方法，又會(huì)將pod調(diào)度具有指定標(biāo)簽的pod上。然后在實(shí)際生產(chǎn)環(huán)ongoing境中，我們需要將pod調(diào)度到具有默些label的一組node才能滿(mǎn)足實(shí)際需求，這個(gè)時(shí)候就需要nodeAffinity(節(jié)點(diǎn)親和性)、podAffinity(pod 親和性) 以及 podAntiAffinity(pod 反親和性)。
親和性可以分為具體可以細(xì)分為硬和軟兩種親和性，
軟親和性：如果調(diào)度的時(shí)候，沒(méi)有滿(mǎn)足要求，也可以繼續(xù)調(diào)度，即能滿(mǎn)足最好，不能也無(wú)所謂
硬親和性：是指調(diào)度的時(shí)候必須滿(mǎn)足特定的要求，如果不滿(mǎn)足，那么pod將不會(huì)被調(diào)度到當(dāng)前node
規(guī)則可以設(shè)置：
軟策略: preferredDuringSchedulingIgnoredDuringExecution
硬策略: requiredDuringSchedulingIgnoredDuringExecution
nodeAffinity 節(jié)點(diǎn)親和性
節(jié)點(diǎn)親和性主要是用來(lái)控制 pod 能部署在哪些節(jié)點(diǎn)上，以及不能部署在哪些節(jié)點(diǎn)上的。它可以進(jìn)行一些簡(jiǎn)單的邏輯組合了，不只是簡(jiǎn)單的相等匹配。
接下來(lái)看一個(gè)示例，使用 Deployment 來(lái)管理3個(gè) pod 副本，使用nodeAffinity控制 pod 的調(diào)度，如下例子：（node-affinity-demo.yaml）
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: affinity
labels:
app: affinity
spec:
replicas: 3
revisionHistoryLimit: 15
template:
metadata:
labels:
app: affinity
role: test
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
name: nginxweb
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution: # 硬策略
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: NotIn
values:
- node03
preferredDuringSchedulingIgnoredDuringExecution: # 軟策略
- weight: 1
preference:
matchExpressions:
- key: com
operator: In
values:
- yijiadashuju這個(gè)pod調(diào)度的時(shí)候，首先要求不能運(yùn)行在node03節(jié)點(diǎn)上，但是如果有節(jié)點(diǎn)滿(mǎn)足labels為com：yijiadashuju 的話(huà)，就會(huì)優(yōu)先調(diào)度到這個(gè)節(jié)點(diǎn)上。
接下來(lái)看下節(jié)點(diǎn)信息：
$ kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 154d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=
node02 Ready 74d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,com=yijiadashuju,course=k8s,kubernetes.io/hostname=node02
node03 Ready 134d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,jnlp=haimaxy,kubernetes.io/hostname=node03 可以看到 node02 節(jié)點(diǎn)有com=yijiadashuju的 label，按要求會(huì)優(yōu)先調(diào)度到這個(gè)節(jié)點(diǎn)，接下來(lái)創(chuàng)建 pod，然后使用descirbe命令查看調(diào)度情況。
$ kubectl create -f node-affinity-demo.yaml
deployment.apps "affinity" created
$ kubectl get pods -l app=affinity -o wide
NAME READY STATUS RESTARTS AGE IP NODE
affinity-7b4c946854-5gfln 1/1 Running 0 47s 10.244.4.214 node02
affinity-7b4c946854-l8b47 1/1 Running 0 47s 10.244.4.215 node02
affinity-7b4c946854-r86p5 1/1 Running 0 47s 10.244.4.213 node02從結(jié)果可以看到 pod 均被部署到了 node02節(jié)點(diǎn)。
現(xiàn)在Kubernetes提供的操作符有下面的幾種
In：label 的值在某個(gè)標(biāo)簽中
NotIn：label 的值不在某個(gè)標(biāo)簽中
Gt：label 的值大于某個(gè)值
Lt：label 的值小于某個(gè)值
Exists：某個(gè) label 存在
DoesNotExist：某個(gè) label 不存在如果nodeSelectorTerms下面有多個(gè)選項(xiàng)的話(huà)，滿(mǎn)足任何一個(gè)條件就可以了；如果matchExpressions有多個(gè)選項(xiàng)的話(huà)，則必須同時(shí)滿(mǎn)足這些條件才能正常調(diào)度 POD。
pod的親和性主要用來(lái)解決pod可以和哪些pod部署在同一個(gè)集群里面，即拓?fù)溆颍ㄓ蒼ode組成的集群）里面；而pod的反親和性是為了解決pod不能和哪些pod部署在一起的問(wèn)題，二者都是為了解決pod之間部署問(wèn)題。需要注意的是，Pod 間親和與反親和需要大量的處理，這可能會(huì)顯著減慢大規(guī)模集群中的調(diào)度，不建議在具有幾百個(gè)節(jié)點(diǎn)的集群中使用，而且Pod 反親和需要對(duì)節(jié)點(diǎn)進(jìn)行一致的標(biāo)記，即集群中的每個(gè)節(jié)點(diǎn)必須具有適當(dāng)?shù)臉?biāo)簽?zāi)軌蚱ヅ?nbsp;topologyKey。如果某些或所有節(jié)點(diǎn)缺少指定的 topologyKey 標(biāo)簽，可能會(huì)導(dǎo)致意外行為。
下面是pod間親和的示例：
pods/pod-with-pod-affinity.yaml：
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: failure-domain.beta.kubernetes.io/zone
containers:
- name: with-pod-affinity
image: k8s.gcr.io/pause:2.0下面是一個(gè)pod反親和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另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性?xún)r(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專(zhuān)為企業(yè)上云打造定制，能夠滿(mǎn)足用戶(hù)豐富、多元化的應(yīng)用場(chǎng)景需求。
