일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- JDK1.8
- cors #Authorization
- 이펙티스자바
- React #생명주기
- React
- React#기초#JS#JavaScrip#개념
- MySQL 5.7 #MySQL 8.0 #차이점 #업그레이드
- 모니터링 #k8s #prometheus #metricbeat #elasticsearch #logstash
- interface
- java
- WEB #HTTP #HTTPS #SSL #통신개념
- MQ#MOM#메시지지향미들웨어#Kafka#ActiveMQ#rabbitMQ
- MQM #웹서버
- ssl #개인키 #공개키
- Oracle #ANSI #SQL #JOIN
- EKS란
- REST#SOAP#API
- non-locking
- SSH #공개키인증
- Mysql #RDBMS #설치 #기동 #설정
- docker #k8s #배포하기
- abstract
- 클라우드#클라우드서비스#클라우드개념#IaaS#Paas#Saas
- Vuejs#JavaScript#프레임워크#개요#개념
- memory #리눅스 #자원관리
- X.25
- 오라클#튜닝
- k8s
- ssh #pem
- JPA #생명주기
Archives
- Today
- Total
개발노트
k8s 배포 가이드 본문
개인적으로 회사내에서 제가 배포할때 쓰려고 만들어둔 가이드를 정리하였습니다.
기본적인 docker image build에서 부터 k8s에 image를 pod 형식으로 배포할때 참고하면 좋을거라 생각됩니다.
k8s 배포 가이드
0. Harbor 로그인.
docker login harbor.okestro.cld -u admin -p okestro2018
1. docker image를 dockerfile을 통해 생성.
docker build -t {이미지명:태그명} {dockerfile경로}
2. docker image를 horbor에 push.
docker push harbor.okestro.cld/{이미지명:태그명}
* push전에 개발환경의 harbor에 로그인 되어있다는 전제조건을 가진다.
3. k8s에 접속 후 deploy, svc, cm.yml 파일 작성.
root@platform-k8s-master0:~/cloud-platform-lab-setting/symphony/symphony-app# pwd
/root/cloud-platform-lab-setting/symphony/symphony-app
root@platform-k8s-master0:~/cloud-platform-lab-setting/symphony/symphony-app# ls -lrt
total 12
-rw-r--r-- 1 root root 235 Nov 11 02:32 svc-symphony-app.yaml
-rw-r--r-- 1 root root 192 Nov 11 02:32 cm-symphony-app.yaml
-rw-r--r-- 1 root root 704 Nov 11 04:21 deployment-symphony-app.yaml
[파일리스트]
1) svc-symphony-app.yaml
2) cm-symphony-app.yaml
3)deployment-symphony-app.yaml
4. k8s에 작성한 .yml 파일들을 통해 pod 생성.
kubectl apply -f {파일이나 디렉토리명}
*위 명령어를 치면 .yml 에 정의된 내용대로 수행됨. 이때 네임스페이스나 서비스명, pod이름등이 정의된대로 올라감.
5. 생성된 pod 상태 확인.
kubectl get pod -n {네임스페이스명}
6. pod 상태 확인.
kubectl describe pod -n {네임스페이스명} {pod명}
7. pod 삭제.
kubectl delete -f {pod를 올린 deployment.yml 파일}
*위 의미는 해당파일을 읽어서 관련된 pod를 삭제한다는 뜻이다. 파일은 그대로 유지됨
8. pod 로그 확인.
kubectl logs -f -n {네임스페이스명} {pod명}
OR
kubectl logs -f --tail {최대표현로그라인} -n {네임스페이스명} {pod명}
k8s 네트워크 타입 관련 명령어 모음
배포 후 네트워크 타입을 변경할 요건이 생겼을시 참고하기위해 정리함.
*외부에서 직접 붙을수있게 하기위한 임시조치
1. k8s 에 떠있는 Service 확인.
kubectl get svc -n {네임스페이스명}
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc-symphony-app NodePort 10.233.0.167 <none> 18095:31300/TCP 6h41m
symphony-api ClusterIP 10.233.16.196 <none> 18082/TCP 22
*위 결과물에 TYPE을 보면 2가지로 나뉘는데
1. NodePort : 포트를 외부에 노출시키는 타입
2. ClusterIP : 내부에서만 사용하겠다는 타입
- service.yaml 파일 내용
apiVersion: v1
kind: Service
metadata:
name: symphony-api
namespace: symphony
spec:
ports:
- name: symphony-api-port
port: 18082
targetPort: 18082
selector:
app: symphony-api-pods-label
type: ClusterIP. --> 해당 옵션으로 설정한뒤 재기동하면 타입이 변경됨.
2. pod 재기동.
kubectl delete -f {pod를 올린 deployment.yml 파일}
kubectl apply -f {pod를 올릴 deployment.yml 파일}
3. Service 확인 명령어를 통해 바뀐 타입을 확인.
kubectl get svc -n {네임스페이스명}
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc-symphony-app NodePort 10.233.0.167 <none> 18095:31300/TCP 6h41m
symphony-api ClusterIP 10.233.16.196 <none> 18082/TCP 22
*위 결과물에 NodePort TYPE의 PORT(S)를 보면 뒤에 31300 포트가 외부에 노출되었다는걸 알수있다.
*외부에서 k8s masterNode의 IP에 31300포트로 요청하게되면 연결되는걸 확인가능하다.
728x90
'클라우드 > Kubernetes' 카테고리의 다른 글
EKS란? (0) | 2022.03.16 |
---|---|
쿠버네티스(k8s) 내장 오브젝트 동작 방법 (0) | 2021.01.11 |
쿠버네티스(k8s) 개념 정리 (0) | 2021.01.11 |
Kubernetes - 사용자 계정 인증 및 권한 인가 (0) | 2020.12.15 |