I was a windows guy at a large auction site and started bringing linux in to my workflows and solutions. I'd already been gaining personal experience with linux and the BSDs, solaris, etc. That was my last "windows job."
I'd say there's really no "linux roles" out there. Entry level or not. Everyone collectively decided "devops" was a big bright beautiful tomorrow and made devs learn release management and made ops people get lost (or become the developer they never wanted to be). Everyone shifted their focus towards "as code" solutions because the SRE book said nobody should log in to servers or something. So we hire people that know the abstractions instead and assume nobody really needs to go deeper than that.
It sucks, but learning the abstractions is how you're gonna have to get started. If you're already a linux nerd then you may benefit from understanding what the abstraction is doing under the hood.
If I was starting out right now, I'd go work through Kelsey Hightower's 'Kubernetes The Hard Way' and build functional kubernetes clusters from scratch on a couple of the cloud providers. Do not copy&paste anything from the blog. Every line, every command, by hand. Type out those CSRs and manifests! Recognize what each component you're setting up is and what it's used for. Like "what is the CCM and what's it responsible for?" Or "What's going on with every step of the kubelet bootstrapping process? What controllers are involved and what are they doing?" Read EVERYTHING under kubernetes.io/docs. Understand the relationships between all the primitives.
If you already have some linux, networking, and containers knowledge to build on top of, I think you could work through all of that in less than 4 weeks and have a better understanding of kubernetes than 80%+ of engineers at any level and crush a kubernetes focused interview.
Thanks but my point still stands: there's no entry-level roles, whether it's "Linux" or a Linux-based "DevOps" role. I'm actually working in a windows-based mostly-DevOps type role, but we use almost zero opensource tools and it's very Microsoft centric.
The closest Linux-y roles that I might have a shot at getting into are "cloud engineer" type roles, with a heavy emphasis on AWS - and I hate AWS with a passion (just as much as I hate Azure).
Regardless, the biggest issue is getting that interview call - now in the age of AI, people are faking their CVs and companies are getting flooded with hundreds or thousands of junk applications, so getting that interview call - especially when you don't meet their professional experience requirements - is next to impossible. I could have all the Kuberneres certs in the world, but what's the point if I get filtered out right at the first stage?
Start introducing it where you are. I was an early advocate for the use of WSL2/Docker and along with that a push towards deploying to Linux initially as a cost saving as projects started shifting away from .Net Framework and into .Net Core and Node that were actually easier to deploy to Linux... WSL/Docker became a natural fit as it was "closer to production" for the development workflow.
It's not always possible, but there are definitely selling points that can help you introduce these things. Hell, scripting out the onboarding chores from a clean windows install (powershell to bootstrap in windows, then bash, etc for the WSL environment) with only 3-4 manual steps... and you get a new dev onboarded in a couple hours with a fully working environment and software stack, including an initialized database... You can raise some eyebrows.
Do the same for automated deployments on your existing projects... shift the testing environments to Linux as a "test" or "experiment" ... you can eat away at both directions.
Before you know it, developers can choose windows or mac instead of one or the other, and can use whatever editor they like. Maybe still stuck with C# or MS-SQL, maybe PostgreSQL for green projects.
I'd say there's really no "linux roles" out there. Entry level or not. Everyone collectively decided "devops" was a big bright beautiful tomorrow and made devs learn release management and made ops people get lost (or become the developer they never wanted to be). Everyone shifted their focus towards "as code" solutions because the SRE book said nobody should log in to servers or something. So we hire people that know the abstractions instead and assume nobody really needs to go deeper than that.
It sucks, but learning the abstractions is how you're gonna have to get started. If you're already a linux nerd then you may benefit from understanding what the abstraction is doing under the hood.
If I was starting out right now, I'd go work through Kelsey Hightower's 'Kubernetes The Hard Way' and build functional kubernetes clusters from scratch on a couple of the cloud providers. Do not copy&paste anything from the blog. Every line, every command, by hand. Type out those CSRs and manifests! Recognize what each component you're setting up is and what it's used for. Like "what is the CCM and what's it responsible for?" Or "What's going on with every step of the kubelet bootstrapping process? What controllers are involved and what are they doing?" Read EVERYTHING under kubernetes.io/docs. Understand the relationships between all the primitives.
If you already have some linux, networking, and containers knowledge to build on top of, I think you could work through all of that in less than 4 weeks and have a better understanding of kubernetes than 80%+ of engineers at any level and crush a kubernetes focused interview.