EKS or GKE integration

An adapter translates a specific interface

In this path, a target adapter is the configuration and provisioning work that supplies the application's dependencies on one target. It can choose storage classes, endpoints and identities. It cannot translate application protocols merely by renaming an environment.

Select a first target deliberately

EKS and GKE can run Kubernetes workloads, but their surrounding identity, network, storage, and operational models differ. Choose one for the first experiment and define what you want to learn from it.

MicroBank currently uses AWS SNS/SQS client behavior. Moving its Pods to GKE does not translate SNS/SQS into Pub/Sub. You must retain reachable AWS services with suitable identity and egress, retain a clearly labelled emulator for a disposable experiment, or implement and test a new application messaging adapter. The third option is application engineering beyond an overlay change.

Plan target-specific responsibilities

GKE workload identity for Google APIs does not itself authorize an AWS SDK request.

Separate three kinds of change

Imagine moving the existing Ledger image to a GKE cluster. Kubernetes can schedule the Pod, but Ledger still calls the AWS messaging API it was written to use.

A practical first choice is to keep the application's existing protocol and explicitly design identity and connectivity. Another is to implement a new messaging adapter, but that is application work with its own tests. Record the choice before spending time on cluster provisioning.

For EKS, inspect whether the code uses a credential provider that can consume the chosen workload identity. The inspected Ledger baseline constructs static credentials, so a ServiceAccount annotation alone does not complete the change. For GKE, Google workload identity authorizes Google APIs; it does not automatically grant access to AWS queues.

Write one target decision with a selected provider, expected API, credential path, private network path and unresolved changes. This exercise produces a design, not a claim that either cloud deployment has been executed.

Try it

Write an adapter decision record before provisioning: target, reason, dependency choices, missing application changes, operator identity, costs to inventory, private access path, and acceptance evidence. Review MicroBank's credential construction; the inspected Ledger code explicitly builds static credentials, so adding a Kubernetes ServiceAccount alone will not switch it to workload identity.

The cloud lab supplies a compatibility review and plan-first workflow. A completed live cloud adapter requires actual target implementation and recorded results; use the table to plan that work and track what remains unverified.

Checkpoint and revision

Identify at least one required change outside Kubernetes YAML. Explain how you would verify that the workload uses the intended short-lived identity rather than inherited dummy or long-lived credentials.

Compare your reasoning

If a Pod starts but cannot read its queue, do not immediately blame Kubernetes. Verify API compatibility, endpoint, identity and permission separately. Keep the source revision in the record because application changes can alter those requirements.

Sources

EKS Pod Identity↗, GKE workload identity↗, AWS SDK Java default credentials↗.