k8s 아키텍처는 너무 다르기 때문에 이것을 조직 외부의 사람들이 이해할 수 있는 맥락에 넣는 것은 어렵다고 생각합니다.
서비스에 블루/그린 배포를 사용하고 helm을 사용하여 적용할 k8s 개체를 생성합니다.
따라서 새 버전을 정상적으로 배포하면 서비스, 배포 및 hpa를 포함한 k8s 대상 파일이 생성됩니다. 이는 새로운 대체 문자를 가리키는 "다채로운" 개체입니다.
hpa 및 배포 개체를 적용한 다음 새 배포 개체를 푸시하고 서비스의 "역할" 레이블을 새 색상으로 설정한 다음 서비스의 "역할" 레이블을 새 색상으로 설정합니다. 그런 다음 이전 배포를 Pod 0개로 축소합니다. 일반 배포에서는 마술처럼 HPA가 작업을 수행하고 HPA에 지정된 최소 포드 수로 확장됩니다. 이 모든 것이 잘 작동합니다.
위에 설명된 단계는 실제로 두 개의 별도 Jenkins 빌드에서 수행됩니다. 첫 번째는 "DEPLOY" 빌드라고 하고 두 번째는 "SWITCH_LIVE"라고 합니다. "DEPLOY" 빌드는 k8s 개체를 생성하고 푸시만 하며 활성 색상은 변경하지 않습니다. "SWITCH_LIVE"가 바로 그 역할을 합니다.
문제는 우리가 SWITCH_LIVE 작업의 Jenkins "재생"을 수행하여 간단히 "롤백"을 수행하려고 할 때 발생합니다. 우리의 맥락에서 이는 단순히 현재 활성 색상 이전의 활성 색상인 대체 색상으로 변경한다는 의미입니다. 내 이론은 "역할" 레이블을 변경하고 선택기를 변경하면 현재 활성 색상에 대한 HPA가 시작되어 최소 수의 포드를 생성한다는 것입니다. 내가 보기에는 배포에서 레이블과 선택기를 변경한 후에 아무 일도 일어나지 않는다는 것입니다.
"DEPLOY" 작업과 "SWITCH_LIVE" 작업을 모두 재생하면 기본적으로 예상대로 작동하지만 이 전략의 문제는 DEPLOY 작업이 모든 k8s 개체 및 애플리케이션 구성 그래프를 재생성하는 것과 같은 다른 작업을 수행한다는 것입니다. 내가 원하는만큼 적지 않습니다.
그런 다음 SWITCH_LIVE 작업을 재생하고 배포 개체를 새 색상으로 수동으로 다시 적용하면 아무것도 변경되지 않았음에도 갑자기 작동이 시작되고 새 색상으로 포드가 생성되기 시작한다는 사실을 발견했습니다.
이것이 작동하는 동안 SWITCH_LIVE 작업이 이 작업을 자동으로 수행할 수 있는 방법이 필요합니다. 앞서 언급했듯이 SWITCH_LIVE 작업에서는 현재 서비스 개체의 역할과 선택기만 업데이트하고 새 배포 개체에는 아무 작업도 수행하지 않습니다. 배포 또는 HPA가 필요한 작업을 수행하도록 "미끄러지는" 정상적인 작업에서 무해한 것이 있습니까?