나는 리눅스 명령어들을 쉽고 빠르게 사용하기 위해 alias 와 functions 들을 만들어 사용하곤 한다. 그런데 내가 만든 alias 와 functions 들이 .bashrc 안에 있으면 재사용성이 떨어지기 때문에 내가 커스텀하게 만든 것들은 다른 파일에서 실행되
나는 쿠버네티스로 On-Premise 서버를 운용하고 있다. 내가 구성한 쿠버네티스 서버의 구성을 공유하고자 한다.우선 사용자 가 Ingress Contoller 를 통해 접속한다. (만약 http 로 접속하였다면 https 로 다시 리다이렉트를 진행한다.)Ingres
현상 kubeadm reset 으로 쿠버네티스를 삭제한 뒤 재설치한 뒤로 아래와 같이 CoreDNS 가 정상적으로 설치되지 않았다. 원인
kubelet 이 active 상태가 되지 않고 멈추는 현상kebelet 은 시작 시 아래의 Config 를 Load 한다.그런데 이중 /var/lib/kubelet/config.yaml 가 존재하지 않아 Error 가 났다.https://github.com/
systemctl 로 관리되는 프로세스들에 대해서 로그를 확인하는 방법을 공유하려 한다.systemctl 로 관리되는 프로세스들은 /var/log/syslog 에 로깅된다. 따라서 아래와 같이 로그를 확인할 수 있다.챗 지피티 ㅎ
Ingress 를 통한 서비스가 동작하지 않을 때에 나는 아래와 같이 리소스들을 점검한다.내가 어떤 식으로 점검하는 지 기록하려 한다.문제가 있다고 의심이 되는 리소스에 대해서 우선적으로 점검한다.외부로부터 트래픽이 오는 지 확인한다.1\. ingress-nginx-c
나는 단일 노드로 쿠버네티스를 구성하고 있었으며 Volume 은 hostPath PV 을 사용하고 있었다. 그러다 분산 로드밸런싱을 위해 노드 하나를 새로 추가하였는데 문제가 발생했다. 새로운 노드에서 기존의 노드의hostPath PV 를 읽지 못하는 현상이 생겼다.
Kubernetes 에서 Ingress 리소스를 추가하려 했는데 다음과 같이 에러가 발생했다.리소스 추가 요청결과:그래서 원인을 찾아보았다.아래와 같이 검증하는 리소스를 제거해줌으로써 해결하였다.kubectl delete -A ValidatingWebhookConfig
리눅스 20.04 이상 기준에서 kubeadm 을 설치하는 방법입니다.2대의 노트북을 활용하여 마스터 노드와 워커 노드를 구성하였습니다.인프라 구성입니다.최소 요구사항메모리 : 2 기가 이상CPU : 2 이상머신 간에 네트워크로 연결되어 있어야 합니다.인터넷 연결이 되
개요 argoCD 를 통해 쿠버네티스 에 CI / CD 를 비교적 손쉽게 적용할 수 있었다. 어떤 방식으로 CI / CD 가 이루어질 수 있는 지
argoCD 를 설치하고 argoCD 의 사이트에 로그인하는 방법을 공유하려 한다.해당 실습은 argoCD 공식 홈페이지(https://argo-cd.readthedocs.io/en/stable/getting_started/기본적으로 k8s 가 설치되어 있어야
아래의 그림과 같이 Ingress 가 정상 동작하지만 계속 Progressing 인 상태가 지속되는 현상이 발생했다.아래의 그림과 같이 현재 내 프로젝트 내 Ingress 의 status 는 아래와 같았다.그러나 argoCD 에서는 status.loadBalancer.
나는 기존 온-프레미스 서버 에 쿠버네틱스 를 적용하였다. 이전에는 단순히 앱을 실행시키는 구조 로 동작하였는데, 이번에는 앱을 도커 이미지로 만들고 쿠버네틱스로 적용 한 것이다. 이번 글에서는 쿠버네틱스 를 적용함으로써 얻은 이점과 내가 설정한 쿠버네틱스 인프라 구조
파드 (Pod) 의 환경변수에 MY_SQL 비밀번호 를 넣어야 할 때가 있었다. MY_SQL 비밀번호 는 기밀사항이므로 외부에 노출을 최소화하는 방법을 찾아보았고, Secret 을 사용하는 방안을 찾았다.이번 글에는 Secret 을 작성하고 적용하는 방법을 공유하려 한
미니큐브 로 쿠버네틱스 를 구동시키고 cert-manager 를 사용하여 서버에 HTTPS 를 적용하는 방법을 공유하려 한다.개념 정리는 일단 뒤로 하고, 바로 실습을 해보자.선제조건 : 미니큐브 가 설치되어 있어야 한다.helm 을 통해 ingress-nginx 컨
나의 백엔드 서버는 현재 온프레미스로 배포되어 있는데, 하나의 서버에서 어플리케이션을 실행시키는 형태 로 배포되어 있다. 배포되어 있는 인프라의 구조에서 발생하는 단점과 불편한 점 등이 있어 아래와 같이 쿠버네틱스를 적용한 인프라 구조 로 바꾸려 한다. 대체 어떤 불
약 4개월 전, 프론트엔드/백엔드 부트캠프 팀원들과 같이 블로그 사이트 를 개발했었다. 사이트를 개발했을 당시에는 적절한 회고록을 작성하지 못했기에 지금이라도 회고록을 작성해보려 한다.프로젝트 주제는 블로그 사이트 였다. 일반적인 블로그에서 지원하는 기능인 게시글,
나는 데브옵스 부트캠프에서 팀 프로젝트를 맡았다. 프로젝트는 특정 주제 에 대해 AWS 를 활용하여 최적의 클라우드 인프라 를 구축하는 것이 주 목표였고 이에 맞춰 프로젝트를 완료하였다. 이번 글에서는 맡았던 프로젝트를 설명하고 프로젝트 진행 과정에서 어려웠던 점과
나는 ECS 를 운용하고 있었고 ECR 에 있는 도커 이미지 를 task 이미지 로서 사용하고 있었다.기존에는 ECS 내 fargate 를 퍼블릭 서브넷 에 놓고 있었지만 보안이 신경쓰여 프라이빗 서브넷 으로 옮겼다. 그랬더니 아래와 같이 에러가 발생했다.에러 원인은
그라파나 를 사용해 ECS 클러스터 내 서비스 의 Metric 을 보는 방법을 공유하려 한다.Metric 을 통해 ECS의 CPU 사용률과 Memory 사용률을 볼 수 있다.선제조건: ECS 를 실행되고 있다는 전제하에 진행한다.Docker 를 통해 그라파나를 설치하고