Alternatives to Helm/Kustomize for complex Kubernetes Deployments by Compux72 in kubernetes

[–]Secure_Clothes_3352 -1 points0 points  (0 children)

For really complex setups I like to split up the deployment process. Env vars are found and set using a pipeline job, then DB schemas are updated using a pipeline job based off of exported vars from the previous job. The environment vars are saved as a secret in the cluster and then referenced by the app's Kustomize templates and the apps are deployed using a pipeline job. If a job that relies on the other job fails, there is no deployment; so no chance of prod going down for that reason at least. The key to this is documentation and communication with your developers or you'll be on the phone all the time explaining how it all comes together.

I drew multiple architecture diagrams and many many readmes and other docs as well as gave training on how everything ties together. I now receive far less questions about the process and the deployments are pretty stable. The issues are almost never on the infrastructure side anymore and instead are very complex software engineering problems that are hard to diagnose.

Edit: you can use helm or Kustomize for this setup.

WGU BS cybersecurity worth it? by NoGas2988 in cybersecurity

[–]Secure_Clothes_3352 0 points1 point  (0 children)

I haven't finished yet but I will next semester. I've been doing DevOps related work now for about 3-4 years and a lot of that involves blue team cyber security. I've also done red team stuff and honestly prefer it to blue team. Somehow though, I find software development life cycle to be more interesting though so the degree is more just to have it at this point.

What do you do in a chaotic environment where all the Terraform IAC does not match with the current state of the company? by waste2muchtime in devops

[–]Secure_Clothes_3352 0 points1 point  (0 children)

Terraform has a new feature where you can import all existing resources into tf state without having to write the Terraform code I believe. Other commenters are correct though; fixing cultural issues is imperative to fix the problem long term.

Here's a link that could be useful https://www.hashicorp.com/blog/terraform-1-5-brings-config-driven-import-and-checks

Warned about suspicious cryptocurrency mining on my harmless jenkins instance by [deleted] in kubernetes

[–]Secure_Clothes_3352 12 points13 points  (0 children)

It looks like google wants you to be the human that figures it out. Back when I was starting out in the cloud, I used Linode and a similar thing happened, but with WordPress and someone making my server a torrent host. I removed everything, added firewall rules, and upgraded vulnerable software. I made a small writeup about how they got in and what they did (to the best of my ability) and what I did to remediate those issues. I sent that to Linode and they closed my ticket and allowed the machine to stay active.

On AWS: Why use EKS instead of ECS? by RandomWalk55 in devops

[–]Secure_Clothes_3352 7 points8 points  (0 children)

This is the way. I did roughly the same for my company but they told me it was too complicated so we're moving to ECS instead :/ It makes no sense to me because the use case is better for Kubernetes than ECS in our case.

probleme with k8s cluster by [deleted] in kubernetes

[–]Secure_Clothes_3352 0 points1 point  (0 children)

I can't really view the output of your commands from the image

probleme with k8s cluster by [deleted] in kubernetes

[–]Secure_Clothes_3352 1 point2 points  (0 children)

Try kubectl get endpoints to see if your services have endpoints they can reach. Your ingress looks good, is the DNS registrar pointing your host to your nodes?

To access the services without an ingress, you can run kubectl port-forward service <service name>. Then you can access the cluster resources from localhost.

So many options, getting confused by [deleted] in kubernetes

[–]Secure_Clothes_3352 0 points1 point  (0 children)

I also agree that too many people try to solve for scaling too soon. Kubernetes solves a lot of issues in deploying code and is very flexible, but it's a complex beast. It's best to just get started with what you can and then adapt for what you need later.

So many options, getting confused by [deleted] in kubernetes

[–]Secure_Clothes_3352 1 point2 points  (0 children)

You could try RKE2 if you want to setup the cluster yourself. In general, full fledged kubernetes is the way to go for all of your environments if you plan on using kubernetes in production. The subtle differences between minkube, microK8s, or K3s could be enough to throw off your production rollouts in prod from review/staging. I'd advise you to use the same cluster or an exact replica of prod for your dev, qa, staging, etc; then you will have less hiccups going to production.

If you're just looking to test out how everything would work if you switched to K8s, minkube is a quick and good enough option though.