1 of 33

☁️ Cloud ☁️

CIS 1912

2 of 33

HW2 Recap

3 of 33

4 of 33

Mid-Semester Feedback

5 of 33

Traditional Infrastructure

Physical servers in racks
Responsibilities?
One application per machine

Inefficient for small workloads

6 of 33

Recall:

Spot Instances

Recall that there are multiple types of “VMs”

Does it run arm? x86?

Contract-based reservations tend to be cheaper
On-Demand Scaling
Sacrificing availability for performance / horizontal scaling

7 of 33

Virtualization

Idea: slice up our servers into smaller "virtual machines"
Great resource efficiency and portability
Still have to maintain physical servers!

8 of 33

Cloud: VMs

"Cloud providers" manage physical servers, providing the user an API through which to access VMs
No more physical server management!
Comes at a cost

Would I rather pay a sysadmin to do this or pay AWS to do it better?

9 of 33

Cloud: Managed Open Source Software

Manage OSS application and rent out access
OSS reduces potential for vendor lock-in

Other providers will have analogous offerings

Sometimes toxic for OSS creators

Business Source License

Managed Kubernetes!

10 of 33

Cloud: Managed Proprietary

Proprietary services specific to cloud providers
Provide best-in-class integration in-provider
Create potential for lock-in

Is this a problem?

11 of 33

Cloud

Functions

Appropriate for Microservices
Single-function server programs
Cloud Nativeness

Functions can have roles

(theoretically) Infinite Horizontal Scaling
What problems could arise?

12 of 33

Cloud vs Local

13 of 33

Exposing Services

Expose via service type

ClusterIP
NodePort
LoadBalancer

Traffic hits service directly

14 of 33

ClusterIP

An IP address linked to a service which is only available from within the cluster or by forwarding a port using kubectl.
This service type should only be used for services that only communicate in-cluster.

15 of 33

NodePort

Opens a port on every node in the cluster.
Forwards incoming requests to the service associated with the port.

16 of 33

LoadBalancer

Application that lives and is provisioned outside of Kubernetes, managed by K8s
The load balancer gets an IP and forwards data transmitted to that IP along to the nodes within your cluster.

17 of 33

Ingress

Expose multiple services through single LB
Allows for common routing behavior ex. TLS, timeouts, authentication

18 of 33

Productionizing Kubernetes

19 of 33

Productionizing Kube

Need system to store & distribute secrets
Permissioning system
Consumption through Kube or direct API calls

Secrets

Ingress providers need HTTPS
Use "challenges" to automatically prove ownership of a domain

TLS Certificates

20 of 33

Secrets: are we done?

How do we create our secrets securely?

21 of 33

Hashicorp Vault

Tool for storing and distributing secrets
Encrypts secrets at rest
Complex permission system for fine-tuning who can access what
Consumption methods

Through synced Kube secrets
Directly through Vault API

22 of 33

Cert Manager

Ingress provider wants HTTPs, but how do we get our TLS certificates?
Want to prove ownership of domain
Methods

Old way: request through web form
New way: dynamically request and prove ownership via Let's Encrypt

Cert Manager to perform LE challenges
Operator to add to Kubernetes

23 of 33

---

apiVersion: v1

kind: ConfigMap

metadata:

namespace: kube-system

data:

traefik.toml: |

defaultEntryPoints = ["http","https"]

debug = false

logLevel = "INFO"

#Config to redirect http to https

[entryPoints]

[entryPoints.http]

address = ":80"

compress = true

[entryPoints.http.redirect]

entryPoint = "https"

[entryPoints.https]

address = ":443"

compress = true

[entryPoints.https.tls]

[api]

[api.statistics]

recentErrors = 10

[kubernetes]

[metrics]

[metrics.prometheus]

buckets=[0.1,0.3,1.2,5.0]

entryPoint = "traefik"

[ping]

entryPoint = "http"

[accessLog]

[consul]

endpoint = "consul-consul-server:8500"

watch = true

[acme]

email = "admin@pennlabs.org"

storage = "traefik/acme/account"

acmeLogging = true

entryPoint = "https"

onHostRule = true

[acme.httpChallenge]

entryPoint = "http"

kind: DaemonSet

apiVersion: apps/v1

metadata:

namespace: kube-system

labels:

app: traefik-ingress-lb

spec:

selector:

matchLabels:

app: traefik-ingress-lb

template:

metadata:

labels:

app: traefik-ingress-lb

spec:

serviceAccountName: traefik-ingress-controller

terminationGracePeriodSeconds: 60

initContainers:

- image: traefik:v1.7-alpine

args:

- storeconfig

- --configfile=/config/traefik.toml

volumeMounts:

- mountPath: /config

containers:

- image: traefik:v1.7-alpine

volumeMounts:

- mountPath: /config

ports:

- name: http

containerPort: 80

- name: https

containerPort: 443

- name: admin

containerPort: 8080

args:

- --api

- --kubernetes

- --configfile=/config/traefik.toml

livenessProbe:

httpGet:

path: /ping

port: 80

initialDelaySeconds: 3

periodSeconds: 3

timeoutSeconds: 1

volumes:

- name: config

configMap:

---

apiVersion: v1

kind: ServiceAccount

metadata:

namespace: kube-system

---

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

rules:

- apiGroups:

- ""

resources:

- services

- endpoints

- secrets

verbs:

- get

- list

- watch

- apiGroups:

- extensions

resources:

- ingresses

verbs:

- get

- list

- watch

---

kind: ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

subjects:

- kind: ServiceAccount

namespace: kube-system

---

kind: Service

apiVersion: v1

metadata:

namespace: kube-system

labels:

app: traefik-ingress-lb

spec:

selector:

app: traefik-ingress-lb

ports:

- protocol: TCP

port: 80

- protocol: TCP

port: 443

type: LoadBalancer

24 of 33

YAML Overload

Levels of abstraction:

Raw YAML
Kustomize
Helm
CDKs

25 of 33

Helm

Templating engine for Kubernetes manifests
Packages templates as "charts"
Allows for customization of chart specifics:

Port number
HTTP/HTTPS
Naming

26 of 33

replicas: 5

deploymentStrategy:

rollingUpdate:

maxSurge: 1

maxUnavailable: 0

type: RollingUpdate

ssl:

enabled: true

enforced: true

permanentRedirect: true

upstream: false

insecureSkipVerify: false

generateTLS: false

persistence:

enabled: false

dashboard:

enabled: false

accessLogs:

enabled: true

format: common

rbac:

enabled: true

metrics:

prometheus:

enabled: true

buckets: [0.1, 0.3, 1.2, 5]

service:

annotations:

prometheus.io/scrape: "true"

prometheus.io/port: "9100"

27 of 33

Helm Demo

28 of 33

HW3 Note

29 of 33

Back to Wharton Computing

“Several years ago, Wharton started their cloud transition from running all their IT services on-premises to a cloud deployment model that includes Amazon Web Services (AWS) ...

The IT teams biggest challenge with their cloud deployment was that every AWS VPC change required manual network changes that took at least one week or more to implement..”

30 of 33

Config on Cloud

What are some challenges?

31 of 33

32 of 33

Fin

Lab 2: Local Kubernetes due soon
Lab 3: Cloud Kubernetes will be released soon
Come to office hours!

33 of 33

Credits

Datacenter pic:

https://medium.com/swlh/how-to-move-a-data-center-4ab553cd131d

VM pic:

https://www.veeam.com/blog/why-virtual-machine-backups-different.html\

Ingress examples:

https://matthewpalmer.net/kubernetes-app-developer/articles/kubernetes-ingress-guide-nginx-example.html