安装k8s过程中涉及知识点梳理

网站调用接口（在执行js操作的时候），或者拉取静态资源的时候，两种方式：【核心区别在于是否依赖当前页面的 URL（浏览器地址栏地址）来解析目标资源的位置。】

相对路径：依赖浏览器地址栏的 URL 解析

相对路径的本质是 "相对于当前页面的 URL" 来定位目标资源，它不会包含完整的协议（如http://、https://）和域名，而是以当前页面所在的路径为基准进行 "拼接"。

核心特点：

路径不完整，需要结合浏览器地址栏的 URL（当前页面 URL）才能解析出完整地址；
写法灵活，常用符号表示层级关系：
- 无特殊前缀：默认相对于当前页面所在的目录（如style.css）；
- ./：明确表示相对于当前页面所在的目录（和无前缀效果一致，如./api/data）；
- ../：表示 "上一级目录"（如../images/logo.png，即当前目录的父目录）；
- 多级层级：可叠加../表示多级父目录（如../../libs/jquery.js）。

绝对路径：不依赖浏览器地址栏，直接指向固定位置

绝对路径是 "完整的资源地址"，它包含了定位资源所需的全部信息（协议、域名、端口、路径等），因此不依赖当前页面的 URL，无论浏览器地址栏是什么，都会直接请求这个固定路径。

核心特点：

路径完整，包含协议（如https://）和域名（或 IP），例如https://api.example.com/user/login、https://cdn.example.com/img/logo.png；
部分场景中，以/开头的路径（称为 "根相对路径"）也被视为特殊的 "绝对路径"（但严格来说是 "站点内绝对路径"），它以网站的根目录为基准，不依赖当前页面的子目录（例如/api/data，无论当前页面在哪个子目录，都会解析为https://www.example.com/api/data）。

http请求状态码：

https://blog.csdn.net/2401_84091289/article/details/137442342

docker安装网站：

https://docs.docker.com/desktop/setup/install/windows-install/

WSL是什么？

WSL 是 Windows Subsystem for Linux（Windows Linux 子系统）的缩写，是微软开发的一项 Windows 系统功能，它允许在 Windows 操作系统中直接运行 Linux 环境（包括命令行工具、Linux 软件、脚本等），而无需安装传统的虚拟机或进行双系统分区。

Hype-V是什么？

Hyper-V ：是硬件级虚拟化技术 （Type-1 虚拟机监控程序），直接运行在物理硬件上，能创建独立的虚拟机（VM）。每个虚拟机都包含完整的操作系统（如 Windows、Linux）、内核和应用，资源隔离性极强，但性能开销较大（因为需要模拟完整硬件）。
Docker ：是操作系统级虚拟化技术（容器化引擎），基于宿主操作系统的内核，通过 "容器" 封装应用及其依赖。容器不包含完整操作系统，而是共享宿主内核，因此更轻量、启动更快、资源占用更低，但隔离性弱于虚拟机。

Windows 环境下配置本地 Kubernetes（k8s）集群的流程

1 下载docker，安装离线wsl，打开docker Desktop

2 打开cmd，确定小三角有ubuntu（在微软商店安装）

3 cmd输入：minikube start 【 启动本地单节点 Kubernetes 集群 的核心命令，由 minikube 工具提供。它的主要作用是在你的本地计算机上快速搭建一个轻量级的 Kubernetes 环境】----minikube delete --all【失败时先删除之前的】

4 若启动失败显示缺少镜像：

minikube delete --all

docker load -i gcr.tar

minikube start

Ubuntu和wsl的关系？

WSL 是 Windows 系统上支持 Linux 环境运行的技术框架，而 Ubuntu 是可在 WSL 上安装和运行的具体 Linux 发行版 ** 之一。

在 Windows 环境中，需要一个 Linux 环境来满足 k8s 对内核特性、容器运行时的依赖，而 Ubuntu 是 WSL 生态中最易用、最流行的 Linux 发行版。

基本操作

每次开机都需要：启动docker ---minikube start

开启控制台：

minikube dashboard 快速启动并访问 Kubernetes Dashboard（Kubernetes 仪表盘）------ 这是一个基于网页的图形化界面，用于可视化管理本地 Minikube 集群。

bash 复制代码

kubectl get ingress

pod和node的区别？

维度	Docker	Pod	Node
定义	容器运行时（工具），用于创建、运行、管理容器。	Kubernetes 最小部署单元，包含一个或多个紧密关联的容器。	Kubernetes 集群的工作节点（物理 / 虚拟机），提供计算资源。
角色	负责运行容器，是容器的 "执行者"。	负责组织容器，是应用的 "最小载体"（容器的逻辑分组）。	负责承载 Pod，是 Pod 的 "物理宿主"（提供硬件资源）。
层级关系	运行在 Node 上，为 Pod 内的容器提供运行环境。	运行在 Node 上，由 Docker 等运行时创建容器。	是最底层的物理 / 虚拟节点，承载 Docker 和 Pod。
功能边界	聚焦 "容器生命周期管理"（创建、启动、停止容器）。	聚焦 "应用组件协作"（同一 Pod 内的容器共享资源、协同工作）。	聚焦 "资源提供"（为 Pod 分配 CPU、内存，管理节点上的所有 Pod）。

k8s的调用链路：

外部用户请求 → NGinx 网关接收 → Ingress 根据规则转发 → service 通过域名找到对应的服务 → 分发到后端 Node 上的 Pod 中，由 Pod 内的容器处理请求。

NGinx, gateway（网关层）

是整个系统的 "入口"，负责接收外部用户的请求，可实现请求路由、负载均衡、鉴权、限流等功能。例如，用户通过域名访问应用时，请求首先到达 Nginx 网关。

Ingress（服务接入层）

是 Kubernetes 中管理外部流量进入集群内部服务的组件，图中标注了 "服务器 IP，服务器端口"，表示它会绑定具体的 IP 和端口，将外部请求转发到对应的内部服务。可以理解为集群的 "流量总调度员"，根据规则把不同的请求分发到不同的服务。

service（服务发现层）

是 Kubernetes 中定义的 "服务抽象"，图中标注 "域名"，表示它通过域名暴露服务，负责将请求转发到后端的 Pod（容器组）。它起到 "服务发现" 的作用，让集群内部的服务可以通过域名互相访问，无需关心 Pod 的具体 IP 变化。

Node 与 Pod（计算与应用层）

Node：是 Kubernetes 集群中的工作节点（物理机或虚拟机），图中的 Node1 和 Node2 是两台不同的节点，提供计算资源。
Pod：是 Kubernetes 中最小的部署单元，一个 Pod 可以包含一个或多个容器。图中的 Pod1-1、POD2-1（Node1 上）和 Pod1-2、po2-2、Pod1-3（Node2 上）是运行应用的容器组，实际承载着业务应用。

配置中心

k8s 配置中心 ：主要用于配置环境变量、Spring Boot 配置文件等与应用运行环境强相关的基础配置。
Nacos 配置中心（Spring Cloud 体系） ：配置更灵活，常用于管理业务级的动态配置（如折扣比例、业务规则等）。

无状态/有状态容器

维度	无状态容器	有状态容器
数据存储	无持久化数据，依赖外部服务	需持久化数据，依赖本地存储
实例身份	所有实例等价，可随意替换	每个实例有唯一身份，不可随意替换
扩缩容 / 部署	无序，可快速扩缩容	有序，需按顺序启动 / 销毁
依赖关系	无依赖，独立运行	可能依赖其他实例（如主从关系）
K8s 管理资源	Deployment + Service	StatefulSet + Headless Service + PV/PVC

server-api是什么？

"server-api" 通常指 服务器端提供的应用程序接口（API，Application Programming Interface），是服务器对外暴露的、供客户端（或其他服务）调用的一组规则和接口集合，用于实现不同系统之间的数据交互或功能调用。

Kubernetes（k8s）配置文件：

通过 3 个资源（Deployment、Service、Ingress）的配置，在 k8s 集群中部署一个 Nginx 服务，并实现 "外部通过域名访问 Nginx" 的完整流程：

Deployment：创建并管理 Nginx 的 Pod（容器实例）；
Service：为 Pod 提供稳定的内部访问地址（集群内可用）；
Ingress：配置外部访问规则，让外部通过域名访问到集群内的 Nginx。

bash 复制代码

# -----------------------------
# 1️⃣ 部署一个 Nginx Pod（通过Deployment管理）
# -----------------------------
# 声明使用的k8s API版本（apps/v1是Deployment资源的当前稳定版本）
apiVersion: apps/v1
# 资源类型：Deployment（用于管理无状态应用的Pod，支持扩缩容、滚动更新等）
kind: Deployment
metadata:
  # Deployment的名称（唯一标识，用于k8s内部管理）
  name: nginx-deployment
  # 给Deployment打标签（键值对），用于筛选或关联其他资源
  labels:
    app: nginx
spec:
  # 指定要运行的Pod副本数（这里启动1个Nginx实例）
  replicas: 1
  # 选择器：通过标签匹配要管理的Pod（只管理标签为app: nginx的Pod）
  selector:
    matchLabels:
      app: nginx
  # Pod模板：定义要创建的Pod的配置（所有副本Pod都基于此模板创建）
  template:
    metadata:
      # 给Pod打标签（需与上面的selector.matchLabels一致，才能被Deployment管理）
      labels:
        app: nginx
    spec:
      # 定义Pod内运行的容器列表
      containers:
        - name: nginx  # 容器名称（在Pod内唯一）
          image: nginx:latest  # 容器使用的镜像（这里是最新版Nginx）
          ports:
            - containerPort: 80  # 容器内部暴露的端口（Nginx默认监听80端口）

---  # 分隔符：用于在一个文件中定义多个k8s资源

# -----------------------------
# 2️⃣ 创建一个 ClusterIP 类型的 Service（集群内部访问入口）
# -----------------------------
# 声明API版本（v1是Service资源的基础版本）
apiVersion: v1
# 资源类型：Service（用于为Pod提供稳定的访问地址，实现服务发现）
kind: Service
metadata:
  # Service的名称（唯一标识，集群内可通过此名称访问）
  name: nginx-service
spec:
  # Service类型：ClusterIP（仅在集群内部可见，生成一个内部IP供集群内访问）
  type: ClusterIP
  # 选择器：通过标签关联Pod（只将请求转发到标签为app: nginx的Pod）
  selector:
    app: nginx  # 与Deployment中Pod的标签一致，实现Service与Pod的绑定
  # 端口映射：定义Service的端口与Pod端口的对应关系
  ports:
    - port: 80  # Service暴露的端口（集群内访问Service时使用此端口）
      targetPort: 80  # 目标Pod的端口（与Pod中containerPort一致，即Nginx的80端口）

---  # 分隔符

# -----------------------------
# 3️⃣ 创建一个 Ingress 规则（外部访问入口）
# -----------------------------
# 声明API版本（networking.k8s.io/v1是Ingress资源的当前稳定版本）
apiVersion: networking.k8s.io/v1
# 资源类型：Ingress（用于配置外部访问集群内服务的规则，如域名、路径转发）
kind: Ingress
metadata:
  # Ingress的名称（唯一标识）
  name: nginx-ingress
  # 注解：配置Ingress控制器的额外参数（这里是Nginx Ingress控制器的规则）
  annotations:
    # 路径重写：将外部请求的路径重写为目标路径（这里重写为根路径/）
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  # 指定使用的Ingress控制器类型（需提前在集群中部署nginx类型的Ingress控制器）
  ingressClassName: nginx
  # 访问规则：定义外部请求如何转发到内部服务
  rules:
    # 限制访问的域名（外部需通过此域名访问，如nginx.local，需在本地 hosts 绑定集群Ingress控制器IP）
    - host: nginx.local
      http:  # 基于HTTP协议的规则
        paths:  # 路径匹配规则
          - path: /  # 匹配外部请求的路径（这里匹配根路径/及所有子路径）
            pathType: Prefix  # 路径匹配类型：Prefix（前缀匹配，如/abc、/abc/123都能匹配）
            backend:  # 匹配后转发的目标服务
              service:
                name: nginx-service  # 目标Service的名称（关联上面创建的nginx-service）
                port:
                  number: 80  # 目标Service的端口（与Service的port一致）