Назад к микросервисам вместе с istio. часть 2 / хабр

Validating Istio configuration

Kiali can validate your Istio resources to ensure they follow proper conventions and semantics. Any problems detected in the configuration of your Istio resources can be flagged as errors or warnings depending on the severity of the incorrect configuration. See the Kiali validations page for the list of all validation checks Kiali performs.

Force an invalid configuration of a service port name to see how Kiali reports a validation error.

Change the port name of the service from to :
Navigate to the Services list by clicking Services on the left hand navigation bar.
Select from the Namespace drop down menu if it is not already selected.
Notice the error icon displayed in the Configuration column of the row.

Services List Showing Invalid Configuration
Click the details link in the Name column to navigate to the service details view.
Hover over the error icon to display a tool tip describing the error.

Service Details Describing the Invalid Configuration
Change the port name back to to correct the configuration and return back to its normal state.

Service Details Showing Valid Configuration

Egress gateway for HTTPS traffic

In this section you direct HTTPS traffic (TLS originated by the application) through an egress gateway.
You need to specify port 443 with protocol in a corresponding , an egress and a .

Define a for :
Verify that your was applied correctly by sending an HTTPS request to https://edition.cnn.com/politics.
Create an egress for edition.cnn.com, a destination rule and a virtual service
to direct the traffic through the egress gateway and from the egress gateway to the external service.
Send an HTTPS request to https://edition.cnn.com/politics.
The output should be the same as before.
Check the log of the egress gateway’s proxy. If Istio is deployed in the namespace, the command to
print the log is:

You should see a line similar to the following:

Kiali

Kiali – это отличный инструмент для того, чтобы начать работать с OpenShift Service Mesh. Можно даже сказать, что именно на нем и надо сосредоточиться, когда вы начинаете работать с mesh-сеткой.

Kiali визуализирует метрики, генерируемые Istio, и помогает понять, что происходит в mesh-сетке. В качестве одной из первоочередных задач мы настоятельно рекомендуем изучить документацию Kiali.

Kiali не только пригодится для визуализации вашего приложения, но и поможет с созданием, проверкой и управлением конфигурациями mesh-сетки. Поначалу изучение конфигураций Istio может быть делом сложным, и Kiali тут сильно поможет.

В Kiali есть много полезных вещей, поэтому мы очень советуем изучить список ее возможностей и FAQ. Например, там есть следующие интересные вещи:

Другая важная вещь – умение маркировать сервисы приложения с помощью меток (label). Istio, а следовательно и Kiali, требует, чтобы маркировка велась строго определенным образом, который поначалу отнюдь не кажется очевидным, особенно когда весь ваш опыт исчерпывается работой с приложением-примером Bookinfo, где все метки уже есть и всё прекрасно работает «из коробки».

Развертывания с использованием меток app и version – это важно, поскольку они добавляет контекстную информацию к метрикам и телеметрии, которые собираются Istio и затем используются в Kiali и Jaeger. Istio может показать такие связи между внутренними и внешними сервисами, о существовании которых вы даже не догадывались

Это полезно, но иногда может раздражать при просмотре графа. К счастью, с графа всегда можно убрать эти

Istio может показать такие связи между внутренними и внешними сервисами, о существовании которых вы даже не догадывались. Это полезно, но иногда может раздражать при просмотре графа. К счастью, с графа всегда можно убрать эти .

Еще одна полезная вещь в Kiali – это то, что она может , что особенно полезно, когда вы сами создаете конфигурации.

Поначалу графы Kiali могут несколько обескураживать. Поэтому стоит изучить различные типы графов, начав с того, как и какие бывают .

NamespacePolicy

kubectl apply -f istio-namespace-policy.yaml

then

curl -vk https://$GATEWAY_IP/version< HTTP/2 200< x-powered-by: Express< content-type: text/html; charset=utf-8< content-length: 1< etag: W/"1-xMpCOKC5I4INzFCab3WEmw"< date: Thu, 06 Dec 2018 23:16:36 GMT< x-envoy-upstream-service-time: 97< server: istio-envoy1

but access to the backend gives:

curl -vk https://$GATEWAY_IP/hostz< HTTP/2 200< x-powered-by: Express< content-type: application/json; charset=utf-8< content-length: 106< etag: W/"6a-dQwmR/853lXfaotkjDrU4w"< date: Thu, 06 Dec 2018 23:30:17 GMT< x-envoy-upstream-service-time: 52< server: istio-envoy[  {    "url": "http://be.default.svc.cluster.local:8080/backend",    "body": "RBAC: access denied",    "statusCode": 403  }]

This is because the namespace rule we setup allows the and namespace access to any service that matches the label

labels:    app: myapp

but our backend has a label of

selector:    app: be

If you want to verify, just add that label () to and apply

Anyway, lets revert the namespace policy to allow access back again

kubectl delete -f istio-namespace-policy.yaml

You should now just see while accessing any page

Introduction to Istio

Istio is an open-source implementation of the service mesh originally developed by IBM, Google, and Lyft. It can layer transparently onto a distributed application and provide all the benefits of a service mesh like traffic management, security, and observability.

It’s designed to work with a variety of deployments, like on-premise, cloud-hosted, in Kubernetes containers, and in servicers running on virtual machines. Although Istio is platform-neutral, it’s quite often used together with microservices deployed on the Kubernetes platform.

Fundamentally, Istio works by deploying an extended version of Envoy as proxies to every microservice as a sidecar:

This network of proxies constitutes the data plane of the Istio architecture. The configuration and management of these proxies are done from the control plane:

The control plane is basically the brain of the service mesh. It provides discovery, configuration, and certificate management to Envoy proxies in the data plane at runtime.

Of course, we can only realize the benefit of Istio when we have a large number of microservices that communicate with each other. Here, the sidecar proxies form a complex service mesh in a dedicated infrastructure layer:

Istio is quite flexible in terms of integrating with external libraries and platforms. For instance, we can integrate Istio with an external logging platform, telemetry, or policy system.

Ingress Gateway Secret in 1.0.0+

Note the secret specifies the Ingress cert to use (the specific metadata name is special and is required)

apiVersion: v1data:  tls.crt: _redacted_  tls.key: _redacted_kind: Secretmetadata:  name: istio-ingressgateway-certs  namespace: istio-systemtype: kubernetes.io/tls

Remember we’ve acquired the earlier:

export GATEWAY_IP=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress.ip}')echo $GATEWAY_IP

Send Traffic

This section shows basic user->frontend traffic and see the topology and telemetry in the Kiali and Grafana consoles:

Viewing and editing Istio configuration YAML

Kiali provides a YAML editor for viewing and editing Istio configuration resources. The YAML editor will also provide validation messages
when it detects incorrect configurations.

Create Bookinfo destination rules:
Click on the left hand navigation bar to navigate to the Istio configuration list.
Select from the Namespace drop down menu if it is not already selected.
Notice the error message and the error icons that alert you to several configuration problems.

Istio Config List Incorrect Configuration Messages
Click the error icon in the Configuration column of the row to navigate to the destination rule view.
The YAML tab is preselected. Notice the color highlights and icons on the rows that have failed validation checks.

YAML Editor Showing Validation Errors and Warnings
Hover over the red icon to view the tool tip message that informs you of the validation check that triggered the error.
For more details on the cause of the error and how to resolve it, look up the validation error message on the
Kiali Validations page.

YAML Editor Showing Error Tool Tip
Delete the destination rules to return back to its original state.

Install CNI

Prerequisites

Install Kubernetes with the container runtime supporting CNI and configured
with the main CNI plugin enabled via .
- AWS EKS, Azure AKS, and IBM Cloud IKS clusters have this capability.
- Google Cloud GKE clusters have CNI enabled when any of the following features are enabled:
  network policy,
  intranode visibility,
  workload identity,
  ,
  or dataplane v2.
- OpenShift has CNI enabled by default.
Install Kubernetes with the enabled.

The Kubernetes documentation highly recommends this for all Kubernetes installations
where ServiceAccounts are utilized.

Install Istio with CNI plugin

In most environments, a basic Istio cluster with CNI enabled can be installed using the following configuration:

This will deploy an DaemonSet into the cluster, which installs the Istio CNI plugin binary to each node and sets up the necessary configuration for the plugin.
The CNI DaemonSet runs with .

Istio CNI

There are several commonly used install options:

configures the namespace to install the CNI DaemonSet.
and configure the directory paths to install the plugin binary and create plugin configuration.
configures the name of the plugin configuration file.
controls whether to configure the plugin as a chained CNI plugin.

Hosted Kubernetes settings

The plugin is expected to work with any hosted Kubernetes version using CNI plugins.
The default installation configuration works with most platforms.
Some platforms required special installation settings.

Google Kubernetes Engine

Red Hat OpenShift 4.2+

What is a Service Mesh?

Modern applications are typically architected as distributed collections of microservices, with each collection of microservices performing some discrete business function. A service mesh is a dedicated infrastructure layer that you can add to your applications. It allows you to transparently add capabilities like observability, traffic management, and security, without adding them to your own code. The term “service mesh” describes both the type of software you use to implement this pattern, and the security or network domain that is created when you use that software.

As the deployment of distributed services, such as in a Kubernetes-based system, grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often addresses more complex operational requirements, like A/B testing, canary deployments, rate limiting, access control, encryption, and end-to-end authentication.

Распространение заголовков контекста трассировки

Jaeger помогает убрать одну из проблем, которая возникает при переходе на микросервисную архитектуру, но для этого все сервисы вашего приложения должны правильно распространять заголовки трассировки (trace headers).

Очень полезно отслеживать, как запросы ходят через сервисы (или даже множество сервисов) в вашей mesh-сетке. OSSM может здесь помочь за счет сбора данных в форме span’ов и трасс (trace). Просмотр трасс очень помогает понять сериализацию, параллелизм и источники задержек в вашем приложении. Вкратце, span – это интервал от начала выполнения единицы работы до ее завершения (например, полная отработка запроса «клиент-сервер»). Трасса – это путь, по которому запрос проходит, двигаясь по mesh-сети, или, другими словами, по мере того, как он передается от одного сервиса вашего приложения к другому. Подробнее об этом можно – и нужно – почитать в .

Обратите внимание, что в OSSM span’ы (единицы работы) автоматически генерируются средствами Istio, а вот трассы – нет. Поэтому чтобы распределенные трассы (distributed traces) были полностью просматриваемыми, разработчик должен изменить код так, чтобы любые существующие trace-заголовки правильно копировались при передаче запроса между сервисами

К счастью, вы не обязаны сами генерировать эти заголовки. Если изначально их нет, то они будут автоматически сгенерированы и добавлены первым Envoy-прокси, который встретится на пути запроса (обычно это прокси на ingress-шлюзе).

Вот список заголовков для распространения:

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

Распространение заголовков может выполняться вручную или с использованием клиентских библиотек Jaeger, реализующих OpenTracing API.

Вот как делается ручное распространение trace-контекста на Java:

Примечание: это надо повторить для всех заголовков из списка выше.

What Is a Service Mesh?

Over the past couple of decades, we’ve seen how monolithic applications have started to decompose into smaller applications. It has found unprecedented popularity with cloud-native computing and microservices architecture. Further, containerization technology like Docker and orchestration system like Kubernetes have only helped in this regard.

While there are a number of advantages for adopting microservices architecture on a distributed system like Kubernetes, it has its fair share of complexities. Since distributed services have to communicate with each other, we have to think about discovery, routing, retries, and fail-over.

There are several other concerns like security and observability that we also have to take care of:

Now, building these communication capabilities within each service can be quite tedious — even more so when the service landscape grows and communication becomes complex. This is precisely where a service mesh can help us. Basically, a service mesh takes away the responsibility of managing all service-to-service communication within a distributed software system.

The way service mesh is able to do that is through an array of network proxies. Essentially, requests between services are routed through proxies that run alongside the services but sit outside in the infrastructure layer:

These proxies basically create a mesh network for the services — hence the name, service mesh! Through these proxies, a service mesh is able to control every aspect of service-to-service communication. As such, we can use it to address the eight fallacies of distributed computing, a set of assertions that describe false assumptions we often make about a distributed application.

Controlled access to external services

Using Istio configurations, you can access any publicly accessible service
from within your Istio cluster. This section shows you how to configure access to an external HTTP service,
httpbin.org, as well as an external HTTPS service,
www.google.com without losing Istio’s traffic monitoring and control features.

Change to the blocking-by-default policy

To demonstrate the controlled way of enabling access to external services, you need to change the
option from the mode to the mode.

Change the option to .

If you used an CR to install Istio, add the following field to your configuration:

Otherwise, add the equivalent setting to your original command, for example:
Make a couple of requests to external HTTPS services from to verify that they are now blocked:

Access an external HTTP service

Create a to allow access to an external HTTP service.
Make a request to the external HTTP service from :

Note the headers added by the Istio sidecar proxy: .
Check the log of the sidecar proxy of :

Note the entry related to your HTTP request to .

Access an external HTTPS service

Create a to allow access to an external HTTPS service.
Make a request to the external HTTPS service from :
Check the log of the sidecar proxy of :

Note the entry related to your HTTPS request to .

Manage traffic to external services

Similar to inter-cluster requests, Istio

can also be set for external services that are accessed using configurations.
In this example, you set a timeout rule on calls to the service.

From inside the pod being used as the test source, make a curl request to the endpoint of the
httpbin.org external service:

The request should return 200 (OK) in approximately 5 seconds.
Use to set a 3s timeout on calls to the external service:
Wait a few seconds, then make the curl request again:

This time a 504 (Gateway Timeout) appears after 3 seconds.
Although httpbin.org was waiting 5 seconds, Istio cut off the request at 3 seconds.

Что такое service mesh?

data planecontrol plane(т.е. «учитывающие» 7 уровень модели OSI)между(Прим. перев.: сравнение существующих контроллеров Ingress для Kubernetes, многие из которых используют уже упомянутый Envoy, см. в этой статье.)sidecar-контейнерможноогромного

Прокси в data plane должны быть быстрыми, поскольку на каждый вызов приходится пара обращений к прокси: одно на стороне клиента, одно — на стороне сервера.
Также прокси должны быть небольшими и легковесными. Каждая будет потреблять ресурсы памяти и CPU, и это потребление будет линейно расти вместе с приложением.
Вам понадобится механизм для развертывания и обновления большого количества прокси. Делать это вручную — не вариант.

503 errors after setting destination rule

If requests to a service immediately start generating HTTP 503 errors after you applied a
and the errors continue until you remove or revert the , then the is probably
causing a TLS conflict for the service.

For example, if you configure mutual TLS in the cluster globally, the must include the following :

Otherwise, the mode defaults to causing client proxy sidecars to make plain HTTP requests
instead of TLS encrypted requests. Thus, the requests conflict with the server proxy because the server proxy expects
encrypted requests.

Whenever you apply a , ensure the TLS mode matches the global server configuration.

Зачем нужен service mesh?

Service mesh предназначен для решения некоторых проблем, присущих распределенным архитектурам приложений.

Эти архитектуры выросли из трехуровневой модели приложений, которая включает уровень клиента, логики и данных. В результате такая модель оказалась сложной для быстро растущих организаций. Кодовые базы монолитных приложений могут стать громоздкими, что создает проблемы в разработке и развертывании.

Чтобы решить эту проблему, такие организации, как Google, Netflix и Twitter, разработали внутренние библиотеки «толстых клиентов» для стандартизации операций в среде выполнения между сервисами. Эти библиотеки обеспечивали балансировку нагрузки, маршрутизацию и телеметрию – это предшественники service mesh. Однако они также наложили ограничения на языки, которые могли использовать разработчики, и требовали внесения изменений во все сервисы при собственном обновлении.

Микросервисный дизайн позволяет избежать некоторых из этих проблем. Вместо большой централизованной кодовой базы приложения у вас есть набор дискретно управляемых сервисов, которые представляют функцию вашего приложения. Преимущества микросервисного подхода:

Повышенная гибкость в разработке и развертывании (поскольку группы могут независимо работать и развертывать различные функции приложений).
Улучшенные функции CI/CD, поскольку отдельные микросервисы можно протестировать и перераспределить независимо.
Дополнительные параметры для языков и инструментов. Разработчики могут использовать лучшие инструменты для выполнения поставленных задач, а не ограничиваться определенным языком или набором инструментов.
Легкость в масштабировании.
Улучшения в среде выполнения и пользовательском опыте, стабильность.

Конечно, микросервисы также создали проблемы:

Распределенные системы требуют разных способов понимания задержки, маршрутизации, асинхронных рабочих процессов и сбоев.
Микросервисные установки не обязательно могут отвечать тем же требованиям к согласованности данных, что и монолитные установки.
Для более высоких уровней распределения требуются более сложные операционные схемы, особенно когда дело касается связи между сервисами.
Распределение сервисов увеличивает вероятность появления уязвимостей безопасности.

Service mesh предназначен для решения этих проблем, предлагая скоординированный и детальный контроль над взаимодействием сервисов. В следующих разделах мы расскажем, как service mesh облегчает обмен данными посредством обнаружения сервисов, маршрутизации и внутренней балансировки нагрузки, конфигурации трафика, шифрования, аутентификации и авторизации, а также метрик и мониторинга. Для примера мы будем использовать приложение Istio Bookinfo – четыре микросервиса, которые вместе отображают информацию о конкретных книгах.

Understanding what happened

In this task you looked at three ways to call external services from an Istio mesh:

Configuring Envoy to allow access to any external service.
Use a service entry to register an accessible external service inside the mesh. This is the
recommended approach.
Configuring the Istio sidecar to exclude external IPs from its remapped IP table.

The first approach directs traffic through the Istio sidecar proxy, including calls to services
that are unknown inside the mesh. When using this approach,
you can’t monitor access to external services or take advantage of Istio’s traffic control features for them.
To easily switch to the second approach for specific services, simply create service entries for those external services.
This process allows you to initially access any external service and then later
decide whether or not to control access, enable traffic monitoring, and use traffic control features as needed.

The second approach lets you use all of the same Istio service mesh features for calls to services inside or
outside of the cluster. In this task, you learned how to monitor access to external services and set a timeout
rule for calls to an external service.

The third approach bypasses the Istio sidecar proxy, giving your services direct access to any external server.
However, configuring the proxy this way does require cluster-provider specific knowledge and configuration.
Similar to the first approach, you also lose monitoring of access to external services and you can’t apply
Istio features on traffic to external services.

Prerequisites

To complete this tutorial, you will need:

A Kubernetes 1.10+ cluster with role-based access control (RBAC) enabled. This setup will use a DigitalOcean Kubernetes cluster with three nodes, but you are free to create a cluster using another method.

Note: We highly recommend a cluster with at least 8GB of available memory and 4vCPUs for this setup. This tutorial will use three of DigitalOcean’s standard 4GB/2vCPU Droplets as nodes.

The command-line tool installed on a development server and configured to connect to your cluster. You can read more about installing in the official documentation.
Helm installed on your development server and Tiller installed on your cluster, following the directions outlined in Steps 1 and 2 of How To Install Software on Kubernetes Clusters with the Helm Package Manager.
Docker installed on your development server. If you are working with Ubuntu 18.04, follow Steps 1 and 2 of How To Install and Use Docker on Ubuntu 18.04; otherwise, follow the official documentation for information about installing on other operating systems. Be sure to add your non-root user to the group, as described in Step 2 of the linked tutorial.
A Docker Hub account. For an overview of how to set this up, refer to this introduction to Docker Hub.

Заключение

С OpenShift Service Mesh вы можете лучше понять, как устроена ваша mesh-сетка, сделать ее более просматриваемой, что, в свою очередь, помогает поднять общий уровень сложности микросервисной архитектуры. Бонусом идет возможность реализовать больше функций и возможностей на уровне самой платформе OpenShift, а не кодировать их на уровне отдельных приложений, что облегчает жизнь разработчикам. Еще один плюс – реализация вещей, которые раньше казались неподъемными, например, канареечное развертывание, A/B-тестирование и т.п. Кроме того, вы получаете целостный подход к управлению микросервисными приложениями на всех своих кластерах OpenShift, что хорошо с точки зрения преемственности людей и непрерывности процессов. В конечном итоге, это поможет перейти от монолитных приложений к распределенной микросервисной архитектуре и работать в большей степени на уровне конфигураций, чем кода.