准备工作
您需要有:
- 安装了 Kf 的现有集群。
- 对安装了
gcloud
、kf
、kubectl
的机器的访问权限。
验证现有 Kf 安装
获取身份验证凭据以便与集群进行交互:
gcloud container clusters get-credentials CLUSTER_NAME \ --zone CLUSTER_ZONE \ --project CLUSTER_PROJECT_ID
运行
kf debug
并验证 Kf CLI 与 Kf 服务器版本是否匹配。- CLI 版本列在
Kf Client
下。 - Kf 服务器版本列在
kf["app.kubernetes.io/version"]
下。
$ kf debug ... Version: Kf Client: v2.0.0 Server version: v1.17.13-gke.1401 kf["app.kubernetes.io/version"]: v2.0.0 ...
如果 Kf 客户端与 Kf 服务器值不一致,请下载并安装 与服务器版本相同的 Kf CLI 版本,然后使用新的 CLI 重复检查。在您继续操作之前,CLI 版本必须与服务器版本匹配。
- CLI 版本列在
运行
kf doctor
以检查集群的状态。确保所有测试均已通过,然后再继续。$ kf doctor ... === RUN doctor/user === RUN doctor/user/ContainerRegistry --- PASS: doctor/user --- PASS: doctor/user/ContainerRegistry ...
如果您看到消息
Error: environment failed checks
,请按照doctor
输出中的指导操作来解决问题,并重试该命令直到成功为止。
升级
如需升级 Kf,请执行以下步骤:
- 准备本地环境和升级。
- 升级 Kf 的依赖项。
- 升级 Kf 并验证升级成功。
准备升级
运行
kf version
以了解 Kf 的当前版本。$ kf version kf version v2.0.0 linux
访问下载页面以查找 Kf 的下一个最新版本。
下载 Kf 版本 YAML 文件并将它另存为
kf-release.yaml
。下载与您的操作系统对应的 Kf 版本,并将它命名为
kf-next
。运行
chmod
以让kf-next
可执行:chmod +x kf-next
运行
kf-next version
以确保下载的版本与您要安装的 Kf 版本一致:$ kf-next version kf version v2.1.0 linux
通过运行以下命令来备份
config-defaults
configmap:kubectl get configmap config-defaults -o yaml -n kf > config-defaults-backup.yaml
运行
kubectl diff -f kf-release.yaml
并检查升级将对集群进行的更改。修改
kf-release.yaml
以保留任何要保留的更改。例如,如果您在 Kf 的
v2.0.0
中将config-defaults
configmap 属性spaceDefaultToV3Stack
设置为 false,则v2.1.0
版本的默认值将为true
。再次运行
kubectl diff -f kf-release.yaml
以确保您所做的任何更改会产生预期的输出。
升级 Kf 依赖项
打开下载页面,然后找到要升级到的 Kf 版本的依赖项表。
升级 Tekton:
打开 Tekton 版本页面。
查找 Kf 依赖项表中列出的 Tekton 版本。
运行“Install one-liner”标题下的命令来升级 Tekton。
升级 Cloud Service Mesh:
在版本下拉列表中,选择 Kf 依赖项表中列出的 Cloud Service Mesh 版本。
按照指南升级 ASM。
升级并验证 Kf
使用修改后的版本配置安装升级后的 Kf 组件:
kubectl apply -f kf-release.yaml
运行
doctor
以确保新安装的版本运行状况良好:kf-next doctor --retries=12 --delay=5s
该命令将多次运行集群检查。在新控制器启动时,有几次尝试失败是正常的。
如果命令失败并显示消息
Error: environment failed checks
,请按照doctor
输出中的指导操作来解决问题,并重试该命令直到成功为止。使用
kf-next
CLI 替换系统中现有的kf
CLI。chmod +x kf-next
mv kf-next $(which kf)
将
config-defaults-backup.yaml
文件与kubectl diff -f config-defaults-backup.yaml
进行比较,以确保您的集群仍然正确配置。例如,如果您保留了对旧版 Kf 所做的所有更改,并且已批准使用与下一个 Kf 版本捆绑的新 buildpack:
$ kubectl diff -f config-defaults-backup.yaml diff -u -N /tmp/LIVE/v1.ConfigMap.kf.config-defaults /tmp/MERGED/v1.ConfigMap.kf.config-defaults --- /tmp/LIVE/v1.ConfigMap.kf.config-defaults +++ /tmp/MERGED/v1.ConfigMap.kf.config-defaults @@ -131,6 +131,8 @@ enable_route_services: false spaceBuildpacksV2: | - - name: new_buildpack - url: https://github.com/cloudfoundry/new-buildpack - name: staticfile_buildpack url: https://github.com/cloudfoundry/staticfile-buildpack - name: java_buildpack exit status 1