કુબરનેટ્સ ક્લસ્ટરમાં છિદ્રો ફિક્સિંગ. DevOpsConf તરફથી રિપોર્ટ અને ટ્રાન્સક્રિપ્ટ

પાવેલ સેલિવાનોવ, સાઉથબ્રિજ સોલ્યુશન્સ આર્કિટેક્ટ અને સ્લર્મ શિક્ષક, એ DevOpsConf 2019 ખાતે એક પ્રેઝન્ટેશન આપ્યું હતું. આ વાર્તાલાપ કુબરનેટ્સ “સ્લર્મ મેગા” પરના ઊંડાણપૂર્વકના અભ્યાસક્રમના એક વિષયનો ભાગ છે.

સ્લર્મ બેઝિક: એન ઇન્ટ્રોડક્શન ટુ કુબરનેટ્સ નવેમ્બર 18-20 ના રોજ મોસ્કોમાં થાય છે.
સ્લર્મ મેગા: કુબરનેટીસના હૂડ હેઠળ જોવું - મોસ્કો, નવેમ્બર 22-24.
સ્લર્મ ઓનલાઈન: બંને કુબરનેટ્સ અભ્યાસક્રમો હંમેશા ઉપલબ્ધ.

કટની નીચે રિપોર્ટની ટ્રાન્સક્રિપ્ટ છે.

શુભ બપોર, સાથીદારો અને જેઓ તેમની સાથે સહાનુભૂતિ ધરાવે છે. આજે હું સલામતી વિશે વાત કરીશ.

હું જોઉં છું કે આજે હોલમાં ઘણા સુરક્ષાકર્મીઓ છે. જો હું સુરક્ષાની દુનિયાની શરતોનો ઉપયોગ તમારા માટે રૂઢિગત છે તે રીતે ન કરું તો હું અગાઉથી તમારી માફી માંગું છું.

એવું બન્યું કે લગભગ છ મહિના પહેલા હું એક સાર્વજનિક કુબરનેટ્સ ક્લસ્ટર તરફ આવ્યો. સાર્વજનિક એટલે કે નેમસ્પેસની nમી સંખ્યા છે; આ નેમસ્પેસમાં યુઝર્સ તેમની નેમસ્પેસમાં અલગ છે. આ તમામ યુઝર્સ અલગ-અલગ કંપનીઓના છે. સારું, એવું માનવામાં આવતું હતું કે આ ક્લસ્ટરનો ઉપયોગ CDN તરીકે થવો જોઈએ. એટલે કે, તેઓ તમને એક ક્લસ્ટર આપે છે, તેઓ તમને ત્યાં વપરાશકર્તા આપે છે, તમે ત્યાં તમારા નેમસ્પેસ પર જાઓ, તમારા મોરચા ગોઠવો.

મારી અગાઉની કંપનીએ આવી સેવા વેચવાનો પ્રયાસ કર્યો હતો. અને મને આ સોલ્યુશન યોગ્ય છે કે નહી તે જોવા માટે ક્લસ્ટરને પોક કરવાનું કહેવામાં આવ્યું.

હું આ ક્લસ્ટરમાં આવ્યો છું. મને મર્યાદિત અધિકારો, મર્યાદિત નેમસ્પેસ આપવામાં આવ્યા હતા. ત્યાંના લોકો સમજી ગયા કે સલામતી શું છે. તેઓએ કુબરનેટ્સમાં રોલ-આધારિત એક્સેસ કંટ્રોલ (RBAC) વિશે વાંચ્યું - અને તેઓએ તેને ટ્વિસ્ટ કર્યું જેથી કરીને હું ડિપ્લોયમેન્ટ્સથી અલગથી પોડ્સ લોન્ચ કરી શકું નહીં. ડિપ્લોયમેન્ટ વિના પોડ લોન્ચ કરીને હું જે સમસ્યાનો ઉકેલ લાવવાનો પ્રયાસ કરી રહ્યો હતો તે મને યાદ નથી, પરંતુ હું ખરેખર માત્ર એક પોડ લોન્ચ કરવા માંગતો હતો. સારા નસીબ માટે, મેં એ જોવાનું નક્કી કર્યું કે ક્લસ્ટરમાં મારી પાસે કયા અધિકારો છે, હું શું કરી શકું છું, હું શું કરી શકતો નથી, અને તેઓએ ત્યાં શું ખરાબ કર્યું છે. તે જ સમયે, હું તમને કહીશ કે તેઓએ RBAC માં શું ખોટી રીતે ગોઠવ્યું છે.

એવું બન્યું કે બે મિનિટમાં મને તેમના ક્લસ્ટરમાં એક એડમિન મળ્યો, બધા પડોશી નેમસ્પેસ જોયા, ત્યાં કંપનીઓના ચાલી રહેલા ઉત્પાદન મોરચા જોયા જેમણે પહેલેથી જ સેવા ખરીદી હતી અને જમાવટ કરી હતી. હું ભાગ્યે જ મારી જાતને કોઈની આગળ જવાથી અને મુખ્ય પૃષ્ઠ પર શપથ લેવાથી રોકી શક્યો.

હું તમને ઉદાહરણો સાથે કહીશ કે મેં આ કેવી રીતે કર્યું અને આનાથી તમારી જાતને કેવી રીતે બચાવવી.

પરંતુ પહેલા, હું મારો પરિચય આપું. મારું નામ પાવેલ સેલિવાનોવ છે. હું સાઉથબ્રિજ ખાતે આર્કિટેક્ટ છું. હું Kubernetes, DevOps અને તમામ પ્રકારની ફેન્સી વસ્તુઓને સમજું છું. સાઉથબ્રિજ એન્જિનિયરો અને હું આ બધું બનાવી રહ્યા છીએ, અને હું સલાહ લઈ રહ્યો છું.

અમારી મુખ્ય પ્રવૃત્તિઓ ઉપરાંત, અમે તાજેતરમાં સ્લર્મ્સ નામના પ્રોજેક્ટ્સ શરૂ કર્યા છે. અમે કુબરનેટ્સ સાથે કામ કરવાની અમારી ક્ષમતાને લોકો સુધી પહોંચાડવાનો પ્રયાસ કરી રહ્યા છીએ, અન્ય લોકોને પણ K8 સાથે કામ કરવાનું શીખવવા માટે.

આજે હું શું વાત કરીશ? રિપોર્ટનો વિષય સ્પષ્ટ છે - કુબરનેટ્સ ક્લસ્ટરની સુરક્ષા વિશે. પરંતુ હું હમણાં જ કહેવા માંગુ છું કે આ વિષય ખૂબ મોટો છે - અને તેથી હું તરત જ સ્પષ્ટ કરવા માંગુ છું કે હું ચોક્કસપણે જેના વિશે વાત કરીશ નહીં. હું હેકનીડ શબ્દો વિશે વાત કરીશ નહીં જેનો ઉપયોગ પહેલાથી જ ઇન્ટરનેટ પર સો વખત કરવામાં આવ્યો છે. તમામ પ્રકારના RBAC અને પ્રમાણપત્રો.

કુબરનેટ્સ ક્લસ્ટરમાં સુરક્ષા વિશે મને અને મારા સાથીદારોને શું પીડા થાય છે તે વિશે હું વાત કરીશ. અમે કુબરનેટ્સ ક્લસ્ટર પ્રદાન કરનારા પ્રદાતાઓ અને અમારી પાસે આવતા ક્લાયન્ટ્સ બંનેમાં આ સમસ્યાઓ જોઈએ છીએ. અને અન્ય કન્સલ્ટિંગ એડમિન કંપનીઓમાંથી અમારી પાસે આવતા ગ્રાહકો પાસેથી પણ. એટલે કે, દુર્ઘટનાનું પ્રમાણ ખરેખર ઘણું મોટું છે.

ત્યાં શાબ્દિક રીતે ત્રણ મુદ્દા છે જેના વિશે હું આજે વાત કરીશ:

1. વપરાશકર્તા અધિકારો વિ પોડ અધિકારો. વપરાશકર્તા અધિકારો અને પોડ અધિકારો એક જ વસ્તુ નથી.
2. ક્લસ્ટર વિશે માહિતી એકત્ર કરી રહ્યા છીએ. હું બતાવીશ કે તમે આ ક્લસ્ટરમાં વિશેષ અધિકારો વિના ક્લસ્ટરમાંથી તમને જોઈતી તમામ માહિતી એકત્રિત કરી શકો છો.
3. ક્લસ્ટર પર DoS હુમલો. જો અમે માહિતી એકત્રિત કરી શકતા નથી, તો અમે કોઈપણ સંજોગોમાં ક્લસ્ટર મૂકી શકીશું. હું ક્લસ્ટર નિયંત્રણ તત્વો પર DoS હુમલાઓ વિશે વાત કરીશ.

બીજી એક સામાન્ય વસ્તુ જેનો હું ઉલ્લેખ કરીશ તે એ છે કે મેં આ બધાનું પરીક્ષણ કર્યું છે, જેના આધારે હું ચોક્કસપણે કહી શકું છું કે તે બધું કાર્ય કરે છે.

અમે Kubespray નો ઉપયોગ કરીને Kubernetes ક્લસ્ટરની સ્થાપનાને આધાર તરીકે લઈએ છીએ. જો કોઈ જાણતું ન હોય તો, આ વાસ્તવમાં એન્સિબલ માટે ભૂમિકાઓનો સમૂહ છે. અમે અમારા કામમાં તેનો સતત ઉપયોગ કરીએ છીએ. સારી વાત એ છે કે તમે તેને ગમે ત્યાં રોલ કરી શકો છો - તમે તેને લોખંડના ટુકડા પર અથવા ક્યાંક વાદળમાં ફેરવી શકો છો. એક ઇન્સ્ટોલેશન પદ્ધતિ દરેક વસ્તુ માટે સિદ્ધાંતમાં કાર્ય કરે છે.

આ ક્લસ્ટરમાં મારી પાસે Kubernetes v1.14.5 હશે. આખું ક્યુબ ક્લસ્ટર, જેને આપણે ધ્યાનમાં લઈશું, નેમસ્પેસમાં વિભાજિત કરવામાં આવ્યું છે, દરેક નેમસ્પેસ એક અલગ ટીમની છે, અને આ ટીમના સભ્યોને દરેક નેમસ્પેસની ઍક્સેસ છે. તેઓ અલગ-અલગ નેમસ્પેસમાં જઈ શકતા નથી, ફક્ત તેમની પોતાની. પરંતુ એક ચોક્કસ એડમિન એકાઉન્ટ છે જે સમગ્ર ક્લસ્ટરના અધિકારો ધરાવે છે.

મેં વચન આપ્યું હતું કે પ્રથમ વસ્તુ અમે કરીશું ક્લસ્ટરના એડમિન અધિકારો મેળવવા. અમને ખાસ તૈયાર પોડની જરૂર છે જે કુબરનેટ્સ ક્લસ્ટરને તોડી નાખશે. આપણે માત્ર તેને કુબરનેટ્સ ક્લસ્ટર પર લાગુ કરવાની જરૂર છે.

kubectl apply -f pod.yaml

આ પોડ કુબરનેટ્સ ક્લસ્ટરના માસ્ટર્સમાંથી એક સુધી પહોંચશે. અને આ પછી ક્લસ્ટર અમને admin.conf નામની ફાઈલ ખુશીથી પરત કરશે. ક્યુબમાં, આ ફાઇલ તમામ એડમિનિસ્ટ્રેટર પ્રમાણપત્રોને સંગ્રહિત કરે છે, અને તે જ સમયે ક્લસ્ટર API ને ગોઠવે છે. મને લાગે છે કે, કુબરનેટ્સ ક્લસ્ટરના 98% એડમિન ઍક્સેસ મેળવવો આટલો સરળ છે.

હું પુનરાવર્તન કરું છું, આ પોડ તમારા ક્લસ્ટરમાંના એક ડેવલપર દ્વારા બનાવવામાં આવ્યો હતો, જેની પાસે તેની દરખાસ્તોને એક નાની નેમસ્પેસમાં જમાવવાની ઍક્સેસ છે, તે બધું RBAC દ્વારા ક્લેમ્પ્ડ છે. તેની પાસે કોઈ અધિકાર નહોતો. પરંતુ તેમ છતાં પ્રમાણપત્ર પરત કરવામાં આવ્યું હતું.

અને હવે ખાસ તૈયાર પોડ વિશે. અમે તેને કોઈપણ છબી પર ચલાવીએ છીએ. ચાલો ડેબિયન:જેસીને ઉદાહરણ તરીકે લઈએ.

અમારી પાસે આ વસ્તુ છે:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

સહનશીલતા શું છે? કુબરનેટ્સ ક્લસ્ટરમાં માસ્ટર્સ સામાન્ય રીતે કલંક તરીકે ઓળખાતી વસ્તુથી ચિહ્નિત થાય છે. અને આ "ચેપ" નો સાર એ છે કે તે કહે છે કે શીંગો માસ્ટર નોડ્સને સોંપી શકાતા નથી. પરંતુ કોઈ પણ પોડમાં તે દર્શાવવાની તસ્દી લેતું નથી કે તે "ચેપ" માટે સહન કરે છે. સહનશીલતા વિભાગ ફક્ત કહે છે કે જો કેટલાક નોડમાં NoSchedule હોય, તો અમારું નોડ આવા ચેપને સહન કરે છે - અને ત્યાં કોઈ સમસ્યા નથી.

આગળ, અમે કહીએ છીએ કે અમારો અંડર માત્ર સહનશીલ નથી, પરંતુ તે માસ્ટરને ખાસ નિશાન બનાવવા માંગે છે. કારણ કે માસ્ટર્સ પાસે સૌથી વધુ સ્વાદિષ્ટ વસ્તુ છે જેની અમને જરૂર છે - બધા પ્રમાણપત્રો. તેથી, અમે નોડસેલેક્ટર કહીએ છીએ - અને અમારી પાસે માસ્ટર્સ પર પ્રમાણભૂત લેબલ છે, જે તમને ક્લસ્ટરમાંના તમામ નોડ્સમાંથી બરાબર તે ગાંઠો પસંદ કરવાની મંજૂરી આપે છે જે માસ્ટર્સ છે.

આ બે વિભાગો સાથે તે ચોક્કસપણે માસ્ટર પાસે આવશે. અને તેને ત્યાં રહેવા દેવામાં આવશે.

પરંતુ ફક્ત માસ્ટર પાસે આવવું આપણા માટે પૂરતું નથી. આ અમને કંઈપણ આપશે નહીં. તેથી આગળ આપણી પાસે આ બે વસ્તુઓ છે:

hostNetwork: true 
hostPID: true 

અમે સ્પષ્ટ કરીએ છીએ કે અમારું પોડ, જે અમે લોન્ચ કરીએ છીએ, તે કર્નલ નેમસ્પેસમાં, નેટવર્ક નેમસ્પેસમાં અને PID નેમસ્પેસમાં રહેશે. એકવાર માસ્ટર પર પોડ લોંચ થઈ જાય, તે આ નોડના તમામ વાસ્તવિક, લાઈવ ઈન્ટરફેસ જોઈ શકશે, તમામ ટ્રાફિકને સાંભળી શકશે અને તમામ પ્રક્રિયાઓની PID જોઈ શકશે.

પછી નાની નાની બાબતોની વાત છે. etcd લો અને તમને જે જોઈએ છે તે વાંચો.

સૌથી રસપ્રદ બાબત એ છે કે આ કુબરનેટ્સ ફીચર, જે ત્યાં ડિફોલ્ટ રૂપે હાજર છે.

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

અને તેનો સાર એ છે કે અમે પોડમાં કહી શકીએ છીએ કે અમે લોન્ચ કરીએ છીએ, આ ક્લસ્ટરના અધિકારો વિના પણ, અમે હોસ્ટપાથ પ્રકારનું વોલ્યુમ બનાવવા માંગીએ છીએ. આનો અર્થ એ છે કે હોસ્ટમાંથી રસ્તો લેવો કે જેના પર આપણે લોન્ચ કરીશું - અને તેને વોલ્યુમ તરીકે લઈએ. અને પછી અમે તેને નામ કહીએ છીએ: યજમાન. અમે આ સમગ્ર હોસ્ટપાથને પોડની અંદર માઉન્ટ કરીએ છીએ. આ ઉદાહરણમાં, /host ડિરેક્ટરીમાં.

હું તેને ફરીથી પુનરાવર્તન કરીશ. અમે પોડને માસ્ટર પાસે આવવા કહ્યું, ત્યાં હોસ્ટનેટવર્ક અને હોસ્ટપીઆઈડી મેળવો - અને આ પોડની અંદર માસ્ટરના સંપૂર્ણ રૂટને માઉન્ટ કરો.

તમે સમજો છો કે ડેબિયનમાં આપણી પાસે બેશ ચાલી રહી છે, અને આ બેશ રૂટ હેઠળ ચાલે છે. એટલે કે, કુબરનેટ્સ ક્લસ્ટરમાં કોઈપણ અધિકારો વિના, અમે હમણાં જ માસ્ટર પર રૂટ મેળવ્યું છે.

પછી આખું કાર્ય સબ ડિરેક્ટરી /host /etc/kubernetes/pki પર જવાનું છે, જો મારી ભૂલ ન હોય, તો ત્યાંથી ક્લસ્ટરના તમામ માસ્ટર સર્ટિફિકેટ્સ પસંદ કરો અને તે મુજબ, ક્લસ્ટર એડમિનિસ્ટ્રેટર બનો.

જો તમે તેને આ રીતે જુઓ, તો આ પોડ્સમાંના કેટલાક સૌથી ખતરનાક અધિકારો છે - વપરાશકર્તા પાસે કયા અધિકારો છે તે ધ્યાનમાં લીધા વિના:

જો મારી પાસે ક્લસ્ટરના અમુક નેમસ્પેસમાં પોડ ચલાવવાના અધિકારો છે, તો આ પોડ પાસે મૂળભૂત રીતે આ અધિકારો છે. હું વિશેષાધિકૃત પોડ્સ ચલાવી શકું છું, અને આ સામાન્ય રીતે તમામ અધિકારો છે, વ્યવહારિક રીતે નોડ પર રૂટ.

મારો પ્રિય રૂટ વપરાશકર્તા છે. અને કુબરનેટ્સ પાસે આ રન એઝ નોન-રુટ વિકલ્પ છે. આ હેકરથી રક્ષણનો એક પ્રકાર છે. શું તમે જાણો છો કે "મોલ્ડેવિયન વાયરસ" શું છે? જો તમે અચાનક હેકર છો અને મારા કુબરનેટ્સ ક્લસ્ટરમાં આવો છો, તો અમે, નબળા સંચાલકો, પૂછીએ છીએ: “કૃપા કરીને તમારા પોડ્સમાં સૂચવો કે જેના વડે તમે મારા ક્લસ્ટરને હેક કરશો, બિન-રુટ તરીકે ચલાવો. નહિંતર, એવું થશે કે તમે તમારા પોડમાં પ્રક્રિયા રૂટ હેઠળ ચલાવો, અને તમારા માટે મને હેક કરવું ખૂબ જ સરળ રહેશે. કૃપા કરીને તમારી જાતને તમારાથી બચાવો."

હોસ્ટ પાથ વોલ્યુમ, મારા મતે, કુબરનેટ્સ ક્લસ્ટરમાંથી ઇચ્છિત પરિણામ મેળવવાની સૌથી ઝડપી રીત છે.

પણ આ બધાનું શું કરવું?

કુબરનેટીસનો સામનો કરનાર કોઈપણ સામાન્ય એડમિનિસ્ટ્રેટરને જે વિચાર આવવો જોઈએ તે છે: “હા, મેં તમને કહ્યું હતું, કુબરનેટ્સ કામ કરતું નથી. તેમાં છિદ્રો છે. અને આખું ક્યુબ બકવાસ છે.” હકીકતમાં, દસ્તાવેજીકરણ જેવી વસ્તુ છે, અને જો તમે ત્યાં જુઓ, તો ત્યાં એક વિભાગ છે પોડ સુરક્ષા નીતિ.

આ એક યામલ ઑબ્જેક્ટ છે - અમે તેને કુબરનેટ્સ ક્લસ્ટરમાં બનાવી શકીએ છીએ - જે શીંગોના વર્ણનમાં ખાસ કરીને સુરક્ષાના પાસાઓને નિયંત્રિત કરે છે. એટલે કે, હકીકતમાં, તે કોઈપણ હોસ્ટનેટવર્ક, હોસ્ટપીઆઈડી, સ્ટાર્ટઅપ સમયે પોડ્સમાં હોય તેવા ચોક્કસ વોલ્યુમ પ્રકારોનો ઉપયોગ કરવાના અધિકારોને નિયંત્રિત કરે છે. પોડ સિક્યોરિટી પોલિસીની મદદથી આ બધું વર્ણવી શકાય છે.

પોડ સિક્યોરિટી પોલિસી વિશે સૌથી રસપ્રદ બાબત એ છે કે કુબરનેટ્સ ક્લસ્ટરમાં, બધા PSP ઇન્સ્ટોલર્સનું વર્ણન કોઈપણ રીતે કરવામાં આવતું નથી, તેઓ ડિફોલ્ટ રૂપે અક્ષમ છે. પ્રવેશ પ્લગઇનનો ઉપયોગ કરીને પોડ સુરક્ષા નીતિ સક્ષમ છે.

ઠીક છે, ચાલો પોડ સિક્યુરિટી પોલિસીને ક્લસ્ટરમાં જમાવીએ, ચાલો કહીએ કે અમારી પાસે નેમસ્પેસમાં કેટલાક સર્વિસ પોડ્સ છે, જેમાં ફક્ત એડમિન પાસે જ ઍક્સેસ છે. ચાલો કહીએ કે, અન્ય તમામ કિસ્સાઓમાં, શીંગો પાસે મર્યાદિત અધિકારો છે. કારણ કે મોટાભાગે વિકાસકર્તાઓને તમારા ક્લસ્ટરમાં વિશેષાધિકૃત પોડ્સ ચલાવવાની જરૂર નથી.

અને અમારી સાથે બધું સારું લાગે છે. અને અમારા કુબરનેટ્સ ક્લસ્ટરને બે મિનિટમાં હેક કરી શકાતું નથી.

એક સમસ્યા છે. મોટે ભાગે, જો તમારી પાસે કુબરનેટ્સ ક્લસ્ટર હોય, તો તમારા ક્લસ્ટર પર મોનિટરિંગ ઇન્સ્ટોલ કરેલું છે. હું આગાહી કરવા માટે પણ ત્યાં સુધી જઈશ કે જો તમારા ક્લસ્ટરનું મોનિટરિંગ હોય, તો તેને પ્રોમિથિયસ કહેવામાં આવશે.

હું તમને જે કહેવા જઈ રહ્યો છું તે પ્રોમિથિયસ ઓપરેટર અને પ્રોમિથિયસ બંને માટે તેના શુદ્ધ સ્વરૂપમાં વિતરિત કરવા માટે માન્ય રહેશે. પ્રશ્ન એ છે કે જો હું ક્લસ્ટરમાં આટલી ઝડપથી એડમિન મેળવી શકતો નથી, તો તેનો અર્થ એ છે કે મારે વધુ જોવાની જરૂર છે. અને હું તમારી દેખરેખની મદદથી શોધી શકું છું.

સંભવતઃ દરેક જણ Habré પર સમાન લેખો વાંચે છે, અને મોનિટરિંગ મોનિટરિંગ નેમસ્પેસમાં સ્થિત છે. સુકાન ચાર્ટ દરેક માટે લગભગ સમાન કહેવાય છે. હું અનુમાન કરી રહ્યો છું કે જો તમે સુકાન સ્થિર/પ્રોમિથિયસ ઇન્સ્ટોલ કરશો, તો તમે લગભગ સમાન નામો સાથે સમાપ્ત થશો. અને મોટે ભાગે મારે તમારા ક્લસ્ટરમાં DNS નામનું અનુમાન લગાવવું પડશે નહીં. કારણ કે તે પ્રમાણભૂત છે.

આગળ અમારી પાસે ચોક્કસ dev ns છે, જેમાં તમે ચોક્કસ પોડ ચલાવી શકો છો. અને પછી આ પોડમાંથી આના જેવું કંઈક કરવું ખૂબ જ સરળ છે:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics એ પ્રોમિથિયસ નિકાસકારોમાંથી એક છે જે કુબરનેટ્સ APIમાંથી જ મેટ્રિક્સ એકત્રિત કરે છે. ત્યાં ઘણો ડેટા છે, તમારા ક્લસ્ટરમાં શું ચાલી રહ્યું છે, તે શું છે, તમને તેની સાથે કઈ સમસ્યાઓ છે.

એક સરળ ઉદાહરણ તરીકે:

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

બિનઅધિકૃત પોડમાંથી સરળ કર્લ વિનંતી કરીને, તમે નીચેની માહિતી મેળવી શકો છો. જો તમને ખબર નથી કે તમે કુબરનેટ્સનું કયું સંસ્કરણ ચલાવી રહ્યા છો, તો તે તમને સરળતાથી કહેશે.

અને સૌથી રસપ્રદ બાબત એ છે કે ક્યુબે-સ્ટેટ-મેટ્રિક્સને ઍક્સેસ કરવા ઉપરાંત, તમે પ્રોમિથિયસને સીધો જ સરળતાથી ઍક્સેસ કરી શકો છો. તમે ત્યાંથી મેટ્રિક્સ એકત્રિત કરી શકો છો. તમે ત્યાંથી મેટ્રિક્સ પણ બનાવી શકો છો. સૈદ્ધાંતિક રીતે પણ, તમે પ્રોમિથિયસના ક્લસ્ટરમાંથી આવી ક્વેરી બનાવી શકો છો, જે તેને બંધ કરી દેશે. અને તમારું મોનિટરિંગ ક્લસ્ટરમાંથી એકસાથે કામ કરવાનું બંધ કરશે.

અને અહીં પ્રશ્ન ઊભો થાય છે કે શું કોઈ બાહ્ય મોનિટરિંગ તમારા મોનિટરિંગ પર નજર રાખે છે. મને મારા માટે કોઈ પરિણામ વિના કુબરનેટ્સ ક્લસ્ટરમાં કામ કરવાની તક મળી. તમને એ પણ ખબર નહીં પડે કે હું ત્યાં કામ કરી રહ્યો છું, કારણ કે ત્યાં હવે કોઈ દેખરેખ નથી.

PSP ની જેમ, એવું લાગે છે કે સમસ્યા એ છે કે આ બધી ફેન્સી ટેક્નોલોજીઓ - કુબરનેટ્સ, પ્રોમિથિયસ - તે કામ કરતી નથી અને છિદ્રોથી ભરેલી છે. ખરેખર નથી.

આવી વસ્તુ છે - નેટવર્ક નીતિ.

જો તમે સામાન્ય એડમિન છો, તો સંભવતઃ તમે નેટવર્ક પોલિસી વિશે જાણતા હશો કે આ માત્ર એક બીજું yaml છે, જેમાંથી ઘણા બધા ક્લસ્ટરમાં પહેલેથી જ છે. અને કેટલીક નેટવર્ક નીતિઓની ચોક્કસપણે જરૂર નથી. અને જો તમે નેટવર્ક પોલિસી શું છે તે વાંચો કે તે કુબરનેટ્સની યામલ ફાયરવોલ છે, તે તમને નેમસ્પેસ વચ્ચે, પોડ્સ વચ્ચેના ઍક્સેસ અધિકારોને મર્યાદિત કરવાની મંજૂરી આપે છે, તો તમે ચોક્કસપણે નક્કી કર્યું છે કે કુબરનેટ્સમાં yaml ફોર્મેટમાં ફાયરવોલ આગામી એબ્સ્ટ્રેક્શન્સ પર આધારિત છે. ... ના, ના. આ ચોક્કસપણે જરૂરી નથી.

જો તમે તમારા સુરક્ષા નિષ્ણાતોને કહ્યું ન હોય કે તમારા કુબરનેટ્સનો ઉપયોગ કરીને તમે ખૂબ જ સરળ અને સરળ ફાયરવોલ બનાવી શકો છો, અને તે ખૂબ જ દાણાદાર પણ છે. જો તેઓ હજી સુધી આ જાણતા નથી અને તમને પરેશાન કરતા નથી: "સારું, મને આપો, મને આપો..." તો પછી કોઈ પણ સંજોગોમાં, તમારે તમારા ક્લસ્ટરમાંથી ખેંચી શકાય તેવા કેટલાક સેવા સ્થાનોની ઍક્સેસને અવરોધિત કરવા માટે નેટવર્ક નીતિની જરૂર છે. કોઈપણ અધિકૃતતા વિના.

મેં આપેલા ઉદાહરણની જેમ, તમે કુબેર્નેટસ ક્લસ્ટરમાં કોઈપણ નેમસ્પેસમાંથી કુબે સ્ટેટ મેટ્રિક્સ ખેંચી શકો છો. નેટવર્ક નીતિઓએ અન્ય તમામ નેમસ્પેસથી મોનિટરિંગ નેમસ્પેસની ઍક્સેસ બંધ કરી દીધી છે અને બસ આટલું જ: કોઈ ઍક્સેસ નથી, કોઈ સમસ્યા નથી. અસ્તિત્વમાં છે તે તમામ ચાર્ટમાં, પ્રમાણભૂત પ્રોમિથિયસ અને પ્રોમિથિયસ બંને જે ઓપરેટરમાં છે, તેમના માટે નેટવર્ક નીતિઓને સક્ષમ કરવા માટે સુકાન મૂલ્યોમાં ફક્ત એક વિકલ્પ છે. તમારે ફક્ત તેને ચાલુ કરવાની જરૂર છે અને તે કાર્ય કરશે.

અહીં ખરેખર એક સમસ્યા છે. સામાન્ય દાઢીવાળા એડમિન હોવાને કારણે, તમે સંભવતઃ નક્કી કર્યું છે કે નેટવર્ક નીતિઓની જરૂર નથી. અને Habr જેવા સંસાધનો પરના તમામ પ્રકારના લેખો વાંચ્યા પછી, તમે નક્કી કર્યું કે ફલાલીન, ખાસ કરીને હોસ્ટ-ગેટવે મોડ સાથે, તમે પસંદ કરી શકો તે શ્રેષ્ઠ વસ્તુ છે.

મારે શું કરવું જોઈએ?

તમે તમારા Kubernetes ક્લસ્ટરમાં જે નેટવર્ક સોલ્યુશન ધરાવો છો તેને ફરીથી ગોઠવવાનો પ્રયાસ કરી શકો છો, તેને કંઈક વધુ કાર્યાત્મક સાથે બદલવાનો પ્રયાસ કરી શકો છો. એ જ કેલિકો માટે, ઉદાહરણ તરીકે. પરંતુ હું હમણાં જ કહેવા માંગુ છું કે કુબરનેટ્સ વર્કિંગ ક્લસ્ટરમાં નેટવર્ક સોલ્યુશન બદલવાનું કાર્ય તદ્દન બિન-તુચ્છ છે. મેં તેને બે વાર હલ કર્યું (બંને વખત, જો કે, સૈદ્ધાંતિક રીતે), પરંતુ અમે તેને સ્લર્મ્સમાં કેવી રીતે કરવું તે પણ બતાવ્યું. અમારા વિદ્યાર્થીઓ માટે, અમે કુબરનેટ્સ ક્લસ્ટરમાં નેટવર્ક સોલ્યુશન કેવી રીતે બદલવું તે બતાવ્યું. સૈદ્ધાંતિક રીતે, તમે ખાતરી કરવાનો પ્રયાસ કરી શકો છો કે ઉત્પાદન ક્લસ્ટર પર કોઈ ડાઉનટાઇમ નથી. પરંતુ તમે કદાચ સફળ થશો નહીં.

અને સમસ્યા ખરેખર ખૂબ જ સરળ રીતે ઉકેલવામાં આવે છે. ક્લસ્ટરમાં પ્રમાણપત્રો છે, અને તમે જાણો છો કે તમારા પ્રમાણપત્રો એક વર્ષમાં સમાપ્ત થઈ જશે. ઠીક છે, અને સામાન્ય રીતે ક્લસ્ટરમાં પ્રમાણપત્રો સાથેનો સામાન્ય ઉકેલ - આપણે શા માટે ચિંતા કરી રહ્યા છીએ, અમે નજીકમાં એક નવું ક્લસ્ટર બનાવીશું, જૂનાને સડી જવા દઈશું અને બધું ફરીથી ગોઠવીશું. સાચું, જ્યારે તે સડી જાય છે, ત્યારે આપણે એક દિવસ માટે બેસવું પડશે, પરંતુ અહીં એક નવું ક્લસ્ટર છે.

જ્યારે તમે નવું ક્લસ્ટર ઊભું કરો છો, ત્યારે તે જ સમયે ફલાલીનને બદલે કેલિકો દાખલ કરો.

જો તમારા પ્રમાણપત્રો સો વર્ષ માટે જારી કરવામાં આવે અને તમે ક્લસ્ટરને ફરીથી ગોઠવવાના ન હોવ તો શું કરવું? કુબે-આરબીએસી-પ્રોક્સી જેવી વસ્તુ છે. આ એક ખૂબ જ સરસ વિકાસ છે, તે તમને કુબરનેટ્સ ક્લસ્ટરમાં કોઈપણ પોડમાં સાઇડકાર કન્ટેનર તરીકે પોતાને એમ્બેડ કરવાની મંજૂરી આપે છે. અને તે ખરેખર કુબરનેટ્સના આરબીએસી દ્વારા આ પોડમાં અધિકૃતતા ઉમેરે છે.

એક સમસ્યા છે. અગાઉ, આ કુબે-આરબીએસી-પ્રોક્સી સોલ્યુશન ઓપરેટરના પ્રોમિથિયસમાં બનાવવામાં આવ્યું હતું. પરંતુ પછી તે ગયો હતો. હવે આધુનિક સંસ્કરણો એ હકીકત પર આધાર રાખે છે કે તમારી પાસે નેટવર્ક નીતિ છે અને તેનો ઉપયોગ કરીને તેને બંધ કરો. અને તેથી આપણે ચાર્ટને થોડો ફરીથી લખવો પડશે. હકીકતમાં, જો તમે જાઓ આ ભંડાર, સાઇડકાર તરીકે આનો ઉપયોગ કેવી રીતે કરવો તેના ઉદાહરણો છે, અને ચાર્ટને ન્યૂનતમ રીતે ફરીથી લખવા પડશે.

એક વધુ નાની સમસ્યા છે. પ્રોમિથિયસ માત્ર એક જ વ્યક્તિ નથી જે તેના મેટ્રિક્સ ફક્ત કોઈને પણ આપે છે. અમારા બધા કુબરનેટ્સ ક્લસ્ટર ઘટકો પણ તેમના પોતાના મેટ્રિક્સ પરત કરવામાં સક્ષમ છે.

પરંતુ મેં પહેલેથી જ કહ્યું તેમ, જો તમે ક્લસ્ટરને ઍક્સેસ કરી શકતા નથી અને માહિતી એકત્રિત કરી શકતા નથી, તો તમે ઓછામાં ઓછું થોડું નુકસાન કરી શકો છો.

તેથી હું ઝડપથી બે રીતો બતાવીશ કે કુબરનેટ્સ ક્લસ્ટરને કેવી રીતે બરબાદ કરી શકાય.

જ્યારે હું તમને આ કહીશ ત્યારે તમે હસશો, આ બે વાસ્તવિક જીવનના કિસ્સા છે.

પદ્ધતિ એક. સંસાધન અવક્ષય.

ચાલો બીજો ખાસ પોડ લોંચ કરીએ. તેમાં આ પ્રકારનો વિભાગ હશે.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

જેમ તમે જાણો છો, વિનંતીઓ એ CPU અને મેમરીનો જથ્થો છે જે વિનંતીઓ સાથે ચોક્કસ પોડ્સ માટે હોસ્ટ પર આરક્ષિત છે. જો અમારી પાસે કુબરનેટ્સ ક્લસ્ટરમાં ચાર-કોર હોસ્ટ હોય, અને ચાર CPU પોડ ત્યાં વિનંતીઓ સાથે આવે, તો તેનો અર્થ એ છે કે વિનંતીઓ સાથેના વધુ પોડ્સ આ હોસ્ટ પર આવી શકશે નહીં.

જો હું આવી પોડ ચલાવીશ, તો હું આદેશ ચલાવીશ:

$ kubectl scale special-pod --replicas=...

પછી અન્ય કોઈ કુબરનેટ્સ ક્લસ્ટરમાં જમાવટ કરી શકશે નહીં. કારણ કે તમામ નોડ્સ વિનંતીઓ સમાપ્ત થઈ જશે. અને આમ હું તમારું કુબરનેટ્સ ક્લસ્ટર બંધ કરીશ. જો હું આ સાંજે કરું, તો હું લાંબા સમય સુધી જમાવટ બંધ કરી શકું છું.

જો આપણે કુબરનેટીસ દસ્તાવેજીકરણ પર ફરી નજર કરીએ, તો આપણે આ વસ્તુને લિમિટ રેન્જ તરીકે ઓળખીશું. તે ક્લસ્ટર ઑબ્જેક્ટ્સ માટે સંસાધનો સેટ કરે છે. તમે yaml માં લિમિટ રેન્જ ઑબ્જેક્ટ લખી શકો છો, તેને અમુક નેમસ્પેસ પર લાગુ કરી શકો છો - અને પછી આ નેમસ્પેસમાં તમે કહી શકો છો કે તમારી પાસે પોડ્સ માટે ડિફોલ્ટ, મહત્તમ અને ન્યૂનતમ સંસાધનો છે.

આવી વસ્તુની મદદથી, અમે ટીમોના ચોક્કસ ઉત્પાદન નેમસ્પેસમાં વપરાશકર્તાઓને તેમના પોડ પર તમામ પ્રકારની બીભત્સ વસ્તુઓ સૂચવવાની ક્ષમતામાં મર્યાદિત કરી શકીએ છીએ. પરંતુ કમનસીબે, જો તમે વપરાશકર્તાને કહો કે તેઓ એક કરતાં વધુ CPU માટે વિનંતીઓ સાથે પોડ્સ લોન્ચ કરી શકતા નથી, તો પણ આવા અદ્ભુત સ્કેલ આદેશ છે, અથવા તેઓ ડેશબોર્ડ દ્વારા સ્કેલ કરી શકે છે.

અને આ તે છે જ્યાં પદ્ધતિ નંબર બે આવે છે. અમે 11 પોડ્સ લોન્ચ કરીએ છીએ. તે અગિયાર અબજ છે. આ એટલા માટે નથી કે હું આવા નંબર સાથે આવ્યો છું, પરંતુ કારણ કે મેં તે જાતે જોયું છે.

વાસ્તવિક વાર્તા. મોડી સાંજે હું ઓફિસેથી નીકળવાનો હતો. હું વિકાસકર્તાઓના જૂથને ખૂણામાં બેઠેલા જોઉં છું, તેમના લેપટોપ સાથે ઉન્માદપૂર્વક કંઈક કરી રહ્યું છે. હું છોકરાઓ પાસે જાઉં છું અને પૂછું છું: "તમને શું થયું છે?"

થોડા સમય પહેલા, સાંજે નવ વાગ્યાની આસપાસ, એક વિકાસકર્તા ઘરે જવા માટે તૈયાર થઈ રહ્યો હતો. અને મેં નક્કી કર્યું: "હવે હું મારી અરજીને એક કરીશ." મેં એક દબાવ્યું, પરંતુ ઇન્ટરનેટ થોડું ધીમું થયું. તેણે ફરીથી એકને દબાવ્યું, તેણે એકને દબાવ્યું, અને Enter પર ક્લિક કર્યું. હું કરી શકે છે તે બધું પર poked. પછી ઇન્ટરનેટ જીવનમાં આવ્યું - અને બધું આ નંબર સુધી ઘટાડવાનું શરૂ થયું.

સાચું, આ વાર્તા કુબરનેટ્સ પર બની ન હતી; તે સમયે તે નોમડ હતી. તે એ હકીકત સાથે સમાપ્ત થયું કે નોમાડને માપવાના સતત પ્રયાસોથી રોકવાના અમારા પ્રયાસોના એક કલાક પછી, નોમેડે જવાબ આપ્યો કે તે સ્કેલિંગ બંધ કરશે નહીં અને બીજું કંઈ કરશે નહીં. "હું થાકી ગયો છું, હું જાઉં છું." અને તે વળાંક આવ્યો.

સ્વાભાવિક રીતે, મેં કુબરનેટ્સ પર તે જ કરવાનો પ્રયાસ કર્યો. કુબરનેટ્સ અગિયાર અબજ શીંગોથી ખુશ ન હતા, તેણે કહ્યું: “હું કરી શકતો નથી. આંતરિક મુખ રક્ષકો કરતાં વધી જાય છે." પરંતુ 1 શીંગો કરી શકે છે.

એક બિલિયનના જવાબમાં, ક્યુબ પોતાનામાં પાછું ખેંચ્યું ન હતું. તેણે ખરેખર સ્કેલિંગ શરૂ કર્યું. પ્રક્રિયા જેટલી આગળ વધતી ગઈ, તેને નવા શીંગો બનાવવામાં વધુ સમય લાગ્યો. પરંતુ હજુ પણ પ્રક્રિયા ચાલુ હતી. એકમાત્ર સમસ્યા એ છે કે જો હું મારા નેમસ્પેસમાં અમર્યાદિત રીતે પોડ્સ લોન્ચ કરી શકું, તો પછી વિનંતીઓ અને મર્યાદાઓ વિના પણ હું કેટલાક કાર્યો સાથે એટલા બધા પોડ્સ લોન્ચ કરી શકું છું કે આ કાર્યોની મદદથી નોડ્સ મેમરીમાં, CPU માં ઉમેરવાનું શરૂ કરશે. જ્યારે હું ઘણા બધા પોડ્સ લોન્ચ કરું છું, ત્યારે તેમાંથી માહિતી સ્ટોરેજમાં જવી જોઈએ, એટલે કે વગેરે. અને જ્યારે ઘણી બધી માહિતી ત્યાં પહોંચે છે, ત્યારે સ્ટોરેજ ખૂબ ધીમેથી પાછું આવવાનું શરૂ કરે છે - અને કુબરનેટ્સ નીરસ થવા લાગે છે.

અને એક વધુ સમસ્યા... જેમ તમે જાણો છો, કુબરનેટ્સ કંટ્રોલ એલિમેન્ટ્સ એ એક કેન્દ્રિય વસ્તુ નથી, પરંતુ ઘણા ઘટકો છે. ખાસ કરીને, ત્યાં એક નિયંત્રક મેનેજર, શેડ્યૂલર અને તેથી વધુ છે. આ બધા લોકો એક જ સમયે બિનજરૂરી, મૂર્ખ કામ કરવાનું શરૂ કરશે, જે સમય જતાં વધુને વધુ સમય લાગશે. કંટ્રોલર મેનેજર નવા પોડ્સ બનાવશે. શેડ્યૂલર તેમના માટે નવો નોડ શોધવાનો પ્રયાસ કરશે. તમારા ક્લસ્ટરમાં ટૂંક સમયમાં તમારી પાસે નવા નોડ્સ સમાપ્ત થવાની સંભાવના છે. કુબરનેટ્સ ક્લસ્ટર ધીમા અને ધીમા કામ કરવાનું શરૂ કરશે.

પણ મેં હજી આગળ જવાનું નક્કી કર્યું. જેમ તમે જાણો છો, કુબરનેટ્સમાં સેવા તરીકે ઓળખાતી વસ્તુ છે. ઠીક છે, તમારા ક્લસ્ટરોમાં મૂળભૂત રીતે, સંભવતઃ, સેવા IP કોષ્ટકોનો ઉપયોગ કરીને કાર્ય કરે છે.

જો તમે એક અબજ પોડ્સ ચલાવો છો, ઉદાહરણ તરીકે, અને પછી કુબરનેટિસને નવી સેવાઓ બનાવવા માટે દબાણ કરવા માટે સ્ક્રિપ્ટનો ઉપયોગ કરો:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

ક્લસ્ટરના તમામ ગાંઠો પર, વધુ અને વધુ નવા iptables નિયમો લગભગ એકસાથે જનરેટ કરવામાં આવશે. વધુમાં, દરેક સેવા માટે એક અબજ iptables નિયમો જનરેટ કરવામાં આવશે.

મેં આ આખી વાત કેટલાય હજાર, દસ સુધી તપાસી. અને સમસ્યા એ છે કે આ થ્રેશોલ્ડ પર પહેલેથી જ નોડ પર ssh કરવું ખૂબ જ સમસ્યારૂપ છે. કારણ કે પેકેટો, ઘણી બધી સાંકળોમાંથી પસાર થતાં, ખૂબ સારા લાગવા માંડે છે.

અને આ પણ, કુબરનેટ્સની મદદથી હલ કરવામાં આવે છે. આવા રિસોર્સ ક્વોટા ઑબ્જેક્ટ છે. ક્લસ્ટરમાં નેમસ્પેસ માટે ઉપલબ્ધ સંસાધનો અને ઑબ્જેક્ટ્સની સંખ્યા સેટ કરે છે. આપણે કુબરનેટીસ ક્લસ્ટરના દરેક નેમસ્પેસમાં yaml ઑબ્જેક્ટ બનાવી શકીએ છીએ. આ ઑબ્જેક્ટનો ઉપયોગ કરીને, અમે કહી શકીએ છીએ કે અમારી પાસે આ નેમસ્પેસ માટે ચોક્કસ સંખ્યામાં વિનંતીઓ અને મર્યાદાઓ ફાળવવામાં આવી છે, અને પછી અમે કહી શકીએ કે આ નેમસ્પેસમાં 10 સેવાઓ અને 10 પોડ્સ બનાવવા શક્ય છે. અને એક જ વિકાસકર્તા ઓછામાં ઓછું સાંજે પોતાને ગૂંગળાવી શકે છે. કુબરનેટ્સ તેને કહેશે: "તમે તમારા શીંગોને તે રકમ સુધી માપી શકતા નથી, કારણ કે સંસાધન ક્વોટા કરતાં વધી જાય છે." બસ, સમસ્યા હલ થઈ ગઈ. અહીં દસ્તાવેજીકરણ.

આ સંદર્ભમાં એક સમસ્યારૂપ મુદ્દો ઉભો થાય છે. તમને લાગે છે કે કુબરનેટ્સમાં નેમસ્પેસ બનાવવાનું કેટલું મુશ્કેલ બની રહ્યું છે. તેને બનાવવા માટે, આપણે ઘણી બધી બાબતો ધ્યાનમાં લેવાની જરૂર છે.

સંસાધન ક્વોટા + મર્યાદા શ્રેણી + RBAC
• નેમસ્પેસ બનાવો
અંદર એક મર્યાદા રેન્જ બનાવો
• અંદર રિસોર્સક્વોટા બનાવો
• CI માટે સર્વિસ એકાઉન્ટ બનાવો
• CI અને વપરાશકર્તાઓ માટે રોલબાઈન્ડિંગ બનાવો
• વૈકલ્પિક રીતે જરૂરી સેવા પોડ લોંચ કરો

તેથી, હું મારા વિકાસને શેર કરવાની આ તક લેવા માંગુ છું. SDK ઓપરેટર તરીકે ઓળખાતી આવી વસ્તુ છે. કુબરનેટ્સ ક્લસ્ટર માટે તેના માટે ઓપરેટરો લખવાનો આ એક માર્ગ છે. તમે Ansible નો ઉપયોગ કરીને નિવેદનો લખી શકો છો.

શરૂઆતમાં તે જવાબીબલમાં લખાયેલું હતું, અને પછી મેં જોયું કે ત્યાં એક SDK ઓપરેટર છે અને મેં જવાબી ભૂમિકાને ઓપરેટરમાં ફરીથી લખી છે. આ નિવેદન તમને કુબરનેટ્સ ક્લસ્ટરમાં એક ઑબ્જેક્ટ બનાવવા માટે પરવાનગી આપે છે જેને આદેશ કહેવાય છે. આદેશની અંદર, તે તમને yaml માં આ આદેશ માટે પર્યાવરણનું વર્ણન કરવાની મંજૂરી આપે છે. અને ટીમના વાતાવરણમાં, તે અમને વર્ણન કરવાની મંજૂરી આપે છે કે અમે ઘણા સંસાધનો ફાળવી રહ્યા છીએ.

થોડું આ સમગ્ર જટિલ પ્રક્રિયાને સરળ બનાવે છે.

અને નિષ્કર્ષમાં. આ બધાનું શું કરવું?
પ્રથમ. પોડ સુરક્ષા નીતિ સારી છે. અને એ હકીકત હોવા છતાં કે કુબરનેટ્સ ઇન્સ્ટોલર્સમાંથી કોઈ પણ આજ સુધી તેનો ઉપયોગ કરતું નથી, તમારે હજી પણ તમારા ક્લસ્ટરમાં તેનો ઉપયોગ કરવાની જરૂર છે.

નેટવર્ક પોલિસી એ માત્ર બીજી બિનજરૂરી સુવિધા નથી. ક્લસ્ટરમાં આ ખરેખર જરૂરી છે.

LimitRange/ResourceQuota - તેનો ઉપયોગ કરવાનો સમય આવી ગયો છે. અમે લાંબા સમય પહેલા આનો ઉપયોગ કરવાનું શરૂ કર્યું, અને લાંબા સમયથી મને ખાતરી હતી કે દરેક તેનો ઉપયોગ કરી રહ્યા છે. તે બહાર આવ્યું છે કે આ દુર્લભ છે.

રિપોર્ટ દરમિયાન મેં જે ઉલ્લેખ કર્યો છે તે ઉપરાંત, ત્યાં બિનદસ્તાવેજીકૃત સુવિધાઓ છે જે તમને ક્લસ્ટર પર હુમલો કરવાની મંજૂરી આપે છે. તાજેતરમાં રિલીઝ થયેલ કુબરનેટીસ નબળાઈઓનું વિસ્તૃત વિશ્લેષણ.

કેટલીક બાબતો ખૂબ જ દુઃખદ અને દુઃખદાયક હોય છે. ઉદાહરણ તરીકે, અમુક શરતો હેઠળ, કુબરનેટ્સ ક્લસ્ટરમાંના ક્યુબેલેટ્સ અનધિકૃત વપરાશકર્તાને વોરલોક ડિરેક્ટરીની સામગ્રી આપી શકે છે.

અહીં મેં તમને જે કહ્યું તે બધું કેવી રીતે પુનઃઉત્પાદન કરવું તેના પર સૂચનાઓ છે. રિસોર્સક્વોટા અને પોડ સિક્યુરિટી પોલિસી કેવી દેખાય છે તેના પ્રોડક્શન ઉદાહરણો સાથેની ફાઇલો છે. અને તમે આ બધાને સ્પર્શ કરી શકો છો.

સૌનો આભાર.

સોર્સ: www.habr.com