Service: AWS CloudFormation
Region: 🇺🇸US East (N. Virginia)
URL: http://status.aws.amazon.com/#cloudformation-us-east-1_1614881883

We are beginning to observe recovery for the increased error rates accessing the CloudFormation Management Console in the US-EAST-1 Region. CloudFormation APIs continue to be unaffected by this issue.

#cloudformation #useast1

Запись митапа https://www.youtube.com/watch?v=7ak4uLIfMh0 (ссылки на модули и слайды в описании видео на youtube)

Service: AWS CloudFormation
Region: 🇺🇸US East (N. Virginia)
URL: http://status.aws.amazon.com/#cloudformation-us-east-1_1614883234

Between 9:14 AM and 9:52 AM PST we experienced increased error rates accessing the CloudFormation Management Console in the US-EAST-1 Region. CloudFormation APIs were unaffected by this issue and were still able to be accessed via the CLI or SDK during this event. The issue has been resolved and the service is operating normally.

#cloudformation #useast1

Привет, через что управляются публичные адреса EKS кластера?

Запустил первые поды, локальные работают а другие не могут синхронизироваться со своим облаком. SG все разрешил, ACL проверил. В kube-dns {{ External-ip   <none> }}

Это мне вопрос?

Эти публичные адреса для API server endpoint'ов выдаются самим сервисом EKS.

но ведь если поду из кластера надо обращаться в сеть, у него тоже будет свой адрес, отличный от адреса для API?

адрес ноды я скорее имею ввиду

Насколько я понимаю, их выдает автоматически EKS

тогда почему под не может связаться с облаком? Может есть чарт проверить доступ наружу?

причем сервисы запущены и имеют свой адрес, а вот соответствующие поды не зажигаются

У подов и у API сервера IP адреса из одной и той же подсети, судя по nslookup

Доступ наружу есть. Публичные разные сайты (google, cloudflare и тд) доступны

ребята помогите жопа сгорает

не могу достучаться из кода к AWS эластику

вот примерный отладочный код из документашки AWS. IAM прописана как на домене так и на пользователе

acceess policy на домене

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Sid": "",
     "Effect": "Allow",
     "Principal": {
       "AWS": "arn:aws:iam::xxx:user/es-xx-shared-xx-user"
     },
     "Action": "*",
     "Resource": [
       "arn:aws:es:x-x-2:xx:domain/es-xx-shared",
       "arn:aws:es:x-x-2:xx:domain/es-xx-shared/*"
     ]
   }
 ]
}

уже вкатил политику на юзера

{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Sid": "VisualEditor0",
           "Effect": "Allow",
           "Action": [
               "es:DescribeReservedElasticsearchInstanceOfferings",
               "es:ListElasticsearchInstanceTypeDetails",
               "es:CreateElasticsearchServiceRole",
               "es:RejectInboundCrossClusterSearchConnection",
               "es:PurchaseReservedElasticsearchInstanceOffering",
               "es:DeleteElasticsearchServiceRole",
               "es:AcceptInboundCrossClusterSearchConnection",
               "es:DescribeInboundCrossClusterSearchConnections",
               "es:DescribeReservedElasticsearchInstances",
               "es:ListDomainNames",
               "es:DeleteInboundCrossClusterSearchConnection",
               "es:ListElasticsearchInstanceTypes",
               "es:DescribeOutboundCrossClusterSearchConnections",
               "es:ListElasticsearchVersions",
               "es:DescribeElasticsearchInstanceTypeLimits",
               "es:DeleteOutboundCrossClusterSearchConnection"
           ],
           "Resource": "*"
       },
       {
           "Sid": "VisualEditor1",
           "Effect": "Allow",
           "Action": "es:*",
           "Resource": "arn:aws:es:us-xx-2:xxx:domain/es-xx-shared"
       }
   ]
}

а в питоне все равно

AuthorizationException(403, '{"Message":"User: arn:aws:iam::xxx:user/es-xx-shared-xx-user is not authorized to perform: es:ESHttpPut"}')

проблема решилась переустановкой пода. Сам себе придумал проблем неправильно указав целевое облако в хелме