import {Chart} from './snowfall.js' export const year = 2018 # Last year’s snowfall In {year}, the snowfall was above average. It was followed by a warm spring which caused flood conditions in many of the nearby rivers. <Chart year={year} color="#fcb32c" />
import {Chart} from './snowfall.js' export const year = 2018 # Last year’s snowfall In {year}, the snowfall was above average. It was followed by a warm spring which caused flood conditions in many of the nearby rivers. <Chart year={year} color="#fcb32c" />
year
in yellow?import {Chart} from './snowfall.js' export const year = 2018 # Last year’s snowfall In {year}, the snowfall was above average. It was followed by a warm spring which caused flood conditions in many of the nearby rivers. <Chart year={year} color="#fcb32c" title="This supports *markdown*?" description="Can you write multi-line description? Can it contain MDX?" />
Chart
Needed A title
And description
?-- hello: who: World!
<hello who="World!" />
-- hello: who: World!
hello
-- ftd.row hello: string who: Everyone! spacing: 10 --- ftd.text: Hello, --- ftd.text: $who background-color: $fpm.color.main.background.base
caption
for even better syntax!-- hello: World!
string
to caption
-- ftd.row hello: caption who: Everyone! spacing: 10 --- ftd.text: Hello, --- ftd.text: $who background-color: $fpm.color.main.background.base
-- integer size: 42 -- string message: Hello React Bangalore!
$
only comes in value position-- ftd.text: $message size: $size
-- record person: caption name: string company: optional body bio:
-- person amitu: Amit Upadhyay company: FifthTry, Inc. Amit is the founder and CEO of FifthTry, Inc. He loves open source and has created FTD and FPM.
-- ftd.text: $amitu.name -- ftd.text: Company -- ftd.text: $amitu.company
-- person list people:
-- people: Amit Upadhyay company: FifthTry, Inc. -- people: Arpita Jaiswal company: FifthTry, Inc. Arpita is a software developer at FifthTry and is the lead contributor of FTD and FPM.
$loop$
ing over a list-- show-person: $o.name $loop$: people as o company: $o.company bio: $o.bio -- ftd.column show-person: caption name: string company: optional body bio: --- .. rest of the body ..
if
-- show-person: $o.name if: $o.bio is not null $loop$: people as o company: $o.company bio: $o.bio
if
and $on-*$
handling-- boolean open: true -- ftd.text: You can see me! if: $open -- ftd.text: Toggle $on-click$: toggle $open
-- boolean funky: false -- ftd.text: Some Text color if $funky: $fpm.color.main.text background-color if $funky: $fpm.color.main.background.base -- ftd.text: Toggle $on-click$: toggle $funky
-- import: fifthtry.github.io/Forest-Theme as ft -- import: ftd-dev.vercel.app/config -- import: fpm -- ft.page: toc: $config.empty-toc -- ft.create-section: -- ft.bread-crumb: --- ft.crumb: Create a book link: / --- ft.crumb: Pick a theme -- ft.template-list: --- ft.theme: Forest if: not $ftd.dark-mode link: https://github.com/FifthTry/Forest-Template/generate image: images/forest.png live_preview: https://fifthtry.github.io/Forest-Template/ --- ft.theme: Forest if: $ftd.dark-mode link: https://github.com/FifthTry/Forest-Template/generate image: images/dark-forest.png live_preview: https://fifthtry.github.io/Forest-Template/
Kubernetes: A Kubernetes cluster consists of a set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
The worker node(s) host the Pods that are the components of the application workload. The control plane manages the worker nodes and the Pods in the cluster. In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.
Control Panel: The control planes components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new pod when a deployments replicas field is unsatisfied).
Control plane components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all control plane components on the same machine, and do not run user containers on this machine. See Creating Highly Available clusters with kubeadm for an example control plane setup that runs across multiple VMs.
Kube Api Server: The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane.
The main implementation of a Kubernetes API server is kube-apiserver. 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.
etcd: Consistent and highly-available key value store used as Kubernetes backing store for all cluster data.
If your Kubernetes cluster uses etcd as its backing store, make sure you have a back up plan for those data.
Kube Controller Manager: Control plane component that runs controller processes.
Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.
Cloud controller manager: A Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud providers API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.
The cloud-controller-manager only runs controllers that are specific to your cloud provider. 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.
As with the kube-controller-manager, the cloud-controller-manager combines several logically independent control loops into a single binary that you run as a single process. You can scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
Kubelet: 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. The kubelet doesnt manage containers which were not created by Kubernetes.
Kube-proxy: 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.
kube-proxy uses the operating system packet filtering layer if there is one and its available. Otherwise, kube-proxy forwards the traffic itself.
Container runtime: The container runtime is the software that is responsible for running containers.
Kubernetes supports several container runtimes: Docker, containerd, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface).
Amit Upadhyay
Twitter: amitu
Github: amitu
Email: amitu@fifthtry.com
FTD Site: ftd.dev
FPM (FTD Static Site Generator): fpm.dev