『无头服务』即 Kubernetes 中的 Headless Service。Service 是 Kubernetes 对后端一组提供相同服务的 Pod 的逻辑抽象和访问入口。 在某些应用场景中，若需要人为指定负载均衡器，不使用 Service 提供的默认负载均衡的功能，或者应用程序希望知道属于同组服务的其他实例。可以通过无头服务实现。 Kubernetes 提供了 Headless Service 来实现这种功能，即不为 Service 设置 ClusterIP（入口 IP 地址），仅通过 Label Selector 将后端的 Pod 列表返回给调用的客户端。 在nacos集群的资源清单文件，通过selector字段 matchlabels为：app=nacos 。 设置了label selector之后，Kubernetes则会根据label selector查询pod列表 自动创建endpoint列表，将服务名（DNS域名）的解析机制配置为：当客户端访问服务名是，得到的是endpoint列表（而不是一个确定的IP地址）也可以回答 一、Headless Service概念 在某些应用场景中，客户端不需要通过Kubernetes内置的Service实现负载均衡功能，或者需要自行完成对服务后端各个实例的服务发现机制，或者需要自行实现负载均衡功能，可以通过创建特殊的名为“Headless”的服务实现。 Headless Service的概念是这种服务没有入口访问地址(无ClusterIP地址)，kube-proxy不会为其创建负载转发规则，而服务名(DNS域名)的解析机制取决于该Headless Service是否设置了Label Selector。 二、Headless Service设置Label Selector 如果Headless Service设置了Label Selector，Kubernetes则将根据Label Selector查询后端Pod列表，自动创建Endpoint列表，将服务名(DNS域名)的解析机制配置为：当客户端访问该服务名时，得到是全部Endpoint列表(而不是一个确定的IP地址) 三、Headless Service未设置Label Selector 如果Headless Service没有设置Label Selector，则Kubernetes不会自动创建对应的Endpoint列表。DNS系统会根据下列条件设置DNS记录。 如果Service类型为ExternalName，则对服务名访问将直接被DNS系统转为Service设置的外部(externalName)； 如果系统中存在与Service同名的Endpoint定义，则服务名将被解析为Endpoint定义中的列表，适用于非ExternnalName类型的Service ———————————————— 参考的博文https://blog.csdn.net/GaoChuang_/article/details/121313534...

　　这篇文章是关于使用 Kubectl 进行 Kubernetes 诊断的指南。 　　列出了 100 个 Kubectl 命令，这些命令对于诊断 Kubernetes 集群中的问题非常有用。这些问题包括但不限于： 　　• 集群信息 　　• Pod 诊断 　　• 服务诊断 　　• 部署诊断 　　• 网络诊断 　　• 持久卷和持久卷声明诊断 　　• 资源使用情况 　　• 安全和授权 　　• 节点故障排除 　　• 其他诊断命令：文章还提到了许多其他命令，如资源扩展和自动扩展、作业和定时作业诊断、Pod 亲和性和反亲和性规则、RBAC 和安全、服务账号诊断、节点排空和取消排空、资源清理等。 　　集群信息： 　　1. 显示 Kubernetes 版本：kubectl version 　　2. 显示集群信息：kubectl cluster-info 　　3. 列出集群中的所有节点：kubectl get nodes 　　4. 查看一个具体的节点详情：kubectl describe node 　　5. 列出所有命名空间：kubectl get namespaces /kubectl get ns 　　6. 列出所有命名空间中的所有 pod：kubectl get pods --all-namespaces 　　Pod 诊断： 　　1. 列出特定命名空间中的 pod：kubectl get pods -n 　　2. 查看一个 Pod 详情：kubectl describe pod -n 　　3. 查看 Pod 日志：kubectl logs -n 　　4. 尾部 Pod 日志：kubectl logs -f -n 　　5. 在 pod 中执行命令：kubectl exec -it -n -- 　　Pod 健康检查： 　　1. 检查 Pod 准备情况：kubectl get pods -n -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' 　　2. 检查 Pod 事件：kubectl get events -n --field-selector involvedObject.name= 　　Service诊断： 　　1. 列出命名空间中的所有服务：kubectl get svc -n 　　2. 查看一个服务详情：kubectl describe svc -n 　　Deployment诊断： 　　1. 列出命名空间中的所有Deployment：kubectl get deployments -n 　　2. 查看一个Deployment详情：kubectl describe deployment -n 　　3. 查看滚动发布状态：kubectl rollout status deployment/ -n 　　4. 查看滚动发布历史记录：kubectl rollout history deployment/ -n 　　StatefulSet诊断： 　　1. 列出命名空间中的所有 StatefulSet：kubectl get statefulsets -n 　　2. 查看一个 StatefulSet详情：kubectl describe statefulset -n 　　ConfigMap 和Secret诊断： 　　1. 列出命名空间中的 ConfigMap：kubectl get configmaps -n 　　2. 查看一个ConfigMap详情：kubectl describe configmap -n 　　3. 列出命名空间中的 Secret：kubectl get secrets -n 　　4. 查看一个Secret详情：kubectl describe secret -n 　　命名空间诊断： 　　1. 查看一个命名空间详情：kubectl describe namespace 　　资源使用情况： 　　1. 检查 pod 的资源使用情况：kubectl top pod -n 　　2. 检查节点资源使用情况：kubectl top nodes 　　图片 　　网络诊断： 　　1. 显示命名空间中 Pod 的 IP 地址：kubectl get pods -n -o custom-columns=POD:metadata.name,IP:status.podIP --no-headers 　　2. 列出命名空间中的所有网络策略：kubectl get networkpolicies -n 　　3. 查看一个网络策略详情：kubectl describe networkpolicy -n 　　持久卷 (PV) 和持久卷声明 (PVC) 诊断： 　　1. 列出PV：kubectl get pv 　　2. 查看一个PV详情：kubectl describe pv 　　3. 列出命名空间中的 PVC：kubectl get pvc -n 　　4. 查看PVC详情：kubectl describe pvc -n 　　节点诊断： 　　1. 获取特定节点上运行的 Pod 列表：kubectl get pods --field-selector spec.nodeName= -n 　　资源配额和限制： 　　1. 列出命名空间中的资源配额：kubectl get resourcequotas -n 　　2. 查看一个资源配额详情：kubectl describe resourcequota -n 　　自定义资源定义 (CRD) 诊断： 　　1. 列出命名空间中的自定义资源：kubectl get -n 　　2. 查看自定义资源详情：kubectl describe -n 　　使用这些命令时，请记住将, , , , , , , , , , , , , , 和替换为你的特定值。 　　这些命令应该可以帮助你诊断 Kubernetes 集群以及在其中运行的应用程序。 　　资源伸缩和自动伸缩 　　1. Deployment伸缩：kubectl scale deployment --replicas= -n 　　2. 设置Deployment的自动伸缩：kubectl autoscale deployment --min= --max= --cpu-percent= -n 　　3. 检查水平伸缩器状态：kubectl get hpa -n 　　作业和 CronJob 诊断： 　　1. 列出命名空间中的所有作业：kubectl get jobs -n 　　2. 查看一份工作详情：kubectl describe job -n 　　3. 列出命名空间中的所有 cron 作业：kubectl get cronjobs -n 　　4. 查看一个 cron 作业详情：kubectl describe cronjob -n 　　容量诊断： 　　1. 列出按容量排序的持久卷 (PV)：kubectl get pv --sort-by=.spec.capacity.storage 　　2. 查看PV回收策略：kubectl get pv -o=jsonpath='{.spec.persistentVolumeReclaimPolicy}' 　　3. 列出所有存储类别：kubectl get storageclasses 　　Ingress和服务网格诊断： 　　1. 列出命名空间中的所有Ingress：kubectl get ingress -n 　　2. 查看一个Ingress详情：kubectl describe ingress -n 　　3. 列出命名空间中的所有 VirtualServices (Istio)：kubectl get virtualservices -n 　　4. 查看一个 VirtualService (Istio)详情：kubectl describe virtualservice -n 　　Pod 网络故障排除： 　　1. 运行网络诊断 Pod(例如 busybox)进行调试：kubectl run -it --rm --restart=Never --image=busybox net-debug-pod -- /bin/sh 　　2. 测试从 Pod 到特定端点的连接：kubectl exec -it -n -- curl 　　3. 跟踪从一个 Pod 到另一个 Pod 的网络路径：kubectl exec -it -n -- traceroute 　　4. 检查 Pod 的 DNS 解析：kubectl exec -it -n -- nslookup 　　配置和资源验证： 　　1. 验证 Kubernetes YAML 文件而不应用它：kubectl apply --dry-run=client -f 　　2. 验证 pod 的安全上下文和功能：kubectl auth can-i list pods --as=system:serviceaccount:: 　　RBAC 和安全性： 　　1. 列出命名空间中的角色和角色绑定：kubectl get roles,rolebindings -n 　　2. 查看角色或角色绑定详情：kubectl describe role -n 　　服务帐户诊断： 　　1. 列出命名空间中的服务帐户：kubectl get serviceaccounts -n 　　2. 查看一个服务帐户详情：kubectl describe serviceaccount -n 　　清空节点和解除封锁： 　　1. 清空节点以进行维护：kubectl drain --ignore-daemonsets 　　2. 解除对节点的封锁：kubectl uncordon 　　资源清理： 　　1. 强制删除 pod(不推荐)：kubectl delete pod -n --grace-period=0 --force 　　Pod 亲和性和反亲和性： 　　1. 列出 pod 的 pod 亲和性规则：kubectl get pod -n -o=jsonpath='{.spec.affinity}' 　　2. 列出 pod 的 pod 反亲和性规则：kubectl get pod -n -o=jsonpath='{.spec.affinity.podAntiAffinity}' 　　Pod 安全策略 (PSP)： 　　1. 列出所有 Pod 安全策略(如果启用)：kubectl get psp 　　事件： 　　1. 查看最近的集群事件：kubectl get events --sort-by=.metadata.creationTimestamp 　　2. 按特定命名空间过滤事件：kubectl get events -n 　　节点故障排除： 　　1. 检查节点情况：kubectl describe node | grep Conditions -A5 　　2. 列出节点容量和可分配资源：kubectl describe node | grep -E "Capacity|Allocatable" 　　临时容器(Kubernetes 1.18+)： 　　1. 运行临时调试容器：kubectl debug -it -n --image= -- /bin/sh 　　资源指标(需要指标服务器)： 　　1. 获取 Pod 的 CPU 和内存使用情况：kubectl top pod -n 　　kuelet诊断： 　　1. 查看节点上的kubelet日志：kubectl logs -n kube-system kubelet- 　　使用Telepresence 进行高级调试： 　　1. 使用 Telepresence 调试 pod：telepresence --namespace --swap-deployment 　　图片 　　Kubeconfig 和上下文： 　　1. 列出可用的上下文：kubectl config get-contexts 　　2. 切换到不同的上下文：kubectl config use-context 　　Pod 安全标准(PodSecurity 准入控制器)： 　　1. 列出 PodSecurityPolicy (PSP) 违规行为：kubectl get psp -A | grep -vE 'NAME|REVIEWED' 　　Pod 中断预算 (PDB) 诊断： 　　1. 列出命名空间中的所有 PDB：kubectl get pdb -n 　　2. 查看一个PDB详情：kubectl describe pdb -n 　　资源锁诊断(如果使用资源锁)： 　　1. 列出命名空间中的资源锁：kubectl get resourcelocks -n 　　服务端点和 DNS： 　　1. 列出服务的服务端点：kubectl get endpoints -n 　　2. 检查 Pod 中的 DNS 配置：kubectl exec -it -n -- cat /etc/resolv.conf 　　自定义指标(Prometheus、Grafana)： 　　1. 查询Prometheus指标：用于kubectl port-forward访问Prometheus和Grafana服务来查询自定义指标。 　　Pod 优先级和抢占： 　　1. 列出优先级：kubectl get priorityclasses 　　Pod 开销(Kubernetes 1.18+)： 　　1. 列出 pod 中的开销：kubectl get pod -n -o=jsonpath='{.spec.overhead}' 　　存储卷快照诊断(如果使用存储卷快照)： 　　1. 列出存储卷快照：kubectl get volumesnapshot -n 　　2. 查看存储卷快照详情：kubectl describe volumesnapshot -n 　　资源反序列化诊断： 　　1. 反序列化并打印 Kubernetes 资源：kubectl get -n -o=json 　　节点污点： 　　1. 列出节点污点：kubectl describe node | grep Taints 　　更改和验证 Webhook 配置： 　　1. 列出变异 webhook 配置：kubectl get mutatingwebhookconfigurations 　　2. 列出验证 Webhook 配置：kubectl get validatingwebhookconfigurations 　　Pod 网络策略： 　　1. 列出命名空间中的 pod 网络策略：kubectl get networkpolicies -n 　　节点条件(Kubernetes 1.17+)： 　　1. 自定义查询输出：kubectl get nodes -o custom-columns=NODE:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status -l 'node-role.kubernetes.io/worker=' 　　审核日志： 　　1. 检索审核日志(如果启用)：检查 Kubernetes 审核日志配置以了解审核日志的位置。 　　节点操作系统详细信息： 　　1. 获取节点的操作系统信息：kubectl get node -o jsonpath='{.status.nodeInfo.osImage}' 　　这些命令应该涵盖 Kubernetes 中的各种诊断场景。确保将、、等占位符替换为你的集群和用例的实际值。 来源：K8S中文社区...

K8S的设计结构大致可分为下列三大部分 Client： 属于用户触发请求的客户端，即Kubectl, 用户的各种触发的命令就是通过kuberctl统一封装后进行命令触发的 Master：用于处理用户触发的请求，进行处理决策， Worker：命令真正的执行者，读取etcd的结果将数据最终执行 K8S设计结构图 Client Kubectl： 是k8s 的client，也是一般RD 最常用的操作方式之一，很多K8S的使用者主要就是通过kubectl跟K8S打交道。 UI：Dashboard 也是一个独立服务，默认可以不需要，这个服务本身可以通过Kubectl部署在k8s上对外提供服务。 Master ApiServer：Master 通信的入口， Client 和 Worker 之前同行 ETCD：Master中唯一的决策结果的存储 Controller Manager：里面保存各种controller Scheduler：执行实例资源的选择调度决策， 选择出合适的Worker节点来运行服务的Pod，真正的部署操作由Kubelet来执行 Worker Kubelet：直接通过ApiServer的watch接口读取原始数据结果 KubeProxy：网络请求通过Kubeproxy实现服务接口的转发，作为普通服务的命名管理 Pod：将容器、网络和存储单元打包在一起，是服务独立的部署单元。核心思路是高内聚 Container：原始服务容器，容器与pod 的对应关系是一个Pod中包含多个容器，多个容器之间的服务可以互相访问 核心理念：K8s 设计的核心理念最终概括为4大点： 声明式、显示接口、无入侵性 和 可移植性 声明式：对比指令式，需求任何功能通过yml文件来描述自己的需求，最终由k8s调度满足 显示接口：任何接口定义都属于显示定义，不存在私有接口，所以给业务CRD 自定义提供前提， 每个K8s 可以根据自己的需求和现有的功能实现自己的服务功能 无入侵性：该特点就是说任何服务部署只要提前打包好docker 的image ，是不需要再做任何代码改造，就可以完成部署。 可移植性：可移植性主要是强调对于有状态的服务，通过PersistentVolume 支持屏蔽底层的数据存储细节 ...

金丝雀发布的由来：17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为瓦斯检测指标，以便在危险状况下紧急撤离。 所在金丝雀发布也是采取类似的流程，在发布过程中，一般先发1台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试 （国内常称灰度测试），如果发现有问题，立马暂停发布，并回滚版本，并排查出错节点信息，并找到其原因，如果一切正常，则继续发布，直到完全更新。 金丝雀发布步骤： 步骤一：将流量从待部署节点移出，更新该节点服务到待发布状态，将该节点称为金丝雀节点； 步骤二：根据不同策略，将流量引入金丝雀节点。策略可以根据情况指定，比如随机样本策略（随机引入）、狗粮策略（就是内部用户或员工先尝鲜）、分区策略（不同区域用户使用不同版本）、用户特征策略（这种比较复杂，需要根据用户个人资料和特征进行分流，类似于千人千面）； 步骤三：金丝雀节点验证通过后，选取更多的节点称为金丝雀节点，重复步骤一和步骤二，直到所有节点全部更新 金丝雀部署和蓝绿有点像，但是它更加规避风险。你可以阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。 采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。 金丝雀和蓝绿的对比 ...

准备工作： 把实验镜像包myapp-lan.tar.gz和myapp-lv.tar.gz上传到部署node节点，然后导入到镜像： ctr -n=k8s.io images import myapp-lan.tar.gz ctr -n=k8s.io images import myapp-lv.tar.gz 1、回到master控制节点创建部署配置文件(yaml配置文件)， [root@ctdmaster1 ~]# vim lv.yaml 配置代码如下 ： apiVersion: apps/v1 kind: Deployment metadata: name: myapp-v1 namespace: blue-green spec: replicas: 3 selector: matchLabels: app: myapp version: v2 template: metadata: labels: app: myapp version: v2 spec: containers: name: myapp image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: containerPort: 80 2、创建名字空间和deploy资源： [root@ctdmaster1 ~]# kubectl create ns blue-green namespace/blue-green created [root@ctdmaster1 ~]# kubectl apply -f lv.yaml 3、查看pods是否创建成功 [root@ctdmaster1 ~]# kubectl get pods -n blue-green NAME READY STATUS RESTARTS AGE myapp-v1-75d7db5cf7-467dg 1/1 Running 0 26s myapp-v1-75d7db5cf7-4rx4z 1/1 Running 0 26s myapp-v1-75d7db5cf7-lhgz9 1/1 Running 0 26s 4、创建前端Service [root@ctdmaster1 ~]# vim service_lanlv.yaml 代码如图： 执行更新服务命令：kubectl apply -f service_lanlv.yaml 执行命令查看是否更新成功：kubectl get svc -n blue-green 在浏览器访问http://k8s-master节点ip:30062 如节点的IP为192.168.40.161，则访问下 http://192.168.40.161:30062 如节点的IP为192.168.40.162，则访问下 http://192.168.40.162:30062 两个节点的效果是一样的。 5、创建蓝色部署环境（即新上线的环境，要替代绿色环境） 1）、创建部署yaml配置文件 vim lan.yaml 2)执行部署配置命令：kubectl apply -f lan.yaml 并查看运行结果 从图中可以看出蓝色版已经运行成功，但是因为在后台运行，所以前端是访问不了的。此时如果需要切换蓝色版本只需要修改前端的配置文件service_lanlv.yaml即可，如： 刷新访问节点1的192.168.40.161:30062 前面已经更新为蓝色版本，说明实验成功。 总的来说，蓝绿部署就是部署两套一样的环境，一个前台运行，一个后台备用，当需要更新的时候，只要把后台运行的更新测试无误之后，把前端的路由或者代理指向后台更新好的环境， 这样后台变前台，前台变后台，如果前台的出了问题，备用的可以立马顶上，这可最大的减少前端访问宕机故障。...

蓝绿部署是一种应用发布模式，可将用户流量从先前版本的应用或微服务逐渐转移到几乎相同的新版本中（两者均保持在生产环境中运行）。旧版本可以称为蓝色环境，而新版本则可称为绿色环境。一旦生产流量从蓝色完全转移到绿色，蓝色就可以在回滚或退出生产的情况下保持待机，也可以更新成为下次更新的模板。 这种持续部署模式原本存在不足之处。并非所有环境都具有相同的正常运行时间要求或正确执行 CI/CD 流程（如蓝绿部署）所需的资源。但是，随着企业加大对数字化转型的支持，许多应用开始支持这种持续交付。蓝绿部署是一种应用发布模式，可将用户流量从先前版本的应用或微服务逐渐转移到几乎相同的新版本中（两者均保持在生产环境中运行）。 蓝绿部署的优势和缺点 优点： 1、更新过程无需停机，风险较少 2、回滚方便，只需要更改路由或者切换DNS服务器，效率较高 缺点： 1、成本较高，需要部署两套环境。如果新版本中基础服务出现问题，会瞬间影响全网用户；如果新版本有问题也会影响全网用户。 2、需要部署两套机器，费用开销大 3、在非隔离的机器（Docker、VM）上操作时，可能会导致蓝绿环境被摧毁风险 4、负载均衡器/反向代理/路由/DNS处理不当，将导致流量没有切换过来情况出现...

Deployment是kubernetes中最常用的资源对象，为ReplicaSet和Pod的创建提供了一种声明式的定义方法，在Deployment对象中描述一个期望的状态，Deployment控制器就会按照一定的控制速率把实际状态改成期望状态，通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器，通过ReplicaSet创建pod，删除Deployment控制器，也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源. 使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级、金丝雀发布、蓝绿部署和回滚。 扩展：声明式定义是指直接修改资源清单yaml文件，然后通过kubectl apply -f 资源清单yaml文件，就可以更改资源。 apiVersion: apps/v1 kind: Deployment metadata: name: myapp-v1 spec: replicas: 3 selector: matchLabels: app: myapp version: v1 template: metadata: labels: app: myapp version: v1 spec: containers: - name: myapp image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: - containerPort: 80 version: v1 template: metadata: labels: app: myapp version: v1 spec: containers: - name: myapp image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: - containerPort: 80 startupProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / livenessProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / readinessProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: /...

1、kubectl get all -o wide -A 【查询所有命名空间下常用资源】 缺点：这种方法 kubectl get all 其实查询出来不是全部资源，仅仅是常用资源，仅仅是 service - deployment/statefulset/daemonset/job/cronjob - replicaset - pod 这个绑定链资源，还有 rbac 的 role rolebinding，配置文件 configmap secrets，服务账号 serviceAccount ，service与pod的绑定endpoints都没有查询出来 2、kubectl api-versions 【查看所有apiVersion版本】 3、kubectl api-resources 【查看所有资源类型】 4、kubectl api-resources --verbs=list --namespaced -o name 5、kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -A #查询所有命名空间下的所有资源 ...

在 Kubernetes 中，名字空间（Namespace） 提供一种机制，将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一，但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象， （例如 Deployment、Service 等），这种作用域对集群范围的对象 （例如 StorageClass、Node、PersistentVolume 等）不适用。 名字空间为名称提供了一个范围。资源的名称需要在名字空间内是唯一的，但不能跨名字空间。 名字空间不能相互嵌套，每个 Kubernetes 资源只能在一个名字空间中。 名字空间是在多个用户之间划分集群资源的一种方法，而当名字空间中存在一个 ResourceQuota 对象时，对于该名字空间而言，资源配额就是开启的。当名字空间资源配额开启时，在空间里创建的Pod或者应用资源时必须必须设置资源限额，否则创建失败。 Kubernetes 初始化启动时会自动创建四个名字空间： 1、default：Kubernetes 包含这个名字空间，以便于你无需创建新的名字空间即可开始使用新集群。 2、kube-node-lease：该名字空间包含用于与各个节点关联的 Lease（租约）对象。 节点租约允许 kubelet 发送心跳， 由此控制面能够检测到节点故障。 3、kube-public：所有的客户端（包括未经身份验证的客户端）都可以读取该名字空间。 该名字空间主要预留为集群使用，以便某些资源需要在整个集群中可见可读。 该名字空间的公共属性只是一种约定而非要求。 4、kube-system：该名字空间用于 Kubernetes 系统创建的对象 有关名字空间的常用命令： 1、创建名字空间 kubectl create ns test 2、获取当前名字空间列表 kubectl get namespace/ns [root@ctdmaster1 ~]# kubectl get namespace NAME STATUS AGE default Active 11d kube-node-lease Active 11d kube-public Active 11d kube-system Active 11d test Active 11d 3、删除名字空间 kubectl delete namespaces 名字空间名 此命令会删除名字空间下的 所有内容，谨慎操作 ！ [root@ctdmaster1 ~]# kubectl get ns NAME STATUS AGE default Active 11d kube-node-lease Active 11d kube-public Active 11d kube-system Active 11d test Active 11d [root@ctdmaster1 ~]# kubectl get pods -n test NAME READY STATUS RESTARTS AGE pod-test 1/1 Running 0 158m [root@ctdmaster1 ~]# kubectl delete ns test namespace "test" deleted [root@ctdmaster1 ~]# kubectl get pods -n test No resources found in test namespace. [root@ctdmaster1 ~]# kubectl get ns NAME STATUS AGE default Active 11d kube-node-lease Active 11d kube-public Active 11d kube-system Active 11d 4、分析名字空间详细信息 kubectl describe namespaces [root@ctdmaster1 ~]# kubectl describe ns test Name: test Labels: kubernetes.io/metadata.name=test Annotations: <none> Status: Active No resource quota. No LimitRange resource. 5、创建资源配额 [root@ctdmaster1 ~]# vim namespace-quota.yaml #以下为资源配额内容 apiVersion: v1 kind: ResourceQuota metadata: name: mem-cpu-quota namespace: test spec: hard: requests.cpu: "2" requests.memory: 2Gi limits.cpu: "4" limits.memory: 4Gi 执行命令： [root@ctdmaster1 ~]# kubectl apply -f namespace-quota.yaml 查看名字空间配额 [root@ctdmaster1 ~]# kubectl describe ns test Name: test Labels: kubernetes.io/metadata.name=test Annotations: <none> Status: Active Resource Quotas Name: mem-cpu-quota Resource Used Hard -------- --- --- limits.cpu 0 4 limits.memory 0 4Gi requests.cpu 0 2 requests.memory 0 2Gi No LimitRange resource. 最后需要注意的是 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中，而且底层资源， 例如节点和持久化卷不属于任何名字空间。 查看哪些 Kubernetes 资源在名字空间中，哪些不在名字空间中： # 位于名字空间中的资源 kubectl api-resources --namespaced=true 不在名字空间中的资源 kubectl api-resources --namespaced=false ...

一、概述 作为接替 Docker 运行时的 Containerd 在早在 Kubernetes1.7 时就能直接与 Kubelet 集成使用，只是大部分时候我们因熟悉 Docker，在部署集群时采用了默认的 dockershim。在V1.24起的版本的 kubelet 就彻底移除了dockershim，改为默认使用Containerd了，当然也使用 cri-dockerd 适配器来将 Docker Engine 与 Kubernetes 集成。可以参考官方文档： https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#docker 二、Containerd 常见命令操作 更换 Containerd 后，以往我们常用的 docker 命令也不再使用，取而代之的分别是 crictl 和 ctr 两个命令客户端。 crictl 是遵循 CRI 接口规范的一个命令行工具，通常用它来检查和管理kubelet节点上的容器运行时和镜像。 ctr 是 containerd 的一个客户端工具。 ctr -v 输出的是 containerd 的版本，crictl -v 输出的是当前 k8s 的版本，从结果显而易见你可以认为 crictl 是用于 k8s 的。 一般来说你某个主机安装了 k8s 后，命令行才会有 crictl 命令。而 ctr 是跟 k8s 无关的，你主机安装了 containerd 服务后就可以操作 ctr 命令。 使用crictl命令之前，需要先配置/etc/crictl.yaml如下： runtime-endpoint: unix:///run/containerd/containerd.sock image-endpoint: unix:///run/containerd/containerd.sock timeout: 10 debug: false 或者使用命令： crictl config runtime-endpoint unix:///run/containerd/containerd.sock crictl config image-endpoint unix:///run/containerd/containerd.sock docker ctr crictl三种命令对比图 由于 Containerd 也有 namespaces 的概念，对于上层编排系统的支持，ctr 客户端 主要区分了 3 个命名空间分别是k8s.io、moby和default，以上我们用crictl操作的均在k8s.io命名空间，使用ctr 看镜像列表就需要加上-n 参数。crictl 是只有一个k8s.io命名空间，但是没有-n 参数。 【温馨提示】ctr images pull 拉取的镜像默认放在default，而 crictl pull 和 kubelet 默认拉取的镜像都在 k8s.io 命名空间下。所以通过ctr导入镜像的时候特别注意一点，最好指定命名空间。 注意-n不能放在命令最后面，下面几行查看的镜像是一样的 ctr -n=k8s.io image ls ctr -n k8s.io image ls crictl 没有-n参数，操作都在k8s.io命名空间下。 crictl image ls crictl images crictl image list = ctr -n=k8s.io image list crictl image ls = ctr -n=k8s.io image ls crictl images = ctr -n=k8s.io image list crictl images = ctr -n=k8s.io image ls 使用ctr命令指定命名空间导入镜像 ctr -n=k8s.io image import dashboard.tar 查看镜像，可以看到可以查询到了 crictl images 三、containerd 客户端工具 nerdctl 推荐使用 nerdctl，使用效果与 docker 命令的语法一致，github 下载链接： https://github.com/containerd/nerdctl/releases 精简 (nerdctl–linux-amd64.tar.gz): 只包含 nerdctl 完整 (nerdctl-full–linux-amd64.tar.gz): 包含 containerd, runc, and CNI 等依赖 nerdctl 的目标并不是单纯地复制 docker 的功能，它还实现了很多 docker 不具备的功能，例如延迟拉取镜像（lazy-pulling）、镜像加密（imgcrypt）等。具体看 nerdctl。 延迟拉取镜像功能可以参考这篇文章：Containerd 使用 Stargz Snapshotter 延迟拉取镜像 https://icloudnative.io/posts/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd/ 1）安装 nerdctl（精简版） wget https://github.com/containerd/nerdctl/releases/download/v0.22.2/nerdctl-0.22.2-linux-amd64.tar.gz 解压 tar -xf nerdctl-0.22.2-linux-amd64.tar.gz ln -s /opt/k8s/nerdctl/nerdctl /usr/local/bin/nerdctl 2）安装 nerdctl（完整版，这里不装） wget https://github.com/containerd/nerdctl/releases/download/v0.22.2/nerdctl-full-0.22.2-linux-amd64.tar.gz tar -xf nerdctl-full-0.16.0-linux-amd64.tar.gz -C /usr/local/ cp /usr/local/lib/systemd/system/*.service /etc/systemd/system/ 启动服务 buildkit systemctl enable buildkit containerd --now systemctl status buildkit containerd 3）安装 buildkit 支持构建镜像 buildkit GitHub 地址： https://github.com/moby/buildkit 使用精简版 nerdctl 无法直接通过 containerd 构建镜像，需要与 buildkit 组全使用以实现镜像构建。当然你也可以安装上面的完整 nerdctl；buildkit 项目是 Docker 公司开源出来的一个构建工具包，支持 OCI 标准的镜像构建。它主要包含以下部分: 服务端 buildkitd，当前支持 runc 和 containerd 作为 worker，默认是 runc； 客户端 buildctl，负责解析 Dockerfile，并向服务端 buildkitd 发出构建请求。 buildkit 是典型的C/S 架构，client 和 server 可以不在一台服务器上。而 nerdctl 在构建镜像方面也可以作为 buildkitd 的客户端。 https://github.com/moby/buildkit/releases wget https://github.com/moby/buildkit/releases/download/v0.10.4/buildkit-v0.10.4.linux-amd64.tar.gz tar -xf buildkit-v0.10.4.linux-amd64.tar.gz -C /usr/local/ 配置 buildkit 的启动文件，可以从这里下载： https://github.com/moby/buildkit/tree/master/examples/systemd buildkit 需要配置两个文件 /usr/lib/systemd/system/buildkit.socket cat > /usr/lib/systemd/system/buildkit.socket <<EOF [Unit] Description=BuildKit Documentation=https://github.com/moby/buildkit [Socket] ListenStream=%t/buildkit/buildkitd.sock SocketMode=0660 [Install] WantedBy=sockets.target EOF /usr/lib/systemd/system/buildkit.service cat > /usr/lib/systemd/system/buildkit.service << EOF [Unit] Description=BuildKit Requires=buildkit.socket After=buildkit.socket Documentation=https://github.com/moby/buildkit [Service] Replace runc builds with containerd builds ExecStart=/usr/local/bin/buildkitd --addr fd:// [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable buildkit --now 四、实战操作 1）修改 containerd 配置文件 配置如下： [plugins.“io.containerd.grpc.v1.cri”.registry] config_path = “” [plugins."io.containerd.grpc.v1.cri".registry.auths] [plugins."io.containerd.grpc.v1.cri".registry.configs] [plugins."io.containerd.grpc.v1.cri".registry.configs."myharbor-minio.com".tls] insecure_skip_verify = true #跳过认证 ca_file = "/etc/containerd/myharbor-minio.com/ca.crt" [plugins."io.containerd.grpc.v1.cri".registry.configs."myharbor-minio.com".auth] username = "admin" password = "Harbor12345" [plugins."io.containerd.grpc.v1.cri".registry.headers] [plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."myharbor-minio.com"] endpoint = ["https://myharbor-minio.com"] 重新加载配置 systemctl daemon-reload 重启containerd systemctl restart containerd 注意：这个配置文件是给crictl和kubelet使用，ctr是不可以用这个配置文件的，ctr 不使用 CRI，因此它不读取 plugins."io.containerd.grpc.v1.cri"配置 2）ctr 拉取推送镜像 推送镜像到harbor ctr --namespace=k8s.io images push myharbor-minio.com/bigdata/minio:2022.8.22-debian-11-r0 --skip-verify --user admin:Harbor12345 –namespace=k8s.io 指定命名空间，不是必须，根据环境而定 –skip-verify 跳过认证 –user 指定harbor用户名及密码 ctr images pull --user admin:Harbor12345 --tlscacert=/etc/containerd/myharbor-minio.com/ca.crt myharbor-minio.com/bigdata/minio:2022.8.22-debian-11-r0 不想-u user:password 每次必须使用 ctr pull/ctr push， 可以使用nerdctl 。 3）镜像构建 cat > Dockerfile <<EOF FROM nginx:alpine RUN echo ‘Hello Nerdctl From Containerd’ > /usr/share/nginx/html/index.html EOF 然后在文件所在目录执行镜像构建命令： 不加-n指定命名空间，crictl看不到，kubelet也不能使用它，默认在default命名空间下 nerdctl -n k8s.io build -t nginx:nerctl -f ./Dockerfile . 参数解释 -t：指定镜像名称 . ：当前目录Dockerfile -f：指定Dockerfile路径 –no-cache：不缓存 4）打标签 tag crictl没有tag命令，只能使用nerdctl和ctr，必须指定命名空间，要不然kubelet无法使用。 ctr -n k8s.io i tag nerdctl -n k8s.io tag nginx:nerctl myharbor-minio.com/bigdata/nginx:nerctl ctr -n k8s.io tag nginx:nerctl myharbor-minio.com/bigdata/nginx:nerctl 查看镜像 nerdctl -n k8s.io images myharbor-minio.com/bigdata/nginx:nerctl 5）将镜像推送到 Harbor 第一种情况：http方式，配置如下： 以下两个哪个都可以 mkdir -p /etc/docker/certs.d/myharbor-minio.com:443 mkdir -p /etc/containerd/certs.d/myharbor-minio.com:443 cat > /etc/containerd/certs.d/myharbor-minio.com:443/hosts.toml <<EOF server = “https://docker.io” [host.“http://myharbor-minio.com:80”] capabilities = [“pull”, “resolve”,“push”] skip_verify = true ca = “ca.crt” #相对路径 ca = “/opt/auth/ca.crt” #绝对路径 ca = [“/opt/auth/ca.crt”] ca = [“ca.crt”] client = [[“/opt/auth/nginx.cclinux.cn.crt”, “/opt/auth/nginx.cclinux.cn.key”]] EOF 第二种情况：https方式，配置如下： 以下两个哪个都可以 mkdir -p /etc/docker/certs.d/myharbor-minio.com:443 mkdir -p /etc/containerd/certs.d/myharbor-minio.com:443 cat > /etc/containerd/certs.d/myharbor-minio.com:443/hosts.toml <<EOF server = “https://docker.io” [host.“https://myharbor-minio.com:443”] capabilities = [“pull”, “resolve”,“push”] skip_verify = true ca = “ca.crt” #相对路径 ca = “/opt/auth/ca.crt” #绝对路径 ca = [“/opt/auth/ca.crt”] ca = [“/etc/containerd/myharbor-minio.com/ca.crt”] client = [[“/opt/auth/nginx.cclinux.cn.crt”, “/opt/auth/nginx.cclinux.cn.key”]] EOF 通过 nerdctl 登录 harbor echo Harbor12345 | nerdctl login --username “admin” --password-stdin myharbor-minio.com:443 nerdctl login --username “admin” --password Harbor12345 myharbor-minio.com:443 登出 nerdctl logout 开始将镜像推送到 harbor 推送到Harbor –insecure-registry skips verifying HTTPS certs, and allows falling back to plain HTTP nerdctl --insecure-registry --namespace=k8s.io push myharbor-minio.com/bigdata/nginx:nerctl ctr --namespace=k8s.io images push myharbor-minio.com/bigdata/nginx:nerctl --skip-verify --user admin:Harbor12345 –namespace=k8s.io 指定命名空间，跟-n一样，不是必须，根据环境而定 –skip-verify 跳过认证 –user 指定harbor用户名及密码 ———————————————— 版权声明：本文为CSDN博主「稚辉君.MCA.P8.JAVA高级架构师」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/m0_37843156/article/details/128277966...