일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- python os
- python subprocess
- 정규식 컴파일
- gcc 업데이트
- snmp test
- subporcess path
- InfluxDB
- CentOS7
- c3 축 없애기
- selinux port 등록
- g++ 업데이트
- influxdb 설치
- 정규식 문자열 출력
- python popen
- telegraf
- regex_search
- gcc regex
- semanage
- c3 축 가리기
- snmp
- c3 step graph
- 1697
- linux시간으로 변경
- c++ 정규식
- centos pyhon 설치
- c3 초
- 백준
- 정규식 활용
- c3 second
- grafana dashboard
- Today
- Total
목록오케스트레이션 (14)
리셋 되지 말자
now = datetime.datetime.now().replace(microsecond = 0) api server에 요청하여 Pod 정보 획득 kubectl을 이용해서 해당 Pod의 생성 시간을 획득할 수 있다. (Z는 utc timezon을 의미한다고 한다) kubectl get pod -o json | jq -r ".metadata.creationTimestamp" 2023-01-27T08:20:42Z Python을 이용해 생성 시간 변환 - 초(second) datetime 모듈을 이용해 Pod가 몇초전에 생성되었는지 구한다. microsecond는 0으로 치환하지 않아도 되지만, 옵션으로 추가했다. import datetime string="2023-01-27T08:20:42Z" pod_cre..
nginx service, deployment apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: selector: matchLabels: run: my-nginx replicas: 2 template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: my-nginx labels: run: my-nginx spec: ports: - port: 80 protocol: TCP selector: run: my-ng..
레퍼런스 - https://kingofbackend.tistory.com/209 [K8S] EKS 클러스터 인증(authenfication) 및 권한(authorization) 설정하기 쿠버네티스 API 요청 과정 간단하게 API Server에 접근하기 까지 프로세스를 보면, 첫번째, 요청을 보냈을 때 인증(Authentication) 과정을 거친다. "너는 k8s cluster에 등록된 사용자가 맞는거지?" 두번째, kingofbackend.tistory.com - https://341123.tistory.com/m/10 [EKS] 현재 사용자 또는 역할이 이 EKS 클러스터에 있는 Kubernetes 객체에 액세스할 수 없습니다. 원인 ConfigMap aws-auth에 현재 사용자 또는 역할이 등록..
https://medium.com/@m.allandhir/understanding-istio-authentication-policy-aa17e84112bf#4319
Pod 생성 방법 kubelet 에서 nginx-pod를 배포할 때, 아래와 같이 했었음 [vagrant@m-k8s ~]$ sudo kubectl create -f nginx-pod.yaml pod/nginx-pod created Pod를 생성하는 다른 방법을 해본다. - kubectl run [vagrant@m-k8s ~]$ sudo kubectl run nginx-pod --image nginx pod/nginx-pod created [vagrant@m-k8s ~]$ sudo kubectl get pod NAME READY STATUS RESTARTS AGE nginx-pod 0/1 ContainerCreating 0 16s [vagrant@m-k8s ~]$ sudo kubectl get pod NA..
kube-proxy kubelet이 pod의 상태를 관리한다면, kube-proxy는 pod의 통신을 담당. kube-proxy 에 문제가 생겼을 때의 시나리오 쿠버네티스 클러스터 구성할 때, br_netfilter 커널 모듈을 적재하고 iptables를 거쳐 통신하도록 설정한 상태임 - master 노드에서 kubectl을 통해, nginx pod를 배포 (nginx-pod.yaml 내용 - 링크) [vagrant@m-k8s ~]$ sudo kubectl create -f nginx-pod.yaml pod/nginx-pod created [vagrant@m-k8s ~]$ sudo kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINA..
kubelet 워커노드에 존재하는 쿠버네티스 클러스터의 구성요소 Pod의 구성 내용(Pod Spec)을 받아서 컨테이너 런타임(CRI, Container Runtime Interface)으로 전달하고, Pod 안의 컨테이너들이 정상적으로 작동하는지 모니터링 쿠버네티스에서 Pod의 생성과 상태 관리 및 복구 등을 담당하는 매우 중요한 구성요소. 따라서 kubelet에 문제가 생기면 Pod가 정상적으로 관리되지 않음 정리 : kubelet은 Pod의 상태를 관리함 Pod 배포 - nginx - nginx-pod.yaml apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: container-name image: nginx -..
kubectl 쿠버네티스 클러스터에 명령을 내리는 역할을 함. 쿠버네티스 클러스터를 이루는 다른 구성 요소들과는 다르게 바로 실행되는 형태인 바이너리로 배포됨. 따라서 반드시 마스터 노드에 있을 필요는 없음. 통상적으로 API 서버와 주로 통신하므로 API서버가 위치하는 마스터 노드에 구성할 때가 많다 - 비확실 kubectl은 API 서버를 통해 쿠버네티스에 명령을 내림. 즉 API 서버의 접속 정보만 있다면 어느 곳에서든 쿠버네티스 클러스터에 명령을 내릴 수 있음 - master 노드에서의 kubectl 명령 [vagrant@m-k8s ~]$ kubectl get nodes The connection to the server localhost:8080 was refused - did you speci..