跳至主要內容

kubernetes入门理解

科哒大约 15 分钟
  1. 学习文档
  2. 了解kubernetes的诞生和发展历史
  3. 理解kubernetes架构
  4. 理解kubernetes组件
  5. 理解kubernetes对象
  6. 了解kubernetes对象声明配置清单
  7. 推荐Rancher管理k8s集群

一、学习文档

官网地址： https://kubernetes.io/zh-cn/docs/homeopen in new window

推荐开源学习项目：https://kuboard.cn/open in new window

二、了解kubernetes的诞生和发展历史

在我们了解完Devops工作模式下后：

结合上图， 我们知道，项目代码都会被编译打包成镜像，最终docker运行。所有的应用都会运行在容器之中。

随着开发迭代，项目越来越来，需要更多的负载和高可用，docker实例也要随之增加。那docker实例在到达一定数量之后要怎么进行管控和调度，这是一个问题。

kubernetes随之诞生。

关于kubernetes的介绍，诞生发展背景，官方文档说得很清楚。

官方简介连接：/https://kubernetes.io/zh-cn/docs/concepts/overview/open in new window

Kubernetes起源

Kubernetes单词起源于希腊语, 是“舵手”或者“领航员、飞行员”的意思。

光从图标上我们就能把docker 和 Kubernetes联系起来了，一个是航行的集装箱，一个是舵手。

来源于Google的 Borg项目： Borg是谷歌内部的一个容器编排工具，谷歌业务90%以上都在Borg上运行，Borg在谷歌内部已经使用了大概15年。 K8S是在Borg的基础上开发出来的轻量级容器编排工具。K8S的根基非常牢固，得益于Borg过去十数年间积累的经验和教训，是站在巨人的肩膀上发展起来的项目。开源之后，迅速称霸容器编排技术领域。

三、kubernetes架构

官方文档页面：

https://kubernetes.io/zh-cn/docs/concepts/architecture/open in new window

k8s的物理架构是master/node模式：K8S集群至少需要一个主节点(Master)和多个工作节点(Worker)，Master节点是集群的控制节点，负责整个集群的管理和控制，主要用于暴露API、调度部署和对节点进行管理。工作节点主要是运行容器的。

以下官方图为例讲解：

  • 左边CONTROL PLANE：就是master，负责管理Node节点的管控和调度，不直接参与工作。
  • 右边 Node 节点：就是Worker，负责工作，到时候我们的应用程序（tomcat、实际项目、数据等），都由Node负责启动运行完毕后，交由master 调度。

  • 多master/多node模式的高可用架构。
  • 单master/多node 架构。

四、Kubernetes组件

Kubernetes 的Master 节点和 Work 节点，因为它们所扮演的身份和角色不太一样，所以其组件构成部分也不太一样。

总的来说，这里组件的最终目的就是要完成主节点 和 工作节点的通信。

Master node

  • apiserver
  • scheduler
  • controller-manager ：
  • Etcd
  • calico
  • docker

Work node

  • kubelet
  • kube-proxy
  • Calico ：
  • Coredns ：
  • docker ：

组件介绍

kubectl
管理k8s的命令行工具，可以操作k8s中的资源对象，如增删改查等。
etcd
是一个高可用的键值数据库，存储k8s的资源状态信息和网络信息的，etcd中的数据变更是通过api server进行的。
apiserver
提供k8s api，是整个系统的对外接口，提供资源操作的唯一入口，供客户端和其它组件调用，提供了k8s各类资源对象（pod,deployment,Service等）的增删改查，是整个系统的数据总线和数据中心，并提供认证、授权、访问控制、API注册和发现等机制，并将操作对象持久化到etcd中。
scheduler
负责k8s集群中pod的调度的，scheduler通过与apiserver交互监听到创建Pod副本的信息后，它会检索所有符合该Pod要求的工作节点列表，开始执行Pod调度逻辑。调度成功后将Pod绑定到目标节点上，相当于“调度室”。
Controller-Manager
作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。
kubelet
每个Node节点上的kubelet定期就会调用API Server的REST接口报告自身状态，API Server接收这些信息后，将节点状态信息更新到etcd中。kubelet也通过API Server监听Pod信息，从而对Node机器上的POD进行管理，如创建、删除、更新Pod。
kube-proxy
提供网络代理和负载均衡，是实现service的通信与负载均衡机制的重要组件，kube-proxy负责为Pod创建代理服务，从apiserver获取所有service信息，并根据service信息创建代理服务，实现service到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络，将到service的请求转发到后端的pod上。
CoreDNS
CoreDNS 其实就是一个 DNS 服务，而 DNS 作为一种常见的服务发现手段，很多开源项目以及工程师都会使用 CoreDNS 为集群提供服务发现的功能，Kubernetes 就在集群中使用 CoreDNS 解决服务发现的问题。

Calico： 是一套开源的网络和网络安全方案，用于容器、虚拟机、宿主机之前的网络连接，可以用在kubernetes、OpenShift、DockerEE、OpenStrack等PaaS或IaaS平台上。

Docker：容器运行时，负责启动容器的，

五、理解kubernetes对象

通过上述内容我们知道，我们的应用到时候会部署在Node节点上。

通过下图可以看出。应用会运行在容器之中（Docker、），而一个个的Container组合成Pod单元。

什么是 Pod?

官方文档：https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/#what-is-a-podopen in new window

如何创建一个Pod资源？

在K8s中，所有的资源都可以使用一个yaml配置文件来创建，创建Pod也可以使用yaml配置文件。

``
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

那说到这里Pod跟kubernetes对象有什么关系？

Pod 只是众多对象中的一种，用于运行容器。

官方解释kubernetes对象

根据 Kubernetes 官方文档open in new window：
Kubernetes 对象是 Kubernetes 系统中的持久化实体（Persistent Entities），用于描述集群的期望状态（Desired State）。用户通过创建、修改或删除对象，告知 Kubernetes 集群应该运行什么（如应用、存储、网络策略等），而 Kubernetes 控制平面（Control Plane）会持续协调实际状态，直到与期望状态一致。

核心特性

  1. 持久化（Persistence）
    • 对象一旦创建，会被 Kubernetes 存储在集群的数据库（etcd）中，并持续跟踪其状态，直到被显式删除。
    • 例如：删除一个 Pod 后，若其由 Deployment 管理，Kubernetes 会自动重建新 Pod 以维持副本数。
  2. 声明式配置（Declarative Configuration）
    • 用户通过 YAML/JSON 文件定义对象的期望状态（如“运行 3 个副本的 Web 服务”），无需关心具体实现细节。
    • Kubernetes 负责将集群的实际状态（如当前运行的副本数）调整到与期望状态一致。
  3. API 驱动（API-Driven）
    • 所有对象通过 Kubernetes API 进行创建、更新和删除操作。
    • 用户可使用 kubectl 或直接调用 API 与对象交互。

对象的组成

每个 Kubernetes 对象必须包含以下字段：

字段名作用
apiVersion指定对象使用的 Kubernetes API 版本（如 apps/v1、v1）。
kind对象的类型（如 Pod、Deployment、Service）。
metadata元数据（名称、标签、命名空间等），用于标识和筛选对象。
spec用户定义的期望状态（如容器镜像、副本数、端口配置）。
status由 Kubernetes 自动维护的实际状态（如 Pod 的 IP、运行状态）。

常见对象类型

官方文档将对象分为以下主要类别：

类别对象示例作用
工作负载Pod、Deployment、Job管理容器化应用的运行（如副本数、生命周期）。
服务发现Service、Ingress暴露应用访问入口，实现负载均衡和路由。
配置与存储ConfigMap、Secret、PV/PVC注入配置、管理敏感数据、提供持久化存储。
集群管理Namespace、ResourceQuota资源隔离、配额限制。
策略与权限Role、NetworkPolicy控制访问权限、定义网络规则。
扩展对象CustomResourceDefinition (CRD)自定义资源类型，扩展 Kubernetes 功能（如 Operator 模式）。

官方设计哲学

  1. 声明式 API（Declarative API）
    • 用户只需声明“想要什么”，而不是“如何实现”。
    • 例如：用户定义 Deployment 的副本数为 3，Kubernetes 自动处理 Pod 的创建、分布和健康检查。
  2. 控制器模式（Controller Pattern）
    • 每个对象由对应的控制器（如 Deployment Controller）监控，持续比对 spec 和 status，并通过调谐循环（Reconciliation Loop）修正差异。
  3. 标签与选择器（Labels & Selectors）
    • 通过 metadata.labels 标记对象，用 spec.selector 建立对象间的关联（如 Service 选择一组 Pod）。

示例：官方文档中的对象定义

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  • 官方解释：
    此 Deployment 对象声明了“期望 3 个运行 nginx:1.14.2 的 Pod”。Kubernetes 会创建并维护这些 Pod，确保任何时刻都有 3 个健康副本。

总结

Kubernetes 官方将对象视为集群状态的抽象，是用户与 Kubernetes 交互的核心载体。通过定义对象的 spec（期望状态），用户将复杂性交给 Kubernetes 控制平面，实现自动化运维。理解对象的概念是掌握 Kubernetes 的基石！

六、了解kubernetes对象声明配置清单

常见对象

●Replicaset 主要用于控制 Pod 副本的数量，确保 Pod 始终处于期望状态。

●Deployment 是建立在 Replicaset 之上的更高级控制器，提供滚动升级、回滚、平滑扩容缩容等功能，更适合生产环境使用。

通过 Deployment 对象，你可以轻松的做到以下事情：

1、创建 ReplicaSet 和 Pod

2、滚动升级（不停止旧服务的状态下升级）和回滚应用（将应用回滚到之前的版本）

3、平滑地扩容和缩容

4、暂停和继续 Deployment

● Namespace：用于将集群资源划分为不同的虚拟空间，支持多租户和资源隔离。

● Service：用于定义一组 Pod 的访问策略，提供 DNS 名称和稳定的 IP 地址，帮助不同组件之间的通信。

k8s 在创建 Service 时，会根据标签选择器 selector(lable selector)来查找 Pod，据此创建与 k8s 在创建 Service 时，会根据标签选择器 selector(lable selector)来查找 Pod，据此创建与Service 同名的 endpoint 对象，当 Pod 地址发生变化时，endpoint 也会随之发生变化，service 接收前端 client 请求的时候，就会通过 endpoint，找到转发到哪个 Pod 进行访问的地址。(至于转发到哪个节点的 Pod，由负载均衡 kube-proxy 决定)

● StatefulSet：管理有状态的应用，确保每个 Pod 有唯一的标识和稳定的存储卷。

  1. 有状态服务？

StatefulSet 是有状态的集合，管理有状态的服务，它所管理的 Pod 的名称不能随意变化。数据持久化的目录也是不一样，每一个 Pod 都有自己独有的数据持久化存储目录。比如 MySQL 主从、redis 集群等。

  1. 无状态服务？

RC、Deployment、DaemonSet 都是管理无状态的服务，它们所管理的 Pod 的 IP、名字，启停顺序等都是随机的。个体对整体无影响，所有 pod 都是共用一个数据卷的，部署的 tomcat 就是无状态的服务，tomcat 被删除，在启动一个新的 tomcat，加入到集群即可，跟 tomcat 的名字无关。

StatefulSet 由以下几个部分组成：

  1. Headless Service：用来定义 pod 网路标识，生成可解析的 DNS 记录

  2. volumeClaimTemplates：存储卷申请模板，创建 pvc，指定 pvc 名称大小，自动创建pvc，且 pvc 由存储类供应。

  3. StatefulSet：管理 pod 的

● DaemonSet：确保所有节点上都运行一个特定的 Pod，适用于日志收集、监控等场景。

  1. DaemonSet 概述

DaemonSet 控制器能够确保 k8s 集群所有的节点都运行一个相同的 pod 副本，当向k8s 集群中增加 node 节点时，这个 node 节点也会自动创建一个 pod 副本，当 node 节点从集群移除，这些 pod 也会自动删除；删除 Daemonset 也会删除它们创建的 pod

  1. DaemonSet 工作原理：

如何管理 Pod？ daemonset 的控制器会监听 kuberntes 的 daemonset 对象、pod 对象、node 对象，这些被监听的对象之变动，就会触发 syncLoop 循环让 kubernetes 集群朝着 daemonset 对象描述的状态进行演进。

  1. Daemonset 典型的应用场景

在集群的每个节点上运行存储，比如：glusterd 或 ceph。 在每个节点上运行日志收集组件，比如：flunentd 、 logstash、filebeat 等。 在每个节点上运行监控组件，比如：Prometheus、 Node Exporter 、collectd 等。

  1. DaemonSet 与 Deployment 的区别

Deployment 部署的副本 Pod 会分布在各个 Node 上，每个 Node 都可能运行好几个副本。 DaemonSet 的不同之处在于：每个 Node 上最多只能运行一个副本。

● ConfigMap：用于存储配置数据，避免将敏感信息或配置硬编码到容器镜像中。

● Secret：用于存储敏感信息，如密码、令牌等，保护应用的安全性。

● Ingress：提供外部访问集群内服务的 HTTP 和 HTTPS 路由规则，通常用于暴露 Web 服务。

想知道对象有哪些参数配置可以使用命令查看

kubectl explain deployment

KIND: Deployment 
VERSION: apps/v1 
DESCRIPTION: 
 Deployment enables declarative updates for Pods and ReplicaSets. 
FIELDS: 
 apiVersion <string> #该资源使用的 api 版本 
 kind <string> #创建的资源是什么？ 
 metadata <Object> #元数据，包括资源的名字和名称空间 
 spec <Object> #定义容器的 
 status <Object> #状态，不可以修改


kubectl explain deployment.spec

KIND: Deployment 
VERSION: apps/v1 
RESOURCE: spec <Object> 
DESCRIPTION: 
 Specification of the desired behavior of the Deployment. 
 DeploymentSpec is the specification of the desired behavior of the 
 Deployment. 
FIELDS: 
 minReadySeconds <integer>

总结

以上只为辅助理解学习，实战还得经过认真实操和深度学习。

七、推荐Rancher管理k8s集群

****
https://docs.rancher.cn/

Copyright © 2025 科哒