서문 실용주의가 필요한 이유: 특정 기술에 매이면 안 된다! 실용주의 프로그래머들은 다음 특징들 중 다수를 공유한다.얼리 어댑터 또는 새로운 것에 빨리 적응하는 사람호기심 많은 사람비판적인 사고의 소유자 > 곧이곧대로 믿지 않는다현실주의자 > 문제의 근본적인 특성을 이해하려 한다다방면에 능숙한 사람 1장 실용주의 철학 실용주의 프로그래머의 다른 점은 문제와 해법에 접근하는 태도와 방식, 철학에서의 차이업무 환경이 마음에 들지 않거나 하는 일이 지루하다면, 직접 그 문제를 고치기 위해 노력하라. > 하지만 너무 오래 노력하지는 말아라 문제가 일어났을 때 전문가답게 처리하는 방법은 솔직해지는 것이다. 소프트웨어 엔트로피 > 깨진 창문을 내버려 두지 말아라 적절히 고칠 시간이 없다면 일단 판자로 덮..
집합: 중복되는 원소가 없음 (구분할 수 있는 객체들의 모임) 진부분집합: 부분집합 중에서 전체와 같지 않은 것공집합은 모든 집합의 부분집합 분할: 하나의 집합을 서로소인 부분집합들로 나눔 (공집합 x)멱집합: 집합 A에 대하여 모든 부분집합들의 집합 (공집합 포함, 개수는 2^n개) 대칭차집합: A∪B에 속하지만 A∩B에는 속하지 않는 원소들곱집합cartesian product: A에 속하는 원소 a와 B에 속하는 원소 b에 대해 모든 순서쌍(a, b)의 집합 X = Y임을 증명하려면 X⊆Y이고 Y⊆X임을 보인다.
1. 설치 pip3 install jupyter 2. 열기 python -m notebook > 안 뜨면 localhost:8888 직접 접속해보기
Deployment POD 업데이트 전략 1. recreate 전략 2. blue-green deployment 서비스의 레이블 셀렉터를 변경해 한 번에 새 버전 POD로 전환 3. rolling update POD를 단계적으로 대체 오류 가능성: 명령을 맡은 프로세스가 하나씩 진행 > 버전 여러개 만들어진 채로 멈춰 있을 수 있음 + kubectl rolling-update 명령어는 k8s 1.18 이후 지원 중단 ++ 업데이트 프로세스가 서버가 아닌 클라이언트에 의해 수행되어, 장애 발생 시 중간 상태로 남게 됨 ++ 선언된 명령을 자체적으로 달성하는 쿠버네티스 운영 철학에도 맞지 않음 Deployment - 선언적 애플리케이션 업데이트 Deployment는 애플리케이션을 배포하고 선언적으로 업데이트..
Service Service 리소스 POD가 재생성되면 IP가 바뀌기때문에 직접 연결하는 데 문제가 생길 수 있음 그래서 서비스 리소스를 이용 한 번 할당받은 뒤에 바뀌지 않는 cluster IP 갖고 있음 Service 리소스가 cluster IP 할당받고, 사용자는 그 IP에 리퀘스트 요청 POD의 레이블(Selector)을 이용해서 서비스가 POD에 리퀘스트 전달 POD 앞단에서 사용자의 트래픽 Load Balancing하는 역할 Service 종류 ClusterIP 디폴트 서비스타입. 클러스터 내부에서 접속 가능 NodePort 각 Node의 지정된 port 할당하는 방식. 클러스터 내/외부 모두 접속 가능 LoadBalancer 로드밸런서의 IP 이용하여 클러스터 외부에서 접근 가능 Servic..
POD POD 하나 이상의 밀접하게 관련된 컨테이너로 구성된 그룹 동일한 리눅스 네임스페이스와 동일한 워커 노드에서 항상 함께 실행 POD가 필요한 이유 여러 개의 프로세스를 단일 단위로 관리할 수 있는 상위 레벨 구조의 필요성 밀접하게 연관된 프로세스를 함께 실행하고, 하나의 컨테이너에서 실행되는 것처럼 거의 동일한 환경을 제공하며 격리된 상태로 유지 쿠버네티스는 각 컨테이너가 자체 세트를 가지고 있는 대신, POD 안의 모든 컨테이너가 동일한 리눅스 네임스페이스 세트를 공유하도록 함으로써 격리시킨다. POD 안의 컨테이너가 동일한 IP 및 포트 공간을 공유하는 방법 네트워크 네임스페이스 공유 POD 안의 컨테이너들은 같은 IP 주소와 PORT 공간 공유 localhost를 통해 같은 POD 안의 다른..