2. DATA AGGREGATOR
KUBERNETES @ BE-MOBILE 2
Be-Mobile
mobility
database
Floating car data
• GPS data
• Smartphone data
• Telco data
Road sensors
• Cameras
• Radars
• Loops
Crowd sourced
• Drivers
• Social media
• Police
• Emergency vehicles
Other data
• Public transport
• Car & bike sharing
• Vehicles & bike parking, fuel
• Traffic emission & noise zones
• Toll
Sourcesfrom>20countries
3. WHO WE ARE
KUBERNETES @ BE-MOBILE 3
Smart Tolling &
Map Matching
Mobility
as a Service
Mobility Monitoring
& Analysis
Traffic
Management
Smart ParkingMobility Payments
Platform
Connected Vehicle
Platforms
Traveler
Information
Smart
mobility
5. MANUAL DEPLOYMENT
➞ Deployments were done manually on the servers
• Growing amount of countries where Be-Mobile is active
• Each country needs the same basic set of applications to be set up
• Growing amount of developers
• Meaning more applications to be deployed
• But, all deployments done by the DevOps-team
➞ Time to deployment increased due to the growth
➞ Management of the applications was getting complex
➞ Human errors might occur
KUBERNETES @ BE-MOBILE 5
6. PUPPET DEPLOYMENT
Dependencies problem: correct version of NodeJS, Java, Mono,…
• Programming the deployment of the applications by configuration
• Roll-outs of new countries and applications were much faster
• Helped avoiding human errors
KUBERNETES @ BE-MOBILE 6
7. PUPPET+DOCKER DEPLOYMENT
• Isolated environments for an application
• Contains all necessities for the application
• E.g.: website + webserver / Java application + Java framework
• No more need for ‘type-specific servers’
• Different types of applications
can all run on the same server
• Easy to migrate a container or scale
over multiple servers
KUBERNETES @ BE-MOBILE 7
8. HOWEVER… NEW BOTTLENECKS
• Chaining multiple applications
• Time consuming
• Error sensitive
• Crashes
• Manual interventions
• Deployments
• Faster, but still a backlog of deployments
KUBERNETES @ BE-MOBILE 8
10. WHAT IS KUBERNETES
• Google project (Borg) made open-source
• Further developed by a strong community
• Orchestration of containers
• Namespaces
• Self-healing
• Allows us to create deployment chains
KUBERNETES @ BE-MOBILE 10
11. ORCHESTRATION IN KUBERNETES
• Multiple servers are combined into a cluster
• Kubernetes picks a server to deploy an container to
• By checking the container resource needs (CPU/memory)
• By checking the servers resource availability
• Containers can be scaled or made high available very easy
• Different ways to do a deployment
• E.g.: rolling update, recreate
KUBERNETES @ BE-MOBILE 11
12. SELF-HEALING WITH KUBERNETES
• When a container no longer responds
• Health checks detect this (if configured)
• Container gets destroyed and restarted
• When a container crashes
• Container gets restarted
• When a server crashes
• Move containers running on the crashed server to another one
➞ Faster recovery time!
KUBERNETES @ BE-MOBILE 12
13. STARTING WITH KUBERNETES
First experience: The Sockshop demo from the kubernetes.io site (on minikube)
KUBERNETES @ BE-MOBILE 13
14. PRODUCTION DEPLOYMENT
Installing kubernetes on bare metal!
A lot of deployment guides are focused on cloud environments
Started with kargo (now known as kubespray). Was our first production cluster.
Very alpha, updating between versions of kubernetes or kargo was very hard.
Then we tried with Kismatic
Easy and well documented installation
”Community” support is great, but only people from Apprenda are working on it
Is still our current installation method.
KUBERNETES @ BE-MOBILE 14
16. OPTION 1: GLUSTERFS
First experience with distributed storage systems
Installed automatic with Kismatic
Pros:
• Easy to manage/setup
Cons:
• We had to create our Persistent Volumes ourselves
• For some reason, not scalable when creating a lot of volumes
KUBERNETES @ BE-MOBILE 16
17. OPTION 2: CEPH
Deployed with Ansible
Pros:
• It just works.
• And really fast!
• StorageClass support in Kubernetes
Cons:
• Steep learning curve
• More complex architecture (compared to GlusterFS)
KUBERNETES @ BE-MOBILE 17
19. WHAT DO WE DEPLOY ON KUBERNETES?
What we do not deploy on Kubernetes :
• Kafka
• Cassandra
• MongoDB
• Ceph
• Elastic Search
• Redis*
What do we deploy on Kubernetes:
• Everything else.
KUBERNETES @ BE-MOBILE 19
20. INSTALLATION SERVERS: ANSIBLE
• Installing one server was OK, installing 10 servers is slow, repetitive and boring.
• Automatic server installations
• Partitioning
• Basic installation of the operating system
• Configuration of firewall rules
• Deployment of core components (Kubernetes/Ceph)
KUBERNETES @ BE-MOBILE 20
21. CLUSTERS TODAY
• More than 1 year of production
• We migrated once a full Kubernetes cluster (switch from Kargo to Kismatic)
• Largest cluster surpassed 100 nodes (6.9 TB memory, 1000+ cores)
• Multiple clusters: test cluster, QA clusters, staging cluster,..
KUBERNETES @ BE-MOBILE 21
31. NGINX INGRESS CONTROLLER AND WEBSOCKETS
Ingress controller getting unresponsive after a while
A lot of nginx processes still running
Perfect blog that describes the problem:
http://danielfm.me/posts/painless-nginx-ingress.html
KUBERNETES @ BE-MOBILE 31
Welkomstwoord / wat zal er besproken worden
Introductie mezelf / team (verantwoordelijkheid van devops team: infrastructuur, shared applicaties en GPS data)
Eerste meetup Be-Mobile
Be-Mobile is opgericht in 2007 met Touring als meerderheids aandeelhouder, sinds 2 jaar is nu Proximus aandeelhouder geworden
- Verzamelen data van alle soorten bronnen (black box, smartphone data, social media, politie)
Verkeers data
Zo verzamelen we 20 miljard GPS posities per dag
Welke diensten leveren we dan aan:
Verkeersinformatie met media bedrijven
RDS TMC/connected
Analyse tools voor steden op historische data
Parking (4411) en parkeergeleidingssytemen
Traffic management (verkeers geleidings sytemen bij evenementen)
Tolheffing
Manueel deployment
Veel meer landen, elk met hun basis set aan applicaties
Meer en meer ontwikkelaars, dus ook meer applicaties die moeten uitgerold worden
Via devops team
Wachttijden
Complex applicatiebeheer
Menselijke fouten
HIER BESLIST GEEN VM, WAAROM
Automatisatie
Programmeren eigenlijk hoe applicaties en servers moeten geinstalleerd worden
Stijle leercurve
Roll-out van nieuwe landen gingen pakken sneller
Ook nieuwe applicaties gingen sneller
Application dependencies mee in package (java framework, webserver,..)
Geen nood aan specifieke java servers, web servers,..
Servers minder complex, gewoon docker containers draaien
Applicatie schalen of migreren is pakken eenvoudiger
Automatisatie brengt nieuwe bottle necks bloot
Minder bezig houden met servers, meer bezig houden met koppelen van applicaties
Nog altijd vrij foutgevoelig
Bij crashes moesten we manueel tussenkomen
Server crash: what to do
Snellere deployments, maar nog altijd een backlog
Service discovery met consul, maar gematigd succes
3 jaar geleden Open-Source gemaakt
Community omvat ook bedrijven als RedHat, GitHub en Google
Orchestration = beheer van de containers
Namespaces = samenplaatsen van containers en configuraties, kan gemakkelijk verwijderd worden
K8s = laag over de servers
Vroeger: zelf server kiezen om iets te deployen
Nu: Kubernetes laten weten dat we een container willen deployen, K8s will take care of it
Vb rolling updates: web container
Vb recreate: Icarus+ with state
Hier zou ik aangeven dat we eigenlijk geen concept meer hebben van een server, maar dat we een overkoepelende interface hebben waar we kunnen aangeven dat een container moet draaien met bepaalde parameters
- Health checks
Vroeger: alles manueel recoveren -> veel werk en tijdrovend
Nood aan state
Deze systemen zijn al cluster/ha based systemen
Performance redenen
Redis is een uitzonderding, hangt er van af hoe belangrijk de persistence is
Uitzondering is voor QA/staging omgevingen, waar we bewust de flexibel willen zijn en dat persistence/perfomance ondermaats is
Automatisatie startte pas vanaf we de automatisatie tool installeerde
Installeren van server viel mee van tijd.. Voor 1 server
Extra automatisatie tool die ons toelaat gewoon het IP adres meegeven en de rol van server.
Cluster van 10 server herinstalleren en terug operationeel hebben in <10 minuten
Meer dan 1 jaar in productie
Verschillende clusters, waaronder het grootste nu meer dan 100 servers bevat.
Reden van verschillende clusters: QA cluster, staging cluster, test cluster
Developer pusht code
Buildserver compileert de applicatie
Buildserver maakt de container voor de applicatie
Slack notification “Deploy to Kubernetes?”
Approval van teamlead of DevOps
VMAP deployments:
Basis componenten voor een basemap uitrollen
Project deloyments:
Pipedrives
Alle configuratie zit samen op 1 plaats
Tool leest de configuratie en geeft deze door aan Kubernetes om te deployen
QA:
Mogelijkheid om heel snel omgevingen op te starten en te verwijderen
Geen achterblijvende test-files
Meerdere environments naast elkaar draaien
Beheer ligt volledig bij QA (en Devs)
C-ITS
Eigen deployment-systeem ontwikkeld door Backend
QA:
Mogelijkheid om heel snel omgevingen op te starten en te verwijderen
Geen achterblijvende test-files
Meerdere environments naast elkaar draaien
Beheer ligt volledig bij QA (en Devs)
C-ITS
Eigen deployment-systeem ontwikkeld door Backend
Nieuw deze maand
Communicatie met kube-api gebeurt via kubectl en tls certificates, vault genereert certfificaten
Eigen kubetoken programma die kubeconfig goed zet
