备案控制台
开发者社区 开发与运维 文章 正文

二进制 k8s 集群下线 master 组件流程分析和实践

2023-11-08 78
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 二进制 k8s 集群下线 master 组件流程分析和实践

事出因果

自己虚拟跑了一个 3 master + 2 node 的 k8s 集群，因为当初验证部署脚本，验证完成后，就开始部署一些服务来验证环境可用性，目前的环境情况，其实也不需要 3 master 这样的架构，

有点浪费电脑的资源，于是有了这样的一个想法

虽说虚拟机，不影响，只需要铲了重装就好，但是这样的习惯也并非好事情

咱要做一个优雅的人，要让他优雅的离场，毕竟也是功臣，怎能直接踹了她 [ k8s 这么可爱，一 jio 上去会哭很久的吧 ]

环境介绍

先介绍一下我的集群架构和情况

  • 部署方式 - 二进制
  • etcd 节点数量 - 3个
  • k8s master 组件节点数量 - 3个
  • k8s apiserver 是否开启高可用-使用 nginx 做反向代理，并使用 upstream 负载均衡到三个 apiserver 节点
  • 使用 127.0.0.1 来访问本机 nginx 反向代理，因此所有 node 节点均有 nginx

个人思路

  1. 我的架构没有涉及到 keepalived 一类的高可用，也没有云主机的 SLB 做高可用，我这里需要先把 nginx 的 upstream 模块内需要下线的节点先置为 down
  • 我这边也不考虑替换证书的apiserver访问地址，还是延续我之前的127.0.0.1:8443
  • 如果有更换 apiserver 访问地址的需求，需要用之前的 ca 根证书，重新生成相关的 kubeconfig 文件，并做替换
  1. 修改 apiserver 访问的 etcd 地址，以及相关的 etcd 证书文件
  2. 下线需要下线的etcd节点
  • 通过 etcdctl member remove 的方式，先将需要下线的 etcd 节点踢出集群
  1. etcd 重启无异常后，重启 apiserver 节点

准备实践

当前 master 节点信息

节点 ip 节点角色 是否下线
172.72.0.95 master 节点 不下线
172.72.0.96 master 节点 下线 etcd 和 master 组件
172.72.0.97 master 节点 下线 etcd 和 master 组件

切换 apiserver 访问流量

如上面所说，我这边需要把所有节点的 nginx 的配置做一个修改，将需要下线的节点置为 down

大家要按照自己实际的场景做处理，这里无法一一道来，整体思路就是将需要下线的节点踢出高可用的场景

  • 以下的操作，仅代表个人环境，大家了解一个思路就好了，具体的实操，还是要以自己的实际环境为准
查看 nginx 配置文件

先看看 nginx 配置文件在哪

systemctl cat kube-nginx
# /etc/systemd/system/kube-nginx.service
[Unit]
Description=kube-apiserver nginx proxy
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
Type=forking
ExecStartPre=/approot/data/k8s/bin/nginx \
             -c /approot/data/k8s/kube-nginx/kube-nginx.conf \
             -p /approot/data/k8s/kube-nginx -t
ExecStart=/approot/data/k8s/bin/nginx \
          -c /approot/data/k8s/kube-nginx/kube-nginx.conf \
          -p /approot/data/k8s/kube-nginx
ExecReload=/approot/data/k8s/bin/nginx \
           -c /approot/data/k8s/kube-nginx/kube-nginx.conf \
           -p /approot/data/k8s/kube-nginx -s reload
PrivateTmp=true
Restart=always
RestartSec=5
StartLimitInterval=0
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

修改 nginx 配置文件

worker_processes 1;
events {
    worker_connections  1024;
}
stream {
    upstream apiserver {
      hash $remote_addr consistent;
      server 172.72.0.95:6443 max_fails=3 fail_timeout=30s;
      server 172.72.0.96:6443 max_fails=3 fail_timeout=30s down;
      server 172.72.0.97:6443 max_fails=3 fail_timeout=30s down;
    }
    server {
      listen *:8443;
      proxy_connect_timeout 1s;
      proxy_pass apiserver;
    }
}

验证配置文件，这里是为了美观，毕竟路径太长了

nginx_home='/approot/data/k8s/kube-nginx'

使用 -p 参数修改 prefix 路径，nginx 编译完，默认的 prefix 路径是编译的时候指定的路径，在这里使用会报错

nginx -p ${nginx_home} \
-c ${nginx_home}/kube-nginx.conf -t

返回如下结果，说明配置文件格式没有问题

nginx: the configuration file /approot/data/k8s/kube-nginx/kube-nginx.conf syntax is ok
nginx: configuration file /approot/data/k8s/kube-nginx/kube-nginx.conf test is successful

重载 nginx，因为的 systemctl 配置了 reload 参数，如果没有配置，使用 nginx -s reload 也可以实现

reload 相比 restart 要优雅很多

systemctl reload kube-nginx

所有的节点，都按照上面的方式修改 nginx 的配置文件，实现 apiserver 流量的切换

停止下线节点的 apiserver 服务

既然已经把 apiserver 的访问转移到指定的节点了，那正常情况下，咱们停止了下线节点的 apiserver 服务，不会对集群造成影响（顺便把开机自启也关了）

systemctl disable kube-apiserver --now

此时，我们可以去不下线的节点执行 kubectl get node 验证是否正常能获取的到节点信息，没有问题就可以继续停止下一个下线节点的 apiserver 服务

生成新的证书

如果新的 csr json 文件找不到了，那就只能通过 openssl 校验证书，获取对应的信息，重新生成证书

  • csr json 文件模板
{
  "CN": "",
  "hosts": [
    "127.0.0.1",
    "kubernetes",
    "kubernetes.default",
    "kubernetes.default.svc",
    "kubernetes.default.svc.cluster",
    "kubernetes.default.svc.cluster.local"
  ],
  "key": {
    "algo": "",
    "size": 
  },
  "names": [
    {
      "C": "",
      "ST": "",
      "L": "",
      "O": "",
      "OU": ""
    }
  ]
}

从原有的 pem 文件获取 csr json 文件的内容 [这里就举个例子，pem 文件名称以自己实际的为准]

openssl x509 -noout -text -in kubernetes.pem | egrep -i 'issuer|dns|public'
  • CN 、 C 、 ST 、 L 、 O 、 OU 、 CN 都在 Issuer 字段可以获取的到
  • hosts 在 DNS 字段可以获取的到
  • key 在 Public Key Algorithm 和 Public-Key 里面可以获取得到，这里对应的 algo 是 rsa ，size 是 2048
        Issuer: C=CN, ST=ShangHai, L=ShangHai, O=k8s, OU=System, CN=kubernetes
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster, DNS:kubernetes.default.svc.cluster.local, IP Address:172.72.0.95, IP Address:172.72.0.96, IP Address:172.72.0.97, IP Address:127.0.0.1, IP Address:10.254.0.1
生成 etcd 新证书

配置 csr-json 文件，去除需要下线节点的 ip

{
  "CN": "etcd",
  "hosts": [
    "172.72.0.95",
    "127.0.0.1"
  ],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "ShangHai",
      "L": "ShangHai",
      "O": "k8s",
      "OU": "System"
    }
  ]
}

生成新的 pem 文件

cfssl gencert -ca=ca.pem \
-ca-key=ca-key.pem \
-config=ca-config.json \
-profile=kubernetes etcd-csr.json | cfssljson -bare etcd

备份老的 etcd 证书，注意，这里的路径也要以自己的实际路径为准


mv /etc/kubernetes/ssl/etcd.pem{,-bak-$(date +%FT%T%z)}
mv /etc/kubernetes/ssl/etcd-key.pem{,-bak-$(date +%FT%T%z)}

复制新的 etcd 证书到 etcd 证书路径，这里先不着急重启服务，因为还没将要下线的节点踢出集群

生成 apiserver 新证书

配置 csr-json 文件，去除需要下线节点的 ip

{
  "CN": "kubernetes",
  "hosts": [
    "172.72.0.95",
    "127.0.0.1",
    "10.254.0.1",
    "kubernetes",
    "kubernetes.default",
    "kubernetes.default.svc",
    "kubernetes.default.svc.cluster",
    "kubernetes.default.svc.cluster.local"
  ],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "ShangHai",
      "L": "ShangHai",
      "O": "k8s",
      "OU": "System"
    }
  ]
}

生成新的 pem 文件

cfssl gencert -ca=ca.pem \
-ca-key=ca-key.pem \
-config=ca-config.json \
-profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes

备份老的 apiserver 证书，注意，这里的路径也要以自己的实际路径为准

mv /etc/kubernetes/ssl/kubernetes.pem{,-bak-$(date +%FT%T%z)}
mv /etc/kubernetes/ssl/kubernetes-key.pem{,-bak-$(date +%FT%T%z)}

复制新的 apiserver 证书到 apiserver 证书路径，这里先不着急重启服务，因为还没修改 etcd 集群的访问地址

修改 apiserver 配置文件

我的二进制部署，是将 apiserver 启动参数写进 systemctl 管理的 service 文件内的，没有单独的去引用，这里需要备份一下 service 文件

cp /etc/systemd/system/kube-apiserver.service{,-bak-$(date +%FT%T%z)}

修改 etcd 的地址，只保留需要的节点，同样先不重启 apiserver 服务

--etcd-servers=https://172.72.0.95:2379

下线 etcd 节点

查找当前 leader 节点

找 leader 节点是因为 leader 节点的数据是最新的，操作之前，需要先快照一下 etcd 的数据，出了问题还能恢复回去

这里也是用的新生成的 etcd 证书来查询的

etcdctl -w table \
--cert /etc/kubernetes/ssl/etcd.pem \
--key /etc/kubernetes/ssl/etcd-key.pem \
--cacert /etc/kubernetes/ssl/ca.pem \
--endpoints https://172.72.0.95:2379 \
endpoint status --cluster

这里可以看到，172.72.0.96 节点是 leader

+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT         |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://172.72.0.95:2379 | 26c65c850c80d42d |  3.4.12 |  4.5 MB |     false |      false |       263 |     642041 |             642041 |        |
| https://172.72.0.96:2379 | 2ae7ff74540f0760 |  3.4.12 |  4.5 MB |      true |      false |       263 |     642041 |             642041 |        |
| https://172.72.0.97:2379 | 4785dde924d48108 |  3.4.12 |  4.6 MB |     false |      false |       263 |     642041 |             642041 |        |
+--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
etcd 数据快照

这里的 --endpoints 使用 172.72.0.96

etcdctl -w table \
--cert /etc/kubernetes/ssl/etcd.pem \
--key /etc/kubernetes/ssl/etcd-key.pem \
--cacert /etc/kubernetes/ssl/ca.pem \
--endpoints https://172.72.0.96:2379 \
snapshot save 172.72.0.95-etcd-snapshot.db
etcd 节点下线

查看节点信息

etcdctl -w table \
--cert /etc/kubernetes/ssl/etcd.pem \
--key /etc/kubernetes/ssl/etcd-key.pem \
--cacert /etc/kubernetes/ssl/ca.pem \
--endpoints https://172.72.0.95:2379 \
member list

返回的结果如下，后面开始下线对应的节点

+------------------+---------+-------------+--------------------------+--------------------------+------------+
|        ID        | STATUS  |    NAME     |        PEER ADDRS        |       CLIENT ADDRS       | IS LEARNER |
+------------------+---------+-------------+--------------------------+--------------------------+------------+
| 26c65c850c80d42d | started | 172.72.0.95 | https://172.72.0.95:2380 | https://172.72.0.95:2379 |      false |
| 2ae7ff74540f0760 | started | 172.72.0.96 | https://172.72.0.96:2380 | https://172.72.0.96:2379 |      false |
| 4785dde924d48108 | started | 172.72.0.97 | https://172.72.0.97:2380 | https://172.72.0.97:2379 |      false |
+------------------+---------+-------------+--------------------------+--------------------------+------------+

下线 172.72.0.97 节点，预期会返回类似如下的输出 Member 4785dde924d48108 removed from cluster 5957c47fd14d3795

etcdctl \
--cert /etc/kubernetes/ssl/etcd.pem \
--key /etc/kubernetes/ssl/etcd-key.pem \
--cacert /etc/kubernetes/ssl/ca.pem \
--endpoints https://172.72.0.95:2379 \
member remove 4785dde924d48108

下线 172.72.0.96 节点，预期会返回类似如下的输出 Member 2ae7ff74540f0760 removed from cluster 5957c47fd14d3795

etcdctl \
--cert /etc/kubernetes/ssl/etcd.pem \
--key /etc/kubernetes/ssl/etcd-key.pem \
--cacert /etc/kubernetes/ssl/ca.pem \
--endpoints https://172.72.0.95:2379 \
member remove 2ae7ff74540f0760

再次查看 etcd 节点信息，就只剩下当前需要保留的节点了

+------------------+---------+-------------+--------------------------+--------------------------+------------+
|        ID        | STATUS  |    NAME     |        PEER ADDRS        |       CLIENT ADDRS       | IS LEARNER |
+------------------+---------+-------------+--------------------------+--------------------------+------------+
| 26c65c850c80d42d | started | 172.72.0.95 | https://172.72.0.95:2380 | https://172.72.0.95:2379 |      false |
+------------------+---------+-------------+--------------------------+--------------------------+------------+
停止下线节点 etcd 服务
systemctl disable kube-etcd --now
修改保留节点的 etcd 配置文件

这里只保留当前节点的信息

--initial-cluster=172.72.0.95=https://172.72.0.95:2380

重载一下 service 文件

systemctl daemon-reload
重启 etcd 服务

这里我们重启一下当前保留的 etcd 节点，确保 etcd 能正常工作

systemctl restart kube-etcd

查看集群健康状态

etcdctl -w table \
--cert /etc/kubernetes/ssl/etcd.pem \
--key /etc/kubernetes/ssl/etcd-key.pem \
--cacert /etc/kubernetes/ssl/ca.pem \
--endpoints https://172.72.0.95:2379 \
endpoint health

返回类似如下的信息，说明 etcd 服务是正常的

+--------------------------+--------+------------+-------+
|         ENDPOINT         | HEALTH |    TOOK    | ERROR |
+--------------------------+--------+------------+-------+
| https://172.72.0.95:2379 |   true | 5.818866ms |       |
+--------------------------+--------+------------+-------+

重启 apiserver controller-manager scheduler 服务

systemctl restart kube-apiserver kube-controller-manager scheduler

不重启 controller-manager 会影响副本控制器，在 controller-manager 的日志里会看到类似这样的报错：Failed to extract job list: Unauthorized

验证节点是否正常

查看 k8s 节点信息是否正常加载

kubectl get node

删一个带有副本控制集的 pod，验证是否会重启 pod

kubectl delete pod -n monitor node-exporter-jlxxl

关闭下线节点其他 k8s master 组件

要记得把开机自启也关闭了

systemctl disable kube-controller-manager kube-scheduler --now

到此，关于 master 节点缩容的实践就结束了


文章标签：
容器服务Kubernetes版
云解析DNS
容器
应用服务中间件
Kubernetes
nginx
JSON
关键词：
容器服务Kubernetes版集群
容器服务Kubernetes版实践
容器服务Kubernetes版组件
容器服务Kubernetes版二进制
容器服务Kubernetes版分析
相关实践学习
容器服务Serverless版ACK Serverless 快速入门：在线魔方应用部署和监控
通过本实验，您将了解到容器服务Serverless版ACK Serverless 的基本产品能力，即可以实现快速部署一个在线魔方应用，并借助阿里云容器服务成熟的产品生态，实现在线应用的企业级监控，提升应用稳定性。
云原生实践公开课
课程大纲 开篇：如何学习并实践云原生技术 基础篇： 5 步上手 Kubernetes 进阶篇：生产环境下的 K8s 实践 相关的阿里云产品：容器服务 ACK 容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器应用管理能力，支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力，打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
chen2ha
目录
相关文章
游客qf4jmczx4xu2y
|
16天前
|
运维 Kubernetes 监控
Kubernetes 集群的持续性能优化实践
【4月更文挑战第26天】 在动态且不断增长的云计算环境中，维护高性能的 Kubernetes 集群是一个挑战。本文将探讨一系列实用的策略和工具，旨在帮助运维专家监控、分析和优化 Kubernetes 集群的性能。我们将讨论资源分配的最佳实践，包括 CPU 和内存管理，以及集群规模调整的策略。此外，文中还将介绍延迟和吞吐量的重要性，并提供日志和监控工具的使用技巧，以实现持续改进的目标。
游客qf4jmczx4xu2y
37 2
我不是游客20240119
|
3天前
|
消息中间件 运维 Kubernetes
构建高效自动化运维体系：Ansible与Kubernetes的融合实践
【5月更文挑战第9天】随着云计算和微服务架构的普及，自动化运维成为确保系统可靠性和效率的关键。本文将深入探讨如何通过Ansible和Kubernetes的集成，构建一个强大的自动化运维体系。我们将分析Ansible的配置管理功能以及Kubernetes容器编排的优势，并展示如何将二者结合，以实现持续部署、快速扩展和高效管理现代云原生应用。文章还将涵盖实际案例，帮助读者理解在真实环境下如何利用这些工具优化运维流程。
我不是游客20240119
12 2
肥猪肥猪-17824
|
1天前
|
存储 运维 监控
Kubernetes 集群的持续监控与性能优化策略
【5月更文挑战第11天】在微服务架构日益普及的当下，Kubernetes 已成为容器编排的事实标准。随着其在不同规模企业的广泛采用，如何确保 Kubernetes 集群的高效稳定运行变得至关重要。本文将探讨一套系统的 Kubernetes 集群监控方法，并结合实践经验分享针对性能瓶颈的优化策略。通过实时监控、日志分析与定期审计的结合，旨在帮助运维人员快速定位问题并提出解决方案，从而提升系统的整体表现。
肥猪肥猪-17824
4 0
GG2020gg
|
3天前
|
Kubernetes Java API
Kubernetes详解（三）——Kubernetes集群组件
Kubernetes详解（三）——Kubernetes集群组件
GG2020gg
15 1
天下无贼001
|
8天前
|
运维 监控 Kubernetes
Kubernetes 集群的监控与维护策略
【5月更文挑战第4天】 在当今微服务架构盛行的时代，容器化技术已成为软件开发和部署的标准实践。Kubernetes 作为一个开源的容器编排平台，因其强大的功能和灵活性而广受欢迎。然而，随着 Kubernetes 集群规模的扩大，集群的监控和维护变得日益复杂。本文将探讨 Kubernetes 集群监控的重要性，分析常见的监控工具，并提出一套有效的集群维护策略，以帮助运维人员确保集群的健康运行和高可用性。
天下无贼001
40 10
天下无贼001
|
9天前
|
存储 运维 监控
Kubernetes 集群的持续监控与优化策略
【5月更文挑战第3天】在微服务架构和容器化部署日益普及的背景下，Kubernetes 已成为众多企业的首选容器编排平台。然而，随着集群规模的增长和业务复杂度的提升，有效的集群监控和性能优化成为确保系统稳定性和提升资源利用率的关键。本文将深入探讨针对 Kubernetes 集群的监控工具选择、监控指标的重要性解读以及基于数据驱动的性能优化实践，为运维人员提供一套系统的持续监控与优化策略。
天下无贼001
37 7
请看我回答~
|
12天前
|
运维 Kubernetes 监控
Kubernetes 集群的监控与维护策略
【4月更文挑战第30天】 在现代云计算环境中，容器化技术已成为应用程序部署和管理的重要手段。其中，Kubernetes 作为一个开源的容器编排平台，以其强大的功能和灵活性受到广泛欢迎。然而，随之而来的是对 Kubernetes 集群监控和维护的复杂性增加。本文将探讨针对 Kubernetes 集群的监控策略和维护技巧，旨在帮助运维人员确保集群的稳定性和高效性。通过分析常见的性能瓶颈、故障诊断方法以及自动化维护工具的应用，我们将提供一套实用的解决方案，以优化 Kubernetes 环境的性能和可靠性。
请看我回答~
25 0
请看我回答~
|
12天前
|
运维 Kubernetes 监控
Kubernetes集群的持续性能优化策略
【4月更文挑战第30天】 在动态且不断扩展的云计算环境中，保持应用性能的稳定性是一个持续的挑战。本文将探讨针对Kubernetes集群的持续性能优化策略，旨在为运维工程师提供一套系统化的性能调优框架。通过分析集群监控数据，我们将讨论如何诊断常见问题、实施有效的资源管理和调度策略，以及采用自动化工具来简化这一过程。
请看我回答~
26 0
请看我回答~
|
12天前
|
Prometheus 监控 Kubernetes
Kubernetes 集群的监控与日志管理策略
【4月更文挑战第30天】 在微服务架构日益普及的当下，容器化技术与编排工具如Kubernetes成为了运维领域的重要话题。有效的监控和日志管理对于保障系统的高可用性和故障快速定位至关重要。本文将探讨在Kubernetes环境中实施监控和日志管理的最佳实践，包括选用合适的工具、部署策略以及如何整合这些工具来提供端到端的可见性。我们将重点讨论Prometheus监控解决方案和EFK（Elasticsearch, Fluentd, Kibana）日志管理堆栈，分析其在Kubernetes集群中的应用，并给出优化建议。
请看我回答~
37 2
景天科技苑
|
13天前
|
Kubernetes 应用服务中间件 nginx
K8S二进制部署详解，一文教会你部署高可用K8S集群（二）
K8S二进制部署详解，一文教会你部署高可用K8S集群（二）
景天科技苑
31 0

热门文章

最新文章

  • 1
    搭建k8s集群kubeadm搭建Kubernetes二进制搭建Kubernetes集群
  • 2
    Ubuntu 22.04 利用kubeadm方式部署Kubernetes(v1.28.2版本)
  • 3
    kubeadm安装k8s
  • 4
    构建高效自动化运维体系：基于Docker和Kubernetes的最佳实践
  • 5
    使用 kubeadm 部署 Kubernetes 集群（二）k8s环境安装
  • 6
    探索Kubernetes的大二层网络：原理、优势与挑战🚀
  • 7
    k8s 到底是什么，架构是怎么样的？
  • 8
    Kubernetes Pod
  • 9
    K8s Pod亲和性、污点、容忍度、生命周期与健康探测详解（下）
  • 10
    K8s好看的管理页面Rancher管理K8S
  • 1
    如何通过计算巢在ACK集群上使用Istio服务网格
    35
  • 2
    Docker容器管理
    35
  • 3
    云原生K8S场景自动化响应ECS系统事件
    123
  • 4
    云计算中的容器化技术：Docker与Kubernetes的实践
    167
  • 5
    934.【kubernetes】kubeadm版本更新证书
    67
  • 6
    TCP 中的 Delay ACK 和 Nagle 算法
    36
  • 7
    K8S基于NFS来动态创建PV【亲测可用】
    85
  • 8
    深入浅出：使用Docker容器化部署Python Web应用
    104
  • 9
    深入探讨 Prometheus 在 Kubernetes 上的部署和实战操作
    238
  • 10
    K8S客户端二 使用Rancher部署服务
    101

    • 相关课程

    更多
  • 体验-Kubernetes 对象及资源规范
  • 阿里云K8S微服务部署案例
  • Kubernetes极速入门
  • Serverless 容器从入门到精通: - Serverless Kubernetes
  • Kubernetes云原生管理实践
  • Kubernetes入门

    • 相关电子书

    更多
  • ACK 云原生弹性方案—云原生时代的加速器
  • ACK集群类型选择最佳实践
  • 企业运维之云原生和Kubernetes 实战

    • 相关实验场景

    更多
  • 在ACK Serverless中部署Stable Diffusion应用
  • 使用ACK-Koordinator部署在离线混部应用
  • 基于 ACK Serverless 解锁你家萌宠的 AI 形象
  • 基于ACK Serverless实现容器应用弹性伸缩
  • 使用ACK Serverless容器化部署大语言模型FastChat
  • 通过EDAS实现K8s微服务应用的金丝雀发布

    • 推荐镜像

    更多
  • kubernetes
  • pouch
  • terraform
    • 下一篇
    部署LAMP环境（Alibaba Cloud Linux 3）