23丨视频：中级篇实操总结

安装kubeadm

我们先来安装Master节点，当然在这之前你需要保证已经安装好了Docker。

首先四步准备工作：改主机名、改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官方文档是一样的，只是改成了国内的软件源。

注意在使用aptinstall的时候，应该明确指定要安装的版本号，像这里我就使用的是Kubernetes1.23.3，如果不指定就会使用当前的最新版本，也就是1.24。

安装完成之后，我们用kubeadmversion、kubectlversion来看一下版本是否正确：

kubeadm version
kubectl version --client

可以看到确实是安装了我们刚才指定的1.23.3版本。

安装Kubernetes

有了kubeadm，我们就可以开始正式安装Kubernetes了。安装时需要从gcr.io拉取镜像，我这里从国内镜像网站上提前下载好了镜像，给你看一下：

docker images

这些镜像中包括Kubernetes的核心组件，比如etcd、apiserver、controller-manager。

现在我们来执行kubeadminit初始化Master节点，看一下脚本文件：

vi master.sh

初始化的时候我使用了参数pod-network-cidr指定Pod的IP地址范围是“10.10.0.0/16”，然后Kubernetes版本也指定使用1.23.3。

为了让kubectl在安装完成后能正常工作，脚本里还会把Kubernetes的配置文件拷贝到当前用户的.kube目录下。

好了，现在我们就运行这个脚本。

注意Master节点初始化完成后，kubeadm会给出一些重要的提示信息，一个是拷贝配置文件，这个我们已经在脚本里做过了，另一个是Worker节点加入集群的kubeadmjoin命令，一定要保存好。我们可以新建一个文件，比如k.txt，然后把它存下来。

我们再用kubectlversion、kubectlgetnode来检查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

稍等一小会，我们再执行kubectlgetnode来看节点状态：

kubectl get node

就看到Master节点的状态是“Ready”，表明节点网络也工作正常了。

Kubernetes集群部署

Worker节点的安装步骤和Master节点是差不多的，先是改主机名，再用prepare.sh做准备工作，修改Docker配置文件、iptables，关闭Linux的swap分区，然后下载kubeadm可执行文件和Kubernetes镜像。

这几步和Master节点完全一样，我就不展示脚本文件了，直接运行。

有了kubeadm之后，因为这个是Worker节点，所以我们不需要执行kubeadminit，而是要执行kubeadmjoin，也就是之前安装Master节点时拷贝的那条命令。它会自动连接Master节点，然后拉取镜像，安装网络插件，最后把节点加入集群。

Worker节点安装好之后，让我们在控制台检查节点的状态，执行kubectlgetnode，会看到两个节点都是“Ready”。

现在让我们用kubectl run，运行Nginx来测试一下：

kubectl run ngx --image=nginx:alpine
kubectl get pod -o wide

会看到Pod运行在Worker节点上，表明我们的Kubernetes多节点集群部署成功。

Deployment的使用

接下来我们来看看Deployment的用法。

首先是kubectlapi-resources来查看Deployment的基本信息：

kubectl api-resources | grep deploy

可以看到Deployment的简称是“deploy”，它的apiVersion是“apps/v1”，kind是“Deployment”。

然后我们执行kubectlcreate，让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，意思是启动两个NginxPod。

把Deployment的YAML写好之后，我们就可以用kubectlapply来创建对象了：

kubectl apply -f deploy.yml

用kubectlget命令查看Deployment的状态：

kubectl get deploy
kubectl get pod

最后来试验一下Deployment的应用伸缩功能，使用命令kubectlscale，把Pod数量改成5个：

kubectl scale --replicas=5 deploy ngx-dep

我们再用kubectlget命令查看，就会发现Pod已经成功变成了5个副本：

kubectl get pod 

最后删除这个Deployment：

kubectl delete deploy ngx-dep

DaemonSet的使用

看完Deployment，我再来演示DaemonSet。

因为DaemonSet不能使用kubectlcreate直接生成样板文件，但大体结构和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

再用kubectlget查看对象的状态：

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管理了两个NginxPod：

kubectl get pod -o wide

然后我们我们使用kubectlexpose创建Service样板文件：

kubectl expose deploy ngx-dep --port=80 --target-port=80 $out

修改之后就是svc.yml，再用kubectlapply创建Service对象：

kubectl apply -f svc.yml

用kubectlgetsvc可以列出Service对象，可以看到它的虚IP地址：

kubectl get svc

想要看Service代理了哪些后端的Pod，要用kubectldescribe命令：

kubectl describe svc ngx-svc

用kubectlgetpod可以对比验证Service是否正确代理了NginxPod：

kubectl get pod -o wide

现在让我们用kubectlexec进入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公司开发的IngressController，需要按照它的文档，创建名字空间、RBAC等相关的资源，这里我使用一个简单脚本来完成：

cat setup.sh
./setup.sh

使用命令kubectlgetns可以看到已经有了一个新的名字空间nginx-ingress。

为了测试验证Ingress和Ingresscontroller的用法，我们还是要先创建Deployment和Service对象：

kubectl apply -f deploy.yml
kubectl apply -f svc.yml

来看一下Ingress的定义：

vi ingress.yml

这个YAML里包含了两个API对象，第一个是IngressClass，名字是ngx-ink，注意在spec里，controller要指定成NginxIngressController。

第二个对象就是路由规则对象Ingress了，我为它添加了一个注解nginx.org/lb-method，指定使用Round-Robin负载均衡算法，然后是关键字段ingressClassName，这样就可以把Ingress和IngressClass联系起来。

后面的rules就是具体的路由规则，比较复杂，要指定host、path，还有后端要转发的Service，最好用kubectlcreate来自动生成，不然很容易写错。

接下来我们看看IngressController的定义，它在kicYAML里：

vi kic.yml

它其实是从Nginx官方的示例文件修改而来的，所以只需要关注几个地方。

第一个是镜像，我改成了更精简的Alpine版本，第二个是启动参数args，一定要加上-ingress-class，关联上刚才的IngressClass对象，否则IngressController就无法找到路由规则Ingress。

它后面还有几个参数，比如-health-status、-ready-status等等，你可以参考官方文档了解它们的作用。

现在我们就应用这两个YAML文件，创建Ingress对象：

kubectl apply -f ingress.yml
kubectl apply -f kic.yml

用kubectlget来逐个查看这些对象的状态：

kubectl get ingressclass
kubectl get ing
kubectl describe ing ngx-ing

kubectl get deploy -n nginx-ingress
kubectl get pod -n nginx-ingress

确认它们都工作正常，我们来做个测试，把本地的8080端口映射到IngressControllerPod的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

多执行几次，你就会发现NginxIngressController通过域名路由规则，把请求转发到了不同的后端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的定义和之前差不多，但IngressClass的名字改成了wp-ink，Ingress路由的host改成了wp.test。

IngressController的变化也不大：

vi wp-kic.yml

关键还是args里的参数-ingress-class，必须和IngressClass匹配，也就是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来访问NginxIngressController，再访问WordPress网站了。