얼마전 도메인이 세개 정도 필요해서 간만에 쇼핑 좀 했다. example.com / example.net 나머지 하나는 뭘로 선택할까... 하다가 구글 검색에 자주 보이는 io 도메인으로 결정했다. 대충 뭐 IT 기술 관련 도메인으로 많이 사용하는 줄로 알고 있긴 했는데 가격이...
AWS 기준으로 닷컴이 $12 인데 io 도메인이 $71 라니... 구글이 $60 로 나오는데 그렇다 해도 .com 의 5배.
어이가 좀 없긴 했는데 궁금하기도 하여 검색을 좀 해봤다.
.io 도메인은 기술기반 스타트업들이나 블록체인 프로젝트에 많이 사용한다. 원래 영국령 인도양식민지(British Indian Ocean Territory)의 국가코드 톱 레벨 도메인으로 한국의 .kr 도메인과 같지만 .io 도메인은 국가 제한이 없는 누구나 사용이 가능할 수 있는 도메인 중 하나이다. 데이터 입출력을 뜻하는 Input/Output 으로도 해석하며 IT 기술기반 업계에서 많이 쓴다고 하는데 그냥 갖다 붙인 느낌... 어쨌든 한참을 그런 업계에서 애용하고 있다니 원한다면 .io 든 .dev 든 사면 되겠지만 가격이 왜 이 모양인지... 비싼 이유를 좀 찾아보려 했으나 해당 글도 별로 없는거 같고 찾고 싶지도 않아졌음. 보아하니 유행 살짝 타니까 돈 좀 벌어볼라고 세계적으로 가격단합 중인거 같은데... 비쌀땐 안사면 됨. 도메인은 .com 이 짱이지...ㅋ
* 요점 대부분의 메일 공급자에서는 SPF레코드가 2014년 4월에 더 이상 사용되지 않으므로 SPF 구성이 적용되지 않습니다. 자세한 내용은 Internet Engineering Task Force(IETF) 웹 사이트에서 RFC 7208을 참조하십시오. SPF 레코드 대신 적용 가능한 값이 포함된 TXT레코드를 만드는 것이 좋습니다.
해결
TXT "v=spf1 include:_spf.google.com ~all"
레코드 유형을 TXT 로 추가하여 해결...
Received-SPF: pass (kakao.com: domain of gabriel@example.com designates 123.123.123.123 as permitted sender)
하는 김에 DMARC 설정 추가하고, DKIM 은 관리자 권한 있으면 추가, 그리고 테스트 ㄱㄱ
또 하나,,, 테스트 한답시고 test1, test2, test3 이 따위로 메일 반복해서 보내면,
Delivery failed: gabriel@kakao.com 10.61.236.127 failed after I sent the message. Remote host said[Response Message]: 554 5.7.1 DAS41 209.85.210.193: Your mail is blocked automatically by anti-spam system. (E04) STEP: DATA SEND
ECR 에서 log4j2 사용중인 이미지들 깜빡하고 있었는데 AWS 에서 친절히 메일이 왔다.
You are receiving this communication because your account has container images stored in Amazon Elastic Container Registry (ECR). While not all container images are impacted by this CVE, your images may be affected if they are using Java with Apache Log4j in certain configurations. Amazon Inspector scans container images stored in Amazon ECR for software vulnerabilities to generate Package Vulnerability findings and is able to detect this issue in container images. You can turn on enhanced scanning from ECR [2] or enable Inspector from Inspector console to discover this issue in your images[3].
계정에 Amazon Elastic Container Registry(ECR)에 저장된 컨테이너 이미지가 있기 때문에 이 통신을 수신하게 되었습니다. 모든 컨테이너 이미지가 이 CVE의 영향을 받는 것은 아니지만 특정 구성에서 Apache Log4j와 함께 Java를 사용하는 경우 이미지가 영향을 받을 수 있습니다. Amazon Inspector는 Amazon ECR에 저장된 컨테이너 이미지에서 소프트웨어 취약성을 스캔하여 패키지 취약성 결과를 생성하고 컨테이너 이미지에서 이 문제를 감지할 수 있습니다. ECR[2]에서 향상된 스캔을 켜거나 Inspector 콘솔에서 Inspector를 활성화하여 이미지에서 이 문제를 발견할 수 있습니다[3].
log4j2 취약점이 추가로 계속 발생하고 있다. 2.15 에서 2.16 버전으로 업데이트...
확인하기도 귀찮다. 자꾸 신경쓰이게 하지 말고, logback 쓰고 log4j2 는 그냥 꼬죠.
EKS 에서 ingress 와 loadbalancer 를 생성했는데 pending 상태라 살펴보니 자격증명 실패 에러가 발생했다.
$ kubectl describe ingress my-ingress
Warning FailedBuildModel 32m (x9 over 47m) ingress (combined from similar events): Failed build model due to WebIdentityErr: failed to retrieve credentials
caused by: InvalidIdentityToken: Incorrect token audience
status code: 400, request id: 4599a6da-7a29-4d82-baf7-d546e7811234
확인하고 삭제하려는데 삭제가 안된다.ㅋ 강제 삭제(--force --grace-period=0)도 안된다; 시간이 한참 지나도 프롬프트가 멈춰버림.
$ kubectl describe svc my-nlb
...
Normal DeletedLoadBalancer 40m service-controller Deleted load balancer
Warning FailedDeployModel 38m service Failed deploy model due to WebIdentityErr: failed to retrieve credentials
Warning ClusterIPNotAllocated 75s (x5 over 37m) ipallocator-repair-controller Cluster IP [IPv4]:172.20.23.140 is not allocated; repairing
Warning PortNotAllocated 75s (x5 over 37m) portallocator-repair-controller Port 32083 is not allocated; repairing
권한은 없는데 복구 의지가 강해서 그런건지, 안죽고 계속 살아나려고 발버둥 치는 느낌. 다른 서비스들과 결합이 되어 있는건지... 클러스터를 거의 초기화 수준으로 다른 모든 리소스를 다 지웠는데도 삭제가 안되는 생명줄 긴 로드 밸런서들. 구글님 덕에 겨우 찾아 삭제했다.
finalizers 는 리소스를 완전히 삭제하기 전에 특정 조건이 충족될 때까지 대기하게 한다. 삭제가 완료되면 대상에서 관련 finalizers 를 삭제하는데, 위처럼 metadata.finalizers 필드를 비워주면 Kubernetes 는 삭제가 완료된 것으로 인식하게 된다.
3년만인가. 드디어 ECS 에서 EKS 로 넘어왔다. 그 때도 ECS 보다는 조금 더 핫했던 쿠버네티스를 써보고 싶었지만 아마 아시아 리전에는 없었던 것으로 기억한다. 그리하여 이래저래 문서들 보고 헤딩하며 클러스터를 만들었는데 무언가 deployment 가 이상 작동을 하는 듯 했다. 안그래도 헤딩 중인데 되는 것 같기도 하고 안되는거 같기도 하고, 한참 삽질 끝에 Fargate 노드가 2개 까지만 만들어지는 현상을 발견했다. 이벤트 로그 메시지:
"Your AWS account has reached the limit on the number of Fargate pods it can run concurrently" 당신의 AWS 계정이 동시에 실행할 수 있는 Fargate 포드 수 제한에 도달했습니다.
내 계정은 이제 막 새로 판지 얼마 안된 새삥인데, 계정에도 뭔 종류가 있나. 뭔 업그레이드를 해야 하나 싶었다. 일단 구글에서는 저 메시지로 검색된 결과가 거의 없었다. 그나마 증상이 유사한 글에서, 몇몇 제한이 있는 리전이 있어서 리전을 바꾸던지 EC2 를 써야 한다는 글을 보았다. 우선 리전에서 fargate 할당량 체크를 했다.
[Service Quotas] - [Fargate On-Demand resource count] 사용률 4% / 적용된 할당량 값 50 / AWS 기본 할당량 값 1,000
개널널. 아직 48개 더 만들 수 있는데 나한테 왜그러는지... 혹시나 해서 도쿄 리전에도 만들어 봤으니 똑같은 메시지. 어쩔 수 없이 [지원센터] 찬스를 이용했다. 간결하게 물었다.
Q. eks 를 사용중이다. Fargate Pod 수가 2가 되면 더 이상 Pod 를 추가할 수 없다.
그랬더니 답변이 정말 개허접스럽게 왔다.
A. Fargate 동시 작업 제한 문제가 발생하지 않도록 EC2 인스턴스를 시작하시겠습니까?
ㅋㅋㅋ Basic 이라고 답변을 이딴 식으로 하면 돼, 안돼? Fargate 써볼라고 하는 사람한테 할 소리? 장사 안하겠다는건데 진짜 수준 개실망. Basic 은 기술문의도 막혀있네. 우와~ 처음 알았음. 답변도 거의 반나절 걸리고 내가 진짜 웬만하면 저기 글 안올리는데 이거 너무 이상해서 올렸더니만 역시나네. 사실 내 질문은 저기서 끝나지 않았음. '이것도 안된다. 저것도 안된다.' 그랬더니 그 때부터는 모든 질문을 기술팀에 넘겼다며 답변이 오는대로 바로 전달하겠다는 말을 남겼고, 난 며칠동안 답변이 오기전 그 모든 현상들을 해결했다.
사실 위 문제의 해결은 그들이 할당량을 100 으로 늘리자마자 해결됐다. 이걸로 해결된게 더 어이가 없다. 이 할당량은 리전에서 생성할 수 있는 Farget 의 최대치인데 기존에도 널널했는데 이제서 됐다는게 이상하다. 위에 나타난 에러는 내 AWS 계정의 제한을 얘기했다. 그들이 내 계정의 제한을 풀어준 것이라면 이해가 가겠지만... 또, 신규 계정의 fargate 제한이 2라면 그것도 말이 안된다. 이에 대해 구체적으로도 문의를 했지만, 과다 청구를 막기 위한 제한이니 안될 경우 할당량 증가 요청을 하라는 ㄱ소리... 불이익을 받지 않기 위해 별 다섯개를 투척하긴 했다만...
내 결론은 Fargate 적용된 할당량 기본값은 2임. 화면에 보여진 50은 아마도 버그일 것임. 아니면 x < 50 ? 50 이던가. 그래서 할당량 값을 새로 업데이트만 시켜줘도 50 이상의 값이 설정되는 것임. 아마 나 역시 51로만 업데이트 했어도 됐을 것임. 이것이 바로 내 소설이다. 만약 이런 문제가 발생하면 바로 할당량 요청 ㄱㄱ
