본문 바로가기

⭐ Kubernetes & EKS

 (140)
Ingress Annotation을 활용한 ssl 적용하기 # 해당 작업이 필요한 이유? - AWS EKS는 AWS 영역과 K8s 영역이 나누어져 있다. 한마디로 이야기 하자면, 서로 다른 영역을 연결을 해놓았다 라고 이해하면 쉽다. 그 연결고리가 바로 Application LoadBalancer 즉 ALB 라고 생각한다. # Ingress에 SSL을 적용하게된 이유는? Ingress에 SSL을 적용하게 된 이유는 간단하다. EKS의 노드의 숫자를 수동으로 조정하거나 어떤 정보를 변경 했을때 로드 밸런서의 리스너 정보가 초기화가 되는 현상이 발생 했다. 여러번 반복되다 보니 해결책을 찾아야 했다. # 그렇다면, 왜 노드그룹 정보를 변경하거나 인스턴스의 갯수를 수동으로 조정 등 했을 뿐인데 ALB의 리스너가 초기화가 되었을까? ALB에서는 CORS에 대해 지원을 ..
Ingress에 대한 이해가 안되는 내용 # Ingress 설정에서 이해가 안가는 내용이 존재한다. 일단 port number 설정에 대한 이해가 안간다. 아래의 예시를 보면, 아래의 # 값으로 주석처리 된 내용을 보면 port number는 80으로 서비스가 되도록 설정 되어 있다. 그런데 18808 번이나 45000번 50000번등으로 설정을 변경 후 배포를 해도 서비스는 정상적으로 수행이 된다. spec: rules: - http: paths: - path: /articles pathType: Prefix backend: service: name: "test-service" port: number: 80 #해당 포트 번호를 45000번이나 50000번으로 변경 후 서비스해도 전혀 이상이 없다... - path: / pathType: Pre..
kubernetes 클러스터 명령어 모음 및 자동완성 설정하기 # k8s 클러스터에서 사용할 수 있는 명령어 확인 kubectl api-resources NAME SHORTNAMES APIGROUP NAMESPACED KIND bindings true Binding componentstatuses cs false ComponentStatus configmaps cm true ConfigMap endpoints ep true Endpoints events ev true Event limitranges limits true LimitRange namespaces ns false Namespace nodes no false Node persistentvolumeclaims pvc true PersistentVolumeClaim persistentvolumes pv fal..
Ingress와 api의 관계에 대한 설명 # Ingress와 api의 관계데 대한 정리 (그림) - 잉그레스의 사전적 정의 : 입장, 권리, 입장권 - 간단하게 설명하면 아래와 같다. Ingress에 설정된 path 주소화 백엔드 api의 주소의 정보가 일치해야 한다. 즉, RESTful API주소로 정의된 서비스를 제공해주는 연결 통로라고 볼 수 있다. (프론트 엔드 및 백엔드에 정의된 /api가 개별로 서비스 가능 하게끔 구성이 가능하다.) 예를 들어 설명하면, 스프링부트의 BoardController가 존재하고, 해당 컨트롤러의 api 주소를 아래와 같이 @GetMapping으로 /articles라는 api주소를 설정 했을때, ingress에서 해당 api주소로 아래와 같이 설정을 하면 ALB의 리스너 정책에 해당 정보를 참고하여 맵핑 후..
service.yaml 파일에 healthcheck 설정 - AWS 로드밸런서 > 대상그룹 > 등록된 대상 > 상태 확인 - 설정하는 방법 1. service.yaml 파일에 healthcheck 어노테이션 설정 apiVersion: v1 kind: Service metadata: name: member-api-service namespace: default annotations: alb.ingress.kubernetes.io/healthcheck-path: "/member" spec: selector: app: member-api type: NodePort ports: - port: 80 protocol: TCP targetPort: 3000 2. 접근 확인 접근 url/member 로 접근이 가능하여 정상적인 페이지가 호출 되어야 한다. 한마디로, serv..
노드그룹(NodeGroup) 변경 및 생성 시 주의사항 # NodeGroup 변경 및 생성 시 주의 사항 - 노드그룹을 변경 및 신규로 생성하면... ALB 리스너 정보가 초기화 된다. 그도 그럴것이 노드그룹을 생성 한다는것은 파드를 재배치 한다는 뜻이고, 파드가 재배치 될때 k8s 정보는 그대로 보존해서 가져가는거 같다. - 하지만 AWS에서 바라보는 타겟그룹 정보가 바뀌게 되면서 로드밸러서의 리스너 정보가 초기화 되는건 아닌지 싶다. - 그래서 노드그룹도 함부로 변경 및 생성하면 안되겠다... - 그래서 pod를 고정으로 특정 인스턴스에 배포를 하는 이유가 위의 이유 때문일까? 아무래도 고정 인스턴스에 배포가 되면 해당 인스턴스가 삭제되지 않는 이상 노드그룹을 새롭게 생성해도 관련정보가 변경되지 않기 때문에? 테스트를 해봐야 겠다. (노드 셀렉터를 사용하..
Deployment 삭제 방법 (ReplicaSet 삭제 안될때, 좀비 pod, pod가 삭제 안될때, pod가 계속 살아날때) # 오류내용 - ReplicaSet이 삭제가 되지 않아 pod를 강제로 지워도 좀비처럼 다시 살아나는 문제 발생 # 해결방법 - Deployment 자체를 삭제 해야한다. - Deployment 를 삭제해야한다. 그러면 pod 및 ReplicaSet이 삭제 된다. - 모든 Deployment를 확인 kubectl get deployments --all-namespaces - Deployment 삭제 kubectl delete -n NAMESPACE deployment DEPLOYMENT // 네임슾이스가 default이고 deployment의 이름이 nginx인경우 아래와 같이 삭제 kubectl delete -n default deployment nginx 여기서 NAMESPACE는 네임 스페이스이고 ..
pod cpu 및 메모리 사용량 확인 # 실행중인 pod의 CPU 및 메모리의 사용량을 확인해보자. 1. 우선 top로 리소스를 확인하기 위해서는 Metric이 설치 되어 있어야 한다. # kubectl top nodes NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% ap-northeast-2.compute.internal 65m 0% 600Mi 1% ap-northeast-2.compute.internal 65m 0% 668Mi 2 2. pod의 CPU와 Memory의 사용량을 확인하는 방법은 아래와 같다. kubectl top pod kubectl top pod -n [namespace_name] kubectl top pod [pod_name] -n [namespace_name] - 끝 -

티스토리툴바