Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Enable canary analysis on deployments and services behind Envoy #385

Closed
mumoshu opened this issue Nov 30, 2019 · 0 comments
Closed

Enable canary analysis on deployments and services behind Envoy #385

mumoshu opened this issue Nov 30, 2019 · 0 comments
Assignees
@mumoshu
Labels
kind/feature Feature request

Comments

@mumoshu
Copy link
Contributor

mumoshu commented Nov 30, 2019

As per discussion in #372 (review), I'm going to contribute:

  • Metrics providers for Deployment and Service behind Envoy
  • Metrics provider for Service behind AppMesh
  • A guide to use Envoy with Deployment kind
  • A guide to use AppMesh with Service kind

The longer explanation follows.

I've implemented and tested the progressive delivery of Kubernetes services in #372. That opened up the possibility to add two broad enhancements to Flagger:

  • Envoy as an ingress gateway solution supported by Flagger, as I successfully used Envoy augmented by Crossover as the ingress gateway solution while testing the PR
  • Make the Service target kind more available to users

The former, we'd eventually need

For the latter, we'd eventually need

  • A metrics provider implementation for Service per each ingress gateway solution
  • A doc per each ingress gateway solution to do progressive delivery of services
  • Enable A/B teting on canary Service per each ingress gateway solution

For this specific issue, I will contribute things around Envoy and AppMesh, that I'm most familiar with and more interested in.

TODOs:

  • Metrics providers for Deployment and Service behind Envoy
  • Metrics provider for Service behind AppMesh
  • A guide to use Envoy with Deployment kind
  • A guide to use AppMesh with Service kind

Ref #372 (review)
mumoshu added a commit to mumoshu/flagger that referenced this issue Nov 30, 2019
@mumoshu
Metrics provider for deployments and services behind Envoy
221a12b 
Assumes `envoy:smi` as the mesh provider name as I've successfully tested the progressive delivery for Envoy + Crossover with it.

This enhances Flagger to translate it to the metrics provider name of `envoy` for deployment targets, or `envoy:service` for service targets.

The `envoy` metrics provider is equivalent to `appmesh`, as both relies on the same set of standard metrics exposed by Envoy itself.

The `envoy:service` is almost the same as the `envoy` provider, but removing the condition on pod name, as we only need to filter on the backing service name = envoy_cluster_name. We don't consider other Envoy xDS implementations that uses anything that is different to original servicen ames as `envoy_cluster_name`, for now.

Ref fluxcd#385
mumoshu added a commit to mumoshu/flagger that referenced this issue Nov 30, 2019
@mumoshu
Add the guide for using Envoy and Crossover for Deployment targets
6636d4a 
Ref fluxcd#385
@mumoshu mumoshu mentioned this issue Nov 30, 2019
Merged
mumoshu added a commit to mumoshu/flagger that referenced this issue Nov 30, 2019
@mumoshu
Metrics provider for deployments and services behind Envoy
beeefbc 
Assumes `envoy:smi` as the mesh provider name as I've successfully tested the progressive delivery for Envoy + Crossover with it.

This enhances Flagger to translate it to the metrics provider name of `envoy` for deployment targets, or `envoy:service` for service targets.

The `envoy` metrics provider is equivalent to `appmesh`, as both relies on the same set of standard metrics exposed by Envoy itself.

The `envoy:service` is almost the same as the `envoy` provider, but removing the condition on pod name, as we only need to filter on the backing service name = envoy_cluster_name. We don't consider other Envoy xDS implementations that uses anything that is different to original servicen ames as `envoy_cluster_name`, for now.

Ref fluxcd#385
mumoshu added a commit to mumoshu/flagger that referenced this issue Nov 30, 2019
@mumoshu
Add the guide for using Envoy and Crossover for Deployment targets
4b5c872 
Ref fluxcd#385
mumoshu added a commit to mumoshu/flagger that referenced this issue Nov 30, 2019
@mumoshu
Add the guide for using Envoy and Crossover for Deployment targets
1f2f3eb 
Ref fluxcd#385
mumoshu added a commit to mumoshu/flagger that referenced this issue Nov 30, 2019
@mumoshu
Metrics provider for deployments and services behind Envoy
6661406 
Assumes `envoy:smi` as the mesh provider name as I've successfully tested the progressive delivery for Envoy + Crossover with it.

This enhances Flagger to translate it to the metrics provider name of `envoy` for deployment targets, or `envoy:service` for service targets.

The `envoy` metrics provider is equivalent to `appmesh`, as both relies on the same set of standard metrics exposed by Envoy itself.

The `envoy:service` is almost the same as the `envoy` provider, but removing the condition on pod name, as we only need to filter on the backing service name = envoy_cluster_name. We don't consider other Envoy xDS implementations that uses anything that is different to original servicen ames as `envoy_cluster_name`, for now.

Ref fluxcd#385
mumoshu added a commit to mumoshu/flagger that referenced this issue Nov 30, 2019
@mumoshu
Add the guide for using Envoy and Crossover for Deployment targets
a828524 
Ref fluxcd#385
@stefanprodan stefanprodan added the kind/feature Feature request label Dec 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mumoshu mumoshu

Labels
kind/feature Feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mumoshu @stefanprodan