云原生之容器编排实践-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!

目录
相关文章
|
19天前
|
Java 应用服务中间件 API
【潜意识Java】javaee中的SpringBoot在Java 开发中的应用与详细分析
本文介绍了 Spring Boot 的核心概念和使用场景,并通过一个实战项目演示了如何构建一个简单的 RESTful API。
36 5
|
2月前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
2月前
|
存储 人工智能 调度
容器服务:智算时代云原生操作系统及月之暗面Kimi、深势科技实践分享
容器技术已经发展成为云计算操作系统的关键组成部分,向下高效调度多样化异构算力,向上提供统一编程接口,支持多样化工作负载。阿里云容器服务在2024年巴黎奥运会中提供了稳定高效的云上支持,实现了子弹时间特效等创新应用。此外,容器技术还带来了弹性、普惠的计算能力升级,如每分钟创建1万Pod和秒级CPU资源热变配,以及针对大数据与AI应用的弹性临时盘和跨可用区云盘等高性能存储解决方案。智能运维方面,推出了即时弹性节点池、智能应用弹性策略和可信赖集群托管运维等功能,进一步简化了集群管理和优化了资源利用率。
|
2月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
2月前
|
人工智能 Cloud Native 调度
阿里云容器服务在AI智算场景的创新与实践
本文源自张凯在2024云栖大会的演讲,介绍了阿里云容器服务在AI智算领域的创新与实践。从2018年推出首个开源GPU容器共享调度方案至今,阿里云容器服务不断推进云原生AI的发展,包括增强GPU可观测性、实现多集群跨地域统一调度、优化大模型推理引擎部署、提供灵活的弹性伸缩策略等,旨在为客户提供高效、低成本的云原生AI解决方案。
|
3月前
|
JSON 安全 算法
Spring Boot 应用如何实现 JWT 认证?
Spring Boot 应用如何实现 JWT 认证?
100 8
|
3月前
|
安全 持续交付 Docker
深入理解并实践容器化技术——Docker 深度解析
深入理解并实践容器化技术——Docker 深度解析
105 2
|
3月前
|
消息中间件 Java Kafka
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
80 1
|
3月前
|
Prometheus 监控 持续交付
深入理解Docker容器化技术:从基础到实践
深入理解Docker容器化技术:从基础到实践
|
3月前
|
持续交付 开发者 Docker
深入理解并实践容器化技术——Docker篇
深入理解并实践容器化技术——Docker篇
64 0