因收到Google相关通知，网站将会择期关闭。相关通知内容 23 视频：中级篇实操总结 你好，我是Chrono。 到今天我们“中级篇”的学习也告一段落了，在这段时间里我们使用kubeadm搭建了更接近生产环境的多节点Kubernetes集群，然后学习了Deployment、DaemonSet、Service、Ingress这4个非常重要的API对象。 这节课作为对“中级篇”的总结和回顾，仍然是视频的形式，把前面几节课里的一些操作都实际演示出来，方便你对照着操作上下文来学习。 首先我会带你看看kubeadm搭建集群的完整过程，然后编写YAML文件，示范Deployment、DaemonSet、Service、Ingress等对象的具体用法，最后是使用这些对象搭建WordPress网站。 让我们开始视频课程的学习吧。 一点说明：视频是我的操作实录，有些包安装比较慢，屏幕会几秒没有动作，在参考视频以及你自己操作的时候可以耐心一些。 一. 安装kubeadm 我们先来安装Master节点，当然在这之前你需要保证已经安装好了Docker（安装参考[第1讲]）。 首先四步准备工作：改主机名、改Docker配置、改网络设置、改交换分区。 修改主机名，把它改成 master： sudo vi /etc/hostname 修改Docker的配置文件，把cgroup的驱动程序改成 systemd，然后是修改iptables的配置，启用 br_netfilter 模块，还有修改“/etc/fstab”，关闭Linux的swap分区。 这些操作步骤都已经列在了[第17讲]里了，因为一个个文件修改很麻烦，我就写了一个脚本文件，把这些操作都自动化了，大概看一下： vi prepare.sh 第一部分是修改Docker配置文件然后重启，第二部分是修改iptables配置，第三部分是关闭Linux的swap分区。我们执行这个脚本，安装的准备工作就做好了。 接下来，下载kubeadm可执行文件，同样我也写成了一个方便的脚本文件： vi admin.sh 基本流程和Kubernetes官方文档是一样的，只是改成了国内的软件源。 注意在使用 apt install 的时候，应该明确指定要安装的版本号，像这里我就使用的是Kubernetes 1.23.3，如果不指定就会使用当前的最新版本，也就是1.24。 安装完成之后，我们用 kubeadm version、kubectl version 来看一下版本是否正确： kubeadm version kubectl version --client 可以看到确实是安装了我们刚才指定的1.23.3版本。 二. 安装Kubernetes 有了kubeadm，我们就可以开始正式安装Kubernetes了。安装时需要从gcr.io拉取镜像，我这里从国内镜像网站上提前下载好了镜像，给你看一下： docker images 这些镜像中包括Kubernetes的核心组件，比如etcd、apiserver、controller-manager。 现在我们来执行 kubeadm init 初始化Master节点，看一下脚本文件： vi master.sh 初始化的时候我使用了参数 pod-network-cidr 指定Pod的IP地址范围是“10.10.0.0/16”，然后Kubernetes版本也指定使用1.23.3。 为了让kubectl在安装完成后能正常工作，脚本里还会把Kubernetes的配置文件拷贝到当前用户的 .kube 目录下。 好了，现在我们就运行这个脚本。 注意Master节点初始化完成后，kubeadm会给出一些重要的提示信息，一个是拷贝配置文件，这个我们已经在脚本里做过了，另一个是Worker节点加入集群的 kubeadm join 命令，一定要保存好。我们可以新建一个文件，比如k.txt，然后把它存下来。 我们再用 kubectl version、kubectl get node 来检查Kubernetes的版本和集群的节点状态了： kubectl version kubectl get node Master节点的状态是“NotReady”，接下来还要安装网络插件Flannel。 Flannel的安装很简单，记得要修改它的YAML文件，“net-conf.json”里的网络范围必须和 kubeadm init 里的一样： vi flannel.yml 现在我们用 kubectl apply 来安装Flannel网络： kubectl apply -f kube-flannel.yml 稍等一小会，我们再执行 kubectl get node 来看节点状态： kubectl get node 就看到Master节点的状态是“Ready”，表明节点网络也工作正常了。 三. Kubernetes集群部署 Worker节点的安装步骤和Master节点是差不多的，先是改主机名，再用prepare.sh做准备工作，修改Docker配置文件、iptables，关闭Linux的swap分区，然后下载kubeadm可执行文件和Kubernetes镜像。 这几步和Master节点完全一样，我就不展示脚本文件了，直接运行。 有了kubeadm之后，因为这个是Worker节点，所以我们不需要执行 kubeadm init，而是要执行 kubeadm join，也就是之前安装Master节点时拷贝的那条命令。它会自动连接Master节点，然后拉取镜像，安装网络插件，最后把节点加入集群。 Worker节点安装好之后，让我们在控制台检查节点的状态，执行 kubectl get node，会看到两个节点都是“Ready”。 现在让我们用 kubectl run，运行Nginx来测试一下： kubectl run ngx --image=nginx:alpine kubectl get pod -o wide 会看到Pod运行在Worker节点上，表明我们的Kubernetes多节点集群部署成功。 四. Deployment的使用 接下来我们来看看Deployment的用法。 首先是 kubectl api-resources 来查看Deployment的基本信息： kubectl api-resources | grep deploy 可以看到Deployment的简称是“deploy”，它的apiVersion是“apps/v1”，kind是“Deployment”。 然后我们执行 kubectl create，让Kubernetes为我们自动生成Deployment的样板文件。 先要定义一个环境变量out: export out="--dry-run=client -o yaml" 然后创建名字叫“ngx-dep”的对象，使用的镜像是“nginx:alpine”： kubectl create deploy ngx-dep --image=nginx:alpine $out 我们把这个样板存入一个文件ngx.yml： kubectl create deploy ngx-dep --image=nginx:alpine $out > deploy.yml 这里可以删除一些不需要的字段，让YAML看起来更干净，然后把replicas改成2，意思是启动两个Nginx Pod。 把Deployment的YAML写好之后，我们就可以用 kubectl apply 来创建对象了： kubectl apply -f deploy.yml 用 kubectl get 命令查看Deployment的状态： kubectl get deploy kubectl get pod 最后来试验一下Deployment的应用伸缩功能，使用命令 kubectl scale，把Pod数量改成5个： kubectl scale --replicas=5 deploy ngx-dep 我们再用 kubectl get 命令查看，就会发现Pod已经成功变成了5个副本： kubectl get pod 最后删除这个Deployment： kubectl delete deploy ngx-dep 五. DaemonSet的使用 看完Deployment，我再来演示DaemonSet。 因为DaemonSet不能使用 kubectl create 直接生成样板文件，但大体结构和Deployment是一样的，所以我们可以先生成一个Deployment，然后再修改几个字段就行了。 这里我使用了Linux系统里常用的小工具sed，直接替换Deployment里的名字，再删除replicas字段，这样就自动生成了DaemonSet的样板文件： kubectl create deploy redis-ds --image=redis:5-alpine $out \ | sed 's/Deployment/DaemonSet/g' - \ | sed -e '/replicas/d' - 这个样板文件因为是从Deployment改来的，所以不会有tolerations字段，不能在Master节点上运行，需要手工添加。 下面这个就是已经改好的完整的DaemonSet YAML描述文件： vi ds.yml 注意看里面的tolerations字段，它能够容忍节点的 node-role.kubernetes.io/master:NoSchedule 这个污点，也就是说能够运行在Master节点上。 现在让我们部署这个加上了“容忍度”的DaemonSet： kubectl apply -f ds.yml 再用 kubectl get 查看对象的状态： kubectl get ds kubectl get pod -o wide 可以看到，这个Redis 的DaemonSet已经跑在了Master和Worker节点上。 最后删除这个DaemonSet： kubectl delete -f ds.yml 六. Service的使用 下面我们来看看Kubernetes里的负载均衡对象Service。 因为Service对象服务于Pod、Deployment等对象，所以在创建它之前，我们需要先创建一个Deployment： kubectl apply -f deploy.yml 这个Deployment管理了两个Nginx Pod： kubectl get pod -o wide 然后我们我们使用 kubectl expose 创建Service样板文件： kubectl expose deploy ngx-dep --port=80 --target-port=80 $out 修改之后就是svc.yml，再用 kubectl apply 创建Service对象： kubectl apply -f svc.yml 用 kubectl get svc 可以列出Service对象，可以看到它的虚IP地址： kubectl get svc 想要看Service代理了哪些后端的Pod，要用 kubectl describe 命令： kubectl describe svc ngx-svc 用 kubectl get pod 可以对比验证Service是否正确代理了Nginx Pod： kubectl get pod -o wide 现在让我们用 kubectl exec 进入Pod，验证Service的域名功能： kubectl exec -it ngx-dep-6796688696-4h6lb -- sh 使用curl，加上域名“ngx-svc”，也就是Service对象的名字： curl ngx-svc 多执行几次，就会看到通过这个域名，Service对象实现了对后端Pod的负载均衡，把流量分发到不同的Pod。 我们还可以再尝试Service的其他域名形式，比如加上名字空间： curl ngx-svc.default curl ngx-svc.default.svc.cluster.local 最后看一下Service使用NodePort方式对外暴露服务的用法，看一下Service对象： kubectl get svc 在PORT里显示它分配了一个随机的端口号31980，只要访问集群里任意一个节点，加上这个端口号，就可以访问到Service对象和它后面的Pod。 我们来试验一下，注意210是Master节点，220是Worker节点： curl 192.168.10.210:31980 curl 192.168.10.220:31980 最后删除Deployment和Service对象： kubectl delete -f deploy.yml kubectl delete -f svc.yml 七. Ingress的使用 学习了Service之后，我们再来看管理集群入口流量的Ingress对象。 我们使用Nginx公司开发的Ingress Controller，需要按照它的文档，创建名字空间、RBAC等相关的资源，这里我使用一个简单脚本来完成： cat setup.sh ./setup.sh 使用命令 kubectl get ns 可以看到已经有了一个新的名字空间 nginx-ingress。 为了测试验证Ingress和Ingress controller的用法，我们还是要先创建Deployment和Service对象： kubectl apply -f deploy.yml kubectl apply -f svc.yml 来看一下Ingress的定义： vi ingress.yml 这个YAML里包含了两个API对象，第一个是Ingress Class，名字是ngx-ink，注意在spec里，controller要指定成Nginx Ingress Controller。 第二个对象就是路由规则对象Ingress了，我为它添加了一个注解nginx.org/lb-method，指定使用Round-Robin负载均衡算法，然后是关键字段ingressClassName，这样就可以把Ingress和Ingress Class联系起来。 后面的rules就是具体的路由规则，比较复杂，要指定host、path，还有后端要转发的Service，最好用kubectl create来自动生成，不然很容易写错。 接下来我们看看Ingress Controller的定义，它在kic YAML 里： vi kic.yml 它其实是从Nginx官方的示例文件修改而来的，所以只需要关注几个地方。 第一个是镜像，我改成了更精简的Alpine版本，第二个是启动参数args，一定要加上-ingress-class，关联上刚才的Ingress Class对象，否则Ingress Controller就无法找到路由规则Ingress。 它后面还有几个参数，比如-health-status、-ready-status等等，你可以参考官方文档了解它们的作用。 现在我们就应用这两个YAML 文件，创建Ingress对象： kubectl apply -f ingress.yml kubectl apply -f kic.yml 用 kubectl get 来逐个查看这些对象的状态： kubectl get ingressclass kubectl get ing kubectl describe ing ngx-ing kubectl get deploy -n nginx-ingress kubectl get pod -n nginx-ingress 确认它们都工作正常，我们来做个测试，把本地的8080端口映射到Ingress Controller Pod的80端口： kubectl port-forward -n nginx-ingress ngx-kic-dep-8859b7b86-cplgp 8080:80 & 因为在Ingress里我们设定的路由规则是ngx.test域名，所以要用curl的resolve参数来把它强制解析到127.0.0.1： curl --resolve ngx.test:8080:127.0.0.1 http://ngx.test:8080 多执行几次，你就会发现Nginx Ingress Controller通过域名路由规则，把请求转发到了不同的后端Pod。 最后我们删除刚才创建的这些Deployment、Service、Ingress等对象： kubectl delete -f deploy.yml kubectl delete -f svc.yml kubectl delete -f ingress.yml kubectl delete -f kic.yml 八. 搭建WordPress网站 这里我们还是来搭建WordPress网站，实际操作Deployment、Service、Ingress这些对象的用法。 第一步是部署MariaDB： wp-maria.yml 它的ConfigMap没有变化，还是“DATABASE”“USER”“PASSWORD”那几个环境变量。下面的部署方式改成了Deployment，简单起见只使用一个实例。之后又为它定义了一个Service对象，这样我们就可以使用域名而不是IP地址来访问数据库。 第二步是部署WordPress应用： vi wp-dep.yml 注意在ConfigMap里我们不再使用固定IP地址了，而是改用了Service提供的域名maria-svc。然后在Deployment里，把WordPress实例设置为2，增加了冗余度，提高了可用性。之后我们还是为它定义了Service对象，并且设置为NodePort模式，指定使用端口30088。 第三步是部署Ingress： vi wp-ing.yml Ingress的定义和之前差不多，但Ingress Class的名字改成了wp-ink，Ingress路由的host改成了wp.test。 Ingress Controller的变化也不大： vi wp-kic.yml 关键还是args里的参数-ingress-class，必须和Ingress Class匹配，也就是wp-ink。还有就是字段hostNetwork: true，让Pod直接使用节点的网络 看完了这些YAML ，让我们用kubectl apply来创建对象： kubectl apply -f wp-maria.yml kubectl apply -f wp-dep.yml kubectl apply -f wp-ing.yml kubectl apply -f wp-kic.yml 创建完成之后，我们再用kubectl get看一下对象的状态： kubectl get deploy kubectl get svc kubectl get pod -n nginx-ingress 现在让我们来到集群之外，假设你已经修改了本地的hosts域名解析文件，把域名wp.test解析到Kubernetes的节点，那就可以直接在浏览器里输入http://wp.test来访问Nginx Ingress Controller，再访问WordPress网站了。 课后作业 如果你在操作过程中遇到困难，欢迎在留言区留言，记得把你的问题描述清楚，这样我和其他同学也能更好地就问题详细讨论。 希望你在这段时间的学习过程中有所收获，下节课就是最后的高级篇了，我们下节课再见。