devstudy

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 에..

nginx 로 proxy를 써서 back-end로 접속을 던질때 nginx.conf 파일에 location 설정시 특정 패턴의 context-path를 잡을때 사용 ex) host로 부터 요청 받는 주소의 context-path 가 /lab** 로 시작 한다고 할때 location ~ /lab(.*)/(*) { proxy_pass http://[목적지 주소]; proxy_http_version 1.1; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; } 식으로 하면 되고 저기서 중요한건 location 뒤에 오는..

로그 수집기 fluentd 에서 pos_file 경로 지정이 뭔지 궁금해서 확인 해보니 position 관련된 파일이고 tail 을 통해 읽어 들인 로그에 대해서 어디까지 읽었는지에 대한 위치 저장값을 가진 파일이다. 결국 이게 없으면 fluentd를 재시작 했을때 로그를 처음부터 읽어서 저장 할 경우 중복 발생이 된다. log.pos 로 생성되는 파일의 용도가 이거다

1.23->1.24로 가기위해 dockershim을 제거하고 containerd 만 기동하는데 rancher agent 가 기동이 안되고 이미지를 자꾸 못찾는다고 나온다. v2.6.6 사용하는데 이미지 태그명이 rancher/rancher-agent:v2.6.6 이런식인데 docker.io/rancher/rancher-agent:v2.6.6 로 바꿔줘야 정상적으로 된다. 접두에 docker.io를 붙여야 되다니.. 외부 인터넷이 가능한 환경에서는 자동으로 되던데 폐쇄망에서는 다른 참조가 걸려서 그런지 정확한 이유는 잘 모르겟다.

현재 k8s가 1.23 -> 24 upgrade 중인데 dockershim 제거 되고 cotainerd 만 사용하게 변경중에 기존 docker 를 이용해 push 된 이미지가 containerd 만으로 pull 을 할때 archive/tar: invalid tar header: unknown 이런 오류가 발생해서 pod 정상 동작이 안된다. 로그를 좀 확인해 보면 pod를 가져오기 위해 layer를 가져오는 과정에서 발생된 거 같았고 spring boot 로 된 pod 의 dockerfile의 from에 사용중인 jdk가 의심가서 jdk 를 노드에 개별적으로 pull 한뒤에 하니까 된다. 해외 이슈로 찾아본 결과 그런 다중 레이어에서 아카이빙이 tar.gz 로 올라가고 이걸 containerd 가 가져올..