news 2026/5/7 4:50:29

云原生部署_k8s入门

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
云原生部署_k8s入门

K8S官网文档：https://kubernetes.io/zh/docs/home/

Kubernetes是什么

Kubernetes 是用于自动部署、扩缩和管理容器化应用程序的开源系统。 Kubernetes 源自 ，Google 15 年生产环境的运维经验同时凝聚了社区的最佳创意和实践。简称K8s.

Kubernetes：作为开源的容器编排引擎，用来对容器化应用进行自动化部署、 扩缩和管理。

K8s核心架构

K8S 是属于Master-Worker架构，即有 Master 节点负责核心的调度、管理和运维，Worker 节点则执行用户的程序。但是在 K8S 中，主节点一般被称为Master Node ，而从节点则被称为WorkerNode 或者 Node。

所有 Master Node 和 Worker Node 组成了K8S 集群，同一个集群可能存在多个 Master Node 和 Worker Node。（不是单个主节点）。

为了实现对应的能力，不同类型的节点具有不同的组件。

Master Node组件

  • kube-apiserver。K8S 的请求入口服务。API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI 命令行工具），然后，API Server 根据用户的具体请求，去通知其他组件干活。
  • Scheduler。K8S 所有Worker Node 的调度器。当用户要部署服务时，Scheduler 会选择最合适的 Worker Node（服务器）来部署。
  • Controller Manager。K8S 所有 Worker Node 的监控器。Controller Manager 有很多具体的 Controller，Node Controller、Service Controller、Volume Controller 等。Controller 负责监控和调整在 Worker Node上部署的服务的状态，比如用户要求 A 服务部署 2 个副本，那么当其中一个服务挂了的时候，Controller 会马上调整，让 Scheduler 再选择一个 Worker Node 重新部署服务。
  • etcd。K8S 的存储服务。etcd 存储了 K8S 的关键配置和用户配置。K8S 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据。

Worker Node组件

  • Kubelet。Worker Node 的监视器，以及与 Master Node 的通讯器。Kubelet 是 Master Node 安插在Worker Node 上的“眼线”，它会定期向 Master Node 汇报自己 Node 上运行的服务的状态，并接受来自Master Node 的指示采取调整措施。负责控制所有容器的启动停止，保证节点工作正常。
  • Kube-Proxy。K8S 的网络代理。Kube-Proxy 负责 Node 在 K8S 的网络通讯、以及对外部网络流量的负载均衡。
  • Container Runtime。Worker Node 的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如 Docker Engine运行环境。

K8s网络模型

K8s内部存在4中不同的网络通信：

  1. 同一个Pod内容器之间的通信
  2. 不同Pod之间通信
  3. Pod和Service之间通信
  4. 集群外部流量和Service之间

K8S为Pod和Service资源对象分别使用了各自的专有网络，Pod网络由K8S的网络插件配置实现，而Service网络则由K8S集群指定。

K8s实战/kubectl命令使用

kubectl是apiserver的客户端工具，工作在命令行下，能够连接apiserver实现各种增删改查等操作。kubectl官方使用文档：https://kubernetes.io/zh/docs/reference/kubectl/overview/

NameSpace（命名空间）

  • 将同一集群中的资源划分为相互隔离的组。
  • 同一命名空间内的资命名称要唯一.
  • 命名空间是用来隔离资源的，不隔离网络。

创建namespace

1. 命令方式

kubectl create namespace tuling

2. yaml方式

新建一个名为 my-namespace.yaml 的 YAML 文件

apiVersion: v1

kind: Namespace

metadata:

name: tulingmall

运行：kubectl apply -f my-namespace.yaml

删除namespace

kubectl delete namespace tuling

kubectl delete -f my-namespace.yaml

Pod

Pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元。

Pod中可以有一个或多个容器，这些容器共享存储、网络、以及怎样运行这些容器的声明。

Deployment

Deployment负责创建和更新应用程序的实例，使Pod拥有多副本，自愈，扩缩容等能力。

创建Deployment后，Kubernetes Master 将应用程序实例调度到集群中的各个节点上。如果托管实例的节点关闭或被删除，Deployment控制器会将该实例替换为群集中另一个节点上的实例。这提供了一种自我修复机制来解决机器故障维护问题。

kubectl create deployment // 可以创建一个应用部署deployment与pod

1.kubectl create deployment my-tomcat --image=tomcat:9.0.55

#my-tomcat表示pod的名称 --image表示镜像的地址

2. kubectl get deployment

#查看一下deployment的信息

3. kubectl delete deployment my-tomcat

#删除deployment

4. kubectl logs my-tomcat-6d6b57c8c8-n5gm4

#查看Pod打印的日志

5. #使用 exec 可以在Pod的容器中执行命令

kubectl exec my-tomcat-6d6b57c8c8-n5gm4 -- env #使用 env 命令查看环境变量

kubectl exec my-tomcat-6d6b57c8c8-n5gm4 -- ls / # 查看容器的根目录下面内容

kubectl exec my-tomcat-6d6b57c8c8-n5gm4 -- sh #进入Pod容器内部并执行bash命令，如果想退出容器可以使用exit命令

Service

Service是一个抽象层，它定义了一组Pod的逻辑集，并为这些Pod支持外部流量暴露、负载均衡和服务发现。

尽管每个Pod 都有一个唯一的IP地址，但是如果没有Service，这些IP不会暴露在集群外部。Service允许您的应用程序接收外部流量。Service也可以用在ServiceSpec标记type的方式暴露，type类型如下：

  • ClusterIP（默认）：在集群的内部IP上公开Service。这种类型使得Service只能从集群内访问。
  • NodePort：使用NAT在集群中每个选定Node的相同端口上公开Service。使用 <NodeIP>:<NodePort> 从集群外部访问Service。是ClusterIP的超集。
  • LoadBalancer：在当前云中创建一个外部负载均衡器(如果支持的话)，并为Service分配一个固定的外部IP。是NodePort的超集。
  • ExternalName：通过返回带有该名称的CNAME记录，使用任意名称（由spec中的externalName指定）公开Service。不使用代理。

Ingress

Ingress是一种Kubernetes资源类型，它允许在Kubernetes集群中暴露HTTP和HTTPS服务。通过 Ingress，您可以将流量路由到不同的服务和端点，而无需使用不同的负载均衡器。

Ingress 通常使用 Ingress Controller 实现，它是一个运行在 Kubernetes 集群中的负载均衡器，它根据Ingress 规则配置路由规则并将流量转发到相应的服务。

Ingress 和 Service区别

Ingress 和 Service都是 Kubernetes 中用于将流量路由到应用程序的机制，但它们在路由层面上有所不同：

  • Service 是 Kubernetes 中抽象的应用程序服务，它公开了一个 单一的IP地址和端口，可以用于在 Kubernetes集群内部的 Pod 之间进行流量路由。
  • Ingress 是一个 Kubernetes 资源对象，它提供了对集群外部流量路由的规则。Ingress 通过一个公共IP地址和端口将流量路由到一个或多个Service。

存储

Volume

Volume指的是存储卷，包含可被Pod中容器访问的数据目录。容器中的文件在磁盘上是临时存放的，当容器崩溃时文件会丢失，同时无法在多个Pod中共享文件，通过使用存储卷可以解决这两个问题。

PV & PVC

Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。要使用Volume， Pod 必须事先知道以下信息：

  • 当前的 Volume 类型并明确 Volume 已经创建好。
  • 必须知道 Volume 的具体地址信息。

但是 Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息，要么询问管理员，要么自己就是管理员。这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。

Kubernetes 给出的解决方案是 Persistent Volume 和 Persistent Volume Claim。

  • PersistentVolume(PV）是外部存储系统中的一块存储空间，由管理员创建和维护，将应用需要持久化的数据保存到指定位置。PV 具有持久性，生命周期独立于 Pod。
  • Persistent Volume Claim (PVC)是对 PV 的申请 (Claim），申明需要使用的持久卷规格。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个PVC，指明存储资源的容量大小和访问模式 （比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。

有了PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配、如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理。

K8S工作流程

以k8s部署nginx为例，在master节点执行一条命令要master部署一个nginx应用

(kubectl create deployment nginx --image=nginx)

Master Node动作：

  1. 这条命令首先发到master节点的网关api server，这是matser的唯一入口
  2. api server将命令请求交给controller mannager进行控制(请求转交：api server -> controller)
  3. controller mannager 进行应用部署解析，生成一次部署信息，并通过api server将信息存入etcd存储（存储要部署的应用: controller->etcd）
  4. scheduler调度器通过api server从etcd存储中，拿到要部署的应用，开始调度看哪个节点有资源适合部署(读取要部署的应用：etcd ->scheduler)
  5. scheduler把计算出来的调度信息通过api server再放到etcd中（保存调度信息：scheduler->etcd）

Worker Node动作：

  1. 每一个node节点的监控组件kubelet，随时和master保持联系（给api-server发送请求不断获取最新数据），拿到master节点存储在etcd中的部署信息(node获取Master信息)
  2. 假设node2的kubelet拿到部署信息，显示他自己节点要部署某某应用，kubelet就自己run一个应用在当前机器上，并随时给master汇报当前应用的状态信息（node执行相应动作）
  3. node和master也是通过master的api-server组件联系的
  4. 每一个Node机器上的kube-proxy能知道集群的所有网络，只要node访问别人或者别人访问node，node上的kube-proxy网络代理自动计算进行流量转发（流量转发）

概念再分析

  • 土地/温室 (物理主机)：提供最底层的电力、物理空间。 或者更形象一点：一根无限长的、可以无限分叉的豆藤（物理集群/云平台）。

  • 豆荚苗 (节点)：从豆藤上生长出来的一个独立植株（虚拟机或物理机）。

  • 豆荚 (Pod)：苗上结的荚。

  • 豆子 (容器)：荚里的籽。

比喻分析：

  • 节点 = 豆荚苗 (植株)：这个比喻的优点在于，它体现了承载和生长的关系。

    • 一棵豆荚苗（节点）上可以结出多个豆荚（Pod）。

    • 豆荚苗提供水分、养分和物理支撑（节点提供CPU、内存、存储和网络）。

    • 这与物理机/虚拟机承载Pod的关系高度吻合。

  • Pod = 豆荚：这个比喻依然完美，豆荚是自然的最小单元，里面包裹着豆子。

  • 容器 = 豆子：依然贴切。

但在K8s语境下需要更精确一点：

  1. 节点 (Node) 不一定是物理机：

    • 在大多数云环境或开发测试环境中，节点（Node）通常是一台云服务器（虚拟机），比如阿里云ECS、AWS EC2。虚拟机底层虽然是物理机，但对K8s来说，这台VM就是一个完整的“节点”。

    • 对于K8s而言，物理机和虚拟机在其上的角色是等同的——都是提供资源的“主机”。

  2. 豆荚苗是物理机 vs 豆荚苗是节点：

    • 如果集群很大，每个节点是一台物理机，那么豆荚苗就是物理机。

    • 如果集群在云上，每个节点是一个虚拟机，那么豆荚苗就是虚拟机，而物理机相当于“土地”或“温室”。

版权声明: 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！
网站建设 2026/5/7 4:49:31

如何用自然语言构建专属RAG智能体：5分钟快速上手指南

如何用自然语言构建专属RAG智能体&#xff1a;5分钟快速上手指南 【免费下载链接】rags Build ChatGPT over your data, all with natural language 项目地址: https://gitcode.com/gh_mirrors/ra/rags RAGs是一款基于Streamlit开发的应用程序&#xff0c;能够让你通过自…

作者头像 李华
网站建设 2026/5/7 4:42:29

Arkloop开源框架：实现应用状态无缝流转与跨端连续体验

1. 项目概述与核心价值最近在折腾一个挺有意思的开源项目&#xff0c;叫 Arkloop。这名字听起来有点抽象&#xff0c;但它的内核其实非常聚焦&#xff1a;一个旨在实现“应用状态无缝流转与循环”的框架。简单来说&#xff0c;它想解决的是我们在不同设备、不同应用、不同场景之…

作者头像 李华
网站建设 2026/5/7 4:39:48

Homemade-Machine-Learning性能调优：10个系统优化技巧

Homemade-Machine-Learning性能调优&#xff1a;10个系统优化技巧 【免费下载链接】homemade-machine-learning &#x1f916; Python examples of popular machine learning algorithms with interactive Jupyter demos and math being explained 项目地址: https://gitcode…

作者头像 李华
网站建设 2026/5/7 4:39:47

Windows系统维护实战：便携工具箱MiLu_EXE的功能解析与安全使用指南

1. 项目概述&#xff1a;一个轻量级Windows系统优化工具箱最近在整理自己的工具箱时&#xff0c;又翻出了这个老朋友——MiLu_EXE。这其实不是一个单一的软件&#xff0c;而是一个由国内开发者“White-147”维护的、集成在单个可执行文件里的Windows系统实用工具集合。如果你经…

作者头像 李华