实例介绍
【实例截图】
【核心代码】
目录
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 _Toc7796 \h 14
查看网桥过滤模块是否加载成功 PAGEREF _Toc13365 \h 14
1.安装ipset和ipvsadm 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 Driver为cgroupfs，而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、安装kubeadm、kubelet和kubectl PAGEREF _Toc2952 \h 15
4、配置kubelet的cgroup PAGEREF _Toc10172 \h 15
编辑/etc/sysconfig/kubelet, 添加下面的配置 PAGEREF _Toc27670 \h 15
5、设置kubelet开机自启 PAGEREF _Toc12631 \h 15
在安装kubernetes集群之前，必须要提前准备好集群需要的镜像，所需镜像可以通过下面命令查看 PAGEREF _Toc21271 \h 16
此镜像kubernetes的仓库中，由于网络原因，无法连接，下面提供了一种替换方案 PAGEREF _Toc20145 \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
4 null类型 PAGEREF _Toc3366 \h 19
5 日期类型 PAGEREF _Toc11115 \h 19
6 时间类型 PAGEREF _Toc12475 \h 19
7 字符串类型 PAGEREF _Toc30820 \h 19
形式一(推荐): PAGEREF _Toc18122 \h 19
形式二(了解): PAGEREF _Toc6871 \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下创建并运行一个nginx的Pod 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支持的格式有很多，比较常见的是wide、json、yaml 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 _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
命令格式: 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
暴露Service PAGEREF _Toc29929 \h 30
查看service PAGEREF _Toc18373 \h 30
这里产生了一个CLUSTER-IP，这就是service的IP，在Service的生命周期中，这个地址是不会变动的 PAGEREF _Toc13432 \h 30
可以通过这个IP访问当前service对应的POD PAGEREF _Toc10167 \h 30
Welcome to nginx! PAGEREF _Toc9830 \h 30
上面创建的Service的type类型为ClusterIP，这个ip地址只用集群内部可访问 PAGEREF _Toc21444 \h 30
如果需要创建外部也可以访问的Service，需要修改type为NodePort PAGEREF _Toc30558 \h 30
此时查看，会发现出现了NodePort类型的Service，而且有一对Port（80:31928/TC） PAGEREF _Toc20898 \h 30
接下来就可以通过集群外的主机访问 节点IP:31928访问服务了 PAGEREF _Toc23310 \h 30
例如在的电脑主机上通过浏览器访问下面的地址 PAGEREF _Toc32725 \h 31
在这里，可通过一个命令来查看每种资源的可配置项 PAGEREF _Toc21680 \h 32
kubectl explain 资源类型 查看某种资源可以配置的一级属性 PAGEREF _Toc15764 \h 32
kubectl explain 资源类型.属性 查看属性的子属性 PAGEREF _Toc23153 \h 32
查看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 _Toc19952 \h 34
此时明显可以看到nginx镜像有一步Pulling image "nginx:1.17.1"的过程 PAGEREF _Toc25861 \h 34
查看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
进入容器，输出环境变量 PAGEREF _Toc21380 \h 35
在下面可以明显看到配置信息 PAGEREF _Toc17363 \h 36
查看发现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 _Toc8882 \h 39
发现pod卡在启动第一个初始化容器过程中，后面的容器不会运行 PAGEREF _Toc17108 \h 39
动态查看pod PAGEREF _Toc14045 \h 39
接下来新开一个shell，为当前服务器新增两个ip，观察pod的变化 PAGEREF _Toc864 \h 39
查看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 _Toc25953 \h 41
观察上面的信息，发现尝试访问8080端口,但是失败了 PAGEREF _Toc17099 \h 42
稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长 PAGEREF _Toc6348 \h 42
当然接下来，可以修改成一个可以访问的端口，比如80，再试，结果就正常了...... PAGEREF _Toc2690 \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详情，发现nginx容器失败 PAGEREF _Toc21282 \h 43
多等一会，再观察pod的重启次数，发现一直是0，并未重启 PAGEREF _Toc10194 \h 43
查看Pod调度到NODE属性，确实是调度到了node1节点上 PAGEREF _Toc12883 \h 44
接下来，删除pod，修改nodeName的值为node3（并没有node3节点） PAGEREF _Toc31107 \h 44
再次查看，发现已经向Node3节点调度，但是由于不存在node3节点，所以pod无法正常运行 PAGEREF _Toc7463 \h 44
查看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 _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
此时查看，发现调度成功，已经将pod调度到了node1上 PAGEREF _Toc20819 \h 47
查看pod状态 （运行成功） PAGEREF _Toc923 \h 47
启动目标pod PAGEREF _Toc2230 \h 48
查看pod状况 PAGEREF _Toc19743 \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=yyy的pod在同一Node上 PAGEREF _Toc26414 \h 49
然后重新创建pod，查看效果 PAGEREF _Toc24757 \h 49
发现此时Pod运行正常 PAGEREF _Toc6090 \h 49
发现调度到了node2上 PAGEREF _Toc27406 \h 49
去除所有污点 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
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
当然也可以直接使用命令实现 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前，会将RS的replicasclear调整为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的名称是在原来deployment的名字后面添加了一个10位数的随机串 PAGEREF _Toc32356 \h 56
变更副本数量为5个 PAGEREF _Toc12443 \h 56
查看deployment PAGEREF _Toc24976 \h 56
编辑deployment的副本数量，修改spec:replicas: 4即可 PAGEREF _Toc29914 \h 56
观察升级过程 PAGEREF _Toc10089 \h 57
至此，新版本的pod创建完毕，就版本的pod销毁完毕 PAGEREF _Toc30321 \h 58
中间过程是滚动进行的，也就是边销毁边创建 PAGEREF _Toc20269 \h 58
查看rs,发现原来的rs的依旧存在，只是pod数量变为了0，而后又新产生了一个rs，pod数量为4 PAGEREF _Toc30640 \h 58
其实这就是deployment能够进行版本回退的奥妙所在，后面会详细解释 PAGEREF _Toc6516 \h 58
查看当前升级版本的状态 PAGEREF _Toc2031 \h 58
查看升级历史记录 PAGEREF _Toc4121 \h 59
可以发现有三次版本记录，说明完成过两次升级 PAGEREF _Toc20475 \h 59
这里直接使用--to-revision=1回滚到了1版本， 如果省略这个选项，就是回退到上个版本，就是2版本 PAGEREF _Toc2393 \h 59
查看发现，通过nginx镜像版本可以发现到了第一版 PAGEREF _Toc12817 \h 59
查看rs，发现第一个rs中有4个pod运行，后面两个版本的rs中pod为运行 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，其下的rs和pod也将被删除 PAGEREF _Toc26444 \h 60
获取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
创建daemonset PAGEREF _Toc17791 \h 64
查看daemonset PAGEREF _Toc8619 \h 64
查看pod,发现在每个Node上都运行一个pod PAGEREF _Toc20234 \h 64
删除daemonset PAGEREF _Toc15738 \h 64
通过观察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会每次运行3个pod，总共执行了6个pod PAGEREF _Toc10878 \h 65
创建cronjob PAGEREF _Toc7857 \h 66
查看cronjob PAGEREF _Toc32231 \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
为了方便后面的测试，修改下三台nginx的index.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
删除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
接下来可以通过电脑主机的浏览器去访问集群中任意一个nodeip的30002端口，即可访问到pod PAGEREF _Toc13427 \h 71
创建service PAGEREF _Toc11492 \h 71
获取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
创建ingress-nginx PAGEREF _Toc18066 \h 73
查看ingress-nginx PAGEREF _Toc31472 \h 73
查看service PAGEREF _Toc13638 \h 73
接下来,在本地电脑上配置host文件,解析上面的两个域名到192.168.109.100(master)上 PAGEREF _Toc27341 \h 74
然后,就可以分别访问tomcat.itheima.com:32240 和 nginx.itheima.com:32240 查看效果了 PAGEREF _Toc19580 \h 74
通过podIp访问nginx PAGEREF _Toc28982 \h 76
通过kubectl logs命令查看指定容器的标准输出 PAGEREF _Toc14735 \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
查看nfs服务器上的共享目录，发现已经有文件了 PAGEREF _Toc6022 \h 78
storage: 1Gi PAGEREF _Toc6865 \h 80
storage: 1Gi PAGEREF _Toc9877 \h 80
readOnly: false PAGEREF _Toc29109 \h 81
查看nfs中的文件存储 PAGEREF _Toc6771 \h 81
创建configmap PAGEREF _Toc24999 \h 82
查看configmap详情 PAGEREF _Toc13586 \h 82
cd /configmap/config/ PAGEREF _Toc5859 \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
进入容器，查看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将特定的subject与ClusterRole绑定，授予权限 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
查看dev下pod，发现没有权限 PAGEREF _Toc20008 \h 88
切换到admin账户 PAGEREF _Toc10069 \h 88
切换账户到devman PAGEREF _Toc5026 \h 88
为了不影响后面的学习,切回admin账户 PAGEREF _Toc4452 \h 89
修改kubernetes-dashboard的Service类型 PAGEREF _Toc4096 \h 90
查看namespace下的kubernetes-dashboard下的资源 PAGEREF _Toc25326 \h 90
小贴士
感谢您为本站写下的评论，您的评论对其它用户来说具有重要的参考价值，所以请认真填写。
- 类似“顶”、“沙发”之类没有营养的文字，对勤劳贡献的楼主来说是令人沮丧的反馈信息。
- 相信您也不想看到一排文字/表情墙，所以请不要反馈意义不大的重复字符，也请尽量不要纯表情的回复。
- 提问之前请再仔细看一遍楼主的说明，或许是您遗漏了。
- 请勿到处挖坑绊人、招贴广告。既占空间让人厌烦，又没人会搭理，于人于己都无利。
关于好例子网
本站旨在为广大IT学习爱好者提供一个非营利性互相学习交流分享平台。本站所有资源都可以被免费获取学习研究。本站资源来自网友分享，对搜索内容的合法性不具有预见性、识别性、控制性，仅供学习研究，请务必在下载后24小时内给予删除，不得用于其他任何用途，否则后果自负。基于互联网的特殊性，平台无法对用户传输的作品、信息、内容的权属或合法性、安全性、合规性、真实性、科学性、完整权、有效性等进行实质审查；无论平台是否已进行审查，用户均应自行承担因其传输的作品、信息、内容而可能或已经产生的侵权或权属纠纷等法律责任。本站所有资源不代表本站的观点或立场，基于网友分享，根据中国法律《信息网络传播权保护条例》第二十二与二十三条之规定，若资源存在侵权或相关问题请联系本站客服人员，点此联系我们。关于更多版权及免责申明参见 版权及免责申明
网友评论
我要评论