밥벌이코딩

예를 들어 haproxy 서비스를 start 할 때 아래 명령어를 실행하는 경우 systemctl start haproxy 아래와 같은 오류가 발생한다. Failed to restart haproxy.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files See system logs and 'systemctl status haproxy.service' for details. 이런 경우 간단하게 해결할 수 있다. sudo를 사용해서 서비스를 실행하면 된다. sudo systemctl start haporxy

1. coredns upgrade #백업 kubectl get deployment coredns -n kube-system -o yaml > aws-k8s-coredns-old.yaml => 해당 백업파일을 apply 시키면 원복이 가능하다. #업그레이드 방법 kubectl set image deployment.apps/coredns -n kube-system coredns=602401143452.dkr.ecr.{region}.amazonaws.com/eks/coredns:{version} => 같은 방법이지만 edit deployment에서 image 부분만 바꿔도 업그레이드 가능하다. #버전 확인 kubectl describe deployment coredns -n kube-system | grep ..

1. 특정 도메인으로 들어온 값 구분하기 - hdr_beg(host) -i 를 사용하면 특정 host로 들어온 값을 구분할 수 있다. frontend front_server bind *:8888 acl auth hdr_beg(host) -i before-ahostname acl interface hdr_beg(host) -i before-bhostname use_backend backend-a if a-host use_backend backend-b if b-host 2. Host 변경 - set-header Host , replace-header Host 등 자유롭게 사용하면 된다 - host 뿐만 아니라 path도 변경해야 되는 경우는 여러가지 방법이 있겠지만 set-uri를 넣고 뒤에 path 부분..

Grafana에서 Alert을 설정할때 아래 이미지처럼 "No data"로 metrics이 수집이 안되는 경우 보통 Alert이 날아간다. 하지만 경우에 따라 No data인 경우가 정상이고 metrics이 수집되는 경우 비정상인 경우도 필요하다. 이런 경우는 Alert을 설정할때 Configure no data and error handing 부분을 설정해주면 No data인 경우도 Alert을 보내지 않을 수 있다. Alert을 설정할때 Configure no data and error handing 부분을 클릭하면 Alert state if no data or all values are null 부분이 보통 No Data로 되어있다. 이 설정은 metrics이 아무것도 수집되지 않는 경우 즉 No ..

이전 포스팅에서 Probe를 체크하는 방법이 3가지가 있었는데 그중 Command로 Probe를 체크하는 방법에 대해서 포스팅을 진행해 봤다. Command probe 성공 : Command 실행 후 결괏값이 0이면 정상 실패 : Command 실행 후 결과값이 0이 아니면 실패 readinessProbe or livenessProbe 적용 readinessProbe: exec: command: - /test/probe/probe.sh test shell 파일 생성 후 테스트 - 권한이 없는 경우 chmod 777을 통해 권한 추가 필요 #!/bin/bash exit 0 소켓 or 스레드 개수를 확인 후 true / false 체크 #!/bin/bash #소켓 결과 RESULT=$(ls /proc/1/f..

kubelet이 각 컨테이너의 상태를 특정 조건으로 주기적으로 체크한 뒤 문제가 있는 pod를 자동으로 재시작하거나 문제가 있는 pod를 서비스에서 제외해서 네트워크 유입을 막을 수 있다. 해당 기능을 probe 구성이라고 한다. probe를 사용하는 방법은 간단하게 2가지가 있다. 1. readinessProbe - 프로브 수행 후 실패하는 경우 pod가 재시작되지 않고 해당 pod를 서비스에서 제외시켜 네트워크 유입을 막는다. 2. livenessProbe - 프로브 수행 후 실패하는 경우 pod가 재기동된다. Probe를 체크하는 방법 1. HTTP probe 성공: get 요청을 보내서 return이 200~300 사이면 정상 실패: 그 외의 값이 return 되는 경우는 비정상 readiness..

1. IAM 역할 생성1. 해당 EKS의 정보확인 aws eks describe-cluster \ --name {cluster_name} \ --query "cluster.identity.oidc.issuer" \ --output text output 값 = > https://oidc.eks.{region}.amazonaws.com/id/{key} 2. json 파일 생성 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::{ID}:oidc-provider/oidc.eks.{region}.amazonaws.com/id/{key}" }, "Action": "sts:Assu..

EKS Kubernetes 버전 업그레이드(1.22 to 1.23)를 진행하기 전 필요한 드라이버가 있는지 수정되는 정책이 있는지 등 확인이 필요하다. 1.22 -> 1.23 으로 업그레이드 시 설치 및 업그레이드 가능한 사항 1. Amazon EBS CSI 드라이버 설치(EBS 볼륨을 사용한다면 필수 설치) : EBS 볼륨을 사용하는 경우 필수 설치 2. CNI Driver 최신 버전 업그레이드 : v1.12.6-eksbuild.1 3. kube-proxy 최신 버전 업그레이드 : v1.23.16-eksbuild.2 4. CoreDNS 최신 버전 업그레이드 : v1.8.7-eksbuild.4 2~4번 네트워크 관련 모듈들 업그레이드는 필수가 아니지만 최신버전을 항상 올려주는게 좋은 것 같다. 아래 표는..

파드간 affinity 사용(podAntiAffinity) - affinity는 Pod를 특정 Node에 배포되도록 하는 정책이다 1. Hard affinity - 규칙이 만족되는 경우만 파드가 기동된다. #requiredDuringSchedulingIgnoredDuringExecution: 규칙이 만족되지 않으면 스케줄러가 파드를 스케줄링할 수 없다. 이 기능은 nodeSelector와 유사하지만, 좀 더 표현적인 문법을 제공한다. ex) 만약 node가 4개 인데 pod replicas가 5개면 pod 4개는 running이지만 pod 1개는 affinity 정책에 걸려 pending 상태로 남아있다. affinity: podAntiAffinity: requiredDuringSchedulingIgno..

master, second 모두 실행 rabbitmq 설치 sudo apt-get install rabbitmq-server 관리자 계정 추가 sudo rabbitmqctl add_user {ID} {Password} ex) sudo rabbitmqctl add_user rabbit rabbit sudo rabbitmqctl set_user_tags {ID} administrator ex) sudo rabbitmqctl set_user_tags rabbit administrator management 활성화 및 접속 sudo rabbitmq-plugins enable rabbitmq_management sudo service rabbitmq-server restart web 접속 확인 http://loc..