kubernetes学习记录

kubernetes学习记录

1
腾讯汽车云

[kuboard官网](Kubernetes教程 | Kuboard)

kubernetes

1
2
3
4
5
6
7
8
9
10
11
Kubernetes（简称K8s）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。
Pod
Pod是Kubernetes中最小的部署单元，可以包含一个或多个容器。这些容器共享网络、存储和生命周期。Pod内的容器可以相互通信，而无需通过网络。
Service
Service是一种抽象资源，用于定义一组Pod的逻辑集合和访问策略。它允许外部流量访问Pod，同时隐藏Pod的具体实现细节。
Deployment
Deployment是一种控制器，用于管理Pod的副本数量和更新策略。它确保指定数量的Pod副本始终运行，并支持滚动更新。
Node
Node是Kubernetes集群中的一个工作机器，可以是物理机或虚拟机。每个Node上运行着kubelet、容器运行时（如Docker或containerd）等组件。
Cluster
Cluster是由多个Node组成的集群，用于运行容器化应用程序。集群由控制平面（Control Plane）和工作节点（Worker Nodes）组成。

deployment

1
2
3
4
Deployment 译名为 部署。在k8s中，通过发布 Deployment，可以创建应用程序 (docker image) 的实例 (docker container)，这个实例会被包含在称为 Pod 的概念中，Pod 是 k8s 中最小可管理单元。
在 k8s 集群中发布 Deployment 后，Deployment 将指示 k8s 如何创建和更新应用程序的实例，master 节点将应用程序实例调度到集群中的具体的节点上。
创建应用程序实例后，Kubernetes Deployment Controller 会持续监控这些实例。如果运行实例的 worker 节点关机或被删除，则 Kubernetes Deployment Controller 将在群集中资源最优的另一个 worker 节点上重新创建一个新的实例。这提供了一种自我修复机制来解决机器故障或维护问题。
在容器编排之前的时代，各种安装脚本通常用于启动应用程序，但是不能够使应用程序从机器故障中恢复。通过创建应用程序实例并确保它们在集群节点中的运行实例个数，Kubernetes Deployment 提供了一种完全不同的方式来管理应用程序。
1
Deployment处于 master 节点上，通过发布 Deployment，master 节点会选择合适的worker节点创建 Container，Container 会被包含在 Pod里。

kubectl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# deployment.yaml
apiVersion: apps/v1	#与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment	#该配置的类型，我们使用的是 Deployment
metadata:	        #译名为元数据，即 Deployment 的一些基本属性和信息
  name: nginx-deployment	#Deployment 的名称
  labels:	    #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解
    app: nginx	#为该Deployment设置key为app，value为nginx的标签
spec:	        #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用
  replicas: 1	#使用该Deployment创建一个应用程序实例
  selector:	    #标签选择器，与上面的标签共同作用，目前不需要理解
    matchLabels: #选择包含标签app:nginx的资源
      app: nginx
  template:	    #这是选择或创建的Pod的模板
    metadata:	#Pod的元数据
      labels:	#Pod的标签，上面的selector即选择包含标签app:nginx的Pod
        app: nginx
    spec:	    #期望Pod实现的功能（即在pod中部署）
      containers:	#生成container，与docker中的container是同一种
      - name: nginx	#container的名称
        image: nginx:1.7.9	#使用镜像nginx:1.7.9创建container，该container默认80端口可访问
1
2
3
4
5
6
7
8
9
应用 YAML 文件
kubectl apply -f nginx-deployment.yaml
 
    
查看部署结果
# 查看 Deployment
kubectl get deployments
# 查看 Pod
kubectl get pods
1
2
可分别查看到一个名为 nginx-deployment 的 Deployment 和一个名为 nginx-deployment-xxxxxxx 的 Pod
任务二达成，至此你已经成功在k8s上部署了一个实例的nginx应用程序

kuboard

heml

pods

1
2
3
4
5
Pod 容器组 是一个k8s中一个抽象的概念，用于存放一组 container，以及这些 container（容器）的一些共享资源。这些资源包括：
1.共享存储，称为卷(Volumes)
2.网络，每个 Pod（容器组）在集群中有个唯一的 IP，pod（容器组）中的 container（容器）共享该IP地址
3.container（容器）的基本信息，例如容器的镜像版本，对外暴露的端口等
例如，Pod可能既包含带有Node.js应用程序的 container 容器，也包含另一个非 Node.js 的 container 容器，用于提供 Node.js webserver 要发布的数据。Pod中的容器共享 IP 地址和端口空间（同一 Pod 中的不同 container 端口不能相互冲突），始终位于同一位置并共同调度，并在同一节点上的共享上下文中运行。（同一个Pod内的容器可以使用 localhost + 端口号互相访问）。
1
Pod（容器组）是 k8s 集群上的最基本的单元。当我们在 k8s 上创建 Deployment 时，会在集群上创建包含容器的 Pod (而不是直接创建容器)。每个Pod都与运行它的 worker 节点（Node）绑定，并保持在那里直到终止或被删除。如果节点（Node）发生故障，则会在群集中的其他可用节点（Node）上运行相同的 Pod（从同样的镜像创建 Container，使用同样的配置，IP 地址不同，Pod 名字不同）。
1
2
Pod 是一组容器（可包含一个或多个应用程序容器），以及共享存储（卷 Volumes）、IP 地址和有关如何运行容器的信息。
如果多个容器紧密耦合并且需要共享磁盘等资源，则他们应该被部署在同一个Pod（容器组）中。
1
2
3
4
Pod（容器组）总是在 Node（节点） 上运行。Node（节点）是 kubernetes 集群中的计算机，可以是虚拟机或物理机。每个 Node（节点）都由 master 管理。一个 Node（节点）可以有多个Pod（容器组），kubernetes master 会根据每个 Node（节点）上可用资源的情况，自动调度 Pod（容器组）到最佳的 Node（节点）上。
每个 Kubernetes Node（节点）至少运行：
Kubelet，负责 master 节点和 worker 节点之间通信的进程；管理 Pod（容器组）和 Pod（容器组）内运行的 Container（容器）。
容器运行环境（如Docker）负责下载镜像、创建和运行容器等。
1
Worker节点是k8s中的工作计算机，可能是VM或物理计算机，具体取决于群集。多个Pod可以在一个节点上运行。

kubectl get

1
2
3
4
5
6
7
kubectl get - 显示资源列表
#获取类型为Deployment的资源列表
kubectl get deployments
#获取类型为Pod的资源列表
kubectl get pods
#获取类型为Node的资源列表
kubectl get nodes

名称空间

1
2
3
4
5
6
7
8
在命令后增加 -A 或 --all-namespaces 可查看所有 名称空间中 的对象，使用参数 -n 可查看指定名称空间的对象，例如
# 查看所有名称空间的 Deployment
kubectl get deployments -A
kubectl get deployments --all-namespaces
# 查看 kube-system 名称空间的 Deployment
kubectl get deployments -n kube-system
    
并非所有对象都在名称空间里

kubectl describe

1
2
3
4
5
6
 - 显示有关资源的详细信息
# kubectl describe 资源类型 资源名称
#查看名称为nginx-XXXXXX的Pod的信息
kubectl describe pod nginx-XXXXXX	
#查看名称为nginx的Deployment的信息
kubectl describe deployment nginx

kubectl logs

1
2
3
4
5
kubectl logs - 查看pod中的容器的打印日志（和命令docker logs 类似）
# kubectl logs Pod名称
#查看名称为nginx-pod-XXXXXXX的Pod内的容器打印的日志
#本案例中的 nginx-pod 没有输出日志，所以您看到的结果是空的
kubectl logs -f nginx-pod-XXXXXXX

kubectl exec

1
2
3
4
kubectl exec - 在pod中的容器环境内执行命令(和命令docker exec 类似)
# kubectl exec Pod名称 操作命令
# 在名称为nginx-pod-xxxxxx的Pod中运行bash
kubectl exec -it nginx-pod-xxxxxx /bin/bash

Kubernetes Service（服务）

1
2
3
4
5
6
7
8
9
10
事实上，Pod（容器组）有自己的 生命周期 (opens new window)。当 worker node（节点）故障时，节点上运行的 Pod（容器组）也会消失。然后，Deployment (opens new window)可以通过创建新的 Pod（容器组）来动态地将群集调整回原来的状态，以使应用程序保持运行。
举个例子，假设有一个图像处理后端程序，具有 3 个运行时副本。这 3 个副本是可以替换的（无状态应用），即使 Pod（容器组）消失并被重新创建，或者副本数由 3 增加到 5，前端系统也无需关注后端副本的变化。由于 Kubernetes 集群中每个 Pod（容器组）都有一个唯一的 IP 地址（即使是同一个 Node 上的不同 Pod），我们需要一种机制，为前端系统屏蔽后端系统的 Pod（容器组）在销毁、创建过程中所带来的 IP 地址的变化。
Kubernetes 中的 Service（服务） 提供了这样的一个抽象层，它选择具备某些特征的 Pod（容器组）并为它们定义一个访问方式。Service（服务）使 Pod（容器组）之间的相互依赖解耦（原本从一个 Pod 中访问另外一个 Pod，需要知道对方的 IP 地址）。一个 Service（服务）选定哪些 Pod（容器组） 通常由 LabelSelector(标签选择器) 来决定。
在创建Service的时候，通过设置配置文件中的 spec.type 字段的值，可以以不同方式向外部暴露应用程序：
ClusterIP（默认）
在群集中的内部IP上公布服务，这种方式的 Service（服务）只在集群内部可以访问到
NodePort
使用 NAT 在集群中每个的同一端口上公布服务。这种方式下，可以通过访问集群中任意节点+端口号的方式访问服务 <NodeIP>:<NodePort>。此时 ClusterIP 的访问方式仍然可用。
LoadBalancer
在云环境中（需要云供应商可以支持）创建一个集群外部的负载均衡器，并为使用该负载均衡器的 IP 地址作为服务的访问地址。此时 ClusterIP 和 NodePort 的访问方式仍然可用。

服务和标签

1
2
3
4
5
TIP
Service是一个抽象层，它通过 LabelSelector 选择了一组 Pod（容器组），把这些 Pod 的指定端口公布到到集群外部，并支持负载均衡和服务发现。
公布 Pod 的端口以使其可访问
在多个 Pod 间实现负载均衡
使用 Label 和 LabelSelector
1
2
3
4
5
Service 将外部请求路由到一组 Pod 中，它提供了一个抽象层，使得 Kubernetes 可以在不影响服务调用者的情况下，动态调度容器组（在容器组失效后重新创建容器组，增加或者减少同一个 Deployment 对应容器组的数量等）。
Service使用 Labels、LabelSelector(标签和选择器) (opens new window)匹配一组 Pod。Labels（标签）是附加到 Kubernetes 对象的键/值对，其用途有多种：
将 Kubernetes 对象（Node、Deployment、Pod、Service等）指派用于开发环境、测试环境或生产环境
嵌入版本标签，使用标签区别不同应用软件版本
使用标签对 Kubernetes 对象进行分类

命令

kubectl get nodes

1
2
3
4
5
6
7
8
9
10
检查节点状态
kubectl get nodes
NAME           STATUS                     ROLES    AGE    VERSION
10.226.0.10    Ready                      <none>   196d   v1.28.3-tke.18
10.226.0.15    Ready                      <none>   190d   v1.28.3-tke.18
10.226.16.2    Ready                      <none>   190d   v1.28.3-tke.18
10.226.16.4    Ready                      <none>   190d   v1.28.3-tke.18
10.226.18.16   Ready                      <none>   58d    v1.28.3-tke.22
10.226.18.3    Ready                      <none>   58d    v1.28.3-tke.22
10.226.2.70    Ready,SchedulingDisabled   <none>   43d    v1.28.3-tke.22

kubectl config view

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
检查 kubectl 使用的配置文件。默认路径是 ~/.kube/config。通过以下命令查看当前使用的配置
kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.226.0.33
  name: cls-ps6hub9f
contexts:
- context:
    cluster: cls-ps6hub9f
    user: "100038521123"
  name: cls-ps6hub9f-100038521123-context-default
- context:
    cluster: cls-ps6hub9f
    namespace: dagster-app-test
    user: "100038521123"
  name: dagster-app-context
current-context: dagster-app-context
kind: Config
preferences: {}
users:
- name: "100038521123"
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED

kubectl get svc -n namespace

1
2
3
# 查看所有 Service
~ kubectl get svc dagster-dagster-webserver -n dagster-app-test
dagster-dagster-webserver   ClusterIP   192.168.92.189   <none>        80/TCP    78d

kubectl get svc xxxx -n namespace -o yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
执行以下命令，查看 Service 的具体端口配置
~ kubectl get svc dagster-dagster-webserver -n dagster-app-test -o yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    meta.helm.sh/release-name: dagster
    meta.helm.sh/release-namespace: dagster-app-test
    service.cloud.tencent.com/sync-begin-time: "2025-12-23T11:12:33+08:00"
    service.cloud.tencent.com/sync-end-time: "2025-12-23T11:12:33+08:00"
  creationTimestamp: "2025-12-23T03:12:33Z"
  labels:
    app.kubernetes.io/instance: dagster
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: dagster
    app.kubernetes.io/version: dev
    component: dagster-webserver
    helm.sh/chart: dagster-0.0.1-dev-git
  name: dagster-dagster-webserver
  namespace: dagster-app-test
  resourceVersion: "12770797908"
  uid: 2e475843-19ba-40f3-88b5-31642d159049
spec:
  clusterIP: 192.168.92.189
  clusterIPs:
  - 192.168.92.189
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app.kubernetes.io/instance: dagster
    app.kubernetes.io/name: dagster
    component: dagster-webserver
  sessionAffinity: None
  type: ClusterIP
status:
  conditions:
  - lastTransitionTime: "2025-12-23T03:12:33Z"
    message: ""
    reason: Success
    status: "True"
    type: Ready
  loadBalancer: {}
1
2
3
4
查询 Service 入口（推荐）
Dagster 部署时通常会创建一个 Service 来对外暴露服务。你需要找到这个 Service 的访问地址：
# 查看所有 Service
kubectl get svc -n <namespace>

kubectl get svc xxxx -n namespace -o wide

1
2
3
4
5
6
7
8
9
10
# 查看 Service 详情（找到 External-IP 或 ClusterIP）
kubectl get svc dagster-webserver -n <namespace> -o wide
~ kubectl get svc dagster-dagster-webserver -n dagster-app -o wide
NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE   SELECTOR
dagster-dagster-webserver   ClusterIP   192.168.79.21   <none>        80/TCP    33d   app.kubernetes.io/instance=dagster,app.kubernetes.io/name=dagster,component=dagster-webserver
Service 可能有几种类型：
Service 类型	访问方式	适用场景
LoadBalancer	有公网 IP（External-IP）	公网访问
ClusterIP	集群内 IP（10.x.x.x）	仅集群内访问
NodePort	节点 IP + 端口	通过节点 IP 访问