ParanBlog.

{ "asdf": "bsdf", "csdf": [ { "dsdf": "esdf", "fsdf": "gsdf" }, { "hsdf": "isdf", "jsdf": "ksdf" } ]}여기에서 "gsdf"를 추출하는 JSON Path: $.csdf[0].fsdfCriteria[1, 2, 10, 476, 388, 3287]에서 40 이상인 수만 추출하기: $[?(@ >= 40)]$: root element. root element상의 list이므로 거기에 []?(): check if@: each element에서 40, 476이 아닌 수만 추출하기: $[?( @ nin [40, 476])]WildcardLists["Apple", "Google",..

지도를 그려서, 모든 오브젝트와 링크를 확인해본다(DB Pod) |DB-Service> (Web Pod) | Web-Service> User웹서비스일 경우, curl로 web-service:port를 확인해본다Failed to connect: Connection timed outweb-service의 Selector와 Endpoint 등을 확인해본다kubectl describe service web-servicePod의 label과 Service의 Selector가 일치하는지 확인해본다Pod가 running state인지 확인해본다, kubectl get pod에서 RESTARTS가 누적되고 있는지 확인한다,kubectl describe와 kubectl log로 상태를 확인한다(컨테이너가 무한재시작되고 ..

etcd는 분산 시스템을 채용하는 K-V 데이터베이스임K-V 데이터베이스는 k-v 페어 여러 개로 구성된 페이지로 구성된다쿠버의 여러 컴포넌트 중 etcd와 직접 통신하는 컴포넌트는 kube-apiserver뿐이다etcd 서버는 1개만 존재할 수도 있지만, 여러 개의 분산형 구조를 할 수도 있음 (High Availability etcd 구성)이 경우 모든 etcd 서버에 같은 데이터가 저장됨하지만 어떻게?우선, Read operation의 경우, 모든 서버에 저장된 데이터가 동일하게 유지되므로, 아무 서버에서 Read를 하든 상관없음하지만, Write 시에 데이터를 어떻게 consistent하게 유지할 수 있는가?여러 etcd 서버 중 하나를 leader로 선출하여, write 작업이 들어오면 전부 l..

시나리오 1: 온프레다음은 MySQL Pod와 (3개의 Replica된 Pod으로 구성된) Deployment로 구성된 간단한 웹사이트의 구성이다.MySQL과 웹서버 간의 통신을 위해 mysql-service ClusterIP Service를 생성웹서버의 외부 노출을 위해 wear-service NodePort Service를 생성이 구성은 작동하지만, 문제가 있다포트 38080을 접속하는 사용자가 꼬박꼬박 입력해주어야함80같이 낮은 포트는 NodePort Service에 할당할 수가 없다!따라서 38080 앞에 80을 listen하는 리버스프록시를 추가해서 사용자 접속을 받은 뒤 38080으로 넘겨주는 구성으로 바꿀 수 있을것이다. 시나리오 2: GCP위와 같은 온프레 구성이 아니라, GCP같은 퍼블릭..

쿠버는 기본적으로 클러스터를 설정할 때 내장 DNS 서버를 디플로이한다단, 수동 구축했을 경우 이것도 수동으로 설정해주어야함클러스터의 다른 노드에 Pod A와 B가 있다고 하자 A: IP 10.244.1.5B: IP 10.244.2.5Service b-service: 10.107.37.188IP 대역이 다르므로, A와 B는 서로 다른 노드에 있을 것이다 - 하지만 별 상관이 없다, 쿠버가 정상적으로 설정되었다면 모든 클러스터 내의 Pod끼리는 스스로의 IP로 통신을 할 수 있어야 한다하지만, 대부분의 경우, b에 대한 Service를 만들어 이것으로 통신을 한다 (이 경우 b-service (NodePort, etc.))Service가 생성되면, 쿠버 DNS 서비스가 해당 서비스에 대한 레코드를 생성한다..

쿠버에서 Pod이 다른 Pod와 자유롭게 통신할 수 있도록 되어 있다고 해도, 이걸 직접 통신하는 데 사용하는 일은 잘 없다보통은 Service를 사용하는 게 일반적 예를 들어 같은 노드에 있는 Pod A (10.244.1.2)와 Pod B(10.244.1.3)이 있다고 하자Pod A에서 Pod B에 접속할 때, 10.244.1.3으로 그냥 IP 입력해서 접속하는 것도 가능은 하다.하지만 보통은, B 접속용 서비스를 생성하고 그 서비스의 이름이나 IP로 접속을 한다서비스는, Pod이 어떤 노드에 있던간에, 클러스터의 모든 노드에서 접속이 가능하다(ClusterIP): 클러스터 내부에서만 접속이 가능하다클러스터 내부에서만 접속 가능하면 되는 시나리오 (DB 서버라든가)에 적합(NodePort): Clust..

Container Runtime은 컨테이너의 추가/삭제마다 Network plugin을 불러야 한다.Kubelet 서비스를 보면, ExecStart=/user/local/bin/kubelet \\... --network-plugin=cni \\ --cni-bin-dir=/opt/cni/bin \\ --cni-conf-dir=/etc/cni/net.d \\...처럼 되어 있다.주의쿠버 1.24 이전까지는 kubelet에서 cni-bin-dir과 network-plugin 파라미터를 통해 CNI 플러그인을 관리하는 것이 가능했으나, 이는 쿠버 1.24에서 삭제되었다!/opt/cni/bin에는 bridge, dhcp, flannel, host-local 등 CNI Network Plugin의 execut..

None네트워크가 없다. 외부로 통신 불가.Host호스트의 네트워크에 그대로 노출한다. 컨테이너 안에서 80을 열면 호스트의 IP로 80에 접근해서 내용을 볼 수 있다.두 개의 컨테이너가 같은 포트를 열 수는 없다.Bridge기본값으로 172.17.0.0/24의 브리지 네트워크가 생성되어 내부 private network 주소를 할당받는다.기본값으로 "bridge"라는 이름의 네트워크가 생성된다. docker network ls를 찍어 보면 Network 이름이 bridge로 되어 있으나, 실제로 호스트에서 생성되는 네트워크 이름은 docker0이다.Docker에서docker inspect 명령의 NetworkSettings 부분을 보면, 컨테이너의 네트워크 네임스페이스를 볼 수 있다.ip link 명령..

Network Namespace 개념은 리눅스 컨테이너에서 네트워크 분리를 위해 사용되는 기술이다.컨테이너는 Process Namespace로 격리되어 있어서, 컨테이너 위에서 돌아가는 프로세스만 볼 수 있다. 컨테이너 위에서 ps aux를 찍어 보면 CMD로 구동되는 프로세스의 PID가 1임을 볼 수 있다.하지만 호스트에서 ps aux를 찍어 보면, 해당 프로세스의 PID가 전혀 다른 값으로 들어가 있는 것을 볼 수 있다.즉 같은 프로세스가 컨테이너 내부와 외부에서 전혀 다른 PID를 가지고 있는 것이다.네트워크 네임스페이스도 비슷하다. 호스트에는 Routing 및 ARP Table이 존재한다.하지만 컨테이너 생성 시에는 네트워크 네임스페이스가 생성되며, 컨테이너 내부에서는 호스트의 네트워크 관련 정보..

Persistent Volumes (PV)Persistent Volume은 Storage Volume들의 클러스터 단위 pool이다. 클러스터의 사용자는 이 풀에서 스토리지를 선택하여 사용할 수 있다.apiVersion: v1kind: PersistentVolumemetadata: name: pv-vol1spec: accessModes: - ReadWriteOnce # ReadOnlyMany | ReadWriteOnce | ReadWriteMany capacity: storage: 1Gi hostPath: # 이 옵션을 Production에서 실제로 사용해서는 안됨 path: /tmp/data awsElasticBlockStore: # 혹은 외부 Storage Provider 사용 ..