在好例子网,分享、交流、成长!
您当前所在位置:首页Go 开发实例Go语言基础 → k8s部署笔记.doc

k8s部署笔记.doc

Go语言基础

下载此实例
  • 开发语言:Go
  • 实例大小:0.16M
  • 下载次数:12
  • 浏览次数:56
  • 发布时间:2022-03-10
  • 实例类别:Go语言基础
  • 发 布 人:XQ881001.
  • 文件格式:.docx
  • 所需积分:2
 相关标签: k8s 部署 笔记

实例介绍

【实例简介】k8s部署笔记.doc

【实例截图】from clipboard

from clipboardfrom clipboardfrom clipboardfrom clipboard

【核心代码】

目录

Kubernetes详细教程  PAGEREF _Toc32173 \h 10

此方式下安装kubernetes集群要求Centos版本要在7.5或之上  PAGEREF _Toc3968 \h 12

主机名成解析 编辑三台服务器的/etc/hosts文件,添加下面内容  PAGEREF _Toc11617 \h 13

启动chronyd服务  PAGEREF _Toc10787 \h 13

1 关闭firewalld服务  PAGEREF _Toc32608 \h 13

2 关闭iptables服务  PAGEREF _Toc28939 \h 13

编辑 /etc/selinux/config 文件,修改SELINUX的值为disable  PAGEREF _Toc3089 \h 13

注意修改完毕之后需要重启linux服务  PAGEREF _Toc24157 \h 13

编辑分区配置文件/etc/fstab,注释掉swap分区一行  PAGEREF _Toc25361 \h 13

注意修改完毕之后需要重启linux服务  PAGEREF _Toc28960 \h 13

/dev/mapper/centos-swap swap  PAGEREF _Toc1442 \h 14

修改linux的内核采纳数,添加网桥过滤和地址转发功能  PAGEREF _Toc4734 \h 14

编辑/etc/sysctl.d/kubernetes.conf文件,添加如下配置:  PAGEREF _Toc14704 \h 14

重新加载配置  PAGEREF _Toc5624 \h 14

加载网桥过滤模块  PAGEREF _Toc7796 \h 14

查看网桥过滤模块是否加载成功  PAGEREF _Toc13365 \h 14

1.安装ipsetipvsadm  PAGEREF _Toc2307 \h 14

2.添加需要加载的模块写入脚本文件  PAGEREF _Toc7512 \h 14

!/bin/bash  PAGEREF _Toc26956 \h 14

3.为脚本添加执行权限  PAGEREF _Toc26372 \h 14

4.执行脚本文件  PAGEREF _Toc5075 \h 14

5.查看对应的模块是否加载成功  PAGEREF _Toc31601 \h 14

1、切换镜像源  PAGEREF _Toc6822 \h 15

2、查看当前镜像源中支持的docker版本  PAGEREF _Toc6724 \h 15

3、安装特定版本的docker-ce  PAGEREF _Toc9573 \h 15

必须制定--setopt=obsoletes=0,否则yum会自动安装更高版本  PAGEREF _Toc16646 \h 15

4、添加一个配置文件  PAGEREF _Toc26189 \h 15

Docker 在默认情况下使用Vgroup Drivercgroupfs,而Kubernetes推荐使用systemd来替代cgroupfs  PAGEREF _Toc16490 \h 15

5、启动dokcer  PAGEREF _Toc31979 \h 15

1、由于kubernetes的镜像在国外,速度比较慢,这里切换成国内的镜像源  PAGEREF _Toc11468 \h 15

2、编辑/etc/yum.repos.d/kubernetes.repo,添加下面的配置  PAGEREF _Toc23336 \h 15

3、安装kubeadmkubeletkubectl  PAGEREF _Toc2952 \h 15

4、配置kubeletcgroup  PAGEREF _Toc10172 \h 15

编辑/etc/sysconfig/kubelet, 添加下面的配置  PAGEREF _Toc27670 \h 15

5、设置kubelet开机自启  PAGEREF _Toc12631 \h 15

在安装kubernetes集群之前,必须要提前准备好集群需要的镜像,所需镜像可以通过下面命令查看  PAGEREF _Toc21271 \h 16

下载镜像  PAGEREF _Toc24578 \h 16

此镜像kubernetes的仓库中,由于网络原因,无法连接,下面提供了一种替换方案  PAGEREF _Toc20145 \h 16

创建集群  PAGEREF _Toc15999 \h 16

创建必要文件  PAGEREF _Toc1779 \h 16

master节点之外的节点进行操作  PAGEREF _Toc17330 \h 17

重启kubelet  PAGEREF _Toc29197 \h 17

重启docker  PAGEREF _Toc1121 \h 17

重启kubelet  PAGEREF _Toc21415 \h 17

重启docker  PAGEREF _Toc30658 \h 17

生成 新的token  PAGEREF _Toc10142 \h 17

纯量, 就是指的一个简单的值,字符串、布尔值、整数、浮点数、Null、时间、日期  PAGEREF _Toc3506 \h 18

1 布尔类型  PAGEREF _Toc23531 \h 18

2 整型  PAGEREF _Toc2966 \h 19

3 浮点型  PAGEREF _Toc6786 \h 19

4 null类型  PAGEREF _Toc3366 \h 19

5 日期类型  PAGEREF _Toc11115 \h 19

6 时间类型  PAGEREF _Toc12475 \h 19

7 字符串类型  PAGEREF _Toc30820 \h 19

对象  PAGEREF _Toc29391 \h 19

形式一(推荐):  PAGEREF _Toc18122 \h 19

形式二(了解):  PAGEREF _Toc6871 \h 19

数组  PAGEREF _Toc8608 \h 19

形式一(推荐):  PAGEREF _Toc27557 \h 19

形式二(了解):  PAGEREF _Toc31975 \h 19

查看所有pod  PAGEREF _Toc7136 \h 20

查看某个pod  PAGEREF _Toc9384 \h 20

查看某个pod,yaml格式展示结果  PAGEREF _Toc32614 \h 20

创建一个namespace  PAGEREF _Toc23903 \h 21

获取namespace  PAGEREF _Toc20621 \h 21

在此namespace下创建并运行一个nginxPod  PAGEREF _Toc2214 \h 21

查看新创建的pod  PAGEREF _Toc16544 \h 21

删除指定的pod  PAGEREF _Toc30803 \h 21

删除指定的namespace  PAGEREF _Toc28938 \h 22

首先执行一次kubectl apply -f yaml文件,发现创建了资源  PAGEREF _Toc11107 \h 22

再次执行一次kubectl apply -f yaml文件,发现说资源没有变动  PAGEREF _Toc17163 \h 22

1 查看所有的ns 命令:kubectl get ns  PAGEREF _Toc19307 \h 23

2 查看指定的ns 命令:kubectl get ns ns名称  PAGEREF _Toc6640 \h 23

3 指定输出格式 命令:kubectl get ns ns名称 -o 格式参数  PAGEREF _Toc13927 \h 24

kubernetes支持的格式有很多,比较常见的是widejsonyaml  PAGEREF _Toc19485 \h 24

4 查看ns详情 命令:kubectl describe ns ns名称  PAGEREF _Toc26 \h 24

ResourceQuota 针对namespace做的资源限制  PAGEREF _Toc8564 \h 24

LimitRange针对namespace中的每个组件做的资源限制  PAGEREF _Toc28514 \h 24

创建namespace  PAGEREF _Toc29145 \h 24

删除namespace  PAGEREF _Toc24356 \h 24

命令格式: kubectl run (pod控制器名称) [参数]  PAGEREF _Toc19679 \h 25

--image 指定Pod的镜像  PAGEREF _Toc26570 \h 25

--port 指定端口  PAGEREF _Toc7144 \h 25

--namespace 指定namespace  PAGEREF _Toc7518 \h 25

查看Pod基本信息  PAGEREF _Toc31294 \h 25

查看Pod的详细信息  PAGEREF _Toc20422 \h 25

获取podIP  PAGEREF _Toc6890 \h 26

访问POD  PAGEREF _Toc26037 \h 26

删除指定Pod  PAGEREF _Toc4698 \h 26

此时,显示删除Pod成功,但是再查询,发现又新产生了一个  PAGEREF _Toc28747 \h 26

这是因为当前Pod是由Pod控制器创建的,控制器会监控Pod状况,一旦发现Pod死亡,会立即重建  PAGEREF _Toc18958 \h 26

此时要想删除Pod,必须删除Pod控制器  PAGEREF _Toc17522 \h 26

先来查询一下当前namespace下的Pod控制器  PAGEREF _Toc22250 \h 26

接下来,删除此PodPod控制器  PAGEREF _Toc4228 \h 26

稍等片刻,再查询Pod,发现Pod被删除了  PAGEREF _Toc28384 \h 26

pod资源打标签  PAGEREF _Toc22461 \h 27

pod资源更新标签  PAGEREF _Toc24840 \h 28

查看标签  PAGEREF _Toc19064 \h 28

筛选标签  PAGEREF _Toc19299 \h 28

删除标签  PAGEREF _Toc26975 \h 28

命令格式: kubectl create deployment 名称 [参数]  PAGEREF _Toc25570 \h 28

--image 指定pod的镜像  PAGEREF _Toc4839 \h 28

--port 指定端口  PAGEREF _Toc5728 \h 28

--replicas 指定创建pod数量  PAGEREF _Toc21964 \h 28

--namespace 指定namespace  PAGEREF _Toc1970 \h 28

查看创建的Pod  PAGEREF _Toc30836 \h 29

查看deployment的信息  PAGEREF _Toc19965 \h 29

UP-TO-DATE:成功升级的副本数量  PAGEREF _Toc25696 \h 29

AVAILABLE:可用副本的数量  PAGEREF _Toc28912 \h 29

查看deployment的详细信息  PAGEREF _Toc24074 \h 29

删除  PAGEREF _Toc6289 \h 29

暴露Service  PAGEREF _Toc29929 \h 30

查看service  PAGEREF _Toc18373 \h 30

这里产生了一个CLUSTER-IP,这就是serviceIP,在Service的生命周期中,这个地址是不会变动的  PAGEREF _Toc13432 \h 30

可以通过这个IP访问当前service对应的POD  PAGEREF _Toc10167 \h 30

Welcome to nginx!  PAGEREF _Toc9830 \h 30

上面创建的Servicetype类型为ClusterIP,这个ip地址只用集群内部可访问  PAGEREF _Toc21444 \h 30

如果需要创建外部也可以访问的Service,需要修改typeNodePort  PAGEREF _Toc30558 \h 30

此时查看,会发现出现了NodePort类型的Service,而且有一对Port80:31928/TC  PAGEREF _Toc20898 \h 30

接下来就可以通过集群外的主机访问 节点IP:31928访问服务了  PAGEREF _Toc23310 \h 30

例如在的电脑主机上通过浏览器访问下面的地址  PAGEREF _Toc32725 \h 31

小提示:  PAGEREF _Toc29005 \h 32

在这里,可通过一个命令来查看每种资源的可配置项  PAGEREF _Toc21680 \h 32

kubectl explain 资源类型 查看某种资源可以配置的一级属性  PAGEREF _Toc15764 \h 32

kubectl explain 资源类型.属性 查看属性的子属性  PAGEREF _Toc23153 \h 32

创建Pod  PAGEREF _Toc2858 \h 33

查看Pod状况  PAGEREF _Toc31041 \h 33

READY 1/2 : 表示当前Pod中有2个容器,其中1个准备就绪,1个未就绪  PAGEREF _Toc11178 \h 33

RESTARTS : 重启次数,因为有1个容器故障了,Pod一直在重启试图恢复它  PAGEREF _Toc26133 \h 33

可以通过describe查看内部的详情  PAGEREF _Toc10963 \h 33

此时已经运行起来了一个基本的Pod,虽然它暂时有问题  PAGEREF _Toc1481 \h 33

创建Pod  PAGEREF _Toc10692 \h 34

查看Pod详情  PAGEREF _Toc19952 \h 34

此时明显可以看到nginx镜像有一步Pulling image "nginx:1.17.1"的过程  PAGEREF _Toc25861 \h 34

创建Pod  PAGEREF _Toc14628 \h 35

查看Pod状态  PAGEREF _Toc17438 \h 35

此时发现两个pod都正常运行了  PAGEREF _Toc21215 \h 35

进入pod中的busybox容器,查看文件内容  PAGEREF _Toc1662 \h 35

补充一个命令: kubectl exec pod名称 -n 命名空间 -it -c 容器名称 /bin/sh 在容器内部执行命令  PAGEREF _Toc16170 \h 35

使用这个命令就可以进入某个容器的内部,然后进行相关操作了  PAGEREF _Toc256 \h 35

比如,可以查看txt文件的内容  PAGEREF _Toc1180 \h 35

创建Pod  PAGEREF _Toc14430 \h 35

进入容器,输出环境变量  PAGEREF _Toc21380 \h 35

创建Pod  PAGEREF _Toc18497 \h 36

查看pod  PAGEREF _Toc6963 \h 36

在下面可以明显看到配置信息  PAGEREF _Toc17363 \h 36

运行Pod  PAGEREF _Toc1726 \h 37

查看发现pod运行正常  PAGEREF _Toc25610 \h 37

接下来,停止Pod  PAGEREF _Toc1205 \h 37

编辑pod,修改resources.requests.memory的值为10Gi  PAGEREF _Toc14581 \h 37

再次启动pod  PAGEREF _Toc22940 \h 37

查看Pod状态,发现Pod启动失败  PAGEREF _Toc32476 \h 37

查看pod详情会发现,如下提示  PAGEREF _Toc31535 \h 37

创建pod  PAGEREF _Toc31983 \h 39

查看pod状态  PAGEREF _Toc8882 \h 39

发现pod卡在启动第一个初始化容器过程中,后面的容器不会运行  PAGEREF _Toc17108 \h 39

动态查看pod  PAGEREF _Toc14045 \h 39

接下来新开一个shell,为当前服务器新增两个ip,观察pod的变化  PAGEREF _Toc864 \h 39

创建pod  PAGEREF _Toc29231 \h 40

查看pod  PAGEREF _Toc32302 \h 40

访问pod  PAGEREF _Toc4252 \h 40

创建Pod  PAGEREF _Toc14081 \h 41

查看Pod详情  PAGEREF _Toc26618 \h 41

观察上面的信息就会发现nginx容器启动之后就进行了健康检查  PAGEREF _Toc28937 \h 41

检查失败之后,容器被kill掉,然后尝试进行重启(这是重启策略的作用,后面讲解)  PAGEREF _Toc10398 \h 41

稍等一会之后,再观察pod信息,就可以看到RESTARTS不再是0,而是一直增长  PAGEREF _Toc21895 \h 41

当然接下来,可以修改成一个存在的文件,比如/tmp/hello.txt,再试,结果就正常了......  PAGEREF _Toc12288 \h 41

创建Pod  PAGEREF _Toc10345 \h 41

查看Pod详情  PAGEREF _Toc25953 \h 41

观察上面的信息,发现尝试访问8080端口,但是失败了  PAGEREF _Toc17099 \h 42

稍等一会之后,再观察pod信息,就可以看到RESTARTS不再是0,而是一直增长  PAGEREF _Toc6348 \h 42

当然接下来,可以修改成一个可以访问的端口,比如80,再试,结果就正常了......  PAGEREF _Toc2690 \h 42

创建Pod  PAGEREF _Toc24290 \h 42

查看Pod详情  PAGEREF _Toc5928 \h 42

观察上面信息,尝试访问路径,但是未找到,出现404错误  PAGEREF _Toc30808 \h 42

稍等一会之后,再观察pod信息,就可以看到RESTARTS不再是0,而是一直增长  PAGEREF _Toc30772 \h 42

当然接下来,可以修改成一个可以访问的路径path,比如/,再试,结果就正常了......  PAGEREF _Toc2574 \h 42

创建Pod  PAGEREF _Toc27940 \h 43

查看Pod详情,发现nginx容器失败  PAGEREF _Toc21282 \h 43

多等一会,再观察pod的重启次数,发现一直是0,并未重启  PAGEREF _Toc10194 \h 43

创建Pod  PAGEREF _Toc14457 \h 44

查看Pod调度到NODE属性,确实是调度到了node1节点上  PAGEREF _Toc12883 \h 44

接下来,删除pod,修改nodeName的值为node3(并没有node3节点)  PAGEREF _Toc31107 \h 44

再次查看,发现已经向Node3节点调度,但是由于不存在node3节点,所以pod无法正常运行  PAGEREF _Toc7463 \h 44

创建Pod  PAGEREF _Toc16466 \h 45

查看Pod调度到NODE属性,确实是调度到了node1节点上  PAGEREF _Toc32633 \h 45

接下来,删除pod,修改nodeSelector的值为nodeenv: xxxx(不存在打有此标签的节点)  PAGEREF _Toc3900 \h 45

再次查看,发现pod无法正常运行,Node的值为none  PAGEREF _Toc25275 \h 45

查看详情,发现node selector匹配失败的提示  PAGEREF _Toc24727 \h 45

创建pod  PAGEREF _Toc15343 \h 46

查看pod状态 (运行失败)  PAGEREF _Toc12626 \h 46

查看Pod的详情  PAGEREF _Toc26706 \h 46

发现调度失败,提示node选择失败  PAGEREF _Toc13701 \h 46

接下来,停止pod  PAGEREF _Toc4168 \h 47

修改文件,将values: ["xxx","yyy"]------> ["pro","yyy"]  PAGEREF _Toc11805 \h 47

再次启动  PAGEREF _Toc10934 \h 47

此时查看,发现调度成功,已经将pod调度到了node1  PAGEREF _Toc20819 \h 47

创建pod  PAGEREF _Toc27699 \h 47

查看pod状态 (运行成功)  PAGEREF _Toc923 \h 47

启动目标pod  PAGEREF _Toc2230 \h 48

查看pod状况  PAGEREF _Toc19743 \h 48

启动pod  PAGEREF _Toc9123 \h 48

查看pod状态,发现未运行  PAGEREF _Toc6154 \h 48

查看详细信息  PAGEREF _Toc26991 \h 48

接下来修改 values: ["xxx","yyy"]----->values:["pro","yyy"]  PAGEREF _Toc26153 \h 49

意思是:新Pod必须要与拥有标签nodeenv=xxx或者nodeenv=yyypod在同一Node  PAGEREF _Toc26414 \h 49

然后重新创建pod,查看效果  PAGEREF _Toc24757 \h 49

发现此时Pod运行正常  PAGEREF _Toc6090 \h 49

创建pod  PAGEREF _Toc31551 \h 49

查看pod  PAGEREF _Toc7091 \h 49

发现调度到了node2  PAGEREF _Toc27406 \h 49

设置污点  PAGEREF _Toc30534 \h 50

去除污点  PAGEREF _Toc32376 \h 50

去除所有污点  PAGEREF _Toc21824 \h 50

node1设置污点(PreferNoSchedule)  PAGEREF _Toc31741 \h 50

创建pod1  PAGEREF _Toc30200 \h 50

node1设置污点(取消PreferNoSchedule,设置NoSchedule)  PAGEREF _Toc12069 \h 50

创建pod2  PAGEREF _Toc31027 \h 51

node1设置污点(取消NoSchedule,设置NoExecute)  PAGEREF _Toc14712 \h 51

创建pod3  PAGEREF _Toc24528 \h 51

添加容忍之前的pod  PAGEREF _Toc12293 \h 51

添加容忍之后的pod  PAGEREF _Toc19359 \h 51

创建rs  PAGEREF _Toc4692 \h 53

查看rs  PAGEREF _Toc30493 \h 53

DESIRED:期望副本数量  PAGEREF _Toc19896 \h 53

CURRENT:当前副本数量  PAGEREF _Toc27633 \h 53

READY:已经准备好提供服务的副本数量  PAGEREF _Toc22618 \h 53

查看当前控制器创建出来的pod  PAGEREF _Toc30291 \h 53

这里发现控制器创建出来的pod的名称是在控制器名称后面拼接了-xxxxx随机码  PAGEREF _Toc2422 \h 53

编辑rs的副本数量,修改spec:replicas: 6即可  PAGEREF _Toc1235 \h 53

查看pod  PAGEREF _Toc16542 \h 53

当然也可以直接使用命令实现  PAGEREF _Toc24332 \h 53

使用scale命令实现扩缩容, 后面--replicas=n直接指定目标数量即可  PAGEREF _Toc15361 \h 53

命令运行完毕,立即查看,发现已经有4个开始准备退出了  PAGEREF _Toc13136 \h 54

稍等片刻,就只剩下2个了  PAGEREF _Toc15884 \h 54

编辑rs的容器镜像 - image: nginx:1.17.2  PAGEREF _Toc14926 \h 54

再次查看,发现镜像版本已经变更了  PAGEREF _Toc25816 \h 54

同样的道理,也可以使用命令完成这个工作  PAGEREF _Toc26937 \h 54

kubectl set image rs rs名称 容器=镜像版本 -n namespace  PAGEREF _Toc27204 \h 54

再次查看,发现镜像版本已经变更了  PAGEREF _Toc11788 \h 54

使用kubectl delete命令会删除此RS以及它管理的Pod  PAGEREF _Toc31150 \h 54

kubernetes删除RS前,会将RSreplicasclear调整为0,等待所有的Pod被删除后,在执行RS对象的删除  PAGEREF _Toc20168 \h 54

如果希望仅仅删除RS对象(保留Pod),可以使用kubectl delete命令时添加--cascade=false选项(不推荐)。  PAGEREF _Toc28840 \h 54

也可以使用yaml直接删除(推荐)  PAGEREF _Toc3055 \h 55

创建deployment  PAGEREF _Toc18970 \h 55

查看deployment  PAGEREF _Toc26500 \h 55

UP-TO-DATE 最新版本的pod的数量  PAGEREF _Toc12210 \h 55

AVAILABLE 当前可用的pod的数量  PAGEREF _Toc15702 \h 55

查看rs  PAGEREF _Toc19344 \h 56

发现rs的名称是在原来deployment的名字后面添加了一个10位数的随机串  PAGEREF _Toc32356 \h 56

查看pod  PAGEREF _Toc1164 \h 56

变更副本数量为5  PAGEREF _Toc12443 \h 56

查看deployment  PAGEREF _Toc24976 \h 56

查看pod  PAGEREF _Toc7479 \h 56

编辑deployment的副本数量,修改spec:replicas: 4即可  PAGEREF _Toc29914 \h 56

查看pod  PAGEREF _Toc11160 \h 56

变更镜像  PAGEREF _Toc30237 \h 57

观察升级过程  PAGEREF _Toc4931 \h 57

变更镜像  PAGEREF _Toc10970 \h 57

观察升级过程  PAGEREF _Toc10089 \h 57

至此,新版本的pod创建完毕,就版本的pod销毁完毕  PAGEREF _Toc30321 \h 58

中间过程是滚动进行的,也就是边销毁边创建  PAGEREF _Toc20269 \h 58

查看rs,发现原来的rs的依旧存在,只是pod数量变为了0,而后又新产生了一个rspod数量为4  PAGEREF _Toc30640 \h 58

其实这就是deployment能够进行版本回退的奥妙所在,后面会详细解释  PAGEREF _Toc6516 \h 58

查看当前升级版本的状态  PAGEREF _Toc2031 \h 58

查看升级历史记录  PAGEREF _Toc4121 \h 59

可以发现有三次版本记录,说明完成过两次升级  PAGEREF _Toc20475 \h 59

版本回滚  PAGEREF _Toc19879 \h 59

这里直接使用--to-revision=1回滚到了1版本, 如果省略这个选项,就是回退到上个版本,就是2版本  PAGEREF _Toc2393 \h 59

查看发现,通过nginx镜像版本可以发现到了第一版  PAGEREF _Toc12817 \h 59

查看rs,发现第一个rs中有4pod运行,后面两个版本的rspod为运行  PAGEREF _Toc30380 \h 59

其实deployment之所以可是实现版本的回滚,就是通过记录下历史rs来实现的,  PAGEREF _Toc13825 \h 59

一旦想回滚到哪个版本,只需要将当前版本pod数量降为0,然后将回滚版本的pod提升为目标数量就可以了  PAGEREF _Toc13379 \h 59

更新deployment的版本,并配置暂停deployment  PAGEREF _Toc6571 \h 59

观察更新状态  PAGEREF _Toc18968 \h 59

监控更新的过程,可以看到已经新增了一个资源,但是并未按照预期的状态去删除一个旧的资源,就是因为使用了pause暂停命令  PAGEREF _Toc21332 \h 60

确保更新的pod没问题了,继续更新  PAGEREF _Toc29384 \h 60

查看最后的更新情况  PAGEREF _Toc742 \h 60

删除deployment,其下的rspod也将被删除  PAGEREF _Toc26444 \h 60

安装git  PAGEREF _Toc6985 \h 61

获取metrics-server, 注意使用的版本  PAGEREF _Toc15739 \h 61

修改deployment, 注意修改的是镜像和初始化参数  PAGEREF _Toc14166 \h 61

安装metrics-server  PAGEREF _Toc6048 \h 61

查看pod运行情况  PAGEREF _Toc32676 \h 61

使用kubectl top node 查看资源使用情况  PAGEREF _Toc5536 \h 61

至此,metrics-server安装完成  PAGEREF _Toc28545 \h 61

创建deployment  PAGEREF _Toc15503 \h 61

创建service  PAGEREF _Toc31433 \h 62

查看  PAGEREF _Toc28573 \h 62

创建hpa  PAGEREF _Toc25480 \h 62

查看hpa  PAGEREF _Toc11717 \h 62

创建daemonset  PAGEREF _Toc17791 \h 64

查看daemonset  PAGEREF _Toc8619 \h 64

查看pod,发现在每个Node上都运行一个pod  PAGEREF _Toc20234 \h 64

删除daemonset  PAGEREF _Toc15738 \h 64

创建job  PAGEREF _Toc6645 \h 65

查看job  PAGEREF _Toc10961 \h 65

通过观察pod状态可以看到,pod在运行完毕任务后,就会变成Completed状态  PAGEREF _Toc27717 \h 65

接下来,调整下pod运行的总数量和并行数量 即:在spec下设置下面两个选项  PAGEREF _Toc22271 \h 65

completions: 6 # 指定job需要成功运行Pods的次数为6  PAGEREF _Toc10243 \h 65

parallelism: 3 # 指定job并发运行Pods的数量为3  PAGEREF _Toc26131 \h 65

然后重新运行job,观察效果,此时会发现,job会每次运行3pod,总共执行了6pod  PAGEREF _Toc10878 \h 65

删除job  PAGEREF _Toc27542 \h 65

创建cronjob  PAGEREF _Toc7857 \h 66

查看cronjob  PAGEREF _Toc32231 \h 66

查看job  PAGEREF _Toc8583 \h 66

查看pod  PAGEREF _Toc28413 \h 66

删除cronjob  PAGEREF _Toc13288 \h 66

10.97.97.97:80 service提供的访问入口  PAGEREF _Toc5424 \h 67

当访问这个入口的时候,可以发现后面有三个pod的服务在等待调用,  PAGEREF _Toc31088 \h 67

kube-proxy会基于rr(轮询)的策略,将请求分发到其中一个pod上去  PAGEREF _Toc11225 \h 67

这个规则会同时在集群内的所有节点上都生成,所以在任何一个节点上访问都可以。  PAGEREF _Toc20686 \h 67

此模式必须安装ipvs内核模块,否则会降级为iptables  PAGEREF _Toc24655 \h 67

开启ipvs  PAGEREF _Toc24029 \h 67

修改mode: "ipvs"  PAGEREF _Toc11124 \h 68

查看pod详情  PAGEREF _Toc20638 \h 68

为了方便后面的测试,修改下三台nginxindex.html页面(三台修改的IP地址不一致)  PAGEREF _Toc21827 \h 68

kubectl exec -it pc-deployment-66cb59b984-8p84h -n dev /bin/sh  PAGEREF _Toc20760 \h 68

echo "10.244.1.39" > /usr/share/nginx/html/index.html  PAGEREF _Toc19898 \h 68

修改完毕之后,访问测试  PAGEREF _Toc7966 \h 68

创建service  PAGEREF _Toc19974 \h 69

查看service  PAGEREF _Toc11587 \h 69

查看service的详细信息  PAGEREF _Toc3102 \h 69

在这里有一个Endpoints列表,里面就是当前service可以负载到的服务入口  PAGEREF _Toc30860 \h 69

查看ipvs的映射规则  PAGEREF _Toc23601 \h 69

访问10.97.97.97:80观察效果  PAGEREF _Toc10915 \h 69

查看ipvs的映射规则【rr 轮询】  PAGEREF _Toc13975 \h 70

循环访问测试  PAGEREF _Toc17039 \h 70

修改分发策略----sessionAffinity:ClientIP  PAGEREF _Toc3613 \h 70

查看ipvs规则【persistent 代表持久】  PAGEREF _Toc8255 \h 70

循环访问测试  PAGEREF _Toc488 \h 70

删除service  PAGEREF _Toc29038 \h 70

创建service  PAGEREF _Toc3912 \h 70

获取service, 发现CLUSTER-IP未分配  PAGEREF _Toc12970 \h 70

查看service详情  PAGEREF _Toc19237 \h 70

查看域名的解析情况  PAGEREF _Toc19840 \h 70

创建service  PAGEREF _Toc10234 \h 71

查看service  PAGEREF _Toc25885 \h 71

接下来可以通过电脑主机的浏览器去访问集群中任意一个nodeip30002端口,即可访问到pod  PAGEREF _Toc13427 \h 71

创建service  PAGEREF _Toc11492 \h 71

域名解析  PAGEREF _Toc24616 \h 72

创建文件夹  PAGEREF _Toc16584 \h 72

获取ingress-nginx,本次案例使用的是0.30版本  PAGEREF _Toc32527 \h 72

修改mandatory.yaml文件中的仓库  PAGEREF _Toc30065 \h 72

修改quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0  PAGEREF _Toc18840 \h 72

quay-mirror.qiniu.com/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0  PAGEREF _Toc1642 \h 73

创建ingress-nginx  PAGEREF _Toc18066 \h 73

查看ingress-nginx  PAGEREF _Toc31472 \h 73

查看service  PAGEREF _Toc13638 \h 73

创建  PAGEREF _Toc7712 \h 73

查看  PAGEREF _Toc371 \h 73

创建  PAGEREF _Toc3465 \h 73

查看  PAGEREF _Toc22535 \h 73

查看详情  PAGEREF _Toc14714 \h 73

接下来,在本地电脑上配置host文件,解析上面的两个域名到192.168.109.100(master)  PAGEREF _Toc27341 \h 74

然后,就可以分别访问tomcat.itheima.com:32240 nginx.itheima.com:32240 查看效果了  PAGEREF _Toc19580 \h 74

生成证书  PAGEREF _Toc8812 \h 74

创建密钥  PAGEREF _Toc23508 \h 74

创建  PAGEREF _Toc14690 \h 74

查看  PAGEREF _Toc4370 \h 74

查看详情  PAGEREF _Toc20457 \h 74

下面可以通过浏览器访问https://nginx.itheima.com:31335 https://tomcat.itheima.com:31335来查看了  PAGEREF _Toc15588 \h 74

创建Pod  PAGEREF _Toc18401 \h 75

查看pod  PAGEREF _Toc1490 \h 75

通过podIp访问nginx  PAGEREF _Toc28982 \h 76

通过kubectl logs命令查看指定容器的标准输出  PAGEREF _Toc14735 \h 76

创建Pod  PAGEREF _Toc4708 \h 76

查看Pod  PAGEREF _Toc15863 \h 76

访问nginx  PAGEREF _Toc30198 \h 76

接下来就可以去host/root/logs目录下查看存储的文件了  PAGEREF _Toc18177 \h 76

同样的道理,如果在此目录下创建一个文件,到容器中也是可以看到的  PAGEREF _Toc11581 \h 77

nfs上安装nfs服务  PAGEREF _Toc24866 \h 77

准备一个共享目录  PAGEREF _Toc31127 \h 77

将共享目录以读写权限暴露给192.168.5.0/24网段中的所有主机  PAGEREF _Toc7164 \h 77

启动nfs服务  PAGEREF _Toc6386 \h 77

node上安装nfs服务,注意不需要启动  PAGEREF _Toc16205 \h 77

创建pod  PAGEREF _Toc22393 \h 77

查看pod  PAGEREF _Toc1136 \h 78

查看nfs服务器上的共享目录,发现已经有文件了  PAGEREF _Toc6022 \h 78

创建目录  PAGEREF _Toc24832 \h 79

暴露服务  PAGEREF _Toc19026 \h 79

重启服务  PAGEREF _Toc4941 \h 79

创建 pv  PAGEREF _Toc26362 \h 79

查看pv  PAGEREF _Toc26567 \h 79

storage: 1Gi  PAGEREF _Toc6865 \h 80

storage: 1Gi  PAGEREF _Toc9877 \h 80

创建pvc  PAGEREF _Toc1300 \h 80

查看pvc  PAGEREF _Toc21219 \h 80

查看pv  PAGEREF _Toc8577 \h 81

readOnly: false  PAGEREF _Toc29109 \h 81

创建pod  PAGEREF _Toc24671 \h 81

查看pod  PAGEREF _Toc31808 \h 81

查看pvc  PAGEREF _Toc8177 \h 81

查看pv  PAGEREF _Toc533 \h 81

查看nfs中的文件存储  PAGEREF _Toc6771 \h 81

创建configmap  PAGEREF _Toc24999 \h 82

查看configmap详情  PAGEREF _Toc13586 \h 82

Data  PAGEREF _Toc29166 \h 82

info:  PAGEREF _Toc16246 \h 82

创建pod  PAGEREF _Toc3637 \h 83

查看pod  PAGEREF _Toc28896 \h 83

进入容器  PAGEREF _Toc15708 \h 83

cd /configmap/config/  PAGEREF _Toc5859 \h 83

ls  PAGEREF _Toc14348 \h 83

more info  PAGEREF _Toc19268 \h 83

可以看到映射已经成功,每个configmap都映射成了一个目录  PAGEREF _Toc28084 \h 83

key--->文件 value---->文件中的内容  PAGEREF _Toc29066 \h 83

此时如果更新configmap的内容, 容器中的值也会动态更新  PAGEREF _Toc26184 \h 83

创建secret  PAGEREF _Toc569 \h 84

查看secret详情  PAGEREF _Toc3863 \h 84

Data  PAGEREF _Toc6361 \h 84

创建pod  PAGEREF _Toc13109 \h 84

查看pod  PAGEREF _Toc9007 \h 84

进入容器,查看secret信息,发现已经自动解码了  PAGEREF _Toc9287 \h 84

Role只能对命名空间内的资源进行授权,需要指定nameapce  PAGEREF _Toc17241 \h 86

ClusterRole可以对集群范围内资源、跨namespaces的范围资源、非资源类型进行授权  PAGEREF _Toc32447 \h 86

RoleBinding可以将同一namespace中的subject绑定到某个Role下,则此subject即具有该Role定义的权限  PAGEREF _Toc17324 \h 87

ClusterRoleBinding在整个集群级别和所有namespaces将特定的subjectClusterRole绑定,授予权限  PAGEREF _Toc3258 \h 87

虽然authorization-clusterrole是一个集群角色,但是因为使用了RoleBinding  PAGEREF _Toc12923 \h 87

所以heima只能读取dev命名空间中的资源  PAGEREF _Toc9513 \h 87

1) 创建证书  PAGEREF _Toc11577 \h 87

2) apiserver的证书去签署  PAGEREF _Toc4333 \h 87

2-1) 签名申请,申请的用户是devman,组是devgroup  PAGEREF _Toc23957 \h 87

2-2) 签署证书  PAGEREF _Toc3586 \h 87

3) 设置集群、用户、上下文信息  PAGEREF _Toc124 \h 88

切换账户到devman  PAGEREF _Toc2299 \h 88

查看devpod,发现没有权限  PAGEREF _Toc20008 \h 88

切换到admin账户  PAGEREF _Toc10069 \h 88

切换账户到devman  PAGEREF _Toc5026 \h 88

再次查看  PAGEREF _Toc20846 \h 88

为了不影响后面的学习,切回admin账户  PAGEREF _Toc4452 \h 89

下载yaml  PAGEREF _Toc8481 \h 89

修改kubernetes-dashboardService类型  PAGEREF _Toc4096 \h 90

部署  PAGEREF _Toc597 \h 90

查看namespace下的kubernetes-dashboard下的资源  PAGEREF _Toc25326 \h 90

创建账号  PAGEREF _Toc32008 \h 90

授权  PAGEREF _Toc4857 \h 90

获取账号token  PAGEREF _Toc7319 \h 90

Data  PAGEREF _Toc29920 \h 90

标签: k8s 部署 笔记

实例下载地址

k8s部署笔记.doc

不能下载?内容有错? 点击这里报错 + 投诉 + 提问

好例子网口号:伸出你的我的手 — 分享

网友评论

发表评论

(您的评论需要经过审核才能显示)

查看所有0条评论>>

小贴士

感谢您为本站写下的评论,您的评论对其它用户来说具有重要的参考价值,所以请认真填写。

  • 类似“顶”、“沙发”之类没有营养的文字,对勤劳贡献的楼主来说是令人沮丧的反馈信息。
  • 相信您也不想看到一排文字/表情墙,所以请不要反馈意义不大的重复字符,也请尽量不要纯表情的回复。
  • 提问之前请再仔细看一遍楼主的说明,或许是您遗漏了。
  • 请勿到处挖坑绊人、招贴广告。既占空间让人厌烦,又没人会搭理,于人于己都无利。
;
报警