전체 글

기억에 남는 내용- 이 책을 적용하실 때에 참고가 될 만한 ‘XP 적용 원칙’을 몇 가지 소개하면서 역자 서문을 마치겠습니다. 제 나름대로 터득한 효과적인 적용 원칙들입니다.    - 낮은 곳의 과일부터    - 가장 핵심적이고 괴로운 문제부터 (근본 원인 분석)    - 성공에 집중하기 (잘 안 되는 것보다 뭐가 잘 되는지에 집중)    - 잘 안 되면 방법을 바꿔서    - 문자에 집착하지 않고    - 점진적으로 (아기 걸음)  후기지금의 나를 만든 것은 무엇인가에 대해 한 번 생각 해봤다. 보통 사람들은 어디에 속해있는지에 따라 (같을 수도 있지만) 서로 다른 페르소나를 가진다.예를 들면 회사에서의 나, 친구들과 있을 때의 나 그리고 가족들과 있을 때의 나는 유사하지만 분명히 다르다. 프로그램을 ..

기억에 남는 내용- 프로그래머들도 얼마든지 현실 생활에서 온전한 사람이 될 수 있습니다.- XP는 자신을 시험해 보고, 자기 자신이 되어 보고, 또 사실 여러분은 원래부터 괜찮았는데 단지 나쁜 친구들과 어울렸던 것이 문제라는 사실을 깨달을 수 있는 기회입니다.  후기작년 말 선배 개발자도 비슷한 얘기를 하셨었다.개발자는 다른 종족? 족속? 다른 부류의 인간? 이라는 표현을 사용 하셨던 기억이다.건방지다면 건방지게도 그 말씀에 100% 동의하지는 않지만, 그렇다고 100% 부정하지도 못하겠다. 원래부터 괜찮았는데 단지 나쁜 친구들과 어울렸다는 말사실 잘 모르겠다.완독을 하기 전이라 그럴지도 모르지만,나쁜 친구라도 개발자스러운, 개발자 다운, 개발자 성향을 가진 친구가 있으면 나쁘더라도 기꺼이 동행을 할 수..

2023년 5월 8일 ~ 6월 14일, 약 한달간 조영호님의 '오브젝트'를 보고 많은 생각을 했다. 그리고 중간에 약간 붕 뜬 기간이 있었지만, 2023년 9월26일 ~ 2023년 12월 24일 약 세달 동안 '객체지향의 사실과 오해'를 읽었다. 결론은 후회된다. 조금이 아니라 아주 많이 빨리 알았어야 했다. 무엇을 접하더라도 맹신하는 것을 경계한다. 돌 다리도 두들겨 보고 건너지 않을 때가 잦은 나라는 것을 알기 때문에 더욱 맹신하는 일은 없다. 다만 영감을 얻고 통찰을 넓힐 수 있었는데, 지금까지의 10년을 되돌아보게 되었다. 마치 영화 호빗, 스마우그의 폐허 마지막 장면에서 빌보가 '내가 지금 뭘 한거지' 같은 느낌을 받았다. 책을 읽으면서 기억하고 싶은, 기억에 남는 부분들을 정리해 보았다. 요즘..

다망(多忙) 했지만 다 망(亡) 하지는 않았습니다. 상반기는회사 사무실이 다른 곳으로 이사를 했습니다. 신분당선을 타야해서 교통비 부담이 늘었습니다. 2022년 12월 21일을 마지막으로 헌혈을 하였는데, 해가 지나고 1월에 우편으로 유공장을 받았습니다. 당분간 하지 않기로 했습니다. 더 오래 함께 하고 싶었던 동료가 떠나고, 새로운 분들이 합류 하였습니다. 새로움에 대한 기대와 걱정도 있었지만, 그보다 아쉬움이 조금 더 컸습니다. 4월 20일 일산 킨텍스 제1전시관에서 KOREA MAT 2023 행사가 있었고, 개발에 참여중인 서비스가 소개 되었습니다. 4월 24일 개발에 참여중인 서비스가 운영 환경에 드디어 배포가 되었습니다. 안도감 보다는 앞으로 해야 할 것들에 대한 생각을 더 많이 했습니다. 대학..

Pod 는 기본적으로 Scheduler 에 의해 Node 에 할당 되지만 사용자의 의도에 의해 Node 를 지정할 수 있고, 운영자가 특정 노드를 사용하지 못하도록 관리 할 수도 있다.  Node 선택 (NodeName, NodeSelector, NodeAffinity)Pod 를 특정 Node 에 할당 되도록 선택하기 위한 용도로 사용 한다.Node1, Node2, Node3 은 서버가 한국에 있고, Node4, Node5 는 미국에 있다고 가정 한다. 이 상태에서 Pod 를 하나 만들면 k8s Scheduler 는 cpu 자원이 가장 많은 Node 에 이 Pod 를 할당 한다.    [NodeName]NodeName 을 사용하면 Scheduler 와는 상관 없이 바로 해당 Node 의 이름으로 Pod ..

리소스를 균등하게 사용하고 있는 3개의 Pod 를 가진 Node 가 있다. 각 Pod 가 Node 의 리소스를 균등하게 사용하고 있기 때문에 특정 Pod 에 추가 리소스를 할당 할 수 없는 상황에서 Pod1 이 추가 리소스를 필요로 하는 상황이 발생 했다. 그럼 Pod1 이 리소스 부족으로 에러가 발생하고 다운 되어야 할까? 아니면 다른 Pod2 나 Pod3 을 다운시키고 Pod1 에 추가 리소스를 할당 해야 할까? k8s 에는 Application 의 중요도에 따라 이런 상황을 핸들링 할 수 있도록 세 가지 단계로 Quality of Service 를 지원해주고 있다. 지금 상황에서는 BestEffort 가 부여 된 Pod 가 가장 먼저 다운이 되고 리소스가 반환 되고 Pod1 은 필요한 리소스를 제공..

Pod 를 만들면 그 안에 Container 가 생기고 Pod 와 Container 의 상태가 Running 이 되면서 그 안에 있는 Application 도 정상적으로 구동이 되고 있을 것이다. 그리고 Service 에 연결 되는데 이 Service 의 IP 가 외부에 노출되어 다수의 사용자에 의해 서비스가 이용 된다. 현재 하나의 Service 에 두 개의 Pod 가 연결되어 있고 트래픽이 반으로 나뉜다고 하자. 이 때 Node2 서버가 문제가 생겨 다운이 된 경우 그 위의 Pod 도 Failed 가 되면서 사용자의 모든 트래픽이 Pod1 로 들어가게 된다. Pod1 이 트래픽을 견뎌준다면 서비스를 유지하는데 문제는 없다. 다운이 된 Pod2 는 Auto Healing 기능에 의해 다른 Node 에 ..

Pod 에는 Lifecycle 이 존재하고 어떤 Pod 든 만들어지고 사라지는 과정을 거치게 된다. Lifecycle 은 각 단계 별로 하는 행동이 다르다는 특징을 갖는다. Pod 역시 단계별로 주요 행동들이 있고, 앞으로 알아 볼 ReadinessProbe, LivenessProbe, Qos, Policy 등 다양한 기능들이 Pod 의 특정 단계와 관련이 있기 때문에 Lifecycle 에 대해 잘 알아야 한다. Pod 를 생성하고 나면 아래와 같이 Status 에 대한 값을 확인할 수 있다. status: phase: Pending conditions: - type: Initialized status: 'True' lastProbeTime: null lastTrans..