- The Mapping Resource
- Automatic Retries
- Canary Releases
- Circuit Breakers
- Cross-Origin Resource Sharing
- Method-based Routing
- Prefix Regex
- Query Parameter Based Routing
- Traffic Shadowing
- Developer Portal
- The Ambassador Module
- Custom Error Responses
- Gzip Compression
- Host CRD, ACME Support, and External Load Balancer Configuration
- Ingress Controller
- Troubleshooting Ambassador
- Scaling Ambassador
- Deploying to Kubernetes from GitHub
- Knative Serverless Framework
- Prometheus monitoring
- Frequently Asked Questions
One of the challenges in adopting Kubernetes and microservices is the development and testing workflow. Creating and maintaining a full development environment with many microservices and their dependencies is complex and hard.
Service Preview, based on Telepresence, enables different developers to run different virtual versions of the same microservice. These virtual versions are deployed on your CI system or local development infrastructure, enabling fast development and testing workflows.
Service Preview runs on Mac OS X, Linux, and Windows via WSL2.
There are three main components to Service Preview:
The Traffic Agent, which controls routing to the microservice. The Traffic Agent is deployed as a sidecar on the same pod as your microservice (behind the scenes, it's a special configuration of the basic Ambassador Edge Stack image). The Traffic Agent sidecar can be manually configured or automatically injected by the Ambassador Injector in any pod with a specific annotation.
The Traffic Manager, which manages the different instances of the Traffic Agent, and is deployed in the cluster.
The Edge Control local client, which runs in your local environment (Linux or Mac OS X). The client is the command line interface to the Traffic Manager.
See the Service Preview reference for more information on how these components work.