Kubernetes consulting sa Pittsburgh at Cleveland

Disenyo ng cluster sa pisikal na server o Proxmox

Maaaring tumakbo ang cluster nang direkta sa mga pisikal na server o sa mga virtual machine sa ilalim ng Proxmox. Binibigyan ng bare metal ang mga node ng direktang access sa hardware. Pinapadali ng mga Proxmox virtual machine ang mga snapshot, rebuild at test cluster. Pinipili namin ito kasama ninyo, batay sa inyong hardware, mga application at kung sino ang magpapatakbo nito.

• Control plane: sapat na bilang ng node para patuloy na tumakbo ang cluster kapag may pumalya.
• Storage: mga persistent volume na nakabatay sa lokal na disk o Ceph storage, depende sa kailangan ng inyong data.
• Access: ingress, mga TLS certificate at kung sino ang maaaring umabot sa cluster API.

Delivery at operasyon

Pinapanatili namin ang configuration ng cluster at application sa version control. Ang pagbabago ay isang GitLab merge request, at sumusunod ang cluster sa repository.

Ang operasyon ay nangangahulugang mga upgrade, monitoring, alerto, backup at kapasidad. Isinusulat namin kung paano gumagana ang bawat bahagi, para mapatakbo ito ng inyong team o ng amin. Para sa mas malalim na pagtingin, basahin ang mga gabay sa Kubernetes at ang mga gabay sa Talos Linux sa aming knowledge base.

Kapag hindi sagot ang Kubernetes

Mas maraming trabaho ang pagpapatakbo ng cluster kaysa sa iisang server. Ang isang application na may isang database ay madalas na mas maayos tumakbo sa Linux virtual machine na may wastong backup, na saklaw ng aming suporta sa Linux server. Ang ilang container sa isang host ay babagay sa Docker at Docker Compose.

Inirerekomenda namin ang cluster kapag kailangan ninyo ng failover sa mga machine, rolling update, o maraming service na dapat i-schedule nang magkakasama. Kung hindi kayo sigurado, ipinapakita ng aming pangkalahatang-ideya ng Linux at Kubernetes kung paano naghahambing ang mga opsyon.

Paano gumagana ang isang engagement

1. Discovery call. Alamin namin kung ano ang pinatatakbo ninyo, ano ang dapat manatiling online at kung sino ang magpapatakbo nito.
2. Nakasulat na saklaw. Isang disenyo o pagsusuri, na may pagkakasunod ng trabaho at plano sa backup at rollback.
3. Pagbuo at turnover. Nagde-deploy kami, sinusubok ang pagkabigo at restore, at dino-document ang operasyon.
4. Tuloy-tuloy na operasyon. Opsyonal, na may itinalagang engineer at walang lock-in.

Ang aming mga opisina ay nasa Coraopolis at Beaver Falls, Pennsylvania. Ang on-site na trabaho sa Cleveland area ay inaayos ayon sa proyekto, at may remote na suporta sa buong bansa. Sumasagot kami sa loob ng isang araw ng trabaho.

Mga tanong tungkol sa Kubernetes consulting

Maaari ba ninyong kunin ang cluster na ginawa ng iba?

Oo. Sinusuri muna namin ang mga node, access, backup at paraan ng deployment, saka aayusin ang mga partikular na problema o hahawakan ang operasyon.

Bakit Talos Linux?

Walang shell at package manager ang Talos. Kino-configure ang mga node sa pamamagitan ng API, na nagpapanatili sa mga itong magkapareho at nagbabawas sa maaaring ma-misconfigure o atakihin.

Kailangan ba namin ng Kubernetes para sa aming application?

Madalas, hindi. Sasabihin namin iyon sa unang tawag at imumungkahi ang Linux virtual machine o Docker kung alinman ang mas babagay.

Maaari ba ninyong ilipat ang aming mga Docker workload sa Kubernetes?

Oo. Kino-convert namin ang mga Compose service sa mga Helm chart, inililipat ang data, sinusubok, at nagka-cutover ayon sa iskedyul na inaprubahan ninyo.