Skip to content

Latest commit

 

History

History
282 lines (184 loc) · 15.3 KB

README.adoc

File metadata and controls

282 lines (184 loc) · 15.3 KB
Raw

Kick Off Meeting: Requirements and prerequisites of using the Service Mesh

Table of Contents

Requirements Capture to Drive Mesh Adoption & Configuration

The requirements below are a summary of the Kick-Off Meeting Requirements & Targeted Outcomes session where stakeholders have stated the capabilities they would like to benefit with Servce Mesh:

  1. The Development Team want to be able to trace (every) request during development, and a sample of 20% of traffic in Production

  2. The Product Team want to see metrics around performance/usage (storing them for up to 1 week)

  3. The Security team wish to enable mTLS in all intermesh and intramesh communications

  4. The Platform Team want to centrally manage security

  5. The Development Teams want to implement some resiliency to make the overall application more stable and reliable.

User Governance Capture

The personas, roles and responsibilities are greatly affected by certain organizational, operational and governance choices around cloud application platforms. These involve (but are not limited to):

  • Type of clusters (multi domain app clusters vs focused clusters) and by extension type of meshes (multi-tenant meshes vs single cluster meshes).

  • Choices of automation for cloud service configuration (Pipelines, GitOps, other(Ansible/Scripting/ACM), none).

  • Platform (Service Mesh) Operating Model (producer-consumer platform -where admins/ops deploy all configs and devs consume- vs self-service platform).

  • Dev(Sec)Ops adopted culture for application and cloud configuration delivery (including Istio configs).

For the purpose of the provided scenarios the travel agency has selected the following options determining the Model of Operation.

Table 1. Model of Operation
# Strategy Option

1

Cluster Type

Focused Clusters

2

Automation

GitOps

3

Operating Model

Self-Service (restricted)

4

Dev(Sec)Ops

GitOps

Self-service (restricted): In this Model of Operation the teams will be able to create Istio configurations in a self-service manner with the exception of Gateway resources which will be handled by the OSSM operating admin.

Map to Enterprise Personas with Roles & Key Responsibilities setup

The outcome of the User Governance Capture workshop and the team Requirements for Mesh Adoption is the definition of the following enterprise personas to be described as those that will interact with the Service Mesh (OSSM). As Upstream Istio, and so OpenShift Service Mesh, do not define standard or default user roles this often causes confusion on what capabilities and responsibilities inside Openshift these personas should have. We have created 3 Roles for the personas and applied them to OCP See Execute Role & User Creation for the creation of users and roles in DEV and PROD environments.

Table 2. Personas & Roles
Enterprise Persona Role Who he is? What he does? Role Setup

Platform Admin

Cluster Admin

Owner of multiple OCP clusters, sets organizational policies

Cluster Admin is the Platform Owner & Operator. S/he is a cluster admin who can add/remove/update cluster operators, install container images to the image registry (in the case of a cluster disconnected environment), update the OCP version, setup cluster infrastructure, setup security.

The Cluster Admin is a super user with all privileges on a cluster and could therefore also be the Mesh Admin.

The Cluster Admin makes available the necessary cluster infrastructure and configurations (routers, networking, infra nodes, labelling, CPU/RAM resources on worker nodes) to support deployment and operation of an OCP cluster and the Service Mesh (OSSM)

The Cluster Admin is the first point of contact to make the Service Mesh (OSSM) resources available (operators, images etc.), to retrieve the cluster and operator logs needed for troubleshooting

Cluster Admin

Mesh Operator

Mesh Operator

Operates parts of the cluster and the domain based service mesh for the hosted services

The Mesh Operator is actually the Mesh Admin of either a whole cluster (Focused Cluster with Single cluster Mesh) or for a few namespaces (multi domain clusters with multi-tenant meshes) and depends on how the Operational Model of the Mesh cluster has been defined. In the Travel solution the it will be the former.

The Mesh Operator as a Mesh Admin can add/remove/update ServiceMeshControlPlane (SMCP), ServiceMeshMemberRole (SMMR), ServiceMeshMember (SMM) resources and any Istio resources (Gateway, secrets, ServiceEntry) that may be configured in the control namespace

The Mesh Operator configures the Observability stack for the Service Mesh (OSSM) control plane based either on the OSSM operator or external Tracing, Prometheus, Elastic Search resources )

The Mesh Operator is also responsible for mesh security and sets up CA, mTLS certs followed by rotation of those certificates

Mesh Operator

Domain Owner (Tech Lead)

Mesh Developer

Onboards developers in the team and understands inter/intra dependencies

Domain Owner is the Application Tech Lead who is aware of dependencies for the application from the mesh based or external applications and environment components

The Domain Owner determines the environemt required for the domain based application to operate in and defines the Istio configurations for the data plane (VirtualService, DestinationRule, ServiceEntry, Sidecar, POD Istio annotations etc.)

The Domain Owner collaborates with the Mesh Operator for ingress/egress traffic Istio configurations (eg. Gateway) and SMCP resource configurations (istio-proxy labelling, ingressgateway/egressgateway configuration, proxy default resources configurations etc.)

Mesh Developer

Developer

Application Viewer (DEV Environment)

Consumes platform, mesh and application configurations, reviews and troubleshoots application functionality and performance via KIALI UI, Jaeger telemetry, Prometheus metrics and POD logs

The Developer is a user who needs to be kept aware of the health, performance and functional correctness of their solution

The Developer should only have (view) access to KIALI visualisations for the namespace where they deploy their applications only, and has therefore a Mesh Application Viewer role.

The Developer as a Mesh Application Viewer due to current requirements of the observability stack components (Grafana, Prometheus, Jaeger) will have access to these PODs and all information included by them WARNING: NO BETTER WAY OTHER THAN GIVING ACCESS TO POD HAS BEEN FOUND TO ACCESS THE PREVVIOUS

Mesh Application Viewer

Application Ops Team

Mesh Developer (Higher -Non-Dev- Environments)

The Application Ops team monitor and maintain the applications in operation in the deployed cluster and within the domain hosted mesh (OSSM), including extracting logs, executing commands to verify state, troubleshooting in higher (non-DEV) environemnts

The Application Ops team will review POD logs and envoy proxy configurations, telemetry metrics and jaeger traces for the PODs included in the mesh to validate any functional or performance issues that may arise

The Application Ops team can extract the information (logs, traces, proxy configs) and collaborate with the Developer and Mesh Operator to determine possible application, mesh or configuration issues

The Application Ops team does not create Istio configs but can suggest changes/corections to the the Developer and Mesh Operator users.

Mesh Developer

Product Owner

Application Viewer (Higher -Non-Dev- Environment)

Monitors (metrics, telemetry, dashboards) applications (in and out of the mesh) from a domain that makeup the product

The _Product Owner _ will keep himself aware of the health, usage, cost as well other metrics around the domain their solution is part of by accessing the observability stack components (dashboards in Grafana, metrics in Prometheus, traces in Jaeger) and will be able to do so for up to 1 week

Mesh Application Viewer

Mapping Enterprise Users to Roles in the DEV Environment

See Execute Role & User Creation for the creation of users and roles in DEV and PROD environments.

Table 3. Users created in DEV Environment
Name Enterprise Persona Role Bindings Namespace

phillip

Platform Admin

Cluster Admin (default admin roles)

dev-istio-system

emma

Mesh Operator

Mesh Operator

dev-istio-system

cristina

Travel Portal Domain Owner (Tech Lead)

Mesh Developer

dev-travel-portal, dev-travel-control

farid

Travel Services Domain Owner (Tech Lead)

Mesh Developer

dev-travel-agency

john

Developer (TP)

Mesh Application Viewer

dev-travel-portal, dev-travel-control

mia

Developer (TS)

Mesh Application Viewer

dev-travel-agency

mus

Product Owner

Mesh Application Viewer

dev-travel-portal, dev-travel-control, dev-travel-agency

Mapping Enterprise Users to Roles in the Higher (PROD) Environment

See Execute Role & User Creation for the creation of users and roles in DEV and PROD environments.

Table 4. Users created in PROD Environment
Name Enterprise Persona Role Bindings Namespace

phillip

Platform Admin

Cluster Admin (default admin roles)

prod-istio-system

emma

Mesh Operator

Mesh Operator

prod-istio-system

cristina

Travel Portal Domain Owner (Tech Lead)

Mesh Developer

prod-travel-portal, prod-travel-control

farid

Travel Services Domain Owner (Tech Lead)

Mesh Developer

prod-travel-agency

craig

Platform (Application Ops) Team

Mesh Application Viewer

prod-travel-portal, prod-travel-control)

mus

Product Owner

Mesh Application Viewer

prod-travel-portal, prod-travel-control, prod-travel-agency

Execute Role & User Creation

  • Create User Roles

oc apply -f ./roles-resources/mesh-operator.yaml
oc apply -f ./roles-resources/mesh-developer.yaml
oc apply -f ./roles-resources/mesh-app-viewer.yaml

Execute User & Role Creation for DEV Environment

  1. Create Users in Cluster htpasswd (See Adding or removing a user in htpasswd)

    ./scripts/add-dev-environment-htpasswd-users.sh <htpasswd-secret-name>

  2. Add roles to the mesh users in DEV namespaces

    Warning
    		 Namespaces must be created first (see in next scenario Setting up a DEV environment for the Travel Portal and Travel Agency Teams 
    #./create-admin-roles.sh         	phillip 	(*ADD YOUR OWN CLUSTER ADMIN USER*)
./scripts/create-mesh-operator-roles.sh emma		dev-istio-system  dev-travel-portal:dev-travel-control:dev-travel-agency
./scripts/create-mesh-dev-roles.sh 	cristina 	dev-istio-system  dev-travel-portal:dev-travel-control
./scripts/create-mesh-dev-roles.sh 	farid 	        dev-istio-system  dev-travel-agency
./scripts/create-mesh-viewer-roles.sh 	john 		dev-travel-portal:dev-travel-control:dev-istio-system
./scripts/create-mesh-viewer-roles.sh 	mia   		dev-travel-agency:dev-istio-system
./scripts/create-mesh-viewer-roles.sh 	mus 		dev-travel-portal:dev-travel-control:dev-travel-agency:dev-istio-system

Execute User & Role Creation for PROD Environment

  1. Execute the following to add additional users for PROD in Cluster htpasswd for PROD (See Adding or removing a user in htpasswd )

    ./add-prod-environment-htpasswd-users.sh <htpasswd-secret-name>

  2. Add roles to the mesh users in PROD namespaces

Warning
 Namespaces must be created first (see in Adding Operators, Namespaces, User/Roles Preparation Actions for PROD 
./create-mesh-operator-roles.sh emma		prod-istio-system  prod-travel-portal:prod-travel-control:prod-travel-agency
./create-mesh-dev-roles.sh 	cristina 	prod-istio-system  prod-travel-portal:prod-travel-control
./create-mesh-dev-roles.sh 	farid 	        prod-istio-system  prod-travel-agency
./create-mesh-viewer-roles.sh 	craig 		prod-travel-portal:prod-travel-control:prod-travel-agency:prod-istio-system

Environment Service Mesh Architectures

The final step in the requirements analysis phase is to determine an architecture based on the expected functional and non-functional requirements for the DEV and PROD environments

DEV Environment Service Mesh (OSSM) Architecture

Table 5. DEV Service Mesh Components
Name Instances Operator Sizing

grafana

1

servicemeshoperator

Default

istiod

1

servicemeshoperator

Default

istio-egressgateway

1

servicemeshoperator

Default

istio-ingressgateway

1

servicemeshoperator

Default

jaeger

1

servicemeshoperator

Default

kiali

1

servicemeshoperator

Default

prometheus

1

servicemeshoperator

Default

wasm-cacher-client-side-tenant

1

servicemeshoperator

Default

PROD Environment Service Mesh (OSSM) Architecture

Table 6. PROD Service Mesh Components
Name Instances Operator Sizing

grafana

1

servicemeshoperator

Production Setup

istiod

1

servicemeshoperator

Production Setup

istio-egressgateway

2

servicemeshoperator

Production Setup

istio-ingressgateway

2

servicemeshoperator

Production Setup

jaeger

1

jaeger-operator

Production Setup

kiali

1

kiali-operator

Default

prometheus

1

servicemeshoperator

Default

elastic-search

1

elastic-search-operator

Production Setup
Important
 Next in Scenario-2 Help the Travel Agency to Setup a Development Environment