【k8s系列】基础概念总结

【k8s系列】基础概念总结1

源自专栏《docker常用命令系列&&k8s系列目录导航》

Pod

在Kubernetes中，Pod是最小的可部署计算单元，它是一组（一个或多个）容器的集合，这些容器共享存储、网络和运行时的声明。Pod中的容器总是并置（colocated）的，并且一同调度，在共享的上下文中运行。Pod建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器相对紧密地耦合在一起。

Pod的组成

Pod的共享上下文包括一组Linux名字空间、控制组（cgroup）以及可能一些其他的隔离方面，即用来隔离容器的技术。在Pod的上下文中，每个独立的应用可能会进一步实施隔离。Pod类似于共享名字空间并共享文件系统卷的一组容器。

Pod的用途

Kubernetes集群中的Pod主要有两种用途：

1. 运行单个容器的Pod。这是最常见的Kubernetes用例，Pod被看作单个容器的包装器，Kubernetes直接管理Pod而不是容器。
2. 运行多个协同工作的容器的Pod。Pod可以封装由紧密耦合且需要共享资源的多个并置容器组成的应用。这些位于同一位置的容器构成一个内聚单元。

Pod的创建和管理

通常，Pod不是直接创建的，而是通过工作负载资源（如Deployment或Job）创建的。这些工作负载资源的控制器能够处理副本的管理、上线，并在Pod失效时提供自愈能力。

Pod的网络和存储

Pod为其成员容器提供了网络和存储的共享资源。所有容器都可以访问共享卷，从而允许这些容器共享数据。每个Pod都在每个地址族中获得一个唯一的IP地址，Pod中的每个容器共享网络名字空间，包括IP地址和网络端口。

Pod的操作系统

从Kubernetes v1.25开始，应该将.spec.os.name字段设置为windows或linux以表示希望Pod运行在哪个操作系统之上。这有助于确定性地标识Pod的操作系统并用于验证。

Pod的更新与替换

当工作负载的Pod模板被改变时，控制器会基于更新的模板创建新的Pod对象而不是对现有Pod执行更新或者修补操作。Kubernetes并不禁止直接管理Pod，但对运行中的Pod的某些字段执行就地更新操作还是可能的，有一定的限制。

Pod的资源共享和通信

Pod使它的成员容器间能够进行数据共享和通信。Pod中的存储卷可以被所有容器访问，从而允许这些容器共享数据。Pod中的容器可以使用localhost互相通信。

容器的特权模式

Pod中的所有容器都可以在特权模式下运行，以使用原本无法访问的操作系统管理权能。这适用于Linux和Windows容器。

静态Pod

静态Pod直接由特定节点上的kubelet守护进程管理，不需要API服务器看到它们。它们通常用于运行自托管的控制面。

Pod管理多个容器

Pod支持构造内聚的服务单元的多个协作进程（形式为容器）。Pod中的容器被自动并置到集群中的同一物理机或虚拟机上，并可以一起进行调度。

容器探针

探针是由kubelet对容器执行的定期诊断，可以执行三种动作：ExecAction、TCPSocketAction和HTTPGetAction。

通过这些机制，Kubernetes提供了灵活的Pod管理，以适应不同的应用场景和需求。

namespace

在Kubernetes中，名字空间是一种非常重要的概念，它提供了一种机制，允许集群中的资源被划分为相互隔离的组。这种设计使得在同一集群中运行多个项目或团队的工作负载成为可能，而不会相互干扰。下面，我将详细介绍Kubernetes名字空间的概念、使用场景、管理方式以及相关的操作。

概念

名字空间确保了同一名字空间内的资源名称是唯一的，但不同名字空间之间的资源名称可以相同。这种作用域限制仅适用于带有名字空间的对象，如Deployment、Service等，而对于集群范围的对象，如StorageClass、Node、PersistentVolume等，名字空间的作用域并不适用。

使用场景

名字空间特别适用于存在很多跨多个团队或项目的用户的场景。对于只有几到几十个用户的小型集群，可能不需要创建或考虑名字空间。名字空间为名称提供了一个范围，并允许通过资源配额在多个用户之间划分集群资源。此外，名字空间不能相互嵌套，每个Kubernetes资源只能在一个名字空间中。

初始名字空间

Kubernetes启动时会创建四个初始名字空间：

• default：默认名字空间，用于新创建的资源，如果未指定其他名字空间。
• kube-node-lease：包含与各个节点关联的Lease对象，用于节点心跳和故障检测。
• kube-public：所有客户端(包括未经身份验证的客户端)都可以读取的名字空间，主要用于集群使用，以便某些资源需要在整个集群中可见可读。
• kube-system：用于Kubernetes系统创建的对象。

管理名字空间

名字空间的创建和删除可以在名字空间的管理指南文档中找到。查看集群中现存的名字空间可以使用kubectl命令，例如：

kubectl get namespaces

为当前请求设置名字空间，可以使用--namespace参数，例如：

kubectl run nginx --image=nginx --namespace=<namespace-name>

为了设置名字空间偏好，即在对应上下文中永久保存名字空间，可以使用：

kubectl config set-context --current --namespace=<namespace-name>

名字空间和DNS

Kubernetes为每个服务创建相应的DNS条目，形式为<service-name>.<namespace-name>.svc.cluster.local。这意味着如果容器只使用<service-name>，它将被解析到本地名字空间的服务。如果需要跨名字空间访问服务，则需要使用完全限定域名（FQDN）。

查看资源是否在名字空间中

大多数Kubernetes资源位于某些名字空间中，但名字空间资源本身并不在名字空间中。可以使用以下命令查看哪些资源在名字空间中，哪些不在：

# 位于名字空间中的资源
kubectl api-resources --namespaced=true

# 不在名字空间中的资源
kubectl api-resources --namespaced=false

自动打标签

从Kubernetes 1.22版本开始，控制面会为所有名字空间设置一个不可变更的标签kubernetes.io/metadata.name，其值为名字空间的名称。

通过以上信息，我们可以看到Kubernetes名字空间为集群管理和多租户环境提供了强大的支持。正确使用和管理名字空间，可以帮助你更有效地组织和隔离集群资源，提高Kubernetes集群的可用性和安全性。

Kubernetes中的持久卷（Persistent Volume，PV）是一种存储资源，它与Pod不同，具有独立于使用它的Pod的生命周期。PV是集群中的一块存储，可以由管理员事先准备，或者使用存储类（Storage Class）动态准备。以下是关于Kubernetes持久卷的一些关键概念：

持久卷和持久卷申领（PersistentVolumeClaim，PVC）

• 持久卷（PV）：是集群中的一块存储，具有独立生命周期，可以由管理员事先准备或动态创建。
• 持久卷申领（PVC）：是用户对存储的请求，类似于Pod对节点资源的请求。PVC可以请求特定的大小和访问模式。

存储类（StorageClass）

存储类资源允许管理员提供具有不同属性的PV，而不会将存储实现的细节暴露给用户。用户可以通过PVC请求特定的存储类。

Deployment

Kubernetes中的Deployment是一种控制器，用于管理没有状态的应用的一组Pod。它允许以声明式的方式更新运行中的Pods，提供应用更新和版本管理的能力。以下是关于Kubernetes Deployment的一些关键概念：

Deployment的用例

• 创建Deployment以上线ReplicaSet并在后台创建Pod。
• 通过更新Deployment的PodTemplateSpec来声明Pod的新状态，实现滚动更新。
• 如果Deployment当前状态不稳定，可以回滚到之前的版本。
• 扩大Deployment规模以承担更多负载。
• 暂停Deployment更新以应用对PodTemplateSpec的多项修改，然后恢复更新。

Deployment的示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

在这个示例中，创建了一个名为nginx-deployment的Deployment，它创建了一个ReplicaSet并启动了三个Nginx Pod副本。

Deployment的更新

更新Deployment时，可以更改Pod模板中的镜像或其他配置。Deployment控制器会以受控速率创建新的ReplicaSet并逐步迁移Pod，同时确保服务的可用性。

Deployment的状态

Deployment的状态可以通过kubectl get deployments命令查看，包括就绪副本数、更新的副本数、可用副本数等。

Deployment的回滚

如果Deployment更新后不稳定，可以使用kubectl rollout undo命令回滚到之前的稳定版本。

Deployment的缩放

可以使用kubectl scale命令来扩大或缩小Deployment的规模。

Deployment的暂停和恢复

在更新Deployment时，可以暂停上线过程以应用多项修改，然后再恢复上线过程。

Deployment的清理策略

可以通过设置.spec.revisionHistoryLimit字段来指定保留旧ReplicaSet的数量，多余的将被垃圾回收。

Deployment的金丝雀部署

可以使用多个Deployment来实现金丝雀部署，每个版本一个Deployment，以向用户子集或服务器子集上线版本。

Deployment的编写和配置

Deployment需要.apiVersion、.kind和.metadata字段，以及.spec部分，其中包含Pod模板、副本数、选择算符和策略等。

Deployment的滚动更新策略

可以指定maxUnavailable和maxSurge参数来控制滚动更新过程，确保在更新期间服务的可用性和过度扩展。

Deployment的进度期限

通过.spec.progressDeadlineSeconds字段可以设置Deployment进展的超时时间，超过这个时间Deployment控制器会报告进展失败。

Deployment的最短就绪时间

.spec.minReadySeconds字段用于指定新创建的Pod在被视为可用之前的最小就绪时间。

通过这些机制，Kubernetes的Deployment控制器提供了强大的应用部署和管理功能，使得在Kubernetes集群中运行和管理无状态应用变得更加容易和可靠。

Deployment-ReplicaSet

Kubernetes中的ReplicaSet是一种控制器，它的主要作用是确保指定数量的Pod副本始终运行。ReplicaSet通过选择算符来管理一组Pod，自动创建和删除Pod以维持副本数量达到用户的期望值。以下是关于Kubernetes ReplicaSet的一些关键概念：

ReplicaSet的工作原理

• 副本数量维持：ReplicaSet保证在任何给定时间都有一定数量的Pod副本运行。
• Pod模板：ReplicaSet使用Pod模板来创建新的Pod，以满足副本数量的要求。

使用ReplicaSet的场景

• 保证副本数量：ReplicaSet确保指定数量的Pod副本始终运行，适用于无状态服务的部署。
• 自动管理：通常，ReplicaSet由更高级的控制器（如Deployment）自动管理，提供声明式更新和其他功能。