关于后端:k8s命令扫盲

0次阅读

共计 11407 个字符，预计需要花费 29 分钟才能阅读完成。

kubectl -n ingress-nginx get pod -o wide 是一个 kubectl 命令，用于获取指定命名空间（ingress-nginx）中运行的 Pod 的详细信息，包含广度（wide）视图。

具体解释如下：

kubectl: 是用于与 Kubernetes 集群进行交互的命令行工具。
-n ingress-nginx: 应用 -n 选项指定了命名空间（namespace）为 ingress-nginx，这示意该命令将在ingress-nginx 命名空间中执行。
get pod: 该局部批示要获取 Pod 资源。
-o wide: 应用 -o 选项指定输入格局为 ”wide” 视图。Wide 视图提供了更多的列，显示 Pod 的更多详细信息，例如所在节点（Node）、IP 地址、调度器、容器状态等。

因而，kubectl -n ingress-nginx get pod -o wide 命令的作用是从 ingress-nginx 命名空间中获取所有 Pod 的详细信息，并以 Wide 视图的格局显示。这对于查看 Pod 的详细信息、理解它们的调度和状态十分有用。

“ing.yaml” 可能是指 Kubernetes 中的 Ingress（入口）资源的配置文件，通常应用 “.yaml” 扩展名。

Ingress 是 Kubernetes 中用于治理对集群内服务的内部拜访的 API 对象。它充当着申请流量的入口，能够通过定义规定来将内部申请路由到不同的服务。

一个 “ing.yaml” 配置文件通常蕴含以下内容：

metadata：定义 Ingress 对象的元数据，如名称、命名空间、标签等。
spec：指定 Ingress 的规定和配置选项，包含：
- rules：定义了路由规定，将特定的域名或门路映射到后端服务。
- tls：指定 SSL/TLS 配置，用于加密传输。
- backend：定义默认的后端服务，用于解决未匹配到规定的申请。

例如，一个简略的 “ing.yaml” 文件示例能够是这样的：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-namespace
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /app
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 8080

以上配置定义了一个名为 “my-ingress” 的 Ingress 对象，在域名 “example.com” 下，将以 “/app” 门路前缀的申请转发到名为 “my-service” 的服务的端口 8080 上。

通过将 “ing.yaml” 文件利用到 Kubernetes 集群，能够创立和配置 Ingress 对象，以便治理内部流量的路由和访问控制。

# Source: docker-registry/templates/secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: diuregistry-docker-registry-secret
  namespace: xxxx
  labels:
    app: docker-registry
    chart: docker-registry-2.2.2
    heritage: Helm
    release: diuregistry
type: Opaque
data:
  htpasswd: xxxxxxxx==
  haSharedSecret: "xxxxxxx=="
  proxyUsername: ""proxyPassword:""

什么意思？

这是一个 Kubernetes Secret 对象的 YAML 配置文件示例。该配置文件定义了一个名为 diuregistry-docker-registry-secret 的 Secret 对象，用于在 Kubernetes 的 xxxx 命名空间中存储敏感的凭据和配置信息。

解释每个局部的含意如下：

apiVersion: v1：指定了应用的 Kubernetes API 版本。
kind: Secret：定义了这个 YAML 文件形容的对象类型为 Secret。
metadata：指定了 Secret 对象的元数据，包含名称、命名空间和标签等。
type: Opaque：指定了 Secret 对象的类型为 Opaque，即不通明类型，意味着其数据内容不受特定格局的限度。
data：指定了要存储在 Secret 对象中的数据。

上面是 data 局部的具体含意：

htpasswd：存储了一个通过 Base64 编码的 htpasswd 文件内容，通常用于基于用户名和明码的身份验证。
haSharedSecret：存储了一个通过 Base64 编码的共享密钥。
proxyUsername 和 proxyPassword：这两个字段为空字符串，示意这个 Secret 对象中没有存储代理的用户名和明码。

总结起来，这个 Secret 对象用于存储与 Docker Registry 相干的敏感凭据和配置信息，如用户名和明码，共享密钥等。这些凭据和配置信息能够在 Kubernetes 中被其余资源（如 Deployment、StatefulSet 等）援用和应用，以实现平安的拜访和配置 Docker Registry。

在 Kubernetes 中，service.yaml、deployment.yaml和 configmap.yaml 是三种不同类型的 YAML 配置文件，别离用于定义不同的 Kubernetes 资源，其区别和作用如下：

service.yaml：Service（服务）资源配置文件
- 作用：定义了一个逻辑服务，用于裸露集群中的应用程序或其余服务，使其可能被其余服务或内部申请拜访。
- 区别：Service 提供了一个稳固的入口点，应用标签选择器将申请路由到后端的 Pod。它能够通过 ClusterIP、NodePort、LoadBalancer、或者 ExternalName 类型来定义服务的拜访形式。
deployment.yaml：Deployment（部署）资源配置文件
- 作用：定义了应用程序或服务的部署标准，包含容器镜像、正本数量、环境变量、挂载卷等。
- 区别：Deployment 管制 Pod 的生命周期，它创立和治理一个或多个 Pod 正本，确保指定数量的 Pod 正本始终运行，并可依据须要进行主动扩缩容、滚动降级等操作。
configmap.yaml：ConfigMap（配置映射）资源配置文件
- 作用：用于存储应用程序的配置数据，如环境变量、配置文件、命令行参数等。
- 区别：ConfigMap 提供了一种将配置数据从利用程序代码中解耦的形式，通过将配置数据存储在 ConfigMap 中，应用程序能够在运行时动静加载这些配置数据，而无需批改代码。

总结：

service.yaml 用于定义服务的拜访形式和路由规定。
deployment.yaml 用于定义应用程序或服务的部署标准和治理正本。
configmap.yaml 用于存储应用程序的配置数据，实现配置和代码的解耦。

通过编写这些不同类型的配置文件并将它们利用到 Kubernetes 集群中，能够实现服务的拜访、利用的部署和配置的治理，从而无效地运行和治理容器化的应用程序。

kubectl -n xxx get ing 是一个 kubectl 命令，用于获取指定命名空间（wing）中的 Ingress（入口）资源的信息。

具体解释如下：

kubectl: 是用于与 Kubernetes 集群进行交互的命令行工具。
-n xxx: 应用 -n 选项指定了命名空间（namespace）为 xxx，这示意该命令将在xxx 命名空间中执行。
get ing: 该局部批示要获取 Ingress 资源的信息。

因而，kubectl -n xxx get ing 命令的作用是从 xxx 命名空间中获取所有 Ingress 资源的信息。这对于查看 Ingress 规定、域名配置和后端服务等十分有用，能够帮忙治理和配置应用程序的入口流量。

依据文件夹门路 docker-registry/templates，它通常是一个 Helm Chart 的模板目录，用于寄存 Docker Registry 相干的 YAML 配置文件。在 Helm Chart 中，该目录下的 YAML 文件通常用于定义 Kubernetes 资源的配置模板，以便在部署 Helm Chart 时生成相应的资源对象。

具体文件和其作用的示例可能会因具体的 Helm Chart 实现而有所不同，以下是一些常见的文件示例及其可能的作用：

deployment.yaml：用于定义 Docker Registry 的 Deployment（部署）资源，包含容器镜像、正本数量、挂载卷等。
service.yaml：用于定义 Docker Registry 的 Service（服务）资源，指定了如何裸露 Docker Registry 的拜访形式。
configmap.yaml：用于定义 Docker Registry 的 ConfigMap（配置映射）资源，存储 Docker Registry 的配置信息，如环境变量、配置文件等。
ingress.yaml：用于定义 Docker Registry 的 Ingress（入口）资源，指定了内部申请如何拜访 Docker Registry。
secret.yaml：用于定义 Docker Registry 的 Secret（凭据）资源，存储敏感的凭据，如用户名、明码等。

这只是一些常见的文件示例，具体的文件和作用可能会依据不同的 Helm Chart 实现而有所不同。如果您有特定的 Helm Chart 或更具体的文件列表，请提供更多详细信息，我将尽力提供更精确的答案。

configmap.yaml 是 Kubernetes 中的一个 YAML 配置文件，用于定义 ConfigMap（配置映射）资源。ConfigMap 是一种用于存储配置数据的 Kubernetes 对象，它容许将配置信息与利用程序代码解耦，并以键值对的模式存储和治理配置数据。

一个典型的 configmap.yaml 文件可能蕴含以下内容：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
  namespace: my-namespace
data:
  key1: value1
  key2: value2

解释每个局部的含意如下：

apiVersion：指定应用的 Kubernetes API 版本。
kind：指定资源类型为 ConfigMap。
metadata：指定 ConfigMap 对象的元数据，包含名称和命名空间等。
data：指定要存储在 ConfigMap 中的配置数据，以键值对的模式提供。

在上述示例中，my-configmap 是 ConfigMap 对象的名称，my-namespace 是 ConfigMap 所在的命名空间。data 局部定义了两个键值对：key1: value1 和 key2: value2。您能够依据理论需要在 data 局部增加更多的键值对，以存储应用程序所需的配置数据。

通过应用 ConfigMap，您能够将配置数据从利用程序代码中解耦，并在部署或更新应用程序时轻松治理和调整配置。应用程序能够通过读取环境变量、挂载配置文件或应用命令行参数等形式，从 ConfigMap 中获取配置数据，以实现动静配置和灵活性。

ingress.yaml 是 Kubernetes 中的一个 YAML 配置文件，用于定义 Ingress（入口）资源。Ingress 容许从集群内部拜访集群外部的服务，并提供了路由和负载平衡的性能。

一个典型的 ingress.yaml 文件可能蕴含以下内容：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-namespace
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /path1
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

解释每个局部的含意如下：

apiVersion：指定应用的 Kubernetes API 版本，通常为 networking.k8s.io/v1。
kind：指定资源类型为 Ingress。
metadata：指定 Ingress 对象的元数据，包含名称和命名空间等。
spec：指定 Ingress 的标准，包含路由规定和后端服务的定义。
- rules：指定拜访规定，能够配置多个规定。
  - host：指定 Ingress 的拜访域名。
  - http：指定应用 HTTP 协定。
    - paths：指定门路规定，能够配置多个门路。
      - path：指定申请门路。
      - pathType：指定门路类型，能够是 Exact、Prefix 或 ImplementationSpecific。
      - backend：指定后端服务的定义。
        
        service：指定服务的名称和端口。

在上述示例中，my-ingress 是 Ingress 对象的名称，my-namespace 是 Ingress 所在的命名空间。spec 局部定义了一个拜访规定，指定了通过 example.com/path1 拜访时应将申请转发到名为 my-service 的服务的端口 80 上。

通过应用 Ingress，您能够通过定义路由规定和拜访域名来拜访集群外部的服务。Ingress 能够实现负载平衡、SSL/TLS 终止、门路匹配和重定向等性能，为集群内部的申请提供入口和流量管制的能力。

在 Linux 零碎中，ss命令是一个弱小的工具，用于显示套接字（socket）统计信息。它提供了比传统的 netstat 命令更具体和更全面的网络连接信息。

以下是 ss 命令的常见用法和选项：

ss [options]

罕用的选项包含：

-t：显示 TCP 连贯的统计信息。
-u：显示 UDP 连贯的统计信息。
-p：显示与套接字关联的过程信息。
-n：以数字模式显示 IP 地址和端口号。
-l：仅显示处于监听状态的套接字。
-a：显示所有连贯（包含监听状态和非监听状态）的统计信息。
-e：显示更具体的信息，包含套接字的状态、用户和标记等。
-o：显示计时器信息，包含连贯的持续时间和超时工夫等。
-i：显示接口信息，包含接口名称、传输层协定和接管 / 发送队列等。

除了上述选项，还有许多其余选项可用于进一步定制和过滤输入。

以下是一些示例用法：

显示所有 TCP 连贯的统计信息：ss -t
显示所有 UDP 连贯的统计信息：ss -u
显示所有监听状态的套接字：ss -l
显示所有与指定过程关联的套接字：ss -p pid
显示所有处于 TIME-WAIT 状态的套接字：ss state TIME-WAIT

请留神，运行 ss 命令可能须要以 root 用户或具备足够权限的用户身份运行，以便获取残缺的套接字信息。

应用 man ss 命令能够获取更具体的 ss 命令的帮忙文档。

这个命令的含意是将文件 deploy.yaml 的内容通过管道传递给 sed 命令，并应用 sed 命令进行文本处理。

具体来说，sed 命令应用了以下选项和表达式：

-e：指定要执行的命令或脚本。
$a：这是一个 sed 的行追加命令，示意在最初一行后追加文本。
\ \ \ \ \ \imagePullSecrets:：这是要追加的文本内容，以 \ 结尾的空格示意缩进。

因而，这个命令的作用是将文件 deploy.yaml 的内容输入，并在文件的最初一行后追加了一个缩进的文本行 \ \ \ \ \ \imagePullSecrets:。这能够用于向 YAML 文件中增加额定的配置项或内容。请留神，命令中的每个空格都应用了反斜杠进行了本义，以确保保留空格的缩进成果。

sudo bash 是一个命令组合，用于以超级用户（root）权限运行交互式的 Bash shell。上面解释其中的含意：

sudo 是一个命令，用于以超级用户（root）权限执行指定的命令。它要求用户输出本人的明码进行身份验证，并长期获取超级用户权限。通过应用 sudo，普通用户能够执行须要特权权限的操作，而无需齐全切换到超级用户。
bash 是一个常见的 Unix/Linux 操作系统的 Shell 解释器。它是一种命令行界面，用于与操作系统进行交互和执行命令。

因而，sudo bash 的意思是应用超级用户权限运行一个新的交互式 Bash shell。这样做能够在以后用户的环境中取得超级用户的特权，从而执行须要特权权限的操作，如更改零碎设置、管理文件等。请审慎应用 sudo 权限，并确保只在必要时应用以避免对系统造成不必要的危险。

svc.yaml 是 Kubernetes 中用于定义服务（Service）的 YAML 文件。在 Kubernetes 中，服务是一种形象的概念，用于将一组具备雷同性能的 Pod 组织在一起，并为它们提供对立的入口点。服务容许其余应用程序或服务通过服务名称和端口拜访这组 Pod，而无需理解底层 Pod 的详细信息。

svc.yaml 文件用于定义一个服务的标准，包含服务的名称、类型、端口映射等。以下是一个示例的 svc.yaml 文件内容：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

在这个示例中，svc.yaml 文件定义了一个名为 my-service 的服务。该服务的选择器指定了与 app: my-app 标签匹配的 Pod，这些 Pod 将被服务关联起来。该服务监听 TCP 协定的 80 端口，并将申请转发到指标端口 8080 上的 Pod。最初，该服务的类型被设置为 ClusterIP，示意该服务只在集群外部可拜访。

通过应用 kubectl apply -f svc.yaml 命令，您能够将该 svc.yaml 文件利用到 Kubernetes 集群中，创立相应的服务资源。创立胜利后，其余应用程序或服务就能够通过拜访 my-service 的名称和端口来拜访与该服务关联的 Pod。

k -n xxxx edit svc xxxxx-service 是一个应用 Kubernetes 命令行工具（kubectl）编辑指定服务的命令，并指定了服务名称和命名空间。

具体来说，命令的各个局部的含意如下：

k：是 kubectl 命令的简写模式，用于与 Kubernetes 集群进行交互。
-n xxxx：应用 -n 选项指定了命名空间为 xxxx。命名空间是 Kubernetes 中用于隔离和组织资源的一种机制。
edit svc xxxxx-service：这部分命令示意编辑指定名称为 xxxxx-service 的服务。

综合起来，k -n xxxx edit svc xxxxx-service 的意思是应用 kubectl 命令编辑命名空间为 xxxx 中名称为 xxxxx-service 的服务。执行这个命令将会关上一个文本编辑器，并显示服务的配置文件。您能够在编辑器中批改服务的配置，并保留退出后，kubectl 将会更新服务的配置。

相干信息更短缺

{
  "ip": "xxx.xxx.xx.xx",
  "city": "Guangzhou",
  "region": "Guangdong",
  "country": "CN",
  "loc": "23.1167,113.2500",
  "org": "AS45090 Shenzhen Tencent Computer Systems Company Limited",
  "timezone": "Asia/Shanghai",
  "readme": "https://ipinfo.io/missingauth"
}

k -n xxxx get pod -o wide 是一个应用 Kubernetes 命令行工具（kubectl）获取指定命名空间下的 Pod 列表的命令，并以具体的宽格局输入。

具体来说，命令的各个局部的含意如下：

k：是 kubectl 命令的简写模式，用于与 Kubernetes 集群进行交互。
-n xxxx：应用 -n 选项指定了命名空间为 xxxx。命名空间是 Kubernetes 中用于隔离和组织资源的一种机制。
get pod：这部分命令示意获取 Pod 的操作。get 是 kubectl 命令的子命令，用于获取 Kubernetes 资源的信息。
-o wide：应用 -o 选项指定输入格局为宽格局。wide 示意输入更具体的信息，包含 Pod 的 IP 地址、节点、所在的命名空间等。

综合起来，k -n xxxx get pod -o wide 的意思是应用 kubectl 命令获取命名空间为 wing 中的所有 Pod 的列表，并以具体的宽格局进行输入。执行这个命令将会显示在指定命名空间下的所有 Pod 的相干信息，例如 Pod 名称、所属节点、IP 地址、运行状态等。

请留神，在执行此命令之前，确保已正确装置并配置了 kubectl 命令行工具，并且具备适当的权限来拜访指定的命名空间中的 Pod。

要在应用 kubectl apply 命令时指定命名空间（namespace），能够应用 -n 或 --namespace 标记后跟要利用资源的命名空间名称。

以下是将 Pod 配置利用到指定命名空间的示例命令：

kubectl apply -f pod.yaml -n < 命名空间名称 >

请将 < 命名空间名称 > 替换为你要将 Pod 配置利用到的理论命名空间名称。在执行此命令时，pod.yaml 文件中的 Pod 配置将被利用到指定的命名空间中。

确保在命令中指定正确的命名空间名称，并且 pod.yaml 文件中的配置正确无误。这样，Pod 将在指定的命名空间中创立或更新。

在 Kubernetes 中，NodePort 是一种服务类型（Service Type），它容许你将集群中的某个服务公开到集群内部，并通过节点的 IP 地址和指定的端口进行拜访。

当你创立一个 NodePort 类型的服务时，Kubernetes 将会调配一个固定的端口号（称为 NodePort）给该服务。而后，这个服务将会在每个节点上监听该 NodePort，并将流量转发到后端 Pod 的对应端口。

NodePort 服务具备以下特点：

内部拜访：NodePort 服务使得集群中的服务能够通过节点的 IP 地址和指定的端口号对外公开，以便内部用户或内部服务可能拜访到服务。
端口范畴：NodePort 端口号的范畴是 30000-32767（能够依据须要进行配置）。在创立 NodePort 服务时，能够指定要应用的特定端口号，或者让 Kubernetes 主动调配可用的端口。
流量转发：NodePort 服务将来自内部的申请流量转发到后端 Pod 的对应端口，从而实现对服务的拜访。这种转发是通过 kube-proxy 组件实现的，它会在每个节点上配置相应的 iptables 规定或 IPVS 规定来解决流量转发。

要创立一个 NodePort 服务，须要定义一个 Service 对象，并指定 spec.type 为 NodePort，以及 spec.ports[*].nodePort 字段来指定 NodePort 端口号。示例 YAML 配置如下：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 8080
      nodePort: 30080
  selector:
    app: my-app

在上述示例中，创立了一个名为 my-service 的 NodePort 服务，将内部流量的端口 30080 转发到后端 Pod 的端口 8080 上。能够依据须要批改端口号和其余相干字段。

应用 NodePort 服务时，你能够通过任意节点的 IP 地址和指定的 NodePort 端口号拜访服务。例如，如果你的节点 IP 是 192.168.0.10，NodePort 是 30080，则能够应用 http://192.168.0.10:30080 进行拜访。

须要留神的是，NodePort 服务公开的端口是固定的，不适宜在生产环境中间接应用，因为端口范畴无限并且可能会与其余服务抵触。在生产环境中，能够思考应用负载均衡器（如 LoadBalancer 类型的服务）或者 Ingress 控制器来代理和公开服务。

当执行 kubectl get all --namespace=default 命令时，你可能会失去以下类型的资源列表：

Pods：列出在 default 命名空间中的所有 Pod，包含它们的名称、状态、IP 地址和节点信息等。
Services：列出在 default 命名空间中的所有 Service，包含它们的名称、类型（ClusterIP、NodePort、LoadBalancer 等）、对应的端口和后端 Pod 信息等。
Deployments：列出在 default 命名空间中的所有 Deployment，包含它们的名称、正本数、可用数和所属的 ReplicaSet 等。
ReplicaSets：列出在 default 命名空间中的所有 ReplicaSet，包含它们的名称、正本数、可用数和关联的 Pod 信息等。
StatefulSets：列出在 default 命名空间中的所有 StatefulSet，包含它们的名称、正本数、可用数和关联的 Pod 信息等。
DaemonSets：列出在 default 命名空间中的所有 DaemonSet，包含它们的名称、所在节点数和关联的 Pod 信息等。
ConfigMaps：列出在 default 命名空间中的所有 ConfigMap，包含它们的名称、数据和关联的资源等。
Secrets：列出在 default 命名空间中的所有 Secret，包含它们的名称、类型（Opaque、TLS 等）和数据等。

请留神，理论的输入后果取决于在 default 命名空间中创立的资源的存在状况。如果没有特定类型的资源存在，那局部后果可能会为空。

此外，你还能够在 kubectl get all 命令前面增加其余标记，例如 -o wide 来获取更具体的信息，或者应用 -A 来查看所有命名空间中的资源。

kubectl get all 等同于 kubectl get all --namespace=default

kubectl get all --namespace="ns 名称", 获取某个 namespace 上面的全副资源

kubectl get pod -n="ns 名称", 也能够 kubectl -n="ns 名称" get pod, 获取某个 namespace 上面的 pod 类型的资源

--namespace能够简写为-n，在后面或前面指定，之后加不加引号, 有没有等号，都是能够的，即如下:

kubectl -n=xxx get pod,kubectl -n="xxx" get pod,kubectl --namespace=xxx get pod,kubectl --namespace="xxx" get pod, kubectl get pod -n="xxx", kubectl get pod -n "xxx" 都是非法的

k -n xxxx get pod -o wide 获取 xxxx 这个 namespace 上面的全副 pod 类型的资源，以更具体的信息来展现

Kubernetes 集群命名空间（Namespace）

本文由 mdnice 多平台公布

正文完

后端

发表至：后端

2023-06-30

0

关于后端:如何在非Spring容器管理的类中注入获取-Spring容器中的-Bean

关于后端:Redis数据结构七之listpack和quicklist

关于后端:企业微信避坑指南一

关于后端:如何在-ACK-中使用-MSE-Ingress

关于前端:程序员职场工具库Excel-应用4-个人工作管理

关于后端:k8s命令扫盲

kubectl -n ingress-nginx get pod -o wide 什么意思？

ing.yaml 是干什么的？

这是一个 Kubernetes Secret 对象的 YAML 配置文件示例

service.yaml，deployment.yaml，configmap.yaml 区别和作用

kubectl -n xxx get ing 什么意思？

docker-registry/templates 这个文件夹上面有什么 yaml 文件？别离干什么用的？

configmap.yaml 大抵是什么内容？

ing.yaml/ingress.yaml 大抵是什么内容？

linux ss 命令

cat deploy.yaml | sed -e ‘$a\ \ \ \ \ \imagePullSecrets:’ 什么意思？

sudo bash 什么意思？

svc.yaml 干什么用的？

k -n xxxx edit svc xxxxx-service 什么意思？

curl https://ipinfo.io

k -n xxxx get pod -o wide 什么意思？

kubectl apply -f pod.yaml 时如何指定 namespace

K8S 的 nodeport 是什么？请具体介绍

kubectl get all –namespace=default 可能失去的后果有哪些？都是什么

一些命令

站内搜索