doc: Add Egress Gateway Getting Started Guide

[blzhao-0]

This is a documentation of the detailed instructions on configuring
cilium components to start using the egress nat gateway feature.

RFE: #13575

Signed-off-by: Yongkun Gui ygui@google.com
Signed-off-by: Bolun Zhao blzhao@google.com

[qmonnet]

Looks good overall, I find the steps very clear and well-explained. I have a few comments on the formatting below.

Please also address the issues reporting from the CI:

• A few typo (also highlighted in my review)
• You need to reference your documents from an index. From the list of the Getting Started Guides for example, likely in the Advanced Networking section.

Please also make sure that you use consistent levels of indents for all the directives in your document (block-content should ideally be left-aligned on the first letter of the directive name, as is the case for your first parsed-literal block for example).

[qmonnet]

Thanks for the update! There are still a few items remaining, please see the un-resolved items above. In addition, you still need to link the document somewhere, and to add busybox to the list of correct words as suggested by the failing GitHub action:

 Please fix the following documentation warnings:
/github/workspace/Documentation/gettingstarted/egress-gateway.rst: WARNING: document isn't included in any toctree

Please fix the following spelling mistakes:
* Documentation/gettingstarted/egress-gateway.rst:127: (busybox) 

If the words are not misspelled, run:
Documentation/update-spelling_wordlist.sh busybox 

[pchaigno]

I fixed the couple build issues mentioned by Quentin to be able to render locally and review. I haven't tested yet, but I think it needs a couple changes if we want folks to be able to follow the guide (without needing to deploy our development VM).

[pchaigno]

Is this going to be enough for users running in e.g. GKE, EKS, AKS?

[anfernee]

This is the guide for onprem environment. In cloud, the way to assign IP addresses will be very different in different cloud providers. We haven't covered those environments yet. Maybe we could do it as next step.

[pchaigno]

Maybe it would be enough to use the existing node IP for managed Kubernetes? It won't demonstrate the SNAT part of the egress gateway, but at least users would be able to observe the redirect. I guess it's better than nothing.

If that's not an option, we should at least clarify at the top that the guide doesn't currently support managed Kubernetes. I would be very careful how we word this though; we don't want to give the impression the feature doesn't support managed Kubernetes.

[anfernee]

Make sense. I'll try in on GKE first as an example. But I won't be able to cover other platforms.

[pchaigno]

But I won't be able to cover other platforms.

I think that's fine as long as we don't make the guide GKE-specific in some way. If there are small issues when running it on other managed K8s, we can always fix them up later.

[qmonnet]

Looks good from my side. Thanks for the updates.

[jrajahalme]

One question for potential simplification only.

[anfernee]

test-me-please

[anfernee]

test-me-please

[pchaigno]

test-me-please

@anfernee This isn't needed for documentation-only changes. There's already Documentation Updates / Validate & Build HTML (pull_request), which runs automatically, to test such changes.