Connect, secure, control, and observe services.

Overview

Istio

Go Report Card GoDoc

Istio logo

An open platform to connect, manage, and secure microservices.

  • For in-depth information about how to use Istio, visit istio.io
  • To ask questions and get assistance from our community, visit discuss.istio.io
  • To learn how to participate in our overall community, visit our community page

In this README:

In addition, here are some other documents you may wish to read:

You'll find many other useful documents on our Wiki.

Introduction

Istio is an open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. Istio's control plane provides an abstraction layer over the underlying cluster management platform, such as Kubernetes.

Istio is composed of these components:

  • Envoy - Sidecar proxies per microservice to handle ingress/egress traffic between services in the cluster and from a service to external services. The proxies form a secure microservice mesh providing a rich set of functions like discovery, rich layer-7 routing, circuit breakers, policy enforcement and telemetry recording/reporting functions.

    Note: The service mesh is not an overlay network. It simplifies and enhances how microservices in an application talk to each other over the network provided by the underlying platform.

  • Istiod - The Istio control plane. It provides service discovery, configuration and certificate management. It consists of the following sub-components:

    • Pilot - Responsible for configuring the proxies at runtime.

    • Citadel - Responsible for certificate issuance and rotation.

    • Galley - Responsible for validating, ingesting, aggregating, transforming and distributing config within Istio.

  • Operator - The component provides user friendly options to operate the Istio service mesh.

Repositories

The Istio project is divided across a few GitHub repositories:

  • istio/api. This repository defines component-level APIs and common configuration formats for the Istio platform.

  • istio/community. This repository contains information on the Istio community, including the various documents that govern the Istio open source project.

  • istio/istio. This is the main code repository. It hosts Istio's core components, install artifacts, and sample programs. It includes:

    • istioctl. This directory contains code for the istioctl command line utility.

    • operator. This directory contains code for the Istio Operator.

    • pilot. This directory contains platform-specific code to populate the abstract service model, dynamically reconfigure the proxies when the application topology changes, as well as translate routing rules into proxy specific configuration.

    • security. This directory contains security related code, including Citadel (acting as Certificate Authority), citadel agent, etc.

  • istio/proxy. The Istio proxy contains extensions to the Envoy proxy (in the form of Envoy filters) that support authentication, authorization, and telemetry collection.

Issue management

We use GitHub to track all of our bugs and feature requests. Each issue we track has a variety of metadata:

  • Epic. An epic represents a feature area for Istio as a whole. Epics are fairly broad in scope and are basically product-level things. Each issue is ultimately part of an epic.

  • Milestone. Each issue is assigned a milestone. This is 0.1, 0.2, ..., or 'Nebulous Future'. The milestone indicates when we think the issue should get addressed.

  • Priority. Each issue has a priority which is represented by the column in the Prioritization project. Priority can be one of P0, P1, P2, or >P2. The priority indicates how important it is to address the issue within the milestone. P0 says that the milestone cannot be considered achieved if the issue isn't resolved.

Comments
  • some questions for DeltaAggregatedResources

    some questions for DeltaAggregatedResources

    hello, i try to send a delta grpc request to istiod in my program, but got response with full rusources, and the Resource.Version was not set in response, this confuses me.... How to use this interface(DeltaAggregatedResources ) correctly?

    istio version: client version: 1.14.1 control plane version: 1.14.1 data plane version: 1.14.1 (1 proxies), (1 proxies)

    ---test code:

    _func send() { ................ ................. if c.grpcConn, err = nets.GrpcConnect(ads.Clusters[0].Address[0]); err != nil { return fmt.Errorf("ads grpc connect failed, %s", err) } c.client = service_discovery_v3.NewAggregatedDiscoveryServiceClient(c.grpcConn) // DeltaAggregatedResources() is supported from istio-1.12.x c.stream, err = c.client.DeltaAggregatedResources(c.ctx) if err != nil { return fmt.Errorf("ads StreamAggregatedResources failed, %s", err) } if err = c.stream.Send(newDeltaAdsRequest(resource_v3.ClusterType, nil)); err != nil { return fmt.Errorf("ads subscribe failed, %s", err) } }

    func newDeltaAdsRequest(typeUrl string, names []string) *service_discovery_v3.DeltaDiscoveryRequest { var subNames [] string subNames = append(subNames, "outbound|9080|v1|reviews.default.svc.cluster.local") var resourcesVersion = make(map[string]string) if names != nil { for , r := range names { resourcesVersion[r] = "v0" } } return &service_discovery_v3.DeltaDiscoveryRequest{ TypeUrl: typeUrl, ResourceNamesSubscribe: subNames, ==>sub one cluster resource InitialResourceVersions: resourcesVersion, ResponseNonce: "", ErrorDetail: nil, Node: config.getNode(), } }

    there some logs in istiod, receive Delta Request:

    2022-11-22T08:44:30.938262Z debug delta Unauthenticated XDS: xxxxx:46142 2022-11-22T08:44:30.939000Z warn model Istio Version is not found in metadata for default, which may have undesirable side effects 2022-11-22T08:44:30.939153Z info delta ADS: new delta connection for node:default-1038 2022-11-22T08:44:30.939172Z debug delta ADS: got Delta Request for: type.googleapis.com/envoy.config.cluster.v3.Cluster 2022-11-22T08:44:30.939183Z debug delta ADS:CDS: INIT/RECONNECT default-1038 2022-11-22T08:44:30.939866Z info delta CDS: PUSH request for node:default resources:29 size:29.2kB cached:26/26 filtered:0 nonce:lgQ5NdgYDgQ=66fb5050-21c6-405c-8495-4d12504f20b0 version:2022-11-22T08:42:16Z/23 2022-11-22T08:44:30.956827Z debug delta ADS: got Delta Request for: type.googleapis.com/envoy.config.cluster.v3.Cluster 2022-11-22T08:44:30.956871Z debug delta ADS:CDS: ACK default-1038 lgQ5NdgYDgQ=66fb5050-21c6-405c-8495-4d12504f20b0

    opened by yanbuduo 0
  • Jwks is an invalid JSON

    Jwks is an invalid JSON

    Bug Description

    1. I apply request authentication policy using demo jwks as bellow:
    kubectl apply -f - <<EOF
    apiVersion: security.istio.io/v1beta1
    kind: RequestAuthentication
    metadata:
      name: "jwt-example"
      namespace: istio-system
    spec:
      selector:
        matchLabels:
          istio: ingressgateway
      jwtRules:
      - issuer: "[email protected]"
        jwksUri: "https://gitcode.net/wuswoo/mytest/-/raw/master/doc/istio/security/tools/jwt/samples/jwks.json"
    EOF
    

    the demo jwks is absolutely same as content from https://raw.githubusercontent.com/istio/istio/release-1.16/security/tools/jwt/samples/jwks.json.

    1. kubectl logs -f istio-ingressgateway-57bcb89bf9-hplr4 -n istio-system

    2022-11-22T07:46:47.730788Z warning envoy config gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8080: Provider 'origins-0' in jwt_authn config has invalid local jwks: Jwks is an invalid JSON 0.0.0.0_8443: Provider 'origins-0' in jwt_authn config has invalid local jwks: Jwks is an invalid JSON

    Version

    $ istioctl version
    client version: 1.15.3
    control plane version: 1.15.3
    data plane version: 1.15.3 (20 proxies)
    

    Additional Information

    No response

    kind/docs 
    opened by 2456868764 0
  • Clarify documentation for Ambient on macOs

    Clarify documentation for Ambient on macOs

    Please provide a description of this PR:

    Add instructions for how to retrieve the local-test-utils directory, and document some of the overrides necessary to build Rust ztunnel using Docker Desktop for macOS.

    To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

    • [X] Ambient
    • [ ] Configuration Infrastructure
    • [ ] Docs
    • [ ] Installation
    • [ ] Networking
    • [ ] Performance and Scalability
    • [ ] Policies and Telemetry
    • [ ] Security
    • [ ] Test and Release
    • [ ] User Experience
    • [ ] Developer Infrastructure

    Please check any characteristics that apply to this pull request.

    • [X] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.
    ok-to-test size/S 
    opened by keithmattix 2
  • How to create new istio metrics, and use default DefaultStatTags?

    How to create new istio metrics, and use default DefaultStatTags?

    Hello everyone, I have a question. I have a requirement, I want to create custom istio metrics, similar to istio_request_total.

    Specifically, I want to create a metric similar to istio_request_total, which contains some tags, such as request_path, reporter, source_app, etc. I implemented it based on envoyfilter, and the implemented yaml content is roughly as follows:

    - applyTo: HTTP_FILTER
        match:
          context: SIDECAR_INBOUND
          listener:
            filterChain:
              filter:
                name: envoy.filters.network.http_connection_manager
                subFilter:
                  name: istio.stats
          proxy:
            proxyVersion: ^1\.11.*
        patch:
          operation: REPLACE
          value:
            name: istio.stats
            typed_config:
              '@type': type.googleapis.com/udpa.type.v1.TypedStruct
              type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
              value:
                config:
                  configuration:
                    '@type': type.googleapis.com/google.protobuf.StringValue
                    value: |
                     {
                        "debug": "false",
                        "stat_prefix": "test",
                        "metrics": [
                          {
                            "name": "requests_total",
                            "dimensions": {
                              "destination_cluster": "node. metadata['CLUSTER_ID']",
                              "source_cluster": "downstream_peer.cluster_id",
                              "reporter": "reporter",
                              "request_path": "request.path",
                              "source_app": "source_app"
                            }
                          }
                        ]
                      }
                  root_id: stats_inbound
                  vm_config:
                    code:
                      local:
                        inline_string: envoy.wasm.stats
                    runtime: envoy.wasm.runtime.null
                    vm_id: stats_inbound
    

    My idea is that reporter and source_app use the default DefaultStatTags list, and then request_path I use sidecar.istio.io/extraStatTags: request.path to declare in the workload. The declaration of my new indicator (test_requests_total) is also through envoyfilter, and its configuration is roughly as follows:

    - applyTo: HTTP_FILTER
        match:
          context: SIDECAR_INBOUND
          listener:
            filterChain:
              filter:
                name: envoy.filters.network.http_connection_manager
                subFilter:
                  name: envoy.filters.http.router
          proxy:
            proxyVersion: ^1\.11.*
        patch:
          operation: INSERT_BEFORE
          value:
            name: istio.stats
            typed_config:
              '@type': type.googleapis.com/udpa.type.v1.TypedStruct
              type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
              value:
                config:
                  configuration:
                    '@type': type.googleapis.com/google.protobuf.StringValue
                    value: |
                      {
                        "debug": "false",
                        "stat_prefix": "test",
                        "definitions": [
                          {
                            "name": "request_total",
                            "type": "COUNTER",
                            "value": "1"
                          }
                        ]
                      }
                  root_id: stats_inbound
                  vm_config:
                    code:
                      local:
                        inline_string: envoy.wasm.stats
                    runtime: envoy.wasm.runtime.null
                    vm_id: stats_inbound
    

    Its declaration in the workload is: sidecar.istio.io/statsInclusionPrefixes: test_request_total

    But I found that the indicator test_solarmesh_total was not generated after such a configuration. I guess it is caused by reporter and source_app not taking effect, but I don't know how to solve it.

    Does anyone know how to fix it? Is there something wrong with my train of thought?

    opened by mark8s 2
  • tracing: fix opentelemetry service name

    tracing: fix opentelemetry service name

    fix: https://github.com/istio/istio/issues/42080

    • fix missing opentelemetry service name
    • fix e2e test

    opentelemetry send zipkin span as following:

    [
    {
          "traceId": "b72c4f57c2cf8dc73df8ea734dcc1481",
          "parentId": "6f5703b3bf77bc1d",
          "id": "266fd6ae4b9bb617",
          "kind": "SERVER",
          "name": "ingress",
          "timestamp": 1669102679177576,
          "duration": 1399,
          "localEndpoint": {
            "serviceName": "httpbin.default"
          },
          "tags": {
            "component": "proxy",
            "downstream_cluster": "-",
            "guid:x-request-id": "233128f2-8a20-929e-bf22-843422da5bde",
            "http.method": "GET",
            "http.protocol": "HTTP/1.1",
            "http.status_code": "200",
            "http.url": "http://httpbin.default:8000/ip",
            "istio.canonical_revision": "v1",
            "istio.canonical_service": "httpbin",
            "istio.mesh_id": "cluster.local",
            "istio.namespace": "default",
            "node_id": "sidecar~10.244.0.46~httpbin-847f64cc8d-982r2.default~default.svc.cluster.local",
            "peer.address": "10.244.0.47",
            "provider": "otel",
            "request_size": "0",
            "response_flags": "-",
            "response_size": "28",
            "upstream_cluster": "inbound|80||",
            "upstream_cluster.name": "inbound|80||",
            "user_agent": "curl/7.86.0-DEV",
            "zone": ""
          }
        },
        {
          "traceId": "b72c4f57c2cf8dc73df8ea734dcc1481",
          "id": "6f5703b3bf77bc1d",
          "kind": "CLIENT",
          "name": "egress httpbin.default:8000",
          "timestamp": 1669102679177281,
          "duration": 1962,
          "localEndpoint": {
            "serviceName": "sleep.default"
          },
          "tags": {
            "component": "proxy",
            "downstream_cluster": "-",
            "guid:x-request-id": "233128f2-8a20-929e-bf22-843422da5bde",
            "http.method": "GET",
            "http.protocol": "HTTP/1.1",
            "http.status_code": "200",
            "http.url": "http://httpbin.default:8000/ip",
            "istio.canonical_revision": "latest",
            "istio.canonical_service": "sleep",
            "istio.mesh_id": "cluster.local",
            "istio.namespace": "default",
            "node_id": "sidecar~10.244.0.47~sleep-69cfb4968f-6qw9g.default~default.svc.cluster.local",
            "peer.address": "10.244.0.47",
            "provider": "otel",
            "request_size": "0",
            "response_flags": "-",
            "response_size": "28",
            "upstream_cluster": "outbound|8000||httpbin.default.svc.cluster.local",
            "upstream_cluster.name": "outbound|8000||httpbin.default.svc.cluster.local",
            "user_agent": "curl/7.86.0-DEV",
            "zone": ""
          }
        }
    ]
    
    area/extensions and telemetry size/M cherrypick/release-1.16 
    opened by zirain 2
Releases(1.16.0)
Owner
Istio
Connect, secure, control, and observe services.
Istio
An open platform to connect, manage, and secure microservices.

Istio An open platform to connect, manage, and secure microservices. For in-depth information about how to use Istio, visit istio.io To ask questions

Baalaji 0 Feb 6, 2022
A microservice gateway developed based on golang.With a variety of plug-ins which can be expanded by itself, plug and play. what's more,it can quickly help enterprises manage API services and improve the stability and security of API services.

Goku API gateway is a microservice gateway developed based on golang. It can achieve the purposes of high-performance HTTP API forwarding, multi tenant management, API access control, etc. it has a powerful custom plug-in system, which can be expanded by itself, and can quickly help enterprises manage API services and improve the stability and security of API services.

Eolink 357 Nov 23, 2022
A code generator that turns plain old Go services into RPC-enabled (micro)services with robust HTTP APIs.

Frodo is a code generator and runtime library that helps you write RPC-enabled (micro) services and APIs.

Monadic 21 Oct 25, 2022
Services-inoeg - The Kiebitz Backend Services. Still a work-in-progess, use with care!

Kiebitz Services This repository contains Kiebitz's backend services: A storage service that stores encrypted user & operator settings and temporary d

Kiebitz! 0 Jan 19, 2022
Rpcx-framework - An RPC microservices framework based on rpcx, simple and easy to use, ultra fast and efficient, powerful, service discovery, service governance, service layering, version control, routing label registration.

RPCX Framework An RPC microservices framework based on rpcx. Features: simple and easy to use, ultra fast and efficient, powerful, service discovery,

ZYallers 1 Jan 5, 2022
An example microservice demo using kubernetes concepts like deployment, services, persistent volume and claims, secrets and helm chart

Docker vs Kubernetes Docker Kubernetes container tech, isolated env for apps infra management, multiple containers automated builds and deploy apps -

abhijit wakchaure 0 Dec 13, 2021
Automatic Service Mesh and RPC generation for Go micro services, it's a humble alternative to gRPC with Istio.

Mesh RPC MeshRPC provides automatic Service Mesh and RPC generation for Go micro services, it's a humble alternative to gRPC with Istio. In a nutshell

AstraNet Toolkit 69 Aug 22, 2022
Dubbo2istio watches Dubbo ZooKeeper registry and synchronize all the dubbo services to Istio.

Dubbo2Istio Dubbo2istio 将 Dubbo ZooKeeper 服务注册表中的 Dubbo 服务自动同步到 Istio 服务网格中。 Aeraki 根据 Dubbo 服务信息和用户设置的路由规则生成数据面相关的配置,通过 Istio 下发给数据面 Envoy 中的 Dubbo p

Aeraki 32 Oct 20, 2022
Study Project for the application of micro services and requisition controls

Starting Endpoint GO with Retry Request Install GoLang for Linux Tutorial: LINK

Antenor Pires 3 Jul 4, 2022
Sample full stack micro services application built using the go-Micro framework.

goTemp goTemp is a full stack Golang microservices sample application built using go-micro. The application is built as a series of services that prov

null 63 Oct 18, 2022
Starter code for writing web services in Go

Ultimate Service Copyright 2018, 2019, 2020, 2021, Ardan Labs [email protected] Ultimate Service 2.0 Video If you are watching the Ultimate Service v

Ardan Labs 2.5k Nov 26, 2022
a microservice framework for rapid development of micro services in Go with rich eco-system

中文版README Go-Chassis is a microservice framework for rapid development of microservices in Go. it focus on helping developer to deliver cloud native a

null 2.6k Nov 27, 2022
This tool generates Go language bindings of services in protobuf definition files for go-kit

protoc-gen-go-kit This tool generates Go language bindings of services in protobuf definition files for go-kit. Installation $ go install github.com/x

X64FUN 1 Nov 9, 2021
An open network for Micro services.

Micro Network The micro network is an open network for Micro services. Note: The network is still in early development. This document serves as a star

Micro 17 Nov 1, 2022
GoLang utility packages to assist with the development of web micro-services.

GoTil Golang utility packages to assist with the development of web micro-services. Installation As a library. go get github.com/ccthomas/gotil Usage

Christopher Thomas 0 Nov 26, 2021
Global Financial Transaction Network Services

Global Financial Transaction Network Services This code was developed at IBM during 2017-2020, and contributed to open source in September 2021. Overv

null 17 Oct 9, 2022
Backend services for the Shiny Sorter image tagging service.

Backend Database The backend database will be MongoDB. Each image will be one object, with the file name, hash, tags, and other metadata. Database Pop

null 0 Aug 4, 2022
Flamingops - Handle your web services consommation with golang

How to use this repo as a template for your project I - Introduction This reposi

Alexandre Delaloy 2 Mar 31, 2022
Go-rifa-microservice - Clean Architecture template for Golang services

Test CI Go Clean template Clean Architecture template for Golang services Overvi

Evandro Martinelli 1 Sep 22, 2022