Kubernetes පොකුරේ සිදුරු සවි කිරීම. DevOpsConf වෙතින් වාර්තා කිරීම සහ පිටපත

සවුත්බ්‍රිජ් විසඳුම් ගෘහ නිර්මාණ ශිල්පී සහ ස්ලර්ම් ගුරුවරයා වන Pavel Selivanov, DevOpsConf 2019 හි ඉදිරිපත් කිරීමක් සිදු කළේය. මෙම කතාව Kubernetes "Slurm Mega" පිළිබඳ ගැඹුරු පාඨමාලාවේ මාතෘකා වලින් එකකි.

Slurm Basic: Kubernetes වෙත හැඳින්වීමක් නොවැම්බර් 18-20 දිනවල මොස්කව්හිදී පැවැත්වේ.
Slurm Mega: Kubernetes ගේ තොප්පිය යට බැලීම - මොස්කව්, නොවැම්බර් 22-24.
Slurm Online: Kubernetes පාඨමාලා දෙකම සෑම විටම ලබා ගත හැකිය.

කප්පාදුවට පහළින් වාර්තාවේ පිටපතක් ඇත.

සුභ සන්ධ්‍යාවක්, සගයන් සහ ඔවුන්ට අනුකම්පා කරන අය. අද මම ආරක්ෂාව ගැන කතා කරන්නම්.

අද ශාලාවේ බොහෝ ආරක්ෂකයින් සිටින බව මට පෙනේ. මම ඔබට සුපුරුදු පරිදි ආරක්ෂිත ලෝකයේ නියමයන් භාවිතා කරන්නේ නම් කල්තියාම මම ඔබෙන් සමාව අයදිමි.

එය එසේ වූයේ මීට මාස හයකට පමණ පෙර මට එක් පොදු කුබර්නෙට්ස් පොකුරක් හමු විය. පොදු යන්නෙන් අදහස් කරන්නේ නාම අවකාශ n වන සංඛ්‍යාවක් ඇති බවයි; මෙම නාම අවකාශයන්හි ඔවුන්ගේ නාම අවකාශයේ හුදකලා වූ පරිශීලකයින් සිටී. මෙම සියලුම පරිශීලකයින් විවිධ සමාගම්වලට අයත් වේ. හොඳයි, මෙම පොකුර CDN ලෙස භාවිතා කළ යුතු යැයි උපකල්පනය කරන ලදී. එනම්, ඔවුන් ඔබට පොකුරක් ලබා දෙයි, ඔවුන් ඔබට එහි පරිශීලකයෙකු ලබා දෙයි, ඔබ ඔබේ නාම අවකාශයට යන්න, ඔබේ පෙරමුණු යොදවන්න.

මගේ පෙර සමාගම එවැනි සේවාවක් විකිණීමට උත්සාහ කළා. ඒවගේම මේ විසඳුම සුදුසුද නැද්ද කියලා බලන්න පොකුර පොකුරන්න කියලා.

මම මේ පොකුරට ආවා. මට සීමිත අයිතිවාසිකම්, සීමිත නාම අවකාශයක් ලබා දුන්නා. එතන හිටපු කට්ටියට තේරුණා ආරක්ෂාව මොකක්ද කියලා. ඔවුන් Kubernetes හි භූමිකා පාදක ප්‍රවේශ පාලනය (RBAC) ගැන කියෙව්වා - සහ මට යෙදවීම් වලින් වෙන වෙනම කරල් දියත් කිරීමට නොහැකි වන පරිදි ඔවුන් එය විකෘති කළා. යෙදවීමකින් තොරව පොඩ් එකක් දියත් කිරීමෙන් මා විසඳීමට උත්සාහ කළ ගැටලුව මට මතක නැත, නමුත් මට ඇත්තටම අවශ්‍ය වූයේ පොඩ් එකක් දියත් කිරීමටයි. වාසනාව සඳහා, මම පොකුරේ මට ඇති අයිතිවාසිකම් මොනවාද, මට කළ හැකි දේ, මට කළ නොහැකි දේ සහ ඔවුන් එහි අවුල් කර ඇති දේ බැලීමට මම තීරණය කළෙමි. ඒ සමඟම, RBAC හි ඔවුන් වැරදි ලෙස වින්‍යාස කර ඇති දේ මම ඔබට කියමි.

එය එසේ සිදු වූයේ මිනිත්තු දෙකකින් මට ඔවුන්ගේ පොකුරට පරිපාලකයෙකු ලැබී, අසල්වැසි නාම අවකාශයන් සියල්ල දෙස බැලූ අතර, දැනටමත් සේවාව මිලදී ගෙන යොදවා ඇති සමාගම්වල ධාවන නිෂ්පාදන පෙරමුණු එහි දක්නට ලැබුණි. කාගේ හරි ඉස්සරහට ගිහින් ප්‍රධාන පිටුවේ කුණුහරුපයක් දාන එක මට යන්තම් නවත්තන්න පුළුවන් වුණා.

මම මෙය කළ ආකාරය සහ මෙයින් ආරක්ෂා වන්නේ කෙසේද යන්න මම ඔබට උදාහරණ සමඟ කියන්නම්.

නමුත් මුලින්ම මට මාව හඳුන්වා දෙන්න. මගේ නම Pavel Selivanov. මම සවුත්බ්‍රිජ්හි ගෘහ නිර්මාණ ශිල්පියෙක්. මට Kubernetes, DevOps සහ සියලු ආකාරයේ විසිතුරු දේවල් තේරෙනවා. සවුත්බ්‍රිජ් ඉංජිනේරුවන් සහ මම මේ සියල්ල ගොඩනඟමින් සිටින අතර මම උපදෙස් දෙමි.

අපගේ ප්‍රධාන ක්‍රියාකාරකම් වලට අමතරව, අපි මෑතකදී Slurms නමින් ව්‍යාපෘති දියත් කළෙමු. අපි උත්සාහ කරන්නේ Kubernetes සමඟ වැඩ කිරීමේ අපගේ හැකියාව ජනතාව අතරට ගෙන ඒමට, K8s සමඟ වැඩ කිරීමට අනෙක් අයටද ඉගැන්වීමට ය.

මම අද කුමක් ගැන කතා කරන්නද? වාර්තාවේ මාතෘකාව පැහැදිලිය - Kubernetes පොකුරේ ආරක්ෂාව ගැන. නමුත් මෙම මාතෘකාව ඉතා විශාල බව මට වහාම පැවසීමට අවශ්‍යයි - එබැවින් මම අනිවාර්යයෙන්ම කතා නොකරන දේ වහාම පැහැදිලි කිරීමට මට අවශ්‍යය. අන්තර්ජාලයේ දැනටමත් සිය ගුණයකින් භාවිතා කර ඇති හැක්නිඩ් වචන ගැන මම කතා නොකරමි. සියලු වර්ගවල RBAC සහ සහතික.

මම Kubernetes පොකුරක් තුළ ආරක්ෂාව ගැන මට සහ මගේ සගයන්ට වේදනා ගෙන දෙන දේ ගැන කතා කරන්නම්. Kubernetes පොකුරු සපයන සැපයුම්කරුවන් අතර සහ අප වෙත පැමිණෙන සේවාදායකයින් අතර මෙම ගැටළු අපි දකිමු. සහ වෙනත් උපදේශන පරිපාලක සමාගම් වලින් අප වෙත පැමිණෙන සේවාදායකයින්ගෙන් පවා. එනම්, ඛේදවාචකයේ පරිමාණය ඇත්ත වශයෙන්ම ඉතා විශාලය.

මම අද කතා කරන කරුණු තුනක් වචනාර්ථයෙන් ඇත:

1. පරිශීලක අයිතිවාසිකම් vs පොඩ් අයිතිවාසිකම්. පරිශීලක අයිතිවාසිකම් සහ පොඩ් අයිතිවාසිකම් එකම දෙයක් නොවේ.
2. පොකුර පිළිබඳ තොරතුරු රැස් කිරීම. ඔබට මෙම පොකුරේ විශේෂ අයිතිවාසිකම් නොමැතිව පොකුරකින් ඔබට අවශ්‍ය සියලුම තොරතුරු එකතු කර ගත හැකි බව මම පෙන්වන්නම්.
3. පොකුරට DoS ප්‍රහාරය. අපිට තොරතුරු එකතු කරන්න බැරි නම් ඕනම අවස්ථාවක පොකුරක් දාන්න පුළුවන්. මම පොකුරු පාලන මූලද්රව්ය මත DoS ප්රහාර ගැන කතා කරන්නම්.

මම සඳහන් කරන තවත් සාමාන්‍ය දෙයක් නම්, මම මේ සියල්ල පරීක්ෂා කළේ කුමක් ද යන්නයි, ඒ සියල්ල ක්‍රියාත්මක වන බව මට නිසැකවම පැවසිය හැකිය.

අපි පදනමක් ලෙස Kubespray භාවිතා කරමින් Kubernetes පොකුරක් ස්ථාපනය කරමු. කවුරුහරි නොදන්නවා නම්, මෙය ඇත්තටම Ansible සඳහා භූමිකාවන් සමූහයකි. අපි එය අපගේ කාර්යයේදී නිරන්තරයෙන් භාවිතා කරමු. හොඳ දෙය නම් ඔබට එය ඕනෑම තැනක රෝල් කළ හැකිය - ඔබට එය යකඩ කැබලිවලට හෝ කොහේ හරි වලාකුළකට පෙරළා ගත හැකිය. එක් ස්ථාපන ක්රමයක් සියල්ල සඳහා ප්රතිපත්තිමය වශයෙන් ක්රියා කරයි.

මෙම පොකුරේ මට Kubernetes v1.14.5 ඇත. අපි සලකා බලනු ලබන සම්පූර්ණ කියුබ් පොකුර නාම අවකාශවලට බෙදා ඇත, එක් එක් නාම අවකාශය වෙනම කණ්ඩායමකට අයත් වන අතර මෙම කණ්ඩායමේ සාමාජිකයින්ට එක් එක් නාම අවකාශයට ප්‍රවේශය ඇත. ඔවුන්ට විවිධ නාම අවකාශවලට යා නොහැක, ඔවුන්ගේම ඒවා පමණි. නමුත් සම්පූර්ණ පොකුරු සඳහා හිමිකම් ඇති යම් පරිපාලක ගිණුමක් තිබේ.

මම පොරොන්දු වුනා අපි මුලින්ම කරන්නේ පොකුරේ පරිපාලක අයිතිවාසිකම් ලබා ගැනීමයි. අපට කුබර්නෙටස් පොකුර බිඳ දමන විශේෂයෙන් සකස් කළ කරල් අවශ්‍ය වේ. අපි කළ යුත්තේ එය Kubernetes පොකුරට යෙදීමයි.

kubectl apply -f pod.yaml

මෙම පොඩ් කුබර්නෙටස් පොකුරේ එක් ස්වාමියෙකු වෙත පැමිණෙනු ඇත. මෙයින් පසු, පොකුර admin.conf නම් ගොනුවක් සතුටින් අප වෙත ආපසු එනු ඇත. Cube හි, මෙම ගොනුව සියලුම පරිපාලක සහතික ගබඩා කරයි, ඒ සමඟම Cluster API වින්‍යාස කරයි. මම හිතන්නේ, Kubernetes පොකුරු වලින් 98%කට පරිපාලක ප්‍රවේශය ලබා ගැනීම ඉතා පහසුයි.

මම නැවතත්, මෙම පොඩ් එක සෑදුවේ ඔබේ පොකුරේ එක් සංවර්ධකයෙකු විසින් ඔහුගේ යෝජනා එක් කුඩා නාම අවකාශයකට යෙදවීමට ප්‍රවේශය ඇති, ඒ සියල්ල RBAC විසින් තද කර ඇත. ඔහුට කිසිම අයිතියක් තිබුණේ නැහැ. කෙසේ වෙතත්, සහතිකය ආපසු ලබා දෙන ලදී.

දැන් විශේෂයෙන් සකස් කරන ලද කරල් ගැන. අපි එය ඕනෑම රූපයක් මත ධාවනය කරමු. අපි උදාහරණයක් ලෙස debian:jessie ගනිමු.

අපට මේ දේ ඇත:

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

ඉවසීම යනු කුමක්ද? Kubernetes පොකුරක ස්වාමිවරුන් සාමාන්‍යයෙන් taint ලෙස හඳුන්වන දෙයකින් සලකුණු කර ඇත. තවද මෙම "ආසාදනයේ" සාරය නම්, මාස්ටර් නෝඩ් වලට කරල් පැවරිය නොහැකි බව පවසන බවයි. නමුත් එය "ආසාදනය" ඉවසා සිටින බව කිසිදු කරල්වල සඳහන් කිරීමට කිසිවෙකු වෙහෙසෙන්නේ නැත. ඉවසීමේ අංශය පවසන්නේ සමහර නෝඩයකට NoSchedule තිබේ නම්, අපගේ නෝඩය එවැනි ආසාදනයකට ඔරොත්තු දෙන බවයි - සහ ගැටළු නොමැත.

තවද, අපගේ යටි ඉවසීම පමණක් නොව, විශේෂයෙන් මාස්ටර් ඉලක්ක කිරීමට අවශ්ය බව අපි කියමු. මන්ද ස්වාමිවරුන්ට අපට අවශ්ය වඩාත්ම රසවත් දේ ඇත - සියලු සහතික. එමනිසා, අපි nodeSelector යැයි කියමු - තවද අප සතුව මාස්ටර් මත සම්මත ලේබලයක් ඇත, එමඟින් පොකුරේ ඇති සියලුම නෝඩ් වලින් හරියටම මාස්ටර් වන නෝඩ් තෝරා ගැනීමට ඔබට ඉඩ සලසයි.

මෙම කොටස් දෙක සමඟ ඔහු අනිවාර්යයෙන්ම ස්වාමියා වෙත පැමිණෙනු ඇත. තවද ඔහුට එහි වාසය කිරීමට අවසර දෙනු ලැබේ.

නමුත් අපට ස්වාමියා වෙත පැමිණීම පමණක් ප්රමාණවත් නොවේ. මෙය අපට කිසිවක් ලබා නොදේ. ඉතින් ඊළඟට අපිට මේ දේවල් දෙක තියෙනවා.

hostNetwork: true 
hostPID: true 

අප දියත් කරන අපගේ පොඩ් කර්නල් නාම අවකාශයේ, ජාල නාම අවකාශයේ සහ PID නාම අවකාශයේ ජීවත් වන බව අපි සඳහන් කරමු. Pod එක මාස්ටර් මත දියත් කළ පසු, එයට මෙම නෝඩයේ සියලුම සැබෑ, සජීවී අතුරුමුහුණත් දැකීමට හැකි වනු ඇත, සියලු ගමනාගමනයට සවන් දෙන්න සහ සියලු ක්‍රියාවලීන්ගේ PID බලන්න.

එතකොට පොඩි පොඩි දේවල්. etcd ගෙන ඔබට අවශ්‍ය දේ කියවන්න.

වඩාත්ම සිත්ගන්නා කරුණ නම් මෙම Kubernetes විශේෂාංගය වන අතර එය පෙරනිමියෙන් පවතී.

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

තවද එහි සාරය නම්, මෙම පොකුරට අයිතිවාසිකම් නොමැතිව වුවද, අපි දියත් කරන පොඩ් එකෙහි අපට පැවසිය හැක්කේ, අපට hostPath වර්ගයේ පරිමාවක් නිර්මාණය කිරීමට අවශ්‍ය බවයි. මෙයින් අදහස් කරන්නේ අප දියත් කරන ධාරකයෙන් මාර්ගය ලබා ගැනීම සහ එය පරිමාව ලෙස ගැනීමයි. ඊට පස්සේ අපි ඒකට නම කියනවා: සත්කාරක. අපි මෙම සම්පූර්ණ සත්කාරක මාර්ගය පොඩ් එක තුළ සවි කරමු. මෙම උදාහරණයේ, / සත්කාරක නාමාවලිය වෙත.

මම එය නැවත නැවත කියන්නම්. අපි පොඩ් එකට කිව්වා මාස්ටර් ළඟට එන්න කියලා, හොස්ට්නෙට්වර්ක් එකයි හොස්ට්පීඩී එකයි එතනට ගන්න - සහ මේ පොඩ් එක ඇතුලේ මාස්ටර්ගේ සම්පූර්ණ රූට්ම මවුන්ට් කරන්න කියලා.

ඩේබියන් හි අපට බැෂ් ධාවනය වන බවත්, මෙම බැෂ් රූට් යටතේ ක්‍රියාත්මක වන බවත් ඔබට වැටහේ. එනම්, කුබර්නෙට්ස් පොකුරේ කිසිදු අයිතියක් නොමැතිව අපට මාස්ටර් මත මුල් බැස ඇත.

එවිට සම්පූර්ණ කාර්යය වන්නේ උප නාමාවලිය / සත්කාරක / etc / kubernetes / pki වෙත යාමයි, මම වරදවා වටහා නොගන්නේ නම්, එහි ඇති පොකුරේ සියලුම ප්‍රධාන සහතික ලබාගෙන, ඒ අනුව, පොකුරු පරිපාලක වන්න.

ඔබ එය මේ ආකාරයෙන් බැලුවහොත්, මේවා කරල් වල ඇති භයානක අයිතිවාසිකම් කිහිපයකි - පරිශීලකයාට ඇති අයිතිවාසිකම් කුමක් වුවත්:

පොකුරේ කිසියම් නාම අවකාශයක පොඩ් එකක් ධාවනය කිරීමට මට අයිතියක් තිබේ නම්, මෙම පොඩ්ට පෙරනිමියෙන් මෙම හිමිකම් ඇත. මට වරප්‍රසාද ලත් කරල් ධාවනය කළ හැකි අතර, මේවා සාමාන්‍යයෙන් සියලුම හිමිකම් වේ, ප්‍රායෝගිකව නෝඩයේ මුල් බැස ඇත.

මගේ ප්රියතම Root පරිශීලකයා. තවද Kubernetes හට මෙම Run As Non-Root විකල්පය ඇත. මෙය හැකර් වරයෙකුගෙන් ආරක්ෂා වීමකි. "මෝල්ඩේවියානු වෛරසය" යනු කුමක්දැයි ඔබ දන්නවාද? ඔබ හදිසියේ හැකර් කෙනෙකු වී මගේ කුබර්නෙටස් පොකුරට පැමිණියහොත්, දුප්පත් පරිපාලකයින් වන අපි මෙසේ අසමු: “කරුණාකර ඔබ මගේ පොකුර හැක් කරන, මූල නොවන ලෙස ධාවනය කරන ඔබේ පොඩ්ස් වල සඳහන් කරන්න. එසේ නොමැතිනම්, ඔබ ඔබේ පොඩ් එකෙහි ක්‍රියාවලිය root යටතේ ක්‍රියාත්මක වන අතර, ඔබට මාව හැක් කිරීම ඉතා පහසු වනු ඇත. කරුණාකර ඔබෙන් ආරක්ෂා වන්න."

ධාරක මාර්ග පරිමාව, මගේ මතය අනුව, Kubernetes පොකුරකින් අපේක්ෂිත ප්රතිඵලය ලබා ගැනීමට වේගවත්ම ක්රමය වේ.

නමුත් මේ සියල්ල සමඟ කුමක් කළ යුතුද?

Kubernetes හමුවන ඕනෑම සාමාන්‍ය පරිපාලකයෙකුට පැමිණිය යුතු සිතුවිල්ල වන්නේ: “ඔව්, මම ඔයාට කිව්වා, Kubernetes වැඩ කරන්නේ නැහැ. එහි සිදුරු ඇත. ඒ වගේම මුළු කියුබ් එකම ගොන් කතාවක්. ඇත්ත වශයෙන්ම, ලේඛනගත කිරීම වැනි දෙයක් තිබේ, ඔබ එහි බැලුවහොත්, අංශයක් තිබේ Pod ආරක්ෂක ප්‍රතිපත්තිය.

මෙය යමහල් වස්තුවකි - අපට එය කුබර්නෙටස් පොකුරේ නිර්මාණය කළ හැකිය - විශේෂයෙන් කරල් විස්තරයේ ආරක්ෂක අංශ පාලනය කරයි. එනම්, ඇත්ත වශයෙන්ම, එය ආරම්භයේදී කරල්වල ඇති ඕනෑම සත්කාරක ජාලයක්, සත්කාරක PID, ඇතැම් වෙළුම් වර්ග භාවිතා කිරීමේ අයිතිය පාලනය කරයි. Pod Security Policy ආධාරයෙන්, මේ සියල්ල විස්තර කළ හැකිය.

Pod ආරක්ෂණ ප්‍රතිපත්තියේ වඩාත්ම සිත්ගන්නා කරුණ නම්, Kubernetes පොකුරේ, සියලුම PSP ස්ථාපකයන් කිසිදු ආකාරයකින් විස්තර කර නොමැති අතර ඒවා පෙරනිමියෙන් අක්‍රීය කර ඇත. ඇතුළත් කිරීමේ ප්ලගිනය භාවිතයෙන් Pod ආරක්ෂක ප්‍රතිපත්තිය සබල කර ඇත.

හරි, අපි Pod Security Policy එක පොකුරට යොදවමු, අපි කියමු අපිට පරිපාලකයින්ට පමණක් ප්‍රවේශය ඇති නාම අවකාශයේ සේවා පොඩ් කිහිපයක් ඇති බව. අපි කියමු, අනෙක් සෑම අවස්ථාවකම, කරල් වලට සීමිත අයිතිවාසිකම් ඇත. මක්නිසාද යත් බොහෝ විට සංවර්ධකයින්ට ඔබේ පොකුරේ වරප්‍රසාද ලත් කරල් ධාවනය කිරීමට අවශ්‍ය නොවේ.

ඒ වගේම අපිත් එක්ක හැම දෙයක්ම හොඳයි වගේ. අනික අපේ Kubernetes cluster එක විනාඩි දෙකකින් Hack කරන්න බෑ.

ගැටලුවක් තිබේ. බොහෝ දුරට, ඔබට Kubernetes පොකුරක් තිබේ නම්, ඔබේ පොකුරේ අධීක්ෂණය ස්ථාපනය කර ඇත. ඔබේ පොකුරට නිරීක්ෂණ තිබේ නම්, එය ප්‍රොමිතියස් ලෙස හඳුන්වනු ඇතැයි පුරෝකථනය කිරීමට තරම් මම දුරදිග යන්නෙමි.

මම ඔබට කියන්නට යන දෙය Prometheus ක්‍රියාකරු සහ Prometheus යන දෙකටම එහි පිරිසිදු ස්වරූපයෙන් වලංගු වේ. ප්‍රශ්නය නම් මට මෙතරම් ඉක්මනින් පරිපාලකයෙකු පොකුරට ලබා ගත නොහැකි නම්, මෙයින් අදහස් කරන්නේ මට තවත් බැලිය යුතු බවයි. තවද මට ඔබගේ නිරීක්ෂණ ආධාරයෙන් සෙවිය හැක.

බොහෝ විට හැමෝම Habré හි එකම ලිපි කියවිය හැකි අතර, අධීක්‍ෂණය අධීක්ෂණ නාම අවකාශයේ පිහිටා ඇත. හෙල්ම් ප්‍රස්ථාරය සෑම කෙනෙකුටම දළ වශයෙන් එකම ලෙස හැඳින්වේ. මම අනුමාන කරන්නේ ඔබ ස්ථාවර/ප්‍රොමිතියස් ස්ථාපනය කිරීමට හෙල්ම් කළහොත්, ඔබට දළ වශයෙන් එකම නම් ලැබෙනු ඇති බවයි. සහ බොහෝ විට මට ඔබේ පොකුරේ DNS නම අනුමාන කිරීමට පවා සිදු නොවනු ඇත. එය සම්මත නිසා.

මීළඟට අපට නිශ්චිත dev ns එකක් ඇත, එහි ඔබට යම් පොඩ් එකක් ධාවනය කළ හැකිය. ඉන්පසු මෙම පොඩ් එකෙන් මෙවැනි දෙයක් කිරීම ඉතා පහසුය:

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

prometheus-kube-state-metrics යනු Kubernetes API වෙතින්ම ප්‍රමිතික එකතු කරන Prometheus අපනයනකරුවන්ගෙන් එකකි. එහි බොහෝ දත්ත තිබේ, ඔබේ පොකුරේ ක්‍රියාත්මක වන්නේ කුමක්ද, එය කුමක්ද, ඔබට එහි ඇති ගැටළු මොනවාද.

සරල උදාහරණයක් ලෙස:

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

වරප්‍රසාද නොලත් පොඩ් එකකින් සරල curl ඉල්ලීමක් කිරීමෙන් ඔබට පහත තොරතුරු ලබා ගත හැක. ඔබ ධාවනය කරන Kubernetes අනුවාදය කුමක්දැයි ඔබ නොදන්නේ නම්, එය ඔබට පහසුවෙන් කියනු ඇත.

සහ වඩාත්ම සිත්ගන්නා කරුණ නම්, kube-state-metrics වෙත ප්‍රවේශ වීමට අමතරව, ඔබට ප්‍රොමිතියස් වෙත කෙලින්ම ප්‍රවේශ විය හැකිය. එතනින් මෙට්‍රික් එකතු කරන්න පුළුවන්. එතනින් මෙට්‍රික් පවා හදන්න පුළුවන්. න්‍යායාත්මකව වුවද, ඔබට එවැනි විමසුමක් Prometheus හි පොකුරකින් ගොඩනගා ගත හැකිය, එය සරලව ක්‍රියා විරහිත කරනු ඇත. තවද ඔබේ අධීක්ෂණය පොකුරෙන් ක්‍රියා කිරීම සම්පූර්ණයෙන්ම නවත්වනු ඇත.

තවද මෙහිදී ප්‍රශ්නය පැන නගින්නේ කිසියම් බාහිර අධීක්‍ෂණයක් ඔබගේ නිරීක්‍ෂණය නිරීක්‍ෂණය කරන්නේද යන්නයි. මට කිසිදු ප්‍රතිවිපාකයක් නොමැතිව Kubernetes පොකුරක් තුළ ක්‍රියා කිරීමට මට දැන් අවස්ථාව ලැබුණි. තවදුරටත් කිසිදු අධීක්ෂණයක් නොමැති බැවින් මා එහි ක්‍රියාත්මක වන බව ඔබ නොදනී.

PSP සමඟ මෙන්ම, ගැටලුව වන්නේ මෙම සියලු විසිතුරු තාක්ෂණයන් - Kubernetes, Prometheus - ඒවා ක්‍රියා නොකරන අතර සිදුරුවලින් පිරී තිබීමයි. ඇත්තෙන්ම නැහැ.

එවැනි දෙයක් තිබේ - ජාල ප්‍රතිපත්තිය.

ඔබ සාමාන්‍ය පරිපාලකයෙක් නම්, බොහෝ විට ඔබ Network Policy ගැන දන්නවා ඇති, මෙය තවත් යමල් එකක් පමණක් වන අතර, ඒවායින් බොහොමයක් දැනටමත් පොකුරේ ඇත. තවද සමහර ජාල ප්‍රතිපත්ති අනිවාර්යයෙන්ම අවශ්‍ය නොවේ. ඔබ Network Policy යනු කුමක්දැයි කියෙව්වද, එය Kubernetes හි yaml ෆයර්වෝලයක් බව, එය ඔබට නාම අවකාශයන් අතර, කරල් අතර ප්‍රවේශ අයිතිවාසිකම් සීමා කිරීමට ඉඩ සලසයි, එවිට ඔබ නිසැකවම තීරණය කර ඇත්තේ Kubernetes හි yaml ආකෘතියේ ෆයර්වෝලය ඊළඟ වියුක්තයන් මත පදනම් වන බවයි. ... නෑ නෑ . මෙය අනිවාර්යයෙන්ම අවශ්ය නොවේ.

ඔබේ කුබර්නෙට්ස් භාවිතයෙන් ඔබට ඉතා පහසු සහ සරල ෆයර්වෝලයක් ගොඩනගා ගත හැකි බව ඔබ ඔබේ ආරක්ෂක විශේෂඥයින්ට නොකීවත්, එය ඉතා කැට සහිත එකක්. ඔවුන් තවමත් මෙය නොදන්නේ නම් සහ ඔබට කරදර නොකරන්නේ නම්: "හොඳයි, මට දෙන්න, මට දෙන්න..." එවිට ඕනෑම අවස්ථාවක, ඔබේ පොකුරෙන් ඇද ගත හැකි සමහර සේවා ස්ථාන වෙත ප්‍රවේශය අවහිර කිරීමට ඔබට ජාල ප්‍රතිපත්තියක් අවශ්‍ය වේ. කිසිම අවසරයකින් තොරව.

මා ලබා දුන් උදාහරණයේ මෙන්, ඔබට කුබර්නෙටස් පොකුරේ ඕනෑම නාම අවකාශයකින් kube රාජ්‍ය ප්‍රමිතික ලබා ගැනීමට කිසිදු අයිතියක් නොමැතිව හැක. ජාල ප්‍රතිපත්ති අධීක්‍ෂණ නාම අවකාශය වෙත අනෙකුත් සියලුම නාම අවකාශ වලින් ප්‍රවේශය වසා ඇත, එය එයයි: ප්‍රවේශයක් නැත, ගැටළු නොමැත. පවතින සියලුම ප්‍රස්ථාරවල, ක්‍රියාකරු තුළ ඇති සම්මත ප්‍රොමිතියස් සහ ප්‍රොමිතියස් යන දෙඅංශයෙන්ම, ඒවා සඳහා ජාල ප්‍රතිපත්ති සරලව සක්‍රීය කිරීමට සුක්කානම අගයන් තුළ විකල්පයක් ඇත. ඔබට එය සක්‍රිය කිරීමට අවශ්‍ය වන අතර ඒවා ක්‍රියාත්මක වනු ඇත.

ඇත්තටම මෙතන එක ප්‍රශ්නයක් තියෙනවා. සාමාන්‍ය රැවුල වවාගත් පරිපාලකයෙකු වන ඔබ බොහෝ විට තීරණය කර ඇත්තේ ජාල ප්‍රතිපත්ති අවශ්‍ය නොවන බවයි. Habr වැනි සම්පත් පිළිබඳ සියලු වර්ගවල ලිපි කියවීමෙන් පසු, ඔබ ෆ්ලැනල්, විශේෂයෙන්ම සත්කාරක-ගේට්වේ මාදිලිය සමඟ ඔබට තෝරා ගත හැකි හොඳම දේ බව තීරණය කළා.

මම කළ යුත්තේ කුමක්ද?

ඔබට ඔබේ Kubernetes පොකුරේ ඇති ජාල විසඳුම නැවත යෙදවීමට උත්සාහ කළ හැකිය, එය වඩාත් ක්‍රියාකාරී දෙයක් සමඟ ප්‍රතිස්ථාපනය කිරීමට උත්සාහ කරන්න. උදාහරණයක් ලෙස එකම කැලිකෝ සඳහා. නමුත් Kubernetes ක්‍රියාකාරී පොකුරක ජාල විසඳුම වෙනස් කිරීමේ කාර්යය ඉතා සුළු නොවන බව මට වහාම පැවසීමට අවශ්‍යය. මම එය දෙවරක් විසඳුවෙමි (දෙවර, කෙසේ වෙතත්, න්‍යායාත්මකව), නමුත් අපි එය Slurms හිදී පවා කරන්නේ කෙසේදැයි පෙන්වමු. අපගේ සිසුන් සඳහා, අපි Kubernetes පොකුරක් තුළ ජාල විසඳුම වෙනස් කරන්නේ කෙසේදැයි පෙන්වා දුන්නා. ප්‍රතිපත්තිමය වශයෙන්, නිෂ්පාදන පොකුරේ අක්‍රිය කාලයක් නොමැති බවට වග බලා ගැනීමට ඔබට උත්සාහ කළ හැකිය. නමුත් ඔබ බොහෝ විට සාර්ථක නොවනු ඇත.

ඒ වගේම ගැටලුව ඉතා සරලව විසඳා ඇත. පොකුරේ සහතික ඇත, ඔබේ සහතිකය වසරකින් කල් ඉකුත් වන බව ඔබ දන්නවා. හොඳයි, සහ සාමාන්‍යයෙන් පොකුරේ සහතික සහිත සාමාන්‍ය විසඳුමක් - අපි කරදර වන්නේ ඇයි, අපි අසල නව පොකුරක් මතු කරන්නෙමු, පැරණි එක කුණු වීමට ඉඩ දෙන්න, සහ සියල්ල නැවත යොදවන්න. ඇත්ත, එය කුණු වූ විට, අපට දිනකට වාඩි වීමට සිදුවනු ඇත, නමුත් මෙන්න නව පොකුරක්.

ඔබ නව පොකුරක් ඔසවන විට, ඒ සමඟම ෆ්ලැනල් වෙනුවට කැලිකෝ ඇතුළු කරන්න.

ඔබේ සහතික වසර සියයක් සඳහා නිකුත් කර ඇත්නම් සහ ඔබ පොකුර නැවත යෙදවීමට නොයන්නේ නම් කුමක් කළ යුතුද? Kube-RBAC-Proxy වැනි දෙයක් තිබේ. මෙය ඉතා සිසිල් වර්ධනයකි, එය ඔබට Kubernetes පොකුරේ ඇති ඕනෑම පොඩ් එකකට පැති කාර් බහාලුමක් ලෙස කාවැද්දීමට ඉඩ සලසයි. තවද එය ඇත්ත වශයෙන්ම Kubernetes හි RBAC හරහා මෙම පොඩ් එකට අවසරය එක් කරයි.

එක ප්‍රශ්නයක් තියෙනවා. මීට පෙර, මෙම Kube-RBAC-Proxy විසඳුම ක්‍රියාකරුගේ Prometheus තුළට ගොඩනගා ඇත. නමුත් පසුව ඔහු නැති විය. දැන් නවීන අනුවාදයන් ඔබට ජාල ප්‍රතිපත්තියක් ඇති බව මත රඳා පවතින අතර ඒවා භාවිතයෙන් එය වසා දමන්න. එබැවින් අපට ප්‍රස්ථාරය ටිකක් නැවත ලිවීමට සිදුවේ. ඇත්ත වශයෙන්ම, ඔබ වෙත ගියොත් මෙම ගබඩාව, මෙය සයිඩ්කාර් ලෙස භාවිතා කරන ආකාරය පිළිබඳ උදාහරණ ඇති අතර, ප්‍රස්ථාර අවම වශයෙන් නැවත ලිවීමට සිදුවේ.

තව පොඩි ප්‍රශ්නයක් තියෙනවා. ප්‍රොමිතියස් පමණක් එහි ප්‍රමිතික කාටවත් ලබා දෙන්නේ නැත. අපගේ සියලුම Kubernetes පොකුරු සංරචක වලටද ඔවුන්ගේම ප්‍රමිතික ආපසු ලබා දීමට හැකි වේ.

නමුත් මම දැනටමත් පවසා ඇති පරිදි, ඔබට පොකුරට පිවිසීමට සහ තොරතුරු රැස් කිරීමට නොහැකි නම්, ඔබට අවම වශයෙන් යම් හානියක් කළ හැකිය.

ඒ නිසා මම ඉක්මනින් Kubernetes පොකුරක් විනාශ කළ හැකි ආකාර දෙකක් පෙන්වන්නම්.

මම මේක කිව්වම ඔයාලට හිනා යාවි, මේක ඇත්ත ජීවිතේ කේස් දෙකක්.

ක්රමය එක. සම්පත් ක්ෂය වීම.

අපි තවත් විශේෂ පොඩ් එකක් දියත් කරමු. ඒකට මේ වගේ කොටසක් තියේවි.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

ඔබ දන්නා පරිදි, ඉල්ලීම් යනු ඉල්ලීම් සහිත විශේෂිත පොඩ් සඳහා සත්කාරකයේ වෙන් කර ඇති CPU සහ මතක ප්‍රමාණයයි. අපට Kubernetes පොකුරක හතර-core සත්කාරකයක් තිබේ නම් සහ CPU පොඩ් හතරක් ඉල්ලීම් සමඟ එහි පැමිණේ නම්, එයින් අදහස් වන්නේ ඉල්ලීම් සහිත තවත් පොඩ් එකක් මෙම සත්කාරකයට පැමිණිය නොහැකි බවයි.

මම එවැනි පොඩ් එකක් ධාවනය කරන්නේ නම්, මම විධානය ක්‍රියාත්මක කරමි:

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

එවිට වෙනත් කිසිවෙකුට Kubernetes පොකුරට යෙදවීමට නොහැකි වනු ඇත. සියලුම නෝඩ් වල ඉල්ලීම් අවසන් වන බැවිනි. එබැවින් මම ඔබේ කුබර්නෙටස් පොකුර නවත්වන්නෙමි. මම මෙය සවස් වරුවේ කළහොත්, මට යෙදවීම සෑහෙන කාලයක් නතර කළ හැකිය.

අපි නැවතත් Kubernetes documentation එක බැලුවොත් අපිට මේ Limit Range කියන දේ පෙනෙයි. එය පොකුරු වස්තූන් සඳහා සම්පත් සකසයි. ඔබට Limit Range object එකක් yaml වලින් ලිවිය හැක, එය යම් යම් නාම අවකාශ වලට යෙදිය හැක - ඉන්පසු මෙම namespace එක තුල ඔබට Pods සඳහා default, උපරිම සහ අවම සම්පත් ඇති බව පැවසිය හැක.

එවැනි දෙයක ආධාරයෙන්, කණ්ඩායම්වල නිශ්චිත නිෂ්පාදන නාම අවකාශයන්හි පරිශීලකයින්ට ඔවුන්ගේ කරල්වල සියලු ආකාරයේ නරක දේවල් දැක්වීමට ඇති හැකියාව සීමා කළ හැකිය. නමුත් අවාසනාවකට මෙන්, CPU එකකට වඩා ඉල්ලීම් සහිත පොඩ්ස් දියත් කළ නොහැකි බව ඔබ පරිශීලකයාට පැවසුවද, එවැනි අපූරු පරිමාණ විධානයක් තිබේ, නැතහොත් ඔවුන්ට උපකරණ පුවරුව හරහා පරිමාණය කළ හැකිය.

අංක දෙක ක්‍රමය පැමිණෙන්නේ මෙතැන් සිටය. අපි කරල් 11 දියත් කරමු. එය බිලියන එකොළහකි. මෙහෙම නම්බර් එකක් ආපු නිසා නෙවෙයි මමම දැක්ක නිසා.

ඇත්ත කතාව. හවස මම ඔෆිස් එකෙන් යන්න හැදුවා. මම දකිනවා සංවර්ධකයින් කණ්ඩායමක් කෙළවරේ වාඩි වී, ඔවුන්ගේ ලැප්ටොප් සමඟ වියරුවෙන් යමක් කරන ආකාරය. මම පිරිමි ළමයින් වෙත ගොස් මෙසේ අසමි: "ඔබට සිදු වූයේ කුමක්ද?"

මීට ටික වේලාවකට පෙර, සවස නවයට පමණ, එක් සංවර්ධනකරුවෙකු නිවසට යාමට සූදානම් වෙමින් සිටියේය. මම තීරණය කළා: "මම දැන් මගේ අයදුම්පත එකකට පරිමාණය කරන්නම්." මම එකක් ඔබා, නමුත් අන්තර්ජාලය ටිකක් මන්දගාමී විය. ඔහු නැවතත් එක ඔබා, එය ඔබා, Enter ක්ලික් කරන්න. මම මට පුළුවන් හැම දේටම ගැහුවා. එවිට අන්තර්ජාලය ජීවයට පැමිණියේය - සහ සෑම දෙයක්ම මෙම අංකයට පරිමාණය කිරීමට පටන් ගත්තේය.

ඇත්ත, මෙම කතාව සිදු වූයේ කුබර්නෙටස් මත නොවේ; එකල එය නෝමාඩ් ය. එය අවසන් වූයේ නොමැඩ් දිගින් දිගටම පරිමාණය කිරීමට ගත් උත්සාහයන් නැවැත්වීමට අප ගත් උත්සාහයෙන් පැයකට පසු, නෝමාඩ් පිළිතුරු දුන්නේ ඔහු පරිමාණය කිරීම නවත්වන්නේ නැති බවත් වෙන කිසිවක් නොකරන බවත්ය. "මට මහන්සියි, මම යනවා." ඒ වගේම ඔහු ගුලි වුණා.

ස්වාභාවිකවම, මම Kubernetes හි එයම කිරීමට උත්සාහ කළෙමි. කුබර්නෙටස් කරල් බිලියන එකොළහක් ගැන සතුටු නොවීය, ඔහු මෙසේ පැවසීය: “මට බැහැ. අභ්‍යන්තර මුඛ ආරක්ෂකයන් ඉක්මවා යයි." නමුත් කරල් 1කට පුළුවන්.

බිලියනයකට ප්‍රතිචාර වශයෙන්, කියුබ් තමා තුළට ඉවත් නොවීය. ඔහු ඇත්තටම පරිමාණය කිරීමට පටන් ගත්තේය. ක්‍රියාවලිය ඉදිරියට ගිය තරමට, ඔහුට නව කරල් නිර්මාණය කිරීමට වැඩි කාලයක් ගත විය. එහෙත් තවමත් ක්රියාවලිය සිදු විය. එකම ප්‍රශ්නය නම්, මට මගේ නාම අවකාශයේ අසීමිත ලෙස පොඩ් දියත් කළ හැකි නම්, ඉල්ලීම් සහ සීමාවන් නොමැතිව වුවද, මට සමහර කාර්යයන් සමඟ පොඩ් විශාල ප්‍රමාණයක් දියත් කළ හැකි අතර, මෙම කාර්යයන් ආධාරයෙන් නෝඩ් මතකයේ, CPU හි එකතු වීමට පටන් ගනී. මම බොහෝ කරල් දියත් කරන විට, ඒවායේ තොරතුරු ගබඩාවට යා යුතුය, එනම්, ආදිය. ඕනෑවට වඩා තොරතුරු එහි පැමිණි විට, ගබඩාව ඉතා සෙමින් ආපසු පැමිණීමට පටන් ගනී - සහ කුබර්නෙටස් අඳුරු වීමට පටන් ගනී.

සහ තවත් එක් ගැටළුවක් ... ඔබ දන්නා පරිදි, Kubernetes පාලන මූලද්රව්ය එක් කේන්ද්රීය දෙයක් නොව, සංරචක කිහිපයක් වේ. විශේෂයෙන්ම, පාලක කළමනාකරුවෙකු, උපලේඛකයෙකු සහ යනාදිය ඇත. මේ සියලු දෙනා එකවරම අනවශ්‍ය, මෝඩ වැඩ කිරීමට පටන් ගනී, කාලයත් සමඟ එය වැඩි වැඩියෙන් කාලය ගත කිරීමට පටන් ගනී. පාලක කළමනාකරු නව කරල් නිර්මාණය කරයි. Scheduler ඔවුන් සඳහා නව නෝඩයක් සොයා ගැනීමට උත්සාහ කරනු ඇත. ඔබ ළඟදීම ඔබේ පොකුරේ නව නෝඩ් අවසන් වනු ඇත. Kubernetes පොකුර සෙමින් හා මන්දගාමීව වැඩ කිරීමට පටන් ගනී.

නමුත් මම තවත් ඉදිරියට යාමට තීරණය කළෙමි. ඔබ දන්නා පරිදි, Kubernetes හි සේවාවක් ලෙස හැඳින්වෙන දෙයක් තිබේ. හොඳයි, ඔබේ පොකුරු පෙරනිමියෙන්, බොහෝ විට, සේවාව IP වගු භාවිතයෙන් ක්රියා කරයි.

ඔබ කරල් බිලියනයක් ධාවනය කරන්නේ නම්, උදාහරණයක් ලෙස, නව සේවා තැනීමට Kubernetis හට බල කිරීමට ස්ක්‍රිප්ට් එකක් භාවිතා කරන්න:

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

පොකුරේ සියලුම නෝඩ් වල, වැඩි වැඩියෙන් නව iptables රීති ආසන්න වශයෙන් එකවර ජනනය වේ. එපමණක් නොව, සෑම සේවාවක් සඳහාම බිලියනයක iptables නීති ජනනය කරනු ඇත.

මම මේ සියල්ල දහස් ගණනක්, දහයක් දක්වා පරීක්ෂා කළා. ගැටළුව වන්නේ දැනටමත් මෙම එළිපත්තෙහි නෝඩයට ssh කිරීම තරමක් ගැටළු සහගත වීමයි. මක්නිසාද යත්, බොහෝ දම්වැල් හරහා ගමන් කරන පැකට් එතරම් හොඳ නැති බවක් දැනෙන්නට පටන් ගනී.

මෙයද කුබර්නෙටස්ගේ උපකාරයෙන් විසඳනු ලැබේ. එවැනි සම්පත් කෝටා වස්තුවක් තිබේ. පොකුරේ ඇති නාම අවකාශය සඳහා පවතින සම්පත් සහ වස්තු ගණන සකසයි. අපට Kubernetes පොකුරේ සෑම නාම අවකාශයකම yaml වස්තුවක් සෑදිය හැක. මෙම වස්තුව භාවිතයෙන්, අපට මෙම නාම අවකාශය සඳහා නිශ්චිත ඉල්ලීම් සහ සීමාවන් වෙන් කර ඇති බව පැවසිය හැකිය, එවිට අපට මෙම නාම අවකාශය තුළ සේවා 10 ක් සහ පොඩ් 10 ක් නිර්මාණය කළ හැකි බව පැවසිය හැකිය. තනි සංවර්ධකයෙකුට අවම වශයෙන් සවස් වරුවේ හුස්ම හිර කර ගත හැකිය. Kubernetes ඔහුට පවසනු ඇත: "ඔබට ඔබේ කරල් එම ප්‍රමාණයට පරිමාණය කළ නොහැක, මන්ද සම්පත කෝටාව ඉක්මවා යන බැවිනි." එච්චරයි, ගැටලුව විසඳා ඇත. ලේඛන මෙතනින්.

මේ සම්බන්ධයෙන් එක් ගැටලුකාරී කරුණක් පැන නගී. Kubernetes හි නාම අවකාශයක් නිර්මාණය කිරීම කොතරම් දුෂ්කර දැයි ඔබට හැඟේ. එය නිර්මාණය කිරීම සඳහා, අපි බොහෝ කරුණු සැලකිල්ලට ගත යුතුය.

සම්පත් කෝටාව + සීමා පරාසය + RBAC
• නාම අවකාශයක් සාදන්න
• ඇතුළත සීමාවක් සාදන්න
• ඇතුළත සම්පත් කෝටාව සාදන්න
• CI සඳහා සේවා ගිණුමක් සාදන්න
• CI සහ පරිශීලකයින් සඳහා භූමිකාවක් නිර්මාණය කරන්න
• විකල්ප වශයෙන් අවශ්‍ය සේවා පොඩ් දියත් කරන්න

එබැවින්, මගේ වර්ධනයන් බෙදා ගැනීමට මම මෙය අවස්ථාවක් කර ගැනීමට කැමැත්තෙමි. එහෙම එකක් තියෙනවා SDK operator කියලා. මෙය Kubernetes පොකුරක් සඳහා ක්‍රියාකරුවන් ලිවීමට මාර්ගයකි. ඔබට Ansible භාවිතයෙන් ප්‍රකාශ ලිවිය හැක.

මුලදී එය Ansible වලින් ලියා ඇත, පසුව මම SDK ක්‍රියාකරුවෙකු සිටින බව දැක ඇන්සිබල් භූමිකාව ක්‍රියාකරුවෙකු ලෙස නැවත ලිවීය. මෙම ප්‍රකාශය ඔබට Kubernetes පොකුරේ විධානයක් ලෙස හඳුන්වන වස්තුවක් නිර්මාණය කිරීමට ඉඩ සලසයි. විධානයක් ඇතුළත, මෙම විධානය සඳහා පරිසරය yaml වලින් විස්තර කිරීමට එය ඔබට ඉඩ සලසයි. කණ්ඩායම් පරිසරය තුළ, අපි බොහෝ සම්පත් වෙන් කරන බව විස්තර කිරීමට එය අපට ඉඩ සලසයි.

පොඩි එක මෙම සම්පූර්ණ සංකීර්ණ ක්‍රියාවලිය පහසු කිරීම.

සහ අවසාන වශයෙන්. මේ සියල්ල සමඟ කුමක් කළ යුතුද?
පලමු. Pod ආරක්ෂක ප්‍රතිපත්තිය හොඳයි. කුබර්නෙට්ස් ස්ථාපකයින් කිසිවක් අද දක්වා ඒවා භාවිතා නොකළද, ඔබ තවමත් ඒවා ඔබේ පොකුරු තුළ භාවිතා කළ යුතුය.

ජාල ප්‍රතිපත්තිය තවත් අනවශ්‍ය අංගයක් පමණක් නොවේ. පොකුරකට ඇත්තටම අවශ්‍ය වන්නේ මෙයයි.

LimitRange/ResourceQuota - එය භාවිතා කිරීමට කාලයයි. අපි මෙය බොහෝ කලකට පෙර භාවිතා කිරීමට පටන් ගත් අතර, බොහෝ කාලයක් තිස්සේ සෑම කෙනෙකුම එය භාවිතා කරන බව මට විශ්වාසයි. මෙය දුර්ලභ බව පෙනී ගියේය.

වාර්තාව අතරතුර මා සඳහන් කළ දේට අමතරව, පොකුරට පහර දීමට ඔබට ඉඩ සලසන ලේඛනගත නොකළ විශේෂාංග තිබේ. මෑතකදී නිකුත් කරන ලදී Kubernetes දුර්වලතා පිළිබඳ පුළුල් විශ්ලේෂණය.

සමහර දේවල් හරිම දුකයි රිදවයි. උදාහරණයක් ලෙස, යම් යම් කොන්දේසි යටතේ, Kubernetes පොකුරක් තුළ ඇති cubelets හට Warlocks නාමාවලියෙහි අන්තර්ගතය අනවසර පරිශීලකයෙකුට ලබා දිය හැක.

මෙහි මම ඔබට පැවසූ සෑම දෙයක්ම ප්‍රතිනිෂ්පාදනය කරන්නේ කෙසේද යන්න පිළිබඳ උපදෙස් තිබේ. ResourceQuota සහ Pod Security Policy කෙබඳුද යන්න පිළිබඳ නිෂ්පාදන උදාහරණ සහිත ගොනු තිබේ. තවද ඔබට මේ සියල්ල ස්පර්ශ කළ හැකිය.

සැමට ස්තුතියි.

මූලාශ්රය: www.habr.com