当前位置： 首页 > news >正文

K8s学习--基础

news 2026/6/2 11:28:07
K8s学习--基础

k8s是什么？

K8s / Kubernetes：容器编排平台（“系统”）

kubectl：操作 Kubernetes 的命令行工具（“遥控器”）

核心概念：

常见对象：

  • Pod:运行容器的最小单位
  • Deployment:管理Pod副本
  • Service:服务访问入口
  • Namespace:环境隔离
  • ConfigMap:配置
  • Secret:密码
  • Ingress:网关/域名入口
  • Node:机器节点

常见对象的作用：

  1. Pod：

Pod = 一个“运行环境” + 容器
一个 Spring Boot 微服务（独立部署单元） → 一个容器 → 一个 Pod

作用：

  • 真正运行容器
  • 提供IP
  • 挂载存储
  • 暴露端口
  1. Deployment:

管理Pod生命周期

作用：

  • 创建Pod
  • 保证副本数量
  • 自动恢复
  • 滚动更新

创建副本是为了高并发做负载均衡<-水平扩容、保证数量是为了能够高可用防止服务挂掉，滚动更新，自动恢复

  1. Service:

给Pod一个稳定访问地址

Pod的IP会发生变化
Service提供稳定的入口，如user-service
请求：http://user-service
自动转发到后面多个Pod

关系：

Service↓Pod1Pod2Pod3

还能做负载均衡，请求：/api/user自动分发：

Pod1
Pod2
Pod3
  1. Namespace:

逻辑分区

相当于文件夹，使得同名资源可共存，如：

dev/user-service
prod/user-service

不同环境、不同项目、不同系统组件可以放在不同的namespace中

  1. ConfigMap

配置中心，放普通配置如：数据库地址、Redis地址、系统参数

作用：

配置与程序分离，上线不需要重新打包

  1. Secret:

密码配置，例如：token、api-key、证书

  1. Ingress 网关/域名入库

外部流量入口

Service 解决 Pod 动态 IP 和负载均衡

Ingress 解决外部统一入口、域名/路径路由、TLS 等 L7 功能

外部请求↓
Ingress (统一 HTTP 入口)↓
Service (L4 负载均衡)↓
Pod (应用实例)

如：
现有下面三个服务

user-service
order-service
menu-service

想要发送请求：

api.xxx.com/user
api.xxx.com/order

Ingress 做路由：

请求↓
Ingress├── /user  -> user-service└── /order -> order-service

配置：

rules:
- host: api.demo.comhttp:paths:- path: /user

作用：

  • 域名
  • HTTPS
  • 路由转发
  1. Node:

工作机器，真正跑Pod的机器

以一个Spring Boot项目为例：

menu-service(Spring Boot)↓
Deployment（3副本）↓Pods↓
Service（统一入口）↓
Ingress（域名访问）数据库密码 -> Secret
Redis地址 -> ConfigMap
dev/test/prod -> Namespace

menu-service 是一个 Spring Boot 服务，它被部署到 Kubernetes 中，由一个 Deployment 管理，并配置了 3 个副本（Pods）来保证高可用和负载能力；这些 Pod 通过 Service 暴露出统一的服务入口，供集群内部访问；外部请求则通过 Ingress 结合域名转发到对应服务。运行过程中，数据库密码等敏感信息存放在 Secret 中，Redis 地址等普通配置存放在 ConfigMap 中，同时通过 Namespace 将开发（dev）、测试（test）、生产（prod）环境进行隔离。

核心作用是：

  1. 自动管理大量容器的部署、扩缩容、故障恢复和网络通信。
比如有一个 Java 服务、MySQL、Redis、前端 Vue 应用：
以前可能：
手动启动 Docker
自己配端口
宕机手动重启
高并发时手动扩容用Kubernetes后可以实现
1. 自动部署应用
比如部署一个 Spring Boot 服务：
你告诉它：
我要 3 个实例
K8s 自动启动。2. 自动扩容
流量高：
3 个实例不够。
K8s：
自动扩到 10 个实例
流量低：
缩回 2 个3. 自动恢复
某个 Pod 崩了：
K8s：
自动重启服务器挂了：
K8s：
换台机器重新拉起4. 服务发现与负载均衡
不用记 IP。
直接访问 Service：
user-service
K8s 自动把请求分发到多个实例。5. 配置与密钥管理
例如：
数据库密码
Redis 地址
环境变量通过：ConfigMap、Secret管理。

kubectl:

操作k8s集群的CLI

功能：

  • 查看集群
  • 部署应用
  • 删除应用
  • 查看日志
  • 重启服务

常见的kubectl命令：
查看命名空间的命令

kubectl get namesapces# 可以简写为
kubectl get ns

执行后可以看到的结果：

NAME              STATUS   AGE
default           Active   120d
kube-system       Active   120d
kube-public       Active   120d
kube-node-lease   Active   120d
lawson-dev        Active   30d
lawson-uat        Active   20d

含义：

  • NAME:命名空间名称
  • STATUS:状态，Active表示正常
  • AGE:已创建多久

查看pod：

# 查看pod：
kubectl get pods
# 查看某个namespace下面的Pod：
kubectl get pods -n [命名空间]
# 查看所有namespace下的Pod：
kubectl get pods --all-namespaces
kubectl get pods -A

查看service：

# 查看service：
kubectl get svc
# 查看某个namespace下的服务：
kubectl get svc -n [命名空间]

查看deployment：

kubectl get deploy

[root@VM-27-206-tencentos ~]# kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
kubernetes-proxy   2/2     2

含义：

  • NAME:Deployment名字
  • READY:已经准备好的Pod数，期望Pod数 READY = 已就绪/总副本数
  • UP-TO-DATE:已经更新到最新版本的Pod数量
  • AVAILABLE:当前可提供服务的Pod数量
  • AGE:创建时间

当升级中时（滚动更新时），可以看到：

READY        1/2
UP-TO-DATE   1

当发现已准备好Pod数和当前可提供服务的Pod数量不一致

READY 2/2
AVAILABLE 1

可能是Pod启动成功但是健康检查还没通过

看日志：

kubectl logs [pod-name]
# 看实时日志
kubectl logs [pod-name] -f

进入容器：

kubectl exec -it [pod-name] --bash

questions

为什么Pod和Service都在Namespace下面？他们俩是什么关系？

Pod是运行环境+容器，真正运行逻辑的地方

Service是访问Pod的入口，类似于网关

Namespace,Pod,Service的关系如下：

Namespace├── Pod└── Service↓指向 Pod

以一个简单的SpringBoot服务menu-service为例:

该服务运行了3个副本：

Pod1
Pod2
Pod3

Pod的IP是不稳定的，所以k8s引入Service的目的就是为例给Pod一个稳定的访问入口

当有请求：

http://menu-service

到Service进行转发到Pod

    Service↓┌──────┼──────┐
Pod1   Pod2   Pod3

为什么Service和Pod都在Namespace下面？

Namespace是逻辑隔离空间

k8s的对象：

  • Pod
  • Service
  • Deployment
  • ConfigMap
  • Secret

大多数都是Namespace级资源

示例：

Namespace: devDeployment/menu-service
Pod/menu-service-xxx
Service/menu-service

Namespace: prodDeployment/menu-service
Pod/menu-service-yyy
Service/menu-service

为什么service和Pod是同级的，而不是Service包含Pod

  1. 在k8s中Pod是消耗品

以3个Pod为例：

今天:
Pod1
Pod2
Pod3

一分钟后：

Pod2 崩了

Deployment:

重新创建Pod4

变成了：

Pod1
Pod3
Pod4

若遇到升级 v1->v2，此时会发生：

删 Pod1
起 Pod5

因此，如果Service包含Pod，那么Service的结果会不断修改

  1. 一个Pod可以同时属于多个Service
    以menu-service为例，现有
labels:app: menu-serviceversion: v1

现在ServiceA业务访问：

selector:app: menu-service

命中：

Pod1
Pod2
Pod3

ServiceB灰度发布：

selector:version: v1

命中：

Pod1
Pod2

ServiceC监控：

selector:app: menu-service

结果：

    Pod↑   ↑   ↑|   |   |
SvcA SvcB SvcC
  1. 解耦，职责分离
    Deployment也要管理Pod

Deployment负责副本、升级、恢复
Service负责流量转发、负载均衡
如果Service包含Pod会发生严重耦合，职责不清晰的问题