Vanilla Kubernetes

Last modified 14 Nov 2024 01:15 +01:00
Table of Contents

This page describes to the midPoint in container context of documentation. This chapter will focus on the vanilla kubernetes.

You may be interested in :

  • common container related information
    Possibilities of customization of the installation.

  • docker related information
    Sample configuration related to the docker environment.

Deployment

In this chapter you will firstly find the scheme of different deployment types and description of used components. Handling of each deployment type is discussed in following paragraphs.

Basic deployment

kubernetes diagram
Figure 1. Basic deployment in kubernetes

To start the environment, we need several objects. We can group them by the type / purpose:

  • StatefulSet
    Control objects, which provide template for the pods including the scale - amount of requested instance.

  • Service
    "Meeting point" for the use case - internal transparent proxy for communication. As pods has dynamic IPs the IP addresses are assigned after pod creation. The name of service is known in advance. It can be used for the connection (e.g. midPoint contacts the repository using service definition).

  • Ingress
    Entry point for the user. It is reverse proxy - first point of contact for the communication from outside on shared ports (http - TCP/80, https - TCP/443). Once the definition matches, the communication is passed to the defined service.

  • Pod
    The pods is not defined directly in this deployment. It is a result of the statefulSet definition.

    Technically, it is the place where the application is running. The other objects are about to create the pod with proper configuration and make it reachable.

Simple deployment with PVC and secret

kubernetes diagram pvc secret
Figure 2. Simple deployment with PVC and secret in kubernetes

This diagram extends the Basic one with two objects.

  • Persistent Volume Claim (PVC)
    To keep data persistent over the container re-creation we need external storage space. In this scenario, the PVC is created based on the template located in statefulset. In case of scaling each pod will have its own PVC.

  • Secret
    Object for keeping sensitive information for the use with the Pod(s). It targets the situation of shared password (e.g. to access the DB we need to "share" the credentials between the DB server and the client connecting into it).

Advanced deployment

kubernetes diagram advanced
Figure 3. Advanced deployment

This diagram extends the Simple one with following objects:

  • Persistent Volume Claim (PVC)
    To keep data persistent over the container re-creation we need external storage space. In this scenario the PVC is created based on the PVC definition. In case of scaling all the pods will share the same PVC.

  • ConfigMap
    The object which can keep the content used as environment variable or it can be mounted to the pod’s filesystem.

Working with deployment

Prepared object definition

We have prepared the definition for you. It is located in our github repository (download ZIP).

For the next steps you need to have the content available locally. One of the option is to use the link pointing to the ZIP file and unzip it.

The commands mentioned here suppose to be run in the terminal / command line.

kubectl is used to communicate with kubernetes cluster. It is supposed you have working setting allowing you to connect, authenticate and communicate with the kubernetes cluster.

To test you can try to request list of nodes in the cluster : kubectl get nodes.

In case you face any issue with kubectl, please refer to kubernetes documentation how to make it work.
Ingress related notes

All the objects except ingress definition can be used as they are.

Location of the ingress definition is 301_ingress.yaml.

In regards to Ingress definition few topics, before applying the files, should be addressed.

  • ingressClassName
    In the definition the presence of nginx is expected. In case you have nginx ingress in the kubernetes environment available you are ok with the value prepared in the file. If not, this option has to be updated to correspond with your kubernetes environment setting.

  • tls
    The default certificate for https will be used. In case you want to use different one, it should be explicitly set in the ingress definition.

  • host
    The host midpoint.example.com is set in the definition file. To make it work you should make this value resolvable - to be able to get IP address. Here are some options how to reach it ( any of them should be sufficient ) :

    • change the value (FQDN) to something else what is under your control

    • set the record to /etc/hosts file (C:\Windows\System32\drivers\etc\hosts in case of windows)

    • set the static record on your local DNS resolver

The environment will be available with following information:

Table 1. Access information

URL:

https://midpoint.example.com (1)

Username:

administrator

Initial password:

Test5ecr3t (2)

  1. on the kubernetes site the FQDN is set using ingress object

  2. The init password is generated by default.

    • In the basic and seimple deployment the password is set in the statefulset definition for midpoint to be this value.
      MP_SET_midpoint_administrator_initialPassword=Test5ecr3t

    • In Advanced deployment there is dedicated secret object with the initial password (see Advanced deployment handling )

Basic deployment handling

For the Basic deployment the the path ./deployment/basic is important.

The basic environment store all data in dynamic (non-persistent) store. In case of pod removing all the related data is deleted.

Please note that it is not possible to partially restart the environment in this scenario. In case you restart DB your repository is lost. In case you restart midPoint the key to access encrypted data in repository is lost.

This configuration is good for quick testing, demo, etc.

Before applying the configuration files, please check Ingress related notes to correspond with your environment.

Apply the configuration to create the midpoint environment
kubectl apply -f ./deployment/basic
output from the apply command

namespace/midpoint-deployment created
service/midpoint-repository created
service/midpoint created
ingress.networking.k8s.io/midpoint created
statefulset.apps/midpoint-repository created
statefulset.apps/midpoint created

Delete the objects related to the midpoint environment
kubectl delete -f ./deployment/basic
output from the delete command

statefulset.apps "midpoint-repository" deleted
statefulset.apps "midpoint" deleted
service "midpoint-repository" deleted
service "midpoint" deleted
ingress.networking.k8s.io "midpoint" deleted
namespace "midpoint-deployment" deleted

The objects are prepared to use their own namespace - logical group of the objects. In the provided files it is creating and using the namespace called midpoint-deployment.

Once the environment is created it takes several seconds to get it up and running. First run can take longer as the image has to be downloaded from public registry - docker hub.

For the information how to access the environment please see Access information

Simple deployment with PVC and secret handling

This deployment extend Basic deployment handling information.

For the Simple deployment with PVC and secret the the path ./deployment/simple is important.

The repository data and midpoint home data are stored on Persistent Volume Claim. It is kept even in case the Pod is removed - it is not removed with the statefulset definition.

On the other side in case of test(s) the data in the environment from the previous run(s) may be present.

Please note that even it is dedicated object(s) it is still part of namespace. In case we are removing namespace all member objects are removed even it is not directly addressed. This statement also covers PVC in the namespace.

Before applying the configuration files please check Ingress related notes to correspond with your environment.

No PVC is explicitly defined. The definition is "hidden" in the statefulset where the section volumeClaimTemplates is. If you prefer to use different size of volume you can change the definition in relevant statefulset before applying the files.

Table 2. Volume sizing in the provided yaml definitions
Pod’s name Volume size

midPoint

128 MB

repository

5 GB

The PVC is created based on the template value with the first run. In case the PVC already exists it is directly used (e.g. re-create the pod).

Apply the configuration to create the midpoint environment
kubectl apply -f ./deployment/common/001_namespace.yaml -f ./deployment/simple
output from the apply command

namespace/midpoint-deployment created
service/midpoint-repository created
service/midpoint created
ingress.networking.k8s.io/midpoint created
secret/midpoint-repository created
statefulset.apps/midpoint-repository created
statefulset.apps/midpoint created

Once you want to remove the objects from the kubernetes environment you can decide if custom data (repository data and midPoint home directory) should also be removed. With the following command you can remove the defined objects keeping namespace and PVC (custom data) for future use.

Delete the objects related to the midpoint environment (keeping PVC)
kubectl delete -f ./deployment/simple
output from the delete command

statefulset.apps "midpoint" deleted
secret "midpoint-repository" deleted
statefulset.apps "midpoint-repository" deleted
service "midpoint-repository" deleted
service "midpoint" deleted
ingress.networking.k8s.io "midpoint" deleted

If you want to completely remove all related data to the midPoint environment it is possible to simply delete the namespace. All the related objects are members of namespace. This also includes indirectly created PVC (we just define template in statefulset and not directly the PVC).

Once the namespace is requested to be deleted, all related objects are removed in cascade.

Delete all the objects related to the midpoint environment (including namespace and PVC)
kubectl delete -f ./deployment/common/001_namespace.yaml
output from the delete command

namespace "midpoint-deployment" deleted

For the information how to access the environment please see <<#accessInfo>

Advanced deployment handling

This deployment extend Simple deployment with PVC and secret handling information.

For the Advanced deployment the the path ./deployment/advanced is important.

Before applying the configuration files please check Ingress related notes to correspond with your environment.

All the prepared objects will be member of the namespace - logical group of objects. We have to create it before any other objects, otherwise an error related to the unknown namespace. The definition is available in common directory.

The definition of the persistent Volume Claim (PVC) is also available. You can find it in common directory.

Create the namespace and PVC for the midPoint environment
kubectl apply -f ./deployment/common
output from the apply command

namespace/midpoint-deployment created
persistentvolumeclaim/midpoint created

There is no default administrator password. We can set the init password by the environment variable. The definition is prepared to use secret object midPoint-init-pass with the key passwd. The object should be created before the midPoint pod will be started. To create the object run the following command - the password can be changed before the command is executed.

Create secret object with the initial midPoint password
kubectl create -n midpoint-deployment secret generic midpoint-init-pass --from-literal=passwd=Test5ecr3t
output from the create command

secret/midpoint-init-pass created

Create configMap with the post-initial-objects (content from the directory)
kubectl create configmap -n midpoint-deployment post-initial-objects --from-file=deployment/post-initial-objects/
output from the create command

configmap/post-initial-objects created

The size of object is limited. In case the limit is reached, one of the solutions is to combine more of them.

Usage of single configMap:
spec:
  volumes:
    - name: midpoint-pio
      configMap:
        name: post-initial-objects
Combining more objects:
spec:
  volumes:
    - name: midpoint-pio
      projected:
        sources:
          - configMap:
              name: post-initial-objects-1
          - configMap:
              name: post-initial-objects-2

At this point we are ready to apply the rest of the files.

Apply the rest of the environment
kubectl apply -f ./deployment/advanced
output from the apply command

secret/midpoint-repository created
service/midpoint-repository created
service/midpoint created
ingress.networking.k8s.io/midpoint created
statefulset.apps/midpoint-repository created
statefulset.apps/midpoint created

To shutdown the environment you have 2 options.

  • scale the replicas to 0
    Scaling down keeps all the definition in place. The statefulset as control object is instructed to create 0 replicas - shutdown all running pods.

    This way we can e.g. selectively shutdown midPoint instances but keeping repository up for maintenance.

    Scale midPoint instances to 0 replica
    kubectl scale -n midpoint-deployment --replicas=0 sts/midpoint
    Scale midPoint instances to 1 replica
    kubectl scale -n midpoint-deployment --replicas=1 sts/midpoint
    output from the scale command

    statefulset.apps/midpoint scaled

    If there is more than one replica, you will need to configure midPoint in cluster configuration. The provided configuration is midPoint cluster ready. The relevant settings are related to :

    • taskManager
      The task manager has to get information that there can also be other active nodes.

    • intra-cluster URL
      Node ID value source has to be set.

    The dedicated doc page is available - Clustering / high availability setup.

    Please note that cluster setup in production deployment require the active subscription.

  • remove the object definition from kubernetes

In order to remove all objects except Persistent volume claims (PVC) and manually created objects (initial password /secret/ and post-initial-objects /configMap/) you can use available definition to select the objects to be removed.

Partially delete the midPoint environment
kubectl delete -f ./deployment/advanced
output from the delete command

secret "midpoint-repository" deleted
service "midpoint-repository" deleted
service "midpoint" deleted
ingress.networking.k8s.io "midpoint" deleted
statefulset.apps "midpoint-repository" deleted
statefulset.apps "midpoint" deleted

To remove all the objects including user data (volumes, secret with init password and configMap with Post-initial-objects) the whole namespace can be removed. The kubernetes will afterwards remove all the objects located in the namespace.

Delete the namespace with the midPoint environment - cascade clean up
kubectl delete -f ./deployment/common/001_namespace.yaml
output from the delete command

namespace "midpoint-deployment" deleted

Additional information

Keystore

Keystore contain the key needed to access sensitive information in the repository. In case you would "lost" the key on midPoint site the system will start but there will be some operation which may fail. Example is connection to the resource (the credentials is not available), user log in.

To make it persistent over the restart or share it between the more pods we need to have it stored out of pod with midpoint.

  • PVC
    Handling the content inside the pod(s).

    • Can be defined by template and created for pod (see Simple deployment with PVC and secret handling). In this case only permanency is covered. Not suitable in case od cluster deployment.

    • Cen be explicitly defined and linked from pod definition (see Advanced deployment handling ). This way both permanency and sharing requirement are covered.

      subset of configuration related to the PVC mount into the midPoint pod as home directory 
        volumes:
    - name: midpoint-home
      persistentVolumeClaim:
        claimName: midpoint-home
  containers:
    volumeMounts:
      - name: midpoint-home
        mountPath: /opt/midpoint/var/
      subset of configuration related to the dedicated PVC with keystore mount into the midPoint pod 
        volumes:
    - name: secret-vol
      persistentVolumeClaim:
        claimName: midpoint-keystore
  containers:
    env:
      - name: MP_SET_midpoint_keystore_keystorePath
        value: /opt/secret-volume/keystore.jceks
    volumeMounts:
      - name: secret-vol
        mountPath: /opt/secret-volume

  • Secret
    Can be updated only "externally" using kubernetes tools - no update from inside the pod is possible. Pod has it mounted into the filesystem in read-only mode. This approach cover both permanency and sharing requirements between the pods.

    create secret secret-volume containing keystore.jceks file
    kubectl create -n midpoint-deployment secret generic secret-volume --from-file=keystore.jceks
    sample of the secret with the keystore 
    apiVersion: v1
kind: Secret
metadata:
  name: secret-volume
  namespace: midpoint-deployment
data:
  keystore.jceks: <base64 encoded content>
    subset of configuration related to the secret mount into the midPoint pod 
      volumes:
    - name: secret-vol
      secret:
        secretName: secret-volume
  containers:
    env:
      - name: MP_SET_midpoint_keystore_keystorePath
        value: /opt/secret-volume/keystore.jceks
    volumeMounts:
      - name: secret-vol
        mountPath: /opt/secret-volume

See also:

Certificate for the resource connection

In case of secured connection to other systems we need to have stored trusted certificate in the trust store. The keystore is used also as trust store by default.

There is available dedicated doc page for this topic - TLS Connections (Client Side).

Was this page helpful?
YES NO
Thanks for your feedback