Skip to content

你好，我是潘野。

今天这次加餐，我为你整理了整门课程的思考题答案，希望对你有所帮助。建议你一定要先自己独立思考、动手编码以后，再对照参考答案，这样学习效果会更好。

因为课程里很多题目都涉及代码，只听音频的话很难理解，所以我建议你直接看文稿。我把每节课的题目和答案放在了一起，每节课的超链接也放在了文稿里，方便你跳转复习。

模块一 基础篇

第 2 讲

题目

请你尝试参考Terraform的官方文档，写一段Terraform的代码，在AWS上启动一个EC2的实例，然后在这个实例中启动http服务并对外提供服务。

答案

https://github.com/cloudnative-automation/cloud-automation/blob/main/example/webserver/main.cf

第 3 讲

题目

这一讲，我提到容器环境中重启主机这有可能会造成一些应用的中断。你知道什么样的情况会造成应用中断么？我们又该如何预防？

答案

如果同学们没有特意为Deployment或者StatefulSet设置过特殊的调度策略，你可能会遇到多个pods被调度到一台机器上的场景。此时重启主机，可能会因为应用容量不足而导致性能下降，甚至服务不可用的情况。

建议你在Deployment或者StatefulSet中设置反亲和性或者Pod拓扑分布约束，以保证pod尽可能分散调度，同时启用PDB，保证最小存活的pod数量。

https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/

第 4 讲

题目

结合上一讲中我们介绍的 Terraform，你能否写一段代码，同时在 AWS 和 Azure 上分别启动一个虚拟机，并在其中启动一个 HTTP 服务？

答案

https://github.com/cloudnative-automation/cloud-automation/tree/main/example/webserver

第 5 讲

题目

GitOps 并不是一种万能的解决方案，它同样存在一些挑战和限制，你能想到有哪些限制吗？

答案

GitOps依赖于大量的自动化，这需要投入大量的时间和精力来编写、测试和维护脚本和配置。这可能会对团队的资源和能力提出较高的要求。

GitOps通常依赖于特定的工具和平台，例如Kubernetes和云服务。这可能限制了GitOps的适用范围，对于不使用这些工具和平台的环境，可能无法直接应用GitOps。

模块二 CI/CD实战篇

第 6 讲

题目

今天，我们使用了 Terraform 在公有云中启动了一个 Kubernetes 集群。但实际工作中，公司里只有一个集群的情况极少，往往我们面对十多个、甚至上百个 Kubernetes 集群，那么我们要如何管理多个集群的 Terraform 代码呢？

答案

一点小Tips，这个思考题是今天课程的精髓所在，答案可以在我们课程代码的其他分支里找一找。

第 7 讲

题目

课程里，我们将 Terraform 状态文件存放在 S3 这步中，S3 存储桶是我们手动在页面上创建出来的，你能否自己写一段 Terraform 代码，通过 GitHub Action 来创建出 S3 存储桶呢？

答案

参考代码仓库中 S3存储桶 的代码以及说明。

第 8 讲

题目

在terraform init的这个环节中，我们加载模块代码往往需要花费 5 到 10 分钟。你有哪些手法可以加速加载模块代码么？

答案

一般有两种做法。

第一种是将terrafrom里涉及到的模块预先存在CI/CD环境中，比如这一讲放在了Docker镜像中，上一讲则是放在Github Runner所在的虚拟机中。

第二种做法是将terraform里涉及的模块放在公司内网环境中，在terrafrom init的时候直接从内网的服务器中加载。

第 9 讲

题目

请你根据 代码仓库 里提供的样例，来完成其他集群组件的部署。

---
clusterURL: 127.0.0.1

addons:

  namespaces:
    default: addons-system

  grafana:
    enabled: false
    names:
      app: grafana
      chart: grafana
    repoURL: https://grafana.github.io/helm-charts
    targetVersion: 7.2.4

  ingressNginx:
    enabled: false
    names:
      app: ingress-nginx
      chart: ingress-nginx/ingress-nginx
    repoURL: https://kubernetes.github.io/ingress-nginx
    targetVersion: 4.9.0

答案

https://github.com/cloudnative-automation/addon-manager/tree/ 09

第 10 讲

题目

请你根据这一讲提供的 Azure Service Operator 讲解，自己动手写一个申请 PostgreSQL 的配置。

答案

apiVersion: database.crossplane.io/v1alpha1
kind: PostgreSQLInstanceClass
metadata:
  name: postgresql-standard
  namespace: app-project1-dev
classRef:
  kind: RDSInstanceClass
  apiVersion: database.aws.crossplane.io/v1alpha2
  name: rdspostgresql-standard
  namespace: aws-infra-dev
---
apiVersion: database.aws.crossplane.io/v1alpha2
kind: RDSInstanceClass
metadata:
  name: rdspostgresql-standard
  namespace: aws-infra-dev
specTemplate:
  class: db.t2.small
  masterUsername: masteruser
  securityGroups:
   - # sg-ab1cdefg
   - # sg-05adsfkaj1ksdjak
  size: 20
  engine: postgresql
  providerRef:
    name: example
    namespace: aws-infra-dev
  reclaimPolicy: Delete

模块三 进阶篇

第 11 讲

题目

假如你的公司计划将部分业务迁移到公有云，你觉得要如何评估该方案的成本和效益呢？

答案

影响成本的因素可不少，我们需要仔细梳理。

  • 业务类型和需求：不同的业务，对资源的需求也不一样。比如，需要大量计算资源的业务，在公有云上可能比私有云更贵。
  • 资源使用量：用得越多，花得就越多。合理规划资源，才能避免浪费。
  • 数据敏感性：敏感数据需要额外防护，这也会增加成本。
  • 技术支持：想要更完善的技术支持，需要额外付费。
  • 地域：不同地区的云服务价格可能不同。选择合适的地域，可以省点钱。
  • 应用架构：优化应用架构，可以更好地利用公有云的特性，从而降低成本。
  • 公有云服务商的定价模式：不同的服务商，定价模式也不同。货比三家，才能选到最划算的。
  • 成本管理策略：制定合理的成本管理策略，可以有效控制成本。

评估步骤和方法：

  1. 明确业务需求：你想把哪些业务搬到公有云？这些业务对资源有什么需求？
  2. 分析资源使用量：你目前使用了多少资源？未来可能需要多少资源？
  3. 评估数据敏感性：你的数据中有多少敏感数据？需要哪些防护措施？
  4. 选择合适的技术支持：你需要什么样的技术支持？愿意为此支付多少费用？
  5. 选择合适的地域：你的业务主要面向哪些用户？选择哪个地域可以更好地服务用户？
  6. 优化应用架构：如何改造应用架构，才能更好地利用公有云的特性？
  7. 公有云服务商的定价模式对比：哪家服务商的定价模式更符合你的需求？
  8. 制定成本管理策略：如何监控和控制成本？

评估结论和建议：

根据以上评估，可以得出公有云方案是否比传统方案更具成本效益的结论。如果结论是肯定的，可以制定具体的迁移方案。

以下是一些建议：

  • 在迁移之前，先进行试用，以评估公有云方案的性能和成本。
  • 选择合适的云服务商，并签订有利的合同。
  • 制定合理的资源使用计划，避免浪费。
  • 定期监控和分析成本，并进行必要的调整。

希望这些信息能帮你做出明智的决策！

第 12 讲

题目

今天的课程里，我提到了HPA的一些不足，比如在真正流量突发的时候，有可能会遇到反应慢半拍，无法及时跟上扩展，导致应用服务中断，那你有哪些思路来解决这个问题呢？

答案

这里我提供三个方面的应对思路供你参考。

  1. 优化监控指标和策略。

  2. 使用更灵敏的监控指标，并结合多维度的指标进行综合判断，以更快速地识别流量突发情况。

  3. 调整 HPA 策略，缩短扩缩容的评估周期和步长，使 HPA 能够更迅速地做出反应。

  4. 可以考虑使用预测模型，根据历史数据和当前趋势预测未来的流量需求，提前进行扩容。

  5. 结合其他扩容手段

  6. 使用 Pod 预热机制，提前创建并预热 Pod，以便在需要时快速投入使用。

  7. 使用 KEDA 等事件驱动的扩容工具，可以根据事件触发扩容，例如队列长度、消息积压等。

  8. 优化应用架构。

  9. 使用微服务架构，将应用拆分成多个独立的服务，可以更细粒度地进行扩缩容。

  10. 使用无状态服务，可以避免扩容时需要进行数据迁移。

第 13 讲

题目

你觉得 KEDA 在哪些场景下可以发挥最大价值？

答案

  • 电商平台：在双十一等购物高峰期，电商平台的流量会激增。KEDA可以根据 HTTP 请求的负载自动扩缩容应用，以确保平台的稳定性和性能。
  • 游戏服务器：游戏服务器的负载会随着玩家数量的增加而增加。KEDA 可以根据玩家登录事件自动扩缩容服务器，以确保玩家的游戏体验。
  • 社交媒体平台：社交媒体平台会产生大量的用户消息。KEDA 可以根据消息队列中的消息数量自动扩缩容应用，以确保消息能被及时处理。

第 15 讲

题目

回顾一下这个模块的内容，应用层面的水平扩缩容HPA，垂直扩缩容VPA，集群层面的扩缩容Karpenter与Cluster Autoscaler，它们适用的场景与缺陷分别是什么。

答案

  • HPA：应用水平扩容，但是Kubernetes原生只支持CPU/Memory指标，需要使用KEDA或者Prometheus-Adapter来配合不同的指标达到水平扩容。
  • VPA：应用垂直扩容，对应用有要求，能够接受中断。
  • Cluster Autoscaler：Kubernetes社区原生的公有云的集群扩缩容方案。
  • Karpenter：AWS的集群扩缩容方案。只能用于AWS，暂时不能用于其他厂商。

模块四 安全篇

第 16 讲

题目

在Kubernetes集群和容器级别，具体有哪些安全软件来完成安全防护？

答案

这里我提供一些常见的工具供你参考。

Kubernetes 集群级别的工具包括Open Policy Agent、NetworkPolicy、Istio和Sealed secrets。

容器级别的工具有Clair 镜像扫描，以及Kubernetes Security Context。

第 17 讲

题目

课程里举了两个场景，你还知道哪些场景适合使用vault？

答案

Vault 可以用于各种需要管理敏感数据的场景，例如以下场景。

  • 证书管理
  • 数据库密码管理
  • API 密钥管理
  • SSH 密钥管理
  • 云服务凭证管理
  • 应用程序配置管理
  • ……

第 18 讲

题目

不同类型的敏感数据（如数据库凭证、API密钥等）对租赁时间的需求可能不同。想一想，我们应该如何优化租赁与回收策略呢？

答案

我们一般从事前，事中，事后三个方面入手。

事前

首先，对所有敏感数据进行分类。根据数据的敏感性、使用频率和业务影响进行分级。

然后，根据数据的分类和风险评估，为不同类型的数据定制租赁时间。例如，对于经常变更的临时访问令牌，设置较短的租赁时间；对于稳定使用的API密钥，设置较长的租赁时间。

事中

接下来设置警报机制，当租赁即将到期或检测到异常使用模式时，自动通知系统管理员和数据所有者。对于到期或不再使用的租赁，自动化回收过程，确保敏感数据不被遗留在系统中。

事后

  • 审计与合规：确保所有回收操作都有审计记录，以支持合规性要求和安全审计。
  • 定期评审：定期评审和更新租赁与回收策略，以适应新的业务需求和技术变化。

第 19 讲

题目

除了Cert-Manager，你还有哪些手段可以从Vault中自动获取证书？

答案

除了使用Cert-Manager，还有多种其他手段可以从HashiCorp Vault中自动获取和管理TLS证书，适用于不同的应用和环境。以下是一些常见的方法。

Vault Agent

Vault Agent 是一个预配置的客户端守护进程，可以自动化从Vault获取证书的过程。它可以配置为自动认证并续订秘钥和证书，不仅限于Kubernetes，也适用于其他各种环境。

Terraform

使用Terraform管理Vault资源可以自动化证书的配置和部署。Terraform提供了一种声明式的方式来管理和编排IT资源，包括TLS证书。通过编写Terraform配置文件，我们可以自动从Vault请求证书，并将其部署到需要的环境中。

Ansible

Ansible是一个自动化平台，可以用来自动化证书的部署和管理。通过编写Ansible playbook，可以从Vault中获取证书，并配置到各种服务器和应用中。Ansible的Vault模块可以简化这一过程。

第 20 讲

题目

请你用Gatekeeper定义一个策略，规则是容器启动的时候禁止使用host network。

答案

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: denyhostnetwork
spec:
  crd:
    spec:
      names:
        kind: DenyHostNetwork
      validation:
        legacySchema: true
        openAPIV3Schema:
          properties:
            hostNetwork:
              type: boolean
            max:
              type: integer
            min:
              type: integer
  targets:
  - rego: |
      package hostnetwork

      violation[{"msg": msg, "details": {}}] {
        input_share_hostnetwork(input.review.object)
        msg := sprintf("hostNetwork is not allowed, pod: %v", [input.review.object.metadata.name])
      }

      input_share_hostnetwork(o) {
        o.spec.hostNetwork
      }

      input_containers[c] {
        c := input.review.object.spec.containers[_]
      }

      input_containers[c] {
        c := input.review.object.spec.initContainers[_]
      }

      input_containers[c] {
        c := input.review.object.spec.ephemeralContainers[_]
      }
    target: admission.k8s.gatekeeper.sh

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: DenyHostNetwork
metadata:
  name: deny-hostnetwork
spec:
  enforcementAction: deny
  match:
    excludedNamespaces:
    - kube-system
    kinds:
    - apiGroups:
      - ""
      kinds:

好，以上就是这次加餐的全部内容。也欢迎你继续在留言区参与交流和讨论。