IuriiO Notebook
  • Broken Code Notebook
  • Architecture and Design
    • Architectural Decision Records
    • Trade-off Analysis
    • Data Decomposition Drivers
    • Selecting a Database Type
    • Service Granularity
    • Consumer-driven Contracts
  • Cloud
    • AWS
      • Resources
      • Compute
        • EC2
        • Batch
        • ECS & ECR
        • Elastic Beanstalk
      • Storage & Data Management
        • S3
        • Storage Gateway
        • RDS
        • DynamoDB
        • ElastiCache
        • Redshift
        • EBS
        • EFS
        • FSx
        • Snowball
        • Athena
        • Encryption and Downtime
        • Untitled
      • Security & Compliance
        • IAM
        • Web Identity Federation
        • Organizations
        • Service Catalog
        • Tags and Resource Groups
        • STS
        • KMS
        • GuardDuty
        • Compliance
        • Marketplace Security Products
        • DDOS
        • Compliance Frameworks
      • High Availability
        • Global Infrastructure
        • Disaster recovery
        • Elastic Load Balancers
        • Untitled
      • Monitoring & Reporting
        • Cost Explorer
        • CloudWatch
        • Systems Manager
        • Config
        • CloudTrail
        • Cost control
        • Untitled
      • Networking
        • Networking 101
        • Route53
        • CloudFront
        • VPC
        • DirectConnect
        • WAF
        • Shield
        • Global Accelerator
      • Deployment & Provisioning
        • Untitled
        • Untitled
      • Automation & Optimization
        • CloudFormation
          • Links
          • Github resources
          • YAML 101
          • Videos
        • OpsWorks
        • Untitled
      • Application Services
        • SQS
        • SWF
        • SNS
        • Untitled
      • Serverless
        • Lambda
        • API Gateway
        • DynamoDB
        • SAM
        • Untitled
      • Well-Architected Framework
    • Azure
      • Tools
      • Organization & Management
      • Authentication & Authorization
      • Compute
      • Networking
      • Storage
      • Databases
      • Security
      • Privacy, Compliance & Trust
      • Cost Management
  • Containers & Services
    • Docker
      • Useful Links
      • Containers
      • Images
      • Dockerfile
      • System
      • Compose
      • Swarm
      • Docker & NodeJS
    • Kubernetes
      • Useful Links
      • Introduction
      • Getting started
      • Exposing containers
      • Kubernetes Management Techniques
        • Declarative YAML
      • Labels and Annotations
      • Storage in Kubernetes
      • Ingress Controller
      • CRD's and The Operator Pattern
      • Kubernetes Dashboard
      • Kubectl Namespaces and Context
  • Frontend
    • Resources
    • Design
      • Search experience
Powered by GitBook
On this page

Was this helpful?

  1. Containers & Services
  2. Kubernetes
  3. Kubernetes Management Techniques

Declarative YAML

  • Kubernetes configuration files - YAML or JSON

  • Each file contains one or more manifests

  • Each manifest describes an API object (deployment, job, secret)

  • Each manifest needs 4 parts (root key:values in the file):

    • apiVersion - Which version of the Kubernetes API you’re using to create this object

    • kind - What kind of object you want to create

    • metadata - Data that helps uniquely identify the object, including a name string, UID, and optional namespace

    • spec - What state you desire for the object

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.17.3
    ports:
    - containerPort: 80
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.3
        ports:
        - containerPort: 80

Declaring multiple types in a single file - separate them with "---"

apiVersion: v1
kind: Service
metadata:
  name: app-nginx-service
spec:
  type: NodePort
  ports:
  - port: 80
  selector:
    app: app-nginx
--- # !!! Separator
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-nginx
  template:
    metadata:
      labels:
        app: app-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.3
        ports:
        - containerPort: 80
  • kubectl api-resources

  • kubectl api-versions

  • We can get all the keys each kind supports: kubectl explain <kind> --recursive

  • We can drill down into subnodes of the kind:

    kubectl explain <kind>.<subnode>

    kubectl explain services.spec

Dry Runs with Apply YAML

  • dry run client-side only:

    kubectl apply -f file.yml --dry-run

  • dry run server-side (will compare current file with what's already deployed on server):

    kubectl apply -f file.yml --server-dry-run

  • see the diff visually:

    kubectl diff -f file.yml

PreviousKubernetes Management TechniquesNextLabels and Annotations

Last updated 5 years ago

Was this helpful?