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

理解使用Kubernetes对象

news 来源：原创 2025/5/1 8:41:16

Kubernetes对象

文章目录

Kubernetes对象
@[toc]
一、什么是Kubernetes对象
二、Kubernetes对象的规约和状态
三、描述Kubernetes对象
四、Kubernetes对象管理方法
五、对象的名称和UID
六、标签和注解
七、名称空间
八、创建Kubernetes对象
1.使用指令式命令创建Deployment
2.使用指令式对象配置创建Deployment
3.使用声明式对象配置创建Deployment

九、操作对象的标签
1.为对象添加标签
2.修改对象的标签
3.删除对象标签
4.操作具有指定标签的对象

十、操作名称空间

一、什么是Kubernetes对象

Kubernetes 对象是 Kubernetes 系统中的持久化实体，Kubernetes 使用这些实体来表示整个集群的状态。具体而言，它们描述了如下信息：

哪些容器化应用正在运行（以及在哪些节点上运行）；
可以被应用使用的资源；
关于应用运行时行为的策略，比如重启策略、升级策略以及容错策略。

Kubernetes 对象是一种“意向表达（Record of Intent）”，一旦创建该对象，Kubernetes 系统将不断工作以确保该对象存在。通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群所谓的期望状态（Desired State）。

操作 Kubernetes 对象，无论是创建、修改或者删除，都需要使用 Kubernetes API。例如，使用 kubectl 命令行接口时，CLI 会调用必要的 Kubernetes API；也可以在程序中使用客户端库，来直接调用 Kubernetes API 。

大多数 Kubernetes 对象包含两个嵌套的对象字段，负责管理对象的配置：对象规约（Spec）和对象状态（Status）。对象规约在创建时候设置其内容，描述对象所具有的特征，即期望状态；而对象状态由 Kubernetes 系统和组件设置并更新。控制平面一直监控对象的实际状态，以使之与期望状态相匹配。

Kubernetes 对象按照功能可以分为几个大类，包括工作负载类、负载均衡类、配置和存储类、集群管理类等等。每个类中又有多种对象，例如工作负载类包含 Pod、Deployment、Statefulset、Daemonset、Job 等。

在这里插入图片描述

这张图展示了一个基于Kubernetes的容器化应用架构及其相关组件之间的关系。图的中心是“Pod”，它是Kubernetes中最小的可部署和可管理的计算单元，包含一个或多个紧密相关的容器。

以下是图中各个组件及其关系的总结：

与Pod相关的组件：

Job和CronJob：这些组件可以使用Pod来运行批处理任务或定时任务。
StatefulSet：用于管理有状态应用的Pod，确保Pod的顺序和唯一性。
DaemonSet：确保在每个节点上都运行一个Pod副本，常用于运行系统级别的守护进程。
Deployment：用于管理无状态应用的Pod，提供滚动更新和回滚功能。
Ingress和Service：用于对外提供服务，将外部流量路由到Pod。

与配置和存储相关的组件：

ConfigMap：用于向Pod提供配置信息，例如环境变量或配置文件。
Secret：类似于ConfigMap，但用于存储敏感信息，如密码和令牌。
PVC（PersistentVolumeClaim）和PV（PersistentVolume）：PVC用于请求持久化存储，而PV则是实际的存储资源，Pod可以通过PVC使用持久化存储。

总结：

Pod是核心，通过不同的控制器（如Job、CronJob、StatefulSet、DaemonSet、Deployment）来运行应用。
Ingress和Service用于将外部流量引入Pod，对外提供服务。
ConfigMap和Secret用于向Pod提供配置和敏感信息。
PVC和PV用于提供持久化存储，供Pod使用。

这种架构展示了Kubernetes中如何通过不同的组件来管理和运行容器化应用，确保应用的可扩展性、可靠性和安全性。

二、Kubernetes对象的规约和状态

在Kubernetes系统中，对象规约（Spec）和对象状态（Status）是管理Kubernetes对象配置的两个重要嵌套字段。

对象规约（Spec）

对象规约是必需的字段，它描述了对象的期望状态，即用户希望对象所具有的特征。当创建Kubernetes对象时，必须提供对象的规约，同时还要提供关于对象的一些基本信息，如名称等。例如，在创建Kubernetes中的Deployment对象来表示运行在集群中的应用时，需要设置Deployment的spec，指定该应用需要有3个副本运行，这就是对该对象期望状态的一种描述。

对象状态（Status）

对象状态描述了对象的当前状态，它由Kubernetes系统和组件负责设置并更新。Kubernetes控制平面会持续监控和管理对象的实际状态，使其与期望状态相匹配。还以Deployment对象为例，当按照spec启动3个应用实例后，如果其中有的实例失败了，这就发生了状态变更，Kubernetes系统会通过执行修正操作，如启动一个新的实例来替换，以响应规约和状态间的不一致。

三、描述Kubernetes对象

Kubernetes对象是Kubernetes系统中的持久化实体，用于表示整个集群的状态，描述了如哪些容器化应用在运行（以及在哪些节点上）、可被应用使用的资源以及应用运行时表现的策略（如重启、升级、容错策略）等信息，代表了用户对集群工作负载的期望状态。

描述Kubernetes对象时：

关键字段：
- apiVersion：创建对象时使用的Kubernetes API版本，不同的Kubernetes版本支持不同的API版本，可通过kubectl api - versions查看当前集群支持的版本。
- kind：要创建的对象类型，例如Deployment、Pod、Service等。
- metadata：用于唯一确定该对象的元数据，包括name字符串（在同类资源中具有唯一性）、UID（在整个集群中唯一）和可选的namespace（若为空，默认值为default）。通过namespace可在一个Kubernetes集群里虚拟出多个逻辑上独立的集群，不同namespace中可存在同名资源对象。
- spec：描述对该对象的期望状态，不同类型的Kubernetes对象，其spec对象的格式不同，包含特定于该对象的嵌套字段，例如Deployment的spec可指定应用副本数，Pod的spec可指定容器镜像等。
配置文件格式：通常使用YAML格式的文件来描述Kubernetes对象，相较于JSON格式，YAML具有更好的可读性。使用kubectl创建对象时，一般将相关信息编辑到YAML格式的manifest文件中供其使用。kubectl在发起API请求时，会将manifest文件中的信息转换为JSON格式。
创建方式：可以直接使用Kubernetes API创建对象，也可使用kubectl将编写好的YAML文件的资源清单发送给Kubernetes API来创建对象。例如通过kubectl apply -f <yaml文件路径>命令，让kubectl将YAML文件的资源清单发送给Kubernetes API，进而创建对象。

四、Kubernetes对象管理方法

Kubernetes对象的管理方法主要有以下三种，每种方法各有优劣，适用于不同场景：

指令式命令：
- 操作方式：用户直接对集群中的活动对象进行操作，通过kubectl指令参数或标志来传递操作。例如创建一个Deployment对象来运行nginx容器，可使用命令kubectl create deployment nginx --image nginx 。
- 适用场景：启动或运行集群中的一次性任务时推荐使用。
- 优点：命令简单，易学且易于记忆；只需一个步骤即可对集群进行更改。
- 缺点：命令没有集成更改审批；不提供与更改关联的审计跟踪功能；除了实时对象外，不提供记录源；不提供模板用来创建新对象。
指令式对象配置：
- 操作方式：kubectl命令指定对象操作（如create、replace等）、可选标志和一个或多个文件名，指定的文件必须包含YAML或JSON格式的完整的对象定义。例如，在配置文件nginx.yaml中定义要创建的对象，使用kubectl create -f nginx.yaml命令创建；通过kubectl replace -f nginx.yaml覆盖实时配置来更新配置文件中定义的对象。
- 适用场景：适合项目生产环境。
- 优点：对象配置可以存储在源代码控制系统中，如Git；可与流程集成，例如在推送和审计跟踪之前审查更改；提供了模板用来创建新的对象。
- 缺点：需要对对象架构有基本的了解；需要编写YAML文件的额外步骤；对文件（而不是目录）效果最好；对活动对象的更新必须反映在配置文件中，否则在下次替换时它们将丢失。
声明式对象配置：
- 操作方式：用户对本地存储的对象配置文件进行操作，但不定义要对文件执行的操作，kubectl会自动检测每个对象的创建、更新和删除操作，允许在目录上工作，根据目录中配置文件对不同的对象执行不同的操作。例如，处理configs目录中的所有对象配置文件，可先用kubectl diff -f configs/查看要进行的更改，然后再用kubectl apply -f configs/应用更改。
- 适用场景：适用于项目生产环境，尤其是需要对多个对象配置文件进行统一管理的场景。
- 优点：直接对活动对象所做的更改将被保留，即使它们没有合并回配置文件中；更好地支持对目录进行操作和自动检测每个对象的操作类型（创建、更新、删除）。
- 缺点：更难调试和理解意外结果；使用diff的部分更新会创建复杂的合并和修补操作。

在实际使用中，应根据具体需求、团队协作方式和环境特点，选择合适的管理方法。同时，应避免对同一个对象采用不同方法来管理，以免导致无法预料的行为。

五、对象的名称和UID

在Kubernetes中，对象的名称（Name）和唯一标识符（UID）是标识对象的重要属性：

名称（Name）

：是用户创建Kubernetes对象时必须指定的字符串，用于在资源URL中定位对象，例如“/api/v1/pods/some - name” 。在同一个命名空间下，同种类型的对象，其名称必须唯一，但不同类型的对象可以重名，如在同一个命名空间中可以存在名为myapp - 1234的Pod和Deployment 。
- 命名约束
  
  ：按照惯例，Kubernetes资源的名称一般有253个字符的最大长度限制，并由小写字母、数字、“ - ”和“.”组成。不过，不同的资源类型可能还会有更具体的限制，常见的有以下几种约束：
  - DNS子域名：大多数资源类型要求名称能用作RFC 1123中定义的DNS子域名，即最多包含253个字符；仅包含小写字母、数字、“ - ”或“.”；以字母数字字符开头和结尾。
  - DNS标签名称：某些资源类型要求名称遵循RFC 1123中定义的DNS标签标准，最多包含63个字符；仅包含小写字母、数字或“ - ”；以字母数字字符开头和结尾。此外，RFC 1035标签标准与之类似，但RFC 1035标签只能以小写字母字符开头。
  - 路径段名称：有些资源类型要求名称能安全地编码为一个路径段，名称不能是“.”或“…”，且不得包含“/”或“%” 。
唯一标识符（UID）：是由Kubernetes系统生成的字符串，用于唯一标识对象。在Kubernetes集群的整个生命周期内，创建的每个对象都会被分配一个独特的UID，旨在区分相似实体的历史事件。Kubernetes UID是通用唯一标识符（也称为UUID），符合ISO/IEC 9834 - 8和ITU - T X.667标准。

六、标签和注解

在Kubernetes中，标签（Labels）和注解（Annotations）是用于管理和组织对象的重要概念，它们有不同的用途和特点：

标签（Labels）

：是附加到Kubernetes对象（如Pods、Nodes、Deployments等）上的键值对，用于标识和选择对象，对对象进行逻辑分组，方便用户管理资源。
- 作用
  
  ：
  - 资源分组与管理：通过给具有相似功能或属性的对象添加相同标签，实现资源的分类管理。例如，将所有用于生产环境的Pod打上“environment=production”标签，便于统一管理和操作。
  - 服务发现与关联：Service通过标签选择器（Selector）关联到对应的Pod，实现服务发现和负载均衡。如定义Service时，通过selector指定关联具有“app=nginx”标签的Pod 。
  - 控制Pod调度：可以给节点（Node）添加标签，如“disktype=ssd”，同时在Pod的配置中使用nodeSelector指定要调度到具有特定标签的节点上，实现Pod的定向调度。
- 语法：标签的键可分为可选前缀和名称，由斜杠分开。若定义前缀，必须是不超过253个字符的DNS子域名；名称部分必须有，最大长度为63个字符，且以字母数字字符开头和结束，允许中间使用横杠（-）、下划线（_）和点（.）。标签的值也是最长63个字符的字符串，规则与键相同。
- 操作命令
  
  ：
  - 列出标签：kubectl get po --show-labels可列出pods的标签。
  - 查看具体标签：kubectl get po -L label_key1, label_key2 查看具体标签。
  - 添加标签：kubectl label po po_name label_key=label_value 为指定pod添加标签。
  - 修改标签：kubectl label po po_name label_key=label_new_value --overwrite，需加--overwrite参数覆盖原有标签值。
注解（Annotations）

：也是键值对，用于添加任意非标识性的元数据到对象上，不用于识别和选择对象，只是附加信息，方便工具和库检索使用。
- 用途
  
  ：
  - 构建与发布信息记录：记录构建号码、版本号、Git commit信息等，如“example.com/build - version: “v1.2.3” ，example.com/git - commit: “a1b2c3d”” 。
  - 日志与监控配置：记录日志收集、监控系统的配置信息，例如“prometheus.io/scrape: “true” ，prometheus.io/port: “8080”” 。
  - 程序配置与指令：为调度器或运维工具提供指令，标记资源以进行特定的资源管理操作。
  - 其他信息记录：还可记录声明式配置层用到的状态信息、负责人联系方式、第三方工具所需信息等。
- 格式
  
  ：
  - 键必须是DNS标签格式的字符串，不能以“kubectl.kubernetes.io/”开头（这是Kubernetes预留的），长度不能超过63个字符。
  - 键和值都必须是字符串。
- 操作命令
  
  ：
  - 添加注解：kubectl annotate pod my - pod - n my - namespace example.com/annotation = "my-value"，可给指定命名空间下的Pod添加注解。
  - 删除注解：kubectl annotate pod my - pod - n my - namespace example.com/annotation-，在键后添加“-”做删除操作。
  - 更新注解：kubectl annotate pod my - pod - n my - namespace example.com/annotation = "my-new-value" -- overwrite，需添加“–overwrite”参数用新值覆盖旧值。

七、名称空间

在Kubernetes中，名称空间（Namespace）提供一种机制，将同一集群中的资源划分为相互隔离的组，类似虚拟化集群，在逻辑上彼此隔离，为用户和团队在组织、安全及性能方面提供帮助。

作用：
- 避免命名冲突：同一名称空间内的资源名称要唯一，但跨名称空间时没有这个要求。例如在不同名称空间中可以有同名的Deployment或Service等资源。
- 资源隔离与管理：适用于存在很多跨多个团队或项目的用户的场景，为不同团队、项目或环境（如开发、测试、生产）提供独立的运行环境，实现资源的逻辑隔离。不同名称空间可设置不同的资源配额，限制该空间内资源的使用，如CPU、内存、存储等，还可利用RBAC（基于角色的访问控制）对不同名称空间设置不同的访问权限。
- 便于资源分类：名称空间为名称提供了一个范围，资源的名称在名称空间内唯一，方便对资源进行分类和筛选。例如可按业务模块或功能划分名称空间，将相关资源归到同一名称空间下管理。
初始名称空间：

Kubernetes启动时会创建四个初始名称空间：
- default：便于用户无需创建新的名称空间即可开始使用新集群，若无特别指定，一些对象会默认创建在此名称空间，但对于生产集群，不建议使用它，而应创建其他名称空间。
- kube - node - lease：包含用于与各个节点关联的Lease（租约）对象，节点租约允许kubelet发送心跳，使控制面能够检测到节点故障。
- kube - public：所有客户端（包括未经身份验证的客户端）都可以读取该名称空间，主要预留为集群使用，以便某些资源需要在整个集群中可见可读，其公共属性只是一种约定而非要求。
- kube - system：用于Kubernetes系统创建的对象。
使用方法：
- 查看名称空间：使用kubectl get namespace或kubectl get ns命令可列出集群中现存的名称空间。
- 创建名称空间：
  - 命令行方式：如kubectl create namespace test 或 kubectl create ns test 。
  - YAML文件方式：编写YAML文件定义名称空间，如：

apiVersion: v1  
kind: Namespace  
metadata:  
  name: test  
  labels:  
    name: test

然后执行kubectl apply -f <文件名>创建。
- 为请求设置名称空间：使用--namespace参数，例如kubectl run nginx --image=nginx --namespace=<名字空间名称> ，kubectl get pods --namespace=<名字空间名称> 。
- 设置名称空间偏好：可通过kubectl config set - context --current --namespace=<名字空间名称>永久保存名称空间，用于对应上下文中所有后续kubectl命令，还可通过kubectl config view | grep namespace:验证设置。
- 名称空间与DNS：创建Service时，会创建对应的DNS条目，格式为<service - name>.<namespace - name>.svc.cluster.local。容器仅使用<service - name>时，会解析到本地名称空间的服务，若要跨名称空间访问，则需使用完整合格的域名（FQDN）。
- 删除名称空间：使用kubectl delete namespace <名称空间名称> 或 kubectl delete ns <名称空间名称>删除，删除名称空间时需谨慎，因为其内部所有对象也会一并被删除。

并非所有Kubernetes资源都在名称空间中，大部分资源（如Pods、Services、Deployments等）存在于名称空间，但像Nodes、PersistentVolumes、StorageClass等集群范围的对象不属于任何名称空间。可通过kubectl api - resources --namespaced=true查看在名称空间里的资源，通过kubectl api - resources --namespaced=false查看不在名称空间里的资源。

八、创建Kubernetes对象

1.使用指令式命令创建Deployment

[root@master ~]# kubectl create deployment nginx --image nginx:1.14.2	//基于nginx镜像创建deployment
deployment.apps/nginx created
[root@master ~]# kubectl get deployment	//查看该deployment是否创建成功，可以发现存在了一个副本
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   0/1     1            0           14s
[root@master ~]# kubectl get pod		//查看pod进行验证
NAME                     READY   STATUS    RESTARTS   AGE
nginx-5477b4ff8c-cp79d   0/1     Pending   0          24s
[root@master ~]# kubectl delete deployment nginx		//删除改对象
deployment.apps "nginx" deleted
[root@master ~]# kubectl get deployment		//再次验证
No resources found in default namespace.
[root@master ~]# kubectl get pod
No resources found in default namespace.
[root@master ~]#

2.使用指令式对象配置创建Deployment

采用这种方法需要创建一个用于定义Deployment的YAML配置文件，如下

[root@master ~]# vi nginx-deployment.yaml
[root@master ~]# cat nginx-deployment.yaml 
# 必需字段，声明对象使用的API版本
apiVersion: apps/v1
# 必需字段，声明要创建的对象的类别
kind: Deployment
# 必需字段，定义对象的元信息，包括对象名称、使用的标签等
metadata:
  name: nginx-deployment
# 必需字段，声明对象的期望状态，如使用的镜像、副本数等
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3    # 运行3个与该模板匹配的Pod
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        
[root@master ~]# kubectl create -f nginx-deployment.yaml 	//基于yaml配置文件创建Deployment
deployment.apps/nginx-deployment created
[root@master ~]# kubectl get deployment		//按照yaml文件的定义，创建了3个副本的deployment和pod
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/3     3            0           19s
[root@master ~]# kubectl get pod		
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-86dcfdf4c6-ftk57   0/1     Pending   0          31s
nginx-deployment-86dcfdf4c6-rzk9d   0/1     Pending   0          31s
nginx-deployment-86dcfdf4c6-wpstc   0/1     Pending   0          31s
[root@master ~]# kubectl delete -f nginx-deployment.yaml 	//基于配置文件删除deployment
deployment.apps "nginx-deployment" deleted
[root@master ~]# kubectl get deployment
No resources found in default namespace.
[root@master ~]# kubectl get pod
No resources found in default namespace.

3.使用声明式对象配置创建Deployment

声明式对象配置也需要YAML配置文件，可沿用上一个yaml文件，仅对该文件执行声明式对象配置操作

[root@master ~]# vi nginx-deployment.yaml 
[root@master ~]# cat nginx-deployment.yaml 		//修改配置文件参数，运行4个副本
# 必需字段，声明对象使用的API版本
apiVersion: apps/v1
# 必需字段，声明要创建的对象的类别
kind: Deployment
# 必需字段，定义对象的元信息，包括对象名称、使用的标签等
metadata:
  name: nginx-deployment
# 必需字段，声明对象的期望状态，如使用的镜像、副本数等
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 4    # 运行4个与该模板匹配的Pod
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
[root@master ~]# kubectl apply -f nginx-deployment.yaml 	//应用修改后的配置
deployment.apps/nginx-deployment created
[root@master ~]# kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/4     4            0           9s
[root@master ~]# kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-86dcfdf4c6-btns5   0/1     Pending   0          18s
nginx-deployment-86dcfdf4c6-fmx44   0/1     Pending   0          18s
nginx-deployment-86dcfdf4c6-hmjml   0/1     Pending   0          18s
nginx-deployment-86dcfdf4c6-x76s4   0/1     Pending   0          18s
[root@master ~]# kubectl delete -f nginx-deployment.yaml 
deployment.apps "nginx-deployment" deleted
[root@master ~]# kubectl get deployment
No resources found in default namespace.
[root@master ~]# kubectl get pod
No resources found in default namespace.

kubectl create和kubectl apply命令的区别在于前者只能创建对象，而后者可以创建和更新对象。如果对象已经启动并运行，并且在yaml配置文件中做了更改，此时使用kubectl create命令将失败，但使用kubectl apply命令则会更新对象。kubectl apply只能创建或更新对象，不能删除对象，删除对象使用kubectl delete。

九、操作对象的标签

1.为对象添加标签

[root@master ~]# kubectl run nginx-a --image=nginx -l app=nginx	//创建名为nginx-a的Pod并为其添加标签app=nginx
pod/nginx-a created
[root@master ~]# vi nginx-label.yaml 	//编写Pod配置文件nginx-label.yaml
[root@master ~]# cat nginx-label.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-b
  labels:                 # 为Pod设置两个Label    
    app: nginx    
    env: prod
spec:
  containers:
  - name: nginx          
    image: nginx
//此配置文件定义名为nginx-b的Pod并为其添加两个标签app=nginx、env=pod。
[root@master ~]# kubectl create -f nginx-label.yaml 	//基于配置文件创建pod
pod/nginx-b created
[root@master ~]# kubectl get pod --show-labels	//添加标签后，查看pod的标签带上选项，可以发现标签
NAME      READY   STATUS    RESTARTS   AGE     LABELS
nginx-a   0/1     Pending   0          5m36s   app=nginx
nginx-b   0/1     Pending   0          15s     app=nginx,env=prod
[root@master ~]# kubectl label pod nginx-a env=test version=0.9	//对于现有的pod，可以直接使用kubectl label添加标签
pod/nginx-a labeled
[root@master ~]# kubectl get pod -L env,version		//可以通过-L选项来查询指定键的标签
NAME      READY   STATUS    RESTARTS   AGE     ENV    VERSION
nginx-a   0/1     Pending   0          6m22s   test   0.9
nginx-b   0/1     Pending   0          61s     prod

2.修改对象的标签

对于对象的现有标签，使用kubectl label命令加上–overwrite选项即可修改

[root@master ~]# kubectl label pod nginx-a env=debug --overwrite
pod/nginx-a labeled
[root@master ~]# kubectl get pod nginx-a --show-labels
NAME      READY   STATUS    RESTARTS   AGE   LABELS
nginx-a   0/1     Pending   0          11m   app=nginx,env=debug,version=0.9

3.删除对象标签

使用kubectl label命令时在标签键后面加一个减号即可删除对象的指定标签

[root@master ~]# kubectl label pod nginx-a version-
pod/nginx-a unlabeled
[root@master ~]# kubectl get pod nginx-a --show-labels
NAME      READY   STATUS    RESTARTS   AGE   LABELS
nginx-a   0/1     Pending   0          16m   app=nginx,env=debug

4.操作具有指定标签的对象

可以通过-l选项来筛选具有指定标签的对象

[root@master ~]# kubectl delete pod -l app=nginx
pod "nginx-a" deleted
pod "nginx-b" deleted
[root@master ~]# kubectl get pod 
No resources found in default namespace.
[root@master ~]#

十、操作名称空间

[root@master ~]# kubectl get namespaces	//查看集群中所有名称空间列表
NAME              STATUS   AGE
default           Active   54m		//默认名称空间
kube-node-lease   Active   54m		//用于与各节点相关的租约对象
kube-public       Active   54m		//主要由集群使用
kube-system       Active   54m		//系统创建对象所用的名称空间
[root@master ~]# vi test-ns.yaml	//可以通过编写配置文件创建名称空间
[root@master ~]# cat test-ns.yaml 
apiVersion: v1 
kind: Namespace 
metadata: 
  name: test-ns

[root@master ~]# kubectl create -f test-ns.yaml 		//执行基于yaml文件创建名称空间
namespace/test-ns created
[root@master ~]# kubectl create namespace test-ns		//也可以通过命令直接创建名称空间
Error from server (AlreadyExists): namespaces "test-ns" already exists
[root@master ~]# kubectl get namespaces
NAME              STATUS   AGE
default           Active   56m
kube-node-lease   Active   56m
kube-public       Active   56m
kube-system       Active   56m
test-ns           Active   37s

//如果不明确指定，将操作默认的名称空间default。需要在特定的名称空间操作时，可以在kubectl命令中通过-n(或--namespace)选项指定。
[root@master ~]# kubectl create -f nginx-deployment.yaml -n test-ns	//基于nginx的yaml文件在test-ns中创建
deployment.apps/nginx-deployment created
[root@master ~]# kubectl get deployment	//查看该deployment及其关联的pod
No resources found in default namespace.
[root@master ~]# kubectl get deployment -n test-ns
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/4     4            0           39s
[root@master ~]# kubectl delete -f nginx-deployment.yaml -n test-ns		//删除也需要指定名称空间
deployment.apps "nginx-deployment" deleted