devstudy

metallb를 가이드에 따라 https://metallb.universe.tf/installation/ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.7/config/manifests/metallb-native.yaml 상기와 같이 설치 하고 1.24 기준 설치 했을때 metallb의 address-pool을 configmap에 정의해서 사용했는데 1.25.에서 정의하고 사용할려고 하니 서비스 type이 load balnacer인 애들이 ip를 매핑을 못하고 pending 에 걸려 있었다 결국 speaker 들이 못받아 오는거 같은데 결국 configmap을 안 보는거 같아서 사이트에 들어가서 config 설정을 보니까..

helm을 통해 argo 설치 를 하고 정상 접근 후 제일 먼저 확인 하는 작업이 cluster의 상태를 보는건데 디폴트 cluster는 자기 자신을 바라본다 kubernetes.default.svc 가 주소이고 version 정보와 connection satus 가 나타나는데 이게 연결이 안된것 처럼 unknown 이다....k8s가 1.24인가? 부터 네임스페이스를 만들면 기본으로 만들어주던 account와 secret이 secret은 보안 정책상 더 이상 안말들어준다. 이것 때문인지 굉장히 삽질을 하다가 저 상태가 app 이 아무것도 배포가 안된 상태에서는 저렇게도 표시가 된다고 하여 테스트로 app 배포를 하니 정상으로 나온다.... 구글 검색하다가 어떤 포럼에 저 내용이 있어서 확인을 했다.....

maven 으로 프로젝트 할때 프로젝트 복사 붙여 넣기 가끔 하는데 maven은 전혀 문제가 없지만 gradle 은 문제가 붙여넣기 프로젝트를 아예 인식 못하고 eclipse gradle duplicate root element console에 저런 에러만 나온다 이유는 프로젝트 root에 있는 settings.gradle 파일에 rootProject.name = '[프로젝트명]' 이게 달라서 그렇다...프로젝트 세팅 파일은 원래 안걸드고 하는데 gradle은 관여 되는 거 같다 복사 할때 옵션으로 update를 켜도 저건 안 바뀐다 즉 프로젝트명 rename 해줘도 저걸 직접 수정해야 된다는 소리 시대의 흐름이 maven에서 gradle로 넘어가는거 같지만 아직까진 장점을 크게 찾기가....어렵다

pv를 생성 해서 pvc를 동작할때 파일 이관을 할 경우 클라우드 특성상 기존에 가지고 있던 권한, 소유자 정보등이 중요하다 그래서 그냥 cp -r 옵션으로는 명령을 실행한 사용자의 권한 정보가 박히기 때문에 pod 동작 보장이 어렵다 그래서 습관적으로 라도 cp -rap 옵션을 줘서 원본의 모든 정보도 다 같이 가져와야 된다. 이게 잘 못 되면 피곤하게도 777 로 박는 경우과 과거엔 꽤 있었다.

k8s를 gitops 형태로 꾸밀때 deployment 파일에 선언하는 내용중에 namespace나 이런 내용은 빼야 argo에서 배포 위치 선택을 자유롭게 할 수 있다 일반 pod의 경우는 서비스 선언을 하고 이 서비스가 돌아가는 pod를 선택 하게 하는게 일반적인데 statefulset 경우는 depoyment에서도 serviceName을 명시적으로 선언해 줘야지만 연결이 정상적으로 된다 spec: replicas : 1 serviceName: [서비스 명]

실제 버전 다운그레이드는 쉽지는 않고 흔하지도 않지만 k8s 에 설치한 sw같은 경우는 image tag 만 바꾸면 간단히 변경이된다. 우연한 기회에 테스트를 진행할 일이 있어서 버전을 변경하고 기동을 했더니 redo log 파일에 대한 버전 미스가 로그로 바로 올라오고 구동안된다. k8s에 db 올리면 pvc 설정을 잡아 줘야 되니까 해당 pvc 로 이동후 ib_logfile[x] 파일을 다 지워준다. db마다 redo 설정에 대해 다르겠지만 마리아 같은 경우 편하게 그냥 저거만 삭제 하면된다. 그렇게 하고 재기동 하니 하위 버전도 바로 구동이 되었다 반대로 하위에서 상위는 별다른거 없이 바로 구동 되었다. 다른 사이트에서도 마리아 구동 안될때 저거 위치 옮겨 두고 구동하니 바로 되었다 자기가 구동할때..

istio를 통해 ingressgateway 서비스에서 match 순서가 중요하다 아래 처럼 prefix가 / 먼저 나오면 이후에 나오는 거는 못찾는거 같다 좀더 테스트 해봐야 하지만 기존 route랑 다르게 websocket 확인할 일이 생겨 적용하다가 / 보다 위에 적용해서 match를 순서를 올리니까 정상 되는거 방금 전에 확인 했다 참고로 apiVersion 사용하는거는 v1beta1 이다 ===아래 안됨=== apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: [vs명] spec: hosts: - "*" gateways: - [gw명] http: - match: - uri: prefix: / route: - ..

k8s pod 가 기동중이고 내부에 있는 파일을 밖으로 꺼내서 작업해야 될때 혹은 반대의 경우가 필요한 경우 사용 kubectl cp [네임스페이스]/[pod명]:[내부경로]/[파일명] [외부서버경로]/[파일명] exec)tomcat war 파일(네임스페이스명: tomcat, pod 명 : tomcat-aadd, 파일명:agent.war) kubectl cp tomcat/tomcat-aadd:/usr/local/tomcat/webapp/agent.war /home/user1/agent.war 디렉토리통으로 할경우에도 됨 반대로 외부 파일을 pod 안으로 넣을때는 kubectl cp [외부서버경로]/[파일명] [네임스페이스]/[pod명]:[내부경로]/[파일명]

k8s를 구축 운영하기 위해 devops 형태의 ci/cd를 많이 구축하고 다양하게도 구축한다. 2022년12월 29일 현재 gitlab+tekton+argo 형태이고 jenkins도 있다 일단 gitops관련해서는 따로 설명이 필요하지만 현태 gitops 형태로 운영하고 있다. rancher와 gitops형태로 구성되게 되면 더 이상 외부 작업자 혹은 운영관리를 위해 cli 작업은 불 필요해지게 된다. 그런 형태의 아키텍처를 구축해서 진행하다 보니 필수 적으로 helm 과 마주하게 된다. 결국은 설정 변경을 오직 git에서만 관리하면 되게 되는데 일반 helm은 대부분 설명이 cli 바탕으로 하게 된다. helm 차트는 다양하게 저장소를 선택 할 수 있는데 tgz 형태의 패키지 압축으로 관리할 수 있는..

온프레미스 환경은 일반적으로 폐쇄망으로 진행되기에 내부 사설 레포지토리인 하보를 많이 설치한다. k8s가 1.24 부터 dockershim 을 제거 함으로 각 노드에 업글 작업을 하면서 docker 자체도 삭제를 했다 내부에서 이미지 작업을 할 경우 사설 저장소에 push 하기 위해선 태그 명도 사설저장소주소/이미지:태그 이런 형태로 올리는데 도커가 있을 경우에는 간단하게 docker login 한 다음에 $docker push 저장소 주소/이미지명:태그 이런 형태의 명령어로 쉽게 업로드를 했었다. 도커를 제거후에는 ctr(containerd CLI)로 처리 해야 되는데 몇몇 변경점이 있다. 도커가 존재 할때는 docker ps docker images 이런 명령어로 이미지를 확인 가능 했지만 ctr 에..