Group items tagged

A controller tracks at least one Kubernetes resource type.

The controller(s) for that resource are responsible for making the current state come closer to that desired state.

in Kubernetes, a controller will send messages to the API server that have useful side effects.

Built-in controllers manage state by interacting with the cluster API server.

By contrast with Job, some controllers need to make changes to things outside of your cluster.

As long as the controllers for your cluster are running and able to make useful changes, it doesn't matter if the overall state is stable or not.

Kubernetes uses lots of controllers that each manage a particular aspect of cluster state.

a particular control loop (controller) uses one kind of resource as its desired state, and has a different kind of resource that it manages to make that desired state happen.

There can be several controllers that create or update the same kind of object.

The control plane's components make global decisions about the cluster

Control plane components can be run on any machine in the cluster.

for simplicity, set up scripts typically start all control plane components on the same machine, and do not run user containers on this machine

The API server is the front end for the Kubernetes control plane.

kube-apiserver is designed to scale horizontally—that is, it scales by deploying more instances. You can run several instances of kube-apiserver and balance traffic between those instances.

Kubernetes cluster uses etcd as its backing store, make sure you have a back up plan for those data.

watches for newly created Pods with no assigned node, and selects a node for them to run on.

Factors taken into account for scheduling decisions include: individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines.

each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.

Node controller

Job controller

Endpoints controller

Service Account & Token controllers

The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.

If you are running Kubernetes on your own premises, or in a learning environment inside your own PC, the cluster does not have a cloud controller manager.

An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod.

The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy.

kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept.

kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.

Kubernetes supports several container runtimes: Docker, containerd, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface).

Addons use Kubernetes resources (DaemonSet, Deployment, etc) to implement cluster features

all Kubernetes clusters should have cluster DNS,

Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services.

Container Resource Monitoring records generic time-series metrics about containers in a central database, and provides a UI for browsing that data.

A cluster-level logging mechanism is responsible for saving container logs to a central log store with search/browsing interface.

name-based virtual hosting

Edge routerA router that enforces the firewall policy for your cluster.

A Kubernetes ServiceA way to expose an application running on a set of Pods as a network service. that identifies a set of Pods using labelTags objects with identifying attributes that are meaningful and relevant to users. selectors.

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.

An Ingress can be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting.

Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer.

Ingress frequently uses annotations to configure some options depending on the Ingress controller,

An optional host.

A list of paths

A backend is a combination of Service and port names

has an associated backend

Both the host and path must match the content of an incoming request before the load balancer directs traffic to the referenced Service.

HTTP (and HTTPS) requests to the Ingress that matches the host and path of the rule are sent to the listed backend.

An Ingress with no rules sends all traffic to a single default backend.

Ingress controllers and load balancers may take a minute or two to allocate an IP address.

A fanout configuration routes traffic from a single IP address to more than one Service, based on the HTTP URI being requested.

nginx.ingress.kubernetes.io/rewrite-target: /

describe ingress

get ingress

Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.

an Ingress resource without any hosts defined in the rules, then any web traffic to the IP address of your Ingress controller can be matched without a name based virtual host being required.

secure an Ingress by specifying a SecretStores sensitive information, such as passwords, OAuth tokens, and ssh keys. that contains a TLS private key and certificate.

An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others.

review the controller specific documentation to see how they handle health checks

edit ingress

After you save your changes, kubectl updates the resource in the API server, which tells the Ingress controller to reconfigure the load balancer.

kubectl replace -f on a modified Ingress YAML file.

Node: A worker machine in Kubernetes, part of a cluster.

in most common Kubernetes deployments, nodes in the cluster are not part of the public internet.

Edge router: A router that enforces the firewall policy for your cluster.

Service: A Kubernetes Service that identifies a set of Pods using label selectors.

An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting.

The Ingress spec has all the information needed to configure a load balancer or proxy server.

An Ingress with no rules sends all traffic to a single default backend and .spec.defaultBackend is the backend that should handle requests in that case.

If defaultBackend is not set, the handling of requests that do not match any of the rules will be up to the ingress controller

A common usage for a Resource backend is to ingress data to an object storage backend with static assets.

Exact: Matches the URL path exactly and with case sensitivity.

Prefix: Matches based on a URL path prefix split by /. Matching is case sensitive and done on a path element by element basis.

multiple paths within an Ingress will match a request. In those cases precedence will be given first to the longest matching path.

Hosts can be precise matches (for example “foo.bar.com”) or a wildcard (for example “*.foo.com”).

Each Ingress should specify a class, a reference to an IngressClass resource that contains additional configuration including the name of the controller that should implement the class.

secure an Ingress by specifying a Secret that contains a TLS private key and certificate.

The Ingress resource only supports a single TLS port, 443, and assumes TLS termination at the ingress point (traffic to the Service and its Pods is in plaintext).

hosts in the tls section need to explicitly match the host in the rules section.

each action also maps to particular CRUD operations in a database

One way to avoid deep nesting (as recommended above) is to generate the collection actions scoped under the parent, so as to get a sense of the hierarchy, but to not nest the member actions.

to only build routes with the minimal amount of information to uniquely identify the resource

The shallow method of the DSL creates a scope inside of which every nesting is shallow

These concerns can be used in resources to avoid code duplication and share behavior across routes

add a member route, just add a member block into the resource block

You can leave out the :on option, this will create the same member route except that the resource id value will be available in params[:photo_id] instead of params[:id].

Singular Resources

use a singular resource to map /profile (rather than /profile/:id) to the show action

Passing a String to get will expect a controller#action format

workaround

organize groups of controllers under a namespace

route /articles (without the prefix /admin) to Admin::ArticlesController

route /admin/articles to ArticlesController (without the Admin:: module prefix)

Nested routes allow you to capture this relationship in your routing.

Resources should never be nested more than 1 level deep.

via the :shallow option

a balance between descriptive routes and deep nesting

:shallow_path prefixes member paths with the specified parameter

Routing Concerns allows you to declare common routes that can be reused inside other resources and routes

Rails can also create paths and URLs from an array of parameters.

use url_for with a set of objects

In helpers like link_to, you can specify just the object in place of the full url_for call

insert the action name as the first element of the array

pass :on to a route, eliminating the block:

Collection Routes

simple routing makes it very easy to map legacy URLs to new Rails actions

add an alternate new action using the :on shortcut

When you set up a regular route, you supply a series of symbols that Rails maps to parts of an incoming HTTP request.

:controller maps to the name of a controller in your application

:action maps to the name of an action within that controller

This route will also route the incoming request of /photos to PhotosController#index, since :action and :id are

use a constraint on :controller that matches the namespace you require

dynamic segments don't accept dots

The params will also include any parameters from the query string

:defaults option.

set params[:format] to "jpg"

specify a name for any route using the :as option

create logout_path and logout_url as named helpers in your application.

Inside the show action of UsersController, params[:username] will contain the username for the user.

should use the get, post, put, patch and delete methods to constrain a route to a particular verb.

use the match method with the :via option to match multiple verbs at once

use the :constraints option to enforce a format for a dynamic segment

constraints

don't need to use anchors

the same name as the hash key and then compare the return value with the hash value.

constraint values should match the corresponding Request object method return type

blacklist

redirect helper

reuse dynamic segments from the match in the path to redirect

this redirection is a 301 "Moved Permanently" redirect.

root method

put the root route at the top of the file

root inside namespaces and scopes

For namespaced controllers you can use the directory notation

use the :constraints option to specify a required format on the implicit id

specify a single constraint to apply to a number of routes by using the block

non-resourceful routes

:id parameter doesn't accept dots

:as option lets you override the normal naming for the named route helpers

use the :as option to prefix the named route helpers that Rails generates for a rout

prevent name collisions

prefix routes with a named parameter

:only option

:except option

alter path names

http://localhost:3000/rails/info/routes

rake routes

setting the CONTROLLER environment variable

Routes should be included in your testing strategy

assert_generates assert_recognizes assert_routing

You can use role-based access control (RBAC) and other security mechanisms to make sure that users and workloads can get access to the resources they need, while keeping workloads, and the cluster itself, secure. You can set limits on the resources that users and workloads can access by managing policies and container resources.

you need to plan how to scale to relieve increased pressure from more requests to the control plane and worker nodes or scale down to reduce unused resources.

Managed control plane: Let the provider manage the scale and availability of the cluster's control plane, as well as handle patches and upgrades.

The simplest Kubernetes cluster has the entire control plane and worker node services running on the same machine.

You can deploy a control plane using tools such as kubeadm, kops, and kubespray.

Secure communications between control plane services are implemented using certificates.

Separate and backup etcd service: The etcd services can either run on the same machines as other control plane services or run on separate machines

Create multiple control plane systems: For high availability, the control plane should not be limited to a single machine

Some deployment tools set up Raft consensus algorithm to do leader election of Kubernetes services. If the primary goes away, another service elects itself and take over.

Groups of zones are referred to as regions.

if you installed with kubeadm, there are instructions to help you with Certificate Management and Upgrading kubeadm clusters.

Production-quality workloads need to be resilient and anything they rely on needs to be resilient (such as CoreDNS).

Add nodes to the cluster: If you are managing your own cluster you can add nodes by setting up your own machines and either adding them manually or having them register themselves to the cluster’s apiserver.

Set up node health checks: For important workloads, you want to make sure that the nodes and pods running on those nodes are healthy.

Authentication: The apiserver can authenticate users using client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth.

Authorization: When you set out to authorize your regular users, you will probably choose between RBAC and ABAC authorization.

Role-based access control (RBAC): Lets you assign access to your cluster by allowing specific sets of permissions to authenticated users. Permissions can be assigned for a specific namespace (Role) or across the entire cluster (ClusterRole).

Attribute-based access control (ABAC): Lets you create policies based on resource attributes in the cluster and will allow or deny access based on those attributes.

Set limits on workload resources

Set namespace limits: Set per-namespace quotas on things like memory and CPU

Prepare for DNS demand: If you expect workloads to massively scale up, your DNS service must be ready to scale up as well.

Each control plane node creates a local etcd member and this etcd member communicates only with the kube-apiserver of this node.

This topology couples the control planes and etcd members on the same nodes.

An HA cluster with external etcd is a topology where the distributed data storage cluster provided by etcd is external to the cluster formed by the nodes that run control plane components.

etcd members run on separate hosts, and each etcd host communicates with the kube-apiserver of each control plane node.

This topology decouples the control plane and etcd member. It therefore provides an HA setup where losing a control plane instance or an etcd member has less impact and does not affect the cluster redundancy as much as the stacked HA topology.

kubeadm uses the network interface associated with the default gateway to set the advertise address for this particular control-plane node's API server. To use a different network interface, specify the --apiserver-advertise-address=<ip-address> argument to kubeadm init

Do not share the admin.conf file with anyone and instead grant users custom permissions by generating them a kubeconfig file using the kubeadm kubeconfig user command.

The token is used for mutual authentication between the control-plane node and the joining nodes. The token included here is secret. Keep it safe, because anyone with this token can add authenticated nodes to your cluster.

You must deploy a Container Network Interface (CNI) based Pod network add-on so that your Pods can communicate with each other. Cluster DNS (CoreDNS) will not start up before a network is installed.

Make sure that your Pod network plugin supports RBAC, and so do any manifests that you use to deploy it.

The cluster created here has a single control-plane node, with a single etcd database running on it.

The node-role.kubernetes.io/control-plane label is such a restricted label and kubeadm manually applies it using a privileged client after a node has been created.

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

remove the node-role.kubernetes.io/control-plane:NoSchedule taint from any nodes that have it, including the control plane nodes, meaning that the scheduler will then be able to schedule Pods everywhere.

view templates are written in a language called ERB (Embedded Ruby) which is converted by the request cycle in Rails before being sent to the user.

Each action's purpose is to collect information to provide it to a view.

A view's purpose is to display this information in a human readable format.

routing file which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions.

You can create, read, update and destroy items for a resource and these operations are referred to as CRUD operations

A controller is simply a class that is defined to inherit from ApplicationController.

If not found, then it will attempt to load a template called application/new. It looks for one here because the PostsController inherits from ApplicationController

:formats specifies the format of template to be served in response. The default format is :html, and so Rails is looking for an HTML template.

:handlers, is telling us what template handlers could be used to render our template.

When you call form_for, you pass it an identifying object for this form. In this case, it's the symbol :post. This tells the form_for helper what this form is for.

that the action attribute for the form is pointing at /posts/new

When a form is submitted, the fields of the form are sent to Rails as parameters.

parameters can then be referenced inside the controller actions, typically to perform a particular task

params method is the object which represents the parameters (or fields) coming in from the form.

Active Record is smart enough to automatically map column names to model attributes,

Rails uses rake commands to run migrations, and it's possible to undo a migration after it's been applied to your database

every Rails model can be initialized with its respective attributes, which are automatically mapped to the respective database columns.

migration creates a method named change which will be called when you run this migration.

The action defined in this method is also reversible, which means Rails knows how to reverse the change made by this migration, in case you want to reverse it later

Migration filenames include a timestamp to ensure that they're processed in the order that they were created.

@post.save returns a boolean indicating whether the model was saved or not.

prevents an attacker from setting the model's attributes by manipulating the hash passed to the model.

If you want to link to an action in the same controller, you don't need to specify the :controller option, as Rails will use the current controller by default.

inherits from ActiveRecord::Base

Rails includes methods to help you validate the data that you send to models

Rails can validate a variety of conditions in a model, including the presence or uniqueness of columns, their format, and the existence of associated objects.

redirect_to will tell the browser to issue another request.

rendering is done within the same request as the form submission

Each request for a comment has to keep track of the post to which the comment is attached, thus the initial call to the find method of the Post model to get the post in question.

pluralize is a rails helper that takes a number and a string as its arguments. If the number is greater than one, the string will be automatically pluralized.

The render method is used so that the @post object is passed back to the new template when it is rendered.

it accepts a hash containing the attributes that you want to update.

field_with_errors. You can define a css rule to make them standout

belongs_to :post, which sets up an Active Record association

creates comments as a nested resource within posts

call destroy on Active Record objects when you want to delete them from the database.

Rails allows you to use the dependent option of an association to achieve this.

store all external data as UTF-8

you're better off ensuring that all external data is UTF-8

use UTF-8 as the internal storage of your database

Rails defaults to converting data from your database into UTF-8 at the boundary.

:patch

By default forms built with the form_for helper are sent via POST

The :method and :'data-confirm' options are used as HTML5 attributes so that when the link is clicked, Rails will first show a confirm dialog to the user, and then submit the link with method delete. This is done via the JavaScript file jquery_ujs which is automatically included into your application's layout (app/views/layouts/application.html.erb) when you generated the application.

Without this file, the confirmation dialog box wouldn't appear.

just defines the partial template we want to render

As the render method iterates over the @post.comments collection, it assigns each comment to

use the authentication system

require and permit

the method is often made private to make sure it can't be called outside its intended context.

Kubebuilder is a comprehensive development kit for building and publishing Kubernetes APIs and Controllers using CRDs

Design declarative APIs for operators, not imperative APIs. This aligns well with Kubernetes APIs that are declarative in nature.

scaling, backup, restore, and monitoring. An operator should be made up of multiple controllers that specifically handle each of the those features.

the operator can have a main controller to spawn and manage application instances, a backup controller to handle backup operations, and a restore controller to handle restore operations.

each controller should correspond to a specific CRD so that the domain of each controller's responsibility is clear.

If you keep a log for every container, you will likely end up with unmanageable amount of logs.

integrate application-specific details to the log messages such as adding a prefix for the application name.

you may have to use external logging tools such as Google Stackdriver, Elasticsearch, Fluentd, or Kibana to perform the aggregations.

adding labels to metrics to facilitate aggregation and analysis by monitoring systems.

a more viable option is for application pods to expose a metrics HTTP endpoint for monitoring tools to scrape.

A good way to achieve this is to use open-source application-specific exporters for exposing Prometheus-style metrics.

in leveraging regular Ruby classes and object oriented design patterns to build a simple, robust and scaleable authorization system

map to the name of a particular controller action

In the generated ApplicationPolicy, the model object is called record.

record

authorize

authorize would have done something like this: raise "not authorized" unless PostPolicy.new(current_user, @post).update?

pass a second argument to authorize if the name of the permission you want to check doesn't match the action name.

you can chain it

authorize returns the object passed to it

the policy method in both the view and controller.

have some kind of view listing records which a particular user has access to

ActiveRecord::Relation

Instances of this class respond to the method resolve, which should return some kind of result which can be iterated over.

scope.where(published: true)

use this class from your controller via the policy_scope method:

PostPolicy::Scope.new(current_user, Post).resolve

policy_scope(@user.posts).each

This method will raise an exception if authorize has not yet been called.

verify_policy_scoped to your controller. This will raise an exception in the vein of verify_authorized. However, it tracks if policy_scope is used instead of authorize

need to conditionally bypass verification, you can use skip_authorization

skip_policy_scope

Having a mechanism that ensures authorization happens allows developers to thoroughly test authorization scenarios as units on the policy objects themselves.

Pundit doesn't do anything you couldn't have easily done yourself. It's a very small library, it just provides a few neat helpers.

all of the policy and scope classes are just plain Ruby classes

rails g pundit:policy post

define a filter that redirects unauthenticated users to the login page

fail more gracefully

raise Pundit::NotAuthorizedError, "must be logged in" unless user

having rails handle them as a 403 error and serving a 403 error page.

config.action_dispatch.rescue_responses["Pundit::NotAuthorizedError"] = :forbidden

with I18n to generate error messages

retrieve a policy for a record outside the controller or view

define a method in your controller called pundit_user

Pundit strongly encourages you to model your application in such a way that the only context you need for authorization is a user object and a domain model that you want to check authorization for.

Pundit does not allow you to pass additional arguments to policies

set up a permitted_attributes method in your policy

policy(@post).permitted_attributes

permitted_attributes(@post)

Pundit provides a convenient helper method

permit different attributes based on the current action,

If you have defined an action-specific method on your policy for the current action, the permitted_attributes helper will call it instead of calling permitted_attributes on your controller

If you don't have an instance for the first argument to authorize, then you can pass the class

It is not some kind of failsafe mechanism or authorization mechanism.

Pundit will work just fine without using verify_authorized and verify_policy_scoped

Pods are immutable, which means that when they die, they are not resurrected. The Kubernetes cluster creates new pods in the same node or in a new node once a pod dies. 

For internal application access within a Kubernetes cluster, ClusterIP is the preferred method

Kubernetes Ingress is an API object that provides routing rules to manage external users' access to the services in a Kubernetes cluster, typically via HTTPS/HTTP.

content-based routing, support for multiple protocols, and authentication.

Ingress is made up of an Ingress API object and the Ingress Controller.

Kubernetes Ingress is an API object that describes the desired state for exposing services to the outside of the Kubernetes cluster.

An Ingress Controller reads and processes the Ingress Resource information and usually runs as pods within the Kubernetes cluster.  

If Kubernetes Ingress is the API object that provides routing rules to manage external access to services, Ingress Controller is the actual implementation of the Ingress API.

Layer 7 (L7) refers to the application level of the OSI stack—external connections load-balanced across pods, based on requests.

if Kubernetes Ingress is a computer, then Ingress Controller is a programmer using the computer and taking action.

the Ingress Controller is an application that runs in a Kubernetes cluster and configures an HTTP load balancer according to Ingress Resources.

ClusterIP is the preferred option for internal service access and uses an internal IP address to access the service

A NodePort is a virtual machine (VM) used to expose a service on a Static Port number.

a NodePort would be used to expose a single service (with no load-balancing requirements for multiple services).

Ingress enables you to consolidate the traffic-routing rules into a single resource and runs as part of a Kubernetes cluster.

An application is accessed from the Internet via Port 80 (HTTP) or Port 443 (HTTPS), and Ingress is an object that allows access to your Kubernetes services from outside the Kubernetes cluster. 

To implement Ingress, you need to configure an Ingress Controller in your cluster—it is responsible for processing Ingress Resource information and allowing traffic based on the Ingress Rules.