哈布罗居民大家好！ Kubernetes 是现代云生态系统的关键要素之一。 该技术为容器虚拟化提供了可靠性、可扩展性和弹性。 John Arundel 和 Justin Domingus 谈论 Kubernetes 生态系统，并介绍针对日常问题的行之有效的解决方案。 您将逐步构建自己的云原生应用程序并创建支持它的基础架构，设置开发环境和持续部署管道，这将在您开发下一个应用程序时为您提供帮助。
• 从基础开始使用容器和Kubernetes：学习该主题不需要特殊经验。 • 运行您自己的集群或选择来自Amazon、Google 等的托管Kubernetes 服务。 • 使用Kubernetes 管理容器生命周期和资源消耗。 • 根据成本、性能、弹性、功率和可扩展性优化集群。 • 了解开发、测试和部署应用程序的最佳工具。 • 利用当前的行业实践来确保安全和控制。 • 在整个公司实施DevOps 原则，以便开发团队能够更加灵活、快速和高效地采取行动。
这本书是为谁而写的？
本书最适合负责服务器、应用程序和服务的管理部门的员工，以及参与构建新云服务或将现有应用程序迁移到 Kubernetes 和云的开发人员。 别担心，您不需要知道如何使用 Kubernetes 或容器 - 我们会教您一切。
经验丰富的 Kubernetes 用户也会发现很多价值，其中深入介绍了 RBAC、持续部署、敏感数据管理和可观察性等主题。 我们希望本书中一定会包含您感兴趣的内容，无论您的技能和经验如何。
本书回答了哪些问题？
在规划和撰写这本书的过程中，我们与数百人讨论了云技术和 Kubernetes，与行业领导者、专家以及完全的新手进行了交谈。 以下是他们希望在本出版物中得到解答的精选问题。
- “我感兴趣的是为什么你应该花时间研究这项技术。 它会帮助我和我的团队解决什么问题？”
- “Kubernetes 看起来很有趣，但进入门槛相当高。 准备一个简单的示例并不困难，但进一步的管理和调试却令人畏惧。 我们希望获得有关人们如何在现实世界中管理 Kubernetes 集群以及我们可能会遇到哪些问题的可靠建议。”
- “主观建议会很有帮助。 Kubernetes 生态系统为新团队提供了太多选择。 当有多种方法可以做同一件事时，您如何知道哪一种最好？ 如何做出选择？
也许是所有问题中最重要的：
- “如何在不干扰我公司的情况下使用 Kubernetes？”
摘抄。 配置和秘密对象
将 Kubernetes 应用程序的逻辑与其配置（即与可能随时间变化的任何值或设置）分离的能力非常有用。 配置值通常包括特定于环境的设置、第三方服务 DNS 地址和身份验证凭据。
当然，这一切都可以直接放入代码中，但这种做法不够灵活。 例如，更改配置值将需要您再次构建和部署代码。 更好的解决方案是将配置与代码分开，并从文件或环境变量中读取配置。
Kubernetes 提供了几种不同的方式来管理配置。 首先，您可以通过 pod 包装器规范中指定的环境变量向应用程序传递值（请参阅第 192 页的“环境变量”）。 其次，配置数据可以使用 ConfigMap 和 Secret 对象直接存储在 Kubernetes 中。
在本章中，我们将详细探讨这些对象，并研究使用演示应用程序管理配置和敏感数据的一些实用方法。
配置更改时更新 pod shell
假设您的集群中有一个部署，并且您想要更改其 ConfigMap 中的一些值。 如果您使用 Helm 图表（请参阅第 102 页的“Helm：Kubernetes 的包管理器”），您可以通过一个巧妙的技巧自动检测配置更改并重新加载 pod shell。 将以下注释添加到您的部署规范中：
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}部署模板现在包含配置参数的校验和：如果参数发生更改，总和将更新。 如果运行 helm Upgrade，Helm 将检测到部署规范已更改，并将重新启动所有 pod shell。
Kubernetes 中的敏感数据
我们已经知道，ConfigMap 对象提供了一种灵活的机制来存储和访问集群中的配置数据。 然而，大多数应用程序都具有敏感且敏感的信息，例如密码或API密钥。 也可以存储在ConfigMap中，但这种方案并不理想。
相反，Kubernetes 提供了一种特殊类型的对象，旨在存储敏感数据：Secret。 接下来，让我们看一个示例，了解如何在我们的演示应用程序中使用该对象。
首先，查看 Secret 对象的 Kubernetes 清单（请参阅 hello-secret-env/k8s/secret.yaml）：
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
在此示例中，magicWord 私钥是 xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing))。 xyzzy 这个词在计算机领域通常非常有用。 与ConfigMap类似，你可以在一个Secret对象中存储多个键和值。 这里，为了简单起见，我们只使用一个键值对。
使用秘密对象作为环境变量
与 ConfigMap 一样，Secret 对象可以在容器中作为环境变量或磁盘上的文件提供。 在以下示例中，我们将为 Secret 中的值分配一个环境变量：
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWord在演示存储库中运行以下命令以应用清单：
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created与之前一样，将本地端口转发到部署以在浏览器中查看结果：
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888打开地址时 :9999/ 您应该看到以下内容：
The magic word is "xyzzy"
将秘密对象写入文件
在此示例中，我们将 Secret 对象作为文件附加到容器。 该代码位于演示存储库的 hello-secret-file 文件夹中。
要将 Secret 连接为文件，我们将使用以下部署：
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-file
ports:
- containerPort: 8888
volumeMounts:
- name: demo-secret-volume
mountPath: "/secrets/"
readOnly: true
volumes:
- name: demo-secret-volume
secret:
secretName: demo-secret如第 240 页“从 ConfigMap 对象创建配置文件”小节中所述。 XNUMX，我们创建一个卷（在本例中为 demo-secret-volume）并将其安装到规范的volumeMounts 部分中的容器中。 mountPath 字段为 /secrets，因此 Kubernetes 会在此文件夹中为 Secret 对象中定义的每个键/值对创建一个文件。
在我们的示例中，我们仅定义了一个名为 magicWord 的键值对，因此清单将在容器中创建一个包含敏感数据的只读文件 /secrets/magicWord。
如果您以与前面的示例相同的方式应用此清单，您应该得到相同的结果：
The magic word is "xyzzy"
读取秘密对象
在上一节中，我们使用 kubectl describe 命令来显示 ConfigMap 的内容。 Secret 也可以做同样的事情吗？
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytes请注意，数据本身不会显示。 Kubernetes 中的秘密对象是不透明类型的，这意味着它们的内容不会显示在 kubectl 描述输出、日志条目或终端中，从而不可能意外泄露敏感信息。
要查看敏感数据的编码 YAML 版本，请使用 kubectl get 命令：
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
eHl6enk=是什么，和我们原来的值完全不一样？ 这实际上是一个 Secret 对象，以 base64 编码表示。 Base64 是将任意二进制数据编码为字符串的方案。
由于敏感信息可能是二进制的并且不会输出（与 TLS 加密密钥的情况相同），因此 Secret 对象始终以 base64 格式存储。
文本 beHl6enk= 是我们的秘密单词 xyzzy 的 Base64 编码版本。 您可以通过在终端中运行 base64 —decode 命令来验证这一点：
echo "eHl6enk=" | base64 --decode
xyzzy因此，虽然 Kubernetes 可以防止您意外地在终端或日志文件中输出敏感数据，但如果您对特定命名空间中的 Secret 对象具有读取权限，则可以对该数据进行 Base64 编码并随后进行解码。
如果您需要对某些文本进行 Base64 编码（例如，将其放入 Secret 中），请使用不带参数的 base64 命令：
echo xyzzy | base64
eHl6enkK访问秘密对象
谁可以读取和编辑 Secret 对象？ 这是由 RBAC（一种访问控制机制）决定的（我们将在第 258 页的“基于角色的访问控制简介”小节中详细讨论）。 如果您运行的集群没有 RBAC 或未启用，则所有 Secret 对象都可供任何用户和容器使用（我们稍后将解释您不应该拥有任何没有 RBAC 的生产集群）。
被动数据加密
那些有权访问 Kubernetes 存储所有信息的 etcd 数据库的人呢？ 他们可以在没有通过 API 读取 Secret 对象的权限的情况下读取敏感数据吗？
从1.7版本开始，Kubernetes支持被动数据加密。 这意味着 etcd 内的敏感信息被加密存储在磁盘上，即使是直接访问数据库的人也无法读取。 要解密它，您需要一个只有 Kubernetes API 服务器拥有的密钥。 在正确配置的集群中，应启用被动加密。
您可以通过以下方式检查被动加密在集群中是否有效：
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...如果您没有看到experimental-encryption-provider-config 标志，则表示未启用被动加密。 当使用 Google Kubernetes Engine 或其他 Kubernetes 管理服务时，您的数据使用不同的机制进行加密，因此该标志不会出现。 请咨询您的 Kubernetes 供应商，了解 etcd 内容是否已加密。
存储机密数据
有一些 Kubernetes 资源永远不应该从集群中删除，例如高度敏感的 Secret 对象。 您可以使用 Helm 管理器提供的注释来保护资源不被删除：
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keep秘密对象管理策略
在上一节的示例中，敏感数据在存储到集群后立即受到保护，免受未经授权的访问。 但在清单文件中，它们以纯文本形式存储。
切勿将机密信息放入版本控制的文件中。 在将这些信息应用到 Kubernetes 集群之前，如何安全地管理和存储这些信息？
您可以选择任何工具或策略来处理应用程序中的敏感数据，但您仍然需要至少回答以下问题。
- 敏感数据应存储在哪里以便易于访问？
- 如何使您的活动应用程序可以访问敏感数据？
- 当您替换或编辑敏感数据时，您的应用程序会发生什么情况？
关于作者
约翰·阿伦德尔 是一位在计算机行业拥有 30 年经验的顾问。 他写了几本书，并与来自不同国家的许多公司合作，为他们提供有关云原生基础设施和 Kubernetes 的建议。 在空闲时间，他喜欢冲浪，是一名出色的手枪射击手，并且业余弹钢琴。 住在英国康沃尔郡的一座童话小屋里。
贾斯汀·多明格斯 — 在使用 Kubernetes 和云技术的 DevOps 环境中工作的系统管理工程师。 他喜欢在户外度过时光、喝咖啡、吃螃蟹和坐在电脑前。 住在华盛顿州西雅图，有一只很棒的猫，还有一个更棒的妻子和最好的朋友艾德丽安。
» 有关本书的更多详细信息，请访问
»
»
对于 Khabrozhiteley 使用优惠券可享受 25% 折扣 - Kubernetes
支付纸质版书籍的费用后，将通过电子邮件发送电子书。
来源： habr.com