Modernizing PCF workloads with Google Kf and Kubernetes

Originally announced in 2011, Cloud Foundry(CF) was designed to support the whole application development lifecycle, from the beginning stages of development to deployment. Pivotal Cloud Foundry is an enterprise-supported distribution of Cloud Foundry, adopted by many organizations seeking to provide a flexible but opinionated platform.

Organizations looking to develop or enhance hybrid and multi-cloud strategies face challenges migrating their applications from PCF to Kubernetes. The high dependency on Cloud Foundry backing services for your application usually means that the application is locked to Cloud Foundry, and migrating the application usually involves code refactor or rewrite, not to mention changes to application lifecycle management and the developer experience.

This blog will cover how Google Cloud Kf can streamline this process, so you can break free from licensing costs and avoid refactoring exercises while maintaining the developer experience and modernizing the platform for your applications.

What is Kf? (Hint: It’s not a CF clone)

Kf feels like Cloud Foundry on the surface, but underneath, it is true Kubernetes. Kf runs on Google Kubernetes Engine (GKE) and leverages several open source projects to run. Unlike PCF, Kf is available without any additional licensing cost or paid subscription on GKE.

Deployed on GKE with Tekton and Anthos Service Mesh(ASM), Kf also installs several custom resources, including builds, apps, and routes, to provide a well-rounded developer experience.

Many organizations have made significant investments in the PCF platform, developer experience and training, but high licensing costs and platform changes have many seeking alternatives. Maintaining the developer experience during migration from PCF is important.  

Kf solves this problem by providing the same developer experience on Kubernetes at no additional cost. Some examples of the correlation of CF commands with Kf and Kubernetes:

Migrating applications to Kf

To demonstrate the power of Kf, and how it helps streamline the migration process for application teams, let’s walk through an example.  We have a music application running on CF that we’d like to migrate to GKE, with Kf: 

We start by creating a space that we will use to deploy the application:

$ kf create-space music
Space requested, waiting for subcomponents to be created
Space created
Status:
  Ready:
    Ready:  True
    Time:   2021-10-21 16:41:22 -0400 EDT
  Conditions:
    Type                      Status  Updated  Message  Reason
    AppNetworkPolicyReady     True    0s
    BuildConfigReady          True    0s
    BuildNetworkPolicyReady   True    0s
    BuildSecretReady          True    0s
    BuildServiceAccountReady  True    0s
    ClusterRoleBindingsReady  True    0s
    ClusterRoleReady          True    0s
    IngressGatewayReady       True    0s
    NamespaceReady            True    0s
    NetworkConfigReady        True    0s
    RoleBindingsReady         True    0s
    RuntimeConfigReady        True    0s


TIP: These other commands could be useful:
Get space info:    kf space music
                   kubectl get space music
Target space:      kf target -s music
Set space config:  kf configure-space

We can inspect the corresponding kubernetes resources created by the `kf create-space` : 

$ kubectl get namespace | grep music
music              Active   141m

Deploying the application is done using the `kf push` command from the directory containing the application code:

$ kf push --space music
Checking for existing App named "sada-music"...
..
..
[deploy] App took 13.82 seconds to become ready.
[deploy] Total push time 91.85 seconds
Successfully deployed
[deploy] End tailing App logs
Name:       sada-music
Space:      music
Routes:     [sada-music-16ddfwutxgjte-cf5dndfng6tk.music.34.130.28.52.nip.io/]
Instances:  1

TIP: These other commands could be useful:
View build logs:  kf build-logs sada-music-2 --space music
View App logs:    kf logs sada-music --space music
Stop App:         kf stop sada-music --space music

We can inspect the application pods created by the `kf push` command using `kubectl`:

$ kubectl get pods -n music
NAME                         READY   STATUS      RESTARTS   AGE
sada-music-1-pod-5s5sg       0/10    Completed   1          6m1s
sada-music-2-pod-n829c       0/10    Completed   1          2m58s
sada-music-877bccb8b-d89w5   2/2     Running     0          100s

The `kf apps` command can be used to find out the status of the application:

$ kf apps
Listing Apps in Space: music
Name        Instances  Memory  Disk  CPU   URLs                                                                  Cluster URL  Ready  Reason
sada-music  1          1Gi     1Gi   100m  ["sada-music-16ddfwutxgjte-cf5dndfng6tk.music.34.130.28.52.nip.io/"]  <nil>        True   <nil>

The `kf routes` command can be used to find out the endpoints  of the application:

$ kf routes
Listing routes in Space: music
sada-music-16ddfwutxgjte-cf5dnd93125653459065614b80d8eda59587ca  sada-music-16ddfwutxgjte-cf5dndfng6tk    music.34.130.28.52.nip.io  /     ["sada-music"]  <nil>         7m44s  True   <nil>

Kf uses Anthos Service Mesh, which is based on Istio,  to provide the ingress and virtual services to access the application endpoint:

$ kubectl get vs -n music
NAME                                                        GATEWAYS                  HOSTS                                                         
music-34-130-28-52-nip-ioa9dfbc8d9dc299c6f4bb6bd6289b8f2d   ["kf/external-gateway"]   ["*.music.34.130.28.52.nip.io","music.34.130.28.52.nip.io"]

The application can now be accessed on the Route created by Kf:

Using Kf with GKE can help reduce changes to the application lifecycle and make migrations to Google Cloud more seamless for application teams. To learn more about Google Cloud Kf, Anthos, or any of its components and how they can help you and your organization, contact us at [email protected].