사용자가 사용하려는 서비스 인증방법을 별도의 SSO Agent가 대행해주는 방식a. 대상 서비스의 인증 방식을 변경하기 어려울 때 사용b. 대상 서비스의 인증 방식을 전혀 변경하지 않음c. 서비스 인증 정보를 에이전트가 관리신뢰관계(Trust-relationship)를

https://www.mongodb.com/docs/atlas/security-vpc-peering/IP 대역은 10.0.0.0 이 제일 무난한것 같다업로드중..

https://reaperes.medium.com/aws-alb-%EC%9D%98-idle-timeout-%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC-7addb8bfb886

https://engineering.lightrun.com/argocd-aws-secrets-manager-3d625aa917f7https://awstip.com/how-to-implement-argocd-vault-plugin-with-aws-sec

현재 요구사항 : Scale In&Out이 빠르면서 비용을 절감할 수 있는 autoscaling 방침이 필요사전 준비기존 EKS 클러스터를 사용합니다.기존 VPC와 서브넷을 사용합니다.기존 보안 그룹을 사용합니다.노드가 하나 이상의 노드 그룹에 속해 있습니다.워크로드에

국가 성능 시험을 통과하기 위해 TPS를 올려야 하는 상황이 있었다.Jmeter를 사용하여 throuput을 올리려고 요청을 아무리 늘려도 TPS가 올라가지 않았다.경험상 tps를 올리는 방법은 ramp up time을 5~10초로 설정해 각 thread 시작 전에

회사에서 국가 성능 테스트에 관한 업무가 있었다. 내가 맡은 부분은 socket의 동접자를 10000명이상 감당한 서버인가 테스트 해보는 것이었다. 동접자를 테스트해본 결과 5000명까지는 로컬(맥)에서 vuser(가상의 user)를 생성 가능했지만, 이게 5000명

Karpenter에서 이따금씩 위와 같은 에러를 방출하는 경우가 있다.찾아보니 해당 에러는 유구한 역사같다.Secret의 karpenter-cert를 삭제하고 다시 배포하는 것이 에러 해결 방법이 되었다.karpenter의 배포가 꼬이면 또 다시 발생할 가능성이 높은것

prometheus를 배포하고 10gi 정도를 storageClass로 할당했으나 위와 같은 에러가 떴다.개발 클러스터라 많은 양의 메트릭 정보가 들어갈거라고 생각하지 않았는데, 의외로 10Gi 로도 부족했다.이럴때, 임의로 스토리지 클래스를 수정하면 에러가 발생할 수

Daemonset은 노드에 하나씩 꼭 붙어야 하는 파드를 의미한다. 예를 들어 promtail이나 fluent-bit와 같이 로그를 수집하는 daemonset은 노드마다 붙어야 각 서버의 로그를 받을 수 있다.이런 daemonset이 많아지거나, 노드가 많아지게 되어

카펜터에는 지켜야하는 여러 규칙이 존재합니다.아래는 요약으로 정리하였으니 개발시에 확인하면 좋습니다.카펜터는 ASG, MNG와 다르게 Kubernetes 기본 API에 더 가까운 scaling management를 사용합니다.ASG와 MNG는 EC2 CPU 로드와 같은

https://imgnew.megazone.com/2022/02/attachment-220211-8.pdf

https://stackoverflow.com/questions/34595579/can-i-programmatically-find-all-untagged-resourceshttps://youtube.com/watch?v=qjwRNlEBRdk&si=qY

로키에서 위와 같은 context canceled 에러가 뜰때가 있다.여러가지 이유가 있을 수 있는데, 필자의 경우 grpc로 수신 받을 수 있는 메시지 크기가 작아 에러가 생겼다.보통 query-frontend에서 에러가 나는 이유는 querier에서 에러가 나기 때

로키로 로그를 받아오면서 한 팀이 유독 request body 와 header 값을 로그에 남겨, 메시지 크기 에러를 불러오는 경우가 있었다. grpc는 기본으로 송신하는 쪽에 메시지 사이즈 제한이 없지만, 수신하는 쪽에는 4mb라는 제한이 있다. 해당 팀에서

메트릭 생성기(metrics-generator)는 Tempo의 선택적인 구성 요소입니다. 기본 helm 차트에 추가해야 합니다.작동 방식Metric Generator는 수집한 trace에서 metric data를 생성합니다. Distributor는 수신된 Span을 I

defualt vpc는 항상 있음.172.31.0.0/16 구성private, public 구분이 없음서로 다른 vpc 간에 peering 안됨.(ip 대역이 같음)처음부터 삭제하고 시작하기 위해 vpc+라우팅 테이블 삭제 함.사용중인 vpc ip 대역의 리스트를 모으

ingress 설정과 관련된 설명은 아래 공식문서가 제일 잘 나와있다.https://awskocaptain.gitbook.io/aws-builders-eks/6.-aws-load-balancer-controller

사내 모니터링 플랫폼을 개발하다가 여러가지 문제에 봉착했다.EKS helm으로 띄운 loki 및 tempo의 서비스는 gossip protocol을 사용해 하나의 gossip ring을 만들고 그 안의 각각의 서비스들이 memberlist를 조회하며 trace 및 로그

사전 준비 💡 k8s 클러스터에 네임스페이스 모니터링(monitoring)이 있어야 함. 💡 helm이 설치되어 있어야 함.Kubernetes에서는 기본적으로 로그가 각 Pod의 생명주기 동안만 유지됩니다. 하지만 단일 Pod의 수명보다 오래 로그를 보관하기