Skip to content

update migration doc to include more information #1541

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

Merged
merged 1 commit into from
Oct 22, 2020
Merged

update migration doc to include more information #1541

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 40 additions & 2 deletions docs/guide/upgrade/migrate_v1_v2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,50 @@ This document contains the information necessary to migrate from an existing ins

!!!warning ""
If you have AWSALBIngressController(<1.1.3) installed, you need to upgrade to version>=v1.1.3(e.g. v1.1.9) first.


## Backwards compatibility
The AWSLoadBalancerController(v2.0.0) is backwards-compatible with AWSALBIngressController(>=v1.1.3).

It supports existing AWS resources provisioned by AWSALBIngressController(>=v1.1.3) for Ingress resources.
It supports existing AWS resources provisioned by AWSALBIngressController(>=v1.1.3) for Ingress resources with below caveats:

1. The AWS LoadBalancer resource created for your Ingress will be preserved.

2. If a numeric TargetPort is used in your service, the AWS TargetGroups created for your Ingress will be re-created.

!!!warning "downtimes"
This would cause downtimes to your service during targets registration into new TargetGroups created.

!!!tip "details"
* The AWSALBIngressController always used `1` as TargetGroup's port.
* The AWSLoadBalancerController will use
* the actual numeric TargetPort as TargetGroup's port if a numeric TargetPort used.
* `1` as TargetGroup's port if a lexical TargetPort used.
* The AWSLoadBalancerController will automatically create new TargetGroups and cleanup old TargetGroups if any.

3. If [security-groups](../../guide/ingress/annotations.md#security-groups) annotation used, the SecurityGroup rule on worker node's SecurityGroup that allow LoadBalancer traffic should be manually adjusted post migration.

!!!tip "details"
when [security-groups](../../guide/ingress/annotations.md#security-groups) annotation used:

* a managed SecurityGroup will be created and attached to ALB. This SecurityGroup will be preserved.
* an inbound rule will be added to your worker node securityGroups which allow traffic from the above managed SecurityGroup for ALB.
* The AWSALBIngressController didn't add any description for that inbound rule.
* The AWSLoadBalancerController will use `elbv2.k8s.aws/targetGroupBinding=shared` for that inbound rule
* You'll need to manually add `elbv2.k8s.aws/targetGroupBinding=shared` description to that inbound rule so that AWSLoadBalancerController can delete such rule when you delete your Ingress.

!!!tip "sample"
inbound rule on worker node securityGroups that allow traffic from the managed LB securityGroup before migration:

|Type | Protocol |Port range|Source |Description - optional|
|--------|----------|----------|---------------------------|----------------------|
|All TCP |TCP |0 - 65535 |sg-008c920b1(managed LB SG)|- |

inbound rule on worker node securityGroups that allow traffic from the managed LB securityGroup after migration:

|Type | Protocol |Port range|Source |Description - optional|
|--------|----------|----------|---------------------------|----------------------|
|All TCP |TCP |0 - 65535 |sg-008c920b1(managed LB SG)|elbv2.k8s.aws/targetGroupBinding=shared| |

## Upgrade steps
1. Determine existing installed AWSALBIngressController version.
Expand Down