{"data":{"markdownRemark":{"html":"

Note the following example makes usage of the Azure instance of Kubernetes; however if you follow the instructions below the process is as standard as creating a Docker image more here and using that for deployment.

\n

Deploying using ACS (Different from ACS-Engine)

\n

Before you Begin

\n

While the methods to do this are possible via the Azure Portal - the below setup makes usage of Powershell. Make sure that you have the Azure CLI and the Kubernetes CLI installed.

\n

Azure CLI - https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest

\n

Kubernetes CLI - Run \"az acs kubernetes install-cli\"

\n

From Powershell make sure you are both logged into the Azure subscription, and Docker hub

\n

Login-AzureRmAccount

\n

docker login

\n

Then you will need to publish your Docker image to a repo see here for more info You can do this either directly through docker hub, or the steps below.

\n

Working with Docker

\n

After running mvn -s settings.xml clean package docker:build you will have created in the target/docker folder your properties file, and the computed jar. (Update this Pom.xml to include the webapp directory for the splash/demo console, or just update the generated Dockerfile directly.

\n

The Dockerfile will look like this.

\n
FROM simudyne/scala-sbt:2.12.12.1.0.4\nADD /simudyneSDK.properties //\nADD /simudyne-demos-1.0-SNAPSHOT-all.jar //\nENTRYPOINT ["java", "-jar", "/simudyne-demos-1.0-SNAPSHOT-allinone.jar"]
\n

(Optional) Working with a Container Registry

\n

Below we'll first create the Azure Container Registry (ACR). Again substitute the Resource Group name, and you'll also want to choose an ACR name. Once logged in you will query to find the ACR login server name which is where you will tag and push your repo.

\n

Then similar to pushing to the docker hub you can tag, and then push your image.

\n

az acr create --resource-group <myResourceGroup> --name <acrName> --sku Basic az acr login --name <acrName> az acr list --resource-group <myResourceGroup> --query "[].{acrLoginServer:loginServer}" --output table docker tag simudyne-demos-2.0.0-beta.2 <acrLoginServer>/simu-repo:demos docker push <acrLoginServer>/simu-repo:demos

\n

Setup Resource and Cluster

\n
    \n
  1. \n

    First create a resource group changing myResourceGroup, and possibly location as needed. You can freely do this via the portal if you want.

    \n
    2. \n
  2. \n

    Then we actually create the cluster, this automatically create 3 worker/agent nodes. It will take a bit of time, so go grab a coffee or something.

    \n
    3. \n
  3. \n

    We'll then merge the cluster into our context in order to make commands via the kubectl. (as an FYI you can make a copy/bat to shorten this to 'kc')

    \n
    4. \n
  4. \n

    We'll first check the nodes using the --watch or -w command. This will override the screen (Ctrl-C) to exist but will automatically update with changes.

    \n
    5. \n
  5. \n

    We then create the deployment as specified in the yml.

    \n
    6. \n
  6. \n

    Check the pod to make sure the deployment is live.

    \n
    7. \n
  7. \n

    Then we'll expose the deployment as a service. (This is different than creating a service via yml)

    \n
    8. \n
\n

az group create --name simudyne-demos --location westeurope\naz acs create --orchestrator-type kubernetes --resource-group simudyne-demos --name myK8SCluster --generate-ssh-keys\naz acs kubernetes get-credentials --resource-group simudyne-demos --name myK8SCluster\nkc get nodes -w\nkc create -f .\\dockerdemo.yml\nkc get pods -w kc expose deployments/docker-demo --port=8080

\n

Working with Ingress/Nginx

\n
    \n
  1. \n

    Once installed, you'll first want to initialize Helm

    \n
    2. \n
  2. \n

    Than you'll install the controller.

    \n
    3. \n
  3. \n

    Check that's installed by using the list command

    \n
    4. \n
  4. \n

    (Optional) If you are not using a cert as provided by an App Service Certificate (exporting the key/crt from the pfx) you will want to install and work with a Let's Encrypt cert which will be automatically generated for you.

    \n
    5. \n
  5. \n

    For our purposes though we already have a wildcard certificate and just need to create the secret that will be used by the TLS section of the yml

    \n
    6. \n
  6. \n

    Finally we check the services and wait for the public ip to show. (will start as ). Take note you should ONLY see a single IP exposed through the Nginx controller. This is because by exposing the application as we did above instead of via a different load balancer or server we've enabled the TLS to handle through Nginx instead of our application.

    \n
    7. \n
\n

helm init --upgrade\nhelm install stable/nginx-ingress\nhelm list\nhelm install --set config.LEGO_EMAIL=yourname@email.com --set config.LEGO_URL=https://acme-v01.api.letsencrypt.org/directory stable/kube-lego\nkc create secret tls custom-tls-cert --key .\\Certs\\certificate.key --cert .\\Certs\\certificate.crt\nkc create -f .\\demosimudyne.yml\nkc get svc -w

\n

Then Update DNS to point to the IP address exposed by the Ingress Controller. Note that ONLY the Ingress Controller (as a Load Balancer) should show a public IP. This is because rather than deploying the application under it's own Load Balancer which requires us to server SSL Traffic, we are using Ingress to properly route that to the app at port 8080 instead.

\n
apiVersion: extensions/v1beta1\nkind: Ingress\nmetadata:\n    annotations:\n      kubernetes.io/ingress.class: nginx\n      kubernetes.io/tls-acme: "true"\n      nginx.ingress.kubernetes.io/affinity: "cookie"\n      nginx.ingress.kubernetes.io/session-cookie-name: "route"\n      nginx.ingress.kubernetes.io/session-cookie-hash: "sha1"\n    name: ingress\nspec:\n    rules:\n      - host: demo.simudyne.com\n        http:\n          paths:\n            - path: /\n              backend:\n                serviceName: docker-demo\n                servicePort: 8080\n               \n    tls:\n        - hosts:\n            - demo.simudyne.com\n          secretName: custome-tls-cert
\n

Setting up Auto-scaling

\n

Now that will create a pod across the 3 nodes, but if you want more replicas there are 2 commands you can employ.

\n

The first \"kubectl scale\" allows you to choose a deployment, and assign how many replicas you want. That's not ideal though.

\n

Instead you should use autoscale, set a parameter (this case cpu % = 50) and a min and max # of pods. 3 pods is the common minimum and really you should keep it to that. Note this autoscales the pods only NOT THE ACTUAL MACHINES. To do that you'd need to go into the Container Service on the Azure Portal and increase the node count.

\n

Alternatively you can do this via Powershell following the below step to specify a new agent count.

\n

kubectl scale --replicas=5 deployment/docker-demo

\n

kubectl autoscale deployment docker-demo --cpu-percent=50 --min=3 --max=10

\n

az acs scale --resource-group=myResourceGroup --name=myK8SCluster --new-agent-count 4

\n

Note: If you are autoscaling - you will need to configure the load balancer to have Session Persistence - this is done by going to the Load Balancer you created as part of your deployment. This means that if you change the setup, or have to redeploy the configuration you will need to configure the Load Balancer again. Select \"Client IP\"

\n

Also make sure that you have the nginx-ingress affinity sections in your YAML as otherwise when working with our simulations you won't get a sticky session.

\n

Adding Operations Management Suite (OMS)

\n

This is an additional tool that is mainly for monitoring you K8s cluster, and can be quite helpful to determine if you're getting a lot of errors, whether there's an undue load, etc.

\n

First you'll actually want to create a service for analytics on Azure, this will give you the workspace ID and Key that you'll need to update below.

\n

Create and give it a name, once complete you'll see a screen like the below.

\n

From there click 'Advanced Settings' and go to the Linux Server connections

\n

Use these values to update the below myWorkspaceID and myWorkspaceKey

\n
apiVersion: extensions/v1beta1\nkind: DaemonSet\nmetadata:\n name: omsagent\nspec:\n template:\n  metadata:\n   labels:\n    app: omsagent\n    agentVersion: v1.3.4-127\n    dockerProviderVersion: 10.0.0-25\n  spec:\n   containers:\n     - name: omsagent\n       image: "microsoft/oms"\n       imagePullPolicy: Always\n       env:\n       - name: WSID\n         value: myWorkspaceID\n       - name: KEY\n         value: myWorkspaceKey\n       - name: DOMAIN\n         value: opinsights.azure.com\n       securityContext:\n         privileged: true\n       ports:\n       - containerPort: 25225\n         protocol: TCP\n       - containerPort: 25224\n         protocol: UDP\n       volumeMounts:\n        - mountPath: /var/run/docker.sock\n          name: docker-sock\n        - mountPath: /var/log\n          name: host-log\n       livenessProbe:\n        exec:\n         command:\n         - /bin/bash\n         - -c\n         - ps -ef | grep omsagent | grep -v "grep"\n        initialDelaySeconds: 60\n        periodSeconds: 60\n   volumes:\n    - name: docker-sock\n      hostPath:\n       path: /var/run/docker.sock\n    - name: host-log\n      hostPath:\n       path: /var/log
\n

From here create the daemonset by running the below command, using the traditional and watch to wait until it's available. To view the portal click \"OMS Portal\" in the above image from the Log Analytics

\n

kubectl create -f oms-daemonset.yaml\nkubectl get daemonset

\n

After a few minutes this portal should populate with a wealth of data.

\n

Steps to Update with New Release

\n

az acs kubernetes get-credentials --resource-group simudyne-demos --name myK8SCluster kc set image deployment docker-demo docker-demo=simudyne/docker-demo:alpha1 kc get pods -w

\n

Working with AKS (Preview)

\n

There are a few changes you will need to do in order to instead work with AKS (Preview)

\n
    \n
  1. \n

    First we need to register with the provider so we can use the Preview

    \n
    2. \n
  2. \n

    We create a resource group same as before.

    \n
    3. \n
  3. \n

    Very little change here for creating the cluster and merging into the context. It's simply changing to aks.

    \n
    4. \n
  4. \n

    Then we'll want to make sure (especially for below custom metrics) we'll need to upgrade Kubernetes. To do this we first will get possible upgrades

    \n
    5. \n
  5. \n

    Then we'll apply the upgrade (this will take a while)

    \n
    6. \n
  6. \n

    Finally we can show that the upgrade to the cluster has processed.

    \n
    7. \n
\n

az provider register -n Microsoft.Network az provider register -n Microsoft.Storage az provider register -n Microsoft.Compute az provider register -n Microsoft.ContainerService

\n

az group create --name myResourceGroup --location westeurope az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 1 --generate-ssh-keys az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

\n

az aks get-upgrades --name myAKSCluster --resource-group myResourceGroup --output table az aks upgrade --name myAKSCluster --resource-group myResourceGroup --kubernetes-version 1.8.7 az aks show --name myAKSCluster --resource-group myResourceGroup --output table

\n

The other change you'll now be able to do is custom metrics for HPA, including memory utilization built in. You'll need to make changes to the resources in your application YAML, and instead of using the autoscale fature you'll deploy the HPA via a new YAML.

\n
resources:\n  requests:\n    memory: "128Mi"\n    cpu: 250m\n  limits:\n    memory: "2Gi"\n    cpu: 750m
\n

Below is the hpa.yml

\n
apiVersion: autoscaling/v2beta1\nkind: HorizontalPodAutoscaler\nmetadata:\n  name: docker-demo\nspec:\n  scaleTargetRef:\n    apiVersion: extensions/v1beta1\n    kind: Deployment\n    name: docker-demo\n  minReplicas: 2\n  maxReplicas: 10\n  metrics:\n  - type: Resource\n    resource:\n      name: cpu\n      targetAverageUtilization: 80\n  - type: Resource\n    resource:\n      name: memory\n      targetAverageValue: 1Gi
","headings":[{"value":"Deploying using ACS (Different from ACS-Engine)","depth":2},{"value":"Before you Begin","depth":3},{"value":"Working with Docker","depth":2},{"value":"(Optional) Working with a Container Registry","depth":2},{"value":"Setup Resource and Cluster","depth":2},{"value":"Working with Ingress/Nginx","depth":2},{"value":"Setting up Auto-scaling","depth":2},{"value":"Adding Operations Management Suite (OMS)","depth":2},{"value":"Steps to Update with New Release","depth":2},{"value":"Working with AKS (Preview)","depth":2}],"frontmatter":{"title":"Deploying via Kubernetes","toc":null,"experimental":null}},"site":{"siteMetadata":{"title":"Simudyne Docs","latestVersion":"2.6"}}},"pageContext":{"absolutePath":"/home/vsts/work/1/s/content/2.5/reference/run_deploy/kubernetes.md","versioned":true,"version":"2.5","kind":"reference","pagePath":"/reference/run_deploy/kubernetes","chronology":{"prev":{"name":"Deploying via Docker","path":"/reference/run_deploy/docker"},"next":{"name":"Deploying on Azure Web Services","path":"/reference/run_deploy/azure"}},"lastUpdated":"2026-04-21T13:56:54.862Z"}}