반응형

Active - Stanby 구성으로 진행 하려 하였으나

F/W에서 내부에서만 접속 가능한 Stanby IP로 스페어 2차 도메인으로 구축을 한 뒤, HTTPS 리턴 값이 죽으면 Name Server에서 Domain Ip만 자동으로 바꿔주는 것이 크로스체크, 안정성이 더 우수하다는 판단으로 이렇게 적용 하려한다.

 

반응형
반응형

AH01114: HTTP: failed to make connection to backend:

 [proxy_http:error] 

체크 할 것

도메인 및 로컬에 curl~  도메인:포트, 로컬:포트

curl infra.clinomics.co.kr:1126  -> 소스 못 받음

curl localhost:1126    ->  소스 받음

 

 

webpac 이슈 같은 냄새가~~

proxy 설정 바꿔주었음

도메인:포트로 백앤드와 아파치 포트리다이렉션을 로컬로 바꿔주었다.

겁나 잘 뜬다 !!! 

반응형
반응형

스크립트 만들고

/etc/init.d/스크립트

스크립트 만들고

update-rc.d start.sh defaults

defaults : runlevel 3,5

실행순서/종료순서는 지정하지 않아도 된다.

- 만약 등록된 것을 지우고 싶다면

update-rc.d -f start.sh remove

재부팅 확인 고고

 

반응형

'server eng' 카테고리의 다른 글

리눅스와 윈도우 폴더 연동[mount smb cifs]  (0) 2023.06.03
linux ubuntu smb user 만들기 10초~컷  (0) 2023.06.03
Ubuntu 20.04 helm install  (0) 2023.04.14
fire wall j-web juniper  (0) 2023.04.13
fire wall j-web juniper  (0) 2023.03.28
반응형

맛간의 쿠버네티스! (본론 -> 스크롤 내려서 A. 부터 보시오 )

2020년 하반기 (쿠버v1.24)부터는 도커심 기본 지원 중단을 때렸습니다. (도커 공부하던 사람은 마이 아푸네요...)

 

하지만, BUT, 그러나 언제나 애니웨이 !!  솟아날 구멍은 있다

 

개발 도구 사용 및 쿠버네티스를 지원하는 컨테이너 런타임을 사용!

 

미란티스(Mirantis)에서 개발한 도커심의 외부 대체품인 크리도커드(cri-dockerd)

 

개발은 여전히 도커로 진행하되, 이를 실행하는 컨테이너 런타임만 다른 것으로 바꾸면 큰 불편 없이 익숙한 환경에서 쿠버네티스를 사용할 수 있어요!

Kuber#1~3 까지 이미 모든 준비를 했기에, 그냥 궈궈 마라샹 궈 하면 되는 상황인데 
갑자기 생각나서 적어봤슴네다.

 

아래 구조로 진행 궈궈

 

 

A. 마스터 노드

master node에서

sudo kubeadm init

A-a. .if error?

애러가 ~ 나셨나요 ???

[ERROR CRI]: container runtime is not running

-해결방법-

/etc/containerd/config.toml 열어서  disabled_plugins 항목에서 CRI  주석 처리~

systemctl restart containerd

sudo kubeadm init

내래 애러 따위 삽질로 퍼내겠습네다. 

 

 

 

마스터 노드에서 토큰 값과 해시를 조회 한다.

kubeadm token list;openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
;

 

 

Token: 9v87ma.w7rek3zwwfdmrvqx

Hash: cc17337904d4c3f7bbae5d8d2de5a479b2829677603d5c80e345de069c72f980

 

A. 워커노드 kubeadm join

폰번호 땃으니 이제 쪼인하자

sudo kubeadm join 210.216.165.207:6443 --token 9v87ma.w7rek3zwwfdmrvqx --discovery-token-ca-cert-hash sha256:cc17337904d4c3f7bbae5d8d2de5a479b2829677603d5c80e345de069c72f980

 

HOXY 애러가 낫나유 ?https://soowim.tistory.com/73

 

 

마스터  노드에서 확인.

kubectl get nodes -o wide

 

노드를 확인 할 수 있다. 

나이 따~

 

이렇게 여러대의 서버를 각각 용도를 나누어 하기와 같이 구성이 가능하다.

간략 설명  쿠버네티스 마스터 노드와 워커 노드

마스터 노드(컨트롤 플레인)에서는 클러스터를 관리하고 클러스터의 기능을 실행한다. 단일 마스터 노드에서 실행하거나 여러 노드로 분할  복제되어 고가용성을 보장할  있는 여러 구성요소로 구성   있다.

·       API Server : 사용자와 컨트롤 플레인과 통신하는 쿠버네티스 API

·       Scheduler : 애플리케이션을 예약하는 스케줄러로, 배포 가능한  구성 요서에 워커 노드 할당을 담당

·       Control Manager : 구성 요소 복제, 워커 노드 추적, 노드 장애 처리  클러스터 기능을 실행

·       etcd : 클러스터 구성을 저장하는 분산 데이터 스토리지  

 

워커 노드는 컨테이너화된 애플리케이션을 실행하는 시스템으로 서비스 실행, 모니터링을 제공한다.

·       Kubelet : API 서버와 통신하고 노드에서 컨테이너를 관리

·       Kube-proxy : 애플리케이션 구성 요소 간에 네트워크 트래픽을 분산하는 쿠버네티스 서비스 프록시

 

 

반응형

+ Recent posts