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

边车容器下的服务网格istio

2018-02-08 3646
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
容器镜像服务 ACR，镜像仓库100个 不限时长
简介：

Istio是一个用于连接、管理以及安全化微服务的开放平台, 提供了一种简单的方式用于创建微服务网络,并提供负载均衡/服务间认证/监控等能力,关键的是并不需要修改服务本身. 主要提供以下功能:

  • Traffic Management: 控制服务之间调用的流量和API调用;
  • Observability: 获取服务之间的依赖,以及服务调用的流量走向;
  • Policy Enforcement: 控制服务的访问策略,不需要改动服务本身;
  • Service Identity and Security: 服务身份与安全相关的功能;

架构

Istio从架构上看,主要分为2个部分,即:

  • 控制面板: 管理代理,用于支持流量路由/运行时执行策略等;
  • 数据面板: 由一系列的智能代理(Envoy)构成,用于仲裁和控制服务之间的网络交互;
    istio_arch

智能代理Envoy

Envoy 是一个面向服务架构的L7代理和通信总线而设计的，这个项目诞生是出于以下目标：

对于应用程序而言，网络应该是透明的，当发生网络和应用程序故障时，能够很容易定位出问题的根源。

Envoy 试图通过提供以下高级特性：

  • 外置进程架构：Envoy是一个独立的进程，与应用程序一起运行。
  • 跨语言: Envoy可以与任何语言开发的应用一起工作。
  • 基于新C++11编码
  • L3/L4过滤器：Envoy其核心是一个L3/L4网络代理，能够作为一个可编程过滤器实现不同TCP代理任务，插入到主服务当中。
  • HTTP L7过滤器：在现代应用架构中，HTTP是非常关键的部件，Envoy支持一个额外的HTTP L7过滤层。HTTP过滤器作为一个插件，插入到HTTP链接管理子系统中，从而执行不同的任务，如缓冲，速率限制，路由/转发，嗅探Amazon的DynamoDB等等。
  • 支持HTTP/2
  • HTTP L7路由：在HTTP模式下运行时，Envoy支持根据content type、runtime values等，基于path的路由和重定向。当服务构建到服务网格时，Envoy为前端/边缘代理，这个功能是非常有用的。
  • 支持gRPC：gRPC是一个来自谷歌的RPC框架，使用HTTP/2作为底层的多路传输。HTTP/2承载的gRPC请求和应答，都可以使用Envoy的路由和LB能力。所以两个系统非常互补。
  • 支持MongoDB L7
  • 支持DynamoDB L7：
  • 服务发现：服务发现是面向服务体系架构的重要组成部分。Envoy支持多种服务发现方法，包括异步DNS解析和通过REST调用服务发现(Service discovery)服务。
  • 健康检查：构建Envoy网格的推荐方法，是将服务发现视为一个最终一致的方法。Envoy含有一个健康检查子系统，它可以对上游服务集群进行主动的健康检查。然后，Envoy联合服务发现、健康检查信息来判定健康的LB对象。Envoy作为一个外置健康检查子系统，也支持被动健康检查。
  • 高级LB：在分布式系统中，不同组件之间LB也是一个复杂的问题。Envoy是一个独立的代理进程，不是一个lib库，所以他能够在一个地方实现高级LB，并且能够被任何应用程序访问。目前，包括自动重试、断路器，全局限速，阻隔请求，异常检测。将来还会支持按计划进行请求速率控制。
  • 前端代理：虽然Envoy作为服务间的通信系统而设计，但是（调试，管理、服务发现、LB算法等）同样可以适用于前端，Envoy提供足够的特性，能够作为绝大多数Web应用的前端代理，包括TLS、HTTP/1.1、HTTP/2，以及HTTP L7路由。
  • 极好的可观察性：如上所述，Envoy目标是使得网络更加透明。而然，无论是网络层还是应用层，都可能会出现问题。Envoy包括对所有子系统，提供了可靠的统计能力。目前只支持statsd以及兼容的统计库，虽然支持另一种并不复杂。还可以通过管理端口查看统计信息，Envoy还支持第三方的分布式跟踪机制。
  • 动态配置：Envoy提供分层的动态配置API，用户可以使用这些API构建复杂的集中管理部署。

Envoy将作为一个独立的sidecar与相关微服务部署在同一个Kubernetes的pod上,并提供一系列的属性给Mixer。Mixer以此作为依据执行策略,并发送到监控系统.

这种sidecar代理模型不需要改变任何服务本身的逻辑,并能增加一系列的功能.

Mixer

Mixer负责在服务网格上执行访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据。代理提取请求级属性，发送到Mixer进行评估。Mixer包括一个灵活的插件模型，使其能够接入到各种主机环境和基础设施后端，从这些细节中抽象出Envoy代理和Istio管理的服务。

后端的基础设施常常被设计用于提供建立服务支持的功能，包括访问控制系统、遥测数据捕获系统、配额执行系统以及计费系统等。传统服务会直接和这些后端系统打交道，和后端紧密耦合，并集成其中的个性化语义以及用法。

Mixer在应用程序代码和基础架构后端之间提供通用中介层。它的设计将策略执行部分移出应用层，而是用运维人员能够控制的配置取而代之。应用程序代码不再将应用程序代码与特定后端集成在一起，而是与Mixer进行相当简单的集成，然后Mixer负责与后端系统连接。

Mixer的设计目的是改变层次之间的边界，以此来降低总体的复杂性。从服务代码中剔除策略逻辑，改由运维人员进行控制。

Mixer架构

istio_mixer_architecture

Mixer 提供三个核心功能：

  • 前提条件检查 允许服务在响应来自服务消费者的传入请求之前验证一些前提条件。前提条件可以包括服务使用者是否被正确认证，是否在服务的白名单上，是否通过ACL检查等等。
  • 配额管理 使服务能够在分配和释放多个维度上的配额，配额这一简单的资源管理工具可以在服务消费者对有限资源发生争用时，提供相对公平的竞争手段。限流控制就是配额的一个实例。
  • 遥测报告 使服务能够上报日志和监控，以及还将启用针对服务生产者以及服务消费者的跟踪和计费流。

这些机制的应用是基于一组 属性 的，每个请求都会将这些属性呈现给Mixer。在Istio中，这些属性来自于Sidecar代理（Envoy）的每一次请求。

Istio使用 属性 来控制在服务网格中运行的服务的运行时行为。属性是具有名称和类型的元数据片段，用以描述入口和出口流量，以及这些流量所属的环境。Istio属性携带特定信息片段，例如API请求的错误代码，API请求的延迟或TCP连接的原始IP地址. 例如：

  request.path: xyz/abc
  request.size: 234
  request.time: 12:34:56.789 04/17/2017
  source.ip: 192.168.0.1
  target.service: example

基于适配器与模板的配置

mixer_architecture

Mixer是一种属性处理引擎，请求到达Mixer时带有一组属性 ，并且基于这些属性，Mixer会生成对各种基础设施后端的调用。该属性集确定Mixer为给定的请求用哪些参数调用哪个后端。为了隐藏各个后端的细节，Mixer使用称为适配器的模块。

Mixer的配置有几个中心职责：

  • 描述哪些适配器正在使用以及它们的操作方式。
  • 描述如何将请求属性映射到适配器参数中。
  • 描述使用特定参数调用适配器的时机。

配置基于适配器和模板来完成：

  • 适配器 封装了Mixer和特定基础设施后端之间的接口。
  • 模板 定义了从特定请求的属性到适配器输入的映射关系。一个适配器可以支持任意数量的模板。

配置使用YAML格式来表示,围绕几个核心抽象构建：

  • Handler：Handlers就是一个配置完成的适配器。适配器的构造器参数就是Handler的配置。
  • 实例：一个（请求）实例就是请求属性到一个模板的映射结果。这种映射来自于实例的配置。
  • 规则：规则确定了何时使用一个特定的模板配置来调用一个Handler。

Handler

适配器封装了Mixer和特定外部基础设施后端进行交互的必要接口，例如Prometheus、New Relic或者Stackdriver。各种适配器都需要参数配置才能工作。例如日志适配器可能需要IP地址和端口来进行日志的输出。

这里的例子配置了一个类型为 listchecker 的适配器。listchecker适配器使用一个列表来检查输入。如果配置的是白名单模式且输入值存在于列表之中，就会返回成功的结果。

apiVersion: config.istio.io/v1alpha2
kind: listchecker
metadata:
  name: staticversion
  namespace: istio-system
spec:
  providerUrl: http://white_list_registry/
  blacklist: false

{metadata.name}.{kind}.{metadata.namespace} 是Handler的完全限定名

实例

配置实例将请求中的属性映射成为适配器的输入, 注意Handler配置中需要的所有维度都定义在这一映射之中。

apiVersion: config.istio.io/v1alpha2
kind: metric
metadata:
  name: requestduration
  namespace: istio-system
spec:
  value: response.duration | "0ms"
  dimensions:
    destination_service: destination.service | "unknown"
    destination_version: destination.labels["version"] | "unknown"
    response_code: response.code | 200
  monitored_resource_type: '"UNSPECIFIED"'

规则

规则用于指定使用特定实例配置调用某一Handler的时机。比如我们想要把 service1 服务中，请求头中带有 x-user 的请求的 requestduration 指标发送给Prometheus Handler:

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: promhttp
  namespace: istio-system
spec:
  match: destination.service == "service1.ns.svc.cluster.local" && request.headers["xuser"] == "user1"
  actions:
  - handler: handler.prometheus
    instances:
    - requestduration.metric.istio-system

operator_template_adapter_dev

Pilot (原Istio-Manager)

Pilot负责收集和验证配置并将其传播到各种Istio组件。它从Mixer和Envoy中抽取环境特定的实现细节，为他们提供用户服务的抽象表示，独立于底层平台。此外，流量管理规则（即通用4层规则和7层HTTP/gRPC路由规则）可以在运行时通过Pilot进行编程。

  • 用户与Istio之间的接口, 收集并验证配置信息并发送给其他组件.作为流量管理的核心组件, Pilot管理所有配置的Envoy代理实例,并提供如下流量管理方式:
    TrafficManagementOverview_2
  • Pilot提供了一个用于适配底层集群管理平台的抽象层，如Kubernetes适配层。
    ManagerAdapters
  • 此外还提供了一个代理控制器，用于Istio代理的动态配置。
    istio_pilot_architecture

Service Model服务模型

服务Service本身并不是Istio特有或新提出的概念，例如K8s早已经提供了类似的service概念和能力。但在Istio中为了支持更细粒度的路由能力，针对服务模型提供了版本的机制，例如可以通过附加label的方式描述版本等。
作为一个逻辑抽象，每一个服务通常会有FQDN全域名及若干个端口，或者也可能会有一个单独的负载均衡器、虚拟IP地址与之对应。

例如，k8s中，一个服务foo就会有一个域名foo.default.svc.cluster.local hostname，虚拟IP10.0.1.1以及可能的监听端口。

一个服务往往会对应多个实例，每一个实例可以是一个container,pod或者vm. 每一个实例都有一个网络端点以及暴露的监听端口。
Istio本身不会提供服务注册以及发现的能力，而是依赖于底层平台提供的现成能力来完成服务注册发现。另外，istio也不会提供DNS能力，也是通过底层平台提供的dns能力（如kube-dns)解析域名。

基于规则的路由能力则是由Istio proxy sidecar 进程来实现，如envoy, nginx等。这些代理通常会同时提供4层与7层的路由能力。这些规则定义可以基于label，或者权重，亦或是基于http header、url等。

Configuration Model配置模型

Istio的规则配置提供了一个基于pb的模式定义。这些规则内容存储在一个KVstore中，pilot订阅了这些配置信息的变化，以便更新istio其他组件的配置内容。

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  route:
  - labels:
    version: v1
    weight: 100

代理控制器

显然，代理控制器是pilot的核心模块，用于控制管理istio中的proxy。当前istio采用了envoy作为proxy，因为istio提供了一套标准的抽象api来对接proxy，所以将来用户可以自定制proxy，不见得必须采用envoy。
针对envoy，istio当前提供了2个组件：

  • proxy agent 一套用于从抽象服务模型和规则配置生成envoy配置信息的脚本命令，同时也会触发proxy的重启；
  • discovery service 实现了envoy的服务发现API，从而可以发布信息到envoy代理；
GET /v1/registration/(string: service_name)

请求发现服务返回指定service_name的所有主机, 返回以下JSON格式的响应：
{
  "hosts": []
}

const std::string Json::Schema::SDS_SCHEMA(R"EOF(
  {
    "$schema": "http://json-schema.org/schema#",
    "definitions" : {
      "host" : {
        "type" : "object",
        "properties" : {
          "ip_address" : {"type" : "string"},
          "port" : {"type" : "integer"},
          "tags" : {
            "type" : "object",
            "properties" : {
              "az" : {"type" : "string"},
              "canary" : {"type" : "boolean"},
              "load_balancing_weight": {
                "type" : "integer",
                "minimum" : 1,
                "maximum" : 100
              }
            }
          }
        },
        "required" : ["ip_address", "port"]
      }
    },
    "type" : "object",
    "properties" : {
      "hosts" : {
        "type" : "array",
        "items" : {"$ref" : "#/definitions/host"}
      }
    },
    "required" : ["hosts"]
  }
  )EOF");

这儿不得不提的是pilot的 proxy injection 能力，你可能已经想到了它是基于iptable规则来实现的。这样所有的服务交互都会被pilot捕获并重新转发。

Istio-Auth

提供服务间以及用户之间的认证,确保不需要修改服务code的前提下增强服务之间的安全性. 主要包括以下3个组件:

  • 身份识别
    • 当Istio运行在Kubernetes时,Auth会使用Kubernetes提供的服务账号来识别运行服务的主体是谁.
  • key管理
    • Auth提供了一个CA自动化生成和管理key和证书.
  • 通讯安全
    • 服务间的通讯通过Envoy在客户端和服务端提供tunnel来保证服务调用的安全.

分布式跟踪

Istio的分布式跟踪是基于Twitter开源的[zipkin]分布式跟踪系统,理论模型来自于Google Dapper 论文.

启动zipkin

安装Istio时会启动zipkin addon,当然也可以使用如下命令启动:

kubectl apply -f install/kubernetes/addons/zipkin.yaml

访问zipkin

访问zipkin dashboard: http://localhost:9411

kubectl port-forward $(kubectl get pod -l app=zipkin -o jsonpath='{.items[0].metadata.name}') 9411:9411

在服务中enable trace

服务本身实现需要做一定的改动,即从最初始的HTTP请求中获取以下header并传递给其他的请求:

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

启用Ingress

在Kubernetes环境下, Istio使用了内置的Ingress来暴露服务,目前支持HTTP和HTTPS两种方式. 具体的Ingress,参见[Kubernetes Ingress]

配置HTTP服务

cat <<EOF | kubectl create -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: simple-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
  - http:
      paths:
      - path: /headers
        backend:
          serviceName: httpbin
          servicePort: 8000
      - path: /delay/.*
        backend:
          serviceName: httpbin
          servicePort: 8000
EOF

配置HTTPS服务

cat <<EOF | kubectl create -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: secured-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  tls:
    - secretName: ingress-secret
  rules:
  - http:
      paths:
      - path: /ip
        backend:
          serviceName: httpbin
          servicePort: 8000
EOF

启用Egress

默认情况下,Istio中的服务是无法访问cluster之外的服务的,这是因为pod中的iptable设置为所有的对外请求都指向sidecar proxy. 而为了能访问外部服务, Istio提供了两种方式来解决这个问题.

配置外部服务

注册一个HTTP和HTTPS服务, 如下:

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Service
metadata:
 name: externalbin
spec:
 type: ExternalName
 externalName: httpbin.org
 ports:
 - port: 80
   # important to set protocol name
   name: http
EOF

或者

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Service
metadata:
 name: securegoogle
spec:
 type: ExternalName
 externalName: www.google.com
 ports:
 - port: 443
   # important to set protocol name
   name: https
EOF

其中, metadata.name 就是内部服务所需要访问的外部服务的名称, spec.externalName则是外部服务的DNS名称.

执行如下命令可以尝试访问外部服务,

export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec -it $SOURCE_POD -c sleep bash
curl http://externalbin/headers
curl http://securegoogle:443

直接访问外部服务

Istio Egress目前只支持访问HTTP/HTTPS请求,而为了支持其他协议请求(如mqtt, mongo等), 就需要配置服务的Envoy sidecar来避免截取外部请求.
最简单的方式是使用参数--includeIPRanges来指定内部cluster服务所使用的IP范围.

Note: 不同的cloud provider所支持的IP范围和获取方式不尽相同.

例如, minikube支持如下:

kubectl apply -f <(istioctl kube-inject -f samples/apps/sleep/sleep.yaml --includeIPRanges=10.0.0.1/24)

配置请求路由

默认配置下,Istio会将所有的请求路由到同一个服务的所有版本上.此外,Istio提供了根据请求内容的路由规则,如下规则描述了所有的请求都会指向服务的版本v1:

type: route-rule
name: ratings-default
namespace: default
spec:
  destination: ratings.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: v1
    weight: 100
---
type: route-rule
name: reviews-default
namespace: default
spec:
  destination: reviews.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: v1
    weight: 100
---
type: route-rule
name: details-default
namespace: default
spec:
  destination: details.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: v1
    weight: 100
---
type: route-rule
name: productpage-default
namespace: default
spec:
  destination: productpage.default.svc.cluster.local
  precedence: 1
  route:
  - tags:
      version: v1
    weight: 100
---

如果需要将某些请求指向其他版本的服务,如根据请求的cookie进行路由:

destination: reviews.default.svc.cluster.local
match:
  httpHeaders:
    cookie:
      regex: ^(.*?;)?(user=jason)(;.*)?$
precedence: 2
route:
- tags:
    version: v2

错误注入

Istio提供2种错误类型可以注入到请求中:

  • delays: 属于时序故障,模拟网络延迟或者上游服务负载过重等;
  • aborts: 属于崩溃故障,模拟上游服务出现故障;一般返回HTTP Error Code或者TCP连接错误代码;

故障注入规则描述如下例子所述:

destination: ratings.default.svc.cluster.local
httpFault:
  delay:
    fixedDelay: 7s
    percent: 100
match:
  httpHeaders:
    cookie:
      regex: "^(.*?;)?(user=jason)(;.*)?$"
precedence: 2
route:
 - tags:
    version: v1

设置请求超时

HTTP请求超时可以通过在路由规则中设置字段httpReqTimeout实现.
具体例子如下:

cat <<EOF | istioctl replace
type: route-rule
name: reviews-default
spec:
  destination: reviews.default.svc.cluster.local
  route:
  - tags:
      version: v2
  httpReqTimeout:
    simpleTimeout:
      timeout: 1s
EOF

限流

在Istio的mixer中配置限流规则,如下ratelimit.yaml:

rules:
- selector: source.labels["app"]=="reviews" && source.labels["version"] == "v3"  
- aspects:
  - kind: quotas
    params:
      quotas:
      - descriptorName: RequestCount
        maxAmount: 5000
        expiration: 5s
        labels:
          label1: target.service

如果target.service=rating, 那么计数器的key则为:

$aspect_id;RequestCount;maxAmount=5000;expiration=5s;label1=ratings

执行如下命令可以使得rating服务的请求控制在每5秒5000次(限定在reviews v3服务在调用时生效):

istioctl mixer rule create global ratings.default.svc.cluster.local -f ratelimit.yaml

简单的访问控制

Istio可以通过设置规则实现简单的访问控制.

使用denials属性

例如:

rules:
- aspects:
  - kind: denials
  selector: source.labels["app"]=="reviews" && source.labels["version"] == "v3"

执行如下命令可以使rating服务拒绝来自reviews v3服务的任何请求.

istioctl mixer rule create global ratings.default.svc.cluster.local -f samples/apps/bookinfo/mixer-rule-ratings-denial.yaml

使用黑白名单

使用黑白名单之前需要先定义一个adapter,如下:

- name: versionList
  impl: genericListChecker
  params:
    listEntries: ["v1", "v2"]

启用白名单时blacklist设置为false,反之为true.

rules:
  aspects:
  - kind: lists
    adapter: versionList
    params:
      blacklist: false
      checkExpression: source.labels["version"]

结论

本文主要从概念、架构到每个组件原理介绍了istio，作为一个用于连接、管理以及安全化微服务的开放平台, istio的确提供了一种简单的方式用于创建微服务网络。后续将会提供一系列的文章分别介绍具体的案例以及涉及的核心技术。

文章标签：
服务网格
容器服务Kubernetes版
云解析DNS
访问控制
负载均衡
终端访问控制系统
容器
Kubernetes
API
网络协议
安全
关键词：
容器服务网格
服务网格Istio
服务网格容器
服务网格 istio
Istio容器
osswangxining
目录
相关文章
帅政的oss
|
5月前
|
机器学习/深度学习 Kubernetes Cloud Native
云原生技术演进之旅：从容器到服务网格
在云计算的浪潮中，云原生技术以其独特的灵活性和可扩展性引领了新的技术革命。本文将深入探讨云原生技术的发展脉络，从容器技术的突破，到Kubernetes的集群管理，再到服务网格的微服务通信解决方案，揭示云原生如何不断适应和塑造现代应用的需求。文章将通过数据支撑和案例分析，展示云原生技术在实际应用中的优势和挑战，并预测其未来的发展趋势。
帅政的oss
55 1
1941623231718325
|
6月前
|
安全 测试技术 开发者
探索服务网格技术：Istio的奥秘与力量
【6月更文挑战第1天】本文介绍了服务网格技术的代表Istio，它是处理服务间通信的基础设施层，由Google、IBM和Lyft联合开发。Istio提供流量管理、安全和可观察性等功能，支持灰度发布、蓝绿部署等，并确保通信安全。适用于微服务治理、多云环境和复杂网络拓扑，尤其适合安全敏感应用。理解Istio有助于解决微服务架构中的挑战。
1941623231718325
69 2
何雨晨
|
2月前
|
Kubernetes 负载均衡 安全
Istio在微服务中释放服务网格的力量
Istio在微服务中释放服务网格的力量
何雨晨
58 4
shuj
|
2月前
|
负载均衡 Cloud Native 安全
云原生时代的开发者指南：从容器到服务网格
【9月更文挑战第32天】在云原生技术日益成为企业数字化转型的核心力量之际，了解其背后的理念与实践对于开发者而言至关重要。本文旨在通过浅显易懂的语言，为读者揭开云原生技术的神秘面纱，从容器化的基础谈起，逐步深入到服务网格的高级应用，带领开发者们在云原生的海洋中航行。
shuj
44 1
土木林森
|
4月前
|
负载均衡 监控 安全
Istio：微服务治理的超级英雄，一键解锁你的服务网格超能力，让管理复杂变简单！
【8月更文挑战第31天】随着云原生技术的发展，微服务架构成为主流，但其复杂性与管理难题也随之增加。Istio作为开源服务网格平台，通过独特的数据平面和控制平面设计，实现了微服务通信的透明管理，简化了治理复杂度。本文将对比Istio与传统微服务管理方法，详细介绍Istio的架构及其工作原理，包括Envoy代理、服务发现、负载均衡、流量管理、安全认证以及监控等功能。Istio不仅简化了微服务治理，还提供了强大的流量控制和安全机制，使开发者能更高效地管理应用。
土木林森
86 2
土木林森
|
4月前
|
开发者 项目管理 开发工具
震惊！单人开发者如何成功过渡到团队协作？Xamarin 项目管理经验大揭秘，让你的开发之路一帆风顺！
【8月更文挑战第31天】Xamarin 是移动应用开发领域的热门跨平台工具，适用于个人开发者及团队。个人开发时需明确需求、运用版本控制（如 Git）并合理规划项目结构以增强代码可维护性。团队协作时，则需建立有效沟通渠道、统一代码规范、严格版本控制及合理分配任务，以提升开发效率与项目质量。
土木林森
67 1
土木林森
|
4月前
|
Kubernetes 安全 Cloud Native
解锁安全新纪元：利用服务网格Istio，打造全链路mTLS加密隧道，从入口网关到出口网关，守护数据安全的每一步
【8月更文挑战第2天】随着云原生技术的发展，服务网格（Service Mesh）如Istio已成为微服务架构的核心，通过双向TLS（mTLS）确保通信安全。首先，在Kubernetes部署Istio以管理服务通信。接着，配置入口网关实现所有入向流量的加密处理，防止数据泄露。最后，通过配置Sidecar代理如Envoy，确保服务网格安全访问外部mTLS服务，从而构建起全链路的数据安全防护。
土木林森
87 11
游客nmbcre4jd7shs
|
5月前
|
敏捷开发 运维 Cloud Native
云原生架构的演进之路：从容器化到服务网格
在数字化转型的浪潮中，云原生技术以其灵活性、可扩展性和弹性成为企业IT架构的新宠。本文将探讨云原生技术的演进路径，特别是容器化技术和服务网格的发展，以及它们如何共同推动现代应用的开发和部署。通过分析实际案例，我们揭示了云原生技术如何助力企业实现敏捷开发和高效运维，同时指出了未来云原生技术的发展趋势。
游客nmbcre4jd7shs
51 1
肥猪肥猪-17824
|
4月前
|
运维 Kubernetes Cloud Native
云原生技术演进：从容器到服务网格
【8月更文挑战第14天】云原生技术的迅速发展，不仅重塑了软件开发与部署的流程，也重新定义了企业IT架构的未来。本文将深入探讨容器技术的兴起、Kubernetes成为事实上的工业标准，以及服务网格的出现如何进一步优化微服务间的通信。通过分析这些技术的发展脉络，我们将揭示它们是如何共同促进现代云原生生态系统的成熟和扩展，同时指出这些技术面临的挑战和未来的发展方向。
肥猪肥猪-17824
43 0
小空门123-30335
|
5月前
|
Kubernetes Cloud Native 持续交付
云原生架构的核心组成部分通常包括容器化（如Docker）、容器编排（如Kubernetes）、微服务架构、服务网格、持续集成/持续部署（CI/CD）、自动化运维（如Prometheus监控和Grafana可视化）等。
云原生架构的核心组成部分通常包括容器化（如Docker）、容器编排（如Kubernetes）、微服务架构、服务网格、持续集成/持续部署（CI/CD）、自动化运维（如Prometheus监控和Grafana可视化）等。
小空门123-30335
503 3
云原生

容器服务

热门文章

最新文章

  • 1
    Docker 镜像加速器
  • 2
    Docker CE 镜像源站
  • 3
    Minikube - Kubernetes本地实验环境
  • 4
    Docker的Windows容器初体验
  • 5
    Docker学习路线图 (持续更新中)
  • 6
    容器镜像服务 Docker镜像的基本使用
  • 7
    Docker Engine 镜像源站
  • 8
    Maven Docker镜像使用技巧
  • 9
    容器内日志收集方案示例
  • 10
    Docker改名啦？什么是 Moby Project
  • 1
    canal-starter 监听解析 storeValue 不一样，同样的sql 一个在mybatis执行 一个在数据库操作，导致解析不出正确对象
    34
  • 2
    【Docker最新版教程】一文带你快速入门Docker常见用法，实现容器编排和自动化部署上线项目
    128
  • 3
    【最新版正确姿势】Docker安装教程（简单几步即可完成）
    629
  • 4
    ​​国内 5 个最佳的控制面板，可轻松管理服务器
    98
  • 5
    【赵渝强老师】K8s的有状态控制器StatefulSet
    48
  • 6
    【赵渝强老师】K8s中Deployment控制器与StatefulSet控制器的区别
    37
  • 7
    【赵渝强老师】K8s的Job控制器多工作队列的并行方式
    32
  • 8
    【赵渝强老师】K8s的周期性任务控制器CronJob
    40
  • 9
    【赵渝强老师】K8s中Job控制器单工作队列的串行方式
    30
  • 10
    【赵渝强老师】K8s中的Deployment控制器
    28

    • 相关课程

    更多
  • 现代应用容器技术快速入门
  • 云计算、容器和云原生基础课程
  • Serverless 容器从入门到精通: - Serverless Kubernetes
  • 容器安全与Palo Alto Networks解决方案
  • 微服务实战-Service Mesh与Istio
  • 服务网格技术最佳实践

    • 相关电子书

    更多
  • 使用CNFS搭建弹性Web服务
  • 阿里云文件存储 NAS 在容器场景的最佳实践
  • 阿里云总监课第五期第四节：从容器到云原生–服务网格

    • 相关实验场景

    更多
  • 容器中的volume卷
  • 容器的文件系统挂载
  • 容器的配置和存储
  • 容器DevSecOps全链路体验
  • 容器的自定义网络
  • 容器的共享网络模型
    • 下一篇
    阿里云无影云电脑免费试用，最长可试用3个月