k8s中资源的介绍及标准资源namespaces实践

第1章 k8s中的资源(resources)介绍

1.1 k8s中资源(resouces)的分类

我们用 kubectl api-resources 可看到其 kubernetes 中的所有资源（当然kubectl所用的kubeconfig所承载的帐户得具备超级权限）。

root@master01:~# kubectl api-resources | head -4   # 只取了前4行
NAME                 SHORTNAMES  APIVERSION NAMESPACED   KIND
bindings                         v1         true         Binding
componentstatuses    cs          v1         false        ComponentStatus
configmaps           cm          v1         true         ConfigMap

这些资源可分为标准资源（安装好kubernetes后就有）、非标准资源（扩展kubernetes后才有），我们可用 kubectl get crd 看到有哪些非标准资源，其结果 NAME 字段对应值以点号"."分隔的第一列就是其资源的name。

root@master01:~# kubectl get crd | head -4        # 只取了前4行
NAME                                         CREATED AT
analysisruns.argoproj.io                     2025-04-23T02:32:30Z
analysistemplates.argoproj.io                2025-04-23T02:32:30Z
applications.argoproj.io                     2025-04-19T17:46:46Z
root@master01:~#
root@master01:~# kubectl api-resources | grep -w applications
applications       app,apps     argoproj.io/v1alpha1     true   Application

1.2 k8s中资源(resources)的级别

不管是标准资源、非标准资源，它们要么是namespace级别、非namespace级别（也称cluster级别）。可从 kubectl api-resources 结果的 NAMESPACE字段中看到，也可用 kubectl api-resources --namespaced=true/false 列出所有namespace级别或非namespace级别的资源

## kubectl工具看某个资源属于什么级别
root@master01:~# kubectl api-resources  | grep -w Namespace 
namespaces   ns   v1    false        Namespace    # <== false表示 非namespace级别
root@master01:~# 
root@master01:~# kubectl api-resources | grep -w Pod
pods        po    v1    true         Pod          # <== true表示 namespace级别## kuectl工具列出所有namespace级别或所有非namespace级别的资源
kubectl api-resources --namespaced=true 
kubectl api-resources --namespaced=false

注意：namespace级别的资源其实例化出来的对象得放在已存在的ns资源对象(由Kind为Namespace的资源namespaces实例化出来的)中。

1.3 k8s中资源(resources)的API规范

我们可用以下方法获取标准资源、非标准资源类的某资源其API规范中有哪些一级字段。

## 参考
root@master01:~# kubectl api-resources | head -1
NAME        SHORTNAMES       APIVERSION     NAMESPACED      KIND## 规范的
# <== 格式
kubectl explain --api-version='<APIVERSION>' <KIND># <== 例如
kubectl explain --api-version='v1' Pod## 简化的
# <== 格式
kubectl explain  <KIND># <== 例如
kubectl explain  Pod

标准资源、非标准资源其API规范一定会有apiVersion、kind、metadata这三个一级字段，在编写其对象的manifests是得写上。
大多数资源其API规范中有spec这个一级字段，用于定义期望状态，在编写其对象的manifests时得写上。
标准资源、非标准资源的API规范一定会有status这个一级字段，在编写其对象的manifests时不用写。当对象创建后其status是由其spec转换而来（期望状态转换成实际状态）。
我们也可以查看某资源其API规范中一级字段下有哪些二级字段，二级字段有哪些三级字段。如下所示。

## 规范的
kubectl explain --api-version='<APIVERSION>' <KIND>                       # 可看到有哪些一级字段
kubectl explain --api-version='<APIVERSION>' <KIND>.某一级字段             # 可看到有哪些二级字段
kubectl explain --api-version='<APIVERSION>' <KIND>.某一级字段.某二级字段   # 可看到有哪些三级字段 ## 简化的
kubectl explain                              <KIND>                       # 可看到有哪些一级字段
kubectl explain                              <KIND>.某一级字段             # 可看到有哪些二级字段
kubectl explain                              <KIND>.某一级字段.某二级字段   # 可看到有哪些三级字段 

前面提到

namespace级别的资源其实例化出来的对象得放在某ns资源对象(由Kind为Namespace的资源namespaces实例化出来)中。

那么所以

namespace级别的资源其API规范中metadata字段下的namespace字段，在编写manifests时得指定。
非namespace级别的资源其API规范中metadata字段下的namespace字段，在编写manifests时不用指定，指定也没用的。

# namespace级别的资源其API规范中metadata字段下的namespace字段，在编写manifests时得指定。
root@master01:~# kubectl explain Pod.metadata.namespace         # 在编写manifests时得指定# 非namespace级别的资源其API规范中metadata一级字段下的namespace字段，在编写manifests时不用指定，指定也没用的。
root@master01:~# kubectl explain Namespace.metadata.namespace   # 在编写manifests时不用指定

1.4 k8s中资源(resources)的manifests

资源实例化出对象

可以使用kubectl工具在命令行直接创建（默认只支持使用相应的标准资源），但这种方式不推荐（若要在线修改呢、若被删除了且在没备份的情况下你如何快速恢复呢）。
也可以根据其API规范编写manifests，其manifests可以放在一个文件中，这个文件中可以存在多个不同类型的资源对象的manifests，得用三个横杠（—）独占一行进行分隔，这个文件中的内容其格式要么是json/yaml，其文件的扩展名也得是json/yaml，推荐内容格式为yaml，文件扩展名为yaml，易于人类可读。最后可用kubectl apply -f /path/xxx.yaml -f /path/yyy.yaml 或 cd /path/ && kubectl apply -f . 或 kubectl apply -f /path/ 进行应用（不存在就创建，存在就更新其差异的，有些字段是不可在线更新的）
在版书时可用 “资源类型或资源name/所实例化出对象的name”来表示一个对象，如下所示

# 以下表示的是同一个对象
Namespace/a   等于  namespaces/a

前面提到

标准资源、非标准资源都有namespace级别、非namespace级别（也称cluster级别），均有一级字段之metadata字段，而metadata字段下的name字段是必须指定的。

那么所以

非namespace级别的某资源所实例化出来的对象不允许重名，不同资源间所实例化出来的对象是允许重名的。如下所示：

Namespace/a#      # 若存在#   kubectl工具命令行再创建Namespace/a，不允许，直接报错。#   kubectl工具apply -f Namespace/a <其manifests所在的文件>，其实是#       更新(有些字段是不允许更新的，例如metadata.name，有些字段更新后的影响你得心中有数)#   
PersistentVolume/a   # # 若存在#   kubectl工具命令行再创建PersistentVolume/a，不允许，直接报错。#   kubectl工具apply -f PersistentVolume/a <其manifests所在的文件>，其实是#      更新(有些字段是不允许更新的，例如metadata.name，有些字段更新后的影响你得心中有数)# 

namespace级别的某资源所实例化出来的对象不能在所指定 ns 中与现有某资源对象重名，可与非指定ns中现有某资源对象重名。

Namespace/a 对象中Deployment/a # 若存在#   kubectl工具命令行再创建Deployment/a，不允许，直接报错。#   kubectl工具apply -f Deployment/a <其manifests所在的文件>，其实是#       更新(有些字段是不允许更新的，例如metadata.name，有些字段更新后的影响你得心中有数)#   Service/a# 若存在#   kubectl工具命令行再创建Service/a，不允许，直接报错。#   kubectl工具apply -f Service/a <其manifests所在的文件>，其实是#       更新(有些字段是不允许更新的，例如metadata.name，有些字段更新后的影响你得心中有数)#   Namespace/b 对象中Deployment/a## 若存在，跟 Namespace/a 中的 Deployment/a 没有任何关系#   kubectl工具命令行再创建Deployment/a，不允许，直接报错。#   kubectl工具apply -f Deployment/a <其manifests所在的文件>，其实是#       更新(有些字段是不允许更新的，例如metadata.name，有些字段更新后的影响你得心中有数)#  Service/a## 若存在，跟 Namespace/a 中的  Service/a 没有任何关系#   kubectl工具命令行再创建Service/a，不允许，直接报错。#   kubectl工具apply -f Service/a <其manifests所在的文件>，其实是#       更新(有些字段是不允许更新的，例如metadata.name，有些字段更新后的影响你得心中有数)#   

第2章 k8s中的标准资源之namespaces的实践

2.1 基本介绍

namespaces资源（简写ns）是kubernetes中的标准资源，属于非namespace级别，其实例化出来的对象用于逻辑存放namespace级别资源所实例化出来的对象。
当ns资源对象被删除后，其里面所包含的非namespace级别资源所实例化出来的对象也会被删除。得小心哦。

2.2 编写相关ns资源对象的manifests

我们应该让各ns资源对象的manifests独占一个文件。因为在删除资源对象时可以使用kubectl delete -f <文件> 来删除，当ns资源对象被删除后，其里面所包含的非namespace级别资源所实例化出来的对象也会被删除。

ns/dev-wyc对象的manifests，手动编写

cat >./ns_dev-wyc.yaml<<'EOF'
apiVersion: v1
kind: Namespace
metadata:name: dev-wyclabels:env: dev proj: wyc
EOF

ns/test-wyc对象的manifests，手动编写

cat >./ns_test-wyc.yaml<<'EOF'
apiVersion: v1
kind: Namespace
metadata:name: test-wyclabels:env: testproj: wyc
EOF

ns/prod-wyc对象的manifests，手动编写

cat >./ns_prod-wyc.yaml<<'EOF'
apiVersion: v1
kind: Namespace
metadata:name: prod-wyclabels:env: prodproj: wyc
EOF

ns/uat-wyc对象的manifests，kubectl工具快速生成

kubectl create namespace uat-wyc --dry-run=client -o yaml >./ns_uat-wyc.yaml
ls -l ./ns_uat-wyc.yaml## 命令行快速生成ns资源对象的manifests,并保存于一个文件中。# 命令行无法指定ns/uat-wyc对象的相应label(不是必须的,可命令行添加，也可编辑文件后并保存)。# PS：我这里没有修改,主要是与后面的步骤有关联#

2.3 应用相关ns资源对象的manifests

应用ns_dev-wyc.yaml这个manifests

# -->检查语法
kubectl apply -f ./ns_dev-wyc.yaml --dry-run=client
# -->应用manifests
kubectl apply -f ./ns_dev-wyc.yaml
# -->列出manifests中的相关资源对象
kubectl get   -f ./ns_dev-wyc.yaml
# -->列出ns/dev-wyc对象
kubectl get   ns/dev-wyc
# -->列出所有的ns资源对象,并根据labels过滤，且显示所有labels
kubectl get   ns -l kubernetes.io/metadata.name=dev-wyc --show-labels

应用ns_test-wyc.yaml这个manifests

kubectl apply -f ./ns_test-wyc.yaml --dry-run=client
kubectl apply -f ./ns_test-wyc.yaml
kubectl get   -f ./ns_test-wyc.yaml
kubectl get   ns/test-wyc
kubectl get   ns -l kubernetes.io/metadata.name=test-wyc --show-labels

应用ns_prod-wyc.yaml这个manifests

kubectl apply -f ./ns_prod-wyc.yaml --dry-run=client
kubectl apply -f ./ns_prod-wyc.yaml
kubectl get   -f ./ns_prod-wyc.yaml
kubectl get   ns/prod-wyc
kubectl get   ns -l kubernetes.io/metadata.name=prod-wyc --show-labels

应用ns_uat-wyc.yaml这个manifests

kubectl apply -f ./ns_uat-wyc.yaml --dry-run=client
kubectl apply -f ./ns_uat-wyc.yaml
kubectl get   -f ./ns_uat-wyc.yaml
kubectl get   ns/uat-wyc
kubectl get   ns -l kubernetes.io/metadata.name=uat-wyc --show-labels
# --> 命令行给其打上相应的标签。规范的是修改其manifests，再应用manifests，这里只是引出命令行如何给某资源对象打Label
kubectl label Namespace uat-wyc env=uat proj=wyc
# --> 再通过相应标签进行查看
kubectl get   ns -l kubernetes.io/metadata.name=uat-wyc --show-labels

2.4 列出相关ns资源对象

列出所有的ns资源对象

## 格式
kubectl get <某资源的kind>## 示例
kubectl get Namespace

列出已存在的一个或多个ns资源对象

## 格式1
kubectl get <某资源的kind>  <对象name>   [对象name]## 格式2
kubectl get <某资源的kind>/<对象name>    [某资源的kind]/[对象的name]## 格式1示例
kubectl get Namespace   dev-wyc  test-wyc  uat-wyc  prod-wyc## 格式2示例
kubectl get Namespace/dev-wyc Namespace/test-wyc  Namespace/uat-wyc  Namespace/prod-wyc

通过标签列出wyc项目相关的ns资源对象

# 列出wyc项目相关的所有ns资源对象
kubectl get ns -l proj=wyc# 列出dev环境之wyc项目所用的ns资源对象
kubectl get ns -l env=dev,proj=wyc   # 指定多个标签进行过滤，当有多个时，用逗号分隔，且是与(and)关系# 列出test环境之wyc项目所用的ns资源对象
...................................# 列出uat环境之wyc项目所用的ns资源对象
...................................# 列出prod环境之wyc项目所用的ns资源对象
...................................

2.5 ns资源对象的name

非namespace级别的某资源所实例化出来的对象不能重名，不同资源间所实例化出来的对象是可以重名的。
namespace级别的某资源所实例化出来的对象不能在所指定 ns 中与现有某资源对象重名，可与非指定ns中现有某资源对象重名。
kubernetes中所有资源对象的name规范均遵循一定的规范：

https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names/#names

ns资源对象的name规范得遵循 RFC 1123。

2.6 ns资源对象的labels

kubernetes中的各资源对象均有 labels 这一属性，属于元数据(metadata)的一部分，支持在线更新，我们不能随便在线更新。
各ns资源对象具备默认的标签之 app.kubernetes.io/instance=<ns资源对象的name> ,我们可以给ns资源对象额外的添加 labels。
有些场景下，ns资源对象可能需要打上特定的标签，例如：Istio部署到kubernetes平台上，其业务所用标签就得打上 Istio 所规定的标签。

2.7 列出ns资源对象所包含非namespace资源对象

首先，kubectl -n <ns资源对象> get all 是看不到 <ns资源对象> 所包含的所有非namespace资源所实例化出来的对象，即使kubernetes中的标准资源。

## 查看 ns/uat-wyc 对象中所包含的所有资源对象，（不严谨） 
root@master01:~# kubectl -n uat-wyc get all
No resources found in uat-wyc namespace.
root@master01:~# ## 可用以下命令查看某 ns资源对象 中所包含的所有资源对象 （严谨）
# <== 列出namespace级别的resources，且只显示name
kubectl api-resources --verbs=list --namespaced=true -o name# <== 列出某ns资源对象中所包含namespace级别资源的相关资源对象
kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl -n <ns资源对象>  get --show-kind  --ignore-not-found | sed '/^NAME/'d | awk -F " " '{print $1}' # <== 示例
root@master01:~#  kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl -n uat-wyc  get --show-kind  --ignore-not-found | sed '/^NAME/'d | awk -F " " '{print $1}' 
configmap/kube-root-ca.crt      # --> configmap是k8s中的标准资源
serviceaccount/default          # --> serviceaccount是k8s中的标准资源

2.8 ns资源对象的删除

第3章 基于ns资源对象实践理解Label的管理