template-gke-resources
Purpose and Scope
This project defines the configuration templates for the resources required to deploy applications on Google Kubernetes Engine (GKE) within the LATAM ecosystem. Its purpose is to standardize and simplify the creation of the base infrastructure in GKE, including network, security, and environment variable configuration.
The scope includes the definition of:
- Backend and Frontend configurations for services.
- ConfigMaps for variable injection.
- Ingress resources for service exposure and traffic routing.
- Basic security policies through Cloud Armor.
- Use of TLS certificates and HTTPS redirection.
This template is designed to be used with the gke-krane-deploy deployment pipeline.
Architecture
The project is based on Kubernetes manifest templates in YAML format, using ERB (Embedded Ruby) to allow customization of values at deployment time. These manifests describe the resources that will be created or updated in a GKE cluster.
The main components defined are:
- BackendConfig: Defines specific configurations for service backends, such as timeouts and security policies (e.g., Cloud Armor).
- FrontendConfig: Defines frontend configurations, such as automatic redirection to HTTPS.
- ConfigMap: Stores non-sensitive configuration data in key-value pairs that can be consumed by pods.
- Ingress: Manages external access to services within the cluster, typically HTTP/HTTPS, configuring load balancing, SSL termination, and host- and path-based routing.
Deployment of these resources is performed through a Jenkins pipeline that uses Krane.
Technologies and Dependencies
- Orchestration Platform: Google Kubernetes Engine (GKE)
- Resource Definition: Kubernetes YAML
- Template Engine: ERB (Embedded Ruby)
- Continuous Integration/Continuous Deployment (CI/CD): Jenkins (using the
gke-krane-deploypipeline) - Version Control: Git (GitLab)
- Perimeter Security (optional): Google Cloud Armor (referenced in
BackendConfig)
Local Configuration
Prerequisites
- Git installed.
- Access to the project repository.
Steps to Review the Templates
-
Clone the repository: Follow the steps below
-
Explore the templates: The main configuration files are located in the
deploy/gke/directory. The key file is:deployment.yaml.erb: Contains the templates forBackendConfig,FrontendConfig,ConfigMap, andIngress.
Variables enclosed in
<%= ... %>(e.g.,<%= owner_name %>,<%= environment %>) are replaced by the deployment pipeline with environment- and application-specific values.
Deployment
Deployment of these GKE resources is performed through the Jenkins pipeline specified in the Jenkinsfile
of the application that consumes this template.
Jenkinsfile
The Jenkinsfile of the application that uses this template must invoke the LATAM global pipeline for GKE
deployments with Krane:
pipelineLatam("gke-krane-deploy")
This pipeline will process the .erb templates in deploy/gke/deployment.yaml.erb, substituting the
variables and applying the resulting YAML manifests to the corresponding GKE cluster.
Deployment Variables
The templates use variables that are injected during the deployment process. Some of the key variables are:
owner_name: Owner or application name.environment: Deployment environment (e.g.,dev,qa,prod).git_commit: Git commit hash.build_id: Build identifier.dns_record: DNS record for the Ingress.static_ip_name: Global static IP resource name.is_prod_deploy: Boolean indicating whether it is a production deployment.
API Endpoints
This project does not define APIs directly, but rather the infrastructure (Ingress) that exposes the endpoints of the
deployed applications. The Ingress resource configured in deploy/gke/deployment.yaml.erb defines how external
traffic is routed to internal services.
Ingress Route Configuration
The Ingress defines path-based routes for different services:
spec:
tls:
- secretName: <%= owner_name %>-<%= environment %>-certificate # TLS certificate
rules:
- host: <%= dns_record %> # Primary DNS
http:
paths:
- path: / # Route for the main frontend
pathType: Prefix
backend:
service:
name: <%= owner_name %>-template-angular-fe-service
port:
number: 80
- path: /api/bl/ # Route for the Business Logic service
pathType: Prefix
backend:
service:
name: <%= owner_name %>-template-spring-bl-service
port:
number: 80
- path: /authorization-service/ # Route for the authorization service
pathType: Prefix
backend:
service:
name: <%= owner_name %>-auth-service-bl-service
port:
number: 80
- path: /web/ # Route for the web service (e.g., traditional Spring MVC)
pathType: Prefix
backend:
service:
name: <%= owner_name %>-template-spring-web-service
port:
number: 80
- Traffic is directed to the corresponding service (
backend.service.name) based on the requestpath. - A secret name (
secretName) is used for TLS configuration, ensuring HTTPS communication. - A global static IP is associated (
kubernetes.io/ingress.global-static-ip-name).
Specific Components (Kubernetes Resources)
BackendConfig
- Purpose: Configure advanced parameters for backend services, such as timeouts and security policies.
- Configuration Fragment (
deploy/gke/deployment.yaml.erb):apiVersion: cloud.google.com/v1kind: BackendConfigmetadata:name: "<%= owner_name %>-<%= environment %>-backendconfig"labels:app: "<%= owner_name %>"git_commit: "<%= git_commit %>"build_id: "<%= build_id %>"spec:timeoutSec: 120 # Timeout for backend responsessecurityPolicy:name: "cloudarmor-corp" # Cloud Armor policy - Usage: Associated with Kubernetes services through annotations in the service definition (not included in this template, but is the expected usage).
FrontendConfig
- Purpose: Specify configurations for the Ingress frontend, primarily HTTP to HTTPS redirection.
- Configuration Fragment (
deploy/gke/deployment.yaml.erb):apiVersion: networking.gke.io/v1beta1kind: FrontendConfigmetadata:name: "<%= owner_name %>-<%= environment %>-frontendconfig"labels:app: "<%= owner_name %>"git_commit: "<%= git_commit %>"build_id: "<%= build_id %>"spec:redirectToHttps:enabled: trueresponseCodeName: MOVED_PERMANENTLY_DEFAULT # 301 response code - Usage: Associated with the Ingress through the
networking.gke.io/v1beta1.FrontendConfigannotation.
ConfigMap
- Purpose: Store and manage configuration variables that can be consumed by applications.
- Configuration Fragment (
deploy/gke/deployment.yaml.erb):apiVersion: v1kind: ConfigMapmetadata:name: "<%= owner_name %>-<%= environment %>-configmap"labels:app: "<%= owner_name %>"git_commit: "<%= git_commit %>"build_id: "<%= build_id %>"data:ENVIRONMENT: "<%= environment %>"APPLICATION: "<%= owner_name %>"DNS_RECORD: "<%= dns_record %>"IS_PROD_DEPLOY: "<%= is_prod_deploy %>" - Usage: Pods can mount this data as environment variables or files.
Ingress
- Purpose: Manage incoming traffic, providing load balancing, SSL termination, and routing based on host names and paths.
- Configuration Fragment (
deploy/gke/deployment.yaml.erb):apiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: <%= owner_name %>-<%= environment %>-ingresslabels:app: "<%= owner_name %>"git_commit: "<%= git_commit %>"build_id: "<%= build_id %>"annotations:kubernetes.io/ingress.global-static-ip-name: <%= static_ip_name %>networking.gke.io/v1beta1.FrontendConfig: <%= owner_name %>-<%= environment %>-frontendconfigspec:tls:- secretName: <%= owner_name %>-<%= environment %>-certificaterules:# ... (see API Endpoints section for rule details) - Usage: Directs external traffic to the correct services within the cluster, based on the defined rules.
Testing
This project, being a set of infrastructure templates, does not contain unit or integration tests in the traditional software sense. "Testing" consists of:
- YAML/ERB Syntax Validation: Ensuring the templates are valid before deployment. This is usually part of the linting process or Krane itself.
- Successful Deployment: Verifying that the Jenkins pipeline applies the manifests to the GKE cluster without errors.
- GKE Resource Verification: Confirming that the resources (
BackendConfig,FrontendConfig,ConfigMap,Ingress) have been created or updated correctly in the cluster. - Connectivity and Routing Tests: Once the applications using these resources are deployed, test access through the Ingress, the correct application of security policies, and HTTPS redirection.
Tools for these verifications include:
kubectlto inspect resources in the GKE cluster.- Google Cloud Platform Console.
- Endpoint testing tools (e.g., Postman, curl) to verify Ingress routing.
Security Considerations
- Mandatory HTTPS: The
FrontendConfigis configured to redirect all HTTP traffic to HTTPS. - TLS Certificates: The Ingress uses a Kubernetes secret
(
secretName: <%= owner_name %>-<%= environment %>-certificate) for SSL/TLS termination. Management of this certificate (creation, renewal) is external to this template but crucial. - Cloud Armor: The
BackendConfigreferences a Cloud Armor security policy (cloudarmor-corp). This implies that traffic to the backends may be protected by WAF and other security rules defined in that policy. - Static IP: Using a global static IP (
kubernetes.io/ingress.global-static-ip-name) facilitates whitelist configuration and DNS records. - ConfigMaps: Should only be used for non-sensitive configuration data. Secrets should be managed using Kubernetes Secrets.
- Pipeline Permissions: The Jenkins pipeline (
gke-krane-deploy) must have the appropriate permissions in GCP to manage these resources in GKE.