Продовжимо про AWS CDK та Python. Пишу не тому, що подобається, а тому, що в інтернеті прикладів ну якось зовсім мало, тож нехай будуть хоча б тут.
Отже, маємо кластер, маємо пару контролерів. Наче все готово – почав встановлювати чарт VictoriaMetrics, і все завелося окрім поду з VMSingle, який завис в статусі Pending.
Зміст
“VolumeBinding”: binding volumes: timed out waiting for the condition
Перевіряємо Events цього поду:
[simterm]
... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 10m default-scheduler running PreBind plugin "VolumeBinding": binding volumes: timed out waiting for the condition
[/simterm]
Швидкий гуглінг привів до питання на StackOverflow, де я і згадав про EKS Add-ons, в саме – про EBS CSI дайвер, який має створювати EBS при появі PersistentVolumeClaim.
Тож сьогодні глянемо, як з AWS CDK додати аддони до кластеру.
Тут, в принципі, все досить просто, єдине що довелося погуглити як жеж саме використовувати CfnAddon
, але цього разу документація знайшлась швидко, і навіть з прикладами на Python, а не TypeScript.
IAM Role для EBS CSI driver
OIDC Provider вже маємо, див. AWS: EKS, OpenID Connect та ServiceAccounts.
Для драйверу теж використовуємо IRSA – описуємо ServiceAccount, політику беремо вже готову – AWS Managed Policy, підключаємо через виклик iam.ManagedPolicy.from_aws_managed_policy_name()
:
... # Create an IAM Role to be assumed by ExternalDNS ebs_csi_addon_role = iam.Role( self, 'EbsCsiAddonRole', # for Role's Trust relationships assumed_by=iam.FederatedPrincipal( federated=oidc_provider_arn, conditions={ 'StringEquals': { f'{oidc_provider_url.replace("https://", "")}:sub': 'system:serviceaccount:kube-system:ebs-csi-controller-sa' } }, assume_role_action='sts:AssumeRoleWithWebIdentity' ) ) ebs_csi_addon_role.add_managed_policy(iam.ManagedPolicy.from_aws_managed_policy_name("service-role/AmazonEBSCSIDriverPolicy")) ...
У from_aws_managed_policy_name
вказуємо ім’я як “service-role/ManagedPolicyName“.
CfnAddon
для EBS CSI driver
Знаходимо актувальну версію дайверу, вказавши версію кластеру – у нас 1.26, бо CDK досі не підтримує 1.27:
[simterm]
$ aws eks describe-addon-versions --addon-name aws-ebs-csi-driver --kubernetes-version 1.26 --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" --output text v1.20.0-eksbuild.1 True ...
[/simterm]
І описуємо підключення самого аддону з CfnAddon
– вказуємо ім’я кластеру, версію та ServiceAccount IAM Role ARN:
... # Add EBS CSI add-on ebs_csi_addon = eks.CfnAddon( self, "EbsCsiAddonSa", addon_name="aws-ebs-csi-driver", cluster_name=cluster_name, resolve_conflicts="OVERWRITE", addon_version="v1.20.0-eksbuild.1", service_account_role_arn=ebs_csi_addon_role.role_arn ) ...
Деплоїмо, перевіряємо:
Перевіряємо поди:
[simterm]
$ kk -n kube-system get pod | grep csi ebs-csi-controller-896d87c6b-7rv9z 6/6 Running 0 9m59s ebs-csi-controller-896d87c6b-v7xg7 6/6 Running 0 9m59s ebs-csi-node-2zwnr 3/3 Running 0 9m59s ebs-csi-node-pt5zs 3/3 Running 0 9m59s
[/simterm]
І тепер маємо PVC для VictoriaMetrcis в статусі Bound:
[simterm]
$ kk -n dev-monitoring-ns get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE vmsingle-victoria-metrics-k8s-stack Bound pvc-151a631b-f6de-4567-8baa-97adb4e04a87 20Gi RWO gp2 91m
[/simterm]
І сам под з VMSingle запустився:
[simterm]
$ kk -n dev-monitoring-ns get po | grep vmsingle vmsingle-victoria-metrics-k8s-stack-f7794d779-n6sc7 1/1 Running 0 28m
[/simterm]
Готово.