模型服务网格:云原生下的模型服务管理

本文涉及的产品
Serverless 应用引擎 SAE,800核*时 1600GiB*时
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 模型服务网格:云原生下的模型服务管理

作者:王夕宁

模型服务网格(Model Service Mesh)是一种架构模式,用于在分布式环境中部署和管理机器学习模型服务。它提供了一个可扩展的、高性能的基础架构,用于将多个模型服务进行管理、部署和调度,以此更好地处理模型的部署、版本管理、路由和推理请求的负载均衡。


模型服务网格的核心思想是将模型部署为可伸缩的服务,并通过网格来管理和路由这些服务, 简化模型服务的管理和运维。它通过将模型服务抽象为可编排的、可伸缩的单元,使得模型的部署、扩展和版本控制变得更加容易。它还提供了一些核心功能,如负载均衡、自动伸缩、故障恢复等,以确保模型服务的高可用性和可靠性。


模型可以根据实际的推理请求负载进行自动缩放和负载均衡,从而实现高效的模型推理。模型服务网格还提供了一些高级功能,如流量分割、A/B 测试、灰度发布等,以便更好地控制和管理模型服务的流量,可以轻松切换和回滚不同的模型版本。它还支持动态路由,可以根据请求的属性,如模型类型、数据格式或其他元数据,将请求路由到适当的模型服务。


阿里云服务网格 ASM 已经提供了一个可扩展的、高性能的模型服务网格基础能力,用于将多个模型服务进行管理、部署和调度,以此更好地处理模型的部署、版本管理、路由和推理请求的负载均衡。通过使用模型服务网格,开发人员可以更轻松地部署、管理和扩展机器学习模型,同时提供高可用性、弹性和灵活性,以满足不同的业务需求。


01 使用模型服务网格进行多模型推理服务


模型服务网格基于 KServe ModelMesh 实现,针对大容量、高密度和频繁变化的模型用例进行了优化,可以智能地将模型加载到内存中或从内存中卸载,以在响应性和计算之间取得平衡。


模型服务网格提供了以下功能:


  • 缓存管理
  • Pod 作为分布式最近最少使用 (LRU) 缓存进行管理。
  • 根据使用频率和当前请求量,加载和卸载模型的副本。
  • 智能放置和加载
  • 模型放置通过 Pod 之间的缓存寿命和请求负载来平衡。
  • 使用队列来处理并发模型加载,并最大限度地减少对运行时流量的影响。
  • 弹性
  • 失败的模型加载会在不同的 Pod 中自动重试。
  • 操作简便性
  • 自动和无缝地处理滚动模型更新。


以下是部署模型示例,使用前提可以参考 [1]。


1.1 创建存储声明 PVC

在 ACK 集群中,使用如下 YAML 创建存储声明 my-models-pvc:


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-models-pvc
  namespace: modelmesh-serving
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: alibabacloud-cnfs-nas
  volumeMode: Filesystem


然后运行如下命令:


kubectl get pvc -n modelmesh-serving


将会得到如下类似的预期结果:


NAME STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
my-models-pvc    Bound    nas-379c32e1-c0ef-43f3-8277-9eb4606b53f8   1Gi        RWX            alibabacloud-cnfs-nas   2h


1.2 创建 Pod 来访问 PVC

为了使用新的 PVC,我们需要将其作为卷安装到 Kubernetes Pod。然后我们可以使用这个 pod 将模型文件上传到持久卷。


让我们部署一个pvc-access Pod,并要求 Kubernetes 控制器通过指定“my-models-pvc”来声明我们之前请求的 PVC:


kubectl apply  -n modelmesh-serving  -f - <<EOF
---
apiVersion: v1
kind: Pod
metadata:
  name: "pvc-access"
spec:
  containers:
    - name: main
      image: ubuntu
      command: ["/bin/sh", "-ec", "sleep 10000"]
      volumeMounts:
        - name: "my-pvc"
          mountPath: "/mnt/models"
  volumes:
    - name: "my-pvc"
      persistentVolumeClaim:
        claimName: "my-models-pvc"
EOF


确认 pvc-access Pod 应该正在运行:


kubectl get pods -n modelmesh-serving | grep pvc-access


将会得到如下类似的预期结果:


pvc-access 1/1     Running


1.3 将模型存储在持久卷上

现在,我们需要将我们的 AI 模型添加到存储卷中,我们将使用 scikit-learn 训练的 MNIST 手写数字字符识别模型。可以从 kserve/modelmesh-minio-examples 仓库[2]下载 mnist-svm.joblib 模型文件的副本。


通过以下命令,将 mnist-svm.joblib 模型文件复制到 pvc-access pod 上的 /mnt/models 文件夹中:


kubectl -n modelmesh-serving cp mnist-svm.joblib pvc-access:/mnt/models/


执行如下命令,确认 model 已经加载成功:


kubectl -n modelmesh-serving exec -it pvc-access -- ls -alr /mnt/models/


应该得到如下内容:


-rw-r--r-- 1 501 staff 344817 Oct 30 11:23 mnist-svm.joblib


1.4 部署推理服务

接下来,我们需要部署一个 sklearn-mnist 推理服务:


apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-mnist
  namespace: modelmesh-serving
  annotations:
    serving.kserve.io/deploymentMode: ModelMesh
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storage:
        parameters:
          type: pvc
          name: my-models-pvc
        path: mnist-svm.joblib


几十秒钟后(取决于镜像拉取速度),新的推理服务 sklearn-mnist 应该准备就绪。


运行如下命令:


kubectl get isvc -n modelmesh-serving


将会得到如下类似的预期结果:


NAME URL                  READY
sklearn-mnist   grpc://modelmesh-serving.modelmesh-serving:8033   True


1.5 运行推理服务

现在我们可以使用 curl 发送推理请求到我们的 sklearn-mnist 模型。数组形式的请求数据表示待分类的数字图像扫描中 64 个像素的灰度值。


MODEL_NAME="sklearn-mnist"
ASM_GW_IP="ASM网关IP地址"
curl -X POST -k "http://${ASM_GW_IP}:8008/v2/models/${MODEL_NAME}/infer" -d '{"inputs": [{"name": "predict", "shape": [1, 64], "datatype": "FP32", "contents": {"fp32_contents": [0.0, 0.0, 1.0, 11.0, 14.0, 15.0, 3.0, 0.0, 0.0, 1.0, 13.0, 16.0, 12.0, 16.0, 8.0, 0.0, 0.0, 8.0, 16.0, 4.0, 6.0, 16.0, 5.0, 0.0, 0.0, 5.0, 15.0, 11.0, 13.0, 14.0, 0.0, 0.0, 0.0, 0.0, 2.0, 12.0, 16.0, 13.0, 0.0, 0.0, 0.0, 0.0, 0.0, 13.0, 16.0, 16.0, 6.0, 0.0, 0.0, 0.0, 0.0, 16.0, 16.0, 16.0, 7.0, 0.0, 0.0, 0.0, 0.0, 11.0, 13.0, 12.0, 1.0, 0.0]}}]}'


JSON 响应应如下所示,推断扫描的数字是“8”:


{
"modelName": "sklearn-mnist__isvc-3c10c62d34",
 "outputs": [
  {
   "name": "predict",
   "datatype": "INT64",
   "shape": [
    "1",
    "1"
   ],
   "contents": {
    "int64Contents": [
     "8"
    ]
   }
  }
 ]
}


02 使用模型服务网格自定义模型运行时


模型服务网格(Model Service Mesh,简称为 ModelMesh) 针对大容量、高密度和频繁变化的模型推理服务的部署运行进行了优化,可以智能地将模型加载到内存中或从内存中卸载,以在响应性和计算之间取得最佳的平衡。


ModelMesh 默认集成了以下模型服务器运行环境,例如:


  • Triton Inference Server,NVIDIA 的服务器,适用于 TensorFlow、PyTorch、TensorRT 或 ONNX 等框架。
  • MLServer,Seldon 的基于 Python 的服务器,适用于 SKLearn、XGBoost 或 LightGBM 等框架。
  • OpenVINO Model Server,英特尔用于英特尔 OpenVINO 或 ONNX 等框架的服务器。
  • TorchServe,支持包含 eager 模式的 PyTorch 模型。


如果这些模型服务器无法满足您的特定要求时,譬如需要处理推理的自定义逻辑,或者您的模型所需的框架还不在上述支持列表中,您可以自定义服务运行时来进行扩展支撑。


具体可以参考 [3]。


03 为大语言模型 LLM 提供服务


大语言模型 LLM(Large Language Model)指参数数量达到亿级别的神经网络语言模型,例如:GPT-3、GPT-4、PaLM、PaLM2 等。以下介绍如何为大语言模型 LLM 提供服务。


使用前提可以具体参考 [4]。

3.1 构建自定义运行时

构建自定义运行时,提供带有提示调整配置的 HuggingFace LLM。此示例中的默认值设置为我们预先构建的自定义运行时镜像和预先构建的提示调整配置。


3.1.1 实现一个继承自 MLServer MLModel 的类

kfp-tekton/samples/peft-modelmesh-pipeline 目录[5]中的 peft_model_server.py 文件包含了如何提供带有提示调整配置的 HuggingFace LLM 的所有代码。


下面的 _load_model 函数显示我们将选择已训练的 PEFT 提示调整配置的预训练 LLM 模型。分词器也作为模型的一部分进行定义,因此可以用于对推理请求中的原始字符串输入进行编码和解码,而无需要求用户预处理其输入为张量字节。


from typing import List
from mlserver import MLModel, types
from mlserver.codecs import decode_args
from peft import PeftModel, PeftConfig
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
import os
class PeftModelServer(MLModel):
    async def load(self) -> bool:
        self._load_model()
        self.ready = True
        return self.ready
    @decode_args
    async def predict(self, content: List[str]) -> List[str]:
        return self._predict_outputs(content)
    def _load_model(self):
        model_name_or_path = os.environ.get("PRETRAINED_MODEL_PATH", "bigscience/bloomz-560m")
        peft_model_id = os.environ.get("PEFT_MODEL_ID", "aipipeline/bloomz-560m_PROMPT_TUNING_CAUSAL_LM")
        self.tokenizer = AutoTokenizer.from_pretrained(model_name_or_path, local_files_only=True)
        config = PeftConfig.from_pretrained(peft_model_id)
        self.model = AutoModelForCausalLM.from_pretrained(config.base_model_name_or_path)
        self.model = PeftModel.from_pretrained(self.model, peft_model_id)
        self.text_column = os.environ.get("DATASET_TEXT_COLUMN_NAME", "Tweet text")
        return
    def _predict_outputs(self, content: List[str]) -> List[str]:
        output_list = []
        for input in content:
            inputs = self.tokenizer(
                f'{self.text_column} : {input} Label : ',
                return_tensors="pt",
            )
            with torch.no_grad():
                inputs = {k: v for k, v in inputs.items()}
                outputs = self.model.generate(
                    input_ids=inputs["input_ids"], attention_mask=inputs["attention_mask"], max_new_tokens=10, eos_token_id=3
                )
                outputs = self.tokenizer.batch_decode(outputs.detach().cpu().numpy(), skip_special_tokens=True)
            output_list.append(outputs[0])
        return output_list


3.1.2 构建 Docker 镜像

实现了模型类之后,我们需要将其依赖项(包括 MLServer)打包到一个支持 ServingRuntime 资源的镜像中。参考如下 Dockerfile 进行镜像构建。


# TODO: choose appropriate base image, install Python, MLServer, and
# dependencies of your MLModel implementation
FROM python:3.8-slim-buster
RUN pip install mlserver peft transformers datasets
# ...
# The custom `MLModel` implementation should be on the Python search path
# instead of relying on the working directory of the image. If using a
# single-file module, this can be accomplished with:
COPY --chown=${USER} ./peft_model_server.py /opt/peft_model_server.py
ENV PYTHONPATH=/opt/
# environment variables to be compatible with ModelMesh Serving
# these can also be set in the ServingRuntime, but this is recommended for
# consistency when building and testing
ENV MLSERVER_MODELS_DIR=/models/_mlserver_models \
 MLSERVER_GRPC_PORT=8001 \
    MLSERVER_HTTP_PORT=8002 \
    MLSERVER_LOAD_MODELS_AT_STARTUP=false \
    MLSERVER_MODEL_NAME=peft-model
# With this setting, the implementation field is not required in the model
# settings which eases integration by allowing the built-in adapter to generate
# a basic model settings file
ENV MLSERVER_MODEL_IMPLEMENTATION=peft_model_server.PeftModelServer
CMD mlserver start ${MLSERVER_MODELS_DIR}


3.1.3 创建新的 ServingRuntime 资源

可以使用以下代码块中的 YAML 模板创建一个新的 ServingRuntime 资源,并将其指向您刚创建的镜像。


apiVersion: serving.kserve.io/v1alpha1
kind: ServingRuntime
metadata:
 name: peft-model-server
  namespace: modelmesh-serving
spec:
  supportedModelFormats:
    - name: peft-model
      version: "1"
      autoSelect: true
  multiModel: true
  grpcDataEndpoint: port:8001
  grpcEndpoint: port:8085
  containers:
    - name: mlserver
      image:  registry.cn-beijing.aliyuncs.com/test/peft-model-server:latest
      env:
        - name: MLSERVER_MODELS_DIR
          value: "/models/_mlserver_models/"
        - name: MLSERVER_GRPC_PORT
          value: "8001"
        - name: MLSERVER_HTTP_PORT
          value: "8002"
        - name: MLSERVER_LOAD_MODELS_AT_STARTUP
          value: "true"
        - name: MLSERVER_MODEL_NAME
          value: peft-model
        - name: MLSERVER_HOST
          value: "127.0.0.1"
        - name: MLSERVER_GRPC_MAX_MESSAGE_LENGTH
          value: "-1"
        - name: PRETRAINED_MODEL_PATH
          value: "bigscience/bloomz-560m"
        - name: PEFT_MODEL_ID
          value: "aipipeline/bloomz-560m_PROMPT_TUNING_CAUSAL_LM"
        # - name: "TRANSFORMERS_OFFLINE"
        #   value: "1" 
        # - name: "HF_DATASETS_OFFLINE"
        #   value: "1"   
      resources:
        requests:
          cpu: 500m
          memory: 4Gi
        limits:
          cpu: "5"
          memory: 5Gi
  builtInAdapter:
    serverType: mlserver
    runtimeManagementPort: 8001
    memBufferBytes: 134217728
    modelLoadingTimeoutMillis: 90000


然后使用 kubectl apply 命令创建 ServingRuntime 资源,您将在 ModelMesh 部署中看到您的新自定义运行时。


3.2 部署 LLM 服务

为了使用您新创建的运行时部署模型,您需要创建一个 InferenceService 资源来提供模型服务。该资源是 KServe 和 ModelMesh 用于管理模型的主要接口,代表了模型在推理中的逻辑端点。


apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: peft-demo
  namespace: modelmesh-serving
  annotations:
    serving.kserve.io/deploymentMode: ModelMesh
spec:
  predictor:
    model:
      modelFormat:
        name: peft-model
      runtime: peft-model-server
      storage:
        key: localMinIO
        path: sklearn/mnist-svm.joblib


在前面的代码块中,InferenceService 命名为 peft-demo,并声明其模型格式为 peft-model,与之前创建的示例自定义运行时使用相同的格式。还传递了一个可选字段 runtime,明确告诉 ModelMesh 使用 peft-model-server运行时来部署此模型。


3.3 运行推理服务

现在我们可以使用 curl 发送推理请求到我们上面部署的 LLM 模型服务。


MODEL_NAME="peft-demo"
ASM_GW_IP="ASM网关IP地址"
curl -X POST -k http://${ASM_GW_IP}:8008/v2/models/${MODEL_NAME}/infer -d @./input.json


其中 input.json 表示请求数据:


{
 "inputs": [
        {
          "name": "content",
          "shape": [1],
          "datatype": "BYTES",
          "contents": {"bytes_contents": ["RXZlcnkgZGF5IGlzIGEgbmV3IGJpbm5pbmcsIGZpbGxlZCB3aXRoIG9wdGlvbnBpZW5pbmcgYW5kIGhvcGU="]}
        }
    ]
}


bytes_contents 对应的是字符串“Every day is a new beginning, filled with opportunities and hope”的 base64 编码。


JSON 响应应如下所示,推断扫描的数字是“8”:


{
"modelName": "peft-demo__isvc-5c5315c302",
 "outputs": [
  {
   "name": "output-0",
   "datatype": "BYTES",
   "shape": [
    "1",
    "1"
   ],
   "parameters": {
    "content_type": {
     "stringParam": "str"
    }
   },
   "contents": {
    "bytesContents": [
     "VHdlZXQgdGV4dCA6IEV2ZXJ5IGRheSBpcyBhIG5ldyBiaW5uaW5nLCBmaWxsZWQgd2l0aCBvcHRpb25waWVuaW5nIGFuZCBob3BlIExhYmVsIDogbm8gY29tcGxhaW50"
    ]
   }
  }
 ]
}


其中 bytesContents 进行 base64 解码后的内容为:


Tweet text : Every day is a new binning, filled with optionpiening and hope Label : no complaint


至此,说明上述大语言模型 LLM 的模型服务请求得到了预期的结果。


04 总结


阿里云服务网格 ASM 已经提供了一个可扩展的、高性能的模型服务网格基础能力,用于将多个模型服务进行管理、部署和调度,以此更好地处理模型的部署、版本管理、路由和推理请求的负载均衡。


欢迎试用:https://www.aliyun.com/product/servicemesh

欢迎使用钉钉扫描以下二维码或搜索钉钉群号加入我们。群号:30421250



相关链接:

[1] 以下是部署模型示例,使用前提可以参考

https://help.aliyun.com/zh/asm/user-guide/multi-model-inference-service-using-model-service-mesh?spm=a2c4g.11186623.0.0.7c4e6561k1qyJV#213af6d078xu7

[2] kserve/modelmesh-minio-examples 仓库

https://github.com/kserve/modelmesh-minio-examples/blob/main/sklearn/mnist-svm.joblib

[3]具体可以参考

https://help.aliyun.com/zh/asm/user-guide/customizing-the-model-runtime-using-the-model-service-mesh?spm=a2c4g.11186623.0.0.1db77614Vw96Eu

[4] 使用前提可以具体参考

https://help.aliyun.com/zh/asm/user-guide/services-for-the-large-language-model-llm?spm=a2c4g.11186623.0.0.29777614EEBYWt#436fc73079euz

[5] kfp-tekton/samples/peft-modelmesh-pipeline 目录

https://github.com/kubeflow/kfp-tekton


点击此处,直达 ASM 产品详情页。

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
1月前
|
运维 Kubernetes 安全
利用服务网格实现全链路mTLS(一):在入口网关上提供mTLS服务
阿里云服务网格(Service Mesh,简称ASM)提供了一个全托管式的服务网格平台,兼容Istio开源服务网格,用于简化服务治理,包括流量管理和拆分、安全认证及网格可观测性,有效减轻开发运维负担。ASM支持通过mTLS提供服务,要求客户端提供证书以增强安全性。本文介绍如何在ASM入口网关上配置mTLS服务并通过授权策略实现特定用户的访问限制。首先需部署ASM实例和ACK集群,并开启sidecar自动注入。接着,在集群中部署入口网关和httpbin应用,并生成mTLS通信所需的根证书、服务器证书及客户端证书。最后,配置网关上的mTLS监听并设置授权策略,以限制特定客户端对特定路径的访问。
105 2
|
2月前
|
机器学习/深度学习 Kubernetes Cloud Native
云原生技术演进之旅:从容器到服务网格
在云计算的浪潮中,云原生技术以其独特的灵活性和可扩展性引领了新的技术革命。本文将深入探讨云原生技术的发展脉络,从容器技术的突破,到Kubernetes的集群管理,再到服务网格的微服务通信解决方案,揭示云原生如何不断适应和塑造现代应用的需求。文章将通过数据支撑和案例分析,展示云原生技术在实际应用中的优势和挑战,并预测其未来的发展趋势。
41 1
|
1月前
|
Prometheus Kubernetes 监控
打造无缝灾备新境界:运用服务网格ASM,将集群外服务无缝融入集群内服务,铸就高可用性坚盾!
【8月更文挑战第2天】随着微服务架构的应用,服务的高可用性变得至关重要。服务网格如阿里巴巴的ASM提供流量管理、服务发现等功能,支撑高可靠服务系统。本文介绍如何利用ASM实现集群外服务作为集群内服务的灾备方案,确保服务连续性。先决条件包括已部署ASM的Kubernetes集群环境及内外部的关键服务副本。通过定义服务条目、配置虚拟服务和目的地规则,可实现自动或手动故障转移。借助ASM的流量管理能力,确保服务高可用性和业务连续性。
37 10
|
1月前
|
Kubernetes 安全 数据安全/隐私保护
利用服务网格实现全链路mTLS(二):通过出口网关访问外部mTLS服务
阿里云服务网格(Service Mesh,简称ASM)提供了一个全托管式的服务网格平台,兼容Istio开源服务网格,简化服务治理,包括流量管理、服务间通信安全及网格可观测性。ASM出口网关统一管理网格内的出口流量,实现全链路加密通信与精细访问控制。本文介绍如何配置ASM出口网关以管理出口流量并发起mTLS通信,涉及配置ServiceEntry、创建出口网关、设置虚拟服务及目标规则等步骤,最终实现安全可控的mTLS服务访问。
111 3
|
1月前
|
Perl
如何利用服务网格ASM使用集群外服务做集群内服务的灾备
本文档指导您如何配置阿里云服务网格(ASM)以实现在多集群环境下,服务间的优先访问及故障转移策略。
92 2
|
2月前
|
Cloud Native Devops 数据库
云原生架构:未来软件开发的引擎深入理解操作系统的虚拟内存管理
【7月更文挑战第30天】在这篇文章中,我们将深入探讨云原生架构的概念,以及它如何改变软件开发的世界。我们将从云原生的基本概念开始,然后深入到它的关键技术和实践,最后讨论它对软件开发的未来影响。无论你是软件开发者,还是IT专业人士,这篇文章都将为你提供深入理解和掌握云原生架构的重要信息。 【7月更文挑战第30天】在数字世界的构建中,虚拟内存是操作系统不可或缺的一环。本文将探索虚拟内存的核心概念、工作机制及其对现代计算环境的重要性,同时揭示其背后的技术细节和面临的挑战。
24 3
|
2月前
|
敏捷开发 运维 Cloud Native
云原生架构的演进之路:从容器化到服务网格
在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT架构的新宠。本文将探讨云原生技术的演进路径,特别是容器化技术和服务网格的发展,以及它们如何共同推动现代应用的开发和部署。通过分析实际案例,我们揭示了云原生技术如何助力企业实现敏捷开发和高效运维,同时指出了未来云原生技术的发展趋势。
|
27天前
|
Cloud Native 安全 云计算
云原生技术的未来:探索服务网格和无服务器架构
随着企业数字化转型的深入,云计算已成为推动业务创新的核心力量。本文将深入探讨云原生技术的最新发展趋势,重点分析服务网格和无服务器架构如何重塑云计算的未来。通过实际案例和技术解析,揭示这些前沿技术如何解决现代应用部署的复杂性,提高系统的可伸缩性和弹性。文章旨在为读者提供云原生领域的深度见解,并激发对云技术未来发展的思考。
60 0
|
28天前
|
运维 Kubernetes Cloud Native
Kubernetes云原生问题之在托管Kubernetes服务中云服务商和用户的运维责任划分如何解决
Kubernetes云原生问题之在托管Kubernetes服务中云服务商和用户的运维责任划分如何解决
31 0
|
29天前
|
运维 Kubernetes Cloud Native
云原生技术演进:从容器到服务网格
【8月更文挑战第14天】云原生技术的迅速发展,不仅重塑了软件开发与部署的流程,也重新定义了企业IT架构的未来。本文将深入探讨容器技术的兴起、Kubernetes成为事实上的工业标准,以及服务网格的出现如何进一步优化微服务间的通信。通过分析这些技术的发展脉络,我们将揭示它们是如何共同促进现代云原生生态系统的成熟和扩展,同时指出这些技术面临的挑战和未来的发展方向。

相关产品

  • 服务网格