💻
Cheet Sheets
  • 🦁Başlarken
  • 🟧DevOps Pre-Requisite
    • ❤️Why Linux? | Linux Basics #1
    • 💛Vi Editor | Linux Basics #2
    • 💙Basics Commands | Linux Basics #3
    • 🧡Package Managers | Linux Basics #4
    • 💚Services | Linux Basics #5
    • 💛Networking Basics
    • 🤎DNS Basics
    • 🩶Applications Basics
    • 🟨Java introduction
    • 🟩NodeJS Introduction
    • 🟦Python Introduction
    • 🟪GIT Introduction
    • 🟧Apache Web Server Introduction
    • ⬛Apache Tomcat
    • 🟫Python Flask
    • 🟥Node.js Express App
    • 🟨Databases
    • 🟩MySQL
    • 🟪MongoDB
    • 🟨SSL & TLS
    • 🟦YAML & JSON - JSON Path
    • ⬛Labs Resources
  • 🍎Kubernetes
    • 🍏Kubernetes: Nedir ?
    • 🍒Bileşenler
    • 🍵Kubectl ve Versiyon
    • ❤️Pod
    • 🏷️Label ve Selector
    • 🔎Annotation
    • 📲Namespaces
    • 📦Deployments
    • 🔁ReplicaSet
    • 🔙Rollout & Rollback
    • 🌐Networking - 1
    • 🌏Service
    • 🛠️Liveness Probe & Readiness Probe
    • 🥐Resource Limits
    • 💰Environment Variables
    • 📃Ephemeral Volumes
    • 🔑Secrets
    • 🌂ConfigMap
    • 🖥️Node Affinity
    • 🔌Pod Affinity
    • ✍️Taint and Toleration
    • 🔦DaemonSet
    • 🧀PV/PVC
    • 🌜Storage Class
    • 🗿StatefulSet
    • 🕹️Job & Cronjob
    • 🔐Authentication
    • 📏Role-based access control (RBAC)
    • 🈷️Service Account
    • 📈Ingress
    • 📂ImagePullPolicy & ImageSecret
    • 📖Static Pods
    • 🌐Network Policy
    • 🫐Helm Nedir?
    • 📽️Prometheus Stack - Monitoring
    • 💼EFK Stack - Monitoring
    • 🥳CRD & Operator
  • 🧑‍⚕️GIT & GITHUB
    • 👉Girizgah
    • 🌴Branch
    • 🤝Merge
    • 🤔Conflict - Rebase
    • 🇸🇴Alias
    • 🛑Gitignore
    • 🥢Diff
    • ◀️Checkout
    • 🔦Stash
    • 👉Other
  • ☁️AWS
    • 🪣S3
    • 🚙EC2
    • ⚖️ELB
    • 🤝Auto Scaling
    • 🗄️EFS
    • 🔐VPC
    • 🎆CloudFront
    • ❤️Route53
    • 🦈RDS
    • 🏢ElastiCache
    • 🔭CloudWatch
    • 👀CloudTrail
    • 📃CloudFormation
    • 🔕SNS
    • 📬SQS
    • 🎇SWF
    • 📧SES
    • 📦Kinesis
    • 📐AWSConfig
    • 👩‍🏭OpsWork
    • 🚀Lambda - Api Gateway
    • 📌ECS - EKS
    • 🔑KMS
    • 📂Directory Service
    • 🏐Snowball
    • 💾Storage Gateway
    • 💽Volume Gateway
    • 📼Tape Gateway
    • 🏠Organizations
    • 🔙Backup-Transfer-CloudShell
    • 🆔IAM
    • 📀DataSync
    • 🗃️FSx
    • 🎒Aurora Serverless
    • 🌐Global Accelerator
    • 💪HPC
    • 🎰Outposts
    • 🗼Others
  • 👨‍🔬Ansible
    • 👉Girizhah
    • 📔YAML
    • ⚙️Komponentler
    • 🎒Inventory
    • 🏑ad-hoc
    • ▶️Playbook
  • 👨‍⚕️PROMETHEUS
    • 📈Terminoloji
    • 🦯Ubuntu 20.04 Prometheus Kurulum
    • 🗒️prometheus.yml dosyasına ilk bakış:
    • 🧭promQL up query
    • 📇Exporters
    • 🔦promQL Data Types
    • 🦯Selectors & Matchers
    • 🔢Binary Operators
    • 💀ignoring and on
    • ✍️Aggregation Operators
    • 🧠Functions
    • 🖊️Alıştırma
    • 💻Client Libraries
    • 🐍Examining the data of our Python application
    • 🐐Examining the data of our GO application
    • ⏺️Recording Rules
    • 💡rate functions
    • ⏰Alerting
    • ⌚Alert Routing
    • ⏰Slack integration with Prometheus
    • 🤯PagerDuty integration with Prometheus
    • ◼️BlackBox exporter
    • 📍Push Gateway
    • 🪒Service Discovery
    • 🧊kube cadvisor with external prometheus
    • 👉aws with prometheus
    • ☁️CloudWatch Exporter
    • 👨‍🚒mysql exporter
    • 🛃Custom exporter with Python
    • ⚙️Prometheus with HTTP API
    • 🤖Prometheus Federation For Kubernetes
    • 📺Grafana
    • ⁉️Prometheus: Ne zaman kullanılmalı? Ne zaman kullanılmamalıdır?
  • 🍪Sheets
    • 🛳️Docker Sheets
    • 🐐Kube Sheets
  • 🔢12 Factor APP
    • 🏗️Introduction
    • 1️⃣Codebase
    • 2️⃣Dependencies
    • 3️⃣Concurrency
    • 4️⃣Processes
    • 5️⃣Backing Services
    • 6️⃣Config
    • 7️⃣Build, release, run
    • 8️⃣Port binding
    • 9️⃣Disposability
    • 🔟Dev/prod parity
    • 🕚Logs
    • 🕛Admin processes
  • ☁️Azure 104
    • 👨‍👨‍👧‍👧Azure Active Directory ( Entra ID )
    • 💰Subscriptions
    • 🌎Virtual Network (VNET)
    • 💻Virtual Machines
    • 🧑‍🌾Load Balancing
    • 🥍Network Advanced
    • 🪡Automating Deployment and Configuration
    • 💂Securing Storage
    • 📓Administering Azure Blobs and Azure Files
    • 🔧Managing Storage
    • 🎁App Service
    • 🛳️Azure Container
    • 🥇Backup And Recovery
    • 🪐Network Watcher
    • ⏰Resource Monitoring And Alerts
  • ⛅AZURE 305
    • 🆔identity and access management
    • 💼Desing Azure AD (Entra ID)
    • 👨‍💼Desing for Azure B2B
    • 🛃Desing for Azure B2C
    • 💳Design for MFA and Conditional Access
    • ⛑️Design for Identity Protection
    • 🚶Access Reviews
    • 🚦Managed identity Demostration
    • 🔐Key Vault Demostration
    • 👑Governance hierarchy
    • 💠Design for Management Groups
    • 🔑Desing for Subscriptions
    • 🍇Desing for resource groups
    • 📟Design for resource tags
    • 🚷Azure Policy & RBAC
    • 🫐Desing For Blueprints
    • 🪡Desing for Virtual Networks
    • 🛫Design for on-premises connectivity to Azure
    • 🔽Design for network connectivity
    • 📦Design for application delivery
    • 🥞Design for network security and application protection
    • 📕Choose a compute solution
    • 🌊Design for virtual machines
    • 🔋Azure Batch Demostration
    • 🛰️Design for Azure App Service
    • ⛲Design for Azure Container Instances
    • 🎢Design for Azure Kubernetes Service
    • 📠Azure Functions Demostration
    • 💪Azure Logic Apps Demostration
    • 🧑‍💼Design for data storage
    • 🎞️Design for Azure storage accounts
    • 🌟Choose the storage replication
    • 📹Azure blob storage - Lifecycle & immutable demo
    • 🥌Azure Files Demostration
    • 🕸️Design Azure disks
    • 🦼Design for storage security
    • 🔮Azure Table Storage And Cosmos DB Demostration
    • 🟧Azure SQL Solutions
    • 🎡Azure SQL Database - Purchasing models
    • 🕯️Database availability
    • 📜Data security strategy
    • 🧮Azure SQL Edge
    • 🚲Azure Data Factory
    • 🔅Azure Data Lake Storage
    • 🧘‍♂️Azure Databricks
    • 🎒Azure Synapse Analytics
    • 🅰️Azure Stream Analytics
    • 📼Data flow strategy
    • 🍥Cloud Adoption Framework
    • ☣️Azure Migration Framework
    • 🦿Assessing workloads
    • 🪡Migration tools
    • 🤖Azure Database migration
    • 👥Storage migration
    • 👜Azure Backup
    • ⏲️Azure Blob Backup and Recovery
    • 💈Azure files backup and recovery
    • 🎞️Azure VM backup and recovery
    • 🧺Azure SQL backup and recovery
    • ⏰Azure Site Recovery
    • 📩Differentiate event and message
    • ✈️Azure messaging solutions
    • 🚜Event Hub
    • 🥍Application optimization solution
    • 🎁Application lifecycle
    • 📺Azure Monitor
    • 🅱️Log Analytics
    • 👥Azure workbooks and Insights
    • 🚌Azure Data Explorer
  • Github Actions
    • Github Actions Nedir?
    • Workflow & Schedule Triggers
    • Single and Multiple Events
    • Manuel Events
    • Webhook Events
    • Conditional Keywords For Steps
    • Expressions - 1
    • Expressions - 2
    • Runners
    • Workflow Commands
    • Workflow Context
    • Dependent Jobs
    • Encrypted Secrets
    • Configuration Variables
    • Default & Custom Env Varb
    • Set Env Varb with Workflow Commands
    • Github Token Secret
    • Add Script to workflow
    • Push Package #1
    • Push Package #2 Docker
    • Service Containers
    • Routing workflow to runner
    • CodeQL Step
    • Caching Package and Dependency Files
    • Remove workflow Artifact
    • Workflow Status Badge
    • Env Protection
    • Job Matrix Configuration
    • Disable & Delete Workflows
    • Actions type for Action
    • Inputs and Outputs for actions
    • Action Versions
    • Files and Directories for Actions
    • Exit Codes
    • Reusable Workflow & Reuse Templates for Actions and Workflows
    • Configure Self Hosted Runners for Enterprise
  • Loki
    • What is Loki?
    • Architecture of Loki
    • Install Loki For Ubuntu
    • Install Promtail For Ubuntu
    • Querying Logs
    • Loki in Kubernetes
    • Deploying Loki in Kubernetes
    • Connecting to Grafana
    • Viewing Kubernetes logs
    • Promtail Customize & Pipeline
  • Ansible
    • Ansible Introduction
    • Introduction to Ansible Configuration Files
    • Ansible Inventory
    • Inventory Formats
    • Ansible Variables
    • Variable Types
    • Registering Variables and Variable Precedence
    • Variable Scoping
    • Magic Variables
    • Ansible Facts
    • Ansible Playbooks
    • Verifying Playbooks
    • Ansible lint
    • Ansible Conditionals
    • Ansible Conditionals based on facts, variables, re-use
    • Ansible Loops
    • Ansible Modules
    • Introduction to Ansible Plugins
    • Modules and Plugins Index
    • Introduction to Handlers
    • Ansible Roles
    • Ansible Collections
    • Introduction to Templating
    • Jinja2 Templates for Dynamic Configs
  • 🅰️Ansible Advanced
    • Playbook run options
    • Facts
    • Configuration files
    • Install required packages
    • SSH keys to managed nodes
    • Adhoc Commands
    • Commands with shell scripts
    • Privilege Escalation
    • Frequently Asked Questions
    • Additional Modules
    • Variable Precedence
    • Variable Scope
    • Use variables to retrieve the results of running commands
    • Magic Variables
Powered by GitBook
On this page

Was this helpful?

  1. Kubernetes

Ingress

PreviousService AccountNextImagePullPolicy & ImageSecret

Last updated 2 years ago

Was this helpful?

Service bölümünde, uygulamalarımızın dış dünyadan erişilebilmesi için, node port ve Load balancer tipinde servislere sahip olduğumuzu görmüş ve bunların detaylarını işlemiştik. Fakat bu yöntemlerin ikisi de OSI layer 'da yani IP layer' da çalıştıkları için bizlerin bazı sorunlarını çözmüyor.

Bu bölümde öncelikle bu sorunları tek, tek tanımlayalım ardından da bu sorunların çözümü olan, Ingress controller ve ingress objelerini görelim. İlk olarak sorunu tanımlayalım;

Azure, Google, AWS gibi bir servis sağlayıcı üstünde yönetilen kubernetes hizmetlerinden, birini kullandığımızı varsayalım. Misal, Azure kubernetes service. Bu kubernetes cluster üstünde, bir uygulama deploy ettik ve uygulamayı da dış dünyadan erişilebilmesi için, Load balancer tipi bir servis ile expose ettik.

Load Balancer tipi bir service oluşturduğumuz zaman ne oluyordu?

Azure bizim için, bir load balancer yaratıp buna public bir IP atıyordu. Ve bu IP adresine gelen tüm istekleri bu servise yönlendiriyordu. Biz de bu IP adresi ile, bu servisin domaini DNS ile eşleştirerek kullanıcıların erişmesini sağlıyoruz.

Aynı kubernetes cluster da 2.bir uygulama deploy ettiğimizi ve aynı şekilde Load Balancer tipi bir servis ile dış dünyaya açtığımızı düşünün, aynı süreç işleyecek Azure bir Load Balancer daha yaratacak, bir tane daha public IP olacak. 3. bir servis yaratmak istersek, yine aynısı olacak. Bu süreç her yeni uygulama yayınlamak istediğimizde aynı şekilde devam edecek. Özetle 30 servisim varsa, 30 tane Load balancer olacak.

Her bir load balancer için, ayrı ayrı para ödememiz gerekiyor. Bu ciddi problem. Her servis için ayrı bir servis oluşturursak, belirli bir zaman sonra işin içinden çıkamayız. Bu bizim ilk sorunumuz.

2. sorunumuz ise, bizim micro servis mimarisinde bir uygulamamızın olduğunu düşünelim. Bu uygulama da şöyle çalışıyor; eğer kullanıcılar "www.example.com" şeklinde root path'e gelirlerse, "A" uygulamasına tarafından sayfa sunuluyor.

Fakat kullanıcı "www.example.com/about" adresine gelirse, bu sayfa "B" uygulaması tarafından, sunuluyor. Bu durumda, mevcut load balancer servisi ile ile bizim bu ortamı kurgulamamız imkansız çünkü, DNS'de www.example.com/about şeklinde path base olarak tanımlama yapamayız. DNS 'de bu mümkün değil, bizim bir şekilde kullanıcı isteklerini bir yerde karşılayıp ve kullanıcının gitmek istediği URL anlayıp, buna göre arkada hangi servise gitmesi gerekiyorsa, ona yönlendirmem gerekiyor.

Uzun lafın kısası, bizim standart sadece IP ve port base yönlendirme yapan, L4 load balancer yerine, L7 de çalışan, application based load balancer'a ihtiyacımız var. Anlatıığım bu 2 sorun da, kubernetes dünyasında ingress controller ve ingress objeleri ile çözüyoruz.

Ingress controller, L7 application load balancer kavramının kubernetes spesifikasyonlarına göre çalışan ve kubernetes de deploy ederek kullanabildiğimiz türüdür. Nginx,Haproxy,Trafeik en bilinen ingress controller uygulamalarıdır.

Özetle, hepsinin yaptığı iş aynıdır. Biz öncelikle bunlardan bir tanesini seçip ve yönergelerini takip ederek ingress controllerı kubernetes clusterımıza kuruyoruz. Bu kurulumu yaptıktan sonra, eğer cloud üstünde çalışıyorsak, bu ingress controller dış dünyaya bir load balancer servisi ile expose oluyor ve public bir IP adresine sahip oluyoruz. Bu noktadan itibaren, artık dış dünyadan kubernetes'e erişim sadece bu IP üstünden sağlanıyor. Sonrasında ise, bu ingress controller'ın, konfigürasyonunu yani, servislerimize dış dünyadan hangi URL üstünden, nasıl ulaşacak kısmını ise, Ingress objeleri dediğimiz objeler arayıcılığıyla belirliyoruz.

Ingress objeleri bizim, ingress controller'ı kubernetes objeleri arayıcılığıyla ayarlamamızı sağlıyor. Genellikle HTTP olarak üzere, bir clusterdaki servislere harici erişimi yöneten bir API nesnesidir.

Yük dengeleme, SSL sonlandırması ve path base routing özelliklerini destekler.

L7 application load balancer 'mız olan ingress controller 'a bağlanarak, "www.example.com" A uygulamasına ve "www.example.com/about" gelen istekleri B uygulamasına, www.example2.com adresine gelen istekleri C uygulamasına yönlendir şeklinde o uygulamanın menülerine, özelliklerini kullanıp ayar yapmak yerine, tüm bu istekleri ingress objesi şeklinde oluşturuyoruz. Deploy ettiğimiz zaman, ingress controller bu objeyi okuyarak, gerekli düzenlemeyi otomatik olarak yapıyor.

Ingress controller bizlere, L7 application load balancer'ların sunduğu, SSL,Path based routing vb. bir çok özelliği kubernetes objeleri olarak deploy edebilmemize olanak sağlıyor.

Ingress için öncellikle, bir ıngress controller kurulması gerekiyor. Bir çok ıngress controller mevcut. Ama bunların genelde 2 tanesi öne çıkmış durumda,

1 => Nginx 2 => Trafeik

Biz nginx ile devam edeceğiz, Nginx'i kubernetes cluster'a nasıl kurabiliriz?

Her ingress controller kurulumu farklıdır. Parametreleri kurulduğu yere göre, aldığı opsiyonlara göre değişebilir. O nedenle bu gibi kurulumların detaylarını ingress controller 'ın kendi dökümantasyonundan öğrenebilirsiniz.

Minikube için Nginx ingress controller kurulumu;

Uygulama;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blueapp
  labels:
    app: blue
spec:
  replicas: 2
  selector:
    matchLabels:
      app: blue
  template:
    metadata:
      labels:
        app: blue
    spec:
      containers:
      - name: blueapp
        image: ozgurozturknet/k8s:blue
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /healthcheck
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
---
apiVersion: v1
kind: Service
metadata:
  name: bluesvc
spec:
  selector:
    app: blue
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: greenapp
  labels:
    app: green
spec:
  replicas: 2
  selector:
    matchLabels:
      app: green
  template:
    metadata:
      labels:
        app: green
    spec:
      containers:
      - name: greenapp
        image: ozgurozturknet/k8s:green
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /healthcheck
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3
---
apiVersion: v1
kind: Service
metadata:
  name: greensvc
spec:
  selector:
    app: green
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: todoapp
  labels:
    app: todo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: todo
  template:
    metadata:
      labels:
        app: todo
    spec:
      containers:
      - name: todoapp
        image: ozgurozturknet/samplewebapp:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: todosvc
spec:
  selector:
    app: todo
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Bu yaml dosyası içerisinde, 3 uygulama deploy ediyoruz. Bu 3 uygulamanın da cluster içerisinden erişilebilir olması için clusterIP tipinde 3 ayrı service objesi oluşturup, uygulamalara atıyoruz.

Bizim bu uygulamaları L7 APP LB üstünden expose etmemiz gerekecek, bunun için gerekli ilk şey ingress controller'dır. Bu ingress controller 'ı minikube kullanıyorsanız yukarıdaki bağlantıya giderek kurulumunu yapabilirsiniz. İngress controller kurulumundan sonra, ingress objeleri oluşturup işlemleri gerçekleştirebiliriz.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: appingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - host: k8sfundamentals.com
      http:
        paths:
          - path: /blue
            pathType: Prefix
            backend:
              service:
                name: bluesvc
                port:
                  number: 80
          - path: /green
            pathType: Prefix
            backend:
              service:
                name: greensvc
                port:
                  number: 80

Ingress de aynen pod, service gibi bir kubernetes objesidir. Networking.k8s.io/v1 api da bulunuyor. tipi de ingress 'dir. Bu objenin spec kısmında, kurallar belirleyerek servisleri ingress üstünden dış dünyaya açıyoruz. Bu örnekte k8sfundamentals.com domainine ait bir servis yayınladığımızı söylüyor ve altında 2 path belirtiyoruz. Eğer bu domaine /blue şeklinde bir istek gelirse, bunun blusvc servisinden cevap vermesini, /green pathine istek gelirse, greensvc servisinden cevap vermesini sağlıyoruz.

Annotations kısmı ise, cluster'a deploy ettiğimiz ingress controller üstünde, herhangi bir ayar yapmak isterseniz bunu hemen, hemen tüm ingress controller için annotations arayıcılığıyla yapıyoruz. Misal bu servis dış dünyaya HTTPS olarak açmak isteseydik kullanmak istediğimiz sertifika bilgilerini annotations arayıcılığıyla girecektik. vb. kullanabileceğimiz annotationslara kullandığımız ingress controller dökümantasyonundan ulaşabiliriz.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: todoingress
spec:
  rules:
    - host: todoapp.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: todosvc
                port:
                  number: 80

Bu ingress dosyasında da, todoapp.com adresine gelen bütün istekleri todosvc isimli servise gönder diyoruz.

Biz bu ingress objelerini deploy ettiğimiz zaman, Kubernetes tüm bu bilgileri bizim ingress controller'ımıza gönderecek ve orada tüm veriler birleştirilip ilgili ingress controller üzerinde gerekli ayarlamalar yapılacak.

Ek not, eğer sistemde birden fazla ingress controller varsa, '--ingress-class=" argümanı ile kullanmak istediğiniz ingress controller 'ın "ingress-class" değerini öğrenip, bunu ingress objesi dosyasında özellikle belirtip, istediğiniz ingress controller'ı kullanabilirsiniz. Kaynak ve örnek;

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: todoingresstestv1
  annotations:
    kubernetes.io/ingress.class: "k8s.io/internal-nginx"
spec:
  rules:
    - host: todoappv1.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: todosvc
                port:
                  number: 80
🍎
📈
Set up Ingress on Minikube with the NGINX Ingress ControllerKubernetes
Multiple Ingress controllers - NGINX Ingress Controller
IngressKubernetes
Kubernetes Ingress Tutorial: Beginners SeriesDevopsCube
Logo
Logo
Logo
Logo