k8s创建命名空间？k8s怎么创建容器

这篇文章给大家聊聊关于k8s创建命名空间，以及k8s怎么创建容器对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。

k8s 一个前端 多个后端 要创建几个命名空间

K8s中前端+多个后端的场景通常建议创建至少3个命名空间，核心依据是环境隔离与资源管理需求，具体规划需结合业务复杂度、团队协作模式及部署策略调整：

一、基础命名空间规划（必选）

1. `default`命名空间：

系统默认空间，可临时部署测试资源，但不建议长期使用，避免与正式环境混淆。

2. `frontend`命名空间：

独立承载前端应用（如Vue/React项目），隔离前端与后端的配置、日志及资源配额，便于单独扩缩容或灰度发布。

3. `backend`命名空间（或按后端类型拆分）：

•若多个后端功能关联（如用户服务+订单服务），可合并至单个`backend`空间，通过Deployment/Service标签区分；

•若后端属于不同业务域（如支付服务+物流服务），建议拆分至`backend-pay`/`backend-logistics`等子空间，避免跨团队部署冲突。

二、进阶命名空间（可选，依环境需求）

1. `dev`/`test`/`prod`环境隔离：

若需多环境部署（开发/测试/生产），需为每个环境创建独立空间，例如：

• `dev-frontend`/`dev-backend`（开发环境）

• `test-frontend`/`test-backend`（测试环境）

• `prod-frontend`/`prod-backend`（生产环境）

此方案可通过Namespace的ResourceQuota/NetworkPolicy实现环境间资源隔离与访问控制。

2. `monitoring`/`logging`系统空间：

若需统一监控（如Prometheus）、日志收集（如ELK），可单独创建系统空间，避免业务资源与监控数据混杂。

三、命名空间设计原则

1.最小化原则：初期建议从3个核心空间（default/frontend/backend）起步，避免过度拆分导致管理复杂；

2.业务关联性：后端若需共享配置（如数据库连接），优先合并空间；若需独立权限，拆分更安全；

3.团队协作：跨团队业务（如前端团队+支付团队）需拆分空间，通过RBAC（角色访问控制）分配权限。

•最简方案：3个命名空间（default+frontend+backend）；

•多环境方案：6个及以上（按环境+业务拆分）；

•核心逻辑：以“环境隔离+业务隔离”为核心，平衡管理效率与安全性。

正确性标签:

k8s 认证和权限控制

k8s的认证机制主要基于 ServiceAccount、Token、证书（crt）以及 HTTP基础认证等方式，通过 ApiServer的认证插件和授权插件依次完成身份验证和权限校验。以下是具体说明：

认证机制核心流程ApiServer处理请求：当客户端（如 Pod、用户或外部系统）向 Kubernetes ApiServer发送请求时，ApiServer会依次调用认证插件和授权插件。认证插件：负责验证客户端身份，支持多种认证方式（如 ServiceAccount Token、X.509证书、HTTP基本认证等）。

授权插件：在认证通过后，检查客户端是否有权限执行请求的操作（如创建 Pod、访问 Secret等）。

ServiceAccount（SA）详解定义与作用ServiceAccount是 Kubernetes的一种资源，用于为 Pod中的进程提供身份标识。每个 Pod默认关联一个 SA（若未指定则使用命名空间下的 default SA），SA的 Token会被挂载到 Pod的/var/run/secrets/kubernetes.io/serviceaccount/目录下，包含以下文件：

token：JWT格式的认证 Token，用于身份验证。

namespace：Pod所属的命名空间名称。

ca.crt：ApiServer的 CA证书，用于验证 ApiServer的身份。

SA与 Pod的关联规则

一对多关系：一个 SA可以关联多个 Pod，但一个 Pod只能关联一个 SA。

命名空间限制：SA和 Pod必须在同一命名空间下，跨命名空间的关联无效。

创建与管理 SA

命令创建：通过 kubectl create sa<SA名称>创建 SA（例如 kubectl create sa xmt）。

查看 SA：使用 kubectl get sa列出所有 SA。

自动生成 Secret：创建 SA后，Kubernetes会自动生成一个包含 Token的 Secret，Secret名称格式为<SA名称>-token-<随机字符串>。

SA的 Token内容SA的 Token是 JWT格式，解码后可获取以下信息：

iss：签发者（kubernetes/serviceaccount）。

kubernetes.io/serviceaccount/namespace：SA所属命名空间。

sub：主体标识（格式为 system:serviceaccount:<命名空间>:<SA名称>）。

uid：SA的唯一标识符。

权限控制机制RBAC（基于角色的访问控制）Kubernetes默认使用 RBAC模型管理权限，核心组件包括：

Role/ClusterRole：定义权限规则（如可操作哪些资源、执行哪些动作）。

RoleBinding/ClusterRoleBinding：将 Role/ClusterRole绑定到用户、组或 SA，授予实际权限。

SA与 RBAC结合

为 SA分配权限时，需通过 RoleBinding或 ClusterRoleBinding将 Role/ClusterRole绑定到该 SA。

例如：创建一个允许读取 Pod的 Role，并将其绑定到 xmt SA，则关联该 SA的 Pod即可读取 Pod信息。

跨命名空间限制

SA的权限仅在其所属命名空间内生效（除非使用 ClusterRole和 ClusterRoleBinding授予集群范围权限）。

例如：default命名空间的 SA无法操作 kube-system命名空间的资源。

实践示例：创建 Pod并指定 SA创建 SA

kubectl create sa my-sa定义 Pod并指定 SA通过 spec.serviceAccountName字段指定 SA：

apiVersion: v1kind: Podmetadata: name: my-podspec: serviceAccountName: my-sa containers:- name: nginx image: nginx验证 SA关联查看 Pod详情，确认 serviceAccountName字段值为 my-sa：

kubectl describe pod my-pod

总结认证：Kubernetes通过 ServiceAccount Token、证书等方式验证客户端身份，ApiServer调用认证插件完成校验。权限控制：基于 RBAC模型，通过 Role/ClusterRole和 RoleBinding/ClusterRoleBinding分配权限，SA作为身份载体参与权限校验。命名空间隔离：SA和权限默认在命名空间内生效，确保资源访问的安全性。

k8s的Service详解

Pod是非永久性资源，会动态创建和销毁，pod的ip会变化。这会导致一类Pod（业务1）访问另一类Pod（业务2）需要找出并跟踪Pod（业务2）的IP地址，再者Pod（业务2）是多个的，如何提供负载均衡呢？虽然Pod1通过轮询一组Pod的ip可以实现，但会Pod就需要增加负载均衡的逻辑，Pod就变得不纯粹了，不符合单一设计原则。于是有了Service，把一类Pods上的应用程序抽象成服务，并提供可以访问他们的策略。

有两种方式：选择算符的Service和没有选择算符的Service

这是最常见的方式，指定 spec.selector即通过打标签的方式，主要是针对集群内部同命名空间的Pod

创建上面的Service,会自动创建相应的 Endpoint对象

查看自动创建的Endpoint对象

主要是针对希望服务指向另一个名字空间或者其他集群中的服务，比如外部的ES集群

此服务没有选择算符，因此不会自动创建相应的 Endpoint对象,需要手动动添加 Endpoint对象，将服务手动映射到运行该服务的网络地址和端口

该模式下，节点上kube-proxy持续监听 Service以及 Endpoints对象的变化，并设置进本地节点iptables，请求反向代理全部交给 iptables来实现。每个Node节点都会配置所有Service进iptables，当捕获到Service的clusterIP和端口请求，利用注入的iptables，将请求重定向到Service的对应的Pod，v1.2版本之后的默认模式。

通过查看iptables规则可以看到：

kube-proxy在 iptables模式下随机选择一个后端Pod，利用Pod就绪探测器验证Pod是否正常，kube-proxy只会把正常的Pod写入iptables，避免流量进入不正常的Pod。

kube-proxy会监视 Kubernetes控制平面对 Service对象和 Endpoints对象的添加和移除操作。对每个 Service，它会在本地 Node上打开一个端口（随机选择）。请求先经过iptables规则，当捕获到达Service的 clusterIP和 Port的请求，并重定向到代理端口（kube-proxy），再由代理端口再代理请求到后端Pod（v1.2版本之前的默认模式）

IPVS模式是利用linux的IPVS模块实现，同样是由kube-proxy实时监视集群的service和endpoint，调用netlink接口相应的创建ipvs规则，由ipvs实现负载均衡访问。IPVS专为负载平衡而设计，并基于内核内哈希表，有更高的网络流量吞吐量（iptables模式在大规模集群比如10000个服务中性能下降显著），并且具有更复杂的负载均衡算法（最小连接、局部性、加权、持久性）。（v1.8以后新支持的）

上面讲的Pod之间调用，采用Service进行抽象，服务之间可以通过clusterIP进行访问调用，不用担心Pod的销毁重建带来IP变动，同时还能实现负载均衡。但是clusterIP也是有可能变动，况且采用IP访问始终不是一种好的方式。通过 DNS和环境变量可以实现通过服务名现在访问。

k8s采用附加组件（CoreDNS）为集群提供DNS服务，会为每个服务创建DNS记录，CoreDNS只为Service和Pod创建DNS记录。kubernetes强烈推荐采用DNS方式.

例如，如果你在 Kubernetes命名空间 my-ns中有一个名为 my-service的服务，则控制平面和 DNS服务共同为 my-service.my-ns创建 DNS记录。 my-ns命名空间中的 Pod应该能够通过按名检索 my-service来找到服务，其他命名空间中的 Pod必须将名称限定为 my-service.my-ns。这些名称将解析为为服务分配的集群 IP。

Kubernetes还支持命名端口的 DNS SRV（服务）记录。如果 my-service.my-ns服务具有名为 http的端口，且协议设置为 TCP，则可以对 _http._tcp.my-service.my-ns执行 DNS SRV查询查询以发现该端口号,"http"以及 IP地址

当 Pod运行在 Node上，kubelet会为每个活跃的 Service添加一组环境变量。简单的{SVCNAME}_SERVICE_HOST和{SVCNAME}_SERVICE_PORT变量。这里 Service的名称需大写，横线被转换成下划线。

举个例子，一个名称为 nginx-svc的 Service暴露了 TCP端口 8080，同时给它分配了 Cluster IP地址 10.0.0.11，这个 Service生成了如下环境变量：

进入example容器，env打印环境变量：

访问Nginx服务可以使用

关于k8s创建命名空间，k8s怎么创建容器的介绍到此结束，希望对大家有所帮助。