八股取士--docker&k8s

一、Docker 基础

Docker 和虚拟机的区别是什么？
- 答案：
  - 虚拟机（VM）：虚拟化硬件，每个 VM 有独立操作系统，资源占用高，启动慢。
  - Docker：容器化应用，共享宿主机内核，轻量级，秒级启动，资源利用率高。
什么是 Docker 镜像（Image）和容器（Container）？
- 答案：
  - 镜像：只读模板，包含运行应用所需的文件系统和配置。
  - 容器：镜像的运行实例，具有可写层，隔离的进程空间。

如何构建一个 Docker 镜像？

答案：

dockerfile 复制代码

# Dockerfile 示例
FROM alpine:3.14
RUN apk add --no-cache python3
COPY app.py /app/
CMD ["python3", "/app/app.py"]

bash 复制代码

docker build -t my-app:1.0 .

Dockerfile 中 COPY 和 ADD 的区别是什么？
- 答案：
  - COPY：仅复制本地文件到镜像。
  - ADD：支持复制并解压 tar 文件，或从 URL 下载文件（不推荐，行为不透明）。
如何减少 Docker 镜像大小？
- 答案：
  - 使用小基础镜像（如 alpine）。
  - 多阶段构建（分离编译和运行环境）。
  - 合并 RUN 命令，清理缓存。

二、Docker 网络与存储

Docker 的网络模式有哪些？
- 答案：
  - bridge（默认）：容器通过虚拟网桥连接到宿主机。
  - host：容器共享宿主机网络命名空间。
  - none：无网络配置。
  - overlay：跨主机的容器通信（用于 Swarm）。
如何让容器访问宿主机上的服务？
- 答案：
  - 使用 host.docker.internal（Mac/Windows）或 --network=host。
  - 直接访问宿主机 IP（如 172.17.0.1）。
Docker 数据卷（Volume）的作用是什么？如何挂载？
- 答案：
  - 作用：持久化容器数据，避免数据丢失。
  - 挂载方式 ：
    bash 复制代码
```
# 创建命名卷
docker volume create my-vol
docker run -v my-vol:/data alpine
# 挂载主机目录
docker run -v /host/path:/container/path alpine
```

三、Docker 实战与优化

如何查看容器日志？

答案：

bash 复制代码

docker logs <container-id>
docker logs --tail 100 -f <container-id>  # 实时查看最后100行

如何进入运行中的容器执行命令？
- 答案：
  bash 复制代码
```
docker exec -it <container-id> /bin/sh
```

Docker Compose 的作用是什么？编写一个简单的 Compose 文件。

答案：

yaml 复制代码

version: '3'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
  redis:
    image: redis:alpine

如何清理 Docker 占用的磁盘空间？

答案：

bash 复制代码

docker system prune -a -f  # 清理所有未使用的镜像、容器、网络

四、Kubernetes 基础

Kubernetes 的核心组件有哪些？
- 答案：
  - Master 节点 ：
    - API Server：集群入口，处理 REST 请求。
    - Scheduler：分配 Pod 到 Node。
    - Controller Manager：维护集群状态（如副本数）。
    - etcd：键值存储，保存集群状态。
  - Worker 节点 ：
    - Kubelet：管理 Pod 生命周期。
    - Kube-Proxy：维护网络规则。
什么是 Pod？为什么需要 Pod？
- 答案：
  - Pod：最小调度单元，包含一个或多个容器，共享网络和存储。
  - 作用：将紧密耦合的容器组合在一起（如应用 + 日志收集 Sidecar）。
Deployment 和 StatefulSet 的区别是什么？
- 答案：
  - Deployment：管理无状态应用，支持滚动更新、回滚。
  - StatefulSet：管理有状态应用（如数据库），提供稳定的网络标识和持久存储。

五、Kubernetes 核心概念

Service 的作用是什么？有哪些类型？
- 答案：
  - 作用：为一组 Pod 提供稳定的 IP 和 DNS 名称，实现负载均衡。
  - 类型：
    - ClusterIP（默认）：集群内部访问。
    - NodePort：通过节点端口暴露服务。
    - LoadBalancer：云平台提供的外部负载均衡器。
    - ExternalName：映射到外部服务。

如何通过 Ingress 暴露服务？

答案：

yaml 复制代码

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

ConfigMap 和 Secret 的作用是什么？
- 答案：
  - ConfigMap：存储非敏感配置（如环境变量、配置文件）。
  - Secret：存储敏感数据（如密码、密钥），Base64 编码（非加密）。

六、Kubernetes 运维与调试

如何查看 Pod 的日志？

答案：

bash 复制代码

kubectl logs <pod-name>
kubectl logs -f <pod-name> -c <container-name>  # 多容器 Pod

如何排查 Pod 无法启动的问题？

答案：

bash 复制代码

kubectl describe pod <pod-name>  # 查看事件
kubectl logs <pod-name> --previous  # 查看前一个容器的日志（崩溃时）

如何实现 Pod 的滚动更新？

答案：

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%      # 最大新增 Pod 数
      maxUnavailable: 25% # 最大不可用 Pod 数

七、Kubernetes 高级特性

什么是 HPA（Horizontal Pod Autoscaler）？如何配置？

答案：

作用：根据 CPU 或自定义指标自动扩缩 Pod 数量。

配置：

yaml 复制代码

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

如何通过 Helm 管理 Kubernetes 应用？
- 答案：
  - Helm：包管理工具，通过 Chart 定义应用模板。
  - 常用命令 ：
    bash 复制代码
```
helm install my-release ./mychart
helm upgrade my-release ./mychart
helm uninstall my-release
```

八、场景与故障排查

如何调试 Kubernetes 中的网络问题？
- 答案：
  1. 检查 Pod 是否 Running：kubectl get pods。
  2. 检查 Service 的 Endpoints：kubectl get endpoints <service-name>。
  3. 使用临时 Pod 测试网络连通性：
    bash 复制代码
```
kubectl run -it --rm --image=alpine test-pod -- sh
ping <service-ip>
```

如何备份和恢复 Kubernetes 集群？

答案：

备份 etcd ：

bash 复制代码

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save snapshot.db

恢复：使用 etcdctl snapshot restore。

35. 如何实现 Kubernetes 的蓝绿部署？

容器的蓝绿升级 （Blue-Green Deployment）是一种零停机 的发布策略，通常用于确保在应用程序更新过程中不中断服务。它的核心思想是通过创建两个相似的环境（蓝色和绿色）来实现平滑的应用程序升级，最终让流量切换到新的版本上。具体来说，蓝绿升级的工作流程和好处可以分为以下几个方面：

1. 基本概念

蓝色环境（Blue Environment）：表示当前正在运行的应用程序版本或环境。
绿色环境（Green Environment）：表示新版本的应用程序，尚未投入使用，但已准备好接管生产流量。

蓝绿升级的核心步骤如下：

在蓝色环境中运行现有的应用程序。
部署新版本的应用程序到绿色环境中。
测试绿色环境，确保一切正常。
将流量从蓝色环境切换到绿色环境。
一旦切换完成，蓝色环境可以关闭或用于下次升级。

2. 如何实现蓝绿升级（容器化环境）

在容器化环境中，蓝绿升级通常结合容器编排工具（如 Kubernetes、Docker Swarm 等）来实现。具体的操作步骤如下：

2.1 创建两个环境

在 Kubernetes 或其他容器管理平台上，通常会创建两个不同的服务或部署（blue 和 green）。
每个环境都会有独立的容器集群，并且两个环境的配置通常是相同的（不同的是应用版本）。

2.2 部署新版本到绿色环境

将新版本的应用程序部署到绿色环境中。此时，绿色环境中的容器集群可以部署并运行新版本的代码、依赖等，进行内部测试和验证。

2.3 测试绿色环境

在流量切换之前，您可以在绿色环境中进行一系列验证，确保新版本的功能正常，性能达标等。
可以通过内部负载均衡或特定的测试流量（比如进行 Canary 测试）来验证新版本的稳定性。

2.4 切换流量

一旦绿色环境经过验证，就可以将流量从蓝色环境切换到绿色环境。通常这可以通过负载均衡器来实现。
在 Kubernetes 中，可以使用 Service 对象来管理流量，切换流量的过程通常会更新 Ingress 配置或 Service Selector，将流量从蓝色环境路由到绿色环境。

2.5 关闭蓝色环境（可选）

一旦流量切换到绿色环境后，可以选择关闭蓝色环境，或者将其作为备用环境用于回滚操作。
蓝色环境可以在未来的升级中作为新的绿色环境来使用，从而形成一个循环。

3. 蓝绿升级的优势

零停机时间：由于流量切换是在两个独立的环境之间进行的，用户不会感受到服务中断。这对于要求高可用性、零停机的应用至关重要。
平滑回滚：如果新版本出现问题，可以很容易地将流量切换回蓝色环境，保证旧版本仍然可用，避免系统崩溃或中断。
验证新版本：在绿色环境中完全隔离的运行新版本，避免了新版本可能带来的问题影响现有系统。可以在绿色环境中进行详尽的测试，确保稳定后再发布。
降低风险：由于升级和部署是分步进行的，避免了大规模的生产环境升级风险，可以先通过小范围验证来确保新版本是可接受的。

4. 容器化中的蓝绿升级策略

在容器化环境中，蓝绿升级与以下几个技术概念紧密相关：

滚动更新：这与蓝绿升级类似，但它是渐进式的，即新版本逐步替代旧版本。虽然滚动更新可以实现平滑升级，但在某些情况下（例如高可用性需求），蓝绿升级会更加适用，因为它可以在版本切换之前完全验证新版本。
负载均衡：通过负载均衡器或容器编排平台的路由控制（如 Kubernetes 的 Ingress 控制器），可以精确地控制流量的切换，确保应用平稳过渡。
服务发现 ：在容器编排平台（如 Kubernetes）中，服务发现机制可以帮助自动化流量的切换。例如，在 Kubernetes 中，可以通过更新 Deployment 的标签或使用 kubectl 命令来实现流量切换。

5. Kubernetes 中的蓝绿升级

在 Kubernetes 中，蓝绿升级通常可以通过以下步骤实现：

创建两个独立的 Deployment，分别代表蓝色和绿色环境。
使用 Service 将流量引导到当前活动的环境（例如蓝色环境）。
更新绿色环境的 Deployment 来部署新版本的应用。
通过 Service 或 Ingress 将流量从蓝色环境切换到绿色环境。
（可选）删除蓝色环境的 Deployment 或保留它作为回滚点。

yaml 复制代码

# Example of two deployments (blue and green)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: app
          image: app:v1

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: app
          image: app:v2

yaml 复制代码

# Example of a Service routing traffic to the active environment (e.g., blue)
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: app-blue
  ports:
    - port: 80
      targetPort: 8080

6. 总结

蓝绿升级是一种有效的部署策略，它提供了零停机的升级体验，确保在版本更新过程中系统的可用性和稳定性。通过使用蓝色和绿色两个独立环境，它允许开发团队在不影响现有用户的情况下部署、验证和切换到新版本的应用程序。对于容器化应用，使用 Kubernetes、Docker Swarm 或其他容器编排平台结合蓝绿升级策略，可以实现高可用、高可靠的服务交付。

36.滚动更新 (Rolling Update) VS 蓝绿升级 (Blue-Green Deployment)

滚动更新 (Rolling Update) 和 蓝绿升级 (Blue-Green Deployment) 是两种常见的部署策略，它们都用于无缝地将新版本的应用程序部署到生产环境，但它们的工作原理和适用场景有所不同。

1. 滚动更新 (Rolling Update)

定义：

滚动更新是一种逐步替换现有应用程序版本的方法。在滚动更新过程中，Kubernetes 会根据指定的更新策略，逐步替换应用程序的旧版本 Pods（容器）为新版本。每次更新一定数量的 Pods，直到全部 Pods 被更新为新版本。

工作原理：

逐个替换 Pods： 更新过程按照一定的步长（例如每次替换 1 个 Pod 或者 10% 的 Pods）来逐步替换旧版本 Pods。
保证应用可用性： 在更新过程中，会始终保持一定数量的旧版本和新版本 Pods 在运行，确保应用在更新过程中不会停机。
更新顺序： 每次替换一个 Pod，Kubernetes 会检查新版本的 Pod 是否正常工作，如果正常才会继续替换下一个 Pod。

优势：

平滑过渡： 在更新过程中，始终有一些 Pods 仍然在提供服务，避免了应用不可用的情况。
资源节省： 无需为旧版本和新版本都保持单独的环境，因此节省了资源。
自动化： Kubernetes 自动管理更新过程，用户无需手动干预。

缺点：

回滚困难： 如果新版本的应用有问题，回滚可能需要手动操作，且无法直接控制回滚过程。
可能有临时的不一致： 由于新旧版本并行运行，可能会出现不同版本的 Pods 同时处理请求，可能引入不一致的问题。
更新过程中可能存在停机时间： 尽管 Kubernetes 会保证一定数量的 Pods 处于可用状态，但仍有可能出现部分请求被拒绝或者延迟的情况。

Kubernetes 中的滚动更新示例：

Kubernetes Deployment 对象默认使用滚动更新策略来进行应用程序的升级。可以通过配置 spec.strategy.type 来设置策略，默认为 RollingUpdate。

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    spec:
      containers:
        - name: myapp
          image: myapp:v2
          ports:
            - containerPort: 8080

maxSurge: 更新过程中可以超出的 Pods 数量（即新创建 Pods 的数量），例如 maxSurge: 1 表示每次更新时最多会多出一个 Pod。
maxUnavailable: 更新过程中不可用的 Pods 数量，表示可接受的最差情况。

2. 蓝绿升级 (Blue-Green Deployment)

定义：

蓝绿升级是一种完全替换现有应用程序版本的方法。在蓝绿升级过程中，维护两个独立的环境------蓝色环境 和绿色环境。蓝色环境代表当前运行的生产版本，绿色环境代表新版本的应用程序。当新版本经过验证后，切换流量到绿色环境。

工作原理：

两个独立的环境： 蓝色环境和绿色环境在同一时间内并行存在。蓝色环境是当前的生产环境，绿色环境是新版本的应用程序。
流量切换： 初始时，流量由服务指向蓝色环境。当新版本应用程序（绿色环境）准备就绪后，通过修改负载均衡器或服务的配置，将流量切换到绿色环境。
切换后，蓝色环境作为备份： 如果绿色环境有问题，可以快速回滚流量到蓝色环境。绿色环境可作为新的生产环境，蓝色环境可用于备份或回滚。

优势：

零停机： 蓝绿升级可以确保应用在切换过程中不会停机，因为流量控制非常明确，切换只发生在流量入口的负载均衡器或服务上。
可控回滚： 如果绿色环境出现问题，流量可以迅速切换回蓝色环境，回滚过程非常简单。
完整验证： 在切换流量之前，可以在绿色环境中完全验证新版本，确保其没有问题。
流量切换精确： 完全控制流量的切换，没有其他版本与新版本并存的情况。

缺点：

资源浪费： 需要两个环境并行运行，意味着需要更多的资源（计算和存储），尤其是对于大型应用，可能会浪费大量资源。
流量切换延迟： 切换流量需要一定的操作，尤其是涉及负载均衡器配置时，可能会有一些延迟。
复杂的管理： 需要管理两个完全独立的环境，包括数据库、缓存等，可能增加管理复杂度。

Kubernetes 中的蓝绿升级示例：

蓝绿升级需要通过创建两个不同版本的 Deployment 和一个 Service 来实现流量的切换。

yaml 复制代码

# 蓝色环境的 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
        - name: myapp
          image: myapp:v1  # 蓝色环境的版本
---
# 绿色环境的 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
        - name: myapp
          image: myapp:v2  # 绿色环境的版本
---
# 负责流量的 Service
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue  # 初始流量指向蓝色环境
  ports:
    - port: 80
      targetPort: 8080

3. 滚动更新与蓝绿升级的对比

特性	滚动更新 (Rolling Update)	蓝绿升级 (Blue-Green Deployment)
更新方式	逐步替换 Pods，逐步升级	完全切换流量到新版本的环境
停机时间	最小，保证有 Pod 在运行	无停机时间，流量切换不影响服务
回滚难易	需要手动操作，回滚过程可能复杂	简单快速，只需切换流量回蓝色环境即可
资源消耗	资源消耗较少，只需要旧版本和新版本的 Pod 并行运行	需要两个完整的环境（蓝色和绿色），资源消耗较高
控制粒度	没有直接控制流量切换的时机	完全控制流量切换，可以精确控制
适用场景	适用于小规模应用或对于资源有要求的场景	适用于需要零停机和快速回滚的场景

4. 总结

滚动更新 适用于大多数场景，尤其是当你希望逐步升级 Pods 并且能够容忍部分 Pods 暂时不正常的情况时。
蓝绿升级 则更适用于关键应用或需要确保零停机的场景，适合有资源和成本预算进行双环境部署的情况。

根据你的需求选择合适的部署策略，若需要稳定性和无缝的切换，可以考虑 蓝绿升级 ；如果资源有限，或者不需要严格的流量控制，滚动更新 是更为经济和简单的选择。

八股取士--docker&k8s

一、Docker 基础

二、Docker 网络与存储

三、Docker 实战与优化

四、Kubernetes 基础

五、Kubernetes 核心概念

六、Kubernetes 运维与调试

七、Kubernetes 高级特性

八、场景与故障排查

更多高频问题（简要答案）

35. 如何实现 Kubernetes 的蓝绿部署？

1. 基本概念

2. 如何实现蓝绿升级（容器化环境）

2.1 创建两个环境

2.2 部署新版本到绿色环境

2.3 测试绿色环境

2.4 切换流量

2.5 关闭蓝色环境（可选）

3. 蓝绿升级的优势

4. 容器化中的蓝绿升级策略

5. Kubernetes 中的蓝绿升级

6. 总结

36.滚动更新 (Rolling Update) VS 蓝绿升级 (Blue-Green Deployment)

1. 滚动更新 (Rolling Update)

定义：

工作原理：

优势：

缺点：

Kubernetes 中的滚动更新示例：

2. 蓝绿升级 (Blue-Green Deployment)

定义：

工作原理：

优势：

缺点：

Kubernetes 中的蓝绿升级示例：

3. 滚动更新与蓝绿升级的对比

4. 总结