You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cortex {{ .Chart.AppVersion }} is initializing in in your cluster.
3
+
Cortex (version {{ .Chart.AppVersion }}) is initializing in your cluster.
4
4
5
-
Wait for the loadbalancers to be provisioned and connected to your cluster.
5
+
It will take 5 to 10 minutes for the load balancers to be provisioned and connected to your cluster.
6
6
7
-
1. Get the Cortex operator endpoint:
7
+
1. Get the Cortex operator endpoint (it might take 1-2 minutes until the endpoint is allocated):
8
8
9
-
{{ if eq .Values.global.provider "aws" }}
9
+
{{- if eq .Values.global.provider "aws" }}
10
10
$ kubectl get service --namespace {{ .Release.Namespace }} ingressgateway-operator -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
11
11
{{- else if eq .Values.global.provider "gcp" }}
12
12
$ kubectl get service --namespace {{ .Release.Namespace }} ingressgateway-operator -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
13
13
{{- end }}
14
14
15
-
2. You can use the curl command below to verify loadbalancer set up. It can take between 5 to 10 minutes for the setup to complete. You can expect to encounter `Could not resolve host` or timeouts when running the verification request below during the loadbalancer initialization.
15
+
2. You can use the curl command below to verify that your load balancer is ready. You can expect to encounter `Could not resolve host` or timeouts when running the verification request before the load balancer is initialized.
16
16
17
-
{{ if eq .Values.global.provider "aws" }}
17
+
{{- if eq .Values.global.provider "aws" }}
18
18
$ export CORTEX_OPERATOR_ENDPOINT=$(kubectl get service --namespace {{ .Release.Namespace }} ingressgateway-operator -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
19
19
{{- else if eq .Values.global.provider "gcp" }}
20
20
$ export CORTEX_OPERATOR_ENDPOINT=$(kubectl get service --namespace {{ .Release.Namespace }} ingressgateway-operator -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
Copy file name to clipboardExpand all lines: docs/clusters/aws/networking/vpc-peering.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# VPC peering
2
2
3
-
If you are using an internal operator load balancer (i.e. you set `operator_load_balancer_scheme: internal` in your cluster configuration file before creating your cluster), you can use VPC Peering to enable your Cortex CLI to connect to your cluster operator from another VPC so that you may run `cortex` commands. Note that because the operator validates that the CLI user is an active IAM user in the same AWS account as the Cortex cluster, it is usually unnecessary to configure the operator's load balancer to be internal.
3
+
If you are using an internal operator load balancer (i.e. you set `operator_load_balancer_scheme: internal` in your cluster configuration file before creating your cluster), you can use VPC Peering to enable your Cortex CLI to connect to your cluster operator from another VPC so that you may run `cortex` commands.
4
4
5
5
If you are using an internal API load balancer (i.e. you set `api_load_balancer_scheme: internal` in your cluster configuration file before creating your cluster), you can use VPC Peering to make prediction requests from another VPC.
Copy file name to clipboardExpand all lines: docs/clusters/aws/security.md
+2-6Lines changed: 2 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ See [networking](networking/index.md) for a discussion of API visibility.
10
10
11
11
## Private operator
12
12
13
-
By default, the Cortex cluster operator's load balancer is internet-facing, and therefore publicly accessible (the operator is what the `cortex` CLI connects to). The operator validates that the CLI user is an active IAM user in the same AWS account as the Cortex cluster (see [below](#cli)). Therefore it is usually unnecessary to configure the operator's load balancer to be private, but this can be done by by setting `operator_load_balancer_scheme: internal` in your [cluster configuration](install.md) file. If you do this, you will need to configure [VPC Peering](networking/vpc-peering.md) to allow your CLI to connect to the Cortex operator (this will be necessary to run any `cortex` commands).
13
+
By default, the Cortex cluster operator's load balancer is internet-facing, and therefore publicly accessible (the operator is what the `cortex` CLI connects to). The operator's load balancer can be configured to be private by setting `operator_load_balancer_scheme: internal` in your [cluster configuration](install.md) file. If you do this, you will need to configure [VPC Peering](networking/vpc-peering.md) to allow your CLI to connect to the Cortex operator (this will be necessary to run any `cortex` commands).
14
14
15
15
## IAM permissions
16
16
@@ -36,7 +36,7 @@ You can specify credentials for spinning up the cluster in four ways (in order o
36
36
37
37
5. You can specify the AWS credentials `"aws access key id"` and `"aws secret access key"` at the CLI's prompt when requested.
38
38
39
-
It is recommended to use an IAM user with the `AdministratorAccess` policy to create your cluster, since the CLI requires many permissions for this step, and the list of permissions is evolving as Cortex adds new features. If it is not possible to use `AdministratorAccess` in your existing AWS account, you could create a separate AWS account for your Cortex cluster, or you could ask someone within your organization to create the Cortex cluster for you (since `AdministratorAccess` is not required to deploy APIs to your cluster; see [CLI](#cli) below).
39
+
It is recommended to use an IAM user with the `AdministratorAccess` policy to create your cluster, since the CLI requires many permissions for this step, and the list of permissions is evolving as Cortex adds new features. If it is not possible to use `AdministratorAccess` in your existing AWS account, you could create a separate AWS account for your Cortex cluster, or you could ask someone within your organization to create the Cortex cluster for you.
40
40
41
41
### Operator
42
42
@@ -72,10 +72,6 @@ The operator requires read permissions for any S3 bucket containing exported mod
72
72
73
73
It is possible to further restrict access by limiting access to particular resources (e.g. allowing access to only the bucket containing your models and the cortex bucket).
74
74
75
-
### CLI
76
-
77
-
In order to connect to the operator via the CLI, you must provide valid AWS credentials for any user with access to the account. No special permissions are required. The CLI can be configured using the `cortex env configure ENVIRONMENT_NAME` command (e.g. `cortex env configure aws`).
78
-
79
75
### Running `cortex cluster` commands from different IAM users
80
76
81
77
By default, the `cortex cluster *` commands can only be executed by the IAM user who created the Cortex cluster. To grant access to additional IAM users, follow these steps:
Copy file name to clipboardExpand all lines: docs/clusters/kubernetes/install.md
+28-29Lines changed: 28 additions & 29 deletions
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,7 @@
1
-
# install
1
+
# Install
2
2
3
3
Cortex currently relies on cloud provider specific functionality such as load balancers and storage. Kubernetes clusters in the following cloud providers are supported:
4
+
4
5
*[AWS](#aws)
5
6
*[GCP](#gcp)
6
7
@@ -14,22 +15,23 @@ Cortex uses helm to install the Cortex operator and its dependencies on your Kub
14
15
* aws cli
15
16
* helm 3
16
17
* EKS cluster
17
-
* kubernetes version >= 1.17
18
-
* at least 3 t3.medium (2 vCPU, 4 GB mem) instances
18
+
* at least 3 t3.medium (2 vCPU, 4 GB mem) instances
19
19
20
-
Note that installing Cortex on your kubernetes cluster will not provide some of the cluster level features such as cluster autoscaling and spot instances with on-demand backup.
20
+
You may install Cortex in any namespace in your cluster. In the guide that follows, the "default" namespace is assumed; if you're using a different namespace, replace all occurrences of "default" with the name of your namespace.
21
21
22
-
### Download cortex charts
22
+
Note that installing Cortex on your Kubernetes cluster will not provide some of the cluster-level features such as cluster autoscaling and spot instances with on-demand backup.
Define a `values.yaml` with the following information provided:
55
57
@@ -58,7 +60,7 @@ Define a `values.yaml` with the following information provided:
58
60
59
61
cortex:
60
62
region: <CORTEX_REGION>
61
-
bucket: <CORTEX_S3_BUCKET>
63
+
bucket: <CORTEX_S3_BUCKET># e.g. "my-cortex-bucket" (without s3://)
62
64
cluster_name: <CORTEX_CLUSTER_NAME>
63
65
global:
64
66
provider: "aws"
@@ -78,7 +80,7 @@ Get the Cortex operator endpoint:
78
80
kubectl get service --namespace default ingressgateway-operator -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
79
81
```
80
82
81
-
You can use the curl command below to verify loadbalancer set up. It can take between 5 to 10 minutes for the setup to complete. You can expect to encounter `Could not resolve host` or timeouts when running the verification request below during the loadbalancer initialization.
83
+
You can use the curl command below to verify that your load balancer is ready. It can take 5-10 minutes for the setup to complete. You can expect to encounter `Could not resolve host` or timeouts when running the verification request before the load balancer is initialized.
82
84
83
85
```bash
84
86
export CORTEX_OPERATOR_ENDPOINT=$(kubectl get service --namespace default ingressgateway-operator -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
@@ -120,22 +122,23 @@ The following tolerations are added to Deployments and Jobs orchestrated by Cort
120
122
* gsutil
121
123
* helm 3
122
124
* GKE cluster
123
-
* kubernetes version >= 1.17
124
-
* at least 2 n1-standard-2 (2 vCPU, 8 GB mem) (with monitoring and logging disabled)
125
+
* at least 2 n1-standard-2 (2 vCPU, 8 GB mem) (with monitoring and logging disabled)
125
126
126
-
Note that installing Cortex on your kubernetes cluster will not provide some of the cluster level features such as cluster autoscaling and spot instances with on-demand backup.
127
+
You may install Cortex in any namespace in your cluster. In the guide that follows, the "default" namespace is assumed; if you're using a different namespace, replace all occurrences of "default" with the name of your namespace.
127
128
128
-
### Download cortex charts
129
+
Note that installing Cortex on your Kubernetes cluster will not provide some of the cluster-level features such as cluster autoscaling and preemptible instances.
Wait for the loadbalancers to be provisioned and connected to your cluster.
181
180
182
-
Get the Cortex operator endpoint (double check your namespace):
181
+
Get the Cortex operator endpoint:
183
182
184
183
```bash
185
184
kubectl get service --namespace default ingressgateway-operator -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
186
185
```
187
186
188
-
You can use the curl command below to verify loadbalancer set up. It can take between 5 to 10 minutes for the setup to complete. You can expect to encounter `Could not resolve host` or timeouts when running the verification request below during the loadbalancer initialization.
187
+
You can use the curl command below to verify that your load balancer is ready. It can take 5-10 minutes for the setup to complete. You can expect to encounter `Could not resolve host` or timeouts when running the verification request before the load balancer is initialized.
189
188
190
189
```bash
191
190
export CORTEX_OPERATOR_ENDPOINT=$(kubectl get service --namespace default ingressgateway-operator -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
0 commit comments