ReplicationController:部署托管的pods

保持pod的健康

我们制作一个中途不能正常处理请求的服务版本,用于做实验
1
// cat app.js
2
const http = require('http');
3
const os = require('os');
4
5
console.log("Kubia server starting...");
6
7
var requestCount = 0;
8
9
var handler = function(request, response) {
10
console.log("Received request from " + request.connection.remoteAddress);
11
requestCount++;
12
if (requestCount > 5) { // 注意这里,请求超过5次会500错误
13
response.writeHead(500);
14
response.end("I'm not well. Please restart me!");
15
return;
16
}
17
response.writeHead(200);
18
response.end("You've hit " + os.hostname() + "\n");
19
};
20
21
var www = http.createServer(handler);
22
www.listen(8080);
Copied!
这段代码大家阅读理解就好,镜像的操作都已经做好了。直接用yaml部署它,体验一下
1
# cat kubia-liveness-probe.yaml
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
name: kubia-liveness
6
spec:
7
containers:
8
- image: luksa/kubia-unhealthy
9
name: kubia
10
livenessProbe: #注意这里增加了健康监测
11
httpGet: #http访问8080端口
12
path: /
13
port: 8080
Copied!
create并查看这个pod
1
$ kubectl create -f kubia-liveness-probe.yaml
2
pod/kubia-liveness created
3
4
$ kubectl describe pod kubia-liveness
5
6
Name: kubia-liveness
7
Containers:
8
kubia:
9
Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3
10
Events:
11
Type Reason Age From Message
12
---- ------ ---- ---- -------
13
Normal Scheduled 115s default-scheduler Successfully assigned liuzongxian/kubia-liveness to cn-hongkong.10.32.100.48
14
Normal Pulling 115s kubelet, cn-hongkong.10.32.100.48 Pulling image "luksa/kubia-unhealthy"
15
Normal Pulled 89s kubelet, cn-hongkong.10.32.100.48 Successfully pulled image "luksa/kubia-unhealthy"
16
Normal Created 89s kubelet, cn-hongkong.10.32.100.48 Created container kubia
17
Normal Started 89s kubelet, cn-hongkong.10.32.100.48 Started container kubia
18
Warning Unhealthy 10s (x3 over 30s) kubelet, cn-hongkong.10.32.100.48 Liveness probe failed: HTTP probe failed with statuscode: 500
19
Normal Killing 10s kubelet, cn-hongkong.10.32.100.48 Container kubia failed liveness probe, will be restarted
Copied!
上面的events内容中出现了unhealthy信息,pod要被重启,从pod信息上能看到已经有重启次数计数了。
1
$ k get pod kubia-liveness
2
NAME READY STATUS RESTARTS AGE
3
kubia-liveness 1/1 Running 3 6m17s
Copied!

附加属性

我们有很多服务启动是需要时间的,为了避免频繁的重启,需要设置一下延时检测时间
1
# cat kubia-liveness-probe-initial-delay.yaml
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
name: kubia-liveness
6
spec:
7
containers:
8
- image: luksa/kubia-unhealthy
9
name: kubia
10
livenessProbe:
11
httpGet:
12
path: /
13
port: 8080
14
initialDelaySeconds: 15 # 注意这个参数
Copied!
initialDelaySeconds 这个参数很有实际用处
大家课下可以自己做这个实验,观察pod描述中的events日志验证

运行pod的多个实例

我们服务都是多副本的,例如100 - 200这样的规模,高可用的实现,我们实现一下。在基础部分我们尝试了一下,用的就是replicacontroller,看看这个yaml
1
# cat kubia-rc.yaml
2
apiVersion: v1
3
kind: ReplicationController #使用副本控制
4
metadata:
5
name: kubia
6
spec:
7
replicas: 3 #3个副本
8
selector:
9
app: kubia #这里表示控制的是kubia服务
10
template:
11
metadata:
12
labels:
13
app: kubia
14
spec:
15
containers:
16
- name: kubia
17
image: luksa/kubia
18
ports:
19
- containerPort: 8080
Copied!
但是最新的kubernetes已经建议大家使用新的副本集控制器ReplicaSet代替了。所以我们直接做ReplicaSet的练习,他们yaml文件类似
1
# cat kubia-replicaset.yaml
2
apiVersion: apps/v1beta2 #api有变化
3
kind: ReplicaSet #和上面的不同,大家用这个
4
metadata:
5
name: kubia
6
spec:
7
replicas: 3
8
selector:
9
matchLabels:
10
app: kubia #注意,是按照这个标签控制副本的
11
template:
12
metadata:
13
labels:
14
app: kubia #所以,为pod打上标签
15
spec:
16
containers:
17
- name: kubia
18
image: luksa/kubia
Copied!
创建一下这个文件
kubectl create这类指令大家已经熟悉了吧,后续可能不会一一列出这个指令了,有需要可以参考前面的命令。
$ k create -f kubia-replicaset.yaml
1
$ k get all
2
NAME READY STATUS RESTARTS AGE
3
pod/kubia-gk6ln 1/1 Running 0 24s
4
pod/kubia-jbxqc 1/1 Running 0 24s
5
pod/kubia-wjlfj 1/1 Running 0 24s
6
7
NAME DESIRED CURRENT READY AGE
8
replicaset.apps/kubia 3 3 3 25s
Copied!
检查一下我们的副本集,状态还挺清楚的
1
$ k describe rs kubia
2
Name: kubia
3
Namespace: liuzongxian
4
Selector: app=kubia
5
Labels: <none>
6
Annotations: <none>
7
Replicas: 3 current / 3 desired
8
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
9
Pod Template:
10
Labels: app=kubia
11
Containers:
12
kubia:
13
Image: luksa/kubia
14
Port: <none>
15
Host Port: <none>
16
Environment: <none>
17
Mounts: <none>
18
Volumes: <none>
19
Events:
20
Type Reason Age From Message
21
---- ------ ---- ---- -------
22
Normal SuccessfulCreate 2m9s replicaset-controller Created pod: kubia-gk6ln
23
Normal SuccessfulCreate 2m9s replicaset-controller Created pod: kubia-jbxqc
24
Normal SuccessfulCreate 2m9s replicaset-controller Created pod: kubia-wjlfj
Copied!

节点异常自动调度pod

因为有了这个副本集控制,kubernetes会时刻帮你看管副本个数,如果某个node(注意node概念是底层节点)错误导致丢失了某些副本,控制器会补充足够的副本在其他node上。
由于把节点下掉操作对大家环境影响较大,这里先不演示了。

水平缩放pod

修改一下副本集个数,将replica改小和改大,例如5,观察一下
1
$ kubectl edit rs kubia
2
replicaset.extensions/kubia edited
Copied!
输出类似
1
$ k get all
2
NAME READY STATUS RESTARTS AGE
3
pod/kubia-brjwr 1/1 Running 0 48s
4
pod/kubia-djttq 1/1 Running 0 48s
5
pod/kubia-gk6ln 1/1 Running 0 5m34s
6
pod/kubia-jbxqc 1/1 Running 0 5m34s
7
pod/kubia-wjlfj 1/1 Running 0 5m34s
8
9
NAME DESIRED CURRENT READY AGE
10
replicaset.apps/kubia 5 5 5 5m35s
Copied!
相比以前部署是不是非常简单了呢?

集群节点上运行系统级的pod

我们有一种部署需求,需要在每台节点有且只有一个副本,例如consul agent、redis、fluentd等等辅助性的组件,可以使用DaemonSet副本集。
1
# cat kubia-daemonset.yaml
2
apiVersion: apps/v1beta2
3
kind: DaemonSet #这里是Daemonset
4
metadata:
5
name: kubia
6
spec:
7
#replicas: 3 #不再使用副本集了
8
selector:
9
matchLabels:
10
app: kubia
11
template:
12
metadata:
13
labels:
14
app: kubia
15
spec:
16
containers:
17
- name: kubia
18
image: luksa/kubia
Copied!
比较简单,我们不必做这个实验了,理解它的用途就好,做一个特殊的实验,见下面描述文件。
1
# cat ssd-monitor-daemonset.yaml
2
apiVersion: apps/v1beta2
3
kind: DaemonSet
4
metadata:
5
name: ssd-monitor
6
spec:
7
selector:
8
matchLabels:
9
app: ssd-monitor
10
template:
11
metadata:
12
labels:
13
app: ssd-monitor
14
spec:
15
nodeSelector:
16
disk: ssd #限定了pod所在节点
17
containers:
18
- name: main
19
image: luksa/ssd-monitor
Copied!
这个描述功能是在含有ssd的节点上部署监控器ssd-monitor
这里已经给个别节点打上了标签,如
$ k label node cn-hongkong.10.32.100.47 disk=ssd
1
$ k get node -L disk
2
NAME STATUS ROLES AGE VERSION DISK
3
cn-hongkong.10.32.100.46 Ready <none> 7d1h v1.14.8-aliyun.1
4
cn-hongkong.10.32.100.47 Ready <none> 4d v1.14.8-aliyun.1 ssd
5
cn-hongkong.10.32.100.48 Ready <none> 2d20h v1.14.8-aliyun.1 ssd
Copied!
创建上面的yaml看看
1
$ k create -f ssd-monitor-daemonset.yaml
2
daemonset.apps/ssd-monitor created
Copied!

删除副本集

做一些清理工作吧
1
$ k delete daemonset.apps/ssd-monitor
2
3
$ k delete all --all # 确保空间没有重要的服务
Copied!
Well Done!到达这里你已经是半个DevOps了,这里是kubernetes的核心功能,能够自动的帮你管理副本集的状态。
下一节,我们让其他服务访问我们的副本集。

思考题

  • 在不同命名空间都创建的DaemonSet,会互相冲突么,比如多部署或少部署?