Embed Size (px)
Citation preview
Towards cloud native computing
Container Packaged
Dynamically Scheduled
Microservices Oriented
Towards cloud native computing
Container Packaged
Dynamically Scheduled
Microservices Oriented
Not just Google ...
… n other internet companies
contextposit that “cloud native” is three things1. container packaged 2. dynamically scheduled 3. micro-services oriented
micro-services• lets developers assemble small, independently deployable components
• create loosely coupled, more agile systems• a basic atom of consumption for software• a basic atom of management for software
why?
Loosely coupled = easier to build and extend
• Compose applications from micro-services• Mix in and extend third party services• More agile systems and teams
why?
Separation of concerns = specialization
• Separate infrastructure ops from cluster ops from app ops• Radically increase code reuse• Radically reduced operations overhead
why?
Deeper automation = fewer bad outcomes
• Higher abstraction provides more insight into behavior• Orchestration made far easier• Self-healing and self-managing systems
Greek for “Helmsman”; also the root of the word “Governor”, “Cybernetics’
• Container orchestrator • Runs Docker containers• Supports multiple cloud and bare-metal
environments• Inspired and informed by Google’s experiences
and internal systems• Open source, written in Go
Manage services, not machines
Kubernetes
libs
app
kernel
libs
app
libs
app
libs
app
libs
app
kernel
libs
app
libs
app
libs
app
Kubernetes Master
libs
app
kernel
libs
app
libs
app
libs
app
Kubernetes gives you a cluster
Pod
Labels
Replication Controller
Service
Kubernetes Core Concepts
Group of containers
Live and die together
Shared network interface
Pod
Serving app
Data updater
Log collector
Pod
Label anything
Name-value pair
Make your own
Grouping via label selector
Pod
App
Log Collector
...
type = Frontend
version = 1.0
Labels
ReplicationController
Replicas → 2Pod
App
Log Collector
...
type = Frontend
version = 1.0
Pod
App
Log Collector
...
type = Frontend
version = 1.0
Replication Controller
ReplicationController
Replicas → 1Pod
App
Log Collector
...
type = Frontend
version = 1.0
Pod
App
Log Collector
...
type = Frontend
version = 1.0
Replication Controller
ReplicationController
Replicas → 2Pod
frontend
Pod
type = Frontend
version = 1.0
Pod
type = Frontend
version = 1.0
Service
Label selectors: version = 1.0 type = Frontend
(micro) Service
Pods are ephemeral● Need something addressable that is not
How do one set of ephemeral things find another set?● Discoverable through DNS● Discoverable environment variables
In time can do fancy things● Dynamic activation, context based scheduling, etc
Micro-services are a gateway to agile apps
Offers a minimum atom of software consumption● Minimally (hostname, port)● Endpoint API (enumerate membership; watch for changes)● Relies on a label selector to establish service membership
Offers a simple framework for orchestration● Route based on a label selector● Blue/Green● Canary deployment● ...
Kubernetes Services Defined
Service Scoping
Two basic scope levels● Cluster● Namespace
{ "kind": "Service", "apiVersion": "v1", "metadata": { "name": "my-service" }, "spec": { "selector": { "app": "MyApp" }, "ports": [ { "protocol": "TCP", "port": 80, "targetPort": 9376 } ] }}
Creating a Service
Assumes a set of pods listening on port 9376, with label ‘MyApp’ set.
POST to the API server will create a new service object
Finding your service: Environment variables
Automatically adds environment variables that are available to each container
REDIS_MASTER_SERVICE_HOST=10.0.0.11REDIS_MASTER_SERVICE_PORT=6379REDIS_MASTER_PORT=tcp://10.0.0.11:6379REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379REDIS_MASTER_PORT_6379_TCP_PROTO=tcpREDIS_MASTER_PORT_6379_TCP_PORT=6379REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
Finding your service: DNS
An optional capability is DNS support (offered as a cluster add-on)
Server watches Kubernetes Services API and automatically creates DNS records for services
Use DNS Lookup with <service-name>.<namespace> to resolve IP
Services in the same namespace can be found via <service-name>
Broadening the Service definition: External services
VM LB IP:Port
VM IP:Port
K8sPod
Other clouds/On-prem IP:Port
Multiple Producers You may want to ‘mix in’ other services (VM based/SaaS based)
Ideally consume them as if they were ‘native’ to your cluster
To support this, it is possible to create services without specifying a selector
Towards a cluster environment
● A critical step towards ‘cloud native development’● Brings a new ‘type B’ cloud
○ Run it natively○ Overlay it on your ‘type A’ cloud infrastructure
Towards standards: CNCF
compute nodeOS
out of scope
api specification
reference implementation
container runtime
infrastructure provisioning
agent
OCI reference implementationOCI api specification
…. N
distributed systems services
resource scheduling
application definition and orchestration
software defined network software defined storage
container image repository
container image registry
Distributed systems services
compute nodeOS
container runtime
infrastructure provisioning
agent
…. N
resource scheduling
application definition and orchestration
software defined network software defined storage
container repository
container registry
distributed systems services
● a standard set of services that are not bound to a single node○ supporting application use cases
■ naming/discovery■ locking/quorum■ state management/sharding■ logging/monitoring
○ supporting cluster use cases■ distributed state management■ distributed control plane■ logging/auditing
● a minimum atom of consumption for software○ within the cluster○ between clusters○ from outside the cluster
Learn more.
Talk to me...Twitter: @cmcluckEmail me: [email protected]
Follow Kubernetes…Twitter: @kubernetesioGithub: https://github.com/googlecloudplatform/kubernetesBlog: http://blog.kubernetes.io/
