반응형

 

아래의 Go App을 Build해서 Kubernetes Worker Node에서 돌려보면,

각 Container가 사용하는 CPU Set(즉, Container App이 Pinning한 Core 정보), Memory Hugepages, Network 주소 및 PCI 정보를 알 수 있다.

 

 

https://github.com/openshift/app-netutil/tree/master/samples/go_app

 

GitHub - openshift/app-netutil: app-netutil is a library that provides API methods for applications to get pod network informati

app-netutil is a library that provides API methods for applications to get pod network information. - GitHub - openshift/app-netutil: app-netutil is a library that provides API methods for applicat...

github.com

 

그리고, 위 Repository에 DPDK example app container도 있으니까, DPDK 테스트할 때도 이용하면 좋다.

 

 

 

 

반응형

 

NUMA with Linux

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

 

NUMA with Linux :: Lunatine's Box — Lunatine's Box

linuxnumainterleaved memoryinterleavenumctlnumad 3236 Words 2016-07-14 15:18 +0900

lunatine.net

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

 

NUMA Deep Dive Part 1: From UMA to NUMA - frankdenneman.nl

Non-uniform memory access (NUMA) is a shared memory architecture used in today’s multiprocessing systems. Each CPU is assigned its own local memory and can access memory from other CPUs in the system. Local memory access provides a low latency – high

frankdenneman.nl

 

 

 

 

HugePages

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

 

Enhanced Platform Awareness (EPA) in OpenShift — Part I, HugePages

This series of posts will show how to configure EPA support in OpenShift 4. In this part you will see 1GB HugePages configuration and usage

luis-javier-arizmendi-alonso.medium.com

 

CPU Pinning

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

 

Enhanced Platform Awareness (EPA) in OpenShift — Part II, CPU pinning

This is the second part about how to configure an EPA ready OpenShift worker node, covering the CPU pinning and CPU isolation…

luis-javier-arizmendi-alonso.medium.com

 

 

NUMA Topology Awareness

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

 

Enhanced Platform Awareness (EPA) in OpenShift — Part III, NUMA Topology Awareness

This time we are going to focus on how we can assure that the CPU scheduling takes into account the NUMA topology of the processor

luis-javier-arizmendi-alonso.medium.com

 

 

SR-IOV, DPDK, RDMA

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

 

Enhanced Platform Awareness (EPA) in OpenShift — Part IV, SR-IOV, DPDK and RDMA

In this Post we’ll review some concepts that help to minimize random latencies and improve the network performance: SR-IOV, DPDK, and RDMA.

medium.com

 

 

반응형

Service Account에 역할(Role)을 부여(Binding)하는 기능에 대한 설명을 보고 싶다면, 아래 Web Docs의 10.3 절을 참고할 것 !!!

 

 

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

 

인증 및 권한 부여 OpenShift Container Platform 4.10 | Red Hat Customer Portal

이 문서에서는 OpenShift Container Platform에서 ID 공급자를 정의하는 방법을 설명합니다. 또한 클러스터를 보호하기 위해 역할 기반 액세스 제어를 구성하는 방법도 알아봅니다.

access.redhat.com

 

반응형

Service Account에 역할(Role)을 Binding하는 기능에 대한 설명을 보고 싶다면, 아래 Web Docs의 10.3 절을 참고할 것 !!!

 

 

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

 

인증 및 권한 부여 OpenShift Container Platform 4.10 | Red Hat Customer Portal

이 문서에서는 OpenShift Container Platform에서 ID 공급자를 정의하는 방법을 설명합니다. 또한 클러스터를 보호하기 위해 역할 기반 액세스 제어를 구성하는 방법도 알아봅니다.

access.redhat.com

 

 

`oc login` 명령을 이용하여 Service Account에 로그인하는 방법은 위 Web Docs의 11.4 절을 참고할 것 !!!

Cluster 외부에서 Service Account로 Login하는 방법을 요약하자면,
1) Service Account의 Secret 정보(즉, Token)을 열람
2) 이 Secret(즉, Token)을 `oc login --token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...` 이렇게 입력
3) `oc login` 성공하면,
4) `oc whoami`를 수행

 

'kubernetes' 카테고리의 다른 글

NUMA, CPU Pinning, DPDK, SR-IOV  (0) 2022.06.18
Service Account에 Role 부여 (Binding)  (0) 2022.06.16
Openshift Authentication and authorization  (0) 2022.06.06
OCP API Token 조회  (0) 2022.05.19
kubernetes node의 taint & toleration  (0) 2022.03.30
반응형

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

 

인증 및 권한 부여 OpenShift Container Platform 4.10 | Red Hat Customer Portal

이 문서에서는 OpenShift Container Platform에서 ID 공급자를 정의하는 방법을 설명합니다. 또한 클러스터를 보호하기 위해 역할 기반 액세스 제어를 구성하는 방법도 알아봅니다.

access.redhat.com

 

 

(영어 문서)

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

 

Authentication and authorization OpenShift Container Platform 4.10 | Red Hat Customer Portal

This document provides instructions for defining identity providers in OpenShift Container Platform. It also discusses how to configure role-based access control to secure the cluster.

access.redhat.com

 

반응형

 

(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
반응형

Kubernetes의 Pod Scheduling에 관한 공부를 하다보면,

  • Node Label을 이용한 NodeSelector, Node Affinity
  • Node Taint, Tolerlation

가 꼭 등장한다.

위 2가지를 따로 따로 공부하면, 그렇구나 라고 이해가 되다가 

이 2가지를 같이 놓고 생각해보면, 비슷한 기능을 하는 것 같은데 왜 이렇게 2가지 모두 있는거지 라는 질문이 자연스레 떠오른다.

 

아래 블로그가 이런 질문에 대한 답을 잘 하고 있다.

 

https://fisache.tistory.com/19

 

CKA 준비 (7) - Scheduling 2 (Node Selector, Node Affinity)

본 포스팅은 Udemy Certificated Kubernetes Administrator 강좌를 공부한 내용입니다. Certified Kubernetes Administrator (CKA) Practice Exam Tests Prepare for the Certified Kubernetes Administrators C..

fisache.tistory.com

 

 

Node Taint 및 Toleration에 대해 기초부터 알고 싶다면, 아래의 Kubernetes Web Docs를 보면 좋다.

 

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/

 

테인트(Taints)와 톨러레이션(Tolerations)

노드 어피니티는 노드 셋을 (기본 설정 또는 어려운 요구 사항으로) 끌어들이는 파드의 속성이다. 테인트 는 그 반대로, 노드가 파드 셋을 제외할 수 있다. 톨러레이션 은 파드에 적용되며, 파드

kubernetes.io

 

# TODO

위 Web Docs에 TolerationSeconds에 관한 설명이 나오는데, 

내 생각에는 Node 장애가 발생했을 때, 빠르게 Pod가 장애가 발생한 Node에서 종료 처리되고 다른 Node로 스케쥴링되게 하려면, 300초로 설정된 값을 1초로 줄이면 되지 않을까하는 상상을 해본다. 

시간 여유가 있을 때, 한번 1초로 변경하고 Node를 다운시켜서 테스트해봐야겠다.

 

참고:
쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로 node.kubernetes.io/not-ready 와 node.kubernetes.io/unreachable 에 대해 tolerationSeconds=300 으로 톨러레이션을 추가한다.
자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안 파드가 노드에 바인딩된 상태를 유지함을 의미한다.

 

반응형

 

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

 

 

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

+ Recent posts