Conversation
|
|
||
| Create an IAM user and attach the **`AmazonSQSReadOnlyAccess`** managed policy — it includes `sqs:GetQueueAttributes`, which is all the exporter needs. Generate an access key for the user and keep the credentials handy for Step 2. | ||
|
|
||
| {/* TODO: (Cathy) update when irsa is supported */} |
There was a problem hiding this comment.
should i be adding a linear ticket?
There was a problem hiding this comment.
Let's have v1 start with support for IRSA, we should not encourage people to generate access keys.
There was a problem hiding this comment.
should i just have this doc not mention static keys at all?
did it for this next draft but can always move it into an appendix
| ## Scaling Latency | ||
|
|
||
| End-to-end scale-up latency depends on the metrics pipeline: | ||
|
|
||
| | Step | Default | | ||
| |------|---------| | ||
| | SQS poll | 10s | | ||
| | Prometheus scrape | 15s | | ||
| | KEDA poll | 30s | | ||
| | HPA scale-up stabilization | 60s | | ||
|
|
||
| The HPA scale-up stabilization window (60s) is the dominant factor. For queue-based workloads where fast scale-up matters, you can drop it to `0` via your worker service's **Settings** tab → **Helm overrides**: | ||
|
|
||
| ```yaml | ||
| keda: | ||
| hpa: | ||
| scaleUp: | ||
| stabilizationWindowSeconds: 0 | ||
| policy: | ||
| type: Percent | ||
| value: 100 | ||
| periodSeconds: 15 | ||
| ``` |
There was a problem hiding this comment.
I think the mention of latency is fine, but let's not mentions prometheus, KEDA, HPA. Instead, we should just say the high-level latency they should expect, due to a combination of SQS polling, metrics scraping and stabilization period.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
| ### Option A: `porter.yaml` | ||
|
|
||
| Declare the [`awsRole` connection](/applications/configuration-as-code/services/connections#aws-role-connection) under your worker service. If your app doesn't have a `porter.yaml`, you can create one at the root of your repo with just the worker service declared — Porter merges it with your dashboard config. | ||
|
|
||
| ```yaml | ||
| services: | ||
| - name: worker | ||
| # ... | ||
| connections: | ||
| - type: awsRole | ||
| role: my-worker-sqs-access | ||
| ``` | ||
|
|
||
| ### Option B: Annotate the service account manually | ||
|
|
||
| If you'd rather not introduce a `porter.yaml`, annotate the worker's service account directly: | ||
|
|
||
| ```bash | ||
| kubectl annotate sa {APP_NAME}-{SERVICE_NAME} -n {NAMESPACE} \ | ||
| eks.amazonaws.com/role-arn=arn:aws:iam::{ACCOUNT_ID}:role/{ROLE_NAME} | ||
| ``` | ||
|
|
||
| Either option results in the service account carrying the `eks.amazonaws.com/role-arn` annotation, which EKS uses to inject IRSA credentials into the pod. |
There was a problem hiding this comment.
do we have a preferred route ?
also seems like pod identity is another possible route bc the dashboard already has an IAM Role Connection toggle under the worker's Advanced settings, but that path uses EKS Pod Identity, not IRSA
do we have a prefrence here? the note under IAM Role Connection makes it seem like we prefer pod identity?
|
|
||
| Create an IAM user and attach the **`AmazonSQSReadOnlyAccess`** managed policy — it includes `sqs:GetQueueAttributes`, which is all the exporter needs. Generate an access key for the user and keep the credentials handy for Step 2. | ||
|
|
||
| {/* TODO: (Cathy) update when irsa is supported */} |
There was a problem hiding this comment.
should i just have this doc not mention static keys at all?
did it for this next draft but can always move it into an appendix
2 participants
No description provided.