주의: 위 문서가 대체로 절차를 잘 설명하고 있지만, ServiceMonitor 리소스에 대한 설정이 이상하다. 그래서 ServiceMonitor 리소스는 내가 별도로 만들었다.
웹 문서의 설명과 다른 부분만 아래와 같이 Comment를 추가했다.
Comment가 붙어 있는 라인만 잘 수정하면, 잘 동작한다.
##
## File name: servicemonitor.yaml
##
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
labels:
k8s-app: almighty
name: almighty
namespace: openshift-monitoring ## Note: 반드시 이 namespace로 설정해야 한다.
spec:
endpoints:
- interval: 15s
port: web
scheme: http
path: /metrics ## 이 설정을 꼭 넣자.
selector:
matchLabels:
app: almighty ## 이 부분이 Pod, Service의 label 값과 같은지 꼭 확인해야 한다.
namespaceSelector:
matchNames:
- almighty ## Service 리소스의 값과 같은지 확인해야 한다.
servicemonitor.yaml 파일을 작성하면, 아래와 같이 kubectl 명령으로 kubernetes cluster에 적용한다.
$ kubectl apply -f servicemonitor.yaml
그런데 여기서 생각해볼 것이 있다. 만약, Service에 포함된 Pod가 2개 이상일 때는 위 ServiceMonitor처럼 Scrapping을 시도하면 2개의 Pod 중에서 1개의 Pod만 Scrapping에 응답하기 때문에 반쪽 짜리 Scrapping이 되는 문제가 있다. Pod가 10개라면, 1개 Pod 입장에서 본다면 Scrapping 인터벌(주기)는 10배로 더 길어진다.
따라서 Service에 포함되는 Pod가 2개 이상일 때는 ServiceMonitor 보다 PodMonitor 조건을 사용하는 것이 좋다. PodMonitor를 사용하면, Prometheus가 각 Pod마다 접근해서 Scrapping한다.
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: almighty
labels:
app: almighty
## FIXME
namespace: openshift-monitoring
spec:
selector:
matchLabels:
## FIXME
app: almighty
podMetricsEndpoints:
## FIXME
- port: web
path: /metrics
interval: 7s ## 테스트를 해보면, 1s 로 설정해도 잘 동작한다.
scheme: http
namespaceSelector:
matchNames:
## FIXME
- almighty
Prometheus Web UI를 열고, 아래와 같이 Qeury(PromQL)을 입력한다.
## Example 1
http_request_duration_seconds_bucket{code="200",handler="found"}
## Example 2
irate(http_requests_total{namespace="almighty", code="200"}[5m])
irate 함수를 사용한 PromQL
위와 같이 챠트가 잘 그려지면, Prometheus의 Scraper가 사용자 App의 Metrics을 잘 Scraping하고 있는 것이다.
만약, Kubernetes 또는 OCP를 초기 구축하고 나서 User App에 대한 Metrics을 Scrapping할 수 있는 Role을 Prometheus ServiceAccount에 부여하지 않았다면, 꼭 Cluster Role과 ClusterRoleBinding을 설정해줘야 한다.
이 Cluster Role Binding 작업이 안 되어 있으면, 위에서 예제로 설명했던 ServiceMonitoring, PodMonitoring을 모두
"endpoints is forbidden" 에러가 발생할 것이다. (아래 Error Log을 참고)
Prometheus Error Log 예시
$ kubectl logs -f -n openshift-monitoring prometheus-k8s-0
ts=2022-08-10T03:29:51.795Z caller=log.go:168 level=error component=k8s_client_runtime func=ErrorDepth msg="github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:471: Failed to watch *v1.Pod: failed to list *v1.Pod: pods is forbidden: User \"system:serviceaccount:openshift-monitoring:prometheus-k8s\" cannot list resource \"pods\" in API group \"\" in the namespace \"almighty\""
위 에러를 없애기 위해 아래와 같이 ClusterRole, ClusterRoleBinding 리소스를 만들어야 한다.
Prometheus Query를 몇달만에 수행하면, 나의 기억력이 떨어져서 손이 멈짓하는데
자주 사용하는 PromQL 예제를 여기에 메모하고 참조해야겠다.
##
## Kubernetes, OCP(Openshift)의 ETCD Pods CPU 통계 데이터 조회
##
pod:container_cpu_usage:sum{namespace="openshift-etcd", pod=~"etcd.+"}
##
## Kubernetes, OCP(Openshift)의 DNS Pods CPU 통계 데이터 조회
##
pod:container_cpu_usage:sum{namespace="openshift-dns", pod=~"dns-.+"}
##
## Kubernetes, OCP(Openshift)의 API Server Pods CPU 통계 데이터 조회
##
pod:container_cpu_usage:sum{namespace="openshift-apiserver", pod=~"apiserver-.+"}
Kubernetes, OCP(Openshift Container Platform)을 사용하다 보면, Resource에 대한 접근 권한 때문에 답답한 경우가 많다.
SCC(SecurityContext)를 잘 관리할 줄 알면, 제일 좋지만 급하게.. 그리고 간단하게 테스트만 하는 상황이라면,
아래와 같이 시스템의 모든 자원에 접근할 수 있도록 권한을 최고 수준(privileged)으로 올려주고 테스트하는 것이 정신 건강에 좋다.
(상용 서비스에서는 절대 이렇게 하면 안 된다. Test bed 같은 곳에서 잠깐 Feasibility check만 하고 Pod를 종료시킨다는 가정하에 사용할 것)
apiVersion: v1
kind: Pod
metadata:
name: my-example-pod
spec:
hostNetwork: true ## <-- 이 설정이 있으면, Pod 내부에서 Host Network이 보인다
## 예를 들어, Host OS의 eno3 network port를 보기 위해
## ifconfit eno3 명령 실행이 가능해진다.
containers:
...
securityContext:
privileged: true ## <-- 이렇게 하면 모든 자원에 접근 가능해진다.
...
securityContext: {}
...
만약, 극단적으로 Pod 내부에 있는 Process가 Host OS의 자원에 제약 없이 접근하고 싶다면 아래 예제 YAML처럼 권한 설정을 하면 된다. 이렇게 하면, Pod 내부에서 Pod 밖(즉 Host OS)의 IP network 자원, TCP Stack, IPC, ProcessID(PID) 등에 자유롭게 접근할 수 있다.
다시 한번 강조하지만, 위와 같이 securityContext.privileged: true 설정된 Pod를 상용 서비스를 제공하는 클러스터에서 구동한 상태로 오래 방치하면 결국 해커의 먹이감이 된다. 꼭 10분~20분 정도 테스트만 하고 바로 Pod를 종료(삭제)해야 한다.
아래 내용은 참고용으로만 볼 것!!!
DaemonSet으로 구동하는 Pod들은 securityContext 값이 privileged 으로 설정된 경우가 많다.
왜냐하면 이런 DaemonSet으로 구동된 Pod들은 각 노드에서 Host 자원에 접근해야 하는 경우가 있기 때문이다.
아래 예시를 보면 바로 이해가 될것이다.
Multus 배포 예시
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: multus
namespace: openshift-multus
... 중간 생략 ...
spec:
template:
... 중간 생략 ...
spec:
containers:
... 중간 생략 ...
securityContext:
privileged: true ## <-- 이 부분
... 중간 생략 ...
Openshift SDN 배포 예시
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: sdn
... 중간 생략 ...
spec:
template:
... 중간 생략 ...
spec:
containers:
... 중간 생략 ...
securityContext:
privileged: true ## <-- 이 부분
... 중간 생략 ...
2015년 Machine Learning, Deep Learning 기술을 이용한 장애 예측 시스템 개발
2017년 Linux Container를 이용한 Container Platform 설계 및 Demo 시스템 개발
2018년 Data Center 가상화 관리 시스템 개발(일명, XOS) + Open Networking OS
2019년 상반기 5G NRF 개발
2019년 하반기 휴직 (건강 문제 발생, 반년 정도 병원 다니면서 요양)
2020년 Kubernetes Cluster에 Deploy할 CNF 개발
2021년 Container Platform 구축을 위한 TF 리딩
2022년 Container Platform 도입 프로젝트
이미 2018년에 정신 건상에 문제가 생겼고, 2019년 봄부터 정신건상의학과 병원을 다니기 시작했다.
제대로 병치레를 하고 보니 아플 때는 빨리 전문의를 찾아가서 상담하고 정밀하게 진단하고 치료하는 것이 제일 좋은 방법이다.
혹시 이 글을 읽는 직장인 중에서 눈에 보이지 않는 병 때문에 치료를 망설이는 직장인이 있다면, 빨리 병원부터 가기를 추천한다.
신입 사원이었을 때 마음가짐 vs. 지금의 마음가짐
신입이었을 때 나의 마음.
내가 제일 잘 하는 것 같다.
내가 제일 똑똑한 것 같다.
내가 제일 열심히 하는 것 같다.
이렇게 잘 하고, 똑똑한데 왜 연봉을 쪼금 주지...?
직장 생활 22년이 넘은 지금의 마음가짐
20년차가 넘었을 때부터 지금까지(23년차까지) 나의 마음은
나 빼고, 동료들은 다 잘하고 있는 것 같다. (내가 있는 회사는 대체로 농땡이 부리는 동료가 없이 평균적으로 근면하고 성실해서 더욱 이런 생각이 많이 드는 것 같다.)
"내가 프로젝트에서 도움이 되고 있는건 맞나?" 라는 스스로 의심하기 시작한다. (매일 자책하는 것이 일...)
이미 출근하면서 하루동안 쓸 에너지 중에서 50% 정도는 소비하는 것 같다. (즉, 체력이 바닥이라는.... ㅠㅠ)
출근해서 모니터를 보고 있는 것만해도 에너지가 고갈되는 느낌이다.
1년만 더 버텨보자. (이런 생각으로 3년째 버티는 중이다 ㅠㅠ) 진짜 올해가 IT 개발자로써 일하는 마지막 해일까...?
아무튼 23년차가 되니까 몸도 힘들고 마음가짐도 무겁다.
결혼 그리고 출산, 육아
나는 결혼을 일찍했다.
대학교 졸업 후 1년 뒤. 만 26세에 결혼했다.
아내와 나는 동갑이고 심지어 생일도 거의 비슷하다. (그래서 생일 파티도 한날 몰아서 한다.)
아내를 학생일 때 만나서, 졸업하고 1년 뒤에 결혼했기 때문에 제대로 준비된 것 없이 신혼 살림을 시작했다.
그리고 내 나이 만 27세일 때, 첫째 아기가 생겼다. 그리고 2년 뒤 둘째 아기, 그리고 또 3년 뒤에 세째 아기.
이렇게 나와 아내를 닮은 아들과 딸이 나에게 왔다.
지금 결혼한지 19년이 되었고, 되돌아 생각해보면 순간 순간에는 힘든 일이 많았던 것 같은데
지금은 결혼한 것을 참 잘한 것이라 생각하고 있다.
그리고 나를 닮은 2세가 있다는 것은 더욱 기쁘다.
결혼을 할지 말지 고민하는 사람이 나에게 결혼하는게 좋냐고 묻는다면, 나의 대답은 확실하다.
" 이 여자를 위해 내 모든 것을 바쳐 희생할 수 있고, 그 희생이 즐겁고 행복하다면 결혼하고 그런 생각이 없다면 하지 말라! "
내가 결혼할 때, 내 마음 속 다짐이 딱 위 문장과 같았다.
사랑하는 사람과 19년 동안 살아보니, 편한 것보다는 불편함이 많고 몸이 고단하거나 정신적으로 힘든 일도 많이 생긴다.
그런데 애초에 이 여자를 즐겁고 행복하게만 할 수 있다면 모든 것을 감내하리라 마음 먹어서 그런지, 힘든 순간이 딱 지나고 나면 행복은 몇배가 되는 느낌이다.
육아도 비슷한 것 같다.
아기 였을 때 한없이 귀엾고 예쁘다가, 아이가 점점 크면서 아이의 고집과 일탈로 아빠가 힘들어지는 경우가 있다.
아기에게 사회적 잣대(예를 들어, 학교성적 같은 것)를 들이밀고 보기 시작하면, 부모는 초조해지는 것 같다.
그래서 항상 마음속으로 다짐했었다. 건강과 웃음만 있다면, 나머지는 하늘이 주는 대로 받자 !!!
특히 학교 공부, 입시에 관해서는 입에 담지 않겠다고 다짐하고 또 다짐했다.
이것 때문에 친한 이웃들에게 "무심하고, 무책임한 부모"라는 소리도 몇번 들었다.
학원 안 다니는 중,고등학교 자녀가 어디있냐고?
아이가 싫어하는데, 굳이 학원에 보낼 필요가 있을까.
음악이 좋다고 하면, 악기 사주고
PC 게임이 좋다고 하면, PC 게임 사주고
놀러 가고 싶다면 놀러 가주고
사회적 책임이 덜한 나이일 때, 어디에 속박당하지 않고 자유를 느끼면서 놀게 해주고 싶었다.
2000년, 2010년, 2022년의 직장 생활. 무엇이 다를까?
나는 2000년에 가장 Hot했던 IT 회사에 입사했기에 분위기 자유롭게, 적당히 급여 괜찮았고, 상하/위계 질서가 없는 회사에서 일을 시작했다. 그래서 내 개인적으로는 2022년보다는 2000년의 내가 다녔던 W회사가 더 분위기가 자유롭고 출/퇴근 및 업무 시간도 내 마음대로 할 수 있었다. (심지어 내가 입사 1년차인 신입사원이었는데도 눈치주는 사람이 없었다)
다만 사회 전반적인 분위기로 보았을 때, 아래와 같이 차이가 있었던 것 같다.
주6일 근무 ㅠㅠ
이거 실화냐? 어떻게 주 6일을 출근할 수 있냐?
(근데 나는 주 1~2 일 정도만 출근하고, 나머지는 집에서 근무했기 때문에 주6일이 크게 와닿지 않았다)
IT는 3D 중에서 극한 직업군 ㅠㅠ
2000년은 아직 IT 개발 인프라, 플랫폼이 별로 없고, 심지어 협업에서 참고할 도서, 웹 검색기도 변변치 않았다.
그런 반면, 중공업 경공업 같은 공장 시스템에 익숙한 경영자가 IT 회사를 경영하면서 업무량으로 압박하는 분위기도 있었다.
이렇다보니 IT 개발자들은 과중한 업무량에 치이고, 밤 11시~새벽 3시 까지 일하는 야근은 일상이었다.
애초에 기한내에 할 수 없는 업무량, 업무 난이도 였기 때문에 결국에 프로젝트 완료일에 일을 못 끝내서 또 잔소리 듣고... ㅠㅠ
나쁜 상황이 돌고 돌게 된다.
이런 근무 환경이 사회 전반적으로 알려지면서 IT 관련 전공을 하려는 학생이 줄어들고, 대학 입시에서도 홀대 받는 것 같았다. (참고로, 1990년 초/중반에는 대학교 전공에서 "전자" "컴퓨터" 이런 문구만 들어가도 대입 성적 상위 1~2%의 학생이 몰리는 현상이 있었다. 지금은 입시생들이 이런 과거의 분위기를 못 믿겠지만...ㅠㅠ)
Stock Option은 유행어처럼 난무했지만, 실제 Stock Option을 행사해서 돈 번 사람은 못 본.... ㅠㅠ
회사 생활과 가정 생활의 균형점을 찾기
회사 생활과 가정 생활의 균형점(흔히 말하는 워라밸)을 찾기 위해 노력하지만, 지나온 20년을 뒤돌아보면
직장 생활, 경제 활동(돈 버는 일)에 더 에너지를 많이 쓴 것 같다.
동년배들보다 일찍 진급하고, 연봉 조정을 위한 평가도 매년 꾸준하게 최고 등급(Special Grade)을 받고, 이런 저런 회사의 포상도 대부분 다 받고... 그런데 이렇게 회사 생활, 경제 활동에 집중하면서 가정 구성원에 대해 소홀하지 않았나하는 후회감이 든다.
