Kubernetes - freeCodeCamp.org

如何通过 Kubernetes 安全专家认证考试

freeCodeCamp.org — Thu, 21 Mar 2024 07:00:00 +0000

原文： How to Pass the Certified Kubernetes Security Specialist Exam – Cheat sheet and Study Guide

本文基于我学习并通过 Kubernetes 安全专家认证考试的经验。2021 年 9 月，我第一次参加考试就通过了。

我于 2020 年 2 月通过了认证 Kubernetes 应用程序开发人员考试，随后于 2020 年 3 月通过了认证 Kubernetes 管理员。

认证 Kubernetes 安全专家或 CKS 考试于 2020 年 11 月左右发布，但我在 2021 年 9 月之前没有机会参加该考试。

作为一些背景信息，在过去的 3 年里，我几乎每天都在使用 Kubernetes，这些经验为我通过 CKS 考试提供了额外的优势。

在本文中，我将分享一些可以帮助您学习和通过考试的资源，以及可以在准备时使用的有用备忘单。我还将分享一些建议，这些建议应该对您有所帮助。

什么是 Kubernetes

Kubernetes 是目前最先进、功能最丰富的容器编排系统，并且它一直在变得更好。

它有一个庞大的社区提供支持，并一直在开发新功能和解决问题。Kubernetes 无疑正在以惊人的速度发展，要跟上其发展速度成为一项挑战。这使其成为容器编排解决方案的最佳选择。

备考资料

以下是通过 CKS 考试的一些很棒的资源：

KodeKloud 和 Killer.sh 的课程提供了模拟考试模拟器，这对备考非常有帮助，而且还能让人对考试有一个大致的了解。我强烈建议注册一门或两门课程。

从 Linux Foundation 购买考试后，你可以免费尝试 2 次来自 kill.sh 的考试模拟器。这样，如果您精通课程内容，您可以跳过课程并直接进入考试提供的考试模拟器。

考试费用为 375 美元，但也有一些优惠和折扣，如果你留意一下，可能会得到更优惠的价格。考试时间为 2 小时，有效期为 2 年，而 CKA 和 CKAD 的有效期为 3 年。

Aliases

CKS 是一项基于表现的考试，您将获得一个考试模拟器，您必须在其中解决问题。除了考试选项卡外，您只能打开一个选项卡。

因为这个考试需要你写很多命令，所以我很早就想到我必须依靠别名来减少击键次数以节省时间。

我在考试时使用了 vi 编辑器，所以在这里我将分享一些关于这个编辑器的实用技巧。

vi defaults for ~/.vimrc:

vi ~/.vimrc
---
:set number
:set et
:set sw=2 ts=2 sts=2
---
^: Start of word in line
0: Start of line
$: End of line
w: End of word
GG: End of file

kubectl defaults for ~/.bashrc:

vi ~/.bashrc
---
alias k='kubectl'
alias kg='k get'
alias kd='k describe'
alias kl='k logs'
alias ke='k explain'
alias kr='k replace'
alias kc='k create'
alias kgp='k get po'
alias kgn='k get no'
alias kge='k get ev'
alias kex='k exec -it'
alias kgc='k config get-contexts'
alias ksn='k config set-context --current --namespace'
alias kuc='k config use-context'
alias krun='k run'
export do='--dry-run=client -oyaml'
export force='--grace-period=0 --force'

source <(kubectl completion bash)
source <(kubectl completion bash | sed 's/kubectl/k/g' )
complete -F __start_kubectl k


alias krp='k run test --image=busybox --restart=Never'
alias kuc='k config use-context'
---

一些捷径

kubectl get 命令为访问资源提供了简短易懂的名称，例如 pvc 用于 persistentstorageclaim。这些可以帮助人们在考试期间节省大量击键和宝贵的时间。

po for pods
rs for replicasets
deploy for deployments
svc for services
ns for namespace
netpol for networkpolicy
pv for persistentstorage
pvc for persistentstorageclaim
sa for serviceaccounts

Kubernetes 手册

kubectl run 命令

kubectl run 命令提供了一个标志 --restart，它允许您创建从 Deployment 到 CronJob 的不同类型的 Kubernetes 对象。

下面的代码片段显示了可用于 --restart 标志的不同选项。

k run:
--restart=Always                             #Creates a deployment
--restart=Never                              #Creates a Pod
--restart=OnFailure                          #Creates a Job
--restart=OnFailure --schedule="*/1 * * * *" #Creates a CronJob

如何从现有的 pod 生成 yaml 规范

有时，从现有 pod 生成规范并对其进行更改比从头开始创建新的更容易。 kubectl get pod 命令为我们提供了所需的标志，以我们想要的格式输出 pod 规范。

kgp  -o wide

# Generating YAML Pod spec
kgp  -o yaml
kgp  -o yaml > .yaml

# Get a pod's YAML spec without cluster specific information
kgp my-pod -o yaml --export > .yaml

kubectl pod 命令

kubectl run 命令提供了很多选项，例如指定请求和 Pod 应该使用的限制，或者容器在创建后应该运行的命令。

# Output YAML for a nginx pod running an echo command
krun nginx --image=nginx --restart=Never --dry-run -o yaml -- /bin/sh -c 'echo Hello World!'
# Output YAML for a busybox pod running a sleep command
krun busybox --image=busybox:1.28 --restart=Never --dry-run -o yaml -- /bin/sh -c 'while true; do echo sleep; sleep 10; done'
# Run a pod with set requests and limits
krun nginx --image=nginx --restart=Never --requests='cpu=100m,memory=512Mi' --limits='cpu=300m,memory=1Gi'
# Delete pod without delay
k delete po busybox --grace-period=0 --force

如何打印日志并导出

在调试应用程序时，日志是信息的基本来源。kubectl logs 命令提供了检查给定 pod 日志的功能。您可以使用以下命令检查给定 pod 的日志。

kubectl logs deploy/
kubectl logs deployment/
#Follow logs
kubectl logs deploy/ --tail 1 --follow

除了查看日志外，我们还可以将日志导出到文件中，以便进一步调试与任何人共享相同的内容。

kubectl logs  --namespace  > /path/to/file.format

如何创建配置映射和机密

kubectl create 命令让我们可以从命令行创建 ConfigMap 和 Secret。我们还可以使用 YAML 文件来创建相同的资源，并通过使用 kubectl apply -f 我们可以应用命令。

kc cm my-cm --from-literal=APP_ENV=dev
kc cm my-cm --from-file=test.txt
kc cm my-cm --from-env-file=config.env

kc secret generic my-secret --from-literal=APP_SECRET=sdcdcsdcsdcsdc
kc secret generic my-secret --from-file=secret.txt
kc secret generic my-secret --from-env-file=secret.env

有用的调试命令

当您在日常工作中以及在 CKS 考试中解决问题时遇到问题和错误时，调试是一项非常重要的技能。

除了能够从容器输出日志外，kubectl exec 命令还允许您登录到正在运行的容器并调试问题。在容器内，您还可以使用 nc 和 nslookup 等实用程序来诊断与网络相关的问题。

# Run busybox container
k run busybox --image=busybox:1.28 --rm --restart=Never -it sh
# Connect to a specific container in a Pod
k exec -it busybox -c busybox2 -- /bin/sh
# adding limits and requests in command
kubectl run nginx --image=nginx --restart=Never --requests='cpu=100m,memory=256Mi' --limits='cpu=200m,memory=512Mi'
# Create a Pod with a service
kubectl run nginx --image=nginx --restart=Never --port=80 --expose
# Check port
nc -z -v -w 2  
# NSLookup
nslookup 
nslookup 10-32-0-10.default.pod

滚动更新和推出

kubectl rollout 命令提供了检查更新状态的能力，如果需要，还可以回滚到以前的版本。

k set image deploy/nginx nginx=nginx:1.17.0 --record
k rollout status deploy/nginx
k rollout history deploy/nginx
# Rollback to previous version
k rollout undo deploy/nginx
# Rollback to revision number
k rollout undo deploy/nginx --to-revision=2
k rollout pause deploy/nginx
k rollout resume deploy/nginx
k rollout restart deploy/nginx
kubectl run nginx-deploy --image=nginx:1.16 --replias=1 --record

缩放和自动缩放命令

kubectl scale 命令提供了在给定部署中扩大或缩小 pod 的功能。

使用 kubectl autoscale 命令，我们可以定义给定部署应该运行的最小 pod 数量，以及部署可以扩展到的最大 pod 数量以及 CPU 百分比等扩展标准。

k scale deploy/nginx --replicas=6
k autoscale deploy/nginx --min=3 --max=9 --cpu-percent=80

网络策略

在 Kubernetes 集群中，默认情况下所有 pod 都可以与所有 pod 通信，这在某些实现中可能是一个安全问题。

为了解决这个问题，Kubernetes 引入了网络策略来允许或拒绝基于 pod 标签的流量，这些标签是 pod 规范的一部分。

下面的示例拒绝在所有命名空间中运行的 Pod 的 Ingress 和 Egress 流量。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress

下面的示例拒绝在所有命名空间中运行的 Pod 的 Ingress 和 Egress 流量。但它允许访问在端口 53 上运行的 DNS 解析服务。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  - Ingress
  egress:
  - to:
    ports:
      - port: 53
        protocol: TCP
      - port: 53
        protocol: UDP

以下示例拒绝对 AWS EC2 实例中 IP 地址“169.256.169.256”上运行的元数据服务器的 Egress 访问。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name:cloud-metadata-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
      - ipBlock: 
          cidr: 0.0.0.0/0
          except:
          - 169.256.169.256/32

下面的示例允许 Egress 访问 AWS EC2 实例中在 IP 地址“169.256.169.256”上运行的元数据服务器。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cloud-metadata-accessor
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: metadata-accessor
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 169.256.169.256/32

使用 Kubesec 进行静态分析

Kubesec 是一个静态分析工具，用于分析 YAML 文件以查找文件问题。

kubesec scan pod.yaml

# Using online kubesec API
curl -sSX POST --data-binary @pod.yaml https://v2.kubesec.io/scan

# Running the API locally
kubesec http 8080 &

kubesec scan pod.yaml -o pod_report.json -o json

使用 Trivvy 进行漏洞扫描

Trivvy 是一种漏洞扫描工具，可扫描容器映像以查找安全问题。

trivy image nginx:1.18.0
trivy image --severity CRITICAL nginx:1.18.0
trivy image --severity CRITICAL, HIGH nginx:1.18.0
trivy image --ignore-unfixed nginx:1.18.0

# Scanning image tarball
docker save nginx:1.18.0 > nginx.tar
trivy image --input archive.tar

# Scan and output results to file
trivy image --output python_alpine.txt python:3.10.0a4-alpine
trivy image --severity HIGH --output /root/python.txt python:3.10.0a4-alpine

# Scan image tarball
trivy image --input alpine.tar --format json --output /root/alpine.json

如何删除不需要的服务

The systemctl exposes the capabilities to start, stop, enable, disable and list services running on a Linux Virtual Machine.
systemctl 提供了启动、停止、启用、禁用和列出在 Linux 虚拟机上运行的服务的功能。

列出服务：

systemctl list-units --type service

停止服务：

systemctl stop apache2

禁用服务：

systemctl disable apache2

删除服务：

apt remove apache2

运行时类

Kubernetes 在 v1.12 版本中引入了 RuntimeClass 功能，用于选择容器运行时配置。容器运行时配置用于运行 pod 的底层容器。

大多数 Kubernetes 集群使用 dockershim 作为运行容器的运行时类，但您可以使用不同的容器运行时。

dockershim 在 Kubernetes 版本 v1.20 中已被弃用，并将在 v1.24 中删除。

如何创建运行时类：

apiversion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

如何为任何给定的 pod 使用运行时类：

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  runtimeClassName: gvisor
  containers:
  - name: nginx
    image: nginx

RBAC 命令

在 Kubernetes 中，

基于角色的访问控制（RBAC）命令提供了一种基于单个用户或服务帐户的角色来调节对 Kubernetes 资源的访问的方法。（来源）

以下是创建角色的方法：

kubectl create role developer --resource=pods --verb=create,list,get,update,delete --namespace=development

如何创建角色绑定：

kubectl create rolebinding developer-role-binding --role=developer --user=faizan --namespace=development

如何验证：

kubectl auth can-i update pods --namespace=development --as=faizan

如何创建集群角色：

kubectl create clusterrole pvviewer-role --resource=persistentvolumes --verb=list

以及如何创建与服务帐户的 Clusterrole 绑定关联：

kubectl create clusterrolebinding pvviewer-role-binding --clusterrole=pvviewer-role --serviceaccount=default:pvviewer

集群维护

您可以使用 kubectl drain 命令从给定节点中删除所有正在运行的工作负载（pod）。

您使用 kubectl cordon 命令来封锁节点以将其标记为可调度。

并且您使用 kubectl uncordon 命令将节点设置为可调度，这意味着控制器管理器可以将新 pod 调度到给定节点。

如何排空所有 pod 的节点：

kubectl drain node-1

如何排空节点并忽略守护程序集：

kubectl drain node01 --ignore-daemonsets

如何强制排空节点：

kubectl drain node02 --ignore-daemonsets --force

如何将一个节点标记为不可调度，这样就不能在这个节点上调度新的 Pod：

kubectl cordon node-1

标记节点可调度

kubectl uncordon node-1

CKS 考试技巧

Kubernetes `kubectl get` 命令为用户提供了一个输出标志，`-o` 或 `--output`，这有助于我们以 JSON、yaml、wide 或 custom-columns 的形式格式化输出。

JSON 和 JSONPath

如何以 JSON Object 的形式输出所有 pod 的内容：

kubectl get pods -o json

JSONPath 从 JSON 对象输出一个特定的键：

kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'

.items[*] 用于我们有多个对象的地方，例如具有 pod 配置的多个容器：

# For list of items use .items[*]
k get pods -o 'jsonpath={.items[*].metadata.labels.version}'
# For single item
k get po busybox -o jsonpath='{.metadata}'
k get po busybox -o jsonpath="{['.metadata.name', '.metadata.namespace']}{'\n'}"

该命令使用 JSONPath 返回节点的内部 IP：

kubectl get nodes -o=jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'

该命令检查特定键的相等性：

kubectl get pod api-stag-765797cf-lrd8q -o=jsonpath='{.spec.volumes[?(@.name=="api-data")].persistentVolumeClaim.claimName}'
kubectl get pod -o=jsonpath='{.items[*].spec.tolerations[?(@.effect=="NoSchedule")].key}'

自定义列有助于输出特定字段：

kubectl get pods -o='custom-columns=PODS:.metadata.name,Images:.spec.containers[*].image'

CKS 考试题目

CKS 考试涵盖与 Kubernetes 生态系统中的安全性相关的主题。Kubernetes 安全是一个庞大的话题，一篇文章难以涵盖，因此本文包含了考试中涉及的一些主题。

如何保护和强化容器镜像

在设计容器镜像以运行您的代码时，请特别注意保护和强化措施，以防止黑客攻击和特权升级攻击。在构建容器镜像时请记住以下几点：

使用特定的包版本，如alpine:3.13。
不要以 root 身份运行 - 使用 USER 来阻止 root 访问。
使用 readOnlyRootFilesystem: true 在 securityContext 中将文件系统设为只读
使用 RUN rm -rf /bin/* 删除 shell 访问

如何最小化操作系统占用空间

容器层

指令 RUN、COPY和ADD创建容器层。其他指令创建临时中间图像并且不增加构建的大小。创建图层的说明会增加结果图像的大小。

典型的 Dockerfile 如下所示。它使用RUN指令添加一个单层。

FROM ubuntu

RUN apt-get update && apt-get install -y golang-go

CMD ["sh"]

多阶段构建

多阶段构建利用 Dockerfile 中的多个FROM语句。FROM 指令标志着构建的一个新阶段。它结合了多个FROM语句，允许利用以前的构建，以便有选择地将二进制文件复制到新的构建阶段，省略不必要的二进制文件。生成的 Docker 映像的大小要小得多，攻击面也大大减少。

FROM ubuntu:20.04 AS build
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y golang-go
COPY app.go .
RUN CGO_ENABLED=0 go build app.go

FROM alpine:3.13
RUN chmod a-w /etc
RUN addgroup -S appgroup && adduser -S appuser -G appgroup -h /home/appuser
RUN rm -rf /bin/*
COPY --from=build /app /home/appuser/
USER appuser
CMD ["/home/appuser/app"]

如何限制节点访问

访问控制文件包含有关 Linux 操作系统中用户/组的敏感信息。

#Stores information about the UID/GID, user shell, and home directory for a user
/etc/passwd
#Stores the user password in a hashed format
/etc/shadow
#Stores information about the group a user belongs
/etc/group
#Stored information about the Sudoers present in the system
/etc/sudoers

禁用用户帐户有助于通过禁用给定用户帐户的登录来保护对节点的访问。

usermod -s /bin/nologin

禁用“root”用户帐户具有特殊意义，因为 root 帐户具有所有功能。

usermod -s /bin/nologin root

以下是如何添加具有主目录和 shell 的用户：

adduser --home /opt/faizanbashir --shell /bin/bash --uid 2328 --ingroup admin faizanbashir
useradd -d /opt/faizanbashir -s /bin/bash -G admin -u 2328 faizanbashir

如何删除用户帐户：

userdel

如何删除群组：

groupdel

如何将用户添加到组：

adduser

如何从组中删除用户：

#deluser faizanbashir admin
deluser

如何为用户设置密码：

passwd

如何将用户提升为 sudoer：

vim /etc/sudoers
>>>
faizanbashir ALL=(ALL:ALL) ALL

如何在没有密码的情况下启用 sudo：

vim /etc/sudoers
>>>
faizanbashir ALL=(ALL) NOPASSWD:ALL

visudo
usermod -aG sudo faizanbashir
usermod faizanbashir -G admin

SSH加固

如何禁用SSH

/etc/ssh/sshd_config 中给出的配置可用于保护对 Linux 节点的 SSH 访问。将 PermitRootLogin 设置为 no 会禁用节点上的 root 登录。

要强制使用密钥登录并禁用使用密码登录节点，您可以将“PasswordAuthentication”设置为“no”。

vim /etc/ssh/sshd_config
>>
PermitRootLogin no
PasswordAuthentication no
<<
# Restart SSHD Service
systemctl restart sshd

如何设置root用户不登录：

usermod -s /bin/nologin root

SSH 复制用户密钥/无密码 SSH：

ssh-copy-id -i ~/.ssh/id_rsa.pub faizanbashir@node01
ssh faizanbashir@node01

如何删除过时的包和服务

以下是列出在 Ubuntu 机器上运行的所有服务的方法：

systemctl list-units --type service
systemctl list-units --type service --state running

如何停止、禁用和删除服务：

systemctl stop apache2
systemctl disable apache2
apt remove apache2

如何限制内核模块

在 Linux 中，内核模块是可以根据需要加载和卸载到内核中的代码片段。它们无需重新启动系统即可扩展内核的功能。模块可以配置为内置或可加载的。

如何列出所有内核模块：

lsmod

如何手动将模块加载到内核中：

modprobe pcspkr

如何将模块列入黑名单：（参考：CIS Benchmarks -> 3.4 Uncommon Network Protocols）

cat /etc/modprobe.d/blacklist.conf
>>>
blacklist sctp
blacklist dccp

# Shutdown for changes to take effect
shutdown -r now

# Verify
lsmod | grep dccp

如何识别和禁用开放端口

如何检查开放端口：

netstat -an | grep -w LISTEN
netstat -natp | grep 9090

nc -zv  22
nc -zv  10-22

ufw deny 8080

如何检查端口使用情况：

/etc/services | grep -w 53

这是[开放端口列表]的参考文档（https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#control-plane-node-s）。

如何限制网络访问

如何识别端口上运行的服务：

systemctl status ssh
cat /etc/services | grep ssh
netstat -an | grep 22 | grep -w LISTEN

UFW防火墙

Uncomplicated Fire Wall (UFW) 是一个在 Arch Linux、Debian 或 Ubuntu 中管理防火墙规则的工具。 UFW 允许您允许和阻止给定端口和来自给定来源的流量。

以下是安装 UFW 防火墙的方法：

apt-get update
apt-get install ufw
systemctl enable ufw
systemctl start ufw
ufw status
ufw status numbered

如何允许所有出站和入站连接：

ufw default allow outgoing
ufw default allow incoming

如何允许规则：

ufw allow 22
ufw allow 1000:2000/tcp
ufw allow from 172.16.238.5 to any port 22 proto tcp
ufw allow from 172.16.238.5 to any port 80 proto tcp
ufw allow from 172.16.100.0/28 to any port 80 proto tcp

如何拒绝规则：

ufw deny 8080

如何启用和激活防火墙：

ufw enable

如何删除规则：

ufw delete deny 8080
ufw delete

如何重置规则：

ufw reset

Linux 系统调用

Linux 系统调用用于从用户空间向 Linux 内核发出请求。例如，在创建文件时，用户空间向 Linux 内核发出创建文件的请求。

内核空间有以下内容：

Kernel Code
Kernel Extensions
Device Drivers

如何使用 Strace 跟踪系统调用

以下是使用 strace 跟踪系统调用的方法：

which strace
strace touch /tmp/error.log

如何获取服务的PID：

pidof sshd
strace -p

如何列出操作期间进行的所有系统调用：

strace -c touch /tmp/error.log

如何合并列出的系统调用：（计数和总结）

strace -cw ls /

如何遵循 PID 并进行整合：

strace -p 3502 -f -cw

AquaSec Tracee

AquaSec Tracee 由 Aqua Security 创建，它使用 eBPF 来跟踪容器中的事件。 Tracee 在运行时直接在内核空间中使用 eBPF（Extended Berkeley Packet Filter），而不会干扰内核源代码或加载任何内核模块。

二进制存储在/tmp/tracee
如果使用具有 --privileged 能力的容器运行，则需要以只读模式访问以下内容：
- /tmp/tracee -> 默认工作区
- /lib/modules -> 内核头文件
- /usr/src -> 内核头文件

如何让 Docker 容器中的 Tracee 变得有趣：

docker run --name tracee --rm --privileged --pid=host \
  -v /lib/modules/:/lib/modules/:ro -v /usr/src/:/usr/src/ro \
  -v /tmp/tracee:/tmp/tracee aquasec/tracee:0.4.0 --trace comm=ls

# 列出主机上所有新进程的系统调用
docker run --name tracee --rm --privileged --pid=host \
  -v /lib/modules/:/lib/modules/:ro -v /usr/src/:/usr/src/ro \
  -v /tmp/tracee:/tmp/tracee aquasec/tracee:0.4.0 --trace pid=new

# 列出来自任何新容器的系统调用
docker run --name tracee --rm --privileged --pid=host \
  -v /lib/modules/:/lib/modules/:ro -v /usr/src/:/usr/src/ro \
  -v /tmp/tracee:/tmp/tracee aquasec/tracee:0.4.0 --trace container=new

如何使用 Seccomp 限制系统调用

SECCOMP – 安全计算模式 – 是一种 Linux 内核级别的功能，您可以将其用于沙箱应用程序以仅使用它们需要的系统调用。

如何检查对 seccomp 的支持：

grep -i seccomp /boot/config-$(uname -r)

如何测试更改系统时间：

docker run -it --rm docker/whalesay /bin/sh
# date -s '19 APR 2013 22:00:00'

ps -ef

如何检查任何 PID 的 seccomp 状态：

grep -i seccomp /proc/1/status

Seccomp 模式：

模式 0：禁用
模式一：严格
模式2：过滤

以下配置用于将系统调用列入白名单。白名单配置文件是安全的，但必须有选择地启用系统调用，因为它默认阻止所有系统调用。

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86",
    "SCMP_ARCH_X32"
  ],
  "syscalls": [
    {
      "names": [
        "",
        "",
        ""
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

以下配置用于将系统调用列入黑名单。黑名单配置文件比白名单具有更大的攻击面。

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86",
    "SCMP_ARCH_X32"
  ],
  "syscalls": [
    {
      "names": [
        "",
        "",
        ""
      ],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

Docker seccomp 配置文件阻止了 x86 架构上 300 多个系统调用中的 60 个。

如何在 Docker 中使用 seccomp 配置文件：

docker run -it --rm --security-opt seccomp=/root/custom.json docker/whalesay /bin/sh

如何允许容器的所有系统调用：

docker run -it --rm --security-opt seccomp=unconfined docker/whalesay /bin/sh

# Verify
grep -i seccomp /proc/1/status

# Output should be:
Seccomp:         0

如何使用 Docker 容器获取容器运行时相关信息：

docker run r.j3ss.co/amicontained amicontained

Kubernetes 中的 Seccomp

安全计算模式（SECCOMP）是 Linux 内核的一项功能。您可以使用它来限制容器内可用的操作。 Seccomp 文档

如何在 Kubernetes 中运行 amicontained：

kubectl run amicontained --image r.j3ss.co/amicontained amicontained -- amicontained

从 v1.20 版本开始，Kubernetes 默认不实现 seccomp。

Kubernetes 中的 Seccomp 'RuntimeDefault' docker 配置文件：

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: amicontained
  name: amicontained
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - args:
    - amicontained
    image: r.j3ss.co/amicontained
    name: amicontained
    securityContext:
      allowPrivilegeEscalation: false

kubelets 中的默认 seccomp 位置

/var/lib/kubelet/seccomp

如何在节点中创建 seccomp 配置文件：

mkdir -p /var/lib/kubelet/seccomp/profiles

# 添加配置文件进行审计
vim /var/lib/kubelet/seccomp/profiles/audit.json
>>>
{
  defaultAction: "SCMP_ACT_LOG"
}

# 添加违规配置文件（默认阻止所有系统调用，不会让任何东西运行）

vim /var/lib/kubelet/seccomp/profiles/violation.json

>>>
{
  defaultAction: "SCMP_ACT_ERRNO"
}

Local seccomp profile – this file should exist locally on a node to be able to work:

...
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/audit.json
...

上述配置文件将使系统调用能够保存到文件中。

grep syscall /var/log/syslog

如何将系统调用号映射到系统调用名称：

grep -w 35 /usr/include/asm/unistd_64.h

# OR
grep -w 35 /usr/include/asm-generic/unistd.h

AppArmor

AppArmor 是一个 Linux 安全模块，用于将程序限制在一组有限的资源中。

如何安装 AppArmor 工具：

apt-get install apparmor-utils

如何检查 AppArmor 是否正在运行和启用：

systemctl status apparmor

cat /sys/module/apparmor/parameters/enabled
Y

AppArmor 配置文件存储在：

cat /etc/apparmor.d/root.add_data.sh

如何列出 AppArmor 配置文件：

cat /sys/kernel/security/apparmor/profiles

如何拒绝所有文件写入配置文件：

profile apparmor-deny-write flags=(attach_disconnected) {
  file,
  # Deny all file writes.
  deny /** w,
}

如何拒绝写入 /proc 文件：

profile apparmor-deny-proc-write flags=(attach_disconnected) {
  file,
  # Deny all file writes.
  deny /proc/* w,
}

如何拒绝重新挂载根 FS：

profile apparmor-deny-remount-root flags=(attach_disconnected) {

  # Deny all file writes.
  deny mount options=(ro, remount) -> /,
}

如何查看个人资料状态：

aa-status

配置文件加载模式

Enforce，监控和执行规则
Complain，不会强制执行规则，但会将它们记录为事件
Unconfined，不会强制执行或记录事件

如何检查配置文件是否有效：

apparmor_parser /etc/apparmor.d/root.add_data.sh

如何禁用配置文件：

apparmor_parser -R /etc/apparmor.d/root.add_data.sh
ln -s /etc/apparmor.d/root.add_data.sh /etc/apparmor.d/disable/

如何生成个人资料并回答以下一系列问题：

aa-genprof /root/add_data.sh

如何为命令生成配置文件：

aa-genprof curl

如何从日志中禁用配置文件：

aa-logprof

如何在 Kubernetes 中使用 AppArmor

要将 AppArmor 与 Kubernetes 一起使用，必须满足以下先决条件：

Kubernetes 版本应该大于 1.4
应启用 AppArmor 内核模块
AppArmor 配置文件应该加载到内核中
应支持容器运行时

Kubernetes 中的示例用法：

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
  annotations:
    container.apparmor.security.beta.kubernetes.io/: localhost/
spec:
  containers:
  - name: ubuntu-sleeper
    image: ubuntu
    command: ["sh", "-c", "echo 'Sleeping for an hour!' && sleep 1h"]

注意：容器应在包含 AppArmor 配置文件的节点中运行。

Linux 功能

Linux 功能特性将可用于以“root”用户身份运行的进程的权限分解为更小的权限组。这样，以“root”权限运行的进程可以被限制为仅获得执行其操作所需的最小权限。

Docker 支持 Linux 功能作为 Docker 运行命令的一部分：使用 --cap-add 和 --cap-drop。默认情况下，容器启动时具有默认允许且可以删除的多个功能。其他权限可以手动添加。

--cap-add 和 --cap-drop 都支持 ALL 值，以允许或删除所有功能。默认情况下，Docker 容器运行 14 种功能。

Kernel < 2.2
- Privileged Process
- Unprivileged Process
Kernel >= 2.2
- Privileged Process
  - CAP_CHOWN
  - CAP_SYS_TIME
  - CAP_SYS_BOOT
  - CAP_NET_ADMIN

有关 Linux 功能的完整列表，请参阅此文档。

如何检查命令需要哪些功能：

getcap /usr/bin/ping

如何获得进程能力：

getpcaps

如何添加安全功能：

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-sleeper
spec:
  containers:
  - name: ubuntu-sleeper
    image: ubuntu
    command: ["sleep", "1000"]
    securityContext:
      capabilities:
        add: ["SYS_TIME"]
        drop: ["CHOWN"]

如何准备考试

CKS 被认为是一项非常艰难的考试。但根据我的经验，我认为，只要练习足够好，并且如果你理解考试涵盖的概念，两小时内就会很容易掌握。

你肯定需要了解底层的 Kubernetes 概念。由于 CKS 的先决条件是通过 CKA 考试，因此在尝试 CKS 之前，您应该对 Kubernetes 及其运作方式有深入的了解。

此外，要通过 CKS，您需要了解容器编排带来的威胁和安全隐患。

引入 CKS 考试表明容器的安全性不容轻视。安全机制应始终到位，以阻止对 Kubernetes 集群的攻击。

特斯拉加密货币黑客事件是由于一个未受保护的 Kubernetes 控制面板造成的，揭示了与 Kubernetes 或任何其他容器编排引擎相关的风险。Hackerone 有一个 Kubernetes 赏金页面列出了标准 Kubernetes 集群中使用的源代码仓库。

练习，练习，再练习！

练习是破解考试的关键，我个人发现 KodeKloud 和 Killer.sh 的考试模拟器对我帮助很大。

我没有像准备 CKA 考试那样多的时间来准备 CKS 考试，但是我在日常工作中正在研究 Kubernetes，所以我对它已经非常熟悉了。

实践是成功的关键。祝考试顺利！

您可以在 faizanbashir.me阅读这篇文章和其他文章

如何成为 Kubernetes 认证开发者（CKAD）

luojiyin — Sat, 01 Jan 2022 04:00:00 +0000

原文： How to Become a Certified Kubernetes Application Developer

本指南是我对最近通过的K8S认证开发者考试的学习笔记总结。

即使你对认证不感兴趣，你可以把K8S看作一站式商店：通过无数的例子解释所有主要的技术概念。

此外，它还有一些来自我准备和参加考试经验和附加内容。

在写本文时，CKAD的课程（研究领域和每个领域的比重）如下：

13% – 核心概念
18% – 配置
10% – 多容器 Pods
18% – 可观察性
20% – Pod 设计
13% – 服务 & 网络
8% – 状态持久性

本指南涵盖了这些课程，只是顺序不同。

我假设你已经知道K8S的基础知识（基本的containers和pods），并希望将你的技能提高一个新的水平。通过这个考试将使你的简历脱颖而出，因为它是一个非常抢手的认证。

内容

Kubernetes简介
如何管理Kubernetes的集群
超越Pods和Deployments
如何配置Pods和Containers
如何在Kubernetes调度Pods
Kubernetes的存储
Kubernetes的网络和安全
Kubernetes中的观察性和调试
技巧和窍门
实践时间
结论

介绍Kubernetes

Kubernetes是一项技术，允许在多个节点上轻松部署和管理容器化程序。它的一些最突出的特点是:

Container 配置和部署
系统监控
持久性存储
自动调度
自动扩展和自动修复

还有更多。

Kubernetes的工作方式是声明式的：你在集群中定义你想要的状态，Kubernetes是确保集群始终处于这种状态。

REST 调用
命令行工具kubectl。你可以通过这个教程，在你的机器上安装它，点击这里。

如果你不能访问一个Kubernetes集群,我建议在你的本地机器上安装minikube。一旦完成安装并启动，允许以下命令来创建你的第一个Pod。

kubectl run --image=busybox --restart=Never --rm -it -- echo "Welcome to Kubernetes!!"

这个pod一旦打印出欢迎消息，它将被自动删除。

如果管理Kubernetes集群

管理集群不是成为CKAD的课程的一部分。就考试而言，你不需要知道如何如何创建一个集群，管理nodes等。

Namespaces

Namespaces 允许你创建虚拟集群，也就是说将资源隔离在同一物理集群的不同部分。比如说:

将以下不同的环境隔开 development, stage, QA, and production
将一个复杂的系统分解成更小的子系统，你可以为前端组件创建一个Namespace,也可以为后端组件创建另一个Namespace，以此类推。
避免了名称冲突: 同一资源可以在不同的Namespace中以相同的名称创建。这使得创建不同的环境 (think stage and prod)，看起来相同。

你可以通过运行以下命令创建一个Namespace:

kubectl create ns my-namespace

资源配额

如果你想限制开发者在Namespace中可以创建的资源数量（包括物理资源和Kubernetes对象，如pods），你可以使用资源配额。

例如，你可以通过ResourceQuota下的Kubernetes secrets 的数量来限制用户在集群上创建:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-quota
spec:
  hard:
    secrets: "2"

在一个文件中，我们称之为my-qouta.yaml，可以简单运行kubectl apply -f my-quota.yaml

kubectl create quota my-quota --hard="secrets=2"

更多的秘密在这个指南的后面。

Labels

Labels（标签）允许你在Kubernetes集群组织资源，label是一个键值对，你可以在创建资源时，添加到资源上，也可以添加到现有资源。你能使用labels过滤资源。

例如：

你想只显示 backend pods。你将label tier=backed添加到pods（键和值都是任意的，你可以使用任何你想的），然后运行 kubectl get pods -l tier=backend去检索需要的pods。
你想定义一个部署或服务的相关pods。告诉 deployment/service，它需要关注通过labels选择pods。

以下是一些常见的label-related的命令：

# 给Pods 添加一个label, 等等
kubectl label pods pod-name key=value
# 通过podname 删除pods上的label
kubectl label pods pod-name label_key-

# 删除一个pod，通过label选择器
kubectl label po -l app app-

# 显示 label
kubectl get pods --show-labels

# 通过lables选择pods
kubect get pods -l 'tier in (frontend,backend)'
kubect get pods -l tier=frontend,deployer=coolest-team

Annotations和labels相似，都是键值对，但Annotations不能用于选择资源，它们的目的是不同的。

Annotations通常为其他工具添加。比如，如果你运行Prometheus来收集指标，你可以把这个配置添加到你的描述符中。

metadata:
	labels:
		name: fluentd-elasticsearch
	annotations:
        prometheus.io/scrape: 'true'
        prometheus.io/port: '9102'

它让Prometheus将 scrape 和 port 的默认值分别改为 true和 9102。

超越 Pods和部署

Multi-container pods是Kubernetes的基本单元。在大多数情况下，你可以认为它是一个容器，但是一个pod可以由多个容器组成。由于pod是短暂的，我们需要一种机制确保当我们现有的pod死亡时，新的pod被创建。

通过部署，你的可以定义一个理想的状态，例如，有三个应用程序的副本一直在运行，Kubernetes将努力实现并在集群中保持这种状态。

也可以轻松管理任何时候运行的副本数量，执行滚动更新，回滚到以前的版本等等。

还有很多工作负荷。

多容器 pod

一个pod可以运行一个以上的容器。容器间可以无缝通讯，因为它们在同一网络和而且它们可以使用 volumes 共享数据。

现在，让我们深入了解一些多容器pod设计模式，在本指南后面，我们将详细介绍volumes(卷),以及如何部署这些模式中的一些。

Sidecar(边车)

在这个模式中，我们有一个运行主程序的容器，同时还有另一个容器，运行次要任务 以增强主容器的功能。

一个经典的例子是，在运行Web服务(主容器)的同时，还有一个处理日志、监控、刷新pod volume(卷)的数据，终端TLS等任务的side 容器

适配器

同样，你可以有你的主容器和一个次要容器， 转换主容器的输出

例如，想象一些你的主容器运行一个输出大量复杂日志的服务。你可以使用一个适配容器来简化这个输出，然后再发送给你的日志服务器，把主容器(以及服务的开发者)从这个服务中解放出来。

Ambassador

另外一个常见选择是使用以辅助容器， 作为一个代理，在你的主容器和外部之间充当代理。

例如，你可能有不同的数据库用于不同的容器，比如测试和生产。当你的主容器需要连接到一个数据库时，它可以根据环境确定适合的数据库给 ambassador容器。

服务

Pods 可以通过其他的Pods的IP地址，连接其他的Pods。然而，pods是短暂的，当它们死亡时，假设你有个复控制器，一个新的pod将被创建，有一个新的IP地址。这使人们很难直接使用IP连接到pods。

Kubernetes提供了一个名为服务的抽象，一个资源有固定的IP地址 ，并将请求发送到对应的pod。

不需要直接连接到pods，你可以通过它的IP地址到达它们的服务。或者通过DNS服务使用完整限定名称查找，这样会更好。此外，一些服务类型也将你的应用程序暴露在集群外面。

服务类型

你可以创建的主要服务类型:

ClusterIP – 在集群内暴露你的应用。如果你不指定类型，这就是Kubernetes创建的默认服务。
NodePort – 它会在集群中的每一个node打开一个端口，将你的应用程序暴露给世界。
LoadBalancer – 使用云服务提供商的负载均衡器向外部暴露服务。

如何在集群内部暴露你的应用程序

假设你想把你的应用程序my-app暴露给集群中的其他节点，端口为80。你可以创建一个命令部署你的应用程序。

kubectl create deploy my-app --image=my-app --port=80

这将创建集群内部其他的Pod只能通过IP访问的pod，如果pod重新启动，其IP将改变。

下一步是为这些pod创建一个ClusterIP服务。下面的命令创建一个可以通过80端口的服务，并将请求转发到的你的应用程序(80端口)。

kubectl expose deploy my-app --port=80

如何将你的应用程序暴露在集群之外

如果你想把你的应用服务暴露给世界，你可以使用这个配置创建一个NodePort服务。

kind: Service
apiVersion: v1
metadata:
	name: my-svc
spec:
    type: NodePort
    selector:
	    app: nginx
    ports:
    - protocol: TCP
    	port: 80 # 你可以到达该服务的端口
    	targetPort: 80 # 你在pod打开的端口

Ingress

服务并不是将你的应用程序给世界的唯一方法。你也可以用 Ingress对象作为你的集群的一个入口点。

除此之外，你还需要一个 Ingress控制器，比如Nginx,来实现对Ingress对象中定义的规则。

由于Ingresses不在CKAD的范围内，我们将转到其他的主题。

Jobs

一个Job将创建一个或多个pods 如果它们成功，将不会被重启启动。你可以使用它们来执行批处理, 一次性任务 ，如并行计算，备份一些文件，转换和导出一些数据等等。

除非另有说明, pod 将运行一次。你可以使用参数 completions来指定一项工作需要运行多少次才能被认为已经完成。默认情况下, pods将按照顺序运行，但你可以设置job，使它们并行运行。

如果它们没有成功运行, 你将它们配置为 Never 重启 (重试)。或者重启失败最多的backoffLimit 次数，
然后Kubernetes认为job已经失败。

下面是如何从命令行中创建一个简单的job:

 kubectl create job my-job --image=busybox -- echo "Hello World"

如果它们的job运行成功，其状态是COMPLETED,其pod(s)不会被删除，这样你就可以访问它们的日志。你可以通过以下方式看到它们。

kubectll get pods --show-all

在默认情况下，2分钟后它们在默认的pod列表中是不可见的。

Cronjobs

Kubernetes提供了Conjobs来创建需要定期或者在未来特定时间运行的jobs：定时清理和备份任务，更新TLS证书等等。

Kubernetes会尽力只运行另一个job来执行你在Cronjob配置中指定的任务。然而，有3个常见的问题你应该注意。

不能保证job会 准确地在所需的时间运行。想象一下，你需要你的工作在上午9点运行，你可以将startingDeadlineSeconds属性设置为x秒。这样，如果job没在上午9点x秒之后开始，它将标记为失败，不会再运行。
2个job可能被安排在同一时间 执行任务。在这种情况下，你需要确保任务是 idempotent ，如果任务被多次执行，执行的任务的结果也不会改变。
没有job可以安排。为了克服这个问题，请确保Cronjob能运行前一次未完成的job。

这是创建一个简单的Cronjob，每分钟打印出"Hello World"

kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- echo "Hello World"

我推荐这个网站帮助你写出正确的cron定时任务。

接下的3个资源不是CKAD考试的一部分，但我认为你至少应该对它们有一个基本的了解。

Daemon sets

Daemon sets(守护设置)确保在你的集群的每一个 node 都有一个pod 调度。除此以外，pod总是在运行:如果pod死了或者有人删除了它，pod将被重新创建。

一个常见的使用场景是，Daemon sets(守护设置)用来收集每个node的日志和指标。但是，即使你不创建任何东西，它们已经在你的集群中运行了一些Daemo sets(守护设置): Kubernetese创建一个 Daemon set(守护设置)，在每个node上运行kube-proxy 组件。

如果你从集群中移除一个node，Kubernetes不会在别的node上创建它的守护进程，因为这个这个node已经在运行Daemon set(守护设置)。如果你在集群中添加一个node，它会自动运行 Daemon set(守护设置)。

Stateful set

到目前为止，我们应该看到部署无状态的应用或者pods的工具，它们有自己的持久性储存，不随工具停止运行而消失。为了部署有状态的应用，你可以是使用 Stateful set(状态设置)

由于这不是CKAD考试的一部分，我们就不多讲了。

静态 pods

静态pods是由kubelet管理的颇多，而不是由Kubernetes API管理的。

要创建它们，你只需要创建一个普通的pod的配置文件和配置kubelet 扫描该目录。如何你重启kubelet后，它将创建pod，并在失败时重启pod。

Kubernetes将创建pod的镜像，这是Kubernetes API服务器中的一个副本。当你运行kubectl get pods，这个pod会出现，但是如果你试图用kubectl delete podName删除它，通过kubelet创建的静态pod 运行在这个node上，它将直接出现在pod列表中。

如何配置 Pods和Containers(容器)

我们刚刚看到在可以在Kubernetes集群上部署不同的工作负载。现在让我们花些时间学习如何配置工作负载中的pods和containers(容器)。

初始化容器

你可以使用 init containers 来设置你的pod初始状态: 向pod的卷写入一些数据，下载些文件等等。

你可以定义一个或者多个init容器，它们将按顺序执行，只在所有的容器完成后，pod才会运行，因此，init容器也可以用来让pod在执行前等待某个条件。

例如，你可以让一个pod在启动前等待另一个服务的容器完成启动和运行。

你可以通过在pod的定义的 spec部分添加类似的这样的内容定义init容器。

spec:
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
 ...

ConfigMaps

将你的应用程序与代码分开是你应该遵循的实践。ConfigMaps 允许你在Kubernetes这样做。

ConfigMaps 是使用 存储非机密数据的键值对，我们将在下一节看到 Secrects 存储机密数据(如密码)。

# 通过参数传递数值
kubectl create configmap my-map --from-literal=db_url=my-url --from-literal=username=username

# 通过文件获取数值
kubectl create configmap another-map --from-file=my-file

一旦创建，你的应用程序可以在同一个namespace的pod以多种方式使用ConfigMaps。

作为命令行参数
作为环境变量
从只读卷中的一个文件

让我们看看一个pod的定义使用这些办法从ConfigMap中读取。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  restartPolicy: Never
  containers:
    - name: busybox
      image: busybox
      args:
        - /bin/sh
        - -c
        - "echo $MY_VARIABLE" # This value comes from the configmap
      env:
      - name: MY_VARIABLE
        valueFrom:
          configMapKeyRef:
            name: another-map           
            key: my-key # To load individual keys from a map
      envFrom:
      - configMapRef:
          name: another-map # To import all values from a map as env variables
      volumeMounts:
      - name: config
        mountPath: "/config" # This will contain files with the data stored in my-map
        readOnly: true
  volumes:
    # Name to refer to this volume in the pod
    - name: config
      configMap:
        # Name of the ConfigMap
        name: my-map

Secrets

Secrets跟ConfigMaps很相似，但你用它们来存储 机密数据。创建和管理Secrets是一个敏感的话题。请务必阅读文档。在这里，我们将学习基础知识。

创建Secrets的最简单方法是:

#从一个字面量创建 secret
kubectl create secret generic secret-name --from-literal=password=password
#从文件内容来创建 secret
kubectl create secret generic secret-name --from-file=path-to-file

然后，你可以将你的secrets导入pod，以环境变量或者文件的形式:

apiVersion: v1
kind: Pod
metadata:
  name: another-pod
spec:
  restartPolicy: Never
  containers:
    - name: busybox
      image: busybox
      args:
        - /bin/sh
        - -c
        - "echo $MY_VARIABLE"
      env:
      - name: MY_VARIABLE
        valueFrom:
          secretKeyRef:
            name: my-secret2
            key: username # To load individual keys from a map
      envFrom:
      - secretRef:
          name: yet-another-secret # To import all values from a map as env variables
      volumeMounts:
      - name: secret-volume
        mountPath: "/secrets" # This will contain files with the data stored in my-map
        readOnly: true
  volumes:
    # Name to refer to this volume in the pod
    - name: secret-volume
      secret:
        # Name of the Secret
        secretName: my-secret

Probes

Probes(探针)允许你设置判断pod是否健康的规则，是否为服务流量做好准备，是否准备好启动。在本节的最后，我将介绍一个带有这些Probes(探针)的样本。

Liveness probes(活性探针)

Kubernetes 会自动重启 crashed containers (崩溃的容器)。然而,这不会考虑到下面的bug (像你的应用程序的无限循环), 死锁等等。你可以定义 Liveness probes(活性探针) 检测你的应用程序是否健康。 Kubernetes 使用这探针来决定是否要重启容器。

你可以定义三种Liveness probes(活性探针):

HTTP Get, 在你的应用程序中定义一个HTTP路由(如/health)，Kubernetes可以通过HTTP请求获取应用程序是否健康
TCP socket 探针，尝试建立一个TCP连接到一个特定的端口。如果连接不能建立，应用程序将重启。
Exec 探针, 在容器内运行一个命令，如果退出状态码不是0，将重启容器。

Readiness probes(准备就绪探针)

想象一下，一个服务在启动时需要加载一个大的配置文件。容器本身是健康的(这可以用上面的Liveness probes检查)，但是没有启动完，接收请求。

Kubernetes使用Readiness probes(准备就绪探针)来确定你的应用程序是否准备好，处理请求。

关于Liveness probes(活性探针)的东西也适用于Readiness probes(准备就绪探针):

它们可以被配置为初始延迟，超时，阈值，周期等等。
它们可以基于HTTP get调用，TCP socket连接，或者在容器内执行命令。

然而，当Liveness probes(活性探针)告诉Kubernetes信息，Kubernetes让不健康的容器重启。Readiness probes(准备就绪探针)用来从可以接收请求的容器池移除没准备好的容器。一旦容器准备好了，它就可以为请求提供服务。

Startup probes(启动探针)

Startup probes(启动探针)只能在启动期间使用，例如应用程序启动缓慢。如果Startup probes(启动探针)返回成功，liveness and readiness 探针(如果已经配置)，将定期运行。

例如

这个pod 将执行以下命令:

sleep 20
touch /tmp/healthy
sleep 30
rm -rf /tmp/healthy
sleep 600

在配置探针时，你应该注意的最基本参数是:

initialDelaySeconds 开始探针延迟秒数
periodSeconds 探针频率
timeoutSeconds 探针的超时时间
failureThreshold Kubernetes尝试次数，超过这个，将放弃尝试
根据我们的配置, 这些探针将在pod创建后10秒后开始。在前20秒内, 文件 /tmp/healthy是不存在。因此, readiness probe(准备就绪探针)返回失败。在接下30秒内readiness probe(准备就绪探针)返回成功，直到我们删除/tmp/healthy文件。

liveness probe(活性探针) 是简单的echo "I'm healthy"命令。如果它能运行，说明这个pod是健康的，否则，这个pod 要重启。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - args:
    - /bin/sh
    - -c
    - "sleep 20; touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
    image: busybox
    name: tmp
    livenessProbe:
     exec: # If this command can be run, the pod is healthy
       command:
       - echo
       - "I'm healthy"
     initialDelaySeconds: 5 # Only start probing after 5 seconds
     periodSeconds: 5 # Probe every 5 seconds
    readinessProbe:
     exec: # If this command can be run, the pod is ready to serve traffic
       command:
       - cat
       - /tmp/healthy
     initialDelaySeconds: 5 # Only start probing after 5 seconds
     periodSeconds: 10 # Probe every 10 seconds
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

执行这个命令可以看到pods的状态:

kubectl get pods --watch

看到Ready 列的值从 0/1, 到 1/1 和回到 0/.1?

运行这个命令，以获得一个事件列表和探针如何失败的，正如我们期待的。

kubectl describe pods my-pod

容器资源

你可以通过定义创建一个pod:

它运行所需的最小资源量，被称为 requests.
pod可以使用的最大资源量，被称为 limits.

Kubernetes在调度pod时，会考虑到你请求的资源。它不会在一个没有足够容量的节点上调度pod，不管当前资源的消耗情况如何。

例如， pod A和podB 在node N上运行，Kubernetes将通过下面的方法计算新的pod C 是否可以在node N上运行:

Total capacity of N - (resources requested by A + resources requested by B) <= resources requested by C( node N的总资源减去 A B需要的最小资源后，是否少于pod C需要的最小资源量)

即使pod A和B没有使用它们请求的最小资源， Kubernetes 承诺 A和B会有它们所请求的最小资源可使用。这是为什么当前的资源使用情况不在前面的公式表达。

如果一个pod超过它的资源限制(它可以使用的最大资源量时)，会发生两种情况:

如果它超过CPU限制，它将被杀掉
如果它超过内存限制，它将会被重新启动

现在让我们创建一个pod，设置好它的最小内存和cpu和最大内存和cpu使用:

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  restartPolicy: Never
  containers:
    - name: busybox
      image: busybox
      args:
        - /bin/sh
        - -c
        - "echo Hello Kubernetes; sleep 3600"
      resources:
        requests:
          memory: "300Mi"
          cpu: 0.2
        limits:
          memory: "1Gi"
          cpu: 0.5

作为一个练习，设置分配的内存和cpu高得离谱一些的值，去创建pod。你会看到pod从未准备好，将有输出

kubectl describe pods resource-limited-pod

会告诉你为什么.

怎样在Kubernetes中调度Pods

这一部分不是CKAD考试教程的一部分。但我相信，你应该对我在这样阐述的概念有一些基本的了解，因为你在使用Kubernetes的过程中，它们很可能会出现。

Kubernetes允许你通过多种机制来指定你希望的pods，被安排到哪个nodes。

最简单的是使用 nodeSelector 字段，根据一个label选择一个node。其他功能的使用，允许更复杂的设置。

Taints and tolerations

你可以 taint(污损) 一个node 去防止在其中的pods被调度, 不用去修改pods本身。当你 taint(污损)一个node, Kubernetes 会调度这个node 中的 pods，容忍 taint(污损)。

你可以看到这个动作，如果你运行：

kubectl describe node master.Kubernetes

在前一个命令的输出中，你会看到这样一行字:

Taints: node-role.kubernetes.io/master:NoSchedule

这种污损会阻止pods在master node中被调度 (除非pods能容忍这种taint).

有三种类型的taint:

NoSchedule: 如果node不能容忍taint，Kubernetes不会在node中调度pod。
PreferNoSchedule: pods不能容忍taint，不会调度在一个node中，除非pods不能调度到其他地方。
NoExecute: 如果已经在node中运行的pods不容忍taint，就把pods从node中移除出去。

Taints 并不保证 pods 会被调度到特定的nodes。为了实现这一点,你需要探索 Node affinity (node亲和性) 概念。

Node亲和性

Node 亲和性告诉 Kubernetes 去 调度pods到特定的nodes 上.

想象一下，你有一个服务S，需要特定硬件去运行。你像把专用硬件用于这个服务，并希望S的pod在上面运行。你怎样才能实现？

你可以taint这种设备上的nodes，以便只有来自服务S的pod可以在这些node上被调度。但是，Kubernetes可以在其他不不具备的所需硬件上的nodes部署这些pods。

我们可以看到: 组合taints和node 亲和性来确保只有来自服务S的pod 在我们的专门的nodes运行。

Node 亲和性调度将S的pods安排到专门的nodes(而不是其他节点)。
Taints 确保没有其他的pod会被安排在专门的nodes，只有来自服务S的pod。

Kubernetes的存储

默认情况下，当一个pod内的容器重启，容器内的数据会丢失，设计上是这样的(无状态)。

如果你想让数据比容器，pod，甚至是node都持久，你需要用卷。另外，如果一个pod是由多个容器组成的，那么这个pod 的卷可以被所有的容器使用。

卷

在你定义了卷后，在pod层，你需要在每个访问的容器装载它。

有很多类型的卷，以满足不同的使用情况(通常，取决于你想在 pod 被销毁时发生什么)。一些常见的卷类型：

emptyDir: 创建一个初始是空的目录。这是在pod不同容器之间共享文件的简单方法。
hostPath: 将一个文件或者目录从node的文件系统挂载到pod，在pod被删除后，这些文件将保留在主机种。
在AWS、GCP或者 Azure云上的卷.

关于这些和其他类型的卷的更多信息，请参考文档。

在容器种挂载一个卷，你的pod的描述符(我们把这个文件称为 with-mounted-volume.yaml),应该是这样的。

apiVersion: v1
kind: Pod
metadata:
  name: with-mounted-volume
spec:
  volumes: # Volumes are defined at the pod level
  - name: my-volume # We'll use this name to mount the volume inside the pod
    hostPath: # Here we define the type of volume we want
      path: /var/my-k8s-volume
  containers:
  - args:
    - /bin/sh
    - -c
    - "sleep 3600"
    image: busybox
    name: bb
    volumeMounts:
    - name: my-volume
      mountPath: /tmp/my-volume-path
  restartPolicy: Never

由于我们已经创建了一个hostPath的卷，它的内容寿命将超过pod。让我们试一下。

# 创建一个 pod
kubectl apply -f with-mounted-volume.yaml
# 创建一个文件 并挂载到本地
kubectl exec -it with-mounted-volume -- sh -c "echo 'Inside the pod' > /tmp/my-volume-path/newfile"
# 尝试去读取一个文件
kubectl exec -it with-mounted-volume -- cat /tmp/my-volume-path/newfile
# 删除 pod
kubectl delete pods with-mounted-volume
# 创建一个pod
kubectl apply -f with-mounted-volume.yaml
# 查看 `/tmp/my-volume-path` 下的内容，看它是否存在
kubectl exec -it with-mounted-volume -- cat /tmp/my-volume-path/newfile

Revisiting 多容器的pods

现在我们熟悉了卷，让我们创建一个多容器的pod，它将用在一个挂载了卷的容器间共享日期。

我们的 pod 描述定义在文件communicating-containers.yaml
我们将会一个带有2个 busybox 容器的pod。
其中一个容器将"Hello World" 追加到一个文件中。
另一个容器可以访问这个文件的内容(以及放在这个共享卷的任何东西)。我们将查看这个共享文件夹，看另一个容器是如何将Hello World追加到文件里的。
这就是我们定义的pod：

apiVersion: v1
kind: Pod
metadata:
  name: communicating-containers
spec:
  volumes:
  - name: vol
    emptyDir: {}
  containers:
  - args:
    - sh
    - -c
    - "while true;do echo 'Hello World' >> /etc/shared/log; sleep 1; done"
    image: busybox
    name: container-1
    volumeMounts:
    - name: vol
      mountPath: /etc/shared/ # The container can access the volume here
  - args:
    - sh
    - -c
    - "sleep 3600"
    image: busybox
    name: container-2
    volumeMounts:
    - name: vol
      mountPath: /etc/a-different-location # The volume can be mounted at different locations on each containers
  restartPolicy: Never

让我们创建pod:

kubectl apply -f communicating-containers.yaml

一旦pod运行起来，我们就可以tailcontainer-2文件，查看文件尾部内容:

kubectl exec -it communicating-containers -c container-2 -- tail -f /etc/a-different-location/log

尽管container-1写东西到 log,但由于log在一个共享卷中，container-2可以看到这个文件。

Persistent Volumes(持久卷)

Persistent Volumes（PVs 持久卷）和 Persistent Volume Claims（PVCs 持久卷申领）通过存储技术跟pod解耦。 PVs是通过集群管理员创建或者动态根据存储类型.

相对我们之前创建的卷，在pod层定义的，PV（持久卷）有自己的生命周期，独立于任何pod。

在创建PVs 后，用户能创建 Persistent Volume Claims（持久卷申领）来获得它们需要的存储，而不需要关心其存储的实际基础设施。

例如

首先，我们定义一个 Persistent Volume（持久卷）在pv.yaml 文件：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: myvolume
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
    - ReadWriteMany
  storageClassName: normal
  hostPath:
    path: /etc/foo

对于 Persistent Volume Claim（持久卷申领），在文件pvc.yaml描述：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  storageClassName: normal
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi

现在, 让我们在集群中创建资源。

# 首先, 创建Persistent Volume（持久卷）
kubectl apply -f pv.yaml
# 然后, 创建the Persistent Volume Claim（持久卷声明）
kubectl apply -f pvc.yaml

我们可以从前面的例子获取pod的定义，稍作调整，开始使用这个持久卷，代替我们定义的hostPath，这是我们唯一要改的地方。

volumes:
  - name: mypd # 当我们配置pod时，要参考这个卷
    persistentVolumeClaim: # 替换掉hostPath
      claimName: mypvc # 名称是我们刚才创建的pvc

Kubernetes中的网络和安全

关于安全问题，这些概念是你应该熟悉的最低限度，以便通过CKAD考试。

Network Policies(网络策略)

默认情况下，所有的ingress流量(即流入你的应用程序的流量)和egress流量(即你的应用程序流出的流量)都是允许的。如何pod都可以连接到其他的pod，即使它们在不同的namespaces。

你可以定义网络策略，根据不同的标准控制ingress流量和egress流量

为了说明这一点,我们创建一个网络策略，只允许带有label access: allowed的pod访问的我们的数据库:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-db-policy # 起个名称
spec:
  podSelector:
    matchLabels:
      app: db # 数据库pods选择
  ingress: # 允许的 ingress 流量
  - from:
    - podSelector: 
        matchLabels: 
          access: allowed # 只有具有该label的pod才能向数据库发送流量

Security Context(安全背景)

当配置一个Security Context(安全背景)，你可以启用一些安全功能，比如防止容器以root身份运行，选择什么用户运行pod等等，下面是一个例子：

spec:
  securityContext:
    runAsUser: 1000 #这将为这个pod层的每个容器设置用户，但可以被覆盖。
  containers:
  - name: my-container
     image: alpine
     securityContext:
     	runAsUser: 1001 #    这覆盖在pod层上的用户设置 	
  - name: another-container
	....

Services Accounts(服务账号)

你的应用程序可以连接到API 服务器进行数据交换。例如，检索有关pod信息在一个namespace。Service accounts(服务账号) 允许应用服务对API服务器进行认证，以便它们进行数据交互。

这是一个 default service account (默认的服务账号)，但是这不一个好的实践，因为不是每个应用程序都需要在API服务器上执行相同的操作。

创建service account(服务账号)的最简单的方法是通过命令行：

kubectl create serviceaccount my-sa

一旦创建, 你一个分配 serviceAccountName 字段 (pod 描述符)分配给一个pod：

spec:
  serviceAccountName: my-sa
  containers:
  - name: web-server
  ...

一旦应用程序被认证,下一步看它是否有适当的权限来完成它所要的操作,也就是说, 查看应用程序是否被授权。

Role Based Access Control(基于角色的访问控制)

管理授权的一个常见办法是 Role Based Access Control (RBAC) (基于角色的访问控制)。 Service accounts(服务账号) 被链接到一个或者多个role(角色)。每个role(角色)都有在某个资源上执行特定操作的权限。

RBAC 授权是通过两个独立的步骤来定义的：

Role 创建, 使用 Role和ClusterRole 资源, 以指定在某些资源上可以执行的操作。
绑定 roles到账号上, 通过使用 RoleBinding 和 ClusterRoleBinding。

正如你所想，包含前缀Cluster的资源在整个集群范围内可用，而其他的资源只在特定的namespace中定义。

由于这不属于CKAD考试的范围，我们将不讨论如何在你的集群中创建和配置RBAC的细节。

Kubernetes中的可观察性和调试

一旦你部署你的应用程序, 你如何知道你的集群发生了什么？

我们已经介绍了Probes作为一种机制决定是否重启pod，以及pod是否为网络流量做好了准备。在这里，我们将看到更多的机制来更好地了解我们的集群状态，并对任何问题故障排除。

获取Pod的基本信息

访问pods的当前状态，有两个基本选项。这是第一选项：

kubect get pods

这将显示你的pods STATUS, AGE, RESTARTS的数量和多少pods内的容器处于 READY状态. 你可以用这个命令去显示pod的ip地址、labels等等。

第二个选项提供了更详细的信息:

kubectl describe pods my-pod

在这个命令的输出的最底部，你会发现一个事件列表，在出差的情况下会给你提示：

Liveness/readiness probes 失败
拉取镜像出现错误
没有足够的内存分配给pod

等等。

如何获取容器的日志

如果一个pod正在运行，你可以使用以下命令访问它的日志。

kubectl logs pod-name [-c container-name] [-n namespace]

如果你的pod有不止一个容器，你只需传递容器名称。同样，从不同的namespace中检索日志要用namespace 标志符(-n)

你甚至tail日志 -f 标志符，看到日志尾部，获取最新的变化：

kubectl logs -f pod-name [-c container-name] [-n namespace]

这对认证来讲是足够了。然而, 在真实的生产环境中，手动检查日志是很麻烦和低效的。如果你在用GCP(谷歌云)，你会希望用其他技术来管理你的日志和服务，像StackDriver技术。如果你想了解更多的有关StackDriver和GCP的信息，请务必查看我的GCP指南.

处理故障的小技巧

虽然在排除故障时没有灵丹妙药, 但从pod层开始通常是一个好注意，可以从可以找到问题的根本原因。

你的基本工具是我们上面提供的命令，除此之外，你可以随时在pod里打开一个终端。

# 假设你的容器镜像使用 sh
kubectl exec -it my-pod -c container -n namespace -- sh

不建议 用这种方式去解决pod的内部问题, 因为根据设计，pods是短暂的，在pods重启后，你的修改会丢失, 问题会复现。当然, 这是一个好的方法去很好地了解问题。

获取你的pod或者node的指标，你可以运行以下命令。

kubectl top pod pod-name

这些工具帮助你解决日常操作中最常见的问题。有太多的事件会出差，在这里不做解释了。如果你面对一些你无法解决的事情，我建议你访问这个，调试你的应用程序

技巧和窍门

这是我发现的一些技巧，在我日常的Kubernetes工作中，特别是在通过CKAD考试时很有用。提高考试速度和效率部分。考虑到这点，让我们来看看可以做些什么来表现得更好。

设置别名

你将反复输入相同的命令。一旦开始考试，请创建以下别名。

# 重要的别名，我强烈建议设置它们
alias k='kubectl'
alias kg='k get'
alias kgpo='k get pods'
alias kdpo='k describe pod'
alias kd='k describe'

# 我还发现这个非常有用
alias kap='k apply -f'

# 我设置这个，只为工作需要
alias kgpoa='kgpo --all-namespaces'
alias kgpol='kgpo --show-labels'
alias kgpow='kgpo -o wide'
alias kgd='kg deploy'
alias kgs='kg svc'
alias kdd='kd deploy'
alias kds='kd svc'

更快搜索你的命令历史

我见过很多工程师，其中很多是高级工程师(seniors)，笨拙按了20次以上的箭头键，在他们的命令历史中找东西。

不同的是，确保你自如地使用Ctrl + r，只有按下它并开始输入你要输入的命令的某些部分。然后，继续按Ctrl + r，直到你找到它。现在你可以按Enter运行它，或者简单开始修改后再运行。

这是一个节省大量时间的方法，并不是每个人都知道的。

熟悉文档

你可以在考试期间查阅文档，然而，这不是学习新东西的时候。访问文档获得yaml的模板，检查特定的参数等等。

确保你对 文档的结构 很熟悉和知道去哪里找东西。使用 搜索功能 ，更快找到.

这份 Kubectl cheat sheet(简明手册) 是金子和 在考试期间可以为你你所用.

你不需要记住所有的东西

除了文档, kubectl 有 --help 关于大多数命令的查看 (-h 是简写)。大多数时候，你会在那里找到问题的答案。

事实上，我建议你在查阅文档之前这样做，因为这要快得多。

想象一下，你想创建一个资源配额对象。你不记得你需要写的yaml或者创建它的命令。你知道 kubectl command 和 --help 参数。那么在查阅文档之前，你应该先试一试这个：

# 我们可以创建得到创建资源配额对象所需要的东西
kubeclt create quota -h
# 例子
kubeclt create quota my-quota --hard="secrets=2"

你有大量的信息来源，因此你不需要记得住这么多的命令或者参数。

然而，考试期间时间非常有限，我认为值得熟记一些命令和任何使用它们。

快速生成一个基本的pod

这一点尤为重要。与其每一次需要一个pod时从文档中复制和粘贴，不如使用下面的命令获得一个描述符，你可以在以后修改它以满足你的需求。

# 运行一个pod nginx，并将其参数写入一个pod.yaml文件中
kubectl run nginx --image=nginx --restart=Never --dry-run=client -o yaml > pod.yaml
# 可以指定一些参数写入pod.yaml文件中
kubectl run nginx --image=nginx --restart=Never  --port=80 --labels=key=val --dry-run=client -o yaml > pod.yaml

别的有用的参数：

--rm # 在运行完成后立即删除pod
-it # 进入交换式终端，直接在pod中有运行命令

例如，你可以用它创建一个临时的pod，用它验证你的工作:

kubectl run tmp --image=busybox --restart=Never --rm -it -- /bin/sh

现在你可以运行命令 wget -O- svc:port ，看看你的服务是否在运行，网络策略是否在工作等等。

注意：

--dry-run=client -o yaml不仅适用于pod,也适用于很多资源。如果我们回到上一节，我们创建一个资源配额，我们可以得到这样描述符:

kubeclt create quota my-quota --hard="secrets=2" --dry-run=client -o yaml

使用 grep

你不需要深入了解正则表达式。只要使用关键词。例如，从冗长的kubectl describe pods my-pod 快速检索信息：

# -i 参数使搜索不区分大小写。有点慢，但对于非常短的文本来讲，这不会有什么影响。 
# -C 2 参数将显示匹配的最前2行和最后2行 (C 是 context的缩写)
kubectl describe pods my-pod | grep -i -C 2 labels
kubectl describe pods my-pod | grep -i -C 2 ip
...

观察pods 的状态变化

与其每隔几秒手动运行kubeclt get pods来查看变化，不如通过watch 参数来查看你的pods是如何变化：

kubectl get pods --watch

快速删除Pods

犯错是学习过程的一部分。在考试中你也会犯错。由于时间紧迫，我们需要确保在删除资源时不要等待很长时间，通过这些参数可以快速删除pods：

k delete pods my-pod --force --grace-period=0

用一个特定命令运行Pod

我发现学习如何用命令行想pod、job、cronjobs等传递命令很有用，比如这个例子:

kubectl run loop --image=busybox -o yaml --dry-run=client --restart=Never \
-- /bin/sh -c 'for i in {1..10}; do echo "Counting: $i"; done' \
> pod.yaml

这会产生一个文件pod.yaml：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: loop
  name: loop
spec:
  containers:
  - args:
    - /bin/sh
    - -c
    - 'for i in {1..10}; do echo "Counting: $i"; done'
    image: busybox
    name: loop
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

你可以运行一个命令，也可以运行多个命令链，就像一个小型的bash脚本一样：

# 运行一个特定的可执行文件
kubectl run busybox --image=busybox -it --restart=Never -- echo 'hello world'
# 在shell内运行(对运行多个命令很有用)
kubectl run busybox --image=busybox -it --restart=Never -- /bin/sh -c 'echo hello world'

这不是一个巨大的区别，但你不需要记住如何在pod的描述符中写，也不需要浪费时间去打开文档。 你只需要使用你已经知道的东西

roll out(展开)

熟悉rollout命令，以获得关于你的部署状态的信息。

我总是使用 --help 参数，来记住如何做我想做的事。

kubectl rollout -h

Bonus(奖励)

最后这些提示不是针对认证的，而是针对日常工作的：

这个kube-ps1 模块让你很容易知道你是在那个集群和namespace中操作的, 以防止犯错误，比如你不应该乱用 prod(生产环境)资源。
另外，我推荐你看一下Helm。Helm 是一个软件包管理器，可以用来轻松部署应用程序 (像npm)。 Helm还允许你编写模板，你可以根据不同的值 (name, resource requests and limits, and so on)重复使用，创建对象。

练习时间

做事永远比读书学得多。所以我在这里留下一些我在准备考试已经解决的问题，供你练习。查看项目地址和这篇文章.

我建议在你先解决自己的所有问题，再看我上面提到资料。同时验证你做的东西: 检查日志，创建一个pod来连接你的服务等等。这也将有助建立你在考试中肌肉记忆。

尝试根据我的提示来练习这些练习，就像你真的在考试中一样，不分心，在浏览器里只打开一个标签--Kubernetes 的官方文档。

结论

本指南包含了将提高你的技能到新的水平，通过CKAD考试以及成为一名真正的Kubernetes开发者所需要的一切。这一切在你手中，你只需要付出一些努力，祝你好运！

你可以访问到我的博客www.yourdevopsguy.com 和在推特上关注我获得更多高质量的技术内容。

如果你喜欢这篇文章，请分享它，因为你可以帮助别人通过考试或者找到工作。

Kubernetes 完全手册

ZhichengChen — Wed, 19 May 2021 08:00:00 +0000

Kubernetes 是一个开放源代码的容器编排平台，可自动执行容器的部署、管理、扩容伸缩和网络管理。

它是由 Google 使用 Go 语言开发的，这项了不起的技术从 2014 年开始一直是开源的。

根据 Stack Overflow 开发者调研报告 - 2020，Kubernetes 是 #3 最喜爱的平台以及 #3 最想要的平台。

除了功能强大之外，Kubernetes 是公认的难上手。入门确实不容易，但是只要你符合入门条件并且有足够的耐心完成该指南，你将可以：

对基础知识有深入的了解。
可以创建和管理 Kubernetes 集群。
部署任意应用程序到 Kubernetes 集群上。

入门条件

熟悉 JavaScript
熟悉 Linux 终端
熟悉 Docker（建议阅读：Docker 入门教程 - 2021 最新版）

项目代码

实例中的代码可以在这个仓库中找到（你的 ⭐ 是我动力的源泉）。k8s 分支包含完整的代码。

容器编排和 Kubernetes 简介
安装 Kubernetes
Kubernetes 初体验
- Kubernetes 的架构
- Control Plane 组件
- Node 组件
- Kubernetes 对象
- Pods
- Services
- 全景图
- 清除 Kubernetes 相关资源
声明式部署方法
- 编写你的第一套配置
- Kubernetes 控制面板
使用多容器应用程序
- 部署计划
- 复用 Controllers, Replica Sets 以及 Deployments
- 创建你的第一个部署
- 调试 Kubernetes 资源
- 从 Pods 获取容器日志
- 环境变量
- 创建数据库部署
- Persistent Volumes 和 Persistent Volume Claims
- Persistent Volumes 的动态预配置
- 通过 Pods 连接 Volumes
- 组装起来
使用 Ingress Controllers
- 设置 NGINX Ingress Controller
- Kubernetes 中的 Secret 和配置
- 在 Kubernetes 中执行更新发布
- 组合 Configurations
答疑
结论

容器编排和 Kubernetes 简介

摘自 Red Hat —

"容器编排是指自动化容器的部署、管理、扩展和联网。

容器编排可以在使用容器的任何环境中使用。它可以帮助你在不同环境中部署相同的应用，而无需重新设计。"

让我来给你看一个例子。假设你开发了一个很棒的应用，这个应用可以根据时间向人们推荐他们应该吃什么。

假设你已经使用 Docker 容器化了应用并将其部署在了 AWS 上。

如果应用因为某种原因宕机，用户马上就不能访问该服务了。

要解决此问题，可以为同一应用程序制作多个副本，使其服务高可用。

即使其中一台实例发生故障，其它两台实例也可以为用用户提供服务。

假设你的应用程序在熬夜党中流行了起来，在你晚上睡觉的时候涌入大量的请求。

如果所有的实例都因为过载而无法响应该怎么办？谁来进行自动伸缩？即使你扩容了 50 个副本，谁来做健康检查？如何设置网络使使流量打到合适的端点上？负载均衡也是一个大问题，你说呢？

Kubernetes 可以很容易的搞定这些问题。Kubernetes 是一个由多个组件组成的容器编排平台，它可以一刻不眠的使是你的服务保持在理想状态。

假设你要连续运行 50 个应用程序副本，如果请求量激增，服务器也能自动扩容。

你只需把你的需求告诉 Kubernetes，它将为你完成其余的繁重工作。

Kubernetes 会实现并维护状态。如果有旧副本挂掉了，它将创建新的副本，管理网络和存储，推出或回滚更新，甚至在必要时升级服务。

安装 Kubernetes

实际上，在本地计算机上运行 Kubernetes 与在云平台上运行 Kubernetes 有很大不同。你需要下面两个程序，来启动和运行 Kubernetes。

minikube - 它可以在本地计算机的虚拟机（VM）上运行单节点 Kubernetes 集群。
kubectl - Kubernetes 命令行工具，可以在 Kubernetes 集群上执行命令。

除了这两个程序之外，你还需要一个管理程序和一个容器平台。显然 Docker 就是所需的容器平台。推荐的管理程序如下：

Hyper-V Windows 系统
HyperKit Mac 系统
Docker Linux 系统

Hyper-V 作为可选功能内置于 Windows 10（Pro、Enterprise 和 Education）中，可以从控制面板中打开。

HyperKit 是 Mac 平台 Docker Desktop 的核心组件。

在 Linux 上，你可以直接通过 Docker 绕过整个管理程序层。它比任何管理程序都高效，是 Linux 上运行 Kubernetes 的推荐方法。

你可以继续安装上述任何管理程序。或者你想保持简单，只需要获取 VirtualBox。

文章的剩余部分，我们假设你正在使用 VirtualBox。别担心，即使你正在使用其他管理程序，区别也不会太大。

整篇文章，我在装有 Ubuntu 的机器上使用带有 Docker 驱动程序的 minikube 完成。

安装了管理程序和容器化平台之后，就该安装 minikube 和 kubectl 程序了。

如果你使用 Mac 或 Windows，安装完 Docker Desktop 后 kubectl 就已经安装了。可在此处找到 Linux 的安装说明。

另外 minikube 也是必需要安装的，可以在 Mac 上使用 Homebrew，Windows 上使用 Chocolatey 来安装 minikube。可以在此处找到 Linux 的安装说明。

安装完成后，可以通过执行以下命令来测试是否安装成功：

minikube version

# minikube version: v1.12.1
# commit: 5664228288552de9f3a446ea4f51c6f29bbdd0e0
kubectl version

# Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-16T00:04:31Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"darwin/amd64"}
# Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:43:34Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

如果你已经为你的操作系统下载了正确的版本并且设置了正确路径，那么那你已经准备就绪啦。

正如我已经提到的，minikube 在本地计算机上的虚拟机（VM）中运行一个单节点 Kubernetes 集群。我将在下一部分中更详细地解释集群和节点。

现在，可以理解为 minikube 使用你选择的管理程序创建常规 VM，并将其视为 Kubernetes 集群。

如果你在本节中遇到任何问题，请查看本文结尾处的答疑部分。

在启动 minikube 之前，必需正确设置管理程序才能使用。执行如下命令将 VirtualBox 设置为默认驱动程序：

minikube config set driver virtualbox

# ❗ These changes will take effect upon a minikube delete and then a minikube start

可以根据需要将 virtualbox 替换为 hyperv、 hyperkit 或者 docker。这个命令只需运行一次。

执行下面的命令启动 minikube：

minikube start

# ? minikube v1.12.1 on Ubuntu 20.04
# ✨ Using the virtualbox driver based on existing profile
# ? Starting control plane node minikube in cluster minikube
# ? Updating the running virtualbox "minikube" VM ...
# ? Preparing Kubernetes v1.18.3 on Docker 19.03.12 ...
# ? Verifying Kubernetes components...
# ? Enabled addons: default-storageclass, storage-provisioner
# ? Done! kubectl is now configured to use "minikube"

可以通过 minikube stop 命令来停止 minikube 。

Kubernetes 初体验

现在已经在本地上安装了 Kubernetes，是时候动手啦。在此示例中，会向本地集群部署一个非常简单的应用，并熟悉一下基础知识。

本节中会涉及到诸如 pod, service, 负载均衡等术语, 如果你没有搞懂他们，别急，我会在全景图小节中详细介绍它们。

如果你在上一小节已经启动了 minikube，那么就可以开始啦，否则你需要先启动它哦。启动 minikube 后，在终端执行下面的命令：

kubectl run hello-kube --image=fhsinchy/hello-kube --port=80

# pod/hello-kube created

你会立即看到 pod/hello-kube created 消息。 run 命令用来在 pod 中运行指定的容器映像。

Pods 就像是封装容器的盒子，执行以下命令确保 pod 已经成功创建并运行：

kubectl get pod

# NAME         READY   STATUS    RESTARTS   AGE
# hello-kube   1/1     Running   0          3m3s

你应该在 STATUS 列看到 Running 信息。如果看到类似 ContainerCreating 的信息，等待一两分钟，然后再次检查。

默认情况下，从集群外部无法访问 Pod。若要使其可访问，必需使用 service 使其暴露。运行 pod 后，执行下面的命令暴露 pod：

kubectl expose pod hello-kube --type=LoadBalancer --port=80

# service/hello-kube exposed

执行以下命令确保负载均衡服务已经成功创建：

kubectl get service

# NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
# hello-kube   LoadBalancer   10.109.60.75        80:30848/TCP   119s
# kubernetes   ClusterIP      10.96.0.1              443/TCP        7h47m

请确保在列表中可以看到 hello-kube 服务。现在已经有了一个公开的 pod 正在运行，执行下面的命令访问它。

minikube service hello-kube

# |-----------|------------|-------------|-----------------------------|
# | NAMESPACE |    NAME    | TARGET PORT |             URL             |
# |-----------|------------|-------------|-----------------------------|
# | default   | hello-kube |          80 | http://192.168.99.101:30848 |
# |-----------|------------|-------------|-----------------------------|
# ? Opening service default/hello-kube in default browser...

默认的 web 浏览器应该会自动打开，显示类似如下的内容：

这是一个非常简单的 JavaScript 应用程序，使用了 vite 和一点 CSS。如果要了解刚才执行的命令，需要熟悉一下 Kubernetes 的架构。

Kubernetes 的架构

在 Kubernetes 的世界中，node 既可以是一台物理设备也可以是一台指定角色的虚拟机。这样的一组使用一个共享网络彼此通信的设备或者服务器的集合就叫做 集群（cluster）。

在本地设置中， minikube 是单节点的 Kubernetes 集群。因此 minikube 没有像上图的多个服务器，而是只有一台服务器同时充当主服务器和 node。

Kubernetes 集群中的每台服务器都会获得一个角色。有两种不同的角色：

control-plane — 做出大部分必要的决定，并充当整个集群的大脑。它可以是单个服务器或者大型项目中的一组服务器。
node — 负责运行工作负载，这些服务器通常由 control-plane 进行细微管理，并按照提供的说明执行各种任务。

集群中每个服务器都将具有一组特定的组件。这些组件的数量和类型根据服务器在集群中承担的角色而有所不同。这意味着节点不必包含 control plane 中的所有的组件。

在接下来的小节里，将更详细的了解组成 Kubernetes 集群的各个组件。

Control Plane 组件

Kubernetes 集群中的 control plane 由如下五个组件组成：

kube-api-server: 这是 Kubernetes control plane 的入口，负责验证和处理使用客户端库（如 kubectl 程序）传递的请求。
etcd: 这是一个分布式键值存储，是整个集群的唯一键值来源。它保存了配置数据和集群的状态信息。etcd 是一个开源项目，由来自 Red Hat 的人开发。该项目的源代码托管在 etcd-io/etcd GitHub 仓库中。
kube-controller-manager: Kubernetes 中的 controller 负责控制集群的状态。当请求 Kubernetes 集群内容时，controller 会做出响应。kube-controller-manager 是通过一个进程管理所有 controller 进程的程序。
kube-scheduler: 调度就是根据节点的可用资源和任务需要的资源分配任务。kube-scheduler 组件执行 Kubernetes 的任务调度以确保集群中所有的服务都不过载。
cloud-controller-manager: 在真实的云环境中，此组件允许你通过 (GKE/EKS) API 连接集群。这样，与该云平台交互的组件就和与集群交互的组件隔离开了。在 minikube 这一类的组件中，该组件并不存在。

Node 组件

与 control plane 相比，node 的组件数量非常少，如下：

kubelet: 该服务充当 control plane 和集群中每个节点之间的网关。从 control plane 到节点的每条指令都通过此服务。它还与 etcd 存储区进行交互以保持状态信息的更新。
kube-proxy: 这个小服务运行在每个节点上，并为其维护网络规则。到达集群内部服务的任何网络请求都将通过此服务。
Container Runtime: Kubernetes 是一个容器编排工具，因此它最终在容器中运行应用程序。这意味着每个节点都需要一个容器环境，比如 Docker、rkt 或者 cri-o。

Kubernetes 对象

摘自 Kubernetes 文档 —

"在 Kubernetes 系统中，Kubernetes 对象 是持久化的实体。 Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息：

哪些容器化应用在运行（以及在哪些节点上）

可以被应用使用的资源

关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略

当创建 Kubernetes 对象时，实际上是在告诉 Kubernetes 系统这个对象应该存在，任何时候 Kubernetes 系统都应该确保该对象的’

运行。

Pods

摘自 Kubernetes 文档 —

"Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元"。

pod 通常封装一个或多个紧密相关的容器，共享一个生命周期和消耗性资源。

尽管一个 pod 可以容纳多个容器，但是你不应该随意的把容器放到 pod 中。pod 中的容器必须紧密相关，以至于可以将它们视为单个应用程序。

例如，后端的 API 可能依赖数据库，但这并不意味着需要把他们都放在同一个容器中。在整篇文章中，不会有任何 pod 放置多个容器。

通常，你不应该直接管理 pod。相反，你应该使用可以提供更好的可管理的高级对象。将在后面的部分中介绍这些更高级别的对象。

Services

摘自 Kubernetes 文档 —

"Kubernetes 的 service 是将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法"。

Kubernetes pods 是非永久性资源。他们被创造出来，即使过一段时间被销毁了，也不会被回收。

相反，新的 pod 取代了旧的 pod。一些更高级别的对象甚至能动态创建和销毁 pod。

在创建每个 pod 时，会为其分配一个新的 IP 地址。但是对于可以创建、销毁和组合多个 pod 的高级对象而言，在此刻运行的 pod 集合可能与稍后运行的 pod 集合并不相同。

这就导致了一个问题：如果集群中的某些 pod 依赖于集群中的另一组 pod，怎样定位并跟踪彼此的 IP 地址呢？

根据 Kubernetes 文档 —

"Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务"。

本质上讲，service 将执行相同功能的多个 pod 组合在一起，并将它们显示为单个实体。

这样一来，如何跟踪多个 Pod 的问题就消失了，因为单个 service 现在充当了所有 pod 的沟通器。

在 hello-kube 示例中，创建了一个 LoadBalancer 类型的服务，该服务可以将来自集群外部的请求连接到集群内部运行的 pod 上。

无论何时，在需要授予另一个应用程序或者集群外部某个对象一个或多个 pod 的访问权限时，就应该创建一个 service。

比如，如果你有一组运行 web 服务的 pod，需要从 internet 进行访问，那么就必需用 service 提供必要的抽象。

全景图

现在你已经对 Kubernetes 的各个组件有了适当的了解，下图描述了他们是如何协作的：

https://kubernetes.io/docs/concepts/overview/components/

在解释各个细节之前，先看一下 Kubernetes 文档 --

"操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 Kubernetes API。比如，当使用 kubectl 命令行接口时，CLI 会执行必要的 Kubernetes API 调用。"

运行的第一个命令是 run 命令，如下：

kubectl run hello-kube --image=fhsinchy/hello-kube --port=80

run 命令负责运行指定的镜像创建新的 pod。运行此命令后，Kubernetes 集群会执行下面的事件：

kube-api-server 组件接收请求，对其进行校验并进行处理。
kube-api-server 接着与节点上的 kubelet 进行通信，并提供创建 pod 所需的指令。
kubelet 组件开始启动运行 pod，并且在 etcd 存储中保持状态的更新。

run 命令的通用语法如下：

kubectl run  --image= --port=

可以在 pod 内运行任何有效的容器映像。fhsinchy/hello-kube Docker 镜像包含了一个非常简单的 JavaScript 应用程序，该应用程序在容器内部的 80 端口上运行。 --port=80 选项允许容器从内部暴露 80 端口。

新创建的 Pod 运行在 minikube 集群内部，并且无法从外部访问。要公开容器并使其可用，运行的第二个命令如下：

kubectl expose pod hello-kube --type=LoadBalancer --port=80

expose 命令负责创建类型为 LoadBalancer Kubernetes service，该服务允许用户访问 Pod 中运行的应用程序。

和 run 命令一样， expose 命令的执行需要在集群内部运行相似的步骤。在这里， kube-api-server 向 kubelet 组件提供了创建 service （而不是 pod）所需的指令。

expose 命令的通用语法如下：

kubectl expose   --type= --port=

对象类型可以是任意合法的 Kubernetes 对象类型。名称必需和要暴露的对象名称匹配。

--type 表示所需的 service 类型。在内部或外部网络中一共有四种不同的 service 类型。

最后， --port 是要从容器中暴露的端口号。

创建完 service 后，最后一件事就是访问在 pod 的应用程序。为此，需要执行如下命令：

minikube service hello-kube

和之前的命令不同，最后一个命令没有用 kube-api-server。它使用 minikube 和本地集群通讯。 minikube 的 service 命令会返回给定服务的完整 URL。

当使用 --port=80 选项创建 hello-kube 容器时，Kubernetes 会在容器内暴露 80 端口，但是无法在集群外部访问它。

接着，使用 --port=80 选项创建 LoadBalancer 服务，它将 80 端口从该容器映射到本地系统中的任意端口，从而可以从集群外部访问它。

在我的系统上， service 命令返回 pod 的 URL 192.168.99.101:30848。该 URL 中的 IP 实际上是 minikube 虚拟机的真实 IP。可以通过下面的命令来验证：

minikube ip

# 192.168.99.101

可以通过如下命令验证 30848 端口是否指向 pod 内部的 80 端口：

kubectl get service hello-kube

# NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
# hello-kube   LoadBalancer   10.109.60.75        80:30848/TCP   119s

在 PORT(S) 列上，可以看到 80 端口实际上映射到本地系统的 30484 端口。因此，无需运行 service 命令，只需找到 IP 和端口号，然后就可以在浏览器内访问 hello-kube 应用程序。

目前集群的状态如下所示：

如果你了解 Docker，那么你可能觉得使用 service 来公开 pod 有点太麻烦了。

但是当你处理涉及多个 pod 的实例时，你就会了解 Kubernetes 这么做的便利了。

清除 Kubernetes 相关资源

现在已经了解如何创建 pod 和 service 之类的 Kubernetes 资源，现在来学习如何清除它们。也就是删除它们。

执行 kubectl 的 delete 命令来删除资源，用法如下：

kubectl delete

使用下面的命令删除名为 hello-kube 的 pod：

kubectl delete pod hello-kube

# pod "hello-kube" deleted

使用下面的命令删除名为 hello-kube 的 service：

kubectl delete service hello-kube

# service "hello-kube" deleted

或者（现在不可用）使用 delete 命令的 --all 选项来一次性删除所有此类对象。该选项的通用语法如下：

kubectl delete  --all

如果要删除所有的 pod 和 service，依次执行 kubectl delete pod --all 和kubectl delete service --all。

声明式部署方法

坦白讲，你在上一节看到的 hello-kube 例子并不是部署 Kubernetes 的最佳方式。

在之前章节采用的是交互式途径（imperative approach），这意味着你必须手动逐个执行每个命令。采用交互式方法无法很好的工程化。

使用 Kubernetes 进行部署的理想方式是声明式途径（declarative approach），作为开发人员，只需让 Kubernetes 知道服务需要达到的状态，其余的 Kubernetes 会搞定。

在本节中，将会使用声明式部署相同的 hello-kube 应用程序。

如果你尚未克隆上面链接的代码仓库，请立即进行操作。

克隆完毕后，进入 hello-kube 目录，该目录包含 hello-kube 应用程序的代码以及用户构建镜像的 Dockerfile 。

├── Dockerfile
├── index.html
├── package.json
├── public
└── src

2 directories, 3 files

JavaScript 代码位于 src 文件夹下，无需关注，你应该看一下 Dockerfile，了解一下计划部署。Dockerfile 文件内容如下：

FROM node as builder

WORKDIR /usr/app

COPY ./package.json ./
RUN npm install
COPY . .
RUN npm run build

EXPOSE 80

FROM nginx
COPY --from=builder /usr/app/dist /usr/share/nginx/html

如你所见，这是一个多阶段构建（multi-staged build）。

第一阶段使用 node 作为基本镜像，然后将 JavaScript 应用程序编译为生产状态。
第二阶段复制第一阶段生成的文件，并将其粘贴到默认的 NGINX 文档根目录中。这里假设第二阶段的基本镜像是 nginx，会把第一阶段构建的文件运行在 80 端口（nginx 默认端口）。

要在 Kubernetes 上部署应用，需要找到一种方式把镜像运行在容器里，并使其能在外部世界通过 80 端口访问。

编写你的第一套配置

在声明式方式中，无需在终端中发送单个命令，只需在 YAML 文件中写下必要的配置，然后将其提供给 Kubernetes 即可。

在 hello-kube 工程目录下，创建另一个名为 k8s 的目录，k8s 是 k(ubernete = 8 个字符)s 的缩写。

文件夹名不必一定是 k8s，可以任意命名。

甚至没有必要将其放在项目目录中，这些配置文件可以放在计算机中的任何位置，因为这些配置与项目源代码无关。

在 k8s 目录中，创建一个名为 hello-kube-pod.yaml 的新文件。先看一下所有的代码，后面会逐行解释。文件内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: hello-kube-pod
  labels:
    component: web
spec:
  containers:
    - name: hello-kube
      image: fhsinchy/hello-kube
      ports:
        - containerPort: 80

每个有效的 Kubernetes 配置文件都有四个必填字段。如下：

apiVersion: 创建对象使用的 Kubernetes API 版本。该值可能会根据你创建的对象的类型而变化。对于 Pod 的创建，所需的版本是 v1。
kind: 创建的对象的类型。Kubernetes 中有许多种对象。本文介绍了很多对象，目前只需知道要创建的对象是 Pod 即可。
metadata: 对象的唯一标识数据。在此字段下，可以有 name、 labels、 annotation 等信息。当使用 kubectl 命令时 metadata.name 会显示在终端上。metadata.labels 字段下的键值对不必一定是 components: web ，可以指定任意 label 比如 app: hello-kube。在接下来创建 LoadBalancer service 时会使用该值作为选择器。
spec: 包含对象希望达成的状态。 spec.containers 子字段包含将要运行在 Pod 内的容器信息。 spec.containers.name 是节点内的容器运行时分配给新创建容器的值。spec.containers.image 是用来创建容器的镜像。spec.containers.ports 字段是各种端口的配置。containerPort: 80 表示容器对外暴露的端口是 80。

现在使用 apply 命令将这个文件提供给 Kubernetes，用法如下：

kubectl apply -f

如下命令 apply 了名为 hello-kube-pod.yaml 的配置文件：

kubectl apply -f hello-kube-pod.yaml

# pod/hello-kube-pod created

执行以下命令以确保 Pod 已经成功启动并且正在运行：

kubectl get pod

# NAME         READY   STATUS    RESTARTS   AGE
# hello-kube   1/1     Running   0          3m3s

在 STATUS 列中能看到 Running。如果显示的是类似 ContainerCreating 的内容，请等待一两分钟后再试。

当 Pod 启动并运行后，就可以开始写 LoadBalancer service 的配置文件了。

在 k8s 路径下创建一个名为 hello-kube-load-balancer-service.yaml 的文件内容如下：

apiVersion: v1
kind: Service
metadata:
  name: hello-kube-load-balancer-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
  selector:
    component: web

和之前的配置文件一样，apiVersion、kind 和 metadata 字段作用相同。如你所见，metadata 内没有 labels 字段，因为 service 使用 labels 选择其它对象，而其它对象无需选择 service。

记住，service 为其他对象设置了访问策略，而其它对象无需为 service 设置访问策略。

在 spec 字段内可以看到一组新的值。和 Pod 不同，service 有四种不同的类型，他们是 ClusterIP、 NodePort、 LoadBalancer 和ExternalName。

在此例中，使用的是 LoadBalancer 类型，这是把 service 暴露给集群外的标准方法。该服务会给你提供一个 IP 地址，可以使用该 IP 地址连接到集群内运行的应用程序。

LoadBalancer 类型需要两个端口值才能正常工作，在 ports 字段下，port 值用于访问 pod 本身，其值可以是任意值。

targetPort 值是容器内部的值，必需要与容器内部的 port 一致。

正如之前所说，hello-kube 应用运行在容器内部的 80 端口上，已经在 Pod 配置文件中暴露了该端口，因此 targetPort 的值应该为 80。

selector 字段用于标识将要连接该 service 的对象。component: web 键值对必须与 Pod 配置文件中的 labels 字段相匹配。如果你之前在配置文件里使用了其它的键值对如 app: hello-kube ，那么就改成你的键值。

在次使用 apply 命令将这个文件提供给 Kubernetes。文件名为hello-kube-load-balancer-service.yaml，命令如下：

kubectl apply -f hello-kube-load-balancer-service.yaml

# service/hello-kube-load-balancer-service created

执行以下命令以确保负载均衡器已经成功创建：

kubectl get service

# NAME                               TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
# hello-kube-load-balancer-service   LoadBalancer   10.107.231.120        80:30848/TCP   7s
# kubernetes                         ClusterIP      10.96.0.1                443/TCP        21h

确保在列表中能看到 hello-kube-load-balancer-service。现在你已经运行了一个公有的 pod，执行下面的命令直接进行访问：

minikube service hello-kube-load-balancer-service

# |-----------|----------------------------------|-------------|-----------------------------|
# | NAMESPACE |           NAME                   | TARGET PORT |             URL             |
# |-----------|----------------------------------|-------------|-----------------------------|
# | default   | hello-kube-load-balancer-service |          80 | http://192.168.99.101:30848 |
# |-----------|----------------------------------|-------------|-----------------------------|
# ?  Opening service default/hello-kube-load-balancer in default browser...

默认的浏览器应该会自动打开，如下所示：

也可以将两个文件一起提供，如下所示，将文件名替换成目录名即可：

kubectl apply -f k8s

# service/hello-kube-load-balancer-service created
# pod/hello-kube-pod created

请确保终端在 k8s 目录的父目录中。

如果位于 k8s 目录中，可以使用点 (.) 引用当前目录。应用批量配置时，最好提前清除之前创建的资源，以防发生冲突。

声明式方法是使用 Kubernetes 的理想方法，当然有一些例外情况，本文结尾会介绍。

Kubernetes 控制面板

在上一节中，使用 delete 命令清除了 Kubernetes 对象。

在本节中，会引入控制面板。Kubernetes 控制面板是一个图形用户界面，用于管理工作负载、service 等。

在终端中执行以下命令启动 Kubernetes 控制面板：

minikube dashboard

# ? Verifying dashboard health ...
# ? Launching proxy ...
# ? Verifying proxy health ...
# ? Opening http://127.0.0.1:52393/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser...

控制面板应该会在浏览器中自动打开：

控制面板界面很直观，你可以快速上手。虽然创建、管理和删除对象都能从控制面板进行，但是本文其余部分还是会使用 cli 来操作。

在 Pods 列表中，可以使用右边的三个点菜单的 Delete 来删除 Pod。LoadBalancer service 也可以如此操作，实际上 Services 列表就位于 Pods 列表后。

可以按 Ctrl + C 组合键或者关闭终端窗口来停止控制面板服务。

使用多容器应用程序

目前为止，已经使用了单个容器运行了应用程序。

在本节中，将会使用两个容器组成应用程序。你还会学习到 Deployment、ClusterIP、 PersistentVolume、PersistentVolumeClaim 以及一些调试技巧。

将使用的服务是一个具备完整 CRUD 功能的简单的基于 express 的日记 API。该应用使用 PostgreSQL 数据库。因此不仅需要部署应用程序，还需要建立应用程序和数据库服务的内部网络连接。

该应用程序的代码位于项目仓库的 notes-api 目录中。

.
├── api
├── docker-compose.yaml
└── postgres

应用程序代码位于 api 目录中，postgres 目录包含了创建 postgres 镜像的 Dockerfile。 docker-compose.yaml 文件包含使用 docker-compose 运行应用程序的配置文件。

就像上一个项目一样，可以查看每个 service 单独的 Dockerfile，以了解应用程序是如何在容器中运行的。

也可以只检查 docker-compose.yaml 并用它来规划 Kubernetes 部署。

version: "3.8"

services: 
    db:
        build:
            context: ./postgres
            dockerfile: Dockerfile.dev
        environment:
            POSTGRES_PASSWORD: 63eaQB9wtLqmNBpg
            POSTGRES_DB: notesdb
    api:
        build: 
            context: ./api
            dockerfile: Dockerfile.dev
        ports: 
            - 3000:3000
        volumes: 
            - /usr/app/node_modules
            - ./api:/usr/app
        environment: 
            DB_CONNECTION: pg
            DB_HOST: db
            DB_PORT: 5432
            DB_USER: postgres
            DB_DATABASE: notesdb
            DB_PASSWORD: 63eaQB9wtLqmNBpg

查看 api 服务定义，应该可以看到服务运行在内部容器的 3000 端口。它还需要一堆环境变量才能正常运行。

可以忽略 volumes，它在开发环境是必需的，并且构建配置是只针对于 Docker。因此可以保留 Kubernetes 配置文件几乎不变，如下：

Port 映射 – 必需从容器公开相同的端口。
环境变量 – 这些变量在所有的环境中都是相同的（尽管值将发生变化）。

db 服务更简单，它只是一堆环境变量。甚至可以用官方的 postgres 镜像代替自定义的镜像。

使用自定义镜像的好处是数据库实例可以附带预先创建的 notes 表。

该表对于应用程序是必需的，如果查看 postgres/docker-entrypoint-initdb.d 目录，会看到一个名为 notes.sql 的文件，该文件用于在初始化期间创建数据库。

部署计划

和之前的项目部署不同，该项目将变的更加复杂。

在这个项目中，将会创建三个 notes API 实例。这三个实例使用 LoadBalancer service 暴露在集群外面。

除了这个实例，还会有一个 PostgreSQL 系统实例。notes API 应用程序的三个实例都使用 ClusterIP service 和数据库实例通讯。

ClusterIP service 是另外一种 Kubernetes service，它在集群内部使应用可见。也就是说即使没有外部流量，应用程序也可以使用 ClusterIP service。

在此项目中，必需仅通过 Notes API 访问数据库，因此在集群中公开数据库服务是一个理想的选择。

上一节中已经提起到，不应该直接创建 pod。因此，在此项目中使用 Deployment 而不是 Pod。

复制 Controllers、Replica Sets 以及 Deployments

根据 Kubernetes 文档 -

"在 Kubernetes 中，控制器通过监控集群的公共状态，并致力于将当前状态转变为期望的状态。控制回路（Control Loop）是一个非终止回路，用于调节系统状态。"

ReplicationController 可以很轻松的创建多个副本。当创建所需的副本后，控制器将保持当前状态。

如果过了一段时间你决定减少副本的数量，那么 ReplicationController 会立刻清除多余的 pods。

否则，如果副本的数量少于预期数量（也许一些 pod 已经崩溃），ReplicationController 会创建新的副本以达到所需的状态。

尽管 ReplicationController 很强大，但目前已不是创建副本的推荐方式。它已经被较新的 API ReplicaSet 取代。

ReplicaSet 除了提供了更多选择外，ReplicationController 和 ReplicaSet 完成的几乎是同一件事。

拥有更多的选择器是件好事，但是更棒的是，能在发布和回滚更新方面具有更大的灵活性。这就该轮到另一个 Kubernetes API Deployment 出场了。

Deployment 就像是 ReplicaSet API 的一个扩展。Deployment 不但允许你立即创建新副本，还允许使用一个或两个 kubectl 命令发布或回滚更新。

REPLICATIONCONTROLLER	REPLICASET	DEPLOYMENT
可以轻松创建多个 pod	可以轻松创建多个 pod	可以轻松创建多个 pod
Kubernetes 中的原始复制方法	更灵活的选择器	扩展自 ReplicaSets，可以轻松更新和回滚

在这个项目里，会使用 Deployment 来维护应用程序实例。

创建你的第一个部署

首先，为 Notes API 部署编写配置文件，在 notes-api 目录中创建一个 k8s 目录。

在该目录中，创建一个名为 api-deployment.yaml 的文件，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000

在此文件中，apiVersion、 kind、 metadata 和 spec 字段作用与之前的项目相同。与上一个文件相比，不一样的地方如下：

创建 pod 时，apiVersion的值是 v1。但是创建部署时，需要的版本是 apps/v1。Kubernetes API 的版本有时会有些混乱，你可能会有些一头雾水。可以阅读一下官网文档对 Deployment YAML 文件的介绍。
spec.replicas 定义了同时运行的副本数量。将此值设置为 3 意味着希望 Kubernetes 同时运行三个应用实例。
在 spec.selector 中，可以让 Deployment 知道要控制那些 pods。之前已经提到，Deployment 是 ReplicaSet 的扩展，可以控制 Kubernetes 对象。将 selector.matchLabels 设置为 component: api 意味着 Deployment 会控制 label 为 component: api 的 pods。这行代码的意思就是让 Kubernetes 知道你希望 Deployment 来控制 label 为 component: api 的 pods。
spec.template 是用于配置 pod 的模板，它与之前的配置文件几乎相同。

现在，要查看此配置效果，和之前一样 apply 该文件：

kubectl apply -f api-deployment.yaml

# deployment.apps/api-deployment created

执行下面的命令确保 Deployment 已经成功创建：

kubectl get deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   0/3     3            0           2m7s

如果查看 READY 列，会看到 0/3。这意味着容器尚未创建，等待几分钟，然后在试一次。

kubectl get deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   0/3     3            0           28m

坦白讲，我已经等了将近半个小时，pod 还未准备就绪。API 本身只有几百 kb。这种规模的部署不应该花这么长的时间，这意味着有问题，我们来解决它。

调试 Kubernetes 资源

开始之前，首先回到起点。get 命令是一个很基础的命令。

get 命令可以打印一张包含一个或多个 Kubernetes 资源重要信息的表。用法如下：

kubectl get

在终端执行如下代码，在 api-deployment 上运行 get 命令：

kubectl get deployment api-deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   0/3     3            0           15m

可以省略 api-deployment 以获取所有可用的部署列表。也可以在配置文件上使用 get 命令。

可以使用如下命令获取有关 api-deployment.yaml 文件中描述的部署信息：

kubectl get -f api-deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   0/3     3            0           18m

默认情况下，get 命令显示的信息非常少，可以使用 -o 选项获取更多信息。

-o 选项设置 get 命令的输出格式，可以使用 wide 输出格式查看更详细信息。

kubectl get -f api-deployment.yaml

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES               SELECTOR
# api-deployment   0/3     3            0           19m   api          fhsinchy/notes-api   component=api

现在列表包含了更多的信息，可以在官方文档了解有关 get 命令的选项。

老实说，仅仅是运行 Deploymen 的 get 命令没啥意思。还需要获取更底层资源的信息。

看一下 pod 列表，看看里面都有啥东西：

kubectl get pod

# NAME                             READY   STATUS             RESTARTS   AGE
# api-deployment-d59f9c884-88j45   0/1     CrashLoopBackOff   10         30m
# api-deployment-d59f9c884-96hfr   0/1     CrashLoopBackOff   10         30m
# api-deployment-d59f9c884-pzdxg   0/1     CrashLoopBackOff   10         30m

现在发现了一些有用的东西。所有的 pods 都有一个值为 CrashLoopBackOff 的 STATUS。之前只接触过 ContainerCreating 和 Running 状态。你可能还会在 CrashLoopBackOff 处看到 Error。

看一下 RESTARTS 列，会发现 pod 已经重启 10 多次了，着意味着因为某些原因， pod 启动失败了。

现在，要查看一个 pod 的更详细信息，可以使用另一个名为 describe 的命令。它和 get 命令很像，用法如下：

kubectl get

执行下面的命令查看 api-deployment-d59f9c884-88j4 pod 的详细信息：

kubectl describe pod api-deployment-d59f9c884-88j45

# Name:         api-deployment-d59f9c884-88j45
# Namespace:    default
# Priority:     0
# Node:         minikube/172.28.80.217
# Start Time:   Sun, 09 Aug 2020 16:01:28 +0600
# Labels:       component=api
#               pod-template-hash=d59f9c884
# Annotations:  
# Status:       Running
# IP:           172.17.0.4
# IPs:
#   IP:           172.17.0.4
# Controlled By:  ReplicaSet/api-deployment-d59f9c884
# Containers:
#  api:
#     Container ID:   docker://d2bc15bda9bf4e6d08f7ca8ff5d3c8593655f5f398cf8bdd18b71da8807930c1
#     Image:          fhsinchy/notes-api
#     Image ID:       docker-pullable://fhsinchy/notes-api@sha256:4c715c7ce3ad3693c002fad5e7e7b70d5c20794a15dbfa27945376af3f3bb78c
#     Port:           3000/TCP
#     Host Port:      0/TCP
#     State:          Waiting
#       Reason:       CrashLoopBackOff
#     Last State:     Terminated
#       Reason:       Error
#       Exit Code:    1
#       Started:      Sun, 09 Aug 2020 16:13:12 +0600
#       Finished:     Sun, 09 Aug 2020 16:13:12 +0600
#     Ready:          False
#     Restart Count:  10
#     Environment:    
#     Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-gqfr4 (ro)
# Conditions:
#   Type              Status
#   Initialized       True
#   Ready             False
#   ContainersReady   False
#   PodScheduled      True
# Volumes:
#   default-token-gqfr4:
#     Type:        Secret (a volume populated by a Secret)
#     SecretName:  default-token-gqfr4
#     Optional:    false
# QoS Class:       BestEffort
# Node-Selectors:  
# Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
#                  node.kubernetes.io/unreachable:NoExecute for 300s
# Events:
#   Type     Reason     Age                         From               Message
#   ----     ------     ----                        ----               -------
#   Normal   Scheduled                     default-scheduler  Successfully assigned default/api-deployment-d59f9c884-88j45 to minikube
#   Normal   Pulled     2m40s (x4 over 3m47s)       kubelet, minikube  Successfully pulled image "fhsinchy/notes-api"
#   Normal   Created    2m40s (x4 over 3m47s)       kubelet, minikube  Created container api
#   Normal   Started    2m40s (x4 over 3m47s)       kubelet, minikube  Started container api
#   Normal   Pulling    107s (x5 over 3m56s)        kubelet, minikube  Pulling image "fhsinchy/notes-api"
#   Warning  BackOff     (x44 over 3m32s)  kubelet, minikube  Back-off restarting failed container

整个输出中最有用的部分是 Events 部分，如下：

Events:
  Type     Reason     Age                         From               Message
  ----     ------     ----                        ----               -------
  Normal   Scheduled                     default-scheduler  Successfully assigned default/api-deployment-d59f9c884-88j45 to minikube
  Normal   Pulled     2m40s (x4 over 3m47s)       kubelet, minikube  Successfully pulled image "fhsinchy/notes-api"
  Normal   Created    2m40s (x4 over 3m47s)       kubelet, minikube  Created container api
  Normal   Started    2m40s (x4 over 3m47s)       kubelet, minikube  Started container api
  Normal   Pulling    107s (x5 over 3m56s)        kubelet, minikube  Pulling image "fhsinchy/notes-api"
  Warning  BackOff     (x44 over 3m32s)  kubelet, minikube  Back-off restarting failed container

从这些事件中，可以看到容器镜像已经成功 pulled，容器也已经创建，但是显然从 Back-off restarting failed container 中可以看出该容器无法启动。

describe 命令和 get 命令类似，并且具有相同的选项。

可以省略 api-deployment-d59f9c884-88j45 名字以获取所有 pods 的信息。或者也可以使用 -f 选项将配置文件传入命令。访问官方文档了解更多信息。

既然已经知道了是容器出了问题，那么就让我们到容器层面看看到底出了什么问题吧。

从 Pods 获取容器日志

还有另一个名为 logs 的 kubectl 命令，可以从容器内部获取容器的日志，用法按如下：

kubectl logs

使用如下命令 api-deployment-d59f9c884-88j45 查看 pod 内的日志：

kubectl logs api-deployment-d59f9c884-88j45
# > api@1.0.0 start /usr/app
# > cross-env NODE_ENV=production node bin/www
# /usr/app/node_modules/knex/lib/client.js:55
#     throw new Error(knex: Required configuration option 'client' is missing.);
    ^
# Error: knex: Required configuration option 'client' is missing.
#     at new Client (/usr/app/node_modules/knex/lib/client.js:55:11)
#     at Knex (/usr/app/node_modules/knex/lib/knex.js:53:28)
#     at Object. (/usr/app/services/knex.js:5:18)
#     at Module._compile (internal/modules/cjs/loader.js:1138:30)
#     at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
#     at Module.load (internal/modules/cjs/loader.js:986:32)
#     at Function.Module._load (internal/modules/cjs/loader.js:879:14)
#     at Module.require (internal/modules/cjs/loader.js:1026:19)
#     at require (internal/modules/cjs/helpers.js:72:18)
#     at Object. (/usr/app/services/index.js:1:14)
# npm ERR! code ELIFECYCLE
# npm ERR! errno 1
# npm ERR! api@1.0.0 start: cross-env NODE_ENV=production node bin/www
# npm ERR! Exit status 1
# npm ERR!
# npm ERR! Failed at the api@1.0.0 start script.
# npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

这正是出问题的地方，看起来是 knex.js 库缺少一个必要的值，导致程序启动失败。可以从官方文档了解更多关于 logs 命令的信息。

出现这个错误主要是因为在部署定义中缺少了一些必需的环境变量。

如果在看一下 docker-compose.yaml 文件中的 api service 定义，应该会看到类似如下的内容：

    api:
        build: 
            context: ./api
            dockerfile: Dockerfile.dev
        ports: 
            - 3000:3000
        volumes: 
            - /usr/app/node_modules
            - ./api:/usr/app
        environment: 
            DB_CONNECTION: pg
            DB_HOST: db
            DB_PORT: 5432
            DB_USER: postgres
            DB_DATABASE: notesdb
            DB_PASSWORD: 63eaQB9wtLqmNBpg

应用程序与数据库进行连接需要这些环境变量。所以，把这些数据添加到部署配置中就可以解决该问题。

环境变量

给 Kubernetes 配置文件添加环境变量非常简单。打开 api-deployment.yaml 文件并按如下更新内容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000
          
          # these are the environment variables
          env:
            - name: DB_CONNECTION
              value: pg

containers.env 字段包含所有的环境变量，如果细心你会发现我还没有给 docker-compose.yaml 文件添加所有的环境变量，我只添加了一个。

DB_CONNECTION 表示应用正在使用 PostgreSQL 数据库，添加这个变量就可以解决上述问题。

现在通过执行下面的命令在此 apply 配置文件：

kubectl apply -f api-deployment.yaml

# deployment.apps/api-deployment configured

这次显示资源已经被 configured。这就是 Kubernetes 厉害的地方，apply 配置文件可以立即生效。

现在在次使用 get 命令确保一切运行正常。

kubectl get deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   3/3     3            3           68m

kubectl get pod

# NAME                              READY   STATUS    RESTARTS   AGE
# api-deployment-66cdd98546-l9x8q   1/1     Running   0          7m26s
# api-deployment-66cdd98546-mbfw9   1/1     Running   0          7m31s
# api-deployment-66cdd98546-pntxv   1/1     Running   0          7m21s

三个 pod 都在运行，并且 Deployment 也运行良好。

创建数据库部署

既然 API 已经启动并且运行，是时候为数据库实例编写配置了。

在 k8s 目录中另创建一个名为 postgres-deployment.yaml 的文件，文件内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      containers:
        - name: postgres
          image: fhsinchy/notes-postgres
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_PASSWORD
              value: 63eaQB9wtLqmNBpg
            - name: POSTGRES_DB
              value: notesdb

配置本身与上一次非常相似，我就不详细解释了，根据目前学到的知识你应该可以了解。

PostgreSQL 默认运行在 5432 端口上，运行 postgres 容器需要 POSTGRES_PASSWORD 变量。该密码也会用于 API 连接数据库。

POSTGRES_DB 变量是可选的，但是在该项目里是必需的，否则会初始化失败。

可以在 Docker Hub 页面上了解 postgres Docker 镜像的更多信息。在此项目中，化繁为简，副本数量设置为 1。

执行以下命令 apply 这个文件：

kubectl apply -f postgres-deployment.yaml

# deployment.apps/postgres-deployment created

通过 get 命令确保 pod 已经正常部署和运行：

kubectl get deployment

# NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
# postgres-deployment   1/1     1            1           13m

kubectl get pod

# NAME                                   READY   STATUS    RESTARTS   AGE
# postgres-deployment-76fcc75998-mwnb7   1/1     Running   0          13m

尽管 pod 已经成功部署和运行，但是数据库部署还是有很大的问题。

如果你以前使用过数据库系统，应该知道数据库是把数据存储在文件系统中。目前，数据库部署如下：

postgres 容器由 pod 封装，数据保留在容器内部的文件系统中。

现在，如果由于某种原因，容器崩溃或者封装容器的 pod 发生故障，则保存在文件系统的所有数据都将丢失。

崩溃后，Kubernetes 会创建一个新的 pod 来维持状态，但是两个 pod 之间没有任何数据转移机制。

为了解决这个问题，可以将数据存储在集群 pod 外部的单独空间中。

和管理计算实例相比，管理此类存储面临的是另一些问题。Kubernetes 中的 PersistentVolume 子系统为用户和管理员提供了一个 API，该 API 从存储的使用方式中抽象出如何提供存储的细节。

Persistent Volumes 和 Persistent Volume Claims

摘自 Kubernetes 文档 —

"持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应。持久卷是集群资源，就像节点也是集群资源一样。"

实际上，PersistentVolume 是一种从存储空间获得切片并将其保留给特定 pod 的方法。Volumes 始终由 pod 占用，而不是像 deployment 这样的高级对象占用。

如果要在具有多个 pod 的 deployment 中使用 volume，必须要执行一些附加步骤。

在 k8s 目录中创建一个名为 database-persistent-volume.yaml 的新文件，内容如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: database-persistent-volume
spec:
  storageClassName: manual
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

apiVersion、 kind 和 metadata 与其它配置文件里的用法一致，在 spec 字段里，有一些新字段：

spec.storageClassName 指示 volume 的名称。假设云提供商有三种可用的存储。slow、 fast 和 very fast 。从云存储上获取的存储方式取决于支付的金额。如果需要 very fast 存储，则需要支付更多的费用。这些不同类型的存储就是 classes。在本例里我使用 manual，在本地集群里可以使用任何你喜欢的选项。
spec.capacity.storage 代表 volume 的存储大小。在此项目中设置了 5GB 的存储空间。
spec.accessModes 设置卷的访问模式。一共有三种存储模式，ReadWriteOnce 代表该 volume 可以通过单个 node 以读写方式安装。ReadWriteMany 则代表该 volume 可以被多个 node 以读写的方式安装。ReadOnlyMany 意味着该 volume 可以被多个 node 以只读的方式安装。
spec.hostPath 是特定于开发者的。它将本地单 node 集群的目录映射为 persistent volume。/mnt/data 意味着保存在持久卷（persistent volume）中的数据位于集群的 /mnt/data 文件夹内。

执行下面的命令 apply 配置文件：

kubectl apply -f database-persistent-volume.yaml

# persistentvolume/database-persistent-volume created

现在使用 get 命令确定 volume 创建成功：

kubectl get persistentvolume

# NAME                         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
# database-persistent-volume   5Gi        RWO            Retain           Available           manual                  58s

现在已经创建了 persistent volume，需要让 postgres pod 访问它，可以通过PersistentVolumeClaim (PVC) 。

persistent volume 声明是 pod 对存储的要求。假设在集群中有很多 volumes。该声明将定义必需满足 pod 的需求的 volume 的特征。

一个类似的的例子是从商店购买 SSD。销售员向你展示了如下模型：

MODEL 1	MODEL 2	MODEL 3
128GB	256GB	512GB
SATA	NVME	SATA

现在你和销售员要求至少 200GB 的存储容量，并且驱动器的型号是 NVME。

MODEL1 是容量小于 200GB 的 SATA，与你的要求不符，MODEL 3 容量大于 200GB，但是不是 NVME 接口的。只有 MODEL2 是容量大于 200GB 并且接口是 NVME 的。正是需要的。

销售人员向你展示的 SSD models 就等同于 persistent volumes，你的要求就等同于 persistent volume 声明。

在 k8s 目录下创建一个名为 database-persistent-volume-claim.yaml 的新文件，文件内容如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-persistent-volume-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

apiVersion、 kind 和 metadata 和之前的作用一致。

spec.storageClass 表示存储类型的声明配置文件。着意味着将任何设置为 manual 的 spec.storageClass 的 PersistentVolume 都适合此类声明。如果有多个设置为 manual 的 volumes ，那么将获得其中任意一个的声明。如果没有 class 为 manual 的 volume，那就动态配置一个。
spec.accessModes 在此设置访问模式。这表明该声明希望使用具有 ReadWriteOnce 的 accessMode。假设有两个设置为 manual 的 volumes 。其中一个将其 accessModes 设置为 ReadWriteOnce，另一个设置为 ReadWriteMany。该声明将获取其中的 ReadWriteOnce 。
resources.requests.storage 是此声明所需要的存储量 2Gi 并不意味着给定的卷必须恰好具有 2GB 的存储容量。而是意味着它至少要有 2GB。你应该还记得之前将存储容量设置为 5GB，大于 2GB。

执行下面的命令 apply 文件：

kubectl apply -f database-persistent-volume-claim.yaml

# persistentvolumeclaim/database-persistent-volume-claim created

使用 get 命令确定 volume 已经成功创建：

kubectl get persistentvolumeclaim

# NAME                               STATUS   VOLUME                       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# database-persistent-volume-claim   Bound    database-persistent-volume   5Gi        RWO            manual         37s

查看 VOLUME 列，这个声明与之前创建的 database-persistent-volume 持久卷绑定，在看一下 CAPACITY，它是 5Gi，因为该声明要求 volume 至少有 2GB 的存储容量。

Persistent Volumes 的动态预配置

在上一小节，你已经创建了一个 persistent volume，然后创建了一个声明，但是如果以前没有设置任何 persistent volume 该怎么办呢？

在这种情况下，将自动设置与声明兼容的持久卷。

开始之前，先执行如下命令删除之前创建的 persistent volume 和 persistent volume 声明：

kubectl delete persistentvolumeclaim --all

# persistentvolumeclaim "database-persistent-volume-claim" deleted

kubectl delete persistentvolumeclaim --all

# persistentvolume "database-persistent-volume" deleted

打开 database-persistent-volume-claim.yaml 文件将内容更新为如下内容：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-persistent-volume-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

我已经从文件中删除了 spec.storageClass 字段，现在重新 apply database-persistent-volume-claim.yaml 文件（无需应用 database-persistent-volume.yaml 文件）：

kubectl apply -f database-persistent-volume-claim.yaml

# persistentvolumeclaim/database-persistent-volume-claim created

现在使用 get 命令查看声明信息：

kubectl get persistentvolumeclaim

# NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# database-persistent-volume-claim   Bound    pvc-525ae8af-00d3-4cc7-ae47-866aa13dffd5   2Gi        RWO            standard       2s

正如你看到的，已经提供了名为 pvc-525ae8af-00d3-4cc7-ae47-866aa13dffd5 且存储容量为 2Gi 的 volume，将其动态绑定到了声明。

该项目的剩余部分使用静态或者动态预配置 persistent volume 都可以。我会使用动态配置。

通过 Pods 连接 Volumes

现在你已经创建了一个 persistent volume 和声明，是时候让数据库 pod 使用该 volume 了。

可以把之前小节创建的 persistent volume 声明连接到 pod 上。打开 postgres-deployment.yaml 文件，将内容更新如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      # volume configuration for the pod
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: database-persistent-volume-claim
      containers:
        - name: postgres
          image: fhsinchy/notes-postgres
          ports:
            - containerPort: 5432
          # volume mounting configuration for the container
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
              subPath: postgres
          env:
            - name: POSTGRES_PASSWORD
              value: 63eaQB9wtLqmNBpg
            - name: POSTGRES_DB
              value: notesdb

我在此配置文件中添加了两个字段。

spec.volumes 字段包含了供 pod 查找 persistent volume 申明的必要信息。 spec.volumes.name 可以是你想要的任何东西。spec.volumes.persistentVolumeClaim.claimName 必需与 database-persistent-volume-claim.yaml 文件中的 metadata.name 值相匹配。
containers.volumeMounts 包含容器挂载的 volume 所必需的信息。containers.volumeMounts.name 必需与 spec.volumes.name 中的值相匹配。containers.volumeMounts.mountPath 代表 volume 挂载的目录。/var/lib/postgresql/data 是 PostgreSQL 的默认数据目录。containers.volumeMounts.subPath 表示将在 volume 创建的目录。假设你与其它的 pod 正在使用相同的 volume。保存在 /var/lib/postgresql/data 目录中的所有数据都将进入 volume 的 postgres 路径下。

现在执行下面的命令重新 apply postgres-deployment.yaml 文件：

kubectl apply -f postgres-deployment.yaml

# deployment.apps/postgres-deployment configured

现在，已经进行了正确的数据库部署，数据丢失的风险小了很多。

想要在这里提及的是，目前数据库部署中只有一个副本，如果有多个副本，那么情况会有所不同，

多个 pod 在不知道彼此存在情况下访问相同的 volume 会产生灾难性的后果，在 volume 内为 pod 创建子目录可以解决这个问题。

组装起来

现在已经运行了 API 和数据库，是时候建立网络并做一些后续工作了。

在前面的章节中已经了解到 Kubernetes 中的网络设置，在开始编写服务之前，先看看我为项目制定的联网计划。

数据库只使用 ClusterIP service 在集群内暴露，不允许任何外部流量访问。
API 部署服务将暴露给外部世界，用户将与 API 通信，API 与数据库通信。

之前通过 LoadBalancer service 将应用暴露给了外部世界，ClusterIP 则再集群中公开应用，并且不允许外部流量访问。

鉴于数据库服务应仅在集群内可用，因此 ClusterIP service 服务非常适合此方案。

在 k8s 目录下创建一个名为 postgres-cluster-ip-service.yaml 的文件，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: postgres-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: postgres
  ports:
    - port: 5432
      targetPort: 5432

ClusterIP 的配置文件与 LoadBalancer 的配置文件差不多，唯一的不同的是 spec.type 。

现在，这个文件就清晰了。5432 是 PostgreSQL 运行的默认端口。所以也要集群内暴露 5432 。

接下来是 LoadBalancer service 的配置文件，负责将 API 暴露给外界。创建一个名为 api-load-balancer-service.yaml 的文件，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: api-load-balancer-service
spec:
  type: LoadBalancer
  ports:
    - port: 3000
      targetPort: 3000
  selector:
    component: api

此配置与上一节中的配置相同。API 运行在容器内的 3000 端口，所以也要在集群中暴露此端口。

最后要做的是要将环境变量添加到 API deployment 中。打开 api-deployment.yaml 文件并按照如下更新其内容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000
          env:
            - name: DB_CONNECTION
              value: pg
            - name: DB_HOST
              value: postgres-cluster-ip-service
            - name: DB_PORT
              value: '5432'
            - name: DB_USER
              value: postgres
            - name: DB_DATABASE
              value: notesdb
            - name: DB_PASSWORD
              value: 63eaQB9wtLqmNBpg

之前，spec.containers.env 下面只有 DB_CONNECTION 变量，新涉及到的字段如下：

DB_HOST 表示数据库服务的地址。在非容器化环境中，该值通常为 127.0.0.1。但是在 Kubernetes 环境中，并不知道数据库容器的 IP 地址。因此只需使用公开的数据库 service 的名字即可。
DB_PORT 是数据库 service 公开的端口，即 5432。
DB_USER 用于连接数据库的用户，默认的用户名是 postgres。
DB_DATABASE API 将要连接的数据库，必须与 postgres-deployment.yaml 文件中的 spec.containers.env.DB_DATABASE 值相同。
DB_PASSWORD 用于连接数据库的密码，必须与 postgres-deployment.yaml 文件中的 spec.containers.env.DB_PASSWORD 值相匹配。

完成此操作后就可以测试 API 了。在执行操作之前，执行一下下面的命令 apply 所有的配置文件：

kubectl apply -f k8s

# deployment.apps/api-deployment created
# service/api-load-balancer-service created
# persistentvolumeclaim/database-persistent-volume-claim created
# service/postgres-cluster-ip-service created
# deployment.apps/postgres-deployment created

如果遇到任何错误，只需删除所有的资源并重新 apply 文件即可。service、persistent volumes、persistent volume 声明会立即创建。

用 get 命令确保所有的部署都已经启动且运行：

kubectl get deployment

# NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment        3/3     3            3           106s
# postgres-deployment   1/1     1            1           106s

从 READY 列中可以看出，所有的 pod 都已经启动并且正在运行。执行 minikube 的 service 命令访问 API。

minikube service api-load-balancer-service

# |-----------|---------------------------|-------------|-----------------------------|
# | NAMESPACE |           NAME            | TARGET PORT |             URL             |
# |-----------|---------------------------|-------------|-----------------------------|
# | default   | api-load-balancer-service |        3000 | http://172.19.186.112:31546 |
# |-----------|---------------------------|-------------|-----------------------------|
# * Opening service default/api-load-balancer-service in default browser...

API 会在默认浏览器里立即打开：

这时 API 的默认响应，还可以通过 Insomnia 或者 Postman 来测试 http://172.19.186.112:31546/ API 的完整 CRUD 功能。

可以将 API 源代码随附的测试作为文档查看。只需打开 api/tests/e2e/api/routes/notes.test.js 文件即可，如果你有 JavaScript 和express 的经验，那么理解这个文件会很容易。

使用 Ingress Controller

目前为止，已经使用 ClusterIP 在集群内公开了的应用程序，使用 LoadBalancer 把应用暴露给集群外。

尽管我已经引用了 LoadBalancer 作为引用于集群外部公开应用程序的的标准 service，但是它还有一些缺点。

当使用 LoadBalancer services 在云环境中公开应用程序时，必需单独为每个公开的服务付费。这在大型项目下回非常昂贵。

还有另一种成为 NodePort 的 service，可以代替 LoadBalancer service。

NodePort 在集群所有节点上打开一个特定的端口，并处理通过该打开端口的所有流量。

你知道，service 将多个 pod 组合在一起，并控制他们的访问方式。通过公开端口到达 service 的任何请求都将最终在正确的容器中。

用于创建 NodePort 的实例配置文件如下：

apiVersion: v1
kind: Service
metadata:
  name: hello-kube-node-port
spec:
  type: NodePort
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 31515
  selector:
    component: web

这里的 spec.ports.nodePort 字段值必须在 30000 和 32767 之间，此范围超出了各种服务通常所使用的常用端口。端口的数字位数很多。、

尝试用 NodePort service 替换前面几节创建的 LoadBalancer service，这应该不难，算是对所学知识的简单测试。

创建 Ingress 可以解决此问题，澄清一下，Ingress 不是一种 service，相反，它位于各个 service 前面，充当路由器的角色。

在集群中使用 Ingress 资源用到了 IngressController。可以在 Kubernetes 文档中找到可用的 ingress controllers 列表。

设置 NGINX Ingress Controller

在此例中，通过向其添加 front end 来扩展 notes API。使用 Ingress 来暴露应用，而不是使用诸如 LoadBalancer 或者 NodePort 之类的 service。

将要使用的而控制器是 NGINX Ingress Controller，在此 NGINX 将用于不同 service 请求的路由。NGINX Ingress Controller 使 Kubernetes 集群的 NGINX 配置变的更容易。

项目代码在 fullstack-notes-application 路径下：

.
├── api
├── client
├── docker-compose.yaml
├── k8s
│   ├── api-deployment.yaml
│   ├── database-persistent-volume-claim.yaml
│   ├── postgres-cluster-ip-service.yaml
│   └── postgres-deployment.yaml
├── nginx
└── postgres

5 directories, 1 file

你会看到 k8s 目录，包含在上一个小节中除了 api-load-balancer-service.yaml 文件的所有的配置文件。

原因是，在该项目中，旧的 LoadBalancer service 将被 Ingress 代替。另外，无需公开 API，而是将前端应用程序公开即可。

在开始编写新文件之前，先看看架构。

用户访问前端应用程序并提交必要的数据，然后前端应用程序将提交的数据转发到后端 API。

然后 API 将数据保留在数据库中，并将其发送回前端应用程序。然后使用 NGINX 实现请求的路由。

可以查看 nginx/production.conf 文件了解如何设置此路由。

现在实现目标所必需的网络如下：

具体如下：

Ingress 将充当此应用程序的入口点和路由器，这是一个 NGINX 类型的 Ingress，因此端口是 nginx 的默认端口 80。
到 / 的每个请求都会被路由到前端应用（左侧的服务）处理。因此，如果应用程序的 URL 是 https://kube-notes.test ，那么所有的 https://kube-notes.test/foo 或者 https://kube-notes.test/bar 都会由前端应用程序处理。
到 /api 的每个请求都会被路由到后端的 API （右侧的服务）处理。因此，如果 URL 是 https://kube-notes.test，那么所有的 https://kube-notes.test/api/foo 或者 https://kube-notes.test/api/bar 都会由后端 API 处理。

完全可以将 Ingress service 配置与子域名一起使用，而不是向这样的路径，这里的设计使用路径的方式。

在本小节中，必需编写四个新的配置文件：

ClusterIP 是 API deployment 的配置。
Deployment 是 front-end 应用的配置。
ClusterIP 是 front-end 应用的配置。
Ingress 是路由的配置。

前三个文件我会快速的过一下。

第一个文件是 api-cluster-ip-service.yaml 配置，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: api-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: api
  ports:
    - port: 3000
      targetPort: 3000

尽管在上一小节中，将 API 直接暴露给了外界，但在本小节中，Ingress 承担起了这个任务，同时使用 ClusterIP 在内部公开 API。

配置不言自明，无需过多解释。

接下来创建一个名为 client-deployment.yaml 的文件来运行前端应用，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: client
  template:
    metadata:
      labels:
        component: client
    spec:
      containers:
        - name: client
          image: fhsinchy/notes-client
          ports:
            - containerPort: 8080
          env:
            - name: VUE_APP_API_URL
              value: /api

它几乎与 api-deployment.yaml 文件相同，很好理解。

VUE_APP_API_URL 环境变量表示 API 请求应该转发的路径。这些转发请求将依次由Ingress 处理。

需要另一个 ClusterIP service 来公开客户端应用程序。创建一个名为 client-cluster-ip-service.yaml 的新文件，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: client-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: client
  ports:
    - port: 8080
      targetPort: 8080

描述的是运行在集群上默认暴露在 8080 端口上的前端应用。

在完成了旧配置之后，下一个配置是 ingress-service.yaml 文件，内容如下：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-service
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - http:
        paths:
          - path: /?(.)
            backend:
              serviceName: client-cluster-ip-service
              servicePort: 8080
          - path: /api/?(.)
            backend:
              serviceName: api-cluster-ip-service
              servicePort: 3000

该文件有一些新配置，也很好理解：

Ingress API 仍处于测试阶段，所以 apiVersion 是 extensions/v1beta1。尽管处于 beta 版本，该 API 很稳定，可以直接在生产环境中使用。
kind 和 metadata.name 字段和之前配置相同。
metadata.annotations 可以包含有关 Ingress 配置的信息。kubernetes.io/ingress.class: nginx 表示 Ingress 对象应该由 ingress-nginx 控制器控制。nginx.ingress.kubernetes.io/rewrite-target 表示重写目标 URL 的地方。
spec.rules.http.paths 包含在 nginx/production.conf 文件中看到的各个路径的路由配置。 paths.path 表示路由的路径，backend.serviceName 是上述路径应该匹配的 service。backend.servicePort 是服务内部的端口。
/?(._)_ 和 /api/?(._) 是简单的正则表达式，表示 ?(.*) 部分会被路由到指定的服务。

配置重写的方式会时不时发生变化，具体可以查看官方文档。

在 apply 新的配置之前，使用 addons 命令激活 minikube 的 ingress 插件，用法如下：

minikube addons


执行如下命令激活 ingress 插件：
minikube addons enable ingress

# ? Verifying ingress addon...
# ? The 'ingress' addon is enabled

可以对 addon  命令使用  disable 选项来禁用插件，查看官网文档了解  addon 命令的更多信息。
插件激活后，可以 apply 配置文件，建议在 apply 新资源之前删除所有的资源（service、deployment 和 persistent volume claims）。
kubectl delete ingress --all

# ingress.extensions "ingress-service" deleted

kubectl delete service --all

# service "api-cluster-ip-service" deleted
# service "client-cluster-ip-service" deleted
# service "kubernetes" deleted
# service "postgres-cluster-ip-service" deleted

kubectl delete deployment --all

# deployment.apps "api-deployment" deleted
# deployment.apps "client-deployment" deleted
# deployment.apps "postgres-deployment" deleted

kubectl delete persistentvolumeclaim --all

# persistentvolumeclaim "database-persistent-volume-claim" deleted

kubectl apply -f k8s

# service/api-cluster-ip-service created
# deployment.apps/api-deployment created
# service/client-cluster-ip-service created
# deployment.apps/client-deployment created
# persistentvolumeclaim/database-persistent-volume-claim created
# ingress.extensions/ingress-service created
# service/postgres-cluster-ip-service created
# deployment.apps/postgres-deployment created

使用  get 命令来确保所有的资源都已经创建成功。当全部运行后，可以通过 minikube 集群的 IP 地址访问该应用程序。执行如下命令获取 IP 地址：
minikube ip

# 172.17.0.2

还可以通过运行 Ingress 来获取此 IP 的地址：
kubectl get ingress

# NAME              CLASS    HOSTS   ADDRESS      PORTS   AGE
# ingress-service      *       172.17.0.2   80      2m33s

IP 和 端口分别在 ADDRESS 和 PORTS 端口列下。访问 127.17.0.2:80，可以直接进入 notes 应用程序。

可以在此应用中执行简单的 CRUD 操作，端口 80 是 NGINX 的默认端口，因此可以省略 URL 中的端口号。
如果你了解如何配置 NGINX，可以使用  ingress controller 执行很多操作。毕竟，这就是控制器的用途 - 将 NGINX 的配置存储在 Kubernetes  的 ConfigMap 上，将会在下一部分中学习。
Kubernetes 中的 Secret 和配置
目前为止，部署中使用纯文本形式存储了敏感信息，如 POSTGRES_PASSWORD，这并不是最佳实践。
可以用 Secret 将值存储在集群中，这是存储密码、token 等的更安全的方法。

在 Windows 命令行中，下一步可能无法正常工作，可以使用 git 终端或者 cmder 完成此任务。

需要将数据转换成 base64 数据才能将信息存储在 Secret 中。如果纯文本密码为  63eaQB9wtLqmNBpg ，执行以下命令获取 base64 版本。
echo -n "63eaQB9wtLqmNBpg" | base64

# NjNlYVFCOXd0THFtTkJwZw==

此步骤是必要的，参数必需是 base64 格式的，现在在  k8s   目录下创建一个  postgres-secret.yaml 文件，内容如下：
apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
data:
  password: NjNlYVFCOXd0THFtTkJwZw==

apiVersion、kind 和  metadata 的意义无需解释，data 字段就是真实的密文。
如上，创建了一个键值对，键是 password， 值是 NjNlYVFCOXd0THFtTkJwZw==。将使用 metadata.name 值在其他配置文件中作为获取密码值的 Secret 的标识。
按如下更新 postgres-deployment.yaml 文件，以在数据库配置中使用此密码：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: database-persistent-volume-claim
      containers:
        - name: postgres
          image: fhsinchy/notes-postgres
          ports:
            - containerPort: 5432
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
              subPath: postgres
          env:
              # not putting the password directly anymore
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: password
            - name: POSTGRES_DB
              value: notesdb


如上，除了 spec.template.spec.continers.env  字段外，所有的字段介绍过。
之前用于存储密码的 name 环境变量是纯文本。但是现在是 valueFrom.secretKeyRef 字段。
这里的 name  字段是指刚刚创建的 Secret 的名字，key 值是指 Secret 配置文件键值对中的键。Kubernetes  将在内部将编码后的值解码为纯文本。
除了数据库配置，你还需按如下所示更新 api-deployment.yaml 文件：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000
          env:
            - name: DB_CONNECTION
              value: pg
            - name: DB_HOST
              value: postgres-cluster-ip-service
            - name: DB_PORT
              value: '5432'
            - name: DB_USER
              value: postgres
            - name: DB_DATABASE
              value: notesdb
              # not putting the password directly anymore
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: password


现在执行下面的命令 apply  这些新的配置文件：
kubectl apply -f k8s

# service/api-cluster-ip-service created
# deployment.apps/api-deployment created
# service/client-cluster-ip-service created
# deployment.apps/client-deployment created
# persistentvolumeclaim/database-persistent-volume-claim created
# secret/postgres-secret created
# ingress.extensions/ingress-service created
# service/postgres-cluster-ip-service created
# deployment.apps/postgres-deployment created

取决于集群的状态不同，输出可能会不同。

谨慎起见，先删除所有的资源然后在 apply 配置文件来创建他们。

使用 get  命令检查并确保所有的 pod 都已经启动并且正在运行。
使用 minikube  IP 访问 notes 应用程序并尝试创建新的 notes， 来测试新的配置。
minikube ip

# 172.17.0.2

访问  127.17.0.2:80，你应该会直接进入 Notes 应用程序。

还有一种无需任何配置文件即可创建 secret  的方法，执行如下命令，使用 kubectl 创建相同的 Secret。
kubectl create secret generic postgres-secret --from-literal=password=63eaQB9wtLqmNBpg

# secret/postgres-secret created

这是一种更方便的方法，因为可以跳过整个 base64 编码步骤。在这种情况下，secret 会被自动编码。
ConfigMap 和  Secret 类似，一般用于非隐私的的信息。
在  k8s  目录下创建一个名为 api-config-map.yaml 的文件，把 API deployment 里所有的其余的环境变量放在  ConfigMap 里：
apiVersion: v1 
kind: ConfigMap 
metadata:
  name: api-config-map 
data:
  DB_CONNECTION: pg
  DB_HOST: postgres-cluster-ip-service
  DB_PORT: '5432'
  DB_USER: postgres
  DB_DATABASE: notesdb


apiVersion、  kind  和 metadata 无需解释。data 字段是以键值对形式的环境变量。
和 Secret 不同，此处的 key 必需与 API 所需的 key 匹配。因此，我从 api-deployment.yaml 文件中复制了一些变量，并稍作修改后粘贴到了此处。
要在 API deployment 中使用 secret，打开 api-deployment.yaml  文件并做如下修改：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000
          # not putting environment variables directly
          envFrom:
            - configMapRef:
                name: api-config-map
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: password


文件除了 spec.template.spec.containers.env  字段外几乎没有改变。
我已经将环境变量移到了 ConfigMap 中。spec.template.spec.containers.envFrom  用来从 ConfigMap 中获取数据。configMapRef.name 表示将从中 提取环境变量的 ConfigMap  。
然后执行下面的命令 apply 所有的配置：
kubectl apply -f k8s

# service/api-cluster-ip-service created
# configmap/api-config-map created
# deployment.apps/api-deployment created
# service/client-cluster-ip-service created
# deployment.apps/client-deployment created
# persistentvolumeclaim/database-persistent-volume-claim created
# ingress.extensions/ingress-service configured
# service/postgres-cluster-ip-service created
# deployment.apps/postgres-deployment created
# secret/postgres-secret created

取决于集群的状态，输出可能会不同。

谨慎起见，先删除所有的 Kubernetes  资源然后在 apply configs 创建他们。

使用 get 命令确保 pod 已经启动并运行，使用 minikube IP 访问 notes 应用并尝试创建新的 note。
执行下面的命令获取 IP 地址。
minikube ip

# 172.17.0.2

访问  127.17.0.2:80 ，直接进入 notes 应用程序。

Secret  和 ConfigMap 还有其它一些技巧，就不在这里展开了，如果想了解，可以查看官方文档。
在 Kubernetes 中执行更新发布
既然已经在 Kubernetes 上成功部署了一个包含多个容器的应用程序，是时候学习执行更新了。
Kubernetes 很神奇，将容器更新为较新版本的镜像比较麻烦，有很多种方式更新容器，这里不会涉及到所有的方法。
相反，我将直接进入更新容器时主要采取的方法。如果打开  client-deployment.yaml 文件并查看 spec.template.spec.containers 字段，会看到下面的配置：
containers:
    - name: client
      image: fhsinchy/notes-client

如上，在  image  字段中，没有使用任何镜像标签。现在，如果你认为在镜像尾部添加  :latest  将确保部署始终拉取最新的镜像，那你可就大错特错了。
我通常采用最简单的路径。之前提到过，在某些情况下，使用命令式而不是声明式是一个好主意，创建一个 Secret 或者更新容器就是这种情况。
可以用来执行更新的命令是 set  命令，其通用语法如下：
kubectl set image / =

资源类型为 deployment，资源名称为 client-deployment。可以在 client-deployment.yaml 文件内的 containers 字段找到容器的名称，本例中为  client  。
我已经构建了带有标签  edge 的 fhsinchy/notes-client 镜像，将使用它来更新 fhsinchy/notes-client 的版本。
最终命令如下：
kubectl set image deployment/client-deployment client=fhsinchy/notes-client:edge

# deployment.apps/client-deployment image updated

由于 Kubernetes 将重新创建所有的 pod，执行此更新可能需要一段时间，可以运行 get 命令来了解是否所有的 pod 都已经启动并且成功运行。
重新创建后，使用 minikube  IP 访问 notes 应用并尝试创建新的 notes。可以执行下面的命令获取 IP：
minikube ip

# 172.17.0.2

通过访问 127.17.0.2:80 应该可以直接进入 notes 应用程序。

鉴于我还未对应用程序代码进行任何实际更改，因此所有的内容都将保持不变。你可以使用  describe 命令来确保 pod 正在使用新的镜像。
kubectl describe pod client-deployment-849bc58bcc-gz26b | grep 'Image'

# Image:          fhsinchy/notes-client:edge
# Image ID:       docker-pullable://fhsinchy/notes-client@sha256:58bce38c16376df0f6d1320554a56df772e30a568d251b007506fd3b5eb8d7c2

grep 命令在 Mac 和 Linux 可以直接使用，如果你使用的是 Windows，使用 git bash 而不是 Windows 命令行。
尽管强制性更新过程有些繁琐，但是通过好的 CI/CD 流程可以使其变得更加容易。
组合 Configurations
尽管其中只有三个容器，但该项目中的配置文件数量已经非常庞大了。
实际上可以按照如下方式组合配置文件：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: client
  template:
    metadata:
      labels:
        component: client
    spec:
      containers:
        - name: client
          image: fhsinchy/notes-client
          ports:
            - containerPort: 8080
          env:
            - name: VUE_APP_API_URL
              value: /api
              
---

apiVersion: v1
kind: Service
metadata:
  name: client-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: client
  ports:
    - port: 8080
      targetPort: 8080

如上，我已经使用界定符（---）组合了 client-deployment.yaml 和 client-cluster-ip-service.yaml 文件。尽管有可能在容器数量很多的项目中减少文件，但我还是建议将他们分开，更简洁、更干净。
答疑
在本节中，我将列出你使用 Kubernetes 时可能遇到的一些常见问题。

如果你在 Windows 或者 Mac 使用 Docker 的 minikube，Ingress  插件可能并没有生效。、
如果你在 Mac 上运行了Laravel Valet，并且将 HyperKit 驱动程序用于minikube，会联网失败。关闭 minikube 服务可以解决此问题。
如果你有一台 Ryzen (mine is R5 1600) PC，并且正在运行 Windows 10，由于缺少内嵌虚拟化支持 VirtualBox  可能会启动失败。必须在 Windows 10 （Pro、Enterprise 和 Education）上安装 Hyper-V 驱动程序，对于家庭版，很遗憾没有该选项。
如果你在 Windows 10 (Pro, Enterprise 和 Education)  上使用用于 minikube 的 Hyper-V  驱动，VM 可能会启动失败，并显示 内存不足的消息。不要紧张，执行 minikube start 重新启动 VM。
如果你在 Windows 命令行中看到本文执行的某些命令丢失，或者功能异常，请改用  git 命令行或者  cmder 。

我建议在你的系统上安装一个 Linux 发行版，并将 Docker 驱动程序用于 minikube。目前为止，这是最快也是最可靠的设置。
结论
衷心感谢你花了这么长时间阅读本文，希望你享受学习过程，并了解了 Kubernetes 的基础知识。
你可以关注我的推特   @frhnhsin  或者在 LinkedIn /in/farhanhasin  上与我联系。
原文：The Kubernetes Handbook，作者：Farhan Hasin Chowdhury