Korifi for K8s Users

As we have stated, Korifi is an implementation on top of Kubernetes. Because of this, you can view Korifi resources either at the higher level (application-centric) abstraction using the cf CLI or at the lower level (container-centric) using kubectl. However, because the use of kubectl is not required to use Korifi, we will not go in-depth on the use of kubectl with Korifi elements.

Korifi with kubectl

You can use kubectl to view and interact with the underlying Korifi components. However, kubectl is optional as the entire lifecycle of applications can be managed using the cf CLI. However, we will touch on the basics below. We leave the detailed investigation to you should you choose to embark on it.


The Korifi installation creates multiple namespaces. You can view the namespaces created by Korifi (denoted below with a “*”).

kubectl get namespaces

cert-manager*                                    Active   25h
cf*                                              Active   25h
cf-org-d255d9f0-962e-4122-bd6a-422110b15e0d*     Active   117m
cf-space-0eee9ef7-ff1e-4a80-842f-a53179768b6f*   Active   116m
default                                          Active   25h
korifi*                                          Active   25h
kpack*                                           Active   25h
kube-node-lease                                  Active   25h
kube-public                                      Active   25h
kube-system                                      Active   25h
local-path-storage                               Active   25h
projectcontour*                                  Active   25h
servicebinding-system*                           Active   25h
Application Pods

Of note are the namespaces starting with cf-org-* and cf-space-*. These correspond to the org and space created after the installation. Applications are deployed to a space. Therefore, you can view your application pods in the namespace corresponding to your space:

kubectl get pods -n cf-space-0eee9ef7-ff1e-4a80-842f-a53179768b6f

NAME                                                     READY   STATUS      RESTARTS   AGE
d60fe7b7-f080-4caa-a26b-b811c88d766e-cf--cbc52994d8-1    1/1     Running     0          16h
ef3d386d-1cea-46bf-8191-fedcedba8532-build-1-build-pod   0/1     Completed   0          17h

The pod marked “Completed” was used during your application’s build process (called staging).

Custom Resources

As discussed earlier, Korifi uses custom resource definitions to implement Cloud Foundry constructs. You can view the list of custom resources created by Korifi.

kubectl api-resources | grep korifi

appworkloads          korifi.cloudfoundry.org/v1alpha1       true         AppWorkload
builderinfos          korifi.cloudfoundry.org/v1alpha1       true         BuilderInfo
buildworkloads        korifi.cloudfoundry.org/v1alpha1       true         BuildWorkload
cfapps                korifi.cloudfoundry.org/v1alpha1       true         CFApp
cfbuilds              korifi.cloudfoundry.org/v1alpha1       true         CFBuild
cfdomains             korifi.cloudfoundry.org/v1alpha1       true         CFDomain
cforgs                korifi.cloudfoundry.org/v1alpha1       true         CFOrg
cfpackages            korifi.cloudfoundry.org/v1alpha1       true         CFPackage
cfprocesses           korifi.cloudfoundry.org/v1alpha1       true         CFProcess
cfroutes              korifi.cloudfoundry.org/v1alpha1       true         CFRoute
cfservicebindings     korifi.cloudfoundry.org/v1alpha1       true         CFServiceBinding
cfserviceinstances    korifi.cloudfoundry.org/v1alpha1       true         CFServiceInstance
cfspaces              korifi.cloudfoundry.org/v1alpha1       true         CFSpace
cftasks               korifi.cloudfoundry.org/v1alpha1       true         CFTask
taskworkloads         korifi.cloudfoundry.org/v1alpha1       true         TaskWorkload

You can explore these resources using kubectl or view the representations defined in the Korifi API.

How do I…?

In Korifi, the primary unit of focus is the application. An application is a higher-level abstraction than a container. Korifi allows developers to work at the higher level but still drop down to the lower level abstraction if need be. Below, we answer common questions from Kubernetes users.

How do I run a container image?

With Korifi, you do not need to bring a container image. Instead, you bring your application code (uploaded during the cf push). Korifi will use kpack and Paketo buildpacks to construct an OCI compatible container image for your application.

Paketo is an implementation of Cloud Native Buildpacks, an easier, more streamlined, secure, and repeatable way to build container images. Cloud Native Buildpacks are part of the Cloud Native Computing Foundation and are supported by all major cloud providers. So while Korifi ships with the Paketo implementation, you can use other provider implementations as well.

How do I check on my pods?

With Korifi, applications run in pods. You do not need to create pods yourself. However, you can still run non-cf pods in the same Kubernetes instance.

An application is a higher-level construct in Korifi. Therefore you can check on your applications using the cf CLI. For example, you can see your apps (in an org and space) by running cf apps. If you deployed the sample application, you would see a list of your applications similar to:

Getting apps in org tutorial / space dev as cf-admin...

name         requested state   processes   routes
sample-app   started           web:1/1     sample-app.apps-127-0-0-1.nip.io

You can also see more details about your app with cf app <APP_NAME>:

cf app sample-app
Showing health and status for app sample-app in org tutorial / space dev as cf-admin...

name:              sample-app
requested state:   started
routes:            sample-app.apps-127-0-0-1.nip.io
last uploaded:     Thu 09 Feb 16:34:02 MST 2023
stack:             io.buildpacks.stacks.bionic

type:           web
instances:      1/1
memory usage:   32M
     state     since                  cpu    memory         disk       logging      details
#0   running   2023-02-10T00:23:19Z   0.0%   22.1M of 32M   0 of 64M   0/s of 0/s

The depths of the Cloud Foundry API are outside the scope of this tutorial. However, we recommend you peruse the documentation and the features in the cf CLI. You will notice that you have access to all the same Kubernetes primitives and the higher-level resource definitions.

How do I configure my application to handle more traffic?

In Korifi, you can scale your application using cf scale to add instances (horizontal scale) or memory (vertical scale). Korifi will handle the rest. You do not need to update any other configuration.

How do I allow traffic into my application?

By default, applications are deployed with an assigned route. This route is used to access the application. Korifi manages the ingress routing for you. You can also deploy applications without a route if ingress is not required.

How do I create a load balancer between pods?

You don’t need to. Instead, as you add (or remove) instances with the cf scale command, Korifi handles this for you.

How do I restart apps/pods/containers?

You likely won’t need to in most cases. However, if you want to, you can use the cf start, cf stop, and cf restart commands.

How to update the application to a new version?

You can simply re-run the cf push command when you have a new version of your application.

How can I create isolation between projects?

You can use the Cloud Foundry constructs of Orgs and Spaces. Orgs and spaces are implemented using namespaces in Korifi. Users are assigned Cloud Foundry roles in orgs and spaces to control access using Kubernetes RBAC. Using the Korifi constructs is far simpler than directly managing namespaces and Kubernetes RBAC.