AI 助理
备案控制台
开发者社区 云原生 文章 正文

Kubernetes 弹性伸缩全场景解析（三） - HPA 实践手册

2019-07-31 1840
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
Serverless 应用引擎 SAE，800核*时 1600GiB*时
推荐场景：
阿里云宣布 Serverless 应用引擎 SAE2.0 将公测上线，多款产品全新升级
可观测链路 OpenTelemetry 版，每月50GB免费额度
EMR Serverless StarRocks，5000CU*H 48000GB*H
简介： 在上一篇文章中，给大家介绍和剖析了 HPA 的实现原理以及演进的思路与历程。本文我们将会为大家讲解如何使用 HPA 以及一些需要注意的细节。  实践 v1 的模板可能是大家平时见到最多的也是最简单的，v1 版本的 HPA 只支持一种指标 ——  CPU。

在上一篇文章中，给大家介绍和剖析了 HPA 的实现原理以及演进的思路与历程。本文我们将会为大家讲解如何使用 HPA 以及一些需要注意的细节。

 autoscaling/v1 实践

v1 的模板可能是大家平时见到最多的也是最简单的，v1 版本的 HPA 只支持一种指标 ——  CPU。传统意义上，弹性伸缩最少也会支持 CPU 与 Memory 两种指标，为什么在 Kubernetes 中只放开了 CPU 呢？其实最早的 HPA 是计划同时支持这两种指标的，但是实际的开发测试中发现：内存不是一个非常好的弹性伸缩判断条件。因为和 CPU不 同，很多内存型的应用，并不会因为 HPA 弹出新的容器而带来内存的快速回收，很多应用的内存都要交给语言层面的 VM 进行管理，也就是说，内存的回收是由 VM 的 GC 来决定的。这就有可能因为 GC 时间的差异导致 HPA 在不恰当的时间点震荡，因此在 v1 的版本中，HPA 就只支持了 CPU 这一种指标。

一个标准的 v1 模板大致如下：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

其中 scaleTargetRef 表示当前要操作的伸缩对象是谁。在本例中，伸缩的对象是一个 apps/v1 版本的 Deployment。 targetCPUUtilizationPercentage 表示：当整体的资源利用率超过 50% 的时候，会进行扩容。接下来我们做一个简单的 Demo 来实践下。

  1. 登录容器服务控制台，首先创建一个应用部署，选择使用模板创建，模板内容如下：
apiVersion: apps/v1beta1
  kind: Deployment
  metadata:
name: php-apache
labels:
 app: php-apache
  spec:
replicas: 1
selector:
 matchLabels:
   app: php-apache
template:
 metadata:
   labels:
     app: php-apache
 spec:
   containers:
   - name: php-apache
     image: registry.cn-hangzhou.aliyuncs.com/ringtail/hpa-example:v1.0
     ports:
     - containerPort: 80
     resources:
       requests:
         memory: "300Mi"
         cpu: "250m"
  --- 
  apiVersion: v1
  kind: Service
  metadata:
name: php-apache
labels:
 app: php-apache
  spec:
selector:
 app: php-apache
ports:
- protocol: TCP
 name: http
 port: 80 
 targetPort: 80
type: ClusterIP

2.部署压测模组 HPA 模板

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
  apiVersion: apps/v1beta1
  kind: Deployment
  name: php-apache
minReplicas: 1
maxReplicas: 10
targetCPUUtilizationPercentage: 50

3.开启压力测试

apiVersion: apps/v1beta1
   kind: Deployment
   metadata:
     name: load-generator 
     labels:
       app: load-generator
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: load-generator
     template:
       metadata:
         labels:
           app: load-generator
       spec:
         containers:
         - name: load-generator
           image: busybox 
           command:
             - "sh"
             - "-c"
             - "while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done"

4.检查扩容状态 

a1

5.关闭压测应用

a2

6.检查缩容状态 

a3

这样一个使用 autoscaling/v1 的 HPA 就完成了。相对而言，这个版本的 HPA 目前是最简单的，无论是否升级 Metrics-Server 都可以实现。

autoscaling/v2beta1 实践

在前面的内容中为大家讲解了 HPA 还有 autoscaling/v2beta1 和 autoscaling/v2beta2 两个版本。这两个版本的区别是 autoscaling/v1beta1 支持了 Resource Metrics 和 Custom Metrics。而在 autoscaling/v2beta2 的版本中额外增加了 External Metrics 的支持。对于 External Metrics 在本文中就不进行过多赘述，因为 External Metrics 目前在社区里面没有太多成熟的实现，比较成熟的实现是 Prometheus Custom Metrics。

a4

上面这张图为大家展现了开启 Metrics Server 后， HPA 如何使用不同类型的Metrics，如果需要使用 Custom Metrics ，则需要配置安装相应的 Custom Metrics Adapter。在下文中，主要为大家介绍一个基于 QPS 来进行弹性伸缩的例子。

  1. 安装 Metrics Server 并在 kube-controller-manager 中进行开启

目前默认的阿里云容器服务 Kubernetes 集群使用还是 Heapster，容器服务计划在 1.12 中更新 Metrics Server，这个地方需要特别说明下，社区虽然已经逐渐开始废弃 Heapster，但是社区中还有大量的组件是在强依赖 Heapster 的 API，因此阿里云基于 Metrics Server 进行了 Heapster 完整的兼容，既可以让开发者使用 Metrics Server 的新功能，又可以无需担心其他组件的宕机。

在部署新的 Metrics Server 之前，我们首先要备份一下 Heapster 中的一些启动参数，因为这些参数稍后会直接用在 Metrics Server 的模板中。其中重点关心的是两个 Sink，如果需要使用 Influxdb 的开发者，可以保留第一个 Sink；如果需要保留云监控集成能力的开发者，则保留第二个 Sink。 

a5

将这两个参数拷贝到 Metrics Server 的启动模板中，在本例中是两个都兼容，并下发部署。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  name: metrics-server
  namespace: kube-system
  labels:
    kubernetes.io/name: "Metrics-server"
spec:
  selector:
    k8s-app: metrics-server
  ports:
  - port: 443
    protocol: TCP
    targetPort: 443
---
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: metrics-server
  namespace: kube-system
  labels:
    k8s-app: metrics-server
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  template:
    metadata:
      name: metrics-server
      labels:
        k8s-app: metrics-server
    spec:
      serviceAccountName: admin
      containers:
      - name: metrics-server
        image: registry.cn-hangzhou.aliyuncs.com/ringtail/metrics-server:1.1
        imagePullPolicy: Always
        command:
        - /metrics-server
        - '--source=kubernetes:https://kubernetes.default'
        - '--sink=influxdb:http://monitoring-influxdb:8086'
        - '--sink=socket:tcp://monitor.csk.[region_id].aliyuncs.com:8093?clusterId=[cluster_id]&public=true'

接下来我们修改下 Heapster 的 Service，将服务的后端从 Heapster 转移到 Metrics Server。 

a6

如果此时从控制台的节点页面可以获取到右侧的监控信息的话，说明 Metrics Server 已经完全兼容 Heapster。

a7

此时通过 kubectl get apiservice，如果可以看到注册的 v1beta1.metrics.k8s.io 的 api，则说明已经注册成功。

a8

接下来我们需要在 kube-controller-manager 上切换 Metrics 的数据来源。kube-controller-manger 部署在每个 master 上，是通过 Static Pod 的托管给 kubelet 的。因此只需要修改 kube-controller-manager 的配置文件，kubelet 就会自动进行更新。kube-controller-manager 在主机上的路径是 /etc/kubernetes/manifests/kube-controller-manager.yaml。

a9

需要将 --horizontal-pod-autoscaler-use-rest-clients=true，这里有一个注意点，因为如果使用 vim 进行编辑，vim 会自动生成一个缓存文件影响最终的结果，所以比较建议的方式是将这个配置文件移动到其他的目录下进行修改，然后再移回原来的目录。至此，Metrics Server 已经可以为 HPA 进行服务了，接下来我们来做自定义指标的部分。

2.部署 Custom Metrics Adapter

如集群中未部署 Prometheus，可以参考《阿里云容器Kubernetes监控(七) - Prometheus监控方案部署》先部署 Prometheus。接下来我们部署 Custom Metrics Adapter。

kind: Namespace
apiVersion: v1
metadata:
  name: custom-metrics
---
kind: ServiceAccount
apiVersion: v1
metadata:
  name: custom-metrics-apiserver
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: custom-metrics:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: custom-metrics-apiserver
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: custom-metrics-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: custom-metrics-apiserver
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-metrics-resource-reader
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  - pods
  - services
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: custom-metrics-apiserver-resource-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-metrics-resource-reader
subjects:
- kind: ServiceAccount
  name: custom-metrics-apiserver
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-metrics-getter
rules:
- apiGroups:
  - custom.metrics.k8s.io
  resources:
  - "*"
  verbs:
  - "*"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: hpa-custom-metrics-getter
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-metrics-getter
subjects:
- kind: ServiceAccount
  name: horizontal-pod-autoscaler
  namespace: kube-system
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-metrics-apiserver
  namespace: custom-metrics
  labels:
    app: custom-metrics-apiserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: custom-metrics-apiserver
  template:
    metadata:
      labels:
        app: custom-metrics-apiserver
    spec:
      tolerations:
      - key: beta.kubernetes.io/arch
        value: arm
        effect: NoSchedule
      - key: beta.kubernetes.io/arch
        value: arm64
        effect: NoSchedule
      serviceAccountName: custom-metrics-apiserver
      containers:
      - name: custom-metrics-server
        image: luxas/k8s-prometheus-adapter:v0.2.0-beta.0
        args:
        - --prometheus-url=http://prometheus-k8s.monitoring.svc:9090
        - --metrics-relist-interval=30s
        - --rate-interval=60s
        - --v=10
        - --logtostderr=true
        ports:
        - containerPort: 443
        securityContext:
          runAsUser: 0
---
apiVersion: v1
kind: Service
metadata:
  name: api
  namespace: custom-metrics
spec:
  ports:
  - port: 443
    targetPort: 443
  selector:
    app: custom-metrics-apiserver
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.custom.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: custom.metrics.k8s.io
  groupPriorityMinimum: 1000
  versionPriority: 5
  service:
    name: api
    namespace: custom-metrics
  version: v1beta1
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-metrics-server-resources
rules:
- apiGroups:
  - custom-metrics.metrics.k8s.io
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: hpa-controller-custom-metrics
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-metrics-server-resources
subjects:
- kind: ServiceAccount
  name: horizontal-pod-autoscaler
  namespace: kube-system

3.部署手压测应用与 HPA 模板

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: sample-metrics-app
  name: sample-metrics-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sample-metrics-app
  template:
    metadata:
      labels:
        app: sample-metrics-app
    spec:
      tolerations:
      - key: beta.kubernetes.io/arch
        value: arm
        effect: NoSchedule
      - key: beta.kubernetes.io/arch
        value: arm64
        effect: NoSchedule
      - key: node.alpha.kubernetes.io/unreachable
        operator: Exists
        effect: NoExecute
        tolerationSeconds: 0
      - key: node.alpha.kubernetes.io/notReady
        operator: Exists
        effect: NoExecute
        tolerationSeconds: 0
      containers:
      - image: luxas/autoscale-demo:v0.1.2
        name: sample-metrics-app
        ports:
        - name: web
          containerPort: 8080
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 3
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 3
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: sample-metrics-app
  labels:
    app: sample-metrics-app
spec:
  ports:
  - name: web
    port: 80
    targetPort: 8080
  selector:
    app: sample-metrics-app
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: sample-metrics-app
  labels:
    service-monitor: sample-metrics-app
spec:
  selector:
    matchLabels:
      app: sample-metrics-app
  endpoints:
  - port: web
---
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2beta1
metadata:
  name: sample-metrics-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-metrics-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Object
    object:
      target:
        kind: Service
        name: sample-metrics-app
      metricName: http_requests
      targetValue: 100
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: sample-metrics-app
  namespace: default
  annotations:
    traefik.frontend.rule.type: PathPrefixStrip
spec:
  rules:
  - http:
      paths:
      - path: /sample-app
        backend:
          serviceName: sample-metrics-app
          servicePort: 80

这个压测的应用暴露了一个 Prometheus 的接口。接口中的数据如下，其中 http_requests_total 这个指标就是我们接下来伸缩使用的自定义指标。

[root@iZwz99zrzfnfq8wllk0dvcZ manifests]# curl 172.16.1.160:8080/metrics
# HELP http_requests_total The amount of requests served by the server in total
# TYPE http_requests_total counter
http_requests_total 3955684

4.部署压测应用

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: load-generator 
  labels:
    app: load-generator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: load-generator
  template:
    metadata:
      labels:
        app: load-generator
    spec:
      containers:
      - name: load-generator
        image: busybox 
        command:
          - "sh"
          - "-c"
          - "while true; do wget -q -O- http://sample-metrics-app.default.svc.cluster.local; done"

5.查看 HPA 的状态与伸缩，稍等几分钟，Pod 已经伸缩成功了。

workspace kubectl get hpa
NAME                     REFERENCE                       TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
php-apache               Deployment/php-apache           0%/50%        1         10        1          21d
sample-metrics-app-hpa   Deployment/sample-metrics-app   538133m/100   2         10        10         15h

最后

这篇文章主要是给大家带来一个对于 autoscaling/v1 和 autoscaling/v2beta1 的感性认知和大体的操作方式，对于 autoscaling/v1 我们不做过多的赘述，对于希望使用支持 Custom Metrics 的 autoscaling/v2beta1 的开发者而言，也许会认为整体的操作流程过于复杂难以理解，我们会在下一篇文章中为大家详解 autoscaling/v2beta1 使用 Custom Metrics 的种种细节，帮助大家更深入地理解其中的原理与设计思路。

文章标签：
容器服务Kubernetes版
云解析DNS
弹性伸缩
可观测监控 Prometheus 版
性能测试
容器
Kubernetes
弹性计算
测试技术
Cloud Native
关键词：
容器服务Kubernetes版场景
云解析DNS实践
云解析DNS kubernetes
容器服务Kubernetes版hpa
容器服务Kubernetes版实践
相关实践学习
容器服务Serverless版ACK Serverless 快速入门：在线魔方应用部署和监控
通过本实验，您将了解到容器服务Serverless版ACK Serverless 的基本产品能力，即可以实现快速部署一个在线魔方应用，并借助阿里云容器服务成熟的产品生态，实现在线应用的企业级监控，提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程，本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术，这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时，本课程也会向您介绍可以采取的工具、方法和可操作步骤，以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后，您将能够： 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
阿里云云原生
目录
相关文章
弹性计算小冉
|
1月前
|
弹性计算 缓存 应用服务中间件
阿里云服务器2核2G99元和2核4G199元实例规格性能及适用场景解析
2024年阿里云推出了两款云服务器，2核2G3M带宽40G ESSD Entry盘价格只要99元1年，2核4G5M带宽80G ESSD Entry盘价格只要199元1年，这两款云服务器的活动截止日期为2026年3月31日，活动期间新购、续费同价。那么这两款云服务器怎么样呢？可以用来做什么？本文将对这两款云服务器进行深度解析，包括配置介绍、实例规格、使用场景以及购买建议，以供选择参考。
弹性计算小冉
234 2
阿里云服务器2核2G99元和2核4G199元实例规格性能及适用场景解析
弹性计算小冉
|
17天前
|
Oracle NoSQL 固态存储
阿里云服务器ESSD Entry云盘与ESSD云盘选择指南：性能与场景解析
在我们选择阿里云服务器的时候，有部分云服务器同时支持ESSD Entry云盘和ESSD云盘，选择不同的云盘，价格也有所差异，有的用户还不清楚他们之间的区别，因此不知道选择哪种更好更能满足自己场景的需求，本文为大家介绍一下阿里云服务器ESSD Entry云盘和ESSD云盘的区别及选择参考。
弹性计算小冉
167 2
阿里云服务器ESSD Entry云盘与ESSD云盘选择指南：性能与场景解析
扬流
|
18天前
|
存储 数据挖掘 OLAP
阿里云 EMR Serverless StarRocks OLAP 数据分析场景解析
阿里云 E-MapReduce Serverless StarRocks 版是阿里云提供的 Serverless StarRocks 全托管服务，提供高性能、全场景、极速统一的数据分析体验，具备开箱即用、弹性扩展、监控管理、慢 SQL 诊断分析等全生命周期能力。内核 100% 兼容 StarRocks，性能比传统 OLAP 引擎提升 3-5 倍，助力企业高效构建大数据应用。本篇文章对阿里云EMR Serverless StarRocks OLAP 数据分析场景进行解析、存算分离架构升级以及 Trino 兼容，无缝替换介绍。
扬流
18985 2
泥腿子架构师
|
24天前
|
Kubernetes 负载均衡 Cloud Native
Kubernetes经典理论与核心概念解析
Kubernetes经典理论与核心概念解析
泥腿子架构师
33 1
aliyun7689123603-22772
|
6天前
|
运维 Kubernetes Docker
容器化技术解析：Docker与Kubernetes的协同应用
7月更文挑战第20天
aliyun7689123603-22772
45 0
公众号:码到三十五
|
1月前
|
存储 缓存 监控
深入JVM：解析OOM的三大场景，原因及实战解决方案
深入JVM：解析OOM的三大场景，原因及实战解决方案
公众号:码到三十五
40 2
郑小健
|
16天前
|
缓存 图形学 UED
U3D开发技术深度解析：异步场景加载与资源管理优化策略
【7月更文第11天】在Unity3D（简称U3D）游戏开发中，优化场景加载与资源管理是提升用户体验的关键一环。通过实现高效的异步场景加载和智能的资源管理策略，我们能显著缩短玩家的等待时间，提升游戏流畅度。本文将详细介绍这两种技术的应用，并提供实用的代码示例。
郑小健
42 0
周周的奇妙编程
|
1月前
|
Kubernetes 网络协议 Cloud Native
Kubernetes网络问题排查分享两则(1)——calico特定场景下的网络性能问题
在对Kubernetes项目[kosmos](https://github.com/kosmos-io/kosmos)与Calico网络性能进行对比测试时，发现kosmos在跨集群容器网络的性能显著优于Calico的集群内网络（约6Gbit/s对比2.9Gbit/s）。物理机网络测试达到9.38Gbit/s，显示Calico有68%的性能损耗。问题定位到网卡的checksum/offload参数，尝试用`ethtool`调整后虽短暂提升，但随后恢复原状。转载自：https://mp.weixin.qq.com/s/XsQZCSqZAXJK46zqc7IpLw
周周的奇妙编程
115 2
weixin_836869520
|
29天前
|
Kubernetes 安全 测试技术
超大规模商用 K8s 场景下，阿里巴巴如何动态解决容器资源的按需分配问题？
超大规模商用 K8s 场景下，阿里巴巴如何动态解决容器资源的按需分配问题？
weixin_836869520
23 0
公众号:码到三十五
|
1月前
|
消息中间件 存储 运维
RocketMQ与Kafka深度对比：特性与适用场景解析
RocketMQ与Kafka深度对比：特性与适用场景解析
公众号:码到三十五
55 0

云原生

热门文章

最新文章

  • 1
    Docker 镜像加速器
  • 2
    Docker CE 镜像源站
  • 3
    Minikube - Kubernetes本地实验环境
  • 4
    微服务架构的理论基础 - 康威定律
  • 5
    微服务（Microservice）那点事
  • 6
    Docker的Windows容器初体验
  • 7
    3分钟，了解阿里云热门开发者工具 Cloud Toolkit
  • 8
    利用Zipkin对Spring Cloud应用进行服务追踪分析
  • 9
    容器镜像服务 Docker镜像的基本使用
  • 10
    网盘关闭不用怕：利用Docker和OSS轻松搭建ownCloud专属网盘
  • 1
    【Azure APIM】调用APIM的备份接口时候遇见InvalidParameters错误
    20
  • 2
    【AI 生图赢奖】用函数计算绘出「少年江湖」，与热播网剧梦幻联动
    35
  • 3
    云端智汇概述
    11
  • 4
    Sphinx
    22
  • 5
    在Python中，`functools`模块提供了一个非常有用的装饰器`lru_cache()`，它实现了最近最少使用（Least Recently Used, LRU）缓存策略。
    22
  • 6
    解决CPU与带宽高使用率问题：深入分析与应对策略
    32
  • 7
    来点干货：AI 求职季通义灵码实战经验分享局
    63
  • 8
    《我们一起进大厂》系列-Zookeeper基础
    29
  • 9
    开发者们，AI 原生应用架构专场 ·上海站来啦
    47
  • 10
    2024 中国开发者调查报告出炉：通义灵码是开发者最常用的 AI 编码辅助工具
    59

    • 相关产品

  • 容器服务Kubernetes版
    文档详情 产品详情

    • 相关课程

    更多
  • 第八届大学生创新创业大赛阿里命题IoT赛题解析
  • 云计算工程师解析与实战-网络专家篇（体验版）
  • 深入解析Docker容器化技术
  • Java面试疑难点解析 - 面试技巧及语言基础
  • Java面试疑难点解析 - Java Web开发
  • Java面试疑难点解析 - 系统架构及项目设计

    • 相关电子书

    更多
  • 神龙云服务器产品及技术深度解析
  • 弹性创造价值：基于ECS的最佳性价比实践解析
  • 公共云弹性计算最佳实践-省钱窍门一：弹性伸缩

    • 相关实验场景

    更多
  • 云原生场景自动化响应ECS系统事件
  • 在ACK Serverless中部署Stable Diffusion应用
  • 利用大模型大规模分发技术，实现AIGC在线应用秒级弹性
  • 使用ACK-Koordinator部署在离线混部应用
  • 使用ACK Serverless容器化部署大语言模型FastChat
  • 通过EDAS部署并访问应用

    • 推荐镜像

    更多
  • kubernetes
  • DNS
  • NTP
    • 下一篇
    通义千问API入门教程