Diretrizes de migração para configurações de Open Service Mesh (OSM) para o Istio

Artigo
01/10/2024

Importante

Este artigo tem como objetivo fornecer uma compreensão simplista de como identificar configurações OSM e traduzi-las para configurações equivalentes do Istio para migrar cargas de trabalho do OSM para o Istio. Este não é, de modo algum, considerado um guia pormenorizado exaustivo.

Este artigo fornece orientações práticas para mapear políticas de OSM para as políticas do Istio para ajudar a migrar suas implantações de microsserviços gerenciadas pelo OSM para serem gerenciadas pelo Istio . Utilizamos o aplicativo de exemplo OSM Bookstore como uma referência base para os usuários atuais do OSM. O passo a passo a seguir implanta o aplicativo Livraria. As mesmas etapas são seguidas e explicam como aplicar as políticas de tráfego OSM SMI usando o equivalente Istio.

Se você não estiver usando o OSM e for novo no Istio, comece com o guia de Introdução do próprio Istio para aprender a usar a malha de serviço do Istio para seus aplicativos. Se você estiver usando o OSM no momento, certifique-se de estar familiarizado com o passo a passo do aplicativo de exemplo OSM Bookstore sobre como o OSM configura as diretivas de tráfego. O passo a passo a seguir não duplica a documentação atual e faz referência a tópicos específicos quando relevante. Você deve estar confortável e totalmente ciente da arquitetura do aplicativo da livraria antes de prosseguir.

Pré-requisitos

Uma subscrição do Azure. Se não tiver uma subscrição do Azure, pode criar uma conta gratuita.
A CLI do Azure instalada.
O complemento OSM AKS é desinstalado do cluster AKS
Qualquer aplicativo OSM Bookstore existente, incluindo namespaces, é desinstalado e excluído do cluster
Instale o complemento de malha de serviço Istio AKS

Modificações necessárias para o aplicativo OSM Sample Bookstore

Para permitir que o Istio gerencie o aplicativo OSM bookstore, há algumas mudanças necessárias nos manifestos existentes. Essas mudanças são com a livraria e os serviços mysql.

Modificações na Livraria

No passo a passo da Livraria OSM, o serviço de livraria é implantado junto com outro serviço de livraria-v2 para demonstrar como o OSM fornece deslocamento de tráfego. Esses serviços implantados permitiram dividir o tráfego do cliente (bookbuyer) entre vários pontos de extremidade de serviço. O primeiro novo conceito para entender como o Istio lida com o que eles chamam de Traffic Shifting.

A implementação OSM da mudança de tráfego é baseada na especificação SMI Traffic Split. A especificação SMI Traffic Split requer a existência de vários serviços de nível superior que são adicionados como back-ends com a métrica de peso desejada para mudar as solicitações do cliente de um serviço para outro. O Istio realiza a mudança de tráfego usando uma combinação de um Serviço Virtual e uma Regra de Destino. É altamente recomendável que você se familiarize com os conceitos de um serviço virtual e regra de destino.

Simplificando, o serviço virtual Istio define regras de roteamento para clientes que solicitam o host (nome do serviço). Os Serviços Virtuais permitem que várias versões de uma implantação sejam associadas a um nome de host de serviço virtual para os clientes direcionarem. Várias implantações podem ser rotuladas para o mesmo serviço, representando diferentes versões do aplicativo por trás do mesmo nome de host. O serviço virtual Istio pode então ser configurado para ponderar a solicitação para uma versão específica do serviço. As versões disponíveis do serviço são configuradas para usar o subsets atributo em uma regra de destino Istio.

A modificação feita no serviço de livraria e implantação para o Istio elimina a necessidade de ter um segundo serviço explícito para segmentar, que o SMI Traffic Split precisa. Não há necessidade de outra conta de serviço para o serviço de livraria v2 também, uma vez que é para ser consolidado sob o serviço de livraria. A modificação original do manifesto traffic-access-v1.yaml do OSM para o Istio para a livraria v1 e v2 é mostrada na seção Criar pods, serviços e contas de serviço abaixo. Demonstramos como fazemos a divisão de tráfego, conhecida como mudança de tráfego mais adiante no passo a passo:

Modificações do MySql

Alterações no conjunto stateful mysql só são necessárias na configuração do serviço. Sob a especificação de serviço, o OSM precisava dos targetPort atributos e appProtocol . Esses atributos não são necessários para o Istio. O seguinte serviço atualizado para o mysqldb se parece com:

apiVersion: v1
kind: Service
metadata:
  name: mysqldb
  labels:
    app: mysqldb
    service: mysqldb
spec:
  ports:
    - port: 3306
      name: tcp
  selector:
    app: mysqldb

Implantar o aplicativo de livraria modificado

Semelhante ao passo a passo da Livraria OSM, começamos com uma nova instalação do aplicativo da livraria.

Criar os namespaces

kubectl create namespace bookstore
kubectl create namespace bookbuyer
kubectl create namespace bookthief
kubectl create namespace bookwarehouse

Adicionar um rótulo de namespace para injeção de sidecar Istio

Para o OSM, usando o comando osm namespace add <namespace> criou as anotações necessárias no namespace para que o controlador OSM adicionasse a injeção automática do sidecar. Com o Istio, você só precisa rotular um namespace para permitir que o controlador Istio seja instruído a injetar automaticamente os proxies do sidecar Envoy.

kubectl label namespace bookstore istio-injection=enabled
kubectl label namespace bookbuyer istio-injection=enabled
kubectl label namespace bookthief istio-injection=enabled
kubectl label namespace bookwarehouse istio-injection=enabled

Implantar o serviço virtual Istio e a regra de destino para livraria

Como mencionado anteriormente na seção Modificação da livraria, o Istio lida com a mudança de tráfego utilizando um atributo de peso do VirtualService que configuramos mais adiante no passo a passo. Implantamos o serviço virtual e a regra de destino para o serviço de livraria. Implantamos apenas a livraria versão 1, mesmo que a livraria versão 2 esteja implantada. O serviço virtual Istio está apenas fornecendo uma rota para a versão 1 da livraria. Diferente de como o OSM lida com a mudança de tráfego (divisão de tráfego), o OSM implantou outro serviço para o aplicativo da livraria versão 2. O OSM precisava configurar o tráfego para ser dividido entre as solicitações do cliente usando um TrafficSplit. Ao usar a mudança de tráfego com o Istio, podemos fazer referência à mudança de tráfego para várias implantações (versões) de aplicativos Kubernetes rotuladas para o mesmo serviço.

Neste passo a passo, a implantação de ambas as versões da livraria (v1 & v2) é implantada ao mesmo tempo. Somente a versão 1 é acessível devido à configuração do serviço virtual. Não há necessidade de implantar outro serviço para a livraria versão 2, habilitamos uma rota para a livraria versão 2 mais tarde, quando atualizamos o serviço virtual da livraria e fornecemos o atributo de peso necessário para fazer o deslocamento do tráfego.

kubectl apply -f - <<EOF
# Create bookstore virtual service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookstore-virtualservice
  namespace: bookstore
spec:
  hosts:
  - bookstore
  http:
  - route:
    - destination:
        host: bookstore
        subset: v1
---
# Create bookstore destination rule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookstore-destination
  namespace: bookstore
spec:
  host: bookstore
  subsets:
  - name: v1
    labels:
      app: bookstore
      version: v1
  - name: v2
    labels:
      app: bookstore
      version: v2
EOF

Criar pods, serviços e contas de serviço

Usamos um único arquivo de manifesto que contém as modificações discutidas anteriormente no passo a passo para implantar os bookbuyeraplicativos , , , , bookwarehousebookthiefbookstoree .mysql

kubectl apply -f - <<EOF
##################################################################################################
# bookbuyer service
##################################################################################################
---
# Create bookbuyer Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookbuyer
  namespace: bookbuyer
---
# Create bookbuyer Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookbuyer
  namespace: bookbuyer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookbuyer
      version: v1
  template:
    metadata:
      labels:
        app: bookbuyer
        version: v1
    spec:
      serviceAccountName: bookbuyer
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookbuyer
          image: openservicemesh/bookbuyer:latest-main
          imagePullPolicy: Always
          command: ["/bookbuyer"]
          env:
            - name: "BOOKSTORE_NAMESPACE"
              value: bookstore
            - name: "BOOKSTORE_SVC"
              value: bookstore
---
##################################################################################################
# bookthief service
##################################################################################################
---
# Create bookthief ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookthief
  namespace: bookthief
---
# Create bookthief Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookthief
  namespace: bookthief
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookthief
  template:
    metadata:
      labels:
        app: bookthief
        version: v1
    spec:
      serviceAccountName: bookthief
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookthief
          image: openservicemesh/bookthief:latest-main
          imagePullPolicy: Always
          command: ["/bookthief"]
          env:
            - name: "BOOKSTORE_NAMESPACE"
              value: bookstore
            - name: "BOOKSTORE_SVC"
              value: bookstore
            - name: "BOOKTHIEF_EXPECTED_RESPONSE_CODE"
              value: "503"
---
##################################################################################################
# bookstore service version 1 & 2
##################################################################################################
---
# Create bookstore Service
apiVersion: v1
kind: Service
metadata:
  name: bookstore
  namespace: bookstore
  labels:
    app: bookstore
spec:
  ports:
    - port: 14001
      name: bookstore-port
  selector:
    app: bookstore

---
# Create bookstore Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookstore
  namespace: bookstore

---
# Create bookstore-v1 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookstore-v1
  namespace: bookstore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookstore
      version: v1
  template:
    metadata:
      labels:
        app: bookstore
        version: v1
    spec:
      serviceAccountName: bookstore
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookstore
          image: openservicemesh/bookstore:latest-main
          imagePullPolicy: Always
          ports:
            - containerPort: 14001
              name: web
          command: ["/bookstore"]
          args: ["--port", "14001"]
          env:
            - name: BOOKWAREHOUSE_NAMESPACE
              value: bookwarehouse
            - name: IDENTITY
              value: bookstore-v1

---
# Create bookstore-v2 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookstore-v2
  namespace: bookstore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookstore
      version: v2
  template:
    metadata:
      labels:
        app: bookstore
        version: v2
    spec:
      serviceAccountName: bookstore
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookstore
          image: openservicemesh/bookstore:latest-main
          imagePullPolicy: Always
          ports:
            - containerPort: 14001
              name: web
          command: ["/bookstore"]
          args: ["--port", "14001"]
          env:
            - name: BOOKWAREHOUSE_NAMESPACE
              value: bookwarehouse
            - name: IDENTITY
              value: bookstore-v2
---
##################################################################################################
# bookwarehouse service
##################################################################################################
---
# Create bookwarehouse Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
---
# Create bookwarehouse Service
apiVersion: v1
kind: Service
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
  labels:
    app: bookwarehouse
spec:
  ports:
  - port: 14001
    name: bookwarehouse-port
  selector:
    app: bookwarehouse
---
# Create bookwarehouse Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookwarehouse
  template:
    metadata:
      labels:
        app: bookwarehouse
        version: v1
    spec:
      serviceAccountName: bookwarehouse
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookwarehouse
          image: openservicemesh/bookwarehouse:latest-main
          imagePullPolicy: Always
          command: ["/bookwarehouse"]
##################################################################################################
# mysql service
##################################################################################################
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mysql
  namespace: bookwarehouse
---
apiVersion: v1
kind: Service
metadata:
  name: mysqldb
  labels:
    app: mysqldb
    service: mysqldb
spec:
  ports:
    - port: 3306
      name: tcp
  selector:
    app: mysqldb
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: bookwarehouse
spec:
  serviceName: mysql
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      serviceAccountName: mysql
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: mypassword
        - name: MYSQL_DATABASE
          value: booksdemo
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - mountPath: /mysql-data
          name: data
        readinessProbe:
          tcpSocket:
            port: 3306
          initialDelaySeconds: 15
          periodSeconds: 10
      volumes:
        - name: data
          emptyDir: {}
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 250M
EOF

Para exibir esses recursos no cluster, execute os seguintes comandos:

kubectl get pods,deployments,serviceaccounts -n bookbuyer
kubectl get pods,deployments,serviceaccounts -n bookthief

kubectl get pods,deployments,serviceaccounts,services,endpoints -n bookstore
kubectl get pods,deployments,serviceaccounts,services,endpoints -n bookwarehouse

Exibir as interfaces do usuário do aplicativo

Semelhante ao passo a passo original do OSM, se você tiver o repositório OSM clonado, poderá utilizar os scripts de encaminhamento de porta para exibir as interfaces do usuário de cada aplicativo aqui. Por enquanto, estamos preocupados apenas em ver o e bookthief UIbookbuyer.

cp .env.example .env
bash <<EOF
./scripts/port-forward-bookbuyer-ui.sh &
./scripts/port-forward-bookthief-ui.sh &
wait
EOF

Em um navegador, abra as seguintes urls:

http://localhost:8080 - Livreiro

http://localhost:8083 - ladrão de livros

Configurar as políticas de tráfego do Istio

Para manter a continuidade com o passo a passo original da Livraria OSM para a tradução para o Istio, discutimos o Modo de Política de Tráfego Permissivo do OSM. O modo de política de tráfego permissivo do OSM era um conceito de permitir ou negar tráfego na malha sem nenhuma regra específica de Controle de Acesso de Tráfego SMI implantada. A configuração do modo de tráfego permissivo existia para permitir que os usuários integrassem aplicativos na malha, enquanto ganhavam criptografia mTLS, sem exigir regras explícitas para permitir que os aplicativos na malha se comunicassem. O recurso de modo de tráfego permissivo era evitar interromper as comunicações do seu aplicativo assim que o OSM o gerenciasse e fornecer tempo para definir suas regras, garantindo que as comunicações do aplicativo fossem criptografadas pelo mTLS. Essa configuração pode ser definida como true ou false por meio do Meshconfig do OSM.

O Istio lida com a aplicação do mTLS de forma diferente. Diferente do OSM, o modo permissivo do Istio configura automaticamente proxies de sidecar para usar mTLS, mas permite que o serviço aceite tráfego de texto simples e mTLS. O equivalente à configuração do modo permissivo do OSM é utilizar as PeerAuthentication configurações do Istio. PeerAuthentication pode ser feito granularmente no namespace ou para toda a malha. Para obter mais informações sobre a aplicação do mTLS pelo Istio, leia o artigo Istio Mutual TLS Migration.

Impor o Modo Estrito Istio em Namespaces de Livraria

É importante lembrar que, assim como o modo permissivo do OSM, a configuração do Istio está relacionada apenas ao uso da aplicação do PeerAuthentication mTLS. As políticas reais de camada 7, muito semelhantes às usadas no HTTPRouteGroups do OSM, são tratadas usando as configurações AuthorizationPolicy do Istio, que você verá mais adiante no passo a passo.

Colocamos granularmente os bookbuyernamespaces , , bookstore, bookthiefe bookwarehouse no modo estrito mTLS do Istio.

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookbuyer
  namespace: bookbuyer
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookthief
  namespace: bookthief
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookstore
  namespace: bookstore
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
spec:
  mtls:
    mode: STRICT
EOF

Implantar políticas de controle de acesso do Istio

Semelhante aos recursos SMI Traffic Target e SMI Traffic Specs do OSM para definir políticas de controle de acesso e roteamento para que os aplicativos se comuniquem, o Istio realiza esses controles de grão fino semelhantes usando AuthorizationPolicy configurações.

Vamos percorrer a tradução da política TrafficTarget da livraria, que permite especificamente que a bookbuyer comunicação com ela, com apenas determinados caminhos, cabeçalhos e métodos da camada 7. A seguir está uma parte do manifesto traffic-access-v1.yaml .

kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha3
metadata:
  name: bookstore
  namespace: bookstore
spec:
  destination:
    kind: ServiceAccount
    name: bookstore
    namespace: bookstore
  rules:
    - kind: HTTPRouteGroup
      name: bookstore-service-routes
      matches:
        - buy-a-book
        - books-bought
  sources:
    - kind: ServiceAccount
      name: bookbuyer
      namespace: bookbuyer
---
apiVersion: specs.smi-spec.io/v1alpha4
kind: HTTPRouteGroup
metadata:
  name: bookstore-service-routes
  namespace: bookstore
spec:
  matches:
    - name: books-bought
      pathRegex: /books-bought
      methods:
        - GET
      headers:
        - "user-agent": ".*-http-client/*.*"
        - "client-app": "bookbuyer"
    - name: buy-a-book
      pathRegex: ".*a-book.*new"
      methods:
        - GET

Se você notar na política TrafficTarget, na especificação é onde você pode definir explicitamente qual serviço de origem pode se comunicar com um serviço de destino. Podemos ver que estamos permitindo que a fonte bookbuyer seja autorizada a se comunicar com a livraria de destino. Se traduzirmos a autorização de serviço para serviço de uma configuração OSM TrafficTarget para um Istio AuthorizationPolicy, será a seguinte aparência:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: bookstore
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]

No Istio's AuthorizationPolicy, você percebe como o serviço de destino da política OSM TrafficTarget é mapeado para a correspondência do rótulo do seletor e o namespace no qual o serviço reside. O serviço de origem é mostrado na seção de regras, onde há um atributo source/principles que mapeia para o nome da conta de serviço do bookbuyer serviço.

Além de apenas a configuração de origem/destino no OSM TrafficTarget, o OSM vincula o uso de um HTTPRouteGroup para definir melhor a autorização de camada 7 à qual a origem tem acesso. Podemos ver apenas na parte do HTTPRouteGroup abaixo. Há dois matches para o serviço de origem permitido.

apiVersion: specs.smi-spec.io/v1alpha4
kind: HTTPRouteGroup
metadata:
  name: bookstore-service-routes
  namespace: bookstore
spec:
  matches:
    - name: books-bought
      pathRegex: /books-bought
      methods:
        - GET
      headers:
        - "user-agent": ".*-http-client/*.*"
        - "client-app": "bookbuyer"
    - name: buy-a-book
      pathRegex: ".*a-book.*new"
      methods:
        - GET

Há um nome books-bought que permite que a origem acesse o caminho usando um método com informações do agente do usuário e do aplicativo cliente do cabeçalho do host, e uma buy-a-book correspondência que usa um regex express para um caminho /books-bought que contém .*a-book.*new o uso de um matchGETGET método.

Podemos definir essas configurações OSM HTTPRouteGroup na seção de regras do Istio AuthorizationPolicy mostrada abaixo:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]
        - source:
            namespaces: ["bookbuyer"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]

Agora podemos implantar o manifesto traffic-access-v1.yaml migrado do OSM, conforme entendido pelo Istio abaixo. Não há um AuthorizationPolicy para o ladrão de livros, então a interface do usuário do ladrão de livros deve parar de incrementar livros da livraria v1:

kubectl apply -f - <<EOF
##################################################################################################
# bookstore policy
##################################################################################################
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]
        - source:
            namespaces: ["bookbuyer"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]
---
##################################################################################################
# bookwarehouse policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "bookwarehouse"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: bookwarehouse
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookstore/sa/bookstore"]
        - source:
            namespaces: ["bookstore"]
      to:
        - operation:
            methods: ["POST"]
---
##################################################################################################
# mysql policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "mysql"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: mysql
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookwarehouse/sa/bookwarehouse"]
        - source:
            namespaces: ["bookwarehouse"]
      to:
         - operation:
            ports: ["3306"]
EOF

Permitir que a Aplicação Bookthief aceda à Livraria

Atualmente não existe nenhuma AuthorizationPolicy que permita que o ladrão de livros se comunique com a livraria. Podemos implantar o seguinte AuthorizationPolicy para permitir que o ladrão de livros se comunique com a livraria. Você percebe a adição da regra para a política de livraria que permite a autorização do ladrão de livros.

kubectl apply -f - <<EOF
##################################################################################################
# bookstore policy
##################################################################################################
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer", "cluster.local/ns/bookthief/sa/bookthief"]
        - source:
            namespaces: ["bookbuyer", "bookthief"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]
---
##################################################################################################
# bookwarehouse policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "bookwarehouse"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: bookwarehouse
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookstore/sa/bookstore"]
        - source:
            namespaces: ["bookstore"]
      to:
        - operation:
            methods: ["POST"]
---
##################################################################################################
# mysql policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "mysql"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: mysql
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookwarehouse/sa/bookwarehouse"]
        - source:
            namespaces: ["bookwarehouse"]
      to:
         - operation:
            ports: ["3306"]
EOF

A interface do usuário ladrão de livros agora deve incrementar livros da livraria v1.

Configurar a mudança de tráfego entre duas versões de serviço

Para demonstrar como equilibrar o tráfego entre duas versões de um serviço Kubernetes, conhecido como deslocamento de tráfego no Istio. Como você lembra em uma seção anterior, a implementação do OSM de deslocamento de tráfego dependia de dois serviços distintos sendo implantados e adicionando esses nomes de serviço à configuração de back-end da TrafficTarget política. Essa arquitetura de implantação não é necessária para como o Istio implementa a mudança de tráfego. Com o Istio, podemos criar várias implantações que representam cada versão do aplicativo de serviço e transferir o tráfego para essas versões específicas por meio da configuração do Istio virtualservice .

O atualmente implantado virtualservice tem apenas uma regra de rota para a versão v1 da livraria mostrada abaixo:

spec:
  hosts:
    - bookstore
  http:
    - route:
        - destination:
            host: bookstore
            subset: v1

Atualizamos o virtualservice para deslocar 100% do peso para a versão v2 da livraria.

kubectl apply -f - <<EOF
# Create bookstore virtual service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookstore-virtualservice
  namespace: bookstore
spec:
  hosts:
  - bookstore
  http:
  - route:
    - destination:
        host: bookstore
        subset: v1
      weight: 0
    - destination:
        host: bookstore
        subset: v2
      weight: 100
EOF

Agora você deve ver o incremento e bookthief a interface do usuário somente para o bookbuyerbookstore serviço v2. Você pode continuar a experimentar alterando o atributo para deslocar o weigth tráfego entre as duas bookstore versões.

Resumo

Esperamos que este passo a passo tenha fornecido a orientação necessária sobre como migrar suas políticas atuais de OSM para as políticas do Istio. Reserve um tempo e analise os Conceitos do Istio e percorra o guia de Introdução do próprio Istio para aprender a usar a malha de serviço do Istio para gerenciar seus aplicativos.