1. MongoDB简介 1.1. 什么是MongoDB？ MongoDB是一个基于分布式文件存储的NoSQL数据库，由C++编写，旨在为WEB应用提供可扩展的高性能数据存储解决方案。
MongoDB的特点：
面向文档存储（Document-Oriented） 模式自由（Schema-Free） 支持动态查询 支持完全索引 支持复制和故障恢复 使用高效的二进制数据存储，包括大型对象（如视频等） 自动处理负载均衡 支持Python、PHP、Ruby、Java、C、C#、Javascript、Perl及C++语言的驱动程序 1.2. MongoDB vs 关系型数据库 特性 MongoDB 关系型数据库 数据模型 文档模型 关系模型 表结构 灵活的Schema 固定的Schema 查询语言 MongoDB查询语法 SQL 事务支持 支持ACID事务 强ACID事务 扩展方式 水平扩展 主要垂直扩展 存储格式 BSON 行列存储 2. 核心概念 2.1. 基本术语对比 关系型数据库 MongoDB 数据库 数据库(Database) 表(Table) 集合(Collection) 行(Row) 文档(Document) 列(Column) 字段(Field) 索引 索引 表连接 嵌入文档或引用 主键 主键（MongoDB提供了默认的_id字段） 2.2. BSON数据类型 MongoDB使用BSON（Binary JSON）格式存储数据，支持以下数据类型：
// 基本数据类型示例 { "name": "张三", // String "age": 25, // Number (Int32) "salary": 8500.1. 第一部分：基础概念 1.1. Q1: 什么是InnoDB Buffer Pool？它的作用是什么？ 回答： Buffer Pool是InnoDB存储引擎在内存中维护的一个缓存区域，主要作用包括：
数据缓存：缓存从磁盘读取的数据页和索引页 减少磁盘I/O：热数据保持在内存中，避免频繁磁盘访问 提升性能：内存访问速度比磁盘快几个数量级 缓冲写操作：通过脏页机制，批量写入磁盘 面试官点评：✅ 回答全面，涵盖了主要功能点
1.2. Q2: Buffer Pool的内部结构是怎样的？ 回答： Buffer Pool采用链表和哈希表的混合结构：
Buffer Pool 结构： ┌─────────────────┐ │ Hash Table │ ← 快速定位页面 ├─────────────────┤ │ LRU List │ ← 页面置换算法 │ ┌─ Young ────┐ │ │ │ (新/热数据) │ │ │ └─────────────┘ │ │ ┌─ Old ─────┐ │ │ │ (旧数据) │ │ │ └─────────────┘ │ ├─────────────────┤ │ Flush List │ ← 脏页管理 ├─────────────────┤ │ Free List │ ← 空闲页面 └─────────────────┘ 关键组件：1. 前言 InnoDB Buffer Pool 是 MySQL 性能优化中最关键的参数之一。设置得当，可以大幅提升数据库性能；设置不当，反而会拖累系统。本文将深入解析如何科学地设置 innodb_buffer_pool_size。
2. 什么是 Buffer Pool？ Buffer Pool 是 InnoDB 存储引擎在内存中维护的一个缓存区域，用于缓存：
数据页面：表中的行数据 索引页面：B+树索引结构 插入缓冲：辅助索引的插入操作 锁信息：行锁和表锁信息 3. 核心设置原则 3.1. 基础计算公式 # 通用公式 Buffer Pool Size = (Working Set Size × 1.2~1.5) + Growth Buffer # 详细计算 Working Set Size = 热数据大小 + 热索引大小 Growth Buffer = 预期1-2年的数据增长量 3.2. 系统内存分配规则 # 专用数据库服务器 Buffer Pool = 总内存 × 70%~80% # 混合应用服务器 Buffer Pool = 总内存 × 50%~60% # 容器化环境 Buffer Pool = 容器内存 × 60%~70% 4.1. 你遇到过这样的坑吗？ 某天你打开监控，看见：
Pod：mysql-prod-xxxx 内存使用率：96.25% 容器资源限制：8Gi innodb_buffer_pool_size：6Gi 你心想：6G + 一点点堆栈，不就够了？怎么可能用掉 96%？ 再一看：
SHOW PROCESSLIST; -- 200+ 个连接，全部 Sleep 状态，持续几千秒未释放 ✅ Bingo：连接相关的内存拖垮了你的数据库。
2. MySQL 总内存使用结构图 MySQL 启动后，内存分为两大部分：
MySQL 总内存 ≈ 全局共享内存（Global memory） + 每连接私有内存（Per-connection memory） 2.1. ️全局共享内存（常驻不变） 参数 功能 说明 innodb_buffer_pool_size 缓存数据页、索引页 5.7 和 8.0 核心参数 innodb_log_buffer_size redo log 写入缓冲 较小，一般 16~64MB key_buffer_size MyISAM 缓冲 只用于 MyISAM，InnoDB 忽略 query_cache_size 查询缓存 8.0 已移除，5.7 建议禁用 table_open_cache 打开表的缓存 每张表 8K~16K 内存不等 2.2. ️每连接私有内存（连接越多越恐怖） 每个连接都会分配一块独立的内存空间，用于执行语句的临时运算。1. 核心参数详解 1.1. sync_binlog 参数 1.1.1. 参数含义 sync_binlog 控制MySQL何时将二进制日志从OS缓存同步到磁盘。
1.1.2. 可选值与含义 sync_binlog = 0：完全依赖操作系统，MySQL不主动同步 sync_binlog = 1：每次事务提交后立即同步到磁盘 sync_binlog = N (N>1)：每N次事务提交后同步一次 1.1.3. 工作机制 事务提交 → 写入binlog buffer → 写入OS cache → sync_binlog控制 → 刷写到磁盘 1.1.4. 配置建议 # 生产环境推荐配置 sync_binlog = 1 # 最高安全级别 # 高并发场景可考虑 sync_binlog = 10 # 平衡性能与安全 # 开发测试环境 sync_binlog = 0 # 最佳性能 1.2. innodb_flush_log_at_trx_commit 参数 1.2.1. 参数含义 控制InnoDB事务日志（redo log）的刷盘策略。
1.2.2. 可选值详解 0：每秒刷写一次，事务提交时不立即刷盘 1：每次事务提交都立即刷写到磁盘（最安全） 2：每次事务提交写入OS缓存，每秒刷写到磁盘 1.2.3. 工作流程对比 值为0: 事务提交 → redo log buffer → (每秒) → OS cache → 磁盘 值为1: 事务提交 → redo log buffer → OS cache → 立即刷盘 值为2: 事务提交 → redo log buffer → OS cache → (每秒) → 磁盘 1.前言 在 Kubernetes 集群中，默认情况下所有 Pod 之间都可以自由通信。但在生产环境中，我们往往需要对网络流量进行精细化控制，这时就需要用到 NetworkPolicy。本文将从基础概念到实际应用，全面介绍 NetworkPolicy 的使用方法。
什么是 NetworkPolicy？ NetworkPolicy 是 Kubernetes 的一种资源对象，用于定义 Pod 之间的网络访问规则。它类似于传统网络中的防火墙规则，可以控制：
入站流量（Ingress）：哪些来源可以访问目标 Pod 出站流量（Egress）：目标 Pod 可以访问哪些目的地 前置条件 在开始之前，确保您的集群满足以下条件：
1. CNI 插件支持 NetworkPolicy 需要 CNI 插件的支持，常见支持的插件包括：
Calico（推荐） Cilium Weave Net Antrea ⚠️ 注意：Flannel 默认不支持 NetworkPolicy
2. 验证支持情况 # 检查当前 CNI 插件 kubectl get pods -n kube-system | grep -E "(calico|cilium|weave|antrea)" # 创建测试策略验证支持 kubectl apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-policy namespace: default spec: podSelector: {} policyTypes: [] EOF # 如果支持，会输出 "networkpolicy/test-policy created" kubectl get networkpolicies -n default NetworkPolicy 基础语法 完整结构示例 apiVersion: networking.1. 介绍 2. 安装 3. 初始化项目 4. 基础用法示例 5. 添加子命令 6. 使用Flags 7. 参数验证 8. 完整示例 9. 使用示例 10. 总结 1. 介绍 Cobra 是一个用于创建强大的现代 CLI 应用程序的库。如果你使用 Go，并且正在寻找一个简单而强大的库来创建 CLI 应用程序，那么你可能会对 Cobra 感兴趣。
2. 安装 go mod init your-project-name go get -u github.com/spf13/cobra@latest 3. 初始化项目 使用 Cobra CLI 工具快速创建项目结构
# 安装 cobra-cli go install github.com/spf13/cobra-cli@latest # 初始化项目 cobra-cli init 4. 基础用法示例 创建一个简单的CLI应用：
package main import ( "fmt" "github.com/spf13/cobra" "os" ) var rootCmd = &cobra.1. 为什么使用 helm 安装 https://github.com/kubernetes/dashboard/?tab=readme-ov-file#introduction 从版本 7.0.0 开始，我们不再支持基于 Manifest 的安装。现在仅支持基于 Helm 的安装。 由于多容器设置和对 Kong 网关 API 代理的硬依赖，因此无法轻松支持基于 Manifest 的安装。
2. Helm 安装 本次以 k8s 1.27 版本为例 找到适配的版本，即 Helm Chart 7.5.0, See: https://github.com/kubernetes/dashboard/releases?page=5
# 添加 helm 仓库 helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/ # 更新仓库 helm repo update # 查找 kubernetes-dashboard helm search repo kubernetes-dashboard/kubernetes-dashboard -l # 列出所有版本 helm search repo kubernetes-dashboard/kubernetes-dashboard --version 7.5.0 # 查看指定版本 # 安装(不含 metrics-server、使用事先安装好的 metrics-server) helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard \ --version 7.查找字符 :s/old/new/g 替换当前行所有 old 为 new :s/old/new/gc 替换当前行所有 old 为 new，并提示确认 :%s/old/new/g 替换所有行所有 old 为 new :%s/old/new/gc 替换所有行所有 old 为 new，并提示确认 :set ic 忽略大小写 :set noic 不忽略大小写 :set nu 显示行号 :set nonu 不显示行号 :set hlsearch 高亮搜索结果 :set nohlsearch 不高亮搜索结果 :set incsearch 实时搜索 :set noincsearch 不实时搜索 :set wrap 自动换行 :set nowrap 不自动换行 :set showmatch 显示括号匹配 :set noshowmatch 不显示括号匹配 :set ruler 显示光标位置 :set noruler 不显示光标位置 :set cursorline 高亮当前行 :set nocursorline 不高亮当前行 :set cursorcolumn 高亮当前列 :set nocursorcolumn 不高亮当前列 :set foldenable 启用折叠 :set nofoldenable 禁用折叠 :set foldmethod 设置折叠方式 :set foldlevel 设置折叠级别 :set foldlevelstart 设置折叠起始级别 :set foldlevelstop 设置折叠结束级别 查找文件 :find file 查找文件 :find /path/to/file 查找文件1. 介绍 在 Kubernetes 环境中进行 故障分析与调试 是一项重要的技能，因为 Kubernetes 涉及众多的组件和服务，且其工作负载通常是分布式的。在面对问题时，分析和调试的技巧将帮助你更快速地定位问题并找到解决方案
2. 涉及工具 kubectl crictl kubeadm journalctl netstat ss lsof tcpdump ip iptables firewall-cmd traceroute nmap 3. 网络问题 首先，我们需要了解 k8s 整个网络架构，数据包是如何流转的，才能快速定位问题。
架构图如下(以flannel为例)：
具体如何排查，网络问题千万种，这里只提供一种思路，仅供参考。
第一步：基本参数，如 overlay,br_netfilter,net.ipv4.ip_forward 等是否配置正确 第二步：防火墙，如 iptables, firewalld 第三步：路由表，如 ip route 第四步：网络插件，如 flannel, calico 第五步：服务发现，如 coredns 第六步：网络策略，如 networkpolicy 第七步：网络日志，如 kubectl describe pod, kubectl logs pod, flannel, calico,journalctl -fu kubelet 第八步：抓包诊断，如 tcpdump, ss, netstat # 基本参数 ## 1 为开启，0 为关闭 ## 查看方法一 lsmod | grep -E 'overlay|br_netfilter' cat /proc/sys/net/ipv4/ip_forward cat /proc/sys/net/bridge/bridge-nf-call-iptables cat /proc/sys/net/bridge/bridge-nf-call-ip6tables ## 查看方法二 modprobe overlay modprobe br_netfilter sysctl net.