전체 글
많은 것을 알고 싶고 변화하는 나의 과정을 기록하고, 공유 하는
-
사용자의 접근 경우 Service가 만들어진 후에 IP를 확인하고, 이 IP로 접근을 하면 되는데(10.111.41.1) Pod의 경우 이 자원들이 동시에 배포가 될 수 있습니다. Pod A가 Pod B에 접근을 해야하는 상황인데 Pod A에 IP를 넣기에는 Pod나 Service가 동적으로 할당되기 때문에 미리 알기에는 제약이 있습니다. Pod B의 경우 문제가 생겨 죽으면 자동으로 재생성되면서 IP가 변경되기 때문에 Pod A가 IP를 알더라도 계속 쓸 수 없습니다. 이런 문제를 해결하기 위해 DNS, Headless 서비스가 필요합니다. Pod가 외부 특정 사이트에 접근해서 데이터를 가져오는 상황에서 접근 주소를 변경해야 되는 상황이 생기면 경로를 변경해주기 위해 Pod를 수정하고 재배포해야 될까요..
13. Basic Object - Service사용자의 접근 경우 Service가 만들어진 후에 IP를 확인하고, 이 IP로 접근을 하면 되는데(10.111.41.1) Pod의 경우 이 자원들이 동시에 배포가 될 수 있습니다. Pod A가 Pod B에 접근을 해야하는 상황인데 Pod A에 IP를 넣기에는 Pod나 Service가 동적으로 할당되기 때문에 미리 알기에는 제약이 있습니다. Pod B의 경우 문제가 생겨 죽으면 자동으로 재생성되면서 IP가 변경되기 때문에 Pod A가 IP를 알더라도 계속 쓸 수 없습니다. 이런 문제를 해결하기 위해 DNS, Headless 서비스가 필요합니다. Pod가 외부 특정 사이트에 접근해서 데이터를 가져오는 상황에서 접근 주소를 변경해야 되는 상황이 생기면 경로를 변경해주기 위해 Pod를 수정하고 재배포해야 될까요..
2024.01.16 -
Mysql 5.7 이후 암호화 기능은 처음에 데이터 파일에 대해서만 암호화 기능이 제공됐다. 8.0 버전부터는 추가로 리두 로그, 언두 로그, 복제를 위한 바이너리 로그 등 모두 암호화 기능을 지원하기 시작했다. 7.1 Mysql 서버의 데이터 암호화 Mysql 서버 암호화 기능은 데이터베이스 서버와 디스크 사이의 데이터 읽고 쓰기 지점에서 암호화 또는 복호화를 수행한다. 별도의 Mysql 서버에서 디스크 입출력 이외의 부분에서는 암호화 처리가 전혀 필요 없다. 즉 Mysql 서버의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행되는 것이다. MySQL 서버에서는 사용자의 쿼리를 처리하는 과정에서 테이블의 데이터가 암호화 되어있는지 확인할 필요가없다. 왜냐하면, 스토리지에서 데이터를 쓰기전에 ..
7. 데이터 암호화Mysql 5.7 이후 암호화 기능은 처음에 데이터 파일에 대해서만 암호화 기능이 제공됐다. 8.0 버전부터는 추가로 리두 로그, 언두 로그, 복제를 위한 바이너리 로그 등 모두 암호화 기능을 지원하기 시작했다. 7.1 Mysql 서버의 데이터 암호화 Mysql 서버 암호화 기능은 데이터베이스 서버와 디스크 사이의 데이터 읽고 쓰기 지점에서 암호화 또는 복호화를 수행한다. 별도의 Mysql 서버에서 디스크 입출력 이외의 부분에서는 암호화 처리가 전혀 필요 없다. 즉 Mysql 서버의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행되는 것이다. MySQL 서버에서는 사용자의 쿼리를 처리하는 과정에서 테이블의 데이터가 암호화 되어있는지 확인할 필요가없다. 왜냐하면, 스토리지에서 데이터를 쓰기전에 ..
2024.01.14 -
Mysql 서버에서 디스크에 저장된 데이터 파일의 크기는 일반적으로 쿼리의 처리 성능과도 직결되지만 백업 및 복구 시간과도 밀접하게 연관된다. 디스크의 데이터 파일은 클수록 쿼리를 처리하기 위해서 더 많은 데이터 페이지를 InnoDB 버퍼 풀로 읽어야 할 수도 있고, 새로운 페이지가 버퍼 풀로 적재되기 때문에 그만큼 더티 페이지가 더 자주 디스크로 기록돼야 한다. 그리고 데이터 파일이 크면 백업 시간이 오래걸리며, 복구 하는데 시간이 오래 걸린다. 이런 문제를 해결하기 위해 데이터 압축 기능을 제공한다. 크게 테이블 압축, 페이지 압축 2가지로 구분할 수 있다. 1. 페이지 압축 : "Transparent Page Compression" 이라고도 불리며, Mysql 서버가 디스크에 저장하는 시점에 데이터..
6. 데이터 압축Mysql 서버에서 디스크에 저장된 데이터 파일의 크기는 일반적으로 쿼리의 처리 성능과도 직결되지만 백업 및 복구 시간과도 밀접하게 연관된다. 디스크의 데이터 파일은 클수록 쿼리를 처리하기 위해서 더 많은 데이터 페이지를 InnoDB 버퍼 풀로 읽어야 할 수도 있고, 새로운 페이지가 버퍼 풀로 적재되기 때문에 그만큼 더티 페이지가 더 자주 디스크로 기록돼야 한다. 그리고 데이터 파일이 크면 백업 시간이 오래걸리며, 복구 하는데 시간이 오래 걸린다. 이런 문제를 해결하기 위해 데이터 압축 기능을 제공한다. 크게 테이블 압축, 페이지 압축 2가지로 구분할 수 있다. 1. 페이지 압축 : "Transparent Page Compression" 이라고도 불리며, Mysql 서버가 디스크에 저장하는 시점에 데이터..
2024.01.13 -
QoS class 위 Qos는 노드에 이렇게 리소스가 있다고 가정하고, 이 노드 위에 Pod가 3개 만들어져서 자원을 모두 사용하고 있는 상태라고 가정합니다. 이 상태에서 Pod1이 추가적으로 자원이 필요할 때 노드에는 추가적으로 할당받을 수 있는 자원이 없기 때문에, 선택을 해야합니다. k8s는 앱의 중요도에 따라 이런 것을 관리할 수 있도록 3가지 단계로 Quality of Service를 지원해주고 있습니다. 현재 위 상태에서는 1. Best Effort가 부여된 Pod가 가장 먼저 다운이 돼서 자원이 반환됩니다. Pod1은 필요한 자원을 추가로 얻게 됩니다. 다음엔 어느 정도 노드에 자원이 남아있지만, Pod2에서 그보다 많은 자원을 요구하는 상황이 됐다면, 2. Burstable이 적용된 Pod..
12. QoS classes (Guaranteed, Burstable, BestEffort) & Node SchedulingQoS class 위 Qos는 노드에 이렇게 리소스가 있다고 가정하고, 이 노드 위에 Pod가 3개 만들어져서 자원을 모두 사용하고 있는 상태라고 가정합니다. 이 상태에서 Pod1이 추가적으로 자원이 필요할 때 노드에는 추가적으로 할당받을 수 있는 자원이 없기 때문에, 선택을 해야합니다. k8s는 앱의 중요도에 따라 이런 것을 관리할 수 있도록 3가지 단계로 Quality of Service를 지원해주고 있습니다. 현재 위 상태에서는 1. Best Effort가 부여된 Pod가 가장 먼저 다운이 돼서 자원이 반환됩니다. Pod1은 필요한 자원을 추가로 얻게 됩니다. 다음엔 어느 정도 노드에 자원이 남아있지만, Pod2에서 그보다 많은 자원을 요구하는 상황이 됐다면, 2. Burstable이 적용된 Pod..
2024.01.12 -
Lifecycle Pod는 해당 라이프사이클 단계에 따라 주요 행동들이 있습니다. status 안에 Phase라고 해서 Pod의 전체 상태를 대표하는 속성이 있습니다. 그리고 Pod가 생성되면서 실행하는 단계들이 있는데 그 단계와 상태를 알려주는 것이 Conditions라는 특성입니다. 또한 컨테이너마다도 State라고 해서 각각의 컨테이너를 대표하는 상태가 있습니다. 먼저 Pod를 대표하는 Phase 종류는 아래와 같습니다. (1) Pending, (2) Running (3) Succeeded, (4) Failed, (5) Unknown Conditions는 4종류가 있고, Reason이라고 해서 Condition의 세부 내용을 알려주는 항목이 있습니다. (1) Initizlized, (2) Conta..
11. Pod - Lifecycle & (ReadinessProbe, LivenessProbe)Lifecycle Pod는 해당 라이프사이클 단계에 따라 주요 행동들이 있습니다. status 안에 Phase라고 해서 Pod의 전체 상태를 대표하는 속성이 있습니다. 그리고 Pod가 생성되면서 실행하는 단계들이 있는데 그 단계와 상태를 알려주는 것이 Conditions라는 특성입니다. 또한 컨테이너마다도 State라고 해서 각각의 컨테이너를 대표하는 상태가 있습니다. 먼저 Pod를 대표하는 Phase 종류는 아래와 같습니다. (1) Pending, (2) Running (3) Succeeded, (4) Failed, (5) Unknown Conditions는 4종류가 있고, Reason이라고 해서 Condition의 세부 내용을 알려주는 항목이 있습니다. (1) Initizlized, (2) Conta..
2024.01.12 -
(CKA 공부에 전념하기 위해 잠시 멈췄습니다.) 1주차 - https://github.com/himJJong/-Mysql8.0-study/issues/1 2주차 - https://github.com/himJJong/-Mysql8.0-study/issues/2 3주차 - https://github.com/himJJong/-Mysql8.0-study/issues/3
RealMysql8.0(CKA 공부에 전념하기 위해 잠시 멈췄습니다.) 1주차 - https://github.com/himJJong/-Mysql8.0-study/issues/1 2주차 - https://github.com/himJJong/-Mysql8.0-study/issues/2 3주차 - https://github.com/himJJong/-Mysql8.0-study/issues/3
2024.01.11 -
노드들이 있고, 각각의 노드에 자원이 다르게 남아있는 상태에서 이전에 배운 ReplicaSet의 경우 Pod를 스케줄러에 의존해서 노드에 배치를 할 때 만약 노드1에 자원이 많이 남아 있는 상태면 위처럼 배치를 많이 할거고, 자원이 별로 없다면 Pod를 배치 안할 수 있습니다. DaemonSet : 노드의 자원 상태와 상관없이 모든 노드에 Pod가 하나씩 생긴다는 특징이 있습니다. 이렇게 사용되는 서비스로 대표적인 1. 성능 수집인데 각 노드들의 성능상태는 모두 감시 대상이죠. 그래서 모니터링 화면이 있을거고, 각각의 노드에 프로메테우스 같은 수집 에이전트가 깔여 있어야 모든 노드들의 정보들을 모니터링 시스템에 전달해 줄 수가 있습니다. 2. 로그 수집인데, 특정 노드에 문제가 파악했다면 로그를 확인해야..
10. Controller - DaemonSet, Job, CronJob노드들이 있고, 각각의 노드에 자원이 다르게 남아있는 상태에서 이전에 배운 ReplicaSet의 경우 Pod를 스케줄러에 의존해서 노드에 배치를 할 때 만약 노드1에 자원이 많이 남아 있는 상태면 위처럼 배치를 많이 할거고, 자원이 별로 없다면 Pod를 배치 안할 수 있습니다. DaemonSet : 노드의 자원 상태와 상관없이 모든 노드에 Pod가 하나씩 생긴다는 특징이 있습니다. 이렇게 사용되는 서비스로 대표적인 1. 성능 수집인데 각 노드들의 성능상태는 모두 감시 대상이죠. 그래서 모니터링 화면이 있을거고, 각각의 노드에 프로메테우스 같은 수집 에이전트가 깔여 있어야 모든 노드들의 정보들을 모니터링 시스템에 전달해 줄 수가 있습니다. 2. 로그 수집인데, 특정 노드에 문제가 파악했다면 로그를 확인해야..
2024.01.10 -
Deployment는 현재 한 서비스가 운영 중인데 이 서비스를 업데이트 해야 돼서 재배포를 해야 할 때 도움 주는 컨트롤러 입니다. 크게 아래와 같이 4가지 방식이 있습니다. ReCreate : Deployment를 만들면 이렇게 v1의 파드가 생성됩니다. 그리고 Pod 하나당 위와 같이 하나씩 자원이 사용된다고 가정하겠습니다. Deployment는 먼저 Pod 모두 삭제합니다. 그렇게 되면 서비스에 대한 다운타임이 발생하고, 자원 사용량도 없어지게 됩니다. 그 후 v2에 대한 Pod 2개를 만들어 줍니다. 단점은 다운타임이 발생해서 일시적인 정지가 가능한 서비스인 경우에만 가능한 방법입니다. Rolling Update : 원래의 상태에서 업그레이드 할 때 Deployment는 먼저 v2의 Pod를 하..
9. Controller - Deployment & 실습Deployment는 현재 한 서비스가 운영 중인데 이 서비스를 업데이트 해야 돼서 재배포를 해야 할 때 도움 주는 컨트롤러 입니다. 크게 아래와 같이 4가지 방식이 있습니다. ReCreate : Deployment를 만들면 이렇게 v1의 파드가 생성됩니다. 그리고 Pod 하나당 위와 같이 하나씩 자원이 사용된다고 가정하겠습니다. Deployment는 먼저 Pod 모두 삭제합니다. 그렇게 되면 서비스에 대한 다운타임이 발생하고, 자원 사용량도 없어지게 됩니다. 그 후 v2에 대한 Pod 2개를 만들어 줍니다. 단점은 다운타임이 발생해서 일시적인 정지가 가능한 서비스인 경우에만 가능한 방법입니다. Rolling Update : 원래의 상태에서 업그레이드 할 때 Deployment는 먼저 v2의 Pod를 하..
2024.01.10