-
Notifications
You must be signed in to change notification settings - Fork 368
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.
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
Add document for BGPPolicy #6524
Conversation
3a474bf
to
56a32cd
Compare
b41974a
to
344f72c
Compare
344f72c
to
5390947
Compare
5390947
to
f544197
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
f544197
to
106f8b6
Compare
8ce56c4
to
3018739
Compare
3018739
to
95ca1ca
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only minor comments left, otherwise lgtm
- All Nodes can advertise all ClusterIPs, respecting `internalTrafficPolicy`. If `internalTrafficPolicy` is set to | ||
`Local`, a Node will only advertise ClusterIPs with at least one local Endpoint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit surprising, because it feels like internalTrafficPolicy
is not something that should impact traffic coming from external routers. However, ClusterIPs were not meant to be externally routable anyway so it's already a bit of an unusual situation. cc @tnqn. If this is the behavior that was agreed upon, then this is fine by me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I thought about this and didn't figure out a better implementation. I think in practice users will only advertise ClusterIPs when they don't have any ExternalIPs and LoadBalancerIPs, and they intend to reduce costs and improve performance by setting the internal traffic policy to local, then it seems fine to only advertise from Nodes that have local Pods to achieve the same goals for external traffic.
Besides, I suppose making external-to-clusterIP traffic not enforce internalTrafficPolicy would impact Antrea Proxy's implementation a lot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose making external-to-clusterIP traffic not enforce internalTrafficPolicy would impact Antrea Proxy's implementation a lot.
makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to make adjustments to my earlier suggestions for the BGP router ID
section, after reviewing the actual code. I didn't realize earlier that the annotation had to be an actual IPv4 address string (a.b.c.d
) and I though a 32-bit integer was to be used.
@hongliangl The doc should probably mention the BGP secret, as pointed out by @luolanzone in another PR review |
16fdf50
to
5f0e135
Compare
Added |
5f0e135
to
6ec4a80
Compare
docs/bgp-policy.md
Outdated
BGP authentication ensures that BGP sessions are established and maintained only with legitimate peers. Antrea supports | ||
BGP authentication by leveraging a Kubernetes Secret, `antrea-bgp-passwords`, to store authentication passwords. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the second sentence, I suggest:
Users can provide authentication passwords for the different BGP peering sessions by storing them in a Kubernetes secret. The secret must be defined in the same Namespace as Antrea (
kube-system
by default) and must be namedantrea-bgp-passwords
.
docs/bgp-policy.md
Outdated
the password for that BGP peer. If a key for a BGP peer does not exist in the Secret, the peer is considered unconfigured | ||
for that one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the last sentence:
If a given BGP peer does not have a corresponding key in the Secret data, then authentication is considered disabled for that peer.
6ec4a80
to
42f81a5
Compare
035c96b
to
2bd84a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
2bd84a2
to
360fba6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
docs/bgp-policy.md
Outdated
1. If the `node.antrea.io/bgp-router-id` annotation is present on the Node and its value is a valid IPv4 address string, | ||
we will use the provided value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't match the implementation which always uses Node IPv4 when there is one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for reminding me about that. I have corrected it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for catching this @tnqn. I'm partially to blame here, as I suggested the previous wording without double-checking the implementation.
I don't want to block the BGP PRs for this, but the implementation doesn't make much sense to me. I see no reason why the annotation should not be honored in the IPv4 case. If anything, that just creates confusion. RFC 6286 relaxes the definition of the BGP router ID, and I don't think we need to "force" the ID to be the Node IP in the IPv4 case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I am perfectly fine having this discussion and potentially making this change post v2.1 release btw)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@antoninbas I agree with you. I wondered why not to handle IPv4/IPv6 consitently but didn't want to ask for a change in the implementation given the tight schedule. We could unify them in 2.2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created #6550 yesterday to track this
docs/bgp-policy.md
Outdated
3. Otherwise, for IPv6-only clusters, a 32-bit integer will be generated by hashing the Node name, then converted to the | ||
string representation of an IPv4 address. | ||
|
||
After this selection process, the `node.antrea.io/bgp-router-id` annotation is added / updated as necessary to reflect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto, I think only IPv6 updates the annotation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except two comments on the examples
docs/bgp-policy.md
Outdated
listenPort: 179 | ||
advertisements: | ||
service: | ||
ipTypes: [ClusterIP, LoadBalancerIP] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove ClusterIP to make the example more reasonable. Normally there is no reason to advertise ClusterIP when the cluster has LoadBalancer enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
docs/bgp-policy.md
Outdated
listenPort: 179 | ||
advertisements: | ||
service: | ||
ipTypes: [ClusterIP, ExternalIP, LoadBalancerIP] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto, we should at least remove ClusterIP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Signed-off-by: Hongliang Liu <[email protected]>
360fba6
to
189fb41
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/skip-all |
No description provided.