코알못

- 원인 : awscli, kubectl 버전 이슈 $ kubectl get nodes error: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1" - 해결 : 저자의 경우 aws cli 버전을 2로 올려서 해결 하였다. $ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" $ unzip awscliv2.zip $ sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update $ aws --version aws-cli/2.12.1 Pytho..

잘못된 CRON 식이라는 오류가 발생하며 Cron 이 등록되지 않았다. 요일 필드에 요일을 설정할시 일 필드에 '*' > '?' 로 변경 해야 적용되는것을 볼 수 있다. UTC 시간+9 하면 한국 시간으로 알맞게 요일 설정하여 아래 미리보기로 확인하면 된다! 끝!

설정 파일에는 비밀번호 같은 민감 정보가 있을 수 있다. 이런 민감 데이터를 관리하기 위한 오브젝트인 Secret을 사용하면 Base64로 인코딩하여 저장하고 불러올때는 디코딩해준다! 이번 실습은 nginx 인증서와 키 파일을 secret을 통해 저장하고 파드 볼륨에서 해당 secret에 있는 데이터를 불러오도록 하여 안전하게 관리 하도록 해보자! 인증서는 cert 디렉토리에 생성하도록 한다. $ mkdir cert nginx에 사용할 인증서와 키파일을 생성한다. # 키 생성 $ openssl genrsa -aes256 -out ./cert/corin.com.key 2048 # 개인키 자체 암호화 제거 $ cp ./corin.com.key ./cert/corin.com.key.enc $ openssl r..

지금까지 쿠버네티스 yaml 파일에 config를 설정 하고 값 수정시 yaml 파일을 수정 하였으며 이는 소스 소스코드가 아닌 설정을 수정하는 것임에도 불구하고 배포를 다시 해야하여 어플리케이션에 영향을 줄 수 있다. 영향을 주지 않도록 Config를 분리 하는 방법인 ConfigMap 오브젝트를 실습 해보자! ConfigMap은 이름에서 보여지는것과 같이 설정값을 Config 키/값 쌍으로 관리한다. ConfigMap을 생성 하는 방법은 2가지가 있다. 리터럴 방식 : 생성시 Key/Value 지정 파일 방식 : 생성시 Config 가 있는 파일의 디렉토리 지정 ConfigMap을 사용하는 방법은 3가지가 있다. 컨테이너에서 ConfigMap 일부 Key 값 불러오기 컨테이너에서 ConfigMap 모..

기본적으로 쿠버네티스 컨테이너가 죽었을때 컨네이너를 재기동 해주나 컨테이너에 띄운 내부 서비스 장애가 났을 경우에는 컨테이너를 재기동 해주지 않는다. 이를 위해서 이용하는것이 livenessProbe(생동감 조사) 이다! 설정은 아래와 같이 7개이며 설명을 참고한다. livenessProbe: httpGet: path: / # probe 엔드포인트 port: 8080 # probe 대상 컨테이너 포트 initialDelaySeconds: 60 # 해당 설정 만큼 대기후 probe 시작 (서비스 기동시간 전에 호출하게 되면 무조건 오류이므로 무한 루프에 빠질 수 있기 때문) periodSeconds: 5 # probe 실행 주기 successThreshold: 1 # 몇개 성공하면 실패 횟수 초기화 할지 ..

LoadBalance를 사용하면 Service External IP를 기억해야하며 하나면 괜찮지만 여러개일때 모두 기억하기 어렵다. 이때 사용하는것이 Ingress로 트래픽을 서비스로 분산하기 위한 라우팅 규칙 모음이다! host 헤더나 path를 통해 서비스를 구분하고 트래픽 포워딩 할 수 있다. Ingress는 규칙 집합으로 IngressController 객체의 도움이 필요하며 이는 쿠버네티스가 지원하는 Ingress Controller를 가지고 직접 구성하거나 여러 라이브러리를 사용하여 구성 해야 한다. 어렵기 때문에 클라우드에서 제공해주는 경우가 있으며 우리는 구글 클라우드를 사용하므로 Ingress 사용시 Controller를 자동 구성해주므로 따로 구현할필요가 없다. Ingress 정의하는 ..

저번 시간에는 NodePort로 Pod 와 통신하는 실습을 진행하였다! 이번 시간에는 loadBalancer로 Pod와 통신하는 실습을 진행해보도록 하자! order 서비스는 주문을 위해 외부 통신 해야하므로 LoadBalancer type 으로 지정하며 payment 서비스는 이전과 동일하게 외부 통신 하지 않으므로 Cluster type으로 지정한다. 이제 실습을 위한 yaml 파일을 생성하며 이전시간과 다른 부분은 order 서비스 오브젝트의 type 이 NodePort > LoadBalancer 타입인 부분이다. # servie-v4.yaml apiVersion: v1 kind: Service metadata: name: order namespace: snackbar labels: service:..

저번 시간에는 ClusterIP로 Pod 통신하는 방법을 배워봤다! 이번 시간에는 NodePort로 Pod 통신하는 실습을 진행해보자! order 서비스 오브젝트는 주문을 위해 외부 통신을 할 예정이며 NodePort 타입으로 지정한다. payment 서비스 오브젝트는 order 파드와 통신 용도이기에 외부 통신 하지 않으므로 ClusterIP 타입으로 지정한다. 이제 실습을 위해 order, payment의 Service 오브젝트와 Deployment 를 생성하는 yaml 파일을 만들도록 한다. # service-v3.yaml apiVersion: v1 kind: Service metadata: name: order namespace: snackbar labels: service: order proje..