文章目录

Overview
Concept
- Hardware
- - 1. Node
  - 2. Cluster
  - 3. Persistent Volumes
- Software
- - 1. Container
  - 2. Pod
  - 3. Deployment
  - 4. Ingress
Kaniko
- using docker
- using k8s
Helm

Overview

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

Concept

https://medium.com/google-cloud/kubernetes-101-pods-nodes-containers-and-clusters-c1509e409e16

Hardware

1. Node

2. Cluster

3. Persistent Volumes

Software

1. Container

2. Pod

Unlike other systems you may have used in the past, Kubernetes doesn’t run containers directly; instead it wraps one or more containers into a higher-level structure called a pod. Any containers in the same pod will share the same resources and local network. Containers can easily communicate with other containers in the same pod as though they were on the same machine while maintaining a degree of isolation from others.

3. Deployment

A deployment’s primary purpose is to declare how many replicas of a pod should be running at a time. When a deployment is added to the cluster, it will automatically spin up the requested number of pods, and then monitor them. If a pod dies, the deployment will automatically re-create it.

4. Ingress

There are multiple ways to add ingress to your cluster. The most common ways are by adding either an Ingress controller, or a LoadBalancer.

Kaniko

Since docker is not the only tool to use container, we have many other choices.
As a container engine, docker can be the best choice.
While there are tools that can build image without daemon thread: Buildah & Kaniko.
While Podman is a container engine without daemon thread and root, and podman build == buildah.
While Kaniko is widely used to build image in K8S.

Since is difficult for docker to build image in container:

mount socket to access the docker daemon, root needed.
use dind container with –privileged.

Kaniko totally run in user space, do not need daemon or root:

in k8s
in docker

It has three parameters:

dockerfile: the container dockerfile need to be build
context
destination: the cloud image base need to upload

using docker

docker run --name kaniko \-v $HOME/.docker/:/kaniko/.docker \-v /data/kaniko:/workspace \gcr.azk8s.cn/kaniko-project/executor:latest \--dockerfile /workspace/Dockerfile \--destination willdockerhub/ubuntu:test \--context dir:///workspace/

using k8s

cat > kaniko-pod.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:name: kaniko
spec:containers:- name: kanikoimage: gcr.azk8s.cn/kaniko-project/executor:latestargs: ["--dockerfile=/workspace/Dockerfile","--context=dir://workspace","--destination=willdockerhub/ubuntu:test"] # replace with your dockerhub accountvolumeMounts:- name: kaniko-secretmountPath: /kaniko/.docker- name: dockerfile-storagemountPath: /workspacerestartPolicy: Nevervolumes:- name: kaniko-secretsecret:secretName: regcreditems:- key: .dockerconfigjsonpath: config.json- name: dockerfile-storagehostPath:path: /data/kaniko/type: Directory
EOF

Helm

对于应用发布者而言，可以通过Helm打包应用，管理应用依赖关系，管理应用版本并发布应用到软件仓库。
对于使用者而言，使用Helm后不用需要了解Kubernetes的Yaml语法并编写应用部署文件，可以通过Helm下载并在kubernetes上安装需要的应用。
**A Chart **is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.
**A Repository **is the place where charts can be collected and shared. It’s like Perl’s CPAN archive or the Fedora Package Database, but for Kubernetes packages.
**A Release **is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the same cluster. And each time it is installed, a new release is created. Consider a MySQL chart. If you want two databases running in your cluster, you can install that chart twice. Each one will have its own release, which will in turn have its own release name.

Kubernetes: Overview, Kaniko Helm相关推荐

利用Serverless Kubernetes和Kaniko快速自动化构建容器镜像
前言: 在云原生时代中,容器镜像是一切应用分发的基础载体,除了dockerhub作为流行的镜像仓库外,各大公有云厂商也都提供了功能丰富镜像仓库服务,如ACR(Aliyun Container Regi ...
Kubernetes中安装Helm及使用
Helm 致力于成为 Kubernetes 的包管理工具,可以方便地发现.共享和使用为 Kubernetes 构建的应用,它包含几个基本概念: Chart:一个 Helm 包,其中包含了运行一个应用所 ...
Kubernetes系列之Helm介绍篇
本次系列使用的所需部署包版本都使用的目前最新的或最新稳定版,安装包地址请到公众号内回复[K8s实战]获取介绍 Helm 是 Deis 开发的一个用于 Kubernetes 应用的包管理工具,主要用来 ...
helm使用_通过图表提升您在Kubernetes上使用Helm的能力
helm使用应用程序是代码和配置的复杂集合,这些集合对其安装方式有很大的影响. 像所有开源软件一样,它们可以从源代码安装,但是大多数时候用户希望简单,一致地安装某些东西. 这就是为什么软件包管理器几 ...
Kubernetes学习之Helm包管理器
一.认识Helm 在之前的文章中的应用部署过程可知,在Kubernetes系统上面部署容器化应用时需要事先手动编写资源配置清单文件,而且其每一次的配置定义基本上都是硬编码.基本上无法实现复用.对于较大 ...
三、《云原生 | Kubernetes篇》helm 升级更新
helm作为Kubernetes的包管理器,典型的C/S架构: helm:命令行工具,一般安装在CI/CD Server上使用 tiller: 是helm的服务端,部署在Kubernetes上,管理R ...
关于Kubernetes中使用Helm部署应用及私有Helm源搭建的一些笔记
写在前面学习K8s涉及,整理笔记记忆博文偏实战,内容涉及: Helm的基本概念及安装,Helm源配置 chart包的安装部署私有Helm源的搭建及chart包的push和pull "不 ...
Kubernetes — Overview
目录文章目录目录 Kubernetes 的发展历史 Kubernetes 的电梯间演讲 Kubernetes 的核心理念 Kubernetes 的发展历史 Kubernetes,名词源于希腊语,意 ...
13、Kubernetes核心技术Helm
文章目录一.为什么引入Helm 二.Helm介绍三.Helm组件及架构四.Helm v3变化五.helm仓库六.使用helm快速部署应用 6.1 使用命令搜索应用 6.2 根据搜索内容选择安 ...

Kubernetes: Overview, Kaniko Helm