일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Docker
- 설정
- hive
- Redis
- ec2
- 로그인
- SpringBoot
- 예제
- aws
- redash
- Cluster
- fastcampus
- Jenkins
- java
- login
- 자동
- gradle
- 레디스
- 클러스터
- EMR
- config
- spring
- 간단
- Zeppelin
- vue
- Mac
- Kafka
- 젠킨스
- 자바
- 머신러닝
- Today
- Total
목록ETC (82)
코알못
설정 파일에는 비밀번호 같은 민감 정보가 있을 수 있다. 이런 민감 데이터를 관리하기 위한 오브젝트인 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..
클러스터에 구축한 파드에 접근하기 위해서는 어떻게 해야 할까 ? Pod IP는 클러스터 내부에서만 접근 가능하므로 외부에서 접근이 불가능하다. 우리는 이를 위해 Service 오브젝트를 사용하면 된다! 서비스 오브젝트를 이용하면 파드 집합에 대해 단일 엔드 포인트로 접근 가능하며 로드 밸런서 기능을 이용할 수 있다! 주의 사항은 pod보다 서비스가 먼저 생성 되어야하고 같은 네임스페이스에 있는 파드만 관리한다. Service 오브젝트의 타입은 세가지로 아래와 같으며 목적에 맞게 사용하면 된다. 서비스 타입 설명 ClusterIP 외부에서 접근 불가능 Internal IP만 할당, External IP 할당 받지 않음 내부 통신 목적시에 사용 internal IP를 클러스터 내부에서 호출하면 적합한 파드로..
저번시간에 Deployment 배포 전략 두가지에 대해서 간단하게 개념을 배웠고 이번시간 실습을 통해 익혀보도록 하자! 추가로 롤백 하는 방법도 알아보도록 하며 실습 내용은 아래와 같다. 배포전략 Recreate 실습 배포전략 RollingUpdate 실습 Revision 을 통한 롤백 실습 우선 배포전략 Recreate 실습을 진행해보자! 아래와 같이 Deployment 오브젝트 yaml 파일을 작성한다. # deployment-v4.yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-app labels: app: my-app spec: replicas: 3 selector: matchLabels: app: my-app strategy: type..