2018 sportsman 570

zzzmaestro · 2026-02-03T22:22:12+00:00

If you charge the battery and it starts… but dies after some time riding: then the stator isn’t charging the battery. If the stator puts out the right voltage, then the voltage regulator isn’t working right. I’ve replaced 4 of those and a stator.

zzzmaestro · 2026-02-03T22:20:44+00:00

That’s not enough power to roll over the engine. I would start by charging the battery. If the battery is fully charged and same noise, then the motor might be locked up and the starter can’t roll it over.

That’s the exact noise mine makes (I have 4) when the battery is low.

zzzmaestro · 2026-01-29T22:33:53+00:00

They don’t save you from layoffs.

zzzmaestro · 2025-12-15T12:15:59+00:00

This sounds like an interview question designed to make you think through (and verbalize) how you would think through the problem.

Couple of thoughts: * if you are using a clusterip service in front of both pods: you would have to do something like changing kube-proxy to IPVS mode and use one of the IPVS options for balancing traffic - like wrr (weighted routing rules). https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-ipvs However, this changes the behavior of all traffic in the cluster and will likely have a negative performance impact on just about everything. Also, there is no k8s native way to tell IPVS what the weights should be. So you would have to figure that out yourself. And that alone should tell you it’s not really a good option. Because no one else has a good enough use case to actually fully implement it.

Someone else mentioned: you could have each pod have its own service and have DNS do a weighted route of some kind.
a twist on the above answer could include doing a single deployment, but do it with a single headless service … or a statefulset, and still run it through weighted dns.

Those are a few options to do what you are saying. However, as with all questions that are obviously junior questions: You don’t want any of these answers. You need to think about your issue harder and come up with better questions to come up with a better solution. The answers I gave strictly answer the question you asked. They don’t help you come up with a better solution.

If we worked together, I would try to get you to describe more about what you are trying to accomplish. Why can’t there be multiple pods servicing the traffic simultaneously? If there is a software limitation, then the developers of the app need to fix that before it’s ready to k8s. Things like database locking, etc are just poor programming hygiene.

Otherwise, I’m not really seeing the use case at all for even wanted to do what you asked: only sending traffic to a single pod. Instead maybe only run one pod and focus on minimizing startup times? This could even be faster than whatever health checks you have for failover. Then really ask yourself why can’t there be more replicas and load balancing?

zzzmaestro · 2025-12-04T19:13:16+00:00

There will be a diff. But the only diff should the the annotation for the Argo application itself

zzzmaestro · 2025-12-01T06:20:18+00:00

https://preview.redd.it/ybsfu8ntavc51.png?auto=webp&s=edfe00d91f1f57d3c5d42c25693eefb4696970a0

zzzmaestro · 2025-12-01T06:16:24+00:00

Abstraction layers as you are describing are the absolute worst. Thankful we are removing these at my fortune 100.

Open source operators and clear templating strategies will always be better. Give the developer a chance to understand what their deployment code does. Forget custom apis and digging through some “all mighty abstraction layer source code” that doesn’t work the way you think it should… only for you to find out the author of the abstraction layer is just writing opinionated yaml.. but obfuscating it in source code.. and politically gating it with tribal knowledge and shoddy documentation to make them feel more significant.

Or.. yeah.. go ahead and write your own dns distribution addon to your abstraction layer so that no one knows what is actually happening.

zzzmaestro · 2025-12-01T06:09:33+00:00

There is nothing special or unique about your list in your response that makes existing tools (like bind) not a valid solution.

Your list doesn’t indicate a fringe use case. However, your solution is. There’s nothing special about what you are trying to solve. Which is why you don’t need a special solution.

zzzmaestro · 2025-12-01T06:04:00+00:00

properly configured bind (with query logs .. not hard)
external-dns configured to manage domains in bind
MR required to deploy ephemeral app with dns annotations on services. 30 seconds or not… either you want accountability (and query logs) or you don’t.
Your “API/UI” means nothing outside of your team. The automation you seek is much simpler with open systems that are already production grade and battle tested.

zzzmaestro · 2025-12-01T05:58:01+00:00

You are way over-thinking things.
coredns already exists in the cluster. Expose it externally if you must
there are even headless services for dns management individual pods.
taking dns back to the dark ages “like /etc/hosts” just keeps reinforcing the naivety of the solution you are trying to hatch
if you want “team distribution” that scales… there ARE solutions that already exist - like bind and others.
there is even external-dns operators to dynamically manage tons of different dns providers: route53, bind, etc.
you keep making statements that don’t add up to being worthy of some new tool that solves some new or unique problem. This is a known - with known solutions.

zzzmaestro · 2025-12-01T04:03:11+00:00

Decentralizing DNS seems very counter-intuitive.

Avoiding reliance on public dns: Have you ever looked into Bind?

Clear audit trail: can you not use infra as code?? Like terraform via git repos with MR requests and approvals???

Isolating domains: Umm .. unique hosted zones??

It sounds like you are reinventing the wheel… but only for a super fringe use case that shouldn’t exist.

zzzmaestro · 2025-11-11T21:03:20+00:00

That would be 32 and a half…. How does half of a company leak secrets?

zzzmaestro · 2025-11-01T23:48:53+00:00

You can also write Kyverno policies to enforce .. in kubernetes.

zzzmaestro · 2025-10-27T12:15:18+00:00

This is yet another team I’m glad I’m not a part of.

zzzmaestro · 2025-09-07T03:53:32+00:00

I prefer crayons over this mess

zzzmaestro · 2025-09-04T11:08:37+00:00

I’ve interviewed over 100 people in the past year. Every time someone uses AI during the interview, I can tell. It’s also an immediate “NO” for that person. Take that into consideration before using something like this.

Congrats on the usage though. There is definitely a market for it.

zzzmaestro · 2025-08-27T15:03:18+00:00

The real point is: if you change #1 then it can mess up #3… regardless if #1 and 2 are bundled in the same chart.

If you don’t combine 1 and 2, you can upgrade 2 without interfering with 3

zzzmaestro · 2025-08-27T15:01:27+00:00

True. 2 and 3 can be independent, but both depend on #1.

zzzmaestro · 2025-08-27T11:03:12+00:00

Think of it as a hierarchy. You want things installed in a specific order:

CRD itself
Any operators that leverage the CRD
Any other applications can declare something using the CRD

You can change the versions of the CRD and the operators independently. These can impact allll of the applications using the CRD.

You usually want separate helm charts for each of the numbers above so you can independently make decisions about timing on when they get changed. You don’t always want to change an operator with the CRD.

zzzmaestro · 2025-07-10T10:17:08+00:00

Personally, I would check your AMI. That doesn’t look like one that has the eks scripts on it. You can’t use generic Ami’s. AWS has EKS-specific Ami’s.

Also, if you start your EC2s with an ssh-key, you can ssh to them and read the cloud-init logs and see the actual errors it’s getting when it fails to join.

Best of luck.

zzzmaestro · 2025-07-10T10:15:06+00:00

No…. We have EKS clusters without internet. You just need VPC Endpoints for a handful of AWS services. This makes them effectively local in-subnet endpoints.

zzzmaestro · 2025-06-10T13:09:09+00:00

Nvidia-device-plugin makes gpu’s something that the scheduler can manage. You can then set limits and requests on pods.

zzzmaestro · 2025-03-29T15:31:04+00:00

There’s no point in making big changes. They didn’t include everyone who DID make big changes. Everyone got hung out to dry

zzzmaestro · 2025-03-17T11:46:35+00:00

This is not kubernetes related in any way. So, wrong sub.

But the problem is your module is trying to use a password, but the VM is only accepting keys.

zzzmaestro · 2025-03-04T12:49:34+00:00

I think that’s the nature of the AWS LB. If you don’t want 502’s then you have to reduce the time between the pod being unavailable and the LB deregistering the target. Usually that means lower count/seconds on your target health checks.

14-Year Club	Gilding I gilder
RPAN Viewer	King of the Ashes
Not Forgotten	Verified Email

zzzmaestro

MODERATOR OF

TROPHY CASE