1. AWS는 너무나도 시장 지배적이었고, 구글은 클라우드 시장에서 자신들만의 차별점을 만들어내고 싶어했다.
2. 구글은 자신들만의 정교한 인프라 전문지식을 가지고 있었고, 이를 클라우드에 적용하는 과정을 지속적으로 진행하고 있었다.
3. 컨테이너 기술은 도커 이전에도 존재했었고, 대부분의 개발자들은 몰랐지만 소수의 개발자들은 컨테이너 기술을 사용해왔다.
4. 컨테이너 기술이 도커에 와서야 대중화된 것은 도커가 컨테이너 기술을 매우 쉽게 추상화하는 것에 성공했기 때문이다.
5. '누구나 도커를 사용할 수 있다'라는 점 그리고 소프트웨어 패키징 개념은 도커가 컨테이너 기술의 표준이 될 수 있도록 도와줬다.
6. 도커 이전에도 대규모 트래픽 처리를 위한 좋은 프레임워크는 많았지만, 이들 대부분은 대기업들만이 사용 가능했다.
7. 구글이 도커 이전에 사용한 컨테이너 툴의 이름은 Borg이다.
8. AWS를 따라잡아야한다는 구글의 열망과 2013년 혜성같이 나타난 도커의 등장은 쿠버네티스 개발의 가장 큰 원동력이다.
9. 첫 쿠버네티스 개발은 총 3인이서 시작하였다.(oe Beda, Brendan Burns, and Craig McLuckie)
10. 쿠버네티스 오픈소스를 결정한 이후, 구글 경영진들에게 오픈소스에 대한 정당성을 설명하는데 상당한 시간을 소요했다.
11. 쿠버네티스는 2014년 도커콘에서 발표되었다.
12. 2014년 도커콘에는 쿠버네티스 외에도 다양한 컨테이너 오케스트레이션 툴들이 발표되었다. 그 중 하나로 페이스북에서 발표한 typperware라는 것이 있다.
13. 도커도 훌륭하지만, 엔터프라이즈 레벨에서 쿠버네티스가 가진 강점은 압도적이었고, 이 때문에 도커는 2013년 발표당시보다 많은 위상을 잃었다.
14. 처음부터 쿠버네티스가 오케스트레이션 툴의 표준처럼 작동한 것은 아니었고, 오히려 초반에는 다른 프로젝트들에 밀리는 경향이 있었다.
15. mesos 혹은 docker swarm은 각자 다른 장점을 가지고 있었고, 넷플릭스와 같은 대형 IT회사는 초반에 mesos를 선택했다.
16. 2016년이 될 때까지 쿠버네티스 코어 개발자들은 아주 고강도의 개발을 진행했고, 그 때문에 번아웃 직전의 상황에 몰렸었다. 그렇게 개발한 이유에는 코어 개발자들이 각자 다른 매니저에게 보고를 해야되는 상황이 있었다.
17. 2016년이 되어서, 쿠버네티스는 하나의 팀으로 구성되었고 새로운 매니저는 지속가능한 개발을 위해 사람들을 끌여들이고, 각자에게 책임감을 부여하는 방식으로 지속적인 개발을 꾀했다.
18. 쿠버네티스는 초기에 '구글의 라이센스(Apache License 2.0)'였고, 이 때문에 상당히 많은 개발자들은 오픈소스 개발 참여를 꺼렸다. 특히, Apache License 개발 참여에 반대하는 기업문화를 가진 개발자들은 참여가 어려웠다.
19. 해당 문제점의 해결책으로 쿠버네티스는 구글 산하가 아닌 CNCF(Cloud Native Computing Foundation)으로 소속을 옮겼고, 더 많은 개발자들이 개발에 참여할 수 있도록 독려했다.
20. 2016년 발표된 포켓몬 고는 쿠버네티스 위에서 작동하도록 설계되었고, 포켓몬 고의 폭발적인 성공과 그를 뒷받침하는 쿠버네티스의 성능은 쿠버네티스가 성공적인 툴이라는 것을 증명해냈다.
21. 당시 포켓몬 고가 만들어내는 트래픽은 당초 회사가 예측한 것의 50배 이상이었다. 쿠버네티스는 50배가 넘는 트래픽을 받아내었다.
22. 2017년, 아마존이 AWS에 쿠버네티스를 사용한 EKS 툴을 발표함으로써 컨테이너 오케스트레이션 툴 간의 경쟁은 종료되었다.
23. 쿠버네티스가 승리할 수 있었던 가장 큰 원인은 수많은 개발자 군단에 있다. 다른 툴들에 비해서도 압도적인 커밋양을 바탕으로 빠르고 안정적인 개발을 해낼 수 있었다.
24. 쿠버네티스가 성공할 수 있었던 중요한 키 포인트는 개발자 커뮤니티를 만들어냈다는 것에 있다. 개발자 커뮤니티와 생태계를 만들어냄으로써 코드 기여뿐만 아니라 수많은 피드백들을 받을 수 있었다.
블로그 글 : https://songseungwoon.com/56
더 재미있는 글 많아용 많관부~