케이스) 플랫폼 업그레이드가 자주 발생하는 클라우드 향 아키텍처

케이스)

일반적인 웹애플리케이션인데 K8S에서 서비스 한다고 가정하자.

그런데 이 K8S가 자주 업그레이드를 해야 한다고 하면?

 

훅 건너뛰어 지금은 22년 9월

본 포스팅을 올릴 때만해도 운영서비스에서 업그레이드를 한번도 안해본 때라 고민이 많았던 상태였고

지금은 이미 업그레이드를 몇 번 해본 상태라 조금 다른 시각으로 K8S 업그레이드에 대해 언급할 수 있을 것 같다.

 

- 업그레이드 자체

  - 클러스터 롤링 업그레이드라 다수의 Replica로 구성된 WEB/WAS는 사실상 영향이 없었다.

 

- 문제점

  - Pod -> Legacy 연동, 특히 방화벽 문제가 어렵다.

     - OpenShift의 경우, Pod -> Legacy 네트워크 연계시 EgressIP를 통해 Source NAT를 한다. 운영기의 경우 EgressIP 를 Primary/Seconday로 2중화를 하고 방화벽도 두 IP모두 허용한다. OpenShift에서 EgressIP의 실체는 노드에 할당된 VIP이며, 업그레이드 시점, 노드가 롤링 Restart하는 경우 해당 노드에 할당된 EgressIP는 동작하지 않는다. 즉 두 개의 노드에 EgressIP가 흩어져 할당되어야 하며, Primary EgressIP가 할당된 노드가 restart하는 시점에 약간의 network connection failure가 발생한다. 경험상 거의 0.1초 정도 Primary -> Secondary로 넘어가는 순단이 발생한다.

     - OpenShift 의 EgressIP는 4.8 부터 A/S -> A/A로 변경되었다. 경험적으로 4.7->4.8로 업그레이드 시 운영팀에서 혹시나 Secondary EgressIP 방화벽이 허용 안된 곳이 있는지 체크하느라 공수가 많이 들었다.

     - Pure K8S 의 경우, EgressIP 가 없다(이는 순전히 OpenShift의 Extention API이다). 따라서 K8S를 쓴다면 아키텍처상 별도의 Egress Router를 Pod로 구성해야 하며, 이를 별도 Egress 전용 노드로 빼는 것이 합리적인 아키텍처라 생각한다.

 

  - WEB/WAS가 아닌 응용

     - 예를 들어 Kafka sink app 같은 경우(consumer) pod 재기동 시 ConsumerGroup에 다시 들어가지 못하는 경우가 발생해 업그레이드 시 주의가 필요하다.

 

   - 버전에 따라 그때그때 고려해야 하는 상황이 발생한다.

     - 예를 들어 Golang 버전이 바뀌는 상황이 있었는데, 이때부터 SSL 인증서가 SANs 방식으로 만들어져야 통신이 가능한 경우가 있었다. 물론 Self-Signed의 경우로 Self-Signed 인증서를 아무 블로그에서나 보고 만들면, SANs 가 아닌 경우가 많았다.

 

대충 이정도?