sejong.jeonjo@gmail.com

NUMA with Linux

https://lunatine.net/2016/07/14/numa-with-linux/

https://frankdenneman.nl/2016/07/07/numa-deep-dive-part-1-uma-numa/

HugePages

https://luis-javier-arizmendi-alonso.medium.com/enhanced-platform-awareness-epa-in-openshift-part-i-hugepages-a28e640fabf6

CPU Pinning

https://luis-javier-arizmendi-alonso.medium.com/enhanced-platform-awareness-epa-in-openshift-part-ii-cpu-pinning-8e397fc9fe08

NUMA Topology Awareness

https://luis-javier-arizmendi-alonso.medium.com/enhanced-platform-awareness-epa-in-openshift-part-iii-numa-topology-awareness-180c91c40800

SR-IOV, DPDK, RDMA

https://medium.com/swlh/enhanced-platform-awareness-epa-in-openshift-part-iv-sr-iov-dpdk-and-rdma-1cc894c4b7d0

Openshift 4.10 인증, 권한에 관해 자세히 알고 싶다면, 아래 Red Hat 공식 Web Docs를 읽어 보자!

(한국어 문서)

https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.10/html-single/authentication_and_authorization/index

(영어 문서)

https://access.redhat.com/documentation/en-us/openshift_container_platform/4.10/html-single/authentication_and_authorization/index

(1)  OCP의 Web Console에서 오른쪽 위에 있는 "계정 이름"을 클릭한다.

(2)  [ Copy login command ]을 클릭하면, 새 브라우저 창이 뜬다.

(3)  위 화면에서 [ Copy login command ]을 클릭하면 아래와 같은 브라우저 창이 새로 열릴 것이다.
       이 때 [ Display Token ]을 클릭한다.

(4)  아래와 같이 OCP API Token과,  oc login 명령 예시가 보일 것이다.

(5)  아래와 같이 curl로 TOKEN 값을 이용해서 API를 호출할 수 있다.

$  curl -X GET -H "Authorization: Bearer sha256~v9-kYQ_N...중간 생략...z1X5UA" https://api.myasset.cloud:6443/api/v1/namespaces/openshift-etcd/pods --insecure

아래와 같이 `oc edit` 명령으로 insecureRegistries 항목에 Container Image Registry 주소를 추가한다.

$  oc edit image.config.openshift.io/cluster

... 중간 생략 ...

spec:
  registrySources:
    insecureRegistries:
    - aaa.cloud.net:8080
    - bbb.cloud.net:5000

... 중간 생략 ...

$

그리고 kubernetes node에서 사람이 podman 명령어를 직접 사용하는 경우도 있기 때문에 아래와 같이 /etc/containers/registres.conf 파일에도 registry 주소를 추가한다.

##
## File Path:  /etc/containers/registries.conf
##

$  cat  /etc/containers/registries.conf

... 중간 생략 ...

[registries.insecure]
registries = ['aaa.registry.net:8080', 'bbb.registry.net:8080']

... 중간 생략 ...

$

장황한 설명보다는 예제가 이해가 쉬울 듯하여, 아래의 예제 코드를 작성했다.

Case:  Kubernetes Cluster 외부에서 Kubernetes Cluster 내부 Service에 접근

아래와 같은 Server, Client App의 구성을 가정하고 아래 예제를 따라해본다.

• Server App 위치: Kubernetes Cluster 내부
• Client App 위치: Kubernetes Cluster 외부

API 접근용 TOKEN 값을 알고 있다면, 바로 아래 예제를 따라서 수행하면 된다.

$  cat curl-pod-list.sh
##
## Create a Pod on myspace namespace
##

TOKEN=$(oc whoami -t)
ENDPOINT="https://api.ocp4.mycluster.io:6443"
NAMESPACE="myspace"

echo ""
echo "TOKEN:     $TOKEN"
echo "ENDPOINT:  $ENDPOINT"
echo "NAMESPACE: $NAMESPACE"
echo ""


##
## Get Pod list in a namespace
##

RESPONSE_FILE=./curl-pod-list-response.json

curl -v -k -o $RESPONSE_FILE \
    -H "Authorization: Bearer $TOKEN" \
    -H 'Accept: application/json' \
    $ENDPOINT/api/v1/namespaces/$NAMESPACE/pods


cat $RESPONSE_FILE


echo ""
echo "====================================================="
echo "                     Summary                         "
echo "====================================================="
echo ""

jq '.items[] | {PodName: .metadata.name, PodIP: .status.podIPs, StartTime: .status.startTime, Node: .spec.nodeName}' curl-pod-list-response.json

$

Case:  Kubernetes Cluster 내부에서 Kubernetes Cluster 내부 Service에 접근

아래와 같은 Server, Client App의 구성을 가정하고 아래 예제를 따라해본다.

• Server App 위치: Kubernetes Cluster 내부
  • Server는 Elasticsearch API Server 역할
• Client App 위치: Kubernetes Cluster 내부

즉, Cluster 내부에서 Pod간 통신이라고 가정한다.

[ 참고 ]
API 접근용 TOKEN은Pod 내부의 /var/run/secrets/kubernetes.io/serviceaccount/token 파일에 있다.
ServiceAccount 별로 Token을 생성하고 서비스 접근 권한을 부여하기 때문에 Client App 역할을 하는 Pod가 사용하는 ServiceAccount에게 Server Pod의 Service에 접근할 수 있도록 Role을 Binding해줘야 한다. 

$  cat clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-my-service-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: system:serviceaccount:my-namespace:my-service-account
  
  $  kubectl apply -f clusterrolebinding.yaml

#!/bin/bash


##
## Run this script in my example pod !
##
##  1) Jump into my example pod
##     $  kubectl exec -n my-namespace -it my-example-pod -- bash
##
##  2) Run this script in the above pod
##     $  chmod +x run-es-query-in-container.sh
##     $  ./run-es-query-in-container.sh
##


TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
ENDPOINT="https://elasticsearch.openshift-logging:9200"
RESPONSE_FILE=curl-es.json

rm  $RESPONSE_FILE

echo ""
echo "TOKEN:     $TOKEN"
echo "ENDPOINT:  $ENDPOINT"
echo ""


curl -k -o $RESPONSE_FILE \
    -H "Authorization: Bearer $TOKEN" \
    -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -d '{ "query": { "match": { "message": "cm-apiserver" } } }' \
    $ENDPOINT/infra-000094/_search?size=3



jq ".hits.hits[]._source | { kubernetes, message }" $RESPONSE_FILE

https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.6/html/networking/add-pod

https://dramasamy.medium.com/high-performance-containerized-applications-in-kubernetes-f494cef3f8e8

Kubernetes cluster 운영 환경에서 Pod간 주고 받은 IP packet을 tcpdump하는 방법을 알아보겠다.

방식 A:  Container 내부에 tcpdump 프로그램을 설치하고, Container 내부에서 직접 tcpdump 명령을 수행

$  kubectl exec  -n my-namespace  my-pod  -c my-container  -it -- bash
(In-Container) $  apt install -y tcpdump 
... 중간 생략 ...

##
## 참고: Kubernetes Pod 내부의 기본 NIC은 eth0이다.
##      만약, Multus CNI를 사용해서 Multi-NIC을 사용하는 경우라면,
##      eth0 이외에 net1, net2 같은 이름으로 NIC이 있을 것이다.
##      따라서, 내가 운영하는 CNI가 1개인지 또는 어떤 종류의 CNI이 인지에 따라
##      NIC의 이름이 다를 수 있으니까, ifconfig 명령 또는 `ip a` 같은 명령으로
##      NIC 이름을 확인하고 tcpdump 명령을 수행해야 한다.
##
(In-Container) $  tcpdump -i eth0 -w  my-capture.pcap
... 중간 생략 ...

위와 같이 생성한 pcap 파일은 Pod 외부에서 볼 수 없기 때문에

   1) Pod 내부에서 scp 명령으로 외부로 옮겨주던지 

   2) 또는 NFS, Ceph storage 같은 PV를 이용하여 저장하는 것을 권장한다.

방식 B: Worker node에서 특정 Pod의 namespace를 이용하여 tcpdump 명령을 수행

예제를 이용하여 설명해보겠다.

'productpage' Pod가 주고 받은 IP packet을 tcpdump하려는 상황을 가정해보자.

우선 'productpage' Pod가 어느 worker node에 있는지 확인한다.

$  kubectl get pod -o wide
NAME                              READY   STATUS    RESTARTS   AGE     IP           NODE  
... 중간 생략 ...
productpage-v1-6b746f74dc-xfjdz   2/2     Running   0          2d17h   10.244.2.4   worker-1
... 중간 생략 ...

'productpage' pod가 worker-1 node에 있으니까, worker-1에 ssh 접속하여 아래의 스크립트를 수행한다.

##
## Filename : run-tcpdump.sh
##

#!/usr/bin/bash

container_id=$(docker container ls | grep k8s_istio-proxy_productpage | awk '{ print $1 }')
echo "Container  ID: $container_id"

container_pid=$(docker inspect -f '{{.State.Pid}}' $container_id)
echo "Container PID: $container_pid"

nsenter -t $container_pid  -n /bin/bash -xec 'tcpdump -i any -w productpage-envoy-any.pcap'


## NOTE: After running this script to capture the packet,
##       Use the packet filter as 'tls or http' with your Wireshark program !

위 `run-tcpdump.sh` 스크립트를 수행하고 나서 만들어진 pcap 파일을 Wireshark으로 열어본다.

그런데, 위 "방식 A, 방식 B"는 Kubernetes를 사용했을 때나 가능한 얘기이고,
OCP(Openshift Container Platform)을 사용하는 경우라면 위 방식으로 container 내부의 network packet을 dump할 수 없다 !!!
왜? OCP, OKD Cluster의  Worker Node에는 'docker' command가 없다.
그러면 어떻게 하는가?
아래와 같이 "방식 C"를 따라해야 한다.

방식 C:  OCP의 Node에서 특정 Pod의 namespace를 이용하여 tcpdump 명령을 수행

예제를 이용하여 설명해보겠다.

(worker2 node에 Pod가 구동되어 있다고 가정하고 설명한다)

##
## Working Location:  Bastion Node, or PC (MacBook)
##

$  oc debug node/worker1.andrew.space

Starting pod/worker1.andrew.space-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.10.11.12
If you don't see a command prompt, try pressing enter.

sh-4.4# chroot /host

sh-4.4# container_id=$(crictl ps | grep my-example-app | awk '{ print $1 }')

sh-4.4# echo $container_id
378f096238fdd

sh-4.4# container_pid=$(crictl inspect $container_id | jq '.info.pid')

sh-4.4# echo $container_pid
3458673

sh-4.4# nsenter -t $container_pid  -n /bin/bash -xec 'tcpdump -i eth0'

... TCPDUMP 출력 결과 생략 ...

만약, OCP 또는 OKD Cluster를 구축할 때, OS를 CoreOS를 사용한 경우라면 
위와 같이 `nsenter -t .... 'tcpdump -i eth0'` 명령을 사용할 수 없다.
왜냐고?
CoreOS는 TCPDUMP 명령을 가지고 있지 않기 때문이다. ㅠㅠ
단, 임시로 CoreOS에 tcpdump command를 설치하고 위 절차를 따라하는 꼼수가 있기는 하다.

잠깐 !!!
만약, 단순히 Container, Pod 내부에서 Root 권한 또는 Host OS 자원에 대한 접근 권한이 필요한 경우라면
이 블로그를 읽고 따라하기 보다는 아래 블로그를 읽고 간단하게 테스트하기를 권장한다.

https://andrewpage.tistory.com/191

Pod 내부의 Application이 Host OS의 Root User 권한으로 OS 자원에 접근하거나 명령을 수행해야 한다면, 해당 'namespace'에

privileged 속성 또는 privilieged와 동등한 수준의 자체 정의한 SecurityContextConstraints(SCC)를 추가해야 한다.

SCC 생성

나만의 SCC를 생성해보자.

$  cat << EOF > my-scc.yaml

kind: SecurityContextConstraints
metadata:
  name: andrew-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities:
- NET_ADMIN
- NET_RAW
- NET_BIND_SERVICE
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
groups:
- system:cluster-admins
priority: 10
readOnlyRootFilesystem: false
requiredDropCapabilities:
- MKNOD
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
users: null
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret

EOF

위와 같이 my-scc.yaml을 작성했다면, 이 파일을 OCP에 적용한다.

## 참고로, scc는 namespace마다 있는 것이 아니다. 
## 따라서 namespace를 지정하지 않고, 아래 명령처럼 scc를 생성한다.

$  oc apply -f my-scc.yaml

이렇게 생성한 SCC를 내가 사용할 ServiceAccount와 binding한다.

$ oc create ns andrew-project
$ oc adm policy add-scc-to-group andrew-scc system:serviceaccounts:andrew
$ oc adm policy add-scc-to-user andrew-scc  -z andrew  -n andrew-project

# SCC 정보를 확인하는 명령
$ oc describe scc andrew-scc

# 'andrew' ServiceAccount로부터 'andrew-scc' SCC를 삭제하는 명령
$ oc adm policy remove-scc-from-user andrew-scc  -z andrew -n andrew-project

추가로 Pod Deploy할 때, 아래와 같이 'securityContext' 항목을 설정해야 한다.

# File name: my-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubuntu-pv
  labels:
    app: ubuntu-pv
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ubuntu-pv
  template:
    metadata:
      labels:
        app: ubuntu-pv
    spec:
    ## NOTE: 이 부분을 추가 !!!
      securityContext:
        runAsUser: 0
      containers:
      - name: ubuntu-pv
        image: myharbor.andrew.space:8080/my-ubuntu:0.1.2
        ## NOTE: 이 부분을 추가 !!!
        securityContext:
          capabilities:
            add:
              - "NET_ADMIN"
              - "NET_RAW"
              - "NET_BIND_SERVICE"

여기까지는 그냥 SecurityContextConstraints에 관한 이해없이 따라해도 잘 동작한다.

그런데 만약 SecurityContextConstraints에 대해서 깊이 있는 지식을 얻고 싶다면, 아래의 Red Hat Blog를 읽어볼 것을 추천한다.

SecurityContextConstraints 방식으로 Process의 실행 권한을 제어하는 방법 외에도 Linux에서 전통적으로 사용하는 Stick Bit(SETUID)와 File Capability 방식으로 Binary File을 만들고, Container Image를 미리 제작하는 방법도 같이 소개하고 있다.

어떤 방식이 더 편하고, 보안(Security)이 우수한지는 사용하는 사람이 판단할 일이다.

추천 Blog - Capabilities in OpenShift (OCP)

https://cloud.redhat.com/blog/linux-capabilities-in-openshift

추천 Web Docs

아래 Web Docs에서 Chapter 15.에 가장 확실한 설명이 있다.

https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.10/html-single/authentication_and_authorization/index