Kubernetes Platforms Built and Run for Software Teams
Every team ships one way, and upgrades land on dates you approve. ITECS builds and runs Kubernetes platforms on EKS, AKS or your own hardware for software teams in Dallas-Fort Worth. The work is the cluster build, identity and access, one deploy path, upgrades on a calendar, cost per service, a security baseline and GPU node pools.
- Who it is for
- Engineering leads who run or plan a cluster
- What ITECS builds
- Clusters on AWS, Azure or your hardware, in code
- What ITECS runs
- Upgrades, node pools and platform add-ons
- Pricing
- Custom-scoped. The assessment gives you a written plan, the order of work and a quote for the first piece. How platform work is priced
- After launch
- Operated by ITECS, or by your team with runbooks
Scope
What ITECS builds into the cluster
The cluster lives in your AWS or Azure account or in your data center. ITECS changes it only through pull requests your engineers review.
- Cluster build
- EKS or AKS in the cloud where your identity and data already live, or Kubernetes on your own servers. Networks, node pools and add-ons are defined in code.
- Identity and access
- Workloads reach cloud services through workload identity instead of stored keys. People reach the cluster through your identity provider's groups, and only engineers you name can exec into a running container.
- One deploy path
- Every service ships through Argo CD or Flux, which applies what is merged to the deploy repository. You pick one of the two from the plan.
- Upgrades on a calendar
- The control plane, node pools and add-ons move one minor version at a time, staging before production. ITECS finds the removed APIs your manifests call, and the plan says who fixes each one before the upgrade date.
- Cost per service
- Requests and limits are set from measured use, and node pools are sized to the workloads on them. Spend is reported for each service.
- Security baseline
- Pod Security Standards are enforced on every application namespace and network policies deny traffic by default. An image policy admits only images from your registry.
- GPU node pools
- Where the plan calls for AI inference, model workloads run on their own GPU pool. Taints keep other workloads off it, and it scales apart from the rest.
Scenario
A self-built cluster that fell behind on upgrades
Illustrative planning scenario, not a reported client result or a named public case study.
- Starting point
- A software company runs its product on a Kubernetes cluster it built and patched itself, now several versions behind. Each team deploys its own way, from scripts to hand-applied manifests. Nobody can say what each service costs to run, and an AI feature waits for GPU nodes.
- Scoped outcome
- The company signs in with Microsoft Entra ID and keeps its data in Azure, so the plan moves the cluster to AKS. Every team ships through one Argo CD setup, and upgrades get dates and a staging run. Spend is reported by service. A GPU pool for the AI feature follows once the platform is stable.
Approach
How ITECS builds or takes over a cluster
Services that run more than one copy keep serving traffic while the platform changes under them. The plan names any that cannot, and you approve the downtime window for each one.
Read the cluster
ITECS reads your manifests, Helm charts, cloud bill and upgrade history, and lists the APIs your workloads call that newer versions remove. Without a cluster yet, it reads the services you plan to move.
Choose the platform
You choose the platform from the plan, which weighs the cloud your team already signs in to. If a cluster is the wrong call, the plan says so.
Build it in code
The cluster, node pools and platform services are built in your account through pull requests your engineers review, then tested on staging.
Move the first service
The first service moves on its own. Once it has shipped cleanly on the new deploy path, the others follow in the order the plan sets.
Operate or hand over
Under managed DevOps, ITECS runs the upgrades, node pools and add-ons. If your team takes the platform, it gets the runbooks and a walkthrough first.
Platform
What runs under your services
Your engineers work at the top. ITECS runs the hex layers, or your team does after handover, and each upgrade waits at the diamond until you approve its window.
Your services
Your engineers write and own the services. They ship a change by merging it, and every service lands on the same platform below.
Run by: Your engineers
Deploy path
A GitOps tool keeps the cluster in step with the deploy repository. A rollback is a revert, and the service owner or the on-call engineer decides when to make it.
- Git repository
- Argo CD or Flux
Run by: ITECS
Platform services
Ingress, workload identity, secrets from your vault and the hooks your monitoring reads. These add-ons are upgraded last in each window, after the node pools.
- Ingress
- Identity
- Secrets
- Observability
Run by: ITECS
Node pools
General pools are sized from measured requests, and a GPU pool runs model workloads where you need one. Their nodes are replaced right after the control plane.
- General pool
- GPU pool
Run by: ITECS
Cluster and control plane
EKS or AKS in your cloud account, or Kubernetes on your servers. Each upgrade starts here and moves one minor version, in staging first, inside a window you approve.
Run by: ITECS
You approve the window
Upgrade order: Cluster and control plane, Node pools, Platform services
Cloud account or hardware
Your AWS or Azure account, or servers in your data center. You own it and pay for it, and ITECS works inside it with the access you grant.
Run by: You
Hex: a layer ITECS runs. Diamond: the upgrade window you approve.
Deliverables
What stays with your team
- Code for the cluster, node pools and platform services, in your repositories.
- A deploy repository and the Argo CD or Flux setup every service uses.
- An upgrade calendar, and a runbook whose steps were proven on staging.
- Workload identity roles and cluster access rules, with the deny cases tested.
- A cost report for each service, with requests and limits set from measured use.
- A scope that names an owner on your team for every cluster, role and repository ITECS creates.
Where it fits
Where platform work fits
The assessment tells you whether you need a cluster. When you do, the pipeline that deploys to it often ships first.
- DevOps assessment
- Tells you whether a cluster is the right call, on which platform and which services move first, before ITECS quotes the build.
- DevOps services
- The hub for the work around a cluster: infrastructure as code, observability and managed DevOps.
- CI/CD pipelines
- The pipeline builds, tests and scans each image. The deploy path takes it from your registry into the cluster.
- Linux server support
- On your own hardware, ITECS's Linux practice on itecsonline.com can patch and support the operating system on each node.
- Managed Azure cloud
- AKS runs inside an Azure subscription and landing zone, and ITECS can run both through managed Azure on itecsonline.com.
- AI-assisted EKS migration assessment
- The ITECS guide shows how to give an AI-assisted assessment scoped read access to your code and verify each blocker it reports before a workload moves.
Pricing
How platform work is priced
The work is custom-scoped, and the quote depends on what the assessment finds in your clusters and accounts.
- Assessment
- Where every engagement starts. A call sets its scope and price, and you get a written plan that orders the work, with a quote for the first piece.
- What moves the quote
- How many clusters and environments you run, the node pools they need, and which services move onto the platform.
- Platform build
- Quoted once you approve the plan.
- Managed DevOps
- A retainer for the clusters ITECS operates, the upgrade calendar and after-hours cover: alerts are answered within the coverage in the retainer.
- Cloud and licenses
- Cloud usage, your hardware and any tool licenses stay client-paid unless a proposal states pass-through billing.
The published AI package prices do not cover Kubernetes work.
FAQ
Kubernetes platform FAQ
What do Kubernetes consulting services include?
Kubernetes consulting services plan, build and run the platform your services deploy to. ITECS covers the cluster build, identity and access, one deploy path, upgrades on a calendar, cost per service, a security baseline and GPU node pools. It works in your AWS or Azure account or on your own hardware, for teams in Dallas-Fort Worth and across the United States.
Do we need Kubernetes?
Not every product does. A handful of web services can run well on managed cloud services with a simple pipeline, and the assessment says so before ITECS quotes a cluster. A cluster earns its keep when many services deploy often, scale on their own or need GPU nodes.
Should we run EKS, AKS or our own servers?
Start from where your identity and data already live. Teams on Microsoft Entra ID and Azure data services fit AKS, and teams on AWS IAM and AWS data services fit EKS. A cluster on your own servers is in scope when data must stay in your data center. The written plan records the choice and the reason.
Who upgrades the cluster, and when?
Under managed DevOps, ITECS does, on dates set well before standard support for your version ends. Each upgrade moves one minor version and runs in staging before production, in a window a person you name approves. If your team runs the platform, the runbook covers the same steps.
What happens when our Kubernetes version leaves support?
AWS and Microsoft publish the date standard support ends for each version. After it, the cluster either costs more under extended support or is upgraded by the cloud provider on its own schedule. ITECS keeps clusters inside standard support, so neither one arrives. On a self-managed cluster nothing forces the upgrade, but security fixes stop, and each skipped version is one more upgrade to run in order.
What does running the platform as a product mean for developers?
Developers get one way to ship. They merge a change, the deploy path rolls it out, and every service has the same logs, metrics and secrets setup. New namespaces, certificates and access come from templates in the deploy repository instead of tickets.
Can the cluster run AI inference on GPUs?
Yes, when your workloads need it. ITECS adds a separate GPU pool with taints, so only model workloads land on those nodes, and that pool scales on its own. Its spend is reported apart from the general pools.
Should we hire a platform engineer instead?
You can, and one good hire can run a cluster. The gaps are nights, leave and the knowledge that goes when that person does. ITECS runs the platform layers under managed DevOps, with the practice it has used for managed IT and security since 2002, including a 24/7 NOC. It can also hand a new hire the runbooks.
Start from the version you run
Send us the version you run and the cloud your team signs in to. The written plan says whether a cluster fits, where it runs and which service moves first.