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.

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

docs: minor touches DOC-910 DOC-911 #1779

Merged
merged 3 commits into from
Nov 9, 2023
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
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
Original file line number Diff line number Diff line change
Expand Up @@ -13,16 +13,16 @@ Cluster Groups may have a cluster endpoint type of either Load Balancer or Ingre

Using **Ingress** as the cluster endpoint type is a more cost effective way to access your Kubernetes workloads than using type **Load Balancer**, which requires a new cloud Load Balancer to be provisioned for each virtual cluster.

When you enable **Ingress** as the endpoint for a Cluster Group, you must deploy an [Ingress Controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers) add-on profile, such as NGINX, on each host cluster in the Cluster Group. The Ingress Controller provides the necessary routing functionality for external traffic to reach the Kubernetes API server of each virtual cluster, as well as any apps each virtual cluster contains.
When you enable **Ingress** as the endpoint for a Cluster Group, you must deploy an [Ingress Controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers) add-on profile, such as Nginx, on each host cluster in the Cluster Group. The Ingress Controller provides the necessary routing functionality for external traffic to reach the Kubernetes API server of each virtual cluster, as well as any apps each virtual cluster contains.

## Prerequisites

- At least one infrastructure or cloud-based cluster you’ve created.
karl-cardenas-coding marked this conversation as resolved.
Show resolved Hide resolved


- The Ingress Controller must have Secure Socket Layer (SSL) passthrough enabled so that Transport Layer Security (TLS) is not terminated at the ingress controller. Palette provides the ```nginx-ingress``` add-on profile with SSL passthrough already enabled. The following example shows how SSL-passthrough is enabled for the NGINX Ingress Controller. You would add an equivalent configuration to the profile of the add-on you are using. <br /><br />
- The Ingress Controller must have Secure Socket Layer (SSL) passthrough enabled so that Transport Layer Security (TLS) is not terminated at the ingress controller. Palette provides the `nginx-ingress` add-on profile where SSL passthrough can be enabled. The following example shows how you can enable SSL-passthrough for the Nginx Ingress Controller.

```yaml
```yaml {5}
charts:
ingress-nginx:
controller:
Expand All @@ -33,9 +33,9 @@ When you enable **Ingress** as the endpoint for a Cluster Group, you must deploy

- Palette's ```nginx-ingress``` add-on profile automatically reroutes inbound requests from port 6443 to port 443 using a TCP service configuration. This is so that TLS termination on port 443 for all Apps can occur at the cloud load balancer while simultaneously allowing connections to the API servers of your Virtual Clusters on port 6443.

If you are using an ingress controller other than the NGINX Ingress Controller and would like to terminate TLS at your ingress controller's cloud load balancer, an equivalent TCP service configuration would be required. Alternatively, you may handle all TLS termination inside the cluster by configuring Cert Manager to issue a certificate for each App's Ingress.<br />
If you are using an ingress controller other than the Nginx Ingress Controller and would like to terminate TLS at your ingress controller's cloud load balancer, an equivalent TCP service configuration would be required. Alternatively, you may handle all TLS termination inside the cluster by configuring Cert Manager to issue a certificate for each App's Ingress.<br />
karl-cardenas-coding marked this conversation as resolved.
Show resolved Hide resolved

The following example shows how port rerouting is achieved for the NGINX Ingress Controller. You would add an equivalent Transmission Control Protocol (TCP) service configuration to the profile of the add-on you are using. <br /><br />
The following example shows how port rerouting is achieved for the Nginx Ingress Controller. You would add an equivalent Transmission Control Protocol (TCP) service configuration to the profile of the add-on you are using. <br /><br />

```yaml
tcp:
Expand All @@ -50,7 +50,7 @@ The following steps describe how to enable an Ingress Controller for a Cluster G
1. Log in to Palette as **Tenant Admin**.


2. Identify each host cluster that requires the addition of an NGINX Ingress Controller profile.
2. Identify each host cluster that requires the addition of an Nginx Ingress Controller profile.

This can be:

Expand All @@ -76,8 +76,8 @@ The following steps describe how to enable an Ingress Controller for a Cluster G

c. Invoke the following command to display the External-IP of the ```nginx-ingress``` LoadBalancer Service: <br /><br />

```
kubectl -n nginx get service nginx-ingress-controller
```shell
kubectl get service nginx-ingress-controller --namespace nginx
```

d. Copy the record to your clipboard or to a text file. You will use the External-IP address to create a CNAME DNS record.
Expand Down Expand Up @@ -121,13 +121,13 @@ To validate that ingress is functioning as expected, do the following:
2. Use a web shell and type the following command to verify you can connect to the newly deployed virtual cluster:

```shell
kubectl get namespaces
kubectl get namespaces --all-namespaces
```
This should display a list of namespaces as shown in the example:

<br />

```shell
```shell hideClipboard
NAME STATUS AGE
default Active 4d11h
kube-system Active 4d11h
Expand All @@ -139,9 +139,9 @@ This should display a list of namespaces as shown in the example:

If an error message displays, it indicates something is wrong with the configuration. Verify the following:

- Each host cluster is deployed with NGINX Ingress Controller.
- Each host cluster is deployed with Nginx Ingress Controller.

- The CNAME record correctly maps to the External-IP of the NGINX Ingress Controller’s LoadBalancer Service.
- The CNAME record correctly maps to the External-IP of the Nginx Ingress Controller’s LoadBalancer Service.

- Cluster Group Settings specify the Cluster endpoint type as **Ingress**, and **Host DNS** specifies the CNAME record you created.

Expand Down
4 changes: 2 additions & 2 deletions docs/docs-content/clusters/clusters.md
Original file line number Diff line number Diff line change
Expand Up @@ -246,9 +246,9 @@ At times, you may be required to work with the Palette Support Team to troublesh

## Proxy Whitelist

This table lists the proxy requirements for enabling the Palette management console.
The following table lists the proxy requirements required by Palette. Depending on the network equipment and configuration, you may have to specify all subdomains of the top-level domains listed in the table. For example, an entry containing `gcr.io` and `*.gcr.io` may be required. Consult your network administrator for the exact requirements.

| Top-level Domain | Port | Description |
| **Top-level Domain** | **Port** | **Description** |
| ------------------------- | ---- | -------------------------------------------- |
| docker.io | 443 | Third party container images. |
| docker.com | 443 | Third party container images. |
Expand Down