Energent.ai liefert KI-gestützte virtuelle Desktop-Agenten, die komplexe Multi-Anwendungs-Workflows für Unternehmensbenutzer automatisieren. Dieser Leitfaden bietet umfassende Bereitstellungsspezifikationen für die Google Cloud Platform unter Verwendung moderner Cloud-nativer Architektur mit GKE, Multi-Tenant-Design und Sicherheitskontrollen auf Unternehmensniveau.
- Dokumentklassifizierung: Öffentlich
- Version: 3.0
- Letzte Aktualisierung: 2025-05-28
- Architektur: GCP GKE + Serverless Hybrid
- Compliance: SOC 2, Google Cloud Security Best Practices
Inhaltsverzeichnis
- Architekturübersicht
- GCP-Infrastrukturanforderungen
- GKE-Cluster-Spezifikationen
- Datenebenen-Architektur
- Serverlose Komponenten
- Sicherheit & Compliance
- Netzwerkarchitektur
- CI/CD-Pipeline
- Überwachung & Beobachtbarkeit
- Bereitstellungsprozess
- Betrieb & Wartung
- Support & Eskalation
1. Architekturübersicht
1.1 Cloud-native Multi-Tenant-Architektur
Energent.ai wird auf der Google Cloud Platform unter Verwendung einer modernen, skalierbaren Architektur bereitgestellt, die Kubernetes-Orchestrierung mit serverlosen Komponenten für optimale Leistung und Kosteneffizienz kombiniert.
┌──────────────────────────────────────────────────────────────────┐
│ GCP CLOUD-UMGEBUNG │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ GKE-CLUSTER │ │ SERVERLESS │ │ DATENEBENE │ │
│ │ │ │ │ │ │ │
│ │ • Multi-Tenant │ │ • Funktionen Auth│ │ • Firestore │ │
│ │ • n2-standard-4 │ │ • Funktionen Bill│ │ • Cloud Storage │ │
│ │ • Auto-Skalierung │ │ • API Gateway │ │ • Filestore │ │
│ │ • Flux GitOps │ │ • Pub/Sub │ │ • Geheimnisverwaltung │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
│ │ │ │ │
│ └─────────────────────┼────────────────────┘ │
│ │ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ VPC-SICHERHEITS-GRENZE │ │
│ │ • Private Subnets • Cloud NAT • Firewall-Regeln │ │
│ │ • IAP-Tunnel • VPC-Endpunkte • Load Balancer │ │
│ └─────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
1.2 Bereitstellungsmodelle
| Modell | Beschreibung | Anwendungsfall | SLA |
|---|
| Multi-Tenant GKE | Gemeinsamer Cluster mit Namespace-Isolierung | Standard-Unternehmensbereitstellung | 99.9% |
| Dedizierter GKE | Einzel-Tenant-Cluster | Hohe Sicherheit, regulatorische Compliance | 99.95% |
| Hybride Bereitstellung | GKE + Kunden-On-Premises-Integration | Integration von Altsystemen | 99.9% |
2. GCP-Infrastrukturanforderungen
2.1 Mindestinfrastrukturspezifikationen
| Komponente | Spezifikation | Zweck |
|---|
| GKE-Cluster-Version | 1.30+ | Kubernetes-Orchestrierung |
| Node-Pool-Instanztyp | n2-standard-4 (4 vCPU, 16 GB RAM) | Compute-optimierte Workloads |
| Mindestkonfiguration der Knoten | 1 vCPU, 2 GB RAM pro Tenant | Ressourcenallokation |
| Persistente Laufwerke | 100 GB SSD, verschlüsselt | Persistenter Speicher für Pods |
| Filestore | Basis, verschlüsselt | Gemeinsames Dateisystem |
| Cloud Storage | Standard, Versionierung aktiviert | Objektspeicher |
| Firestore | Native Mode, Verschlüsselung im Ruhezustand | Metadaten und Konfiguration |
2.2 GCP-Dienstabhängigkeiten
| Dienst | Zweck | Konfiguration |
|---|
| Google GKE | Kubernetes-Orchestrierung | Privater Cluster, Logging aktiviert |
| Compute Engine | Dynamische Knoten-Skalierung | Auto-Skalierung, vorübergehende Instanzen |
| Cloud Load Balancing | Verkehrsverteilung | SSL-Termination, Cloud Armor |
| Cloud Functions | Serverlose Funktionen | Laufzeit: Python 3.11, VPC-Connector |
| API Gateway | API-Management | Ratenbegrenzung, Authentifizierung |
| Cloud Monitoring | Überwachung und Logging | GKE-Überwachung, benutzerdefinierte Metriken |
| Secret Manager | Geheimnisverwaltung | Automatische Rotation, Verschlüsselung |
| Cloud KMS | Schlüsselverwaltung | Kundengesteuerte Schlüssel, automatische Rotation |
3. GKE-Cluster-Spezifikationen
3.1 Cluster-Konfiguration
# GKE-Cluster-Terraform-Konfiguration
resource "google_container_cluster" "energent_cluster" {
name = "energent-production"
location = var.gcp_region
remove_default_node_pool = true
initial_node_count = 1
network = google_compute_network.vpc.name
subnetwork = google_compute_subnetwork.subnet.name
networking_mode = "VPC_NATIVE"
ip_allocation_policy {
cluster_secondary_range_name = "k8s-pod-range"
services_secondary_range_name = "k8s-service-range"
}
private_cluster_config {
enable_private_nodes = true
enable_private_endpoint = false
master_ipv4_cidr_block = "172.16.0.0/28"
}
master_auth {
client_certificate_config {
issue_client_certificate = false
}
}
workload_identity_config {
workload_pool = "${var.project_id}.svc.id.goog"
}
addons_config {
gcp_filestore_csi_driver_config {
enabled = true
}
network_policy_config {
disabled = false
}
}
cluster_telemetry {
type = "ENABLED"
}
logging_config {
enable_components = [
"SYSTEM_COMPONENTS",
"WORKLOADS",
"API_SERVER"
]
}
monitoring_config {
enable_components = [
"SYSTEM_COMPONENTS",
"WORKLOADS"
]
}
}
3.2 Node-Pool-Konfiguration
# Primärer Node-Pool
resource "google_container_node_pool" "energent_nodes" {
name = "energent-node-pool"
location = var.gcp_region
cluster = google_container_cluster.energent_cluster.name
node_count = 3
autoscaling {
min_node_count = 2
max_node_count = 20
}
node_config {
preemptible = false
machine_type = "n2-standard-4"
disk_size_gb = 100
disk_type = "pd-ssd"
service_account = google_service_account.gke_service_account.email
oauth_scopes = [
"https://www.googleapis.com/auth/logging.write",
"https://www.googleapis.com/auth/monitoring",
"https://www.googleapis.com/auth/cloud-platform"
]
workload_metadata_config {
mode = "GKE_METADATA"
}
labels = {
env = "production"
app = "energent-ai"
}
taint {
key = "workload"
value = "energent-ai"
effect = "NO_SCHEDULE"
}
}
management {
auto_repair = true
auto_upgrade = true
}
}
3.3 Multi-Tenant-Ressourcenzuweisung
| Tenant-Stufe | CPU-Limit | Speicherlimit | Speicher | Gleichzeitige Workflows |
|---|
| Basic | 1 vCPU | 2 GB | 10 GB | 1 |
| Standard | 2 vCPU | 4 GB | 25 GB | 2 |
| Premium | 4 vCPU | 8 GB | 50 GB | 4 |
| Enterprise | 8 vCPU | 16 GB | 100 GB | 8 |
4. Datenebenen-Architektur
4.1 Speicherarchitektur
4.1.1 Cloud Storage-Konfiguration
# Cloud-Speicher-Bucket für Objektspeicherung
resource "google_storage_bucket" "energent_storage" {
name = "energent-${var.environment}-storage-${random_id.bucket_suffix.hex}"
location = var.gcp_region
uniform_bucket_level_access = true
versioning {
enabled = true
}
encryption {
default_kms_key_name = google_kms_crypto_key.storage_key.id
}
lifecycle_rule {
condition {
age = 90
}
action {
type = "SetStorageClass"
storage_class = "NEARLINE"
}
}
retention_policy {
retention_period = 2592000 # 30 Tage
}
labels = {
environment = var.environment
purpose = "energent-object-storage"
}
}
resource "google_storage_bucket_iam_member" "storage_admin" {
bucket = google_storage_bucket.energent_storage.name
role = "roles/storage.admin"
member = "serviceAccount:${google_service_account.gke_service_account.email}"
}
4.1.2 Firestore-Konfiguration
# Firestore-Datenbank für Metadaten und Konfiguration
resource "google_firestore_database" "energent_metadata" {
project = var.project_id
name = "energent-metadata-${var.environment}"
location_id = var.gcp_region
type = "FIRESTORE_NATIVE"
concurrency_mode = "OPTIMISTIC"
app_engine_integration_mode = "DISABLED"
point_in_time_recovery_enablement = "POINT_IN_TIME_RECOVERY_ENABLED"
delete_protection_state = "DELETE_PROTECTION_ENABLED"
}
# Firestore-Sicherheitsregeln
resource "google_firestore_database" "security_rules" {
depends_on = [google_firestore_database.energent_metadata]
# Sicherheitsregel-Inhalt würde hier definiert werden
# Implementierung von Mandantenisolation und Zugriffskontrollen
}
4.1.3 Filestore Gemeinsamer Speicher
# Filestore für gemeinsames Dateisystem
resource "google_filestore_instance" "energent_shared" {
name = "energent-shared-${var.environment}"
location = var.gcp_zone
tier = "BASIC_HDD"
file_shares {
capacity_gb = 1024
name = "energent-share"
}
networks {
network = google_compute_network.vpc.name
modes = ["MODE_IPV4"]
}
labels = {
environment = var.environment
purpose = "shared-storage"
}
}
5. Serverlose Komponenten
5.1 Cloud-Funktionen
5.1.1 Authentifizierungsdienst
# Cloud-Funktion für Authentifizierung
resource "google_cloudfunctions2_function" "auth_service" {
name = "energent-auth-${var.environment}"
location = var.gcp_region
build_config {
runtime = "python311"
entry_point = "auth_handler"
source {
storage_source {
bucket = google_storage_bucket.functions_source.name
object = google_storage_bucket_object.auth_source.name
}
}
}
service_config {
max_instance_count = 100
min_instance_count = 1
available_memory = "512Mi"
timeout_seconds = 60
environment_variables = {
FIRESTORE_PROJECT = var.project_id
SECRET_MANAGER_PROJECT = var.project_id
ENVIRONMENT = var.environment
}
vpc_connector = google_vpc_access_connector.connector.id
vpc_connector_egress_settings = "ALL_TRAFFIC"
service_account_email = google_service_account.functions_service_account.email
}
event_trigger {
trigger_region = var.gcp_region
event_type = "google.cloud.pubsub.topic.v1.messagePublished"
pubsub_topic = google_pubsub_topic.auth_events.id
}
labels = {
environment = var.environment
service = "authentication"
}
}
5.1.2 Abrechnungsdienst
# Cloud-Funktion für Abrechnung
resource "google_cloudfunctions2_function" "billing_service" {
name = "energent-billing-${var.environment}"
location = var.gcp_region
build_config {
runtime = "python311"
entry_point = "billing_handler"
source {
storage_source {
bucket = google_storage_bucket.functions_source.name
object = google_storage_bucket_object.billing_source.name
}
}
}
service_config {
max_instance_count = 50
min_instance_count = 0
available_memory = "1Gi"
timeout_seconds = 300
environment_variables = {
FIRESTORE_PROJECT = var.project_id
STORAGE_BUCKET = google_storage_bucket.energent_storage.name
}
service_account_email = google_service_account.functions_service_account.email
}
}
5.2 API-Gateway-Konfiguration
# API-Gateway für serverlose Funktionen
resource "google_api_gateway_api" "energent_api" {
provider = google-beta
api_id = "energent-api-${var.environment}"
project = var.project_id
labels = {
environment = var.environment
service = "api-gateway"
}
}
resource "google_api_gateway_api_config" "energent_api_config" {
provider = google-beta
api = google_api_gateway_api.energent_api.api_id
api_config_id = "energent-config-${var.environment}"
project = var.project_id
openapi_documents {
document {
path = "spec.yaml"
contents = base64encode(templatefile("${path.module}/api-spec.yaml", {
project_id = var.project_id
region = var.gcp_region
}))
}
}
lifecycle {
create_before_destroy = true
}
}
resource "google_api_gateway_gateway" "energent_gateway" {
provider = google-beta
gateway_id = "energent-gateway-${var.environment}"
api_config = google_api_gateway_api_config.energent_api_config.id
location = var.gcp_region
project = var.project_id
labels = {
environment = var.environment
service = "api-gateway"
}
}
6. Sicherheit & Compliance
6.1 Netzwerksicherheit
6.1.1 VPC-Konfiguration
# VPC-Netzwerk und Firewall-Regeln
resource "google_compute_network" "vpc" {
name = "energent-vpc-${var.environment}"
auto_create_subnetworks = false
mtu = 1460
}
resource "google_compute_subnetwork" "subnet" {
name = "energent-subnet-${var.environment}"
ip_cidr_range = "10.0.0.0/16"
region = var.gcp_region
network = google_compute_network.vpc.id
secondary_ip_range {
range_name = "k8s-pod-range"
ip_cidr_range = "10.1.0.0/16"
}
secondary_ip_range {
range_name = "k8s-service-range"
ip_cidr_range = "10.2.0.0/16"
}
private_ip_google_access = true
}
resource "google_compute_firewall" "allow_internal" {
name = "energent-allow-internal"
network = google_compute_network.vpc.name
allow {
protocol = "tcp"
ports = ["0-65535"]
}
allow {
protocol = "udp"
ports = ["0-65535"]
}
allow {
protocol = "icmp"
}
source_ranges = ["10.0.0.0/8"]
}
resource "google_compute_firewall" "allow_https" {
name = "energent-allow-https"
network = google_compute_network.vpc.name
allow {
protocol = "tcp"
ports = ["443"]
}
source_ranges = ["0.0.0.0/0"]
target_tags = ["https-server"]
}
6.1.2 Firewall-Regeln
| Richtung | Protokoll | Portbereich | Quelle/Ziel | Zweck |
|---|
| Eingehend | HTTPS | 443 | 0.0.0.0/0 | API-Zugriff |
| Eingehend | TCP | 1024-65535 | 10.0.0.0/8 | Interner Verkehr |
| Ausgehend | HTTPS | 443 | 0.0.0.0/0 | Externe API-Aufrufe |
| Ausgehend | TCP | 53 | 0.0.0.0/0 | DNS-Auflösung |
6.2 Verschlüsselungsstandards
| Datenstatus | Verschlüsselungsmethode | Schlüsselverwaltung | Compliance |
|---|
| Im Ruhezustand | AES-256-GCM | Cloud KMS mit automatischer Rotation | SOC 2, FIPS 140-2 Level 3 |
| Während der Übertragung | TLS 1.3 | Von Google verwaltete Zertifikate | SOC 2, PCI DSS |
| Im Speicher | Anwendungsebene | Hardware-Sicherheitsmodul | SOC 2 |
| Backup | AES-256 | Cloud KMS über Regionen hinweg | SOC 2, GDPR |
6.3 IAM und Dienstkonten
6.3.1 GKE-Dienstkonten
# GKE-Dienstkonto
resource "google_service_account" "gke_service_account" {
account_id = "energent-gke-${var.environment}"
display_name = "Energent GKE Service Account"
project = var.project_id
}
resource "google_project_iam_member" "gke_permissions" {
for_each = toset([
"roles/logging.logWriter",
"roles/monitoring.metricWriter",
"roles/monitoring.viewer",
"roles/storage.objectViewer"
])
project = var.project_id
role = each.value
member = "serviceAccount:${google_service_account.gke_service_account.email}"
}
# Workload-Identitätsbindung
resource "google_service_account_iam_member" "workload_identity" {
service_account_id = google_service_account.gke_service_account.name
role = "roles/iam.workloadIdentityUser"
member = "serviceAccount:${var.project_id}.svc.id.goog[energent-ai/energent-platform]"
}
7. Netzwerkarchitektur
7.1 VPC-Design
┌─────────────────────────────────────────────────────────────────┐
│ VPC (10.0.0.0/16) │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────┐ │
│ │ Öffentliches │ │ Öffentliches │ │ Öffentliches │ │
│ │ Subnetz │ │ Subnetz │ │ Subnetz │ │
│ │ (10.0.1.0/24) │ │ (10.0.2.0/24) │ │(10.0.3.0/24)│ │
│ │ │ │ │ │ │ │
│ │ Cloud NAT │ │ Cloud NAT │ │ Cloud NAT │ │
│ │ Lastverteiler │ │ Lastverteiler │ │Lastverteiler│ │
│ └─────────────────┘ └─────────────────┘ └─────────────┘ │
│ │ │ │ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────┐ │
│ │ Privates Subnetz│ │ Privates Subnetz│ │Privates Sub │ │
│ │ (10.1.0.0/16) │ │ (10.1.0.0/16) │ │(10.1.0.0/16)│ │
│ │ │ │ │ │ │ │
│ │ GKE-Knoten │ │ GKE-Knoten │ │ GKE-Knoten │ │
│ │ Funktionen-VPC │ │ Funktionen-VPC │ │ Funktionen │ │
│ └─────────────────┘ └─────────────────┘ └─────────────┘ │
│ │ │ │ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────┐ │
│ │ Dienst-Subnetz │ │ Dienst-Subnetz │ │Dienst-Subnet│ │
│ │ (10.2.0.0/16) │ │ (10.2.0.0/16) │ │(10.2.0.0/16)│ │
│ │ │ │ │ │ │ │
│ │ Firestore │ │ Firestore │ │ Firestore │ │
│ │ Cloud-Speicher │ │ Cloud-Speicher │ │Cloud-Speicher│ │
│ └─────────────────┘ └─────────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────────┘
7.2 Private Service-Verbindungen
| Dienst | Typ | Zweck |
|---|
| Cloud-Speicher | Privater Endpunkt | Zugriff auf Objektspeicher |
| Firestore | Privater Endpunkt | Zugriff auf Metadaten |
| GKE | Privater Cluster | Zugriff auf Cluster-API |
| Container-Registry | Privater Endpunkt | Container-Registry |
| Cloud-Monitoring | Privater Endpunkt | Überwachung und Protokollierung |
| Secret Manager | Privater Endpunkt | Zugriff auf Geheimnisse |
8. CI/CD-Pipeline
8.1 Infrastruktur als Code (Terraform)
8.1.1 Terraform-Struktur
terraform/
├── environments/
│ ├── dev/
│ ├── staging/
│ └── production/
├── modules/
│ ├── gke/
│ ├── networking/
│ ├── security/
│ └── storage/
├── shared/
│ └── backend.tf
└── global/
└── iam.tf
8.1.2 Terraform-Pipeline (Cloud Build)
# cloudbuild.yaml
steps:
# Terraform Init
- name: 'hashicorp/terraform:1.6.0'
entrypoint: 'sh'
args:
- '-c'
- |
cd terraform/environments/${_ENVIRONMENT}
terraform init -backend-config="bucket=${_TF_STATE_BUCKET}"
# Terraform Plan
- name: 'hashicorp/terraform:1.6.0'
entrypoint: 'sh'
args:
- '-c'
- |
cd terraform/environments/${_ENVIRONMENT}
terraform plan -var-file="${_ENVIRONMENT}.tfvars" -out=tfplan
# Terraform Apply (nur auf Hauptzweig)
- name: 'hashicorp/terraform:1.6.0'
entrypoint: 'sh'
args:
- '-c'
- |
if [ "${BRANCH_NAME}" = "main" ]; then
cd terraform/environments/${_ENVIRONMENT}
terraform apply -auto-approve tfplan
else
echo "Skipping apply for non-main branch"
fi
substitutions:
_ENVIRONMENT: 'production'
_TF_STATE_BUCKET: 'energent-terraform-state'
options:
logging: CLOUD_LOGGING_ONLY
machineType: 'E2_HIGHCPU_8'
timeout: 1200s
8.2 Kubernetes GitOps (Flux)
8.2.1 Flux-Konfiguration
# flux-system/gotk-sync.yaml
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
name: energent-k8s
namespace: flux-system
spec:
interval: 1m
ref:
branch: main
url: https://github.com/energent-ai/k8s-manifests
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
name: energent-apps
namespace: flux-system
spec:
interval: 10m
path: './apps'
prune: true
sourceRef:
kind: GitRepository
name: energent-k8s
validation: client
8.3 Serverless-Bereitstellung (Cloud Build)
8.3.1 Funktionsbereitstellungskonfiguration
# cloudbuild-functions.yaml
steps:
# Auth-Funktion bereitstellen
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:latest'
entrypoint: 'bash'
args:
- '-c'
- |
cd functions/auth
gcloud functions deploy energent-auth-${_ENVIRONMENT} \
--runtime python311 \
--trigger-http \
--entry-point auth_handler \
--memory 512MB \
--timeout 60s \
--region ${_REGION} \
--vpc-connector ${_VPC_CONNECTOR} \
--set-env-vars ENVIRONMENT=${_ENVIRONMENT}
# Billing-Funktion bereitstellen
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:latest'
entrypoint: 'bash'
args:
- '-c'
- |
cd functions/billing
gcloud functions deploy energent-billing-${_ENVIRONMENT} \
--runtime python311 \
--trigger-topic billing-events \
--entry-point billing_handler \
--memory 1024MB \
--timeout 300s \
--region ${_REGION}
substitutions:
_ENVIRONMENT: 'production'
_REGION: 'us-central1'
_VPC_CONNECTOR: 'energent-vpc-connector'
options:
logging: CLOUD_LOGGING_ONLY
9. Überwachung & Beobachtbarkeit
9.1 Cloud-Monitoring-Konfiguration
9.1.1 GKE-Überwachung
# Cloud-Monitoring für GKE
resource "google_monitoring_dashboard" "gke_dashboard" {
dashboard_json = jsonencode({
displayName = "Energent GKE Dashboard"
mosaicLayout = {
tiles = [
{
width = 6
height = 4
widget = {
title = "GKE Cluster CPU Utilization"
xyChart = {
dataSets = [{
timeSeriesQuery = {
timeSeriesFilter = {
filter = "resource.type=\"k8s_cluster\" AND metric.type=\"kubernetes.io/container/cpu/core_usage_time\""
}
}
}]
}
}
}
]
}
})
}
# Protokollbasierte Metriken
resource "google_logging_metric" "error_rate" {
name = "energent_error_rate"
filter = "resource.type=\"k8s_container\" AND resource.labels.namespace_name=\"energent-ai\" AND severity=\"ERROR\""
metric_descriptor {
metric_kind = "GAUGE"
value_type = "INT64"
display_name = "Energent Error Rate"
}
}
9.2 Anwendungsmetriken
| Metrikkategorie | Metriken | Ziel | Alarmgrenzwert |
|---|
| Verfügbarkeit | Betriebszeit, Gesundheitsprüfungen | 99,9% | < 99,5% |
| Leistung | Antwortzeit, Durchsatz | < 2s, > 1000 RPS | > 5s, < 500 RPS |
| Ressourcennutzung | CPU, Speicher, Speicherplatz | < 80% | > 90% |
| Fehlerraten | 4xx-, 5xx-Fehler | < 1% | > 5% |
9.3 Audit-Protokollierung
# Cloud-Audit-Protokollkonfiguration
resource "google_project_iam_audit_config" "project_audit" {
project = var.project_id
service = "allServices"
audit_log_config {
log_type = "ADMIN_READ"
}
audit_log_config {
log_type = "DATA_READ"
}
audit_log_config {
log_type = "DATA_WRITE"
}
}
# Protokoll-Sink für Sicherheitsereignisse
resource "google_logging_project_sink" "security_sink" {
name = "energent-security-sink"
destination = "storage.googleapis.com/${google_storage_bucket.audit_logs.name}"
filter = "protoPayload.serviceName=\"container.googleapis.com\" OR protoPayload.serviceName=\"iam.googleapis.com\""
unique_writer_identity = true
}
10. Bereitstellungsprozess
10.1 Bereitstellungszeitplan
| Phase | Dauer | Aktivitäten | Beteiligte |
|---|
| Vorbereitung | 2-3 Tage | Infrastrukturplanung, Sicherheitsüberprüfung | Kunden-IT, Sicherheit, Energent-Lösungen |
| Infrastruktur | 1-2 Tage | Terraform-Bereitstellung, VPC-Einrichtung | Kunden-DevOps, Energent-Plattform |
| GKE-Cluster | 0,5 Tag | Cluster-Bereitstellung, Knotengruppen | Kunden-DevOps, Energent-Plattform |
| Anwendung | 0,5 Tag | Flux-Bereitstellung, Anwendungsausrollung | Energent-Plattform-Team |
| Integration | 1-2 Tage | IAM, Überwachung, Tests | Kunden-IT, Energent-Support |
| Go-Live | 0,5 Tag | Produktionsumstellung, Validierung | Alle Beteiligten |
10.2 Bereitstellungsbefehle
10.2.1 Infrastruktur-Bereitstellung
# Infrastruktur-Bereitstellung mit Terraform
cd terraform/environments/production
terraform init -backend-config="bucket=energent-terraform-state"
terraform plan -var-file="production.tfvars"
terraform apply -auto-approve
# GKE-Cluster überprüfen
gcloud container clusters get-credentials energent-production --region us-central1
kubectl get nodes
10.2.2 Anwendungs-Bereitstellung
# Flux GitOps installieren
flux bootstrap github \
--owner=energent-ai \
--repository=k8s-manifests \
--branch=main \
--path=./clusters/production
# Serverlose Komponenten bereitstellen
gcloud builds submit --config cloudbuild-functions.yaml \
--substitutions _ENVIRONMENT=production,_REGION=us-central1
# Überprüfung der Bereitstellung
kubectl get pods -n energent-ai
kubectl get ingress -n energent-ai
10.3 Validierung der Bereitstellung
# Endpunkte für Gesundheitsprüfung
curl -k https://api.energent.example.com/health
curl -k https://api.energent.example.com/metrics
# Kubernetes-Validierung
kubectl top nodes
kubectl get hpa -n energent-ai
kubectl logs -n energent-ai -l app=energent-platform
11. Betrieb & Wartung
11.1 Backup & Notfallwiederherstellung
11.1.1 Backup-Strategie
| Komponente | Häufigkeit | Aufbewahrung | RTO | RPO |
|---|
| GKE Cluster-Zustand | Täglich | 30 Tage | < 4 Stunden | < 24 Stunden |
| Anwendungsdaten | Echtzeit | 90 Tage | < 1 Stunde | < 15 Minuten |
| Konfiguration | Bei Änderung | 1 Jahr | < 30 Minuten | 0 |
| Prüfprotokolle | Echtzeit | 7 Jahre | < 24 Stunden | 0 |
11.1.2 Verfahren zur Notfallwiederherstellung
# GKE-Cluster-Backup mit Velero
velero backup create energent-cluster-backup \
--include-namespaces energent-ai \
--storage-location gcp
# Firestore Point-in-Time-Wiederherstellung
gcloud firestore databases restore \
--source-database=energent-metadata-production \
--destination-database=energent-metadata-restored \
--backup-time=2025-05-28T10:00:00Z
11.2 Skalierung & Leistung
11.2.1 Konfiguration der automatischen Skalierung
# Horizontaler Pod-Autoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: energent-platform-hpa
namespace: energent-ai
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: energent-platform
minReplicas: 3
maxReplicas: 50
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
11.3 Aktualisierung & Wartung
11.3.1 Rolling-Updates
# GKE-Cluster-Update
gcloud container clusters upgrade energent-production \
--master \
--cluster-version 1.30 \
--region us-central1
# Anwendung-Rolling-Update über Flux
git commit -am "Update energent-platform to v2.1.0"
git push origin main
# Flux erkennt und wendet Änderungen automatisch an
12. Support & Eskalation
12.1 Support-Stufen
| Stufe | Reaktionszeit | Kanäle | Umfang |
|---|
| L1 - Basis | < 4 Stunden | E-Mail, Portal | Allgemeine Fragen, Dokumentation |
| L2 - Standard | < 2 Stunden | Telefon, E-Mail, Meet | Technische Probleme, Integrationssupport |
| L3 - Premium | < 1 Stunde | Telefon, Meet, Video | Komplexe technische Probleme, Architektur |
| L4 - Kritisch | < 30 Minuten | Telefon, SMS, Eskalation | Produktionsausfälle, Sicherheitsvorfälle |
12.2 24/7 Support-Abdeckung
Enterprise-Support:
Notfall-Eskalation:
12.3 Service-Level-Agreements
| Dienst | SLA | Strafe |
|---|
| Plattformverfügbarkeit | 99,9 % Uptime | 10 % monatlicher Kredit pro 0,1 % Ausfall |
| Reaktionszeit (P95) | < 2 Sekunden | 5 % monatlicher Kredit bei > 5 Sekunden |
| Support-Reaktion | Gemäß obenstehender Stufen | Eskalation zur nächsten Stufe |
| Datenwiederherstellung | RTO < 4 Stunden | 25 % monatlicher Kredit bei Überschreitung |
Anhänge
Anhang A: GCP-Dienstkosten
| Dienst | Geschätzte monatliche Kosten | Skalierungsfaktor |
|---|
| GKE-Cluster | $75 | Fest pro Cluster |
| Compute Engine (3x n2-standard-4) | $850 | Linear pro Node |
| Persistente Laufwerke (300GB) | $60 | Linear pro GB |
| Cloud Storage (1TB) | $20 | Linear pro GB |
| Firestore | $120 | Nutzungsbasiert |
| Cloud Functions | $35 | Anfragebasiert |
| Gesamtkosten Basis | ~$1.160/Monat | Für 100 Mandanten |
Anhang B: Sicherheits-Compliance-Checkliste
Anhang C: Fehlerbehebungsleitfaden
Häufige Probleme:
-
GKE-Knoten treten dem Cluster nicht bei
- Überprüfen Sie die Berechtigungen des Dienstkontos
- Überprüfen Sie die Subnetz-Routing und Cloud NAT
-
Anwendungspods CrashLooping
- Überprüfen Sie Ressourcenlimits und -anforderungen
- Überprüfen Sie Ansprüche auf persistente Volumes
-
Netzwerkverbindungsprobleme
- Überprüfen Sie die Konfiguration des VPC-Konnektors
- Überprüfen Sie die Firewall-Regeln
- Dokumentklassifizierung: Öffentlich
- Version: 3.0
- Letzte Aktualisierung: 2025-05-28
- Nächste Überprüfung: 2025-08-28
- Kontakt: support@energent.ai