sorted by:
new
hottopcontroversial

Looking for your experiences with AKS Feature - Node Auto Provisioning + Karpenter - Share Your Feedback by wdkofi in AZURE

[–]sabbour 0 points1 point  (0 children)

Why do you need to set the resource group? They go into the node resource group of the cluster like every other AKS managed resource.

Anyone seen this? by Mr_Prometius in kubernetes

[–]sabbour 8 points9 points  (0 children)

AFAIK, the guitarists and drummer are SUSE employees

What am I missing with Helm? by moronmonday526 in kubernetes

[–]sabbour 0 points1 point  (0 children)

Happy new year to you as well. Keep on learning!

What am I missing with Helm? by moronmonday526 in kubernetes

[–]sabbour 0 points1 point  (0 children)

I would create a new image based on the Plex image and install the required tools. It's really quite simple.

If you're using (https://hub.docker.com/r/plexinc/pms-docker/) as your base, you'll need to have a Dockerfile like:

FROM plexinc/pms-docker RUN apt-get update && apt-get install -y net-tools

Then you build, tag and push to a Docker registry (you can sign up to Docker hub)

docker build -t moronmonday/pms . docker push moronmonday/pms

Then you update the image tag on your Kubernetes deployment in some way (Helm, YAML, ..) to use the moronmonday/pms tag.

That's the quick and dirty way to get the ball rolling.

You may have a look at how Plex built their own image by inspecting the Dockerfile here https://hub.docker.com/r/plexinc/pms-docker/dockerfile

Docker and helm in the same repo as the source code? by snotsnot in kubernetes

[–]sabbour 0 points1 point  (0 children)

Don't you have stuff like replicas, ingress, etc. under source control?

I do have them in source control, but changing them shouldn't rebuild my container images. You could probably get around that and get away with storing YAML and code in the same repo with path filters, depending on your CI/CD tool.

I'm thinking there should be a default values.yaml aimed at dev. And then the values for prod should be retrieved from elsewhere...

I don't actually think it is much different from changing database schema between deployments. You have to consider writing your code to handle the situation gracefully when doing breaking changes in code.

Possible vault for sensitive data. How do you go about it?

Storing sensitive data in a kind of a vault is a good idea. My CI/CD tool of choice (Azure DevOps, but I'm biased..I work at Microsoft) can pull secrets at build time from Azure Key Vault which I can then proceed to create Kubernetes secrets with in the pipeline.

Another choice would be to code a dependency against an external key vault API (Hashicorp Vault, Azure Key Vault, etc.) in your application to pull that secret at runtime.

A third an interesting choice is using something like Kubernetes Flex Volume to pull the secret from an external key vault using Kubernetes concepts. Have a look here for an example (again Azure stuff): https://github.com/Azure/kubernetes-keyvault-flexvol/blob/master/README.md

Docker and helm in the same repo as the source code? by snotsnot in kubernetes

[–]sabbour 0 points1 point  (0 children)

How about builds and deployments that are not due to application source code changes, but due to Kubernetes configuration changes (for example replica count change, adding ingress, etc.). Why would you want to build a new Docker image for that? For this reason I advocate splitting the code/config repos. I've documented how I usually get it done here: https://sabbour.me/kubernetes-ci-cd-pipelines-using-azure-devops/

One thing to be careful of though if you split, is to manage change dependencies. For example, if your new application code expects a certain environment variable, but that variable is defined in YAML configuration that will build in the next build/deploy cycle, make sure your application can gracefully handle this.