在微服务架构中，应用实例的频繁部署、扩缩容、重启都是常态。
如果不进行优雅上下线（Graceful Startup & Shutdown），就可能导致：
为了解决这些问题，我们需要让服务在启动和关闭阶段都更有序、更“温柔”、更可控。
从 Spring Boot 2.3+ 开始，官方就支持优雅关闭（Graceful Shutdown）：
server:
shutdown: graceful或通过启动参数启用：
-Dserver.shutdown=graceful这表示当 Spring Boot 接收到关闭信号（如 SIGTERM）时，不会立刻中断请求，而是：
我们有一个 docker compose 部署的 harbor，随着时间的推移，存储的镜像越来越多，磁盘空间已经捉襟见肘。急需迁移到更大的存储空间去。harbor 支持众多的后端存储，所支持的后端存储类型和配置方法点击 Configuring a registry | CNCF Distribution 和 Harbor docs | Configure the Harbor YML File 查看。
我这里使用的是minio（兼容s3）作为后端存储。
假设我的 harbor 的访问地址是：https://hub.kops.cc
修改 harbor.yml 文件：
storage_service:
s3:
accesskey: minioadmin
secretkey: minioadmin
regionendpoint: http://127.0.0.1:9000
bucket: harbor
multipartcopythresholdsize: "5368709120"执行 ./prepare 脚本使配置生效
./prepare
docker-compose down
docker-compose up -d在网络通信中，端口是用于区分不同服务的重要资源。通常，每个服务会绑定到一个特定端口上，但有时我们需要通过同一个端口来代理不同的服务。这种技术被称为端口复用。本文将介绍端口复用的场景、用途、协议特性，并分别使用 Nginx 和 HAProxy 进行端口复用配置。
端口复用在以下场景中非常有用：
端口复用的实现依赖于协议特性。通过分析协议的特定字段或数据包的前几个字节，可以判断请求的类型并将其转发到相应的后端服务。
可重现构建(reproducible builds)是一组软件开发实践，如果给定相同的源代码、构建环境和构建指令，任何一方都可以bit-by-bit重新构建出相同副本，则构建是可重现的。本文将探讨可重现构建的重要性，以及在maven项目中如何实现这一目标。
不知道你有没有发现，你的java工程在没有修改代码的情况下，两次构建出来的jar/war包md5值是不一样的。为什么会出现这种情况呢？jar包其实是一个zip压缩包，当你解包两次构建查看其中的差异时，你会发现最明显的区别就是文件夹的时间不一样了：
除了时间不一样以外，还有元数据等等，具体要解决的问题，在apache官网有个提案，记录了可重现构建需要解决的问题。
KT-Connect 是一个用于 Kubernetes 环境下的网络代理工具，旨在简化开发和测试过程中对 Kubernetes 集群内服务的访问。它通过创建一个或多个代理，使得本地开发环境可以直接与 Kubernetes 集群内的服务进行通信，而无需复杂的端口映射或修改服务配置。这种方式有助于开发者在本地开发、调试容器化应用时，如同直接操作本地服务一样便捷。
KT-Connect 的主要功能和特点包括：
使用 KT-Connect 可以显著提升 Kubernetes 应用的开发效率，尤其是对于需要频繁调试、集成测试的场景，它提供了一个灵活且高效的本地开发解决方案。
要想运行KT-Connect，需要确保两个镜像能在你的Kubernetes集群中正常拉取：
如果你的网络受限，不能拉取以上镜像，需要你提前将镜像导入到每个Kubernetes节点。