Setup Prometheus and Grafana to scrap Cilium metrics This will create a new namespace cilium-monitoring kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.15.1/examples/kubernetes/addons/prometheus/monitoring-example.yaml Some warnings… namespace/cilium-monitoring created serviceaccount/prometheus-k8s created configmap/grafana-config created configmap/grafana-cilium-dashboard created configmap/grafana-cilium-operator-dashboard created configmap/grafana-hubble-dashboard created configmap/grafana-hubble-l7-http-metrics-by-workload created configmap/prometheus created clusterrole.rbac.authorization.k8s.io/prometheus created clusterrolebinding.rbac.authorization.k8s.io/prometheus created service/grafana created service/prometheus created Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "grafana-core" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "grafana-core" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "grafana-core" must set securityContext.

TL;DR QueueHandler를 사용해서 process-safe logger를 만들고 LoggerAdapter를 활용해서 매 로그 메시지마다 특정 정보가 자동으로 출력. main.py #!/usr/bin/env python3 import logging import logging.handlers import multiprocessing from worker import worker_process from my_logger import logger_process if __name__ == "__main__": # Configure logging logging.basicConfig(level=logging.DEBUG) # Create a queue for logging log_queue = multiprocessing.Queue() # Create worker processes num_workers = 2 processes = [] for i in range(num_workers): p = multiprocessing.Process(target=worker_process, args=(i, log_queue)) processes.append(p) p.start() # Create a logger process for process-safe loggging p = multiprocessing.

Why not Agollia algolla 는 site indexing 을 위해 Algollia 서버로 정보를 보내는 듯 함. 대신 hugo에 아주 seamless 하게 연동이 되는데. 좀 아쉽네. (Privacy 건은 좀 더 확인해 봐야겠다) Algollia를 잘 결합해서 사용하는 사이트 하나 https://inchan.dev Search를 클릭하면 입력 창의 크기가 자동으로 커져서 결과가 보여지는 창도 적당해서 보기 좋다. Install Pagefind 설치는 npx를 이용해서 설치하거나, cargo build하거나. 혹은 github에 올려져 있는 바이너리 다운받아 설치하거나. 이 중에 마지막 방법 선택

homelab 서버로 사용할 PC를 당근마켓을 통해 구입. 제품 사양에 비해 저렴하고,, 구입 과정도 매끄러워서 기분좋게 구입한 제품이다. 오랜만에 AMD CPU를 사용하는 PC를 사용하게 되었네. 조립 PC를 사본 지가 언제인지. 최근 10년 넘게는 맥만 구입해서 궁금하다. 완성품(특히 애플 노트북)에 비해 좋은 점은 원하는 사양으로 변경할 수 있다는 거 일텐데, 그래서 그 장점을 십분 활용하고자, 중고로 얻어온 제품이 이미 16 GiB 메모리가 실장되어 있지만, 32 GiB를 하나 추가로 구입했다. 다른 건 못해도 RAM Flex라도 해 보자.

서로 다른 pod의 container에서 실행되는 DPDK process들도 다른 경우와 마찬가지로 DPDK runtime config 파일과 hugepage map 파일만 공유하면 hugepage를 공유할 수 있다. 이 때 서로 다른 pod가 같은 DPDK runtime config 파일들과, hugepage map 파일을 공유하기 위해 두 개 pod가 함께 사용할 수 있는 hostPath 를 이용한다. hostPath는 pod가 실행되는 node의 파일 시스템을 이용하여 volume을 만든다. 그러므로 서로 다른 pod가 동일 node에서 실행되는 경우에만 pod가 hugepage를 공유할 수 있다. DPDK runtime config 두 개 pod에서 hostPath 를 이용하여 DPDK runtime config 파일을 공유를 위한 volume을 만든다.

하나의 pod에 2개의 container를 두고, 각각의 container에 primary process, secondary process를 실행하려면 두 개 container에서 실행되는 DPDK process간 runime config 파일과, hugepage map 파일을 공유하는 방법은 다음과 같다. 하나의 pod에 하나의 container만 두는 경우와 달리 두 개의 container가 /var/run/dpdk 위치를 공유해야 하므로, 각 container가 갖는 기본 파일 시스템이 아니라 명시적으로 pod의 volume을 이용해서 파일을 공유해야 한다. 이를 위해 pod spec에 다음과 같은 volume spec을 추가한다. volume: - name: dpdk-config emptyDir: emptyDir에 명시적으로 지정하지 않은 경우 tmpfs를 사용하므로, 위 volume은 tmpfs를 사용하여 생성된다.

How to run DPDK application in Kubernetes environment Kubernetes에서 DPDK application을 실행하기 위해서는 DPDK application이 포함된 container에 runtime config 파일이 저장될 /var/run/dpdk 디렉토리와 hugetlbfs 형태로 hugepage가 존재해야 한다. 이 중 /var/run/dpdk는 container 가 갖는 file system에 생성되는 기본 linux directory인 /var/run 아래 위치하므로, DPDK application이 실행되면서 디렉토리를 생성한다. 반면, hugetblfs 디렉토리은 kubernetes의 volume 에서 제공하는 emptyDir을 사용하면 Pod와 lifecycle을 함께 하는 hugepage를 만들어 사용할 수 있다. Container에서 hugepage를 할당받기 위해서는 다음과 같이 container spec에 요구하는 hugepage 크기를 명시한다.

Basic use of hugepage DPDK application이 hugepage를 사용할 때 다음과 같은 2가지 디렉토리를 사용한다. DPDK runtime config files /var/run/dpdk 로 고정된 경로를 사용요 DPDK 에서 hugepage를 어떻게 사용하는 지에 대한 meta data를 저장 hugepage map hugepage를 사용하기 위해 hugetlbfs 를 이용할 때 생성하는 hugepage map 파일들이 위치한 곳. DPDK는 이곳에 hugepage의 단위 크기를 갖는 file을 생성하고, mmap()을 사용하여 hugepage를 접근 만일 시스템에 2개 이상의 hugetlbfs가 마운트된 위치가 있는 경우 DPDK process를 실행할 때 --huge-dir 옵션을 사용하여 특정 위치를 사용하도록 할 수 있다.

문제점 Traefik 로그에 time 정보가 제대로 나오게 하려면 helm chart에 환경 변수에 TZ를 설정해도 로그 시간이 제대로 나오지 않음. 192.168.0.101 - - [06/Jan/2022:1:18:17 +0000] "GET /ping HTTP/1.1" 200 2 "-" "-" 100 "ping@internal" "-" 0ms env: - name: TZ value: Asia/Seoul kubectl describe 명령으로 확인하면 환경변수가 제대로 설정된 것으로 나옴 Environment: TZ: Asia/Seoul 해결책 https://doc.traefik.io/traefik/observability/access-logs/#time-zones 위 페이지를 보니 다음과 같이 몇 가지 설정을 해야 한다고. Traefik will timestamp each log line in UTC time by default.