Calico კუბერნეტში ქსელისთვის: შესავალი და მცირე გამოცდილება

სტატიის მიზანია მკითხველს გააცნოს Kubernetes-ში ქსელის დაკავშირებისა და ქსელის პოლიტიკის მართვის საფუძვლები, ასევე მესამე მხარის Calico მოდული, რომელიც ავრცელებს სტანდარტულ შესაძლებლობებს. გზად, კონფიგურაციის სიმარტივე და ზოგიერთი მახასიათებელი ნაჩვენები იქნება რეალური მაგალითების გამოყენებით ჩვენი ოპერაციული გამოცდილებიდან.

სწრაფი შესავალი Kubernetes ქსელური მოწყობილობის შესახებ

კუბერნეტის კლასტერი ქსელის გარეშე შეუძლებელია. ჩვენ უკვე გამოვაქვეყნეთ მასალები მათ საფუძვლებზე: ”ილუსტრირებული გზამკვლევი ქსელში Kubernetes-ში"და"შესავალი Kubernetes ქსელის პოლიტიკაში უსაფრთხოების პროფესიონალებისთვის".

ამ სტატიის კონტექსტში, მნიშვნელოვანია აღინიშნოს, რომ K8s არ არის პასუხისმგებელი კონტეინერებსა და კვანძებს შორის ქსელის დაკავშირებაზე: ამისათვის სხვადასხვა CNI დანამატები (კონტეინერის ქსელის ინტერფეისი). მეტი ამ კონცეფციის შესახებ ჩვენ მათაც მითხრეს.

მაგალითად, ამ დანამატებიდან ყველაზე გავრცელებულია ფლანელი — უზრუნველყოფს სრულ ქსელურ კავშირს ყველა კლასტერულ კვანძს შორის, თითოეულ კვანძზე ხიდების აწევით, მასზე ქვექსელის მინიჭებით. თუმცა, სრული და დაურეგულირებელი ხელმისაწვდომობა ყოველთვის არ არის მომგებიანი. კლასტერში რაიმე სახის მინიმალური იზოლაციის უზრუნველსაყოფად, აუცილებელია ჩარევა firewall-ის კონფიგურაციაში. ზოგადად, ის მოთავსებულია იმავე CNI-ს კონტროლქვეშ, რის გამოც მესამე მხარის ნებისმიერი ჩარევა iptables-ში შეიძლება არასწორად იქნას ინტერპრეტირებული ან საერთოდ იგნორირებული იყოს.

და კუბერნეტის კლასტერში ქსელის პოლიტიკის მენეჯმენტის ორგანიზებისთვის მოწოდებულია „გარემო“. NetworkPolicy API. ეს რესურსი, რომელიც განაწილებულია შერჩეულ სახელთა სივრცეებზე, შეიძლება შეიცავდეს წესებს ერთი აპლიკაციიდან მეორეზე წვდომის დიფერენცირების მიზნით. ის ასევე საშუალებას გაძლევთ დააკონფიგურიროთ ხელმისაწვდომობა კონკრეტულ პოდებს, გარემოს (სახელთა სივრცეებს) ან IP მისამართების ბლოკებს შორის:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

ეს არ არის ყველაზე პრიმიტიული მაგალითი ოფიციალური დოკუმენტაცია შეიძლება ერთხელ და სამუდამოდ ხელი შეუშალოს ქსელის პოლიტიკის მუშაობის ლოგიკის გაგების სურვილს. თუმცა, ჩვენ მაინც შევეცდებით გავიგოთ ტრაფიკის ნაკადების დამუშავების ძირითადი პრინციპები და მეთოდები ქსელის პოლიტიკის გამოყენებით...

ლოგიკურია, რომ არსებობს ტრაფიკის 2 ტიპი: პოდში შესვლა (Ingress) და მისგან გამოსვლა (Egress).

ფაქტობრივად, პოლიტიკა იყოფა ამ 2 კატეგორიად მოძრაობის მიმართულებიდან გამომდინარე.

შემდეგი საჭირო ატრიბუტი არის სელექციონერი; ის, ვისთანაც ვრცელდება წესი. ეს შეიძლება იყოს პოდი (ან პოდლების ჯგუფი) ან გარემო (ანუ სახელთა სივრცე). მნიშვნელოვანი დეტალი: ამ ობიექტების ორივე ტიპი უნდა შეიცავდეს ეტიკეტს (ეტიკეტების კუბერნეტის ტერმინოლოგიაში) - ეს არის ის, რომლითაც მოქმედებენ პოლიტიკოსები.

სელექტორების სასრული რაოდენობის გარდა, რომლებიც გაერთიანებულია რაიმე სახის ეტიკეტით, შესაძლებელია სხვადასხვა ვარიაციებში დაწეროთ ისეთი წესები, როგორიცაა „დაუშვა/უარი ყველაფრის/ყველას“. ამ მიზნით გამოიყენება ფორმის კონსტრუქციები:

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

- ამ მაგალითში, გარემოში არსებული ყველა პოდი დაბლოკილია შემომავალი ტრაფიკისგან. საპირისპირო ქცევის მიღწევა შესაძლებელია შემდეგი კონსტრუქციით:

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

ანალოგიურად გამავალი:

  podSelector: {}
  policyTypes:
  - Egress

- რომ გამორთო. და აი, რა უნდა შეიცავდეს:

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

რაც შეეხება CNI მოდულის არჩევანს კლასტერისთვის, აღსანიშნავია, რომ ყველა ქსელის მოდული არ უჭერს მხარს NetworkPolicy-ს. მაგალითად, უკვე ნახსენებმა ფლანელმა არ იცის როგორ დააკონფიგურიროს ქსელის პოლიტიკა, რომელიც პირდაპირ ნათქვამია ოფიციალურ საცავში. იქ ალტერნატივაც არის ნახსენები - ღია კოდის პროექტი კალიკო, რაც მნიშვნელოვნად აფართოებს Kubernetes API-ების სტანდარტულ კომპლექტს ქსელის პოლიტიკის თვალსაზრისით.

Calico-ს გაცნობა: თეორია

Calico მოდული შეიძლება გამოყენებულ იქნას Flannel-თან ინტეგრაციაში (ქვეპროექტი Canal) ან დამოუკიდებლად, რომელიც მოიცავს როგორც ქსელთან დაკავშირებას, ასევე ხელმისაწვდომობის მართვის შესაძლებლობებს.

რა შესაძლებლობებს იძლევა K8s "boxed" გადაწყვეტის და Calico-ს API ნაკრების გამოყენება?

აი, რა არის ჩაშენებული NetworkPolicy-ში:

• პოლიტიკოსები შეზღუდულია გარემოთი;
• პოლიტიკები გამოიყენება ეტიკეტებით მონიშნულ პოდებზე;
• წესები შეიძლება გამოყენებულ იქნას პოდებზე, გარემოში ან ქვექსელებზე;
• წესები შეიძლება შეიცავდეს პროტოკოლებს, დასახელებულ ან სიმბოლურ პორტის სპეციფიკაციებს.

აი, როგორ აფართოებს Calico ამ ფუნქციებს:

• პოლიტიკა შეიძლება გამოყენებულ იქნას ნებისმიერ ობიექტზე: pod, კონტეინერი, ვირტუალური მანქანა ან ინტერფეისი;
• წესები შეიძლება შეიცავდეს კონკრეტულ მოქმედებას (აკრძალვა, ნებართვა, ხე-ტყის აღება);
• წესების სამიზნე ან წყარო შეიძლება იყოს პორტი, პორტების დიაპაზონი, პროტოკოლები, HTTP ან ICMP ატრიბუტები, IP ან ქვექსელი (მე-4 ან მე-6 თაობა), ნებისმიერი სელექტორი (კვანძები, ჰოსტები, გარემო);
• გარდა ამისა, თქვენ შეგიძლიათ დაარეგულიროთ ტრაფიკის გავლა DNAT პარამეტრების და ტრაფიკის გადამისამართების პოლიტიკის გამოყენებით.

პირველი ვალდებულებები GitHub-ზე Calico-ს საცავში თარიღდება 2016 წლის ივლისით, ხოლო ერთი წლის შემდეგ პროექტმა დაიკავა წამყვანი პოზიცია Kubernetes ქსელის კავშირის ორგანიზებაში - ამას მოწმობს, მაგალითად, კვლევის შედეგები, დირიჟორობით The New Stack:

ბევრი მსხვილი მართული გადაწყვეტა K8-ებით, როგორიცაა Amazon EKS, Azure AKS, Google GKE და სხვებმა დაიწყეს მისი რეკომენდაცია გამოსაყენებლად.

რაც შეეხება შესრულებას, აქ ყველაფერი მშვენიერია. მათი პროდუქტის ტესტირებისას, Calico-ს განვითარების ჯგუფმა აჩვენა ასტრონომიული შესრულება, გაუშვა 50000-ზე მეტი კონტეინერი 500 ფიზიკურ კვანძზე, რომლის შექმნის სიჩქარე წამში 20 კონტეინერია. სკალირებასთან დაკავშირებით არანაირი პრობლემა არ გამოვლენილა. ასეთი შედეგები გამოცხადდნენ უკვე პირველი ვერსიის გამოცხადებისას. დამოუკიდებელი კვლევები, რომლებიც ფოკუსირებულია გამტარუნარიანობასა და რესურსების მოხმარებაზე, ასევე ადასტურებს, რომ Calico-ს მუშაობა თითქმის ისეთივე კარგია, როგორც Flannel-ის. მაგალითად:

პროექტი ძალიან სწრაფად ვითარდება, ის მხარს უჭერს მუშაობას პოპულარულ გადაწყვეტილებებში, მართული K8s, OpenShift, OpenStack, შესაძლებელია Calico-ს გამოყენება კლასტერის გამოყენებით. კოპსი, არის ცნობები Service Mesh ქსელების მშენებლობაზე (აქ არის მაგალითი გამოიყენება ისტიოსთან ერთად).

ივარჯიშე Calico-სთან ერთად

ვანილის Kubernetes-ის გამოყენების ზოგად შემთხვევაში, CNI-ის დაყენება ხდება ფაილის გამოყენებამდე calico.yaml, გადმოწერილი ოფიციალური საიტიდან, გამოყენებით kubectl apply -f.

როგორც წესი, მოდულის ამჟამინდელი ვერსია თავსებადია Kubernetes-ის უახლეს 2-3 ვერსიასთან: ძველ ვერსიებში ოპერაცია არ არის გამოცდილი და არ არის გარანტირებული. დეველოპერების თქმით, Calico მუშაობს Linux-ის ბირთვებზე 3.10-ზე მაღლა, გაშვებული CentOS 7, Ubuntu 16 ან Debian 8, iptables ან IPVS-ის თავზე.

იზოლაცია გარემოში

ზოგადი გაგებისთვის, მოდით შევხედოთ მარტივ შემთხვევას იმის გასაგებად, თუ როგორ განსხვავდება ქსელის პოლიტიკა Calico-ს ნოტაციაში სტანდარტულისგან და როგორ ამარტივებს წესების შექმნის მიდგომა მათ წაკითხვასა და კონფიგურაციის მოქნილობას:

კლასტერში განლაგებულია 2 ვებ აპლიკაცია: Node.js-ში და PHP-ში, რომელთაგან ერთი იყენებს Redis-ს. PHP-დან Redis-ზე წვდომის დასაბლოკად, Node.js-თან კავშირის შესანარჩუნებლად, უბრალოდ გამოიყენეთ შემდეგი პოლიტიკა:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

არსებითად, ჩვენ დავუშვით შემომავალი ტრაფიკი Redis პორტში Node.js-დან. და სხვას აშკარად არ კრძალავდნენ. როგორც კი NetworkPolicy გამოჩნდება, მასში ნახსენები ყველა სელექტორი იწყებს იზოლირებას, თუ სხვა რამ არ არის მითითებული. თუმცა, იზოლაციის წესები არ ვრცელდება სხვა ობიექტებზე, რომლებიც არ არის დაფარული სელექტორის მიერ.

მაგალითი იყენებს apiVersion Kubernetes out of box, მაგრამ არაფერი გიშლით ხელს მის გამოყენებაში ამავე სახელწოდების რესურსი Calico-ს მიწოდებიდან. იქ სინტაქსი უფრო დეტალურია, ასე რომ თქვენ მოგიწევთ ზემოაღნიშნული შემთხვევის წესის გადაწერა შემდეგი ფორმით:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

ზემოაღნიშნული კონსტრუქციები რეგულარული NetworkPolicy API-ით მთელი ტრაფიკის დაშვების ან უარყოფისთვის შეიცავს კონსტრუქტებს ფრჩხილებით, რომლებიც ძნელად გასაგები და დასამახსოვრებელია. Calico-ს შემთხვევაში, firewall-ის წესის ლოგიკის საპირისპიროდ შესაცვლელად, უბრალოდ შეცვალეთ action: Allow on action: Deny.

იზოლაცია გარემოთი

ახლა წარმოიდგინეთ სიტუაცია, როდესაც აპლიკაცია წარმოქმნის ბიზნეს მეტრიკას პრომეთეში შეგროვებისთვის და შემდგომი ანალიზისთვის Grafana-ს გამოყენებით. ატვირთვა შეიძლება შეიცავდეს სენსიტიურ მონაცემებს, რომლებიც კვლავ საჯაროდ ჩანს ნაგულისხმევად. მოდით დავმალოთ ეს მონაცემები ცნობისმოყვარე თვალებისგან:

პრომეთე, როგორც წესი, მოთავსებულია ცალკე სერვისის გარემოში - მაგალითში ეს იქნება ასეთი სახელების სივრცე:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

საველე metadata.labels ეს შემთხვევითი არ აღმოჩნდა. როგორც ზემოთ აღინიშნა, namespaceSelector (ისევე, როგორც podSelector) მუშაობს ეტიკეტებით. მაშასადამე, იმისთვის, რომ მეტრიკა აიღოს ყველა პოდიდან კონკრეტულ პორტზე, თქვენ მოგიწევთ რაიმე სახის ლეიბლის დამატება (ან უკვე არსებულიდან) და შემდეგ გამოიყენეთ ისეთი კონფიგურაცია, როგორიცაა:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

და თუ იყენებთ Calico პოლიტიკას, სინტაქსი ასეთი იქნება:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

ზოგადად, ამ ტიპის პოლიტიკის დამატებით სპეციფიკურ საჭიროებებზე, შეგიძლიათ დაიცვათ მავნე ან შემთხვევითი ჩარევისგან აპლიკაციების მუშაობაში კლასტერში.

საუკეთესო პრაქტიკა, Calico-ს შემქმნელების აზრით, არის მიდგომა „დაბლოკე ყველაფერი და აშკარად გახსენი ის, რაც გჭირდება“, დოკუმენტირებული ოფიციალური დოკუმენტაცია (სხვები მიჰყვებიან მსგავს მიდგომას - კერძოდ, ქ უკვე ნახსენები სტატია).

დამატებითი Calico ობიექტების გამოყენება

შეგახსენებთ, რომ Calico API-ების გაფართოებული ნაკრების მეშვეობით თქვენ შეგიძლიათ დაარეგულიროთ კვანძების ხელმისაწვდომობა, არ შემოიფარგლება მხოლოდ პოდებით. შემდეგ მაგალითში გამოყენებით GlobalNetworkPolicy ICMP მოთხოვნების კლასტერში გადაცემის შესაძლებლობა დახურულია (მაგალითად, პინგები პოდიდან კვანძში, პოდებს შორის ან კვანძიდან IP პოდში):

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

ზემოაღნიშნულ შემთხვევაში, ჯერ კიდევ შესაძლებელია კლასტერული კვანძების ერთმანეთთან „მიმართვა“ ICMP-ის საშუალებით. და ეს საკითხი მოგვარებულია საშუალებებით GlobalNetworkPolicy, მიმართა ერთეულს HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

VPN საქმე

და ბოლოს, მე მოვიყვან Calico ფუნქციების გამოყენების ძალიან რეალურ მაგალითს კლასტერული ურთიერთქმედების შემთხვევაში, როდესაც პოლიტიკის სტანდარტული ნაკრები არ არის საკმარისი. ვებ აპლიკაციაზე წვდომისთვის კლიენტები იყენებენ VPN გვირაბს და ეს წვდომა მკაცრად კონტროლდება და შემოიფარგლება გამოსაყენებლად დაშვებული სერვისების კონკრეტული სიით:

კლიენტები უკავშირდებიან VPN-ს სტანდარტული UDP პორტით 1194 და, როდესაც დაკავშირებულია, იღებენ მარშრუტებს პოდებისა და სერვისების კლასტერულ ქვექსელში. მთელი ქვექსელები გადატვირთულია ისე, რომ არ დაკარგონ სერვისები მისამართების გადატვირთვისა და შეცვლისას.

პორტი კონფიგურაციაში სტანდარტულია, რაც გარკვეულ ნიუანსებს აწესებს აპლიკაციის კონფიგურაციისა და Kubernetes კლასტერში გადატანის პროცესზე. მაგალითად, იმავე AWS-ში LoadBalancer for UDP გამოჩნდა ფაქტიურად გასული წლის ბოლოს რეგიონების შეზღუდულ სიაში და NodePort არ შეიძლება გამოყენებულ იქნას მისი გადამისამართების გამო ყველა კლასტერულ კვანძზე და შეუძლებელია სერვერის ინსტანციების რაოდენობის მასშტაბირება. შეცდომის ტოლერანტობის მიზნები. გარდა ამისა, თქვენ მოგიწევთ პორტების ნაგულისხმევი დიაპაზონის შეცვლა...

შესაძლო გადაწყვეტილებების ძიების შედეგად აირჩიეს შემდეგი:

1. პოდები VPN-ით დაგეგმილია თითო კვანძში hostNetwork, ანუ რეალურ IP-მდე.
2. სერვისი განთავსებულია გარეთ ClusterIP. კვანძზე ფიზიკურად დამონტაჟებულია პორტი, რომელიც ხელმისაწვდომია გარედან მცირე დათქმებით (ნამდვილი IP მისამართის პირობითი არსებობა).
3. იმ კვანძის დადგენა, რომელზედაც წიპწა გაიზარდა, ჩვენი ისტორიის ფარგლებს სცილდება. მე უბრალოდ ვიტყვი, რომ შეგიძლიათ მჭიდროდ „მიაჭედოთ“ სერვისი კვანძზე ან დაწეროთ პატარა გვერდითი სერვისი, რომელიც მონიტორინგს გაუწევს VPN სერვისის მიმდინარე IP მისამართს და დაარედაქტირებს კლიენტებთან რეგისტრირებულ DNS ჩანაწერებს - ვისაც აქვს საკმარისი ფანტაზია.

მარშრუტიზაციის თვალსაზრისით, ჩვენ შეგვიძლია ცალსახად ამოვიცნოთ VPN კლიენტი VPN სერვერის მიერ გაცემული IP მისამართით. ქვემოთ მოცემულია ასეთი კლიენტის სერვისებზე წვდომის შეზღუდვის პრიმიტიული მაგალითი, რომელიც ილუსტრირებულია ზემოხსენებულ Redis-ზე:

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

აქ 6379 პორტთან დაკავშირება მკაცრად აკრძალულია, მაგრამ ამავე დროს შენარჩუნებულია DNS სერვისის ფუნქციონირება, რომლის ფუნქციონირება საკმაოდ ხშირად განიცდის წესების შედგენისას. რადგან, როგორც უკვე აღვნიშნეთ, როდესაც სელექტორი გამოჩნდება, მასზე გამოიყენება ნაგულისხმევი უარყოფის პოლიტიკა, თუ სხვა რამ არ არის მითითებული.

შედეგები

ამრიგად, Calico-ს გაფართოებული API-ს გამოყენებით, შეგიძლიათ მოქნილად დააკონფიგურიროთ და დინამიურად შეცვალოთ მარშრუტი კლასტერში და მის გარშემო. ზოგადად, მისი გამოყენება შეიძლება ჰგავს ბეღურების სროლას ქვემეხით, ხოლო L3 ქსელის დანერგვა BGP და IP-IP გვირაბებით გამოიყურება ამაზრზენი უბრალო Kubernetes-ის ინსტალაციაში ბრტყელ ქსელში... თუმცა, წინააღმდეგ შემთხვევაში ინსტრუმენტი გამოიყურება საკმაოდ სიცოცხლისუნარიანი და სასარგებლო. .

უსაფრთხოების მოთხოვნების დასაკმაყოფილებლად კლასტერის იზოლირება შეიძლება ყოველთვის არ იყოს შესაძლებელი და სწორედ აქ მოდის Calico (ან მსგავსი გამოსავალი) სამაშველოში. ამ სტატიაში მოცემული მაგალითები (მცირე ცვლილებებით) გამოიყენება ჩვენი კლიენტების რამდენიმე ინსტალაციაში AWS-ში.

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «შესავალი Kubernetes ქსელის პოლიტიკაში უსაფრთხოების პროფესიონალებისთვის";
• "ილუსტრირებული გზამკვლევი ქსელში Kubernetes-ში": ნაწილები 1 და 2 (ქსელის მოდელი, გადაფარვის ქსელები), ნაწილი 3 (მომსახურება და ტრაფიკის დამუშავება);
• «Container Networking Interface (CNI) - ქსელის ინტერფეისი და სტანდარტი Linux კონტეინერებისთვის".

წყარო: www.habr.com