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

Artigo
09/25/2024

Importante

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

Este artigo fornece diretrizes 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 Livraria do OSM como uma referência base para 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 SMI do OSM usando o equivalente do Istio.

Se você não estiver usando o OSM e for novo no Istio, comece com o próprio guia de Introdução do Istio para saber como usar a malha de serviço do Istio para seus aplicativos. Se você estiver usando o OSM no momento, verifique se está familiarizado com o passo a passo do aplicativo de exemplo Livraria do OSM sobre como o OSM configura as políticas 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 relevantes. Você deve estar confortável e totalmente ciente da arquitetura do aplicativo Livraria antes de continuar.

Pré-requisitos

Uma assinatura do Azure. Caso não tenha uma assinatura do Azure, é possível criar uma conta gratuita.
A CLI do Azure instalada.
O complemento AKS do OSM é desinstalado do cluster do AKS
Qualquer aplicativo Livraria do OSM existente, incluindo namespaces, é desinstalado e excluído do cluster
Instalar o complemento de malha de serviço do Istio do AKS

Modificações necessárias ao aplicativo de exemplo Livraria do OSM

Para permitir que o Istio gerencie o aplicativo Livraria do OSM, há algumas alterações necessárias nos manifestos existentes. Essas mudanças são com a livraria e os serviços MySQL.

Modificações da Livraria

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

A implementação do OSM da mudança de tráfego baseia-se na especificação de divisão de tráfego SMI. A especificação de divisão de tráfego SMI 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 deslocar 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 uma regra de destino.

Simplificando, o serviço virtual do 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 que os clientes sejam direcionados. Várias implantações podem ser rotuladas para o mesmo serviço, representando diferentes versões do aplicativo por trás do mesmo nome do host. Em seguida, o serviço virtual do Istio pode 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 atributo subsets em uma regra de destino Istio.

A modificação feita no serviço de livraria e na implantação do Istio remove a necessidade de ter um segundo serviço explícito para ser direcionado, o que a divisão de tráfego SMI precisa. Não há necessidade de ter outra conta de serviço para o serviço de livraria v2 também, pois ela deve ser consolidada sob o serviço de livraria. A modificação de manifesto do OSM traffic-access-v1.yaml original no 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 deslocamento de tráfego posteriormente no passo a passo:

Modificações do MySQL

As alterações no conjunto com estado MySQL só são necessárias na configuração do serviço. Sob a especificação de serviço, o OSM precisava dos atributos targetPort e appProtocol. Esses atributos não são necessários para o Istio. O seguinte serviço atualizado para o mysqldb é semelhante a:

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

Implantar o aplicativo Livraria modificado

Semelhante ao passo a passo da Livraria OSM, começamos com uma nova instalação do aplicativo de 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 do Istio

Para OSM, o uso do comando osm namespace add <namespace> criou as anotações necessárias para o namespace do controlador OSM para adicionar injeção automática de sidecar. Com o Istio, você só precisa rotular um namespace para permitir que o controlador do Istio seja instruído a injetar automaticamente os proxies de sidecar do 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 do Istio e a regra de destino para a Livraria

Conforme mencionado anteriormente na seção Modificação da Livraria, o Istio manipula a mudança de tráfego utilizando um atributo de peso VirtualService que configuramos posteriormente 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 seja implantada. O serviço virtual Istio está fornecendo apenas 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 de livraria versão 2. O OSM precisava configurar o tráfego para ser dividido entre solicitações de cliente usando um TrafficSplit. Ao usar a mudança de tráfego com o Istio, podemos referenciar a mudança de tráfego para várias implantações de aplicativos do Kubernetes (versões) rotuladas para o mesmo serviço.

Neste passo a passo, a implantação de ambas as versões da livraria (v1 e v2) é implantada ao mesmo tempo. Somente a versão 1 pode ser acessada 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 posteriormente quando atualizamos o serviço virtual da livraria e fornecemos o atributo de peso necessário para fazer a mudança de 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 aplicativos bookbuyer, bookthief, bookstore, bookwarehouse e 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, só estamos preocupados em exibir as interfaces do usuário bookbuyer e bookthief.

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 - bookbuyer

http://localhost:8083 - bookthief

Configurar políticas de tráfego do Istio

Para manter a continuidade com o passo a passo original da Livraria do OSM para a tradução para 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 o tráfego na malha sem nenhuma regra de Controle de Acesso de tráfego SMI específica implantada. A configuração do modo de tráfego permissivo existia para permitir que os usuários integrassem aplicativos na malha, ao mesmo tempo em que 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 aplicativo assim que o OSM o gerenciasse, fornecer tempo para definir suas regras e ao mesmo tempo garantir que as comunicações do aplicativo fossem criptografadas por mTLS. Essa configuração pode ser definida como true ou false por meio do MeshConfig do OSM.

O Istio lida com a imposição de 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 o tráfego de texto sem formatação e mTLS. O equivalente à configuração de modo permissivo do OSM é utilizar as configurações PeerAuthentication do Istio. PeerAuthentication pode ser feito granularmente no namespace ou em toda a malha. Para obter mais informações sobre a imposição de mTLS pelo Istio, leia o artigo Migração de TLS Mútua do Istio.

Impor o modo Istio estrito em namespaces de livraria

É importante lembrar que, assim como o modo permissivo do OSM, a configuração PeerAuthentication do Istio está relacionada apenas ao uso da imposição de mTLS. As políticas reais de camada 7, assim como as usadas em HTTPRouteGroups do OSM, são tratadas usando as configurações authorizationPolicy do Istio que você vê posteriormente no passo a passo.

Colocamos granularmente os namespaces bookbuyer, bookthief, bookstore e 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 destino de tráfego SMI e especificações de tráfego SMI do OSM para definir políticas de controle de acesso e roteamento para que os aplicativos se comuniquem, o Istio realiza esses controles de granularidade semelhantes usando configurações AuthorizationPolicy.

Vamos percorrer a tradução da política TrafficTarget da livraria, que permite especificamente que bookbuyer se comunique com ela, com apenas determinados caminhos, cabeçalhos e métodos de camada 7. Veja a seguir 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ê observar na política TrafficTarget, a 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 origem bookbuyer seja autorizada a se comunicar com a livraria de destino. Se convertermos a autorização de serviço para serviço de uma configuração de OSM TrafficTarget para um Istio AuthorizationPolicy, se parecerá com o seguinte:

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 AuthorizationPolicy do Istio, você percebe como o serviço de destino da política TrafficTarget do OSM é 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 em que há um atributo de origem/princípios que mapeia para o nome da conta de serviço para o serviço bookbuyer.

Além de apenas a configuração de origem/destino no TrafficTarget do OSM, o OSM associa o uso de um HTTPRouteGroup para definir ainda mais 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 match com o nome books-bought que permite que a origem acesse o caminho /books-bought usando um método GET com informações de usuário-agente de cabeçalho de host e cliente-aplicativo e uma correspondência buy-a-book que usa um regex express para um caminho que contém .*a-book.*new usando um método GET.

Podemos definir essas configurações de HTTPRouteGroup do OSM na seção de regras do Istio AuthorizationPolicy mostrado 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 bookthief, então a interface do usuário bookthief 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

Permitindo que o aplicativo Bookthief acesse a Livraria

Atualmente, não há nenhum AuthorizationPolicy que permita que o bookthief se comunique com a livraria. Podemos implantar o seguinte AuthorizationPolicy para permitir que o bookthief se comunique com a livraria. Observe a adição da regra para a política de livraria que permite a autorização do bookthief.

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 do bookthief agora deve estar incrementando 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 do Kubernetes, conhecido como deslocamento de tráfego no Istio. Como você lembra de uma seção anterior, a implementação do OSM de mudança de tráfego dependia de dois serviços distintos sendo implantados e de adicionar esses nomes de serviço à configuração de back-end da política TrafficTarget. 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 deslocar o tráfego para essas versões específicas por meio da configuração virtualservice do Istio.

O virtualservice implantado atualmente 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 da interface do usuário bookbuyer e bookthief somente para o serviço v2 bookstore. Você pode continuar a experimentar alterando o atributo weigth para deslocar o tráfego entre as duas versões bookstore.

Resumo

Esperamos que esse passo a passo tenha fornecido as diretrizes necessárias sobre como migrar suas políticas atuais do OSM para as políticas do Istio. Reserve um tempo para examinar os Conceitos do Istio e percorrer o próprio guia de Introdução do Istio para saber como usar a malha de serviço do Istio para gerenciar seus aplicativos.

Compartilhar via