容器化
前言 在人工智能快速发展的今天，如何快速构建和部署 AI 应用已成为企业数字化转型的核心挑战。Dify 作为一款开源的 LLMs（大型语言模型）应用开发平台，凭借其直观的设计和强大的功能，已帮助数万家企业实现了 AI 能力的快速落地。本文将深入解析基于 Docker 的 Dify 私有化部署方案，带你一步步构建属于自己的企业级 AI 应用开发平台。 一、项目概览 1.1 什么是 Dify？ Dify 是一个开源的 LLMs 应用开发平台，支持超过数百种主流 AI 模型的接入，包括 GPT、Claude、Gemini、通义千问、文心一言等。其核心功能包括： * 可视化 AI 工作流编排：通过拖拽式界面，轻松构建复杂的 AI 工作流程 * RAG
容器化
基于官方 postgres 镜像的生产级部署与备份实践 前言 PostgreSQL 作为最强大的开源关系型数据库之一，在企业级应用中扮演着重要角色。将 PostgreSQL 部署在 Kubernetes 环境中，不仅能享受容器化带来的便利，还能利用 Kubernetes 的弹性伸缩和自愈能力。 今天，我将分享一套完整的 PostgreSQL K8s 部署方案，包括 StatefulSet 部署、用户权限管理、以及自动备份策略。 为什么选择 Kubernetes 部署 PostgreSQL？ 优势 说明 高可用 Kubernetes 自动重启故障 Pod，保证服务持续运行 弹性伸缩 根据负载动态调整资源配额 版本管理 通过镜像版本轻松实现数据库升级 资源隔离 独立的 Namespace 和资源配额 存储管理 HostPath 或持久卷灵活配置 整体架构一览 先来看一张部署架构图：
容器化
基于 bitnami/etcd 镜像的生产级部署实践 前言 在 Kubernetes 生态系统中，Etcd 作为核心的分布式键值存储，承担着至关重要的角色。它不仅是 Kubernetes API Server 的数据后端，还广泛用于服务发现、配置共享等场景。 今天，我将分享一套基于 Kubernetes 的 Etcd 部署方案，这套方案已经在生产环境中稳定运行，服务于 APISIX 网关等关键系统。 为什么选择这个方案？ 在深入技术细节之前，先说说为什么选择这个部署方案： 特性 说明 bitnami 镜像 业界最可靠的 etcd 容器镜像，维护活跃，安全更新及时 StatefulSet 原生支持有状态应用，保证 Pod 启动顺序和数据持久性 双 Service 模式 Headless + NodePort，
容器化
Kubernetes 高可用 MariaDB Galera 集群部署指南 一、架构概述 本文档详细介绍如何在 Kubernetes 集群中部署 MariaDB Galera 高可用集群。该集群采用一主两从的架构设计，包含以下三个节点： 节点角色 Pod 名称 NodePort 端口 说明 Master mariadb-master 30306 主节点，处理写入操作 Slave mariadb-slave 30307 从节点，处理只读操作 Backup mariadb-backup 30308 备份节点，兼作异步备份 集群架构图 端口说明 端口 用途 3306 MySQL/MariaDB 标准连接端口 4567 Galera 集群内部通信端口 4568 IST (Incremental
容器化
前言 对象存储是现代数据架构中不可或缺的组成部分。MinIO 作为一个高性能、兼容 S3 协议的对象存储系统，在 Kubernetes 环境中有着广泛的部署实践。本文将分享在 K8s 集群中部署 MinIO 的几种不同方式，以及在实际操作中积累的一些经验。 架构概览 方案一：传统 DaemonSet 部署 核心配置 这种方式采用 DaemonSet 控制器，在指定标签的节点上各运行一个 MinIO 实例，组成分布式集群。 apiVersion: apps/v1 kind: DaemonSet metadata: name: minio namespace: rtghj-minio spec: selector: matchLabels: app: minio template: spec: # 节点选择：仅部署到标记为 minio-server=true
容器化
本文介绍如何在 Kubernetes 集群中部署 MongoDB 4.4.13 分片副本集（Replica Set），使用 DaemonSet 确保每个指定节点运行一个 MongoDB 实例，通过 hostNetwork 直接暴露端口，并配置定时备份策略。 一、架构概述 该集群采用三节点副本集架构： 节点 角色 端口 说明 mongoserver1 PRIMARY :30017 主节点，处理写入 mongoserver2 SECONDARY :30017 从节点，同步复制 mongoserver3 SECONDARY :30017 从节点，同步复制 关键设计决策： * DaemonSet 而非 StatefulSet — 每个节点精确运行一个 Pod，与节点绑定 * hostNetwork: true
容器化
什么是 Xinference Xinference 是一个开源的大模型推理框架，支持本地部署各类开源大模型，包括 LLM、Embedding、Rerank 等模型类型。它提供类似 OpenAI API 的接口，方便与现有应用集成。 本文介绍如何通过 Docker Compose 在本地部署 Xinference v1.14.0，并配置开机自动加载常用模型。 Docker Compose 配置 首先创建目录结构： mkdir -p xinference/data/xinference xinference/data/huggingface xinference/data/modelscope 编写 docker-compose.yaml： services: inference: volumes: - ./data/xinference:/root/.xinference
容器化
本文介绍如何在 Kubernetes 集群中部署 Elasticsearch 6.8.23 三节点集群与 Kibana 6.8.23 可视化面板。Elasticsearch 采用 DaemonSet 部署确保每个指定节点运行一个实例，Kibana 采用 Deployment 部署并通过 NodePort 对外暴露访问。 一、架构概述 组件 部署方式 节点数 端口 说明 Elasticsearch DaemonSet 3 :9200 / :9300 数据存储与检索引擎 Kibana Deployment 1 :5601 可视化面板 Service NodePort 1 :30056 → :5601 Kibana 外部访问入口 关键设计决策： * DaemonSet
容器化
Kafka 3.6 引入了 KRaft 模式，不再依赖 ZooKeeper，让集群架构更简洁。本文记录在 K8s 上用 bitnami/kafka:3.6.2 部署两套 KRaft 集群的过程——一套用于内部服务通信，另一套带 SASL 认证对外暴露给 ETL 管线消费。 一、两套集群的设计思路 为什么要部署两套？内部集群走 PLAINTEXT 直连，简单高效；ETL 集群面向外部系统，必须走 SASL_PLAINTEXT 认证，保障数据边界安全。两者共用 rtghj-kafka 命名空间，但 KAFKA_KRAFT_CLUSTER_ID 不同，互不干扰。
容器化
本文介绍如何在 Debian 11 (Bullseye) 上从零部署 Kubernetes v1.25.4 集群，涵盖镜像源配置、系统调优、容器运行时安装、K8s 组件部署、集群初始化与网络插件配置，以及 NFS 存储、资源回收策略和 TLS 证书更新等运维操作。 一、设置镜像源 Debian 默认可能使用 CD-ROM 源，国内环境下建议替换为阿里云镜像源，加速软件包下载。 首先注释掉 CD-ROM 源： sed -ri 's/^deb\scdrom:\[Debian.*/#&/' /etc/apt/sources.list 添加阿里云镜像源： cat <<
容器化
本文基于 Flink 1.15.2 + Kubernetes 的生产环境部署实践。 一、架构概览 Flink 在 Kubernetes 上采用经典的 JobManager + TaskManager 主从架构，JobManager 负责作业调度与协调，TaskManager 承载实际的计算任务。 资源分配一览 组件 作用 副本数 Task Slots 内存配置 JobManager 作业调度、Checkpoint 管理、协调 1 — 8G TaskManager 执行计算任务 3 80/Pod 48G 总计 — 4 240 — 二、Namespace 隔离 为 Flink 创建独立 Namespace，
容器化
本文基于 APISIX 3.9.1 + Dashboard 3.0.1 + etcd 3.5.15 + Prometheus + Grafana 的生产级 Docker Compose 部署实践。 一、整体架构 本次部署采用 Docker Compose 编排五大组件，形成从配置管理到流量监控的完整闭环： 组件 版本 作用 端口 APISIX 3.9.1-debian API 网关核心，路由转发、插件执行 9080/9443 Dashboard 3.0.1-alpine 可视化配置管理界面 9000 etcd 3.5.15