- istio
- cert-manager
- external-dns
- Deploys Istio using
istioctl installwith parameters file -
- json logging by default
-
- ingressgateway enabled
- external-dns watches for route53 automation, watching:
-
- service
-
- ingress
-
- istio-gateway
-
- istio-virtualservice
- Deploys cert-manager with letsencrypt integration for automated ingressgateway certificates
Default top-level gateways:
| gateway | urls | cluster |
|---|---|---|
| twdps.digital-gateway | (*.)twdps.digital | sbx-i01-aws-us-east-1 |
| twdps.io-gateway | (*.)twdps.io | prod-i01-aws-us-east-1 |
Cluster specific gateways:
| gateway | urls | cluster |
|---|---|---|
| sbx-i01-aws-us-east-1.twdps.digital-gateway | (*.)sbx-i01-aws-us-east-1.twdps.digital | sbx-i01-aws-us-east-1 |
| sbx-i01-aws-us-east-1.twdps.io-gateway | (*.)sbx-i01-aws-us-east-1.twdps.io | sbx-i01-aws-us-east-1 |
| prod-i01-aws-us-east-1.twdps.digital-gateway | (*.)prod-i01-aws-us-east-1.twdps.digital | prod-i01-aws-us-east-1 |
| prod-i01-aws-us-east-1.twdps.io-gateway | (*.)prod-i01-aws-us-east-1.twdps.io | prod-i01-aws-us-east-1 |
Ingress domains should be considered a organizational Product decision. In other words, Decide on the top-level subdomains that reflect the product strategy you have in mind for api product domains. For many companies this can be as simple as https://api.example.com is how all custom API are to be referenced with the various capabilities part of the left-of-domain path definition (api.example.com/v1/profiles...).
Where there are a limited set or unlikley to change ingress patterns, the configuration could be included within the extensions pipeline. In many enterprise situations there will be a need for a more omplex, or even customer-managed, experience around ingress domains and therefore a dedicated platform API would beed to be created to manage this feature. But even in that situation, there will probably be a brief period where alpha-users of the platform need to be onboarded with ingress capabilities. See the psk-platform-simple-teams-and-ns pipeline for an example of a lightweight, interim method to manage the basic 'customer' configuration within a cluster while the API driven solution is being created.
Default namespace
A default-mtls namespace is deployed to each cluster for validate and testing of istio configurations.
Create a new revision config in the istio-configuration folder. Update the version in the install.json files and deploy. Note: this is presently an in-place upgrade that results in momentary service interruption.
validate basic mesh functionality
Deploys an instance of httpbin to the default-mtls namespace and defines a virtual service on the default cluster gateway at httpbin.cluster twdps.io domain. A successful test confirms the healthy functionality of the following:
- the ingressgateway service successfully provisioned an ELB
- gateways were defined for the domains managed by the cluster
- certificates were successfully requested from Let'sEncrypt and are attached to the gateways
- envoy sidecars are successfully injected into managed namespaces
- istiod and the istio mutatingwebhook are successfully proxying traffic via envoy
- tls traffic successfully reaches the httpbin test application
Extensions to add:
- crossplane
- k6
explore
- external-secrets operator (or similar tool as this one in particular does not support 1password, perhaps we create the extension to support)
other:
- convert istio install/upgrade to revision-based canary method. (this should address the simplistic data plane version refresh in the in-place upgrade, but need to confirm)