Container

    • รู้จัก Container มันคืออะไร แตกต่างจาก Virtualization อย่างไร:
      www.blognone.com/node/105928

    • Kubernetes คืออะไร ทำไม Orchestration จึงเป็นหัวใจของ Infrastructure ยุคนี้:
      www.blognone.com/node/106492

    • Certified Calico Operator: Level 1 - Learn Kubernetes networking and security fundamentals using Calico Free!
      academy.tigera.io/course/certified-calico-operator-level-1

    • Which Kubernetes Certification Path Should I Take?:
      image
      acloudguru.com/blog/engineering/which-kubernetes-certification-path-should-i-take

    • Kubernetes 101:
      www.youtube.com/watch?v=GPC6mEuiBBE

    • Kubernetes for Beginner:
      medium.com/@sikiryl/ep-0-kubernetes-content-e138c25846bb

    • https://www.proen.cloud

    The Kubernetes Network Model:

    image
    • IP per Pod -> VMs & Processes ≈ Pods & Containers
    • Isolation with Network Policy -> simple 'flat' network

    Kubernetes Network Implementations:

    image
    • Host Local IPAM CNI Plugin
    • Other CNI Plugins
    • Network Policy
    • Performance & Encryption

    Kubernetes DNS:

    image
    • Example service: my-svc.my-namespace.svc.cluster-domain.example
    • Pod in cluster:  my-svc.my-namespace
    • Pod in my-namespace: my-svc

    Outgoing NAT:

    image
    • Pod IPs may not be routable outside of the cluster (e.g. overlay network)

    • The key principles of the Kubernetes networking model:
      • Every pod gets its own IP address
      • Containers within a pod share the pod IP address and can communicate freely with each other
      • Pods can communicate with each other directly without NAT
      • Network isolation is provided by network policy
      • The Kubernetes network model requires L3 (IP) connectivity only. Pods may be in the same CIDR, but are normally not strictly in the same subnet as they don't have L2 connectivity.
      • Kubernetes supports overlay and non-overlay networks.
      • The Kubernetes network model does not require that pods can communicate with workloads outside of the cluster without NAT. For example, if the pod network is an overlay, then it needs to NAT outgoing traffic.

    • Kubernetes supports network plugins using CNI API.
      • Kubenet built into Kubernetes and can provide some very basic networking, but is not an API used by Kubernetes network plugins.
      • Network plugins can implement IP Address Management, but IPAM is not an API.
      • Kubernetes supports a REST API for managing Kubernetes resources, but uses a different API for network plugins.

    • Kubernetes Services:
      • Can be though of as a virtual load balancer built into the pod network
      • Normally use label selectors to define which pods belong to a Service
      • Are discoverable by pods through the Kubernetes DNS service
      • May include external load balancer
      • The Kubernetes network model does specify that pods can communicate with each other directly without NAT. But a pod communicating with another pod via a service is not direct communication, and normally will use NAT to change the connection destination from the service to the backing pod as part of load balancing.

    • Calico can be installed:
      • As part of hosted Kubernetes platform (e.g. Amazon Elastic Kubernetes Service (AWS EKS), Azure (AKS), Google Engine (GKE), IBM Cloud (IKS))
      • As part of a kubernetes distro or installer (eg. kops, kubespray, micro8s, etc.)
      • Using YAML manifests
      • Using the Tigera Calico operator

    What is Network Policy?:

    image
    • Simple 'flat' network
    • Isolation is not defined by the structure of the network

    Why is Network Policy Important?:
    • Attacks continue to grow in sophisticated and volume
    • Traditional firewalls struggle with dynamic nature of Kubernetes
    • Network Policy is label selector based -> inherently dynamic
    • Empowers teams to adopt 'shift left' security practices

    • apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: blue-policy
        namespace: production
      spec:
        podSelector:
          matchLabels:
            color: blue
        ingress:
        - from:
          - podSelector:
            matchLabels:
              color: red
          ports:
            - port: 80

    • apiVersion: projectcalico.org/v3
      kind: NetworkPolicy
      metadata:
        name: blue-policy
        namespace: production
      spec:
        selector: color == 'blue'
        ingress:
        - action: Allow
          protocol: TCP
          source:
            selector: color == 'red'
          destination:
            ports:
              - port: 80
    B-)
  • 2 Comments sorted by

    • apiVersion: projectcalico.org/v3
      kind: GlobalNetworkPolicy
      metadata:
        name: red-policy
      spec:
        order: 100
        selector: color == 'red'
        ingress:
        - action: Deny
          source:
            selector: color == 'blue'
        - action: Allow
          source:
            serviceAccounts:
              selector: color == 'green'

    • apiVersion: projectcalico.org/v3
      kind: NetworkSet
      metadata:
        name: external-database
        namespace: staging
        labels:
          role: db
      spec:
        nets:
        - 192.51.100.0/28
        - 203.0.113.0/24

    • apiVersion: projectcalico.org/v3
      kind: HostEndpoint
      metadata:
        name: my-host-eth0
        labels:
          role: k8s-worker
          environment: production
      spec:
        interfaceName: eth0
        node: my-host
        expectedIPs: ["10.0.0.1"]

    Network Policy Support:

    Kubernetes Network Policy:
    • Ingress & egress rules
    • Pod selectors
    • Namespace selectors
    • Port lists
    • Named ports
    • IP blocks & excepts
    • TCP, UDP, or SCTP

    Calico Network Policy:
    • Namespaced & global scopes
    • Deny and log actions
    • Policy ordering
    • Richer matches, including:
      • ServiceAccounts
      • ICMP
    • Istio integration, including:
      • Cryptographic identity matching
      • Layer 5-7 match criteria

    image

    Ability to protect Hosts:
    image
    Istio Integration:
    • apiVersion: projectcalico.org/v3
      kind: GlobalNetworkPolicy
      metadata:
        name: summary
      spec:
        selector: app == 'summary'
        ingress:
        - action: Allow
          http:
            methods: ["GET"]
            paths:
              - exact: "/foo/bar"
              - prefix: "/baz"
            source:
              serviceAccounts:
                names: ["customer"]

    • Single familiar network policy model
    • Match on L5-7 application layer attributes
    • Match cryptographic identity of Service Accounts
    • Multiple enforcement points
      • Network infrastructure layer
      • Service mesh layer

    Extendable with Calico Enterprise:
    www.tigera.io/tigera-products

    Best Practices for Network Policy
    Ingress and Egress:
    • apiVersion: projectcalico.org/v3
      kind: NetworkPolicy
      metadata:
        name: blue-policy
        namespace: production
      spec:
        selector: color == 'blue'
        ingress:
        - action: Allow
          protocol: TCP
          source:
            selector: color == 'red'
          destination:
            ports:
              - 80
        egress:
        - action: Allow
          protocol: TCP
          destination:
            selector: color == 'green'
            ports:
              - 80

    Default Deny:
    • All pods in all namespaces
    • All host endpoints
    • Including the control plane!
      • (Except for configured Calico 'failsafe' ports)

    Default App Policy:
    • Non-system pods only
    • Always allow DNS queries to kube-dns

    Hierarchical Network Policy:

    image
    • Traditional enterprise network security was implemented using Designing a physical topology of network devices (firewalls, routers, switches) and Static IP address ranges.

    • Kubernetes network security:
      • Assumes a flat pod network
      • Is defined using network policies, enforced by network plugins, decoupled from the underlying network capabilities
      • Abstracted from the network by using label selectors

    • Traditional firewalls work with Kubernetes by Use them at the perimeter.

    Building Containerized Applications on AWS:

    Containers:
    • Docker
    • Registries
    • Building images

    Computing platforms:
    • Bare-metal => Virtual machines => Containers

    Containerization terminology:
    • Container
    • Image
    • Registry

    A container is...:
    • ...everything an application needs, from dependencies to environment variables.

    A container image is...:
    • ...the packaged configuration needed to deploy a running container.

    A registry is...:
    • ...similar to a source code repository, holding container images.
    • Amazon Elastic Container Registry

    Docker components:
    • Docker daemon
    • Docker CLI
    • Image registry

    Docker client:
    • docker create
    • docker run
    • docker rm

    A dockerfile is a set of instructions to build a container.

    • FROM ubuntu:16.04

      MAINTAINER PlaWanSai "plawansai@notarealemail.com"

      RUN apt-get update -y && \
              apt-get install -y python-pip python-dev

      COPY ./requirements.txt /app/requirements.txt

      WORKDIR /app

      RUN pip install -r requirements.txt

      COPY . /app

      EXPOSE 8080

      ENTRYPOINT [ "python" ]

      CMD [ "app.py" ]


    Building Modern Python Applications on AWS:

    • :~/environment $ python --version

    • ~/environment $ pip install boto3

    Client interface:
    • Low level
    • One-to-one map to AWS APIs
    • Responses come as Python dictionaries
    B-)

  • Resource interface:
    • Higher level interface
    • Object-oriented
    • Wrapper for client
    • Exposes a subset of AWS APIs

      client.py:
    • import boto3

      client = boto3.client('s3')

      response = client.list_objects(Bucket='aws-bma-test')

      for content in response['Contents']:
          obj_dict = client.get_object(Bucket='aws-bma-test', Key=content['Key'])
          print(content['Key'], obj_dict['LastModified'])

      resource.py:
    • import boto3

      s3 = boto3.resource('s3')
      bucket = s3.Bucket('aws-bma-test')
      # the objects are available as a collection on the bucket object
      for obj in bucket.objects.all():
          print(obj.key, obj.last_modified)
          
      # access the client from the resource
      s3_client = boto3.resource('s3').meta.client

    Sessions:
    • Default session is created when create a client or resource
    • Use to set up credentials and region

    S3 select:
    • A feature of S3
    • Submit a SQL query to read/filter a subset of data in an object
    • Data filtering done by S3, not your code

    Kubernetes 101:

    Virtual Machines vs Containers:
    image
    Kubernetes คืออะไร?:
    • K8s คือระบบ Open-source ที่ใช้ในหาร Deploy, Scale และจัดการ Container แบบอัตโนมัติ โดยการจัดกลุ่ม Container ให้เป็นหน่วยทำให้ง่ายต่อการจัดการ

    องค์ประกอบของ Kubernetes:
    • Hardware:
      • Nodes
      • Cluster
      • Persistent Volumes
    • Software:
      • Containers
      • Pods
      • Deployment
      • Ingress

    Nodes:
    • Worker Machine ของ Kubernetes เป็นได้ทั้ง Virtual Machine หรือ Physical Machine ซึ่งใน Kubernetes จะแบ่ง Node ออกเป็นสองประเภท ได้แก่ Master และ Worker Node

      image

    Cluster:
    • กลุ่มของ Node เมื่อมีการ Deploy Application, Cluster จะทำการกระจายงานไปยัง Node ต่างๆ

      image

    Persistent Volumes:
    • พื้นที่จัดเก็บข้อมูลที่ถูกต่อเข้ากับ Cluster ใช้สำหรับบันทึกข้อมูลที่มาจาก Pods เนื่องจากข้อมูลใน Pods จะถูกลบไปพร้อมกับ Pods

      image

    Containers:
    • ภาชนะที่บรรจุ Application รวมไปถึง Environments และ Package ต่างๆ ที่จำเป็นต้องใช้ใน Run Application ให้อยู่ในรูป File, File เดียว

      image

    Pods:
    • กลุ่มของ Container ที่ถูก Deploy อยู่บน Host เดียวกัน ใช้ทรัพยากรและ Network ร่วมกัน เป็นหน่วยที่เล็กที่สุดซึ่งใช้ในการ Run Application หากมีการใช้งานที่มากจน Pod เดียวไม่สามารถรับไหว Kubernetes สามารถปรับเพิ่มจำนวน Replica หรือสำเนาของ Pod เพื่อให้รองรับการทำงานได้

    Deployment:
    • ใช้ประกาศจำนวน Replica หรือสำเนาของ Pod ที่ใช้ Run และคอยตรวจสอบจำนวน Pod ให้เป็นไปตามที่ตั้งค่าไว้

      image

    Ingress:
    • ชุดของ Routing Rules ที่กำหนดว่าบริการจากภายนอกจะเข้าถึงบริการที่ทำงานภายใน Kubernetes Cluster ได้อย่างไร

      image
    Kubernetes Architecture:

    Kubernetes Cluster ประกอบด้วย:
    1. Master Node ที่เป็นตัวควบคุม
    2. Worker Node ที่เป็นตัวทำงาน
    image
    Master Node:
    • จะคอยรับคำสั่งจาก CLI (Command Line Interface) ที่เรียกว่า kubectl หรือ UI (User Interface) ผ่าน API จากนั้นจะทำการประมวลผลแล้วสั่งการไปที่ Worker Node โดย Master Node จะประกอบไปด้วย
      1. API Server
      2. Key-Value Store (etcd)
      3. Controller
      4. Scheduler

    image
    API Server:
    • เป็นองค์ประกอบแรกของ Kubernetes Cluster ที่เปิดใช้งาน มีหน้าที่รับคำสั่งจากผู้ใช้ โดยจะมีการตรวจสอบความถูกต้องของผู้ใช้ก่อน ถ้าถูกต้องก็จะทำการ Update ทรัพยากรของ Kubernetes ใน etcd ตามคำสั่งของผู้ใช้

    Key-Value Store (etcd):
    • เป็นแหล่งเก็บข้อมูลสำรองที่บันทึกการกำหนดค่าให้กับ Cluster โดยจะบันทึกการกำหนดค่าทั้งหมดและสถานะของ Cluster ซึ่ง Master Node จะทำการดึงข้อมูลสถานะของ Nodes, Pods และ Container จาก etcd

    Controller:
    • เป็นส่วนที่รับคำสั่งจาก API Server แล้วตรวจสอบกับสถานะปัจจุบันของ Node ที่ได้รับคำสั่งให้ควบคุม ถ้าพบว่าสถานะของ Node นั้นๆ มีความแตกต่างกัน ก็จะดำเนินการ Update นอกจากนี้ Controller ยังมีหน้าที่รักษาระบบให้อยู่ในสถานะที่ต้องการอย่างต่อเนื่องโดยการเปรียบเทียบกับสถานะปัจจุบันของระบบ

    Scheduler:
    • มีหน้าที่ค้นหาและกำหนด Node ที่เหมาะสมสำหรับการใช้สร้าง Pod โดย Scheduler จะทำการตรวจสอบทรัพยากรของ Node เพื่อหา Node ที่เหมาะสมตามข้อกำหนดของ Pod จากนั้นจึง Deploy Pod ไปยัง Node นั้นๆ

    Worker Node:
    • ทำหน้าที่ Run Container ตามคำสั่งที่ได้รับมาจาก Master Node จากนั้นจึงรายงานผลกลับ โดย Worker Node จะประกอบด้วย
      1. Kubelet
      2. Container Runtime
      3. Kube-proxy

    image
    Kubelet:
    • เป็นส่วนที่คอยรับคำสั่งที่ส่งมาจาก API Server แล้วติดต่อกับ Container Runtime ให้ Pull Image ที่ต้องการในการ Run Pods นอกจากนี้ Kubelet ยังคอยตรวจสอบ Pods เพื่อแจ้งกลับไป Master Node ในกรณีที่ Pods เกิดข้อผิดพลาดในการทำงาน

    Container Runtime:
    • เป็นส่วนที่ใช้ Run Container ใน Pod (เช่น Docker, ContainerD เป็นต้น) โดยจะ Pull Image ที่ต้องการมาจาก Container Image Registry

    Kube-proxy:
    • ทำหน้าที่ Load-balance Traffic ที่กำหนดไว้ใน Services ไปยัง Pods ที่ถูกต้อง เพื่อเปิดให้ภายนอกสามารถเข้าถึง Pod ที่อยู่ภายในได้


    B-)