Kubernetes 笔记 ongoing

通过命令创建配置文件

在执行任意创建资源的命令时, 都可以通过这种方式来生成对应的配置文件:

kubectl [command] --dry-run=client -o yaml > [filename]

例如这里尝试创建名为 nginx 的 pod:

kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

就会在当前工作目录得到 pod.yaml 文件:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

WARNING

用这种方式得到的配置文件, 通常还需要做进一步处理.

私有镜像仓库的授权

容器镜像位于某个私有仓库, 那么在拉取时就需要提供额外信息.
具体包括: 镜像仓库的链接, 有权限的用户名和密码.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      # 在这里提供 secret 的名称, secret 需要额外创建
      imagePullSecrets: 
        - name: secret-name
      containers:
        - name: my-app
          image: registry-server/my-app:latest

k8s 专门为我们提供了 docker-registry 类型的 secret, 创建命令如下:

kubectl create secret docker-registry SECRET_NAME \
    --docker-server DOCKER_REGISTRY_SERVER \
    --docker-username DOCKER_USER \
    --docker-password DOCKER_PASSWORD

如果使用 GitLab Container Registry, 则可以创建 Deploy Token.
并将用户名和密码, 分别替换上述命令中的 DOCKER_USER 和 DOCKER_PASSWORD.
DOCKER_REGISTRY_SERVER 是镜像仓库的链接, 例如 GitHub 对应 https://ghcr.io.

TIP

通过命令创建 docker-registry 类型的 secret 后, 可以查看其内部的 .dockerconfigjson 字段.
.dockerconfigjson 字段的值, 可以写入 yaml 配置文件, 之后就可以通过配置文件创建 secret.
可以更进一步, 借助 Helm, 将 .dockerconfigjson 的值通过 value.yaml 提供.

删除无用的命名空间

首先需要确保要删除的命名空间是空的,
没有正在运行的 pod, service, deployment 等资源.

kubectl get all --namespace [namespace-name]

如果确认命名空间未被使用, 则可以使用以下命令删除:

kubectl delete namespace [namespace-name]

WARNING

若删除命名空间, 则会同时删除此命名空间下的所有资源.

命名空间的使用场景

INFO

参考 Kubernetes Namespace: A Practical Guide and 6 Tips for Success.

namespace 最显著的特点是 "隔离得很彻底".
例如 secret 这个资源只能被相同 namespace 内的其他资源使用.
总的来讲, 如果这种 "彻底的隔离" 是目的, 就应该划分为不同的命名空间.

同一个 namespace 中同类型资源不能使用相同的名字, 但是不同 namespace 中的资源可以重名.
这个特点可以避免命名冲突, 也可以让资源的名称更简短, 让人识别起来更容易.

不同的命名空间可用于区分测试与生产环境, 以避免生产环境中的用户受到影响.
或者对于游戏服务器来说, 可以将正式服和测试服分别放在不同的命名空间中.

可以为每个命名空间设置资源配额, 网络则略, 和 RBAC (基于角色的访问控制).
这对大型企业而言有用, 因为不同团队负责的不同产品位于不同的 namespace 中, 互不影响.

namespace 将相互有关联的 k8s 资源联系起来, 使其更易管理, 检测, 排除故障.

使用 namespace 还是 label 来隔离测试环境与生产环境? (ChatGPT)

Label 和 Namespace 都可以用于在 Kubernetes 中隔离测试环境和开发环境.
它们是两种不同的概念, 可以单独或结合使用, 具体选择取决于你的需求和组织策略.

使用Namespace隔离:

• 优势:

  • Namespace 提供了一个物理上的隔离单元, 允许在同一集群中创建多个相互隔离的环境.
  • 可以使用 RBAC (Role-Based Access Control) 在 Namespace 级别定义访问权限, 确保不同环境的资源安全.
  • 不同 Namespace 可以有不同的网络策略, 进一步隔离流量.

• 注意事项:

  • Namespace 隔离是物理隔离, 适用于需要更彻底隔离的场景, 但可能涉及更多的资源开销.

使用Label隔离:

• 优势:

  • Label 是一种在逻辑上对资源进行标记的方式, 可以更灵活地应用于各种场景.
  • 可以在同一个 Namespace 内使用 Label 对资源进行分类, 实现逻辑上的隔离.
  • 适用于场景中资源共享, 但需要逻辑隔离的情况.

• 注意事项:

  • Label 隔离更注重逻辑上的划分, 可能需要更仔细的命名和管理, 以确保正确应用到资源上.
  • 对于一些涉及安全性的场景, Namespace 提供了更为严格的隔离.

选择方案的考虑因素:

1. 隔离级别: 如果你需要更彻底的隔离, 尤其是在安全性要求较高的场景下, 使用 Namespace 可能更合适. 如果逻辑隔离已经足够, 可以考虑使用 Label.
2. 资源开销: Namespace 可能会涉及更多的资源开销, 因为它提供了物理隔离. 在资源有限的情况下, 可以考虑使用 Label 实现逻辑隔离.
3. 管理复杂性: Namespace 在管理上可能更直观, 特别是当需要对 RBAC, 网络策略等进行配置时. Label 虽然灵活, 但也需要更仔细的管理.

通常, 一个综合的策略是使用 Namespace 进行物理隔离, 同时在每个 Namespace 内使用 Label 进行逻辑划分. 这样可以兼顾隔离性和灵活性, 满足不同场景的需求.

resource requests and limits

技术细节

参考 How to Set Up Kubernetes Requests and Limits - James Walker.

resources:
  requests:
    cpu: 100m     # 作为权重, 权重更高的 container 可以使用更多的 CPU 资源
    memory: 128Mi # 若已存在的 requests.memory 加起来超过 node memory, 则不再调度新的
  limits:
    cpu: 250m     # 限制单个 container 可使用的 CPU 资源上限 (建议不要设置这个值)
    memory: 500Mi # limits.memroy 限制单个 container 可使用的内存上限, 超出会被 kill

• 如果忽略 requests, 只设置 limits, 那么 k8s 会自动设置同规格的 requests.
• 如果超过 limits.memory, 就会触发 out-of-memory (OOM) kill, 这通常意味着容器 重启.
• 如果超过 limits.cpu:
  • cpu 资源不够用时, 则会被 k8s 限制对 cpu 资源的使用.
  • cpu 资源有富余时, 则什么都不会发生, 此时允许超过 cpu limit.

最佳实践

• 不要设置 limits.cpu, 而应该只通过 requests.cpu 来按权重分配 cpu 资源.
• 永远将 limits.memory 和 requests.memory 设置成相同的值.
• 经常检查并调整 requests 和 limits. 通过 kubectl top pod 来检测资源实际使用情况.
• 如有必要, 考虑再用 Resource Quotas 来设置 namespace 层面的资源配合.