BEOM_IT

stream editorsed는 "stream editor"의 약자로, 파일 편집을 자동화하는 명령줄 유틸리티입니다.주로 파일 내용에서 특정 패턴을 찾아서 다른 패턴으로 바꾸는 작업에 사용됩니다.기본 예제sed [option] [command] [file]옵션설명-p 행을 출력한다(-n 옵션과 함께 사용할 경우, 선택된 행만 출력한다.)-d 선택한 행을 삭제한다.-f 파일 안의 내용을 실행한다.'s/가/나/g''가' 문자열을 '나' 문자열로 대체한다.-e다중 편집을 한다.-qsed를 종료한다.연산자메타문자의미예제설명^라인의 처음/^tomcat/tomcat으로 시작하는 모든 라인들$라인의 끝/tomcat$/tomcat로 끝나는 모든 라인들.하나의 문자 매칭, 하지만 newline 문자는 제외/t….t/ *..

oc 명령어를 사용해 ns를 조회하는 권한이 없을때 oc get ns와 oc get ns [네임스페이스명]을 입력했을 경우 차이! oc get ns 명령어는 현재 사용자가 조회 가능한 모든 네임스페이스를 출력합니다. 따라서 현재 사용자가 네임스페이스 조회 권한이 없는 경우에는 oc get ns 명령어를 실행해도 어떤 네임스페이스도 출력되지 않습니다. 반면에 oc get ns [네임스페이스명] 명령어는 지정된 네임스페이스의 정보를 출력합니다. 따라서 현재 사용자가 지정된 네임스페이스의 조회 권한이 없더라도 해당 네임스페이스에 대한 정보를 출력할 수 있습니다. 그러나 해당 네임스페이스를 제어하거나 수정할 수 있는 권한이 없는 경우에는 오류 메시지가 출력됩니다.

쿠버네티스에서 노드(Node)는 애플리케이션이 실행되는 호스트 머신입니다. ex)VM,물리적서버 노드는 일반적으로 가상 또는 물리적인 서버이며, 애플리케이션의 실행을 담당하는 작업자 노드(Worker Node)와 쿠버네티스 시스템 컴포넌트를 실행하는 마스터 노드(Master Node)로 구성됩니다. 노드에는 컨테이너(Container)가 실행됩니다. 컨테이너는 애플리케이션을 실행하는 단위이며, 하나의 노드에는 여러 개의 컨테이너가 실행될 수 있습니다. 노드에 실행되는 컨테이너는 독립적인 공간을 가지고 있으며, 다른 컨테이너나 호스트 머신에서 실행되는 프로세스와 격리되어 있습니다. 컨테이너는 가볍고 빠르게 배포, 확장, 관리할 수 있으며, 여러 컨테이너를 동일한 노드에서 실행하면 노드의 리소스를 효율적으로..

카나리 배포(Canary Deployment)는 새로운 버전의 애플리케이션을 릴리스하기 전에 먼저 일부 사용자에게 테스트를 진행하는 방식 모든 사용자에게 동일한 새로운 버전의 애플리케이션을 릴리스하는 대신, 일부 사용자에게 새로운 버전의 애플리케이션을 제공하고 이를 모니터링하며, 안정적인 상태인 경우 나머지 사용자에게 롤아웃 카나리 배포는 예상치 못한 버그, 성능 문제 등을 빠르게 감지하고 대처할 수 있으며, 전체 애플리케이션의 안정성을 높이는 데 도움이 됩니다. 이를 위해서는 새로운 버전의 애플리케이션과 이전 버전의 애플리케이션이 함께 실행되어야 합니다. 카나리 배포를 구현하기 위해 로드 밸런싱, 라우팅 규칙, 그리고 롤백 전략 등을 설정할 수 있는 컨트롤러를 사용 Istio Linkerd etc...

그물 형태의 통신이나 경로를 제어하는 개념 애플리케이션의 서로 다른 부분이 서로 데이터를 공유하는 방법을 제어하는 ​​방법 대부분 트래픽 컨트롤 기능 ex) 트래픽의 99%는 이전 이미지로 기동중인 디플로이에 전송하고 1%를 신규 디플로이에 전송해 서비스 환경에 단계적으로 카나리 배포 가능 카나리=배포 전 일부 인원 테스트 기능 트래픽 시프팅 서킷 브레이커 에러 반환 폴트 인젝션 속도 제한 재시도

오픈소스 소프트웨어 C++로 만들어진 엔보이를 사용하여 쿠버네티스 클러스터에 서비스 매시를 구현 서비스매시: 그물 형태의 통신이나 경로를 제어하는 개념 istio는 서비스 매시를 쿠버네티스 클러스터 외부의 VM이나 물리서버로 확장 여러 클러스터를 istio를 연계함으로써 서비스 매시를 구성한 멀티 클러스터 환경 구축 이스티오 아키텍처 이스티오는 각 파드안에서 Sidecar로 Envoy 프록시가 들어가 있는 형태 마이크로서비스간 통신은 엔보이를 반드시 통과 Envoy Sidecar 작동 클라이언트 -> envoy -> app -> envoy -> envoy -> app

우선 순위 : BestEffort > Burstable > Guaranteed 컨테이너의 리소스 설정으로 결정됨 Guaranteed (보장, 개런티드) 모든 컨테이너에 requests, limit 설정 request, limit의 memory, cpu 모두 설정 각 컨테이너의 request와 limit의 memory, cpu 값이 같음 apiVersion: v1 kind: Pod metadata: name: qos-demo namespace: qos-example spec: containers: - name: qos-demo-ctr image: nginx resources: limits: memory: "200Mi" cpu: "700m" requests: memory: "200Mi" cpu: "700m"..

kubernetes 에서 $ kubectl edit 명령으로 Deployment 설정 변경을 시도. 새로운 volume과 configMap을 추가한 후 :wq 명령으로 저장하고 나왔는데 edit 편집내용이 저장되지 않고 오류가 발생함. error: deployments.apps "unbound" is invalid A copy of your changes has been stored to "/tmp/kubectl-edit-4ssjm.yaml" error: Edit cancelled, no valid changes were saved. 이 내용을 구글링 한 결과 kubernetes의 버그라는 말과 함께 Deployment에 설정되어있는 imagePullPolicy: 부분을 모두 주석처리 해준 뒤 저장해보면..

$ oc get ns -> ns 조회 $ oc describe no -n [ns] ->특정 ns의 node를 조회 $ oc describe no | more -> node 조회(몇 개 없다면..) Allocated resource: 항목의 CPU/Memory 의 Requests , Limit을 확인후 배포 결정 ex) node 2개 (12core/24Gi) A-node 6core/12Gi 사용중(50%/50%) $ oc adm top no -n [ns] 조회시 CPU/Memory가 (6%/46%)사용중 이럴경우 50%만 허용

CPU/MEM 값 조회 kubectl top pods -n [ns 명] or kubectl get hpa -A Pod 스펙 변경 pod의 cpu/mem를 수정할 때 사용 requests는 생성 시 필요한 최소 자원이고 최대 limits 까지 자원을 사용할 수 있다. kubectl edit deploy -n [ns명] [deploy명] resources: limits: cpu: 100m memory:500Mi requests: cpu:100m memory:500Mi 신규 Pod 배포시 빠른 배포 $ kubectl get replicaset -n [ns명] 레플리카 조회 후 수정 $ kubectl edit replicaset -n [ns명] [기존replicaset] spec: replicaset:0