Blockchain & Devops

ServiceAccount에 적용된 Role의 신뢰관계 설정 문제일 가능성이 크다. ServiceAccount가 AWS 리소스에 접근할 권한이 없기 때문. $ kubectl describe sa aws-load-balancer-controller -n kube-system 먼저 ALB Controller의 SA를 상세 정보를 확인하면, 위와 같이 Annotation에 선언된 Role을 확인할 수 있음. 위에선 AmazonEKSLoadBalancerControllerRole이 SA의 Role로 선언되어 있음. AmazonEKSLoadBalancerControllerRole을 확인해보면 아래와 같은 신뢰관계가 구성되어있다. { "Version": "2012-10-17", "Statement": [ { "Ef..

Ingress 동작 방식 ALB Controller는 API 서버의 Ingress 이벤트를 모니터링한다. 요구 사항을 충족하는 수신 리소스 발견 시, AWS 리소스 생성을 시작한다. 수신 리소스에 맞춰 AWS에서 ALB(ELB v2)를 생성한다.(이 ALB는 인터넷 연결이 되거나 내부에 존재할 수 있으며 Annotation으로 서브넷 지정 가능) Target Group은 수신 리소스에서 지정된 고유 k8s 서비스에 대해 AWS에서 생성된다. 수신 리소스의 Annotation에 설명된 모든 포트에 대해 리스너가 생성된다. 포트는 80과 443이 디폴트며, Annotation에 인증서 첨부도 가능하다. 수신 리소스에 각 경로에 대한 규칙이 생성된다. 특정 경로에 대한 트래픽이 적절한 k9s 서비스로 라우팅된..

Helm을 사용하면 1분 내로 설치가 가능하다. $ helm repo add argo https://argoproj.github.io/argo-helm $ helm fetch argo/argo-cd $ tar -xvzf argo-cd-5.16.1.tgz $ kubectl create namespace argo $ nano values.yaml // 필요에 따라 value.yaml 수정 // service type : Loadbalcer // service subnet : 사용 중인 서브넷 추가 $ helm install argo -n argo argo/argo-cd -f values.yaml $ kubectl -n argo get secret argocd-initial-admin-secret -o jso..

kubeconfig 파일을 생성하여 EKS 클러스터 API 서버와 통신할 수 있도록 구성한다. cluster를 컨트롤할 bastion 서버에는 aws cli, kubectl가 미리 설치되어 있어야한다. (혹시 기존에 config 파일이 존재했다면, 삭제하고 재설정하는 것을 권장) kubectl 설치 (아래 aws 공식문서 참고) https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/ # 기존 버전 설치되어 있는 지 확인 $ kubectl version | grep Client | cut -d : -f 5 # kubernetes amd 64 1.23버전 다운 (linux) $ curl -o kubectl https://s3.us-west-2.amazo..

Application ## 먼저 엔드포인트 확인 $ curl endpoint ## 서비스 상태 확인 (Selector와 Endpoint 체크) $ kubectl describe service web-service ## 파드 확인 $ kubectl get pod $ kubectl describe pod web $ kubectl logs web -f --previous Control Plane ## Node & Pod 확인 $ kubectl get nodes $ kubectl get pods ## Controlplane Pod & Service 확인 $ kubectl get pods -n kube-system ## Controlplane Service 확인 $ service kube-apiserver sta..

멀티 컨테이너 파드는 아주 유용하다. 대체로 파드에 하나의 컨테이너만 생성하는 편이지만, 파드에 여러 컨테이너를 추가하면서 얻을 수 있는 장점이 많다. 컨테이너를 동일한 노드에서 관리해야하는 프로세스가 필요하거나, 파드의 컨테이너간 통신이 필요한 경우 멀티컨테이너의 역할이 요구된다. 여기서 멀티컨테이너는 3가지 패턴이 있는데 아래와 같다. 사이드카 패턴(Sidecar) 사이드가 패턴은 어플리케이션에 필수적이지만, 어플리케이션의 일부일 필요가 없는 컨테이너로 구성된다. 대체로 Logging이나 Sync를 맞추거나 혹은 monitoring이 필요한 경우에 많이 사용하는 패턴이다. 이 패턴은 로깅 코드에 결함이 생길 경우에 격리된 컨테이너기 때문에 어플리케이션에 영향을 주지 않는다는 장점이 있다. 어댑터 패턴..

도커를 실행할 때, ENTRYPOINT와 CMD를 활용해서 명령어의 인자값을 컨테이너 실행시에 전달하고 수정할 수 있다. 쿠버네티스에서도 Pod 정의에서 활용이가능하다. Kubernetes Command & args 왼쪽은 Dockerfile에서 선언된 ENTRYPOINT와 CMD다. 오른쪽 POD 정의에서 command는 ENTRYPOINT의 필수 실행 명령을, args를 통해서 인자값을 전달할 수 있게된다. Configmap 환경변수를 미리 선언하고 관리할 수 있는 Kubernetes Configmap을 이용하면 많은 인자값 관리가 편리해진다. 위처럼 ConfigMap을 Key:Vaule 식으로 먼저 정의를 한다. 적용할 Pod에서 spec.containers.envFrom.configMapRef.n..

Helm은 쿠버네티스의 service, deployment, configmap과 같은 다양한 오브젝트들을 결합해주는 쿠버네티스용 패키지라고 보면 된다. Helm은 애플리케이션 컨테이너 배포는 물론이고, 이에 필요한 쿠버네티스 리소스를 모두 배포해주는 역할이라고 보면된다. 왜 굳이 Helm을 사용해야할 까? Deployment 히스토리 기능 제공 Helm에서 배포된 어플리케이션은 Helm release로 관리가 된다. 릴리즈된 버전 기록을 자동으로 유지 관리하고 배포 후에 문제 발생시 롤백하는 것이 간편하다. CI/CD 파이프라인 가능 CI/CD 파이프라인을 이용해서 배포 작업을 구성하고 자동화할 수 있다. 멀티스테이징 배포 중에 어플리케이션 구성이 가능하다. 쉽게 말해서, 스테이킹 운영환경에 따라서 Po..

서비스와 인그레스는 같은 네트워크 관련 오브젝트로, 쿠버네티스의 각 컨테이너의 네트워크 포워딩과 설정에 관여한다고 볼 수 있다. 서비스(Service) 위 이미지에서 보는 것처럼, 서비스는 같은 역할과 서비스를 하는 여러 POD를 하나로 묶어서 관리하는 오브젝트라고 볼 수 있다. 파드가 새로 생성될 때마다 동적으로 IP를 할당할 수 있다. 간단히 말해서 서비스는 트래픽을 파드로 전달만하는 역할을 한다. 여기서 서비스는 여러 종류를 가진다. 1) ClusterIP 내부에서만 접근할 수 있는 IP를 할당한다. 그래서 외부에서 접속이 불가능하다. 그러나 kubeproxy를 활용하면 접근할 수 있다 2) NodePort 클러스터의 모든 노드로 외부에서 접근할 수 있는 포트를 개방한다. NodePort가 설정되면..

쿠버네티스의 오브젝트는 컨테이너 워크로드를 처리하는데 사용되는 1) 워크로드용 객체, 네트워크 및 보안을 처리하는 2) 인프라 객체와 구분할 수 있다. 오브젝트 생성을 위해서는 YAML을 활용하고, API 서버를 통해서 요청된다. 그리고 생성전에 유효성 검증이 진행된다. Workload 1) Pod 파드는 작업의 기본 단위면서, k8s에서 생성하고 관리할 수 있는 가장 작은 단위의 유닛이다. 파드는 하나 이상의 컨테이너들의 그룹이며, 모두 스토리지와 네트워크 리소스를 공유한다. 굳이 비유를 하자면 '하나 혹은 여러 컨테이너들을 감싼 얇은 wrapper'다. 2) Deployment 디플로이먼트는 파드와 레플리카셋의 선언적인 설정을 제공한다. Deploy하여 레플리카셋보다 한 단계 높은 관리 오브젝트를 생..