K8s —基础指南（K8s - Basic Guide）

K8s ---基础指南

K8s 是云上部署容器化应用的事实标准。它作为容器的强大编排器，管理容器重启、负载均衡等任务。

理解 Kubernetes 架构

Kubernetes 的关键功能之一是为访问 Pod 提供稳定的端点，尽管 Pod 本身是短暂的。Kubernetes 服务有效地弥补了这一差距。

在 Docker Desktop 中启用 Kubernetes，等待其启动。

要检查 kubectl 正在与哪个集群交互，请使用：

kubectl config current-context

为什么使用 Pod？

Pod 是 Kubernetes 的基本对象，允许你充分利用 Kubernetes 的潜力。Pod 封装一个或多个容器，并为它们提供统一的环境。

Pod 定义示例

apiVersion: v1
kind:Pod
metadata:
name:geeky
labels:
    app.kubernetes.io/name:geeky           # 标准，最广泛的标签
    app.kubernetes.io/component:frontend# 指定角色
    app.kubernetes.io/instance:frontend   # 细粒度控制
spec:
containers:
-name:geeky
    image:<Image>
    env:
      -name:SERVICE_HOST
        value:expected-url# 通过集群 IP 服务实现前后端通信
    resources:
      requests:              # 最小资源分配
        memory:"128Mi"      # 内存，单位 Mebibytes
        cpu:"200m"         # CPU，单位 millicores
      limits:                # 资源上限
        memory:"128Mi"
    ports:
      -containerPort:3000

关键 `kubectl` 命令

应用 Pod 配置：

kubectl apply -f pod_config_name.yaml
列出 Pod：

kubectl get pods
描述 Pod 详情：

kubectl describe pod pod_name
查看日志：

kubectl logs pod_name
实时日志流：

kubectl logs -f pod_name
端口转发以本地访问：

kubectl port-forward pod_name 8080:3000

访问地址：localhost:8080
按标签或名称删除 Pod：

kubectl delete pod -l "app.kubernetes.io/name=geeky" kubectl delete pod geeky
删除所有 Pod：

kubectl delete pods --all

网络隔离与通信

当你有多个 Pod 时，Kubernetes 使用网络命名空间确保网络级隔离，逻辑上分离资源。为了实现 Pod 之间的通信，Kubernetes 使用服务。这允许无缝交互，同时在需要时保持严格的隔离。

服务：持久端点

Kubernetes 服务为应用程序提供持久端点。它们通过提供稳定的虚拟 IP 地址来解决短暂 Pod 带来的挑战。主要有两种类型的服务：NodePort 和 ClusterIP。

NodePort 服务

NodePort 服务将应用程序暴露在集群中每个节点的 IP 地址的特定端口上。虽然对原型开发有用，但不适合生产环境，因为暴露机器端口可能存在安全风险。NodePort 范围从 30000 到 32767。

NodePort 服务定义示例：

apiVersion: v1
kind:Service
metadata:
name:geeky
spec:
type:NodePort
selector:
    app.kubernetes.io/instance:frontend
ports:
-port:3000
    targetPort:3000
    nodePort:32000

应用服务配置：

kubectl apply -f service-definition.yaml
这将在 localhost:32000 上本地暴露应用程序，将请求转发到标记为 frontend 的 Pod。

ClusterIP 服务

ClusterIP 服务为集群内的应用程序提供稳定的内部 IP 地址和端口。这非常适合 Pod 之间的内部通信。

ClusterIP 服务定义示例：

apiVersion: v1
kind:Service
metadata:
name:geeky
spec:
selector:
    app.kubernetes.io/component:frontend
ports:
-port:3000
    targetPort:3000

该服务将所有流量转发到匹配标签 frontend 的任何 Pod。当流量到达 Pod 时，它确保 Pod 内的目标端口可访问且响应。
列出服务：

kubectl get services

命名空间：资源组织

Kubernetes 中的命名空间允许你逻辑上分离和分组资源，便于管理和应用基于角色的访问控制（RBAC）。

关键 `kubectl` 命令

列出命名空间：

kubectl get namespaces
列出命名空间中的 Pod：

kubectl get pods -n default
删除命名空间中的所有 Pod：

kubectl delete pods --all -n default
创建命名空间：

kubectl create namespace geeky-app
将资源应用到命名空间：

kubectl apply -f . -n geeky-app
列出命名空间中的资源：

kubectl get pods,services -n geeky-app

在元数据中定义命名空间

在资源配置的元数据部分直接定义命名空间，确保资源在指定的命名空间中创建。这通常更方便，并防止在 kubectl 命令中手动指定命名空间。

Kubernetes 弹性：幕后机制

Kubernetes 通过其控制器确保弹性和自愈：

restartPolicy: 默认情况下，restartPolicy 设置为 Always，确保 Pod 在失败时自动重启。
内存不足（OOM）：当 Pod 超出其内存限制时，它会被标记为 OOMKilled。Kubernetes 会重启此类 Pod 以保持弹性。

Kubernetes 控制器

期望状态：控制器比较 Pod 的当前状态与期望状态，采取行动以调和任何差异。
持续监控： Kubernetes 持续监控容器的健康状况，并在需要时采取纠正措施。

部署和 Pod 副本

Kubernetes 中的部署提供了一种声明式的方式来管理应用程序更新和扩展。当你创建部署时，它会自动创建一个 ReplicaSet，确保始终运行指定数量的 Pod 副本。

部署定义示例

apiVersion: apps/v1
kind:Deployment
metadata:
name:geeky
namespace:geeky-ns
spec:
replicas:3
selector:
    matchLabels:
      app.kubernetes.io/instance:geeky-api
template:
    metadata:
      labels:
        app.kubernetes.io/name:geeky
        app.kubernetes.io/component:backend
        app.kubernetes.io/instance:backend
    spec:
      containers:
      -name:geeky
        image:<Image>
        resources:
          requests:
            memory:"128Mi"
            cpu:"200m"
          limits:
            memory:"128Mi"
        ports:
          -containerPort:3000

部署的关键点

通过部署管理你的 Pod，而不是独立的 Pod 原语。
列出命名空间中的部署：

kubectl get deployments -n geeky-ns
部署默认提供负载均衡，使用轮询方式。

幕后机制

部署控制器根据部署规范创建 ReplicaSet。
ReplicaSet 确保运行所需数量的 Pod 副本。
ReplicaSet 控制器监控 Pod 的状态，并在必要时重新创建它们。
部署控制器管理部署的整个生命周期，包括更新和回滚。

通过在部署对象中声明期望状态，Kubernetes 会处理其余部分，确保你的应用程序按指定运行和扩展。

滚动更新和回滚

Kubernetes 部署使你能够使用最小停机时间无缝更新应用程序，采用滚动更新策略。部署控制器逐步用新 Pod 替换旧 Pod，确保更新过程中的持续可用性。

滚动更新策略

你可以使用部署规范中的 strategy 字段控制更新过程。例如：

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # 更新期间最大不可用 Pod 数量
      maxSurge: 1         # 更新期间最大额外创建的 Pod 数量

回滚更改

如果部署更新导致问题，你可以轻松回滚到之前的稳定状态。

回滚到之前的版本：

kubectl rollout undo deployment/<name> -n <namespace>

探针：确保应用程序健康

Kubernetes 提供存活探针和就绪探针来监控容器的健康和就绪状态。这些探针确保你的应用程序保持弹性和响应性。

存活探针

存活探针检查容器是否正常运行。如果探针失败，Kubernetes 会重启容器。

就绪探针

就绪探针确定容器是否准备好处理流量。如果探针失败，容器将从服务端点中排除。

探针配置示例

livenessProbe:
  httpGet:
    path:/healthz
    port:8080
initialDelaySeconds:25
periodSeconds:5
readinessProbe:
httpGet:
    path:/ready
    port:8080
periodSeconds:5

关键点：
使用存活探针检测并重启不健康的容器。
使用就绪探针确定容器何时准备好开始接受流量。
这些探针共同帮助维护应用程序的健康和可用性。

Kubernetes 中的存储编排

Kubernetes 使用持久卷（PV）和持久卷声明（PVC）简化了有状态应用程序的存储管理。

带存储的 StatefulSet 示例

StatefulSet 非常适合管理有状态应用程序，因为它们为每个 Pod 提供稳定的标识符和存储。

apiVersion: apps/v1
kind:StatefulSet
metadata:
name:database
namespace:database-ns
spec:
serviceName:db
replicas:2
selector:
    matchLabels:
      app.kubernetes.io/instance:db
template:
    metadata:
      labels:
        app.kubernetes.io/name:geeky
        app.kubernetes.io/component:db
        app.kubernetes.io/instance:db
    spec:
      containers:
      -name:database
        image:registry.k8s.io/nginx-slim:0.8
        volumeMounts:
        -name:db-persistent-storage
          mountPath:/data/db
volumeClaimTemplates:
-metadata:
      name:db-persistent-storage
    spec:
      accessModes:["ReadWriteOnce"]
      resources:
        requests:
          storage:1Gi

关键组件

持久卷（PV）：表示实际的存储资源。
持久卷声明（PVC）： Pod 对存储的请求。
卷声明模板：自动为每个 StatefulSet Pod 生成 PVC。

存储编排的好处

自动配置和附加存储卷。
在 Pod 重启或重新调度时无缝保持数据持久性。
内置机制用于维护 Pod 身份和状态。
列出命名空间中的 PVC：

kubectl get pvc -n database-ns

配置管理

ConfigMap 和 Secret

ConfigMap：存储非机密的纯文本数据。

ConfigMap 定义示例：

apiVersion: v1
kind:ConfigMap
metadata:
name:geeky-config
namespace:geeky-ns
data:
player_initial_lives:"3"
ui_properties_file_name:"user-interface.properties"

Secret：安全地存储敏感数据，以 Base64 编码。

Secret 定义示例：

apiVersion: v1
kind:Secret
metadata:
name:geeky-secret
namespace:geeky-ns
type:Opaque
data:
    username:YWRtaW4=# base64 编码的 'admin'
    password:dDBwLVMzY3IzdA==# base64 编码的 't0p-S3cr3t'

水平 Pod 自动扩展

Kubernetes 支持根据观察到的指标（如 CPU 或内存使用率）自动扩展 Pod。

关键概念

Metrics Server： Kubernetes 通过 metrics-server 收集资源使用指标。

kubectl top pods -n geeky-ns
HorizontalPodAutoscaler 定义：

apiVersion: autoscaling/v2
kind:HorizontalPodAutoscaler
metadata:
name:geeky
namespace:geeky-ns
spec:
scaleTargetRef:
apiVersion:apps/v1
kind:Deployment
name:geeky
minReplicas:1
maxReplicas:10
metrics:
-type:Resource
resource:
name:cpu
target:
type:Utilization
averageUtilization:50
获取 HPA 状态：

kubectl get hpa -n geeky-ns

注意事项

水平 Pod 自动扩展器根据观察到的 CPU 使用率（最常见）自动调整部署中的 Pod 数量。
自动扩展行为： HPA 将增加或减少副本数以维持目标 CPU 使用率。
扩展范围： Pod 数量将根据 CPU 使用率在 1 到 10 之间调整。
资源指标：虽然此示例使用 CPU，但 HPA 也可以使用内存或自定义指标。
目标使用率： 50% 的目标使用率是常见的起点，但可以根据应用程序需求进行调整。
命名空间范围： HPA 是命名空间特定的，允许在应用程序的不同部分应用隔离的扩展策略。
扩展算法： Kubernetes 使用控制循环定期根据观察到的指标调整副本数。

Kubernetes 中的 Ingress 控制器

Kubernetes 中的 Ingress 控制器充当反向代理，管理外部 HTTP(S) 流量并将其路由到正确的内部服务。与 NodePort 不同，NodePort 在每个节点上暴露服务，而 Ingress 控制器集中路由过程，使其更高效和可扩展。

设置 Ingress 控制器

要使用 Ingress，请在 Kubernetes 集群中下载并安装 Ingress 控制器（如 NGINX）。

基本 Ingress 配置示例：

以下 YAML 定义了一个基本的 Ingress 资源，指定了如何将传入流量路由到内部服务。

apiVersion: networking.k8s.io/v1
kind:Ingress
metadata:
name:geeky
labels:
name:geeky
namespace:geeky-ns
spec:
ingressClassName:nginx
rules:
-host:url
http:
paths:
-pathType:Prefix
path:"/"
backend:
service:
name:frontend
port:
number:3000
此设置将针对 url 的 HTTP 请求路由到端口 3000 上的 "frontend" 服务。

查看可用的 Ingress 类：

要查看可用的 Ingress 类，请运行：

kubectl get ingressclass

生产环境中的流量限制

在开发环境中，配置通常是宽松的，但在生产环境中，你需要实施更严格的规则。

例如，购买域名后，你可以设置规则以限制流量到特定主机：

spec:
  rules:
-host:geeky.example.com
    http:
      paths:
      -path:"/"
        pathType:Prefix
        backend:
          service:
            name:geeky
            port:
              number:3000

此设置确保只有来自 geeky.example.com 的流量可以访问服务，通过拒绝来自其他主机的请求提供额外的安全性。

Ingress 控制器和 AWS 中的负载均衡器

将 Ingress 控制器（如 NGINX）部署到 AWS 集群时，会自动配置负载均衡器以处理外部流量。

NGINX Ingress 控制器设置示例：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
kubectl get services -n nginx

在生产环境中：

设置负载均衡器后，你可以通过指定主机创建更严格的 Ingress 规则。

Ingress 配置示例：

apiVersion: networking.k8s.io/v1
kind:Ingress
metadata:
name:geeky-ingress
namespace:geeky-ns
spec:
ingressClassName:nginx
rules:
-host:geeky.example.com
    http:
      paths:
      -pathType:Prefix
        path:"/"
        backend:
          service:
            name:geeky
            port:
              number:3000

这将限制对服务的访问仅限于 geeky.example.com。

Kubernetes 中的 Helm

Helm 是 Kubernetes 的强大包管理器，简化了应用程序的部署、管理和扩展。通过使用 Helm Chart，你可以将 Kubernetes 资源作为单个单元进行管理，简化部署、升级和回滚。

Helm 基础

Helm Chart： Helm Chart 是一组定义相关 Kubernetes 资源的文件。
Release： Release 是 Helm Chart 的部署。你可以使用 Helm 命令安装或卸载 Release。

典型的 Helm Chart 结构：

mychart/
  ├── Chart.yaml          # 包含 Chart 信息
  ├── values.yaml         # 默认配置值
  └── templates/          # 模板文件目录
      ├── deployment.yaml
      ├── service.yaml
      └── ingress.yaml

values.yaml：存储模板的值（如 deployment.yaml 或 service.yaml）。
Chart.yaml：包含有关 Chart 的元数据。

安装和管理 Helm Chart

1. 安装 Helm Chart：

helm install geeky geeky-1.0.0.tgz

2. 卸载 Helm Release：

helm uninstall geeky

3. Helm 升级：

要升级 Release，请使用：

helm upgrade geeky geeky-1.0.2.tgz
或者，从当前目录升级：

helm upgrade geeky . -n geeky-ns

4. 回滚 Helm Release：

如果需要，你可以回滚 Release：

helm rollback geeky 2 -n geeky-ns

5. Helm 打包：

要打包 Helm Chart：

helm package .

6. 列出所有 Helm Release：

helm list -A

使用外部 Helm 仓库

Helm 支持外部仓库，如 Bitnami，它提供了 Elasticsearch 和 MySQL 等流行服务的 Chart。

1. 添加 Helm 仓库：

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

2. 使用自定义值安装 Chart：

helm install geeky bitnami/mongodb --version 1x.x.1x -f values.yaml -n geeky-ns

此命令使用自定义配置安装 MongoDB。

3. 移除 Helm 仓库：

helm repo remove bitnami

Kubernetes 中的 Operator

Kubernetes Operator 通过使用自定义资源管理复杂应用程序，扩展了 Kubernetes 的功能。这些资源不是 Kubernetes 默认的一部分，而是由 Operator 定义和控制。

核心概念

自定义资源（CR）： Operator 引入了扩展 Kubernetes API 的新资源，针对特定应用程序定制。
自定义控制器： Operator 实现控制器，监控自定义资源并管理相应的 Kubernetes 资源（如 Pod、服务、ConfigMap）。

Operator 的工作原理

创建自定义资源：当你创建自定义资源（如 PostgreSQL 集群）时，Operator 的控制器会检测到它并创建必要的 Kubernetes 资源。
监控资源： Operator 持续监控并调整资源以维持期望状态。

PostgreSQL 集群的自定义资源示例：

apiVersion: database.example.com/v1
kind:PostgresCluster
metadata:
name:my-db
spec:
version:"13"
instances:3
storage:
    size:1Gi

应用自定义资源：

kubectl apply -f postgres-cluster.yaml

监控自定义和原生资源：

kubectl get postgresclusters
kubectl get pods

常见的 Operator 和用例

Operator 可用于管理各种软件系统，包括：

数据库： PostgreSQL、MongoDB、MySQL、Elasticsearch
消息队列： Apache Kafka、RabbitMQ
监控： Prometheus
服务网格： Istio

使用 eksctl 部署到 AWS

使用 eksctl 将 Kubernetes 部署到 AWS 提供了管理多个工作节点集群的灵活性。

1. 安装 eksctl：

choco install -y eksctl eksctl version

2. 使用 eksctl 创建集群：

创建集群的示例命令：

eksctl create cluster \
--name my-cluster \
--region us-west-2 \
--node-type t3.medium \
--nodes 3

此命令创建一个包含 3 个工作节点的集群，并更新 kubectl 上下文以便轻松交互。

最终清理

完成 Kubernetes 集群和服务后，执行适当的清理以释放资源并确保一切清理干净。

1. 删除 Kubernetes 集群：

如果你使用 AWS 和 eksctl 管理集群，可以使用以下命令删除整个集群：

eksctl delete cluster --name my-cluster
这将删除与集群关联的所有资源，包括 EC2 实例、VPC 和其他托管服务。

2. Docker 清理：

使用 Docker 后，最好删除未使用的资源（镜像、容器、网络等）以释放空间。
要删除所有未使用的 Docker 对象，包括未与容器关联的镜像、容器、卷和网络：

docker system prune -a
此命令将在删除这些资源之前请求确认，因此请确保你不需要其中的任何资源。

3. 在本地机器上禁用 Kubernetes：

如果你在本地使用 kubectl 与 Kubernetes 集群交互，完成后你可能希望禁用它。
你可以简单地删除 Kubernetes 配置文件或使用以下命令重置：

kubectl config unset current-context

4. 从 Docker 中删除镜像和容器：

要手动从 Docker 中删除镜像和容器，可以使用以下命令：

删除所有停止的容器：

docker container prune
删除所有未使用的镜像：

docker image prune -a

通过遵循这些清理步骤，你可以确保没有不必要的资源被留下，优化你的本地机器和云环境。

K8s —基础指南（K8s - Basic Guide）