Configure Istio
Istio is an open source service mesh that layers transparently onto existing distributed applications. It provides a uniform and more efficient way to secure, connect, and monitor services. This document describes how to configure Istio on StreamNative Platform to expose KoP, MoP, AoP, the Pulsar broker, StreamNative Console, and Grafana services.
Prerequisites
sn-platform
chart: 1.6.2 or higherpulsar-operator
chart: 0.12.3 or higher- cert-manager operator: v1.0.0 or higher
- Install kubectl v1.16 or higher.
- Install Helm 3.0 or higher.
- Install the istioctl CLI tool.
Limitations
In the sn-platform
chart versions prior to 1.6.2, it is not supported to expose HTTP requests through Pulsar Proxy when Istio is enabled. Therefore, it is recommended to disable Pulsar Proxy when you want to enable Istio.
Install Istio
This section describes how to install Istio with the Istio operator. For other Istio installation methods, see installation guides.
-
Go to the Istio release page to download the installation file for your Operating System (OS), or download and extract the latest release automatically (Linux or macOS):
The command above downloads the latest release (numerically) of Istio. You can pass variables on the command line to download a specific version or to override the processor architecture. For example, to download Istio 1.13.1
for the x86_64
architecture, execute the following command:
-
Move to the Istio package directory. For example, if the package is
istio-1.13.1
: -
Install the Istio operator.
Install Istio Ingress Gateway
Istio Ingress Gateway describes a load balancer operating at the edge of the Pulsar that receives incoming HTTP/TCP connections. It configures exposed ports, protocols, etc.
-
Define a YAML file of the Istio Ingress Gateway.
This example defines an Istio Ingress Gateway YAML file (
ingressgateway.yaml
), which configures gateways on different ports for KoP, MoP, AoP, HTTPS, TLS, and HTTP services. -
Apply the YAML file to install the Istio Ingress Gateway.
-
View whether configurations are applied successfully.
Example output
From the above output you can see that the Istio Ingress Gateway is installed successfully.
- If the
EXTERNAL-IP
value is set, your environment has an external load balancer that you can use for the Istio Ingress Gateway. If theEXTERNAL-IP
value is<none>
(or perpetually<pending>
), your environment does not provide an external load balancer for the Istio Ingress Gateway. In this case, you can access the Istio Ingress Gateway using the service’s node port. - If you have an external load balancer for your Kubernetes cluster, you need to specify the port
9093
, port8883
, port5671
, and port6651
for KoP, MoP, AoP, and the Pulsar Broker respectively on the load balancer. - If you do not have an external load balancer for your Kubernetes cluster, you need to specify the node port
9093
for KoP, the node port8883
for MoP, the node port5671
for AoP, and the node port6651
for the Pulsar Broker. By default, Kubernetes does not permit port9093
, port8883
, or port6651
. Therefore, you need to add the--service-node-port-range=6000-40000
field at the/etc/kubernetes/manifests/kube-apiserver.yaml
Kubernetes API server configuration file and then use thesystemctl restart kubelet
command to restart the Kubernetes API server to reload new configurations.
Enable Istio Gateway
This section describes how to enable the Istio Gateway.
Configure TLS Ingress Gateway
Certificates can be issued in multiple methods. This section describes two methods. You can choose either of them to issue certificates for the Istio Ingress Gateway.
openssl
This section describes how to manually configure the TLS Ingress Gateway to expose a secure service using TLS.
-
Generate client and server certificates and keys.
a. Create a root certificate and private key to sign the certificates for your services.
b. Create a certificate and a private key.
-
Create a secret for the Istio Ingress Gateway.
cert-manager
cert-manager supports issuing certificates through different issuers. You can use either an internal or a public issuer to issue the certificates.
To generate certificates with an internal issuer, you can set certs.istio_internal_issuer.enabled
to true
in the values.yaml
YAML file and then use the helm upgrade
command to update the resource. The certificates generated by the internal issuer are self-signed certificates.
-
[1]
enabled
: use an internal issuer. -
[2]
type
: specify the type of the internal issuer.-
selfsigning
: theselfsigning
issuer generates a Certificate Authority (CA) based on an automatically-generated secret. You can use the private key of the certificate to sign the certificate itself. -
secret
: thesecret
issuer represents a CA whose certificate and private key are stored inside the cluster as a Kubernetes Secret. Then, you can use the Kubernetes Secret to sign a certificate. -
custom
: you can specify an internal issuer through this option. For example, you can specify using Vault to sign certificates for your PKI, as shown below.
-
-
[3]
issuers
and its sub fields: the configuration of the internal issuer.selfsigning
: theselfsigning
issuer has no dependency on any other resource. Therefore, you do not need to configure any item for this issuer.secret
:secretName
is the name of the Secret resource that is automatically created and managed by the CA. It is populated with a private key and certificate, signed by the issuer.custom
: you can configure items for custom certificate issuers. For more detailed configurations, see the cert-manager documentation.
To generate certificates with an internal issuer, you can set certs.istio_internal_issuer.enabled
to true
in the values.yaml
YAML file and then use the helm upgrade
command to update the resource. The certificates generated by the internal issuer are self-signed certificates.
-
[1]
enabled
: use an internal issuer. -
[2]
type
: specify the type of the internal issuer.-
selfsigning
: theselfsigning
issuer generates a Certificate Authority (CA) based on an automatically-generated secret. You can use the private key of the certificate to sign the certificate itself. -
secret
: thesecret
issuer represents a CA whose certificate and private key are stored inside the cluster as a Kubernetes Secret. Then, you can use the Kubernetes Secret to sign a certificate. -
custom
: you can specify an internal issuer through this option. For example, you can specify using Vault to sign certificates for your PKI, as shown below.
-
-
[3]
issuers
and its sub fields: the configuration of the internal issuer.selfsigning
: theselfsigning
issuer has no dependency on any other resource. Therefore, you do not need to configure any item for this issuer.secret
:secretName
is the name of the Secret resource that is automatically created and managed by the CA. It is populated with a private key and certificate, signed by the issuer.custom
: you can configure items for custom certificate issuers. For more detailed configurations, see the cert-manager documentation.
To generate certificates with the public issuer, you can specify the certs.istio_public_issuer.enabled
to true
in the values.yaml
YAML file and configure the information about the public issuer. Then, you can use the helm upgrade
command to update the resource.
This example shows how to use the ACME public issuer to issue certificates. For a list of available issuers, see the cert-Manager official documentation.
- [1]
enabled
: use a public issuer. - [2]
type
: specify the type of the certificate issuer. - [3]
acme
and its sub fields: the configuration of the ACME public issuer.
Enable Istio Gateway and expose services through the Pulsar broker
This example enables the Istio Gateway, specifies values for certSecretName
(the name of the Kubernetes secret that was created in the previous step), and defines the URLs for the Pulsar broker and StreamNative Console.
-
Configure the Istio Gateway for StreamNative Platform in the
values.yaml
YAML file as follows:-
[1]
namespace
: the default namespace for the Istio gateway. By default, it is set toistio-system
. -
[2]
mode
: the TLS mode for the Istio gateway. Available options areSIMPLE
andPASSTHROUGH
. By default, it is set toSIMPLE
.-
SIMPLE
: terminate TLS traffic at the Istio gateway. In this case, the gateway certificate is used. -
PASSTHROUGH
: do not terminate TLS traffic at the Istio gateway. Instead, terminate TLS traffic at the component. In this case, the certificate that is mount to the component is used. Therefore, you need to configure the gateway TLS of the Pulsar broker in thevalues.yaml
YAML file, as shown below.
-
-
Currently, the PASSTHROUGH
TLS mode is not available for the StreamNative Console. You still need to configure the certSecretName
option for the StreamNative Console.
-
[3]
certSecretName
: the name of the Kubernetes Secret. It can also either be a certificate issued by the internal or the external issuer. If neither the internal nor the external issuer is configured, there should be a Secret namedcertSecretName
that contains certificates under the Istio Gateway namespace. -
[4][5]
external_domain
: Pulsar Broker generates the Pod domain names based on theadvertisedDomain
field (the domain of the Pulsar Broker). Therefore, you must include the suffix of the external domains for Pulsar Broker and control center in thedomain.suffix
. As shown below, if the external domains for Pulsar Broker and control center are set tobroker.example.com
andcontrol_center.example.com
respectively, thedomain.suffix
should be set toexample.com
.
Enable Istio Gateway and expose service through the Pulsar Proxy
This example enables the Istio Gateway, specifies values for certSecretName
(the name of the Kubernetes secret that was created in the previous step), and defines the URLs for the Pulsar Proxy and StreamNative Console.
-
Configure the Istio Gateway for StreamNative Platform in the
values.yaml
YAML file as follows:- [1]
namespace
: the default namespace for the Istio gateway. By default, it is set toistio-system
. - [2]
certSecretName
: the name of the Kubernetes Secret. It can also either be a certificate issued by the internal or the external issuer. If neither the internal nor the external issuer is configured, there should be a Secret namedcertSecretName
that contains certificates under the Istio Gateway namespace. - [3]
type
: the method of exposing the Pulsar Proxy service. It should be set toIstioGateway
when Istio is enabled. - [4][5]
external_domain
: if the external domains for the Pulsar Proxy and the control center are set toproxy.example.com
andcontrol_center.example.com
respectively, thedomain.suffix
should be set toexample.com
.
- [1]
-
Apply the new configuration.
Access ingress services
This section describes how to access KoP, MoP, the Pulsar broker, StreamNative Console, and Grafana after installing Istio and Istio Ingress Gateway, and enabling Istio Gateway.
Access KoP
To access KoP, follow these steps.
-
Configure the Kafka client.
a. Create a certificate in the JKS format. This example creates a self-signed JKS certificate.
If you use a certificate signed by a public issuer, you do not need to configure the certificate on the Kafka client.
b. Create the Kafka client configuration file (client.properties
).
-
Configure the DNS address.
a. Get the related host domains.
The output looks similar to:
b. Configure the DNS address in
/etc/hosts
. -
Connect to KoP via the Kafka client.
a. Start a Kafka producer and send a message from the Kafka producer.
b. Open a new terminal window and enter the Kafka Pod.
c. Start a Kafka consumer.
Access MoP
To access MoP using the Eclipse Mosquitto MQTT CLI tool, follow these steps.
- Create a Kubernetes Secret (
mqtt-cert
) using the CA certificate that is generated in configure TLS Ingress Gateway.
If you use a certificate signed by a public issuer, you do not need to configure the certificate on MoP.
-
Deploy an MQTT client Pod.
a. Define an MQTT client Pod as below and save the YAML file (
pod.yaml
).b. Apply your configurations.
-
Enter the MQTT client Pod and configure the DNS address in
/etc/hosts
. -
Connect to MoP using the MQTT client.
a. Publish messages to the Pulsar cluster.
i. Open a new terminal window and enter the MQTT client Pod.
ii. Publish messages to the Pulsar cluster.
b. Subscribe to messages from the Pulsar cluster.
i. Open a new terminal window and enter the MQTT client Pod.
ii. Subscribe to messages from the Pulsar cluster.
Access AoP
To access AoP using the RabbitMQ client, follow these steps.
-
Create a Pulsar namespace and set the retention policy for the namespace.
This example shows how to use the pulsar-admin CLI tool to create a Pulsar namespace named
vhost1
and set the retention size and retention time to 100M and 2 days, respectively. -
Create a Maven project and add a dependency to the RabbitMQ client.
-
Connect to AoP using the RabbitMQ client.
- [1]
connectionFactory.setVirtualHost
: represent the Pulsar namespace for AoP. - [2]
connectionFactory.setHost
: represent the endpoint for Pulsar service. - [3]
connectionFactory.setPort
: represent the port ID for AoP. It is set to port5671
.
- [1]
Access a Pulsar broker
To access a Pulsar broker, follow these steps:
- Create a certificate. For details, see configure TLS Ingress Gateway.
If you use a certificate signed by a public issuer, you do not need to configure the certificate on the Pulsar broker.
-
Update the Pulsar broker configuration file (
conf/client.conf
). -
Validate the configuration by producing and consuming data with the
pulsar-client
CLI tool.
Access the StreamNative Console
- Create a certificate. For details, see configure TLS Ingress Gateway.
If you use a certificate signed by a public issuer, you do not need to configure the certificate on the StreamNative Console.
-
Verify whether you can connect to the StreamNative Console using the self-signed certificate.
Access Grafana
- Create a certificate. For details, see configure TLS Ingress Gateway.
If you use a certificate signed by a public issuer, you do not need to configure the certificate on Grafana.
-
Verify whether you can connect to the Grafana service using the self-signed certificate.