当前位置：网站首页>说了半天跨平台，今儿咱就来跨跨！（完结篇）——Kubenetes上手实践

说了半天跨平台，今儿咱就来跨跨！（完结篇）——Kubenetes上手实践

2022-08-09 17:18:00 【InfoQ】

两句闲言

去年写过两篇这个系列的文章，出于种种原因（当然主要原因是我懒），没有完成。后来也陆续写了一些别的内容，但始终没有再去把这个尾巴给续上，正好最近接触了一下kubenetes，就以这个为切入点，来完结这个系列吧。
第一篇：
https://xie.infoq.cn/article/5fdeb09ec3872f86727a94a22
第二篇：
https://xie.infoq.cn/article/4f735951a021aa02c5c290f09

几片碎语

其实我写这篇kubernetes内容的底气也不是很足，目前的知识结构主要是建立在部分官方文档的基础上，因为实践成功，有点大喜过望，记录一下过程，也算是给还没有实际接触过kubernetes的老铁们趟趟道。也算正式开启云原生开发之旅了，哈哈！再说为什么要聊kubernetes呢？现在的软件市场，单体应用以后基本没什么发展前途了，早在很多年以前，单体应用的前景就已经能看到天花板了，只是在一些小微企业和特殊的场景里，单体应用还在发光发热。而放眼整个互联网，不论国内还是国外，云原生，分布式，高并发系统都已经相当普及了。所以这就是所谓的“风口”，我觉得程序员还是要顺势而为，投入到有未来，有发展前景的行业中去，跟上时代，不然知识面太窄，造成就业面也太窄，以后再遇上个裁员潮，就真的芭比Q了啊！

准备工作

故事该从哪里说起呢？

如果之前没有接触过kubernetes，上手的时候是一个模糊，朦胧的状态，虽然现在关于kubernetes的文章很多，但有的写的版本比较早，再用新的版本来参照已经不适用，有的写的内容非常大，脱离了入门基础，所以要说起入门级别的指引，还是得看
官方的文档
！其实上手任何工具，框架，或者开发语言，最好的入门资料，绝大多数时候都是官方的文档。虽然有些时候这些文档并没有中文版本，但翻译软件如此发达的当下，这个并不是太大的问题。我这里依照的入门流程就是几篇官方文档，分别是
：
kubernetes的官方文档
：
docker的官方文档
：
kind的官方文档
：
minikube的官方文档
（打了个酱油）
为什么要看这么多文档？答案也很简单，因为不熟！所以在上手的时候，会看到文档里有很多概念，把你指引到相应的地址，其中关联最多的，就是以上四个地方。

注意，我的分享主要是介绍从零开始搭建本地开发环境并实际部署一个集群，其中不会太深入相关概念的解释，建议在上手过程中如果遇到此类困惑，还是去文档中寻求答案。

先试着搭个开发环境吧


这里，我再想多说一句。在选择开发环境，尤其是上手人员还是新手的时候，最好选一个自己熟悉的环境进行操作演练。你平时在windows环境下开发，就选windows的作为开发环境，是macOS就选macOS，不要贸然选一个自己不熟悉的环境去尝试新的东西。现在的各种软件工具，基本都是跨平台支持，即便Windows环境不太适合生产环境，但作为开发环境来练习和入门还是绰绰有余的！

基本情况

先介绍下我本机的相关情况操作系统 ：Windows 11子系统 ：Ubuntu 22.04基本软件 ：docker desktop（V4.11.1，截止到2022.8.9号官方发布的最新版本）

null

准备工作

启用wsl2
如果还没安装，可以参照
官方文档
进行安装，系统需要开启wsl

null
开启wsl2

# 在powershell或者命令提示符终端中输入该命令即可
wsl.exe –set-default-version 2

验证wsl版本（我这里因为已经安装好了docker环境，所以会列出更多内容）

wsl -l -v

null
安装合适的Ubuntu发行版
在windows store中找一个合适的发行版即可，我这里用的是22.04

null
安装好后，根据指引，进入ubuntu子系统，进行更新

# 更新可用软件包的存储库和列表 
sudo apt update

# 根据安装的软件包更新系统 > “-y” 将自动批准更改 
sudo apt upgrade -y

null
安装Docker Desktop
Windows环境下的Docker Desktop安装非常简单，参照
文档
安装即可需要说明的是，在安装之前，请确保系统开启了hyper-v

null
启动wsl集成
打开，docker desktop，进入设置页面，执行相关配置

null
null
配置完成后，进入ubuntu，验证配置是否生效

sudo apt upgrade -y

null
看到终端打印出相关信息，则证明配置生效！
*一点额外操作
到上面那一步，其实基本的配置就完成了，但由于国内的网络环境限制，为了更好的体验，还要配置一些镜像加速类的操作这里我用的是阿里云的镜像加速，基本操作流程可以参照一下官方文档：
https://help.aliyun.com/document_detail/60750.html
根据文档进行一系列配置后，会得到一个加速器地址，结构是这样的：
[系统分配前缀].mirror.aliyuncs.com
。
然后把这个添加到docker的配置文件里就好

 "registry-mirrors": [
 "https://{系统分配的前缀}.mirror.aliyuncs.com"
 ]
null
好了，终于可以正式去创建集群了!

创建集群

kind还是minikube？

两种方式其实都可以，在kubernetes1.24之前，minikube的方式应该是更容易，现在网上的很多资料也都是基于minikube的。但环境来到wsl中后，情况可能会发生变化。这里我把我踩过的坑简单介绍一下，怕折腾的同学可以简单参考一下

  • 安装，这个没什么可说的，在wsl中安装minikube还是很流畅的，执行着几段命令就可以
# 下载
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
# 使二进制可执行文件
chmod +x ./minikube
# 将二进制文件移动到可执行路径
sudo mv ./minikube /usr/local/bin/

  • 启动
minikube start

到这里，会出现一个大概这样“System has not been booted with systemd…”的错误然后到这里，我折腾了一番，为了让wsl中启用systemd，找了很多方法，结果，成功的让我的虚拟机起不来了。。然后为了继续“探索”，我也不得不把子系统删掉，再重新安装了一次。这也是上边这一段为啥没截图的原因，因为不想再折腾一次了~~但后来翻看文档内容，我的尝试应该是方向错了，因为minikube本身提供了基于windows系统的启动方式，并不需要在wsl中使用，所以，如果大家想在Windows上尝试minikube，建议先看一下
文档的介绍
吧~~
对了，我还确实找到了一个可以在wsl中使用systemd的脚本。看评论应该是好使，但我没再继续尝试了，因为它这个脚本也已经实在2019年写的了，而且毕竟也不是官方出的方案，有兴趣的同学可以研究一下，传送门：
https://forum.snapcraft.io/t/running-snaps-on-wsl2-insiders-only-for-now/13033

用kind来创建一个集群

安装kind

打开windows终端，进入到wsl子系统，按顺序输入如下命令，安装kind

# 下载
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.14.0/kind-linux-amd64
# 使二进制可执行文件
chmod +x ./kind
# 将二进制文件移动到可执行路径
sudo mv ./kind /usr/local/bin/kind

null
可以看到，安装流程和minikube的安装流程基本一致

创建一个单节点集群

安装好kind后，可以简单做一些验证性的操作，然后就可以创建集群了

# 创建一个单节点集群，名字叫wslkind
kind create cluster --name wslkind

null
到这里，就已经创建了一个基本的集群节点了。
因为kind本身就是一个适合学习和测试的工具，启动快，资源占用低，但目前不适合生产环境，所以这里更多的内容，就不过多啰嗦了，大家感兴趣可以到官方文档去了解一下。

利用Docker Desktop 创建集群（推荐）

事实上，在Windows环境下创建基于docker的k8s集群，已经变得非常简单，通过docker desktop提供的kubernetes能力就可以完成，关于这一点，docker的官网有更为
详细的介绍
，大家可以去看一下。在Windows环境下，用Docker Desktop来部署k8s集群有一个非常大的优势，就是docker提供了可视化的界面，多数情况下，不需要输入命令就可以完成操作，这对新手来说还是非常友好的。

开启kubernetes

打开Docker Desktop的设置界面，到kubernetes栏目，勾选“Enable Kubernetes”选项，然后应用并重启。

null
执行上述操作后，会自动下载一些镜像到本地，这里我们可以先不用去管。

打包应用镜像

开启kubernetes环境后，既可以去打包我们自己的应用镜像了，这里我之前已经打包好并上传到
dockerhub
了，具体流程，在文章开头的两个链接里有具体介绍，也单独写过一篇相关的
文章
，可以简单参考一下。打包后，登录dockerhub，可以看到自己上传的镜像

null

编写k8s启动文件

为什么要编写一个配置文件？关于这一点，其实内容有
亿
点抽象，我贴一段docker官网上的话（翻译过的，
原文地址
）
“使用 Kubernetes YAML 描述应用程序 Kubernetes 中的所有容器都被调度为 pod，它们是共享一些资源的同地容器组。此外，在实际应用中，我们几乎从不创建单独的 pod；相反，我们的大部分工作负载都被安排为部署，它们是由 Kubernetes 自动维护的可扩展的 Pod 组。最后，所有 Kubernetes 对象都可以并且应该在称为 Kubernetes YAML 文件的清单中进行描述。这些 YAML 文件描述了 Kubernetes 应用程序的所有组件和配置，可用于在任何 Kubernetes 环境中轻松创建和销毁您的应用程序。”
总之，现阶段，我们要知道，需要编写一个yaml格式的文件，来描述应用程序的一些基本内容，通过这个文件，才能让kubernetes来启动集群

apiVersion: apps/v1
kind: Deployment
metadata: 
 name: k8s-cipapi
 namespace: default
 labels:
 name: k8s-cipapi
spec: 
 replicas: 1
 selector:
 matchLabels: 
 name: k8s-cipapi
 template:
 metadata:
 labels:
 name: k8s-cipapi
 spec:
 containers:
 - name: k8s-cipapi
 image: tonydf/cipapi:v220804 # 镜像标识，如果本地不存在就会到dockerhub拉取，当然这个拉去规则是可以设置的。
 ports:
 - containerPort: 8002

---

apiVersion: v1
kind: Service
metadata:
 name: k8s-cipapi
 namespace: default
spec:
 type: NodePort
 selector:
 name: k8s-cipapi
 ports:
 - port: 8002
 targetPort: 80

注意，这里涉及到很多属性，我就简单挑几个说明一下

  • apiVersion，创建该对象所使用的 Kubernetes API 的版本
  • kind，想要创建的对象的类别
  • metadata，帮助唯一标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace
  • spec，你所期望的该对象的状态
  • ---，这三个线表示同级别内容的分割

以上只是外层属性的含义，其中每个属性内部还有各自专属的子属性，的确有些复杂，但好在层次分明，条例清晰，yaml的格式也比json更加简洁，实际理解起来并不是很困难。更具体的大家可以去看
kubernetes的官方文档

启动集群

在windows终端中，通过命令，启动我们自己的k8s

kubectl apply -f .\cipapi.yaml

启动之后可以命令，查看启动状态

kubectl get deployments

null
可以看到，启动集群之后，集群状态并没有马上变成“ready”状态，这是因为我再启动这个集群的时候，并没有在本地打包容器镜像，因此k8s会自动根据我设定的镜像标签去dockerhub拉取镜像。几分钟后，再来看集群状态

null
就已经是启动状态了。还可以通过如下命令，来查看服务状态

 kubectl get services

null
k8s-cipapi就是我们自己的服务项目了。同样的，可以执行docker ps命令，来对照一下容器的状态

null
可以看到，k8s自动帮我们创建了一个容器，并根据我们在yaml中配置的相关内容设置了容器的name。

数据验证

确定集群正常启动后，就可以来验证一下服务是否正常启动了通过命令

kubectl get svc

可以看到k8s给我们部署好的服务的外部端口

null
可以看到，容器内部，使用的是8002端口，暴露给外网访问的端口变成了31494在浏览器访问一下

null
这里呢，是因为swagger的默认配置不支持跨域，而k8s通过类似nginx反向代理的形式把对外的端口改成了31494，所以访问swagger默认文档的时候会提示这个错误，所以这个是系统配置的问题，并不是集群造成的问题。接下来在通过postman来实际访问一下接口，看看效果

null
可以看到，接口成功返回了数据！

通过kubernetes-dashboard来检测集群状态

通过上面的实践，可以看到，部署好集群之后，还要监控集群的状态，而在实际的开发应用中，如果每次都通过命令行的形式来查看，效率就太低了，因此我们可以部署一个dashboard应用，来可视化的管理我们的集群。先上github地址：
https://github.com/kubernetes/dashboard
其实具体安装和配置流程，这个文档里也介绍的很清楚了，我这里就简单过一下流程
安装
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.0/aio/deploy/recommended.yaml
访问
# 要从本地工作站访问 Dashboard，必须为 Kubernetes 集群创建一个代理访问通道
kubectl proxy

代理启动后，在浏览器访问这个地址 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/，就可以看到登陆界面了

null
创建rbac配置文件
要想快速访问这个管理面板，需要创建一个基于rbac的token，为了快速完成这个操作，首先需要创建一个yaml文件

apiVersion: v1
kind: ServiceAccount
metadata:
 name: admin-user
 namespace: kubernetes-dashboard
 
---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: admin-user
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cluster-admin
subjects:
- kind: ServiceAccount
 name: admin-user
 namespace: kubernetes-dashboard

然后通过创建集群的指令，完成服务的部署

kubectl apply -f dashboard-adminuser.yaml

之后，就可以获取token了

kubectl -n kubernetes-dashboard create token admin-user

null
复制这个token值，到登陆界面，就可以看到管理面板了

null
到此，在开发环境部署k8s集群的旅程就基本结束了，接下来就是更加深入的了解，和调整优化了！

结束语

基本就是这些啦，关于k8s和微服务的探索，这仅仅是冰山一角，还有更多的内容等待去挖掘，我也会继续狂奔，顺势而为，希望参与评选的大家，都有好成绩啊，哈哈。



原网站

版权声明
本文为[InfoQ]所创，转载请带上原文链接，感谢
https://xie.infoq.cn/article/945fea47b8e67f9b75a1b20b0

边栏推荐

猜你喜欢

随机推荐