DevBoi

우선 pod생성은 run으로 생성한다. kubectl run "pod name" --image "url or filename" kubectl run echo --image ghcr.io/subicura/echo:v1 kubectl describe pods/smith로도 내용을 봤다. kubectl run을 하게 되면 위와 같은 과정으로 pod이 생성된다 이전에 공부했듯이 , 스케줄러는 Api server를 통해 할당 되지 않은 pod을 검사하고, 이를 pod을 노드에 할당하도록한다. kubelet이 컨테이너를 생성하고, 이 안에 pod상태를 api server에 결과를 전달 한다. 다시 삭제하고 yaml 파일 기준으로 작성하여 pods를 생성해보도록하자 실제로는 이런 방식으로 pod을 생성하고 관리를 할..

1)apply - 원하는 상태를 적용한다. 보통 -f 옵션으로 파일과 함께 사용한다. ex. kubectl apply -f [파일 명 or URL] kubectl apply -f https://subicura.com/k8s/code/guide/index/wordpress-k8s.yml 이렇게 하면 원격 url에서 배포하는 yml 파일을 댕겨와서 적용 시켜준다. 뭔가 pods,deployment,service 들이 생성된 것을 볼 수 있다. 2)get - 리소스 목록을 보여준다. 이제 생성된 것을 봐야겠지? kubectl get pod kubectl get pods kubectl get po kubectl get pod,service kubectl get po,svc kubectl get all 위의 명령..

1. Docker desktop 설치 -> 쿠퍼네티스 enable 실행, window에서는 minikube사용하는데, command에 일일히 치는 ㅈㄴ 귀찮;;; 2. kubectl 설치 -> 가이드 많음, 그냥 curl로 설치 Docker desktop으로, setting에서 k8s enable하면, 요로케 로컬에서 Kubernetes Cluster를 띄워버리고, kubectl을 로컬 터미널에서 치면 정상적으로 확인이 가능하다. kubectl version --output yaml kubectl config get-contexts kubectl get pods -- all-namespaces 우선 위 커맨드 내용이 정상적으로 출력되면 이제 데모를 위한 준비가 완료된 것이다.

pod이라는 오브젝트를 생성한다고 해보자 각각의 yaml 파일을 만들고, create를 하게 되면 이렇게 생성이된다. 나는 생성하다가 오류가 났다...ㅋ 그리고 ArgoCD라는 custom resource기준대로작성된 문서이다. 문서는 어느정도 비슷한 유형을 따른다. 각각 풀스택로 정의되면 k8s는 이런방식으로 동작을 하게 된다. 직접 실습 하면서 확인해보자. 이게 쿠버네티스의 과정을 도식화 한것이다. 이제 실습을 해보자

가장 작은 배포 단위 Pod은 내부적으로 고유한 ip를 가질 수 있다. Pod안에 보통 컨테이너가 하나만 있지만, 두개 이상이 존재할 수도 있다. 하나의 pod에 컨테이너와 캐시, 로그 등으로 묶을 수도있다. ReplicaSet - 총 몇개의 pod으로 관리를 할 지를 결정한다. 만약에 3개의 pod만있는데, 4개를 요구한다면 pod template기준으로, 1개를 추가해준다. 무중단 배포를 위해, 배포버전을 바꾸면, 리플리카가 두개가 뜨게 되고 이를 세팅을 바꾸게되면 pod의 개수를 줄이거나 늘리게 해준다. Deployment 는 즉 ReplicaSet기준으로, 배포버전이 변경되었을때 무중단 배포를 위해서 존재하는 녀석이다. 클러스터 내부에서 사용하는 프록시 Pod들이 모인, 곳에 로드밸런싱을 해준다...

grafana로 admin을 보고 helm으로 업데이트하고 kubectl로 명령어를 치고... 우선 K8S에 대한 구조를 익혀보자 우선 이런 구조이다. 어떤 서버에 용량이 여유가있어서, 새로운 컨테이너를 배포하려고하면 어떤 서버에 넣어야할까? 사람이 직접 골라서 하지않는다. Master서버에서 어떤 서버에 여유가있어서 이 컨테이너가 어떤 서버에 들어갈 수 있는지를 골라서 해준다. 1) etcd 모든 상태와 데이터를 저장하고 분산 시스템으로 구성하여 안전성을 높인다. 가볍고 빠르면서 정확하게 설계가 디고, key-value 형태로 데이터를 저장한다. TTL, watch같은 부가 기능을 제공하기도 한다. 모든 상태를 저장하기 때문에 백업은 필수이다. 대부분 두 대정도 돌아간다. 2) Scheduler 컨테이..

Spring Cloud Gateway란? Spring Reactive 생태계 위에 Spring Cloud에서 구현한 Api Gateway이다. Api gateway? reverse proxy를 향상 시켰다. Netfilix zuul, Amazon Api Gateway, Spring cloud Gateway등이 있다. *Reverse Proxy란? Proxy는 클라이언트와 서버간의 중계기이다. Proxy는 크게 Post Proxy 와 Reverse Proxy, 두가지가 존재한다. Post Proxy란, 사용자가 웹서버에 직접 접근 하는 것이 아니라, Proxy서버를 통해 간접적으로 요청 할 수 있게 해주는 것 Proxy 서버가 사용자 앞에 있는 것을 PostProxy라고 한다. Reverse Proxy는 ..

내가 담당하게 된 서비스 중 API-gateway의 모듈이 추가되었다. API-Gateway에 대해서 설명이 듣던중 서킷 브레이커 패턴에 대해서 듣게 되었고, 정확하게 몰라, 정리를 하면서 공부를 하려고한다. 대부분의 모놀리틱스 환경에서의 어플리케이션이다. 특정 서비스들은 서로를 호출하면서 영향을 주는 관계에 있다. 아니면 gateway를 사용하지 않는 msa의 환경에서도 이렇게 되어있다. 어떤 환경이냐면, 특정 서비스 A에서 B를 호출한다고 가정해보자 B가 행이찼거나 slow 현상이 발생하게 되면, 이는 A의 로드타임에도 영향을 미칠수있다. 두개면 두개로 간단하게 보이지만, 연관된게 점점 더 많아진다면? 더 많은 복잡한 장애가 발생하게 된다. 이를 "장애 전파"라고 한다. 서킷 브레이커는 하나의 패턴에..

유저정보를 관리하던, 테스트를 해보던 간에 JPA 설정 및 데이터베이스 연동은 필수이다. 추후 스프링 시큐리티를 적용하던 Redis로 테스트를 하던 데이터 베이스 연동을 하지 않고는 그냥 추상적인 구현이기 떄문에 우선 부랴부랴 연동 해보자 h2와 JPA를 maven 방식으로 추가해준다. 그리고 application.yml에서 해당 jpa 설정과 h2관련 설정을 추가해준다. 이러면 기동시에 jpa 관련 설정들과 h2의 경로를 알아서 설정해서 개발이 가능하게 Entity 별 테이블관리, JPA사용등등을 하게 해준다. 정상적으로 테스트가 됬는지 엔티티 하나를 생성해서 재기동해보자 JPA 관련 전략이 create이기 때문에 재기동할때마다 테이블이 신규 생성 및 초기화 될 것 이다. 재기동할때 테이블 생성 쿼리가..

인터셉터를 오랜만에 구현해볼겸, 로깅 및 로그인 여부 체크 용도의 인터셉터 두개를 구현해보자 단순한 LoggingInterceptor를 생성 하여 빈으로 등록하고, WebConfig를 별도로 생성 및 빈으로 등록하여, 해당 인터셉터를 등록해준다. 우선 간단하게 사용자가 요청하는 URI과 Ip 정보를 로그로 찍게 한다. 단순히 로깅용 인터셉터만 생성하는 것이 아닌, 별도로 로그인 여부를 판별하는 인터셉터도 생성해보자 우선 Redis나 스프링 시큐리티를 사용하기 전 이니까, 로그인 성공시에 쿠키에만 해당 쿠키값을 저장 해놓고 해당 쿠키값을 체크해서 로깅을 해보자 로그인 성공 시에 단순히 쿠키에 값을 넣고, 인터셉터로 쿠키 값의 이름을 체크해서, 값 이있는지 있다면, 그 값이 Y인지를 체크하는 인터셉터를 생성..