Previously we have been successful on creating our first Spring boot Application powered by Apache Ignite.
On this blog we shall focus on what is needed to be done on the Kubernetes side in order to be able to spin up our application.
As described on a previous blog we need to have our Kubernetes RBAC policies in place.
We need a role, a service account and the binding.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: job-cache rules: - apiGroups: - "" resources: - pods - endpoints verbs: - get - list - watch --- apiVersion: v1 kind: ServiceAccount metadata: name: job-cache --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: creationTimestamp: 2020-03-07T22:23:50Z name: job-cache roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: job-cache subjects: - kind: ServiceAccount name: job-cache namespace: "default"
Our service account will be the job cache. This means that we should use the job-cache service account for our Ignite based workloads.
The next step is to create the deployment. The configuration would not be very different from statefulset as explained in a previous post.
apiVersion: apps/v1 kind: Deployment metadata: name: job-api-deployment labels: app: job-api spec: replicas: 2 selector: matchLabels: app: job-api template: metadata: labels: app: job-api spec: containers: - name: job-api image: job-api:1.0 env: - name: IGNITE_QUIET value: "false" - name: IGNITE_CACHE_CLIENT value: "false" ports: - containerPort: 11211 protocol: TCP - containerPort: 47100 protocol: TCP - containerPort: 47500 protocol: TCP - containerPort: 49112 protocol: TCP - containerPort: 10800 protocol: TCP - containerPort: 8080 protocol: TCP - containerPort: 10900 protocol: TCP serviceAccount: job-cache serviceAccountName: job-cache
This is simpler since the Ignite configuration has been done through Java code.
The image that you see is supposed to be your dockerised Java application we worked before.
The next big step is to define the service. I will not use one service for all. Instead I would create a service for the cache and a service for our api in order to be used as an api.
apiVersion: v1 kind: Service metadata: labels: app: job-cache name: job-cache spec: ports: - name: jdbc port: 11211 protocol: TCP targetPort: 11211 - name: spi-communication port: 47100 protocol: TCP targetPort: 47100 - name: spi-discovery port: 47500 protocol: TCP targetPort: 47500 - name: jmx port: 49112 protocol: TCP targetPort: 49112 - name: sql port: 10800 protocol: TCP targetPort: 10800 - name: rest port: 8080 protocol: TCP targetPort: 8080 - name: thin-clients port: 10900 protocol: TCP targetPort: 10900 selector: app: job-api type: ClusterIP
Without getting into kubernetes details, the Ignite nodes shall synchronize using the job-cache internal dns. So we shall use kubernetes internal dns capabilities to communicate with the Ignite cluster.
The next step is to create the service for the actual job api application.
apiVersion: v1 kind: Service metadata: labels: app: job-api name: job-api spec: ports: - name: rest-api port: 80 protocol: TCP targetPort: 8080 selector: app: job-api sessionAffinity: None type: ClusterIP
Οn the following blog we shall apply our configurations to kubernetes and test our codebase.