Hopp til innholdet
BigTree108

Tjenester for Kubernetes-rådgivning og -utvikling

Kubernetes-rådgivning og -utvikling for team som kjører containere i produksjon: klynger på EKS, AKS, GKE og egen maskinvare, Helm-charts, GitOps-leveranse, klyngesikkerhet og observerbarhet, versjonsoppgraderinger og GPU-arbeidsbelastninger, med dedikerte Kubernetes-ingeniører til teamet deres eller et Kubernetes-prosjekt levert fra ende til ende.

Dette bygger vi med Kubernetes

  • Produksjonsklynger

    EKS-, AKS- eller GKE-klynger definert i Terraform, med noder skalert av Karpenter eller cluster autoscaler, trafikk rutet gjennom Gateway API, og nettverkspolicyer som nekter som standard.

  • Containerisering av applikasjoner

    Eksisterende .NET-, Java-, Python- og Node.js-applikasjoner flyttet inn i små images uten root som bygges og skannes i pipelinen, med konfigurasjonen holdt utenfor imaget.

  • Helm-charts og manifester

    Applikasjoner pakket med Helm eller Kustomize, hver med ressursforespørsler og -grenser, readiness- og liveness-prober og et pod disruption budget.

  • GitOps-leveranse

    Argo CD eller Flux som holder hver klynge i takt med Git, og Argo Rollouts eller Flagger som flytter trafikk til en ny versjon trinn for trinn, slik at det som kjører, er det repositoriet sier og en tilbakerulling er en revert.

  • Observerbarhet i klyngen

    Prometheus og Grafana eller skyens egen overvåking, OpenTelemetry-spor på tvers av tjenester, og varsler på det brukerne ville merket i stedet for på hver omstart av en pod.

  • Klyngesikkerhet

    Pod Security Standards, RBAC per team, hemmeligheter hentet fra et hvelv av External Secrets Operator, signerte images, opptakspolicyer i Kyverno eller OPA Gatekeeper, og gjensidig TLS mellom tjenester gjennom Istio eller Linkerd.

  • Oppgraderinger og drift etter lansering

    Minorversjoner oppgradert innenfor leverandørens støttevindu, fjernede API-er funnet før de ødelegger en utrulling, ingress-nginx erstattet med en implementering av Gateway API nå som prosjektet er avviklet, og Velero-sikkerhetskopier gjenopprettet etter en plan.

  • Klynger on-premises og hybride klynger

    Kubernetes på egne servere eller ytterst i nettverket med OpenShift, Rancher RKE2, Talos Linux eller k3s, og flåter som spenner over skyer og datasentre, styrt fra ett sted gjennom Cluster API og GitOps.

  • GPU- og maskinlæringsarbeidsbelastninger

    GPU-nodepooler som kjører med NVIDIA GPU Operator, modeller servert gjennom KServe eller vLLM, Ray-klynger gjennom KubeRay og batchjobber i kø i Kueue, med KEDA som skalerer på køens lengde slik at ledige GPU-er frigjøres.

Lei inn Kubernetes-ingeniører

  • Dedikerte Kubernetes-ingeniører

    Kubernetes-ingeniører som blir en del av teamet deres på heltid, jobber i repositoriene, oppgavesystemet og møtene deres, og rapporterer til lederen deres. Dere intervjuer dem, og vi tar oss av den ukrainske kontrakten, lønn, fakturering og fravær.

  • Prosjektleveranse med Kubernetes

    Et team som tar Kubernetes-prosjektet fra omfang til utgivelse: estimat, utvikling, tester og utrulling, med en teknisk leder hos oss som eier planen og kvaliteten.

  • Support og overtakelse av Kubernetes-løsninger

    Et eksisterende Kubernetes-system overtatt fra et annet team eller holdt i drift: først en gjennomgang med kun lesetilgang og en skriftlig liste over risikoer, deretter rettelser og nye funksjoner i rekkefølge etter betydning.

Siden om dedikert team forklarer hvordan spesialister blir med i teamet deres, og siden om outsourcing dekker prosjektleveranse, overtakelser og hvordan vi priser.

Hvem som jobber med Kubernetes-prosjektet deres

  • Kubernetes-ingeniører

    Klynger, GitOps og oppgraderinger

  • Plattformingeniører

    Den interne plattformen teamene deres ruller ut gjennom

  • DevOps- og site reliability-ingeniører

    Pipelines, overvåking og vakt

  • Backend-utviklere

    Applikasjoner gjort klare for containere

  • Sikkerhetsingeniører

    Policyer, RBAC og klyngegjennomganger

Slik driver vi Kubernetes

Et administrert kontrollplan der leverandøren tilbyr et, alt deklarert i Git, og klynger som kan bygges opp igjen fra kode i stedet for å repareres for hånd. Folk når klyngen gjennom identitetsleverandøren deres med kortlevde legitimasjoner, så ingen bærbar maskin holder en kubeconfig med administratorrettigheter.

På en klynge et annet team har bygget starter vi med en skrivebeskyttet gjennomgang av versjoner, tillegg, RBAC, nettverkseksponering og ressursinnstillinger, og en skriftlig liste over risikoer i rekkefølge etter påvirkning, før noe endres.

Andre tjenester for sky, DevOps og sikkerhet

Oversikt: Sky, DevOps og sikkerhet

Spørsmål om Kubernetes-utvikling

Hvilke bransjer arbeider Kubernetes-ingeniørene deres i?

Mest fintech, som kjører betalings- og handelstjenester som trenger isolasjon og revisjonsspor; sky-, hosting- og telekomselskaper som tilbyr plattformer på Kubernetes til sine egne kunder; netthandel, med tjenester som skalerer for salgstopper; SaaS-produkter med mange tjenester og tenants; KI-produkter som serverer modeller på GPU-klynger; og helseplattformer som holder pasientdata i adskilte navnerom eller klynger.

EKS, AKS eller GKE?

Vanligvis den i skyen dere allerede bruker, fordi identitet, nettverk og fakturering følger med: EKS på AWS, AKS på Azure og GKE på Google Cloud, med EKS Auto Mode eller GKE Autopilot når dere vil ha nodene administrert også. På egen maskinvare, OpenShift eller Rancher. Terraform- og GitOps-oppsettet vårt er det samme på alle.

Kan dere oppgradere en klynge som har falt etter?

Ja, én minorversjon om gangen. Hver arbeidsbelastning kontrolleres for API-er neste versjon fjerner, oppgraderingen øves på en kopi av klyngen, og ingress-kontrollere, operatorer og andre tillegg oppgraderes samtidig.

Hvor raskt kan Kubernetes-ingeniører starte?

Når rett Kubernetes-ingeniør er tilgjengelig, avhenger starten bare av intervjuet deres, NDA-en og IP-overdragelsen. Ellers gjennomfører vi et søk, som vanligvis gir kandidatprofiler innen to til tre uker, og ingen starter før dere har sagt ja.

Hvordan leier vi inn Kubernetes-ingeniører gjennom BigTree108?

Fortell oss om arbeidet, erfaringsnivået og timene dere trenger. Vi foreslår én eller to personer med profilene deres, dere intervjuer dem slik dere ville intervjuet en egen ansatt, og dere signerer én avtale med BIG TREE 108 LLC og får én faktura i måneden.

Hvem eier arbeidet de leverer?

Det gjør dere. Hver spesialist har en signert kontrakt med BigTree108 som overdrar alt arbeidsresultat til selskapet, og avtalen vår med dere overdrar det videre til dere. Kode, design og dokumenter leveres inn i deres egne repositorier og verktøy, og oppbevares ikke der bare vi kan endre dem.

Kjører dere Kubernetes?

Fortell oss om leverandøren, klyngeversjonen og hva som kjører på den. Dere får svar innen én arbeidsdag: en plan, kandidatprofiler eller et omfang for en gjennomgang av klyngene deres.