1. Kubernetes services can be used to abstract external dependencies like databases and SaaS services, decoupling consumers from providers. 2. For databases, a service allows using a single-instance container database in test environments instead of a production cluster, without consumers needing different configurations. 3. For SaaS services, an ExternalName service type maps the service to the real URL in production but to a virtualization pod in tests, providing fake responses without consumers knowing.

1. Composing Services* with
Kubernetes
Bart Spaans
@bartspaa

2. Hi!
● Founder @AnkyraLtd
● Continuous delivery on modern infrastructure
● I also briefly studied to be a composer

3. Kubernetes

4. Services
● “A Kubernetes Service is an abstraction which defines a logical set of Pods and a
policy by which to access them”
● But we can also use Services to decouple from external dependencies

5. External Dependencies
● Databases
● Queues
● SaaSes

6. External dependencies as far as the eye can see…
...and one day they will all be yours (to configure)
Woah!

7. Problem?
● Multitude of tools
● Not always multi-tenancy
● Not always automatable
● Hampers delivery speed

8. Multiple
Environments
● CI
● Perf
● Staging
● Live
● Perf2
● Staging2
● Staging-test1
● Perf3-pls-dont-destroy
● Live2
● Prod
● ...And they all need
different config

9. “Just deploying a new environment”

10. Today: Composition
Tips
Focusing on that last problem:
external dependencies across
multiple environments

11. 1. The Database

12. Scenario
Imagine a distributed database not running inside a cluster.
Dedicated SSDs, private network, tuned kernel, the works.

13. The highly tuned, distributed cluster is overkill for testing environments
Slow to setup compared to containers
The Problem

14. The highly tuned, distributed cluster is overkill for testing environments
Slow to setup compared to containers
The Problem

15. Kubernetes Solution
Instead of directly consuming the database URL add a Kubernetes Service for an
external dependency
In the “light” environments deploy the database as a single instance container =>
consumers are none the wiser and don’t need any extra config
database.internal.domain database.default.svc.cluster.local

16. Discovering External Services in Production
apiVersion: v1
kind: Endpoints
metadata:
name: eventstore
subsets:
- addresses:
- ip: 10.132.10.10
- ip: 10.132.10.11
- ip: 10.132.10.12
ports:
- name: rest-api
port: 2114
protocol: TCP
- name: client-api
port: 1112
protocol: TCP
kind: Service
apiVersion: v1
metadata:
name: eventstore
spec:
ports:
- name: rest-api
protocol: TCP
port: 2114
targetPort: 2114
- name: client-api
protocol: TCP
port: 1112
targetPort: 1112
eventstore.default.svc.cluster.local => loadbalancer for external IPs
No selector

17. Discovering External Services in Test
apiVersion: v1
kind: Endpoints
metadata:
name: eventstore
subsets:
- addresses:
- ip: 10.132.10.10
- ip: 10.132.10.11
- ip: 10.132.10.12
ports:
- name: rest-api
port: 2114
protocol: TCP
- name: client-api
port: 1112
protocol: TCP
kind: Service
apiVersion: v1
metadata:
name: eventstore
spec:
selector:
app: eventstore
ports:
- name: rest-api
protocol: TCP
port: 2114
targetPort: 2114
- name: client-api
protocol: TCP
port: 1112
targetPort: 1112
eventstore.default.svc.cluster.local => loadbalancer for internal pods
Let Kubernetes
create Endpoints
for this selector

18. Why not just configure
the clients differently in
testing environments?
- Because you’d have to change that
configuration for all the consumers
depending on environment, instead of
not at all
- This approach puts the onus on the
deployment process of the provider

19. Snapshot of the Ankyra release registry showing the production unit

20. 2. The SaaS

21. Software as a Service
These can be great*
Save time
Benefits TCO
Piggyback on the provider’s economies of scale
Buys piece of mind
* Every SaaS is equal, but some SaaS are more equal than others

22. Downsides
They’re usually not free (in any sense of the word)
They may not support multi-tenancy / multi-environments
They may not be automatable
They can introduce flakiness when used directly in tests
They affect measurements when used in performance testing environments

23. Service
Virtualisation
Record interactions with a
service, play them back in
a test environment.
OSS Examples: wiremock,
hoverfly, mock-server,
mountebank, ...

24. Kubernetes Solution
Deploy a Service of the new ExternalName type

25. New in 1.7
Prod
kind: Service
apiVersion: v1
metadata:
name: saas
spec:
type: ExternalName
externalName: saas.example.com
Test
kind: Service
apiVersion: v1
metadata:
name: saas
spec:
selector:
app: saas-mock-stub-virtualisation
ports:
- name: http
protocol: TCP
port: 80
targetPort: 8080
=> saas.default.svc.cluster.local resolves to a
CNAME record with the value
saas.example.com
=> saas.default.svc.cluster.local resolves to
local pods

26. What about
certificates?
This kind of breaks the illusion...
● Requires a certificate for
“saas.default.svc.cluster.local”
● SV software usually supports self-signed
certificates
● But the SaaS probably doesn’t…
● Requires another approach

27. Conclusion
Using Services we can decouple providers from consumers
This allows us to deploy downgraded or faked providers
Which gives us a way to somewhat deal with external dependencies

28. Thanks!
@bartspaa
@AnkyraLtd