Kubernetes K8s 解決了哪些問題?

時間 2021-05-06 23:00:49

1樓:

em, 我不太了解OpenStack不過K8s的好處在我實際工作中大部分在他的文件裡都已經描述的很好了

Kubernetes provides you with:

Service discovery and load balancingKubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable.

Storage orchestrationKubernetes allows you to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more.

Automated rollouts and rollbacksYou can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container.

Automatic bin packingYou provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. You tell Kubernetes how much CPU and memory (RAM) each container needs. Kubernetes can fit containers onto your nodes to make the best use of your resources.

Self-healingKubernetes restarts containers that fail, replaces containers, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.

What is Kubernetes?

在我的實際工作中,除了運維上的工作減少外(倒是這個主要是devops團隊的工作我感受不明顯),從開發上主要體現到高可用的方案,像自動的health check 和自動的擴充套件,和前面的負載均衡,這個讓考慮問題會清晰很多。

2樓:

K8s作為知名的容器排程平台,那麼我們簡單說說乙個容器排程系統需要具備哪些能力。

排程

能夠自動生成容器例項。

親和、反親和

生的容器可以相近或者相隔,提高可用性。

健康檢查

自動監測容器的健康狀態。

容錯

自動在健康的接點上生成新的容器例項。

可擴充套件網路

允許容器之間互相通訊。

服務發現

允許容器之間互相發現。

滾動公升級

容器公升級不可以對業務造成影響,同時支援出錯回滾。

3樓:iyacontrol

其實計算中心的發展史,就是乙個不斷抽象,追求效率的過程。這個效率包括資源利用的效率和工程效率。

從物理機,到虛擬機器,再到容器,未來可能是serverless。我們的執行程式的載體越來越抽象,資源切割粒度越來越小。有種「坐井觀天」的感覺,你以為你擁有整個作業系統,其實只是底層物理機的一部分(隔離性)。

我們需要記住抽象不是目的,提高效率才是。

虛擬機器時代無疑是openstack,那麼對應容器時代就是kubernetes了。所以openstack依舊有其使用場景和價值,但是kubernetes是技術發展的選擇,較高層面上說,kubernetes 更加有效的提高了資料中心的資源的效率

接下來我們具體一些分析。

Kubernetes最初定義就是容器編排和管理引擎。其管理不同節點上的容器生命週期,這些節點可以是物理機或虛擬機器。其具備以下特點:

通過一系列排程演算法,可以合理排程Pod到主機

提供對服務的自癒能力。其會監控節點和容器執行狀況問題並做出相應的操作。並且kubernetes控制模式是宣告式而非命令式,控制器會不斷對比負載的真實狀態和期望狀態,從而做出糾正偏差的操作。

提供儲存,網路,proxy,安全性

可擴充套件但是隨著kubernetes發展,已經發展成下一代作業系統。在這個萬物皆可CRD的時代,kubernetes作為基石,衍生出了太多的專案。

比如服務網格領域的istio,serverless領域的knative。你可以通過 kubevirt

去管理虛擬機器,你也可以通過 Crossplane 管理基礎設施,也可以通過 kubeedge 實現邊緣計算。 而在AI領域,我們可以使用 kuebflow 構建我們的機器學習平台。大資料領域,flink 和 spark 也早已支援kubernetes 作為其資源管理的provider ......

4樓:亮哥

如果說OpenStack解決了虛擬化的編排問題,那K8S則解決了容器的編排問題,但又不僅僅解決了這個問題。

所以要想說明白K8S解決了什麼問題,還得從虛擬化和容器的區別說起。

可以把容器看成一種更「輕量「的虛擬化(雖然這樣描述不怎麼正確,但從這個視角確實更容易理解),但這個「輕量」帶來了大量以前在虛擬化領域沒有遇到的問題,K8S的容器編排能力解決了這些問題,但在這之上設計了更高層次的面向應用的服務抽象,所以如果說OpenStack更面向IAAS,則K8S更接近PAAS。

從使用者角度,如果說以前的應用管理員/運維人員面向的是單機作業系統、操作介面是Linux命令列,那用了K8S之後,應用管理員/運維人員則直接面向的是集群作業系統,操作介面就是K8S的API,如kubectl命令列、各種二次設計的UI介面等,通過宣告式的檔案來告訴k8s需要部署什麼應用即可,而不用去關注太多的檔案、程序、網路等底層概念,這些底層資源交給K8s來統籌管理了。

而OpenStack交給使用者的還是虛擬機器、網路、儲存這些東西,和K8s顯然不在乙個層面。

5樓:景安雲

個人認為k8s 火不了多久,但是docker 還是有價值的

容器編排內部的複雜遠超想象,SDN網路繞來繞去複雜就算了,iptables那天文般的配置表簡直就是用來折騰人的

有點過度運維的感覺,不過學一下k8s是很必要的,你會學到很多東西,真的,但是火不了的原因恰恰是太複雜了。

6樓:豬豬俠

kubernetes使你的關注從單機邁向集群, 你終於可以不用考慮單機硬體問題了,終於可以不用考慮底層os的問題了! 動態調配資源,動態熱更新服務都變得簡單規範化!

7樓:黃承開

好吧,很多人把容器當虛擬機器用,所以遇到了各種不爽……雖然兩者的確解決的問題域有重疊,不過解法和思路是完全不同的。

怎麼說呢openstack其實也還算不錯了,相當成熟,也並沒有沒落,我相信也會有很多人認為虛擬機器很差勁,因為單機很爽,blablabla的,情況和我上面說的如出一轍。

吐槽了兩段話,說點乾貨吧,其實k8s和openstack相對於之前的那些覺得各種不爽的人的認知,做到的恰恰是他們吐槽的點。舉個具體的例子,其實這種編排的解決方案,是包含了網路架構的設計的,更具體的就是靠sdn解決流量的問題,而不是單機上的iptables(當然我承認會有一些邊緣的case還是需要iptables),抖個機靈的話就是開啟方式錯了。這裡牽涉到乙個認知和經驗的遷移的問題,就不展開了。

8樓:任衛

終極目標:如何在不穩定的硬體和不穩定的軟體上構造穩定的服務。

k8s將機器、網路等等做了抽象,做到了Infrastructure As Code,而且還是AS的DDL,簡單地寫乙份YAML就能完整管理軟體發布的所有方面,機器計算資源、儲存、網路訪問都通過這份YAML描述檔案就完成了宣告與配置。這對DevOps當然是極好的,Dev可以在更廣泛的範圍內自行搞定Ops的很多問題。

自動化問題,K8S將幾乎所有操作都自動化了,自動化地按照您指定的方式更新例項、自動化根據您提供的健康檢查方式對例項進行健康檢查,並自動化地根據健康檢查結果更新可用例項列表。自動化根據條件幫您重啟不健康的例項,甚至自動化地建立或銷毀例項以與當前的訪問量相匹配。

9樓:蘿蔔

對下重新對計算、儲存、網路、負載均衡資源進行抽象,便於排程管理;對上通過控制器管理業務生命週期,包括服務新增、容量管理、服務簡單自癒。

10樓:UCloud雲計算

Kubernetes作為一款社群最火的容器管理排程軟體,它主要解決了兩方面的問題:

一第乙個肯定要說的是「容器的編排排程」,從原來的AIO的應用變成容器化應用微服務化應用,帶來的好處就是服務解耦,可以快速擴充套件服務,帶來的不好就是使用者管理成本增加,kuebrnetes很好地解決了這個問題,幫助我們實現了應用層面的管理抽象,根據不同業務應用,使用不同的部署型別。

二第二個要說的是kubernetes的一致性能力,雖然雲計算現在在多雲場景下還不具備真正的乙個「build once,run any cloud provider」但這個趨勢已經開始呈現了,大家遵循kubernetes的API,保障API的一致性,想想多年前的運維要在多雲廠商環境下部署服務的處境,考慮不同的作業系統、不同的作業系統版本、核心版本、網路差異還有一些詭異的問題等等,通過kubernetes已經開始有了乙個很好地發展趨勢,面向使用者運維更加的友好。

當然這一切的代價就是基礎運維工程師需要很系統的去理解k8s的抽象內容排程策略等,才能成為一名Kubernetes Administrator,當然這一切的學習是值得的:)

部署Kubernetes k8s 時,為什麼要關閉swap selinux 防火牆?

已登出 為什麼關閉swap?如果乙個node效能不足時,那麼應該即時的遷移到效能足夠的節點,不能讓swap來拖慢這個進度,這是沒有意義的。為什麼關閉selinux?docker和kubelet對selinux支援性都不是很好吧目前看為什麼關閉防火牆?一般firewalld ufw這一類的程式被認為是...

奧迪 S8 如何?

我給大家打個謎語,猜一四門轎車 百公里實測四秒以內四門轎車 裝有大排量雙渦輪增壓發動機 內飾摸著全都是碳纖維和真皮 車裡每乙個細節做的恰到好處 這裡有很多符合條件的四門轎車車Panamera,S63,Quattroporte,賓利等等等等 我再來提供乙個重要條件 車主沒有女朋友 嗯,我來再畫個重點 ...

如何看待S8S9冠軍IG FPX雙雙無緣S10

闊瓣含笑 說無緣的還為時尚早了。不過就ig的表現來看接下來一段賽程他們會打得異常艱難。除了omg以外他們要面對的要麼是水鬼隊要麼是強隊。包括 v5,滔博,vg,rng。以滔博和v5的架勢來看,ig至少要戰勝這些隊伍中的三支 已經算上OMG 才有機會保住他們現在的地位。ig現在是聯賽第四跟蘇寧並列,而...