AWS: EKS, OpenID Connect та ServiceAccounts
0 (0)

7 Липня 2023

Зараз сетаплю новий ЕКС кластер, і серед інших компонентів запускаю в ньому ExternalDNS, який використовує Kubernetes ServiceAccount для аутентифікації в AWS, щоб мати змогу вносити зміни до доменної зони в Route53.

Однак забув налаштувати Identity Provider в AWS IAM, і ExternalDNS видав помилку:

level=error msg=”records retrieval failed: failed to list hosted zones: WebIdentityErr: failed to retrieve credentials\ncaused by: InvalidIdentityToken: No OpenIDConnect provider found in your account for https://oidc.eks.us-east-1.amazonaws.com/id/FDF***F2F\n\tstatus code: 400

Тож почав згадувати за OIDC, потім взагалі про аутентифікацію в Kubernetes, и вирішив ще раз копнути в те, як воно все працює, бо в останніх версіях EKS/Kubernetes були досить цікаві зміни.

Що таке OpenID Connect та Identity Provider

OpenID Connect (OIDC) це протокол, який дозволяє сервісам виконувати аутентифікацію іншого сервісу або користувача на основі Identity Tokens, які являють собою JSON Web Tokens (JWT).

Сам JWT підписується Identity Provider (IDP), і містить в собі інформацю про юзера або сервіс.

В нашому випадку, AWS Elastic Kubernetes Service – це Identity Provider, а AWS – це Service Provider. Тобто, EKS аутентифікує юзерів, і каже Амазону, що цьому юзеру можна довіряти виконувати якісь дії в AWS.

Тож головне, що треба усвідомлювати, коли ви налаштовуєте Identity Providers в AWS IAM, це те, що ви не налаштовуєте якийсь окремий AWS Service під назвою “Identity Providers“, а налаштовуєте AWS IAM, якому кажете – “Хей, довіряй чуваку з оцим URL”, тобто налаштовуєте Trust relations між вашим Identity Provider (EKS, GitHub, GitLab, Google тощо) та Service Provider (AWS).

Якщо провести аналогію, то це якби ви в аеропорту на паспортному контролі десь в Амстердамі прийшли зі своїм українським паспортом, і вам там повірили, що ви – то саме ви, бо прикордонна служба Нідерландів (Service Provider) довіряє уряду України (Identity Provider), який вам видав цей паспорт (JWT).

AWS EKS та IAM Role

Окей, тож як Kubernetes Pod у EKS отримує доступ до AIM-ролі?

Ми повернемось детальніше до цієї теми в кінці, у AWS IAM Roles for Kubernetes ServiceAccounts, але зараз глянемо загальну картину процесу:

  • ми створюємо ServiceAccount для Kubernetes Pod, в annotations цього ServiceAccount вказуємо ARN IAM-ролі, яку цей Pod має використовувати для аутентифікації в AWS (авторизація, тобто перевірка які саме дії ви можете в AWS виконувати, буде виконуватись на рівні самого AWS в IAM за допомогою IAM Policy, яка підключена до вашої IAM Role)
  • EKS генерує JWT-токен, в якому вказано, що “подавач” цього токену дійсно є валідним EKS-юзером, і EKS це підтвержує своїм сертифікатом
  • процес із поду за допомогою цього токену проходить аутентифікацію в AWS IAM і виконує AssumeRole
  • і вже від імені цїєї ролі виконує необхідні дії з AWS API

Тобто, в процесі приймаються участь Kubernetes ServiceAccount, AWS AIM, та JWT-токени.

Розберемося з цим усім по черзі, і почнемо з ServiceAccounts та JWT в EKS, бо з часів написання Kubernetes: ServiceAccounts, JWT-токены, аутентификация и RBAC-авторизация процес трохи змінився.

EKS ServiceAccounts та Projected Volumes

Якщо раніше при створенні ServiceAccount створювався статичний Kubernetes Secret, який в собі мав три поля – namespace, ca.crt та власне token, то тепер це все генерується динамічно для кожного поду та ServiceAccount.

Давайте переглянемо, що ми зараз маємо в поді з ExternalDNS:

[simterm]

$ kk -n kube-system get pod external-dns-85587d4b76-2flhg -o yaml
...
    env:
    - name: AWS_DEFAULT_REGION
      value: us-east-1
    - name: AWS_STS_REGIONAL_ENDPOINTS
      value: regional
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::492***148:role/eks-dev-1-26-EksExternalDnsRoleB9A571AF-1CFSB6BBQDGSZ
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
...
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-qdgjr
      readOnly: true
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
...
  serviceAccount: external-dns
  serviceAccountName: external-dns
...
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
  - name: kube-api-access-qdgjr
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
...

[/simterm]

Отже, в volumeMounts ми бачимо два volumes – kube-api-access-qdgjr та aws-iam-token. До aws-iam-token повернемось пізніше, а поки давайте розглянемо volumes.projected для kube-api-access-qdgjr.

ServiceAccount Tokens

Починаючи з версії 1.22, Kubernetes має два типи токені – Long Live та Time Bound.

Long Live вже вважається deprecated, і не має використовуватись, хоча його можливо зробити зо допомогою Secret – це той самий тип токенів, які використовувались для ServiceAccounts раніше:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa
---
apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  annotations:
    kubernetes.io/service-account.name: test-sa
type: kubernetes.io/service-account-token

Time Bound токени генеруються Kubernetes TokenRequest API, мають обмежений час життя, валідні тільки для конкретного Pod та ServiceAccount, і підключаються до поду за допомогою Projected Volumes та serviceAccountToken.

Kubernetes API JWT authentification

Глянемо в самому поді зміст каталогу /var/run/secrets/kubernetes.io/serviceaccount:

[simterm]

$ kk exec -ti pod/test-pod -- ls -l /var/run/secrets/kubernetes.io/serviceaccount
total 0
lrwxrwxrwx    1 root     root            13 Jul  5 09:37 ca.crt -> ..data/ca.crt
lrwxrwxrwx    1 root     root            16 Jul  5 09:37 namespace -> ..data/namespace
lrwxrwxrwx    1 root     root            12 Jul  5 09:37 token -> ..data/token

[/simterm]

Тут маємо три файли, які створені з Projected Volumes, в яких ми бачили три source, кожний з власним path:

  • serviceAccountToken: містить токен, отриманий від kube-apiserver за допомогою TokenRequest API, і використовується подом для аутентифікації на Kubernetes API. Має обмежений час життя, і валідний тільки для цього конкретного поду та його ServiceAccount
    • підключається у path: token
  • configMap: бере зміст kube-root-ca.crt ConfigMap, використовується подом, щоб впевнитись, що він підключається саме до потрібного Kubernetes API
    • підключається у path: ca.crt
  • downwardAPI: отримує від API інформацію про metadata.namespace
    • підключається у path: namespace

Давайте глянемо, що в самому токені – він теж змінився.

Отримуємо сам токен:

[simterm]

$ token=`kubectl -n kube-system exec external-dns-85587d4b76-2flhg -- cat /var/run/secrets/kubernetes.io/serviceaccount/token`

[/simterm]

І дивимось зміст за допомогою jwt-cli або на сайті https://jwt.io:

[simterm]

$ jwt decode $token

Token header
------------
{
  "alg": "RS256",
  "kid": "64aacc8aa986bf6161312dfdfeba00e63ed64f9d"
}

Token claims
------------
{
  "aud": [
    "https://kubernetes.default.svc"
  ],
  "exp": 1720254790,
  "iat": 1688718790,
  "iss": "https://oidc.eks.us-east-1.amazonaws.com/id/FDF***F2F",
  "kubernetes.io": {
    "namespace": "kube-system",
    "pod": {
      "name": "external-dns-85587d4b76-2flhg",
      "uid": "d59b56f1-fa01-4a0f-8897-1933926e4d42"
    },
    "serviceaccount": {
      "name": "external-dns",
      "uid": "38c8f023-60bf-416e-b6c2-d37939ac3c06"
    },
    "warnafter": 1688722397
  },
  "nbf": 1688718790,
  "sub": "system:serviceaccount:kube-system:external-dns"
}

[/simterm]

Тут:

  • aud (audience): для кого цей токен призначений – отримувач має ідентифікувати себе з цим ім’ям, інакше токен має бути відхилений
  • exp (expiration time): “термін придатності” цього токену – після його закінчення, токен має бути відхилений
  • iat (issued at): час створення токену, від якого буде рахуватись exp
  • iss (issuer): OIDC Issuer URL нашого кластеру – той самий Identity Provider URL, який потім будемо використовувати при налаштувані AWS IAM
  • kubernetes.io: тут бачимо UID самого пода та ServiceAccount – саме тому якщо под або його ServiceAccount буде перестворено, то цей токен стане невалідним, бо зміняться UID
  • sub (subject): “ім’я користувача” цього токену – буде перевірятись у AWS IAM для авторизації дій з AWS API

Використовуючи це токен – ми з поду можемо аутентифікуватись на API нашого Kubernetes-кластеру.

Описуємо под з cURL:

---
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
    - name: curl
      image: curlimages/curl
      command: ['sleep', '36000']
  restartPolicy: Never

Створюємо його:

[simterm]

$ kubectl apply -f test-pod.yaml 
pod/test-pod created

[/simterm]

Підключаємось, та створюємо змінні:

[simterm]

$ kubectl exec -ti test-pod -- sh
~ $ SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
~ $ TOKEN=$(cat ${SERVICEACCOUNT}/token)
~ $ CACERT=${SERVICEACCOUNT}/ca.crt
~ $ curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET https://kubernetes.default.svc/api
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "ip-172-16-110-147.ec2.internal:443"
    }
  ]
}

[/simterm]

Тоді як без токену – підемо за російським кораблем отримаємо відповідь 403:

[simterm]

~ $ curl --cacert ${CACERT} -X GET https://kubernetes.default.svc/api
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/api\"",
  "reason": "Forbidden",
  "details": {},
  "code": 403
}

[/simterm]

Добре – з аутентифікацією в Kubernetes API наче розібралися, давайте глянемо на AWS.

AWS IAM Roles для Kubernetes ServiceAccounts

Для роботи з AWS API, Kubernetes Pod використовує модель IRSA – IAM Role for Service Accounts.

Хоча ви все ще можете використовувати підхід з ACCESS/SECRET через змінні оточення, або підключати необхідну роль до EC2 WorkerNode як EC2 IAM Instance Role, робота через IRSA дозволяє вам видавати права на роботу з AWS для конкретного поду, а не всіх подів на цьому ЕС2-інстансі.

У випадку ж з ACCESS/SECRET для поду – ключі у вас статичні, і по-перше – можуть бути скомпрометовані (вкрадені), по-друге – вам необхідно їх десь тримати та передавати у Deployment/StatefulSet, etc під час створення вашого workload, тоді як IRSA використовує динамічні дані доступу (credentials), яки створються під час запиту поду до IAM-ролі, і вам не потрібно їх ані зберігати, ані хвилюватись через їх витік.

Assume Role з AWS CLI

Отже, Kubernetes Pod буде виконувати AssumeRole для отримання ролі, тож давайте згадаємо, як AssumeRole працює з AWS CLI – тоді будемо краще уявляти собі, як це працює в EKS з його подами.

Описуємо IAM Policy, яка дозволяє доступ до S3-бакетів:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "*"
        }
    ]
}

Створюємо її:

[simterm]

$ aws iam create-policy --policy-name irsa-test --policy-document file://irsa-policy.json
{
    "Policy": {
        "PolicyName": "irsa-test",
        ...
        "Arn": "arn:aws:iam::492***148:policy/irsa-test",
        ...
    }
}

[/simterm]

Описуємо Trusted Policy для майбутньої IAM Role – хто зможе виконувати запит sts:AssumeRole цієї ролі до AWS API:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::492***148:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Тут в Principal "arn:aws:iam::492***148:root" вказуємо, що будь-який валідний юзер цього AWS-аккаунту може виконати "Action": "sts:AssumeRole".

Cтворюємо саму роль, якій підключаємо цю полісі:

[simterm]

$ aws iam create-role --role-name irsa-test-role --assume-role-policy-document file://irsa-trust.json
{
    "Role": {
        "Path": "/",
        "RoleName": "irsa-test-role",
        "RoleId": "AROAXFIUAIGSBE2Q2WORF",
        "Arn": "arn:aws:iam::492***148:role/irsa-test-role",
        "CreateDate": "2023-07-05T11:05:37Z",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Sid": "",
                    "Effect": "Allow",
                    "Principal": {
                        "AWS": "arn:aws:iam::492***148:root"
                    },
                    "Action": "sts:AssumeRole"
                }
            ]
        }
    }
}

[/simterm]

І додаємо до ролі політику, яка дозволяє виконувати запити до S3:

[simterm]

$ aws iam attach-role-policy --role-name irsa-test-role --policy-arn arn:aws:iam::492****148:policy/irsa-test

[/simterm]

Тепер з AWS CLI перевіряємо чи зможемо ми виконати assume цієї ролі:

[simterm]

$ aws sts assume-role --role-arn arn:aws:iam::492***148:role/irsa-test-role --role-session-name TestIrsa
{
    "Credentials": {
        "AccessKeyId": "ASI***GU3",
        "SecretAccessKey": "g5N***xhR",
        "SessionToken": "Fwo***g==",
        "Expiration": "2023-07-05T12:25:54Z"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAXFIUAIGSBE2Q2WORF:TestIrsa",
        "Arn": "arn:aws:sts::492***148:assumed-role/irsa-test-role/TestIrsa"
    }
}

[/simterm]

Працює.

Що тут відбувається?

  • AWS CLI виконує запит до AWS STS
  • STS перевіряє, чи може користувач (який у ~/.aws/credentials має ACCESS/SECRET ключі юзеру в AWS) виконувати API-запит sts:AssumeRole (а так як ми в Trust Policy  цієї ролі вказали Principal "arn:aws:iam::492***148:root" – то може)
  • якщо перевірку пройдено, то STS створює тимчасові дані доступу для цієї ролі – AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY та AWS_SESSION_TOKEN і повертає їх до AWS CLI

Далі, використовуючи ці дані, ми можемо виконувати дії від імені ціьєї IAM-ролі:

[simterm]

$ export AWS_ACCESS_KEY_ID=ASI***YHO
$ export AWS_SECRET_ACCESS_KEY=WPN***ZiN
$ export AWS_SESSION_TOKEN=Fwo***Vo=

[/simterm]

Перевіримо юзера тепер:

[simterm]

$ aws sts get-caller-identity
{
    "UserId": "AROAXFIUAIGSBE2Q2WORF:TestIrsa",
    "Account": "492***148",
    "Arn": "arn:aws:sts::492***148:assumed-role/irsa-test-role/TestIrsa"
}

[/simterm]

І глянемо чи маємо ми доступ до бакетів:

[simterm]

$ aws s3 ls
2023-02-01 13:29:34 amplify-staging-112927-deployment
2023-02-02 17:40:56 amplify-dev-174045-deployment
...

[/simterm]

Окей, з цим розібралися.

Тепер глянемо, як це відбувається в EKS.

AssumeRole as a ServiceAccount

Спочатку налаштуємо Identity Provider в IAM, створимо ServiceAccount та IAM Role, яку будемо використовувати, перевіримо, і потім глянемо як саме воно працює.

Отримуємо OpenID Connect provider URL:

[simterm]

$ aws eks describe-cluster --name eks-dev-1-26-cluster --query "cluster.identity.oidc.issuer" --output text
https://oidc.eks.us-east-1.amazonaws.com/id/FDF***F2F

[/simterm]

Переходимо до AWS Console > IAM > Identity Providers, додаємо нового провайдера з типом OpenID Connect.

Вказуємо Provider URL, клікаємо Get thumbprint:

За цим відбитком IAM в майбутньому буде перевіряти, чи дійсно до нього прийшов той самий Issuer, якого ми вказуємо в Provider URL.

В полі Audience задаємо sts.amazonaws.com – “до кого” цей IDP зможе звертатись.

Клікаємо Add provider, переходимо до нього, та копіюємо його ARN:

Створюємо файл “політики довіри” – описуємо, хто зможе виконувати Assume ролі, яку будемо створювати для нашого тестового поду:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::492***148:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/FDF***F2F"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/FDF***F2F:aud": "sts.amazonaws.com",
          "oidc.eks.us-east-1.amazonaws.com/id/FDF***F2F:sub": "system:serviceaccount:default:irsa-test-service-account"
        }
      }
    }
  ]
}

Тут:

  • Federated: ARN Identity Provider-у, якого ми створили
  • Action: яку саме дію він зможе виконувати
  • Condition: і при яких умовах – якщо sub, тобто “юзер” буде irsa-test-service-account ServiceAccount, і він буде звертатись до sts.amazonaws.com

Створюємо IAM Role, нотуємо її ARN:

[simterm]

$ aws iam create-role --role-name irsa-test --assume-role-policy-document file://irsa-trust.json
...
        "Arn": "arn:aws:iam::492***148:role/irsa-test",
...

[/simterm]

Підключимо ту саму S3 Policy, яку робили ще на початку:

[simterm]

$ aws iam attach-role-policy --role-name irsa-test --policy-arn arn:aws:iam::492***148:policy/irsa-test

[/simterm]

Описуємо ServiceAccount, в annotations якого вказуємо IAM Role ARN – тієї ролі, яку тільки що створили:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: irsa-test-service-account
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::492***148:role/irsa-test

І додаємо тестовий под з AWS CLI, якому вказуємо цей serviceAccountName:

---
apiVersion: v1
kind: Pod
metadata:
  name: irsa-test-pod
spec:
  containers:
    - name: aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  serviceAccountName: irsa-test-service-account

Деплоїмо:

[simterm]

$ kubectl apply -f irsa-sa.yaml 
serviceaccount/irsa-test-service-account created
pod/irsa-test-pod created

[/simterm]

Підключаємось в под, і пробуємо переглянути S3 корзини в аккаунті:

[simterm]

sh-4.2# aws s3 ls
2023-02-01 11:29:34 amplify-staging-112927-deployment
2023-02-02 15:40:56 amplify-dev-174045-deployment
...

[/simterm]

І переконаємось, що ми це зробили дійсно використовуючи роль irsa-test:

[simterm]

sh-4.2# aws sts get-caller-identity
{
    "UserId": "AROAXFIUAIGSM3R35H4WY:botocore-session-1688726924",
    "Account": "492***148",
    "Arn": "arn:aws:sts::492***148:assumed-role/irsa-test/botocore-session-1688726924"
}

[/simterm]

А тепер розберемося, як воно працює.

IRSA та Amazon EKS Pod Identity webhook

Глянемо на наш под, як ми це робили на самому початку з подом ExternalDNS:

[simterm]

$ kubectl get pod/irsa-test-pod -o yaml
...
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::492***148:role/irsa-test
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
...
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-frc4n
      readOnly: true
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
...
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
  - name: kube-api-access-frc4n
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace

[/simterm]

Ми вже розбирали що знаходиться в /var/run/secrets/kubernetes.io/serviceaccount/token, який створюється з Projected Volume kube-api-access-frc4n – теперь глянемо на /var/run/secrets/eks.amazonaws.com/serviceaccount/token.

Для нього використовується той самий тип serviceAccountToken, якому передається audience: sts.amazonaws.com. В результаті маємо JWT-токен для аутентифікації в AWS:

[simterm]

$ token=`kubectl exec -ti pod/irsa-test-pod -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token`
$ jwt decode $token
...
Token claims
------------
{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1688813222,
  "iat": 1688726822,
  "iss": "https://oidc.eks.us-east-1.amazonaws.com/id/FDF***F2F",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "irsa-test-pod",
      "uid": "cc040630-1e85-4339-9699-7106c2b37a9b"
    },
    "serviceaccount": {
      "name": "irsa-test-service-account",
      "uid": "65b197d7-1609-433c-825e-b423f622978b"
    }
  },
  "nbf": 1688726822,
  "sub": "system:serviceaccount:default:irsa-test-service-account"
}

[/simterm]

Бачимо всі тіж поля:

  • aud: має співпадати з audience нашого Identity Provider в AWS AIM (інакше отримаємо помилку “An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Incorrect token audience” – я с першого разу помилився, коли додавав IDP – в Audience вказав sts.amazon.com замість sts.amazonaws.com)
  • iss: IAM буде перевіряти, від кого прийшов токен, і чи може він довіряти цьому джерелу
  • sub: буде використовуватись у IAM Role Trusted Policy – згадайте Condition.StringEquals у файлі irsa-trust.json

Тобто, з цим токеном ми можемо звернутись до AWS STS, і отримати temporary crdentials, за якими зможемо виконати запит на sts:AssumeRoleWithWebIdentity.

Перевіримо?

Використаємо AWS CLI та assume-role-with-web-identity:

[simterm]

sh-4.2# token=`cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token`
sh-4.2# aws sts assume-role-with-web-identity --role-session-name "test-irsa" --role-arn arn:aws:iam::492***148:role/irsa-test --web-identity-token $token
{
    "Credentials": {
        "AccessKeyId": "ASI***PUU",
        "SecretAccessKey": "Y/Z***KQW",
        "SessionToken": "IQo***A==",
        "Expiration": "2023-07-07T12:54:30+00:00"
    },
    "SubjectFromWebIdentityToken": "system:serviceaccount:default:irsa-test-service-account",
    "AssumedRoleUser": {
        "AssumedRoleId": "AROAXFIUAIGSM3R35H4WY:test-irsa",
        "Arn": "arn:aws:sts::492***148:assumed-role/irsa-test/test-irsa"
    },
    "Provider": "arn:aws:iam::492***148:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/FDF***F2F",
    "Audience": "sts.amazonaws.com"
}

[/simterm]

Wow! It’s a magic!

То щож відбувається, коли ми створюємо ServiceAccount с IAM Role ARN в аннотаціях?

Чудово описано ось тут – Introducing fine-grained IAM roles for service accounts:

Отже:

  • при створенні пода з ServiceAccount, якому вказано IAM Role, Amazon EKS Pod Identity webhook створює змінні оточення AWS_ROLE_ARN та AWS_WEB_IDENTITY_TOKEN_FILE, і додає aws-iam-token projected volume, в якому генерує JWT
  • при роботі процесу всередині поду – цей процес (AWS CLI, CDK, SDK, whatever) використовує змінні оточення:
    • AWS_ROLE_ARN – щоб знати, Assume якої ролі робити
    • та AWS_WEB_IDENTITY_TOKEN_FILE – що знати, звідки йому взяти токен для аутентифікації в AWS

Тобто, коли ми викликали aws s3 ls і не передавали йому ніяких параметрів – він просто взяв їх з оточення:

[simterm]

sh-4.2# env | grep AWS_
AWS_ROLE_ARN=arn:aws:iam::492***148:role/irsa-test
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
AWS_DEFAULT_REGION=us-east-1
AWS_REGION=us-east-1
AWS_STS_REGIONAL_ENDPOINTS=regional

[/simterm]

That’s all, folks!

Корисні посилання

Loading

AWS: CDK – створення EKS з Python та загальні враження від CDK
0 (0)

23 Червня 2023

Terraform то чудово, але поки що вирішили перші кластера AWS EKS створювати за допомогою AWS CDK, бо по-преше – він вже є на проекті, по-друге – самому цікаво спробувати новий інструмент.

Тож сьогодні розглянемо що з цього вийшло, та як створювався кластер і необхідні ресурси.

Про перше знайомство з СDK писав тут – AWS: CDK – знайомство та приклади на Python.

Забігаючи наперед – особисто я, дуже м’яко кажучи, не в захваті від CDK:

  • ніякого тобі KISS – Keep It Simple Stupid, ніякого тобі “явне краще неявного”
  • місцями незрозуміла документація з приклами на TypeScript навіть в репозиторії PyPi
  • купа окремих бібліотек та модулів, іноді геморой з їхніми імпортами
  • загальна перенавантаженість коду CDK/Python – Terraform з його HCL або Pulumi з Python виглядає набагато простішим для розуміння загальної картини інфрастуктури, котора цим кодом описана
  • перенавантаженість самого CloudFormation стеку, створенного за допомогою CDK – купа IAM-ролей, якісь Lambda-функції і таке інше – коли воно зламається, то доведеться дуже довго шукати де і що саме “пішло не так”
  • питати Google на тему “AWS CDK Python create something” – майже марна справа, бо результатів або не буде взагалі, але будуть на TypeScript

Хоча пост планувався в стилі “як зробити”, але в результаті вийшло “Як вистрілити собі в ногу, запроваджуючи на проекті AWS CDK”.

AWS CDK vs Terraform

Знову-таки, хоча сам пост не про це, але кілька слів після роботи з CDK та його порівняння з Terraform.

Time To Create: AWS CDK vs Terraform

Перше, що хочеться прям на початку показати – це швидкість роботи AWS CDK vs Terraform:

Тест, звісно, достаточно штучний, але дуже гарно показав різницю в роботі.

Я спецільно не створював NAT Gateways, бо їхнє створення займає більше хвилини просто на запуск самих NAT-інстансів, тоді як на створення VPC/Subnets/etc час не витрачається, тож бачимо саме швидкість роботи CDK/CloudFormation versus Terraform.

Пізніше ще заміряв створення VPC+EKS з CDK та Terraform:

CDK

  • create: 18m54.643s
  • destroy: 26m4.509s

Terraform:

  • create: 12m56.801s
  • destroy: 5m32.329s

AWS CDK workflow

Та й в цілому процес роботи CDK виглядає занадто ускладненим:

  • пишемо код на Python
  • який траснлюється до бекенду CDK на NodeJS
  • генерує CloudFormation Template та ChangeSets
  • CDK для своєї роботи створює пачку Lambda-функцій
  • і тільки потім створюються ресурси

Плюс в самому CloudFormation стеку для EKS створюється ціла купа AIM ролей та Lambda-функцій з неясним та неявним призначенням.

AWS CDK та нові “фічі” AWS

Ще з насправді досить очікуваного – CDK не має всіх нових “плюшок” AWS. Я с цим зіткнувся ще кілька років тому, коли потрібно було у CloudFormation створити cross-region VPC Peering, а CloudFormation це не підтримував, хоча у Terraform це вже було реалізовано.

Аналогічно виявилось і зараз: остання версія CDK (2.84.0) не має підтримки EKS 1.27, реліз якої відбувся майже місць тому, 24-го травня – Amazon EKS now supports Kubernetes version 1.27.  А ось Terraform її вже підтримує – AWS EKS Terraform module.

Але таке. Окей, най буде, як то кажуть.

Давайте пробувати.

Початок роботи: спитаємо ChatGPT

Щоб мати якусь точку для старту – спитав ChatGPT. В цілому, ідею від подав, хоча з застарілими імпортами та деякими атрибутами, які довелось переписувати:

Поїхали.

Python virtualevn

Створюємо Python virtualevn:

[simterm]

$ python -m venv .venv
$ ls -l .venv/
total 16
drwxr-xr-x 2 setevoy setevoy 4096 Jun 20 11:18 bin
drwxr-xr-x 3 setevoy setevoy 4096 Jun 20 11:18 include
drwxr-xr-x 3 setevoy setevoy 4096 Jun 20 11:18 lib
lrwxrwxrwx 1 setevoy setevoy    3 Jun 20 11:18 lib64 -> lib
-rw-r--r-- 1 setevoy setevoy  176 Jun 20 11:18 pyvenv.cfg

[/simterm]

Активуємо його:

[simterm]

$ . .venv/bin/activate
(.venv)

[/simterm]

Тепер можемо створювати новий application.

AWS CDK Init

Створюємо шаблон нашого стеку з Python:

[simterm]

$ cdk init app --language python
...
✅ All done!

[/simterm]

Отримуємо таку структуру файлів та каталогів:

[simterm]

$ tree .
.
├── README.md
├── app.py
├── atlas_eks
│   ├── __init__.py
│   └── atlas_eks_stack.py
├── cdk.json
├── requirements-dev.txt
├── requirements.txt
├── source.bat
└── tests
    ├── __init__.py
    └── unit
        ├── __init__.py
        └── test_atlas_eks_stack.py

4 directories, 11 files

[/simterm]

Встановлюємо залежності:

[simterm]

$ pip install -r requirements.txt
Collecting aws-cdk-lib==2.83.1
  Using cached aws_cdk_lib-2.83.1-py3-none-any.whl (41.5 MB)
...

[/simterm]

Перевіряємо, що все працює:

[simterm]

$ cdk list
AtlasEksStack

[/simterm]

Зміст app.py зараз маємо такий:

Та у atlas_eks/atlas_eks_stack.py маємо шаблон для створення стеку:

from aws_cdk import (
    # Duration,
    Stack,
    # aws_sqs as sqs,
)
from constructs import Construct

class AtlasEksStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # The code that defines your stack goes here

        # example resource
        # queue = sqs.Queue(
        #     self, "AtlasEksQueue",
        #     visibility_timeout=Duration.seconds(300),
        # )

Додамо змінні оточення до app.py – аккаунт та регіон, та оновлюємо виклик AtlasEksStack():

...
AWS_ACCOUNT = os.environ["AWS_ACCOUNT"]
AWS_REGION = os.environ["AWS_REGION"]

app = cdk.App()
AtlasEksStack(app, "AtlasEksStack",
        env=cdk.Environment(account=AWS_ACCOUNT, region=AWS_REGION),
    )
...

Задаємо змінні в консолі:

[simterm]

$ export AWS_ACCOUNT=492***148 
$ export AWS_REGION=us-east-1

[/simterm]

Перевіряємо ще раз з cdk list.

Створення EKS кластеру

Повертаємось до ChatGPT, що він там далі рекомендує:

Нам тут цікаві тільки імпорти (з якими він не вгадав), та сам ресурс cluster = eks.Cluster(), якому він пропонує версію 1.21, бо сам ChatGPT, як ми знаємо, має базу до 2021 року.

CDK: AttributeError: type object ‘KubernetesVersion’ has no attribute ‘V1_27’

Щодо AWS CDK та версії EKS, писав про це на початку – виглядала помилка так:

AttributeError: type object ‘KubernetesVersion’ has no attribute ‘V1_27’

Окей – давайте поки 1.26, там подивимось, як з цим жити.

Обновлюємо файл atlas_eks_stack.py, використовуємо eks.KubernetesVersion.V1_26:

from aws_cdk import (
    aws_eks as eks,
    Stack
)
from constructs import Construct

class AtlasEksStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        cluster = eks.Cluster(
            self, 'EKS-Cluster',
            cluster_name='my-eks-cluster',
            version=eks.KubernetesVersion.V1_26,
        )

Перевіряємо з cdk synth:

[simterm]

$ cdk synth
[Warning at /AtlasEksStack/EKS-Cluster] You created a cluster with Kubernetes Version 1.26 without specifying the kubectlLayer property. This may cause failures as the kubectl version provided with aws-cdk-lib is 1.20, which is only guaranteed to be compatible with Kubernetes versions 1.19-1.21. Please provide a kubectlLayer from @aws-cdk/lambda-layer-kubectl-v26.
Resources:
  EKSClusterDefaultVpc01B29049:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsHostnames: true
      EnableDnsSupport: true
      InstanceTenancy: default
      Tags:
        - Key: Name
          Value: AtlasEksStack/EKS-Cluster/DefaultVpc
    Metadata:
      aws:cdk:path: AtlasEksStack/EKS-Cluster/DefaultVpc/Resource
...

[/simterm]

CDK сам тсворить VPC та subnets і все інше для мережі, та IAM ролі. Це, в принципі, зручно, хоча там є свої питання.

Ми далі будемо створювати власну VPC.

Warning: You created a cluster with Kubernetes Version 1.26 without specifying the kubectlLayer property

На початку cdk synth каже щось про kubectlLayer:

[Warning at /AtlasEksStack/EKS-Cluster] You created a cluster with Kubernetes Version 1.26 without specifying the kubectlLayer property. This may cause failures as the kubectl version provided with aws-cdk-lib is 1.20, which is only guaranteed to be compatible with Kubernetes versions 1.19-1.21. Please provide a kubectlLayer from @aws-cdk/lambda-layer-kubectl-v26.

З імені можно припустити, що CDK створить Lambda-функцію, в якій буде викликати kubectl для виконання якихось задач в самоу Kubernetes.

В документації KubectlLayer сказано, що “An AWS Lambda layer that includes kubectl and helm.”

Дуже дякую – все відразу стало зрозуміло. Де воно використовується, для чого?

Ну, ок… Давайте спробуємо позбутися цього варнінгу.

Знову спитаємо ChatGP:

Пробуємо встановити aws-lambda-layer-kubectl-v26:

[simterm]

$ pip install aws-cdk.aws-lambda-layer-kubectl-v26
ERROR: Could not find a version that satisfies the requirement aws-cdk.aws-lambda-layer-kubectl-v26 (from versions: none)
ERROR: No matching distribution found for aws-cdk.aws-lambda-layer-kubectl-v26

[/simterm]

Da f*****ck!

Ну, добре… Пам’ятаємо, що ChatGP “старенький” – може, ліба якось інакше називається?

PyPI no longer supports ‘pip search’

Пробуємо pip search – спочатку перевіримо, що search в PiP взагалі є, бо давно ним не користувався:

[simterm]

$ pip search --help

Usage:   
  pip search [options] <query>

Description:
  Search for PyPI packages whose name or summary contains <query>.

Search Options:
  -i, --index <url>           Base URL of Python Package Index (default https://pypi.org/pypi)
...

[/simterm]

Окей – шукаємо:

[simterm]

$ pip search aws-lambda-layer-kubectl
ERROR: XMLRPC request failed [code: -32500]
RuntimeError: PyPI no longer supports 'pip search' (or XML-RPC search). Please use https://pypi.org/search (via a browser) instead. See https://warehouse.pypa.io/api-reference/xml-rpc.html#deprecated-methods for more information.

[/simterm]

WHAAAAT?!?

Тобто, просто з консолі з PiP знайти пакет неможливо? Це як так? Трохи “розрив шаблону”.

Окей – поки лишимо, як є, хоча далі з цим знову зустрінемось, і таки доведеться фіксити.

Змінні в CDK Stack

Що тепер хочеться, це додати змінну для Environment – Dev/Stage/Prod, і потім використовати її в іменах ресурсів та тегах.

Додамо до app.py змінну $EKS_STAGE, а до створення AtlasEksStack() – передаємо її другим агрументом, щоб використати як ім’я стеку, і додаємо параметр stage, що потім використовувати всередені класу:

...
EKS_STAGE = os.environ["EKS_ENV"]


app = cdk.App()
AtlasEksStack(app, "f'eks-{EKS_STAGE}-1-26'",
        env=cdk.Environment(account=AWS_ACCOUNT, region=AWS_REGION),
        stage=EKS_STAGE
    )
...

Далі у файлі atlas_eks_stack.py описуємо параметр stage: str, і використовуємо його при створенні eks.Cluster() у параметрі cluster_name:

...
    def __init__(self, scope: Construct, construct_id: str, stage: str, **kwargs)
    ...
        cluster = eks.Cluster(
            self, 'EKS-Cluster',
            cluster_name=f'eks-{stage}-1-26-cluster',
            version=eks.KubernetesVersion.V1_26,
        )

Задаємо змінну оточення в терміналі:

[simterm]

$ export EKS_ENV=dev

[/simterm]

З cdk list перевіримо, що ім’я стеку змінилось і має $EKS_ENV:

[simterm]

$ cdk list
eks-dev-1-26

[/simterm]

Та з sdk synth перевіримо, що ім’я кластеру теж змінилось:

[simterm]

$ cdk synth
...
    Type: Custom::AWSCDK-EKS-Cluster
    Properties:
      ServiceToken:
        Fn::GetAtt:
          - awscdkawseksClusterResourceProviderNestedStackawscdkawseksClusterResourceProviderNestedStackResource9827C454
          - Outputs.AtlasEksStackawscdkawseksClusterResourceProviderframeworkonEvent588F9666Arn
      Config:
        name: eks-dev-1-26-cluster
...

[/simterm]

Добре – кластер є, тепер створимо для нього VPC.

Створення VPC та Subnets

Кастомну VPC хочеться, бо по-дефолту CDK створить по Subnet-у у кожній AvailabilityZone, тобто три мережі, плюс до кожної буде свій NAT Gateway. Але по-перше – мені більше подобається самому контролювати розбивку мережі, по-друге – кожен NAT Gateway коштує грошей, а нам поки що fault-tolerance аж на три AvailabilityZone не потрібен, краще зекономити трохи грошей.

Документація по CDK VPC – aws_cdk.aws_ec2.Vpc.

Типи Subnet тут – SubnetType.

Тут як на мене ще один не найкращий нюанс CDK: так, це зручно, що він має багато викорорівневих ресурсів, коли тобі достатньо просто вказати subnet_type=ec2.SubnetType.PUBLIC, а CDK сам створить все необхідне, але особисто мені декларативний підхід Terraform та його HCL виглядає привабливішим, бо навіть якщо використовувати модуль VPC, а не описувати все вручну – набагато простіше зайти в код того модулю і подивитись, що він має “під капотом”, ніж копатись у бібліотеці CDK. Але це чисто особисте “Я так бачу“.

Крім того, в документації не сказано, що PRIVATE_WITH_NAT вже deprecated, побачив це тільки коли перевіряв створення ресурсів:

[simterm]

$ cdk synth
[WARNING] aws-cdk-lib.aws_ec2.VpcProps#cidr is deprecated.
  Use ipAddresses instead
  This API will be removed in the next major release.
[WARNING] aws-cdk-lib.aws_ec2.SubnetType#PRIVATE_WITH_NAT is deprecated.
  use `PRIVATE_WITH_EGRESS`
  This API will be removed in the next major release.
[WARNING] aws-cdk-lib.aws_ec2.SubnetType#PRIVATE_WITH_NAT is deprecated.
  use `PRIVATE_WITH_EGRESS`
  This API will be removed in the next major release.
...

[/simterm]

Окей.

Додаємо availability_zones, в яких хочемо створювати subnets, і описуємо subnet_configuration.

В subnet_configuration описуємо subnet group – одну Public, та одну Private – CDK створить subnet кожного типу в кожній Availability Zone.

На майбутнє – відразу створимо S3 Endpoint, бо в кластері планується Grafana Loki, яка буде ходити в S3 бакети.

До ресурсу eks.Cluster() додаємо параметр vpc.

Весь файл тепер виглядає так:

from aws_cdk import (
    aws_eks as eks,
    aws_ec2 as ec2,
    Stack
)
from constructs import Construct

class AtlasEksStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, stage: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        availability_zones = ['us-east-1a', 'us-east-1b']

        # Create a new VPC
        vpc = ec2.Vpc(self, 'Vpc',
            ip_addresses=ec2.IpAddresses.cidr("10.0.0.0/16"),
            vpc_name=f'eks-{stage}-1-26-vpc',
            enable_dns_hostnames=True,
            enable_dns_support=True,
            availability_zones=availability_zones,
            subnet_configuration=[
                ec2.SubnetConfiguration(
                    name=f'eks-{stage}-1-26-subnet-public',
                    subnet_type=ec2.SubnetType.PUBLIC,
                    cidr_mask=24
                ),
                ec2.SubnetConfiguration(
                    name=f'eks-{stage}-1-26-subnet-private',
                    subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS,
                    cidr_mask=24
                )
            ]
        )

        # Add an S3 VPC endpoint
        vpc.add_gateway_endpoint('S3Endpoint',
                                 service=ec2.GatewayVpcEndpointAwsService.S3)

        cluster = eks.Cluster(
            self, 'EKS-Cluster',
            cluster_name=f'eks-{stage}-1-26-cluster',
            version=eks.KubernetesVersion.V1_26,
            vpc=vpc
        )

Деплоємо, перевіряємо:

[simterm]

$ cdk deploy eks-dev-1-26
...
eks-dev-1-26: deploying... [1/1]
eks-dev-1-26: creating CloudFormation changeset...
...
✨  Total time: 1243.08s

[/simterm]

1243.08s секунд – 20 хвилин. Окей…

Додавання Stack Tags

Що ще хочеться – це додати власні теги до всіх ресурсів, які буде створювати CDK в цьому стеку.

В app.py використовуємо cdk.Tags, якому передаємо об’єкт AtlasEksStack():

...
app = cdk.App()

eks_stack = AtlasEksStack(app, f'eks-{EKS_STAGE}-1-26',
        env=cdk.Environment(account=AWS_ACCOUNT, region=AWS_REGION),
        stage=EKS_STAGE
    )
cdk.Tags.of(eks_stack).add("environment", EKS_STAGE)
cdk.Tags.of(eks_stack).add("component", "EKS")

app.synth()

Деплоїмо (Total time: 182.67s просто на додавання тегів на ресурси), та перевіряємо теги:

Все є.

Створення NodeGroup

Взагалі скоріш за все будемо використовувати Karpenter замість “класичного” Cluster Autoscaler, бо про Karpenter чув багато гарних відгуків і хочеться його спробувати у ділі, і тоді ноди треба буде переробити, але поки що створимо звичайну Managed NodeGroup за допомогою add_nodegroup_capacity().

До файлу atlas_eks_stack.py додаємо cluster.add_nodegroup_capacity() з Amazon Linux AMI :

...
        # Create the EC2 node group
        nodegroup = cluster.add_nodegroup_capacity(
            'Nodegroup',
            instance_types=[ec2.InstanceType('t3.medium')],
            desired_size=1,
            min_size=1,
            max_size=3,
            ami_type=eks.NodegroupAmiType.AL2_X86_64
        )

Необхідні IAM-ролі CDK має створити сам – подивимось.

У ресурсі eks.Cluster() вказуємо default_capacity=0, щоб СDK не створював власну дефолтну групу:

...
        cluster = eks.Cluster(
            self, 'EKS-Cluster',
            cluster_name=f'eks-{stage}-1-26-cluster',
            version=eks.KubernetesVersion.V1_26,
            vpc=vpc,
            default_capacity=0
        )
...

Error: b’configmap/aws-auth configured\nerror: error retrieving RESTMappings to prune: invalid resource batch/v1beta1, Kind=CronJob, Namespaced=true: no matches for kind “CronJob” in version “batch/v1beta1″\n’

Зараз стек вже задеплоєно, запускаємо cdk deploy, щоб оновити – і…

[simterm]

eks-dev-1-26: creating CloudFormation changeset...
1:26:35 PM | UPDATE_FAILED        | Custom::AWSCDK-EKS-KubernetesResource | EKSClusterAwsAuthmanifest5D430CCD
Received response status [FAILED] from custom resource. Message returned: Error: b'configmap/aws-auth configured\nerror: error retrieving RESTMappings to prune: invalid resource batch/v1beta1, Kind=CronJob, Namespaced=true: no matches for kind "CronJob" in version "bat
ch/v1beta1"\n'

[/simterm]

Шта? Якого біса?

aws-auth ConfigMap, Kind=CronJob? Звідки це?

Тобто, мабуть, CDK намагається оновити aws-auth ConfigMap, щоб додати NodeGroup AIM роль, але… Але – що?

Судячи з Гуглу, проблема як раз пов’язана з kubectlLayer, про яку писав вище – aws-eks: cdk should validate cluster version and kubectl layer version.

При чьому проявляється це тільки під час оновлення стеку. Якщо створювати його заново – то все працює. Але тут варто згадати про швидкість роботи CDK/CloudFormation, бо видалення і створення займає хвилин 30-40.

KubectlV26Layer

Ну, все ж довелося фіксити цю проблему.

Добре… Шукаємо просто в браузері – aws-cdk.lambda-layer-kubectl-v26. Є така ліба. Але навіть у PyPi репозиторії приклади на TypeScript – щиро дякую:

Це взагалі проблема при роботі з AWS CDK на Python – дуже багато прикладів все одно на TS.

Окей, ладно – лібу знайшли, вона називається aws-cdk.lambda-layer-kubectl-v26, встановлюємо:

[simterm]

$ pip install aws-cdk.lambda-layer-kubectl-v26

[/simterm]

Додаємо до requirements.txt:

[simterm]

$ pip freeze | grep -i lambda-layer-kubectl >> requirements.txt

[/simterm]

Додаємо у файл atlas_eks_stack.py:

...
from aws_cdk.lambda_layer_kubectl_v26 import KubectlV26Layer
...

        # to fix warning "You created a cluster with Kubernetes Version 1.26 without specifying the kubectlLayer property" 
        kubectl_layer = KubectlV26Layer(self, 'KubectlV26Layer')
        ...
        cluster = eks.Cluster(
            self, 'EKS-Cluster',
            cluster_name=f'eks-{stage}-1-26-cluster',
            version=eks.KubernetesVersion.V1_26,
            vpc=vpc,
            default_capacity=0,
            kubectl_layer=kubectl_layer
        )
...

Повторюємо деплой для апдейту вже існуючого стеку, і…

CloudFormation UPDATE_ROLLBACK_FAILED

І маємо іншу помилку, бо після “Error: b’configmap/aws-auth configured\nerror” стек лишився у статусі UPDATE_ROLLBACK_FAILED:

[simterm]

...
eks-dev-1-26: deploying... [1/1]
eks-dev-1-26: creating CloudFormation changeset...

 ❌  eks-dev-1-26 failed: Error [ValidationError]: Stack:arn:aws:cloudformation:us-east-1:492***148:stack/eks-dev-1-26/9c7daa50-10f4-11ee-b64a-0a9b7e76090b is in UPDATE_ROLLBACK_FAILED state and can not be updated.
...

[/simterm]

Тут варіант або просто видалити стек і створити заново (вбити ще хвилин 30-40 свого часу), або погуглилити та знайти How can I get my CloudFormation stack to update if it’s stuck in the UPDATE_ROLLBACK_FAILED state.

Спробуємо ContinueUpdateRollback:

Але нє – все-одно стек поломаний:

Тож видаляємо, і йдемо на Фейсбук дивитись котиків, поки воно буде перестворюватись.

Cannot replace cluster “since it has an explicit physical name

На цьому місці ще ловив “Cannot replace cluster “eks-dev-1-26-cluster” since it has an explicit physical name.“, виглядало це так:

[simterm]

...
2:30:45 PM | UPDATE_FAILED        | Custom::AWSCDK-EKS-Cluster            | EKSCluster676AE7D7
Received response status [FAILED] from custom resource. Message returned: Cannot replace cluster "eks-dev-1-26-cluster" since it has an explicit physical name. Either rename the cluster or remove the "name" configuration
...

[/simterm]

Але на цей раз не зарепродьюсилось, хоча треба мати на увазі, бо точно вилізе ще колись.

Добре, отже тепер вже маємо VPC, EKS Cluster та NodeGroup – час подумати про IAM.

IAM Role та aws-auth ConfigMap

Що треба зробити наступним – це створити IAM-роль, яку можна буде assume для отримання доступу до кластеру.

Поки що без всяких RBAC та юзер-груп – просто роль, щоб потім виконати aws eks update-kubeconfig.

Використовуємо aws_cdk.aws_iam.Role() і  aws_cdk.aws_eks.AwsAuth():

from aws_cdk import (
    ...
    aws_iam as iam,
    ...
)
...
        # Create an IAM Role to be assumed by admins
        masters_role = iam.Role(
            self,
            'EksMastersRole',
            assumed_by=iam.AccountRootPrincipal()
        )

        # Attach an IAM Policy to that Role so users can access the Cluster
        masters_role_policy = iam.PolicyStatement(
            actions=['eks:DescribeCluster'],
            resources=['*'],  # Adjust the resource ARN if needed
        )
        masters_role.add_to_policy(masters_role_policy)

        cluster.aws_auth.add_masters_role(masters_role)

        # Add the user to the cluster's admins
        admin_user = iam.User.from_user_arn(self, "AdminUser", user_arn="arn:aws:iam::492***148:user/arseny")
        cluster.aws_auth.add_user_mapping(admin_user, groups=["system:masters"])

masters_role – роль, яку можна буде assume будь-ким з AWS-аккаунту, а admin_user – мій IAM юзер для “прямого” доступу до кластеру.

CfnOutput

Outputs CloudFormation-стеку. Наскільки пам’ятаю, може використовуватись для cross-stack передачі values, але нам більше треба для отримання ARN-у masters_role:

from aws_cdk import (
    ...
    Stack, CfnOutput
)
...
        # Output the EKS cluster name
        CfnOutput(
            self,
            'ClusterNameOutput',
            value=cluster.cluster_name,
        )

        # Output the EKS master role ARN
        CfnOutput(
            self,
            'ClusterMasterRoleOutput',
            value=masters_role.role_arn
        )

Деплоїмо:

[simterm]

...
Outputs:
eks-dev-1-26.ClusterMasterRoleOutput = arn:aws:iam::492***148:role/eks-dev-1-26-EksMastersRoleD1AE213C-1ANPWK8HZM1W5
eks-dev-1-26.ClusterNameOutput = eks-dev-1-26-cluster

[/simterm]

Налаштування kubectl з AWS CLI

Ну й врешті-решт, після всіх страждань – спробуємо отримати доступ до кластеру.

Спочатку через master_role – оновлюємо ~/.aws/config:

[profile work]
region = us-east-1
output = json

[profile work-eks]
role_arn = arn:aws:iam::492***148:role/eks-dev-1-26-EksMastersRoleD1AE213C-1ANPWK8HZM1W5
source_profile = work

У [profile work-eks] виконуємо IAM Role Assume – використовуємо нашу master_role, використовуючи ACCESS/SECRET ключи профайлу [work].

Створюємо kube-config:

[simterm]

$ aws --profile work-eks eks update-kubeconfig --region us-east-1 --name eks-dev-1-26-cluster --alias eks-dev-1-26
Added new context eks-dev-1-26 to /home/setevoy/.kube/config

[/simterm]

І перевіряємо доступ:

[simterm]

$ kubectl get node
NAME                        STATUS   ROLES    AGE   VERSION
ip-10-0-2-60.ec2.internal   Ready    <none>   19h   v1.26.4-eks-0a21954

[/simterm]

Аналогічно, якщо використовувати персональний AIM-аккаунт, тобто user_arn="arn:aws:iam::492***148:user/arseny":

[simterm]

$ aws --profile work eks update-kubeconfig --region us-east-1 --name eks-dev-1-26-cluster --alias eks-dev-1-26-personal

[/simterm]

“Вона працює” (с)

По результату можу сказати одне – особисто я не готовий брати відповідальність за роботу такого стеку у production.

Можливо, якщо з CDK попрацювати ще, і знати основні його підводні камені, та згадати всі “особливості” CloudFormation – то з ними можна жити. Але поки що – ні, взагалі не хочеться.

Loading

VictoriaMetrics: знайомство та використання замість Prometheus
0 (0)

8 Червня 2023

Давно і багато чув про VictoriaMetrics, і нарешті настав час, коли її можна спробувати.

Отже, в двох словах – VictoriaMetrics це “Prometheus на стероідах”, і повністю з ним сумісна – може використовувати його файли конфігурації, експортери, PromQL тощо.

Тож як для людини, яка завжди користувалась Prometheus, перше питання – в чьому різниця? Єдине, що пам’ятаю, це те, що VictoriaMetrics начебто вміє в anomaly detection, чого не вистачало в Prometheus – давно хотілось додати.

В Google порівнянь не так багато, але знайшлись такі:

З цікавого:

  • підримує Pull та Push  моделі (на відміну від Prometheus, якому для push потрібен Pushgateway)
  • можна налаштувати Prometheus з remote write у VictoriaMetrics, тобто з Prometheus писати дані у VictoriaMetrics
  • VictoriaMetrics має концепцію “неймспейсів” – можна мати ізольовані середовища для метрик, див. Multitenancy
  • має власний MetricsQL з ширшими ніж у PromQL можливостями
  • для знайомства є VictoriaMetrics playground
  • для AWS є Managed VictoriaMetrics

Отже, сьогодні глянемо на архітектуру і компоненти, запустимо VictoriaMetrics з Docker Compose, налаштуємо збір метрик с Prometheus exporters, глянемо як там з алертами, і підключимо Grafana.

Prometheus з Alertmanager, пачка експортерів та Grafana вже є, наразі запущені просто через Docker Compose на AWS EC2, туди ж додамо інстанс VictoriaMetrics. Тобто основна ідея – замінити Prometheus на VictoriaMetrics.

З того, що побачив поки запускав VictoriaMetrics – виглядає прям дуже цікаво. Більше можливостей по функціям, по шаблонам алертів, сам UI дає більше можливостей для роботи з метриками. Спробуємо його використати замість Prometehus в нашому проекті, подивимось, як воно буде. Правда, якихось прикладів в тому ж Гуглі небагато, проте ChatGPT може допомогти.

Архітектура VictoriaMetrics

VictoriaMetrics має cluster version та single-node version. Для невеликих проектів до мільйона метрик в секунду рекомендується використовувати single node, але у кластер-версії гарно описана загальна архітектура.

Основні сервіси та компоненти VictoriaMetrics:

  • vmstorage: відповідає за зберігання даних та відповіді на запит даних клієнтами (vmselect)
  • vmselect: відповідає за обробку вхідних запитів на вибірку даних та збор даних з нод vmstorage
  • vminsert: відповідає за прийом метрик та розподіл даних по нодам vmstorage у відповідності до імен та лейбл цих метрик
  • vmui: Web UI для доступу к даним і параметрам конфігурацї
  • vmalert: обробляє алерти з файлу конфігурації та відправляє їх до Alertmanager
  • vmagent: займається збором метрик з різних джерел, таких як експортери Prometheus, їхнє фільтрування та релейбл, і зберігання у сховищі даних (самій VictoriaMetrics або через remote_write протокол Prometheus)
  • vmanomaly:  VictoriaMetrics Anomaly Detection – сервіс, який постійно сканує дані у VictoriaMetrics і за допомогою механізмів machine learning виявляє несподівані зміни, які можна використовувати у алертах
  • vmauth: простий auth proxy, роутер та лоад-балансер для VictoriaMetrics.

Запуск VictoriaMetrics з Docker Compose

Отже, як ми можемо використати VictoriaMetrics у випадку, якщо вже є Prometheus та його експортери?

  1. можемо налаштувати Prometheus слати метрики у VictoriaMetrics, див. Prometheus setup (майте на увазі, що remote_write на Prometheus-інстансі збільшить споживання ресурсів ЦПУ та диску на 25%) – не бачу сенсу в нашому випадку, але можливо буде корисним у разі використання якогось KubePrometehusStack
  2. можемо налаштувати VictoriaMetrics на збір даних з експортерів Prometheus, див. How to scrape Prometheus exporters such as node-exporter, тобто як раз зробити те, що хочеться зараз – замінити Prometheus на VictoriaMetrics з мінімальними змінами у конфігурації Prometheus

Приклад Docker Compose файлу – docker-compose.yml.

Що ми в ньому маємо:

  • vmagent: збирає метрики з експортерів,див опції у Advanced usage
  • victoriametrics: зберігає дані, див опції у List of command-line flags
  • vmalert: працює з алертами, див опції у Flags
  • alertmanager: старий знайомий) приймає алерти від vmalert

Давайте почнемо з контейнерів vmagent та victoriametrics, алерти підключимо пізніше.

Тут приклад з усіма сервісами окрім експортерів Prometheus:

version: '3.8'

volumes:
  prometheus_data: {}
  grafana_data: {}
  vmagentdata: {}
  vmdata: {}

services:
  prometheus:
    image: prom/prometheus
    restart: always
    volumes:
      - ./prometheus:/etc/prometheus/
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/usr/share/prometheus/console_libraries'
      - '--web.console.templates=/usr/share/prometheus/consoles'
      - '--web.external-url=http://100.***.****.197:9090/'
    ports:
      - 9090:9090
      - alertmanager:alertmanager

  alertmanager:
    image: prom/alertmanager
    restart: always
    ports:
      - 9093:9093
    volumes:
      - ./alertmanager/:/etc/alertmanager/
    command:
      - '--config.file=/etc/alertmanager/config.yml'
      - '--storage.path=/alertmanager'

  grafana:
    image: grafana/grafana
    user: '472'
    restart: always
    environment:
      GF_INSTALL_PLUGINS: 'grafana-clock-panel,grafana-simple-json-datasource'
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning/:/etc/grafana/provisioning/
    env_file:
      - ./grafana/config.monitoring
    ports:
      - 3000:3000
    depends_on:
      - prometheus

  loki:
    image: grafana/loki:latest
    ports:
      - "3100:3100"
    command: -config.file=/etc/loki/local-config.yaml

  victoriametrics:
    container_name: victoriametrics
    image: victoriametrics/victoria-metrics:v1.91.2
    ports:
      - 8428:8428
    volumes:
      - vmdata:/storage
    command:
      - "--storageDataPath=/storage"
      - "--httpListenAddr=:8428"
#      - "--vmalert.proxyURL=http://vmalert:8880"

  vmagent:
    container_name: vmagent
    image: victoriametrics/vmagent:v1.91.2
    depends_on:
      - "victoriametrics"
    ports:
      - 8429:8429
    volumes:
      - vmagentdata:/vmagentdata
      - ./prometheus:/etc/prometheus/
    command:
      - "--promscrape.config=/etc/prometheus/prometheus.yml"
      - "--remoteWrite.url=http://victoriametrics:8428/api/v1/write"
...

Для victoriametrics поки що закоментуємо --vmalert.proxyURL, додамо його згодом.

До vmagent підключаємо каталог ./prometheus – в ньому маємо файл prometheus.yaml з конфігурацією srape_jobs, та файли параметрів експортерів (наприклад – ./prometheus/blackbox.yml та /prometheus/blackbox-targets/targets.yaml для Blackbox Exporter).

У --remoteWrite.url вказуємо, куди будемо писати отримані метрики – до інстансу VictoriaMetrics.

Запускаємо:

[simterm]

# docker compose up

[/simterm]

Якщо перейти без URI, тобто просто на domain.com/ – то видасть всі доступні шляхи, дуже прям зручно:

field evaluation_interval not found in type promscrape.GlobalConfig

Але vmagent не запустився:

[simterm]

2023-06-05T09:38:31.376Z        fatal   VictoriaMetrics/lib/promscrape/scraper.go:117   cannot read "/etc/prometheus/prometheus.yml": cannot parse Prometheus config from "/etc/prometheus/prometheus.yml": cannot unmarshal data: yaml: unmarshal errors:
  line 4: field evaluation_interval not found in type promscrape.GlobalConfig
  line 13: field rule_files not found in type promscrape.Config
  line 19: field alerting not found in type promscrape.Config; pass -promscrape.config.strictParse=false command-line flag for ignoring unknown fields in yaml config

[/simterm]

Окей, відключимо strictParse – додаємо --promscrape.config.strictParse=false:

...
    command:
      - "--promscrape.config=/etc/prometheus/prometheus.yml"
      - "--remoteWrite.url=http://victoriametrics:8428/api/v1/write"
      - "--promscrape.config.strictParse=false"

Перезапускаємо сервіси, та заглянемо на порт 8429, vmagent – теж є лінки :

Перевіряємо таргети – вони є, тобто vmagent зчитав файл prometheus.yaml, але не всі працюють, наприклад – Sentry експортер є, YACE є, а от blackbox, node_exporter та cAdvisor не бачить:

А чому?

Ага… Не бачить тих, у кого sd_configs, тобто динамічний сервіс-діскавері:

...  - job_name: 'cadvisor'

    # Override the global default and scrape targets from this job every 5 seconds.
    scrape_interval: 5s

    dns_sd_configs:
    - names:
      - 'tasks.cadvisor'
      type: 'A'
      port: 8080
...

Хоча наче має вміти – Supported service discovery configs.

Глянемо логи vmagent.

error in A lookup for “tasks.cadvisor”: lookup tasks.cadvisor on 127.0.0.11:53: no such host

А логи кажуть, що контейнер з vmagent не може отримати A-запис з DNS:

[simterm]

...
vmagent                                 | 2023-06-05T10:04:10.818Z      error   VictoriaMetrics/lib/promscrape/discovery/dns/dns.go:163 error in A lookup for "tasks.cadvisor": lookup tasks.cadvisor on 127.0.0.11:53: no such host
vmagent                                 | 2023-06-05T10:04:10.821Z      error   VictoriaMetrics/lib/promscrape/discovery/dns/dns.go:163 error in A lookup for "tasks.node-exporter": lookup tasks.node-exporter on 127.0.0.11:53: no such host
...

[/simterm]

Читаємо документацію по dns_sd_configs, де говориться про “# names must contain a list of DNS names to query“, але в мене зараз job описана з names = tasks.container_name, див. Container discovery.

Спробуємо вказати просто ім’я, тобто cadvisor замість tasks.cadvisor:

...
  - job_name: 'cadvisor'
    dns_sd_configs: 
    - names:
#      - 'tasks.cadvisor'
      - 'cadvisor'
      type: 'A'
      port: 8080
...

А job_name: 'prometheus' просто вимикаємо – вона нам не потрібна.

І тепер всі таргети з’явились:

VictoriaMetrics та Grafana

Тепер давайте спробуємо використати VictoriaMetrics як data source у Grafana.

В принципі, тут все робиться однаково з Prometheus, використовуючи той же тип data source.

Додаємо новий data source з типом Prometheus, в URL вказуємо http://victoriametrics:8428:

Обновлюємо графік – вибираємо щойно доданий data source:

 

І тепер можемо використовувати функцію sort_by_label_numeric, якої не вистачало у пості Prometheus: GitHub Exporter – пишемо власний експортер для GitHub API.

З Prometheus ця панель виглядає так:

А з VictoriaMetrics та sort_by_label_numeric – так:

Добре, наче все працює.

Можемо пробувати роботу з алертами.

VictoriaMetrics та Alertmanager

Отже, зара маємо запущений Alertmanager та Prometheus.

У prometheus.yaml маємо вказаний файл з алертами:

...
rule_files:
  - 'alert.rules'
...

Що нам треба – це запустити vmalert, якому вкажемо “бекенд” у вигляді Alertmanager, якому він буде слати алерти, та сам файл з алертами у форматі Prometheus.

Як і сама VictoriaMetrics, vmalert має дещо ширші можливості, ніж Prometheus, наприклад – зберігає статус алертів, тож рестарт контейнеру не сбиває silenced алерти. Ще є зручна змінна $for для шаблонів, в якій передається значення for з алерту, і можемо мати щось таке:

...
    for: 5m
    annotations:
      description: |-
        {{ if $value }} *Current latency*: `{{ $value | humanize }}` milliseconds {{ end }} during `{{ $for }}` minutes
...

Також є підримка httpAuth, є можливість виконати запит алерту з query та багато іншого, див. Template functions.

Додаємо vmalert в docker-compose.yaml:

...
  vmalert: 
    container_name: vmalert
    image: victoriametrics/vmalert:v1.91.2
    depends_on:
      - "victoriametrics"
      - "alertmanager"
    ports:
      - 8880:8880
    volumes:
      - ./prometheus/alert.rules:/etc/alerts/alerts.yml
    command:
      - "--datasource.url=http://victoriametrics:8428/"
      - "--remoteRead.url=http://victoriametrics:8428/"
      - "--remoteWrite.url=http://victoriametrics:8428/"
      - "--notifier.url=http://alertmanager:9093/"
      - "--rule=/etc/alerts/*.yml"

Тут у datasource.url вказуємо, звідки брати метрики для перевірки у алертах, remoteRead.url та remoteWrite.url – де зберігати стан алертів.

У notifier.url – куди будемо слати алерти (а вже Alertmanager через свій конфіг відправить їх у Slack/Opsgenie/etc). І у rule вказуємо сам файл з алертами, який підключаємо у volumes.

Перезапускаємо контейнери з docker compose restart, и заходимо на порт 8880:

Окей, є алерт-рули.

Спробуємо тригернути тестовий алерт – і маємо новий алерт у vmalert Alerts:

Та повідомлення в Slack від Alertmanager:

Все працює.

Тепер можна відключати контейнер з Prometheus, тільки оновити depends_on у Grafana – замість prometheus вказати victoriametrics, і замінити data sources у дашбордах.

Bonus: Alertmanager Slack template

І приклад шаблону для нотіфікацій в Slack. Він ще буде перероблюватись, поки що вся система більше в стані proof of concept, але в цілому буде якось так.

Файл alertmanager/notifications.tmpl з шаблоном:

{{/* Title of the Slack alert */}}
{{ define "slack.title" -}}
  {{ if eq .Status "firing" }} :scream: {{- else -}} :relaxed: {{- end -}}
  [{{ .Status | toUpper -}} {{- if eq .Status "firing" -}}:{{ .Alerts.Firing | len }} {{- end }}] {{ (index .Alerts 0).Annotations.summary }}
{{ end }}    

{{ define "slack.text" -}}

    {{ range .Alerts }}
        {{- if .Annotations.description -}}
        *Description*: {{ .Annotations.description }}
        {{- end }}
    {{- end }}

{{- end }}

Його використання в alertmanager/config.yml:

receivers:

- name: 'slack-default'
 
  slack_configs:
    - title: '{{ template "slack.title" . }}'
      text: '{{ template "slack.text" . }}'
      send_resolved: true
      actions:
        - type: button
          text: 'Grafana :grafana:'
          url: '{{ (index .Alerts 0).Annotations.grafana_url }}'
        - type: button
          text: 'Prometheus query :mag:'
          url: '{{ (index .Alerts 0).GeneratorURL }}'
        - type: button
          text: 'AWS dashboard :aws:'
          url: '{{ (index .Alerts 0).Annotations.aws_dashboard_url }}'

Темплейт для алерту – підключається в контейнер vmalerts, див. Reusable templates:

{{ define "grafana.filter" -}}
  {{- $labels := .arg0 -}}
  {{- range $name, $label := . -}}
    {{- if (ne $name "arg0") -}}
      {{- ( or (index $labels $label) "All" ) | printf "&var-%s=%s" $label -}}
    {{- end -}}
  {{- end -}}
{{- end -}}

І сам алерт:

- record: aws:apigateway_integration_latency_average_sum
  expr: sum(aws_apigateway_integration_latency_average) by (dimension_ApiName, tag_environment)

- alert: APIGatewayLatencyBackendProdTEST2
  expr: aws:apigateway_integration_latency_average_sum{tag_environment="prod"} > 100
  for: 1s
  labels:
    severity: info
    component: backend
    environment: test
  annotations:
    summary: "API Gateway latency too high"
    description: |-
      The time between when API Gateway relays a request to the backend and when it receives a response from the backend
      *Environment*: `{{ $labels.tag_environment }}`
      *API Gateway name*: `{{ $labels.dimension_ApiName }}`
      {{ if $value }} *Current latency*: `{{ $value | humanize }}` milliseconds {{ end }}
    grafana_url: '{{ $externalURL }}/d/overview/overview?orgId=1{{ template "grafana.filter" (args .Labels "environment" "component") }}'

А $externalURL отримується vmalerts з параметру --external.url=http://100.***.***.197:3000".

Корисні посилання

Loading

Prometheus: GitHub Exporter – пишемо власний експортер для GitHub API
0 (0)

1 Червня 2023

Прийшла досить цікава задачка – побудувати в Grafana дашборду, в якій би відображався статус процессу розробки, а саме – перформанс, тобто ефективність наших DevOps-процесів.

Потрібно це тому, что ми намагаємось побудувати “true continuous deployment”, щоб код автоматично потрапляв у Production, і нам важливо бачити як саме проходить процес розробки.

Загалом для оцінки ефективності процессу розробки ми придумали 5 метрик:

  • Deployment Frequency: як часто виконуються деплої
  • Lead Time for Changes: скільки часу займає доставка фічі до Production, тобто час між її першим коммітом в репозиторій до моменту, коли вона потрапляє в Production
  • PR Lead Time: час, котрий фіча “вісить” у статусі Pull Request
  • Change Failure Rate: процент деплоїв, які викликали проблеми у Production
  • Time to Restore Service: час на відновлення системи у випадку її краху

Див. MKPIS – Measuring the development process for Gitflow managed projects та The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling.

Почати вирішили з метрики для PR Lead Time – будемо міряти час від створення Pull Request до його мержу в master-гілку, і виводити його на Grafana-дашборді.

Що зробимо: напишемо власний GitHub Exporter, який буде ходити до GitHub API, збирати дані, та створювати Prometheus-метрику, яку потім використаємо у Grafana. Див. Prometheus: створення Custom Prometheus Exporter на Python.

Тобто у нас будуть:

  • Grafana/Prometheus стек
  • Python
  • бібліотека PyGithub для роботи з GitHub API
  • prometheus-client для створення власних метрик

GitHub API та PyGithub

Почнемо з GitHub API. Документація – Getting started with the REST API.

GitHub token та аутентифікація

Нам знадобиться token – див. Authenticating to the REST API та Creating a personal access token.

Перевіряємо його:

[simterm]

$ curl -X GET -H "Authorization: token ghp_ys9***ilr" 'https://api.github.com/user'
{
  "login": "arseny***",
  "id": 132904972,
  "node_id": "U_kgDOB-v4DA",
  "avatar_url": "https://avatars.githubusercontent.com/u/132904972?v=4",
  "gravatar_id": "",
  "url": "https://api.github.com/users/arseny***",
...

[/simterm]

Окей, відповідь є, значить токен працює.

Бібліотека PyGithub

Встановлюємо PyGithub:

[simterm]

$ pip install PyGithub

[/simterm]

Тепер спробуємо сходити до GitHub API у коді на Python:

#!/usr/bin/env python

from github import Github

access_token = "ghp_ys9***ilr"

# connect to Gihub
github_instance = Github(access_token)
organization_name = 'OrgName'
# read org
organization = github_instance.get_organization(organization_name)
# get repos list     
repositories = organization.get_repos()

for repository in repositories:
    print(f"Repository: {repository.full_name.split('/')[1]}")

Тут створюємо github_instance, аутентифікуємось з нашим токеном, отримуємо інформацію про GitHub Organization, та всі репозиторії цієї організації.

Запускаємо:

[simterm]

$ ./test-api.py 
Repository: chatbot-automation
Repository: ***-sandbox
Repository: ***-ios
...

[/simterm]

Окей, працює.

Отримання інформації про Pull Request

Далі, спробуємо отримати інформацю про пул-реквест, а саме – час його створення та закриття.

Тут, щоб спростити та пришвидшити розробку експортеру і його тестування, будемо використовувати тільки один репозиторій і будемо вибирати закриті пул-реквести тільки за останній тиждень, а потім вже повернемо цикл, в якому будемо перебирати всі репозиторії та пул-реквести в них:

...

# get infro about a repository
repository = github_instance.get_repo("OrgName/repo-name")
# get all PRs in a given repository
pull_requests = repository.get_pulls(state='closed')

# to get PRs closed during last N days
days_ago = datetime.now() - timedelta(days=7)

for pull_request in pull_requests:
    merged_at = pull_request.closed_at
    created_at = pull_request.merged_at

    if created_at >= days_ago and created_at and merged_at:
        print(f"Pull Request: {pull_request.number} Created at: {pull_request.created_at} Merged at: {pull_request.merged_at}")

Тут у циклі для кожного PR отримуємо його атрибути merged_at та created_at, див. List pull requests – у Response schema є список всіх атрибутів, які ми можемо побачити для кожного PR.

У days_ago = datetime.now() - timedelta(days=7) отримуємо день 7 днів тому, щоб вибрати пул-реквести, створені після цієї дати, а потім для перевірки виводимо на екран інформацію про дату створення PR та дату, коли його змержили в master.

Перевіряємо:

[simterm]

$ ./test-api.py 
Pull Request: 1055 Created at: 2023-05-31 18:34:18 Merged at: 2023-06-01 08:14:49
Pull Request: 1049 Created at: 2023-05-31 10:22:16 Merged at: 2023-05-31 18:03:09
Pull Request: 1048 Created at: 2023-05-30 15:16:13 Merged at: 2023-05-31 14:17:57
...

[/simterm]

Гуд! Працює.

Тепер можемо починати думати про метрику для Prometheus.

Prometheus Client та метрики

Встановлюємо бібліотеку:

[simterm]

$ pip install prometheus_client

[/simterm]

Щоб мати більше уяви про те, що саме ми хочимо побудувати – можна почитати How to Read Lead Time Distribution, де є приклад такого графіку:

Тобто в нашому випадку будуть:

  • x-axis (горизонталь): час (години на закриття PR)
  • y-axis (вертикаль): кількість PR закриті за Х-годин

Тут я досить багато часу витратив, намагюсь зробити це з використанням різних типів метрик для Prometheus, і спочатку пробував Histogram, бо наче ж виглядає логічно – в бакети гістрограми вносити значення, по типу такого:

buckets = [1, 2, 5, 10, 20, 100, 1000]
gh_repo_lead_time = Histogram('gh_repo_lead_time', 'Time in hours between PR open and merge', buckets=buckets, labelnames=['gh_repo_name'])

Проте, з Histogram не вийшло, бо в бакет 1000 потрапляють всі значення меньше 1000, в бакет 100 – всі менше ста, і так далі, а нам потрібно в бакет 100 включати тільки дані про пул-реквести, які були закриті між 50 годин та 100 годин.

Але врешті-решт все вийшло з використанням типу Counter та лейбл repo_name та time_interval.

Див. A Deep Dive Into the Four Types of Prometheus Metrics.

Створення метрики

Спочатку створимо Python dictionary з “бакетами” – це години, на протязі яких були закриті пул-реквести:

time_intervals = [1, 2, 5, 10, 20, 50, 100, 1000]

Далі будемо отримувати кількість годин на закриття у кожному PR, перевіряти в який саме “бакет” цей PR попадає, і потім заносити дані у метрику – додавати лейблу time_interval зі значенням з бакету, в який це PR попав, та інкрементити значення каунтеру.

Створємо саму метрику pull_request_duration_count та функцію calculate_pull_request_duration(), в яку будемо передавати пул-реквест для перевірки:

...
# buckets for PRs closed during {interval}
time_intervals = [1, 2, 5, 10, 20, 50, 100, 1000]  # 1 hour, 2 hours, 5 hours
# prometheus metric to count PRs in each {interval}
pull_request_duration_count = Counter('pull_request_duration_count',
                                      'Count of Pull Requests within a time interval',
                                      labelnames=['repo_name', 'time_interval'])

def calculate_pull_request_duration(repository, pr):
    created_at = pr.created_at
    merged_at = pr.merged_at

    if created_at >= days_ago and created_at and merged_at:
        duration = (merged_at - created_at).total_seconds() / 3600

        # Increment the histogram for each time interval
        for interval in time_intervals:
            if duration <= interval:
                print(f"PR ID: {pr.number} Duration: {duration} Interval: {interval}")
                pull_request_duration_count.labels(time_interval=interval, repo_name=repository).inc()
                break
...

Тут у calculate_pull_request_duration():

  • отримуємо час створення та мержу пул-реквеста
  • перевіряємо, що PR молодший за $days_ago і має атрібути created_at та merged_at, тобто він вже змержений
  • рахуємо, скільки часу він провів до моменту його мержу в мастер-гілку, та переводимо в години – duration = (merged_at - created_at).total_seconds() / 3600
  • у циклі проходимось по “бакетах” з нашого time_intervals dictionary – шукаємо, в який з них попадає цей PR
  • і в кінці створюємо метрику pull_request_duration_count, в labels якої вносимо ім’я репозиторію та “бакет”, в який попав цей пул-реквест, і інкриментимо значення каунтера на +1:
    pull_request_duration_count.labels(time_interval=interval, repo_name=repository).inc()

Далі, описуємо функцію main() та ї виклик:

...

def main():
    # connect to Gihub
    github_instance = Github(github_token)
    organization_name = 'OrgName'
    # read org
    organization = github_instance.get_organization(organization_name)
    # get repos list 
    repositories = organization.get_repos()

    for repository in repositories:
        # to set in labels
        repository_name = repository.full_name.split('/')[1]
        pull_requests = repository.get_pulls(state='closed')

        if pull_requests.totalCount > 0:
            print(f"Checking repository: {repository_name}")
            for pr in pull_requests:
                calculate_pull_request_duration(repository_name, pr)
        else:
            print(f"Sckipping repository: {repository_name}")

    # Start Prometheus HTTP server
    start_http_server(8000)
    print("HTTP server started")
    while True:
        time.sleep(15)
        pass

if __name__ == '__main__':
    main()

Тут ми:

  • створємо об’єкт Github
  • отримуємо список репозиторіїв організацї
  • для кожного репозиторія викликаємо get_pulls(state='closed')
  • перевіряємо, що в репозиторії були пул-реквести, і по черзі відправляємо їх до функції calculate_pull_request_duration()
  • запускаємо HTTP-сервер на порту 8000, де будемо отримувати метрики

Повний код Prometheus-експортеру

Все разом тепер виходить так:

#!/usr/bin/env python

from datetime import datetime, timedelta
import time
from prometheus_client import start_http_server, Counter
from github import Github

# TODO: move to env vars
github_token = "ghp_ys9***ilr"

# to get PRs closed during last N days
days_ago = datetime.now() - timedelta(days=7)
# buckets for PRs closed during {interval}
time_intervals = [1, 2, 5, 10, 20, 50, 100, 1000]  # 1 hour, 2 hours, 5 hours
# prometheus metric to count PRs in each {interval}
pull_request_duration_count = Counter('pull_request_duration_count',
                                      'Count of Pull Requests within a time interval',
                                      labelnames=['repo_name', 'time_interval'])

def calculate_pull_request_duration(repository, pr):
    created_at = pr.created_at
    merged_at = pr.merged_at

    if created_at >= days_ago and created_at and merged_at:
        duration = (merged_at - created_at).total_seconds() / 3600

        # Increment the Counter for each time interval
        for interval in time_intervals:
            if duration <= interval:
                print(f"PR ID: {pr.number} Duration: {duration} Interval: {interval}")
                pull_request_duration_count.labels(time_interval=interval, repo_name=repository).inc()
                break

def main():
    # connect to Gihub
    github_instance = Github(github_token)
    organization_name = 'OrgNameg'
    # read org
    organization = github_instance.get_organization(organization_name)
    # get repos list 
    repositories = organization.get_repos()

    for repository in repositories:
        # to set in labels
        repository_name = repository.full_name.split('/')[1]
        pull_requests = repository.get_pulls(state='closed')

        if pull_requests.totalCount > 0:
            print(f"Checking repository: {repository_name}")
            for pr in pull_requests:
                calculate_pull_request_duration(repository_name, pr)
        else:
            print(f"Skipping repository: {repository_name}")

    # Start Prometheus HTTP server
    start_http_server(8000)
    print("HTTP server started")
    while True:
        time.sleep(15)
        pass

if __name__ == '__main__':
    main()

Запускаємо скрипт:

[simterm]

$ ./github-exporter.py
...
Skipping repository: ***-sandbox
Checking repository: ***-ios
PR ID: 1332 Duration: 5.4775 Interval: 10
PR ID: 1331 Duration: 0.32916666666666666 Interval: 1
PR ID: 1330 Duration: 20.796944444444446 Interval: 50
...

[/simterm]

Чекаємо, поки будуть перевірені всі репозиторії і запуститься http_server(), та перевіряємо метрики з curl:

[simterm]

$ curl localhost:8000
...
# HELP pull_request_duration_count_total Count of Pull Requests within a time interval
# TYPE pull_request_duration_count_total counter
pull_request_duration_count_total{repo_name="***-ios",time_interval="10"} 1.0
pull_request_duration_count_total{repo_name="***-ios",time_interval="1"} 1.0
pull_request_duration_count_total{repo_name="***-ios",time_interval="50"} 2.0
pull_request_duration_count_total{repo_name="***-ios",time_interval="100"} 1.0
pull_request_duration_count_total{repo_name="***-ios",time_interval="20"} 1.0
pull_request_duration_count_total{repo_name="***-ios",time_interval="1000"} 1.0
...

[/simterm]

Гуд! Працює.

GitHub API rate limits

Майте на увазі, що GitHub обмежує кількість запитів до API – 5,000 на годину зі звичайним юзерським токеном, та 15.000, якщо у вас Enterprise ліцензія. Див. Rate limits for requests from personal accounts.

Якщо його перевищити – отримаєте 403:

[simterm]

...
  File "/usr/local/lib/python3.11/site-packages/github/Requester.py", line 423, in __check
    raise self.__createException(status, responseHeaders, output)
github.GithubException.RateLimitExceededException: 403 {"message": "API rate limit exceeded for user ID 132904972.", "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}

[/simterm]

Prometheus Server та отримання метрик

Залишилось почати збирати метрики у Prometheus, та створити Grafana dashboard.

Запуск Prometheus Exporter

Створюємо Dockerfile:

FROM python:latest

COPY github-exporter.py ./
RUN pip install prometheus_client PyGithub

CMD [ "python", "./github-exporter.py"]

Збираємо образ:

[simterm]

$ docker build -t gh-exporter .

[/simterm]

У нас Prometheus/Grafana поки що в простому Docker Compose – додаємо запуск нашого нового експортеру:

...
  gh-exporter:
    scrape_timeout: 15s
    image: gh-exporter
    ports:
      - 8000:8000
...

(токен таки краще передавати через змінну оточення з docker-compose файлу, а не хардкодити в коді)

І у файлу конфігурації самого Prometheus – описуємо нову scrape_job:

scrape_configs:
...
  - job_name: gh_exporter
    scrape_interval: 5s
    static_configs:
      - targets: ['gh-exporter:8000']
...

Запускаємо, і за хвилину перевіряємо метрики в Prometheus:

Найс!

Grafana dashboard

Останнім робимо саму борду.

Додамо змінну, щоб мати змогу відобразити дані по конкретному репозіторію/ях:

Для візуалізації я використав тип Bar gauge і такий query:

sum(pull_request_duration_count_total{repo_name=~"$repository"}) by (time_interval)

У Overrides задаємо колір для кожної колонки.

Єдине, що тут не дуже – це сортування колонок: сам Prometheus це не вміє і не хоче (див. Added sort_by_label function for sorting by label values), а Grafana сортує по першим цифрам у отриманих  з label значеннях, тобто 1, 2, 5, не враховуючи кількість 0 після цифри.

Але то вже деталі – може, таки візьмемо Victoria Metrics з її sort_by_label, або в Grafana просто створимо кілька графіків, і в кожному будемо виводити дані по конкретному “бакету” та кількості пул-реквестів в ньому.

Loading

Loki: збір логів з CloudWatch Logs з використанням Lambda Promtail
0 (0)

20 Травня 2023

Збирати логи у Grafana Loki з Kubernetes дуже просто – запускаємо Promtail у DaemonSet, йому вказуємо читати всі дані з /var/logs – і готово (насправді взагалі нічого не вказуємо – з Helm-чарту все працює з коробки).

А от як бути з CloudWatch Logs? На новому проекті маємо купу AWS Lambda, API Gateways і т.д, і всі вони пишуть логи у CloudWatch.

Що стосується Lambda, то можна було б використати Lambda Telemetry API, і писати логи з функції відразу в Loki, див. Building an AWS Lambda Telemetry API extension for direct logging to Grafana Loki, і можливо пізніше ми цей підхід також використаємо, але зараз у нас вже є купа логів від інших сервісів у CloudWatch, і треба таки їх читати.

Ще є варіант встановити CloudWatch як data source у Grafana, і просто користуватись логами з інтерфейсу Grafana та мабуть навіть мати алерти Grafana з цих логів, але рано чи пізно все одно з’явиться Kubernetes або просто ЕС2 інстанси, і треба буде збирати з них логи, тож будемо відразу робити все з Loki, тим більш в неї чудовий LogQL і набагато більше гнучкості у створенні лейбл та алертів.

В такому випадку можемо використати Lambda Promtail від самої Grafana, а працювати воно буде наступним чином:

  • якась Lambda-функція (наприклад) пише лог у CloudWatch Log Group
  • у Log Group будемо мати Subscription filter, який буде слати логи на іншу Lambda-функцію – власне у Lambda Promtail
  • а Lambda Promtail буде пересилати їх до інстансу Loki

Отже, сьогодні створимо тестову Lambda-функцію, яка буде писати логи, і запустимо Lambda Promtail, яка буде слати логи в Grafana Loki, яка вже є.

На що треба звернути увагу, так це на кількість даних, які будуть писатись, бо як завжди з AWS – попасти на гроші досить легко, тому добре мати налаштований AWS Budgets, щоб отримати алерт в разі неочікуваних витрат.

Також треба мати на увазі, що до Loki потрібно буде відкривати доступ на порт 3100, тож Lambda Promtail краще мати в тій самій VPC, де запущена сама Grafana та/або мати якийсь NGINX з HTTP-аутентифікацією.

Тестова Lambda для створення логів

Створюємо функцію, нехай буде на Python:

У коді функції додамо кілька print(), щоб створити запис в лог:

import json
import os

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }
    print('## ENVIRONMENT VARIABLES')
    print(os.environ['AWS_LAMBDA_LOG_GROUP_NAME'])
    print(os.environ['AWS_LAMBDA_LOG_STREAM_NAME'])
    print('## EVENT')
    print(event)

Тиснемо Test, щоб створити тестовий евент, дані в полі Event JSON нам не важливі, просто вказуємо ім’я евенту, та зберігаємо його:

Тиснемо Test ще раз – функція виконалась, Function Logs пішли:

Переходимо у Monitor > Logs, а звідти у CloudWatch Logs:

І перевіряємо, що Log events є:

Все – тепер можемо переходити до Lambda Promtail.

Запуск Lambda Promtail

Взагалі є готовий Terraform проект і навіть Cloudformation темплейт, тож можна скористатись ними. Єдине, що у Terrafrom треба пофіксити створення resource "aws_iam_role_policy_attachment" "lambda_sqs_execution" у файлі sqs.tf, бо там йде виклик ролі role = aws_iam_role.iam_for_lambda.name, а у main.tf вона називається resource "aws_iam_role" "this".

В усьому іншому Terraform працює – задаємо значення для змінних у variabels.tf – write_address, log_group_names та lambda_promtail_image, і можна створювати ресурси.

Проте я все ж вважаю за краще на перший раз створити все руками, щоб краще розуміти що і як буде працювати.

Docker образ та Elastic Container Service

Спочатку підготуємо Docker-образ, бо запустити AWS Lambda з публічного ECR Grafana чомусь неможливо, хоча ніде в документації такого обмеження не знайшов.

Переходимо до ECR, створюємо репозиторій:

Завантажуємо публічний образ від Grafana:

[simterm]

$ docker pull public.ecr.aws/grafana/lambda-promtail:main

[/simterm]

Перетегаємо його на свій репозиторій:

[simterm]

$ docker tag public.ecr.aws/grafana/lambda-promtail:main 264***286.dkr.ecr.eu-central-1.amazonaws.com/lambda-promtail-writer:latest

[/simterm]

Логінимось до ECR – вказуємо --profile, якщо не дефолтний, та AWS Region:

[simterm]

$ aws --profile setevoy ecr get-login-password --region eu-central-1 | docker login --username AWS --password-stdin 264***286.dkr.ecr.eu-central-1.amazonaws.com
...
Login Succeeded

[/simterm]

Пушимо туди наш образ:

[simterm]

$ docker push 264***286.dkr.ecr.eu-central-1.amazonaws.com/lambda-promtail-writer:latest

[/simterm]

Переходимо до Lambda.

Створення Lambda Promtail function

Створюємо нову функцію, вибираємо Container image, та вказуємо URI імейджу, який запушили вище:

Переходимо до Configuration > Environment variables, і задаємо мінімально необхідні змінні:

  • EXTRA_LABELS: теги/лейбли, які будуть додані у Loki, тут вказуємо у форматі labelname,labelvalue
  • WRITE_ADDRESS: адреса Loki з https:// та  URI /loki/api/v1/push

Конфігурація CloudWatch Log Group Subscription filters

Повертаємось до CloudWatch Log Group, в якій були наші тестові логи, і у Subscription filters додаємо нову підписку для Lambda-функції (див. Using CloudWatch Logs subscription filters або How can I configure a CloudWatch subscription filter to invoke my Lambda function?):

Вибираємо функцію, в яку будемо стрімити логи, та при потребі у Configure log format and filters можемо вказати фільтр, через який буде вибиратись що саме пересилати у Lambda, щоб не слати зовсім всі строки.

Зараз нам це не потрібно, тож у Log format ставимо Other, а Subscription filter pattern лишаємо пустим.

У Subscription filter name вказуємо ім’я самого фільтру:

Зберігаємо – Start streaming, повертаємось до Lambda write-logs, і кілька раз тиснемо Test, щоб створити ще записів у CloudWatch Log Group, які мають стригерити функцію lambda-promtail-testing і передати їй дані, які вона відправить у Loki.

Перевіряємо у функції lambda-promtail-testing – у Monitoring мають бути виклики:

У випадку Errors – на вкладці Logs є посилання на CloudWatch Log цієї функції, де буде описана помилка.

Якщо ж все Success – то в Loki вже маємо побачити нову лейблу, і по ній можемо вибрати логи з функції write-logs:

Готово.

На сторінці документації Grafana ще пишуть, що “Or, have lambda-promtail write to Promtail and use pipeline stages.“, але я так і не знайшов можливості в Promtail писати дані по gRPC або HTTP, хоча така ідея була ще у 2020 році, але вона досі в Draft – Promtail Push API. 

Loading

Terraform: початок роботи та планування нового проекту – Dev/Prod та bootsrap
0 (0)

14 Травня 2023

Треба запланувати використання Terraform у новому проекті, а це включає в себе і планування структри файлів для проекті, і як створити бекенд (тобто bootstrap) і інші потрібні для початку роботи ресурси, і подумати на тему роботи з кількома оточеннями і AWS-аккаунтами.

Взагалі, цей пост спочатку писався чисто про створення AWS SES, але я почав додавати багато деталей по тому, як жеж саме створити та планувати новий проект з Terraform, тож вирішив винести окремим постом. Про SES пізніше теж допишу, бо там досить цікаво саме по самому SES та пошті в цілому.

Наприкінці цього поста, як завжди, буде багато цікавих посилань, але особливо хочу відмітити Terraform Best Practices від Anton Babenko.

Планування Terraform для нового проекту

Про що треба буде подумати?

  • структура файлів проектів
  • бекенд – AWS S3, як робити корзину для першого запуску?
  • гарно б DynamoDB для State Locking, але то іншим разом
  • dev/prod оточення та aws multi account – як робитимо?

Структура файлів Terraform

У проекті для AWS SES спочатку зробив все у одному файлі, але давайте зробимо “як треба”, див. наприклад How to Structure Your Terraform Projects (там ще багато чього).

Отже, як організуємо:

  • main.tf – виклики модулів
  • terraform.tf – параметри backend-у, провайдери, версії
  • providers.tf – тут сам провайдер AWS, аутентифікаця, регіон
  • variables.tf – тут декларуємо змінні
  • terraform.tfvars – значення для змінних

У проекті SES ще будуть окремі файли ses.tf та route53.tf для всього, що пов’язано з ними.

Multiple environments з Terraform

Окей, а що маємо по роботі з декількома оточеннями типу Dev/Prod, або взагалі різними AWS-аккаунтами?

Можемо зробити через Terraform Workspaces, але щось я не пам’ятаю, щоб багато чув про них в плані використання для Dev/Prod та ще й з CI/CD пайплайнами. Хоча – як варіант, і може має сенс якось спробувати. Див. How to manage multiple environments with Terraform using workspaces).

Взагалі-то не знайшов якось “золотої кулі”, і варіантів прям купа. Хтось використовує git-бранчі або Terragrunt (How to manage multiple environments with Terraform), хтось – різні директорії (How to Create Terraform Multiple Environments), хтось – рішення типу Spacelift.

Dev та Production по каталогах

Як на мене, для невеликого проекту найбільш привабливим виглядає варіант з використанням декільких калалогів для оточень і Terraform modules для ресурсів.

Спробуємо, щоб побачити, як воно все виглядатиме та працюватиме.

У каталозі проекту створимо структуру директорій:

[simterm]

$ mkdir -p environments/{dev,prod}
$ mkdir -p modules/vpc

[/simterm]

В результаті маємо таке:

[simterm]

$ tree
.
|-- environments
|   |-- dev
|   `-- prod
`-- modules
    `-- vpc

[/simterm]

Тут у нас environments/dev/ та prod/ будуть незалежними проектами з власними параметрами та будуть використовувати загальні модулі з каталогу modules. Таким чином процес розробки чогось нового для інфрастуктури можна спочатку протестити у окремому файлі в каталозі environments/dev, потім перенести його до modules, додати до dev вже у вигляді модулю, і після повторного тестування там – додати до production.

Крім того, так як будемо мати власні файли параметрів для AWS, то зможемо використовувати окремі AWS-аккаунти.

Поки що руками створимо корзину для стейтів – дійдемо до цього пізніше, як будемо говорити про Bootstrap:

[simterm]

$ aws s3 mb s3://tfvars-envs
make_bucket: tfvars-envs

[/simterm]

Створення shared-модулю

Переходимо до каталога modules/vpc/ і у файлі main.tf описуємо VPC (втім, якщо вже дотримуватися best practicies, то краще використовувати модуль VPC, також від Anton Babenko):

resource "aws_vpc" "env_vpc" {
  cidr_block      = var.vpc_cidr

  tags = {
    environment = var.environment
  }
}

В тому ж каталозі створюємо файл variables.tf зі змінними, але без значень – тільки декларуємо їх:

variable "vpc_cidr" {
  type = string   
}

variable "environment" {
  type = string
}

Створення Dev/Prod оточень

Переходимо до environments/dev і готуємо файли. Почнемо з параметрів – terraform.tf та provider.tf.

У terraform.tf описуємо потрібні провайдери, версії та бекенд.

У бекенді у key вказуємо шлях до стейт-файлу в директорії dev/ – її буде створено при деплої. А для Prod – вкажемо prod/ (хоча можна взагалі різні корзини):

terraform {
  required_providers {
    aws = { 
      source  = "hashicorp/aws"
      version = ">= 4.6.0"
    }
  }

  required_version = ">= 1.4"

  backend "s3" {
    bucket = "tfvars-envs"
    region = "eu-central-1"
    key    = "dev/terraform.tfstate"
  }   
}

У provider.tf параметри провайдера AWS – регіон та AWS profile з ~/.aws/config, який буде використовуватись:

provider "aws" {
  region    = var.region
  profile   = "default"
}

Хоча можна зараз було б об’єднати їх у terraform.tf, але на майбутнє – нехай буде так.

Створюємо main.tf, в якому використовуємо наш модуль з каталогу modules, якому передаємо змінні:

module "vpc" {
  source = "../../modules/vpc"

  vpc_cidr        = var.vpc_cidr
  environment     = var.environment
}

Додаємо файл variables.tf, в якому також тільки декларуємо змінні, тут нова змінна region для terraform.tf та providers.tf:

variable "vpc_cidr" {
  type = string 
}
    
variable "environment" {
  type = string
}

variable "region" {
  type = string
}

І нарешті самі значення змінних описуємо у файлі terraform.tfvars:

vpc_cidr      = "10.0.0.0/24"
environment   = "dev"
region        = "eu-central-1"

Аналогічно робимо для environments/prod/, тільки з каталогом prod/ у бекенді та іншими значеннями у terraform.tfvars:

vpc_cidr      = "10.0.1.0/24"
environment   = "prod"
region        = "eu-central-1"

Отримуємо таку структуру:

[simterm]

$ tree
.
|-- environments
|   |-- dev
|   |   |-- main.tf
|   |   |-- provider.tf
|   |   |-- terraform.tf
|   |   |-- terraform.tfvars
|   |   `-- variables.tf
|   `-- prod
|       |-- main.tf
|       |-- provider.tf
|       |-- terraform.tf
|       |-- terraform.tfvars
|       `-- variables.tf
`-- modules
    `-- vpc
        |-- main.tf
        `-- variables.tf

[/simterm]

Перевіримо наш Dev – виконуємо init:

[simterm]

$ terraform init

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing modules...

Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Installing hashicorp/aws v4.67.0...
- Installed hashicorp/aws v4.67.0 (signed by HashiCorp)

Terraform has been successfully initialized!

[/simterm]

І plan:

[simterm]

$ terraform plan
...
Terraform will perform the following actions:

  # module.vpc.aws_vpc.env_vpc will be created
  + resource "aws_vpc" "env_vpc" {
      + arn                                  = (known after apply)
      + cidr_block                           = "10.0.0.0/24"
      ...
      + tags                                 = {
          + "environment" = "dev"
        }
      + tags_all                             = {
          + "environment" = "dev"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

[/simterm]

Окей – можна створювати ресурси, але як щодо корзини tfvars-envs, яку ми вказали у backend? Якщо ми спробуємо виконати apply зараз, то деплой сфейлиться, бо бакету для бекенду нема.

Тобто – як взагалі підготувати AWS аккаунт до використання Terraform, виконати його bootstraping?

Terraform Backend Bootstrap

Тобто, маємо новий проект, новий аккаунт, і нам десь треба зберігати state-файли. Ми будемо використовувати AWS S3, а потім ще додамо DynamoDB для state-lock, але й корзина, і таблиця в DynamoDB мають бути створені до деплою нового проекту.

Поки бачу три основних варіанти:

  • “clickops”: все створюємо руками через AWS Console
  • скриптом або вручну створювати через AWS CLI
  • рішення по типу Terragrunt або Terraform Cloud, але це поки овер-інжинірінг для такого маленького проекту
  • мати окремий проект з Terraform, назвемо його bootstrap, в якому створюються ресурси і стейт-файл, який потім імпортуємо в новий бекенд

Ще з найдених варіантів – використовувати CloudFormation для цього – How to bootstrap an AWS account with Terraform state backend, але таке собі – не хочеться змішувати кілька orchestration management тулів.

Ще нагуглив рішення з Makefile – Terrastrap – Bootstrap a S3 and DynamoDB backend for Terraform, цікава реалізація.

До речі, якщо маєте GitLab – то в нього є свій бекенд для Terraform-state, див. GitLab-managed Terraform state, і в такому випадку нічого створювати не потрібно (хіба що DynamoDB та AIM, але питання зі стейтами вирішується).

В принципі якщо питання просто створити корзину, то можна й AWS CLI, але як бути, коли планується і S3, і DynamoDB, та ще й окремий IAM юзер для Terraform з власною IAM Policy? Все робити через AWS CLI? І це повторювати для всіх нових проектів вручну? Ну, таке собі.

Перше рішення, яке придумалось – це мати єдиний bootstrap-проект, в якому ми будемо створювати ресурси для всіх іншних проектів, тобто – всі корзини/Dynamo/IAM, просто через різні tfvars – можна було  б організувати щось накташлт рішення з Dev/Prod оточеннями, як робили вище. Тобто у репозиторії з bootstrap-проектом мати окремі директорії з власними файлами terraform.tf, provider.tf та terraform.tfvars під кожен новий проект.

В такому випадку можна руками з AWS CLI створити перший бакет для самого проекту bootstrap, і вже в цьому проекті описуємо створення DynamoDB, S3-бакетів, IAM-ресурсів для інших проектів.

Для проекту bootstrap для аутентифікації можна взяти якісь існуючі ACCESS/SECRET ключі, а інші проекти вже зсможуть використовувати IAM юзера або роль, яку ми створимо у бутстрапі.

Виглядає наче робочою ідею, але є ще один варіант – використовувати каталог/репозиторій bootstrap як модуль в кожному проекті, і створювати ресурси перед запуском проекту.

Тобто:

  • модуль bootsrap – його зберігаємо в репозиторії для доступу з інших проектів
  • потім при створенні нового проекту – включаємо цей модуль в код, за його допомогою створюємо S3-бакет, AIM та DynamoDB
  • після створення – імпортуємо state-файл, який отримали після бутстрапу, в нову корзину
  • і вже тоді починаємо роботу з оточеннями

Спробуємо – як на мене, то цей варіант виглядає непогано.

Видаляємо корзину, яку створили на початку, вона має бути порожня, бо з terraform apply ми нічого не створювали:

[simterm]

$ aws s3 rb s3://tfvars-envs
remove_bucket: tfvars-envs

[/simterm]

Створення Bootstrap модулю

Створюємо репозиторій, і в ньому файл s3.tf з aws_s3_bucket – поки обійдемось без IAM/Dynamo, тут чисто для прикладу і перевірки плану:

resource "aws_s3_bucket" "project_tfstates_bucket" {
  bucket = var.tfstates_s3_bucket_name

  tags = {
    environment = "ops"
  }
}

resource "aws_s3_bucket_versioning" "project_tfstates_bucket_versioning" {
  bucket = aws_s3_bucket.project_tfstates_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

Додаємо variables.tf з ім’ям корзини:

variable "tfstates_s3_bucket_name" {
  type = string
}

Тепер повертаємось до нашого проекту, і в корні створюємо файл main.tf, в якому використовєємо bootstrap модуль з Github:

module "bootstrap" {
  source = "[email protected]:setevoy2/terraform-bootsrap.git"

  tfstates_s3_bucket_name = var.tfstates_s3_bucket_name
}

У source, до речі, можемо задати бранч або версію, наприклад:

source = "[email protected]:setevoy2/terraform-bootsrap.git?ref=main

Далі, додаємо файл variables.tf:

variable "tfstates_s3_bucket_name" {
  type = string 
}

variable "region" {
  type = string
}

Файл provider.tf:

provider "aws" {
  region    = var.region
  profile   = "default"
}

І terraform.tf:

terraform {
  required_providers {
    aws = { 
      source  = "hashicorp/aws"
      version = ">= 4.6.0"
    }
  }

  required_version = ">= 1.4"

#  backend "s3" {
#    bucket = "tfvars-envs"
#    region = "eu-central-1"
#    key    = "bootstrap/terraform.tfstate"
#  }   
}

Тут блок backend поки закоментований – повернемось до нього, як створимо корзину, поки що state file буде згенеровано локально. У key вказуємо шлях bootstrap/terraform.tfstate – саме туди буде імпортовано наш стейт.

Додаємо файл terraform.tfvars:

tfstates_s3_bucket_name = "tfvars-envs"
region                  = "eu-central-1"

Тепер структура виходить така:

[simterm]

$ tree
.
|-- environments
|   |-- dev
|   |   |-- main.tf
|   |   |-- provider.tf
|   |   |-- terraform.tf
|   |   |-- terraform.tfvars
|   |   `-- variables.tf
|   `-- prod
|       |-- main.tf
|       |-- provider.tf
|       |-- terraform.tf
|       |-- terraform.tfvars
|       `-- variables.tf
|-- main.tf
|-- modules
|   `-- vpc
|       |-- main.tf
|       `-- variables.tf
|-- provider.tf
|-- terraform.tf
|-- terraform.tfvars
`-- variables.tf

[/simterm]

Тобто, в корні проекту у main.tf ми виконуємо тільки бутстрап для створення корзини, а потім вже з каталогів environments/{dev,prod} створюємо ресурси інфрастуктури.

Створення Bootstrap S3-корзини

У корні виконуємо terraform init:

[simterm]

$ terraform init

Initializing the backend...
Initializing modules...
Downloading git::ssh://[email protected]/setevoy2/terraform-bootsrap.git for bootstrap...
- bootstrap in .terraform/modules/bootstrap

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 4.6.0"...
- Installing hashicorp/aws v4.67.0...
- Installed hashicorp/aws v4.67.0 (signed by HashiCorp)
...

[/simterm]

Перевіряємо з terraform plan, і як все гаразд – то запускаємо створення корзини:

[simterm]

$ terraform apply
...
  # module.bootstrap.aws_s3_bucket.project_tfstates_bucket will be created
  + resource "aws_s3_bucket" "project_tfstates_bucket" {
...
module.bootstrap.aws_s3_bucket_versioning.project_tfstates_bucket_versioning: Creation complete after 2s [id=tfvars-envs]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[/simterm]

Тепер наступний крок – імпортувати локальний state-файл:

[simterm]

$ head -5 terraform.tfstate
{
  "version": 4,
  "terraform_version": "1.4.6",
  "serial": 4,
  "lineage": "d34da6b7-08f4-6444-1941-2336f5988447",

[/simterm]

Розкоментуємо блок backend у terraform.tf рутового модулю:

terraform {
  required_providers {
    aws = { 
      source  = "hashicorp/aws"
      version = ">= 4.6.0"
    }
  }

  required_version = ">= 1.4"

  backend "s3" {
    bucket = "tfvars-envs"
    region = "eu-central-1"
    key    = "bootstrap/terraform.tfstate"
  }   
}

І визиваємо terraform init ще раз – тепер він бачить, що замість local backend має s3 backend, і запропонує мігрувати terraform.tfstate туди – відповідаємо yes:

[simterm]

$ terraform init

Initializing the backend...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "s3" backend. No existing state was found in the newly
  configured "s3" backend. Do you want to copy this state to the new "s3"
  backend? Enter "yes" to copy and "no" to start with an empty state.

  Enter a value: yes


Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Initializing modules...

Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using previously-installed hashicorp/aws v4.67.0

Terraform has been successfully initialized!

[/simterm]

Тепер маємо налаштований бекенд, котрий можемо використовувати для проекту.

Повертаємось до environments/dev/, перевіряємо ще раз з plan, і нарешті створимо наше Dev-оточення:

[simterm]

$ terraform apply
...
module.vpc.aws_vpc.env_vpc: Creating...
module.vpc.aws_vpc.env_vpc: Creation complete after 2s [id=vpc-0e9bb9408db6a2968]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

[/simterm]

Перевіряємо корзину:

[simterm]

$ aws s3 ls s3://tfvars-envs
                           PRE bootstrap/
                           PRE dev/

[/simterm]

І файл стейту:

[simterm]

$ aws s3 ls s3://tfvars-envs/dev/
2023-05-14 13:37:27       1859 terraform.tfstate

[/simterm]

Все є.

Отже, процесс створення нового проекту буде таким:

  1. у корні проекту створюємо main.tf, в якому описуємо використання модулю bootstrap з source = "[email protected]:setevoy2/terraform-bootsrap.git
  2. у файлі terraform.tf описуємо бекенд, але коментуємо його
  3. створюємо корзину з модулю bootsrap
  4. розкоментуємо бекенд, і через terrafrom init імпортуємо локальний state file

Після цього проект готовий до створення dev/prod оточень з бекендом для стейт-файлів у новій корзині.

І да, таки цікаво які тули/підходи використовуєте, тож велкам у коменти або чатик RTFM у Telegram.

Посилання по темі

Loading

AWS: CDK – знайомство та приклади на Python
0 (0)

12 Травня 2023

AWS Cloud Development Kit (AWS CDK) дозволяє описувати інфрастуктуру використовуючи мови програмування TypeScript, JavaScript, Python, Java, C# або Go.

“Під капотом” створює CloudFormation стек, в якому створються ресурси, описані в вашому коді.

Відповідь на питання “Нашо CDK, коли є Terraform?” можна знайти ось тут – 4 ultimate reasons to prefer AWS CDK over Terraform.

Але так як я поки CDK не користувався, то про переваги та недоліки казати нічого не буду.

Єдине, на що відразу можна звернути увагу, це те, ще по-перше – нема state-файлів, як у Terraform, які, звістно, корисні, але додають трохи болю при менеджменті, по-друге – сам CloudFortaion, який має свої недоліки та “це не баг, а фіча”, зато маємо можливість у веб-інтерфейсі AWS Console побачити всі ресурси.

Взагалі, до AWS CDK прийшов тому, що на новому проекті він вже використовується, тож перш ніж тягнути в проект Terraform, треба розібратись з тим, що тут вже є.

UPD: Ну, нє, таки скажу. Виглядає наче й непогано і цікаво, бо “нарешті Python!”, але:

  • всеж HCL-код виглядає куди більш лаконічно та зрозуміло
  • прикладів та й банально результатів пошуку у Гуглі по Terraform набагто більше, а це значить і швидкість виконання задачі більша
  • ну й… дойшов до того, що треба було створити SES домен, і… І нічого. Дуже неочікувано, але в стандартних Construtcs нічого толком не зайшов, а єдиний більш-менш конструкт з Construct Hub мав приклади тільки для TypeScript, навіть у PyDoc. Таке собі задоволення, чесно кажучи

Окрім CDK для самого AWS, є також cdk8s для Kubernetes та CDKTF для Terraform.

Окей, давайте знайомитись з AWS CDK.

Key concepts

Почати можна з документації AWS Getting started with the AWS CDK або переглянути непоганий відео-туторіал на 20 хвилин Getting Started with AWS CDK and Python.

Отже, основні поняття, якими будемо оперувати при роботі з AWS CDK:

  • App: App являє собою такий собі “контейнер”, в якому ми описуємо наш застосунок, і може мати в собі один або більше Stacks (які потім будут сформовані у CloudFormation Stacks). Див. Apps.
  • Stack: зі Stack буде формуватись CloudFormation Stack або change set. У самому Stack на рівні коду ми описуємо те, які саме ресурси в цьому стеку будуть створені, а ресурси описуємо, використовуючи Constructs. Див. Stacks.
  • Construct: основні “будівельні блоки” у CDK, в яких описуються компоненти, которі необхідно створити в AWS. Див. Construct.

На Construct зупинимось трохи детальніше, бо вони розподіляють на три основних групи:

  • AWS CloudFormation-only або L1 (“layer 1”): тут маємо ресурси, які описані і підтримуються самим CloudFormation, і всі такі ресурси мають имена з префіксом Cfn, наприклад, для AWS S3 бакетів це CfnBucket. Всі ці ресурси знаходяться у модулі aws-cdk-lib.
  • Curated або L2: ці конструкти розроблені командою AWS CDK для спрощення управління інфрастуктурою. Як правило, вони включать в себе ресурси з L1 з деякими дефолтними значеннями та політиками безпеки. Ресурси у aws-cdk-lib готові до використання у production, а якщо ресурс являє собою окремий модуль – то він ще або у стані розробки, або є experimental.
  • Patterns або L3: Patterns включають в себе декілька ресурсів, які дозволяють побудувати всю архітектуру під конкретний use case. Так само як і з L2 ресурсами, готові до продакшену модулі включені в модуль aws-cdk-lib, а ті, що знаходяться у стані розробки – являть собою окремі модулі.

Окрім AWS Construct Library є ще й Construct Hub, в якому можна знайти модулі від партнерів AWS.

Встановлення AWS CDK

Для роботи з AWS CDK, навіть якщо ви будете писати на Python, потрібна Node.js, так як всі мови програмування на CDK будуть працювати через бекенд на Node.js.

Для роботи з CDK маємо CLI, через яку можемо створювати нові App, генерувати CloudFormation темплейти, виконувати diff між нашим кодом і існуючими CloudFormation стеками та багато іншого.

Встановлюємо сам CDK – бекенд та CLI:

[simterm]

$ npm install -g aws-cdk
added 1 package, and audited 2 packages in 1s

[/simterm]

Перевіряємо CLI:

[simterm]

$ cdk --help
Usage: cdk -a <cdk-app> COMMAND

Commands:
  cdk list [STACKS..]             Lists all stacks in the app      [aliases: ls]
  cdk synthesize [STACKS..]       Synthesizes and prints the CloudFormation
                                  template for this stack       [aliases: synth]
  cdk bootstrap [ENVIRONMENTS..]  Deploys the CDK toolkit stack into an AWS
                                  environment
  cdk deploy [STACKS..]           Deploys the stack(s) named STACKS into your
                                  AWS account
...

[/simterm]

Цікавості заради – куди веде сам файл cdk:

[simterm]

$ which cdk
/home/setevoy/.nvm/versions/node/v16.18.0/bin/cdk

[/simterm]

Ага, Node.js.

Authentication with AWS

Документація – Authentication and access:

  • AWS SSO: використовууючи SSO-сессію через AWS CLI конфіг (~/aws/config), див. IAM Identity Center authentication
  • AWS EC2 Instance IAM Role: якщо код CDK запускається всередені AWS, наприклад з EC2, то до інстансу можна підключити IAM roles for Amazon EC2
  • AWS IAM User Access/Secret keys: ну і звичні ключі доступу для AWS CLI з профілем у файлах ~/aws/config та ~/.aws/credentials

Створення проекту

cdk init

За допомогою cdk init можемо згенерувати шаблон файлів та директорій.

Щоб отримати допомогу по конкретній команді, наприклад для init – додайте --help після неї, тобто cdk init --help:

Тут з цікавих опцій можуть бути наступні:

  • --verbose: більш детальний аутпут
  • --debug: ще більш детальний
  • --role-arn: використовувати IAM Role (див. AWS: IAM AssumeRole – описание, примеры)
  • --language: мова програмування, яка буде використовуватись при створенні проекту
  • --list: отримати список доступних шаблонів

Спробуємо list:

[simterm]

$ cdk init --list
Available templates:
* app: Template for a CDK Application
   └─ cdk init app --language=[csharp|fsharp|go|java|javascript|python|typescript]
* lib: Template for a CDK Construct Library
   └─ cdk init lib --language=typescript
* sample-app: Example CDK Application with some constructs
   └─ cdk init sample-app --language=[csharp|fsharp|go|java|javascript|python|typescript]

[/simterm]

Тут можемо створити шаблон для App, бібліотеки для Construct Library, або створити sample-app, тобто приклад App, в якому вже будуть додані якісь Constructcs.

Створюємо директорію нашого проекту:

[simterm]

$ mkdir cdk-example && cd cdk-example

[/simterm]

Запускаємо init sample-app:

[simterm]

$ cdk init sample-app --language=python
Applying project template sample-app for python
...
Initializing a new git repository...
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint: 
hint:   git config --global init.defaultBranch <name>
hint: 
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint: 
hint:   git branch -m <name>
Please run 'python3 -m venv .venv'!
Executing Creating virtualenv...
✅ All done!

[/simterm]

Глянемо структуру файлів та директорій проекту:

[simterm]

$ tree .
.
|-- README.md
|-- app.py
|-- cdk.json
|-- cdk_example
|   |-- __init__.py
|   `-- cdk_example_stack.py
|-- requirements-dev.txt
|-- requirements.txt
|-- source.bat
`-- tests
    |-- __init__.py
    `-- unit
        |-- __init__.py
        `-- test_cdk_example_stack.py

4 directories, 11 files

[/simterm]

Python virtualenv та встановлення модулів AWS CDK

source.bat – скрипт для Windows для створення Python virtualenv, який має викликати файл .venv\Scripts\activate.bat:

[simterm]

$ tail -1 source.bat 
.venv\Scripts\activate.bat

[/simterm]

Але так як я це роблю на Linux, то каталогу .venv\Scripts намє взагалі, натомість маємо набор скриптів у .venv/bin/ (ну теж якось виглядає… AWS CDK начебто серйозний проект, але таку дрібницю, як скрипти, зроблено через якось… недбало?):

[simterm]

$ ls -1a .venv/bin/
.
..
Activate.ps1
activate
activate.csh
activate.fish
pip
pip3
pip3.11
python
python3
python3.11

[/simterm]

Для Linux використовуємо .venv/bin/activate, який являею собой shell-команди для створення та налаштування змінних оточення:

[simterm]

$ . .venv/bin/activate
(.venv)

[/simterm]

Щоб перевірити, що ми справді у virtualenv можна перевірити значення змінної $VIRTUAL_ENV, яка має шлях до каталогу поточного віртуального оточення, в якому будуть необхідні бібліотеки:

[simterm]

$ echo $VIRTUAL_ENV
/home/setevoy/Scripts/AWS_CDK/.venv

[/simterm]

Далі, встановлюємо залежності – модулі aws-cdk-lib та constructs:

[simterm]

$ pip install -r requirements.txt
...
Collecting aws-cdk-lib==2.78.0 
 Using cached aws_cdk_lib-2.78.0-py3-none-any.whl (41.0 MB) 
Collecting constructs<11.0.0,>=10.0.0 
 Using cached constructs-10.2.18-py3-none-any.whl (58 kB)
...

[/simterm]

Файл app.py

Перевіримо зміст app.py, який являє собою основу нашого проекту, бо саме з нього CDK почне свою роботу:

#!/usr/bin/env python3

import aws_cdk as cdk

from cdk_example.cdk_example_stack import CdkExampleStack


app = cdk.App()
CdkExampleStack(app, "cdk-example")

app.synth()

Першим виконуємо import aws_cdk as cdk – імпортуємо модуль aws_cdk dir, який знаходиться у каталозі .venv:

[simterm]

$ find . -name aws_cdk
./.venv/lib/python3.11/site-packages/aws_cdk

[/simterm]

Далі, from cdk_example.cdk_example_stack import CdkExampleStack – імпортуємо клас CdkExampleStack(Stack) з модулю cdk_example_stack.py:

from constructs import Construct
from aws_cdk import (
    Duration,
    Stack,
    aws_iam as iam,
    aws_sqs as sqs,
    aws_sns as sns,
    aws_sns_subscriptions as subs,
)


class CdkExampleStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        queue = sqs.Queue(
            self, "CdkExampleQueue",
            visibility_timeout=Duration.seconds(300),
        )

        topic = sns.Topic(
            self, "CdkExampleTopic"
        )

        topic.add_subscription(subs.SqsSubscription(queue))

А в ньому вже бачимо самі ресурси, які будуть створюватись – SQS та SNS з Subscription.

Можна переглянути документацію по ресурсах:

[simterm]

>>> import aws_cdk as cdk
>>> help (cdk.App())

[/simterm]

Де буде описаний клас App:

[simterm]

Help on App in module aws_cdk object:

class App(Stage)
 |  App(*args: Any, **kwargs) -> Any
 |  
 |  A construct which represents an entire CDK app. This construct is normally the root of the construct tree.
 |  
 |  You would normally define an ``App`` instance in your program's entrypoint,
 |  then define constructs where the app is used as the parent scope.
...

[/simterm]

Добре, йдемо далі.

cdk list (або ls) поверне нам список ресурсів в поточному каталозі/проекті:

[simterm]

$ cdk ls
cdk-example

[/simterm]

Далі, можемо спробувати cdk synth, який сгенерує нам шаблон CloudFormation, которий буде використано при деплої ресурсів:

[simterm]

$ cdk synth
Resources:
  CdkExampleQueue7618E31B:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeout: 300
    UpdateReplacePolicy: Delete
    DeletionPolicy: Delete
    Metadata:
      aws:cdk:path: cdk-example/CdkExampleQueue/Resource
  CdkExampleQueuePolicy839151B5:
    Type: AWS::SQS::QueuePolicy
...

[/simterm]

Робота з AWS CDK

AWS Account CDK Bootstrap

Перед тим, як вже деплоїти проект, нам потрібно налаштувати наш AWS аккаунт (або регіон) для роботи AWS CDK. Для цього використовуємо cdk bootstrap, який створить CloudFormation стек з необхідними для роботи CDK ресурсами – S3-корзиною, ролі та полісі в IAM, ECR репозиторій, та записи у AWS Systems Manager Parameter Store. Див. bootstrapping.

Запускаємо:

[simterm]

$ cdk -v bootstrap
...
 ⏳  Bootstrapping environment aws://264***286/eu-central-1...
...
CDKToolkit |  0/12 | 1:43:06 PM | REVIEW_IN_PROGRESS   | AWS::CloudFormation::Stack | CDKToolkit User Initiated
CDKToolkit |  0/12 | 1:43:11 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | CDKToolkit User Initiated
CDKToolkit |  0/12 | 1:43:16 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role          | FilePublishingRole 
CDKToolkit |  0/12 | 1:43:16 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role          | LookupRole 
CDKToolkit |  0/12 | 1:43:16 PM | CREATE_IN_PROGRESS   | AWS::SSM::Parameter     | CdkBootstrapVersion 
CDKToolkit |  0/12 | 1:43:16 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role          | CloudFormationExecutionRole 
CDKToolkit |  0/12 | 1:43:16 PM | CREATE_IN_PROGRESS   | AWS::ECR::Repository    | ContainerAssetsRepository 
CDKToolkit |  0/12 | 1:43:16 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role          | ImagePublishingRole 
CDKToolkit |  0/12 | 1:43:16 PM | CREATE_IN_PROGRESS   | AWS::S3::Bucket         | StagingBucket
...
CDKToolkit | 11/12 | 1:44:02 PM | CREATE_COMPLETE      | AWS::IAM::Role          | DeploymentActionRole 
CDKToolkit | 12/12 | 1:44:04 PM | CREATE_COMPLETE      | AWS::CloudFormation::Stack | CDKToolkit 
[13:44:09] Stack CDKToolkit has completed updating
 ✅  Environment aws://264***286/eu-central-1 bootstrapped.

[/simterm]

Перевіряємо S3 бакет:

[simterm]

$ aws s3 ls
2023-05-10 13:43:42 cdk-hnb659fds-assets-264***286-eu-central-1

[/simterm]

cdk deploy

І тепер можемо виконати cdk deploy, який створить CloudFormation Stack з нашими SQS/SNS/Subscription:

[simterm]

$ cdk deploy      
...
cdk-example: assets built

This deployment will make potentially sensitive changes according to your current security approval level (--require-approval broadening).
Please confirm you intend to make the following modifications:

IAM Statement Changes
┌───┬────────────────────────┬────────┬─────────────────┬───────────────────────────┬────────────────────────────────────────────────────────┐
│   │ Resource               │ Effect │ Action          │ Principal                 │ Condition                                              │
├───┼────────────────────────┼────────┼─────────────────┼───────────────────────────┼────────────────────────────────────────────────────────┤
│ + │ ${CdkExampleQueue.Arn} │ Allow  │ sqs:SendMessage │ Service:sns.amazonaws.com │ "ArnEquals": {                                         │
│   │                        │        │                 │                           │   "aws:SourceArn": "${CdkExampleTopic}"                │
│   │                        │        │                 │                           │ }                                                      │
└───┴────────────────────────┴────────┴─────────────────┴───────────────────────────┴────────────────────────────────────────────────────────┘
(NOTE: There may be security-related changes not in this list. See https://github.com/aws/aws-cdk/issues/1299)

Do you wish to deploy these changes (y/n)? y
...

[/simterm]

Віповідаємо Y:

[simterm]

...
Do you wish to deploy these changes (y/n)? y
cdk-example: deploying... [1/1]
[0%] start: Publishing 20e979ce16c7aba5e874330247d9054b841ea313261b523b47a50fc4cd1d6662:current_account-current_region
[100%] success: Published 20e979ce16c7aba5e874330247d9054b841ea313261b523b47a50fc4cd1d6662:current_account-current_region
cdk-example: creating CloudFormation changeset...
[███████████████████▎······································] (2/6)

1:48:50 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | cdk-example
1:48:54 PM | CREATE_IN_PROGRESS   | AWS::SQS::Queue        | CdkExampleQueue
...

[/simterm]

CDK локально сгенерує файл темплейту cdk.out/cdk-example.template.json для CloduForamtion та загрузить його до бакету CDK, який був створений під час виконання cdk bootstrap:

[simterm]

$ aws s3 ls cdk-hnb659fds-assets-264***286-eu-central-1
2023-05-10 13:48:45       5750 20e979ce16c7aba5e874330247d9054b841ea313261b523b47a50fc4cd1d6662.json

[/simterm]

Перевіряємо CloduForamtion стек:

[simterm]

$ aws cloudformation list-stacks
{
    "StackSummaries": [
        {
            "StackId": "arn:aws:cloudformation:eu-central-1:264***286:stack/cdk-example/3c4e4db0-ef20-11ed-9672-0a9a3483d50e",
            "StackName": "cdk-example",
            "CreationTime": "2023-05-10T10:48:45.099000+00:00",
...

[/simterm]

Або у AWS Console:

Тим часом деплой завершено:

[simterm]

...
 ✅  cdk-example

✨  Deployment time: 91.52s

Stack ARN:
arn:aws:cloudformation:eu-central-1:264***286:stack/cdk-example/3c4e4db0-ef20-11ed-9672-0a9a3483d50e

✨  Total time: 97.99s

[/simterm]

cdk diff

Добре – побачили, як воно все працює на всьому готовому, тепер давайте спробуємо створити щось власне, наприклад – S3 корзину.

До імпортів додаємо aws_s3 as s3 та прибираємо sns/sqs, iam та Duration.

Видаляємо ресурси SQS та SNS з класу CdkExampleStack, та описуємо створення корзини – беремо приклад з документації PyPI:

from constructs import Construct
from aws_cdk import (
    Stack,
    aws_s3 as s3
)


class CdkExampleStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        bucket = s3.Bucket(self, "MyEncryptedBucket",
            encryption=s3.BucketEncryption.KMS
        )

І поглянемо, що нам поверне cdk diff:

Червоним та - це те, що буде видалятись, зеленим та + – створюватись нове (прям дуже terraform plan нагадало).

Окей – і запускаємо деплой:

[simterm]

$ cdk deploy

✨  Synthesis time: 6.38s

cdk-example: building assets...
...
Do you wish to deploy these changes (y/n)? y
cdk-example: deploying... [1/1]
[0%] start: Publishing 5bb8c7fc8643769d69d5eb9712af36c955f9b509cc05d26740d035e9d7225a16:current_account-current_region
[100%] success: Published 5bb8c7fc8643769d69d5eb9712af36c955f9b509cc05d26740d035e9d7225a16:current_account-current_region
cdk-example: creating CloudFormation changeset...
[████████████▉·············································] (2/9)

11:29:47 AM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | cdk-example
11:31:54 AM | CREATE_IN_PROGRESS   | AWS::S3::Bucket    | MyEncryptedBucket
...

[/simterm]

Глянемо, як воно виглядає в UI:

Готово.

Ну і приберемо за собою – видалимо стек.

cdk destroy

Перевіримо їм’я стеку з list:

[simterm]

$ cdk ls            
cdk-example

[/simterm]

І виконуємо cdk destroy з ім’ям стеку, щоб повністю його видалити:

[simterm]

$ cdk destroy cdk-example
Are you sure you want to delete: cdk-example (y/n)? y
cdk-example: destroying... [1/1]

 ✅  cdk-example: destroyed

[/simterm]

Глянемо адмінку:

Але бакет та ключ не видалило. А чому?

AWS CDK RemovalPolicy

Тому що у aws_cdk.core є окрема RemovalPolicy, яка по дефолту має значення Retain.

Ця політика контролює дії, які будуть виконані з ресурсами, которі були видалені з-під контролю CloudFormation:

  • якщо ресурс видалений з шаблону (взагалі я чомусь думав, що CloudFormation видаляє такі ресурси, але то з досвіду, коли шаблони писались делоїлись вручну через AWS CLI, у випадку з CDK, як бачимо, по дефолту вони таки зберігаються)
  • ресурс потребує заміни шляхом створення нового, тож CloudFormation створює новий, а старий видаляє зі свого контролю, але залишає сам ресурс
  • CloudFormation стек видалено

Останній пункт у нас і спрацював.

Окей, давайте повторимо експеримент – створимо стек заново, але до корзини додамо параметр removal_policy для її видалення при видаленні стеку, і auto_delete_objects=True, щоб видалити всі об’єкти в ній, бо інакше корзину видалити не можна.

Крім того, ключ для корзини треба створити окремим об’єктом і передати йому власний removal_policy, а потім цей ключ передавати аргументом в параметр encryption_key корзини:

from constructs import Construct
from aws_cdk import (
    Stack,
    RemovalPolicy,
    aws_s3 as s3,
    aws_kms as kms
)


class CdkExampleStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        my_key = kms.Key(self, "MyKey",
            enable_key_rotation=True,
            removal_policy=RemovalPolicy.DESTROY
        )

        bucket = s3.Bucket(self, "MyEncryptedBucket",
            encryption=s3.BucketEncryption.KMS,
            encryption_key=my_key,
            removal_policy=RemovalPolicy.DESTROY,
            auto_delete_objects=True
        )

Виконуємо synth:

[simterm]

$ cdk synth
Resources:
  MyKey6AB29FA6:
    Type: AWS::KMS::Key
    ...
    UpdateReplacePolicy: Delete
    DeletionPolicy: Delete
...
  MyEncryptedBucket9A8D2FE1:
    Type: AWS::S3::Bucket
    ...
    UpdateReplacePolicy: Delete
    DeletionPolicy: Delete
...

[/simterm]

Ось тепер має спрацювати – у обох ресурсів бачимо DeletionPolicy: Delete.

деплоймо:

[simterm]

$ cdk deploy
...
cdk-example: creating CloudFormation changeset...

 ✅  cdk-example

✨  Deployment time: 180.7s

Stack ARN:
arn:aws:cloudformation:eu-central-1:264***286:stack/cdk-example/1f5353d0-efe4-11ed-a627-02deb26b4a5c

✨  Total time: 187.53s

[/simterm]

І видаляємо:

[simterm]

$ cdk destroy
Are you sure you want to delete: cdk-example (y/n)? y
cdk-example: destroying... [1/1]

 ✅  cdk-example: destroyed

[/simterm]

Не встиг зробити скрін, але CDK запускав AWS Lambda, яка видаляла об’єкти в корзині, а може й саму корзину.

Ну й поки на цьому все.

У Workshop є ще приклади роботи, більше “продвинуті”, тож рекомендую.

Loading

AWS: Fargate – можливості, порівняння з Lambda/EC2 та використання з AWS EKS
0 (0)

3 Травня 2023

AWS Fargate – ще одне serverless-рішення від Amazon, яке бере на себе управління інфраструктурою, позбавляючи користувача необхідності витрачати час на налаштування ЕС2-інстансів, операційної системи, систем управління контейнерами тощо.

Взагалі, коли знайомився з Fargate, натрапив на чудове відео з AWS re:Invent 2022, де дуже добре розказано (і показано) про Shared Responsibility model у AWS – за які частини системи відповідає Амазон, а за які – користувач, тож дуже рекомендую до перегляду – AWS re:Invent 2022 – A close look at AWS Fargate and AWS App Runner.

Якщо поглянути на схему з цього відео, то там гарно відображена роль Fargate:

Тобто, AWS бере на себе все, пов’язане з серверами та операційною системою і її компонентами, тоді як нам лишається тільки створити та запустити контейнер.

При цьому, AWS Fargate можна використовувати разом із AWS Elastic Container Service або AWS Elastic Kubernetes Service, і саме його роботу з AWS EKS ми сьогодні й розглянемо.

AWS Fargate vs AWS Lambda

Перше питання, яке з’явилось у мене, коли я почав читати про Fargate – а навіщо, якщо вже є AWS Lambda? В чому різниця? До речі, у відео ще розказується і про AWS App Runner – ще один serverless-сервіс від Амазону, але зараз не про нього (а ще маємо Knative, хоча це вже не про AWS).

Functionality

Отже, концептуально – AWS Fargate являє собою CaaS, тобто Container as a Service, тоді як AWS Lambda – це FaaS, тобто Function as a Service: для роботи з Fargate вам потрібно мати зібраний docker-образ (чи будь-який інший відповідний до Open Container Initiative специфікації), тоді як для роботи з AWS Lambda вам потрібен тільки код – Lambda сама “запакує” його в контейнер, та запустить.

Крім того, для Fargate ви маєте налаштовувати автоскейлінг контейнерів, тоді як у Lambda це відбувається автоматично. Крім того, контейнери у Fargate не будуть скейлитись в нуль, коли немає роботи – для цього ви маєте виключати Fargate tasks самі (або просто скейлити в нуль поди в Kubernetes), а у Lambda фунцкції будуть запинені, як тільки до них перестануть надходити евенти, які тригерять запуск цих функцій.

Вартість та оплата за сервіс

При цьому обидва сервіси мають однакову модель оплати – pay-as-you-go model, тобто ви платите тільки за час, коли ваш контейнер або функція виконуються, хоча й мають відмінності: у Fargate оплата стягується саме за споживані CPU/RAM в секунду, тоді як у Labmda ви платите за кожен виклик функції та за час її виконання. Див. AWS Fargate Pricing.

Use Cases

Fargate добре підходить для роботи довготривалих задач, для яких ви маєте більше можливостей налаштувати робоче оточення, і маєте менше обмежень на CPU/RAM, дискову систему для збереження даних та не маєте таких суттєвих лімітів на розмір даних, які можете відправляти/отримувати.

З іншого боку Lambda дозволяє вам швидше запускати код (бо не маєте потреби збирати образ контейнеру), автоматичний скейлінг “з коробки”, моніторинг, і добре підходить для короткотривалих задач.

AWS Fargate vs AWS EKS EC2 Node Groups

Вже по ходу діла запуску перших подів у EKS з використанням Fargate з’явилося інше питання – а що там з EC2?

В цьому порівняні, у Fargate такі переваги:

  • більш швидкий скейлінг
  • може бути більше cost effective рішенням, ніж EC2
  • не потребує security патчів (хоча Managed Node Groups начебто теж самі встановлюють патчі)

Недоліки Fargate:

  • менше контролю над інфрастуктурою
  • іноді рішення з EC2 може бути більш вигідним по вартості
  • обмеження по CPU/Memory та типам інстансів (наприклад, немає змоги звикористовувати GPU)

У випадку з EC2 ви маєте більший контроль над інфрастуктурою та типами інстансів (GPU, мережа тощо), але це потребує більше роботи інженерів (запуск, обслуговання серверів, моніторинг), до того ж ви платити за сервери незважаючи на те, виконується на них якась робота, чи ні.

Взагалі, ви просто можете в одному EKS-кластері мати і Node Groups, і Fargate-інстанси для різних подів.

Amazon EKS та AWS Fargate

Отже, у EKS наші поди мають чомусь запускатись. Зазвичай для цього використовуються NodeGrops (Managed та Self-managed), які являють собою звичайні AWS EC2 інстанси, але замість віртуальних машин ми можемо використати AWS Fargate, див. Amazon EKS nodes.

Які саме поди будуть запускатись налаштовується у Fargate profiles, які являються частиною вашого EKS-кластеру. Сам EKS інтегруються з Fargate через контролери, які вбудовані в сервіс EKS і працюють на його control plane. Крім того, для запуску подів у Fargate є окремий scheduler – fargate-scheduler (на відміну від default-scheduler, котрий відповідає за запуск подів на ЕС2-інстансах).

Див. AWS Fargate.

Особливості Fargate у EKS

При планувані використання AWS Fargate разом з вашим EKS, майте на увазі, що:

  • Network Load Balancers та Application Load Balancers при використанні Fargate мають бути з IP targets
  • DaemonSets не підтримуються
  • Privileged containers не підтримуються
  • Pods у Fargate не можуть мати HostPort або HostNetwork
  • Pods у Fargate можуть бути запущені тільки у приватних мережах (private subnets)
  • ви можете використовувати Vertical Pod Autoscaler щоб задати потрібні resources.requests для подів, і потім скейлити їх за допомогою Horizontal Pod Autoscaler
  • Amazon EC2 instance metadata service (IMDS) не підтримується у Fargate
  • на Fargate нодах використовується Amazon VPC CNI plugin for Amazon EKS, альтернативні CNI plugins не підтримуються
  • ви можете використовувати Amazon EBS CSI controller з Fargate, але не маєте змоги підключати додаткові EBS
  • при використанні Kubernetes job з Fargate важливо видаляти ці джоби після завершення їхньої роботи навіть якщо Failed, інакше вони продовжуватимуть використовувати Fargate ноди, а ви продовжите платити
  • максимум 16 vCPU та 120 GB RAM (див. AWS Fargate increases compute and memory resource configurations by 4x)
  • у AWS ECS наче вже є можливість використовувати Fargate Spot instances, але у EKS такого поки нема (але є GitHub issue з таким реквестом)

Див. всі у AWS Fargate considerations.

Створення EKS кластеру

Тут все будемо “клікопсити”, якось іншим разом розгорнемо EKS за допомогою Terraform або AWS CDK.

EKS cluster IAM role

Спершу, нам потрібна AIM роль, через яку майбутній кластер буде спілкуватись з сервісами Амазону, див. Amazon EKS cluster IAM role.

Переходимо в АІМ, клікаємо Create role, у Trusted entity type залишаємо AWS service, у Use case зі списку вибираємо EKS – Cluster:

На сторінці Add permissions лишаємо за-замовченням, та натискаємо Next:

Далі, задаємо ім’я ролі, і тиснемо Create Role:

Створення VPC та Subnets

Боже, сто років не створював їх… Тим більш вручну.

Окей, що нам треба:

  • VPC
  • її розбити на кілька сабнетів в різних AvailabilityZones
    • частина – публічні, з Internet Gateway – для всяких AWS LoadBalancer
    • частина – приватні, тут будуть жити поди Куберу, для них створимо NAT Gateway
  • і ще там щось було з SecurityGroups

Поїхали.

І – оп… Приїхали) Інтерфейс створення VPC переробили прям круто…

Переходимо до VPC, створюємо нову мережу, вибираємо VPC and more – мені просто цікаво, як воно, і виглядає воно прям реально зручно – все створюємо відразу, а не півгодини клікаємо по VPC dashboard, а потім думаємо де ми накосячили в route tables.

Тож створюємо VPC з сабнетами в кожній Availability Zone, створюємо публічні сабнети з Internet Gateway, та приватні с NAT Gateway у кожній Availability Zone (дороже, але надійніше, якщо таке робити для Продакшену). Заодно додамо VPC S3 endpoints – зараз він не потрібен, але взагалі дуже корисна штука в плані security та cost-effective:

Внизу перевіряємо, що DNS hostnames та DNS resolution включені – це вимога для роботи Fargate (описано у тому ж AWS Fargate considerations, якщо ви його пропустили):

Клікаємо Create.

Чорт – реально круто зробили!

Чекаємо створення ресурсів:

Створення EKS cluster

Переходимо до Elastic Kubernetes Service, клікаємо Add cluster > Create:

Задаємо ім’я кластеру, вибираємо створену роль, та клікаємо Next (Secrets encryption – щось новеньке, треба якось потестити):

Далі, вибираємо нашу VPS – сабнети підтянуться самі, нижче вибирамо SecurityGroup, наразі можна дефолтну з нашой VPC:

Далі, налаштовуємо доступ до нашого кластеру.

AWS Fargate Pod зависає у статусі Pending

Трохи забігаючи наперед – про можливу проблему. Після налаштування начебто всього – тестовий под завис у стаутсі Pedning з такими повідомленнями:

[simterm]

$ kubectl describe pod nginx
Name:                 nginx
Namespace:            default
...
Labels:               eks.amazonaws.com/fargate-profile=fargate-test-eu-central-1-profile
...
Status:               Pending
...
  Warning  LoggingDisabled   11m    fargate-scheduler  Disabled logging because aws-logging configmap was not found. configmap "aws-logging" not found
  Warning  FailedScheduling  8m48s  fargate-scheduler  Pod provisioning timed out (will retry) for pod: default/nginx

[/simterm]

Я вже все перебрав і перегуглив – Fargate profiles, SecurityGroup EKS, NAT Gateways у subnets – всюди все вірно. WTF?

Виявилось, що коли в цьому пості трохи нижче написав:

Вазагалі, звісно бажано відключати публічний доступ до АПІ, і ходити через приватний ендпоінт, наприклад через ВПН. Але зараз залимо обидва варвіанти – і публічний, і приватний, тіль задамо ліміт на ІП.

То побіг далі, і не переключив доступ до кластеру з дефолтного значення Public на Public and private, що й призвело до проблеми.

І це сказано у перших строках документації, і я навіть цитував це, коли описував процес:

Without the private endpoint enabled, the CIDR blocks that you specify for public access must include the outbound sources from your VPC.

Але я тупо пропустив переключити опцію, і півгодини намагався зрозуміти в чьому проблема.

Окей, йдемо далі – на цей раз вже правильно.

Отже, взагалі, звісно бажано відключати публічний доступ до Kubernetes API, і ходити через приватний ендпоінт, наприклад через VPN. Але зараз включимо обидва варіанти – і публічний, і приватний, тільки задамо ліміт на мій домашній IP.

Знаходимо його:

[simterm]

$ curl ifconfig.me
217.***.***.253

[/simterm]

Та додаємо його у дозволені:

Далі, налаштовуємо логування. Тут теж бажано включати якщо не всі, то хоча б логи API-серверу, Audit або Authentificator, та Scheduler:

На наступному кроці, вибираємо Addons (теж наче не було такого раніше), тут ще й GuardDuty з’явився:

На наступній сторінці не бачу, що можна було б міняти – лишаємо, клікаємо Next:

І нарешті останнє – ревью, та створюємо кластер:

Чекаємо. Раніше це займало хвилин 15-20, але були новини, що Амазон пришвидшив процесс.

Налаштування kubectl

Для перевірки того, що з кластером все гаразд і для подальшого тестування подів додамо його у наш ~/.kube/config.

Додаємо у конфіг:

[simterm]

$ aws --profile setevoy eks update-kubeconfig --name fargate-test-eu-central-1-cluster --alias setevoy-fargate-test-eu-central-1-cluster
Added new context setevoy-fargate-test-eu-central-1-cluster to /home/setevoy/.kube/config

[/simterm]

Перевіряємо:

[simterm]

$ kk get pod --all-namespaces
NAMESPACE     NAME                      READY   STATUS    RESTARTS   AGE
kube-system   coredns-cbbbbb9cb-2hhx2   0/1     Pending   0          18h
kube-system   coredns-cbbbbb9cb-4xf2w   0/1     Pending   0          18h

[/simterm]

Поки що маємо тільки два поди с CoreDNS, зараз у Pending, бо намає ані Woker Nodes, ані Fargate profile.

Переходимо до Fargate.

Підключення AWS Fargate

Тепер, як маємо EKS кластер, настав час підключати Fargate.

Див. документацію у Getting started with AWS Fargate using Amazon EKS, і перше, на шо звертаємо увагу – це Security Groups на Worker Nodes:

If you restrict access to the public endpoint of your cluster using CIDR blocks, we recommend that you also enable private endpoint access. This way, Fargate pods can communicate with the cluster. Without the private endpoint enabled, the CIDR blocks that you specify for public access must include the outbound sources from your VPC.

В нашому випадку ніяких Node Groups нема, тож продовжуємо.

EKS pod execution IAM Role

Спочатку нам треба додати АІМ роль, яка дозволить подам у Fargate комунікувати з Амазоном, див. Amazon EKS pod execution IAM role (обожнюю документацію Амазону).

Переходимо в AIM > Roles > Create role.

На цей раз вибираємо EKS – Fragate pod:

Далі – Next, на сторінці Add permissions лишаємо, як є (можна подивитись самі пермішени), переходимо далі, задаємо ім’я і натискаємо Create role:

Після створення знаходимо роль, переходимо до вкладки Trust relationships, редагуємо роль:

Прописуємо нову політику доступу до цієї ролі:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Condition": {
         "ArnLike": {
            "aws:SourceArn": "arn:aws:eks:eu-central-1:26***286:fargateprofile/fargate-test-eu-central-1-cluster/*"
         }
      },
      "Principal": {
        "Service": "eks-fargate-pods.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Натискаємо Update policy, та переходимо до створення Fargate profile.

Створення Fargate profile

Fargate профіль описує, які саме поди з Kubernetes-кластру будут запускатись у Fargate, див. AWS Fargate profile.

Для створення, переходимо до EKS, потім до нашого кластеру, на вкладці Compute знизу знаходимо Add Fargate profile:

Задаємо ім’я, АІМ роль підставилась автоматично, як і приватні сабнету нашої VPC:

У Pod selectors описується які поди з яких неймспейсів будуть запускатись з цим Fargate профілем.

Зараз для тесту нехай будуть всі, але в цілому можна створювати різні профайли для різних типів подів з виборкою по неймспейсам та/або лейблам, які додані подам:

Далі, перевіряємо, що все вірно, та створюємо профайл:

Створення зайняло хвилин 5.

Запуск Kubernetes-подів у Fargate

Отже, поки що маємо тільки два поди з CoreDNS, які знаходяться у статусі Pending.

Щоб CoreDNS поди запустились у Fargate – редагуємо їхній Deployment, та прибираємо аннотацію eks.amazonaws.com/compute-type: ec2:

 

За хвилину-дві перевіряємо:

[simterm]

$ kubectl -n kube-system get pod
NAME                       READY   STATUS    RESTARTS   AGE
coredns-75694977b5-m7smc   0/1     Pending   0          5m48s
coredns-75694977b5-tgwdl   1/1     Running   0          50s

[/simterm]

Перший пішов.

І після запуску перших подів на вкладці Compute нашого кластеру маємо побачити Fargate-ноди у EKS-кластері:

Поки стартує другий под з CoreDNS – додамо звичайний тестовий под, щоб ще раз побачити як воно працює:

[simterm]

$ kubectl run nginx --image=nginx
pod/nginx created

[/simterm]

І за пару хвилин перевіряємо поди:

[simterm]

$ kubectl get pod --all-namespaces
NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
default       nginx                      1/1     Running   0          2m27s
kube-system   coredns-75694977b5-r8d6b   1/1     Running   0          46s
kube-system   coredns-75694977b5-tgwdl   1/1     Running   0          5m52s

[/simterm]

Та Fargate-ноди:

Щодо івенту “Disabled logging because aws-logging configmap was not found” – можно окремо налаштувати логгінг, див. Fargate logging, на запуск подів не впливає.

Ще з цікавого, що добре знати, це те, що IAM-роль для наших подів додається до aws-auth ConfigMap кластеру:

[simterm]

$ kk -n kube-system get cm aws-auth -o yaml
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      - system:node-proxier
      rolearn: arn:aws:iam::264***286:role/AmazonEKSFargatePodExecutionRole-fargate-test-eu-central-1
      username: system:node:{{SessionName}}

[/simterm]

Так начебто все.

Можна пробувати користуватись замість звичайних EC2.

Посилання по темі

Loading

Kubernetes: вертикальний скейлінг подів з Vertical Pod Autoscaler
0 (0)

29 Квітня 2023

Окрім Horizontal Pod Autoscaler (HPA), який створює додаткові поди якщо наявні починають використовувати більше CPU/Memory, ніж налаштовано у лімітах HPA, існує і Vertical Pod Autoscaler (VPA), який працює за іншою схемою: замість горизонтального масштабування, тобто збільшення кількості подів, він змінює resources.requests поду, що призводить до того, что Kubernetes Scheduler “переселяє” цей под на іншу WorkerNode, якщо на поточній не вистачає ресурсів.

Тобто, VPA постійно моніторить споживання ресурсів контейнерами у подах, і змінює значення відповідно до актуального споживання ресурсів, і може як збільшувати значення реквестів, так і зменшувати його, таким чином автоматично налаштовуючи потреби пода, щоб уникнути нераціонального використання ресурсів інстансів Kubernetes-кластеру та забезпечити сам под достатнім CPU time і пам’ятю.

Компоненти Vertical Pod Autoscaler

Після деплою VPA, він створює три поди для своєї роботи:

  • recommender: займається моніторингом використання ресурсів подами, і видає свої рекомендації по значенню cpu/mem requests, які треба встановити подам
  • updater: моніторить поди та їхні поточні значення cpu/mem requests, і якщо ці значення не збігаються зі значеннями від recommender – то “вбиває” їх (EvictedByVPA Kubernetes event), щоб контролери Kubernetes перестворили їх з потрібними значеннями
  • admission-plugin: займається власне тим, що встановлює значення реквестів для нових подів, або тих, що були перестворенні після того, як updater кільнув їх

Обмеження Vertical Pod Autoscaler

При використанні VPA, майте на увазі, що:

  • VPA не відслідковує процесс перестворення подів, тобто після того, як под був evicted – то його створення вже цілком залежить від Kubernetes. Якщо у кластері на момент перестворення подів не буде вільних WorkerNodes, то под може залишитиcь у Pending статусі, тому бажано мати Cluster Autoscaler або Karpenter, який запустить новую ноду
  • VPA не може використовуватись одночасно з HPA, якщо скейлінг налаштовано на CPU/Memory, але їх можна використовувати, якщо HPA налаштований на custom metrics
  • також майте на увазі сам факт того, що при роботі VPA перестворює поди, тобто якщо у вас немає якогось fault-tolerant у вигляді додаткових подів, які зможуть взяти на себе навантаження на час перестворення поду – то сервіс буде недоступний, допоки відповідний контроллер (ReplicaSet, StatefulSet, etc) не запустить новий інстанс поду

Див більше у Known limitations.

Запуск Vertical Pod Autoscaler

При роботі, VPA покладається на Kubernetes Metrics Server для отримання значень CPU/Mem подів, але також може використовувати Prometheus, див. How can I use Prometheus as a history provider for the VPA recommender.

Встановлення Metrics Server

Оскільки тестити VPA будемо у Minikube, то встановимо плагін Metrics Server:

[simterm]

$ minikube addons enable metrics-server

[/simterm]

Або у разі звичайного Kubernetes-кластеру – з Helm-чарту:

[simterm]

$ helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
$ helm -n kube-system upgrade --install metrics-server metrics-server/metrics-server

[/simterm]

І дивимось, чи працює kubectl top pod, який бере дані саме з Metrics Server:

[simterm]

$ kubectl top pod --all-namespaces
NAMESPACE     NAME                               CPU(cores)   MEMORY(bytes)   
kube-system   etcd-minikube                      83m          33Mi            
kube-system   kube-apiserver-minikube            249m         254Mi           
kube-system   kube-controller-manager-minikube   54m          45Mi            
kube-system   kube-scheduler-minikube            26m          22Mi

[/simterm]

Встановлення Vertical Pod Autoscaler

Також використовуємо Helm-чарт – cowboysysop/vertical-pod-autoscaler:

[simterm]

$ helm repo add cowboysysop https://cowboysysop.github.io/charts/
$ helm -n kube-system upgrade -install vertical-pod-autoscaler cowboysysop/vertical-pod-autoscaler

[/simterm]

Перевіряємо поди:

[simterm]

$ kk -n kube-system get pod -l app.kubernetes.io/name=vertical-pod-autoscaler
NAME                                                            READY   STATUS    RESTARTS   AGE
vertical-pod-autoscaler-admission-controller-655f9b57d7-q85kc   1/1     Running   0          58s
vertical-pod-autoscaler-recommender-7d964f7894-k87hb            1/1     Running   0          58s
vertical-pod-autoscaler-updater-7ff97c4d85-vfjkj                1/1     Running   0          58s

[/simterm]

Та його CustomResourceDefinitions:

[simterm]

$ kk get crd
NAME                                                  CREATED AT
verticalpodautoscalercheckpoints.autoscaling.k8s.io   2023-04-27T08:38:16Z
verticalpodautoscalers.autoscaling.k8s.io             2023-04-27T08:38:16Z

[/simterm]

Тепер все готове, щоб починати ним користуватись.

Приклади роботи з Vertical Pod Autoscaler

В репозиторії VPA є директорія examples, яка містить приклади маніфестів, наприклад у файлі hamster.yaml є приклад налаштованого VPA та тестового Deployment.

Але давайте створимо свої маніфести, та задеплоїмо ресурси окремо.

Спочатку Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hamster
spec:
  selector:
    matchLabels:
      app: hamster
  replicas: 2
  template:
    metadata:
      labels:
        app: hamster
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534 # nobody
      containers:
        - name: hamster
          image: registry.k8s.io/ubuntu-slim:0.1
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
          command: ["/bin/sh"]
          args:
            - "-c"
            - "while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done"

Тут маємо створити два поди, яким задаємо requests у 100 Milicpu та 50 Megabyte memory.

Деплоймо:

[simterm]

$ kubectl apply -f hamster-deployment.yaml 
deployment.apps/hamster created

[/simterm]

За хвилину-дві перевіряємо ресурси, які реально споживаються подами:

[simterm]

$ kk top pod
NAME                       CPU(cores)   MEMORY(bytes)   
hamster-65cd4dd797-fq9lq   498m         0Mi             
hamster-65cd4dd797-lnpks   499m         0Mi

[/simterm]

Тепер додамо VPA:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  # recommenders field can be unset when using the default recommender.
  # When using an alternative recommender, the alternative recommender's name
  # can be specified as the following in a list.
  # recommenders: 
  #   - name: 'alternative'
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        minAllowed:
          cpu: 100m
          memory: 50Mi
        maxAllowed:
          cpu: 1
          memory: 500Mi
        controlledResources: ["cpu", "memory"]

Деплоїмо:

[simterm]

$ kubectl apply -f hamster-vpa.yaml 
verticalpodautoscaler.autoscaling.k8s.io/hamster-vpa created

[/simterm]

Перевіряємо сам VPA:

[simterm]

$ kk get vpa
NAME          MODE   CPU   MEM   PROVIDED   AGE
hamster-vpa   Auto                          14s

[/simterm]

І за хвилину-дві, коли спрацює recommender:

[simterm]

$ kk get vpa
NAME          MODE   CPU    MEM       PROVIDED   AGE
hamster-vpa   Auto   587m   262144k   True       43s

[/simterm]

І ще за хвилину – перевіряємо поди, коли спрацює Updater:

[simterm]

$ kk get pod
NAME                       READY   STATUS        RESTARTS   AGE
hamster-65cd4dd797-fq9lq   1/1     Terminating   0          3m43s
hamster-65cd4dd797-hc9cn   1/1     Running       0          13s
hamster-65cd4dd797-lnpks   1/1     Running       0          3m43s

[/simterm]

Та перевіряємо значення requests нового поду:

[simterm]

$ kubectl get pod hamster-65cd4dd797-hc9cn -o yaml | yq '.spec.containers[].resources'
{
  "requests": {
    "cpu": "587m",
    "memory": "262144k"
  }
}

[/simterm]

Тепер, як ми побачили VPA в дії, давайте трохи розберемось з його API та доступними параметрами.

Vertical Pod Autoscaler API reference та параметри

Повний опис див. у API reference, а зараз просто зробимо describe нашого існуючого VPA, щоб зрозуміти, що там взагалі є:

[simterm]

$ kubectl describe vpa/hamster-vpa
Name:         hamster-vpa
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  autoscaling.k8s.io/v1
Kind:         VerticalPodAutoscaler
Metadata:
  Creation Timestamp:  2023-04-27T09:05:41Z
  Generation:          61
  Resource Version:    7016
  UID:                 227c0ce6-7f86-4bff-b9b5-d88914f90bec
Spec:
  Resource Policy:
    Container Policies:
      Container Name:  *
      Controlled Resources:
        cpu
        memory
      Max Allowed:
        Cpu:     1
        Memory:  500Mi
      Min Allowed:
        Cpu:     100m
        Memory:  50Mi
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         hamster
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2023-04-27T09:06:11Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     569m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  262144k
Events:          <none>

[/simterm]

Або у “чистому” yaml:

[simterm]

$ kubectl get vpa/hamster-vpa -o yaml           
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
...
spec:
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      controlledResources:
      - cpu
      - memory
      maxAllowed:
        cpu: 1
        memory: 500Mi
      minAllowed:
        cpu: 100m
        memory: 50Mi
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hamster
  updatePolicy:
    updateMode: Auto
status:
  ...
  recommendation:
    containerRecommendations:
    - containerName: hamster
      lowerBound:
        cpu: 570m
        memory: 262144k
      target:
        cpu: 587m
        memory: 262144k
      uncappedTarget:
        cpu: 587m
        memory: 262144k
      upperBound:
        cpu: "1"
        memory: 262144k

[/simterm]

І тепер розлянемо параметри з нашого VPA та інші, которі можуть бути нам корисні в майбутньому:

  • spec (VerticalPodAutoscalerSpec):
    • targetRef: тип контролеру, який відповідає за поди, которі будуть скейлитись цим VPA
    • updatePolicy (PodUpdatePolicy): задає, чи будуть рекомендації застосовані при створенні поду, і чи будуть застосовуватись протягом його роботи
      • updateMode: може мати значення “Off“, “Initial“, “Recreate” та “Auto” (дефолтне значення):
        • Off: не буде застосовувати нові значення, а тільки внесе їх у поле status (див. нижче)
        • Initial: застосує значення тільки при створенні поду
        • Recreate: застосує значення при створенні поду і під час його роботи
        • Auto: на цей час виконує теж саме, що Recreate (хоча ще чотири роки тому наче казали, що планується при “Auto” міняти реквести без рестарту)
      • minReplicas: мінімальна кількість подів, які мають бути в статусі Running, щоб VPA Updater виконав Pod Eviction для застосування нових значень у requests
    • resourcePolicy (PodResourcePolicy): задає параметри того, як CPU та Memory requests будуть налаштовуватись для конкретних контейнерів, якщо не задано – то VPA застосує нові значення для всіх контейнерів в поді
      • containerPolicies (ContainerResourcePolicy): налаштування для конкретних контейнерів, або для всіх, які не мають власних параметрів, за допомогою containerName = '*'
        • containerName: ім’я контейнеру, для якого описуються параметри
        • mode: задає, чи будуть рекомендації застосовані при створенні контейнеру, і чи будуть застосовуватись протягом його роботи, може мати значення “Off” або “Auto” (дефолтне значення)
        • minAllowed та maxAllowed: задає мінімальні та максимальні значення для CPU/Memory requests
        • ControlledResources: для яких саме ресурсів застосовувати рекомендації – ResourceCPU, ResourceMemory, або обидва (дефолтне, якщо не вказано жодного)
  • status (VerticalPodAutoscalerStatus): останні рекуомендації від Recommender
    • recommendation (RecommendedPodResources): останні рекомендовані значення CPU/Memory
      • containerRecommendations (RecommendedContainerResources): рекомендації для кожного контейнеру
        • containerName: ім’я контейнеру
        • target: рекомендовані значення для контейнеру
        • lowerBound: мінімально рекомендовані значення для контейнеру
        • upperBound: максимально рекомендовані значення для контейнеру
        • uncappedTarget: останні рекомендовані значення CPU/Memory на основі реального споживання ресурсів без врахування ContainerResourcePolicy (тобто без minAllowed та maxAllowed), не враховується Recommender, відображається тільки для інформації

На цьому поки все.

З VPA бувають проблеми, але в цілому у нас в продакшені працють без нарікань, наприклад – міняються значення для подів Prometheus-серверу.

Loading

Prometheus: запуск Pushgateway у Kubernetes з Helm та Terraform
0 (0)

28 Квітня 2023

Маємо на проекті багато AWS Lambda функцій, з яких девелопери хочуть мати можливість відправляти метрики до нашого Prometheus, щоб додати власних алертів та графіків у Grafana.

Для цього у функціях використовується бібліотека Prometheus, яка дозволяє ці метрики створювати (див. Prometheus: створення Custom Prometheus Exporter на Python), але ж ми не маємо змоги нормально отримати ці дані з Prometheus, бо функції можуть жити декілька секунд, а Prometheus використовує PULL-модель, тобто він сам ходить до експортерів, та витягує звідти дані.

Що можемо зробити у випадку AWS Lambda – це додати Prometheus Pushgateway, який буде мати зовнішній ендпоінт, на який функції будуть слати свої метрики, а Prometheus буде забирати ці дані з Pushgateway, який виконує таку собі “проксі роль”.

Загальна схема роботи Prometheus та роль Pushgateway добре відображена на цій схемі:

Тож сьогодні запустимо Prometheus Pushgateway у Kubernetes використовуючи Helm-чарт, а чарт будемо встановлювати за допомогою Terraform.

Pushgateway Helm chart

Спочатку, давайте подивимося, що у нас є у values чарту Pushgateway.

По факту, наразі нам тут можуть бути цікавими тільки два параметри – це Ingress та ServiceMonitor.

Напишемо свій values, для тесту задеплоїмо на Dev оточення, а потім додамо до Terraform, через який Pushgateway вже буде деплоїтися по всіх наших моніторинг-оточеннях:

ingress:
  enabled: true
  className: alb
  path: /
  pathType: Prefix
  annotations:
    alb.ingress.kubernetes.io/scheme: internal
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:638***021:certificate/e97f17e9-33f9-46e7-9b2b-d50de8a72219
    alb.ingress.kubernetes.io/target-type: ip
  hosts:
    - test-pushgateway.monitoring.dev.example.com

serviceMonitor:
  enabled: true
  namespace: monitoring
  additionalLabels:
    release: prometheus

Тут описуємо створення Kubernetes Ingress, якому на порт 443 відповідного AWS Application Load Balancer підключимо SSL сертифікат з Amazon Certificate Manager. В hosts задаємо ім’я хоста, яке за допомогою ExternalDNS буде створено в AWS Route53.

І додаємо ServiceMonitor з лейблою release: prometheus, щоб Prometheus із Kube Prometheus Stack його побачив.

Додаємо репозиторій Prometheus:

[simterm]

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm repo update

[/simterm]

І встановлюємо Pushgateway до неймспейсу monitoring:

[simterm]

$ helm -n monitoring upgrade --install prometheus-pushgateway-test prometheus-community/prometheus-pushgateway -f pushgateway-values-dev.yaml 
...
NOTES:
1. Get the application URL by running these commands:
  http://test-pushgateway.monitoring.example.com/

[/simterm]

Перевіряємо Pod та Ingress:

[simterm]

$ kubectl get pod,ingress --namespace monitoring -l app.kubernetes.io/instance=prometheus-pushgateway-test
NAME                                               READY   STATUS    RESTARTS   AGE
pod/prometheus-pushgateway-test-6b5dfbdd7f-chzkf   1/1     Running   0          53s

NAME                                                    CLASS   HOSTS                                         ADDRESS                                                              PORTS   AGE
ingress.networking.k8s.io/prometheus-pushgateway-test   alb     test-pushgateway.monitoring.dev.example.com   internal-k8s-monitori-promethe-***-***.us-west-2.elb.amazonaws.com   80      54s

[/simterm]

Pushgateway має власний веб-інтерфейс – відкриваємо доступ до його поду на порт 9091:

[simterm]

$ kubectl -n monitoring port-forward pod/prometheus-pushgateway-test-6b5dfbdd7f-chzkf 9091
Forwarding from 127.0.0.1:9091 -> 9091
Forwarding from [::1]:9091 -> 9091

[/simterm]

Та в браузері переходимо на http://localhost:9091:

Далі, перевіримо чи бачить сам Prometheus цей Pushgateway – відкриваємо порт 9090 до Prometheus Pod:

[simterm]

$ kk -n monitoring port-forward prometheus-prometheus-kube-prometheus-prometheus-0 9090
Forwarding from 127.0.0.1:9090 -> 9090
Forwarding from [::1]:9090 -> 9090

[/simterm]

Та переходимо до Status > Targets, і шукаємо Pushgateway target:

І перевіримо, чи потраплять метрики з Pushgateway до Prometheus.

Оскільки наш Ingress/ALB має тип internal, тобто недоступний ззовні, то запустимо Kubernetes Pod з Ubuntu в Kubernetes-кластері:

[simterm]

$ kubectl run pod --rm -i --tty --image ubuntu -- bash
If you don't see a command prompt, try pressing enter.
root@pod:/#

[/simterm]

Встановлюємо в ньому curl:

[simterm]

root@pod:/# apt update && apt -y install curl

[/simterm]

Та користуючись документацією відправимо запит, тільки порт не вказуємо, бо у нас він 443, SSL:

[simterm]

root@pod:/# echo "some_metric 3.14" | curl --data-binary @- https://test-pushgateway.monitoring.dev.exmaple.com/metrics/job/some_job

[/simterm]

Перевіряємо в Pushgateway:

Та у Prometheus:

Є, чудово.

Аутентифікація Pushgateway

Оскільки у нас Pushgateway працює на internal-ALB, то я не став поки робити аутентифікацію, бо він це все ще в процесі тестування, і поки невідомо як воно там зайде девелоперам.

Але у values є блок, з прикладом запуску контейнера з openshift/oauth-proxy, а у Using OpenShift OAuth Proxy to secure your Applications on OpenShift наче непогано описано приклад його використання – якось можна буде спробувати.

Terraform та Helm для Pushgateway

“Так в проекті повелося” (с), що більша частина ресурсів у Kubernetes деплоїться за допомогою Terraform та його helm_release resource.

У нас багато аккаунтів AWS, і в кожному буде свій ARN сертифікату, тож отримаємо його за допомогою Data Source (або можна створити власний за допомогою aws_acm_certificate):

data "aws_acm_certificate" "wildcard" {
  domain = "*.${var.root_domain}"
}

Змінна root_domain у нас передається з основного модулю, та має вигляд monitoring.dev.example.com.

Для нашого values створюємо темплейт pushgateway-values.tpl.yaml:

ingress:
  enabled: true
  className: alb 
  path: /
  pathType: Prefix 
  annotations:
    alb.ingress.kubernetes.io/scheme: internal
    alb.ingress.kubernetes.io/certificate-arn: ${acmWildcardArn}
    alb.ingress.kubernetes.io/target-type: ip
  hosts: 
    - ${pushgatewayUrl}
  
serviceMonitor:
  enabled: true
  namespace: monitoring
  additionalLabels:
    release: prometheus

І додаємо сам helm_release, в якому у values[] задаємо файл темплейту та пару змінних – ARN сертифікату, який отримали за допомогою data.aws_acm_certificate, та домен для Ingress hosts:

resource "helm_release" "pushgateway" {
  name = "prometheus-pushgateway"

  namespace = kubernetes_namespace.monitoring.id

  repository  = "https://prometheus-community.github.io/helm-charts"
  chart       = "prometheus-pushgateway"
  version     = "2.1.3"
  max_history = 10

  values = [
    templatefile("${path.module}/configs/prometheus/pushgateway-values.tpl.yaml", {
      acmWildcardArn : data.aws_acm_certificate.wildcard.arn,
      pushgatewayUrl : "pushgateway.${var.root_domain}"
    })
  ]
}

Деплоїмо:

[simterm]

$ terraform apply
...
module.monitoring.helm_release.pushgateway: Creating...
module.monitoring.helm_release.pushgateway: Still creating... [10s elapsed]
module.monitoring.helm_release.pushgateway: Still creating... [20s elapsed]
module.monitoring.helm_release.pushgateway: Still creating... [30s elapsed]
module.monitoring.helm_release.pushgateway: Creation complete after 32s [id=prometheus-pushgateway]
...
Apply complete! Resources: 1 added, 1 changed, 0 destroyed.

[/simterm]

Перевіряємо Ingress та Pod:

[simterm]

$ kk -n monitoring get ingress,pod -l app.kubernetes.io/instance=prometheus-pushgateway
NAME                                               CLASS   HOSTS                                    ADDRESS                                                              PORTS   AGE
ingress.networking.k8s.io/prometheus-pushgateway   alb     pushgateway.monitoring.dev.example.com   internal-k8s-monitori-promethe-***-***.us-west-2.elb.amazonaws.com   80      10m

NAME                                          READY   STATUS    RESTARTS   AGE
pod/prometheus-pushgateway-55b9f5ffd6-sm9ck   1/1     Running   0          10m

[/simterm]

Все є.

Готово.

Loading