云原生之容器编排实践-SpringBoot应用以Deployment方式部署到minikube以及弹性伸缩

简介: 云原生之容器编排实践-SpringBoot应用以Deployment方式部署到minikube以及弹性伸缩

G50XKKJAH3S9E4SW@Q~4YPY.png

背景


在实际生产环境下,我们更多的是使用 yaml 描述文件来启动一个 Pod ,并设置 kind 属性值为 Deployment 类型。


Deployment


使用 Deployment 来部署应用,重点关注其可以实现应用服务的动态扩缩容。

需要注意的是:应用本身需要支持水平伸缩。 Kubernetes 并不会让你的应用变得可扩展,它只是让应用的扩缩容变得简单。


yaml


[root@k8s0 ~]# vi cloud-native-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  # 部署名字
  name: cloud-native
spec:
  replicas: 2
  # 用来查找关联的Pod,所有标签都匹配才可以
  selector:
    matchLabels:
      app: cloud-native
  # 定义 Pod 相关数据
  template:
    metadata:
      labels:
        app: cloud-native
    spec:
      # 定义容器,可以多个
      containers:
        - name: cloud-native # 容器名字
          image: registry.cn-hangzhou.aliyuncs.com/container-repo/docker-hub:0.0.1-SNAPSHOT
      imagePullSecrets:
        - name: aliyunregistry
# 通过yaml描述文件启动deployment
[root@k8s0 ~]# kubectl apply -f cloud-native-deployment.yaml 
deployment.apps/cloud-native created

查看Kubernetes资源


通过 yaml 描述文件启动 Deployment 之后,我们可以通过 kubectl get pods , kubectl get deployment 以及 kubectl get all 来观察所发生的变化:根据我们的 yaml 配置,会启动两个副本的服务实例。


[root@k8s0 ~]# kubectl get pods
NAME                              READY   STATUS    RESTARTS      AGE
cloud-native                      1/1     Running   0             48m
cloud-native-684d4d8485-c2zgz     1/1     Running   0             4s
cloud-native-684d4d8485-f7qzm     1/1     Running   0             4s
hello-minikube-58647b77b8-srpbq   1/1     Running   6 (74m ago)   30d
[root@k8s0 ~]# kubectl get deployment
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
cloud-native     2/2     2            2           18s
hello-minikube   1/1     1            1           30d
# 查看所有Kubernetes资源
[root@k8s0 ~]# kubectl get all

弹性伸缩


可通过 kubectl scale 命令的 --replicas 参数来实现 Pod 副本数的弹性伸缩。需要注意的是,伸缩过程并不是一蹴而就的。我们并不是告诉 Kubernetes 需要采取什么行动,也没有告诉 Kubernetes 增加3个 Pod ,只设置新的期望的实例数量并让 Kubernetes 决定需要采取哪些操作来实现期望的状态。这是 Kubernetes 基本的原则之一。不是告诉 Kubernetes 应该执行什么操作,而是声明性地改变系统的期望状态,并让 Kubernetes 检查当前的状态是否与期望的状态一致。在整个 Kubernetes 的世界中都是这样的。当指定副本数为5时,那么最终调整得到的结果便是5个副本,不多也不少。


[root@k8s0 ~]# kubectl scale deployment cloud-native --replicas=5
[root@k8s0 ~]# kubectl get pod
NAME                              READY   STATUS    RESTARTS      AGE
cloud-native                      1/1     Running   0             62m
cloud-native-684d4d8485-c2zgz     1/1     Running   0             14m
cloud-native-684d4d8485-f7qzm     1/1     Running   0             14m
cloud-native-684d4d8485-rsbg7     1/1     Running   0             5s
cloud-native-684d4d8485-s9lkj     1/1     Running   0             5s
cloud-native-684d4d8485-skmtk     1/1     Running   0             5s
hello-minikube-58647b77b8-srpbq   1/1     Running   6 (88m ago)   30d

由于一开始我们的副本数配置是2,当指定副本数为5时,我们看到现在的 Pod 列表中 cloud-native 有3个新增的副本:即Age为5s的那3个。


查看Deployment详情


可通过 kubectl describe 命令查看 Pod 的详细信息,不过其输出内容过长,这里省略了。此外,可通过 kubectl exec 类似于 Docker 的命令进入到 Pod 内部,进行一系列的操作。


[root@k8s0 ~]# kubectl describe pod cloud-native-684d4d8485-rsbg7
[root@k8s0 ~]# kubectl exec -it cloud-native-684d4d8485-rsbg7 -- sh

回滚历史版本


时空穿梭,救火专用。


[root@k8s0 ~]# kubectl rollout history deployment cloud-native
deployment.apps/cloud-native 
REVISION  CHANGE-CAUSE
1         <none>

删除Deployment


[root@k8s0 ~]# kubectl delete deployment cloud-native
deployment.apps "cloud-native" deleted
[root@k8s0 ~]# kubectl get pod
NAME                              READY   STATUS    RESTARTS      AGE
cloud-native                      1/1     Running   0             64m
hello-minikube-58647b77b8-srpbq   1/1     Running   6 (90m ago)   30d
可以看到名为 cloud-native 的 Deployment 已被删除,需要注意的是上面还剩下一个名为 cloud-native 的 Pod ,这是我们上一篇中以 kind: Pod 方式启动的,所以删除 Deployment 并不会删除这个 Pod 。


Dashboard


EFFZ9Z`)MQNS4U]%X7D(4Q0.png


其实,除了前面通过命令行查看已经运行的 Deployment 以及 Pod 信息,我们还可以通过 Kubernetes 为我们提供的 Dashboard 以可视化的方式观测我们运行的 Kubernetes 资源信息。访问 Dashboard 具体操作方式可参考:云原生之容器编排实践-在CentOS7上安装minikube


If you have any questions or any bugs are found, please feel free to contact me.

Your comments and suggestions are welcome!

目录
相关文章
|
3天前
|
存储 Cloud Native 文件存储
云原生之使用Docker部署home-page个人导航页
【5月更文挑战第4天】云原生之使用Docker部署home-page个人导航页
17 1
|
23小时前
|
Cloud Native 测试技术 Linux
云原生之使用Docker部署homer静态主页
【5月更文挑战第7天】云原生之使用Docker部署homer静态主页
8 0
|
1天前
|
监控 Cloud Native 测试技术
云原生之使用Docker部署ServerBee服务器监控工具
【5月更文挑战第6天】云原生之使用Docker部署ServerBee服务器监控工具
10 1
|
2天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第9天】 随着数字化转型的浪潮席卷全球,企业正迅速采纳云原生技术以实现敏捷性、可扩展性和弹性。本文深入探讨了云原生架构的关键组件,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps文化,并分析了这些技术如何帮助企业加速产品上市时间,提高运营效率,并最终实现业务目标。同时,文章也识别了企业在采纳云原生实践中可能面临的挑战,如安全性考量、团队技能提升和复杂的网络管理,并提出了相应的解决方案和最佳实践。
|
4天前
|
Kubernetes Cloud Native 持续交付
【Docker专栏】Kubernetes与Docker:协同构建云原生应用
【5月更文挑战第7天】本文探讨了Docker和Kubernetes如何协同构建和管理云原生应用。Docker提供容器化技术,Kubernetes则负责容器的部署和管理。两者结合实现快速部署、自动扩展和高可用性。通过编写Dockerfile创建镜像,然后在Kubernetes中定义部署和服务进行应用暴露。实战部分展示了如何部署简单Web应用,包括编写Dockerfile、构建镜像、创建Kubernetes部署配置以及暴露服务。Kubernetes还具备自动扩展、滚动更新和健康检查等高级特性,为云原生应用管理提供全面支持。
【Docker专栏】Kubernetes与Docker:协同构建云原生应用
|
5天前
|
Kubernetes Cloud Native 持续交付
探索云原生架构的未来:如何优化资源管理和服务部署
【5月更文挑战第6天】 随着云计算的快速发展,云原生技术已成为企业数字化转型的关键驱动力。此篇文章深入探讨了云原生架构的核心组件及其在资源管理和服务部署方面的优化策略。通过分析容器化、微服务及自动化管理的实践案例,本文旨在为读者提供一套系统的方法论,以利用云原生技术实现更高效、灵活且可靠的IT基础设施。
24 2
|
5天前
|
Kubernetes Cloud Native 持续交付
构建高效云原生应用:Kubernetes与微服务架构的融合
【5月更文挑战第6天】 在数字化转型的浪潮中,企业正迅速采纳云原生技术以实现敏捷性、可扩展性和弹性。本文深入探讨了如何利用Kubernetes这一领先的容器编排平台,结合微服务架构,构建和维护高效、可伸缩的云原生应用。通过分析现代软件设计原则和最佳实践,我们提出了一个综合指南,旨在帮助开发者和系统架构师优化云资源配置,提高部署流程的自动化水平,并确保系统的高可用性。
27 1
|
5天前
|
存储 Cloud Native 文件存储
云原生之使用Docker部署Nas-Cab个人NAS平台
【5月更文挑战第2天】云原生之使用Docker部署Nas-Cab个人NAS平台
90 1
|
6天前
|
Kubernetes Cloud Native Docker
使用 kubevpn 在本地快速开发云原生应用
KubeVPN 是一个用于云原生开发的工具,它允许用户通过本地计算机直接访问远程 Kubernetes 集群中的服务,利用 k8s DNS 或 Pod IP/Service IP。它可以拦截并调试服务网格中的工作负载流量,并提供开发模式,让容器在本地以与 k8s pod 相同的环境运行。快速开始包括下载二进制文件、自定义 Krew 安装、构建二进制文件以及安装示例应用。KubeVPN 支持链接到多个集群、DNS 解析、反向代理,以及在 Docker 中的开发模式,确保与 Kubernetes 运行环境一致。此外,它还兼容多种协议和平台。
23 5
|
6天前
|
Cloud Native 测试技术 Linux
云原生之使用Docker部署RSS阅读器Huntly
【5月更文挑战第1天】云原生之使用Docker部署RSS阅读器Huntly
34 4

热门文章

最新文章