In the recent SAP platform discussions,
Kyma has become a ?hot topic. Mainly, the announcement that
Kyma will be available as a managed service from SAP seemed to gotten everyone's attention. It certainly caught my attention.
If you haven't heard of Kyma yet, there is a great
blog post available that explains what Kyma is in detail. If you're looking for a short version, Kyma is an open source project part of
CNCF Cloud Native Landspace that runs on top of Kubernetes to simplify the extension and integration of monolithic software.
At least, that's what I have heard.
I have yet to understand what Kyma
is or
does on my own. Therefore, I'm going to roll up my sleeves and experience Kyma firsthand.
If you have been curious about Kyma and looking to dig deeper into the core components, I want to encourage you to try out Kyma with
me. I will be sharing my experiences in a series of blog posts which will contain a list of the steps I took, the lessons I learned, and the tips I gathered in hopes that it will amplify not only your understanding but mine as well.
Installation
To get started with Kyma, we must first install Kyma onto a cluster. Before jumping in, let me share my setup.
- Mac OS Catalina version
10.15.4
- Minikube version
v1.11.0
- Hyperkit version
v0.20200224-27-g79c6a4
- Kyma CLI version
v1.13.0
Note: I highly recommend using a non-work device especially if it's heavily locked down by your IT department.
With the setup I shared, installing Kyma locally using Minikube can be done with just two commands.
$ kyma provision minkube
$ kyma install
Successful installation output will result in a list of all components installed, a URL for the console, username/password to access the console, and
"Installation successful! Happy Kyma-ing! :)"
message.
?Lessons Learned
What does installation tell us?
1. Kyma downloads
A LOT of components. A list of components installed can be seen by the log output and felt by the time it takes. Installing Kyma on Minikube took ~17mins for me, so patience seems to be essential.
2. There are two versions of Kyma that's available to install: full (Kyma) and lite (Kyma Lite). The lite version is used for local development and does not install components like logging, monitoring, and etc. A full list of all components installed for full and lite version can be found
here.
3. Kyma allows you the flexibility to
customize the installation. By modifying a
yaml
file used to install components, you can enable or disable them. According to the
documentation, it seems there are some components that you can not disable without providing a replacement. However, I was not able to find which components are required and which components are optional.
4. Kyma provides a console for easy visibility into the cluster and to trigger administrative actions to change the state of the cluster.
?Tips
- Be patient with the installation
- The installation documentation recommends Minikube version
1.6.2
, but I was able to run the installation successfully with version v1.11.0
(So far, I haven't ran into any issues yet)
- If installation using
kyma
CLI does not work, try running the installation from source code
kyma install --source local --src-path {YOUR_KYMA_SOURCE_PATH}
- Username and Password for accessing the console
- username is
admin@kyma.cx
- password can be retrieved by running the following command
kubectl get secret admin-user -n kyma-system -o jsonpath="{.data.password}" | base64 --decode
Deploy a Sample Application
The first example available to test out Kyma functionality is a
tutorial on deploying a sample service. This tutorial goes through the steps of creating a
Deployment
,
Service
, and a
custom resource APIRule
to deploy and expose the service’s API either insecurely or securely.
Even though the tutorial ends after securing the service’s API without details on how to access the API afterward, there is a
longer version of the tutorial available if you want to explore how to retrieve tokens necessary to test the secured API.
Using both tutorials, I was able to test out the following cases
- Expose a sample application without authentication
- Expose a sample application with authentication using JSON Web Tokens
- Expose a sample application with authentication using OAuth2
A high-level overview of the steps I took are listed below
- Create a
Deployment
- Create a
Service
- Create an
APIRule
- Add the IP address of Minikube to a local host file
- Make a call to the service without a header
- Modify existing
APIRule
to add jwt rule
- Grab a jwt token from
kubeconfig
- Make a call to the service with a jwt token in the header
- Modify existing
APIRule
to add OAuth2 rule
- Create an
OAuth2Client
- Create a
Secret
for OAuth2
- Make a call to retrieve a token
- Make a call to the service with an OAuth2 token in the header
?Lessons Learned
What does deploying a sample application tell us?
1. Kyma offers its own gateway to expose applications outside of the cluster. Kyma requires the creation of a
CustomResourceDefinition apirules.gateway.kyma-project.io
which is used to create Istio Virtual Service that specifies traffic routing rules to apply to a Kubernetes service.
2. Kyma's API Gateway Controller which manages
apirules.gateway.kyma-project.io
also allows you to secure the exposed service using
Dex (JWT) and
Hydra (OAuth2 Token). Enabling the two options requires interaction with
ORY Oathkeeper component and is triggered to create a
Rule
(
rules.oathkeeper.ory.sh
) resource when
APIRule
(
apirules.gateway.kyma-project.io
) declares an authentication method.
3. Kyma comes with a self-signed certificate using
xip.io
to allow a 30-days SSL certificate for local development. A certificate can be found in a secret called
apiserver-proxy-tls-cert
and steps to
update TLS certificate is available on their official docs.
4. Kyma automatically injects Istio envoy sidecar proxy to all pods in all namespaces except istio-system
and kube-system
. If needed, sidecar proxy injection can be disabled by modifying the istio-injection
label to disabled
. Additionally, mutual TLS (mTLS) is enabled cluster-wide with strict
configuration which allows only mTLS traffic within the workloads.
?Tips
- "Update your service's API to secure it" part of the tutorial returns
404
when trying to apply the yaml
file.
- GitHub issue is open to address the bug
- When fetching
jwt
token via UI, downloading kubeconfig
is not possible in chrome. Try out other browsers instead (Confirmed it works with safari
)
- GitHub issue(s) are open to address the bug
- It might be possible to grab it programmatically, not sure if this is possible.
- Run
kubectl get apirule --all-namespaces
to see an existing example of APIRule
resource
- Using env variable in the header for
jwt
and OAuth2
Authentication may not work. In that case, try inserting the values instead.
- Example with env variable
- Example without env variable
- Local domain for Minikube installation is
kyma.local
- Always add the IP address of Minikube to the host file on your local machine for your any services you want to expose
echo "$(minikube ip) $hostname.kyma.local" | sudo tee -a /etc/hosts
- To list
OAuth2Client
resource run the following command
kubectl get oauth2client.hydra.ory.sh
--
So far, I see that Kyma offers a set of cloud-native components out of the box and removes the complexity of integrating these technologies.
This may be favorable for a lot of Kubernetes users who want production-grade services. By deferring the decision and implementation to Kyma, you can choose to focus on functionalities instead.
However, this doesn't mean you get to look the other way when there's a problem with one of the components. While Kyma takes care of installation and integration, it will still be your responsibility to understand how it all fits together.
I realize that I am just scratching the surface here. This will be an iterative process for me. As I explore more, my perspective on what Kyma
is and
does will evolve.
I hope you came to similar conclusions as I have. If you have any feedback on my insights or want to share your own insights, I would love to hear from you!
See you in the
next post! ?