Kubernetes 및 고가용성 환경에서 Mattermost 업그레이드

요약

이 가이드는 Kubernetes와 Mattermost Operator를 통해 관리되는 Mattermost 배포를 업그레이드하기 위한 탄력적이고 포괄적인 전략을 제공합니다. Mattermost는 Helm 차트와 Mattermost Operator 를 통해 배포 및 관리되는 컨테이너 오케스트레이션을 위해 Kubernetes 를 사용합니다.

이 가이드는 Kubernetes와 Mattermost Operator를 통해 관리되는 Mattermost 배포를 업그레이드하기 위한 탄력적이고 포괄적인 전략을 제공합니다. 여기에는 고가용성(HA)과 선택적 Active/Active 페일오버 구성이 포함됩니다. 제로 다운타임을 보장하고, 서비스 위험을 최소화하며, 강력한 폴백 메커니즘을 제공하기 위한 모범 사례를 설명합니다.

아키텍처 개요#

Kubernetes 기반 배포#

Mattermost는 Helm 차트와 Mattermost Operator 를 통해 배포 및 관리되는 컨테이너 오케스트레이션을 위해 Kubernetes 를 사용합니다. 이 모델은 확장 가능하고 고가용성이 있으며 자동으로 관리되는 애플리케이션 수명 주기를 가능하게 합니다.

Mattermost Operator는 업그레이드 프로세스를 자동으로 처리하여 파드가 점진적으로 업데이트되고 업그레이드 전체에 걸쳐 트래픽이 올바르게 라우팅되도록 합니다. 업그레이드 중 오류가 발생하면 Operator는 변경 사항을 적용하지 않아 라이브 환경에 영향을 주지 않고 문제를 조사하고 해결하거나 수동으로 롤백할 수 있습니다. 롤백 세부사항은 Mattermost 서버 다운그레이드 문서를 참조하세요.

상태 모니터링은 정상 파드만 교체되고 상태 점검을 통과한 후에만 새 파드가 온라인 상태가 되도록 합니다. 새 파드는 업데이트된 버전으로 배포되고 이전 파드는 정상적으로 종료됩니다.

고가용성#

고가용성(HA) 클러스터 기반 배포 에서 Mattermost는 클러스터에서 여러 애플리케이션 서버를 실행합니다. 이 구성은 한 서버가 실패하더라도 다운타임 없이 다른 서버가 요청을 계속 처리할 수 있도록 합니다. 사용자 트래픽 로드 밸런싱은 NGINX Ingress 또는 HAProxy와 같은 서비스로 관리됩니다. PostgreSQL 과 파일 스토리지 는 이중화 및 페일오버를 위해 복제와 함께 배포됩니다.

Active/Active 배포#

Active/Active 구성은 선택 사항이며 지리적으로 분산된 지역 또는 가용 영역에서 동시에 실행되는 두 개 이상의 Mattermost 클러스터로 구성됩니다. 각 클러스터는 데이터베이스 및 파일 스토리지와 같은 공유 백엔드 컴포넌트와 동기화를 유지하면서 독립적으로 라이브 사용자 트래픽을 처리하고 요청을 처리할 수 있습니다.

엔터프라이즈 고객을 위한 주요 이점은 다음과 같습니다:

복원력 및 가동 시간: 유지보수나 중단으로 인해 사이트가 사용 불가능해지면 다른 사이트가 최소한의 중단으로 사용자를 계속 서비스할 수 있습니다.
지리적 분산: 사용자는 낮은 지연 시간과 더 빠른 응답 시간을 위해 가장 가까운 클러스터에 연결합니다.
부하 분산: 성능 및 시스템 확장성을 향상시키기 위해 클러스터 간에 워크로드를 균형 있게 분배할 수 있습니다.

이러한 배포는 데이터 일관성, 업그레이드 안전성 및 원활한 트래픽 페일오버를 보장하기 위해 신중한 구성 관리 및 조정이 필요합니다. 이러한 클러스터는 구성/데이터 일관성을 유지해야 하며 조정된 업그레이드가 필요합니다. 권장 사항은 Active/Active 업그레이드 고려사항 섹션을 참조하세요.

1단계: 준비#

이 단계는 환경이 정상적이고 백업되어 있으며 업그레이드 준비가 되어 있는지 확인합니다. 중단을 방지하고 롤백 준비 상태를 보장하기 위해 각 단계를 주의 깊게 따르세요.

Important

데이터 백업: 업그레이드를 시작하기 전에 항상 데이터베이스와 파일 스토리지를 백업하세요. 업그레이드 프로세스 중 문제가 발생한 경우 이전 상태로 복원할 수 있습니다.
안전한 업그레이드: Mattermost Operator는 롤아웃 전에 업그레이드 유효성 검사를 수행합니다. 검사가 실패하면 업그레이드가 차단되고 변경 사항이 적용되지 않습니다. 검사가 통과되면 Operator는 가동 시간을 유지하기 위해 파드를 점진적으로 업그레이드합니다.

업그레이드 전 체크리스트#

클러스터 상태: 모든 노드가 준비 상태이고 모든 파드가 오류 없이 실행 중인지 확인하세요. 이 단계는 업그레이드 프로세스 중 문제를 방지하는 데 중요합니다. 클러스터 상태를 확인하려면 다음 명령어를 사용하세요:

kubectl get nodes
kubectl get pods --all-namespaces

Helm 설정: Helm이 올바르게 설치되고 Kubernetes 클러스터에서 구성되었는지 확인하세요. 최신 버전의 Mattermost Operator Helm 차트가 있는지 확인하세요. Helm 설정을 확인하려면 다음 명령어를 사용하세요:

helm repo update
helm upgrade mattermost-operator mattermost/mattermost-operator -n <OPERATOR_NAMESPACE_HERE> -f <OPTIONAL_CUSTOM_VALUES_HERE>

Mattermost Operator 버전 확인: 이미지 버전이 Helm 저장소의 최신 지원 릴리즈와 일치하는지 확인하세요. Mattermost Operator의 현재 이미지 버전을 확인하려면 다음 명령어를 사용하세요:

kubectl get deployment mattermost-operator -n mattermost -o=jsonpath='{.spec.template.spec.containers[0].image}'

사용 가능한 리소스 확인: Kubernetes 클러스터가 업그레이드 프로세스를 처리하기에 충분한 CPU 및 메모리 리소스를 보유하고 있는지 확인하세요. 리소스 가용성을 확인하려면 다음 명령어를 사용하세요:

kubectl top nodes
kubectl describe node | grep Allocatable

데이터베이스 및 파일 스토리지를 백업하세요.

pg_dump 또는 볼륨 스냅샷을 사용하여 안전한 외부 위치(예: S3 또는 NFS)에 전체 백업을 생성하세요. 백업을 복원할 수 있는지 확인하세요. 자세한 내용은 백업 및 재해 복구 문서를 참조하세요.

구성 일관성 확인: values.yaml, 시크릿 및 기타 구성 파일이 버전 관리되고 모든 클러스터에서 일관되어 있는지 확인하세요(Active/Active 배포 에 필요). GitOps 또는 구성 관리 시스템과 같은 도구를 사용하여 모든 클러스터에 동일한 구성이 있는지 확인하세요.
초기 잘못된 구성을 조기에 발견하기 위해 프로덕션을 미러링하는 스테이징 환경에서 업그레이드를 테스트하여 드라이 런을 수행하는 것을 강력히 권장합니다.

2단계: 업그레이드 수행#

이 단계는 Mattermost Operator와 Mattermost 서버를 새 버전으로 업데이트하는 것을 포함합니다. Operator는 파드가 점진적으로 업데이트되고 업그레이드 전체에 걸쳐 트래픽이 올바르게 라우팅되도록 업그레이드 프로세스를 관리합니다.

별도의 Mattermost 사용자 정의 리소스를 갖는 것을 권장합니다. 자세한 내용은 Kubernetes에 Mattermost 배포 문서를 참조하세요.

별도의 리소스에서 <new-version-tag> 를 업그레이드할 특정 버전으로 교체하여 mattermost-installation.yaml 파일의 version 필드를 업데이트하세요:

apiVersion: installation.mattermost.com/v1beta1
  kind: Mattermost
  metadata:
    name: <INSTALLATION_NAME_HERE>
  spec:
    version: <new-version-tag>  # Update this field

또는 Helm ``values.yaml`` 을 직접 사용하는 경우 원하는 Mattermost 버전으로 업데이트하세요:

image:
repository: mattermost/mattermost-enterprise-edition
tag: <new-version-tag></code></pre>
<li class="numbered">업데이트된 구성을 적용하세요:


Mattermost 사용자 정의 리소스 배포의 경우:

  
kubectl apply -f mattermost-installation.yaml

  Helm 값 배포의 경우:

  helm upgrade mattermost mattermost/mattermost-operator -f values.yaml
3. 다음 명령어로 업그레이드 진행 상황과 로그를 추적하여 롤아웃을 모니터링하세요:
kubectl get pods -n mattermost
kubectl logs -f <pod-name> -n mattermost</code></pre>
<p>새 파드는 업데이트된 버전으로 시작됩니다. 상태 점검이 통과되면 이전 파드가 정상적으로 종료되고 롤링 업그레이드 동작으로 인해 트래픽이 계속 유지됩니다. NGINX, HAProxy 또는 Ingress 구성은 업그레이드 프로세스 중에 트래픽을 원활하게 계속 라우팅합니다.



3단계: Active/Active 업그레이드 고려사항#

배포에 멀티 클러스터 또는 멀티 리전 배포를 포함한 Active/Active 구성이 포함된 경우, 데이터 일관성과 서비스 가용성을 유지하기 위해 모든 클러스터가 조정된 방식으로 업그레이드되도록 해야 합니다.

조정된 사이트 업그레이드를 위해 다음 단계를 권장합니다:

글로벌 로드 밸런서 또는 DNS를 사용하여 업그레이드 중인 사이트에서 트래픽을 라우팅하세요.
한 번에 한 사이트씩 업그레이드하면서 다른 사이트로 트래픽을 유도하세요. 이를 통해 다운타임을 최소화하고 업그레이드 프로세스의 유효성을 검증할 수 있습니다.
다음 사이트로 진행하기 전에 데이터베이스 및 스토리지에 대한 복제 상태를 확인하세요.
업그레이드된 사이트로 트래픽을 재개하기 전에 성능과 로그를 모니터링하세요.

업그레이드 중 스플릿 브레인 시나리오를 방지하고 데이터 일관성을 보장하려면:

글로벌 로드 밸런서 또는 DNS를 사용하여 트래픽을 활성 사이트로만 유도하세요.
업그레이드가 완료되고 유효성이 검증될 때까지 업그레이드 중인 사이트에서 쓰기를 비활성화하세요.
한 번에 하나의 사이트만 데이터를 활발히 쓰고 있는지 확인하세요.
복제 지연, 파일 동기화 문제 또는 데이터 발산의 징후에 대한 로그를 모니터링하세요.
각 사이트 업그레이드 전후에 데이터 복제 채널의 상태를 확인하세요.

4단계: 유효성 검증#

업그레이드 후:

다음 명령어를 사용하여 모든 파드가 정상적이고 예상 버전을 실행하는지 확인하세요:

  
kubectl get pods -n mattermost -o=jsonpath='{.items[*].spec.containers[*].image}'
제품 스모크 테스트를 수행하세요:

Mattermost 웹 인터페이스에 로그인하고 팀과 채널을 탐색하세요.
메시지 게시 및 파일 업로드와 같은 핵심 기능을 테스트하세요.
모든 통합, 웹훅, 플러그인이 예상대로 작동하는지 확인하세요.
로그에서 오류 메시지를 확인하세요.

모니터링 도구를 사용하여 애플리케이션 상태 및 성능을 확인하세요. 성능 지표 수집 및 검토에 대한 자세한 내용은 Prometheus 및 Grafana를 사용한 성능 모니터링 문서 또는 메트릭 플러그인 문서를 참조하세요.


롤백 전략#

업그레이드 문제가 발생한 경우, 사용자 정의 리소스를 수정하고 Mattermost 버전을 원래 값으로 되돌려 롤백을 수행해야 합니다.

Mattermost 사용자 정의 리소스 배포의 경우, mattermost-installation.yaml 파일의 version 필드를 이전 버전으로 업데이트하세요:


apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
metadata:
  name: <INSTALLATION_NAME_HERE>
spec:
  version: <previous-version-tag>  # Set back to previous version
그런 다음 롤백을 적용하세요:


kubectl apply -f mattermost-installation.yaml
또는 Helm 값 배포의 경우, Helm의 롤백 명령어를 사용하세요:


helm rollback mattermost <revision_number>
필요한 경우 PostgreSQL 데이터베이스와 파일 스토어 백업을 복원하세요. 자세한 가이드는 백업 및 재해 복구 문서를 참조하세요.

자주 묻는 질문#

업그레이드 성공을 어떻게 확인할 수 있나요?#

성공적인 업그레이드는 다음으로 표시됩니다:

예상 이미지 버전을 실행하는 모든 파드
파드 로그에 오류 없음
기능적 스모크 테스트 통과(로그인, 메시지, 파일 업로드 등)
모니터링 대시보드에 이상 없음

업그레이드 후 어떤 사항을 모니터링해야 하나요?#

업그레이드 후 다음 주요 지표를 모니터링하는 것을 권장합니다:

파드 상태 및 재시작
오류 또는 경고에 대한 애플리케이션 로그
데이터베이스 복제 상태(HA 또는 Active/Active의 경우)
Prometheus/Grafana를 통한 성능 지표(지연 시간, 오류율)

프로덕션에 영향을 주지 않고 업그레이드를 테스트하려면 어떻게 해야 하나요?#

프로덕션을 미러링하는 별도의 스테이징 환경을 배포하고, 라이브 프로덕션 클러스터를 업그레이드하기 전에 전체 엔드투엔드 업그레이드 시뮬레이션을 실행하는 것을 강력히 권장합니다.

Operator와 Mattermost 서버를 동시에 업그레이드할 수 있나요?#

먼저 Operator를 업그레이드하세요. Mattermost 서버 버전을 업그레이드하기 전에 안정적인지 확인하세요.

데이터베이스를 별도로 업그레이드해야 하나요?#

Mattermost는 기본적으로 데이터베이스 스키마를 업그레이드하지 않습니다. 최신 Mattermost 버전에서 요구하는 경우 데이터베이스 스키마 업데이트를 수동으로 적용해야 합니다. 마이그레이션 단계에 대한 Mattermost 서버 변경 로그 를 검토하세요.

업그레이드 후 파드가 준비 상태가 되지 않으면 어떻게 해야 하나요?#

kubectl 을 사용하여 Operator 로그와 파드 이벤트를 확인하여 문제를 식별하고 해결하세요. 리소스 제약, 구성 오류 또는 네트워크 연결 문제와 같은 일반적인 문제를 찾아보세요.

Mattermost Operator와 애플리케이션 서버 간의 버전 호환성에 대해 알아야 할 것은 무엇인가요?#

오래된 Operator 버전을 실행하면 새로운 Mattermost 기능이나 업그레이드 흐름을 지원하지 않을 수 있습니다. Operator와 Mattermost 서버 간의 버전 호환성에 대한 Helm 차트 릴리즈 노트 를 항상 확인하세요.

GitOps 또는 CI/CD를 사용하여 이 업그레이드 프로세스를 자동화할 수 있나요?#

네. ArgoCD 또는 FluxCD와 같은 도구를 사용하여 버전 관리된 values.yaml 파일에서 Helm 변경 사항을 적용하여 업그레이드를 관리할 수 있습니다. 프로덕션으로 프로모션하기 전에 변경 사항이 스테이징에서 피어 검토되고 유효성이 검증되는지 확인하세요.


Docs/Mattermost/Upgrade/Upgrade-mattermost-kubernetes-ha
Kubernetes 및 고가용성 환경에서 Mattermost 업그레이드
원문 보기
번역일: 2026-04-22
요약
이 가이드는 Kubernetes와 Mattermost Operator를 통해 관리되는 Mattermost 배포를 업그레이드하기 위한 탄력적이고 포괄적인 전략을 제공합니다. Mattermost는 Helm 차트와 Mattermost Operator 를 통해 배포 및 관리되는 컨테이너 오케스트레이션을 위해 Kubernetes 를 사용합니다.



이 가이드는 Kubernetes와 Mattermost Operator를 통해 관리되는 Mattermost 배포를 업그레이드하기 위한 탄력적이고 포괄적인 전략을 제공합니다. 여기에는 고가용성(HA)과 선택적 Active/Active 페일오버 구성이 포함됩니다. 제로 다운타임을 보장하고, 서비스 위험을 최소화하며, 강력한 폴백 메커니즘을 제공하기 위한 모범 사례를 설명합니다.

아키텍처 개요#

Kubernetes 기반 배포#

Mattermost는 Helm 차트와 Mattermost Operator 를 통해 배포 및 관리되는 컨테이너 오케스트레이션을 위해 Kubernetes 를 사용합니다. 이 모델은 확장 가능하고 고가용성이 있으며 자동으로 관리되는 애플리케이션 수명 주기를 가능하게 합니다.

Mattermost Operator는 업그레이드 프로세스를 자동으로 처리하여 파드가 점진적으로 업데이트되고 업그레이드 전체에 걸쳐 트래픽이 올바르게 라우팅되도록 합니다. 업그레이드 중 오류가 발생하면 Operator는 변경 사항을 적용하지 않아 라이브 환경에 영향을 주지 않고 문제를 조사하고 해결하거나 수동으로 롤백할 수 있습니다. 롤백 세부사항은 Mattermost 서버 다운그레이드 문서를 참조하세요.

상태 모니터링은 정상 파드만 교체되고 상태 점검을 통과한 후에만 새 파드가 온라인 상태가 되도록 합니다. 새 파드는 업데이트된 버전으로 배포되고 이전 파드는 정상적으로 종료됩니다.

고가용성#

고가용성(HA) 클러스터 기반 배포 에서 Mattermost는 클러스터에서 여러 애플리케이션 서버를 실행합니다. 이 구성은 한 서버가 실패하더라도 다운타임 없이 다른 서버가 요청을 계속 처리할 수 있도록 합니다. 사용자 트래픽 로드 밸런싱은 NGINX Ingress 또는 HAProxy와 같은 서비스로 관리됩니다. PostgreSQL 과 파일 스토리지 는 이중화 및 페일오버를 위해 복제와 함께 배포됩니다.

Active/Active 배포#

Active/Active 구성은 선택 사항이며 지리적으로 분산된 지역 또는 가용 영역에서 동시에 실행되는 두 개 이상의 Mattermost 클러스터로 구성됩니다. 각 클러스터는 데이터베이스 및 파일 스토리지와 같은 공유 백엔드 컴포넌트와 동기화를 유지하면서 독립적으로 라이브 사용자 트래픽을 처리하고 요청을 처리할 수 있습니다.

엔터프라이즈 고객을 위한 주요 이점은 다음과 같습니다:

복원력 및 가동 시간: 유지보수나 중단으로 인해 사이트가 사용 불가능해지면 다른 사이트가 최소한의 중단으로 사용자를 계속 서비스할 수 있습니다.
지리적 분산: 사용자는 낮은 지연 시간과 더 빠른 응답 시간을 위해 가장 가까운 클러스터에 연결합니다.
부하 분산: 성능 및 시스템 확장성을 향상시키기 위해 클러스터 간에 워크로드를 균형 있게 분배할 수 있습니다.

이러한 배포는 데이터 일관성, 업그레이드 안전성 및 원활한 트래픽 페일오버를 보장하기 위해 신중한 구성 관리 및 조정이 필요합니다. 이러한 클러스터는 구성/데이터 일관성을 유지해야 하며 조정된 업그레이드가 필요합니다. 권장 사항은 Active/Active 업그레이드 고려사항 섹션을 참조하세요.

1단계: 준비#

이 단계는 환경이 정상적이고 백업되어 있으며 업그레이드 준비가 되어 있는지 확인합니다. 중단을 방지하고 롤백 준비 상태를 보장하기 위해 각 단계를 주의 깊게 따르세요.

Important
데이터 백업: 업그레이드를 시작하기 전에 항상 데이터베이스와 파일 스토리지를 백업하세요. 업그레이드 프로세스 중 문제가 발생한 경우 이전 상태로 복원할 수 있습니다.
안전한 업그레이드: Mattermost Operator는 롤아웃 전에 업그레이드 유효성 검사를 수행합니다. 검사가 실패하면 업그레이드가 차단되고 변경 사항이 적용되지 않습니다. 검사가 통과되면 Operator는 가동 시간을 유지하기 위해 파드를 점진적으로 업그레이드합니다.
업그레이드 전 체크리스트#

클러스터 상태: 모든 노드가 준비 상태이고 모든 파드가 오류 없이 실행 중인지 확인하세요. 이 단계는 업그레이드 프로세스 중 문제를 방지하는 데 중요합니다. 클러스터 상태를 확인하려면 다음 명령어를 사용하세요:

  
kubectl get nodes
kubectl get pods --all-namespaces
Helm 설정: Helm이 올바르게 설치되고 Kubernetes 클러스터에서 구성되었는지 확인하세요. 최신 버전의 Mattermost Operator Helm 차트가 있는지 확인하세요. Helm 설정을 확인하려면 다음 명령어를 사용하세요:

  
helm repo update
helm upgrade mattermost-operator mattermost/mattermost-operator -n <OPERATOR_NAMESPACE_HERE> -f <OPTIONAL_CUSTOM_VALUES_HERE>
Mattermost Operator 버전 확인: 이미지 버전이 Helm 저장소의 최신 지원 릴리즈와 일치하는지 확인하세요. Mattermost Operator의 현재 이미지 버전을 확인하려면 다음 명령어를 사용하세요:

  
kubectl get deployment mattermost-operator -n mattermost -o=jsonpath='{.spec.template.spec.containers[0].image}'
사용 가능한 리소스 확인: Kubernetes 클러스터가 업그레이드 프로세스를 처리하기에 충분한 CPU 및 메모리 리소스를 보유하고 있는지 확인하세요. 리소스 가용성을 확인하려면 다음 명령어를 사용하세요:

  
kubectl top nodes
kubectl describe node | grep Allocatable
데이터베이스 및 파일 스토리지를 백업하세요.

pg_dump 또는 볼륨 스냅샷을 사용하여 안전한 외부 위치(예: S3 또는 NFS)에 전체 백업을 생성하세요. 백업을 복원할 수 있는지 확인하세요. 자세한 내용은 백업 및 재해 복구 문서를 참조하세요.

구성 일관성 확인: values.yaml, 시크릿 및 기타 구성 파일이 버전 관리되고 모든 클러스터에서 일관되어 있는지 확인하세요(Active/Active 배포 에 필요). GitOps 또는 구성 관리 시스템과 같은 도구를 사용하여 모든 클러스터에 동일한 구성이 있는지 확인하세요.

초기 잘못된 구성을 조기에 발견하기 위해 프로덕션을 미러링하는 스테이징 환경에서 업그레이드를 테스트하여 드라이 런을 수행하는 것을 강력히 권장합니다.


2단계: 업그레이드 수행#

이 단계는 Mattermost Operator와 Mattermost 서버를 새 버전으로 업데이트하는 것을 포함합니다. Operator는 파드가 점진적으로 업데이트되고 업그레이드 전체에 걸쳐 트래픽이 올바르게 라우팅되도록 업그레이드 프로세스를 관리합니다.

별도의 Mattermost 사용자 정의 리소스를 갖는 것을 권장합니다. 자세한 내용은 Kubernetes에 Mattermost 배포 문서를 참조하세요.

별도의 리소스에서 <new-version-tag> 를 업그레이드할 특정 버전으로 교체하여 mattermost-installation.yaml 파일의 version 필드를 업데이트하세요:

  
apiVersion: installation.mattermost.com/v1beta1
  kind: Mattermost
  metadata:
    name: <INSTALLATION_NAME_HERE>
  spec:
    version: <new-version-tag>  # Update this field

또는 Helm ``values.yaml`` 을 직접 사용하는 경우 원하는 Mattermost 버전으로 업데이트하세요:

image:
repository: mattermost/mattermost-enterprise-edition
tag: <new-version-tag></code></pre>
<li class="numbered">업데이트된 구성을 적용하세요:

  

Mattermost 사용자 정의 리소스 배포의 경우:

  
kubectl apply -f mattermost-installation.yaml

  Helm 값 배포의 경우:

  helm upgrade mattermost mattermost/mattermost-operator -f values.yaml
3. 다음 명령어로 업그레이드 진행 상황과 로그를 추적하여 롤아웃을 모니터링하세요:
kubectl get pods -n mattermost
kubectl logs -f <pod-name> -n mattermost</code></pre>
<p>새 파드는 업데이트된 버전으로 시작됩니다. 상태 점검이 통과되면 이전 파드가 정상적으로 종료되고 롤링 업그레이드 동작으로 인해 트래픽이 계속 유지됩니다. NGINX, HAProxy 또는 Ingress 구성은 업그레이드 프로세스 중에 트래픽을 원활하게 계속 라우팅합니다.



3단계: Active/Active 업그레이드 고려사항#

배포에 멀티 클러스터 또는 멀티 리전 배포를 포함한 Active/Active 구성이 포함된 경우, 데이터 일관성과 서비스 가용성을 유지하기 위해 모든 클러스터가 조정된 방식으로 업그레이드되도록 해야 합니다.

조정된 사이트 업그레이드를 위해 다음 단계를 권장합니다:

글로벌 로드 밸런서 또는 DNS를 사용하여 업그레이드 중인 사이트에서 트래픽을 라우팅하세요.
한 번에 한 사이트씩 업그레이드하면서 다른 사이트로 트래픽을 유도하세요. 이를 통해 다운타임을 최소화하고 업그레이드 프로세스의 유효성을 검증할 수 있습니다.
다음 사이트로 진행하기 전에 데이터베이스 및 스토리지에 대한 복제 상태를 확인하세요.
업그레이드된 사이트로 트래픽을 재개하기 전에 성능과 로그를 모니터링하세요.

업그레이드 중 스플릿 브레인 시나리오를 방지하고 데이터 일관성을 보장하려면:

글로벌 로드 밸런서 또는 DNS를 사용하여 트래픽을 활성 사이트로만 유도하세요.
업그레이드가 완료되고 유효성이 검증될 때까지 업그레이드 중인 사이트에서 쓰기를 비활성화하세요.
한 번에 하나의 사이트만 데이터를 활발히 쓰고 있는지 확인하세요.
복제 지연, 파일 동기화 문제 또는 데이터 발산의 징후에 대한 로그를 모니터링하세요.
각 사이트 업그레이드 전후에 데이터 복제 채널의 상태를 확인하세요.

4단계: 유효성 검증#

업그레이드 후:

다음 명령어를 사용하여 모든 파드가 정상적이고 예상 버전을 실행하는지 확인하세요:

  
kubectl get pods -n mattermost -o=jsonpath='{.items[*].spec.containers[*].image}'
제품 스모크 테스트를 수행하세요:

Mattermost 웹 인터페이스에 로그인하고 팀과 채널을 탐색하세요.
메시지 게시 및 파일 업로드와 같은 핵심 기능을 테스트하세요.
모든 통합, 웹훅, 플러그인이 예상대로 작동하는지 확인하세요.
로그에서 오류 메시지를 확인하세요.

모니터링 도구를 사용하여 애플리케이션 상태 및 성능을 확인하세요. 성능 지표 수집 및 검토에 대한 자세한 내용은 Prometheus 및 Grafana를 사용한 성능 모니터링 문서 또는 메트릭 플러그인 문서를 참조하세요.


롤백 전략#

업그레이드 문제가 발생한 경우, 사용자 정의 리소스를 수정하고 Mattermost 버전을 원래 값으로 되돌려 롤백을 수행해야 합니다.

Mattermost 사용자 정의 리소스 배포의 경우, mattermost-installation.yaml 파일의 version 필드를 이전 버전으로 업데이트하세요:


apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
metadata:
  name: <INSTALLATION_NAME_HERE>
spec:
  version: <previous-version-tag>  # Set back to previous version
그런 다음 롤백을 적용하세요:


kubectl apply -f mattermost-installation.yaml
또는 Helm 값 배포의 경우, Helm의 롤백 명령어를 사용하세요:


helm rollback mattermost <revision_number>
필요한 경우 PostgreSQL 데이터베이스와 파일 스토어 백업을 복원하세요. 자세한 가이드는 백업 및 재해 복구 문서를 참조하세요.

자주 묻는 질문#

업그레이드 성공을 어떻게 확인할 수 있나요?#

성공적인 업그레이드는 다음으로 표시됩니다:

예상 이미지 버전을 실행하는 모든 파드
파드 로그에 오류 없음
기능적 스모크 테스트 통과(로그인, 메시지, 파일 업로드 등)
모니터링 대시보드에 이상 없음

업그레이드 후 어떤 사항을 모니터링해야 하나요?#

업그레이드 후 다음 주요 지표를 모니터링하는 것을 권장합니다:

파드 상태 및 재시작
오류 또는 경고에 대한 애플리케이션 로그
데이터베이스 복제 상태(HA 또는 Active/Active의 경우)
Prometheus/Grafana를 통한 성능 지표(지연 시간, 오류율)

프로덕션에 영향을 주지 않고 업그레이드를 테스트하려면 어떻게 해야 하나요?#

프로덕션을 미러링하는 별도의 스테이징 환경을 배포하고, 라이브 프로덕션 클러스터를 업그레이드하기 전에 전체 엔드투엔드 업그레이드 시뮬레이션을 실행하는 것을 강력히 권장합니다.

Operator와 Mattermost 서버를 동시에 업그레이드할 수 있나요?#

먼저 Operator를 업그레이드하세요. Mattermost 서버 버전을 업그레이드하기 전에 안정적인지 확인하세요.

데이터베이스를 별도로 업그레이드해야 하나요?#

Mattermost는 기본적으로 데이터베이스 스키마를 업그레이드하지 않습니다. 최신 Mattermost 버전에서 요구하는 경우 데이터베이스 스키마 업데이트를 수동으로 적용해야 합니다. 마이그레이션 단계에 대한 Mattermost 서버 변경 로그 를 검토하세요.

업그레이드 후 파드가 준비 상태가 되지 않으면 어떻게 해야 하나요?#

kubectl 을 사용하여 Operator 로그와 파드 이벤트를 확인하여 문제를 식별하고 해결하세요. 리소스 제약, 구성 오류 또는 네트워크 연결 문제와 같은 일반적인 문제를 찾아보세요.

Mattermost Operator와 애플리케이션 서버 간의 버전 호환성에 대해 알아야 할 것은 무엇인가요?#

오래된 Operator 버전을 실행하면 새로운 Mattermost 기능이나 업그레이드 흐름을 지원하지 않을 수 있습니다. Operator와 Mattermost 서버 간의 버전 호환성에 대한 Helm 차트 릴리즈 노트 를 항상 확인하세요.

GitOps 또는 CI/CD를 사용하여 이 업그레이드 프로세스를 자동화할 수 있나요?#

네. ArgoCD 또는 FluxCD와 같은 도구를 사용하여 버전 관리된 values.yaml 파일에서 Helm 변경 사항을 적용하여 업그레이드를 관리할 수 있습니다. 프로덕션으로 프로모션하기 전에 변경 사항이 스테이징에서 피어 검토되고 유효성이 검증되는지 확인하세요.
목차
아키텍처 개요Kubernetes 기반 배포고가용성Active/Active 배포1단계: 준비업그레이드 전 체크리스트2단계: 업그레이드 수행3단계: Active/Active 업그레이드 고려사항4단계: 유효성 검증롤백 전략자주 묻는 질문업그레이드 성공을 어떻게 확인할 수 있나요?업그레이드 후 어떤 사항을 모니터링해야 하나요?프로덕션에 영향을 주지 않고 업그레이드를 테스트하려면 어떻게 해야 하나요?Operator와 Mattermost 서버를 동시에 업그레이드할 수 있나요?데이터베이스를 별도로 업그레이드해야 하나요?업그레이드 후 파드가 준비 상태가 되지 않으면 어떻게 해야 하나요?Mattermost Operator와 애플리케이션 서버 간의 버전 호환성에 대해 알아야 할 것은 무엇인가요?GitOps 또는 CI/CD를 사용하여 이 업그레이드 프로세스를 자동화할 수 있나요?