记录几个日常工作中经常会碰到的问题，相关的原理及案例说明
k8s是如何对存储进行管理的
k8s支持各种类型的存储，基本上兼容x86服务器上支持的类型，像：nfs，nas，本地存储，云商存储等
k8s同时支持静态和动态存储类型，按照最佳实践，目前企业中使用的最多的还是动态存储类型，动态存储类型k8s会自动对存储进行管理维护，大大减轻了运维人员的负担。
动态存储解决了如下问题：
Kubernetes（k8s）动态存储管理主要解决了在容器化应用部署中，对持久化存储资源的自动创建、绑定、回收以及扩展等操作的问题。传统的手动方式需要预先创建并配置存储卷（PersistentVolume, PV），然后将其与Pod中的持久化卷声明（PersistentVolumeClaim, PVC）进行关联，这种方式存在一定的局限性：
手动创建和分配PV：管理员需要预估并提前准备足够的存储资源，如果需求发生变化，或者有新的应用需要存储资源时，就需要手动创建或调整PV。
资源利用率低：静态配置的存储资源可能导致资源浪费或不足，尤其是在多个应用共享集群存储资源的情况下。
扩容难：当存储空间不足时，需要手动扩展PV的容量，这一过程繁琐且不利于快速响应业务需求变化。
下面是一个使用动态存储的最佳实践案例：
-
确保集群支持动态存储：
-
首先确认你的Kubernetes集群已经安装了对应的存储插件或驱动程序，例如对于AWS EBS、GCE Persistent Disk或其他云服务商提供的块存储服务，集群应该已经集成了相关的CSI（Container Storage Interface）插件。
-
创建StorageClass：
-
根据你的存储后端系统，创建一个或多个StorageClass对象。这个对象定义了如何动态地为PVC提供存储卷。比如，如果你使用的是AWS EBS，可以创建如下所示的StorageClass：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: aws-ebs-fast
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Delete
-
创建PersistentVolumeClaim (PVC)：
-
创建一个PVC时，指定所需的存储大小和所使用的StorageClass。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-dynamic-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: aws-ebs-fast # 使用之前创建的StorageClass名称
resources:
requests:
storage: 5Gi
-
应用Pod引用PVC：
-
在应用Pod或者Deployment的YAML文件中挂载这个PVC到容器内。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-app-image
volumeMounts:
- mountPath: /data
name: my-storage-volume
volumes:
- name: my-storage-volume
persistentVolumeClaim:
claimName: my-dynamic-pvc
-
部署应用程序：
-
将上述YAML文件应用到Kubernetes集群中。当Kubernetes接收到这个PVC资源时，它会根据你指定的StorageClass自动创建一个新的PersistentVolume，并将其绑定给PVC。
pod访问service是如何做到自动发现的
我有个场景tomcat pod 需要连接MySQL pod 我想让它能够自动识别并连接 不需要运维人员再关心
在Kubernetes集群中，当一个Pod需要连接到同一个集群内的MySQL Service时，最佳实践是利用Kubernetes的内部服务发现机制，而不是直接获取Service的ClusterIP。这样可以确保应用程序能够自动识别并连接目标MySQL服务，而不需要运维人员手动干预。
在Tomcat Pod的环境变量配置中，可以设置数据源（DataSource）连接字符串使用服务名而非具体的IP地址。例如，在Spring Boot或类似的Java应用中，你可以配置如下：
apiVersion: v1
kind: Deployment
metadata:
name: tomcat-app
spec:
replicas: 1
selector:
matchLabels:
app: tomcat
template:
metadata:
labels:
app: tomcat
spec:
containers:
- name: tomcat-container
image: your-tomcat-image
env:
- name: MYSQL_SERVICE_HOST
value: mysql-service.default.svc.cluster.local # 替换为你的MySQL服务名称和命名空间
- name: MYSQL_SERVICE_PORT
value: "3306" # 或者通过service.spec.ports[].targetPort获取
# ...
然后，在Tomcat应用的配置文件或者代码中引用这些环境变量来构建数据库连接URL：
properties
spring.datasource.url=jdbc:mysql://${MYSQL_SERVICE_HOST}:${MYSQL_SERVICE_PORT}/database_name?useSSL=false&serverTimezone=UTC
# 其他相关数据库连接属性...
这样，无论MySQL Service背后的ClusterIP如何变化，由于Kubernetes DNS系统会自动解析mysql-service.default.svc.cluster.local这个服务名到正确的IP地址，所以Tomcat应用总是能成功连接到MySQL服务。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/225680.html
