Deployment 是 Kubernetes 提供的一种自我修复机制来解决机器故障维护的问题

前面提到了单独部署 Pod，但是这种方式只适合临时的 Pod，用于测试调试

用于生产，则需要 Deployment 等控制器管理部署 Pod，维持 Pod 的副本数量以及 Pod 监控和维护 对于 Kubernetes 对象的部署，例如 Pod、Deployment、Service 等，有三种部署方式：

• Using Generators (Run, Expose)
• Using Imperative way (Create)
• Using Declarative way (Apply)

在本章，我们将会来学习如何使用 Deployment 来部署应用，并学会管理 Pod

以下命令均在 master 节点上执行，如需在 slave 上，会额外说明

创建 Deployment

Deployment 的创建，有两种方法，一种是直接使用命令创建( kubectl create )，一种是通过 YAML( kubectl apply )

当我们创建一个 deployment 时，kubectl create 和 kubectl apply 效果是一样的，但是 apply 还具有更新 (update) 的功能

kubectl apply 会在以前的配置、提供的输入和资源的当前配置之间 找出三方差异，以确定如何修改资源，kubectl apply 命令将会把推送的版本与以前的版本进行比较，并应用你所做的更改， 但是不会自动覆盖任何你没有指定更改的属性

另外还有 kubectl replace 、kubectl edit

• kubectl replace 是破坏性更新/替换，容易导致问题
• kubectl edit 可以更新 Deployment 等已存在的对象

但我们应该使用以 kubectl create 和 kubectl apply 进行创建资源

kubectl create

我们来使用 deployment 部署一个 Pod，这个 Pod 包含一个 Nginx 容器

kubeclt create deployment nginx-test --image=nginx:latest

# 格式 kubectl create deployment {deployment对象名称} --image={镜像名称和标签}

nginx 容器会以 Pod 的方式部署到节点中，但是被部署到哪个节点是随机的，当前只有一个 slave 节点，所以必定在此节点上

Deployment 会为我们自动创建 Pod，Pod 由 {deployment名称}-{随机名称} 组成

kubectl get deployment -o wide

kubectl get pods -o wide

# 清理资源
# kubectl delete deployment nginx-test

有一个不是很讲究的点需要说一下，那就是 kubectl get xxx 时，不管 xxx 加不加 s，都是可以

只是讲究语义时，我们会习惯性的根据我们的目的加 s，比如想获得全部对象 pods、nodes，对于单一对象则 pod xxx、node xxx

kubectl apply

# 通过 yaml 文件部署 nginx
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml

使用 apply 创建时，yaml 文件需要有一些信息，比如：

kind: Deployment
... ...
medatada:
    name:nginx
... ...
    spec:
      containers:
      - image: nginx:latest

kubectl apply -f，在 yaml 中指定 kind: Deployment

检查 YAML

有时我们不知道我们的创建命令或 yaml 是否正确，可以使用 --dry-run=client，--dry-run=client 参数来表示当前内容只是预览而不真正提交

root@master:~# kubectl create deployment test-nginx --image=nginx:latest --dry-run=client
deployment.apps/test-nginx created (dry run)

命令的意思是：在本地模拟创建一个名为 test-nginx 的 Deployment，但不提交到 Kubernetes 集群 输出的意思是：命令格式没问题，模拟创建成功，但没有写入集群

此外加上 -o json 参数，可以快速获得需要的 YAML 模板，然后复制到 YAML 文件，根据需要改动、定制，除了 Deployment，其它 kubernetes 对象也可以使用这种方法

kubectl create deployment testnginx --image=nginx:latest --dry-run=client -o yaml

导出 yaml

我们可以从已经创建的 Deployment 、Pod、Service 等对象导出 yaml 文件

kubectl get deployment nginx-deployment -o yaml > mynginx.yaml

# 清理资源
kubectl delete deployment nginx-deployment

# 用导出的 yaml 再创建一个 deployment
kubectl apply -f mynginx.yaml

查看 Deployment

查看 deployment 的信息，这里的 nginx 用的是 apply -y 创建的，不是 create 创建的

kubectl get deployments 

kubectl get deployments -o wide

查看集群中最近发生的事件，如创建 Deployment 到部署容器过程的详细事件记录

kubectl get events

查看 deployment 更加详细的信息，各种信息的集合

kubectl describe deployment nginx-deployment
# kubectl describe deployment nginx （名称前缀匹配 会匹配多个 nginx 当前只有一个）

我们可以看到，存在 3 个维持 Nginx Pod 副本，可以使用 kubectl scale 进行缩容，参数 --replicas 就是副本个数；或者使用 kubectl edit 进行编辑文件达到扩缩容

kubectl scale deployment nginx-deployment --replicas=1

查看 Pod

我们通过 Deployment 创建了应用，但这些 Pod 是怎么跟 Deployment 对象关联起来的？接下来我们需要了解如何查看 Pod

kubectl get pods -o wide

curl {nginx_ip}

对于没有指定的 Deployment、Pod、Service 等对象，会默认分配到 default 命名空间中，我们在执行kubectl get {} 时，会获取 default 命名空间中的对象， 后面加上 --all-namespaces 可以获得所有命名空间中的对象，使用 --namespace= 可以指定获取某个命名空间中的对象

kubectl get pods --all-namespaces

kubectl get pods --namespace=default

实时修改

使用 kubectl edit 可以修改的是对象允许更新的字段例，例如 Deployment 的副本数和镜像，这里我们使用前面已经部署好的 Nginx 这个 Deployment

kubectl edit 默认使用的是 vi/vim 编辑器

kubectl edit deployment nginx-deployment

多个容器

一个 Pod 中，是可以包含多个容器的，我们可以使用命令或 YAML 形式创建包含多个容器的 Pod 服务

kubectl create deployment nginx-test --image=nginx:latest --image=busybox:latest --dry-run=client -o yaml

在 master 机器上用 Dashboard 中看看对于的信息

kubectl get services --namespace kubernetes-dashboard

登陆即可，IP 是 master 的 IP

总结

本章我们粗略涉及了一下 deployment 的知识，但 deployment 不仅仅只有这么些内容，当前只是进行了基础操作，对于原理我们尚未涉及

但学习总得有个过程，先学基础概念，再到基础操作，然后深入原理

愿诸君顺遂

Pod 在 Kubernetes 中是最重要的对象之一，Pod 集群中创建和管理的、最小的可部署的计算单元

在 Kubernetes 中部署一个应用时，创建的便是 Pod，一个 Pod 中包含一个或多个容器，这些容器在 Pod 中能够共享网络、存储等环境，然后组成一个应用对外提供服务

我们不必过于关注这些概念，只需要知道，在 Kubernetes 中，是不会直接操作容器的，而是通过 Pod 封装了容器，集群通过管控 Pod ，便可控制容器的存储、网络等资源，实现资源隔离或共享

创建 Pod

以下命令 master 节点上执行

kubectl run nginxtest --image=nginx:latest --port=80

# -o wide 查看更多的 pods 信息
kubectl get pods -o wide

# ip 为 pods 中的 ip，curl 后需要显示 Welcome to nginx 
curl {nginx_ip}

# 清除
kubectl delete pod nginxtest

nginxtest 为 Pod 名称，并且为其映射端口为 80，这里创建了一个 nginx 应用，并且 这个 Pod 会被 挂载在 slave 节点上

一般来说，我们会选择 使用 xx.yaml 文件 进行 pod 的创建，以此来发挥 pod 全部能力

# nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginxtest
spec:
  containers:   
  - image: nginx:latest
    name: nginxtest
    ports:
    - containerPort: 80
      protocol: TCP
      
# 应用
kubeclt apply -y nginx.yaml

了解 Pod

Pod 是 Kubernetes 中调度资源的最小单位，一个 Pod 中可以包含多个容器，Pod 中的容器被打包在一起作为一个整体， Pod 中的容器不会被分配到不同节点中，它们一定被部署到同一个节点中

每个 Pod 之间都是隔离的，也就是在 Pod 内无论怎么使用端口，都不会对另一个 Pod 产生影响，但是在 Pod 内，因为各个容器都是共享同一个 Pod 的网络，因此一个 Pod 内，不允许有两个进程占用相同的端口

与 主机相同，在同一主机下，不同的 app 使用的进程、端口，都是不同的，不然就会冲突

Pod 是如何启动

在 Kubernetes 中，当创建 Pod 时，会先启动一个 pause 容器，然后 Pod 中我们定义的容器会以 containerd 模式共享 pause 中的网络，在 Pod 网络中相当于交换机，但是 pause 不只是实现容器的网络互通，还有其它功能

我们的 nginxtest 是挂载在 slave 节点上的，所以需要在 slave 上查看 pause

crictl pods --name nginxtest

crictl images | grep pause

查看 Pod 的信息

以下命令master 节点上执行

# 查看 Pod 配置、状态和事件
kubectl describe pod nginxtest

# 查看容器日志
kubectl logs nginxtest

# 在容器中执行命令
kubectl exec nginxtest -- nginx -v

Pod 常见状态有：

• Pending：尝试启动容器，如果容器正常启动，则进入下一个阶段
• Running：处于运行状态
• Succeeded、Failed：正常结束或故障等导致容器结束
• Unknown：因为某些原因无法取得 Pod 的状态

Pod 被分配到某个节点时， Pod 会一直在该节点运行，直到停止或被终止，Pod 在整个生命周期中只会被调度一次。也就是说 Pod 是一次性的，如果 Pod 故障了，那么如果需要恢复应用的运行，是需要重新创建 Pod 的，而不是重启 Pod  

在 Kubernetes 中，Pod 被认为是相对的临时性实体，而不是长期存在的。由于 Pod 本身不具有治愈能力，如果 节点故障或者节点资源耗尽、节点被维护、Pod 被驱逐等，那么 Pod 无法在节点上继续存活。无论 Pod 因为何种原因被删除，在 Pod 中的网络、存储卷等，也会被销毁，新的 Pod 被创建时，相关的网络、存储卷也会被重建

在删除 Pod 时，Kubernetes 会终止 Pod 中的所有容器，会向容器中的进程发生 SIGTERM 信号，等待进程的正常关闭，所以 Pod 可能不会被马上删除，当然如果进程不能正常关闭，Kubernetes 最多等待 30s，然后会使用 SIGKILL 强制杀死进程

容器重启策略

# 一个简单的 pod.yaml 配置
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: nginx
spec:
  containers:
  - image: nginx:latest
    imagePullPolicy: Always
    name: nginx
    ... ...
  restartPolicy: Always

在这个 YAML 中，有两个 *Policy ，取值有 Always、OnFailure 和 Never 三种，它们代表了某种生命周期策略

对于每个容器，都可以设置 imagePullPolicy ，指示在拉取镜像时如果失败，是否进行重试

在 spec 中，有个 restartPolicy 字段，其值默认为 Always，指示 Pod 中所有容器的重启动作，但是在 Deployment、StatefulSet、DaemonSet 等控制器中，restartPolicy 只支持 Always ，不支持 OnFailure 和 Never

容器启动失败，重试间隔会越来越长，kubelet 会在 10s 后重试第一次，如果还是失败，第二次 20s 后再重试；按照 10s、20s、40s、80s ... 的间隔重试，但最长不超过 5 分钟。如果容器被成功运行且运行了 10 分钟以上，那么计时器会被重置，下次出现故障时，按照 10s、20s 的间隔时间重试

如果单独创建 Pod，并且设置了 restartPolicy: Always，那么 Pod 会一直停留在此节点上，如果 容器故障，Pod 可能会无限重试

总结

本章粗略讲了 Pod 的一些基础知识，当然，不可能全部都能进行记忆，最重要的是，存在一个印象，等未来真实使用到这些知识时，你不会胆怯，这样，就足够了

愿诸君顺遂

集群使用环境为 Mac、UTM 虚拟机、Ubuntu 24.04 LTS ARM64 架构 镜像源、root 用户

• 本章出现的 IP 不得照抄，需要按实际 IP 进行填写
• Windows 用户，可以让 AI 重写此文件，以此达到配置集群的目的

master、slave 虚拟机 均开启了共享主机网络功能，并在主机使用脚本让虚拟机自动监听 梯子 开放的端口，以此达到拉取外网镜像源能力

• 脚本可以用 AI 生成，目的只有一个，那就是开放一个端口提供给虚拟机使其能访问外网

master 机器为控制平面，master 初始化后，root 的 kubectl 配置固定为 /root/.kube/config；kubeadm token 使用控制平面上的 /etc/kubernetes/admin.conf

下面配置 master、slave 双机 Kubernetes 集群

一 配置主机网段

master 主机

root@master:~# hostname
master
root@master:~# ip -4 -br addr
lo               UNKNOWN        127.0.0.1/8 
enp0s1           UP             192.168.64.2/24 metric 100 
docker0          DOWN           172.17.0.1/16 
root@master:~# ip route
default via 192.168.64.1 dev enp0s1 proto dhcp src 192.168.64.2 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.64.0/24 dev enp0s1 proto kernel scope link src 192.168.64.2 metric 100 
192.168.64.1 dev enp0s1 proto dhcp scope link src 192.168.64.2 metric 100 
root@master:~#

slave 主机

root@slave:~# hostname
slave
root@slave:~# ip -4 -br addr
lo               UNKNOWN        127.0.0.1/8 
enp0s1           UP             192.168.64.3/24 metric 100 
docker0          DOWN           172.17.0.1/16 
root@slave:~# ip route
default via 192.168.64.1 dev enp0s1 proto dhcp src 192.168.64.3 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.64.0/24 dev enp0s1 proto kernel scope link src 192.168.64.3 metric 100 
192.168.64.1 dev enp0s1 proto dhcp scope link src 192.168.64.3 metric 100 
root@slave:~#

分别在各自的 /etc/hosts 中加入双方的主机 ip master 主机

127.0.0.1 localhost

192.168.64.2 master
192.168.64.3 slave

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

slave 主机

127.0.0.1 localhost

192.168.64.2 master
192.168.64.3 slave

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

需要确保双方能够互相 ping 通（ping master、ping slave 不丢包）。

二 改造环境

以下命令应该在 master 与 slave 机器上执行

2.1 配置 UTM 宿主机代理

创建 root 专用的代理环境文件：

cat > /root/.utm-proxy-env <<'EOF'
export HTTP_PROXY='http://192.168.64.1:17897'
export HTTPS_PROXY='http://192.168.64.1:17897'
export http_proxy='http://192.168.64.1:17897'
export https_proxy='http://192.168.64.1:17897'
export NO_PROXY='127.0.0.1,localhost,::1,master,slave,192.168.64.0/24,10.96.0.0/12,10.244.0.0/16,.svc,.svc.cluster.local,.cluster.local'
export no_proxy="$NO_PROXY"
unset ALL_PROXY all_proxy
EOF

grep -qxF 'source /root/.utm-proxy-env' /root/.bashrc || \
  echo 'source /root/.utm-proxy-env' >> /root/.bashrc

source /root/.utm-proxy-env

APT 使用独立配置，避免环境变量是否被继承造成差异：

cat > /etc/apt/apt.conf.d/99-utm-proxy <<'EOF'
Acquire::http::Proxy "http://192.168.64.1:17897";
Acquire::https::Proxy "http://192.168.64.1:17897";
EOF

nc -vz 192.168.64.1 17897
curl -fsSI https://pkgs.k8s.io | head

NO_PROXY 中包含节点网段、Service 网段和 Pod 网段，因此外网 HTTP/HTTPS 请求走代理，master:6443 和 Kubernetes 集群内部地址保持直连

2.2 准备 Linux 节点

# 更新系统并安装基础工具
apt-get update
apt-get install -y ca-certificates curl gpg bash-completion netcat-openbsd

dpkg --print-architecture

# 关闭 Swap
swapoff -a
sed -ri '/\sswap\s/s/^#?/#/' /etc/fstab
swapon --show

# 加载内核模块
tee /etc/modules-load.d/k8s.conf >/dev/null <<'EOF'
overlay
br_netfilter
EOF

modprobe overlay
modprobe br_netfilter

# 配置内核网络参数
tee /etc/sysctl.d/k8s.conf >/dev/null <<'EOF'
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sysctl --system

# 输出应为 1
sysctl net.bridge.bridge-nf-call-iptables
sysctl net.ipv4.ip_forward

这些配置的目的，是把普通 Linux 主机调整为适合 Kubernetes 节点运行的环境：关闭 Swap 保证 kubelet 能准确进行内存资源管理；加载 overlay 支持容器镜像的分层文件系统；加载 br_netfilter 并开启 bridge-nf-call-iptables，让 Pod 经过 Linux Bridge 的流量能够被 iptables/netfilter 处理；开启 ip_forward，让节点具备转发 Pod 网络数据包的能力，从而支持跨 Pod、跨节点通信

三 安装并配置 containerd

以下命令应该在 master 与 slave 机器上执行

# 安装 containerd
apt-get install -y containerd
install -d -m 0755 /etc/containerd
containerd config default | tee /etc/containerd/config.toml >/dev/null

# 使用 systemd cgroup
sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

# containerd 是独立的 systemd 服务，必须单独配置代理才能拉取镜像
install -d -m 0755 /etc/systemd/system/containerd.service.d
cat > /etc/systemd/system/containerd.service.d/10-utm-proxy.conf <<'EOF'
[Service]
Environment="HTTP_PROXY=http://192.168.64.1:17897"
Environment="HTTPS_PROXY=http://192.168.64.1:17897"
Environment="NO_PROXY=127.0.0.1,localhost,::1,master,slave,192.168.64.0/24,10.96.0.0/12,10.244.0.0/16,.svc,.svc.cluster.local,.cluster.local"
EOF

systemctl daemon-reload
systemctl enable --now containerd
systemctl restart containerd

# 检查服务
systemctl is-active containerd
ctr version
systemctl show containerd -p Environment --no-pager
grep -n 'SystemdCgroup = true' /etc/containerd/config.toml

应该输出 active ，以及 SystemdCgroup = true ![](https://raymq.com/api/v3/objects/image/s0clqqsodkq4p2w64h.png) 目的是为 Kubernetes 安装并配置**容器运行时 containerd**。Kubernetes 本身不直接创建和运行容器，而是由 kubelet 通过 CRI 调用 containerd 来完成镜像拉取、容器创建、启动和停止等操作；生成 /etc/containerd/config.toml 是为了建立默认配置；设置 SystemdCgroup = true 是让 containerd 和 kubelet 统一使用 systemd` 管理 cgroup，避免资源管理方式不一致；最后启动并检查 containerd，确认容器运行时已经正常工作

四 安装 kubeadm、kubelet、kubectl

以下命令应该在 master 与 slave 机器上执行

# 添加 Kubernetes 1.36 软件仓库
install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.36/deb/Release.key \
  | gpg --dearmor --yes -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.36/deb/ /' \
  | tee /etc/apt/sources.list.d/kubernetes.list >/dev/null
  
# 安装并锁定版本
apt-mark unhold kubelet kubeadm kubectl 2>/dev/null || true
apt-get update
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl
systemctl enable --now kubelet

# 检查版本
kubeadm version -o short
kubelet --version
kubectl version --client

# 输出版本
v1.36.3
Kubernetes v1.36.3
Client Version: v1.36.2
Kustomize Version: v5.8.1

五 创建 kubeadm 配置文件

以下命令只在 master 机器上执行

# 创建配置文件
MASTER_IP="$(ip -4 route get 1.1.1.1 | awk '{for (i=1; i<=NF; i++) if ($i=="src") {print $(i+1); exit}}')"
K8S_VERSION="$(kubeadm version -o short)"

: "${MASTER_IP:?无法取得控制平面 IP}"
: "${K8S_VERSION:?无法取得 Kubernetes 版本}"

printf 'MASTER_IP=%s\nK8S_VERSION=%s\n' "$MASTER_IP" "$K8S_VERSION"

cat > kubeadm-config.yaml <<EOF
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "${MASTER_IP}"
  bindPort: 6443
nodeRegistration:
  name: master
  criSocket: unix:///run/containerd/containerd.sock
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: "${K8S_VERSION}"
controlPlaneEndpoint: "master:6443"
networking:
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
EOF

# 检查文件
cat kubeadm-config.yaml
kubeadm config validate --config kubeadm-config.yaml

六 初始化 master

以下命令只在 master 机器上执行

# 拉取镜像
kubeadm config images pull --config kubeadm-config.yaml

# 初始化集群并保存日志
set -o pipefail
kubeadm init --config kubeadm-config.yaml --upload-certs --v=5 \
  | tee kubeadm-init.out
  
# 为 root 配置 kubectl
install -d -m 0700 /root/.kube
install -o root -g root -m 0600 \
  /etc/kubernetes/admin.conf /root/.kube/config

# 验证 API Server
kubectl cluster-info
kubectl get nodes -o wide

# 确认直连 API Server
curl -k --noproxy '*' https://master:6443/livez
kubectl get nodes -o wide

第一条为 `ok`；第二条中 master 显示 `NotReady` 为正常。

保留 kubeadm join master:6443 --token xxxxx --discovery-token-ca-cert-hash xxxx ！！！

七 安装 Calico 网络插件

以下命令只在 master 机器上执行

# 下载 Calico 清单
curl -LO https://raw.githubusercontent.com/projectcalico/calico/v3.32.1/manifests/calico.yaml

# 使用清单
kubectl apply -f calico.yaml

# 观察 Pod 启动过程
# 当 calico-node、calico-kube-controllers、coredns 都进入 Running 即可退出
kubectl get pods -n kube-system -w

# 检查节点，master 从 NotReady 变为 Ready
kubectl get nodes -o wide

八 将 slave 加入集群

以下命令注意区分 master 与 slave 机器上执行

# 使用上述保留的 token；如果丢失，在 master 重新生成
# kubeadm token create --print-join-command

# 在 slave 中加入 token
kubeadm join master:6443 --token xxxx --discovery-token-ca-cert-hash xxxx

# 回到 master 机器检查
kubectl get nodes -o wide
kubectl get pods -A -o wide

master、slave 均存在且为 Ready

九 验证集群可用性

以下命令只在 master 机器上执行

# 创建 Deployment 和 Service
kubectl create deployment web --image=nginx:alpine
kubectl expose deployment web --port=80
kubectl rollout status deployment/web --timeout=120s
kubectl get pods -o wide
kubectl get service web

# 测试 Pod 访问 Service
kubectl run curl-test \
  --image=curlimages/curl:latest \
  --restart=Never --rm -it \
  -- curl -s http://web
  
# 清理验证资源
kubectl delete deployment web
kubectl delete service web

能正常返回 Nginx HTML，则代表配置成功，可以清理验证资源了

安装 Dashboard

Dashboard 是管理 Kubernetes 集群的 Web UI，以下命令在 master 机器执行

# 检查 helm 版本
helm version

# 安装 Dashboard
DASHBOARD_CHART_URL='https://github.com/kubernetes-retired/dashboard/releases/download/kubernetes-dashboard-7.14.0/kubernetes-dashboard-7.14.0.tgz'

helm upgrade --install kubernetes-dashboard \
  "$DASHBOARD_CHART_URL" \
  --namespace kubernetes-dashboard \
  --create-namespace \
  --wait \
  --timeout 10m
  
# 检查 Helm Release、Pod 和 Service
# helm list 中的状态应为 deployed
# Dashboard 的 API、Auth、Web、Metrics Scraper 和 Kong Pod 应为 Running
# Service kubernetes-dashboard-kong-proxy 应监听 443/TCP
helm list --namespace kubernetes-dashboard

kubectl --namespace kubernetes-dashboard wait \
  --for=condition=Ready pod \
  --all \
  --timeout=600s
  
# Dashboard 会默认挂载到 slave 机器上
kubectl --namespace kubernetes-dashboard get pods,service -o wide

以下步骤非常重要，因为 Dashboard 需要使用 Token 进行校验登陆，所以此 Token 需保存

# 创建管理员 ServiceAccount
kubectl --namespace kubernetes-dashboard \
  create serviceaccount dashboard-admin \
  --dry-run=client -o yaml \
  | kubectl apply -f -

# 授予 cluster-admin 权限
kubectl create clusterrolebinding dashboard-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kubernetes-dashboard:dashboard-admin \
  --dry-run=client -o yaml \
  | kubectl apply -f -

# 创建长期 Token
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Secret
metadata:
  name: dashboard-admin-token
  namespace: kubernetes-dashboard
  annotations:
    kubernetes.io/service-account.name: dashboard-admin
type: kubernetes.io/service-account-token
EOF

# 等待 master 把 Token 写入 Secret
kubectl --namespace kubernetes-dashboard wait \
  --for=jsonpath='{.data.token}' \
  secret/dashboard-admin-token \
  --timeout=60s
  
# 每次登陆，执行此命令，将输出的 Token 粘贴到暴露的 URL 即可
kubectl --namespace kubernetes-dashboard \
  get secret dashboard-admin-token \
  --output=jsonpath='{.data.token}' \
  | base64 --decode
printf '\n'

# 通过打印出的节点进入 DashBoard 界面
MASTER_IP="$(
  ip -4 route get 1.1.1.1 \
    | awk '{for (i=1; i<=NF; i++) if ($i=="src") {print $(i+1); exit}}'
)"

kubectl --namespace kubernetes-dashboard \
  get service kubernetes-dashboard-kong-proxy

printf 'Dashboard 地址：https://%s:30443\n' "$MASTER_IP"

可以看到 Dashboard 也是非常好看的，

总结

本章实现了 master、slave 双机 k8s 集群，当然只是属于学习阶段，真实环境中需要配置的机器不只有一台，难度会往上增加

但核心是不变的，那就是 保持冷静，遇到问题，解决问题就好了

愿诸君顺遂

今天是 2026年8月7日凌晨12点42分41秒，从这个记录的时间点开始，我写下这篇文章，我的思绪是嘈杂的，我不清楚我要写什么，但是我的目的很明确，我想记录一些话，一些在今天乃至未来，会改变我的话 这是我的 mt 说的话，从第一次认识，到今天这个时候，mt 一直在强调的就是 思考 每次与 mt 非工作时的闲聊，都能给我一些思考，在潜移默化的改变我，这些闲聊，默默的在我脑袋里埋下一颗种子，开始慢慢的生根发芽

从第一次面试反问 mt 强调要思考；到下班后 mt 请客吃麦当劳分享他的故事；到跟 mt 出差说要为共产主义，为社会做贡献；再到公司楼下遛弯 mt 分享以前实习生的事；到工作时 mt 说他能为我们兜底；最后到今天 mt 的回答...

回顾两年前与两个月前，我...我或许变了: 在两年前，我的为人着想的想法，仅仅只是一个想法，产生的念头源自于我在祈求某些事情成功后我将这么做去回报成功，但即使成功我也没有去行动，因为失败次数更多，这是一种功利的想法；直至两个月前，我开始思考，我开始写博客发视频，开始记录我的日常与学习笔记，我由衷的希望，我的笔记、我的博客、视频、甚至是口头话语，可以去帮助他人，去帮助那些在这条路上迷茫困惑的人，去帮助那些与我一样没有学历、没有天赋、没有背景...但却不甘堕落的那些人，我希望他们能变好...

我不是一个才华横溢之辈，也并非富甲一方，我做不到施舍钱财救济苦难之人，更不能靠自己的才华让社会变得更好，我所能做的，也只是发一些文章、视频，指引身处迷雾之人及时走出，同样的，我也会希望接受过帮助的人能在别人迷茫困惑时同样指引他们这或许就是 mt 所说的共产主义吧...

虽然这么做，还会同时满足我的被认可感，或者说也算是功利心吧，但是与两年前不同了，就算文章、视频...籍籍无名，但我还是会坚持...

我一直在焦虑，一直在困惑，一直在反复确认我所坚持的是否是对的...我把这些统称为情绪，这些情绪源自于我一直在思考，思考我的处境...我应该怎么做？我未来怎么办？为什么这么简单的事我都处理不好？就像 mt 说的，疑问来自于知识的积累，我所面临的知识积累不只有我的工作，还包括与他人言语相传、社交平台、电子群聊...这些每天接触到的东西，都会潜移默化的作为一种积累，存储到你的脑子某一个角落，等到哪天再去用时，你才会发现会因为这个积累导致很多你无法理解的事，你会有驱动的去搜索前后之因果...或许这就是 mt 想让我明白的吧

从实习第一天到现在，mt 一直没有正面的告诉我如何去学习，也正如他所说的，每个人的路都是不一样的，自己选择的路才是最好的，旁人言语，也不如自撞南墙，即使你会因此走错很多路、会始终无法明白当初的选择为什么会走错，但只有自己的选择，才无愧于心，才无愧于人...

愿 诸君顺遂

今天我们来学习什么是 Django 框架

在学任何东西时，首要的就是学习基础概念，你得知道它是干什么的，才能知道做出的东西的意义是什么

Django 是 Python 社区的两大最受欢迎的 Web 框架之一（另一个是 Flask），凭借功能强大的脚手架和诸多开箱即用的组件，用 Django 搭建 Web 应用快速而又省力。但因为过于强大，想要驾驭它需要花费不少的力气，本教材将通过实现一个新闻发布网站带你快速熟悉 Django 框架

来源

Django 由 Adrian Holovaty 和 Simon Willison 在 2003 年的秋天写成，并在 2005 年正式发布。他们俩当时为一个新闻报社制作网站，对快速开发有着比较高的需求，并且希望能够在开发的同时也能够让非技术人员为网站添加内容。于是这也使得 Django 具备了两项鲜明的特点：

• 高度强调可复用性和可插拔性，内置大量现成的成熟组件，开发效率极高
• 自带与数据库联动的后台管理系统，能够在开发的同时创建内容

MTV 框架

MTV 框架是每个 Django App 的组织结构

• M（Model）：创建数据模型，并执行数据库迁移
• T（Template）：写出基本的 Django 模板，并从视图中传入数据
• V（View）：在视图中访问数据库，实现业务逻辑，渲染模板，并接入路由表 如果大家了解过 MVC 框架的话，或许就不会陌生了，如下：

大家熟知的 View，在 Django 里面代表的是业务逻辑，也就是 MVC 中的控制器

安装

安装前需要确保环境中存在 python3 和 pip，然后就可以直接使用 pip 进行安装

# 一般情况下 python 都是 3.1.2 版本
python3 -m pip install django

初步体验

安装好 Django 后，我们用 Django 自带的脚手架工具 django-admin 创建项目：

source ～/django-env/bin/activate
django-admin startproject django_news
cd django_news

django_news
├── django_news              // 项目全局文件目录
│   ├── __init__.py
│   ├── settings.py          // 全局配置
│   ├── urls.py              // 全局路由
│   └── wsgi.py              // WSGI服务接口（暂时不用纠结这个是神马）
└── manage.py                // 项目管理脚本

使用 manage.py 运行开发服务器（Development Server）

python manage.py runserver

可以看到，出现了一堆红色的提示，不用管，按照提示，我们通过浏览器访问 localhost:8000，可以看到欢迎界面 Django 开发服务器可以保持开启，并且后面修改代码会自动重新加载，非常方便。后面运行其他命令时，再打开一个终端（命令行）即可。

总结

我认为，当你看完这一篇教程之后，你应该会有这么一个印象：

Django 是一个高度模块化的 Web 框架，提供了丰富的组件用于开发；有 MTV 框架；使用 xxx 命令启动开发服务器

但 Django 框架并非只有这么些内容，更多具体的知识，需要你主动去钻研学习

愿诸君顺遂

上一章中，我们学会了如何实现视图，并将其接入路由配置中，使其能够被用户访问

接下来，我们将实现一个 Django 模板作为网页前端，从而给用户呈现更丰富的内容

Django 模板语言基础

Django 模板本质上是一个 HTML 文档，只不过通过一些特殊的语法实现数据的填充

表达式插值

最常用的语法，没有之一。通过在一对花括号 {{}} 放入一个表达式，就能够在视图中传入表达式中变量的内容，并最终渲染成包含变量具体内容的 HTML 代码。需要注意的是，所支持的表达式仅支持以下形式（可以自由组合）：

<!-- 单个变量 -->
{{ variable }}

<!-- 获取字典的键或对象的属性 -->
{{ dict.key }}
{{ object.attribute }}

<!-- 获取列表中的某个元素 -->
{{ list.0 }}

eg:
<h1>{{ name }}</h1>
<p>{{ news.title }}</p>
<p>{{ news.visitors.0 }}</p>

如果我们在视图中传入以下上下文字典（Context Dictionary）：

{
    'name': 'Tuture',
    'news': {
        'title': 'Hello World',
        'visitors': ['Tom', 'Marc'],
    }
}

那么最终渲染成的 HTML 代码就是：

<h1>Tuture</h1>
<p>Hello World</p>
<p>Tom</p>

条件语句

顾名思义，有条件的语句，定义如下

{% if is_true %}
  <h1>It is true!</h1>
{% else %}
  <h1>It is false!</h1>
{% endif %}

如果变量 is_true 为真那么最终渲染出来的就是 <h1>It is true!</h1>，否则就是 <h1>It is false!</h1>，整个条件语句必须以 {% endif %} 结束，并且 {% else %} 是可选的

循环语句

循环语句用来在模板上展示任意长的列表内容

{% for elem in some_list %}
  <p>{{ elem }}</p>
{% endfor %}

如果传入的 some_list 为 ['Apple', 'Banana', 'Orange']，那么渲染出的 HTML 代码就是：

<p>Apple</p>
<p>Banana</p>
<p>Orange</p>

实现一个 Django 模板

在 news 目录中创建一个 templates 目录，再在 templates 目录中创建一个 news 目录，并在内层的 news 目录中创建 index.html 文件 大家可能看到会有些疑问，为什么还要再创建一个 news 目录放置 index.html 文件？

这是由于 Django 的模板查找机制 会将所有应用里面的模板全部收集到一起，如果两个模板的名字冲突，就会导致其中一个模板不能被正确访问。如果放在 news 子文件夹里面，就能够通过 news/index.html 访问，通过命名空间的机制避免冲突 内容如下：

{% if news_list %}
  <ul>
  {% for elem in news_list %}
    <li>
      <h3>{{ elem.title }}</h3>
      <p>{{ elem.content }}</p>
    </li>
  {% endfor %}
  </ul>
{% else %}
  <p>暂无新闻</p>
{% endif %}

刚好覆盖了上述的三种模板语法：表达式插值、条件语句和循环语句

完成模板编写后，我们需要在视图中对其进行渲染，打开 news/views.py 文件，修改代码：

from django.shortcuts import render

def index(request):
    context = {
        'news_list': [
            {
                "title": "Raymq.com是个博客",
                "content": "一个作者倾尽心血的博客",
            },
            {
                "title": "Raymq.com 的专栏很棒",
                "content": "有很多知识可以去学习",
            },
        ]
    }

    return render(request, 'news/index.html', context=context)

这里我们调用 django.shortcuts.render 函数来渲染模板，这个函数通常接受三个参数（有其他参数，但是这里我们不关心）：

• request：请求对象，直接把视图的参数 request 传进来就可以
• template_name：模板名称，这里就是我们刚刚创建的 news/index.html
• context：传入模板的上下文对象，必须是一个字典，字典中的每个键对应模板中的变量，这里我们弄了些假数据，假装是从数据库里面取来的、

继续访问 localhost:8000，看一下我们的首页内容：

总结

这一章我们主要讲了模板怎么建立的，以及如何在视图渲染

愿诸君顺遂

上一节我们讲了 Django 是一个高度模块化的框架

具体来说，一个 Django 应用由多个子应用组成，我们一般称之为 App（注意不是我们常说的移动应用 APP，而是 Application） 如上图可以看到 Django App 一般分为三大类： 内置：即 Django 框架自带的应用，包括 admin（后台管理）、auth（身份鉴权）、sessions（会话管理）等等 自定义：即用来实现我们自身业务逻辑的应用，这里我们将创建一个新闻展示应用 第三方：即社区提供的应用，数量极其丰富，功能涵盖几乎所有方面，能够大大减少开发成本

而所有的 Django 应用都在 djangonews/settings.py 的 INSTALLEDAPPS 列表中定义

实现自定义 APP

python3 manage.py startapp news

生成的 news 应用文件夹结构如下所示：

news                     // news 应用目录
├── __init__.py          // 初始化模块
├── admin.py             // 后台管理配置
├── apps.py              // 应用配置
├── migrations           // 数据库迁移文件目录
│   └── __init__.py      // 数据库迁移初始化模块
├── models.py            // 数据模型
├── tests.py             // 单元测试
└── views.py             // 视图

可以看到一个目录下有很多的文件，这是因为 Django 始终坚持解耦的原则 —— 尽量减少代码之间的耦合，把不相关的代码拆成多个模块，让同一个模块具有内聚性

我们在 settings.py 中将 news 应用加入 INSTALLED_APPS 中

业务逻辑编写

通过访问 localhost:8000/admin 已经可以访问后台管理系统了（虽然会跳转到登录界面）

接下来，我们同样希望能够访问到刚才创建的 news 应用，因此，这一步中我们将：

• 在视图（View）中写一点业务逻辑
• 接入路由，使其能够被访问

Django 的路由系统

如果你对路由一直很迷惑，只需要记住路由的核心概念：决定"从哪里到哪里应该怎么走"的规则，本质都是"根据输入找到对应处理逻辑"。

Django 的路由系统是由全局路由和子应用路由组成。简单来说，根据用户输入的 URL，全局路由表进行匹配并选择正确的子应用路由，再由所选择的子应用路由匹配并选择正确的视图（View）如图： 用户访问 example.com/apple/buy，然后全局路由根据 /apple/buy 先选择 apple 的路由表，再从 apple 路由表中根据 /buy 选择 /buy 路由，然后执行 /buy 对应的 BuyView 视图，返回给用户结果

编写第一个视图

对视图访问的流程大致了解之后，我们就可以开始动手了

首先打开 news/views.py，写一个简单的视图函数，返回一串 Hello World!

from django.http import HttpResponse

def index(request):
    return HttpResponse('Hello World!')

上面这个 index 函数可以说是一个最简单的视图函数了，实际大部分应用的视图要比这复杂得多。Django 同时支持 基于函数的视图（FBV，Function-based View）和 基于类的视图（CBV，Class-based View），这里显然是 FBV，接收一个 request 请求对象作为参数，返回了一个 HttpResponse 对象

将视图接入路由

接着，我们要让路由系统能够访问到刚才写好的视图函数。因此先实现子应用 news 的路由表，创建 news/urls.py 文件，内容如下：

from django.urls import path
from . import views

urlpatterns = [
    path('', views.index, name='index'),
]

每一个 Django 路由表模块（urls.py）中都约定必须包含一个 urlpatterns 列表用来存放路由映射表。列表中每个元素是一个用 django.urls.path 函数封装好的路由映射，通常接收以下三个参数：

• route：必须，实际的访问路由; 空字符串等于 /，空路由
• view：必须，该路由将要访问的视图
• name：可选，该路由的名称，方便后续在模板中使用

我们将刚刚写好的 news 路由表接入全局路由表。由于我们希望新闻能够展示在首页（即通过 / 就能访问，无需 /news），因此 news 应用路由在全局路由中的 URL 是一个空字符串。在 django_news/urls.py 中修改，内容如下：

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', include('news.urls')),
]

这里使用 django.urls.include 函数将 news 应用的路由表接入进来，并且 include 函数的参数是路由模块路径的字符串 news.urls，省去了手动 import 的麻烦

添加路由规则时顺序是很重要的，因为在尝试匹配时会按照从上到下的顺序进行，因此应该把最模糊的路由（即空路由）放在最下面。

如果你的开发服务器还在运行（如果没有可以再打开），访问 localhost:8000，就可以看到一串熟悉的字符了

总结

这一篇，主要讲解了一些 APP 的概念，以及路由的概念，以及如何编写一个视图并通过路由从而在网页进行体现

整体流程就是：news/view.py ——> news/urls.py ——> django_news/urls.py

愿诸君顺遂

Django 的 MTV，我们已经讲了 T（Template）和 V（View），现在来到了最后一：M（Model）

数据模型是 Django 入门最大的难点，消化这一步的内容就需要花点力气了。下面我们先介绍一下 Django 的数据模型设计

Django 在数据模型方面的设计堪称典范，列举一些闪光点：

• 由于高度解耦的设计，可轻松切换各种关系型数据库（默认的 SQLite，可选 MySQL、PostgreSQL、Oracle 等等）
• 强大的 ORM（Object Relation Mapping，对象关系映射）模块，使得用 Python 操作数据库非常轻松，免去了使用 SQL 的麻烦
• 优秀的数据库迁移机制（Migration），修改数据模式（Schema）比较方便，能够适应不断变化的功能需求

我们暂且选择默认的 SQLite 数据库，省去了配置数据库的烦恼

理解 ORM

如果你写过 c++ 或 go ，对于 ORM 来说应该是不陌生的，ORM 能够将面向对象的代码转换成相应的 SQL 语句，从而对数据库进行操作

SQL 是用于访问和处理数据库的标准的计算机语言，但是直接写在代码里面显然难以维护，而且对使用者的要求也非常高，写的糟糕的 SQL 代码查询效率非常低下。因此，使用设计良好的 ORM 不仅让代码可读性更好，也能帮助开发者进行查询优化，节省不少力气

来看一些简单的 Django ORM 例子：

# 查询所有模型
# 等价于 SELECT * FROM Blog
Blog.objects.all()

# 查询单个模型
# 等价于 SELECT * FROM Blog WHERE ID=1
Blog.objects.get(id=1)

# 添加单个模型
# 等价于 INSERT INTO Blog (title, content) VALUES ('hello', 'world')
blog = Blog(title='hello', content='world')
blog.save()

理解数据库迁移

数据库迁移是指将用 Django 定义的模型转换成 SQL 代码（即迁移文件），并在数据库中进行建表操作（或更新表），如图 一般开发流程如下： 1、用 Django 定义了一个新的数据模型 2、用 makemigrations 命令创建迁移文件（存储在子应用的 migrations 目录里面） 3、用 migrate 命令执行迁移 4、在开发中发现第 1 步中定义的模型不完善，更新数据模型 5、跳转到第 2 步，反复循环

实现一个数据模型

在 news/models.py 中定义数据模型 Post ，包括标题 title 字段和 content 字段，代码如下：

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()

    def __str__(self):
        return self.title

创建数据迁移文件：

python3 manage.py makemigrations

# 输出:
Migrations for 'news':
  news/migrations/0001_initial.py
    - Create model Post

并且成功地自动创建了 news/migrations/0001_initial.py 迁移脚本，开始数据迁移

python manage.py migrate

输出如下

数据迁移完后，创建数据库迁移完成后，我们就可以创建用于登录后台管理的超级用户：

python3 manage.py createsuperuser

按照提示填写用户名和密码即可，然后访问 localhost:8000/admin，进入后台系统的登录页面： 可以看到一个奇怪的事，我们明明创建了 news 应用还有 Post 模型，为什么没有显示呢？

配置后台管理接口

因为我们没有实现 news 应用的后台管理接口，在 news/admin.py 中写入：

from django.contrib import admin
from .models import Post

admin.site.register(Post)

再次访问 localhost:8000/admin 就可以看到 news 应用和 Post 模型了： 点击 Posts 一栏的 +Add 按钮，开始添加新闻：

视图中添加数据查询

最后，我们在视图中加入从数据库中查询的代码，代码如下，对伪数据进行替换即可：

from django.shortcuts import render
from .models import Post

def index(request):
    context = { 'news_list': Post.objects.all() }
    return render(request, 'news/index.html', context=context)

访问 localhost:8000 就可以看到刚才在后台管理系统添加的新闻

总结

通过这四篇的教程，我们已经成功做出了一个简陋的 新闻发布网站，并且可以从 后台管理系统中添加新闻，最终展示到我们的网站首页上

希望这份专栏能够让你对 Django 里最重要的一些概念和操作有基本的了解

Django 还有很多很多的高级玩法，例如数据模型中的高级查询、字段索引、更换数据库等等，模板中的继承机制、内部标签等等，还有视图中如何处理各类请求（POST、PUT等），这些内容或许我不会出，但如果你对 Django 感兴趣，希望你能够主动去了解 学习

愿诸君顺遂

序言

今天我们来讲讲 IaaS、PaaS、SaaS

原因是今天配环境的时候，mt 给我发了一句 emmm，说实话，我对这三个 aas 的理解来自于大二上学习 云计算 这门课，是为了应付考试刷了很多次题库，理解始终处于一种非常浅显的理解。

PaaS：平台即服务 SaaS：软件即服务 IaaS：基础设施即服务

我当时理解的其实就这么多，而对于 平台、软件 对应的服务是什么不知道。 å 希望阅读完以下内容，能让你对这些服务有基本的了解。

正文

IaaS、PaaS、SaaS 是云计算的三大服务模式，分别代表 基础设施、平台和软件的服务化。 它们在资源管理、用户操作、应用开发等层面抽象程度不同，适用场景和用户角色也各有侧重。

IaaS

IaaS：Infrastructure as a Service、基础设施即服务。为用户提供底层计算、存储、网络等基础资源，用户可以按需租用虚拟机、存储空间、网络等硬件资源，无需自建数据中心。用户负责在这些资源上安装操作系统、部署应用，拥有较高的灵活性和控制权。

看到这些，大家应该就能轻松想到，我们平常看到的各种云服务器。比如 AWS EC2、阿里云 ECS、OpenStack 等，就属于 IaaS。适用于需要高度定制化、对底层资源有特殊需求的企业或开发者。

它的优势：弹性扩展、资源利用率高、自动化运维；劣势：用户需自行管理操作系统、应用环境，运维压力较大。

这里你可能会有些迷糊，为什么已经是自动化运维了，还会存在用户运维压力较大呢？

本质上是，IaaS 卖的是基础设施的运维。

比如你的 云服务器 的物理机硬盘暴了，它能做到自动数据迁移；你设置好了访问流量策略，人多时加机器扩容，人少时缩容。而这些都是云厂商自动帮你做的，当你看到信息前你是无感的。

而用户的运维压力源自于，云厂商提供给你的是一个虚拟机，这台机器的系统你需要自己搭、端口开放策略自己决定、性能压力很大你需要自己排查（这里为什么不是自动扩缩容，因为云厂商只保证物理机性能没被别人抢走）

简单来说：IaaS 就是你租一个毛坯厨房（虚拟机），里面有水电气。然后就没了，什么锅啊、灶台啊、菜啊，自己想办法去。并且设备坏了，call 给云厂商给你换，但是你又得重新装修。

PaaS

PaaS：Platform as a Service，平台即服务。 PaaS 在 IaaS 之上进一步抽象，提供应用开发、运行、管理所需的平台环境，包括数据库、中间件、开发框架、容器管理等。开发者只需关注应用代码，无需管理底层硬件和操作系统。

说白了，就是将底层硬件进行封装，使用可视化界面进行底层硬件管理。我们常见的 xx后台管理系统，就类似于PaaS。

比如 Google App Engine、Heroku、蓝鲸PaaS平台、OpenShift 等，就属于 PaaS。适用于快速开发、部署、迭代应用的场景，尤其是中小团队或需要敏捷开发的企业。（敏捷开发就是迭代速度要快

优势：开发效率高、自动化部署、资源弹性、运维简化；劣势：平台限制较多，部分场景下对底层资源的控制有限。

这里的平台限制，很好理解，就是固化。我平台只支持 python 3.9，我的代码使用了 3.12 的异步，部署到平台上，发现运行不了，你怎么解决？只能降级，因为平台不是你的，升级版本可能就是个把月后才会做的。

简单来说：PaaS 就是你租了一个标准的中央厨房（应用运行环境），灶台（操作系统）已经砌好，锅（数据库/中间件）已经架上，甚至连切好的葱姜蒜（常用依赖库）都给你装在小碗里了。但是，可能中央厨房会限制你每道菜烹饪时间为 xx分钟，你要是文火煲个鸡汤，你吃的没准还是生的。

SaaS

SaaS：Software as a Service，软件即服务。SaaS是最高层的云服务，直接向用户提供完整的软件应用（比如邮箱、CRM、ERP、协同办公等），用户无需开发、部署、维护，只需通过浏览器或客户端使用就行了。

常见的就是 Salesforce、飞书、企微、蓝鲸SaaS应用等。适用于对IT能力要求低、希望快速上线业务的企业和个人。

优势：即开即用、无需运维、按需付费、升级维护由服务商负责；劣势：定制能力有限，数据安全需依赖服务商。

这就涉及到数据安全的问题了，hh，虽然小公司的数据不是什么非必要的数据......

简单来说：SaaS 就是你直接点外卖，然后吃就可以了

结语

这三种模式，在我看来就是一句话：降低技术门槛，让业务更加简便。

不知道各位看完后，是否对这三个模式有了基础的了解。

最后我想说一些额外的话，可能大家对于这些东西，会有疑问，说：我一定要学这东西吗？好多内容，我要不要都记住？

我的回答是：不需要，你只需看过，有印象，就够了。

最后附上一张 蓝鲸产品架构

愿诸君顺遂。