Doc-734 k8s ingress

[kaitlynmichael]

DOC-734

Note to reviewers (@yuvallevy2 @laurentdroin) please pay attention to comments that start with "SME QUESTION:" These are areas I need more clarification from a subject matter expert.

STAGING LINK: https://docs.redislabs.com/staging/DOC-734/platforms/kubernetes/tasks/set-up-ingress-controller/

[laurentdroin]

Every time a Redis Enterprise Database (REDB) is created in a Kubernetes (K8s) environment, a service is created that allows requests to be routed to that database. This type of service is called ClusterIP and can only be accessed from within the K8s cluster.

I am not sure how much detail we want to add here, but the type of service created for each database is not necessarily ClusterIP.
We support 3 types of service for our databases: ClusterIP, Headless (which really is a special type of ClusterIP service), and Load Balancer. Customers can choose what type of service will be created for the cluster databases. They can even choose a combination of 2, or the 3.
By default, the files that we have available on github will create 2 services per database: ClusterIP and Headless (see https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/redis_enterprise_cluster_api.md#servicesriggerconfigurationspec)

Also, an important aspect that we may want to emphasize is that all of this is for accessing databases from outside the Kubernetes cluster. From inside the k8s cluster, services can be accessed directly. No need for ingress or ingress controller.

also

For requests to be routed to the REDB from outside the K8s cluster, you need an ingress controller

That is in case of ClusterIP or Headless service. An Ingress controller should not be needed to access a service of type Load Balancer.

[laurentdroin]

You’ll need a database with the following: <!— SME QUESTION: are the values below necessary?? Why do they need replication enabled?? —>

None of this is needed, all we need is to have a database (and of course, there should be a service for it otherwise the customer has a bigger issue). Now, the service should probably be a ClusterIP service (if the service is Load Balancer, there is probably no point using Ingress).
The database doesn't even need to be an REDB database. It could have been created in the UI or via API (although I think we want to establish the use of REDB as a good practice).

So maybe we just say "have a database and a corresponding ClusterIP service".

[laurentdroin]

the K8s cluster is called ldr-eks-04

Hmmm... "ldr" is my initials. I use it to easily see what resources are mine. I am not sure we want to keep "ldr" references throughout this doc.

[laurentdroin]

OK, the small stuff first:

• In the first paragraph, "headless" is in a different style compared to the other services types
• In the "Create ingress resource", there are 2 step 1.

[laurentdroin]

When HAProxy is used for ingress control, an additional annotation is needed:
kubernetes.io/ingress.class: haproxy

[laurentdroin]

I think we need to clarify the concept of hostname, and it's a bit complicated.
Kaitlyn, maybe we need to discuss this over zoom.

[laurentdroin]

I think we need to explain how to get the CA certificate because I'm not sure customers would know where to get it from.

They can get it from any of the Redis Enterprise pod's redis-enterprise-node container.
A way to get it directly from the kubectl command would be:
kubectl exec -it <pod name> -c redis-enterprise-node -- cat /etc/opt/redislabs/proxy_cert.pem
Customers can event redirect the output to a file. If they redirect the output to a file called "proxy_cert.pem", that will match what is used in the examples (when testing the database connection).

[laurentdroin]

In order to connect to the database, the client needs to support TLS and SNI. I am not sure if this should be in the prerequisites or if we just mention this at the beginning of the "Test your external access " section.

[rrelledge]

Looks good. I just left a couple of small suggestions.

[laurentdroin]

Just a last note for today to mention that when testing the databases, the port to use will be 443. Pretty much always. This will be clearer on Monday.

[laurentdroin]

Two more comments:

In step 1 of "create ingress resource", we give a command that contains "-n ingress-controller". I don't know if we can completely assume what namespace the command should be run against, and it may depend on the ingress controller.
"ingress-controller" is typical of HAproxy. For NGINX, the typical namespace will be "ingress-nginx".
But even that depends on how the customer installed their ingress controller. They might have chosen their own namespace name.
So maybe we use "-n " ?

2nd comment: The list of annotations for each controller doesn't look formatted properly. In the screenshots I have, the annotations are not aligned together.

Looks good otherwise.