Kubernetes集群日志持久化实战

已于 2025-04-14 16:13:43 修改
阅读量401 收藏 10
点赞数 3
文章标签： kubernetes
于 2025-04-03 22:45:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_46634095/article/details/146974585
版权

文章目录

场景

现有场景

在整个Kubernetes集群中有多套环境多套服务如果需要查询日志较为繁琐，并且考虑到开发查询日志并不太方便，所以我们通过hostpath方式将日志文件持久化存储到服务器本地，然后通过ELK将日志收集并进行展示，这样就解决了日志查看繁琐问题。

痛点：
因为使用hostpath持久化到本地，每个pod都会将日志存储在运行节点的固定目录上，所有的pod都是同样的操作，一个node节点上好几十个pod，就会导致同一个文件被多个pod写入内容导致日志覆盖的问题，往往最后一个pod才可以真正的将日志写入到该文件中，就会导致日志丢失的问题。

解决方案

痛点分析

  • 日志覆盖的根源
    1、共享路径冲突：所有的pod日志文件路径相同（历史遗留问题，但是如果我们根据每个服务的名称去划分路径的话，如果启动多个pod副本，几个服务同时向同一个文件写入，也会有概率导致丢失）
    2、文件写入模式：pod以覆盖模式（非追加模式）打开日志文件（hostpath是直接挂载上去的）

解决思路

从上述的覆盖根源来看，我们需要将每个pod隔离出来就可以解决覆盖问题，但是怎么将每个pod都单独出来呢？

  1. 通过kubernetes的pv、pvc的方式，动态的给每个pod都生成一个存储路径
  2. 通过subPathExpr 的方式自动为每个pod创建一个独立的目录进行存储
  3. 使用daemonset方式启动filebeat收集日志
  4. 部署 ELK，接收filebeat收集的日志并进行展示

注意：subPathExpr 这种方式需要Kubernetes 1.15+版本支持
pv、pvc的这种方式需要为每个deploy都新增pvc，加大了运维维护成本，所以暂时不考虑该方案

实施指南

一、Kubernetes pod单独存储操作示例

1. 应用deploy配置

  1. deploy注入pod名称环境变量
env:
  - name: POD_NAME  # 变量名
    valueFrom:
      fieldRef:
        fieldPath: metadata.name  # 自动获取 Pod 名称
  1. 使用subPathExpr 动态生成子目录
volumeMounts:
  - mountPath: /opt/logs
    name: logs-dir
    subPathExpr: $(POD_NAME)  # env变量引用
  1. 配置houstpath卷
volumes:
  - name: logs-dir
    hostPath:
      path: /data/logs/uat
      type: DirectoryOrCreate  # 自动创建目录
  1. 完整配置示例
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ioscar-commonsystem-callcenter-server
  name: ioscar-commonsystem-callcenter-server
  namespace: uat
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ioscar-commonsystem-callcenter-server
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      annotations:
        kubectl.kubernetes.io/restartedAt: "2025-01-10T14:27:52+08:00"
      creationTimestamp: null
      labels:
        app: ioscar-commonsystem-callcenter-server
    spec:
      containers:
      - env:
        - name: pod_name
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: ns
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.podIP
        image: harbor-ioscar.cbf.com/ioscar-uat/commonsystem-callcenter-server:116
        imagePullPolicy: Always
        name: ioscar-commonsystem-callcenter-server
        ports:
        - containerPort: 9103
          protocol: TCP
        readinessProbe:
          failureThreshold: 15
          httpGet:
            path: /actuator/health
            port: 9103
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 20
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: "1"
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 200Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /opt/logs
          name: logs-dir
          subPathExpr: $(pod_name)
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - hostPath:
          path: /data/logs/uat
          type: DirectoryOrCreate
        name: logs-dir

2. 效果验证

最终实现的效果：将pod中的/opt/logs挂载到宿主机的/data/logs/uat/pod具体名称

# 1. 查看服务部署的具体node节点
kubectl get pod -n uat -o wide  |grep ioscar-commonsystem-callcenter-server 
 
# 2. 进入到node节点上
ssh node-1

# 3. 查看日志目录是否生成
ll /data/logs/uat/ioscar-commonsystem-callcenter-server-65b7f54f7b-6mmpr

至此日志覆盖的问题已经解决不回再出现日志丢失的问题，此时接入ELK进行日志收集即可

3. 可能遇到的问题

  1. 环境变量未定义

subPathExpr: $(pod_name) 引用了未声明的 pod_name，实际路径会变成空值，导致所有 Pod 共享 /data/logs/uat 根目录。
所以必须配置env环境变量，并且变量名称的大小写必须注意，env是什么subPathExpr就配置成什么

env:
  - name: POD_NAME  # 变量名
    valueFrom:
      fieldRef:
        fieldPath: metadata.name  # 自动获取 Pod 名称

二、日志收集操作示例

1. 日志收集核心组件角色

filebeat（日志收集） --> kafka（削峰） --> logstach（日志解析） --> es（存储与检索（必选）） --> kibana（展示（必选））

filebeat：go语言编写，轻量级，支持断点续传适合部署在当量生产服务器上
kafka：缓冲层，解耦生产者和消费者，削峰。可以临时存储突增的日志数据，不会使下游服务因激增导致过载
logstach：日志脱敏或者日志打标签深度解析等功能（虽然也支持日志收集和输出，但是体量太大jvm运行，不如filebeat强大）
es：数据库对日志进行存储，并支持检索
kibana：日志展示，方便了开发人员直接查询到服务的日志

2. filebeat 安装与部署

filebeat是日志收集器需要在每个节点进行部署安装配置，比较麻烦，可以使用kubernetes集群的daemonset（会默认在每个节点启动一个实例，避免重复的安装部署操作）和configmap（类似于配置文件，将配置文件持久化出来，方便修改配置）来部署

# configmap配置
apiVersion: v1
data:
  filebeat.yml: |
    logging.level: error
    filebeat.inputs:					# 日志收集字段
    - type: log
      enabled: true
      paths:
        - /data/logs/uat/*/*.log		# 日志采集（日志存放路径，支持通配符）
      scan_frequency: 10s				# 每10s扫描一次
      tail_files: true					# 从文件末尾开始读取
      json.keys_under_root: true		# 自动解析json日志
      json.overwrite_keys: true
      json.add_error_key: false
      spool_size: 1000
      idle_timeout: 10s
      close_removed: true

    output.kafka:						# 日志发送给kafka
      enabled: true
      hosts: ["192.168.1.1:9092"]		# kafka地址端口
      #topic: "cbc"
      topic: "ants-%{[app_name]}"		# 自动创建topic app_name是一个json变量是日志文件中的内容（可以自己定义topic的名字）
      partition.round_robin:
        reachable_only: true
kind: ConfigMap
metadata:
  name: filebeat
  namespace: default



# daemonset
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    name: log-filebeat
  name: log-filebeat
  namespace: default
spec:
  selector:
    matchLabels:
      name: log-filebeat
  template:
    metadata:
      labels:
        name: log-filebeat
    spec:
      containers:											# 下列就是使用的镜像
      - image: harbor-ioscar.cbf.com/cbf/filebeat:7.1.1
        imagePullPolicy: IfNotPresent
        name: log-filebeat
        resources:											# 资源的限制
          limits:
            cpu: 800m
            memory: 1G
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        - mountPath: /usr/share/filebeat/filebeat.yml		# 映射到pod中的路径
          name: filebeat									# 关联volumes的名称实现关联关系
          subPath: filebeat.yml								
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      volumes:
      - configMap:											# configmap座位挂载点
          defaultMode: 420
          items:
          - key: filebeat.yml								# configmap的键值对
            mode: 420
            path: filebeat.yml
          name: filebeat									# 引用的configmap名称
        name: filebeat

3. kafka 安装与部署

kafka是日志收集中用来解耦、削峰的组件，主要的作用就是应对日志激增的问题，保护下游组件不会因为激增的日志崩溃。

依赖环境
1、jdk（不详细赘述了）
2、zookeeper（可以使用自己环境中的zookeeper如果没有kafka的安装包中也包含一个简易的）

kafka下载地址

  • 解压安装包
# 解压安装包
tar -zxvf kafka_2.11-1.1.0.tgz	
# 进入到kafka配置文件中创建zookeeper文件夹	
mkdir zookeeper
# 创建下列文件夹用于存储日志和数据（后续在zookeeper配置文件中写入）
cd zookeeper
mkdir {logs,data}
  • 修改kafka配置文件
# 修改kafka的配置文件
vim  /kafka/config/server.properties
broker.id=1												#这个id是唯一标识（必须唯一）
listeners=PLAINTEXT://ip:9092							#是kafka真正的bind的地址
advertised.listeners=PLAINTEXT://ip:9092				#将listener信息发布到zookeeper中去
port=9092                                				#端口号
host.name=ip      										#服务器IP地址，修改为自己的服务器IP
log.dirs=/mnt/soft/kafka_data/log/kafka					#日志存放路径，上面创建的目录，需要手动创建，否则会启动报错
zookeeper.connect=localhost:2181         				#zookeeper地址和端口，单机配置部署，localhost:2181

示例：
在这里插入图片描述

  • 修改zookeeper配置文件
vim  /kafka/config/zookeeper.properties

dataDir=/kafka/zookeeper/data			# zookeeper的data目录（就是之前创建的zookeeper的data文件夹）

dataLogDir=/kafka/zookeeper/logs 		# zookeeper日志目录

clientPort=2181							# zookeeper端口号

maxClientCnxns=0

示例：
在这里插入图片描述

  • 启动kafka服务

因为kafka依赖于zookeeper服务所以我们需要先将zookeeper启动起来，在启动kafka

# 先启动zookeeper 
/kafka/bin/zookeeper-server-start.sh -daemon ../config/zookeeper.properties

# 确定zookeeper启动成功
netstat -lntp |grep 2181   

# 启动kafka
/kafka/bin/kafka-server-start.sh ../config/server.properties

# 确定kafka启动成功
netstat -lntp |grep 9092

启动之后等待接收日志数据即可。

4. logstach安装部署

logstach在日志收集过程中承担日志的转发和日志深度解析的角色（比如日志打标签，日志脱敏等）

依赖环境
1、jdk1.8

logstach下载地址

# 解压logstach压缩包（包名称自己指定）
tar -zxvf logstash.tar.gz	

# 修改logstach的配置文件
cd logstash/config
vim logstash-sample.conf
# 日志导入
input {
  kafka {
    bootstrap_servers => "192.168.1.1:9092"		# 读取kafka的地址以及端口
    topics_pattern  => "cbc-.*"					# 读取kafka的topic名称，如果多个以,分割
    group_id => "logstash"
    consumer_threads => 40
    codec => "json"
    decorate_events => true
    auto_offset_reset => "latest"
    codec => "json"
  }
}
# 日志匹配输出
output {
  elasticsearch {								# 这里表示将日志输出给es
    hosts => ["http://192.168.1.1:9200"]		# es的地址以及端口
    index => "%{[@metadata][kafka][topic]}-%{+YYYYMMdd}"
  }
}


# 修改启动参数
vi /logstash/config/jvm.options
-Xms4g		# 指定启动占用内存为4g
-Xmx4g


# 启动logstach
cd logstash/bin
./logstash -f ../config/logstash-sample.conf	


# 检查是否启动成功
netstat -lntp |grep 9600

还可以做一些日志的高级设置，因为我这里没需求，如果感兴趣可以自己查阅资料

5. elasticsearch安装部署

elasticsearch下载地址

Elasticsearch是日志收集过程中用于存储和检索日志的一个组件，其实就是一个日志数据库

依赖环境
1、jdk1.8以上
2、需要使用es自己的系统账号（自己创建一个账号）
3、配置系统最大线程数为最大，否则无法启动

安装部署

# 解压es安装包
tar -zxvf elasticsearch.tar.gz


# 修改配置文件
vim config/elasticsearch.yml	
cluster.name: ela-cbc							# 设置集群名称，所有节点的这个配置应该都是一样的
node.name: cbc-es02-al							# 设置当前节点名称
node.master: true								# 设置当前节点为主节点
node.data: true									# 设置当前节点为数据节点
path.data: /data/app/elasticsearch/data/data	# 存储数据的路径
path.logs: /data/app/elasticsearch/logs/		# 存储日志的路径
bootstrap.memory_lock: false					# 是否允许es将自己锁定在内存中，以提高性能，false不允许
network.host: 10.60.250.67						# 监听地址
network.tcp.no_delay: true						# 启用tcp无延迟模式，提高数据传输效率
network.tcp.keep_alive: true					# 保持tcp连接活跃
network.tcp.reuse_address: true					# 启动tcp地址重用
network.tcp.send_buffer_size: 128mb				# 设置tcp发送缓冲区大小
network.tcp.receive_buffer_size: 128mb			# 设置tcp接受缓冲区大小
transport.tcp.port: 9300						# 设置es传输层通信端口
transport.tcp.compress: true					# 启用传输层通信的数据压缩
http.max_content_length: 200mb					# 设置http请求的最大内容长度
http.cors.enabled: true							# 是否启用跨域资源共享，允许其他域名的应用访问es
http.cors.allow-origin: "*"						# 设置语序的跨域源，即允许访问的域名
http.port: 9200									# 设置http服务监听端口
# 集群部署es可以写地址集，当然也可以单节点部署，只写一个节点ip加端口即可
discovery.seed_hosts: ["192.168.1.1:9300", "192.168.1.2:9300", "192.168.1.3:9300"]			# 设置其他节点内部通信端口
cluster.initial_master_nodes: ["192.168.1.1:9200", "192.168.1.2:9200", "192.168.1.3:9200"]	# 初始化列表
cluster.fault_detection.leader_check.interval: 15s	# 设置集群故障检测的主节点检查间隔
discovery.cluster_formation_warning_timeout: 30s	# 超时告警时间
cluster.join.timeout: 30s						# 加入集群超时时间
cluster.publish.timeout: 90s					# 集群发布超时时间
cluster.routing.allocation.cluster_concurrent_rebalance: 32			# 设置集群并发重新平衡数量
cluster.routing.allocation.node_concurrent_recoveries: 32			# 设置节点并发恢复数量
cluster.routing.allocation.node_initial_primaries_recoveries: 32	# 设置节点初始化主分片恢复的数量


vim config/jvm.options
- Xms1g	#表示初始化内存大小
- Xmx1g	#表示最大可以使用的内存大小


# 修改操作系统最大线程数
vim /etc/security/limits.conf
* soft nofile 65536		#用户打开文件数最大为65536（软资源限制）
* hard nofile 131072		#操作系统打开文件数不超过131072（硬性资源限制）
* soft nproc 2048		#用户和进程能打开的最大进程数2048（软资源限制）
* hard nproc 4096		#操作系统能打开的最大进程数4096（硬资源限制）


vim  /etc/sysctl.conf
vm.max_map_count=262145	#这个参数设置一个进程可以创建的虚拟内存映射数量，在es中lucene使用大量的虚拟内存映射来管理索引数据，默认太小了，不满足es的允许


sysctl -p	#刷新一下线程配置



# 创建es账号
useradd elsearch
passwd elsearch


# 启动es
chown elsearch.elsearch /elasticsearch		# 属主属组全部给es账号
su elsearch									# 使用es账号启动否则会报错
./bin/elasticsearch


# 检查是否成功
 netstat -lntp |grep 9200
 netstat -lntp |grep 9300

6. kibana安装部署

kibana是日志收集过程中用于日志展示的，格式化日志方便日志查看

依赖环境
1、jdk1.8以上

kibana下载

tar -zxvf kibana.tar.gz


# 修改配置文件
cd kibana/config
vim kibana.yml
# kibana端口
server.port: 5601
server.host: "0.0.0.0"	
elasticsearch.hosts: ["http://192.168.1.1:9200"]		# 这里配置es的地址加端口
i18n.locale: "zh-CN"


# 启动kibana
kibana/bin/kibana 

# 访问
http://localhost:5601

总结

对于大多数 Kubernetes 1.15+ 环境，推荐将 subPathExpr 方案作为日志隔离的 ​标准化配置。该方案在以下场景表现尤为突出：

  • ​快速实施需求：新服务上线需立即实现日志隔离
  • ​混合部署环境：同一集群运行多团队/多项目服务
    ​- 成本敏感场景：无法承担云存储费用的测试/开发环境
    通过本方案，团队可建立起 ​分钟级 的日志隔离能力，同时为后续构建统一的日志观测平台奠定坚实基础。
刘家豪TOP1
关注
kubernetes集群搭建efk日志收集平台
jks212454的博客
07-03 2712
kubernetes集群搭建efk日志收集平台
k8s之mysql容器数据持久化日志以及观测云日志分析
qq_36229701的博客
05-05 952
因为需要这几种日志，通过configmap自定义my.cnf中错误日志，慢查询，常规日志的位置；datadir目录中的数据和二进制日志也很重要，此次不涉及。metadata:data:my.cnf: |[mysqld]log-error=/var/lib/mysql/mysqld.log #错误日志log-bin=/var/lib/mysql/mysql-bin #二进制日志general_log_file=/var/lib/mysql/server2.log #常规日志。
基于hostpath的k8s pod日志持久化
最美dee时光的博客
11-19 4838
前置条件： 考虑到pod的多副本，但同时需要将日志集中收集起来，所以采用hostpath的方式将同一个服务的多pod的日志持久化到一起，日志穿插性的写在一个文件中。 由于pod重启会打散分配到不同节点上，所以基于nfs的网络文件系统通过共享目录的方式挂载到客户端节点（nfs-server:/mnt/hostpath; nfs-client: /mnt/hostpath,将nfs-server的/mnt/hostpath挂载到nfs-client的/mnt/hostpath下，从而达到同服务多pod可以写到
（八）K8S数据持久化存储
csdn570566705的博客
05-27 1743
EmptyDir是Kubernetes中一种简单的数据卷类型，它提供了一个临时的空目录，可以用于在Pod内部共享文件。EmptyDir卷在Pod被调度到节点上时创建，并且只在Pod的生命周期内存在，当Pod被删除或重新调度时，其中的数据也会被清除。hostPath是Kubernetes中一种常见的卷类型，它允许将主机上的文件或目录直接挂载到Pod中的容器中。这样，容器可以直接访问主机上的文件系统，并与主机共享数据。都是本地存储卷方式emptyDir是临时存储空间，完全不提供持久化支持；
十一、K8S之持久化存储
qq_39381892的博客
11-06 552
持久化存储通常用于程序的状态数据、数据库文件、日志文件等需要在容器生命周期之外的数据，它可以通过各种存储解决方案实现，如主机路径、本地存储、网络存储（如NFS、ISCSI）、云存储等。 PV是集群中的一块存储，它可以是物理存储设备、网络存储卷或云提供商的存储服务。PV独立于Pod的生命周期，可以被多个Pod共享 PVC是Pod对持久化存储的请求。 它相当于是Pod对PV的申请单。Pod可以通过声明PVC来请求所需的存储资源，并指定访问模式、容量和存储类等要求。Kubernetes会根据PVC的要求去匹配可用
Kubernetes部署_04_k8s持久化存储（亲测可用）
毛毛的专栏
05-29 3125
新建具有两个节点的k8s集群，主节点(master节点/m节点)的ip地址是192.168.100.150，从节点(w1节点)的ip地址是192.168.100.151。本文操作如何将pod中的container容器中的目录映射到宿主机(包括pod所在宿主机和其他任意宿主机)，分为三个部分：volumes的使用、pv/pvc的使用、storageClass的使用。三者的关系是：volumes映射Pod只能映射到自己所在node(实际机器)的目录上；
Kubernetes集群存储管理实战：持久化存储卷的类型与使用
[Kubernetes集群存储管理实战：持久化存储卷的类型与使用](https://img-blog.csdnimg.cn/direct/80941fa8d85d475f9e5e247d913afc06.png) # 1. Kubernetes存储基础** Kubernetes存储管理是管理Kubernetes集群中持久...
基于CCE Kubernetes网络与持久化存储实战
热门推荐
退役复学在校大学生，目光所至，皆为华夏
11-30 3万+
在登录弹性云服务器ecs-k8s的Xfce终端上，通过上步骤下载kubectl中，记录的 kubectl链接地址：https://dl.k8s.io/v1.23.14/kubernetes-client-linux-amd64.tar.gz 来下载kubectl，并将kubectl和kubeconfig.json配置文件拷贝到/home目录下。云服务器的弹性公网IP地址可以通过鼠标移动到云桌面浏览器页面中左侧菜单栏，点击“服务列表”->“计算”->“弹性云服务器ECS”进入服务器列表，进查看并复制。
Docker容器化实战：从CI/CD到Kubernetes集群部署
最新发布
shejizuopin的博客
04-11 455
通过本文的实战示例，我们展示了从Docker容器化到Kubernetes集群部署的全流程，涵盖了CI/CD、Docker Compose、Kubernetes基础与高级特性、性能优化与故障排查等方面。希望本文的代码和表格示例能为开发者提供实用的参考，助力应对容器化和集群部署中的挑战。Docker和Kubernetes的结合为现代应用提供了强大的部署和管理能力，是构建云原生应用的关键技术。
【Kubernetes】日志平台EFK+Logstash+Kafka实战
09-26
整个EFK+Logstash+Kafka日志平台在Kubernetes中的部署，不仅仅是一个简单的日志收集和分析过程，它还涉及到集群管理、资源调度、数据持久化、网络配置等多方面的知识。通过本教程的学习，用户将能够深入理解...
Docker学习第十一天——k8s之持久化存储
qq_39637333的博客
05-15 939
1、做持久化存储的原因在k8s中部署的应用都是以pod容器的形式运行的，假如我们部署MySQL、Redis等数据库，需要对这些数据库产生的数据做备份。因为Pod是有生命周期的，如果pod不挂载数据卷，那pod被删除或重启后这些数据会随之消失，如果想要长久的保留这些数据就要用到pod数据持久化存储。2、常用持久化存储类型• emptyDir• hostPath• nfs• cephfs• secret3、持久化存储步骤1）定义pod的volume，这个volume指明它要关联到哪个存储上的。
mysql 集群日志_MySQL集群配置
weixin_33070823的博客
02-18 309
一.下面假设这3台服务的情况：Server1: 172.18.3.205Server2: 172.18.3.207Server3: 172.18.3.208Servers1和Server2作为实际配置MySQL集群的服务器。对于作为管理节点的Server3则要求较低，只需对Server3的系统进行很小的调整并且无需安装MySQL，Server3可以使用一台配置较低的计算机并且可以在Server3同...
k8s集群日志
weixin_30727835的博客
08-30 438
硬件环境： 三台虚拟机， 10.10.20.203 部署docker、etcd、flannel、kube-apiserver、kube-controller-manager、kube-scheduler、elsticsearch、kibana 10.10.20.206部署docker、flannel、kubelet、kube-proxy、filebeat 10.10.20.20...
（九）K8S数据持久化高级存储
csdn570566705的博客
05-29 1792
PV（Persistent Volume）和 PVC（Persistent Volume Claim）是 Kubernetes 中用于管理持久化存储的两个核心概念。PV 是集群中的持久化存储资源，而 PVC 则是 Pod 对 PV 的请求。PV 是集群中的持久化存储资源，它可以由集群管理员预先配置和管理。PV 独立于 Pod 存在，可以被多个 Pod 共享使用。PV 可以连接到各种后端存储系统，如本地磁盘、网络存储、云存储等。PV 有自己的生命周期，可以手动创建、删除和管理。
k8s 持久化存储
m0_73950916的博客
09-22 947
retain模式的话，删除pvc后，pv仍然存在，处于释放的状态，但是不能被其他的pvc绑定使用了，里面的数据还是存在的，下次使用的话，数据还是存在的，默认的回收策略。创建Pod时，使用pvc作为存储卷的话，会与pv绑定，当删除pod时，pvc和pv就会解绑，这个时候的pv里面的数据可以保留或者删除。上面静态模式的话，需要事先创建pv，然后一一对应，如果有成千上万的话，就需要很多的pv，维护的成本很高。创建pvc，指定存储类，就能从供应商下面的共享文件里面创建对应的pv，自动的创建出来。
Kubernetes 集群日志管理
隔壁老瓦的专栏
06-21 654
Kubernetes 开发了一个 Elasticsearch 附加组件来实现集群的日志管理。这是一个 Elasticsearch、Fluentd 和 Kibana 的组合。Elasticsearch 是一个搜索引擎，负责存储日志并提供查询接口；Fluentd 负责从 Kubernetes 搜集日志并发送给 Elasticsearch；Kibana 提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的日志。Elasticsearch 附加组件本身会作为 Kubernetes
Kubernetes集群日志详解
Free雅轩的博客
01-19 1211
服务器和应用程序日志记录是开发人员、运维人员和安全团队了解应用程序在其生产环境中运行状态的重要工具。日志记录使运维人员能够确定应用程序和所需组件是否运行平稳，并检测是否发生了异常情况，以便他们能够对这种情况做出反应。 对于开发人员，日志记录提供了在开发期间和之后对代码进行故障排除的可见性。在生产环境中，开发人员通常依赖于没有调试工具的日志记录工具。在加上系统的日志记录，开发人员可以与运维人员携手合作，有效地解决问题。 日志记录工具最重要的受益者是安全团队，尤其是在云原生的环境中。能够从应用程序和系
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值