HighLight in your life~

const number15 = [1,2,3,4,56,7,8,9,10,1,1,2,2,2,3,3,3,3];

const searchNumber = 1;
let startPosition = 0;
let lastResult = [];

while(true) {

let idxRst = number15.indexOf(searchNumber, startPosition); // 있으면 인덱스 return, 없으면 -1 return

//조건문 --> return된 인덱스가 -1이면 loop 종료
if(idxRst == -1)
  break;

lastResult.push(idxRst); //찾은 인덱스는 결과 변수에 push
startPosition = idxRst + 1; //찾은 것 그 다음부터 순회를 이어가야하니까 --> 찾은 것에 1 더해서 다시 순회.
}

console.log(lastResult);

console.log("찾고자 하는 ${searchNumber}의 인덱스는 = " + lastResult);
console.log("출현 빈도 수 = " + lastResult.length);

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

const number15 = ['Smith','Tom','Tommy','Ford','Willson','Smith'];

const searchNumber = 'Smith';
let startPosition = 0;
let lastResult = [];

while(true) {

let idxRst = number15.indexOf(searchNumber, startPosition); // 있으면 인덱스 return, 없으면 -1 return

//조건문 --> return된 인덱스가 -1이면 loop 종료
if(idxRst == -1)
  break;

lastResult.push(idxRst); //찾은 인덱스는 결과 변수에 push
startPosition = idxRst + 1; //찾은 것 그 다음부터 순회를 이어가야하니까 --> 찾은 것에 1 더해서 다시 순회.
}

console.log(lastResult);

console.log("찾고자 하는 ${searchNumber}의 인덱스는 = " + lastResult);
console.log("출현 빈도 수 = " + lastResult.length);

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

const number15 = 'Welcome, Hello World~~~!!!';

const searchNumber = 'l';
let startPosition = 0;
let lastResult = [];

while(true) {

let idxRst = number15.indexOf(searchNumber, startPosition); // 있으면 인덱스 return, 없으면 -1 return

//조건문 --> return된 인덱스가 -1이면 loop 종료
if(idxRst == -1)
  break;

lastResult.push(idxRst); //찾은 인덱스는 결과 변수에 push
startPosition = idxRst + 1; //찾은 것 그 다음부터 순회를 이어가야하니까 --> 찾은 것에 1 더해서 다시 순회.
}

console.log(lastResult);

console.log("찾고자 하는 ${searchNumber}의 인덱스는 = " + lastResult);
console.log("출현 빈도 수 = " + lastResult.length);

//11. 인덱스 몇 번째에 있는지 찾기 indexOf

//알파벳 찾기
console.clear();
let abcArr1 = "ABCDEFGHIJKMN";
console.log('---------------------------------------------------- J의 인덱스는?');
console.log(abcArr1.indexOf('J')); // 9 

//역순으로 찾기 --> lastIndexOf();
let abcArr2 = "ABCDEFGHIJKJMN";

console.log('---------------------------------------------------- J의 역순 인덱스는?');
console.log(abcArr2.lastIndexOf('J')); // 11

//대소문자 구분을 한다. (Default)
let abcArr3 = "ABCDEFGHIJKJMN";
console.log('---------------------------------------------------- J의 인덱스는? 대소문자 구분');
console.log(abcArr3.lastIndexOf('j')); // -1

//대(소)문자 변환 후 --> indexOf 사용
let abcArr4 = "abcdABCD";
console.log('---------------------------------------------------- 대소문자 변환');
console.log(abcArr4.lastIndexOf('A')); // 4
console.log(abcArr4.toUpperCase().indexOf('A')); //0 
console.log(abcArr4.toUpperCase().lastIndexOf('A')); // 4

//13. indexOf 옵션 --> indexOf("찾을 특정 값(value)", "시작할 위치(position)")
console.clear();
console.log('---------------------------------------------------- 시작 위치 옵션');
const nums = ['k','o','r','e','a','u','s','a'];
console.log(nums.indexOf('a')); //4 
console.log(nums.indexOf('a', 2)); //4
console.log(nums.indexOf('a', 6)); //7

console.log('---------------------------------------------------- 시작 위치 옵션 - 문자열');
const strs13 = "Hello, World~!!!";

console.log(strs13.indexOf('o')); //4
console.log(strs13.indexOf('o', 5)); //8
console.log(strs13.indexOf('o', 9)); //-1

//14-1. 특정 번째에 있는 값의 인덱스 찾기 -->  세번째 4 찾기
console.log('---------------------------------------------------- 특정 번째 인덱스 찾기');
const numbers = [2,3,4,3,5,8,5,3,4,8,4,2,1];
console.log(numbers);

console.log(numbers.indexOf(4));    // 2
console.log(numbers.indexOf(4, 3)); // 8
console.log(numbers.indexOf(4, 9)); // 10

//14-2. 특정 번째에 있는 값의 인덱스 찾기 -->  세번째 3 찾기
console.log(numbers.indexOf(3));    // 1
console.log(numbers.indexOf(3, numbers.indexOf(3)+1)); // 3
console.log(numbers.indexOf(3, numbers.indexOf(3, numbers.indexOf(3)+1)+1)); // 7

//11. 배열 붙이기 concat() 메서드
console.clear();
const myArr1 = [1, 2, 3, 4];
const myArr2 = [5, 6, 7, 8];

const myArr3 = myArr1.concat(myArr2);

console.log(myArr1);
console.log(myArr2);
console.log('---------------------------------------------------- concat() 배열');
console.log(myArr3); // 1, 2, 3, 4, 5, 6, 7, 8

//문자열
const str1 = "Hello";
const str2 = "World";
console.log('---------------------------------------------------- concat() 문자열');
console.log(str1.concat(', ', str2)); // Hello, World

--------------------------------------------------------------------------------------------------------------------------------------------


/***************************
TABLE INITRANS 변경(1->10)
***************************/
SELECT 'ALTER TABLE '||OWNER||'.'||TABLE_NAME||' INITRANS 10;'  FROM DBA_TABLES WHERE OWNER LIKE '%ADM' AND INI_TRANS=1;

ALTER TABLE WKJOBADM.JEP_TB_LAB300_STAT INITRANS 10;

/***************************
INDEX INITRANS 변경(2->20)
***************************/
SELECT 'ALTER INDEX '||OWNER||'.'||INDEX_NAME||' INITRANS 20;'  FROM DBA_INDEXES WHERE OWNER LIKE '%ADM' AND INDEX_NAME NOT LIKE '%$%' AND INI_TRANS=2;

ALTER INDEX DQMADM.PK_JF_QUERY_30 INITRANS 20;

--------------------------------------------------------------------------------------------------------------------------------------------


--1. 변경 전
CREATE INDEX IX_EI_COD_3000NT_15 ON EICODADM.TB_COD_3000NT(CVPL_RCEPT_DE,INSTT_SEQ_NO,CVPL_FORMAT_CD,CVPL_REQST_CNO);


--2. 변경 후
CREATE INDEX IX_EI_COD_3000NT_15 ON EICODADM.TB_COD_3000NT(CVPL_RCEPT_DE,INSTT_SEQ_NO,CVPL_FORMAT_CD,CVPL_REQST_CNO) 
NOLOGGING TABLESPACE TS_IDX_EI LOCAL ONLINE;

​가. NOLOGGING 옵션은 UNDO, REDO를 최소화하기 위한 옵션입니다.
나. LOCAL 옵션은 LOCAL 파티션 인덱스 생성을 위한 옵션입니다.
다. ONLINE 옵션은 DML(INSERT, UPDATE, DELETE 등)이 이뤄져도 LOCK발생을 우회하면서 INDEX를 생성하는 옵션입니다.

--------------------------------------------------------------------------------------------------------------------------------------------

[완료] (MDMIFDB 인덱스 생성검토) EICODADM.TB_COD_3000NT 인덱스 생성 

1. 아래의 구문을 사용한 인덱스 생성 : 45분 내외 소요됨

CREATE INDEX EICODADM.IX_EI_COD_3000NT_15 ON EICODADM.TB_COD_3000NT(CVPL_RCEPT_DE,INSTT_SEQ_NO,CVPL_FORMAT_CD,CVPL_REQST_CNO)
NOLOGGING TABLESPACE TS_IDX_EI LOCAL ONLINE;


2. 생성된 인덱스 10% 샘플링 통계수집

BEGIN
  SYS.DBMS_STATS.GATHER_INDEX_STATS (
     OwnName           => 'EICODADM'
    ,IndName           => 'IX_EI_COD_3000NT_15'
    ,Estimate_Percent  => 10
    ,Degree            => 4
    ,No_Invalidate  => FALSE);
END;
/

//10. splice() 메서드
//배열의 기존 요소를 삭제하거나 교체하고자 할 때 --> 새로운 요소를 추가 --> 배열의 값을 변경.
//특징1 --> 원본을 수정.
//특징2 --> 잘라내고(삭제하고) 이어 붙이기 기능

//기본 사용법
//splice(______, ______, ______, ______);
//splice(start, count(del), 값(item), 값(item));

console.clear();
console.log('---------------------------------------------------- splice()');

//원본배열
const oriArt10 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
console.log("원본 배열: "+oriArt10);

//10-1.
console.log('---------------------------------------------------- splice() 10-1');
const spliceAr1 = oriArt10.splice(5);
console.log(spliceAr1); // 6, 7, 8, 9, 10
console.log(oriArt10); // 1, 2, 3, 4, 5

//10-2.
console.log('---------------------------------------------------- slice() 10-2');
const sliceAr1 = oriArt10.slice(3);
console.log(sliceAr1); // 4, 5, 6, 7, 8, 9, 10
console.log( "원본 배열: " + oriArt10); // 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
console.log("원본 배열 길이: " + oriAr10.length); //7

//10-3.
const oriAr10 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
console.log('---------------------------------------------------- slice() 10-3');
const spliceAr3 = oriAr10.splice(3, 2, 'a', 'b', 'c');
console.log(spliceAr3); // 4, 5
console.log("원본 배열: "+ oriAr10); // 1, 2, 3, a, b, c, 6, 7, 8, 9, 10
console.log("원본 배열 길이: "+ oriAr10.length); // 11

//10-4.
console.clear();
console.log('---------------------------------------------------- slice() 10-4');
const oriStrings = ['서울', '부산', '인천', '경기', '전라', '경상', '충청'];
console.log(oriStrings);

// 지정한 인덱스 포함해서 2개를 삭제하고 --> 새로운 '강원', '제주' 를 추가
const oriStrings1 = oriStrings.splice(2, 2, '강원', '제주');
console.log(oriStrings1); // 인천, 경기
console.log(oriStrings); // 서울, 부산, 강원, 제주, 전라, 경상, 충청

// 마이너스 지정
const oriStrings2 = oriStrings.splice(-2);
console.log(oriStrings2); // 경상, 충청
console.log(oriStrings); // 서울, 부산, 강원, 제주, 전라

//0 지정
const oriStrings3 = oriStrings.splice(3, 0, '진도');
console.log(oriStrings3); // [] --> 지정한 인덱스 자리에 삭제하는 것 없이 --> 새로운 요소 삽입
console.log(oriStrings); // '서울', '부산', '인천', '경기', '전라' --> '서울', '부산', '인천', '진도', '경기', '전라'

*** 쿠버네티스 오케스트레이션 : 쿠버네티스 클러스터 구축 / Prometheus 이용한 모니터링 구축

1. kubeadm은 Kubernetes Cluster 생성을 위한 kubeadm init과 kubeadm join을 위한 툴이다.

Kubeadm은 Kubernetes의 공식 설치 도구이다. 확장성이 뛰어나며 지속적으로 개발되고 있다. kubeadm init : Control-plane 노드의 부트스트랩, kubeadm join : Worker 노드를 부트스트랩하고 Cluster에 조인, kubeadm upgrade : Kubernetes Cluster를 신규 버전으로 업그레이드 등의 옵션 및 기능이 있다.

2. 파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다.

쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 클러스터(Cluster) 에서의 Running 프로세스를 나타낸다. 파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, container 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다.

* K8S 클러스터 네트워킹
- 전체 클러스터를 위한 하나의 가상 네트워크
- 각 파드에는 고유한 IP가 존재
- 서비스는 파드와 다른 범위의 IP 대역을 가짐
- 클러스터 CIDR: 클러스터 내 파드에 할당하는데 사용되는 IP 범위
- 서비스 클러스터 IP 범위: 서비스에 대한 IP범위, 이것은 클러스터 CIDR와 중복 불가
- 파드 CIDR: 특정 노드 내 파드에 대한 IP 범위, 이 범위는 클러스터 CIDR 내에 있어야 하지만 다른 노드의 파드 CIDR과 겹치면 안됨
- IP는 컨테이너가 아니라 파드에 할당된다.
- 컨테이너간 통신: Highly-coupled 된 컨테이너간 통신을 위해 pods와 로컬 호스트 통신으로 해결
- 파드와 서비스 통신: 서비스에서 담당
- 외부와 서비스 통신: 서비스에서 담당
- Pod 내부의 container-to-container 통신: 컨테이너 엔진(예컨데, 도커)
- 외부와 Pod의 통신: Service, Ingress, Engress

-----------------------------------------------------------------------------------------------------------------------------------

* K8S 클러스터 네트워킹 구성
- 사용자의 Pod 접속: 인터넷 사용자들의 클라이언트는 Pod에 직접 접속할 수 있고 Service를 설정해야 함
- 서비스 정책: Service는 kube-proxy에 의해 관리되고 여러 개의 iptables 규칙으로 설정
- Service의 외부 연결 방법: (1) NodePort , (2) clusterIP, (3) LoadBalancer

1. K8S Worker Network
- K8S는 Pod 단위로 배포가 되며 하나의 Pod는 Overlay Network을 가진다.
- Pod는 하나 이상의 컨테이너를 가지게 되지만 Pod에는 하나의 IP만 부여

2. Node간 Network Communication
- 서로 다른 노드에 있는 Pod간 통신은 Proxy Container(kube-proxy)를 통해서 구성

3. 외부와 Network Communication
- 클라이언트가 외부에서 해당 서비스에 접근하기 위해서는 크게 NodePort와 LoadBalancer를 사용할 수 있다.
- NodePort는 해당 Worker 노드의 포트를 외부에 오픈해서 사용자가 직접 Worker 노드의 포트로 직접 접속하는 방식
- LoadBalancer의 경우 서비스를 배포하고 나면 External IP로 LoadBalancer로 셋팅

4. Ingress
- Service와 Pod는 클러스터 네트워크에 의해 라우팅이 가능한 IP들을 가진다. 
- Ingress란 클러스터 서비스들에게 연결하기 위한 inbound connection을 허용하는 규칙들의 모음
- 단순히 트래픽을 로드밸런싱 해주는 것 이외에도 SSL, Virtual Host 등의 기능을 제공
- Ingress를 사용시 NodePort로 서비스를 배포

5. Overlay Network
- 가상 네트워크 인터페이스와 Bridge와 Routing rule의 조합을 Overlay Network 
- K8S 네트워크에서는 Overlay Network를 이용하여 Pod들이 서로 정보를 주고 받기 때문에 Pod 네트워크라고 함

6. CNI : 컨테이너 네트워크 인터페이스
- CNCF 프로젝트 중 하나
- 리눅스 컨테이너(예컨데, 도커)를 위한 네트워킹으로 런타임과 플러그인 간의 상호 작용을 정의
- 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기
www.cncf.io

7. Adopters(Plugins)
 7-1. Container runtimes
  CoreOS Tectonic : Enterprise Ready ,  Upstream Kubernetes
  rkt : Container engine
  Kurma : Container runtime
  K8S : a system to simplify container operations
  Openshift : Redhat's container platform
  Cloud Foundry : a platform for cloud applicatoins
  Apache Mesos : a distributed systems kernel
 
 7-2. 3rd party plugins
  Project Calico - a layer 3 virtual network
  Weave - a multi-host Docker network
  Contiv Networking - policy networking for various use cases 
  SR-IOV
  Cilium : BPF & XDP for containers
  Infoblox : enterprise IP address management for containers
  Multus : a Multi plugin
  Romana : Layer 3 CNI plugin supporting network policy for K8S
  CNI Genie : generic CNI network plugin
  Flannel a network fabric for containers, designed for K8S
  CoreOS K8S Namespace CNI - select CNI plugin per-namespace
  VMware NSX plugin
  Nuage VSP plugin
 
8. 쿠버네티스 클러스터 네트워크는 전체 클러스터를 위한 하나의 가상 네트워크로 각 파드에는 고유한 IP가 존재하며 서비스는 파드와 다른 범위의 IP 대역을 가진다.
9. 쿠버네티스에서 IP는 container가 아니라 pod에 할당된다.
10. 컨테이너 네트워크 인터페이스(CNI)는 리눅스 컨테이너를 위한 네트워킹으로 런타임과 플러그인 간의 상호작용을 정의하며 표준 API를 제공한다.

11. 쿠버네티스 클러스터 구축은 컨테이너 가상화인 도커를 기반으로 쿠버네티스 패키지 설치를 통해 구축된다.
12 Prometheus를 이용한 모니터링 구축은 쿠버네티스 기반으로 ConfigMap 생성, 배포 및 서비스 생성, 가시화 도구 설치 등으로 구축된다.

-----------------------------------------------------------------------------------------------------------------------------------

1. 쿠버네티스 컨테이너를 실행하는 하드웨어 호스트, 즉 노드에 대한 지표 모니터링이 필요하다.

쿠버네티스는 노드의 CPU, 메모리, 디스크, 네트워크 사용량과 노드 OS와 커널에 대한 모니터링이 필요하다.

2. 프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 서비스 디스커버리 (Service discovery)를 사용한다.

모니터링 대상 목록을 유지하고 있고, 대상에 대한 IP나 기타 접속 정보를 설정 파일에 주면, 그 정보를 기반으로 프로메테우스 서버가 모니터링 정보를 읽어온다. 오토스케일링을 많이 사용하는 클라우드 환경이나 쿠버네티스와 같은 컨테이너 환경에서는 모니터링 대상의 IP가 동적으로 변경되는 경우가 많기 때문에 이를 일일이 설정파일에 넣는데 한계가 존재하며 이러한 문제를 해결 하기 위해서 프로메테우스는 서비스 디스커버리 를 사용하는데, 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링 하는 형태이다.

1. 쿠버네티스 컨테이너를 실행하는 하드웨어 호스트, 즉 노드에 대한 지표 모니터링이 필요하다.

쿠버네티스는 노드의 CPU, 메모리, 디스크, 네트워크 사용량과 노드 OS와 커널에 대한 모니터링이 필요하다.

2. 프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 서비스 디스커버리 (Service discovery)를 사용한다.

모니터링 대상 목록을 유지하고 있고, 대상에 대한 IP나 기타 접속 정보를 설정 파일에 주면, 그 정보를 기반으로 프로메테우스 서버가 모니터링 정보를 읽어온다. 오토스케일링을 많이 사용하는 클라우드 환경이나 쿠버네티스와 같은 컨테이너 환경에서는 모니터링 대상의 IP가 동적으로 변경되는 경우가 많기 때문에 이를 일일이 설정파일에 넣는데 한계가 존재하며 이러한 문제를 해결 하기 위해서 프로메테우스는 서비스 디스커버리 를 사용하는데, 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링 하는 형태이다.

1. K8S 모니터링 시스템
 - 시스템을 운영하는데 있어서 운영 관점에 있어서 가장 중요한 기능 중의 하나는 시스템에 대한 모니터링
 - 시스템 자원의 사용량이나 에러 등에 대한 모니터링을 통해서 시스템을 안정적으로 운영하고 문제 발생시 원인 파악과 대응 가능
 - K8S 기반의 시스템 모니터링 대상
 가. 리소스: 리소스 모니터링은 클러스터와 어플리캐이션 헬스를 이해하기 위해 필수적
 나. 디스크: 임계치는 클러스터 사이즈와 상관이 없기 때문에, 디스크 사용량을 모니터링 하는 것은 디스크 볼륨을 모니터링 하는 것 보다 더 효율적
 다. CPU: CPU모니터링은 kube-state-mertics를 통해 가능하며 시스템, 사용자 사용량과 iowait 또한 모니터링 가능
 라. 메모리: 메모리 모니터링 또한 kube-state-merics에서 가능하며 메모리 사용량 확인 가능
 마. Pod: Pod Deployment의 헬스는 K8S가 제대로 작동하는지 확인
 사. 네트워크: 네트워트 대역폭

2. K8S 모니터링 시스템 : 4가지 계층
 2-1. 노드(호스트)
 - K8S 컨테이너를 실행하는 HW 호스트, 즉 노드에 대한 지표 모니터링이 필요
 - 노드의 CPU, 메모리, 디스크, 네트워크 사용량과 노드 OS와 커널에 대한 모니터링

 2-2. 컨테이너
 - 노드에서 기동되는 각각의 컨테이너에 대한 정보
 - 컨테이너의 CPU, 메모리, 디스크, 네트워크 사용량 등을 모니터링

 2-3. 애플리케이션
 - 컨테이너 안에서 구동되는 개별 애플리케이션의 지표를 모니터링
 - 컨테이너 기동되는 애플리케이션의 응답시간, 에러 빈도 등을 모니터링

 2-4. K8S
 - 컨테이너를 컨트롤 하는 K8S 자체에 대한 모니터링
 - K8S의 자원인 서비스나 Pod, 계정 정보 등

* 모니터링 아키텍처
 1. 프로메테우스 기반 모니터링 아키텍처
 - 프로메테우스는 SoundCloud에서 개발된 모니터링 툴
 - '16년에 CNCF에 오픈소스 프로젝트 기부
 - 프로메테우스의 주요 기능으로 시계열 데이터를 저장할 수 있는 다차원 데이터 모델과 이 데이터 모델을 효과적으로 활용할 수 있는 PromQL이라는 쿼리 언어
 - 수집대상을 정적으로 설정할 수 있고 Service Discovery 를 통해서 동적으로 설정하는 것도 가능
 - 데이터 저장은 디스크에 저장하는 것도 가능하지만 외부 스토리지에 저장하는 것 가능

 - (프로메테우스 서버) 시계열 데이터를 수집해와서 저장하는 메인 컴포넌트
 - (클라이언트 라이브러리) 애플리케이션을 개발할 때 프로메테우스에서 데이터를 수집
 - (pushgateway) 클라이언트에서 직접 프로메테우스로 데이터 전송시 송신
 - (exporter) 프로메테우스를 클라이언트 라이브러리를 내장해서 만들어지지 않은 애플리케이션들에서 데이터를 수집
 - (AlertManager) 알람을 보낼 때 알람의 중복처리,그룹핑 등과 알람

2. 데이터 수집 부분
- 기본적으로 프로메테우스는 데이터 수집을 Pulling 모델을 사용
- 모니터링 대상이 되는 자원이 지표 정보를 프로메테우스로 보내는 것이 아니라 프로메테우스가 주기적으로 모니터링 대상에서 지표를 읽는 모델을 사용
- 모니터링 대상이 프로메테우스의 데이터 포멧을 지원할 경우 바로 읽어올 수 있고 만약에 지원하지 않는다면 별도의 에이전트를 설치해서 지표를 읽어올 수 있는데, 이를 exporter라고 함
- mysql, nginx, redis와 같은 패키지는 미리 개발된 export가 있어서 다양한 서비스의 지표까지 쉽게 수집 가능
- 프로메테우스 클라이언트 라이브러리를 사용하게 되면 바로 지표를 프로메테우스 서버로 전송 가능
- push gateway가 지표를 보관하고 있다가 프로메테우스 서버가 Pulling을 하면 저장된 지표 정보를 리턴

----------------------------------------------------------------------------------------

*모니터링 시스템 구축
1. 서비스 디스커버리 : 모니터링 대상 목록을 유지하고 대상에 대한 ip나 기타 접속 정보를 설정 파일에 주면 그 정보를 기반으로 프로메테우스 서버가 모니터링 정보 수집 / 모니터링 대상이 등록되어 있는 저장소에서 목록을 받아서 그 대상을 모니터링하는 형태 / DNS나 Consul, etcd와 같은 다양한 서비스 디스커버리 서비스와 연동을 통해서 자동으로 모니터링 대상의 목록 수집 가능
2. azure_sd_configs / consul_sd_configs / dns_sd_configs / ec2_sd_configs / openstack_sd_configs / file_sd_configs / gce_sd_configs / kubernetes_sd_configs
3. 저장 및 시각화
- 수집된 지표 정보들은 프로메테우스 내부의 시계열 DB에 저장
- 프로메테우스 웹 콘솔을 이용하여 시각화 되거나 또는 API를 외부에 제공해서 Grafana와 같은 시각화 툴을 통해서 지표를 시각화
4. 알림 서비스
- 부가 기능 중의 하나로 alerting 컴포넌트는 지표에 대한 규칙을 설정하고 규칙을 위반할 경우에는 알림을 보낼 수 있는 기능
- 알림을 보내는 대상은 이메일이나 pagerduty와 같은 notification 서비스 등과 연동 가능

----------------------------------------------------------------------------------------

*K8S 연동 아키텍처
1. 프로메테우스 서버가 모니터링할 리소스를 찾기 위해서 Service Discovery 메커니즘 필요
2. K8S API를 호출하고 자원들의 목록(Pod, Node, Service,  Ingress, Endpoint 등)의 목록을 Label Selector를 이용하여 수집
3. 수집된 모니터링 대상에 대해서 모니터링 수행
4. K8S는 apiServer에서 /metric 이라는 URL을 통해서 기본적인 지표 정보를 리턴
5. K8S 자원들에 대한 모니터링은 api를 통해서 수집

시스템을 운영하는데 있어서 운영 관점에 있어서 가장 중요한 기능 중의 하나는 시스템에 대한 모니터링이다.
K8S 기반의 시스템 모니터링 대상은 리소스, 디스크, CPU, 메모리, Pod, 네트워크 등이 있다.
K8S 시스템 모니터링 4가지 계층은 노드(호스트), 컨테이너, 애플리케이션, 쿠버네티스로 구성된다.

----------------------------------------------------------------------------------------

*** 쿠버네티스 보안
계정인증
네트워크 정책
Pod Security Policy
Security Context


1. 쿠버네티스는 자체적으로 사용자 계정을 관리하고 이를 인증(Authenticate)하는 시스템이 없다.

반드시 별도의 외부 계정 시스템을 사용해야 하며 외부계정시스템의 형태로 지원하며 OAuth나 구글 계정(Google Account)이나 오픈스택의 키스톤(keystone)과 같은 계정 연동 방식을 지원한다.

2. 쿠버네티스는 클러스터 내부에 가상네트워크를 구성해서 사용하는데, 이때 kube-proxy 이외에 네트워킹 관련한 애드온을 사용한다.

AWS, 애저, 구글클라우드같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 사용하지 않아도 된다. 쿠버네티스를 직접 보유중인 서버들에 설치해서 구성을 하려고 하려면 네트워킹 관련 애드온을 설치해서 사용해야 한다. 네트워킹 애드온의 종류는 10개가 넘을 정도로 다양하게 있다. ACI, Calico, Canal, Cilium, CNI-Genie, Contiv, Falannel, Multus, NSX-T, Nuage, Romana, Weave Net등이 있고, OCI의 CNI(Container Network, Interface) 를 구현하고 있다면 다른 애드온들도 사용할 수 있다.

----------------------------------------------------------------------------------------

*계정인증
- 계정체계를 관리함에 있어서 사람이 사용하는 사용자 어카운트와 시스템이 사용하는 서비스 어카운트 두 가지 개념을 제공
1. 일반적인 사용자
- 일반적인 사용자는 우리가 일반적으로 생각하는 사용자 아이디의 개념
- 자체적으로 사용자 계정을 관리하고 이를 인증(Authenticate)하는 시스템이 없음
- 반드시 별도의 외부 계정 시스템을 사용해야 하며 계정 시스템 연동을 위해서 OAuth나 구글계정(Google Account)이나 오픈스택의 Keystone과 같은 계정 연동 방식을 지원

2. 서비스 아카운트
- 직접 관리하는 사용자 계정
- 클라이언트가 K8S API를 호출하거나 콘솔이나 기타 클라이언트가 K8S API를 접근하고자 할 때는 이는 실제 사용자가 아니라 시스템

3. 인증(Authentication) 방법
- Basic HTTP Auth : HTTP 요청에 사용자 아이디와 비밀번호를 실어 보내서 인증하는 방식
- Access token via HTTP Header : 일반적인 REST API 인증에 많이 사용되는 방식
- Client cert :  클라이언트의 식별을 인증서(Certification)을 이용해서 인증하는 방식
- Custom made

4. 권한 관리(Authorization)
- 권한 처리 체계는 기본적으로 역할기반의 권한 인가 체계
- ABAC(Attribute-based access control)와 RBAC(Role-based access control) 2가지 방법 제공

4-1. ABAC
- 단어의 의미 그대로 속성 기반의 권한 관리
- 사용가능한 속성으로는 일반적으로 사용자, 그룹, 요청경로, 요청동사 등 외에도 네임스페이스, 자원 등으로 설정

4-2. RBAC
- 역할 기반권한 관리
- 사용자와 역할을 별개로 선언한 다음에 그 2가지를 Binding해서 사용자에게 권한을 부여
- 서버에 접근할 필요없이 kubectl이나 api를 이용해서 관리하는 것이 가능

----------------------------------------------------------------------------------------

*** 네트워크 정책 개념
- Pod그룹에 대해, 서로간 또는 외부 네트워크 엔드포인트와의 통신여부를 결정하는 정책
- 네트워크 정책으로 Pod간 통신, 네임스페이스간 통신, 포트 번호 지정 등을 서술적으로 설정할 수 있음
- NetworkPolicy 리소스들은 Pod들을 선택하고 선택된 Pod들에 허용되는 트래픽을 특정하는 규칙을 정의하기 위해 레이블을 사용함
- 네트워크 정책들은 네트워크 Provider가 제공하는 네트워크 플러그인을 통해 실현됨.

*** 네트워크 정책
1. Ingress 트래픽 컨트롤 정의
- ipBlock : CIDR IP 대역으로, 특정 IP대역에서만 트래픽이 들어오도록 지정
- podSelector : label을 이용하여, 특정 label을 가지고 있는 Pod들에서 들어오는 트래픽만 수신 가능
- namespaceSelector : 특정 namespace로 부터 들어오는 트래픽만 수신 가능
- Protocol & Port : 받을 수 있는 프로토콜과 허용되는 포트를 정의

2. Engress 트래픽 컨트롤 정의
- Engress 트래픽 컨트롤은 ipBlock과 Protocol & Port 두 가지만 지원
- ipBlock : 트래픽이 나갈 수 있는 ip 대역을 정의
- Protocol & Port : 트래픽을 내보낼 수 있는 프로토콜과 포트를 정의

----------------------------------------------------------------------------------------

* 네트워킹 에드온
- K8S는 클러스터 내부에 가상네트워크를 구성해서 사용하는데, 이때 kube-proxy 이외에 네트워킹 관련한 에드온을 사용
- AWS, Azure, Google Cloud 같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 에드온을 사용하지 않더라도 각 클라우드 벤더에서 구현되어 있음
- 쿠버네티스를 직접 보유중인 서버들에 설치해서 구성을 하려고 하려면 네트워킹 관련 에드온을 설치해서 사용해야함
- 네트워킹 애드온의 종류는 ACI, Calico, Canal, Cilium, CNI-Genie, Contiv, Flannel, Multus, NSX-t, Nuage, Romana, WeaveNet 등이 있고, OCI의 CNI(Container Network Interface)를 구현하고 있다면 다른 애드온들도 사용 가능 

----------------------------------------------------------------------------------------

* Security Context
- Pod나 컨테이너에 대한 접근제어 설정이나 특수 권한을 설정하는 기능을 제공
- Pod 또는 컨테이너의 권한부여, 환경설정 접근을 정의하는 SecurityContext 필드
- Pod 또는 컨테이너 내의 securityContext 필드는 컨테이너 프로세스들이 사용하는 사용자(runAsUser)와 그룹(fsGroup), 가용량, 권한 설정, 보안 정책(SELinux/AppArmor/Seccomp)을 설정하기 위해 사용됨
- 런타임 UID, GID를 포함함

----------------------------------------------------------------------------------------

* Pod Security Policy
- SecurityContext는 컨테이너나 Pod의 보안 기능을 정의
- Pod Security Policy는 보안 기능에 대한 정책을 정의
- Pod 생성/업데이트에 관한 세밀한 권한인증 제공
- Pod 스펙에 대한 보안적 측면을 통제하는 클러스터-수준 리소스
- PodSecurityPolicy 객체는, 관련 필드들에 대한 기본값들을 포함하여, Pod가 시스템 내로 받아들여지기 위해 구동될 때의 조건들 집합을 정의함
- Pod 보안정책 통제는 선택적인 입장 승인 컨트롤러로서 구현됨

----------------------------------------------------------------------------------------

* K8S는 계정 체계를 관리함에 있어서 일반적인 사용자 계정과 시스템이 사용하는 서비스 계정 두 가지 개념을 제공한다.
* 네트워크 정책 정책은 Pod 그룹에 대해 서로간 또는 외부 네트워크 엔드포인트와의 통신여부를 결정하는 정책이다.
* K8S의 Pod나 컨테이너에 대한 접근 제어 설정이나 특수 권한을 설정하는 기능을 제공하는데 이를 Security Context라고 한다.
* SecurityContext는 컨테이너나 Pod의 보안 기능을 정의하고 Pod Security Policy는 보안 기능에 대한 정책을 정의한다.

1. 쿠버네티스 롤링 업데이트는 기존 버전과 새버전이 동시에 존재할 수 있는 단점은 있지만, 시스템을 무 장애로 업데이트할 수 있다는 장점이 있다.

롤링 업데이트는 가장 많이 사용되는 배포 방식 중의 하나이다. 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 해준다. 새로운 파드는 가용한 자원을 보유한 노드로 스케줄될 것이다. 새 버전을 배포하면서, 새 버전 인스턴스를 하나씩 늘려나가고, 기존 버전을 하나씩 줄여나가는 방식이다.

2. 쿠버네티스는 Deployment, StatefulSets, DaemonSet, Job, CronJob등 다양한 배포 방식을 지원한다.

Deployment는 새로운 버전의 애플리케이션을 다양한 전략으로 무중단 배포 가능하고, StatefulSets은 실행 순서를 보장하고 호스트 이름과 볼륨을 일정하게 사용할 수 있어 순서나 데이터가 중요한 경우에 사용 가능하며 로그나 모니터링 등 모든 노드에 설치가 필요한 경우엔 DaemonSet을 이용하고 배치성 작업은 Job이나 CronJob을 이용한다.

롤링 업데이트 / Deployment / ConfigMap

1. 롤링 업데이트
 - 일반적으로 애플리케이션을 배포하는 방법은 블루/그린, 카날리 배포, 롤링 업데이트 등이 존재
 - 롤링 업데이트는 가장 많이 사용되는 배포 방식 중의 하나
 - 롤링 업데이트는 파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 하는 방법
 - 사용자들은 애플리케이션이 항상 가용한 상태일 것이라 여기고 개발자들은 하루에 여러번씩 새로운 버전을 배포하도록 요구됨. 
   (시스템을 무 장애로 업데이트할 수 있다는 장점)

1-1. 롤링 업데이트 방식
 - 여러 개의 인스턴스를 동작 시키도록 애플리케이션을 스케일하는 것은 애플리케이션의 가용성에 영향을 미치지 않으면서 업데이트를 수행하는 것에 대한 요구
 - 기본적으로 업데이트가 이루어지는 동안 이용 불가한 파드의 최대 개수와 생성 가능한 새로운 파드의 최대 개수는 하나
 - 애플리케이션 스케일링과 유사하게 디플로이먼트가 외부로 노출되면, 서비스는 업데이트가 이루어지는 동안 오직 가용한 파드에게만 트래픽을 로드밸런스 할 것이다. 가용한 파드란 애플리캐이션의 사용자들에게 가용한 상태의 인스턴스를 의미

1-2. 롤링 업데이트
 - 하나의 환경에서 또 다른 환경으로의  애플리캐이션Promotion(컨테이너 이미지 업데이트를 통해)
 - 이전 버전으로의 Rollback
 - 서비스 중단 없는 애플리케이션의 지속적인 통합과 지속적인 전달
 *디플로이먼트가 외부로 노출되면, 서비스는 업데이트가 이루어지는 동안 오직 가용한 파드에게만 트래픽을 로드밸런스 할 것이다.

---------------------------------------------------------------------------------------------------------------------------------------------

1. 디플로이먼트의 개념
 - K8S에서 일반적으로 Replicatoin Controller(RC)를 이용해서 배포하지 않고 Deployment라는 개념 사용
 - 복제된(replicated) 애플리케이션을 관리하는 API 객체
 - 각 레플리카는 각각 하나의 Pod로 대표되며, 그러한 Pod들은 클러스터 내 노드들에 걸쳐 배포된다.
 - ReplicaSet(+Pod) 생성
 - 롤링 업데이트 등을 할 때 RC를 두 개를 만들어야 하고 하나씩 Pod의 수를 수동으로 조정해야 하기 때문에 이를 자동화해서 추상화한 개념이 Deployment
 - Deployment는 기본적으로 Replicatoin Controller(RC)를 생성하고 이를 관리하는 역할

2. 디플로이먼트의 특징
 - 디플로이먼트는 K8S가 애플리캐이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시
 - 디플로이먼트가 만들어지면, K8S 마스터가 해당 애플리캐이션 인스턴스를 클러스터의 개별 노드에 스케줄
 - 애플리캐이션 인스턴스가 생성되면, K8S 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를 모니터링
 - 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 매커니즘을 제공
 * 디플로이먼트는 애플리캐이션 인스턴스를 생성하고 업데이트하는 역할을 담당
 - kubectl 이라는 cli를 통해 디플로이먼트를 생성 및 관리
 - kubectl은 클러스터와 상호 작용하기 위해 K8S API를 사용
 - 디플로이먼트를 생성할 때, 애플리캐이션에 대한 컨테이너 이미지와 구동시키고자 하는 복제 수를 지정
 * 애플리케이션이 K8S 상에 배포되려면 지원되는 컨테이너 형식 중 하나로 패키지 되어야 한다.

---------------------------------------------------------------------------------------------------------------------------------------------

1. ConfigMap 개념
- 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해 주기 위한 기능 / 클라우드 네이티브 아키텍처에서 컨테이너는 변하지 않는 자원
 - 비 기밀 데이터를 key-value 쌍으로 저장하기 위해 사용하는 API 객체
 - 컨테이너 이지미에서 설정 데이터를 분리(decouple)시키기 위한 것
 - 컨테이너 이미지에서 사용하는 환경변수와 같은 세부 정보를 분리하고, 그 환경변수에 대한 값을 외부로 노출 시키지 않고 내부에 존재하는 스토리지에 저장해서 사용하는 방법
 - 환경변수, 커맨드라인 인자, 볼륨 내의 설정파일로 사용 가능
 - ConfigMap을 사용하면 컨테이너 이미지에서 해당 환경에 국한된 설정을 분리 가능 / 애플리케이션을 어디로든 쉽게 이전 가능(portable)
 - ConfigMap을 변경하더라도 Running 상태의 Pod에 곧바로 적용되지 않으며 Pod를 재기동 해야 한다.
 - 생성된 ConfigMap은 kubectl get configmap 명령으로 확인

2. ConfigMap 사용법 : ConfigMap을 컨테이너에서 가져다 사용하는 방법은 3가지
 - File systme : Pod에 ConfigMap을 mount할 수 있다. Key 이름에 따라 각 항목의 파일이 생성됨 / 해당 파일의 내용은 값으로 설정
 - Enviroment variable : ConfigMap을 사용해 환경변수의 값을 동적으로 설정
 - Command-line arguement : K8S는 ConfigMap 값을 기반으로 컨테이너에 대한 명령줄을 동적으로 생성하도록 지원

3. K8S에서 애플리케이션을 배포하는 방법은 블루/그린, 카날리 배포, 롤링 업데이트 등에 존재한다. 롤링 업데이트는 Pod 인스턴스를 점진적으로 새로운 것으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 하는 방법이다.
 K8S 디플로이먼트는 복제된(replicated) 애플리케이션을 관리하는 API 객체로 각 레플리카는 각각 하나의 Pod로 대표되며, 그러한 Pod들은 클러스터 내 노드들에 걸쳐 배포된다.
 ConfigMap은 비 기밀 데이터를 key-value 쌍으로 저장하기 위해 사용하는 API 객체로 컨테이너에서 필요한 환경설정 내용을 컨테이너와 분리해서 제공해 주기 위한 기능을 제공한다.

1. 쿠버네티스 볼륨은 디스크 서비스로 Pod 내 컨테이너들이 접근가능하다.

쿠버네티스 볼륨은 데이터를 담는 디렉토리로 pod 내에서 구동되는 컨테이너들보다 오래 유지되며, 그 데이터는 컨테이너가 재시작되더라도 계속 보존되며, 로컬 디스크, configMap, secret, persistentVolumeClaim, emptyDir, hostPath 등이 있다.

2. 쿠버네티스 서비스는 포트, 로드밸런서를 기술할 수 있다.

쿠버네티스 서비스는 지정된 IP로 생성이 가능하고, 여러 Pod를 묶어서 로드 밸런싱이 가능하며, 고유한 DNS 이름을 가질 수 있으며, 멀티 포트 지원, Pod 간에 랜덤으로 부하를 분산하는 로드 밸런싱 알고리즘도 지원된다.

3. K8S 헬스 체크

쿠버네티스는 각 컨테이너의 상태를 주기적으로 체크해서, 문제가 있는 컨테이너를 자동으로 재시작하거나 또는 문제가 있는 컨테이너(Pod를) 서비스에서 제외할 수 있다. 이러한 기능을 헬쓰 체크라고 하는데, 크게 두가지 방법이 있다.

컨테이너가 살아 있는지 아닌지를 체크하는 방법이 Liveness probe 그리고 컨테이너가 서비스가 가능한 상태인지를 체크하는 방법을 Readiness probe 라고 한다.